비탈릭: 이더의 숙청 단계의 주요 목표는 다음과 같습니다.

저자: 이더리움 창립자 비탈릭, 편집: 골든 파이낸스 덩 통

주: 이 글은 이더리움 창립자 비탈릭이 최근 발표한 이더리움 프로토콜의 미래, 5부: 숙청에 관한 기사의 다섯 번째 파트이며, 이더리움 프로토콜의 미래, 5부: 숙청에 대한 연재 글 중 5번째 파트입니다. https://vitalik.eth.limo/general/2024/10/26/futures5.html" target="_blank">이더리움 프로토콜의 가능한 미래, 5부: 퍼지 ", 4부에서는 "비탈릭: 더 버지, 이더의 미래"를 참조하세요. 3부는 "비탈릭: 이더리움의 스컬지 국면을 위한 주요 목표"에서, 2부는 다음 링크에서 확인할 수 있습니다. "비탈릭: 이더 프로토콜의 서지 단계가 어떻게 진화해야 하는가", 파트 1은 다음에서 확인할 수 있습니다. "이더리움 지분증명에서 개선할 수 있는 다른 것들"에서 확인할 수 있습니다. 다음은 5부 전문입니다.

피드백과 의견을 보내주신 저스틴 드레이크, 팀 베이코, 매트 가넷, 파이퍼 메리엄, 마리우스 반 데르 비덴, 토마스 스탄작에게 특별히 감사드립니다.

이더넷이 직면한 과제 중 하나는 기본적으로 모든 블록체인 프로토콜의 부피와 복잡성이 시간이 지남에 따라 증가한다는 것입니다. 이는 두 가지 방식으로 발생합니다.

• 기록 데이터: 모든 거래와 기록의 어느 시점에 생성된 모든 계정은 새로운 클라이언트가 영구적으로 저장해야 합니다. 네트워크와 완전히 동기화된 새 클라이언트에 의해 저장되고 다운로드되어야 합니다. 이로 인해 체인의 용량이 일정하게 유지되더라도 클라이언트 로드와 동기화 시간은 시간이 지남에 따라 증가하게 됩니다.

• 프로토콜 기능: 새로운 기능을 추가하는 것이 기존 기능을 제거하는 것보다 훨씬 쉽기 때문에 시간이 지남에 따라 코드 복잡성이 증가하게 됩니다.

이더가 장기적으로 지속 가능하려면 이 두 가지 경향에 강력한 압력을 가하여 시간이 지남에 따라 복잡성과 부풀어 오름을 줄여야 합니다. 하지만 그 동안에는 블록체인의 핵심 속성 중 하나인 지속성을 보존해야 합니다. NFT, 트랜잭션 호출 데이터의 러브레터, 백만 달러가 담긴 스마트 컨트랙트를 체인에 올려놓고 10년 동안 동굴에 들어갔다가 나와도 여전히 그곳에서 사용자가 읽고 상호작용하기를 기다리는 것을 발견할 수 있습니다. 디앱이 완전히 탈중앙화되고 업그레이드 키를 없애는 것을 편안하게 느끼려면 의존성, 특히 L1 자체를 깨뜨리는 방식으로 업그레이드되지 않을 것이라는 확신이 있어야 합니다.

더 퍼지, 2023 로드맵.

이 두 가지 요구 사이의 균형을 맞추는 데 집중한다면 연속성을 유지하면서 확장, 복잡성, 쇠퇴를 최소화하거나 역전시킬 수 있습니다. 대부분의 유기체는 시간이 지남에 따라 노화하지만 다행히도 일부 유기체는 그렇지 않습니다. 사회 시스템도 수명이 매우 길 수 있습니다. 이더리움은 이미 작업 증명이 사라지고, SELFDESTRUCT 연산 코드가 대부분 사라졌으며, 비콘 체인 노드가 최대 6개월 동안 오래된 데이터를 저장하는 등 일부 사례에서는 이미 성공했습니다. 이더의 장기적인 확장성, 기술적 지속 가능성, 심지어 보안을 위해 보다 일반적인 방식으로 이더가 나아갈 길을 찾고 장기적으로 안정적인 최종 결과를 향해 나아가는 것은 이더의 궁극적인 과제입니다.

퍼지: 주요 목표

• 각 노드가 모든 기록을 영구적으로 저장할 필요성을 줄이거나 제거하여 클라이언트 측 스토리지 요구사항을 줄이고, 궁극적으로

• 불필요한 기능을 제거하여 프로토콜 복잡성 감소

기록 데이터 만료

어떤 문제를 해결하나요?

이 글을 쓰는 현재, 완전히 동기화된 이더넷 노드는 실행 클라이언트에 약 1.1TB의 디스크 공간이 필요하고 합의 클라이언트에는 수백 GB의 디스크 공간이 추가로 필요합니다. 이 중 대부분은 과거 블록, 트랜잭션, 영수증에 대한 데이터로, 대부분 몇 년이 지난 기록 데이터입니다. 즉, 가스 한도가 전혀 증가하지 않더라도 노드의 크기는 매년 수백 기가바이트씩 증가할 것입니다.

무엇일까요? 어떻게 작동하나요?

