Smart Contract 는 1994년 암호학, 법학에 일가견이 있는 컴퓨터 과학자인 Nick Szabo 에 의해 소개된 개념이다. 신뢰할 수 없는 컴퓨터 인터넷 환경에서 "고도로 발달된" 계약을 준수하도록 하는 프로토콜이다.

혹 처음 "스마트 계약" 이라는 말을 처음 듣는 사람들은, 블록체인에 "계약" 이라 불리울만한 "문서"를 업로드 하고 이를 준수하도록 "약속"하는 것이라는 막연한 상상을 하고는 한다(실제로 있었다). Contract 라는 용어가 그러한 오해를 살 수도 있는게 사실이긴 하다.

말을 약간 바꿔보자. "스마트 계약"은 블록체인에 모든 Node가 접근할 수 있는 "코드" 를 업로드 하고, 이를 "실행" 하도록 하는 "프로토콜" 이라고 한다면 좀더 이해하기 편할 수 있을 것이다.

일단 이 Smart Contract 에 대하여 기술적으로 이해하기 전에 Ethereum 의 기본적인 아래 사항에 대해 이해하고 있는게 좋다.

(위 개념들은 시간나는대로 정리하여 블로그로 올리기로 한다)

Contract 는 마치 Assembly 코드를 연상시키는 듯한 Byte Code 형태의 코드로 구성해왔다. OP_CODE 로 불리우는 1바이트 크기의 명령인 Operation Code 들은 Stack 에 쌓이며 실행된다. 

Bitcoin 의 경우, Script 라고 부르고 있으며 기본적인 Balance Transfer Transaction 의 경우 Client 가 Transaction 의 Script 파트에 Pubkey, PubKeyHash, Private Key Signature 를 연산하여 UTXO 를 소비하려는 현재 Transaction 이 정당한지를 검증하는 Script 를 자동으로 추가하도록 되어있다.

좀더 자세히는, UTXO 의 Public Key Hash 가  Transaction 의 INPUT 파트에 있는 Unlocking Script 내의 Public Key 의 HASH160 OPCODE 연산 결과와 같은지를 비교하며 최종 CHECKSIG OPCODE 를 통해 Private Key 의 Signature 를 Public Key 로 검증하여 TRUE 를 리턴하는지를 검사한다.

이러한 Script 파트에는 원하는 OPCODE 들을 구성하여 Transaction 을 만들어낼 수 있는데, 쌍방 혹은 여러 “신뢰되지 않은” Peer 들 간에 특정한 OPCODE Script를 실행시켰을 때 값이 정상이라면 그 Transaction 을 "정상으로 인정한다”라는 “계약적인 조건”을 명시하고 실행 가능하므로, 이러한 개념으로  Contract Code 라고 표현하고 있다.

Bitcoin 의 OPCODE 는 Constants, Flow Control, Stack, String 의 Splice, Bitwise, Arithmetic, Crypto, Locktime, Pseudo-Words 의 카테고리에 해당하는 85개 정도의 명령어를 제공하고있다.

Bitcoin 이 선보인 이 Contract Script 는 매우 획기적인 방식이며 신뢰할 수 없는 환경에서 신뢰를 기반으로 해야하는 중요한 거래가 가능하도록 하는 핵심적인 요소로서 동작한다. Ethereum 의 Vitalik Buterin 은 어린나이에 이러한 Bitcoin Blockchain 에 대해 이해하고 Contract Code 를 더 확장하면 무한한 확장성을 가진 탈 중앙화 된 컴퓨팅 환경, 더 나아가서는 Global/World Computer 를 실현시킬 수 있다고 믿고 Gavin Wood 박사는 그의 사상을 구현하기위해 함께하며 개발언어에 독립적인 Yellow Paper 를 만든다.

Ethereum 은 Bitcoin 의 Contract 에 비해 매우 고도로 발전된 형태의 Contract Code 라고 말할 수 있으며, 단순한 “검증” 과 “연산” 을 뛰어넘는 ”상태”와 “함수”를 정의하고 “상태변이”와 “데이터 저장”이 가능한  Turing Complete 코드 개발을 가능하도록 하였다.

