이더 프로토콜의 가능한 미래(5): 퍼지

이 기사에서는 성능 저하 없이 블록체인 아키텍처를 단순화하고 네트워크 효율성과 지속 가능성을 향상시키는 방법에 대한 통찰력을 제공합니다.

원문: 이더리움 프로토콜의 가능한 미래, 5부: 퍼지 (vitalik.eth)

작성자: Vitalik.eth

편집자: ChoeyGit, 183Aaros, LXDAO

번역가의 서문

블록체인 기술과 이더 생태계의 추종자이자 학습자로서 저는 Vitalik이 제안한 "The Purge" 계획을 보고 매우 흥분되고 기뻤습니다. 이 계획은 독특한 개발 아이디어를 제안합니다. 즉, 블록체인이 기능 확장을 추구하는 맥락에서 대신 시스템 아키텍처를 최적화하고 단순화하여 네트워크 효율성을 향상시킬 것입니다. 이 계획은 주로 참여 문턱을 낮추고 네트워크의 지속 가능성을 향상시키기 위해 블록체인 데이터 확장 문제를 해결하고 시스템 복잡성을 단순화하는 데 중점을 두고 있습니다.

블록체인 기술의 급속한 발전으로 인해 네트워크 데이터의 지속적인 증가와 점점 복잡해지는 시스템 아키텍처의 어려움이 점차 대두되고 있습니다. 특히 오늘날 레이어 2 솔루션이 널리 사용되는 경우 더 높은 확장성을 제공하고 시스템에 추가적인 복잡성을 가져옵니다. 이런 맥락에서 이 글의 '더 퍼지(The Purge)' 계획은 새로운 사고의 방향을 제시한다.

이 기술 경로가 네트워크 성능에 영향을 주지 않고 효과적인 무게 감소를 달성할 수 있습니까? 단순성과 기능성 사이의 균형을 맞추는 방법은 무엇입니까? 이러한 문제에 대한 심층적인 토론을 보려면 기사를 따르십시오.

이 기사의 개요

이 글은 총 10,000단어 정도이며, 3부분으로 구성되어 있습니다. 이 글을 다 읽는 데는 50분 정도 소요될 것으로 예상됩니다.

1. 기록 만료
2. 주 만료
3. 기능 정리

텍스트 내용

"이더 프로토콜의 가능한 미래(5): 퍼지"

피드백과 리뷰를 주신 Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden 및 Tomasz Stanczak에게 특별히 감사드립니다.

이더 과제에 직면해 있습니다. 기본적으로 블록체인 프로토콜은 시간이 지남에 따라 크기와 복잡성이 증가합니다. 이러한 상황은 주로 두 가지 측면에 반영됩니다.

기록 데이터 : 온체인 트랜잭션과 계정이 생성될 때마다 모든 클라이언트가 영구적으로 저장해야 합니다. 동시에 새 클라이언트도 전체 노드 동기화를 수행할 때 모든 데이터를 다운로드해야 합니다. 이로 인해 체인의 처리 용량이 일정하게 유지되더라도 클라이언트 로드 및 동기화 시간이 계속 증가합니다.

프로토콜 기능 : 기존 기능을 제거하는 것보다 새로운 기능을 추가하는 것이 훨씬 쉬우므로 시간이 지남에 따라 코드 복잡성이 증가합니다.

이더 지속 가능한 장기 개발을 위해 우리는 시간이 지남에 따라 복잡성과 부풀림의 지속적인 감소라는 두 가지 추세에 대처할 수 있는 강력한 조치를 찾아야 합니다. 동시에 우리는 블록체인의 핵심 특성인 영속성 도 유지해야 합니다. 거래 데이터(콜데이터)에 작성된 러브레터인 NFT를 저장할 수도 있고, 백만 달러가 포함된 스마트 계약을 온체인 배포할 수도 있습니다. 당신이 10년 동안 동굴에 숨어 있다 하더라도, 당신이 나올 때 읽고 상호 작용할 수 있도록 기다리고 있는 것이 여전히 거기에 있다는 것을 알게 될 것입니다. 탈중앙화 애플리케이션(dapp)은 완전한 탈중앙화 안전하게 달성하고 업그레이드 키를 제거하기 전에 애플리케이션을 실행하는 데 의존하는 구성 요소가 업그레이드로 인해 파괴적인 변경을 일으키지 않을 것이라는 확신을 가져야 합니다. —— — 특히 L1 자체는 더욱 그렇습니다.

연속성을 유지하면서 데이터 팽창, 복잡성 및 부패를 최소화하거나 반전시키면서 이 두 가지 요구 사항 사이의 균형을 찾아야 합니다. 우리는 이 분야에 대한 연구에 투자하는 한 이것이 확실히 달성 가능하다고 믿습니다. 유기체는 이것을 할 수 있습니다. 대부분의 사람들은 시간이 지남에 따라 노화되지만 운이 좋은 소수는 그렇지 않습니다. 사회 시스템조차도 매우 긴 수명을 달성할 수 있습니다. 이더 작업 증명 메커니즘(Pow)이 제거되고, SELFDESTRUCT opcode(opcode)가 기본적으로 사라졌으며, 비콘 체인 노드는 이제 지난 6개월의 기록 데이터만 저장하는 등 여러 분야에서 성공 사례를 보여주었습니다. 이는 장기적인 확장성, 기술적 지속 가능성, 보안 측면에서 이더 의 궁극적인 과제이며, 이더 의 보다 보편적인 개발 경로를 찾고 장기적인 안정성이라는 궁극적인 목표를 향해 나아가는 것을 목표로 합니다.

퍼지: 주요 목표

• 클라이언트 스토리지 요구 사항을 줄이고 각 노드가 모든 기록 데이터를 영구적으로 저장할 필요성을 줄이거나 제거하여 상태 데이터 저장에 대한 의존도를 줄일 수도 있습니다.
• 불필요한 기능을 제거하여 프로토콜 복잡성을 줄입니다.

이 장의 내용

• 기록 만료
• 주 만료
• 기능 정리

기록이 만료되었습니다.

우리는 어떤 문제를 해결하려고 합니까?

