Vitalik: EIP-6780 이더넷 프로토콜 간소화를 위한 핵심 단계

저자: 비탈릭 번역: 굿오바, 골든파이낸스

최근 덴쿤 하드포크에서 잘 알려지지 않은 EIP 중 하나는 EIP-6780입니다. 알려진 EIP는 EIP-6780으로, 연산 코드 SELFDESTRUCT의 기능 대부분을 제거합니다.

이 EIP는 이더 프로토콜 개발에서 종종 과소평가되는 부분인 이더 프로토콜이 복잡성을 없애고 새로 추가되어 개발되고 있다는 핵심 예시입니다. 보안 보장을 추가하여 프로토콜의 노력을 단순화하기 위해 개발 중입니다. 이는 제가 "정리"라고 부르는 프로젝트, 즉 이더를 간소화하고 기술 부채를 없애는 프로젝트의 중요한 부분입니다. 비슷한 정신을 가진 더 많은 EIP가 등장할 것이므로, 특히 EIP-6780이 어떻게 목표를 달성하는지, 그리고 앞으로 어떤 다른 EIP가 등장할지 이해하는 것이 좋습니다.

EIP-6780은 어떻게 이더 프로토콜을 간소화하나요?

EIP-6780은 이를 호출하는 컨트랙트를 파괴하고 코드와 저장소를 비워 동일한 트랜잭션 중에 컨트랙트가 생성된 경우에만 유효하도록 하는 옵코드 SELFDESTRUCT의 기능을 줄였습니다. 이것은 그 자체로 명세서의 복잡성을 줄이지는 않습니다. 그러나 두 가지 새로운 불변성을 도입하여 구현을 개선합니다.

1. EIP-6780 이후에는 단일 블록에서 편집할 수 있는 최대 스토리지 슬롯 수가 있습니다(대략적으로: 가스 제한 / 5000).

2. 컨트랙트의 트랜잭션 또는 블록 시작 시 비어 있지 않은 코드가 있는 경우 해당 트랜잭션 또는 블록의 끝에도 동일한 코드가 있습니다.

이전에는 이러한 불변성 중 어느 것도 사실이 아니었습니다:

1. SELFDESTRUCT 스토리지 슬롯 수가 많은 컨트랙트는 단일 블록 내에서 슬롯 수를 무제한으로 지울 수 있습니다. 이 특수한 경우를 효율적으로 처리하기 위해 추가 코드가 필요하기 때문에 버클 트리 구현이 더 어려워지고 이더넷 클라이언트 구현이 복잡해집니다.

2. 컨트랙트의 코드는 비어 있지 않은 상태에서 비어 있는 SELFDESTRUCT로 변경될 수 있으며, 실제로 컨트랙트를 다른 코드로 즉시 다시 생성할 수도 있습니다. 따라서 계정 추상화 지갑에서 DoS 공격에 취약하지 않은 코드베이스를 사용하여 트랜잭션을 검증하는 것이 더 어려워집니다.

이제 이러한 불변성이 정확해져 이더 클라이언트 및 기타 유형의 인프라를 훨씬 쉽게 구축할 수 있게 되었습니다. 몇 년 후에는 미래의 생태 산업 단지가 이 작업을 완료하여 SELFDESTRUCT가 완전히 제거될 수 있기를 바랍니다.

또 어떤 '정화'가 일어나고 있나요?

• Geth는 최근 수천 줄의 코드와 사전 병합(PoW) 네트워크에 대한 지원을 제거했습니다.

• 이 EIP는 더 이상 "빈 계정"을 걱정하는 코드가 필요하지 않다는 사실을 공식화합니다(참조: 상하이 DoS 공격 수정의 일환으로 이 개념을 도입한 EIP-161)

• Geth는 최근 수천 줄의 코드를 제거하여 사전 병합(PoW) 네트워크에 대한 지원을 없앴습니다.

• 덴쿤의 블롭 저장 기간은 18일이며, 이는 이더넷 노드가 블롭 데이터를 저장하는 데 약 50GB만 필요하고 이 양은 시간이 지나도 늘어나지 않는다는 것을 의미합니다

앞의 두 가지는 클라이언트 개발자의 삶을 크게 개선합니다. 후자는 노드 운영자의 수명을 크게 향상시킵니다.

