체인 데이터가 100GB단위를 넘어가면서,
Sync할때 많은 문제들이 발생하고 있으며, 다양한 관련 연구들이 진행중이지만, 현실적으로 다가오기엔 시간이 조금 더 필요한 것으로 보인다.
얼마전부터 이더리움의 DB 분석을 계속 해왔던 이유는, 어떻게하면 노드의 쉬운 네트워크 가입을 지원할수 있을까 고민하다, 첫번째 넘어야 할 허들이 데이터 크기라는 것에 생각이 닿았기 때문이다.
현재 데이터들이 어떻게 구성되어 쌓여가고 있는지 를 분석하고, 좀더 좋은 방향으로 연구를 진행해 보고자, 이 글을 시작했다.
geth의 경우 chaindata 폴더(leveldb)에 블록 체인의 모든 데이터를 저장하는데, 저장되는 데이터의 종류는 다음과 같다.
흔히 말하는 이더리움 계정의 정보이다.
key, value의 형태로 보자면
[secure-key + hash : address]
[hash , rlp(stateObject)]
[roothash, rlp(trie-node)
의 데이터가 주를 이루며, 흔히 우리가 이야기하는 머클패트리샤(MPT) 자료구조의 데이터를 생각하면 된다.
self mining의 경우 블록 confirm 타이밍이 되어야 potential block을 genesis chain에 추가한다.따라서 DB에 안보일수 있으므로 caching관련옵션을 끄고, confirm타임도 1로 변경해야 원하는 데이터를 확보할 수 있었다.
데이터 검증은 아래 처럼 어카운트 2개를 생성한 것이statedb에 쓰여지고,트렌젝션을 통해 데이터를 전송하면, Trie가 추가적으로 써지는 것을 확인하는 방식으로 진행하였다. chaindb에는 나머지 블록정보만 존재하는 것을 확인하였다.
//coinbase생성하고
personal.newAccount("base")
miner.start()
miner.stop()
//1번 블록이 마이닝되었을때 db확인
//추가 계정을 생성하고, 해당 계정으로 1eth전송
personal.newAccount("guest1")
eth.sendTransaction({from:eth.coinbase, to:eth.accounts[1], value: web3.toWei(5,"ether")})
//2번블록 mining
miner.start()
miner.stop()
// statedb의 stateObject를 확인하여 balance가 9, 1 ether가 나와야 한다.
이제 눈감고도 rlp를 깔수 있게 되었다 lol
private network테스트에서 생각하지 못한 부분은 db업데이트가 sync시에도 일어난다는 것이다. sync로직에서 기존에 데이터가 1개의 db로 이루어져 있다고 가정하여 stateroot를 chaindb에서 생성하려고 하는 문제가 있었다
수정(https://github.com/NAKsir-melody/go-ethereum/commit/c5cf1f83d05991dc5ccf891edab350d409693141
싱크가 동작하면서, 가장 먼저 작은 스크립트를 만들어 주기적으로 db의 사이즈를 모니터링해봤다.
#!/usr/bin/python3
import subprocess
import time
def du(path):
return subprocess.check_output(['du','-sb', path]).split()[0].decode('utf-8')
if __name__ == "__main__":
f = open('data.csv', 'w')
while True:
string = du('chaindata') + '\t' + du('statedata') +'\n'
print(string)
f.write(string)
f.flush()
time.sleep(3)
f.close()
Testnet 싱크초기의 각 DB의 크기변경 추세를 그래프로 나타내보면, 아래와 같다.
파란색 데이터가 chaindb이고, 빨간색 데이터가 statedb사이즈인데, statedb가 월등히 많은 것을 확인하였다.
초기에는 계정은 많이 만들어놓고 막상 트렌젝션이 별로 없었나? 하는 생각도 들고,
이러다가 트렌젝션이 활성화 되면, 역전하겠지? 라는 생각도 든다. 무튼 데이터 분석 환경은 우선 성공적으로 구축이 된것으로 판단된다.
개인적으로 진행중(반포기중)이다. 사용하는 오래된 노트북의 리소스 문제로 더이상 진행하기 힘들것 같다. 다만, 이러한 시도를 통해 무언가 sync방식을 좀더 변화시킬수 있을것 같다는 생각이 드는것 같다.
정리되지 않은 스케치이지만, 첫싱크때는 회색부분의 체인데이터가 필요없게 하는 방법을 생각하는 중이다. 싱크 이후에는 요청에 따라 les프로토콜의 ODR로 읽어와줘야 할것이다. 그런데 생각해보면 parity warp싱크랑 그다지 다른거 같지도 않다.
백수생활중에 해온 업무를 정리하는 차원에서 글을 정리해보았는데,
이게 연구인지, 혼자놀기의 진수인지 조금 헷갈린다.
이전 회사에서 느끼지 못했던 리소스의 부재에 대한 아쉬움도 있고.
블록체인 왜 하냐고 정말 많은 질문을 받았다. 매번 설명 할때마다 장황 했었는데, 요근래 조금씩 정리가 되었다.
"돈이 될 것 같아서 나왔는데, 코드가 너무 재밌어서 눌러 앉았습니다."
잘못 분석된 내용이 있거나, 수정할 부분이 있다면
[email protected]로 언제든 연락부탁드립니다.