[블록체인] 10. Ethereum - Smart Contracts and Dapps

 

What is a Smart Contract?

contract account는 code와 data storage(프로그램이 종료되어도 유지해야하는 데이터)를 가지고있지만,
private key는 가지고있지 않음. (독자적으로 invoke되지 못하기 때문.)
EOA는 private key에 의해 컨트롤됨. (계좌이체 시 sender 체크용)

Smart Contract

단순히 EVM에 의해 실행되는 컴퓨터 프로그램을 의미함! (contract에 어떠한 법적인 의미가 있는 것은 아님)

- immutable
: data는 바뀔 수 있지만 code부분은 바뀔 수 없음.(다수가 받아들인 블록체인은 변경 불가능)
 account상에 포함되었지만 문제가 있거나 없애고싶은 smart contract가 생겼을 때,
 account 자체를 지울 수는 없지만 code를 일부 폭파(self destruct)시킬 수는 있음.

- deterministic
: smart contract의 실행 결과는 결정론적이어야 함. 바뀌면 안됨.
 이더리움의 full node의 EVM에서 smart contract를 실행하는데,
 어떤 smart contract를 실행했을 때 full node마다 결과가 전부 다르다면 합의를 볼 수 없음.
 코드 시작 직전의 상태가 똑같다면 해당 smart contract를 어떤 채굴자(full node)가 실행하더라도 output은 동일해야함.

- 아래 것들에 접근 가능함
: 자신의 상태(data storage에 들어있는 state), 자신을 호출한 트랜잭션의 context, block에 대한 정보

EVM

virtual machine은 하나지만 이를 블록체인 상 모든 full node들이 각각 돌림.(=local instance) 
하지만 deterministic하기 때문에 결과적으로 이더리움 시스템은 하나의 world computer라고 부를 수 있음.
full node들이 local에서 트랜잭션들을 실행하고 그 결과로 채굴 경쟁을 벌임. 어떤 노드가 실행하든 시작상태가 동일하다면 output도 동일하므로 어떤 노드가 채굴에 성공해서 발표하면 다른 노드는 (본인이 했어도 동일한 결과가 나왔을 것이므로) 그것을 accept할 수 밖에 없음.

 

Life Cycle of a Smart Contract

smart contract는 Solidity같은 high-level language로 쓰였음.
smart contract를 EVM에서 실행하려면 low-level bytecode로 컴파일 되어야 함.
컴파일 된 코드는 special contract creation transaction을 통해 deploy(account 상에 포함)되며 to(목적지)는 zero.

contract는 독자적으로 동작(invoke)할 수 없으며 EOA에 의해 시작된 transaction로부터 호출되면 실행됨.
contract는 parallel하게 실행되지는 않음.
parallel하게 진행된다면 실행 순서에 따른 state의 변화에 대해 정확히 모든 노드들의 동의를 받기 힘들기때문에
Ethereum world computer는 single-threaded machine임. multiple transaction은 순서를 매겨서 한 순간에 하나씩 실행.

transaction은 atomic함. 쪼개져서 실행되지 않음.
어떤 transaction이 한 번 시작이 되면 중간에 interrupt되지 않고 끝까지 실행됨. -> state변화가 deterministic함.
transaction이 성공적으로 종료된 경우에만 global state에 변화를 기록함. 에러로 인해 실행 실패했다면 변화된 state는 transaction 시작 전으로 roll back하며 사용된 gas는 환불해주지 않음.

contract 코드가 deploy(이더리움 블록체인 상에 적용)되면, 코드 자체를 바꿀 순 없음. 
smart contract를 실행하는 EVM에서 self-destruct를 실행시키면 해당 코드를 지울 순 있음.
-> code와 내부 상태(코드 실행을 위해 필요한 저장소)가 지워짐. account는 지워지지 않음.
contract가 지워진 후에 해당 account로 transaction을 보내더라도 실행될 코드가 없기때문에 아무런 일도 일어나지 않음.

* self-destruct
contract를 삭제하려면 EVM opcode SELFDESTRUCT를 실행해야함.
이는 개발자가 smart contract를 작성할 때, 스스로 selfdestruct(recipient_address)를 집어넣어야 함.
해당 코드를 포함하지 않는다면 smart contract 삭제 불가능.
self-destruct opcode는 negative gas임. opcode 실행에 수수료를 받지 않고 오히려 gas refund를 제공함.

 

