Account 까지 만들었으므로 이제 Account 의 address 에 이더가 충만한 나만의 genesis 를 만들어서 간단한 Transfer Transaction 을 실행해보겠다.

참고로, 그간 golang 강좌 초반부를 쓰느라 신경을 좀 못쓴 동안에 1.2.0 버전이 바로 어제 릴리즈 되었다 (2016.02.29 에).
git pull 하고 submodule 을 update 한 후 1.2.0 버전으로 소스를 업데이트 하고서 다시 빌드를 하였으며, 이후 설명은 eth 1.2.0 기준으로 해 가도록 하겠다.

1.1.4 버전으로 Private Network 을 구성하고 나서 좀 당황스러운 점들이 있었다. 일단, Node 간에 RLPx handshake 가 auth 를 검증하는 동안 실패하는 상황이 발생하며 Handshake가 실패하면 아예 Miner 가 Mining 을 멈추는 상황으로 가는 버그이다. 이게 수정되었는지 궁굼한데 Release Note 를 보니 Mining 쪽 버그 픽스가 되었다고 하는데 1.2.0 에서 확인해봐야 하겠다.

그리고, Geth 의 Attach 가 eth 에 가능하게 되었다. geth 에는 --session-key 옵션이 없는데 이게 어떻게 동작할라나 모르겠다. 암튼 된다고 하니 이 두녀석들을 갖고 또 테스트 해봐야 하겠다. eth 1.2.0 과 geth 1.3.4 가 거의 동시에 릴리즈 되었으니, geth 설명할 때에도 최신버전 (아예 1.3.4의 코드네임이 Homestead 이다)으로 해야 하겠다.

[goodjoon Debug]$  ./eth --version
eth version 1.2.0
eth network protocol version: 63
Client database version: 12041
Build: Windows/msvc/int/Debug
[goodjoon Debug]$

일단은 Private Network 상에서 PoW 로 Consensus 를 하는, Public 형태와 동일한 Ethereum Local Network 을 구성 해보도록 한다.

▌config.json (genesis.json) 만들기

genesis.json 이 Frontier Release 버전인 eth 1.0.0 과 달라졌다. Geth 와도 호환이 안되는 JSON 포맷으로 바뀌었다 (config.json). 그나마 좀 Simple 한 포맷이었는데, 좀더 복잡하게 바뀌었다.
create-genesis.py 스크립트로 만들어져 나오는 json 은 동작하지 않으므로, 수동으로 작업해보도록 하겠다.

1.2.0 부터는 genesis.json 으로 부르지 않고, config.json 으로 부른다. 옵션도 --config 로 바뀌었다. --genesis 옵션도 코드 내에서는 아직 살아있지만 --help 로 볼때는 나오지 않는다.

우선 내 Account 중에 억만장자를 만들고 싶은 Account 의 Address 를 결정해야 한다.
eth 가 잘 빌드되었다면

$WEBTHREE/build/libethereum/ethkey/Debug
밑에 ethkey.exe 파일이 있다

[goodjoon Debug]$  ethkey.exe list --master 1111
1a7e55b0-3eb7-05ec-248e-8d901e268d76 0096bb98… XE602H4XB00HUY08LU416SCBGO3CS63H66  Default key
6ecc980b-2f99-013d-167e-0ea9caffde4e 007386ab… XE561WBEXUY46M6G05SDKF5P9C334V3JT6  myname
31ae0923-14da-a1a9-85ba-ab9563c5da4b 005bfaf9… XE241IE5KGWVRVYD6B5H8ZHMXNMP57Q4KM  joooooon
[goodjoon Debug]$
위 처럼 Wallet 의 Key 들이 보인다면 이중에서 사용할 Key 를 선택한다. 난 "Default key" 로 자동생성되었던 Account 를 선택한다.

Genesis 에는 Account 의 Balance 를 지정해주려면 Address 가 필요한데, 위 ethkey list 명령으로 출력된 결과에는 address 가 FULL 로 표시되지 않는다. ethkey 를 다시 사용하여 Full Address 를 표시해본다.
[goodjoon Debug]$  ethkey.exe inspect "Default key" --master 1111
Default key (0096bb98…)
  ICAP: XE602H4XB00HUY08LU416SCBGO3CS63H66
  Raw hex: 0096bb9802b14f72ba4cdbd105127fe57a1dafae
[goodjoon Debug]$

옵션에 계속 --master 1111 을 넣는 이유는, 현재 MinGW/MSYS 를 사용하고있는데 eth 가 이 환경에서는 key store 의 master 패스워드 입력하라는 Prompt 가 나올 때 Exception 이 발생하므로 master 패스워드를 바로 지정해주어야 한다. (Windows Command Prompt 환경에서는 문제가 없다)

위 Raw hex : 부분이 사용할 Account 의 address 이다.

이렇게 Linux 나 Mac 버전 또는 다른 Windows 에서도 Wallet 을 만들고 (keys.info, keys.salt), Key 를 생성한다 (Wallet (keys.info) 에 key 추가, .web3/keys 디렉토리에 추가된 key 의 정보(json) 추가).
Account 의 Address 를 모두 파악했다면, 이제 Genesis 정보를 만들어준다

{
    "sealEngine""Ethash",
    "params": {
        "accountStartNonce""0x00",
        "maximumExtraDataSize""0xFF",
        "tieBreakingGas"false,
        "minGasLimit""0x1388",
        "gasLimitBoundDivisor""0x0400",
        "minimumDifficulty""0x020000",
        "difficultyBoundDivisor""0x0800",
        "durationLimit""0x0d",
        "blockReward""0x4563918244F40000",
        "registrar" : "",
        "networkID" : "0xA1"
    },
    "genesis": {
        "nonce""0x0000000000000000",
        "difficulty""0x020000",
        "mixHash""0x0000000000000000000000000000000000000000000000000000000000000000",
        "author""0x0000000000000000000000000000000000000000",
        "timestamp""0x00",
        "parentHash""0x0000000000000000000000000000000000000000000000000000000000000000",
        "extraData""0x",
        "gasLimit""0x1388"
    },
    "accounts": {
        "0096bb9802b14f72ba4cdbd105127fe57a1dafae": { "wei""10000000000000000000000000000000000"},
        "0047d27a61e384403d875239cbc462896044213e": { "wei""20000000000000000000000000000000000"}
    }
}

위 처럼 genesis 정보를 만들어 준다. 가장 아래의 "accounts" 내의 정보가 주소와 Balance 이다.

아래는 "파악된" json 파라미터 정보들이다. Ethereum 의 가장 큰 문제가 바로 "체계 없는 문서화" 라고 생각한다. 어떤것은 Github Wiki 에 있고 어떤건 Gitbook 에, 또 어떤건 readthedocs 에.. 또 어떤건 각 Repository 의 wiki 에.. 또 어떤건 Repository 내의 프로젝트에 있는 .md 파일에.. 뭐 난리다.. 그래서 더 접근하기가 쉽지 않다.

위 config.json 의 경우도 제대로 된 문서 하나를 찾지 못했다. 개념적인 부분과 소스코드를 분석했던 기억을 더듬어 다시 써보니 혹시 틀린 부분이 있다면 그저 그러려니 하자.

