[블록체인] - 이더리움_Smart Contracts와 DApp

 이전 정리글에서는 이더리움의 Account, Transaction, Block에 대해서 정리해보았다. 이번 정리글에서는 Smart contract와 DApp에 대해서 자세히 정리해 보려고 한다.

---

1. Smart Contract

 앞선 정리글에서 자주 등장했던 Samrt Contract는 대체 무엇일까?

 

 CA(Contract Account)에는 code와 data storage가 존재한다. Smart contract는 간단히 말해 이 code와 storage가 결합된 형태로, EVM 위에서 실행되는 프로그램이라고 정리할 수 있다.

 

 즉, Smart Contract는 이더리움 네트워크에 배포되어 validator가 실행할 수 있는 EVM 코드 프로그램이다. 

 

 Smart Contract는 다음과 같은 특징을 가지고 있다.

• immutable: 한 번 deploy되면, smart contract의 코드는 바뀔 수 없다.
  • 새로운 버전을 배포하려면 아예 새로운 CA 주소가 생성된다.
• deterministic: smart contract의 실행 결과는 누가 실행해도 동일해야 한다. 즉, 같은 입력을 넣으면 항상 같은 결과가 나와야 한다.
• Smart Contract는 현재 state, 트랜잭션 context, 최근 블록 정보 등에 접근할 수 있다.

 EVM은 각 노드마다 설치되어 있으며, EVM의 초기 상태와 opcode 실행 규칙은 어디서나 동일하다. 따라서 동일한 트랜잭션을 실행하면 모든 노드가 동일한 final state를 생산한다. 이러한 특징 때문에 이더리움을 종종 world computer라고 부른다.

 

- Smart Contract의 Life Cycle

 그럼 이 samrt contract는 이더리움 내에서 어떻게 실행될까? 다음 과정을 한 번 살펴보자.

• Smart Contract는 EVM에서 실행될 수 있는 low-level bytecode로 compile되어야 한다.
• 컴파일 된 코드는 특별한 contract creation transaction이라는 트랜잭션으로 deploy된다.
  • 이 트랜잭션은 to 필드가 비어있으며, 이를 통해 새로운 CA가 생성된다.
• Contract는 오직 트랜잭션에 의해 호출되어야만 실행되며, EOA에 의해 시작된다.
• Contract는 병렬적으로 실행될 수 없다. Ethereum의 world computer는 사실상 single-threaded machine으로 여겨지기 때문이다.
  • 즉, 모든 트랜잭션은 순서대로 하나씩 처리되며, 이 때문에 VISA 같은 중앙화된 시스템에 비해 처리 속도가 느릴 수밖에 없다.
• 트랜잭션은 얼마나 많은 contract가 불리고 언제 불리든지 상관없이 "atomic"한 특징을 지닌다. 이는 곧, 하나의 트랜잭션이 모두 완전히 성공적으로 끝나야 global state 변화에 반영된다는 뜻이다.
• 실행 도중 에러나 가스 부족으로 종료된다면, 해당 smart contract가 실행된 적 없는 것처럼 roll-back된다.

+) Contract는 한 번 배포되면 수정되거나 변경될 수 없다. 하지만 EVM의 SELFDESTRUCT opcode를 통해 해당 contract account의 storage를 모두 제거하고 해당 주소를 빈 account(blank account) 상태로 만들 수 있다.

 

 그렇지만, 해당 account는 자체는 이더리움 상태에 남아 있기 때문에 트랜잭션을 보낼 수느 있다. 그러나 더 이상 동작할 코드가 없기 때문에 이 주소로 보내는 트랜잭션에서는 contract execution이 발생하지 않는다.

 

 이러한 contract 삭제 기능은 contract 내부에 SELFDESTRUCT opcode가 포함되어 있을 때만 가능하다. 즉, contract 개발자가 SELFDESTRUCT 기능을 넣어야 되며, 넣지 않는다면 해당 contract는 delete 될 수 없다.

 

 예를 들어 Solidity에서는 selfdestruct(recipient_address)라는 코드로 실행되며, contract의 잔액을 recipeint_address로 전송하며, 해당 contract를 삭제하여 해당 account 상태를 blank로 만든다.

 

 또한 SELFDESTRUCT opcode는 자원을 해제(storage 삭제)를 수행하기 때문에 EVM에서 gas refund를 제공하는 연산으로 여겨진다. 이러한 동작 방식 때문에 negative gas라고 표현하기도 한다.

 

