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