[번역] 이더리움 리제네시스?

(이 문서는 https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582 내용을 번역하였으며, 번역상의 오류를 포함하고 있을 수 있습니다.)

 

리제네시스 

<큰 블럭체인 및 상태(state) 부담을 감소시키기 위한 이더리움 리셋>

by AlexeyAkhunov

 

Cosmos Hub 허브에서의 교훈

Cosmos Hub가 버전 1에서 버전 2로, 그리고 버전 2에서 버전 3으로 어떻게 업그레이드했는지 본적이 있다면, 이것이 본질적으로 새로운 제네시스에서 블록 체인을 다시 시작함으로써 이루어 졌다는 것을 알 수 있습니다. 업그레이드시 노드 운영자는 노드를 종료 한 후 Cosmos Hub state스냅 샷을 생성 합니다. 해당 스냅 샷은 블록 1에서 새로운 블록 체인을 시작하기위한 제네시스로 효과적으로 사용이 가능했습니다. 이제 Cosmos Hub에 합류하려는 사람들은  CosmosHub-3의 제네시스를 획득하고 CosmosHub-3의 모든 블록 (CosmosHub-1나 CosmosHub-2 제외)을 다운로드하고 리플레이 시키면 됩니다. 

 

 

이더리움1을 다시 런칭할 수 있을까?

Ethereum에서 이러한 방법을 적용했다고 가정해봅시다. 여기에는 정말 큰 블록 체인 (150 ~ 160Gb)과 상당히 큰 state (저장 방법에 따라 40 ~ 100Gb)가 있습니다. 이러한 재 런칭의 분명한 이점은 새롭게 참여한 노드가 150Gb 상당의 블록이 아닌 40Gb 크기의 state로 시작이 가능하다는 것입니다. 그러나 40Gb를 다운로드하는 것도 여전히 좋은 경험이 아닙니다.

 

 

이더리움의 state는 암묵적, 머클 루트 해시만 드러난다

이제 (다운로드 받은) 40Gb 크기의 "오프체인"을 저장하고 루트 해시 만 제네시스로 사용할 수 있다고 가정 해 보겠습니다. 또한 빈 state로 시작하겠습니다. 어떻게 일부의 state를 가지고 트랜잭션 접근을 할 수 있을까요?

40Gb는 내부에 저장되어있으며 이를 획득하는 정확한 방법은 구현 세부사항이라 합시다. 1,000만 개의 블록을 모두 실행하여 계산하거나 빠른 동기화 또는 워프 동기화를 통해 스냅 샷을 다운로드하거나 다른 사람의 외부 디스크에서 복사 한 다음 다시 확인할 수도 있습니다. state가 암묵적으로 저장되어있지만, 블록 생성자(보통 채굴 풀)가 state에 액세스 할 수 있고 항상 모든 트랜잭션을 처리 할 수 있다고 가정합시다. 우리가 제거하려고 하는 부분은, 다른 모든 검증 노드가 블록의 트랜잭션이 유효하고 블록 헤더에 표시된 state 루트 해시가 블록 실행의 결과와 일치하는지 확인할 수 있는 암묵적 state 대한 접근 권한입니다. 

 

 

블록에서의 증명 vs 트랜잭션에서의 증명?

사람들이 이것에 대해 처음 공부할 때, 추가 증명이 실제로 트랜잭션 발신자에 의해 제공되고 트랜잭션 내용의 포함 된다고 생각합니다. 하지만 우리는 그들에게 "아니예요. 그것이 블록 채굴자의 일입니다."라고 설명해야합니다. 그러나 나중에 트랜잭션에는 추가적인 증거를 포함해야한다는 것을 알게됩니다. 즉, 전송 주소에 이 거래를위한 가스를 구매할 수있는 충분한 ETH가 있음을 증명해야하며, 이 계정의 다른 모든 거래에 대해서도 nonce가 더 낮다는 것도 증명해야합니다. 또한 전송 계정의 임시 값을 증명해야 할 수도 있으므로 노드는 nonce 값 간격이 있는지 여부를 확인 해야하므로, 실행 불가능한 트랜잭션 폭풍을 통해 잠재적인 DDOS 공격을받을 수 있습니다. 더 엄격하게 검사를 수행 할 수 있지만 ETH 잔액과 보내는 계정의 nonce 값을 아는 것만으로는 DDOS 를 막기 위한 추가 정보로는 충분하지 않습니다. 

 

 