---

Smart Contract vs DApp

DApp = smart contract + user interface

 

이더리움 구현 가능성과 법적 효력 문제

smart contract의 스마트'계약'에는 어떠한 법적 의미도 들어가 있진 않지만,
계약 내용을 디지털화해서 안전하게 저장해놓고 필요할 때 접근하는 것에 대한 욕구가 생겼음
=> 리카르디안 컨트랙트(Ricardian contract)
: 일상생활에서의 계약 내용을 디지털화 한 것. (계약 내용, A와 B의 서명, 공증인의 서명, etc..)
-> 법 조항이나 법률 용어들을 smart contract(프로그램 코드)로 상세하게 표현해내는 것이 불가능함.
그리고 smart contract를 통해서 계약을 맺고 의견차이가 생겼을 때 온라인으로 조절하기 어려움.(법적 관할권 문제)

 

 

---

탈중앙화 된 앱 (DApp) : CryptoKitties

by 액시엄 젠(2017년)
경제 규모는 4천만 달러에 달했고 10만 달러 이상의 고양이를 거래하기도 했음.
크립토키티의 거래량이 이더리움 네트워크 트래픽의 약 25%를 차지하기도 함.
(이더리움이 2015년에 launch되었는데 이 디앱이 이더리움 초기 부스트에 큰 도움을 줬음)

ICO를 통해 투자금을 모으는 다른 블록체인 프로젝트와 달리, 지속가능한 자체 수익모델을 개발하여 사용했음.

일반 사용자가 이 DApp을 이용하기 위해서는 이러한 wallet software를 구동시켜야 함.
wallet software는 DApp에 접근할 수 있는 web interface 제공뿐만아니라 트랜잭션 유발 및 gas 지불도 가능함.
(일반 브라우저로는 트랜잭션 유발 및 gas 지불이 불가능)

 

 

---

ERC20 Token

ERC = Ethereun Request for Comments (RFC)

NFT (Non Fungible Token)

대체 불가능한 토큰.
원본과 복사본의 가치 차이가 있음. NFT는 어떤 게 원본인지 알려줌.

ERC20

fungible token을 만들기위한 이더리움 표준.
교환 가능(대체 가능). 복사를 몇 번 하든 가치가 똑같음.

 

Coins vs. Tokens

* Coin
: 블록체인에 native한 디지털 화폐 ex) Bitcoin의 BTC, Ethereum의 ETH, Ethereum classic의 ETC
 가치를 저장하고 교환의 매체로 사용함. PoW로 채굴되거나 PoS로 얻을 수 있음.

* Token (≠ coin)
: 블록체인 플랫폼(프로젝트) 상에서 프로그램에 의해 만들어진 currency.
 블록체인 상에서 새로운 토큰을 만들기 위해서는 새로운 contract가 필요하며,
 코드가 deploy되면 토큰을 어떤 용도로 사용할 지가 코드에 의해 규명됨.
 ex) ERC20, ERC721

ICO (Initial Coin Offering)

ICO for selling ERC20 tokens for ether

smart contract를 통해서 투자자를 대상으로 새로운 프로젝트를 소개하고, 얼마를 투자하면 우리의 코인을 얼마나 줄 것인지 알려줌. 투자자들은 교환가치가 어느정도 확립되어있는 돈(비트코인이나 이더리움)으로 투자함.
대부분의 프로젝트가 이런식으로 시작함.

cf) IPO : 기업 공개 (주식시장에 우리 회사를 공개해서 투자자금을 모음)

 

---

Dapp: an app mostly/entirely decentralized

탈중앙화된 앱. 하지만 전적으로 모든 부분에서 완벽히 탈중앙화 되어있는 것은 아님.

DApp의 장점

- Resiliency (탄력성)
: DApp의 backend는 블록체인 플랫폼에 의존하고 있음.
 따라서 이더리움의 모든 노드가 전부 다운되지 않는 한 DApp이 다운되거나 사용하지 못하는 상태가 되는 경우가 없음.