라는 상태변이 함수과계에서,

Bitcoin 의 S와 S' 는 UTXO 의 Balance 만이 가능하지만,

Ethereum 의 S 는 EOA(Externally Owned Account)의 Balance 는 물론, Account의 Nonce, Contract Account 의 Storage 에 저장된 데이터의 값들도 포함된다.

즉, “잔고” 뿐만이 아니라 “데이터” 또한 상태변이 함수로 변이 가능한 상태의 대상이 된다는 것이다.

또한 이러한 상태변이 함수를 Smart Contract 라고 부르며, Smart Contract 는 EVM(Ethereum Virtual Machine) 이 실행시키고, 여기에서 실행되는 이러한 Smart Contract 함수를 정의한 Code 를 EVM Code 또는 Smart Contract Code (줄여서 Contract Code) 라고 부른다.

Loop 지원, Contract Account, (Contract 의) Block 과 Transaction 정보에의 접근, Statefull, Gas 개념 등은 Ethereum Smart Contract 의 큰 특징이다.

Bitcoin 대비 별것 아닌 변화일것이라 생각될 수 있지만 이것은 Blockchain 기술의 적용 가능 분야를 무한히 확장할 수 있는 큰 변화이다. 복잡한 금융 파생상품에서 부터 지능형 머신/IoT 디바이스의 자율적 협업,  슈퍼컴퓨터를 초월하는 강력한 컴퓨팅 까지 가능하게 하는 중요한 열쇠가 바로 이 Smart Contract 라고 할 수 있다.

Ethereum 은 Dapp (Decentralized Application) 이라는 개념을 Smart Contract 를 중심으로 하여 실현하고 있으며, 이는 기존의 중앙 집중식의 시스템의 단점(DoS 취약, 보안 취약, Single Point of Failure, Scalability 한계성, Privacy 침해, 외부 인터페이스 표준화 문제 등)으로 부터 자유로워질 수 있는 탈중앙화된 Appication 아키텍쳐가 가능해지는 기술이라고 할 수 있으며, 전통적인 P2P 로는 풀 수 없었던 “신뢰할 수 없는 환경에서의 신뢰성 있는 서비스 운영”이 가능하게 하는 핵심적인 기술이 아닐까 생각한다.

Ethereum 은 Smart Contract Code 구현을 위해 4가지의 언어를 구현한다. 

Mutan, LLL, Serpent, Solidity 가 현재 Ethereum 의 Smart Contract 를 구현할 수 있는 Code 이다. 이중 Mutan 은 C 언어와 유사한 구조를, LLL 은 Low-Level 의 OPCODE 형태를 가지며, Serpent 는 Python 과 유사하다고 할 수 있고, Solidity 는 JavaScript 와 매우 닮았다.

Mutan 은 Deprecated 되었으며, LLL 은 더이상 Develop 하지 않으나 여전히 지원하고는 있으며 Serpent 와 Solidity 가 주요 언어라고 볼 수 있으며 그 중 Ethereum 은 Solidity 를 Main 언어로 주력하고있다.

EVM(Ethereum Virtual Machine) 은 이러한 상위레벨 언어로 만들어진 코드가 컴파일되어 생성되는 Byte  Code 를 실행하기 위한 Runtime 으로, OPCODE, Stack 외에 Ethereum 에서 추가된 Memory, Storage 를 사용하는 주체이기도 하다.

Smart Contract 실행 (Create, Message Transaction)은 모든 Block 검증을 수행하는 Node 에서 동일하게 일어난다. 또한 Contract 를 실행하는데에는 현재 Homestead 에서도 아래와 같은 Gas 를 소모해야 한다.

Gas 는 Gas * GasPrice 만큼의 Wei 비용으로 지불되며, 이는 Turing Complete Machine 인 이더리움이 무한루프와 같은 Attack 으로 부터 자유롭기 위함과 Contract 실행과 Storage 사용에 대한 자원비용 보상을 지불하는 목적이다.