히스토리 저장 문제의 핵심적인 단순화 기능은 각 블록이 해시 링크(및 기타 구조)를 통해 이전 블록을 가리키기 때문에 현재에 대한 합의만으로도 히스토리에 대한 합의가 가능하다는 것입니다. 네트워크가 가장 최근 블록에 대한 합의에 도달하는 한, 모든 기록 블록, 트랜잭션 또는 상태(계정 잔액, 난수, 코드, 저장소)는 단일 참여자가 머클 증명을 통해 제공할 수 있으며, 해당 증명을 통해 다른 사람이 그 정확성을 검증할 수 있습니다. 합의는 N/2-of-N 신뢰 모델인 반면, 내역은 1-of-N 신뢰 모델입니다.

이는 히스토리를 저장하는 방법에 대한 많은 선택지를 열어줍니다. 자연스러운 선택 중 하나는 각 노드가 데이터의 극히 일부만 저장하는 네트워크입니다. 이는 토렌트 네트워크가 수십 년 동안 작동해온 방식입니다. 네트워크는 총 수백만 개의 파일을 저장하고 배포하지만, 각 참여자는 그 중 일부만 저장하고 배포합니다. 직관적이지 않을 수도 있지만, 이러한 접근 방식은 데이터의 견고성을 반드시 감소시키지도 않습니다. 노드 운영 비용을 줄임으로써 각 노드가 기록의 10%를 무작위로 저장하는 100,000개의 노드로 구성된 네트워크를 구현할 수 있다면 각 데이터 조각은 각 노드가 기록의 10%를 저장하는 것과 동일하게 10,000번 복제될 것입니다. - 각 노드가 모든 것을 저장하는 10,000개의 노드 네트워크와 정확히 동일한 복제 계수입니다.

오늘날 이더는 모든 노드가 모든 기록을 영구적으로 저장하는 모델에서 벗어나기 시작했습니다. 합의 블록(즉, 지분 증명 합의와 관련된 부분)은 약 6개월 동안만 저장되며, 블롭은 약 18일 동안만 저장됩니다. eip-4444는 과거 블록과 영수증에 대해 1년의 저장 기간을 도입하는 것을 목표로 하고 있습니다. 장기적인 목표는 각 노드가 모든 것을 저장하는 조정된 기간(아마도 ~18일)을 가진 다음, 이전 데이터를 분산된 방식으로 저장하는 이더넷 노드의 피어투피어 네트워크를 갖추는 것입니다.

이미지 src="https://img.jinse.cn/7313225_watermarknone.png" title="7313225" alt="3CCZmM1irqCJHQ5oosNlQ251jxdKRvF94cXdCA59.jpeg">

정정 삭제 코드를 사용하면 복제 계수를 일정하게 유지하면서 견고성을 향상시킬 수 있습니다. 실제로 데이터 가용성 샘플링을 지원하기 위해 블롭은 이미 삭제 수정 코드를 사용하고 있습니다. 가장 간단한 해결책은 이 중복 제거를 재사용하고 실행 및 합의 블록 데이터도 블롭에 넣는 것입니다. 어떤 연구가 존재하나요?

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/ 네트워킹 계층/포털 네트워크/

포털 네트워크 및 EIP-4444: https://github.com/ethereum/portal- network-specs/issues/308

포탈에서 SSZ 오브젝트의 분산 저장 및 검색: https://ethresear.ch/t/distributed- 포털 네트워크용 저장 및 암호화로 안전하게 보호된 SSZ 오브젝트 검색

가스 개선 방법 제한(패러다임): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

어떻게 해야 하며, 장단점은 무엇인가요?

이력을 저장하기 위한 구체적인 분산 솔루션을 구축하고 통합하는 것, 즉 최소한 실행 이력은 물론 궁극적으로 컨센서스와 합의도 저장하는 것이 남은 주요 과제입니다. 가장 간단한 솔루션은 (i) 기존 토렌트 라이브러리를 가져오는 것과 (ii) 포탈 네트워크라는 이더리움 네이티브 솔루션입니다. 이 중 하나를 도입하면 EIP-4444를 활성화할 수 있는데, 이 자체는 하드포크가 필요하지 않지만 새로운 버전의 네트워크 프로토콜이 필요합니다. 따라서 모든 클라이언트에서 동시에 활성화하는 것이 좋습니다. 그렇지 않으면 전체 기록을 다운로드할 것으로 예상하지만 실제로는 다운로드하지 않는 다른 노드에 연결하여 클라이언트가 실패할 수 있기 때문입니다.

주요 트레이드오프는 '이전' 기록 데이터를 어떻게 사용할 수 있게 할 것인가와 관련이 있습니다. 가장 간단한 해결책은 내일 이전 데이터 저장을 중단하고 기존 아카이브 노드와 다양한 중앙 집중식 제공업체에 복제를 의존하는 것입니다. 이는 쉽지만 영구적인 데이터 기록으로서 이더의 입지를 약화시킬 수 있습니다. 더 어렵지만 더 안전한 접근 방식은 먼저 토렌트 네트워크를 구축하고 통합하여 분산된 방식으로 기록을 저장하는 것입니다. 여기서 "얼마나 노력하는가"에는 두 가지 차원이 있습니다."

• 최대 노드 수가 실제로 모든 데이터를 모든 데이터를 저장할 수 있을까요?

• 히스토리 저장소를 프로토콜과 얼마나 깊숙이 통합해야 하나요?

(1)의 경우 가장 엄격한 접근 방식은 각 자격 증명 검증자에게 일정 비율의 히스토리를 저장하도록 요구하고, 주기적으로 암호학적으로 저장하고 있는지 확인하는 양육권 증명을 사용하는 것입니다. 클라이언트당 저장되는 기록의 비율에 대한 자발적인 기준을 설정하는 것이 더 적당한 접근 방식일 수 있습니다.