[SealEngine]
Block 생성을 위한 Consensus 메커니즘을 어떤걸 사용할것인지를 지정한다.
현재 SealEngineBase Class 를 상속받는 Class 들에는 Ethash, BasicAuthority, NoProof 가 있다. 

Ethash 는 DAG 나 General Hashing 을 통해 PoW 를 하는 엔진이고, BasicAuthority 는 PoA 를 위해 실험적으로 Ethereum 에서 만들어놓은 Consensus 메커니즘으로, 현재 flu core 를 통해 사용할 수도 있으며, web3 에 통합되어있다. NoProof 는 Consensus 를 위한 증명작업을 하지 않는 Sealer 이다.

[Params]
"AccountStartNonce" : Account 의 최초 시작 Nonce 값을 지정한다. 기본적으로는 당연히 0 부터 시작하면 된다.
"maximumExtraDataSize" : 블럭의 Extra Data 의 최대 크기를 지정한다. 
"tieBreakingGas" : 
"minGasLimit" : 블럭의 최소 Gas 제한량이다. Block 의 GasLimit 값은 이 minGasLimit 보다 커야한다.
"gasLimitBoundDivisor" : 현재 블럭의 GasLimit 값은 parent block 의 gaslimit 대비 +- (parent block 의 GasLimit / gasLimitBoundDivisor)이내에 있어야 한다.
"minimumDifficulty" : 블럭의 최소 Difficulty 이다. 아무리 시간이 오래걸려도 PoW 는 이 Difficulty 이상을 유지해야 한다.
"difficultyBoundDivisor" : Frontier 까지 유효하며, 이전 Block 생성시간 대비 현재 Block 생성 시간이 durationLimit 보다 작으면 parent 의 difficulty 에 parent 의 difficulty / difficultyBoundDivisor 값을 더하고, 크면 같은값을 빼서 블럭 생성 시간을 조정한다
"blockReward" : Miner 의 Codebase 에 챙겨줄 reward wei 이다
"registrar" : Olympic 부터 Frontier, Homestead 등에서 기본적으로 존재하는 registrar Smart Contract 의 Address 이다. Name Register 서비스를 해주는 Contract 로 보면 된다.
"networkID" : 피어간의 통신 시 논리적으로 네트웍을 구분짓는 ID 이다. 피어간에 통신을 위해서는 이 networkID 값이 같아야 한다. Olympic 은 0, Frontier 는 1, Morden Testnet 은 2를 쓴다.

[Genesis]
"nonce" : 블럭의 nonce 값
"difficulty" : Block 의 Difficulty
"mixhash" : Block 의 hash 값
"author" : Block Author 정보, 필요하면 넣고..
"timestamp" : 블럭 생성 시각
"parentHash" : Genesis 이므로 0
"extraData" : 넣고싶은 Extra Data
"gasLimit" : Block 의 Gas Limit

[Accounts]
"<Account Address>": {"wei":<Balance>} 와 같은 형식은 UCA/UOA Account 의 Balance 를 적는 형식이고,
"0000000000000000000000000000000000000001": { "wei": "1", "precompiled": { "name": "ecrecover", "linear": { "base": 3000, "word": 0 } } } 와 같은 형식은 Precompiled Contract 를 표시하는 형식이다. Precompiled Contract 사용에 대해서는 향후에 알아보자.


이렇게 하면 일단 Private Network 에서 동작하는 Ethereum 을 위한 기본적인 Genesis 정보를 정의할 수 있다. 원래는 Genesis 만 지정하였는데, C++ Ethereum 은 좀더 유연성을 부여하기 위해 
  1. sealEngine
  2. options
  3. params
  4. genesis
  5. accounts
  6. network
로 구성된 config 정보를 입력할 수 있도록 하였다. 일단 목적은 private blockchain 을 염두에 둔것 같다.

다음은 이 Genesis 정보 기반으로 두 노드간에 실제적으로 통신을 해보자 (졸려졸려..)

반응형
블로그 이미지

Good Joon

IT Professionalist Since 1999

,
지난번에 빌드환경 구성이 일단 끝났고, 이번에는 실제로 Build 를 해보겠다.

Dependency 다운로드가 끝났다면 이제 본격적으로 Visual Studio 용 솔루션과 세부 프로젝트들을 CMake 를 통해 Generate 해야한다.
Command Line 에서도 빌드할 수 있지만 Visual Studio 의 Debug 를 통해 Logic 을 디버깅 해야하는 경우가 생기므로 Visual Studio 용 프로젝트를 생성해본다.

▌Visual Studio Project 생성

이제 본격적으로 Visual Studio 의 Project 를 생성한다. 
/d/ethereum/project/webthree-umbrella/build
위 디렉토리를 만들고 들어간 후
[goodjoon webthree-umbrella]$  cd build/
[goodjoon build]$  cmake -DEVMJIT=0 -G "Visual Studio 12 2013 Win64" ..
위와 같이 VS2013 용 Project 를 Generate 한다.

빌드 후 디렉토리는 아래와 같다


이제 생성 된 cpp-ethereum.sln 파일을 Visual Studio 로 열어본다.

▌EVMJIT

EVMJIT(Ethereum Virtual Machine Just In Time Compiler) 는 libethereum 의 서브모듈 이다.
위에서 cmake 시에 -DEVMJIT=0 을 해주었는데, 이렇게 해서 EVMJIT 모듈은 설치하지 않는다.

evmjit 모듈은 LLVM 라이브러리 3.7.0 이상의 Dependency 가 걸려있고, 현재 기준으로 3.7.1 이 최신버전이다.
지난번 extdep 에서 download 받은 라이브러리들 중에는 LLVM 도 포함되어있으며, Release 와 Debug 모드 모두 다운로드 받는다.

그런데 다운로드받은 이 LLVM 라이브러리 의 Debug 버전은 Visual Studio 로 Link 걸고 빌드할 때 _ITERATOR_DEBUG_LEVEL 이 0으로 정의되어있다는 오류가 발생하고, 현재 빌드하려는 프로젝트 (evmjit) 는 이 값이 2 이기 때문에 충돌이 난다고 하며 에러를 수백개 뱉어낸다.

extdeps 로 다운받은 라이브러리만 그런지는 모르겠지만, 일단 Build 환경이 다른것으로 보인다. 이러한 오류 없이 빌드하려면 LLVM 라이브러리를 소스로 가져와 Visual Studio 로 빌드하고 이 빌드된 라이브러리들을 evmjit 의 참조 프로젝트로 또는 linker 의 옵션으로 넣어주어야 할 것이다.

EVMJIT 는 Solidity 와 Serpent 의 Smart Contract Code 를 Console 이나 RPC 를 통해 Bytecode 로 런타임에 컴파일해주는 기능으로, mix 와 같은 툴이나 온라인 IDE 로도 충분히 그 기능을 대체할 수 있으므로 그냥 EVMJIT 모듈을 포함하지 않도록 하겠다.

1.0.0 Frontier Release C++ eth 의 EVMJIT 는 XCode 를 통해 Mac 에서 빌드하는데에는 문제가 없었으나 실제 동작해보면 이 또한 JIT 컴파일이 지원되지 않는 버그를 볼 수 있어서 궂이 빌드하지 않도록 하는 두번째 이유가 된다.