Gas 가 생각보다 많이 나올 수 있는데, Code 실행과  sstore 등 뿐만 아니라, Transaction 의 size 에도 비용이 비례하여 증가하게 되기 때문이며, 최소 Gas Price 보다 크지 않으면 아예 Transaction 이 발생하지 못하는 비극이 발생한다. 결론적으로 돈이 있어야 한다.

모든 Contract Account 는 Storage 라고 불리는 Persistent 저장소를 갖고있다. Key-Value 맵 구조로 32바이트 키를 32바이트 값으로 맵핑하도록 되어있다. Contract 는 자기 자신 이외의 Contract 의 Storage 를 읽거나 쓸 수 없다.

Memory 는 Contract 가 Message Call 이 있을 때 마다 최신의 Instance 를 얻을 수 있는 공간으로, Byte 레벨로 읽고 쓸 수 있으나 32바이트 단위 Chunk로 저장된다. 즉, 1 이라는 값을 저장하면 32바이트 (256비트) 공간에 저장된다.

EVM 은 총 1024개의 Instruction Set (OPCODE) 를 담을 수 있는 Stack 을 갖으며, 256비트의 word (값) 을 갖는다. 

이러한 특성으로 Message Call 시에도 몇가지 제약사항들이 있는데, 그중 하나는 32바이트를 넘는 문자열을 하나의 파라미터로 보낼 수는 없다는 것이다. 

Contract 는 다른 Contract 를 Call 하거나 EOA 로 Ether 를 보낼 수 있으며, 이때 Message Call 을 사용하게된다. 일반 이체 Transaction 과 매우 유사하지만 호출할 Contract 의 주소, Method 의 주소, 함수  파라미터(옵션)를 넣는것이 다르다.

Sub Contract Call 이 실행되어야 하는 경우, 연쇄적인 Message Call 이 Contract 에 의해 일어나게 되며, 이러한 연속된 Contract 실행을 위한 충분한 Gas 를 포함시켜야만 나중에 Contract 실행이 끝까지 될 수 있다. Call 은 최대 1024 Depth 까지 호출될 수 있다.

Message Call 의 결과는 Block 내의 Transaction Receipt 를 참고하여 조회할 수 있다.

Contract 실행 전, EVM 은 Transaction Sender 의 잔고가 충분한지 검토하고 실행하며, 실행 중 Gas 가 모두 소진되었으나 실행이 완료되지 않은 경우에는 그때까지의 Gas 는 지출되고 모든 State 는 Contract 실행 이전 단계로 돌아간다.

Message Call 중에, Delegatecall 이라는 방식이 있는데, 이건 Contract 가 실행될 때 Contract 를 실행시킨 Contract 의 Context 를 사용한다는 것이다. 그리고, Message Sender 와 Value 가 변경되지 않고 Caller Contract 의 것을 그대로 사용한다.

이러한 특성을 활용하여 Library 형태의 Contract 를 만들 수 있다.

Contract 를 Byte Code 로 컴파일 하여 Blockchain 에 Upload 하여야 Contract 를 실행할 수 있다. Contract Create 는 EOA 가 Create 하는것이 일반적이나, Contract 가 다른 Contract 를 Create 할 수도 있다. 

Contract 를 삭제할 수 있는 유일한 방법은 Contract Address 에서 (자신이) SELFDESTRUCT 명령을 수행하는 것이다. 이때 Contract Account 의 Ether 잔고는 지정된 Account 로 이체되고 Contract 의 모든 State 는 소멸된다.

위 기본적인 개념들 말고도 설명해야 하는 것들이 많다. 앞으로 조금씩 써보도록 하고, 예제도 종종 올려보도록 하겠다. 

Genesis 정보까지 모두 준비되었다. 이제 Node 를 실행하면 된다.

그런데 옵션으로 주어야 할게 쫌 있다. 좀 자질구레한것들이지만 Shell Script 로 만들어놓으면 편하기 때문에 MinGW 의 bash shell script 로 만들어놓는다.

내가 사용중인 Shell Script 는 다음과 같다. Wallet 의 Master Password 는 1111 이고 JSON-RPC 를 사용하기 위한 Session-Key 로는 0000 을 지정해주었다. 