(2)의 경우, 기본적인 구현은 현재 포털에서 이미 전체 이더리움 이력이 포함된 ERA 파일을 저장하고 있는 것만 포함합니다. 보다 철저한 구현은 실제로 동기화 프로세스에 연결하여 다른 아카이브 노드가 온라인 상태가 아니더라도 전체 기록 저장 노드 또는 아카이브 노드를 동기화하려는 경우 포털 네트워크에서 직접 동기화하여 동기화할 수 있도록 하는 것입니다.

다른 로드맵과 어떻게 상호작용하나요?

노드에 필요한 1.1TB 중 약 300GB는 스테이트이고 나머지 약 800GB는 히스토리로, 노드를 매우 간단하게 실행하거나 시작하려면 히스토리 스토리지 요구 사항을 줄이는 것이 스테이트리스보다 더 중요할 수 있습니다. 스마트워치에서 실행되고 설정하는 데 몇 분밖에 걸리지 않는 이더넷 노드의 비전은 상태 비저장성과 EIP-4444가 모두 구현되어야만 실현될 수 있습니다.

또한 기록 저장을 제한하면 최신 이더넷 노드 구현이 최신 버전의 프로토콜만 지원하여 더 간단하게 구현할 수 있습니다. 예를 들어, 2016년 DoS 공격 당시 생성된 빈 저장 슬롯이 모두 삭제되었으므로 많은 코드 줄을 안전하게 제거할 수 있습니다. 이제 지분 증명으로의 전환이 완료되었으므로 클라이언트는 작업 증명과 관련된 모든 코드를 안전하게 제거할 수 있습니다.

상태 데이터 만료

어떤 문제를 해결하나요?

클라이언트의 기록 저장 필요성을 제거하더라도 계정 잔액과 난수, 계약 코드, 계약 스토리지 등 증가하는 상태로 인해 클라이언트의 스토리지 요구량은 연간 약 50GB로 계속 증가할 것입니다. 사용자는 일회성 요금을 지불하여 현재와 미래의 이더 클라이언트에게 영원히 부담을 줄 수 있습니다.

상태는 역사보다 '만료'가 훨씬 더 어려운데, 이는 EVM 설계의 기본 가정이 상태 개체가 생성되면 영원히 존재하고 언제든 모든 트랜잭션에서 읽을 수 있다는 것이기 때문입니다. 특수한 종류의 블록 빌더만 실제로 상태를 저장할 필요가 있고, 다른 모든 노드(심지어 리스트 생성까지!)는 상태 저장 없이 실행할 수 있기 때문에 문제가 그렇게 나쁘지 않을 수 있다는 주장이 제기되고 있습니다. 모두 상태 저장 없이 실행할 수 있습니다. 그러나 일부에서는 상태 비저장성에 지나치게 의존하고 싶지 않으며, 궁극적으로 이더를 탈중앙화하기 위해 상태가 만료되기를 원할 수도 있다고 주장합니다.

이것이 무엇인가요? 어떻게 작동하나요?

현재 새로운 상태 객체를 생성할 때 (i) 이더를 새 계정으로 전송하거나 (ii) 코드를 사용해 새 계정을 생성하거나 (iii) 이전에 손대지 않은 스토리지 슬롯을 설정하는 세 가지 방법 중 하나를 사용하면 해당 상태 객체는 항상 그 상태로 유지됩니다. 대신, 우리가 원하는 것은 시간이 지나면 해당 개체가 자동으로 만료되는 것입니다. 핵심 과제는 다음 세 가지 목표를 달성하는 방식으로 이를 수행하는 것입니다.

• 효율성: 만료 프로세스를 실행하는 데 많은 추가 계산이 필요하지 않습니다. 프로세스를 실행하는 데 많은 추가 계산이 필요하지 않습니다.

• 사용자 친화성: 5년 동안 동굴에 들어갔다가 다시 돌아와도 ETH, ERC20, NFT 또는 CDP 포지션에 대한 액세스 권한을 잃지 않아야 합니다 ......

• strong>개발자 친화성: 개발자들이 완전히 새로운 사고방식 모델로 전환할 필요는 없습니다. 또한 오늘날의 경직되고 업데이트되지 않은 애플리케이션도 계속 합리적으로 잘 작동해야 합니다.

문제는 이러한 목표를 달성하지 않아도 쉽게 해결할 수 있습니다. 예를 들어, 각 상태 객체에 만료 날짜를 추적하는 카운터를 저장하고(읽기 또는 쓰기 시 자동으로 발생하는 이더를 소멸시켜 만료 날짜를 연장할 수 있음), 상태를 순회하는 루프를 만들어 만료된 상태 객체를 제거할 수 있습니다. 그러나 이렇게 하면 추가 계산(및 스토리지 요구 사항)이 발생하고 사용자 편의성 요구 사항을 충족하지 못합니다. 또한 개발자가 저장소 값이 0으로 초기화되는 극단적인 경우를 추론하는 것도 어렵습니다. 만료 타이머를 계약 범위 내로 설정하면 기술적으로는 개발자의 작업이 더 쉬워지지만, 개발자는 지속적인 스토리지 비용을 사용자에게 '전가'하는 방법을 고민해야 하는 등 경제적으로 더 어려워집니다.

