이글은 새로운 정보과 경험을 소개할뿐 무언가를 강제로 권하는 글은 아닙니다. 참고만 하시고 모든 선택은 본인의 결정으로..
0.들어가기전
- 이더리움 클라이언트 다양성
이더리움은 현재 POS 라는 합의알고리즘에 의해 블럭을 생성합니다.
POS에 참가하려면 32이더를 예치하고 밸리데이터가 되어야 하고.
EL ( Excution Layer) 과 CL ( Consensus Layer) 두 클라이언트를 구동하면서 풀노드를 운영하며 체인을 유지합니다.
https://eth-docker.net/assets/images/ethereum-full-node-281bc402bbd16a07837b05a99b57d75b.png
이더리움 네트워크의 최종성(비가역적으로 되돌릴수 없는, 확정된 블럭) 은 만들어진 후 2 에폭을 지나야 하는데. ( 1에폭 = 32슬롯. 1슬롯(12초) = 6.4분 ) 최종화 되기까지 각 에폭에서 총 참가자의 2/3이상의 합의가 있어야 됩니다.
EL 과 CL은 여러 클라이언트로 구현되어 있는데.
만약 특정 클라리언트의 점유율이 1/3을 넘고. 점유율이 높은 클라이언트가 오류를 일으키면 이더리움 네트워크는 최종성을 유지 못하고 통제불능에 빠질수도 있습니다. 그래서 이더리움 재단에서는 각 클라이언트이 점유율을 33% 이하로 낮추기 위해 애를 쓰고 있습니다.
현재 각 클라이언트 점유율입니다.
한때 EL클라이언트중 Geth ( GO Ethereum)는 점유율이 80%를 육박했고.
CL 클라이언트중 Prysm도 50%넘는 점유율을 보였었는데. 여러 노력에 의해 분산되고 있는중입니다.
저도 메인노드는 사실 Geth와 Prysm을 사용하고 있습니다. - 오래 사용해서 로그 보기도 편하고 유지보수가 쉽습니다.
그러나 백업노드도 돌려야 하고 메인노드도 다른 클라이언트로 갈아타기를 위해 계속 이거저거 사용을 해봤는데.
딱 맘에 드는게 아직 없었습니다.
네더마인 + 라이트하우스 조합은
네더마인이 C++로 만들어졌는데 CPU부하가 좀 큰편이고 실시간 노드 크기 증가도 커서 ( 물론 온라인 프루닝이 되긴 하지만 )
맘에 들지가 않더라구요. 다만 동기화 속도가 가장 빨라서. 비상시에 처음부터 동기화 해야 할때는 유용할것 같습니다.
자바로 만들어진 BESU + TEKU 조합도 한동안 테스트해봤는데. 자바의 메모리 누수문제인지. 이상하게 오류가 많아서 백업노드를 돌리다 두번이나 깨져서 이제 놓아주려고 합니다.
그러다가 아카이브 노드가 필요해져서..
*여기서 잠깐.. 이더리움 노드는 크게 아카이브 노드, 풀 노드 , 라이트 노드 로 나뉘어져있습니다.
라이트노드는 블록헤더만을 처리해서 블럭검증은 못하나 데이터를 쿼리하고 트랜젝션을 발행할수 있어 모바일지갑에 주로 사용됩니다.
풀노드는 제네시스부터의 블럭,헤더 등을 모두 저장하나 상태 정보는 수백블럭만 저장하고 이후 최신데이터로 교체합니다.
스테이킹을 위해서는 full node가 필요합니다.
아카이브 노드는 헤더 블럭 상태 등 모든 데이터를 저장해서. 특정시점에 특정 어카운트의 밸런스등을 알수가 있습니다만
데이터가 어마어마하게 커집니다.
예를 들어 Geth는 full 노드의 경우 현재 약 1.1TB를 차지하나 아카이브노드는 13TB에 육박합니다.
그러나 여기서.. Erigon이 등장하는데.. 아시는분은 아실.. 진정한 Pied Piper...
2.6xx 버전에서 아카이브노드 사이즈를 3.2TB로 줄였고. 현 3.0 베타에서는 1.8TB로 줄였습니다.
새 버전인 에리곤 3.0 베타를 계속 테스트하던 중.. 알수없는 오류로 계속 블럭 동기화가 중단되어.. 2.6으로 돌아가려던 찰라..
오늘 소개해드릴 Reth를 알게되었습니다.
geth는 말그대로 Go Ethereum의 약자인데.. Go 언어로 쓰여진 이더리움 이란 뜻입니다.
EL 클라이언트인 reth는 Rust Ethereum입니다. Rust 언어로 쓰여졌네요.
( Rust로 쓰여진 CL 클라이언트는 많이 사용하는 Lighthouse입니다. )
이더리움 클라이언트계에서 Pied Piper인 erigon에서 사용한 기술을 그대로 차용해서 비슷한 사이즈로 크기를 줄였습니다.
key-value를 쌍으로 MDBX에 저장합니다. - 자세한게 궁금하시면 아래 링크를 참고하세요.
https://github.com/ledgerwatch/erigon/wiki/Choice-of-storage-engine
https://github.com/ledgerwatch/erigon/blob/release/2.60/docs/programmers_guide/db_walkthrough.MD
그래서 백업노드를 Reth와 Lighthouse로 갈아탔는데. 동기화도 잘 되었고. 특별한 무리없이 잘 운영중입니다.
Reth는 얼마전 라이트하우스의 개발사인 시그마프라임으로 부터 코드 감사를 받고.
https://github.com/paradigmxyz/reth/blob/main/audit/sigma_prime_audit_v2.pdf
드디어 Production 버전인 1.0을 4일전 막 출시했습니다.
https://github.com/paradigmxyz/reth/releases
풀노드는 1.1TB , 아카이브 노드의 경우 현재 2.16TB정도라 개인이 운영하기에도 크게 부담스런 사이즈는 아닙니다.
EL 클라이언트 비교를 보면 Reth는 DB증가율도 낮은 편이라 2TB 저장장치를 가진 사람들한테도 장기 운영에 좋을거 같습니다.
메모리가 적은 저사양 시스템에서는 CL 클라이언트로 Nimbus를 권해드립니다.