이 글을 쓰는 시점에서 완전히 동기화된 이더 노드는 클라이언트를 실행하는 데 약 1.1TB의 디스크 공간이 필요하고 합의 클라이언트를 저장하는 데 추가로 수백 GB가 필요합니다. 그 중 대부분은 과거 블록, 거래 및 영수증 데이터를 포함하는 과거 데이터이며, 대부분은 수년이 지났습니다. 이는 가스 한도가 전혀 증가하지 않더라도 노드 크기는 여전히 연간 수백 GB씩 증가한다는 것을 의미합니다.

그것은 무엇이며 어떻게 이루어 집니까?

기록 저장 문제에는 주요 단순화 속성이 있습니다. 각 블록은 (다른 구조 중에서) 해시로 연결되어 있고 이전 블록을 가리키기 때문에 이는 현재 상태에 대한 합의가 있을 때마다 기록에 대한 합의가 있음을 의미합니다. . 네트워크가 최신 블록에 대한 합의에 도달하는 한, 모든 기록 블록, 거래 또는 상태(계정 잔액, nonce, 코드, 저장)는 모든 단일 참가자에 의해 제공될 수 있으며 단일 참가자를 제외한 모든 참가자를 허용하는 Merkle 증명이 수반될 수 있습니다. 수동으로 정확성을 확인합니다. 합의가 N/2-N 신뢰 모델을 사용하는 경우 기록은 1-of-N 신뢰 모델입니다.

이는 과거 데이터를 저장하는 방법에 대한 다양한 옵션을 열어줍니다. 자연스러운 선택은 네트워크의 각 노드가 데이터의 작은 부분만 저장하도록 하는 것입니다. 이는 토렌트 네트워크가 수십 년 동안 작동한 방식과 같습니다. 전체 네트워크는 수백만 개의 파일을 저장하고 배포하지만 각 참가자는 그 중 일부만 저장하고 배포합니다. 아마도 직관에 반하는 것처럼 이 접근 방식이 반드시 데이터의 견고성을 감소시키는 것은 아닙니다. 노드 운영 비용을 줄여 100,000개의 노드가 있는 네트워크를 구현할 수 있으며, 각 노드는 기록 데이터의 10%를 무작위로 저장하며, 각 데이터 조각은 10,000번 복사됩니다 . 이는 10,000개의 노드가 있는 네트워크와 동일합니다. 각 노드가 모든 데이터를 저장하는 노드 네트워크는 정확히 동일한 복제 요소를 갖습니다.

오늘날 이더 모든 노드가 모든 기록 데이터를 영구적으로 저장하는 모델에서 점차 벗어나기 시작했습니다. 합의 블록(즉, 지분 증명 합의와 관련된 부분)은 약 6개월 동안만 저장됩니다. Blob은 약 18일 동안만 저장됩니다. 제안 EIP-4444는 과거 블록 및 영수증에 대한 1년 저장 기간을 도입하는 것을 목표로 합니다. 장기적인 목표는 각 노드가 모든 데이터를 저장하는 공동 저장 기간(약 18일 정도)을 설정하고, 이후 오래된 데이터는 이더 노드의 P2P 네트워크를 통해 분산 방식으로 저장하는 것입니다. .

삭제 코드는 동일한 복제 요소를 유지하면서 데이터 견고성을 향상시킬 수 있습니다. 실제로 데이터 가용성 샘플링을 지원하기 위해 Blob 자체는 이미 삭제 코딩 기술을 사용하고 있습니다. 가장 간단한 해결책은 이 삭제 코딩 기술을 재사용하고 실행 계층과 컨센서스 레이어 의 블록 데이터를 Blob에 넣는 것입니다.

현재 연구와 어떤 연관성이 있나요?

• EIP-4444 제안: https://eips.ethereum.org/EIPS/eip-4444
• 토렌트 네트워크 및 EIP-4444 제안: https://ethresear.ch/t/torrents-and-eip-4444/19788
• 포털 네트워크: https://ethereum.org/en/developers/docs/networking-layer/portal-network/
• 포털 네트워크 및 EIP-4444 제안: https://github.com/ethereum/portal-network-specs/issues/308
• 포털에서 SSZ 객체의 분산 저장 및 검색: https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• 가스 수수료 한도를 높이는 방법(Paradigm): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

앞으로 해야 할 일과 절충점은 무엇입니까?

남은 주요 작업에는 구체적인 분산 기록 저장 솔루션(적어도 실행 계층의 기록 데이터, 최종적으로는 컨센서스 레이어 데이터 및 Blob)을 구축하고 통합하는 작업이 포함됩니다. 가장 간단한 두 가지 솔루션이 있습니다. (i) 기존 토렌트 라이브러리를 직접 가져오는 것과 (ii) 포털 네트워크라고 하는 이더 기반 솔루션입니다. 이 두 가지 시나리오 중 하나가 도입되면 EIP-4444를 활성화할 수 있습니다. EIP-4444 자체에는 하드 포크 필요하지 않지만 새로운 네트워크 프로토콜 버전이 필요합니다. 따라서 모든 클라이언트에서 동시에 이 기능을 활성화하는 것이 중요합니다. 그렇지 않으면 클라이언트가 다른 노드에 연결할 때 클라이언트가 전체 기록 데이터를 다운로드할 것으로 예상하지만 실제로 얻을 수 없는 실패 리스크 있을 수 있습니다.

주요 절충점은 "고대" 과거 데이터의 가용성을 얼마나 멀리 보장할 것인가입니다. 가장 간단한 해결책은 내일부터 "고대" 기록 데이터 저장을 중단하고 대신 데이터 복제를 위해 기존 아카이브 노드와 다양한 중앙 집중식 서비스 제공업체에 의존하는 것입니다. 이는 구현하기 쉽지만 영구적인 기록 저장소로서 이더 의 위치를 ​​약화시킬 것입니다. 더 어렵지만 안전한 방법은 먼저 토렌트 네트워크를 구축하고 통합하여 기록 데이터를 분산 방식으로 저장하는 것입니다. 여기서 "얼마나 열심히 노력하는가"에는 두 가지 차원이 있습니다.