이러한 문제는 핵심 이더리움 개발 커뮤니티가 수년간 고민해 온 문제이며, '블록체인 임대'와 '재생'과 같은 제안도 포함되어 있습니다. 결국, 저희는 제안 중 가장 좋은 부분을 취합하여 "가장 덜 알려진 해결책"의 두 가지 범주에 집중했습니다.

• 부분 상태 만료 솔루션.

• 주소 주기 기반 상태 만료 제안.

부분 상태 만료

부분 상태 만료 제안은 모두 동일한 원칙을 따릅니다. 상태를 청크로 나눕니다. 각 청크는 비어 있거나 비어 있지 않은 블록에 대한 "최상위 맵"을 영구적으로 저장합니다. 각 블록의 데이터는 최근에 액세스한 경우에만 저장됩니다. "부활" 메커니즘이 있어 블록이 더 이상 저장되지 않는 경우 누구나 해당 블록이 무엇인지에 대한 증거를 제공하여 데이터를 복구할 수 있습니다.

이 제안들 간의 주요 차이점은 (i) "최근"을 어떻게 정의할 것인가, (ii) "블록"을 어떻게 정의할 것인가 하는 점입니다. 한 가지 구체적인 제안은 EIP-7736으로, 버클 트리에 도입된 "줄기 및 잎" 설계를 기반으로 합니다(바이너리 트리 등 모든 형태의 상태 비저장 트리와 호환 가능). 이 설계에서는 서로 인접한 헤더, 코드, 슬롯이 동일한 '줄기' 아래에 저장됩니다. 스템 아래에 저장되는 데이터는 최대 256 * 31 = 7,936바이트까지 가능합니다. 대부분의 경우 계정의 전체 헤더와 코드, 그리고 많은 키 저장 슬롯이 동일한 줄기 아래에 저장됩니다. 특정 트렁크 아래의 데이터를 6개월 이내에 읽거나 쓰지 않은 경우 데이터는 더 이상 저장되지 않고 데이터에 대한 32바이트 커밋("스텁")만 저장됩니다. 향후 이 데이터에 액세스하는 트랜잭션은 데이터를 '부활'하고 스텁에 대한 조정 증명을 제공해야 합니다.

이미지 src="https://img.jinse.cn/7313267_watermarknone.png" title="7313267" alt="fSOCmKUg6ovk9kmRWRgZgLoGkNPdlLOh9MCDofTr.jpeg">

유사한 아이디어를 구현하는 다른 방법도 있습니다. 예를 들어, 계정 간격이 충분하지 않은 경우 트리의 각 1/232 부분을 유사한 줄기 및 잎 메커니즘으로 제어하는 방식을 개발할 수 있습니다.

공격자가 대량의 데이터를 하나의 하위 트리에 배치하고 매년 단일 트랜잭션을 전송하여 클라이언트가 대량의 상태를 영구적으로 저장하도록 함으로써 '트리를 업데이트'할 수 있다는 인센티브 때문에 더욱 까다로운 문제입니다. 업데이트 비용이 트리 크기에 비례하거나 업데이트 기간이 트리 크기에 반비례하는 경우, 누군가가 대량의 데이터를 동일한 하위 트리에 넣어 다른 사용자에게 해를 끼칠 수 있습니다. 예를 들어 2^16 = 65536개의 연속된 상태 개체를 각각 '그룹'으로 간주하여 하위 트리 크기에 따라 계정 간격을 동적으로 설정함으로써 이 두 가지 문제를 제한하려는 시도를 할 수 있습니다. 그러나 이러한 아이디어는 더 복잡하지만, 줄기 기반 접근 방식은 간단하고 일반적으로 줄기 아래의 모든 데이터가 동일한 애플리케이션 또는 사용자와 관련이 있기 때문에 인센티브를 조화롭게 조정할 수 있습니다.

주소 주기 기반 상태 만료 제안

32바이트 스텁의 경우에도 영구적인 상태 증가를 전혀 피하고 싶다면 어떻게 해야 할까요? 상태 객체가 삭제되고 나중에 EVM 실행이 정확히 같은 위치에 다른 상태 객체를 배치했지만 원래 상태 객체에 관심이 있는 사람이 다시 돌아와서 복원하려고 하면 어떻게 될까요? 부분 상태 만료의 경우 '스텁'은 새 데이터 생성을 방지합니다. 전체 상태 만료의 경우 스텁을 저장할 수도 없습니다.

주소 주기 기반 설계는 이 문제를 해결하는 가장 좋은 방법입니다. 전체 상태를 단일 상태 트리에 저장하는 대신 상태 트리 목록을 늘리고, 읽거나 쓴 상태는 최신 상태 트리에 저장합니다. 새로운 빈 상태 트리가 매 주기마다 추가됩니다(예: 1년). 이전 상태 트리는 고정됩니다. 완전한 노드는 가장 최근의 트리 두 개만 저장하면 됩니다. 상태 개체가 두 사이클 동안 손대지 않아 만료된 트리에 속하더라도 여전히 읽거나 쓸 수 있지만 트랜잭션이 머클 증명을 증명해야 하며, 이 작업이 완료되면 사본이 가장 최근 트리에 다시 저장됩니다.

이 모든 것을 사용자와 개발자 친화적으로 만드는 핵심 아이디어 중 하나는 주소 주기라는 개념입니다. 주소 주기는 주소의 일부인 숫자 입니다. 핵심 규칙은 주소 주기가 N인 주소는 주기 N 동안 또는 그 이후(즉, 상태 트리 목록이 길이 N에 도달할 때)에만 읽거나 쓸 수 있다는 것입니다. 새로운 상태 객체(예: 새 컨트랙트 또는 새 ERC20 잔액)를 저장하려는 경우, 주소 기간이 N 또는 N-1인 컨트랙트에 상태 객체를 넣으면 이전에 아무것도 없었다는 증명을 제공할 필요 없이 즉시 저장할 수 있습니다. 반면에 이전 주소 주기에 상태를 추가하거나 수정하려면 증명이 필요합니다.