- Contract Deployment Code

 Contract Deployment Code는 앞서 정리했듯이 새로운 컨트랙트를 생성할 때 이용하는 코드이다. 즉, 스마트 컨트랙트가 최초로 deploy(=upload)되는 과정이다.

 

 컨트랙트를 만들기 위해 특별한 트랜잭션이 필요하고 해당 트랜잭션의 데이터 필드는 컨트랙트의 initiation code로 채워진다. 이 initiation code는 코드 자체가 컨트랙트 코드를 블록체인에 업로드하고 초기화하는 역할을 한다.

 

 EVM은 해당 트랜잭션의 data field를 ROM에 적재하여 트랜잭션을 실행시키고 그 deployment 코드의 실행 결과를 새로운 컨트랙트 account의 코드(runtime bytecode)로 저장한다.

 

 위의 과정을 통해 새로운 컨트랙트가 deploy됨과 동시에 생성되며, 이때 컨트랙트 storage는 초기 constructor 로직에 따라 설정될 수 있다.

• deployment bytecode: 새로운 컨트랙트를 생성할 때 사용되는 코드로, EVM에서 실행된 후 출력값으로 runtime bytecode를 반환하면서 종료된다.
• runtime bytecode: 컨트랙트가 블록체인에 저장되는 실제 실행 코드로, 이후 해당 컨트랙트가 호출될 때마다 실행된다.

 즉 위의 두 코드는 목적이 다르며, deployment bytecode가 종료될 때 그 결과로 runtime bytecode가 생성되는 구조이다.

 

최종 정리하면, 다음과 같은 과정을 거쳐 새로운 스마트 컨트랙트가 등록된다.

1. .특별한 트랙잭션을 보낸다
   • to 필드가 0x0, data 필드가 deployment bytecode로 구성되어 있다.
2. 이 트랜잭션이 실행되면 EVM이 deployment bytecode를 ROM에 올려서 실행한다.
3. 실행 결과 나온 output이 runtime bytecode이며 이 runtime bytecode가 새로운 주소(account)에 저장된다.
4. 이렇게 생성된 account address가 새로운 스마트 컨트랙드 계정(CA)이다.

 

- EVM(Ethereum Virtual Machine)

 EVM은 실제 컴퓨터에서 동작하는 VM(e.g VMWARE, VirtualBox)과 달리 더 제한된 domain만을 실행할 수 있다. 즉, 계산 엔진과 저장공간의 abstraction 기능만 제공하기 때문에 오히려 JVM과 더 비슷하다고 한다.

 

 EVM은 다음과 같은 특징을 지닌다.

• EVM은 Solidity나 Vyper로 작성된 스마트 컨트랙트가 컴파일된 bytecode 명령어를 실행한다.
• EVM은 scheduling기능이 없다. 실행 순서는 EVM 내부가 아니라 외부(Ethereum 클라이언트)가 정한다.
  •  즉, Validator가 어떤 트랜잭션을 어떤 순서로 실행할지를 결정한다.
• EVM은 각 노드 안에 독립적으로 존재하는 VM이지만, 모든 노드가 동일한 initial state로 시작해 동일한 final state를 만들기 때문에 전체적으로는 하나의 탈중앙화 전역 컴퓨터처럼 동작한다.
• EVM은 가짜 turing-complete machine이라고 하는데, 이는 EVM이 이론적으로는 Turing Complete를 지원하지만 gas에 의해 실행이 제한되므로 무한 루프는 실행이 불가능하기 때문이다.

 그렇다면 이제 EVM 아키텍처를 한 번 살펴보자.

 

 EVM은 스택 기반 아키텍처로 구성되어 있으며, 모든 계산은 256bit word 단위로 스택을 이용해 수행된다. 또한 EVM은 여러 종류의 주소 공간을 사용한다. 구성요소를 살펴보면 다음과 같다.