거래에서 증거에 대한 비판

이제 상상해 봅시다. 실제로, 우리는 거래 발신자가 거래와 관련된 모든 state에 대한 증거를 포함하기를 원합니다. 증인을 위해 가스를 추가로 청구하는 작업을 단순화할 수 있기 때문에 이 방법이 좋을 것 같습니다. 이 방법에 대한 주요 비판은 대개 정적 상태 액세스(SSA)와 반대로 DSA(Dynamic State Access)와 관련이 있습니다. 트랜잭션이 특히 복잡한 스마트 계약, 특히 다른 계약에 중첩된 호출을 많이 포함하는 경우, 이 트랜잭션이 적용될 state항목은 사전 계산하기 어려울 수 있습니다. 또한 트랜잭션을 먼저 실행하여 불충분한 증거 오류를 발생시킴으로써 사용자를 함정에 빠뜨리는 데에도 사용할 수 있습니다.

 

 

리제네시스가 가져올 완화

DSA에 대한 우려를 완전히 해결할 수는 없지만, 사용자가 불편함을 거의 느끼지 않을 정도로 충분히 완화시킬 수 있으며, 결코 원하는 state 전환을 달성하지 못할 정도로 영구적으로 함정에 빠지게 되는 일은 없을 것입니다. 완화는 state 루트 (트랜잭션이 성공하기 위한 필요충분조건이 아님)에 대해 체크 아웃하는 트랜잭션과 함께 제공되는 모든 증명이 암시적 state의 일부가된다는 추가 규칙에 의존합니다. 따라서 거래를 실행하려는 사용자의 반복적인 시도는 암묵적 state를 계속 증가시키고 결국 성공하게 됩니다. 사용자를 함정에 빠뜨리려는 공격자는 트랜잭션의 state 액세스를 암시적 state 밖으로 리디렉션하는 보다 정교한 방법을 고안해야 하며, 결국 공격자는 실패하게 됩니다.

암묵적 state가 ("재 런칭"직후) 점점 더 많은 활성 액세스 state를 포함하게되어, 아무것도없는 state에서 증가함에 따라  트랜잭션에서 제공해야 할 증빙이 줄어들게 됩니다. 시간이 지나면, 대부분의 거래는 어떠한 증거도 첨부할 필요가 없게 됩니다. 단지 아주 오래되고 "먼지투성이의" 부분을 접근하는 부분의 증거만 첨부하게 됩니다.

 

 

계속 할 수 있습니다

나는 이것을 “재 런칭” reGenesis라고 부르며, 비 채굴 노드의 부담을 줄이기 위해 정기적으로 수행 할 수 있습니다. 또한 Stateless Ethereum의 덜 극적인 버전을 나타냅니다. ReGenesis를 반복적으로 수행하면 Ethereum 클라이언트 구현의 아키텍처가 단순해집니다. 고급 스냅 샷 동기화 알고리즘의 필요성을 대부분 없앨 수 있습니다. 1M 블록 (대략 6 개월)마다 ReGenesis를 수행하면 state 스냅 샷과 블록 체인 파일을 BitTorrent, Swarm, IPFS를 통해 사용할 수 있습니다. state가 6 개월마다가 아니라 매 15 초마다 변경되고 있으므로 지금은 가능하지 않습니다. 클라이언트 구현이 6개월 분량의 블록 리플레이에 대처할 수 있다면, 정교한 스냅샷 알고리즘이 필요하지 않게됩니다. 결과적으로 이더리움 구현의 복잡성이 줄어들 것입니다.

 

 

단점

많이 살펴보지는 않았지만, 세 가지가 있습니다.

1. 사용자는 트랜잭션을 생성하기 위해 완전한 암시적 state에 대한 액세스 권한이 필요할 수 있습니다.

   나는 실제로 이것이 공정한 타협이라고 생각합니다.
2. 사용자는 결국 원하는 state전환을 달성 할 때까지 (동적 상태 접근으로 인해) 트랜잭션을 반복해야 할 수 있습니다.
3. 네트워크가 ReGenesis 이전에 모든 블록을 효과적으로 "아카이브"하는 경우에 일부 롤업 기술(데이터 가용성을 위해 블록체인 데이터를 활용하는)은 중단 될 수 있습니다. 

 

토론에 참여해주세요.

업데이트 : 리제네시스 계획에 대한 문서 링크입니다. : https://ledgerwatch.github.io/regenesis_plan.html