[블록체인] ZKP · DeFi · Solidity 기말고사 정리

 

 

 

1. ETH Advanced  

* Trillema – 1. Security - The ability of the blockchain system to operate as expected, defend itself from attacks, bugs, and other unforeseen issues : 보안  

2. Scalability - The ability for a blockchain system to handle an increasingly growing amount of transactions : 확장성   

3. Decentralization - Creating a blockchain system that does not rely on a central point of control  

 

- 이더리움은 보안은 포기하기 어려움, 남은 둘 중 탈중앙성을 첫번째로 선택  

+ 이더리움 위에서 롤업 체인들이 확장성을 가져가도록 설계  

- 다른 체인들, 솔라나 -> 탈중앙성 포기, 확장성 선택 : 실제로 사람들이 쓸만하도록 만들자  

- 비트코인 (BTH)   = 친구한테 돈보내는데 10분씩 걸리는 것  

 

- How to solve scalability? - 10개를 1초에 처리 vs 100개를 10초에 처리 -> 둘은 다름   

- Bandwidth = throughput (둘 다 10으로 동일)   

- Latency = 개인의 입장에서 10초, 1초마다 결과가 나오는 것은 다름  

 

* Layer 1 (ETH) - Data availability layer / Security layer   

* Layer 2 - Faster confirmation / Lower transaction cost / Customization  

+ 2의 모든 내용 layer 1에 쓰임 -> shut-down 되더라도, 1에서 데이터(돈) 회수 가능  

= Layer 2의 모든 tx들이 layer 1에도 있다 + 검증이 가능하다 (security 측면)  

 

 

- Layer 1과 2 연결하는 smart contract  

- 체인 재단에서 운영하는 sequencer  : tx들을 블럭에 넣는다 (탈중앙화 이슈 O)    

- transaction order 정의함 - MEV : Maximal Extractable Value  : 최대추출 가능가치 문제 O     

- Layer 2 tx들이 쌓인 블럭이 1의 tx 하나에 들어감 -> 문제가 생기면 해당 tx를 1이 실행 가능   

- Layer 3는 Layer 2에 기록됨 (Layer1에 security에 기대고 있는가는 의문)  

- 실제 computation (balance 변화, coin swap 등)은 layer 2에서 빠르게 처리, User에게 제공     

 

 

 

 

* Types of Rollups   

1. Optimistic Rollup - Assume that blocks are generated in a valid way

If there is a single honest validator at least, we can find out invalid blocks in a certain amount of time (검증 일주일 걸림)  

- 트랜젝션이 문제가 없다고 가정하고 실행, 하나라도 정직한 validator가 있다면, 문제 발견, 제보 O  

- Layer 1에 전부 올려서 실행 -> TPS 낮음 / 데이터 모두 올려야 하니깐, Privacy 구성 어렵고 비쌈   

- EVM 거의 그대로 올릴 수 있다    

 

2. Zero-Knowledge Rollup

- The validity of a block can be proven by zero knowledge  

- No need to check validity by the nodes / But generating proof is computationally heavy  

- 영지식 기술 – tx 모두 실행하지 않아도, 트랜잭션의 유효성 검증 가능   

- 수학적 검증 : 증명을 생성하는 것이 computation 많다 / 대신 매우 빠르다.   

- Layer 1에 모두 올릴 필요X -> 높은 TPS / 영지식 증명이 가능한 형태 변형, 모든 솔리디티코드는 X  

- Layer 2에서 Proof 만들 때마다 연산 많이 필요 / 증명할 때 영지식으로 더욱 trust 가능           

 

- ETH는 원래 monolithic -> roll up이 되면서, exec는 L2, 나머지 둘은 L1으로 가게 됨  

- Sui, Aptos : monolithic / 이더리움 진영에서 파생되는 많은 레이어들 -> Modular  - celestia : cosmos 별도의 체인           

 

 

 

2. ZKP Zero Knowledge Proof  

- A protocol in which one party can convince another party    

- some given statement is true / without conveying to the verifier any information   

- beyond the mere fact of the statement’s truth  (원본데이터 노출 없이, 상대를 검증 가능)  

 

- Prover vs Validator : The Ali Baba Cave  

– P가 B로 가는 길을 택함 -> V가 A로 나오라 함 -> P가 비번을 알아야만 가능  1

. Completeness : 완전성 - Peggy 진짜라면 테스트를 계속 통과  