이 설계는 이더의 현재 속성을 대부분 유지하고, 추가 계산이 거의 필요하지 않으며, 애플리케이션을 현재와 거의 동일하게 작성할 수 있고(주소 기간 N을 가진 주소의 잔액이 주소 기간 N을 가진 하위 계약에 저장되도록 ERC20을 다시 작성해야 함), "사용자가 5년 동안 동굴에 있었다"의 문제를 해결합니다. ' 문제를 해결합니다. 하지만 한 가지 큰 문제가 있습니다. 주소 주기에 맞추려면 주소가 20바이트를 넘어야 한다는 점입니다.

주소 공간 확장

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

0x01000000000157aE408398dF7E5f4552091A69125d5d5dFcb7B8C2659029395bdF

빨간색은 버전 번호입니다. 여기서 주황색으로 표시된 4개의 0은 나중에 슬라이스 번호를 입력할 수 있는 빈 공간을 나타냅니다. 녹색은 주소 주기 번호입니다. 파란색은 26바이트 해시입니다.

여기서의 핵심 과제는 이전 버전과의 호환성입니다. 기존 컨트랙트는 20바이트 주소를 중심으로 설계되었으며, 주소의 길이가 정확히 20바이트라고 명시적으로 가정하는 타이트한 바이트 패킹 기술을 사용하는 경우가 많습니다. 이 문제를 해결하기 위한 한 가지 아이디어는 변환 그래프를 사용하는 것으로, 새로운 주소와 상호 작용하는 이전 컨트랙트는 새로운 주소의 20바이트 해시를 보게 됩니다. 그러나 이를 보호하려면 상당한 노력이 필요합니다.

주소 공간 축소

다른 접근 방식은 그 반대입니다. 2128 크기의 일부 주소 하위 범위(예: 0xffffffff로 시작하는 모든 주소)를 즉시 비활성화한 다음 해당 범위를 사용하여 주소 주기와 14바이트 해시를 가진 주소를 도입하는 것입니다.

이 접근 방식은 자산이나 권한을 보유하고 있지만 아직 코드가 체인에 게시되지 않은 주소, 즉 사실과 다른 주소에 대한 보안 위험을 초래한다는 점이 가장 큰 희생입니다. 이러한 위험은 누군가 (아직 게시되지 않은) 코드를 가지고 있다고 주장하지만 해시가 동일한 주소를 가리키는 다른 유효한 코드를 가지고 있는 주소를 생성하는 것과 관련이 있습니다. 이러한 충돌을 계산하려면 현재 280개의 해시가 필요하지만, 주소 공간 축소를 통해 이 숫자는 매우 접근하기 쉬운 256개의 해시로 줄어들게 됩니다.

주요 위험 영역인 단일 소유자가 보유하지 않은 지갑의 사실과 다른 주소는 현재 비교적 드문 상황이지만, 다중 L2 세계로 이동함에 따라 더욱 일반화될 가능성이 높습니다. 유일한 해결책은 이러한 위험을 받아들이되, 문제가 발생할 수 있는 모든 일반적인 사용 사례를 파악하고 효과적인 해결책을 마련하는 것입니다. 어떤 연구가 존재하나요?

초기 제안

블록체인 임대료:https://github.com/ethereum/EIPs/issues/35

재생: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

strong>부분 상태 만료 제안

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

주소 공간 확장에 대한 문서

원본 제안: https://ethereum-magicians.org/t/increasing-address-size-from-20 --to-32-bytes/5485

Ipsilon 댓글: https://notes.ethereum.org/@ipsilon/ 주소 공간 확장 탐색

블로그 게시물 댓글: 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이 아닌 증가율을 허용합니다. 이 결과는 피어 투 피어 네트워크와 관련된 기록 만료 제안과 유사할 수 있는데, 각 클라이언트가 저장해야 하는 기록 데이터의 비율은 낮지만 고정되어 있는 영구 기록 저장소의 증가율은 훨씬 낮지만 여전히 0이 아닌 증가율을 허용합니다.

• 만료일을 선언하고 주소 공간을 확장합니다. 여기에는 기존 애플리케이션을 포함하여 주소 형식 변환 방법이 효과적이고 안전한지 확인하기 위한 다년간의 프로세스가 포함됩니다.

• 만료일을 선언하고 주소 공간을 축소합니다. 여기에는 크로스 체인 상황을 포함하여 주소 충돌과 관련된 모든 보안 위험이 해결될 수 있도록 다년간의 프로세스가 포함됩니다.