▌빌드 하기

솔루션 파일을 열어보면, 아래 처럼 BUILD_ALL 프로젝트가 StartUp Project 로 설정되어있다.

향후에 코드 분석에 필요하니 일단 Debug 모드를 Active 로 두고 ALL_BUILD 프로젝트를 Build 를 해본다.
(처음에는 File 들을 Parsing 하고 Indexing 하느라고 시간이 좀 걸린다. 빌드하는데에는 상관 없으므로 바로 빌드 해보자)

99개 에러와 353개 경고가 보인다.

▌에러 수정

위 에러의 이유는 모두 소스파일의 Characterset Encoding 때문에 생긴것이다. 

위 밑줄친것과 같은 UTF-8 특수캐릭터들이 PoC7 버전때 부터인가 지속 추가되어 화면에 이쁘게(?) 출력하기 위한 이상한 짓을 많해 해놓고있는데 이게 CP949 기반인 한글 Windows 와 No-BOM UTF-8 만을 자동인식하는 Visual Studio 2013 의 컴파일러가 환상적으로(?) 결합되어 빚어내는 문제이다.


에러가 발생한 소스파일을 에러를 더블클리해서 Open 한 다음

File > Advanced Save Options ... 에서 

  1. Unicode (UTF-8 with signature) - Codepage 65001 를 선택한다.
  2. OK 를 누른 후, ctrl+S 로 파일을 저장해준다

(반드시 with Signature 로 해야한다. Visual Studio 2013 은 (2015도 마찬가지) BOM 없는 UTF-8 을 자동인식하지 않으며, 이를 강제하는 옵션도 발견하지 못했다.
한글 Windows 의 경우 OS 의 기본 Characterset 인 CP949 를 기본 Characterset 으로 지정하여 파싱한다.)

BlockHeader.cpp
Block.cpp
BlockQueue.cpp
BlockChain.cpp
ClientBase.cpp
State.cpp
TransactionQueue.cpp

위 파일들을 Advanced Save Options.. 로 Encoding 을 수정해수고 저장한다.

그리고 다시 Build 를 한다.
(Warning 은 무시한다. 대부분이 Character Encoding 해석이 안된다는 경고이다.)

failed 프로젝트가 없다면 성공한 것이다.



▌동작 테스트

AlethZero 나 mix 는 좀더 수정할 것들이 있어서 향후에 해보도록 하고, 일단 가장 중요한 Ethereum 의 CLI 인 eth 가 작동하는지 확인해보자.

MinGW 로 Bash 를 열고, .bash_profile 에 
export ETH_HOME=/d/ethereum
export ETH_BUILD=/d/ethereum/project/webthree-umbrella/build
위와같이 ETH_HOME 과 ETH_BUILD 환경변수를 추가해주었다.
내가 내부적으로 사용하기 위해서 추가한것이고, 이후 블로그에서는 이 환경변수를 기반으로 설명할것이다.

$ETH_BUILD/webthree/eth
디렉토리가 eth 프로젝트 디렉토리이며, 그 밑의 Debug 디렉토리에 좀전에 빌드한 eth.exe 실행파일이 위치하고있다.

버전 확인을 해본다.
[goodjoon Debug]$  ./eth --version
eth version 1.1.3
eth network protocol version: 63
Client database version: 12041
Build: Windows/msvc/int/Debug
1.1.3 버전임을 알 수 있다. (C++ 팀 리더가 바뀌면서 요즘 바짝 긴장을 했는지, 나흘전에 또 1.1.4가 릴리즈 되었다)

보면, Network Protocol Version 이 63 인것을 볼 수 있다. Client 가 다르더라도 저 PV 는 같은 버전이어야 함을 상기해야한다.
Frontier 가 릴리즈된 1.0.0 버전은 PV61 이다. 지금은 PV61,62,63 클라이언트들이 Frontier 에도 섞여있다.

일단 Frontier 에 붙어서 동작하는걸 확인해보겠다. 이왕이면 Mining 도 ON 시켜서 동작시켜보자.
또한 CLI JS Console 로 들어가는 옵션도 함께 넣어보자.
[goodjoon Debug]$  ./eth --mining on console
(++)Ethereum
 !   21:21:18.012|main  void __cdecl dev::eth::Client::init(class dev::p2p::Host *,const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,enum dev::WithExisting,class boost::multiprecision::number<struct boost::multiprecision::backends::cpp_int_backend<256,256,0,0,void>,0>) 18794 ms

Please enter a MASTER password to protect your key store (make it strong!): Error initializing key manager: D:\ethereum\project\webthree-umbrella\libweb3core\libdevcore\CommonIO.cpp(145): Throw in function class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl dev::getPassword(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &)
Dynamic exception type: class boost::exception_detail::clone_impl<struct dev::ExternalFunctionFailure>
std::exception::what: Unknown exception

 !   21:21:19.011|main  Stop worker 962 ms
[goodjoon Debug]$
실행 하자마자 에러이다. 

일단 옵션을 설명하면,
--mining on : 마이닝 기능을 켠다는 이야기이다
console : Javascript Console 모드로 들어가라는 이야기이다

그런데 바로 뒤에 에러가 난다. Key Manager 를 초기화 하다가 에러가 나는데, 원래는 "Please enter a MASTER password to protect your key store ..." 하고나서 패스워드를 물어보게 되어있다.
그리고 이 Master Password 를 입력하고나면 그 다음단계로 진행하는데, MinGW 환경이나 CygWin 환경에서는 에러가 난다. 똑같은 커맨드를 쳐도 Windows Command Prompt 상에서는 이후에 잘 진행되는것을 확인할 수 있다. 문제는 KeyManager 모듈이 load() 될 때 발생되는데, 이건 나중에 수정되어야 할 부분이다.

이 Master Password 는 예전 PoC 8 버전에서도 도입되지 않다가 Frontier 릴리즈와 함께 도입되었는데, Wallet 의 Private Key 관리의 보안상 허점이 많이 있기 때문에 이 부분의 보안강화를 위해 생겨났다. ethkey.exe 를 통해 향후 좀더 상세한 관리를 할 수 있고, 예전처럼 무식하게 config.rlp 에 Private Key 와 Public Key 를 넣어두지 않는다는점에 주의해야 한다.

Master Password 는 까먹으면 끝장이다. Wallet 의 모든 Key 들을 관리하기 위한 Key Store 의 Master Password 이며, Private Key 를 사용하기 전에 이 Master Key 패스워드를 입력해야 한다.

현재 MinGW 에서 CLI 로 interaction 하는때에 오류가 생기므로, 옵션을 추가하여 아예 Master Password 를 지정해주면서 시작하자.
[goodjoon Debug]$  ./eth --mining on console --master 1111
(++)Ethereum
Ethereum (++) 1.1.3
  Code by Gav Wood et al, (c) 2013, 2014, 2015.