• ROM(Read-Only Memory, non-volatile): smart contract의 bytecode가 적재되고 실행된다.
• Memory(volatile memory): 트랜잭션 실행 도중에만 존재하는 휘발성 메모리로 0x00부터 시작하며 실행이 끝나면 초기화 된다.
• Storage(persistent storage): 이더리움 글로벌 state에 포함되는 영구 저장소로, 컨트랙트 계정마다 존재한다. key-value 매핑 형식으로 저장되며 0x00부터 시작한다.
• Stack: 계산을 수행하기 위핸 최대 1024개의 256bit word를 저장한다.

이를 그림으로 살펴보면 다음과 같다.

그림에 대해서 설명하면 다음과 같다.

• Non-volatile(비휘발성)
  • ROM(Code): 스마트 컨트랙트의 런타임 bytecode가 저장되어 있으며 변경되지 않는다. 즉, EVM이 실행해야 하는 명령어 목록이 여기에 들어 있다.
  • RAM: 이더리움 state가 저장되어 있다. 컨트랙트의 변수들이 여기에 기록된다.
• Volatile(휘발성)
  • stack: EVM이 실행하는 opcode들이 계산을 수행하기 위한 값들이 push/pop되는 공간이다.
  • args: 외부에서 전달된 입력값이 저장되는 Read-Only 공간이다.
  • memeory: 일종의 임시 작업 공간이다.

 EVM은 유효한 트랜잭션을 실행하여 이더리움의 state, 상태를 업데이트한다. 

 

- EVM Instruction Set

 EVM에는 여러 명령어들이 존재한다. 다음과 같은 종류들 이 있다.

• arithmetic and bitwise logic operations: ADD, MUL, SUB, DIV, SHA#, EQ, AND, OR, XOR ...
• execution context inquiries: CALL, RETURN, REVERT, INVAILD, SELFDESTRUCT...
• stack, memory, and storage: POP, MSTORE, SLOAD, SSTORE...
• logging, calling, and others: GAS, BALANCE, ORIGIN,..

+) bytecode operation도 존재하며, EVM은 account 정보에 접근할 수 있다.

 

- EVM state

 다음은 EVM의 상태에 대해서 정리해 보려고 한다.

 

 이더리움은 transaction 기반 state machine이라고 하는데, external actors(account holders와 vaildators)가 트랜잭션을 만들고 이를 실행하면서 state transition이 발생한다.

 

 EVM은 이러한 Ethereum의 state를 스마트 컨트랙트 코드 실행 결과로부터 계산되는 유효한 state transition을 적용함으로써 업데이트한다. 이 이더리움의 world state는 이더리움의 주소(20Bytes value)와 accounts의 매핑 관계이다.

 

 트랜잭션이 스마트 컨트랙트를 호출하면, Validator는 그 트랜잭션을 포함한 블록을 만들기 전에 해당 스마트 컨트랙트를 EVM 위에서 실행해 보고 그 결과로 발생하는 state transition이 유효한지 판단한다. EVM의 구성은 다음과  같다.

• program code ROM: 스마트 컨트랙트의 runtime bytecode가 이 영역에 올라간다. ROM이므로 실행 중에 코드 자체는 절대 변경되지 않는다.
• Program Counter(PC): 지금 어떤 명령어를 실행 중인가를 가리키는 포인터이다. 항상 0번 명령어부터 시작한다.
• sotrage: 계정의 영구 저장소로, 해당 스마트 컨트랙트 계정이 가지고 있는 영구 상태 변수 값들이 저장되는 공간이다. 트랜잭션 실행 성공 시 global Ethereum state에 반영된다.
• memory: 임시 작업용 공간으로, 트랜잭션 시작 시 모든 값이 0으로 초기화된 휘발성 메모리이다. 실행이 끝나면 초기화된다.
• Gas supply: 트랜잭션을 보낸 사용자가 지불한 gas limit이 여기에 저장되어 명령어 실행할 때마다 gas를 차감한다. gas가 부족해지면 즉시 실행이 중단되고 revert가 발생한다.

이렇게 EVM의 실행이 정상적으로 종료된면 변경된 storage 값, 새로운 contract 값, ETH 전송 등이 global state의 업데이트에 반영된다.

 

- EVM과 Gas

 앞서, EVM에서 명령어를 실행할 때마다 Gas를 소비한다고 정리했다. 더 구체적으로 EVM 내에서 gas가 어떻게 소비되는지 정리해 보려고 한다.

 