중요한 점은 주소 형식 변경에 의존하는 상태 만료 체계의 구현 여부와 관계없이 주소 공간을 확장하고 축소하는 문제는 결국 해결해야 한다는 것입니다. 오늘날 주소 충돌을 생성하는 데는 약 2^80개의 해시가 필요하며, 이는 리소스가 매우 풍부한 플레이어에게 이미 가능한 계산 부하입니다. GPU는 약 2^27개의 해시를 만들 수 있으므로 2^52를 계산하는 데 1년 동안 실행할 수 있으므로 전 세계의 모든 ~2^30 GPU는 약 1/4년 안에 충돌을 계산할 수 있습니다. 전 세계의 모든 ~2^30 GPU는 ~1/4년 안에 충돌을 계산할 수 있으며, FPGA와 ASIC은 이 과정을 더욱 가속화할 수 있습니다. 앞으로 이러한 공격은 점점 더 많은 사람들에게 공개될 것입니다. 어차피 이 매우 어려운 주소 문제를 해결해야 하기 때문에 전체 상태 만료를 구현하는 데 드는 실제 비용은 생각보다 높지 않을 수 있습니다.

다른 로드맵과 어떻게 상호작용하나요?

상태 만료를 실행하면 변환 프로세스가 필요 없기 때문에 한 상태 트리 형식에서 다른 형식으로 변환하기가 더 쉬워질 수 있습니다. 새로운 형식을 사용하여 새 트리를 만든 다음 나중에 하드 포크를 수행하여 이전 트리를 변환할 수 있기 때문입니다. 따라서 상태 만료는 복잡하지만 로드맵의 다른 측면을 단순화하는 데 도움이 됩니다.

기능 정리

어떤 문제를 해결하나요?

보안, 접근성, 신뢰할 수 있는 중립성을 위한 핵심 전제 조건 중 하나는 단순성입니다. 프로토콜이 미적으로 보기 좋고 단순하면 오류 발생 가능성이 줄어듭니다. 새로운 개발자가 프로토콜의 어느 부분이든 참여하고 사용할 수 있는 가능성이 높아집니다. 공정할 가능성이 더 높고 특별한 이해관계에 대한 저항력이 더 강합니다. 안타깝게도 프로토콜은 다른 사회 시스템과 마찬가지로 기본적으로 시간이 지남에 따라 더 복잡해집니다. 이더가 점점 더 복잡해지는 블랙홀에 빠지지 않으려면 두 가지 중 한 가지를 해야 합니다: (i) 프로토콜의 변경과 골화를 중단하거나, (ii) 실제로 기능을 제거하고 복잡성을 줄일 수 있어야 합니다. 중간 과정, 즉 프로토콜을 덜 변경하면서 시간이 지남에 따라 약간의 복잡성을 제거하는 방법도 가능합니다. 이 섹션에서는 복잡성을 줄이거나 제거하는 방법에 대해 설명합니다.

무엇인가요? 어떻게 작동하나요?

프로토콜 복잡성을 줄이는 큰 단일 수정 사항은 없으며, 문제의 특성상 작은 수정 사항이 많이 있습니다.

기본적으로는 이미 완료되었으며 다른 문제를 처리하는 방법에 대한 청사진이 될 수 있는 한 가지 예는 SELFDESTRUCT 옵코드의 제거입니다. 셀프디스트럭트 옵코드는 단일 블록 내에서 스토리지 슬롯을 무제한으로 수정할 수 있는 유일한 코드이므로 클라이언트가 DoS 공격을 피하기 위해 더 정교한 기능을 구현해야 합니다. 이 옵코드의 원래 목적은 자발적인 상태 삭제를 가능하게 하여 시간이 지남에 따라 상태 크기를 줄일 수 있도록 하는 것이었습니다. 실제로 이 옵션을 사용하는 사람은 거의 없습니다. 이 옵코드는 덴쿤 하드포크에서 동일한 트랜잭션에서 생성된 계정만 자체 삭제할 수 있도록 약화되었습니다. 이를 통해 DoS 문제를 해결하고 클라이언트 측 코드를 대폭 간소화할 수 있게 되었습니다. 향후에는 이 옵코드를 완전히 제거하는 것이 합리적일 수 있습니다.

지금까지 확인된 프로토콜 간소화 기회에 대한 몇 가지 주요 사례는 다음과 같습니다. 첫째, EVM 외부의 몇 가지 예. 이러한 예는 상대적으로 방해가 되지 않으므로 단기간에 합의를 도출하고 구현하기가 더 쉽습니다.

• RLP → SSZ 변환: 원래 이더리움 객체는 RLP라는 인코딩을 사용해 직렬화되었습니다. 오늘날 비콘 체인은 직렬화뿐만 아니라 해싱을 지원하는 등 여러 면에서 훨씬 더 나은 SSZ를 사용합니다. 궁극적으로 저희는 RLP에서 완전히 벗어나 모든 데이터 유형을 SSZ 구조로 전환하여 업그레이드를 훨씬 쉽게 만들고자 합니다. 이를 위해 현재 제안된 EIP로는 [1] [2] [3]이 있습니다.

• 구형 트랜잭션 유형 삭제: 오늘날 트랜잭션 유형이 너무 많아서 많은 트랜잭션 유형이 삭제될 수 있습니다. 완전한 삭제에 대한 보다 적당한 대안은 계정 추상화 기능으로, 스마트 계정에 이전 스타일의 거래를 처리하고 검증하는 코드를 포함할 수 있습니다(원할 경우).

• LOG 개혁: 로깅은 프로토콜에 복잡성을 더하는 블룸 필터와 기타 로직을 생성하지만 속도가 너무 느려서 클라이언트가 실제로 사용하지는 않습니다. 이 기능을 제거하고 대신 SNARK와 같은 최신 기술을 사용하는 프로토콜 외부의 분산형 로그 읽기 도구와 같은 대안에 노력을 기울일 수 있습니다.