2. Soundness : 건전성 - Peggy가 거짓말쟁이라면 확률적으로 들통남  

3. Zero-Knowledge :영지식성 - Victor는 비밀번호도, 문 여는 원리도 모름   

- P의 지식을 증명 받았을 뿐, 그 지식 자체는 모름  

 

- Peggy proved that she knows the password of the gate without revealing the password.  

* Efficiently Verifiable Proofs (NP-proofs)  

- Claim 증명하고자 하는 명제 / P: 증명하려는 사람 / V: 검증하려는 사람   

- Prover : 시간 제한 X  - Verifier : 다항시간: O(n), O(n²), O(n³) 등  

* NP 문제 = V 매우 빠름, P는 오래 계산도 ok  - 검증이 너무 느리면 프로토콜 의미 X  

- NP: 답 검증하기는 쉬우나, 답 찾기는 어려움        

 

 

- P는 서로 다른 색 주장 / V는 색맹 = 다른 색인지 직접 볼 수 X, but 거짓말을 잡아낼 방법은 O  

- 검증자 무작위 뒤집기 -> 증명자가 선택을 따라올 수 있는지 확인 -> 두 색 다름을 ZKP 증명   

- 검증자 던졌던 동전 A의 결과 == 증명자 추측 -> accept, 다르면 reject (P 거짓이면 1/2 찍기 ing)  

 

- Def: L is an NP-language (or NP-decision problem), if there is a poly (|x|) time verifier V where  

- Completeness = True claims have (short) proofs  

- Soundness = False theorems have no proofs  

 

 

 

 

 

* Why do we need random bit b?   

- If we only use b = 0, soundness cannot be satisfied. (50% 확률로는 맞출 수 있음)  

- z^2 = s * y mod N / we can find s even if we don’t know x (s = z^2 / y mod N)  

- Cheating prover can provide the same s repeatedly, but there is no way to verify.  

- b가 random이어야, 절반 확률로 반복했을 때 사기꾼이 걸림 (soundness 충족됨)  

+ ZCash (zk-SNARK) – ZKP 사용, 소유자 간 개인정보 노출 없이, 상호 코인 전송 가능    

 

 

 

3. Decentralized Finance  

- DeFi = Decentralized Finance   

- Decentralized : 중앙 기관이 소유권을 갖지 X / 자산을 소유한 사람만이 자산을 이동시킴  

- Finance : 금융 서비스 (예금, 대출, 자산 거래 등)  

- KYC = 고객 확인 : Know Your Customer   

- AML = 자금세탁방지 : Anti-Money Laundering              

 

 

 

 

* Landscape of DeFi Protocols            

- 프로토콜 실 사례 : staking, lending, DEX, Advanced  

 

 

 

3-1. Staking   

- 토큰을 예치하면 이자 지급 / 이자의 원천 = 프로토콜에서 발생하는 인플레이션을 이자로 지급   

- PoS(Proof of Stake) 합의 알고리즘을 사용하는 경우 많이 사용 

 * ETH Consensus - The Merge 이후 PoS 체인 전환 / 노드 검증자 되려면 32 ETH 필요  

- 검증자는 블록 제안 + 제안된 블록의 유효성 검증 / 제안 · 검증 결과에 따라 리워드 수취     

 

* ETH Staking (1, 2 = 32 ETH need vs 3, 4 = 꼭 32개 없어도 됨)   

1. Solo Staking = 본인이 직접 노드 운영하며, 블록을 검증하고, 그에 맞는 인센티브를 수취  

2. Staking as a Service = 클라우드 서비스 등 하드웨어 인프라를 제공하는 서비스  

+ 직접 노드를 운영하듯 32 ETH 예치해야 하며, 수익 모두 가져갈 수 있음 but 노드 운영비 지출  

3. Pool Staking = 32 ETH보다 적은 양(소액)으로 다른 서비스를 통해 예치, 여러 사람 모아서 운영  

4. CEX Staking = 중앙화 거래소에 토큰을 입금하고 입금된 양을 기반으로 스테이킹 리워드 지급  

- 입출금 빈번, staking to unstaking 1주일 정도 걸림, 100개 중 50개 정도만 예치 가능   

 

* Liquid Staking Token, Liquid Staking Derivatives  

- 단순히 스테이킹 기능을 제공 X, 스테이킹하면 별도의 토큰을 지급 (10 ETH -> 10 stETH)  