• EVM은 트랜잭션의 gas limit을 확인하고 해당 트랜잭션 실행을 위해 동일한 양의 gas를 gas supply(가스 저장 공간)에 채워 넣는다.
• 각 operation 전에, EVM은 operation 실행을 위한 충분한 gas가 gas supply에 남아있는지 확인한다.
• EVM이 실행을 성공적으로 마쳤다면, 사용된 gas cost는 transaction fee로 사용되며, ether로 전환된다.
  • 즉 transaction fee = gas cost(사용된 gas 양) * gas price(사용된 gas의 단위 가격)
• 남아있는 gas는 ether로 전환되어 sender에게 환불된다. 
  • remaining gas = gas limit - gas cost
  • refunded ether = remaining gas * gas price

+) 이때, block의 gas limit이 존재하는데, 블록에 포함되는 모든 가스들을 합친 양이 gas limit을 넘어가면 안된다.

 

 예를 들어, 5trnasaction이 현재 validator의 pending pool에 있는데, 각 트랜잭션이 포함하고 있는 gas 양이 30,000, 30,000, 40,000, 50,000, 50,000 이고 블록의 gas limit이 180,000이라면 최대 4개의 트랜잭션 밖에 블록에 포함시킬 수 있고, 나머지 하나는 다음 블록에 포함시켜야 한다. 만약 gas limit을 넘어서 블록을 제시한다면, 해당 블록은 무효처리 된다.

---

2. Token

 이더리움에서는 이더리움 Coin인 ETH 말고 토큰이라는 개념이 존재한다. 이 토큰은 DApp을 위해서 필요한 것으로, DApp에 대해서 본격적으로 정리하기 전에 토큰에 대해서 미리 정의해야 한다.

 

 이더리움에서는 DApp을 위한 토큰이 존재하는데, ERC20이라는 토큰을 사용한다. 

 

 그럼 이 토큰과 코인의 차이점은 무엇일까?

 

- Coin

• 블록체인 자체의 네이티브 디지털 화폐
• 가치 저장 및 교환에 사용
• PoW나 PoS 같은 Consensus 알고리즘에 의해 채굴 가능
• eg. 비트코인(BTC), 이더리움(ETH)

- Token

• 블록체인에 위에서 동작한 DApp을 위해 스마트 컨트랙트로 만들어진 디지털 자산
• utility나 payement와 등 특정 플랫폼, 서비스를 위한 기능 제공
• 블록체인 프로토콜을 토큰의 존재를 직접적으로 인지하지 못한다.
• 이더리움 블록체인에 새로운 토큰을 만들기 위해서는 새로운 smart contract를 만들어야되고 deploy되면 그 컨트랙트가 토큰의 ownership, transfer, 권한 관리 등 모든 동작을 정의한다.
• eg. ERC20 토큰, ERC721 토큰(NFT)

 즉, 각 DApp에 해당하는 토큰을 보유함으로써 

• 해당 DApp의 접근 권한을 인증하거나,
• 일정 토큰 이상을 보유하면 해당 DApp에서 권한이 상승할 수도 있으며,
• DApp 내부 경제 시스템에서는 게임 포인트, 유틸리티 포인트처럼 사용되기도 한다.

 이처럼 토큰은 DApp이 사용자 권한을 관리하거나 기능을 제공하기 위해 사용하는 디지털 자산이라고 할 수 있다.

 

 다음 그림을 통해 토큰 발행 과정을 이해해보자.

 

그림에 대해서 설명하면 다음과 같다.

1. Alice가 스마트 컨트랙트를 통해 DApp을 만들기 위해 Bob에게 투자 요청을 한다.
2. Bob이 충분한 검토를 마친 뒤, Alice가 만든 토큰 발행용 스마트 컨트랙트 "AliceICO"로 ETH를 전송해 투자한다.
3. 스마트 컨트랙트는 해당 ETH를 받은 것을 확인하고 미리 정의된 규칙에 따라 새로운 토큰 "AliceCoin"을 발행한다.
4. 발행된 "AliceCoin"을 Bob에게 전송하여 Bob이 토큰을 보유하게 된다.

 위 과정을 ICO(Initial Coin Offering)이라고 하며, 상장 전에 투자자에게 자금을 받고 그 대가로 토큰을 배분한다는 점에서 주식의 IPO 과정과 유사하다고 해서 ICO라는 이름으로 불린다.