1. 최대 노드 수가 실제로 모든 데이터를 저장하도록 하려면 얼마나 많은 노력이 필요합니까?
2. 과거 데이터 저장소를 프로토콜에 어느 정도까지 통합해야 합니까?

차원 (1)의 경우 매우 엄격한 솔루션에는 보관 증명이 포함됩니다. 각 지분 증명 유효성 검사기는 실제로 특정 비율의 기록 데이터를 저장하고 정기적인 암호화 검사를 수행하여 저장 조건을 확인해야 합니다. 또 다른 좀 더 겸손한 해결책은 자발적인 표준을 설정하고 각 클라이언트가 과거 데이터의 특정 비율을 자발적으로 저장하도록 하는 것입니다.

차원 (2)의 경우 기본 구현 솔루션은 기존 결과를 직접 채택하는 것입니다. Portal은 이미 이더 의 전체 기록이 포함된 ERA 파일을 저장합니다. 보다 포괄적인 구현은 이를 실제로 동기화 프로세스에 연결하여 누군가가 전체 기록을 저장하는 노드 또는 아카이브 노드를 동기화하려는 경우 다른 아카이브 노드가 없더라도 포털 네트워크에서 직접 동기화할 수 있도록 하는 것입니다. 온라인.

로드맵의 다른 부분과 어떻게 상호 작용합니까 ?

노드를 매우 간단하게 실행하거나 시작하려면 기록 데이터 저장소 요구 사항을 줄이는 것이 상태 비저장보다 더 중요합니다. 노드에 필요한 1.1TB의 저장소 중 상태 데이터는 약 300GB를 차지하고 기록 데이터는 나머지 약 800GB. 이더 노드를 스마트워치에서 실행하고 단 몇 분 만에 설정한다는 비전은 무상태와 EIP-4444가 모두 구현된 경우에만 달성될 수 있습니다.

과거 데이터의 저장을 "최신 이더 노드는 최신 버전의 프로토콜만 지원하면 됩니다"로 제한하면 실행 가능성이 향상되고 노드 구현도 더 간단해집니다. 예를 들어, 2016년 DoS 공격 중에 생성된 빈 저장소 슬롯이 모두 제거되었으므로 이제 관련된 많은 코드 줄을 안전하게 삭제할 수 있습니다. 마찬가지로, 이제 지분 증명(PoS)으로의 전환이 "오래된" 역사이므로 클라이언트는 이제 모든 작업 증명(PoW) 관련 코드를 안전하게 제거할 수 있습니다.

상태가 만료되었습니다.

어떤 문제가 해결되나요?

클라이언트가 기록 데이터를 저장할 필요성을 제거하더라도 상태 데이터(계정 잔액 및 nonce 값, 계약 코드 및 계약) 의 지속적인 증가 로 인해 클라이언트의 스토리지 요구 사항은 연간 약 50GB씩 계속 증가할 것입니다. 저장. 사용자는 현재 및 미래의 이더 클라이언트에 영구적인 스토리지 부담을 주는 일회성 비용을 지불합니다.

상태 데이터는 기록 데이터보다 "만료"하기가 더 어렵습니다. 왜냐하면 EVM의 기본 설계는 일단 상태 개체가 생성되면 영구적으로 존재하고 언제든지 모든 트랜잭션에서 읽을 수 있다는 가정을 기반으로 하기 때문입니다. 무상태를 도입하면 이 문제가 그다지 심각하지 않을 수 있다는 관점 있습니다. 특정 클래스의 블록 빌더만 실제로 상태 데이터를 저장해야 하는 반면 다른 모든 노드(포함 목록 생성까지!)는 무상태에서 실행될 수 있습니다. 방법. 그러나 또 다른 관점 무국적에 너무 많이 의존해서는 안 되며 궁극적으로 이더 의 탈중앙화 보장하기 위해 상태 만료가 여전히 필요할 수 있다는 것입니다.

그것은 무엇이며 어떻게 이루어 집니까?