- Utility of LST = ETH-stETH 통해 즉시 unstake = stETH 시장에서 바로 팔면 즉시 ETH 전환 가능  

- stETH 맡기고 다른 토큰 대출 (ETH, USDT, etc) -> looping, 레버리지 (10 -> 15, 20 가능)   

- wstETH(wrapped) 통해 compounding 가치 표현하는 토큰으로 전환하여 DeFi 이용 (친화적)   

 

- ETH : stETH = 1:1 거의 비율 고정, but 이자 컴파운딩 X, 수량 증가 (rebase)   

- wstETH = 수량 고정, 토큰의 가치가 알아서 올라감, 이자 컴파운딩 O  

- Liquid = 유동성, 스테이킹을 했음에도, 자금이 묶이지 않고 계속 쓸 수 있다는 의미   

 

* Kaia Consensus - PoS + PBFT 컨센서스 활용 / 카카오에서 개발  

- 노드 검증자가 되기 위해서는 5M KLAY 필요 / 검증자는 블록을 제안 or 제안된 블록 유효성 검증  

- 매 epoch마다 round-robin 방식으로 proposer 선정  

- Block reward = Validator 50% + Klaytn Community Fund 30% + Klaytn Foundation Fund 20%        

 

3-2. Lending   

- Lending · DEX = Protocol 코인들과 연관성이 깊지는 않음, 별도의 서비스   

- 특정 토큰을 예치(Deposit)하면 다른 토큰을 빌릴(Borrow)수 있음 like 은행  

- 10 ETH 예치하고 1000 USDC 빌림 / Deposit에 대한 이자는 얼마나 많이 빌려갔는지에 따라 변동  

 

* AAVE – borrow 이자율과 supply 이자율의 차이가 아베의 수익률이 됨 (은행 개념)   

- 과담보대출 (Overcollateralization)  

- 대출을 받기 위해서는 대출받을 가치보다 더 높은 가치의 예치(Deposit)해야 함 (담보보다 적은 돈)  

- $100가치의 ETH 예치 -> $70의 USDT 빌림가능 / 대출받은 가치 > 예치가치 하락 -> 청산발생   

- $100가치의 ETH가 토큰 가격 하락에 의해 $70 가치가 되면 청산이 일어날 수 있다. (조작 가능)  

 

- 플래시 론(Flash Loan)  

- 담보 없이 대출을 실행하되, 한 트랜잭션 내에서 대출상환이 완료되어야 함  

- 플래시 론 공격에 의한 해킹 사례 주의 필요   

 

* Compound (like AAVE)   

- cToken - 담보 토큰별로 생성되는 컨트랙트 / 담보 토큰을 예치하면 비율에 맞게 cToken 발행  

- mint/redeem/borrow/repay/liquidate / ERC-20 기반 토큰 표준 사용, 다른 DeFi서 다시 이용 가능  

- 과담보대출 - cToken의 계좌 유동성을 기반으로 대출 가능한 자산을 확인  

- 미리 설정된 대출한도보다 작을 경우에만 대출 실행  

 

* MakerDAO  

- DAI – MakerDAO에서 발행하는 1달러의 가치를 유지하는 토큰   

- ETH나 다른 토큰들을 담보로 발행됨 / 담보의 가치가 부족해질 경우 청산됨   

- MKR - 거버넌스 토큰   

- 어떤 담보물들을 인정할 지, 담보 비율 등의 파라미터 조절에 사용 / 수수료와 벌금에 사용    

 

3-3. DEX  

- 거래소: CEX (like upbit) vs DEX (탈중앙 거래소)   

- Decentralized Exchanges   

- 오더 북을 채울 때마다 트랜잭션을 만들기 힘듦 : 트랜잭션 수수료, 트랜잭션 실행시간  

- 탈중앙화 거래소는 다른 형태의 구현이 필요 / DB가 블록체인이기 때문에!  

 

* Uniswap V2              

* IL = 비영구적 손실 / 토큰 보유 대비 손실 = LP(유동성 풀에 돈을 넣은 사람)가 입는 손해   

* Uniswap (DEX) : CEX 오더북 대신, Liquidity Pool에 코인을 넣어두고, 수학 공식 자동 가격 결정   

- 유동성 K는 일정, 유동성 풀에 넣었다 = 매수/매도 발생  

- V2 : 모든 가격 구간에 얇게 유동성 제공, LP 자산이 거의 안 쓰이는 가격 구간에 묶임  