Transaction Signer: XE602H4XB00HUY08LU416SCBGO3CS63H66 (1a7e55b0-3eb7-05ec-248e-8d901e268d76 - 0096bb98)
Mining Beneficiary: XE602H4XB00HUY08LU416SCBGO3CS63H66 (1a7e55b0-3eb7-05ec-248e-8d901e268d76 - 0096bb98)
Foundation: XE55PXQKKK4B9BYPBGT1XCYW6R5ELFAT6EM (00000000-0000-0000-0000-000000000000 - de0b2956)
  i  21:41:11.885|p2p  UPnP device: http://192.168.0.1:4112/etc/linuxigd/gatedesc.xml [st: urn:schemas-upnp-org:device:InternetGatewayDevice:1 ]
 !   21:41:11.963|main  void __cdecl dev::p2p::Host::start(void) 2216 ms
Node ID: enode://2ee2a7e6a73b3af8aa737ce8bf016322828bdfdc5249d1ce4454f9e570a5b1486d988fd1119dacb18f50759de52c0728e4b4d229c01d5fdaa52fdd498ee81b57@211.222.99.182:30303
JSONRPC Admin Session Key: gsIJYPwuntU=
  i  21:41:12.450|<unknown>  Loading full DAG of seedhash: #00000000…

위와같이 --master 옵션을 주고 1111 로 패스워드를 지정해주니 잘 진행이 된다.

그리고 Mining 을 위해 DAG file 을 생성하게 된다. Dagger Hashimoto 파일이라고 불리는데, 1GB 정도 크기의 2차원 배열 데이터를 갖는 파일이다. Mining 시에 적은 ASIC 을 사용한 마이닝을 방지하고 GPU 연산을 더 효율적으로 하고, Light Client 의 Verification 성능향상 등을 위해 Hashing 시 필요한 대규모의 Cache 를 만들어놓는것이다. 자세한 이야기는 다음에 더 하도록 하고, 일단 1GB 의 용량이 최소한 필요하다는것을 상기하자.

DAG 테이블을 모두 만들어내는데에는 수십분 정도 소요되니 바람이나 좀 쐬고 와도 된다.

막간을 이용해 eth 가 사용하는 디렉토리들을 잠깐 설명해보면,

%APPDATA%/Local/ethash - DAG 파일이 위치한다
%APPDATA%/Roaming/Ethereum/config.rlp - Address 가 저장된 파일이다. eth 가 사용하며, 예전에는 Private Key, Public Key 가 들어있었으나 지금은 Key 메커니즘이 복잡해졌고, 이는 향후에 설명한다.
%APPDATA%/Roaming/Ethereum/keys.info, keys.info.salt - 실제적인 Key 가 들어있는 파일이다. AlethZero 와 eth 가 공용으로 사용한다.
%APPDATA%/Roaming/Ethereum/.web3 - Webthree 가 사용하는 Key 에 대한 정보가 들어있다.
%APPDATA%/Roaming/Ethereum/<4바이트HEX값> - state Trie, extra 데이터, block 데이터 등이 저장되는 Level DB 가 있다

이제 1GB 가량의 DAG 파일이 생성이 완료되면, Full DAG loaded 라고 뜬다.


그런데 또 문제가 있다.

console 이 안뜬다 (원래는 이쁘게 '>') 모양과 함께 web3 라고 치면 web3.js 의 JavaScript 개체들이 주욱 나와야 하나 아예 Console 자체가 동작하지 않는다.

이 또한 Windows 에서의 eth 버그이다. 사실 이후에도 eth 의 Windows 에 대한 외면은 매우 많고 다양하다. 
가장 잘 돌아가는 환경은 Mac 과 Ubuntu 이다. Windows 버전은 그냥 울며 겨자먹기로 써야하는 상황이다.
그도 그럴것이, eth 는 Front-End-User 용이 아니다. Back-End 용으로 분류하고있으며, 그래서 Linux 환경에 대해서는 매우 신경을 많이쓰는 느낌이다.


▌Console Attach 하기

Console 이 안된다고해서 실망할 필요는 없다. eth 는 attach 기능을 통해, 기존에 동작하는 eth 인스턴스에 console 을 attach 할 수 있다. 물론 2개의 Terminal 창이 필요하긴 하지만, console 을 쓸 수 있다는게 어디인가? 

일단, 현재 실행중인 Process 는 죽인다. Console 이 동작 안하니 ctrl+C 를 눌러 break 시켜버리자. ctrl+C 로 안되면 작업관리자를 열어서 강제 종료 시켜버려도 된다.

그리고, MinGW Bash Shell 을 2개 띄우고, 하나의 Shell 에서는
[goodjoon Debug]$ ./eth --json-rpc --json-admin 0000 --mode full --mining on --master 1111 --verbosity 5 console
로 실행한다. 여기서 추가된 옵션만 설명하면,

--json-rpc : JSON-RPC 인터페이스를 사용하겠다는 이야기이다. 외부 eth 를 attach 모드로 실행한 후 JavaScript Console 로 명령을 날리면, Console 이 이 JavaScript API 를 JSON-RPC 를 통해 대상 프로세스에게 요청하도록 되어있다.
--json-admin : 옵션에서 --help 를 치면 --admin 이라고 되어있는데, 이건 오타이다. 이런 옵션은 없으며, --json-admin 을 사용해야한다. (이게 언제쩍 버그인데 여태 수정을 안하고있다) JSON-RPC 를 사용하려면 Session Key 를 주어야 하는데, 원래는 eth 가 실행될 때 로그 초반에 Session Key 라는게 출력될 때 랜덤하게 생성된 그 키를 복사에서 attach 할 프로세스에 session key 로 지정해주어야 한다. 불편함을 줄이기 위해 아예 이 값을 --json-admin 옵션으로 주도록 했다.
--mode full : 기본값이긴 한데, Full Node 로 작동하게 할것인지, Peer Node (피어들의 정보만을 제공하는 노드)로 동작시킬것인지를 지정한 것이다
--verbosity 5 : Log 출력의 Verbosity 를 지정해준다. 0~99 까지 줄 수 있는데 5만 주어도 로그가 넘쳐난다.
기본값이 Frontier Network 으로 Bootstrap 하게 되어있으므로 --frontier 옵션을 쓰지는 않았다.

시간이 조금 지나면 Peer 간에 Hello 메시지를 주고받으며 PING/PONG 을 하다가 Block 을 Import 하여 Sync 하기 시작하고, Validation 작업을 수행한다.

이제 두번째 터미널을 열고, Console 을 Attach 해보자
[goodjoon Debug]$  ./eth --session-key 0000 attach
> 

--session-key 는 JSON-RPC 의 --json-admin 옵션으로 준 Key 값을 준것이고, attach 를 통해 기본적인 localhost:8545 포트의 JSON-RPC 로 연결하게 된다.

이제 잘 attach 가 되었는지 확인해보자
> web3.version
{
  api: '0.15.1',
  node: '++eth-v1.1.3-0//Debug-Windows/msvc/int',
  getNode: [Function],
  network: '',
  getNetwork: [Function],
  ethereum: '0x3f',
  getEthereum: [Function],
  whisper: Error: METHOD_NOT_FOUND: The method being requested is not available on this server,
  getWhisper: [Function]
}
>
node: 는 Client 의 Node 식별을 위한 Full Name 이며, 별도의 옵션을 주지 않았으므로 ++eth-v1.1.3-0//Debug-Windows/msvc/int 와 같이 나온다
ethereum: 은 eth 프로토콜 버전이며 10진수로 변환하면 63 이 된다