오늘은 새 상태 객체를 생성할 때(세 가지 방법 중 하나로 수행할 수 있습니다: (i) ETH를 새 계정으로 보내기, (ii) 코드를 사용하여 새 계정 만들기, (iii) 이전에 사용하지 않은 스토리지 슬롯 설정, 상태 개체는 상태에 영구적으로 존재하며 우리가 원하는 것은 다음 세 가지 목표를 갖는 것입니다.

1. 효율성 : 만료 프로세스를 실행하는 데 추가 계산 비용이 대량 들지 않아야 합니다.
2. 사용자 친화성 : 누군가가 동굴에 들어갔다가 5년 후 다시 나타나더라도 ETH, ERC20 토큰, NFT, CDP 포지션 등과 같은 자산에 대한 액세스 권한을 잃지 않아야 합니다.
3. 개발자 친화성 : 개발자에게 완전히 익숙하지 않은 정신 모델로 전환하도록 요구해서는 안 됩니다. 또한 현재 강화되어 더 이상 업데이트되지 않는 애플리케이션은 계속해서 정상적으로 작동해야 합니다.

실제로 이러한 목표 달성에 대해 생각하지 않고 문제를 해결하는 것은 쉽습니다. 예를 들어, 각 상태 개체에 만료 날짜 카운터를 저장하도록 하고(읽거나 쓸 때마다 자동으로 수행될 수 있는 ETH를 파괴하여 만료를 연장할 수 있음) 만료된 상태 개체를 삭제하기 위해 상태를 순회하는 루프를 설정할 수 있습니다. . 프로세스. 그러나 이로 인해 추가 계산이 필요하고(심지어 스토리지 요구 사항도 증가) 사용자 친화성 요구 사항을 확실히 충족하지 못합니다. 저장된 값이 때때로 0으로 재설정되는 특수한 경우를 개발자가 처리하기 어려울 수도 있습니다. 만료 타이머가 계약 수준에서 설정되면 기술적으로는 개발자가 더 쉽게 할 수 있지만 경제적 측면에서는 더 많은 어려움이 발생합니다. 개발자는 지속적인 스토리지 비용을 사용자에게 "전가"하는 방법을 고려해야 합니다.

이러한 문제는 수년 동안 이더 핵심 개발 커뮤니티를 괴롭혔으며, 그 동안 "블록체인 임대" 및 "재생성"과 같은 제안이 등장했습니다. 궁극적으로 우리는 이러한 제안의 가장 좋은 부분을 결합하여 "가장 잘 알려지지 않은 최악의 시나리오"의 두 가지 범주에 도달했습니다.

• 부분 상태 만료 솔루션
• 주소주기 기반 상태 데이터 만료 메커니즘 제안

부분 상태 만료

모든 부분 상태 만료 제안은 동일한 원칙을 따릅니다. 상태 데이터를 여러 개의 청크로 나눕니다. 각각은 어떤 데이터 블록이 비어 있는지 또는 비어 있지 않은지 태그"최상위 매핑 테이블"을 영구적으로 저장합니다. 각 데이터 블록 내의 데이터는 최근에 액세스된 경우에만 저장됩니다. "활성화" 메커니즘도 있습니다. 즉, 데이터 블록이 더 이상 저장되지 않으면 누구나 데이터 증거를 제공하여 이를 복원할 수 있습니다.

이러한 제안 간의 주요 차이점은 (i) "단기"가 정의되는 방식과 (ii) "데이터 청크"가 정의되는 방식입니다. 구체적인 제안 중 하나는 Verkle 트리에 도입된 "줄기 및 잎" 설계를 기반으로 하는 EIP-7736입니다(비록 이진 트리와 같은 모든 형태의 무상태와 호환 가능하지만). 이 설계에서는 인접한 헤더, 코드 및 슬롯이 동일한 "스템" 아래에 저장됩니다. 각 스템에 저장되는 최대 데이터는 256 * 31 = 7,936바이트입니다. 대부분의 경우 계정의 전체 헤더, 코드 및 많은 키 저장 슬롯이 동일한 스템 아래에 저장됩니다. 줄기 아래의 데이터를 6개월 이내에 읽거나 쓰지 않으면 데이터는 더 이상 저장되지 않고 대신 32바이트 약정("스텁")만 저장됩니다. 이 데이터에 액세스하는 향후 트랜잭션은 데이터를 "활성화"하고 스텁과 비교하여 확인할 수 있는 증거를 제공해야 합니다.

유사한 아이디어를 구현하는 다른 방법이 있습니다. 예를 들어, 계정 수준 세분성이 충분하지 않은 경우 상태 트리의 각 1/232 부분이 유사한 줄기 및 잎 메커니즘으로 관리되도록 솔루션을 설계할 수 있습니다.

그러나 이 접근 방식은 인센티브 메커니즘의 구현을 더욱 어렵게 만듭니다. 공격자는 단일 하위 상태 트리에 대량 의 데이터를 저장한 다음 트랜잭션을 "업데이트"하도록 전송하여 클라이언트가 대량 의 상태를 영구적으로 저장하도록 강제할 수 있습니다. 상태 트리"를 매년 사용합니다. 업데이트 비용이 상태 트리의 크기에 비례하도록 설정된 경우(또는 업데이트 기간이 트리의 크기에 반비례), 공격자는 잠재적으로 동일한 하위 항목에 대량 의 데이터를 보관하여 다른 사용자를 괴롭힐 수 있습니다. 상태 트리. 하위 상태 트리의 크기를 기반으로 하는 동적 세분성으로 두 가지 문제를 모두 제한하려고 시도할 수 있습니다. 예를 들어 연속된 각 2^16 = 65536개 상태 개체는 "그룹"으로 간주될 수 있습니다. 그러나 이러한 아이디어는 더 복잡합니다. 이와 대조적으로 줄기 기반 접근 방식은 일반적으로 줄기 아래의 모든 데이터가 동일한 애플리케이션 또는 사용자와 관련되어 있기 때문에 간단하고 인센티브를 잘 조정할 수 있습니다.

주소주기 기반 상태 만료 메커니즘 제안

영구적인 상태 성장을 완전히 피하고 싶고 32바이트 스텁도 유지하고 싶지 않다면 어떻게 될까요? 활성화 충돌이 발생할 수 있기 때문에 이는 까다로운 문제입니다. 상태 개체가 제거되고 후속 EVM 실행이 정확히 동일한 위치에 다른 상태 개체를 배치한 다음 원래 상태 개체를 관리하는 사람이 돌아와서 복원을 시도한다고 가정합니다. 어떻게 될까요? 부분 상태 만료 시나리오에서 "스텁"은 새 데이터가 생성되는 것을 방지합니다. 그러나 완전한 상태 만료 체계에서는 스텁을 저장할 수도 없습니다.

주소 기간 기반 설계는 이 문제에 대한 가장 잘 알려진 솔루션입니다. 전체 상태를 저장하기 위해 상태 트리를 사용하는 대신 지속적으로 증가하는 상태 트리 목록을 유지하며 읽거나 쓴 모든 상태는 최신 상태 트리에 저장됩니다. 새로운 빈 상태 트리는 매 기간(예: 1년)마다 추가됩니다. 이전 상태 트리는 완전히 동결 되었습니다. 전체 노드는 가장 최근 상태 트리 두 개만 저장하면 됩니다. 상태 개체가 두 주기 동안 액세스되지 않아 만료된 상태 트리에 빠진 경우에도 읽거나 쓸 수 있지만 관련 트랜잭션은 이에 대한 Merkle 증명을 제공해야 합니다. 일단 입증되면 성공 시 복사본 상태는 최신 상태 트리에 다시 저장됩니다.

이 모든 것을 사용자와 개발자 친화적으로 만드는 핵심 개념은 "주소 주기"입니다. 주소 기간은 주소의 일부입니다. 핵심 규칙은 주소 기간이 N인 주소는 기간 N 동안이나 이후(즉, 상태 트리 목록 길이가 N에 도달할 때)에만 읽거나 쓸 수 있다는 것입니다. 새로운 상태 개체(예: 새 계약 또는 새 ERC20 잔액)를 저장하려면 주소 기간이 N 또는 N-1인 계약에 상태 개체를 넣어두기만 하면 됩니다. 해당 장소가 이전에 비어 있었다는 증거를 제공해야 합니다. 그러나 반면에 이전 주소 기간의 상태를 추가하거나 편집하려면 증거가 필요합니다.

이 설계는 추가 계산 오버헤드를 최소화하면서 이더 의 현재 기능 대부분을 유지하며 응용 프로그램을 현재와 거의 동일하게 작성할 수 있도록 합니다(단, 주소 기간 N과 주소의 잔액 저장되도록 하려면 ERC20을 다시 작성해야 합니다). 에서 주소 기간 N)도 있는 하청 계약에서 "사용자가 5년 동안 동굴에 입장했습니다"라는 문제를 해결합니다. 그러나 여기에는 심각한 문제가 있습니다. 주소 주기를 수용하려면 주소를 20바이트 이상으로 확장해야 합니다 .