- V3 : 필요한 구간만 유동성 집중, 효율 증가, 수익 증가, 가격이 범위를 넘어가면 비활성화 (수익 0)   

 

Uniswap V2

 

 

 

Uniswap V3

 

 

 

+ Slippage : 풀에 돈(유동성)이 적으면, 조금만 바뀌어도 가격 변동 심해서 손해 발생, 거래 불안정  

- V3: 특정 구간에만 돈을 몰아 넣으면, 해당 구역의 유동성 커짐 -> slippage 개선  

- but IL 증가 가능 : LP 구간을 나가면, (ETH 2000 도달 -> USDT만 갖게 됨, 더 올라도 계속 놓침)   

- V2에 나온 프로토콜, V3에서는 큰 의미 X  : 좁은 공간에 유동성을 깔면 되니깐   

- Curve : 스테이블코인 간 스왑 시, 슬리피지 거의 X  

- 3개의 component 서로 상호보완적  : Staking, Lending, DEX   

 

3-4. Advanced  

* DEX Aggregator = 여러 DEX에 나눠서 swap요청 보내면 slippage 최소화 가능  

- 여러 DEX에서 스왑 가능한 토큰이 다를 수 있는데, 이를 모아서 한 군데서 스왑 가능  

- 하나의 DEX만 사용하더라도 routing(pool)을 여러 경로를 사용하면 slippage 최소화 가능  

- 최근에는 여러 체인을 거치는 cross-chain aggregator도 존재  

 

* Pandle – Yield Tokenization : 전통 금융이 블록체인 De-fi 올라오려고 함  

- 이자 토큰과 원금 토큰으로 분리 (Principal Token 원금 + Yield Token 이자)  

- ETH → stETH (이자 + 원금) → SY-stETH → PT-stETH (원금) + YT-stETH (이자)   

 

* Summary   

1. Staking : 네트워크의 보안에 기여 / 이자를 받을 수 있음 / 중요 의사결정에 투표할 수 있음  

- LST를 통해 다시 DeFi를 이용할 수 있음  

2. Lending : DeFi의 은행 / 예금 · 대출을 통한 레버리지 / 과담보대출 / 플래시론  

3. DEX : Uniswap V2 - CPMM, 슬리피지(Slippage), 비영구적 손실(Impermanent Loss)  

- Uniswap V3 - 집중화된 유동성(Concentrated Liquidity)   

- Curve StableSwap - 가치변동성이 적은 토큰의 slippage 최적화   

4. Advanced : DEX aggregator 통한 swap 비용 최적화   

: 하나만 사용하면 slippage 증가 가능, 모든 거래가 한 곳에 몰리지 X (DEX 별 토큰 유동성 다름)  

- Bridge-DEX aggregator 통한 multichain swap 비용 최적화   

- Pendle - 이자와 원금을 분리하여 별도의 토큰으로 DeFi 이용    

 

 

 

4. Blockchain Service Development  

- Web 1.0 : 단방향, 집에 있는 PC(HW)  

- Web 2.0 : 양방향, 페이스북(SNS),  개인화된 컨텐츠 환경, 실시간 정보 교환  

- Web 3.0 : 내 데이터에 대한 주권,   블록체인, 정보를 넘어선 가치 교환 

 + 2.0에 추가된 features -> 3.0    

 

Web3.0

 

- Web 2.0 = 프론트 + 백엔드 나뉨 - 큰 틀에서 간단한 components   

- Web 3.0 = 블록체인은 더 필요 O  = Smart Contract / Wallet   + Endpoint Node / Indexer / Oracle  

+ 블록체인 네트워크 자체가 바로 제공할 수 없는 데이터들 = indexer    

 

1. Frontend   

- Development process is similar to normal Web2 (HTML5/css/javascript/react/vue /flutter)  

- The differences : (어떻게 블록체인 기술들과 상호작용 할 지 고민 필요)     

- Wallet / Web3 SDK / RPC request to Blockchain nodes / Blockchain Indexed data   

 

2. Backend  

- When designing API/DB schema, need to consider how to interact with blockchain data   

- Sometimes, need to listen to the changes of blockchain data / Then, put the changes into DB   

 

3. Smart Contract   

- A program deployed on a blockchain network   

- This program can be executed only via submitting a transaction   

- Anyone can see the change / The change cannot be rolled back (immutable 특성)  

 

4. Oracle   

- Data outside of the chain can be brought into blockchain   

