[블록체인] 20. 이더리움 - Smart Contract & dApp

 

 

현재 이더리움은 크게 위와 같은 구조로 되어있따.

먼저 EVM을 돌리고 있는 노드가 있고, Light Client 라는 전체 노드를 다 가진게 아니라 내 트랜잭션과 관련된 뭔가가 발생하면 그것만 모니터링 하는 노드가 있을 수 있고, 중앙화된 API 서버를 통해 이더리움 네트워크의 블록 채굴 내역등을 조회할 수 있는 서비스 등이 존재한다. (이런 게 조금 아이러니 하다. 탈중앙화 서비스의 정보를 얻기위한 서버는 중앙화라는 것)

 

 

그래서 현재는 이렇게 중앙화된 서버에서 이더리움과 관련된 정보를 제공하고 있지만, 나중엔 궁극적으로 이것까지 탈중앙화를 할 것이라고 이더리움 파운데이션은 예측하고 있다.

 

탈 중앙화된 portal network

 

이는 사용자 인터페이스용으로 존재하는 이더리움과 별개의 P2P 네트워크라고 보면 된다.

 

 

2022년 PoS 로 넘어간 역사적 사건을 가리켜 The Merge 라고 부른다.

그리고 그 이후 (post - merge) 의 각 이더리움 노드는 이렇게 Consensus 와 트랜잭션 실행이 모두 노드에 포함되게 되었다.

(과거에는 컨센서스 부분이 EVM 에 없었다.)

 

 

그래서 머지 이전에는 PoW 방식을 사용하여 EVM에서는 트랜잭션을 경쟁적으로 실행해서 블록을 만드는데만 집중했다면,

머지 이후에는 PoS 방식을 사용하여 각 노드가 트랜잭션을 실행하는 영역이 컨센서스 계층에 포함되어, 컨센서스 과정에서 트랜잭션이 실행되는 구조가 되었다. 즉, EVM을 실행시키는 Execution Module 에서는 트랜잭션을 실행, 컨센서스 레이어에서는 만들어진 블록을 검증한다.

 

 

위 그림은 이더리움 블록이 만들어지는 과정을 보여준다.

 

1. EVM이 블록체인으로부터 데이터를 메모리에 로딩한다. (스마트 컨트랙트 관련 스토리지 상태 등)

2. EVM이 트랜잭션을 멤풀에서 가져와 EVM 메모리로 로딩한다.

3. EVM이 트랜잭션들을 실행하고, 블록으로 만든다.

4. 블록을 네트워크에 뿌린다.

5. 네트워크가 블록을 승인한다.

 

---

Smart Contract

CA (Contarct Account) 는 private key 가 필요하지 않고, 상태 내부에 코드를 가지고 있다.

이 코드를 가리켜 Smart Contract 라고 부르며, 일종의 컴퓨터 프로그램과 같다.

이 코드는 한번 이더리움 네트워크에 올라와 확정이 되면 바꿀 수 없지만, 지우는 것은 가능하도록 허용한다.

그래서 만약 지우게 되면 그때의 CA 는 blank account 가 된다. (주소는 있지만 내용은 비어있어서 누군가 호출해도 아무일도 하지 않음)

코드를 지우러면 SELFDESTRUCT 라는 명령어를 EVM에서 실행하면 된다.

그리고 이 명령어는 스마트 컨트랙트를 만들 때 미리 만들어져있어야 한다.

이때 이 명령어는 아무나 실행할 수 없고, 컨트랙트를 만든 사람만 실행할 수 있다.

그리고 만약 스마트 컨트랙트를 지우게 되면 그 만큼 공간을 비워주는 것과 같아서 역으로 gas를 받는다. (negetive gas 지불)

물론 받는 gas 양은 악용을 막기 위해 만들 때 지불하는 gas 양보다 적다.

 

스마트 컨트랙트는 deterministic 해서 누가 실행하는 같은 input data 라면 같은 결과를 만들어낸다.

코드의 실행과정에서 data storage 에 접근하거나, 최신 블록의 정보, 최신 블록의 내용을 참조해서 가져오는 것도 가능하다.

 