주소 공간 확장

한 가지 제안은 버전 번호, 주소 기간 번호 및 확장된 해시 값을 포함하는 새로운 32바이트 주소 형식을 도입하는 것입니다.

빨간색 부분은 버전 번호입니다. 여기에 있는 4개의 주황색 0은 나중에 조각 번호를 저장하는 데 사용할 수 있는 예약된 공간입니다. 녹색 부분은 주소 기간 번호입니다. 파란색 부분은 26바이트 해시 값입니다.

여기서 중요한 과제는 이전 버전과의 호환성입니다. 기존 계약은 20바이트 주소를 기반으로 설계되었으며 주소 길이가 정확히 20바이트라고 명시적으로 가정하는 컴팩트 바이트 패킹 기술을 사용하는 경우가 많습니다. 이 문제를 해결하기 위한 한 가지 아이디어는 새 스타일 주소와 상호 작용하는 이전 스타일 계약이 새 스타일 주소의 20바이트 해시 값을 볼 수 있도록 변환 매핑 테이블을 사용하는 것입니다. 그러나 이 접근 방식의 보안을 보장하는 데에는 복잡한 문제가 많이 있습니다.

주소 공간 축소

또 다른 접근 방식은 반대입니다. 크기가 2^128인 주소의 하위 범위(예: 0xffffffff로 시작하는 모든 주소)를 즉시 비활성화한 다음 이 범위를 사용하여 주소 기간과 14바이트 해시를 포함하는 주소를 도입합니다.

이 접근 방식의 주요 비용은 자산이나 권한을 보유하지만 코드가 아직 온체인 에 게시되지 않은 주소인 반대 사실 주소 에 대한 보안 리스크 초래한다는 것입니다. 리스크 누군가가 (아직 공개되지 않은) 코드 조각을 소유한다고 주장하는 주소를 생성하면서 동시에 동일한 주소로 해시되는 또 다른 유효한 코드 조각을 가질 수 있다는 것입니다. 이러한 충돌을 계산하려면 현재 2^80개의 해시 작업이 필요합니다. 주소 공간 축소로 인해 이 숫자는 매우 달성 가능한 2^56개의 해시 작업으로 줄어듭니다.

주요 리스크 영역은 단일 소유자가 보유하지 않은 가상 주소가 있는 지갑입니다. 이는 오늘날 상대적으로 드문 상황이지만 다중 L2 세계로 진입하면서 이러한 상황이 더욱 일반화될 수 있습니다. 유일한 해결책은 이러한 리스크 받아들이고, 이 문제가 발생할 수 있는 모든 일반적인 사용 시나리오를 식별하고, 효과적인 회피 솔루션을 찾는 것입니다.

기존 연구와의 연관성은 무엇입니까?

초기 제안

• 블록체인 임대: https://github.com/ethereum/EIPs/issues/35
• 환생 제안 활성화(Regenesis): https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582

이더 상태 크기 관리 이론:

https://hackmd.io/@vbuterin/state_size_management

무국적 및 상태 만료를 달성할 수 있는 몇 가지 경로는 다음과 같습니다.

https://hackmd.io/@vbuterin/state_expiry_paths

부분적으로 만료된 제안서

EIP-7736: https://eips.ethereum.org/EIPS/eip-7736

주소 공간 확장 문서

• 원래 제안: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
• 입실론 리뷰: https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
• 블로그 게시물 리뷰: https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6

충돌 저항력 상실로 인해 어떤 문제가 발생합니까?

https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

앞으로 해야 할 일과 절충점은 무엇입니까?

나는 미래에 네 가지 가능한 경로를 봅니다.

상태 만료 메커니즘을 도입하지 않고 무상태를 구현합니다 . 상태 데이터는 계속해서 증가할 것입니다(비록 천천히: 아마도 수십 년 동안 8TB를 초과하지 않을 것임). 상대적으로 전문화된 사용자 그룹만 보유하면 됩니다. 지분 증명(PoS) 검증자도 상태를 보유할 필요가 없습니다. 상태의 일부에 액세스해야 하는 유일한 기능은 포함 목록을 생성하는 것 입니다. 그러나 우리는 이를 탈중앙화 방식으로 수행할 수 있습니다. 각 사용자는 자신의 계정이 포함된 상태 트리의 일부를 유지 관리할 책임이 있습니다. 사용자가 거래를 브로드캐스트하면 확인 단계에서 액세스한 상태 객체의 증명도 브로드캐스트됩니다(이는 외부 소유 계정 EOA 및 ERC-4337 계정에 적용됩니다). 그러면 무상태 검증자는 이러한 증명을 전체 목록이 포함된 증명으로 결합할 수 있습니다.

상당히 감소했지만 여전히 0이 아닌 영구 상태 크기 증가율을 허용하는 부분 상태 만료 메커니즘을 구현합니다. 이 결과는 P2P 네트워크와 관련된 기록 만료 제안의 상황과 거의 유사합니다. 각 클라이언트는 기록 데이터의 낮지만 고정된 비율을 저장해야 하므로 영구 기록 저장의 감소하지만 0이 아닌 증가율을 수용해야 합니다. .

상태 만료 메커니즘 과 주소 공간 확장을 동시에 구현합니다. 이 프로세스는 주소 형식 변환 방법이 실현 가능하고 안전한지 확인하기 위해 수년 동안 계속될 것이며, 여기에는 기존 애플리케이션에 대한 보안 보장도 포함됩니다.