• 비콘 체인 동기화 위원회 메커니즘 최종 제거: 동기화 위원회 메커니즘은 처음에 이더에 대한 가벼운 클라이언트 측 검증을 가능하게 하기 위해 도입되었습니다. 그러나 이는 프로토콜에 복잡성을 더했습니다. 결국 SNARK를 사용해 이더리움 합의 계층을 직접 검증할 수 있게 되면 전용 라이트 클라이언트 검증 프로토콜이 필요하지 않게 될 것입니다. 이렇게 하면 이더넷 합의 검증자의 무작위 하위 집합에서 서명을 검증하는 보다 "네이티브" 라이트 클라이언트 프로토콜을 생성하여 전용 라이트 클라이언트 프로토콜의 필요성을 없앨 수 있습니다.

• 데이터 형식 조화: 현재 실행 상태는 머클 패트리샤 트리에 저장되고, 합의 상태는 SSZ 트리에 저장되며, 블롭은 KZG 커미티로 제출됩니다. 앞으로는 블록 데이터와 상태를 위한 단일 통합 형식을 만드는 것이 합리적입니다. 이러한 형식은 (i) 스테이트리스 클라이언트를 위한 간단한 증명, (ii) 데이터의 직렬화 및 삭제 코딩, (iii) 표준화된 데이터 구조에 대한 모든 중요한 요구사항을 충족할 것입니다.

• 비콘 체인 위원회 삭제: 처음에 이 메커니즘은 버전별 실행 샤딩을 지원하기 위해 도입되었습니다. 하지만 결국 L2와 블롭을 통해 샤딩하게 되었습니다. 그 결과 이 위원회는 불필요한 것으로 판단되어 이를 제거하기 위한 노력이 진행 중입니다.

• 혼합 바이트 순서 제거: EVM은 빅엔디안 바이트 순서, 합의 계층은 리틀엔디안 바이트 순서입니다. 이를 다시 조화시켜 모든 것을 빅엔드 바이트 순서로 만드는 것이 합리적일 수 있습니다(EVM은 변경하기 어렵기 때문에 아마도 빅엔드 바이트 순서일 것입니다).

이제, EVM 내부의 몇 가지 예시:

• 가스 메커니즘 단순화: 현재의 가스 규칙은 블록을 검증하는 데 필요한 리소스의 양을 명시적으로 제한하는 데 최적화되어 있지 않습니다. 주요 예로는 (i) 블록의 읽기/쓰기 횟수를 제한하기 위한 것이지만 현재 매우 임의적인 메모리 읽기/쓰기 비용과 (ii) 현재 EVM의 최대 메모리 소비량을 추정하기 어렵게 만드는 메모리 채우기 규칙이 있습니다. 제안된 수정 사항에는 모든 스토리지 관련 비용을 간단한 공식으로 통합하기 위한 스테이트리스 가스 비용 변경과 메모리 가격 책정 제안이 포함됩니다.

• 프리컴파일 제거: 현재 이더가 가지고 있는 많은 프리컴파일은 불필요하게 복잡하고 상대적으로 사용되지 않으며, 실제로 어떤 애플리케이션에서도 사용되지 않는 합의 실패 클로즈 콜의 많은 부분을 차지합니다. 이 문제를 해결하는 두 가지 방법은 (i) 사전 컴파일을 완전히 제거하는 것과 (ii) 동일한 로직을 구현하는 (필연적으로 더 비싼) EVM 코드로 대체하는 것입니다. 이 EIP 초안에서는 신원 사전 컴파일에 대해 먼저 이 작업을 수행하고 나중에 RIPEMD160, MODEXP 및 BLAKE를 제거할 것을 제안합니다.

• 가스 가시성 제거: EVM 실행이 더 이상 남은 가스 양을 확인할 수 없게 되면 일부 애플리케이션(특히 스폰서 트랜잭션)이 중단되지만 향후 업그레이드(예: 고급 버전의 다차원 가스)가 더 쉬워집니다. EOF 사양은 이미 가스를 를 관찰할 수 없지만 프로토콜 간소화에 기여하기 위해서는 EOF를 의무화해야 합니다.

• 정적 분석의 개선: 오늘날의 EVM 코드는 특히 점프가 동적일 수 있기 때문에 정적으로 분석하기 어렵습니다. 또한 최적화된 EVM 구현(다른 언어로 미리 컴파일된 EVM 코드)을 만들기도 더 어렵습니다. 동적 점프를 제거하거나 가스 비용을 계약의 총 점프 횟수에 따라 선형화하여 더 비싸게 만들면 이 문제를 해결할 수 있지만, 이를 통해 얻을 수 있는 프로토콜 간소화 이점을 위해서는 EOF를 의무화해야 합니다.

어떤 연구가 존재하나요?

Purge의 다음 단계: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA

SELFDESTRUCT:https://hackmd.io/@vbuterin/ selfdestruct

SSZ-ification EIPS: [1] [2] [3]

주 가스 비용 없음 변경: 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) 이전 버전과의 호환성입니다. 체인으로서 이더의 가치는 애플리케이션을 배포하고 몇 년 후에도 여전히 작동할 것이라는 확신을 가질 수 있는 플랫폼이라는 점입니다. 동시에, 이러한 이상을 너무 멀리 가져가면 윌리엄 제닝스 브라이언의 말처럼 "이전 버전과의 호환성이라는 십자가 위에서 이더를 십자가에 못 박는 것"이 될 수도 있습니다. 전체 이더리움에서 특정 기능을 사용하는 앱이 두 개뿐이고, 그 중 하나는 수년간 사용자가 없었고 다른 하나는 거의 사용되지 않아 총 57달러의 가치를 얻었다면, 우리는 해당 기능을 제거하고 필요하다면 피해자에게 57달러를 우리 주머니에서 지불해야 합니다.