---

3. DApp: an app mostly/entirely decentralized

 이제 본격적으로 DApp에 대해서 정리해 보려고 한다. DApp은 Decentralized App으로, 탈중앙화 앱이다. 앞서 정리했지만, 유튜브에서 영상을올리면 해당 영상의 소유주는 컨텐츠 제작자가 아닌 Google이나 유튜브이다. 이런 중앙 집중식 구조를 벗어나, 데이터와 소유 권한을 중앙 서버가 아닌 사용자, 참여자에게 분산시키는 것을 탈중앙화라고 한다.

 

 그럼, 이런 탈중앙화 앱, DApp의 장점들은 무엇이 있을까? 다음과 같다.

• Resiliency: DApp의 backend는 블록체인 플랫폼 위에서 실행되며, 네트워크 전체가 운영되는 한 중단되지 않는다. 또한 일부 노드가 다운되더라도 블록체인은 계속 유지되므로 서비스는 쉽게 shutdown되지 않는다.
• Transparency: DApp의 스마트 컨트랙트 코드는 누구나 열람할 수 있고, 그 기능을 직접 검증할 수 있다. 또한 DApp과의 상호작용(트랜잭션)은 블록체인에 영구히 기록된다.
• Censorship resistance: 사용자는 중앙 기관(eg. 유튜브나 구글 같은 플랫폼 운영자)의 개입 없이 DApp과 직접 상호작용(트랜잭션)할 수 있다. 또한, 스마트 컨트랙트는 배포 이후 코드 수정이 불가능하기 때문에 제작자나 특정 참여자가 임의로 코드를 변경하거나 사용자 권한을 제한할 수 없다.

 

 따라서, DApp에서는다음과 같은 요소들이 탈중앙화의 대상이 될 수 있다.

• Backend 서비스 로직
• Frontend 로직
• Data Storage
• 메시지 프로토콜
• Name Resolution

차례 차례 어떤 요소들이 탈중앙화되었는지 정리해 보려고 한다.

- Backend(smart contract)

• DApp의 비지니스 로직과 관련 상태를 저장하고 있는 코드이다.
• DApp의 핵심은 개념 중 하나는 기존의 서버 역할을 smart contract가 대체한다는 점이다.
  • 하지만, smart contract는 블록체인 위에서만 동작하며, 모든 연산을 해당 CA에서 처리하면 부담이 매우 커지기 때문에 모든 기능을 smart contract 안에서 처리할 수는 없다.
  • 따라서, smart contract 코드를 짤 때 핵심적인 상태 변화 및 중요한 로직 중심으로 최소화하여 작성해야 하며, 이런 구조 때문에 모든 DApp이 100% 완전 탈중앙화된 앱이라고 말할 수는 없다.
• smart contract는 배포 후에는 수정이 불가능하며, 완전히 제거(SELFDESTRUCT)하여 계정을 blank 상태로 만들지 않는 이상 코드 변경은 절대 허용되지 않는다.
• smart contract의 사이즈도 중요하다
  • 엄청나게 큰 smart contract는 deploy하고 사용하는 데 엄청나게 많은 gas가 소비된다.
  • 그래서, 어떤 DApp들은 off-chain computation과 외부 data source를 사용하기도 한다.

- Frontend(web user interface)

• DApp의 클라이언트 쪽 인터페이스는 표준 웹 기술인 HTML, CSS, JS 등을 사용한다.
• 트랜잭션을 발생시키거나 key를 관리하는 등 이더리움과 상호작요하는 기능은 MetaMask(비트코인 Wallet 같은 S/W)같은 웹브라우저 확장 프로글매을 통해 수행된다.
• 종종 DApp은 web3.js 같은 라이브러리를 사용해 이더리움 노드와 연결된다.
• 현재 DApp은 웹 기반 개발 중심이며, 모바일을 위한 개발 환경은 상대적으로 적고 제한적이다.

-Data Storage

• 높은 gas 비용때문에, 대부분의 DApp은 큰 데이터를 저장하기 위해 off-chain data storage 서비스, 즉, 외부 storage를 사용한다.
• Data Storage 플랫폼은 중앙화된 방식일 수도 있고, 탈중앙화된 방식일 수도 있다.
  • ex) P2P 플랫폼의 IPFS나 이더리움의 Swarm이라는 플랫폼