> web3.eth.coinbase
'0x0096bb9802b14f72ba4cdbd105127fe57a1dafae'> web3.eth.blockNumber
24840
> web3.eth.getBlock('latest')
{
  transactions: [],
 receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',
  hash'0xc88b3957581f72a2aa1f5e5bcad12898d1117ba492adc88398bdd4b2a6275b7c',
  seedHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
  miner: '0x3f98e477a361f777da14611a7e419a75fd238b6b',
  uncles: [],
  extraData: '0x476574682f76312e302e302f6c696e75782f676f312e342e32',
  gasLimit: 5000, 
 transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',

  gasUsed: 0,
  size: 0,

  logsBloom: '0x000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000',
  totalDifficulty: 16505476021090676',
  number: 25657,
  parentHash: '
0xcb29677c43d3877bc401b578a64e2de7c7839a5080163b2bf3194b5fa5bdcc29',
  boundary: '
0x0000000000fa64ef32fc5b94d0c88ff91d9f142f5459c015652cd4e44bb3bc27',
  author: '
0x3f98e477a361f777da14611a7e419a75fd238b6b',
  stateRoot: '
0x429dd84e5a8e30f31a4442b7a0bc7aae79f459751ffcc57d2a2d6f699a38e532',
  difficulty: 1124127046574'
,
  nonce: '0xa8f99a70ac8ec05e',
  timestamp: 1438579639,
  mixHash: '0xf42a0dd21ec4fce0c20b21af14b661f6d43babc3c5bc215f1652a77f3fdc877b',
  sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347'
}
>

자신의 coinbase 와 가장 마지막 block 의 정보를 출력해봤다. 모두 의미있는 값이 나온다면 정상동작중인 것이다.

다음 부터는 Ethereum 의 사상에 대해서 조금씩 이야기를 정리해보기로 하겠다.
음.. 그전에 Blockchain 에 대한 기술적인 정리도 조금 할까..? 생각 중이다. 1.0  의 기술적인 개념부터 이해를 해야 Ethereum 의 개념도 이해가 갈테니 말이다.

그럼 오늘은 또 이만~


반응형
블로그 이미지

Good Joon

IT Professionalist Since 1999

,

IBM 이 주도하고 있는 Linux Foundation 의 Collaborative Project 인 Hyperledger 프로젝트 발표 후 Github 에 업데이트가 없다가. 조금전인 2016.02.17 오전 11시 경에 README.md 의 업데이트가 있었다.

현재 시점에서 이 HyperLedger TSC(Technical Steering Commitee)는 광범위한 유스케이스와 Value Add 된 솔루션을 올릴 수 있는 블록체인 플랫폼을 지향하고있다.

이 Project 에는 4가지 종류의 Contribution Proposal 이 올라왔다. 아래 제안들은 아직 결정된것이 아니며, TSC 가 열심히 검토해서 결정하겠다고 한다. (그러나 아마도 답은 이미 나와있는상태에서 시작하는 게임 아닐까 싶기도 하다. IBM이 아니겠는가? 아니면 DAH ..? 아니면 적절한 사상들 간의 종합적인 산출물이 나올 수 있을듯 한데..)


Ripple Proposed Contribution

Rippled 는 OSS 로, C++ 로 구현된 2012년 부터 작동중인 Public Blockchain 이며, Cross-Currency 지불을 가능케 하는 플랫폼이다. 주문장(Order Books) 기반으로 이루어지는 빠른 Transaction 과 복잡한 구현을 단순화 하는데에 초점이 맞추어져있다.

분산 원장(Distributed Ledger)기술로 NuDB 라는 고성능의 Key/Value 기반의 DB 를 포함하고 있다. 수 테라바이트의 데이터셋을 최소함의 RAM 소모로 핸들링 하기에 최적화 되어있다. SSD 와 같은 고성능의 I/O 가 필요하다.

https://github.com/ripple/rippled

IBM Proposed Contribution

IBM 은 Open Blockchain (OBC) 라는 이름으로 프로젝트를 하겠다고 발표한바 있고, 2월15일에 0.1.0을 릴리즈 하였다. License 는 Apache 기반으로 진행중이며, Hyper Ledger 프로젝트에 Contribute 하기 위해 오픈소스화 하였다고 한다. 정식으로 Hyper Ledger 프로젝트로 채택되면 IBM 은 이후 Hyperledger 에 집중하고, 아래 Repository 는 IBM 내부적인 필요성에 의해 관리한다고 한다. 언어는 Go 로 개발되어있다.

Open Blockchain 은 여러 산업에서 사용할 수 있게하기위한 목적의 저수준의 Fabric Code 이다. 핵심은 Smart Contract, Digital Assets, Record Repositoroes, Decentralized Network Providing Consensus, Cryptographic Security 이다.

https://github.com/openblockchain


Digital Asset Holdings Proposed Contribution

DAH 의 후보군은 기업을 위한 Blockchain Server 형태로, Client API 를 포함한다. 이 프로젝트도 Hyper Ledger 프로젝트 채택을 위한 목적으로 공개 된 프로젝트이다. 모듈화된 아키텍쳐와 설정 가능한 네트워크 구조는 금융권에 적합한 구조를 위해 설계되었다고 한다. 데이터 백본의 컨셉을 Multi-Organization 레벨로 확장한 것이다. 라이선스는 Apache 라이선이다.

금융권용 답게 Java 기반으로 구현되어있다. 골드만삭스를 비롯 각종 금융권들로 부터 많은 긍정적인 반응과 투자를 받은 회사로 상당히 유력한 후보군이라 볼 수 있다.

https://github.com/DigitalAssetCom/hlp-candidate


Blockstream Proposed Contribution

좀 됐긴 했지만 Elements 라는 이름의 Blockchain OSS 도 있다. Bitcoin 을 확장한 개념으로, Confidential Transactions, Segregated Wirness, Relative Lock Time 등등의 확장 개념이 들어가있다. Bitcoin testnet 과의 Pegging 도 가능하다.

https://github.com/ElementsProject/elements


앞으로 이 4개 Proposal 중에 어떤게 정식으로 Hyper Ledger 의 Codebase 또는 사상으로 채택될지는 모르겠으나 내생각에는 IBM 이 가장 유력하지 않는가 싶다. 애초에 TSC 가 보고있는 관점도 "산업 전반에 걸친" 블록체인 플랫폼이므로 (왠지 IBM 이 만들어낸 기준 스러워도 보이지만) 금융권에서 신뢰받고있는 DAH 의 codebase 또한 무시못할 것으로 보인다.

Hyper Ledger 가 아니더라도, DAH 의 Blockchain 소스가(물론 일부이고 Hyper Ledger 프로젝트 채택 목적이겠지만) 공개되어 올라온것 만으로도 특히 국내 금융권에게는 희소식이 아닐까 싶다.


반응형
블로그 이미지

Good Joon

IT Professionalist Since 1999

,
불과 며칠 전에 1.1.3 버전이 Release 되었다. 1.1.2 부터 PV62(Protocol Version 62) 와 PV63 을 지원 중이며, 1.1.2 대비 eth Console 과 AlethOne 크래쉬 버그픽스가 있었다. 이 1.1.3 Release Branch 로 빌드 해보기로 한다.