사회적으로 더 큰 문제는 긴급하지 않은 하위 호환성 파괴적 변경을 위한 표준화된 파이프라인을 만드는 것입니다. 이 문제를 해결하는 한 가지 방법은 자체 파괴 파이프라인과 같은 기존 선례를 검토하고 확장하는 것입니다. 파이프라인은 다음과 같습니다.

• 1단계: 기능 X 삭제에 대한 논의 시작.

• <>< Strong>2단계: 분석을 수행하여 X를 제거하는 것이 애플리케이션에 얼마나 방해가 될지 결정하고, 그 결과에 따라 (i) 아이디어를 포기하거나 (ii) 계획대로 진행하거나 (iii) X를 제거하는 "가장 방해가 적은" 수정된 방법을 결정하고 진행합니다.

• 3단계: X를 사용하지 않는 공식적인 EIP를 개발하여 널리 사용되는 상위 인프라(예: 프로그래밍 언어, 지갑)가 이를 준수하고 이 기능의 사용을 중단하도록 합니다.

• 4단계: 마지막으로 X를 물리적으로 제거합니다.

1단계와 4단계 사이에는 어떤 프로젝트가 어느 단계에 있는지 명확하게 표시된 수년에 걸친 프로세스가 있어야 합니다. 이 시점에서는 기능 제거 프로세스의 강도와 속도를 높이는 것과 프로토콜 개발의 다른 영역에 더 많은 리소스를 투입하는 것 사이에는 상충 관계가 있지만, 우리는 파레토 프론티어와는 거리가 멀다.

EOF

EVM에 제안된 주요 변경 사항은 EVM 객체 형식(EOF)으로, 가스 관측성, 코드 관측성 비활성화(즉, 코드 복사본 없음), 정적 점프만 허용하는 등 여러 가지 변경 사항을 도입합니다. 목표는 이전 버전과의 호환성을 유지하면서(EOF 이전의 EVM은 여전히 존재하므로) 더 강력한 속성을 갖도록 EVM을 더 많이 업그레이드할 수 있도록 하는 것입니다.

이 방법의 장점은 새로운 EVM 기능을 추가하고 더 강력한 보장을 제공하는 더 강력한 EVM으로의 마이그레이션을 장려하는 자연스러운 경로를 만든다는 것입니다. 단점은 결국 이전 EVM을 사용 중단하고 제거할 방법을 찾지 못하면 프로토콜의 복잡성이 크게 증가한다는 것입니다. 주요 질문은 다음과 같습니다. 특히 전체 EVM의 복잡성을 줄이는 것이 목표인 경우 EVM 간소화 제안에서 EOF의 역할은 무엇인가요?

로드맵의 나머지 부분과 어떻게 상호작용하나요?

로드맵의 나머지 부분에 있는 많은 "개선" 제안은 기존 기능을 단순화할 수 있는 기회이기도 합니다. 위의 몇 가지 예를 반복하자면:

• 단일 슬롯 최종성으로 전환하면 위원회를 없애고 경제성을 재작업하며 자격 증명과 관련된 기타 단순화 작업을 수행할 수 있습니다.

• 계정 추상화를 완전히 구현하면 기존 트랜잭션 처리 로직을 모든 EOA로 대체할 수 있는 "기본 계정 EVM 코드"로 이동하여 많은 부분을 제거할 수 있습니다.

• 이더 상태를 바이너리 해시 트리로 옮기면 모든 이더 데이터 구조가 동일한 방식으로 해시될 수 있도록 새 버전의 SSZ와 조정할 수 있습니다.

더 급진적인 접근 방식: 프로토콜의 많은 부분을 컨트랙트 코드로 변환

더 급진적인 이더 간소화 전략은 프로토콜을 그대로 유지하되 프로토콜의 많은 부분을 프로토콜 기능에서 컨트랙트 코드로 변환하는 것입니다.

가장 극단적인 버전은 이더 L1을 "기술적으로" 비콘 체인으로 만들고, 누구나 자신만의 집계를 만들 수 있는 최소한의 가상머신(예: RISC-V, 카이로 또는 증명 시스템 전용의 더 간단한 가상머신)을 도입하는 것입니다. 그러면 EVM이 이러한 집계 중 첫 번째 집계가 됩니다. 아이러니하게도 이는 2019-20년 구현 환경 제안과 정확히 동일한 결과이지만, SNARK가 실제로 구현하는 것이 더 실현 가능성이 높습니다.

이미지 src="https://img.jinse.cn/7313302_watermarknone.png" title="7313302" alt="YXuY3KxC2q9U1ZIZay6rq9XK2aIpesYrubu00Itl.jpeg">

더 겸손한 접근 방식은 비콘 체인과 현재 이더넷 실행 환경 간의 관계를 그대로 유지하되 EVM을 교체하는 것입니다. RISC-V, 카이로 또는 다른 VM을 새로운 "공식 이더 VM"으로 선택한 다음 모든 EVM 컨트랙트를 원래 코드의 로직을 해석하는 새로운 VM 코드(컴파일 또는 해석)로 변환하도록 강제할 수 있습니다. 이론적으로는 "대상 VM"을 EOF 버전으로 사용하여 이 작업을 수행할 수도 있습니다.