- Typical data = Price feed / Verifiable Random Function to verify lottery-like games   

: 온체인 데이터 조작은 상대적으로 쉬움, 바이낸스(CEX, 외부 가격을 의미)는 가격 조작 거의 불가능   

 

5. Wallet   

- One of the important components in Web3 industry (like 인터넷 브라우저 역할)  

- Tx is signed by the wallet   

1. Custodial wallet - Private key is owned by the service   

- Service can manage the funds of the users / Needs to be regulated  

2. non-custodial wallet - Private key is owned by the user (사용자 자신이 키 가짐, 복구불가)   

- Service cannot manage the funds of the users / Irrecoverable if the user lost his private key  

 

6. Endpoint Node  

- Full node of a blockchain network / entrypoint to read/write the blockchain data  

- The node can be managed by : Each service / Endpoint node service providers   

- Some of the service names (Ankr, pokt.network, All that node, Quicknode, etc.)  

 

7. Indexer   

- Blockchain node itself is insufficient to provide data to the service  

- It is inefficient for a node to produce an output of :    

the transaction history of an account / events generated by a contract  

- For this, indexer is needed (KAS, Etherscan API, Moralis, Alchemy, Covalent, Tatum, The graph)  

+ 블록체인 노드만의 정보로는 불충분, 거래 내역 추적 등 서비스를 위한 별도의 indexer protocols       

 

 

 

5. Solidity  

- Smart Contract Language for Ethereum   

- Why new language? -> To make language constructs reflecting the blockchain system  

- Language for EVM (Ethereum Virtual Machine)        

 

 

 

- 일반 언어: 프로그램 작성 시, CPU – MEM 고려, 기타 주변 기기 – 언어에서 확장된 library 활용  

- 블록체인 – storage 특성까지 언어가 고려 (여러 대의 장비가 모두 동일한 구조, 그 위에서 코딩)   

+ 휘발성 X, A to B 송금 기록이 사라지면 안되고, 저장되어야 함 -> 스토리지 고려 필요   

 

- 네트워크 연결 or 키보드 등 주변 장치 연결 control = 블록체인에서는 불가능함  

- f(x) = y / 블록체인에서는 old state 만 x에 들어감. Input(N, K) 이런 건 못 들어감   

 

* Blockchain Programming Environment   

- Smart Contract 여러 컴퓨터 위에 같이 올라가서 동작해야 한다.  

- tx를 어떤 컴퓨터에서 실행하든, 실행 결과는 동일해야 함 -> 그래야 consensus 합의 가능  

- old state에 새로운 인풋 들어올 때, new state는 어떤 컴퓨터에서 실행하든 Tx 결과 동일해야 함  

 

- Outside of Blockchain data can’t be accessible -> 외부에 있는 데이터는 접근 X   

- 데이터 조작은 transaction의 형태로만 이루어져야 한다.   

 

 

 

 

* EVM : Ethereum Virtual Machine   

- 실행 환경 = computation <-> data   

- stack-based VM (가상머신은 대부분 스택 기반) vs register-based (일반 HW, processor)      

 

- EVM : Stack-based VM / Word size: 256 bits = 32 B (x86 = 32, 64bit 구조가 다름)  

- Precompiled contracts: special & complicated instructions (ecrecover, SHA2-256, RIPEMD-160)  

- Gas is measured to pay the transaction fee / gas is calculated based on opcode and operand  

: 연산마다 gas 사용이 증가함 (gas table)  

 

* Data Types = Value Types / Reference Types / Mapping Types  

1. Value Type – 하나의 값을 갖고 가는 것 (word 1 size = copy 가능)   

* integer (= int 256, **EXP) + overflow, underflow (잔고 오버플로우 되면, 10억 이상 날아감)  

: 원래는 just wraps, safe math 등을 사용 -> solidity 0.8.0부터 tx revert 됨   

- floating point 사용 X / Fixed point number -> int + decimal 이렇게 표현함   

 

* Address (20 byte) / Address Payable (실질적으로 돈을 보내는 주소)   

- payable -> address : implicit conversion is allowed   

- address -> payable : To convert, payable(<address>) is required  

- other types -> address : Explicitly convertible from uint160, integer literals, bytes20, contract  

- other types -> payable : only address and contract are allowed  

 

- Members  

- balance (ETH 잔고, read native coin balance of the account)  

- transfer : revert if (not enough balance, rejected from the recipient account)   