Mac OS X 에서는 그나마 빌드 및 실행이 잘되는 편인데, Windows 빌드는 예전 버전들 부터 잘 되지 않는 편이다. 빌드는 되더라도 기능에 버그가 있거나 하는 경우가 많다.

▌준비할 것

빌드하기 전에 우선 아래 준비사항이 모두 준비되었는지 확인하자.

  1. Windows 7 또는 8 64비트 (32 비트 버전과 Windows 10 은 지원하지 않음)
  2. Git for Windows 1.9.0 이상
  3. 7-Zip 
  4. CMake 3.0 이상
  5. Windows 7 또는 8 SDK 
  6. Visual Studio 2013 Community Edition (Update 5 를 별도로 받아 Build 넘버 12.0.40629.00 이 되도록 한다)
    Visual Studio 2015 는 아직 지원 안함

▌환경 설치

▪ Git 설치

Git 사이트 에서 Git for Windows 다운로드 받고, Git Bash Shell 을 설치하도록 한다.


설치하면 Git Bash 로 실행 되는지 정도는 확인하자.



▪ 7zip 설치

7zip 사이트 에서 최신 exe 버전을 다운로드 한다.


다운로드 받은 exe 파일을 실행하여 원하는 Directory 에 설치한다


그리고 반드시 설치한 디렉토리를 PATH 에 추가해 주어야 한다


위처럼 System 의 PATH 환경변수에 7zip 설치된 경로를 추가 해 주었다.

▪ CMake 설치

CMake 사이트 에서 Latest Release 에서 Installer 버전을 다운로드 받아서 설치한다.


PATH 에 CMake 를 자동 추가하도록 설치 시 옵션을 선택한다.



▪ Windows SDK 설치

Windows SDK 사이트 (7 또는 8.1) 에서 SDK 를 다운로 받아 설치한다.


▪ Visual Studio 2013 Community

Visual Studio 2013 Community 사이트 에서 Installer 를 다운로드 받고 설치한다. 시간이 꽤 걸린다.



위 처럼 Update 5 를 설치하고 있는지 확인한다.

이제 소스를 Checkout 하고 빌드를 해보도록 하자

▌소스 Clone

Git Bash 를 통해 MinGW 의 Bash Shell 로 들어간다.

우선 디렉토리를 아래와 같이 만들었고, project 밑으로 프로젝트를 clone 할 예정이다.
[goodjoon project]$  pwd
/d/ethereum/project
[goodjoon project]$

git 으로 Repository 를 Clone 한다. Submodule 들이 다수 걸려있으므로, submodule 들도 --recursive 옵션으로 모두 가져온다.
[goodjoon project]$
brella.gitproject]$  git clone --recursive https://github.com/ethereum/webthree-umbrella
Cloning into 'webthree-umbrella'...
remote: Counting objects: 71041, done.
remote: Compressing objects: 100% (2/2), done.
Receiving objects:  56% (40071/71041), 16.92 MiB | 2.96 MiB/s

webthree-umbrella 가 clone 되었고, 
[goodjoon project]$  ls -al
total 8
drwxr-xr-x 1 korean44 없음 0 Feb 14 23:16 ./
drwxr-xr-x 1 korean44 없음 0 Feb 14 23:04 ../
drwxr-xr-x 1 korean44 없음 0 Feb 14 23:16 webthree-umbrella/
[goodjoon project]$

webthree-umbrella 해서 git status 를 해보면
[goodjoon webthree-umbrella]$  git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
nothing to commit, working directory clean
[goodjoon webthree-umbrella]$
확인해보면, 위 처럼 develop Branch 에 HEAD 가 있음을 알 수 있다. 그래서, Release 브랜치로 다시 checkout 을 해야한다.

[goodjoon webthree-umbrella]$  git checkout release
M       webthree-helpers
Branch release set up to track remote branch release from origin.
Switched to a new branch 'release'
[goodjoon webthree-umbrella]$  git status
On branch release
Your branch is up-to-date with 'origin/release'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   webthree-helpers (new commits)

no changes added to commit (use "git add" and/or "git commit -a")
[goodjoon webthree-umbrella]$

release Branch 로 checkout 을 하고 status 를 보면, submodule 이 실제로 update 가 안되었기 때문에 modified 된것처럼 나온다. 
Submodule 들도 Update 해주자
[goodjoon webthree-umbrella]$  git submodule update --recursive
Submodule path 'webthree-helpers': checked out '4932539374f9b9ea1030b4514c5292620d55f3c0'
[goodjoon webthree-umbrella]$  git status
On branch release
Your branch is up-to-date with 'origin/release'.
nothing to commit, working directory clean
[goodjoon webthree-umbrella]$

불과 사흘전에 Release 를 해서 그런지 Submodule 들이 대부분 최신 Branch 여서 webthree-helpers 브랜치만 Update 되었다.

▌Dependency 다운로드

Windows 에서 빌드를 하기 위해서는 llvm 및 Qt 을 비롯해 아래와 같은 라이브러리들이 필요하다
boost 1.55.0
cryptopp 5.6.2
curl 7.4.2
jsoncpp 1.6.2
json-rpc-cpp 0.5.0
leveldb 1.2
llvm 3.7.0
microhttpd 0.9.2
OpenCL_ICD 1
qt 5.4.1
miniupnpc 1.9
v8 3.15.9

apt 나 brew, port 가 없는 Windows 에서 일일이 라이브러리를 다운로드 받아 설치하기란 매우 번거로운 일이기때문에 C++DEV 팀에서 간단한 배치를 하나 제공한다.
/d/ethereum/project/webthree-umbrella/webthree-helpers/extdep
위 경로로 가보면 getstuff.bat 파일이 있는데, 이 파일을 실행시키면 모든 dependency 라이브러리들을 다운로드 받는다

[goodjoon extdep]$  ./getstuff.bat
한참동안을 뭔가 잘못된 것 처럼 가만히 있는다. 라이브러리를 하나씩 다운로드 받고 압축 풀고를 반복한다. 4.4GB 를 다운받고 압축 푸느라 수십분 정도 작업이 길어질 수 있으므로 TV나 좀 보다오자.
인터넷 연결만 잘 되어있다면 안될 이유는 없을것이다.

오늘은 너무 졸려서 이만..^^;;
다음은 본격적인 소스 빌드와 오류 해결로 넘어가보겠다.


반응형
블로그 이미지

Good Joon

IT Professionalist Since 1999

,
 Ethereum 의 Github 를 가보면 매우 많은 프로젝트들이 Repository 에 올라와 있는게 보이고, 매우 복잡하게 느껴진다.

 그러나 업데이트 안하고 있는 프로젝트나 다른 프로젝트의 Sub Module 들이 많이 섞여있는 상태이므로 자꾸 왔다갔다 하다보면 별로 복잡하게 느껴지지 않는다.

주요 프로젝트들에 대해서 간단히 설명해본다.

yellowpaper

The "Yellow Paper": Ethereum's formal specification

Vitalik Buterin 이 White Paper 를 쓰고있고, Ethereum 의 사상의 기술적인 Spec 이라고 할 수 있는 Yellow Paper 를 Gavin Wood 가 쓴다. 이 Yellow Paper 는 얼핏 보면 수학공식 같아 보이지만, 말로 표현할때의 해석의 모호성을 줄이기 위해 수학적인 기호를 차용한 정도이다. 복잡한 수식은 없으며 대부분 집합 기호를 통해 개념을 설명한다.

