ETH 1.X: 상태 비저장 이더리움 "REGENESIS"의 새로운 아이디어
소스 |Ethereum Blog
저자 | 그리핀 이치바 호치키스
첫 번째 레벨 제목
Eth 1.x: Stateless Ethereum "reGenesis"의 새로운 아이디어이번 주에 우리는테크 트리
업데이트를 통해 Ethereum 1.x 개발을 위한 몇 가지 새로운 주요 이정표를 추가합니다. 이 이정표는 Stateless Ethereum의 전체 구현으로 간주되지 않지만 중기적으로 합리적으로 달성할 수 있는 목표입니다.
동시에 코드 청킹(코드 머클라이제이션), 상태 바이너리 트리 등 우리와 비교적 가까운 목표는 이미 EIP를 준비하고 있다. 이 기사에서는 달성한 진행 상황을 설명하고 독자가 관심 영역을 드릴다운할 수 있도록 링크를 첨부합니다.
첫 번째 레벨 제목
이진 트리현재 이더리움은 16개의 포크를 사용합니다.패트리샤 메르켈 트리
상태를 인코딩하지만 바이너리로 변환하면 특히 증인 크기 측면에서 효율성이 크게 향상됩니다. 이더리움 상태를 완전히 다시 코딩하려면 새로운 패러다임의 개발과 명확한 전환 전략이 필요합니다. 마지막으로 스마트 계약 코드를 청크하고 이 프로세스를 이진 트리 전환 또는 독립 실행형 업데이트로 통합할지 여부를 결정해야 합니다.
에서 언급).ethresearch.
공식 이진 트리 사양 및 청킹 규칙에 대한 논의는 다음에서 찾을 수 있습니다.
이진 트리로 전환
중요한 것은 이진 트리 패러다임의 목적지뿐만 아니라 여행 자체도 가치가 있습니다! 이상적인 전환에서는 네트워크의 트랜잭션 처리에 중단이 없을 것입니다. 즉, 클라이언트는 15초마다 나타나는 새 블록을 처리하면서 새로운 이진 트리를 구축해야 합니다.현재 가장 유망해 보이는 전환 전략은"재정의" 방법
, 부분적으로 geth의 새로운 스냅샷 동기화 프로토콜을 기반으로 합니다. 일반적으로 새로운 상태 변경은 이진 패러다임의 기존 16진법에 추가됩니다. 즉, 전환 중에 이진법과 16진법이 혼합될 것입니다. 영향을 받지 않는 상태는 백그라운드 처리로 전환됩니다. 일단 변환되면 두 계층이 단일 이진 트리로 병합됩니다.
클라이언트 다양성도 바이너리 변환 프로세스에서 매우 중요한 역할을 한다는 점에 유의하는 것이 중요합니다. 각 클라이언트는 자체 버전의 전환을 구현하거나 다른 클라이언트에 의존하여 전환을 수행한 다음 다른 쪽에서 새 트리를 기다려야 합니다.
이를 위해서는 "두 번 생각"해야 하며 모든 클라이언트가 협력하여 전환을 테스트하고 조정해야 합니다. 보안상의 이유로 전환 중에 네트워크가 일시적으로 서비스를 중단해야 할 수도 있지만(예: 일부 빈 블록 채굴) 구체적인 계획에 동의하기에는 너무 이릅니다.
코드 청킹
이더리움 상태 트리의 상당 부분은 50GB 상태 중 약 1GB를 차지하는 스마트 계약 코드로 구성됩니다. 스마트 계약 상호 작용에 대한 모든 증인은 많은 추가 데이터를 생성할 수 있는 codeHash를 계산하기 위해 상호 작용 코드를 제공해야 합니다.
코드를 청크로 나누는 방법은 여러 가지가 있는데 복잡도에 따라 간단한 방법은 일반 청킹(예를 들어 각 청크 크기는 64바이트)이고, 더 복잡한 방법은 Solidity functionId 또는 JUMPDEST 명령을 기반으로 한 정적 분석입니다. 최적의 코드 청킹 전략은 궁극적으로 메인 네트워크에서 수집한 실제 데이터에 적용할 수 있는지 여부에 달려 있습니다.
reGenesis
텍스트@mandrigin의 설명,게다가,게다가@realLedgerwatch가 제출한 전체 제안서
간단히 말해서 reGenesis는 기본적으로 "블록체인의 대대적인 청소"라고 할 수 있습니다. 전체 상태는 개념적으로 "활성" 상태와 "비활성" 상태로 구분됩니다. 전체 "활성" 상태는 주기적으로 비활성화된 다음 거의 처음부터 새로운 활성 상태를 생성하기 위해 새로운 트랜잭션이 생성됩니다(따라서 "reGenesis"라는 이름).
트랜잭션에 이전 상태가 필요한 경우 상태 비저장 이더리움에서 요구되는 증명과 매우 유사한 증인이 제공됩니다. 상태 변경이 일부 비활성 상태와 일치한다는 Merkle 증명입니다. 트랜잭션이 상태의 "비활성" 부분을 필요로 하는 경우 자동으로 "활성" 상태(트랜잭션 성공 여부에 관계없이)로 전환하고 이 부분은 다음 reGenesis가 발생할 때까지 남아 있습니다.
이것의 한 가지 장점은 실제로 상태를 제거하지 않고 상태를 사용하는 데 약간의 경제적 제약이 있다는 것입니다. 둘째, 트랜잭션 발신자가 맹목적으로 반복적으로 트랜잭션을 시도하는 경우 증인을 생성할 수 없습니다.
reGenesis의 중요성과 관련하여 이더리움이 궁극적인 상태 비저장 목표를 향한 큰 발걸음을 내딛게 하고 상태 비저장을 달성하기 위한 가장 큰 도전, 즉 EVM 실행 중 증인 가스를 계산하는 방법을 피합니다. 동시에 특정 버전의 트랜잭션 증인이 네트워크에 전파되도록 하여 더 가벼운 클라이언트와 dapp 개발자가 상태 비저장 패러다임 및 증인 생성에 익숙해질 수 있는 더 많은 기회를 가질 수 있습니다.
reGenesis 이후의 "진정한" 상태 비저장은 정도의 문제입니다. 상태 비저장 이더리움은 실제로 각 블록 이후의 reGenesis입니다.
주 네트워크
처음부터 네트워크 프로토콜의 최적화는 기술 트리의 "부수 작업"에 불과했지만 reGenesis가 상태 비저장 이더리움의 영역에 진입하면서 이더리움 체인 데이터(상태 포함)를 공유하기 위한 대체 네트워크 프리미티브를 탐색하는 것이 중요한 작업이 되었습니다. ).주 임무. 이더리움의 현재 네트워크 프로토콜은 전체이지만 실제로는 서로 다른 "서브 네트워크"를 통해 공유할 수 있는 여러 유형의 데이터가 있으며 이러한 "서브 네트워크"는 다양한 요구를 충족할 수 있습니다.Stateless 세션 초기에 이 주제에 대해 논의할 때 우리는 이를，"쓰리네트웍스"DHT 기반
네트워크는 자주 변경되지 않는 데이터 유형을 보다 효율적으로 처리할 수 있습니다. reGenesis의 도입으로 이러한 간헐적으로 변경되는 데이터에 "비활성" 상태가 포함될 수 있으며 이론적으로 풀 노드에 의해 현재 하나씩 브로드캐스트되는 대신 비트스트림 스웜 네트워크에 적용될 수 있습니다.마지막 reGenesis 이후 네트워크 전체에 불변 상태를 전파하는 네트워크는 정적 상태 네트워크입니다.devp2p 라이브러리(Ethereum 네트워크 프로토콜)의 새로운 Discovery v5.1 사양 기반
스트레칭.Merry-go-Round sync이전과 유사SNAP protocol활성 상태를 동기화하는 데 사용할 수 있는 는 클라이언트가 전체 상태를 신속하게 동기화할 수 있도록 하는 완전히 분산된 동적 상태 네트워크를 향한 중요한 단계입니다.
발문
발문상태 비저장 이더리움 기술 트리의 각 분기에 대한 보다 자세한 기술 설명은 독자가 참조할 수 있습니다., 이 모든 주제는 Eth1x/2 R&D Discord에서도 논의할 수 있습니다. 가입을 원하면 ethresear.ch에서 초대를 요청할 수 있습니다. 피드백과 제안이 필요하면 트위터에서 @gichiba 또는 @JHancock으로 연락해 주세요.
고지 사항: ECN의 번역 작업은 중국 이더리움 커뮤니티에 고품질 정보 및 학습 리소스를 제공하는 것을 목표로 합니다.기사의 저작권은 원저자에게 있습니다.재인쇄는 원문의 출처와 ethereum.cn을 표시해야 합니다.장기적으로 재인쇄는 ethereumcn@gmail.com으로 연락주세요.