ex) x.transfer(10) -> x에 잔고가 10만큼 없다면 -> 트랜잭션 실패   

+ Tansfer는 실패하면 Revert, send는 실패하더라도 false return (다른 동작 구현 가능)  

 

- Send : low level counterpart of transfer  

- returns false if the execution fails   

- call, delegatecall, staticcall : low level interface, interact with other contracts   

- input parameter should be encoded by using abi.encodeWithSignature   

- gas and value can be manually set   <- call에 보낼 가스랑 이더를 정의   

 

- storage 변경 권한 call, delegate 둘 다 가능한데 주체가 다름 (B에서 A( )의 함수를 실행 시킴)  

- call (B read/write), static(B read only), delegate (A read/write – A의 스토리지를 변경함)  

- 나머지 둘은 호출한 애가 A / delegate = B에 있는 코드로 A의 스토리지에 접근한 것   

 

- contract 배포하면 수정 불가능 -> upgradable 개념 (by delegate call)   

- context는 A(원본데이터, storage)를 사용, implementation은 계속 바꿀 수 있게 (B -> C -> D 등)  

- 실제로 A에서 B로 돈을 보낼 순 X (delegate: value X) – 모든 state에 대한 context 는 A에 있음   

 

- code : get the code of a contract  

- codehash : get the code hash of a contract (To check whether the address is contract or not)  

: contract가 아니라면, hash 값이 nil이 나오게 됨 (주소가 contract or EOA인지 알 수 있음)    

 

* Contract   

- User-defined type / Represents a deployed smart contract / Can deploy a contract runtime  

- Explicitly converted from address / Accessible members (Functions/variables declared as public)  

 

* User-defined Value Types (type C is V)   

- C is a new user-defined type / V has to be a built-in value type  

- C.wrap() and C.unwrap() are the only operators defined implicitly   

-> stateMath 구현 가능 (오버플로우 발생 여부를 체크)  

 

* Function Types   

- function (<parameter types>) {internal|external} [pure|view|payable] [returns <return types>)]

- conversion between functype A and B allowed if and only if   

: parameter types are identical / return types are identical / internal/external property is identical  

 

- state mutability of A is more restrictive than B   

: pure => view and non-payable / view => non-payable / payable => non-payable  

- Pure는 함수 내 member 변수 접근 X, only params만 사용  

- View는 멤버 접근 O, read only / pure view도 아닌 일반 함수는 멤버 접근 O, 수정도 가능  

 

- Member   

- .address : the address of the contract of the function  

- .selector : ABI function selector (func이름 + parameter 전체를 string으로 hash, 32B 중 앞의 4B)     

 

2. Reference Type – copy 하기에 큰 값들, ref 지칭 (structs, arrays, and mappings Data Location)  

1. memory : stored in memory / lifetime is limited to a function call   

2. storage : stored in the contract storage / lifetime is limited to the lifetime of the contract  

3. calldata : special data location for function call / read-only, non-persistent (휘발성)  

- lifetime is limited to a function call   

+ 내가 pointing 하는게 메모리면 바로 쓰는데, 스토리지면 불러와야 함, 두 공간 분리   

- 스토리지와 메모리 간 이동 = gas 소모, 좋은 프로그래밍 아님   

 

- Assignment between storage and memory = always create an independent copy  

- Assignment from memory to memory = only create references, changes will be visible in both  

- Assignment from storage to a local storage variable = create a reference  

- Other assignments to storage = always copy   

 

- func 바깥에 있다면? = Storage, 메모리를 바깥에 정의된 변수 x에 할당하려면, 전부 copy 해야함  

- 메모리인가 스토리지인가에 따라, 복사가 될 지, ref만 가져갈 지가 결정됨  

- dynamic size의 storage array는 push로 계속 늘려나갈 수 있는데, memory array는 늘릴 수 X    

 

* Array  

- Compile-time fixed size (uint[5])  or runtime dynamic size (uint[])   

- .push() : initialized with zero and returns the reference   

- .push(value) : appends ‘value’ to the end of array   

- bytes.concat and string.concat   : concatenation of bytes or strings  

 

* Allocating memory arrays   

- using new   

- Unlike storage arrays, .push() is not allowed. impossible to resize  

 

- Members - length : number of elements / push() : Allowed for dynamic storage arrays   

- Append zero-initialized element to the end / Returns the reference / e.g., x.push() = 2;   