Ethereum 의 중요 개념인 Block, State/State Transition, Transaction, Gas, Contract 등에 대한 동작 방식을 정의해놓았다. Ethereum 내부의 개발자들은 이 Yellow Paper 를 보고 구현한다고는 하지만 사실 이 내용만 보고 그들의 사상을 구현하기에는 부족한 부분들이 매우 많다. 통신, 마이닝, 로직의 흐름 등은 설명되어 있지 않으므로 설계서 보다는 핵심 사상의 정의 수준이라고 해야 하겠다.

go-ethereum

Official golang implementation of the Ethereum protocol

나도 2014년 말 Ethereum 을 접하면서 Go 언어라는것을 처음 알게 되었다. Go 언어는 Chrome 의 V8 엔진 개발에 참여하고 Java Hotspot 컴파일러를 개발한 Robert Griesmer, UTF-8 과 분산 운영체제를 개발한 Rob Pike, UNIX 의 창시자라 불리는 Ken Thompson, 프로그래밍 천재라는 Russ Cox 등의 천재들이 만들어낸 매우 간결하지만 강력한, Google 이 만들어낸 걸작의 언어이다. Ethereum 의 공식 구현체 중 가장 빠르게 버전업이 되는 구현체이며, DApp 클라이언트 플랫폼으로 Go Ethereum (Geth) 를 공식화 하고있다. 코드도 매우 깔끔한 편이다.

webthree-umbrella

The umbrella project for all of C++ Web Three implementation

작년까지만 해도 C++ Ethereum 으로 불리우던 cpp-ethereum 프로젝트가 있었는데, 이 프로젝트가 webthree-umbrella 라는 이름으로 바뀌었고 git repository 구조도 바뀌게 되었다. Ethereum 의 공식 구현체이며 Repository 내 많은 submodule 들이 이 프로젝트에 dependecy 로 참조되고 있다. 나도 비록 근래에는 Java 기반의 Enterprise S/W Architect 를 했지만 2000년 부터 7년 간을 C++ 을 했었기에 주로 이녀석을 분석했었는데, 처음 코드를 보면서 "이게 뭔 C++ 이야?" 라는 생각이 들었는데, boost 라이브러리들을 많이 사용하고, C++ '11 스펙을 사용하는 관계로 C++ 98 스펙에 익숙했던 나에게는 해석에 참 많은 시간이 필요로 하게 하였다. Gavin Wood 의 해커끼(?) 보이는 코드의 복잡함들도 더러 보이며 TrieDB 쪽은 특히 Template Class를 꼬아서 쓰기때문에 해석 중에 컨텍스트를 잃어버리는 경우도 생겼다. 버그도 많은편이고 코드 복잡성은 Top 수준이다. Ethereum 은 C++ Ethereum 을 Backend 용으로 적합하고 Go 보다는 좀더 나은 성능을 원하는 경우에 사용할것을 권고한다. 비교적 자주 업데이트 되는 편이지만 작년 기준으로는 Go 대비 한발 늦는 개발 진행 때문에 Geth 와 함께 코드를 보는 경우도 있었다.

pyethapp

 forked from heikoheiko/pyethapp

이름에서 보이듯이 Python 기반의 프로젝트이다. Ethereum 은 Pyethapp 은 "학습" 목적으로 단정짓는다. (사실 작년 Frontier 발표 전에는 그런 말도 안보이더니..) 성능과 기능 보다는 Ethereum 의 동작 원리를 이해하고 분석하는데에 사용할것을 권고하고 있다. Python 은 언어도 쉬운편이니 Ethereum 의 핵심 메커니즘 맛보기 수준 정도를 원한다면 이녀석으로 시작해보는것도 괜챦을 듯 하다. 상세한 코드 주석이 세심한 배려심을 드러내고있다.

Java implementation of the Ethereum yellowpaper

작년에 파일럿 시스템을 만들 때 codebase 로 활용했던 녀석이다. 지금와서 보면 참 후회스러운 선택이었지만 일단 작년 5~6월 정도에는 매우 Simple 한 코드와 Java 의 간결성 때문에 이녀석을 선택했었다. 그러나 C++ ETH (eth) 와 Geth 대비 확연히 떨어지는 구현도를 보였으며, 심지어 Miner 는 불과 며칠 전에 Homstead Prerelease 버전인 1.1.0 버전에서야 추가 되었다. 공식 구현체가 아니므로 너무 큰 기대는 하지 않는게 상책이지만 요즘은 어떤지 확인이 한번 필요하기도 하다.

alethzero

The AlethZero Hardcore Ethereum Client

C++ Team 이 개발하고 있는 일종의 Debug 툴이다. eth 를 테스트하기에 충분한 기능들이 들어가있고, Qt 기반의 GUI 로 Tx 을 날리거나 Block, Peer, Node, Tx, Contract Code 실행, Mining 상태 등을 보여준다. C++ 팀의 주력 개발 Client 라 보면 된다. 단 Mist 와 같은 DApp Client 가 아니고, eth 의 동작을 테스트하는 목적으로 보면 되는 클라이언트이다. 

mix

The Mix Ethereum Dapp Development Tool

Mix 는 공식적인 Ethereum 의 DApp 개발도구이다. HTML/CSS/JavaScript 기반으로 DApp 을 만들고, Smart Contract 를 개발할 수 있도록 되어있다. Contract Code 를 개발하고 컴파일하고 검증할 때 사용하면 좋으며, 아래 Mist 에서 실행되는 DApp 은 Mix 로 개발하는게 순서상 맞다.

mist

Mist browser

Mist 는 Go 언어로 Go 개발팀이 만들고 있는 일반 End-User 용 Ethereum Client 이다. DApp 을 구동하는 플랫폼이며, Browser 와 유사한(내부적으로 Web View 를 갖는) 클라이언트이다. 웹 엔진과 Geth 가 통합된 형태라고 보면 되며, 향후 Light Weight Client 는 이 mist 형태로 일반 유저에게 배포될 것이다.

solidity

The Solidity Contract-Oriented Programming Language

Solidity, Serpent, LLL 은 Smart Contract 를 기술하는 언어이다. Solidity 는 C++ 팀이 개발하고 있으며, 현재 가장 잘 만들어진 Smart Contract 구현 언어이다. solc 로 Solidity 코드를 컴파일 하면 EVM Code 가 생성되도록 되어있으며, 요즘은 예제들도 상당히 많이 돌아다니므로 배우기가 더 쉬워졌다. 문법은 JavaScript 와 유사하여 러닝커브도 짧은 편이다.

Serpent 도 Smart Contract 기술 언어중에 하나이다. 문법이 Python 매우 유사하다. Solidity 다음으로 많이 사용되나 요즘은 Ethereum 에서도 Solidity 를 많이 밀고있는 상황이라 상대적으로 Serpent 는 약간 뒤쳐지는 느낌이다.