그리고 연결되는 Node 간의 시간차는 +- 13분 이내 이어야 한다. 시간을 잘 맞추고 시작하자.

[Linux]

./eth --config $ETH_HOME/res/config.json --master 1111 --json-rpc
--json-admin 0000 --admin-via-http --no-bootstrap --listen 30301
--remote "192.168.0.122" --port 30301 --db-path $ETH_HOME/db_goodjoon 
--mining on --address "0047d27a61e384403d875239cbc462896044213e" 
--verbosity 99 --json-rpc-port 8545 --ipc --upnp off  $@

[Windows]

.\eth.exe --config d:\ethereum\res\config.json --master 1111 
--json-rpc --json-rpc-port 8545 --json-admin 0000 --admin-via-http 
--listen 30301 --remote "192.168.0.60" --port 30301 
--db-path d:\ethereum\db_goodjoon --verbosity 9 
--admin-via-http -o full  --upnp off  %*

--admin-via-http 옵션은 1.2.0 에서 새로생긴 옵션인데, JSON-RPC 를 통해 admin 기능을 실행할 수 있게 허용하겠단 이야기이다. 

--no-bootstrap 으로, Peer Server 에 연결하지 않도록 하였으며

--remote 옵션으로 직접 연결할 Node 를 지정해주었다.

--db-path 로 기본 DB PATH 를 사용하지 않고 db_goodjoon 을 사용하도록 설정하였다. 

console 옵션은 어차피 1.2.1 버전의 C++ eth 는 동작하지 않는다. 나중에 process 를 하나 더 띄워서 attach 해서 사용할것이기 때문에 console 옵션은 주지 않았다.

※ 뒤에서 언급하겠지만, 1.2.1 버전 오면서 Windows 의 버그와 Default 값의 동작이 더 심각해졌다. coinbase address 도 기본으로 안넣어주고, JSONRPC 포트도 지정해주지 않으면 -1 값이다. 그러나 아직도 --help 에는 8545 기본값으로 나온다. Geth 의 jsonrpcapi 옵션에서 볼수있었던 JSON RPC admin 기능을 위해 --admin-via-http 옵션도 생겨나고 했는데 그러면서 좀더 꼬이고있기도 하다. (새로 팀장 오고나서 팀을 "REBOOT" 하겠다고 했는데, 좀 잘 되었으면 좋겠다. Go 팀을 좀 봐라 쫌..)

(++)Ethereum 이 출력되고 이후 뭔가 좌르륵~ 나오고 있다면 일단 동작하는 것이다. 

Ubuntu에서 실행중인 모습

(++)Ethereum
...  00:36:07.628|eth  Reading /home/korean44/.web3/keys/152d7983-ac83-b2f9-159c-18ab7106fd83.json
⧎ ℹ  00:36:07.649|eth  Id: ##e808dba2…...  00:36:07.684|eth  Opened blockchain DB. Latest: #5df28093… (rebuild not needed)...  00:36:07.700|eth  Opened state DB.
⧫ ◎  00:36:07.702|eth  startedWorking()
cpp-ethereum 1.2.1
  By cpp-ethereum contributors, (c) 2013-2016.
  See the README for contributors and credits.
Transaction Signer: XE50000000000000000000000000000000 (00000000-0000-0000-0000-000000000000 - 00000000)
Mining Beneficiary: XE8916H0DGVW3SIMF6X9AWCB8J6ZV5PWE6 (152d7983-ac83-b2f9-159c-18ab7106fd83 - 0047d27a)
Foundation: XE55PXQKKK4B9BYPBGT1XCYW6R5ELFAT6EM (00000000-0000-0000-0000-000000000000 - de0b2956)
  ℹ  00:36:13.611|p2p  UPnP device: http://192.168.0.1:3274/etc/linuxigd/gatedesc.xml [st: urn:schemas-upnp-org:device:InternetGatewayDevice:1 ]