또 무엇이 제거되어야 할까요?

사전 컴파일

사전 컴파일은 EVM 코드가 없는 대신 클라이언트 자체에서 직접 구현해야 하는 로직을 가진 이더컨트랙트입니다. 사전 컴파일은 EVM에서 효율적으로 구현할 수 없는 복잡한 형태의 암호화를 구현하는 데 사용할 수 있다는 개념입니다.

오늘날 사전 컴파일은 특히 타원 곡선 사전 컴파일을 통해 ZK-SNARK 기반 애플리케이션을 구현하는 데 매우 성공적으로 사용되고 있습니다. 하지만 거의 사용되지 않는 다른 사전 컴파일도 있습니다.

• RIPEMD-160: 비트코인과의 호환성 향상을 지원하기 위해 해시 함수가 도입되었습니다

  .

• 아이덴티티: 입력과 동일한 출력을 반환하는 프리컴파일

• BLAKE2: 해시 함수가 도입되었습니다. code>: 지캐시와의 호환성 향상을 지원하기 위해 도입된 해시 함수

• MODEXP: RSA 기반 암호화를 지원하기 위해 매우 큰 모듈로 함수를 도입

이러한 사전 컴파일의 필요성은 예상보다 훨씬 적은 것으로 판명되었습니다. 아이덴티티는 데이터를 복사하는 가장 쉬운 방법이었기 때문에 널리 사용되었지만, Dencun 이후에는 MCOPY 코드 조작이 이를 대체했습니다. 안타깝게도 이러한 모든 사전 컴파일은 컨센서스 버그의 큰 원인이자 ZK-SNARK 회로, 공식적으로 검증된 친숙한 구현 등을 포함한 새로운 EVM 구현에 큰 골칫거리입니다.

이러한 사전 컴파일을 제거하는 방법에는 두 가지가 있습니다.

1. 예를 들어 EIP-7266은 BLAKE2를 제거하고, EIP-7266은 BLAKE2를 제거하는 등 사전 컴파일을 간단히 제거할 수 있습니다. 7266은 BLAKE2를 제거합니다. 간단하지만 여전히 이를 사용하는 모든 응용 프로그램이 중단됩니다.

2. 예를 들어, 사전 컴파일을 동일한 작업을 수행하는(불가피하게 가스 비용이 더 많이 들지만) EVM 코드 블록으로 대체할 수 있습니다. 이 EIP 초안은 ID 사전 컴파일에 대해 바로 이 작업을 수행합니다. 이는 더 어렵지만 이를 사용하는 애플리케이션을 거의 중단시키지 않을 것입니다(새 EVM 코드의 가스 비용이 일부 입력 블록 가스 한도를 초과하는 드문 경우를 제외하고)

이력(EIP-4444)

오늘날 모든 이더 노드는 모든 기록 블록을 영구적으로 저장해야 합니다. 이는 매우 낭비적인 접근 방식으로 오랫동안 인식되어 왔으며, 높은 스토리지 요구 사항으로 인해 이더 노드 운영을 불필요하게 어렵게 만들었습니다. 덴쿤에서는 약 18일 동안만 저장하면 되는 블롭을 도입했습니다. EIP-4444를 사용하면 일정 시간이 지나면 이더 블록도 기본 이더 노드에서 제거됩니다.

해결해야 할 핵심 질문 중 하나는 이전 기록이 모든 노드에 저장되지 않는다면, 이를 저장하는 데 사용되는 은 무엇일까요? 실제로는 블록 브라우저와 같은 대규모 엔티티가 이를 수행할 것입니다. 그러나 P2P 프로토콜이 해당 정보를 저장하고 전달하도록 만드는 것도 가능하고 어렵지 않으며, 이는 작업에 더 최적화되어 있습니다.

이더리움 블록체인은 영구적이지만, 각 노드가 모든 데이터를 영원히 저장하도록 요구하는 것은 그 영구성을 달성하기 위한 매우 '과도한' 방식입니다.

한 가지 접근 방식은 오래된 기록을 위한 간단한 P2P 플러드 네트워크입니다. 다른 하나는 포털 네트워크와 같이 이더넷 사용에 보다 명시적으로 최적화된 프로토콜을 위한 것입니다.