- Transparency (투명성)
: DApp을 구성하는 핵심요소인 smart contract 코드는 모두에게 공개되어있으며 누구도 기록을 조작,변경하지 못함.

- Censorship resistance (검열 거부) 
: user는 중앙화된 제어(centralized control)의 영향 받을 필요 없이 DApp에 접근 가능함. 

 

Dapp components

Backend software (application logic) 

백엔드 핵심은 smart contract임! business logic과 관련 state 저장.
기존의 server-side component를 대체함.(서버가 필요하지 않음. 서버 역할을 대체할만한 탈중앙화된 부분이 존재)

smart contract에서 실행하는 것은 비용이 많이 드니까 최대한 핵심적인 것으로만 제한해서 실행시키자.
smart contract의 코드 자체는 이미 블록체인에 기록되었기 때문에 변경될 수 없음.(지울 수는 있음; self-destruct)

smart contract의 size가 크다면 설치 및 사용할 때의 cost가 많이 들어서 현실적으로 많은 DApp들이 타협 중임.
-> DApp을 돌릴 때 이더리움을 살짝 벗어나서 다른 외부 소스의 도움을 받자.
: 계산량이 많은(CPU intensive한) 코드의 실행이 필요하다면 외부의 도움을 받자. (offchain computation)
: 방대한 양의 데이터를 저장해놓고 수시로 참조해야 한다면 외부 저장소의 도움을 받자 (offchain storage)

=> off-chain(이더리움 플랫폼을 벗어난 외부 소스)을 신뢰할 수 있는지에 대한 문제가 있음.

Frontend software

일반 사용자들에게 가장 익숙한 웹 기반의 인터페이스를 그대로 채택중.(HTML,CSS,Javascript 등의 표준 웹 기술 사용)
하지만 일반 웹 브라우저로는 이더리움에 접근 불가능.(내 account에 gas; ether가지고 있고 서명을 해야 transaction 발생시킬 수 있기 때문.) -> extension 붙여야 wallet역할 가능. ex) MetaMask

이더리움과 연결될 때는 보통 web3.js 라이브러리를 사용함.
대부분 non_mobile dapps을 만들 수 있는 tool들만 주로 나와있음.

Data storage

storage의 size가 크면 gas cost가 많이 들어서 대부분의 DApp은 off-chain data storage service를 사용함.
ex) cloud storage service(클라우드 운영자에 의해 centralized)

=> P2P에 기반한 data storage service를 이용하자! (decentralized)
- IPFS
: NFT 거래하는 open sea에서 디지털화된 작품을 저장하는 용도로 사용하는 시스템.
 content를 hash해서 그 hash(key역할)로 file을 찾음. (content-addressable)

- Swarm
: IPFS와 거의 비슷함.
 hash로 file에 접근 가능. (content-addressable)

Decentralized Message communications

특정한 목적지로 직접 보내는 것이 아니라 P2P 네트워크를 통해서 이웃을 거쳐서 감.
P2P 네트워크의 모든 노드가 client이자 server역할을 하면서 메세지를 전달함.
ex) Whisper : DApp을 위한 P2P 메세지 프로토콜 ex) 채팅방

Ethereum Name resolution (ENS)

사용자가 어떠한 smart contract에 접근하기 위한 interface를 제공하는 서비스(DNS랑 비슷).
탈중앙화된 방식으로 다른 DApp을 제공하는 DApp임.
ex) Ethereum Foundation donation address 0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359 외울수없음.
      ENS를 이용하면 저걸로 바꿔줘서 저기로 접속할 수 있음. (전자가 request, 후자가 response)

cf) DNS : centralized service

Web3 architecture ; A decentralized web using smart contracts and P2P technologies

---

An Example: Auction Dapp

간단한 경매 DApp 설계

물건 소유자가 물건의 originality를 보장해줘야 가치를 인정받고 팔림.
따라서 ERC721 표준에 따라 NFT를 만들고 원본에 연결해서 originality를 보장해줌.

원본은 그대로 냅두고 원본의 '소유권'이 바뀌는 거임

transaction이 요청해서 createAuction()이 가장 먼저 실행됨

 

Further Decentralizing the Auction Dapp

To make this Dapp decentralized and resilient