⧎ ℹ  00:36:13.684|p2p  Punched through NAT and mapped local port 30301 onto external port 15725 .
⧎ ℹ  00:36:13.684|p2p  External addr: 211.222.99.134
⧎ ℹ  00:36:13.686|p2p  p2p.started id: ##e808dba2…
 ⚡   00:36:13.695|eth  void dev::p2p::Host::start() 2091 ms
Node ID: enode://e808dba2f0d7eb464656e01be81317386af18b8a0c554c7f9fd78fcd0f1a008a584891aed201018444af50ede46faf6884750baa1f06eca9e9c706d827b931a3@211.222.99.134:15725
JSONRPC Admin Session Key: 0000
⧫ ℹ  00:36:13.738|eth  Mining Beneficiary: @0047d27a…
⧫ ◎  00:36:13.739|eth  Rejigging seal engine......  00:36:13.741|eth  Generating seal on #ab31b73b… # 1
  ℹ  00:36:13.743|miner0  Loading full DAG of seedhash: #00000000…
DAG  00:36:19.606|miner0  Generating DAG file. Progress: 0 %
⧫ ◎  00:36:22.718|eth  Since 2016-03-04 15:36:07.686Z (15): 15ticks
DAG  00:36:25.842|miner0  Generating DAG file. Progress: 1 %

아마 Windows 에서는 아예 Console 에서 JavaScript Console 기능이 동작하지 않을 것이다. 버그이다. 이건 Frontier Release 이전부터 계속되어오는 문제이다.

수정하고싶은 생각도 없는듯 하고 암튼 Windows 는 C++ Ethereum의 대상이 아닌게 날이갈수록 확신이 든다.

※ Miner는 DAG 파일을 만드는데에 상당한 시간이 소요된다. 처음 1회만 실행되므로 참고 기다린다.

그래도 JavaScript Console 을 띄워서 보는게 가장 빠른 방법이므로 한번 해보도록 한다.

Linux 에서는 

만으로도 현재 실행중인 eth 에 attach 를 한다. Linux 에서는 console 이 잘 동작하므로 처음 실행할 때 마지막에 console 이라고 치면 되긴 하지만, 로그가 수없이 지나가므로 JavaScript API 를 실행시켜도 결과가 로그에 파묻힌다. 그래서 난 그냥 터미널 하나 더 띄워서 attach 시킨다.

Windows 는 1.2.1 버전 오더니 더 심각한 버그들이 발생한다.

이렇게 url 까지 적어줘야 한다. default 가 먹히질 않는다.

암튼 Console 이 attach 되고나면 ">" 가 보인다. JavaScript Console 이다.

1.2.0 까지만 해도 안그랬던것 같은데, JavaScript API 를 Geth 와 I/F 를 맞추고있는 과정이라서 그런지 web3 만 치면 전체 object 들이 나와야 하지만 에러가 난다. 이건 Linux 나 Windows 나 모두 마찬가지이다.

그래서, web3.eth 객체를 살펴보면, 아래처럼 출력이 될 것이다.

> web3.eth
{
  _requestManager: {
    provider: {
      send: [Function],
      sendAsync: [Function]
    },
    polls: {
    },
    timeout: null,
    send: [Function],
    sendAsync: [Function],
    sendBatch: [Function],
    setProvider: [Function],
    startPolling: [Function],
    stopPolling: [Function],
    reset: [Function],
    poll: [Function]
  },
  getBalance: [Function],
  getStorageAt: [Function],
  getCode: [Function],
  getBlock: [Function],
  getUncle: [Function],
  getCompilers: [Function],
  getBlockTransactionCount: [Function],
  getBlockUncleCount: [Function],
  getTransaction: [Function],
  getTransactionFromBlock: [Function],
  getTransactionReceipt: [Function],
  getTransactionCount: [Function],
  call: [Function],
  estimateGas: [Function],
  sendRawTransaction: [Function],
  sendTransaction: [Function],
  sign: [Function],
  compile: {
    solidity: [Function],
    lll: [Function],
    serpent: [Function]
  },
  submitWork: [Function],
  getWork: [Function],
  coinbase: '0x0047d27a61e384403d875239cbc462896044213e',
  getCoinbase: [Function],
  mining: false,
  getMining: [Function],
  hashrate: 0,
  getHashrate: [Function],
  syncing: false,
  getSyncing: [Function],
  gasPrice: 50000000000',
  getGasPrice: [Function],
  accounts: ['0x0047d27a61e384403d875239cbc462896044213e'],
  getAccounts: [Function],
  blockNumber: 0,
  getBlockNumber: [Function],
  iban: [Function],
  sendIBANTransaction: [Function],
  defaultBlock: 'latest',
  defaultAccount: undefined,
  contract: [Function],
  filter: [Function],
  namereg: [Function],
  icapNamereg: [Function],
  isSyncing: [Function]
}

