원제: 이더리움 프로토콜의 가능한 미래, 5부: 퍼지
원작자: 비탈릭 부테린
원작: 오데일리 플래닛 데일리 남편분은 잘 계시나요?
10월 14일부터 이더리움 창립자 비탈릭 부테린(Vitalik Buterin)은 The Merge , The Surge , The Scourge , The Verge 부터 The Purge 의 최신 릴리스에 이르기까지 이더리움의 가능한 미래에 대한 논의를 연속적으로 발표해 왔습니다. 이더리움 메인넷의 향후 개발에 대한 Vitalik의 비전과 현재 직면한 문제를 해결하는 방법입니다.
병합: 참여 및 거래 확인 속도를 높이기 위해 PoS로 이동한 후 이더리움이 단일 슬롯 완결성을 개선하고 스테이킹 임계값을 낮춰야 할 필요성에 대해 논의했습니다.
The Surge: Ethereum 확장을 위한 다양한 전략, 특히 롤업 중심 로드맵과 확장성, 분산화 및 보안에 대한 과제와 솔루션을 탐구합니다.
The Scourge: PoS로의 전환에서 이더리움이 직면한 중앙화 및 가치 추출의 위험에 대해 논의하고, 분산화와 공정성을 강화하는 다양한 메커니즘을 개발하는 동시에 사용자 이익을 보호하기 위해 스테이킹 경제 개혁을 수행했습니다.
The Verge: Verkle 트리 및 STARK와 같은 기술이 어떻게 블록체인의 분산화 및 효율성을 향상시킬 수 있는지에 초점을 맞춰 이더리움의 무상태 검증에 대한 과제와 솔루션을 논의했습니다.
10월 26일, Vitalik Buterin은 The Purge에 대한 기사를 게재했습니다. 이 기사에서는 Ethereum이 직면한 과제가 장기적으로 복잡성과 저장 요구 사항을 줄이는 동시에 체인의 내구성과 분산화를 유지하는 것이 어떻게 클라이언트 저장 공간을 줄이는지에 대해 논의했습니다. History Expiration과 State Expiration을 통해 부담을 줄이고 Feature Cleaning을 통해 프로토콜을 단순화하여 네트워크의 지속 가능성과 확장성을 보장합니다.
다음은 오데일리플래닛데일리가 편집한 원본 내용이다.
피드백과 리뷰를 주신 Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden 및 Tomasz Stanczak에게 특별히 감사드립니다.
이더리움이 직면한 과제 중 하나는 기본적으로 모든 블록체인 프로토콜의 부풀림과 복잡성이 시간이 지남에 따라 증가한다는 것입니다. 이는 두 곳에서 발생합니다.
기록 데이터: 기록의 어느 시점에서든 이루어진 모든 거래와 생성된 모든 계정은 모든 클라이언트에 의해 영구적으로 저장되고 새 클라이언트에 의해 다운로드되어 네트워크에 완전히 동기화되어야 합니다. 이로 인해 체인 용량이 일정하게 유지되더라도 시간이 지남에 따라 클라이언트 로드 및 동기화 시간이 증가합니다.
프로토콜 기능: 기존 기능을 제거하는 것보다 새로운 기능을 추가하는 것이 훨씬 쉬우므로 시간이 지남에 따라 코드 복잡성이 증가합니다.
이더리움이 장기적으로 유지되려면 두 가지 추세에 대한 강력한 대응 압력이 필요하며 시간이 지남에 따라 복잡성과 팽창을 줄여야 합니다. 그러나 동시에 우리는 블록체인을 훌륭하게 만드는 핵심 속성 중 하나인 지속성을 보존해야 합니다. NFT, 거래 호출 데이터에 러브레터, 체인에 100만 달러가 포함된 스마트 계약을 넣고 10년 동안 동굴에 들어가 보면 여전히 거기에서 읽고 상호 작용할 때까지 기다리고 있음을 발견할 수 있습니다. . DApp이 완전히 분산되고 업그레이드 키를 제거하는 데 편안함을 느끼려면 종속성이 특히 L1 자체를 손상시키는 방식으로 업그레이드되지 않을 것이라는 확신이 있어야 합니다.
우리가 이 두 가지 요구 사항 사이의 균형을 맞추고 연속성을 유지하면서 부풀림, 복잡성 및 쇠퇴를 최소화하거나 반전시키겠다고 결심한다면 그것은 절대적으로 가능합니다. 유기체는 이것을 할 수 있습니다. 대부분의 유기체는 시간이 지남에 따라 노화되지만 운이 좋은 소수는 그렇지 않습니다 . 사회 시스템조차도 수명이 매우 길 수 있습니다 . 어떤 경우에는 이더리움이 성공했습니다. 작업 증명이 사라졌고, SELFDESTRUCT opcode가 대부분 사라졌으며, 비콘 체인 노드는 최대 6개월치의 오래된 데이터를 저장해 왔습니다. 보다 일반적인 방식으로 이더리움의 경로를 찾고 장기적인 안정성이라는 최종 결과를 찾는 것은 이더리움의 장기적인 확장성, 기술적 지속 가능성, 심지어 보안에 대한 궁극적인 과제입니다.
퍼지: 주요 목표.
각 노드가 모든 기록 또는 최종 상태를 영구적으로 저장할 필요성을 줄이거나 제거하여 클라이언트 스토리지 요구 사항을 줄입니다 .
불필요한 기능을 제거하여 프로토콜 복잡성을 줄입니다.
기사 디렉토리:
기록 만료
어떤 문제가 해결되었나요?
이 글을 쓰는 시점에서 완전히 동기화된 Ethereum 노드에는 실행 클라이언트를 위해 약 1.1TB 의 디스크 공간이 필요하고 합의 클라이언트를 위해 추가로 수백 GB의 디스크 공간이 필요합니다. 그 중 대부분은 역사적입니다. 과거 블록, 거래, 영수증에 대한 데이터는 대부분 수년이 지났습니다. 이는 가스 한도가 전혀 증가하지 않더라도 노드 크기가 매년 수백 GB씩 계속 증가한다는 것을 의미합니다.
그것은 무엇이며 어떻게 작동합니까?
히스토리 저장 문제의 핵심 단순화 기능은 각 블록이 해시 링크(및 기타 구조 )를 통해 이전 블록을 가리키기 때문에 현재에 대한 합의가 히스토리에 대한 합의를 달성하기에 충분하다는 것입니다. 네트워크가 최신 블록에 대한 합의에 도달하는 한, 모든 기록 블록이나 거래 또는 상태(계정 잔액, 논스, 코드, 저장)는 Merkle 증명을 통해 모든 단일 참가자에 의해 제공될 수 있으며, 증명을 통해 다른 사람이 이를 확인할 수 있습니다. 단정. 합의는 N/2-N 신뢰 모델인 반면, 역사는 N-of-N 신뢰 모델 입니다.
이는 기록을 저장하는 방법에 대한 많은 옵션을 제공합니다. 자연스러운 선택은 각 노드가 데이터의 작은 부분만 저장하는 네트워크입니다. 이것이 수십 년 동안 토렌트 네트워크가 작동한 방식입니다. 네트워크는 총 수백만 개의 파일을 저장하고 배포하지만 각 참가자는 그 중 일부만 저장하고 배포합니다. 아마도 직관에 어긋나는 것처럼 이 접근 방식이 반드시 데이터의 견고성을 떨어뜨리는 것은 아닙니다. 각 노드가 무작위로 10%의 기록을 저장하는 노드 실행을 더욱 경제적으로 만들어 100,000개 노드의 네트워크를 구축할 수 있다면 각 데이터 조각은 10,000번 복제됩니다. 대 10,000번 복제됩니다. 정확히 동일합니다. 노드 네트워크이며 각 노드는 모든 것을 저장합니다.
오늘날 이더리움은 모든 기록을 영구적으로 저장하는 모든 노드 모델에서 벗어나기 시작했습니다. 합의 블록(즉, 지분 증명 합의와 관련된 부분)은 약 6개월 동안만 저장됩니다. Blob은 약 18일 동안만 저장됩니다. EIP-4444는 과거 블록 및 영수증에 대한 1년 저장 기간을 도입하는 것을 목표로 합니다. 장기적인 목표는 각 노드가 모든 것을 저장하는 통일된 기간(약 18일 정도)을 설정한 다음 이더리움 노드의 P2P 네트워크를 구축하여 오래된 데이터를 분산 네트워크 방식으로 저장하는 것입니다.
삭제 코드를 사용하면 복제 요소를 동일하게 유지하면서 견고성을 높일 수 있습니다. 실제로 Blob은 데이터 가용성 샘플링을 지원하기 위해 이미 삭제 코딩되어 있습니다. 가장 간단한 해결책은 아마도 이러한 삭제 코드를 재사용하고 실행 및 합의 블록 데이터도 Blob에 넣는 것입니다.
기존 연구와의 연관성은 무엇입니까?
그 밖에 무엇을 해야 하고, 어떤 절충안을 마련해야 합니까?
남은 주요 작업은 기록(최소한 실행 기록은 물론 합의 및 블롭도 저장)을 저장하기 위한 구체적인 분산 솔루션을 구축하고 통합하는 것으로 구성됩니다. 가장 간단한 솔루션은 (i) 단순히 기존 토렌트 라이브러리를 가져오고 (ii) 포털 네트워크 라고 불리는 Ethereum 기반 솔루션을 사용하는 것입니다. 이들 중 하나라도 도입되면 EIP-4444를 열 수 있습니다. EIP-4444 자체에는 하드포크가 필요하지 않지만 새로운 네트워크 프로토콜 버전이 필요합니다. 따라서 모든 클라이언트에 대해 동시에 활성화하는 것이 좋습니다. 그렇지 않으면 전체 기록을 다운로드하려고 했지만 실제로 가져오지 못해 다른 노드에 연결하여 클라이언트가 실패할 위험이 있습니다.
주요 절충점은 고대 과거 데이터를 제공하기 위해 노력하는 방법과 관련이 있습니다. 가장 간단한 해결책은 내일 고대 역사 저장을 중단하고 기존 아카이브 노드와 다양한 중앙 집중식 복제 공급자에 의존하는 것입니다. 쉽지만 영구적인 기록 장소로서의 이더리움의 지위를 약화시킵니다. 더 어렵지만 안전한 방법은 먼저 토렌트 네트워크를 구축하고 통합하여 기록을 분산 방식으로 저장하는 것입니다. 여기서 우리가 얼마나 열심히 노력하는가에는 두 가지 차원이 있습니다.
가장 큰 노드 집합이 실제로 모든 데이터를 저장하도록 하려면 어떻게 해야 할까요?
기록 저장소를 프로토콜에 얼마나 깊이 통합합니까?
(1)에 대한 극도로 편집증적인 접근 방식에는 에스크로 증명이 포함됩니다. 즉, 각 지분 증명 유효성 검사기가 일정 비율의 기록을 저장하고 정기적으로 암호화 방식으로 그렇게 하는지 확인하도록 요구하는 것입니다. 보다 겸손한 접근 방식은 각 클라이언트가 저장하는 기록의 비율에 대한 자발적인 표준을 설정하는 것입니다.
(2)의 경우 기본 구현에는 오늘 완료된 작업만 포함됩니다. Portal은 이미 Ethereum의 전체 기록이 포함된 ERA 파일을 저장합니다. 보다 철저한 구현에는 실제로 동기화 프로세스에 연결하는 것이 포함되므로 누군가가 전체 기록 스토리지 노드 또는 아카이브 노드를 동기화하려는 경우 다른 아카이브 노드가 없더라도 포털 네트워크에서 직접 동기화하여 그렇게 할 수 있습니다. 온라인.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
노드를 매우 쉽게 실행하거나 시작하려면 기록 스토리지 요구 사항을 줄이는 것이 상태 비저장보다 더 중요합니다. 노드에 필요한 1.1TB 중에서 ~300GB가 상태이고 나머지 ~800GB가 기록입니다. 무국적 및 EIP-4444를 구현해야만 스마트 워치에서 이더리움 노드를 실행하고 설정하는 데 몇 분 밖에 걸리지 않는다는 비전이 실현될 수 있습니다.
또한 기록 저장을 제한하면 최신 Ethereum 노드 구현이 최신 버전의 프로토콜만 지원하는 것이 더 쉬워지므로 더 간단해집니다. 예를 들어, 2016년 DoS 공격 중에 생성된 빈 저장소 슬롯이 모두 제거 되었으므로 이제 많은 코드 줄을 안전하게 제거할 수 있습니다. 이제 지분 증명으로의 전환이 이루어졌으므로 고객은 모든 작업 증명 관련 코드를 안전하게 제거할 수 있습니다.
주 만료
어떤 문제가 해결되었나요?
클라이언트가 기록을 저장할 필요성을 제거하더라도 계정 잔액 및 임시값, 계약 코드 및 계약 스토리지 등 상태가 계속 증가함에 따라 클라이언트 스토리지 요구 사항은 연간 약 50GB로 계속 증가할 것입니다. 사용자는 일회성 수수료를 지불하여 현재와 미래의 Ethereum 고객에게 영원히 부담을 줄 수 있습니다.
상태는 기록보다 만료하기가 더 어렵습니다. 왜냐하면 EVM은 기본적으로 상태 개체가 생성되면 항상 존재하고 언제든지 모든 트랜잭션에서 읽을 수 있다는 가정을 중심으로 설계되었기 때문입니다. 어떤 사람들은 우리가 무상태를 도입하면 이 문제가 그리 나쁘지 않을 것이라고 주장합니다. 전용 블록 빌더 클래스만 실제로 상태를 저장해야 하고 다른 모든 노드(심지어 목록 생성도!)는 무상태로 실행될 수 있습니다. 그러나 우리는 무국적에 너무 많이 의존하고 싶지 않으며 결국 이더리움을 분산화하기 위해 상태를 만료시키고 싶을 수도 있다는 주장이 있습니다.
그것이 무엇이며 어떻게 작동하는지
오늘, 새로운 상태 개체를 생성할 때(세 가지 방법 중 하나로 발생할 수 있습니다: (i) ETH를 새 계정으로 보내기, (ii) 코드를 사용하여 새 계정 만들기, (iii) 이전에 변경되지 않은 저장소 슬롯 설정) 상태 객체는 항상 이 상태입니다. 대신 우리가 원하는 것은 시간이 지남에 따라 객체가 자동으로 만료되는 것입니다. 핵심 과제는 다음 세 가지 목표를 달성하는 방식으로 이를 수행하는 것입니다.
효율성: 만료 프로세스를 실행하는 데 광범위한 추가 계산이 필요하지 않습니다.
사용자 친화성: 누군가가 5년 동안 동굴에 들어갔다가 돌아오더라도 ETH, ERC 20, NFT, CDP 포지션에 대한 액세스 권한을 잃어서는 안 됩니다.
개발자 친화성: 개발자는 완전히 익숙하지 않은 정신 모델로 전환할 필요가 없습니다. 또한 현재 골화되어 업데이트되지 않은 응용 프로그램은 계속해서 정상적으로 작동해야 합니다.
이러한 목표를 달성하지 못하면 쉽게 문제가 발생할 수 있습니다. 예를 들어, 각 상태 개체에 만료 날짜 카운터도 저장하도록 할 수 있으며(읽기 또는 쓰기가 이루어질 때마다 자동으로 발생할 수 있는 ETH를 소각하여 만료 날짜를 연장할 수 있음) 루프를 상태에 대해 반복하여 제거하도록 할 수 있습니다. 만료 날짜 프로세스 상태 개체입니다. 그러나 이로 인해 추가 계산(및 저장 요구 사항)이 발생하며 확실히 사용자 친화성 요구 사항을 충족하지 않습니다. 개발자가 저장된 값이 때때로 0으로 재설정되는 극단적인 경우에 대해 추론하는 것도 어렵습니다. 계약 내에서 만료 타이머를 설정하면 기술적으로 개발자의 삶이 더 쉬워지지만 경제적 측면은 더욱 어려워집니다. 개발자는 지속적인 스토리지 비용을 사용자에게 전가하는 방법에 대해 생각해야 합니다.
이는 블록체인 임대 및 재생 과 같은 제안을 포함하여 이더리움 핵심 개발 커뮤니티가 수년 동안 고심해 온 문제입니다. 궁극적으로 우리는 제안의 가장 좋은 부분을 결합하고 가장 잘 알려지지 않은 최악의 솔루션의 두 가지 범주에 중점을 두었습니다.
부분 상태 만료 솔루션
주소 기간을 기준으로 한 상태 만료 권장 사항입니다.
부분 상태 만료 부분 상태 만료
부분 상태 만료 제안은 모두 동일한 원칙을 따릅니다. 우리는 상태를 덩어리로 나눕니다. 모든 사람은 비어 있거나 비어 있지 않은 블록의 최상위 맵을 영구적으로 저장합니다. 각 블록의 데이터는 최근에 데이터에 액세스한 경우에만 저장됩니다. 더 이상 저장되지 않으면 부활 메커니즘이 있습니다.
이러한 제안 간의 주요 차이점은 다음과 같습니다. (i) 가장 가까운을 어떻게 정의합니까, (ii) 청크를 어떻게 정의합니까? 구체적인 제안 중 하나는 EIP-7736 입니다. 이는 Verkle 트리에 도입된 줄기 잎 디자인을 기반으로 합니다(비록 이진 트리와 같은 모든 형태의 무상태 상태와 호환 가능). 이 설계에서는 서로 인접한 헤더, 코드 및 슬롯이 동일한 트렁크에 저장됩니다. 스템에 저장되는 최대 데이터 양은 256 * 31 = 7,936바이트입니다. 대부분의 경우 계정의 전체 헤더와 코드는 동일한 트렁크와 많은 키 저장 슬롯에 저장됩니다. 특정 트렁크의 데이터를 6개월 동안 읽거나 쓰지 않으면 해당 데이터는 더 이상 저장되지 않고 해당 데이터의 32바이트 약정(스텁)만 저장됩니다. 이 데이터에 액세스하는 향후 트랜잭션은 데이터를 부활하고 스텁에 대한 검사 증거를 제공해야 합니다.
유사한 아이디어를 구현하는 다른 방법이 있습니다. 예를 들어, 계정 수준의 세분성이 충분하지 않은 경우 트리의 각 1/2 32 부분이 유사한 줄기 및 잎 메커니즘으로 제어되는 체계를 개발할 수 있습니다.
이는 인센티브로 인해 더욱 까다로워집니다. 공격자는 많은 데이터를 단일 하위 트리에 넣고 매년 단일 트랜잭션을 보내 클라이언트가 많은 상태를 영구적으로 저장하도록 함으로써 트리를 업데이트할 수 있습니다. 갱신 비용을 트리 크기에 비례하거나 갱신 기간에 반비례하도록 설정하면 누군가가 동일한 하위 트리에 많은 데이터를 넣어 다른 사용자에게 피해를 줄 수 있습니다. 하위 트리 크기에 따라 세분성을 동적으로 만들어 두 가지 문제를 모두 제한하려고 시도할 수 있습니다. 예를 들어, 각각의 연속적인 2 16 = 65536 상태 개체는 그룹으로 간주될 수 있습니다. 그러나 이러한 아이디어는 더 복잡합니다. 스템 기반 접근 방식은 일반적으로 스템 아래의 모든 데이터가 동일한 애플리케이션 또는 사용자와 관련되어 있기 때문에 간단하고 인센티브를 조정할 수 있습니다.
주소 기간에 따른 주 만료 권장 사항
32바이트 스텁이라도 영구적인 상태 증가를 완전히 방지하려면 어떻게 해야 할까요? 부활 충돌 로 인해 다음과 같은 어려운 질문이 있습니다. 하나의 상태 개체가 삭제되고 나중에 EVM 실행이 다른 상태 개체를 정확히 동일한 위치에 배치했지만 원래 상태 개체에 관심이 있는 누군가가 돌아와서 이를 복원하려고 하면 어떻게 될까요? 스터빙은 상태의 일부가 만료될 때 새 데이터가 생성되는 것을 방지합니다. 상태가 완전히 만료되면 스텁을 저장할 수도 없습니다.
이러한 문제를 해결하기 위한 가장 잘 알려진 아이디어는 주소주기 기반 설계이다. 전체 상태를 저장하기 위해 하나의 상태 트리를 사용하는 대신 점점 늘어나는 상태 트리 목록을 갖게 되며 읽거나 쓴 모든 상태는 최신 상태 트리에 저장됩니다. 새로운 빈 상태 트리는 매 기간(예: 1년)마다 추가됩니다. 오래된 나무들은 완전히 얼어붙었습니다. 전체 노드는 가장 가까운 두 개의 트리만 저장합니다. 상태 객체가 두 주기 동안 건드리지 않아 만료 트리에 빠진 경우에도 읽거나 쓸 수 있지만 트랜잭션은 Merkle 증명을 증명해야 합니다. 일단 증명되면 사본은 늦어도 나무.
이를 사용자와 개발자 모두 친화적으로 만드는 핵심 아이디어는 주소 주기 개념입니다. 주소 기간은 주소의 일부인 숫자입니다. 핵심 규칙은 주소 기간이 N인 주소는 기간 N 동안이나 이후(즉, 상태 트리 목록이 길이 N에 도달할 때)에만 읽거나 쓸 수 있다는 것입니다. 새로운 상태 개체(예: 새 계약 또는 새 ERC 20 잔액)를 저장하려는 경우 해당 상태 개체를 주소 기간이 N 또는 N-1인 계약에 반드시 넣어두면 저장할 수 있습니다. 이전에 아무 일도 없었다는 증거를 제시하지 않고 즉시 수행하십시오. 반면, 이전 주소 기간 동안 이루어진 추가 또는 편집에는 증거가 필요합니다.
이 설계는 이더리움의 현재 속성을 대부분 유지하고 추가 계산이 필요하지 않아 애플리케이션을 지금과 거의 동일하게 작성할 수 있습니다. (주소 기간 N이 있는 주소 잔액이 하도급 계약에 저장되도록 ERC 20을 다시 작성해야 하며, 자체적으로 주소가 있습니다. 기간 N)은 사용자가 5년 동안 동굴에 있었다는 문제를 해결합니다. 그러나 주소주기에 맞게 주소를 20바이트 이상으로 확장해야 한다는 큰 문제가 있습니다.
주소 공간 확장 주소 공간 확장
한 가지 제안은 버전 번호, 주소 기간 번호 및 확장된 해시를 포함하는 새로운 32바이트 주소 형식을 도입하는 것입니다.
0x 01 (빨간색) 0000(주황색) 000001(녹색) 57 AE 408398 dF 7 이자형 5 에프 4552091 에이 69125 d5 FC 7 비 8 기음 2659029395 bdF(파란색).
빨간색은 버전 번호입니다. 여기에 있는 4개의 주황색 0은 향후 샤드 번호를 수용할 수 있는 빈 공간을 의미합니다. 녹색은 주소 사이클 번호입니다. 파란색은 26바이트 해시 값입니다.
여기서 중요한 과제는 이전 버전과의 호환성입니다. 기존 계약은 약 20바이트 주소로 설계되었으며 주소 길이가 정확히 20바이트라고 명시적으로 가정하여 엄격한 바이트 패킹 기술을 사용하는 경우가 많습니다. 이 문제를 해결하기 위한 한 가지 아이디어는 새 스타일 주소와 상호 작용하는 이전 스타일 계약이 새 스타일 주소의 20바이트 해시를 볼 수 있는 변환 매핑을 포함합니다. 그러나 보안을 보장하는 데는 상당한 복잡성이 있습니다.
주소 공간 축소
또 다른 접근 방식은 반대 방향을 취합니다. 즉, 일부 2,128 크기의 주소 하위 범위(예: 0x ffffffff로 시작하는 모든 주소)를 즉시 금지한 다음 해당 범위를 사용하여 주소 마침표와 14바이트 해시가 있는 주소를 도입합니다.
0x ffffffff 000169125 d5 FC 7 비 8 C2659029395bdF
이 접근 방식의 주요 희생은 자산이나 권한을 보유하지만 코드가 아직 체인에 게시되지 않은 주소인 반사실적 주소의 보안 위험이 발생한다는 것 입니다. 위험은 누군가가 (아직 출시되지 않은) 코드를 소유한다고 주장하지만 동일한 주소에 해시된 또 다른 유효한 코드 조각을 가지고 있는 주소를 생성하는 것과 관련됩니다. 오늘날 이러한 충돌을 계산하려면 280개의 해시가 필요합니다. 주소 공간 축소로 인해 이 숫자는 쉽게 액세스할 수 있는 256개의 해시로 줄어듭니다.
주요 위험 영역인 한 명 이상의 소유자가 보유한 지갑에 대한 반사실적 주소는 오늘날 상대적으로 드물지만 다중 L2 세계로 이동함에 따라 더욱 일반화될 가능성이 높습니다. 유일한 해결책은 이 위험을 단순히 받아들이되 문제가 발생할 수 있는 모든 일반적인 사용 사례를 식별하고 효과적인 해결 방법을 찾는 것입니다.
기존 연구와의 연관성은 무엇입니까?
초기 제안
부분 상태 만료 제안
EIP-7736 ;
주소 공간 확장 문서
그 밖에 무엇을 해야 하고, 어떤 절충안을 마련해야 합니까?
나는 미래에 네 가지 가능한 경로가 있다고 생각합니다.
우리는 무국적이며 상태 만료를 도입하지 않습니다. 상태는 성장하고 있지만(느리게도: 아마도 수십 년 동안 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 변환: 처음에는 Ethereum 객체가 RLP 라는 인코딩을 사용하여 직렬화되었습니다. RLP는 유형이 없고 불필요하게 복잡합니다. 오늘날 비콘 체인은 직렬화뿐만 아니라 해싱 지원을 포함하여 여러 면에서 훨씬 더 나은 SSZ 를 사용합니다. 결국 우리는 RLP를 완전히 제거하고 모든 데이터 유형을 SSZ 구조로 이동하여 업그레이드를 더 쉽게 할 수 있기를 바랍니다. 현재 EIP에는 [1] [2] [3] 이 포함됩니다.
기존 거래 유형 제거: 현재 거래 유형이 너무 많아 그 중 상당수가 삭제될 수 있습니다. 완전한 제거에 대한 보다 가벼운 대안은 계정 추상화 기능입니다. 이를 통해 스마트 계정은 원하는 경우 레거시 거래를 처리하고 확인하는 코드를 포함할 수 있습니다.
로그 개혁: 로그는 프로토콜의 복잡성을 증가시키는 블룸 필터 및 기타 로직을 생성하지만 너무 느리기 때문에 실제로 클라이언트에서 사용되지 않습니다. 이러한 기능을 제거 하고 대신 SNARK와 같은 최신 기술을 사용하는 오프 프로토콜 분산 로그 읽기 도구와 같은 대안을 사용할 수 있습니다.
비콘 체인 동기화 위원회 메커니즘이 마침내 제거되었습니다. 동기화 위원회 메커니즘은 원래 이더리움의 라이트 클라이언트 검증을 가능하게 하기 위해 도입되었습니다. 그러나 이는 프로토콜의 복잡성을 크게 증가시킵니다. 결국 우리는 SNARK를 사용하여 이더리움 합의 계층을 직접 확인할 수 있게 될 것이며, 이를 통해 전용 라이트 클라이언트 확인 프로토콜이 필요하지 않게 될 것입니다. 잠재적으로 합의에 대한 변경을 통해 Ethereum 합의 유효성 검사기의 무작위 하위 집합에서 서명을 검증하는 보다 네이티브 라이트 클라이언트 프로토콜을 생성하여 동기화 위원회를 더 일찍 제거할 수 있습니다.
통합 데이터 형식: 오늘날 실행 상태는 Merkle Patricia 트리에 저장되고 합의 상태는 SSZ 트리 에 저장되며 Blob은 KZG 약속을 통해 커밋됩니다. 미래에는 블록 데이터에 대한 단일 통합 형식과 상태에 대한 단일 통합 형식을 갖는 것이 합리적일 것입니다. 이러한 형식은 (i) 상태 비저장 클라이언트의 간단한 증명, (ii) 데이터의 직렬화 및 삭제 코딩, (iii) 표준화된 데이터 구조 등 모든 중요한 요구 사항을 충족합니다.
비콘 체인 위원회 제거: 이 메커니즘은 원래 실행 샤딩의 특정 버전을 지원하기 위해 도입되었습니다. 대신 L2 및 blob을 통해 샤딩을 완료합니다. 따라서 위원회는 불필요하며 이를 제거하기 위한 조치가 취해지고 있습니다 .
혼합 엔디안 제거: EVM은 빅 엔디안이고 합의 계층은 리틀 엔디안입니다. 모든 것을 어떤 식으로든 재조화하고 만드는 것이 합리적일 수 있습니다(EVM은 변경하기가 더 어렵기 때문에 아마도 빅 엔디안일 것입니다).
이제 EVM의 몇 가지 예를 살펴보겠습니다.
가스 메커니즘의 단순화: 현재 가스 규칙은 잘 최적화되지 않았으며 블록을 검증하는 데 필요한 리소스 수에 대한 명확한 제한을 제공할 수 없습니다. 이에 대한 주요 예로는 (i) 블록의 읽기/쓰기 수를 제한하도록 설계되었지만 현재는 상당히 임의적인 스토리지 읽기/쓰기 비용과 (ii) 현재 최대값을 추정하기 어려운 메모리 채우기 규칙이 있습니다. EVM의 메모리 소비. 제안된 수정 사항에는 모든 스토리지 관련 비용을 간단한 공식과 메모리 가격 제안 으로 통합하는 상태 비저장 가스 비용 변경이 포함됩니다.
사전 컴파일 제거: 현재 이더리움이 갖고 있는 사전 컴파일 중 다수는 불필요하게 복잡하고, 상대적으로 사용되지 않으며, 합의 실패의 상당 부분을 차지하지만 어떤 애플리케이션에서도 거의 사용되지 않습니다. 이 문제를 해결하는 두 가지 방법은 (i) 사전 컴파일을 제거하는 것과 (ii) 동일한 로직을 구현하는 (필연적으로 더 비싼) EVM 코드로 바꾸는 것입니다. EIP 초안에서는 나중에 첫 번째 단계로 ID 사전 컴파일을 위해 이 작업을 수행할 것을 권장합니다 . RIPEMD 160, MODEXP 및 BLAKE는 제거 후보가 될 수 있습니다.
가스 관측성 제거: EVM 실행 시 가스가 얼마나 남았는지 더 이상 확인할 수 없도록 만듭니다. 이로 인해 일부 응용 프로그램(주로 후원 계약)이 중단되지만 향후 업그레이드가 더 쉬워집니다(예: 차원 간 가스 의 고급 버전). EOF 사양은 이미 가스를 관찰할 수 없게 만들었지만 프로토콜을 단순화하려면 EOF가 필수가 되어야 합니다.
정적 분석 개선: 오늘날의 EVM 코드는 특히 점프가 동적일 수 있기 때문에 정적으로 분석하기가 어렵습니다. 이는 또한 EVM 구현 최적화(EVM 코드를 다른 언어로 사전 컴파일)를 더욱 어렵게 만듭니다. 동적 점프를 제거 하여 이 문제를 해결할 수 있습니다(또는 계약의 총 JUMPDEST 수에 대한 가스 비용이 선형으로 변하는 등 비용을 더 비싸게 만들 수 있음). EOF가 바로 그런 일을 합니다. 하지만 프로토콜 단순화의 이점을 얻으려면 EOF를 시행해야 합니다.
기존 연구와의 연관성은 무엇입니까?
블룸 필터 제거 ;
그 밖에 무엇을 해야 하고, 어떤 절충안을 마련해야 합니까?
이 기능을 단순화할 때의 주요 절충점은 (i) 단순화의 범위와 속도 대 (ii) 이전 버전과의 호환성입니다. 체인으로서의 이더리움의 가치는 애플리케이션을 배포할 수 있고 몇 년 후에도 여전히 작동할 것이라는 확신을 가질 수 있는 플랫폼이라는 사실에서 비롯됩니다. 동시에, 이 이상은 너무 멀리 갈 수 있으며 William Jennings Bryan의 말에 따르면 이더리움을 이전 버전과의 호환성의 십자가에 못 박습니다. 전체 이더리움에서 특정 기능을 사용하는 애플리케이션이 단 두 개 있고, 그 중 하나는 수년간 사용자가 없었고, 다른 하나는 거의 완전히 사용되지 않았으며 총 57달러의 가치를 얻었다면 해당 기능을 제거해야 합니다. 필요한 경우 피해자의 주머니에서 $57를 지불하십시오.
더 광범위한 사회적 문제는 긴급하지 않은 이전 버전과의 호환성을 깨뜨리는 변경을 수행하기 위한 표준화된 파이프라인을 만드는 것입니다. 이 문제에 접근하는 한 가지 방법은 자기 파괴 과정과 같은 기존 선례를 조사하고 확장하는 것입니다. 파이프라인은 다음과 같습니다.
기능 X 제거에 대해 이야기해 보세요.
제거 및 지속의 영향을 확인하기 위한 분석을 수행합니다.
X를 더 이상 사용하지 않는 공식 EIP를 개발합니다. 널리 사용되는 상위 인프라(예: 프로그래밍 언어, 지갑)가 이를 존중하고 이 기능의 사용을 중지하는지 확인하세요. ;
마지막으로 실제로 X를 삭제합니다.
1단계와 4단계 사이에는 어떤 프로젝트가 어느 단계에 있는지에 대한 명확한 지침과 함께 다년간의 파이프라인이 있어야 합니다. 이 시점에서는 기능 제거 프로세스의 역동성과 속도와 보다 보수적으로 프로토콜 개발의 다른 영역에 더 많은 리소스를 할당하는 것 사이에 균형이 있지만 여전히 파레토 경계에서는 멀리 떨어져 있습니다.
EOF
EVM에 대해 제안된 주요 변경 사항 중 하나는 EVM 개체 형식(EOF) 입니다. EOF에는 가스 관측성 비활성화, 코드 관측성(예: CODECOPY 없음), 정적 점프만 허용하는 등 많은 변경 사항이 도입되었습니다. 목표는 이전 버전과의 호환성을 유지하면서 더 강력한 속성으로 EVM을 더 많이 업그레이드할 수 있도록 하는 것입니다(EOF 이전 EVM이 여전히 존재하기 때문에).
이것의 장점은 새로운 EVM 기능을 추가하기 위한 자연스러운 경로를 생성하고 더 강력한 보장을 통해 더 엄격한 EVM으로의 마이그레이션을 장려한다는 것입니다. 단점은 결국 이전 EVM을 더 이상 사용하지 않고 제거할 수 있는 방법을 찾지 않는 한 프로토콜의 복잡성이 크게 증가한다는 것입니다. 주요 질문은 EVM 단순화 제안에서 EOF가 어떤 역할을 하는가입니다. 특히 목표가 전체 EVM 복잡성을 줄이는 것이라면 더욱 그렇습니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
로드맵의 나머지 부분에 있는 개선 제안 중 상당수는 이전 기능을 단순화할 수 있는 기회이기도 합니다. 위의 몇 가지 예를 반복하면 다음과 같습니다.
단일 슬롯 최종성으로 전환하면 위원회를 제거하고 경제를 재설계하며 기타 지분 증명 관련 단순화를 수행할 수 있는 기회가 제공됩니다.
계정 추상화를 완전히 구현하면 기존 트랜잭션 처리 로직을 많이 제거하고 모든 EOA가 대체할 수 있는 기본 계정 EVM 코드로 이동할 수 있습니다.
모든 Ethereum 데이터 구조가 동일한 방식으로 해시될 수 있도록 Ethereum 상태를 이진 해시 트리로 이동하면 SSZ의 새 버전과 조화를 이룰 수 있습니다.
보다 급진적인 접근 방식: 대부분의 프로토콜을 계약 코드로 변환
보다 급진적인 이더리움 단순화 전략은 프로토콜을 동일하게 유지하면서 대부분을 프로토콜 기능에서 계약 코드로 이동하는 것입니다.
가장 극단적인 버전은 Ethereum L1을 기술적으로 단지 비콘 체인으로 만들고 다른 사람들이 자체 롤업을 생성할 수 있도록 하는 최소한의 가상 머신(예: RISC-V , Cairo 또는 최소한의 전용 증명 시스템)을 도입하는 것입니다. 그러면 EVM이 이러한 롤업 중 첫 번째 롤업이 됩니다. 아이러니하게도 이는 2019-20년 경영진 환경 제안 과 정확히 동일한 결과입니다. 하지만 SNARK를 사용하면 실제로 구현하는 것이 더 실현 가능합니다.
보다 겸손한 접근 방식은 비콘 체인과 현재 이더리움 실행 환경 간의 관계를 변경하지 않고 유지하면서 EVM의 내부 스왑을 수행하는 것입니다. RISC-V, Cairo 또는 다른 VM을 새로운 공식 Ethereum VM으로 선택한 다음 모든 EVM 계약을 원래 코드 논리(컴파일 또는 해석을 통해)를 해석하는 새로운 VM 코드로 강제할 수 있습니다. 이론적으로 이는 EOF 버전인 대상 VM을 통해 수행될 수도 있습니다.
