[블록체인] Besu : Quorum Developer Quickstart

Private Network Example - Hyperledger Besu

Hyperledger Besu는 Quorum Developer Quickstart라는 초보용 프로그램을 제공한다. 해당 프로그램을 실행하면, Hyperledger Besu의 도커 이미지를 컨테이너로 빌드하고, 폐쇄형 네트워크(private network)의 기반을 시뮬레이션하기 위한 4개의 validator와 1개의 non-validator가 생성된다. 이때 non-validator는 RPC를 가능하게 해주는 노드이다. 기타 다양한 플러그인을 포함해 Docker Compose 파일도 세팅이 되어있다. 

 

그냥 '이런게 있구나'하고 넘어가서는 안된다! 해당 프로그램은 폐쇄형(private) 블록체인을 어떠한 과정을 통해서 구성할 수 있는지 알아보자.

 

 

1. docker-compose.yml

Prerequisites를 모두 설치하고 run이 끝나고 나면, 지정한 폴더에 위와 같이 설치가 된다. 그 중 가장 먼저 볼 것은 'docker-compose.yml'이다. 앞서 말했듯이 Quorum Developer Quickstart는 Hyperledger Besu와 여러 플러그인의 도커 이미지를 가져와 컨테이너로 빌드해주는 프로그램이다. 그리고 이 여러 개의 컨테이너의 옵션들을 모두 설정하여 순서대로 실행시켜주는 것이 '도커 컴포즈(Docker Compose)'이다. 그말은 즉, 어떤 옵션으로 컨테이너들을 실행시켰는지 도커 컴포즈를 보면 모두 알 수 있다는 것이다. 

 

vi 에디터로 docker-compose.yml을 열어보면 가장 첫줄에는 yml 파일 포맷의 버전이 적혀있다. 그 아래로 x-besu-로 시작하는 이것 저것 보이지만, Page Down을 눌러 "services: "가 적힌 곳을 찾아 먼저 보자. 여기서 service는 Docker에 올릴 각각의 컨테이너를 의미한다. 

 

Quorum Developer Quickstart는 테스트를 위해 총 4개의 validator와 1개의 non-validator를 생성한다. environment에서는 서비스의 이름과 Hyperledger Besu의 버전을 정의하고 있다. 처음 도커로 run할 때, 옵션으로 넣은 값인 'latest'가  service.version의 값으로 들어가 있는 것을 확인할 수 있다. 아래 volumes 항목들을 보니 "원래 로컬로 깔려있었다면 (':'기준으로) 오른쪽에 있는 주소에서 찾아야 할 것들은 왼쪽 주소에 있다"라고 이야기하는 듯하다.

 

volumes의 항목들을 보니 아래 항목들을 참조하는 듯하다. config, genesis 등의 단어가 들어가는 것을 보니 구성 파일(configuration fille, 프로그램의 매개 변수 및 초기 설정을 구성하는 데 사용되는 파일)인 듯하다. 아래 파일들은 조금 이따가 찬찬히 살펴보도록 하자.

• config.toml
• permissions_config.toml
• static-nodes.json
• log-config.xml
• log-config.splunk.xml
• genesis.json

volume 다음에 network에는 ipv4_address에 해당 컨테이너에 할당 될 IP 주소가 172.16.239.11있다. 그러고 보니 도커에서는 어떻게 IP가 할당 되고, 어떤 구조로 돌아가는 건지 궁금해졌다.

 