1. 모든 application code를 Swarm이나 IPFS에 저장

1) preparing Swarm
2) uploading files to Swarm

DApp의 전체 프론트엔드를 Swarm에 저장해두고, 실행할 때는 웹서버 대신 Swarm node에서 직접적으로 실행.
file hash를 참조해서 어떤 Swarm node에서든지 file들에 접근할 수 있음.

* Swarm : content addresable하게 접근할 수 있는 data storage

2. ENS를 사용해서 DApp에 name으로 접근

ENS는 탈중앙화된 방식으로 구현되었고 DApp의 접근성을 높임. (name만 가지고 DApp의 resource를 찾을 수 있음)

1) ENS registry 호출
 : name resolution을 할 수 있는 resolver의 주소를 알려줌.
  (등록된 질문이기만하면 그 질문에 대한 답을 알려줄 수 있는 resolver를 알려줌) ; resolver는 하나가 아님!!탈중앙화!!
2) 답을 알려줄 수 있는 resolver가 호출되면 알맞은 결과를 리턴해줌.

* ENS의 name 등록 과정
: 등록하고자하는 이름이 이미 다른 사람에 의해 등록되어있는지 판단하는 과정 필요
 -> 해당 과정을 Auction을 통해서 함! (decentralized)
  나보다 높은 bid를 제시하며 같은 name으로 Auction을 신청한 사람이 있다면 그사람이 낙찰됨.

 

해당 Auction의 목적 : 가장 높은 bid를 쓴 사람에게 ethereumbook.eth를 팔기

일정 기간동안 bid를 받음. 이더리움이니까 bid가 담긴 트랜잭션을 암호화하지 않고 누구나 볼 수 있음. 
-> 치명적 단점임. 꼭 사용하고싶다면 가장 높은 bid보다 조금 더 높게 내면 됨.
=> 따라서 bid를 감추기 위해 hash를 사용함. bid에 hash를 적용하고 (예측 불가능하도록) 랜덤 쓰레기값을 붙여서 보냄.

* Reveal Period
: bid 얼마 했는지 패를 드러내자. hash값을 만들 때 사용한 랜덤값을 제시해서 나의 bid값을 증명.
 해당 기간동안 reveal하지 않으면 무효처리됨. 해당 기간이 끝나면 가장 높게 써낸 bid가 결정됨.
 이때 Vickery Auction을 사용함.

* Vickery Auction
: 가장 높은 bid를 써낸 사람에게 낙찰이 되는 것은 기존 Auction과 동일함.
 근데 그 사람이 물건을 가져가기 위해 지불해야하는 돈은 내가 내겠다고 했던 bid값보다 작음. (2등 금액을 지불함)
 -> bid값을 높게 쓰는 것에 대해 겁을 내는 것을 없애줘서 낙찰가를 끌어내리려는 것을 방지함
 
* Post-Auction
: 낙찰받은 사람이 name resolver를 셋업시킴 -> name resolver가 낙찰 성공 대상의 이름에 대한 resolution 제공

* Resolver
: 이름에 대한 값을 알려주는 역할(name server역할)
 ENS에서는 DNS와는 달리 name server가 고정된 하나(중앙 서버)만 있는 것이 아님.
 어떤 name resolver가 이 이름에 대한 resolution을 제공하게 될 지 모름.(공격하여 shut down 시키기 어려움)

cf) DNS가 name resolution을 하는 과정
: 브라우저 창에 www.google.com  검색 -> 구글에 접근하기위해 도메인 이름(www.~)은 사실상 의미가 없음.
IP주소가 필요함.. 32bit(IPver4)를 사람이 보기 좋게 10진수로 바꿔놓은 것이 203.249.66.10인데
이걸 외우기 힘드니까 도메인 이름으로 검색함. -> 도메인 이름을 IP주소로 바꿔주는 것이 필요함. 그 역할을 하는 것이 name server임.(centralized)

cf) DNS의 name 등록 과정
: 도메인 이름을 등록받아주는 registra에게 이 도메인에 대해 내가 소유권을 주장하고 싶다고 등록 요청을 함.
 -> 도메인 이름을 이미 선점중이면 등록을 받아주지 않음. (registra에게 찾아가야하니까 centralized)