상태 만료 메커니즘 과 주소 공간 축소를 동시에 구현합니다. 이 프로세스는 크로스체인 시나리오의 리스크 포함하여 주소 충돌과 관련된 모든 보안 리스크 해결되도록 수년 동안 계속될 것입니다.

중요한 관점 주소 공간 확장 및 축소와 관련된 이러한 까다로운 문제는 주소 형식 변경에 의존하는 상태 만료 체계의 구현 여부에 관계없이 결국 해결되어야 한다는 것입니다 . 현재 주소 충돌을 생성하려면 약 2^80개의 해시 작업이 필요하며 이 계산 부하는 리소스가 매우 충분한 행위자에게 이미 실현 가능합니다. GPU는 초당 약 2^27개의 해시 작업을 수행할 수 있으므로 2^52번 계산할 수 있습니다. 따라서 전 세계 약 2^30개의 GPU가 약 1/4년 안에 충돌을 계산할 수 있으며 FPGA와 ASIC은 이 속도를 더욱 가속화할 수 있습니다. 앞으로는 이러한 유형의 공격이 점점 더 많은 사람들에게 공개될 것입니다. 따라서 전체 상태 만료를 구현하는 데 드는 실제 비용은 보이는 것만큼 높지 않을 수 있습니다. 어쨌든 이 매우 어려운 주소 문제를 해결해야 하기 때문입니다.

로드맵의 다른 부분과 어떻게 상호 작용합니까?

상태 데이터 만료 메커니즘을 구현하면 변환 프로세스가 필요하지 않기 때문에 상태 트리 형식 간 변환이 더 쉬워질 수 있습니다. 새 형식으로 새 상태 트리를 직접 생성하고 나중에 하드 포크 를 통해 이전 상태 트리를 변환할 수 있습니다. 따라서 상태 데이터 만료 메커니즘은 복잡하지만 로드맵의 다른 측면을 단순화하는 데 이점을 제공합니다.

기능 정리

우리는 어떤 문제를 해결하려고 합니까?

보안, 접근성 및 신뢰할 수 있는 중립성을 위한 주요 전제 조건 중 하나는 단순성입니다. 프로토콜이 우아하고 단순하다면 취약점이 발생할 가능성이 줄어듭니다. 이는 또한 새로운 개발자가 어떤 부분에든 참여하고 작업할 수 있는 가능성을 높일 것입니다. 동시에, 이러한 단순성으로 인해 계약이 더 공정해지고 특수 이해관계의 영향에 더 저항할 가능성이 높아집니다. 불행히도 프로토콜은 다른 사회 시스템과 마찬가지로 시간이 지남에 따라 기본적으로 점점 더 복잡해집니다. 이더 점점 더 복잡해지는 블랙홀에 빠지는 것을 원하지 않는다면, 우리는 두 가지 중 하나를 수행해야 합니다: (i) 변경을 중단하고 프로토콜이 굳건해지도록 하십시오. (ii) 실제로 특정 기능을 제거하고 복잡성을 줄일 수 있어야 합니다. . 중간 경로도 가능합니다. 즉, 프로토콜 변경 횟수를 줄이면서 시간이 지남에 따라 복잡성을 어느 정도 줄이는 것입니다. 이 섹션에서는 복잡성을 줄이거나 제거하는 방법에 대해 설명합니다.

그것은 무엇이며 어떻게 이루어지나요 ?

프로토콜 복잡성을 줄이는 단일 대규모 솔루션은 없습니다. 문제의 본질은 작은 수정 사항이 많다는 것입니다.

다음은 거의 완료되었으며 다른 유사한 상황을 처리하기 위한 참조로 사용할 수 있는 예입니다. 즉, SELFDESTRUCT opcode를 제거하는 것입니다. SELFDESTRUCT opcode는 단일 블록 내에서 무제한 수의 저장소 슬롯을 수정할 수 있는 유일한 opcode이므로 클라이언트가 DoS 공격을 피하기 위해 더 많은 복잡성을 구현해야 합니다. 이 opcode의 원래 목적은 시간이 지남에 따라 상태 데이터 크기를 줄일 수 있도록 자발적인 상태 정리를 구현하는 것이었습니다. 그러나 실제로 그것을 사용하는 사람은 거의 없습니다. Dencun 하드 포크 에서는 동일한 거래에서 생성된 계정의 자체 파괴만 허용하도록 이 opcode가 약화되었습니다. 이는 DoS 문제를 해결하고 클라이언트 코드를 크게 단순화합니다. 앞으로는 이 opcode를 완전히 제거하는 것이 합리적일 수 있습니다.

지금까지 확인된 주요 프로토콜 단순화 기회 중 일부는 다음과 같습니다. 첫 번째는 EVM 외부의 몇 가지 예입니다. 이러한 변경 사항은 상대적으로 영향이 적으므로 단기적으로 동의하고 구현하기가 더 쉽습니다.

