일주일뒤 이더리움 네트워크 업그레이드가 있습니다.(덴쿤,3월13일 오후23시경)

간단정리 :  

3월13일 오후23시경 - 이더리움 메인넷  epoch 269568에서  덴쿤 업그레이드

스테이킹 노드 운영자는 특정버전 이상의 클라이언트로 업그레이드 필수 

Geth 신규사용자분중 신기술 궁금하신분은 PBSS와 pebbleDB 사용해 보세요. 

( 초기버전이라 버그가능성이 있긴 합니다만 온라인 프루닝 지원하니 향후 스토리지 관리가 매우 편해질수도 있습니다.  ) 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

참고로 전  X300에  5600g + 32GB Ram + 하이닉스 NVME 2TB로  작년 4월 이후 11개월정도 사용했는데  

초기 동기화때  디스크 사용량은 약 1TB 정도였고  최근  1.6TB로   여유공간이  200기가 정도밖에 남지 않아  Geth 오프라인 프루닝이 필요했는데.   덴쿤 업데이트를 위해  GETH 클라이언트 업그레이드중에  정상 종료가 되지 않아 최신 DB가 깨져  최근 2주간의 데이터 동기화가 필요하길래..   재빨리 복구노드로 키를  옮겨서 온라인 상태로 만들고.  

기존 메인노드는  아래 소개한 오프라인 프루닝이 필요없는  PBSS와 pebbleDB로 설정해서  GETH 재동기화 중입니다. 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

이더리움 메인넷  epoch 269568에  덴쿤업그레이드가 있습니다.(  예상시간 on March 13, 2024 at 13:55 UTC ( KST 22:55 ) )

테스트넷인  goerli  holesky에서는 이미 성공적으로 적용되었습니다.   이와 관련하여  참고할 만한 내용 남겨봅니다.  

0. 들어가며 

재작년  11월경에 부테린이   이더리움  로드맵을 정리해서 올린적이 있습니다.  - 관심있으신분들은 한번 보시면 도움이 되겠습니다. (

https://twitter.com/VitalikButerin/status/1588669782471368704

)

각각을 간단히 설명하자면   아래와 같습니다. 

• The Merge: 작업 증명에서 지분 증명으로의 전환과 관련된 업그레이드
• The Surge: 롤업 및 데이터 샤딩을 통한 확장성과 관련된 업그레이드
• The Scourge: MEV의 검열 저항, 분산화 및 프로토콜 위험과 관련된 업그레이드
• The Verge: 블록 검증과 관련된 업그레이드를 보다 쉽게 수행
• The Purge: 노드 실행의 계산 비용 절감 및 프로토콜 단순화와 관련된 업그레이드
• Splurge: 이전 카테고리에 잘 맞지 않는 기타 업그레이드입니다.

머지는 이미 실행되었고.. 이번 덴쿤 업데이트는  위 로드앱의 Surge에 해당합니다.  

이번 업데이트에서 주목할 내용은  프로토댕크샤딩으로 알려진 EIP-4844의 구현입니다.

https://eips.ethereum.org/EIPS/eip-4844

이더리움의  L1 거래수수료는 매우비싸고  롤업을 통해 수수료를 절감하는 시도가 있지만 이 또한 많은 사용자에게 너무 비싸서  최종적으로 샤딩이라는 목표에 도달해야 하지만  여기까지는 많은 노력과 시간이 필요하니.   최종목표인  샤딩 사양에  사용될것으로 예상되는 것과 동일한 형식의 BLOB 트랜젝션을 도입하여 일시적인 확장 완화를 제공하는 것이 목표입니다. 

EIP-4844 스펙명세에 따르면 매 블럭당 BLOB의 크기는 0.375MB, 최대 0.75MB , 최소 유지기간 4096 에폭.( 약 18일 ) 

매블럭당  목표치인 0.375MB가 꽉 찬다고 가정하면  48GBbyte,  최대치로 적용되면  96GB의 데이터공간이 추가로 필요합니다. 

*국내운영환경에서는  트래픽제한이 거의 없기때문에 문제가 되지는 않겠지만 .  노드끼리 BLOB데이터를 추가로 주고 받아야 하니  트래픽도 소폭 증가될것으로 보입니다.  

업그레이드 이후 필요한 최소  클라이언트 버전  

- 아래 명시된 버전보다 구버전을 사용하시는 분들은 일주일 이내 반드시 업그레이드 하셔야 합니다.  

Consensus Layer Mainnet Releases

NAME	VERSION	LINK
Lighthouse	5.0.0	Download
Lodestar	1.16.0	Download
Nimbus	24.2.2	Download
Prysm	5.0.0	Download
Teku	24.2.0	Download

Execution Layer Mainnet Releases

NAME	VERSION	LINK
Besu	24.1.2	Download
Erigon	2.58.1	Download
go-ethereum	1.13.13	Download
Nethermind	1.25.4	Download
Reth (alpha)	0.1.0-alpha.19	Download

이와 별개로..  몇가지   내용 추가 합니다. 

기존버전의  Geth(해시 베이스)를 운영하다 보면  새로운 블럭을 수신하면  트랜젝션이 실행되고  상태정보가 업데이트 되면서 저장소 데이터도 업데이트 되는데.  이때 필요없는 데이터가 누적되고 필요이상의 데이터공간을 차지합니다.  

Pruning이라는 작업을 통해 정리를 할수 있는데. GETH는  오프라인 프룬만 지원해서   6-7시간정도  오프라인상태로 있던지  백업노드로 전환 후  오프라인 상태에서 프루닝 작업을 했어야 했습니다. 

실행계층 클라이언트인  GETH는 최근 몇가지 새로운 기능을 추가했는데.  PBSS 와 pebble-db 입니다

1.PBSS  (Path-Based-Storage-Scheme )

위에 설명한 해시배이스 스토리지 저장기법대신   경로기반의 저장방식을 사용하여  MPT 트리 트리 액세스를 최적화하고 효율성을 향상시키며 인라인 상태 정리를 가져오는 데 사용됩니다

기존 해시방식과 비교하면 동기화시간도 줄어들고 데이터사이즈도 줄어듭니다.

초기단계라 조심할 필요가 있지만 조만간 기본옵션으로  제공될 예정입니다. 

기존 데이터셋과 호환이 되지 않아   기존 사용자는 geth removedb 명령으로 기존 상태DB를 제거하고 다시 동기화해야 합니다.

* ancient db는 날리지 않아도 됩니다.  ( 다  지우고 재동기화 해도 되지만  ancient db를 다시 받지 않아도 되어 더 빨리동기화됩니다.) 

처음 설치하시는 분은   명령어 옵션에  --state.scheme=path  를  넣어주시고 시작하시면 됩니다. 

적용후 시작시 로그에  "State scheme set by user                 scheme=path"가 보이면  잘 적용된겁니다. 

2. pebble-db 

GETH가 기존에 사용하던 DB는  LevelDB였는데  더이상 프로젝트가 더이상 유지 관리 않아  향후 pebbleDB로 전환하기로 했습니다.  두 DB가 호환이 안되어  이 또한 재 동기화가 필요하고.   

현재는 디폴트가 아니기 때문에  명령어에   --db.engine=pebble를 넣어주셔야 합니다. 

적용 확인방법은  Geth  시작시 로그에 "Using pebble as db engine"이 보입니다.  

레벨DB와 페블DB 성능차이 스냅샷 동기화시  30%이상  페블DB 빨리 동기화 되었다는 벤치마크가 있습니다