스마트 컨트랙트는 Solidity 를 사용해서 작성되며, 이를 실행하기 위해 EVM 이 실행가능한 바이트코드로 변환해서 실행된다.

그리고 바이트코드는 EVM이 설치된 그 기계에 맞게 변환되어서 실행된다.

 

Smart Contract 를 만들어내는 트랜잭션은 특별하게 Contract Creation Transaction 이라고 부른다.

(지난 글에서는 Deploy Transaction 이라고 했떤 것 같은데..)

이 트랜잭션의 목적지 필드 (to) 는 0x0 을 지정하면 된다.

 

또한 스마트 컨트랙트는 병렬적으로 실행될 수 없다.

그리고 스마트 컨트랙트를 인보크하는 트랜잭션은 실행되거나 안되거나 둘 중 하나만 가지는 atomic 한 성질을 갖는다.

 

 

 

DAPP 과 스마트 컨트랙트 사이의 관계를 보면, 스마트 컨트랙트는 일종의 백엔드와 같은 역할을 해서, Dapp 에 있는 사용자 인터페이스로 들어온 요청을 처리하는 역할을 수행한다.

 

EVM

EVM은 JVM과 비슷하게 바이퍼, 솔리디티와 같은 언어로 작성된 스마트 컨트랙트를 EVM 바이트 코드로 바꾸면, EVM이 호스트 기계어로 바꿔서 실행한다.

EVM이 트랜잭션을 검증할 때는 스케줄링을 하지 않고 싱글스레드로 하나의 트랜잭션을 처리하고, 처리가 끝나면 그 다음 트랜잭션을 실행하는 방식으로 동작한다. (그래서 트랜잭션의 실행 순서는 node 가 제공한다.)

 

스마트 컨트랙트는 각 코드마다, 이 코드에서 접근할 수 있는 '데이터가 영구 저장되는 공간' 이 정해져있다.

그리고 EVM은 그런 각각의 공간이 수백만개로 분산된 일종의 global computer 라고 볼 수 있다.

(각 노드에서 같은 코드를 실행해도 각 노드의 저장 공간을 쓰는 셈이니까..?)

 

EVM은 스택 기반의 아키텍처를 따른다.

그리고 이때 word (명령어와 데이터의 단위 크기) 크기는 256bit 이다.

EVM이 실행시킬 바이트 코드는 ROM에 올려서 수정되지 않도록 하고, 메모리와 스토리지를 갖는다.

메모리는 초기에 0으로 초기화되어있다가 EVM이 실행하는 코드의 연산값이 메모리에 저장된다.

그리고 실행이 끝나면 메모리는 다시 초기화된다.

스토리지도 이더리움 상태의 일부로서 동일하게 처음에는 0으로 초기화 된다.

 

 

그래서 EVM을 보면 이런 구조로 되어있다.

ROM 에는 실행할 코드가, RAM 에는 메모리와 저장공간이 있다.

 

 

처음에는 PC (Program Counter) 값이 0으로 세팅되고 스택, 메모리, 스토리지는 모두 비어있다.

위 그림에서 윗쪽 영역은 non-volatile = 파워가 나가도 변하지 않으며, 새로운 코드가 들어오기 전까지는 그대로 유지된다.

반면 아래쪽 영역은 파워가 나가면 초기화되는 영역이다.

 

 

EVM에서 사용하는 instruction set 은 위와 같다.

기존의 어셈블리에서 사용하는 것 외에도 블록체인과 관련된 명령어도 존재한다. (해시 계산, 블록 참조 등)

중간에 REVERT 명령어는 out of gas 가 되면 롤백할 때 사용하고,

INVALID 명령어는 현재 트랜잭션이 유효하지 않음을 나타낸다. (연산 중간에 유효하지 않을 경우 호출하고 거기서 종료한다.)

SELFDESTRUCT 는 코드를 지우는 명령어이다.

 

 

EVM이 처음 시작되면, EVM은 현재 블록에 있는 모든 내용을 가져와서 트랜잭션을 하나씩 실행한다.

 

 