도커의 각 컨테이너는 가상 이더넷 어댑터(veth, virtual ethernet를 갖는다. 만약 나와 같은 옵션을 선택했다면, docker ps -a로 봤을 때, 총 15개의 컨테이너가 실행되고 있을 것이다. 이 veth들이 docker0에 바로 연결되는 구조라 생각했는데, docker-compose로 묶여 있어서인지(확실하지 않다) bridge를 하나 더 거치는 구조로 되어 있다. 

 

아무튼 docker-compose.yml 에서 해당 서비스(컨테이너)에 어떤 IP를 줄지 정의하고 있고, Validator1에 실제 할당 되었는지는 docker inspect [Validator1의 컨테이너 ID]를 입력해 "NetworkSettings" 값을 확인해보면 된다. 결국, docker-compose.yml 파일은 광범위하게 여러 값들을 설정해 원하는 방향으로 컨테이너들이 실행될 수 있도록 해주는 파일이었다. 그리고 그중에서 어떤 설정들은 구성 파일로 따로 정의되어있었다. 구성 파일들을 하나씩 보도록 하자.

 

 

2. configuration files

먼저 /config/besu/config.toml의 항목들을 간단하게 정리했다.

항 목	설 명
rpc	rpc 기능에 관한 설정 초가값
ws	잘 모르겠음
graphql	graphql(API 관리) 설정 초기값
metrics	모니터링 목적의 통계 수집 설정 초기값
permission	private network이기 때문에, 네트워크 가입 허용 대상 정의
bootnodes	어떤 노드가 부트노드인지 enode url로 설정
static nodes	동적으로 새로 가입하지 않은 미리 정의된 노드

bootnode, enode url 등의 단어가 낯설었다. 

먼저 bootnode는 간단히 이야기하면 특정 이더리움 네트웍에 참여하고자 하는 노드들을 서로 연결시켜 주는 프로그램이다. 예를 들어 아래 그림의 node4가 bootnode에 붙으면 bootnode는 현재 붙어 있는 노드 정보(node1...node3)를 node4에 알려 준다. node4는 이 정보에 바탕해서 다른 노드들과 통신하며 p2p 망을 이룬다. 그리고 node4는 수시로 bootnode에 붙어 이 정보를 갱신 받는다.

http://blockchaindev.kr/models/content/92

그리고 이 bootnode를 configure.toml에서는 "enode://..."로 시작하는 url 주소로 알렸다. 이것은 이더리움 노드의 주소를 표기하는 하나의 체계인데, "enode://[공개키]@[노드의 IP]:[듣고있는 포트]"의 형식을 가지고 있다. docker inspect로 IP 주소를 알 수 있고, docker ps -a로 열려 듣고 있는 포트 번호도 파악할 수 있다. 위의 표에서 permission 항목은, permission_config.toml를 참조하고 있는데, 이것을 vi 에디터로 열어보면 현재 올려져있는 모든 노드의 주소도 enode url 형태로 적혀있을 것이다.

https://eth.wiki/fundamentals/enode-url-format

 

enode url에 공개키라는 단어가 나온다. 학부 수업 때 잠깐 들었던 기억은 나지만, 자세히 기억나지 않을 뿐더러 이게 왜 필요한지 찾아봤다. 설명이 너무 잘 되어 있어, 아래 글을 참고하면 좋을 듯 하다. 나머지 목록에 있는 파일들도 하나하나 열어보면서 어떤 값들이 적혀있는지 찾아봤다.

[Mastering Ethereum] 3장 키와 주소 — Steemit

 

 

3. genesis.json

자 그럼 여기까지 순서를 생각해보자. docker-compose.yml 을 보며, 도커 컴포즈가 옵션에 맞게 컨테이너를 실행시키기 시작한다. 먼저 bootnode인 validator1이 먼저 올라온다. 그 다음은? 최초의 블록을 생성해야 한다. 다른 말로 제네시스 블럭(Genesis block)이라고 하며, 이 곳에는 다양한 실제 블록체인 네트워크의 설정값이 들어가야 한다. 그리고 그 내용을 정의하는 것이 genesis.json이다. 일단 열어보자.

/config/besu/

cliqueGenesis.json, ibft2Genesis.json 같다. 이 둘 중 하나는 genesis.json으로 사용할 것이다. 그래서 곰곰히 생각해보니, 아까 docker-compose.yml의 volume에서 파일을 매칭 시켜줬었던 것이 기억난다.

내가 직접 설정한 적은 없지만, default로 합의 알고리즘을 ibft2를 사용하기로 한 듯하다. 다시 보니 Besu의 Quorum Developer Quickstart 링크 가장 초장에 IBFT 2.0 네트워크를 구성한다고 나와있다. 위 사진의 노란 네모를 보면, 오른쪽 경로 genesis.json은 ibft2Genesis.json에 대응시켜놨음을 알 수 있다. Clique나 IBFT 2.0은 합의 알고리즘의 일종인데, 좀 더 자세히 공부를 해봐야 할 것 같다. 

아무튼 우리가 찾던 genesis.json은 ibft2Genesis.json이다! 최초의 블록에는 어떤 내용들이 적혀 있는지 하나하나 뜯어보자. 사진 아래 링크를 참고해서 각 속성 값들이 무엇을 의미하는지 찾아봤다. 

Explaining the Genesis Block in Ethereum

 

config: chainID

내가 어느 체인에 올라와 있는지 알려준다. 이더리움 메인넷의 chainID는 1이다. 여기는 1337로 되어 있는데, 이건 private chain의 default 체인 ID라고 한다. (1-Ethereum mainnet, 2-Morden, 3-Ropsten, 4-Rinkeby, 5-Goerli, 42-Kovan, 1337-Private(default))

 

alloc

네트워크에 들어왔을 때, 어떤 사람의 지갑에 얼만큼의 돈을 채워둘지를 정한다. 사람들의 주소와 채워줄 금액이 적혀있다. 예제에서는 private key를 같이 넣어줬는데, 그 이유를 잘 모르겠다. 해당 주소들은 /config/networkFiles 디렉토리에 member1, member2, member3 폴더에 key로 저장되어 있다. 사실 여기서 "validator가 네트워크의 member 아니었나?" 하는 생각이 들었다.  그래서 이것 저것 고민하다가, npx quorum-dev-quickstart 처음 실행 시,private transaction 옵션을 y로 해봤더니 컨테이너로 member들이 떠있음 확인할 수 있었다....!

아무튼 여기서는 네트워크 시작 전 alloc으로 member1, member2, member3에게 이더리움을 미리 몽땅 쥐어주고 있음을 알 수 있다.

 

difficulty

채굴의 어려운 정도를 의미한다. 채굴, 합의 알고리즘 관련해서는 따로 공부해서 포스팅을 해봐야겠다. 갑자기 채굴 뿐 아니라 블럭, 데이터, 분기 등 다양한 개념이 헷갈려서 몇몇 자료들을 찾아봤다.

블록체인의 정의와 기술 “비전공자도 이해하는 기본적 이해”

개발자가 설명해주는 비트코인 채굴 방법 (ft 시뮬레이터, 노마드코더)

 

 

mixhash, nonce

mix hash와 nonce를 함께 사용하여 블록이 제대로 채굴되었는지 확인한다. 두 개의 값을 사용하는 이유는 공격자가 거짓 nonce로 블록을 위조할 경우, nonce가 거짓임을 발견하는 데 계산 비용이 많이 들기 때문이다. mixhash는 nonce를 확인하는 데 비용이 많이 들지 않는 nonce를 찾기 위한 중간 계산이다. 따라서 블록의 유효성을 검사할 때 잘못된 혼합 해시를 발견하는 경우 검사하지 않고 한 번에 블록을 삭제할 수 있다..

 

parentHash

이전 블록 헤더의 해시. 사실 제네시스 블록에서는 해당 항목을 정의할 필요가 없겠지만, 제네시스 블록은 다른 블록들에게 앞으로 이어질 네트워크의 블록이 어떤 형식이어야 하는지 알려줘야하기 떄문에, 비워두지 않고 적절히 채워둔다.

 

coinbase

해당 블록을 채굴했을 때, 보상이 들어갈 곳의 곳의 주소를 의미한다.

 

Timestamp

유닉스 함수를 이용해, 블록이 생성된 시간을 기록