현재 Difficulty 도 낮춰놓고, 블록 생성 간격도 13분에서 1분으로 맞추도록 조정하였다. 

여태 Windows 버전을 Build 하고 소스 수정하고 해왔다. 그런데 Homestead 겨냥중인 1.2.1 버전 릴리즈 되면서 더이상 Windows 를 안쓰고싶게 만든다.

Frontier (1.0.1) 까지는 그나마 참고 쓸 수 있었으나 1.1.3 버전 부터였나 점점 되야하는 기능들이 Windows 에서 안돌더니 이제 Geth 와 I/F 맞춘다는 명목등을 이유로 작업을 하고있으면서 Windows 는 안그래도 뒷전인데 더 뒷전이 되어버렸다.

Windows 에서 못써먹겠다는 이유는 대략 이러하다.

1.0.1 => Contract 를 Create 하고 배포한 후 JSONRPC 건 JavaScript 건 call 을 2회 하면 그 다음부터는 무조건 0을 리턴한다. 재기동만이 정상화 방법이다. 그래서 Windows 에서는 Mining 시키고 Mac 이나 Linux 에 Contract call 을 해왔다.

1.1.3 => Windows 버전이 다른 Peer 와 Connect 할때 RLPx Handshake 시에 괜히 auth fail 이 난다. 그리고 이 시점 부터 다른 Platform 의 Miner 가 멈추고 아예 동작을 안한다. Windows 를 먼저 띄워놓고 다른 Platform 의 Peer 가 connect 을 하면 괜챦다. 

1.2.0/1.2.1 => Windows 가 붙으면 auth fail 은 또 계속 난다. Miner 죽는 문제는 해결한듯 하다. 그런데 Geth 와 CLI 나 JS Console 이 아직 맞춰지지도 않았고 API 가 동작하지 않는것들도 있다. 

그리고, DAG 도 버그가 있다. 어떤때는 hashrate 가 3,4 H/s 가 나온다. 계속 재실행 하다보면 언젠다 다시 정상 hashrate 가 나온다. 문제다.

위 이유로, 이후 진행은 Linux 로만 한다. Mac OS X 도 잘 지원되는 편이나 블로그 쓰는데 맥북까지 켜서 2대에서 끄적거리기가 싫다 ^^;; 그냥 VirtualBox 로 Linux 2대 켜놓고, shared folder 하나 만들어서 소스는 한군데에서 수정하고 빌드한 후 양쪽 VBox Guest (Ubuntu 15.10) 에서 실행시켜 테스트 하는 방향으로 가겠다. 뭐 필요하면 3대 4대 하거나 Instance 를 더 늘리던가 하겠다.

$ sudo apt-get install -y dkms build-essential linux-headers-generic linux-headers-$(uname -r)

3. VBoxLinuxAdditions.run 을 실행한다

$ sudo /media/cdrom/VBoxLinuxAdditions.run

4. Reboot 한다

5. 공유폴더를 Mount 해본다 

$ sudo mount -t vboxsf <공유이름> <마운트할폴더>

잘 되면 그냥 쓰면된다. 그런데 No Such Device 라고 나올 수 있다. 이럴때는

6. vboxadd 설정을 다시 해본다

$ cd /opt/VBoxGuestAdditions-*/init 
$ sudo ./vboxadd setup

7. 다시한번 리부팅 하고 마운트 해보면 잘 될것이다