이때 프로그램 코드는 ROM에 올라오고, PC, memory 는 0으로 초기화한다.

storage 는 현재 account 의 state에 저장되어잇는 그 상태를 로딩하고, 트랜잭션에 기술된 값을 기반으로 gas supply 를 세팅한다.

 

트랜잭션은 1개씩 순차적으로 실행하며, 현재 블록에 들어있는 트랜잭션이 100개라면 1~100번째 트랜잭션까지 다 순서대로 실행하고, 100번째로 실행한 트랜잭션이 끝난 그 순간의 상태를 다음 이더리움 global state의 상태로 인지한다.

 

 

Smart Contract 배포

코드를 생성할 때는, initiation code 를 작성해서 트랜잭션에 담고 목적지를 0x0 으로 세팅해서 이더리움 네트워크로 전송하면 된다.

이때 initiation code는 그 실행 결과로 smart contract (runtime bytecode) 코드를 로딩하는 코드이다.

(그러니까 smart contract 코드를 직접 담는게 아니라 initiation code 를 작성하는 것?)

 

그래서 EVM은 initiation code를 ROM 에 일단 세팅하고 실행하면, initiation code 가 Smart Contract 코드를 생성해서 그것을 올린다. 그러면 이 output 결과가 디플로이 되면서 이더리움 네트워크에 smart contract 가 저장된다.

그리고 이때 스마트 컨트랙트 코드가 사용할 초기의 영구 스토리지 내용도 미리 세팅해서 보내둘 수 있고, 이더도 함께 보낼 수 있다.

 

지피티에 물어보면 deployment byte 코드는 배포할 때만 실행되며, initialize code 를 실행한 결과로 나오는 runtime bytecode 만 블록체인에 저장된다고 한다.

 

 

라고 한다.

 

 

---

EVM & gas

 

EVM 에서 연산을 실행하려면 gas 가 필요하다고 햇었다.

간단한 예제를 살펴보자.

 

두 수를 더하는 것은 3 gas 가 소모되고, 해싱에는 30 + 해싱할 원본 데이터의 256bit마다 6gas가 추가로 든다고 해보자.

그리고 트랜잭션을 전송하는 비용은 기본적으로 21000 gas 가 든다.

 

이렇게 어떤 연산을 할 때는 얼마의 gas가 필요한지는 고정되어있다.

다만 법정화폐의 이더리움 대비 가치에 따라 1 gas 마다 실제로 지불할 이더리움 (wei) 의 양은 내가 결정할 수 있다.

만약 이더리움의 가치가 올라갔다면 gas 비용은 낮아질 것이고, 이더리움의 가치가 낮아졌다면 gas의 단위 비용이 올라갈 것이다.

 

 

계속 했던 말이긴 하지만, 모든 연산을 EVM이 성공적으로 마쳤다면, 총 gas cost * gas price 를 수수료로 지불하고,

이렇게 지불하면 남은 gas는 내가 처음에 상한에 걸었던 금액에서 차감하여 계산한다.

그리고 최종적으로 돌려받는 이더는 남은 가스 * 내가 설정했던 가스당 가격으로 돌려받는다.

 

블록의 gas 리밋은 1500만부터 3000만 가스 사이로 지정할 수 있고, 각 트랜잭션의 최대 가스 합이 이 범위 안에 있어야 유효한 블록이다.

---

DApp

Coin vs Token

coin : 블록체인에서 사용하는 네이티브 화폐

token : 블록체인 프로젝트에서 스마트 컨트랙트로 만든 가상의 코인

 

이더리움에서는 스마트 컨트랙트의 코드에 의해 토큰을 만들 수 있는데, 이때 발급할 토큰의 표준은 크게 2가지가 있다.

1. ERC20 (FT = 구분이 안되는 토큰)

2. ERC721 (NFT = 구분 가능한 토큰)

 

토큰을 설명할 때 제일 좋은 예시는 '기부 플랫폼' 이다.

기부금의 사용처를 투명하게 공개하는 블록체인 기반 기부 플랫폼을 만들었다고 해보자.

 