- push(x) :  append x to the end / e.g., x.push(2);  

- pop() remove the last element / returns nothing (push 연이어 호출 X)  

 

* Structure   - User-defined types / Cannot contain itself  

- struct { uint8, uint, uint8 }  vs  struct { uint8, uint8, uint } = packing 차이  

- 첫번째는 워드 1개 1개 1개, 총 3개 (32B * 3) / 두번째는 앞의 둘을 워드 1개, 워드 1개 (32B * 2)     

 

3. Mapping Type   

- KeyType = any built-in value type, bytes, string, contract, or enum   

- ValueType = any type   - KeyName, ValueName = optional     

* key data is not stored, keccak256(key) is used for lookup : 매핑의 전체 길이 이런거 불가능     

 

* Layout of a Solidity Source File   

- SPDX License Identifier : SPDX (System Package Data Exchange) / MIT, GPL-3.0, Apache-2.0   

- pragma: 어떤 컴파일러 버전 이상부터, 아래 코드를 제대로 돌릴 수 있다는 명시   

+ ABI Coder (Application Binary Interface) = v1 or v2  

 

- Importing other files : import “filename”; // 다른 smart contract import 해올 수 있음   

- import "@klaytn/contracts/KIP/token/KIP7/KIP7.sol";  

 

* Constructor 불리는 시점 = 블록체인의 스마트 컨트랙트가 배포되는 시점   

- 원래 class의 constructor는 object instantiation (그때 생성자가 불림)  

- 블록체인에서는 코드가 실제로 deploy가 되었을 때, 블록체인 상에 올라올 때, Constructor가 불림  

- Only one constructor is allowed /Constructor arguments should be passed when deploying  

 

* State Variable Visibility   

1. public : Automatically generates getter functions for public variables

- The value is accessible via getter function   

2. internal : Can only be accessed within the contract / Default visibility level   

- inaccessible to derived contracts   

3. private : same as internal / Not visible in derived contracts        

 

- pure는 params 받은 것만 접근 가능 / 멤버변수 접근하지 않는 함수 = 컴파일러 최적화 가능  

- E가 C를 상속 -> compute 접근 가능   

 

* Function Modifiers   

- Mostly used to check conditions prior to execution of a function : 함수 실행 전, 체크에 활용  

- Can be overridden if it has virtual   

- Multiple modifiers = whitespace-separated list  = 여러 개 호출 시 빈 칸으로 분리   

- ‘_’ placeholder = used to denote where the function should be inserted   

=  _ 이 위치에서 함수가 실행됨  

 

* Function Modifiers   

- if 구문 충족할 때에만 함수를 실행함, _ 없으면 function 실행 안될 수 있음  

modifier checkSomething() { = 함수 호출 전/후에 추가 로직을 실행하도록 하는 문법 (미들웨어)      

    // 함수 실행 전에 실행될 코드      

    doCheck();     

    _ ;  // ← 여기서 원래 함수가 실행됨 = modifier 내부에서 여기 원래 함수 실행해라는 위치 표시      

    // 함수 실행 후에 실행될 코드      

    doAfter();

}          

 

- constant = 고정 값 (컴파일 타임)  

- immutable = 생성자 안에서만(초기 배포) 업데이트 가능, 다른 곳은 read만 가능   

- 실제 contract 가 블록체인 상에 배포가 될 때 결정되는 값 의미    

 

* receive  

- External = 외부에서 호출 가능한 함수 / payable = 이 컨트랙트가 ETH를 이 함수 통해 받을 거야.   

- 누가 나에게 보냈니? Or 얼마만큼 보냈니?   

 

* fallback   

- 예상하지 못한 호출을 받을 때, 실행되는 예비 처리 함수

-> 셋 다 맞지 않아 -> fallback 호출     

 

* Events   

- Logging functionality of contracts   

- Applications can subscribe and listen events   

- Add the attributed indexed : up to three parameters  : shown as “topics” of the events  

 

- 지갑이 계속 모든 주소에 대해 call 호출 X -> 변경 시점에 서비스로 정보 던져준다면 좋음         

- block explorer = 그냥 서버에서 DB를 보여주는 것 (사용자가 보기 쉽게) : etherscan, tx 정보 확인  

 

* Inheritance : 상속      

- base 1 or 2?   * Units and Globally Available Variables   

- Ether unit = 제일 작은 단위가 wei (1)   

- 비트코인 = 사토시 / 1 ether 로 써야함