• 탈중앙화된 P2P storage는 다음과 같다.
  • IPFS(Inter-Planetary File System): 파일 내용을 기반으로 생성된 해시값(content hash)을 주소로 사용하는 분산 파일 시스템이다. 중앙 서버 대신 P2P 네트워크에 파일이 저장되며, 사용자는 해당 파일의 해시값으로 빠르게 데이터를 검색할 수 있다.
  • Swarm: IPFS와 비슷하지만, content-addressable P2P storage system이며, Ethereum Foundation에 의해 만들어졌다. 이더리움과의 통합을 목표로 설계되었다.

- Decentarlized Message Communications

• 애플리케이션 간 메시지를 주고받아야 하는 경우나 앱 상에서 유저들끼리 메시지를 주고받아야 하는 경우, 전통적으로는 중앙 서버에 의존해서 이루어졌다.
• 탈중앙화는 관점에서는 이러한 메시지 서비스를 P2P 네트워크에서 직접 제공한다.
  • Whisper: DApp을 위한 P2P 메시지 프로토콜로 탈중앙화된 메시지 프로토콜이다. 메시지는 네트워크 내 모든 노드로 전파되며, 각 peer가 각자의 목적지로 온 메시지가 아니면 router 역할을 하여 전달해주는 방식으로 이루어진다. 또한 메시지는 암호화되어 전송되기 때문에 수신 대상이 아닌 노드는 메시지 내용을 알 수 없다.

- Ethereum Name Servie(ENS)

• DNS와 유사한 역할을 하는 탈중앙화 이름 서비스이다.
• 사람이 읽기 어려운 긴 스마트 컨트랙트 주소나 account 주소를 사람이 읽기 쉬운 이름으로 매핑해준다.
• 해당 매핑 정보는 ENS 스마트 컨트랙트에 저장되며 모든 사용자는 이를 조회하여 특정 이름이 어떤 주소 또는 리소스를 가리키는지 확인할 수 있다.

 

 위와 같은 DApp 시스템을 이해하기 위해 다음 예시를 살펴보자. 다음 예시는 경매 DApp의 작동 구조를 나타낸 것이다.

 위 그림에 대해서 설명하기 전에, 일반 앱에서 경매를 하기 위해서는 어떤 과정이 필요한지 먼저 정리하고 비교를 통해 DApp 작동을 확인해보자.

 

 일반 앱에서 경매를 구현한다고 하면 다음과 같은 과정을 떠올려야 한다.

1. 판매자(seller)가 경매 broker에게 경매할 물건을 등록한다.
   • 물건의 상태, 최소 시작 가격, 경매 조건 등을 브로커에게 넘겨 브로커가 관리한다.
2. 경매 브로커가 입찰을 받고, 낙찰자가 있으면 돈을 받아 판매자에게 지급한다.
3. 낙찰자가 없거나 조건 미충족 시 물건을 다시 판매자에게 돌려준다.

 즉, 일반 경매는 브로커(중앙 서버)가 모든 절차를 관리하는 구조이다.

 

 그럼 위 그림과 같은 DApp에서의 경매 과정을 살펴보자.

1. 경매할 물건의 ownership을 auctionHouse 스마트 컨트랙트로 이전한다. 즉, 해당 자산을 ERC721 토큰으로 토큰화하여 컨트랙트가 관리하도록 맡긴다.
2. 스마트 컨트랙트를 통해 경매를 생성한다.
3. Buyer가 Bidding(입찰)을 제시한다.
   • 만약, bidding 값이 경매자가 원하는 값 이하라면 해당 경매를 Cancel하고 토큰화시켰던 ownership을 다시 판매자에게 반환된다.
   • 충분한 bidding 값이 나왔다면, 경매는 End되고 토큰화된 ownership을 낙찰자에게 넘긴다.

 DApp에서는 이 모든 과정이 스마트 컨트랙트 내부 로직으로 자동 처리되기 때문에 중앙 브로커 없이 훨씬 단순하고 투명하게 경매를 구현할 수 있다는 장점이 있다.

 

 DApp의 아키텍처를 그림으로 살펴보면 다음과 같다.