그러면 스마트 컨트랙트를 통해서 기부를 한 사람들에게 기부금에 비례하여 토큰을 발급해줄 수 있다.

그리고 이 기부 플랫폼이 앞으로 어떤 방향성으로 나아갈 지 결정할 때 사용할 투표권으로서 토큰을 사용하도록 할 수 있다.

또는 어떤 메타버스를 만들었을 때, 그 메타버스의 입장권으로서 토큰이 활용될 수도 있고,

부동산 플랫폼을 만들었다면 부동산 소유에 대한 증거로 토큰을 활용할 수 있다.

 

이렇게 토큰은 해당 블록체인 프로젝트 내에서 자산, 내부 페이먼트, 유틸리티 등 다양한 목적으로 활용할 수 있다.

(특정 메타버스 내에서는 토큰을 화폐로 쓸 수 있다던가)

그리고 이런 토큰의 발급, 권한, 회수 등은 스마트 컨트랙트에 의해 관리된다.

 

 

블록체인에서 코인을 얻는 방법을 알아보자.

(Initial Coin Offering : ICO, 주식과 관련하여 IPO를 흉내낸 이름)

 

어떤 새로운 블록체인 프로젝트를 시작하려고 하는데, 초기 자금이 필요한 상황이다.

이때 ICO를 많이 사용한다.

 

그러면 블록체인 프로젝트를 시작할 자금을 돈으로 받는 대신에, 해당 프로젝트에서 사용할 네이티브 코인을 보상으로 지급해준다.

만약 이 프로젝트가 정말 잘 될 프로젝트라서 성공한다면, 초기에는 적은 돈으로 많은 코인을 받았다가 코인의 가치가 상승하면 그만큼 시세차익을 얻을 수 있고, 프로젝트가 실패하면 투자금을 잃게 된다.

 

만약 이더리움 플랫폼 상에서 새로운 프로젝트가 생겼는데 관심이 생겼다면, 그때는 이더를 지불한 대신 토큰을 보상으로 받게 되고, 이 토큰을 활용하여 해당 프로젝트에 내 지분만큼 권리행사를 할 수 있게 되거나, 그 프로젝트의 자체 화폐로 쓸 수 있다.

 

---

이제 디앱에 대해 정리해보자.

디앱은 이론상으론 완벽히 탈중앙화되면 좋겠지만, 실제로 완벽히 탈중앙화되기는 힘들다.

(조금씩 중앙화된 부분이 들어있다.)

그래서 일단은 현실적으로 모든 것을 다 탈중화하지는 못했지만, 대부분 탈중앙화 된 어플리케이션을 DApp 이라고 불러보자.

 

 

디앱에는 다음과 같은 요소들이 들어간다.

어플리케이션 로직 (스마트 컨트랙트) 이 들어간 백엔드와, 사용자 인터페이스가 있는 프론트엔드, 데이터가 저장되는 스토리지와 사용자간 통신을 위한 메세지 통신, 그리고 이 디앱을 검색을 통해서 찾을 때 필요한 name resolution

 

 

다음은 디앱의 장점을 보여준다.

- Resiliency (탄력성) : 디앱은 블록체인 기반에서 돌아가므로, 블록체인의 모든 노드가 죽지 않으면 디앱 서비스도 죽지 않는다.

- Transparency (투명성) : 블록체인 네트워크는 공개되어있으므로, 디앱의 비즈니스 로직은 누구나 확인할 수 있다.

- Censorship Resistance (검열 저항성) :  탈중앙화된 방식으로 네트워크에 접근하므로 누군가 어플리케이션의 로직을 함부로 바꾸거나 조정할 수 없다.

 

이제 디앱을 구성하는 요소를 하나씩 살펴보자.

 

백엔드

비즈니스 로직이 담기는 부분이며, 스마트 컨트랙트 코드가 실행되어 로직을 처리한다.

다만 스마트 컨트랙트 코드에는 복잡한 로직을 넣을 수 없다. (넣지 않는 것이 좋다.)