• RLP에서 SSZ로의 변환 : 처음에는 이더 개체가 RLP라는 인코딩을 사용하여 직렬화되었습니다. RLP는 유형이 없고 불필요하게 복잡합니다. 오늘날 비콘 체인은 직렬화뿐만 아니라 해싱도 지원하는 등 여러 측면에서 상당한 이점을 갖는 SSZ를 사용합니다. 우리는 결국 RLP에서 완전히 벗어나 모든 데이터 유형을 SSZ 구조로 변환하여 업그레이드를 더 쉽게 만들 수 있기를 바랍니다. 현재 관련 EIP 제안에는 다음이 포함됩니다. [1]https://eips.ethereum.org/EIPS/eip-6465[2]https://eips.ethereum.org/EIPS/eip-6465[3]https://eips .ethereum.org/EIPS/eip-6465
• 기존 거래 유형 제거 : 현재 거래 유형이 너무 많아 그 중 상당수를 제거할 수 있습니다. 완전한 제거에 대한 보다 온화한 대안은 스마트 계정이 필요에 따라 레거시 거래를 처리하고 검증하기 위한 코드를 선택적으로 포함할 수 있도록 하는 계정 추상화 기능을 도입하는 것입니다.
• 로깅 변환 : 로깅은 프로토콜에 복잡성을 추가하는 블룸 필터 및 기타 논리를 생성하지만 속도가 너무 느려 클라이언트가 실제로 사용하지 않습니다. 이러한 기능을 제거하고 대신 SNARK와 같은 최신 기술을 사용하는 오프 프로토콜 탈중앙화 로그 읽기 도구와 같은 대안 개발에 투자할 수 있습니다.
• 비콘 체인은 마침내 동기화 위원회 메커니즘을 제거합니다 . 동기화 위원회 메커니즘은 원래 이더 에서 라이트 클라이언트 검증을 가능하게 하기 위해 도입되었습니다. 그러나 이는 프로토콜에 상당한 복잡성을 추가합니다. 결국 우리는 SNARK를 사용하여 이더 컨센서스 레이어 직접 확인할 수 있게 되어 전문적인 라이트 클라이언트 확인 프로토콜이 필요하지 않게 될 것입니다. 합의 변경을 통해 우리는 이더 합의 검증자의 무작위 하위 집합 서명을 검증하는 것과 관련된 보다 "네이티브" 라이트 클라이언트 프로토콜을 생성함으로써 동기화 위원회를 더 일찍 제거할 수 있습니다.
• 통합 데이터 형식 : 현재 실행 상태는 Merkle Patricia 트리에 저장되고 합의 상태는 SSZ 트리에 저장되며 Blob은 KZG 커밋을 사용하여 커밋됩니다. 앞으로는 블록 데이터와 상태 데이터에 대해 별도의 통합 형식을 개발하는 것이 합리적일 것입니다. 이러한 형식은 (i) 상태 비저장 클라이언트에 대한 간단한 증명, (ii) 데이터 직렬화 및 삭제 코딩, (iii) 표준화된 데이터 구조 등 모든 중요한 요구 사항을 충족합니다.
• 비콘 체인 위원회 제거 : 이 메커니즘은 원래 특정 버전의 샤딩을 지원하기 위해 도입되었습니다. 그러나 결국 우리는 레이어 2 네트워킹 및 데이터 블록을 통해 샤딩을 구현했습니다. 결과적으로 위원회는 더 이상 필요하지 않으며 현재 위원회를 제거하기 위한 작업이 진행 중입니다.
• 혼합 엔디안 제거 : EVM은 빅엔디안 바이트 순서를 사용하는 반면 컨센서스 레이어 리틀엔디안 바이트 순서를 사용합니다. 모든 것을 엔디안 중 하나로 통합하고 통합하는 것이 합리적입니다(EVM은 변경하기가 더 어렵기 때문에 아마도 빅 엔디안일 것입니다).

이제 EVM 내의 몇 가지 예를 살펴보겠습니다.

• 가스 메커니즘의 단순화 : 현재 가스 규칙은 블록 검증에 필요한 자원의 양을 제한하는 측면에서 잘 최적화되어 있지 않습니다. 주요 예는 다음과 같습니다: (i) 블록의 읽기 및 쓰기 수를 제한해야 하지만 현재 상당히 무작위로 구현되는 저장 읽기 및 쓰기 비용 및 (ii) 현재 어려운 메모리 채우기 규칙; EVM을 추정합니다. 제안된 수정 사항에는 모든 스토리지 관련 비용을 간단한 공식으로 통합하는 상태 비저장 가스 비용 변경과 메모리 가격 책정에 대한 제안이 포함됩니다.
• 사전 컴파일된 계약 제거 : 현재 이더 의 사전 컴파일된 계약 중 상당수는 불필요하게 복잡하고 거의 사용되지 않으며 합의 실패 시 아차 실패의 상당 부분을 차지하지만 실제로 이를 사용하는 애플리케이션은 없습니다. 이 문제를 해결하는 방법에는 두 가지가 있습니다. (i) 사전 컴파일된 계약을 직접 제거하고, (ii) 동일한 로직을 구현하는 EVM 코드로 교체합니다(이로 인해 필연적으로 비용이 증가합니다). 이 초안 EIP는 루트 ID 사전 컴파일된 계약에 대해 먼저 수행할 것을 제안하며 그 후 RIPEMD 160, MODEXP 및 BLAKE가 제거 후보가 될 수 있습니다.
• 가스 관측성 제거 : EVM 실행 프로세스에서는 더 이상 남은 가스의 총량을 볼 수 없습니다. 이는 일부 응용 프로그램(주로 후원 거래)의 작동에 영향을 주지만 향후 업그레이드를 더 쉽게 만듭니다(예: 고급 버전의 다차원 가스). EOF 사양은 이미 가스를 관찰할 수 없게 만들었지만, 프로토콜 단순화를 위해서는 EOF가 필수 사양이 되어야 합니다.
• 정적 분석을 위한 최적화 : 현재 EVM 코드는 특히 점프(점프 코드)가 동적일 수 있기 때문에 정적으로 분석하기가 어렵습니다. 이는 또한 EVM 구현을 최적화하는 것을 더 어렵게 만듭니다(EVM 코드를 다른 언어로 미리 컴파일하여). 동적 점프를 제거하여(또는 계약의 총 JUMPDEST 수에 따라 가스 비용을 선형으로 만드는 등 비용을 더 높게 만들어) 이 문제를 해결할 수 있습니다. EOF는 이미 이를 달성했지만 프로토콜 단순화의 이점을 얻으려면 EOF를 시행해야 합니다.

기존 연구와의 연관성은 무엇입니까?

• 퍼지의 다음 단계: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• 계약 파기: https://hackmd.io/@vbuterin/selfdestruct
• SSZ 관련 EIPS:
  • https://eips.ethereum.org/EIPS/eip-6493
  • https://eips.ethereum.org/EIPS/eip-6466
  • https://eips.ethereum.org/EIPS/eip-6465
• 무상태 가스 비용 변경: https://eips.ethereum.org/EIPS/eip-4762
• 현재 메모리 가격: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• 사전 컴파일된 계약 제거: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• 블룸 필터 제거: https://eips.ethereum.org/EIPS/eip-7668
• 증분 검증 가능한 계산(예: 재귀적 STARK)을 사용한 오프체인 보안 로그 검색 방법: https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