이외에 LLL 과 Mutan 이 있었는데 LLL 은 Low-Level 언어이며 현재는 더이상 발전시키지 않고있는 언어이다. Mutan 은 훨씬 이전부터 지원하지 않고있다. LLL 은 현재도 사용할 수는 있다. OP Code 의 래퍼 정도로 매우 저수준이기 때문에 간단히 코드 짜서 테스트해보고 디버깅 할때에는 LLL 을 사용할 수도 있다.

web3.js

Ethereum Compatible JavaScript API

Ethereum 의 JavaScript API 이다. 내부적으로는 JSON RPC 를 통해 eth / geth 와 통신한다. Geth/Eth 의 Javascript Console 이나 브라우져, Node.js runtime 에서 사용할 수 있는 API 이다. 특히 이 web3.js 의 spec 을 자주 보게 될것인데, ethereum 의 console 의 명령이 frontier 이전 버전은 Command 방식으로 사용하다가, 아예 Command 는 지양하도록 하며 Console 에서 모든 명령은 이 web3 JavaScript API 를 사용하도록 했기 때문이다.

diary

The Ethereum Developer logs

바로 어제 부터 글이 올라오기 시작한다. 개발일지같은 형태로 올라오는데, 급 외부 사람들과의 Communication 에 신경을 쓰고있다. 신임 C++ Team Leader 인 Christian Reitweissner 의 글을 봐도 커뮤니케이션 열심 하겠다고 하는걸로 봐서 내부적으로 뭔가 일이 있었나보다. 앞으로 자주 들러보게 될 것 같다.

wiki

The Ethereum Wiki -

Ethereum 의 기술적인 부분들은 이제 이 Wiki 로 통합되었다. 이전에는 ethereum/ethereum 프로젝트(리파지토리)에 가이드를 올렸는데, 이제는 ethereum/wiki 프로젝트로 옮겨갔다. 좀더 정리되는것 같은 느낌이 나지만 아직도 각 프로젝트 별 문서는 자체 리파지토리 내의 Wiki 를 사용하는 등 산만함이 완전히 가시지는 않았다.


위와 같이 주요 리파지토리(프로젝트) 들에 대해 알아보았다. 앞으로 블로그에서 저 프로젝트들이 종종 언급될 듯 한데 한번쯤 들어가서 Readme.md 파일이라도 읽어보는게 좋겠다는 생각이다.




반응형
블로그 이미지

Good Joon

IT Professionalist Since 1999

,
 2014년 하반기, Decentralized Computing 에 대한 관심과 Autonomous IoT Device 의 자율적인 협업을 위한 방안을 연구하던 중 당시 비트코인의 핵심 기술로 적용된 Blockchain 기술을 접하게 되었고, 특히 Blockchain 의 Consensus 메커니즘이 디바이스 간 자율적인 협업을 위한 핵심 메커니즘으로 작용할 수 있다는 생각으로 2014년 말 부터 Blockchain 기술을 더 깊이 연구해보게 되었다. IBM 의 ADEPT 컨셉도 이쯔음에 발표되었고 ("Device Democracy 라는 주제로") 마침 유사한 고민을 하던 중 글로벌 기업도 이러한 노력을 하고있다는 데에서 더 신이 나기도 했다.

 2015년 3월 부터는 비트코인에서 사용중인 원시적인 Blockchain 기술을 1.0으로 기준화 하고 Blockchain 2.0 이라 불리우던 Ethereum 을 집중적으로 연구하였고, PoC8 버전을 달리던 C++, Go Ethereum 을 분석하여 당시 매우 덜 구현되어있던 EthereumJ (Java) 를 CodeBase 로 하여 해석된 메커니즘을 Java 로 추가 구현 하였다.

 애초 Ethereum 의 Smart Contract 개념을 가장 중요시하게 보고 있었던터라 약 3개월 뒤에 Solidity 기반의 간단한 Smart Contract Code 를 개발하고, EthereumJ 에 Mining 기능 및 각종 Validation, Networking 을 추가하여 진본 증명 파일럿 시스템을 개발해보았다. 요즘 말하는 Private Blockchain 까지는 아니지만 Local Blockchain 을 구성하여 자체적인 Blockchain 서비스를 시험개발해 본 것이다.

 2016년에 들어서자 한국은행 총장의 신년사에서도 Blockchain이 언급될 만큼, 금융권은 Nasdaq 과 R3CEV 등의 사례를 보며 핀테크를 넘어선 글로벌 미래 금융기술을 준비하는데에 Blockchain 기술을 매우 중요한 요소로 생각하고, 기술을 응용한 비즈니스모델을 만들고자 노력중인것으로 보인다.

 역시나 발빠른 스타트업들은 이러한 금융사로 부터 펀딩을 받기 위해 노력중이나, 사실 기술 보다는 화술로 어필하고 있는 회사들도 다수 보인다. 또한 대부분 인프라가 잘 갖추어지고(많은 Client, Miner, Exchange, Full Blockchain Node) 성숙한 오픈소스 기반의 기술들이 많은 비트코인 네트워크를 사용한 Public Blockchain 으로 Transaction 을 발생 시키고 Overlay 하는 정도의 기술을 갖고있다.

 작년 중반 까지도 블럭체인 기술을 하는 대부분의 스타트업들은 비트코인과 같은 "가치화폐 창조" 라는 꿈을 갖고 시장에 뛰어들고있었다. 비트코인 네트워크에 Colored Coin 형태의 신규 토큰을 발행하거나 Alt Coin 을 만들어내고, 이 Coin 이 시장에서 가치를 인정받는 순간 "최초 발행한 발행량 x 가치평가금액" 이 그 즉시 실제 돈이 될 수 있는 "일확천금"의 기회가 생기기 때문이다. 그래서 대부분 "Coin Exchange" + "Colored Coin"/"Alt Coin" 기술에 주력을 하고 있었고 사실 지금도 상황은 마찬가지이다.

 그러나 작년 말 부터 금융권을 중심으로하여 불어오는 Consorthium Blockchain, Private Blockchain 의 필요성은, 이해와 응용 비즈니스 모델을 만들어내기 힘든 블럭체인 기술에 대해 그나마 약간 알고 있는 스타트업을 만나고 있으며, 스타트업 기업들은 이 기회를 활용하여 향후 자신들의 이상을 실현하기 위한 스폰서를 찾기 위해 많은 구애활동을 하고 있다.

 불과 지난 1월 20일, 42개 은행의 컨소시엄 회사인 R3CEV 가 Customize 한 Ethereum 으로 11개 은행을 대상으로 PoC 를 수행했다는 기사가 나왔다. IBM 은 2014년, ADEPT 컨셉을 발표할 때에도 Blockchain 기술 기반은 Ethereum 으로 못박고, Resource Sharing 은 Bit Torrent, Messaging 은 Telehash 를 조합하겠다고 발표한 바 있다. R3CEV 의 실제적인 기술진의 핵심은 IBM 의 이전 executive Architect 였던 Richard Gendal Brown 이고, Ethereum 으로 테스트해본것은 어찌보면 당연한듯 해보인다.

 블로그를 통해 Ethereum 을 기반으로 다양한 사상과 원리, 응용방법을 공유하고 그 외 Private / Consorthium Blockchain OSS 구현체들에 대해서도 이야기 해보도록 하겠다.



반응형
블로그 이미지

Good Joon

IT Professionalist Since 1999

,