왜냐하면 스마트 컨트랙트 코드를 실행할 때마다 비용이 발생하기 때문이다.

 

그래서 생각한 아이디어가 upchain computation, 말 그대로 블록체인이 아닌 외부에서 computation 해서 그 결과를 블록체인으로 가지고 오자는 아이디어가 등장했다. (결국은 일부 중앙화되는 방식)

 

스마트 컨트랙트 코드는 지우는 것 말고는 수정될 수 없기 때문에, 믿을 수 있다.

 

프론트 엔드

전통적인 웹 기술을 사용하여 만든 사용자 인터페이스.

최근에는 블록체인을 위해 전용 웹 브라우저도 등장한다고 한다.

이 브라우저는 WEB 3.0 을 지원하며, 메타 마스크와 같은 브라우저가 대표적인 예시이다.

(메타마스크는 월렛인데, 브라우저에서 익스텐션으로 제공한다고 한다.)

 

모바일 쪽 클라이언트는 아직 개발되고 있고, 현재는 웹에서 주로 사용된다고 한다.

 

데이터 스토리지

전통적인 앱에서 DBMS 역할에 해당하는 부분. (하지만 탈중앙화되어있다.)

gas 비용 때문에 보통 업체인에서 대신 계산하는 방법을 사용하기도 하지만 이 부분은 탈중앙화에서 멀어지기 때문에, 탈중앙화에 가까워지도록 하는 방법이다.

 

1. IPFS

탈중앙화된 컨텐츠 addressable 시스템

P2P 네트워크에 분산해서 데이터를 해시로 만들어 저장해두고, 해시를 통해 데이터가 어디에 저장되어있는지 파악하는 방법이다.

 

2. SWARM

이더리움 파운데이션에서 만든 IPFS와 거의 동일한 시스템 (탈중앙화된 스토리지)

 

 

메세지 커뮤니케이션

어플리케이션 내부 또는 유저와 유저 사이에 내부 통신을 할 때, 이 통신까지 P2P로 만들어서 탈중앙화시킨 것

대표적으로 위스퍼 같은 것이 있다.

 

 

ENS (이더리움 Name Service)

DNS와 비슷하게 서비스의 이름을 통해서 스마트 컨트랙트에 접근할 수 있도록 도와주는 서비스

(특정한 서비스를 받을 수 있는 노드로 연결시켜주는 서비스)

ENS 자체도 Dapp 이고, 다른 앱에 도움을 주는 디앱이라고 보면 된다.

 

 

 

그래서 이렇게 디앱 전용 브라우저를 통해 여러가지 디앱에 접근할 수 있다. (이더리움, 스웜, 위스퍼..)

---

Example

 

 

디앱을 사용한 온라인 경매 사이트를 만들어보자.

그러면 위와 같은 구조로 설계해볼 수 있다.

 

먼저 경매로 물건을 팔려는 사람은 이 물건에 대한 전용 옥션을 연다.

그리고 판매하려는 물건에 대한 소유권을 입증할 토큰을 만든다.

 

경매애 참여하는 사람은 입찰가를 스마트 컨트랙트를 통해 예치해두면, 판매자는 토큰에 그 사람의 이름을 포함해서 넘겨준다.

그러면 컨트랙트는 예치된 이더를 판매자에게 제공한다.

 

만약 경매가 불발되면, 구매자는 이더를 돌려받고, 판매자는 판매할 물건을 다시 돌려받는다.

 

만약 이 옥션 앱을 좀 더 탈중화된 방식으로 만들고 싶다면, 모든 데이터를 swarm 이나 IPFS 에 저장할 수 있다.

(프론트엔드 코드까지도 웹서버가 아니라 탈중앙화된 공간에 저장해서 실행)

 

그리고 스왐에서 내가 저장한 디앱을 찾을 때는 ENS를 통해 찾을 수 있다.

ENS에서는 특정 이름에 대한 resolver 를 등록해두는데, resolver 는 그 이름 하나만을 위한 네임서버와 같다.

 

 

그래서 하나의 옥션 앱을 만들 때 다양한 디앱을 조합해서 이렇게 만들 수 있다.