또는 모달 형식으로:

이더넷 노드 실행에 필요한 스토리지의 양을 줄이면 크게 증가할 수 있습니다.EIP -4444는 또한 노드 동기화 시간을 줄여 많은 노드 운영자의 워크플로우를 간소화할 수 있습니다. 결과적으로 EIP-4444는 이더리움의 노드 탈중앙화를 크게 증가시킬 수 있습니다. 잠재적으로 각 노드가 기본적으로 기록의 일부만 저장한다면, 현재와 거의 동일한 수의 특정 기록 사본을 네트워크에 저장할 수도 있습니다.

로그 개혁

이 EIP 초안 직접 인용:

로깅은 원래 탈중앙화 애플리케이션(dapp)이 이 정보를 쉽게 쿼리할 수 있도록 애플리케이션이 체인에 이벤트에 대한 정보를 기록할 수 있도록 하기 위해 도입되었습니다. 디앱은 블룸 필터를 사용하여 기록을 빠르게 탐색하고, 애플리케이션과 관련된 로그를 포함하는 여러 블록을 식별한 다음, 필요한 로그가 있는 개별 트랜잭션을 빠르게 식별할 수 있습니다.

실제로 이 메커니즘은 너무 느립니다. 거의 모든 디앱이 이더넷 노드(또는 원격으로 호스팅된 노드)에 대한 RPC 호출이 아니라 중앙화된 추가 프로토콜 서비스를 통해 기록에 액세스합니다.

어떻게 할 수 있을까요? Bloom 필터를 제거하고 LOG 연산 코드를 단순화하여 해시를 상태에 넣는 값만 생성하도록 할 수 있습니다. 그런 다음, <코드>주제와 로그가 필요하고 이를 원하는 애플리케이션이 주어진 모든 로그의 쉽게 검색 가능한 테이블을 나타내는 증명 가능한 올바른 "로그 트리"를 생성하기 위해 ZK-SNARK와 증분 검증 가능 계산(IVC)을 사용하는 별도의 프로토콜을 구축할 수 있습니다. Centrality는 이러한 별도의 프로토콜을 사용할 수 있습니다.

SSZ로 이전

현재 트랜잭션과 영수증을 포함한 이더의 블록 구조 대부분은 여전히 RLP와 머클 패트리샤 트리에 기반한 오래된 형식을 사용하여 저장되고 있습니다. 이로 인해 이 데이터를 사용하는 애플리케이션을 개발하는 것이 불필요하게 어렵습니다.

이더넷 합의 계층은 더 깨끗하고 효율적인 SSZ(SimpleSerialize)로 전환되었습니다:

정보 출처: https://eth2book.info/altair/part2/building_blocks/merkleization/

그러나 변환을 완료하고 실행 레이어를 동일한 구조로 이동해야 합니다. .

SSZ의 주요 이점은 다음과 같습니다

• 사양이 더 간단하고 명확합니다

• < p style="text-align: 왼쪽;">현행 6포크 머클 패트리샤 트리와 비교했을 때, 머클 증명의 길이는 대부분의 경우 4배 감소합니다

• 극도로 긴 머클의 최악의 경우와 비교해보면 다음과 같습니다. 머클 증명의 길이가 제한됨(예: 계약 코드 증명 또는 긴 영수증 출력)

• 복잡한 비트 조작 코드를 구현할 필요가 없음(RLP에 필요)

• ZK-. SNARK 사용 사례의 경우, 바이너리 머클 트리를 중심으로 구축된 기존 구현을 재사용할 수 있는 경우가 많습니다

현재 Ether에 존재하는 암호화 데이터 구조는 SHA256 바이너리 트리, SHA3 RLP 해시 목록, 16진수 패트리샤 트리 등 세 가지 유형이 있습니다. SSZ로의 전환이 완료되면 SHA256 바이너리 트리와 버클 트리 두 개만 남게 됩니다. 장기적으로는 SNARK 해시에 대해 충분히 숙달되면 SHA256 이진 트리와 버클 트리를 모든 이더넷에서 작동하는 암호화 데이터 구조인 SNARK 친화적인 해시를 사용하는 이진 머클 트리로 대체할 가능성이 높습니다.