앞으로 해야 할 일은 무엇이고 절충점은 무엇입니까 ?

이러한 기능 단순화를 수행할 때의 주요 장단점은 (i) 단순화 범위 및 속도 대 (ii) 이전 버전과의 호환성입니다. 블록체인으로서 이더 의 가치는 개발자가 애플리케이션을 배포하고 이러한 애플리케이션이 앞으로도 수년 동안 제대로 작동할 것이라는 확신을 가질 수 있는 플랫폼이라는 것입니다. 그러나 동시에 이러한 이상은 너무 지나칠 수도 있습니다. 윌리엄 제닝스 브라이언(William Jennings Bryan)의 말을 빌리자면 "이더리움을 하위 호환성의 십자가에 이더 박는 것"입니다. 전체 이더 에서 특정 기능을 사용하는 애플리케이션이 두 개뿐이고 그 중 하나는 수년 동안 사용자가 없었고 다른 하나는 거의 완전히 사용되지 않았으며 가치가 57달러만 잠겨 있는 경우 해당 기능을 제거해야 합니다. 필요한 경우 영향을 받은 사용자에게 57달러를 직접 지불할 수 있습니다.

더 광범위한 사회적 문제는 긴급하지 않고 이전 버전과 호환되지 않는 변경을 수행하기 위한 표준화된 프로세스를 구축하는 방법입니다. 한 가지 방법은 SELFDESTRUCT(계약 파기) 처리 프로세스 등 기존 선례를 연구하고 확장하는 것입니다. 프로세스는 대략 다음과 같습니다.

• 1단계: 기능 X 제거 논의 시작
• 2단계: 분석을 수행하여 X를 제거하고 앞으로 나아가기 위해 수정 사항을 제거하는 방법을 결정합니다.
• 3단계: X를 폐기하기 위한 공식 EIP를 제안합니다. 널리 사용되는 상위 인프라(예: 프로그래밍 언어, 지갑)가 이 변경 사항을 준수하는지 확인하고 이 기능 사용을 중지하세요.
• 4단계: 마지막으로 실제로 X를 제거합니다.

각 프로젝트의 현재 단계가 명확하게 표시된 1단계부터 4단계까지 다년간의 프로세스가 진행됩니다. 이 프로세스에서는 기능 제거 프로세스의 강도와 속도와 보다 보수적인 접근 방식을 취하고 프로토콜 개발의 다른 영역에 더 많은 리소스를 투자하는 것 사이에 균형이 있습니다. 그러나 우리는 아직 파레토 국경과는 거리가 멀다.

EOF

EOF(EVM Object Format)는 EVM에 대한 주요 변경 사항을 제안하는 세트입니다. EOF에는 가스 관측성 비활성화, 코드 관측성 비활성화(즉, CODECOPY를 허용하지 않음), 정적 점프만 허용 등과 같은 대량 변경 사항이 도입되었습니다. 목표는 이전 버전과의 호환성을 유지하면서 더 강력한 기능을 위해 EVM에 대한 더 많은 업그레이드를 가능하게 하는 것입니다(EVM의 EOF 이전 버전은 여전히 ​​존재하므로).

이 접근 방식의 장점은 새로운 EVM 기능을 추가하기 위한 자연스러운 경로를 제공하고 더 강력한 보장을 통해 더 엄격한 EVM으로의 마이그레이션을 장려한다는 것입니다. 단점은 결국 이전 버전의 EVM을 더 이상 사용하지 않고 제거할 수 있는 방법을 찾지 않는 한 프로토콜 복잡성이 크게 증가한다는 것입니다. 중요한 질문은 다음과 같습니다. 특히 전반적인 목표가 EVM 복잡성을 줄이는 것인 경우 EVM 단순화 제안에서 EOF가 어떤 역할을 합니까?

로드맵의 다른 부분과 어떻게 상호 작용합니까?

로드맵에 있는 많은 "최적화" 제안은 이전 기능을 단순화할 수 있는 기회이기도 합니다. 위의 예 중 일부를 반복하면 다음과 같습니다.

• 단일 슬롯 최종성으로 전환하면 위원회를 제거하고 경제 모델을 재구성하며 기타 지분 증명 관련 단순화를 수행할 수 있는 기회가 제공됩니다.
• 계정 추상화를 완벽하게 구현하면 모든 EOA를 대체할 수 있는 "기본 계정 EVM 코드" 조각으로 이동하여 기존 트랜잭션 처리 로직을 대량 제거할 수 있습니다.
• 이더 상태를 이진 해시 트리로 마이그레이션하면 SSZ의 새 버전과 조화를 이루어 모든 이더 데이터 구조를 동일한 방식으로 해시할 수 있습니다.

보다 급진적인 접근 방식은 프로토콜의 많은 부분을 계약 코드로 변환하는 것입니다.

보다 급진적인 이더 단순화 전략은 프로토콜 자체를 변경하지 않고 유지하면서 프로토콜 기능에서 계약 코드로 많은 부분을 이동하는 것입니다.

이 접근 방식의 가장 극단적인 버전은 이더 L1을 "기술적으로" 비콘 체인으로만 존재하게 하면서 최소한의 가상 머신(예: RISC-V, Cairo 또는 시스템 가상 머신에 대한 더 간단하고 전용 증명)을 도입하는 것입니다. 누구나 자신만의 롤업을 만들 수 있습니다. EVM은 이러한 롤업 중 첫 번째 롤업으로 전환됩니다. 흥미롭게도 이 결과는 2019-20년 실행 환경 제안과 완전히 일치하지만 SNARK를 사용하면 실제로 구현될 가능성이 훨씬 더 높아집니다.

면책조항: 블록체인 정보 플랫폼으로서 이 사이트에 게시된 기사는 작성자와 게스트 관점 만을 나타낼 뿐이며 Web3Caff의 입장과는 아무런 관련이 없습니다. 기사에 포함된 정보는 참고용일 뿐이며 투자 조언이나 제안을 구성하지 않습니다. 귀하가 위치한 국가 또는 지역의 관련 법률 및 규정을 준수하십시오.