원래 제목:Should Ethereum be okay with enshrining more things in the protocol?

원작자: 비탈릭 부테린

Odaily 번역기 - Nian Yin Si Tang

피드백과 리뷰를 주신 Justin Drake, Tina Zhen 및 Yoav Weiss에게 특별히 감사드립니다.

이더리움 프로젝트 초기부터 핵심 이더리움을 최대한 단순하게 만들고, 그 위에 프로토콜을 구축하여 이를 최대한 달성하려는 강한 철학이 있었습니다. 블록체인 공간에서 L1 구축 대 L2 집중 논쟁은 주로 확장에 관한 것으로 생각되는 경우가 많지만 실제로는 여러 이더리움 사용자의 요구를 충족하는 데 있어 디지털 자산 교환, 개인 정보 보호와 같은 유사한 문제가 있습니다. , 사용자 이름, 고급 암호화, 계정 보안, 검열 저항, 선행 보호 등이 있습니다. 그러나 최근 이러한 기능을 핵심 Ethereum 프로토콜에 더 많이 포함시키려는 신중한 시도가 있었습니다.

이 글에서는 최소 캡슐화라는 원래 철학의 이면에 있는 몇 가지 철학적 추론과 이러한 아이디어에 대한 최근의 사고 방식을 탐구할 것입니다. 목표는 특정 기능을 캡슐화하는 것이 고려할 가치가 있는 가능한 목표를 더 잘 식별하기 위한 프레임워크 구축을 시작하는 것입니다.

프로토콜 미니멀리즘에 대한 초기 철학

당시 이더리움 2.0으로 알려진 것의 초기 역사에는 자체 구축을 가능한 한 적게 시도하고 거의 모든 작업을 사용자에게 맡기는 깨끗하고 단순하며 아름다운 프로토콜을 만들고자 하는 강한 열망이 있었습니다. 이상적으로 프로토콜은 단지 가상 머신이고, 블록을 검증하는 것은 단지 가상 머신 호출입니다.

이것은 Gavin Wood가 이더리움 2.0이 어떤 모습일지에 대해 이야기하던 2015년 초에 그렸던 화이트보드 다이어그램을 대략적으로 재구성한 것입니다.

상태 전환 기능(블록을 처리하는 기능)은 단일 VM 호출일 뿐이며 다른 모든 논리는 계약을 통해 발생합니다. 일부 시스템 수준 계약이지만 대부분 사용자 제공 계약입니다. 이 모델의 아주 좋은 특징은 전체 하드포크조차도 블록 프로세서 계약에 대한 단일 거래로 설명될 수 있다는 것입니다. 이는 오프체인 또는 온체인 거버넌스에 의해 승인된 다음 실행 권한이 업그레이드됩니다.

2015년에 논의된 이러한 논의는 특히 우리가 고려하는 두 가지 영역에 적용됩니다.계정 추상화 및 확장. 스케일링의 경우 위 다이어그램을 자연스럽게 확장한 것처럼 느껴지는 최대 추상 형태의 스케일링을 만들려고 노력하는 것이 아이디어입니다. 계약은 대부분의 이더리움 노드에 저장되지 않은 데이터를 호출할 수 있으며 프로토콜은 이를 감지하고 매우 일반적인 확장 컴퓨팅 기능을 통해 호출을 해결합니다. 가상 머신의 관점에서 보면 호출은 별도의 하위 시스템으로 이동한 다음 얼마 후 마법처럼 정답을 반환합니다.

우리는 이 아이디어를 간략하게 살펴봤지만 모든 종류의 블록체인 확장이 가능하다는 것을 증명하는 데 너무 집중했기 때문에 빨리 포기했습니다. 나중에 살펴보겠지만, 데이터 가용성 샘플링과 ZK-EVM의 조합은 이더리움 스케일링의 가능한 미래가 실제로 이 비전에 매우 가깝다는 것을 의미합니다! 반면에 계정 추상화에서는 어떤 종류의 구현이 가능하다는 것을 처음부터 알고 있었기 때문에 거래는 단지 호출일 뿐이다라는 순수한 출발점에 최대한 가까운 것을 만들기 위한 연구가 즉시 시작되었습니다.

트랜잭션을 처리하는 것과 발신자 주소에서 실제 기본 EVM 호출을 수행하는 것 사이에는 많은 상용구 코드가 있으며 그 이후에는 더 많은 상용구 코드가 있습니다. 이 코드를 가능한 한 0에 가깝게 줄이려면 어떻게 해야 합니까?

여기서 주요 코드 중 하나는 트랜잭션의 nonce와 서명이 올바른지 확인하는 역할을 하는 verify_transaction(state, tx)입니다. 처음부터 계정 추상화의 실제 목표는 사용자가 기본적인 비증분 검증 및 ECDSA 검증을 자체 검증 로직으로 대체하여 사용자가 소셜 복구 및 다중 서명 지갑과 같은 기능을 보다 쉽게 ​​사용할 수 있도록 하는 것이었습니다. 따라서 Apply_transaction을 간단한 EVM 호출로 재구성하는 방법을 찾는 것은 단순히 코드를 깨끗하게 만들기 위해 코드를 깨끗하게 만드는 작업이 아니라 논리를 사용자의 계정 코드로 이동하여 사용자에게 필요한 유연성을 제공하는 것입니다.

그러나 apply_transaction에 고정 논리가 가능한 한 적게 포함되어야 한다고 주장하는 것은 결국 많은 문제를 야기했습니다. 가장 초기의 계정 추상화 제안 중 하나인 EIP-86을 살펴보겠습니다.

EIP-86이 있는 그대로 포함된다면 이더리움 스택의 다른 부분의 복잡성을 엄청나게 증가시키는 대신 EVM의 복잡성을 줄일 수 있으며, 전체를 도입하는 것 외에도 본질적으로 다른 곳에 동일한 코드를 작성해야 합니다. 예를 들어, 다중 무효화 문제는 말할 것도 없고 동일한 해시 값을 가진 동일한 거래가 체인에 여러 번 나타날 수 있습니다.

계정 추상화에 여러 가지 무효화 문제가 있습니다. 온체인에 포함된 하나의 트랜잭션은 멤풀에 있는 수천 개의 다른 트랜잭션을 무효화할 수 있으므로 멤풀이 저렴하게 채워지기 쉽습니다.

그 이후로 계정 추상화는 단계적으로 발전했습니다. EIP-86은 나중에 EIP-208이 되었고 결국에는 실용적인 EIP-2938이 되었습니다.

그러나 EIP-2938은 결코 미니멀리스트가 아닙니다. 그 내용은 다음과 같습니다:

• 새로운 거래 유형

• 세 가지 새로운 트랜잭션 범위 전역 변수

• EVM 실행 중단점으로 가스 가격 및 가스 한도 확인을 처리하고 일회성 수수료 지불을 위해 ETH를 임시로 저장하는 매우 투박한 PAYgas opcode를 포함한 두 개의 새로운 opcode

• 거래 검증 단계에서 금지된 opcode 목록을 포함한 복잡한 마이닝 및 재방송 전략 세트

이더리움 핵심 개발자(이더리움 클라이언트 최적화 및 병합 구현에 중점을 둔)를 개입시키지 않고 계정 추상화를 달성하기 위한 노력의 일환으로 EIP-2938은 궁극적으로 완전히 오프 프로토콜인 ERC-4337로 재설계되었습니다.

ERC-4337. 전적으로 EVM 호출에 의존합니다!

이는 ERC이기 때문에 하드 포크가 필요하지 않으며 기술적으로 이더리움 프로토콜 외부에 존재합니다. 그럼...문제가 해결되었나요? 사실은 그렇지 않은 것으로 밝혀졌습니다. ERC-4337에 대한 현재 중기 로드맵에는 실제로 ERC-4337의 큰 부분을 일련의 프로토콜 기능으로 전환하는 작업이 포함되며, 이는 이 경로를 고려해야 하는 이유에 대한 유용한 지침의 예입니다.

패키지 ERC-4337

결국 ERC-4337을 프로토콜로 다시 가져오는 데에는 몇 가지 주요 이유가 논의되었습니다.

• 가스 효율: EVM 내부에서 수행되는 모든 작업은 스토리지 슬롯과 같이 가스 비용이 많이 드는 기능을 사용할 때의 비효율성을 포함하여 어느 정도의 가상 머신 오버헤드를 발생시킵니다. 현재 이러한 추가 비효율성은 그 이상은 아니더라도 최소 20,000개의 가스를 추가합니다. 이러한 구성요소를 프로토콜에 넣는 것이 이러한 문제를 제거하는 가장 쉬운 방법입니다.

• 코드 버그 위험: ERC-4337 진입점 계약에 무서운 버그가 있다면 모든 ERC-4337 호환 지갑은 자금이 고갈될 수 있습니다. 계약을 프로토콜 내 기능으로 대체하면 하드 포크를 통해 코드 버그를 수정해야 하는 암묵적인 의무가 생기므로 사용자의 자금 부족 위험이 제거됩니다.

• EVM opcode 지원, txt.origin 등. ERC-4337 자체는 txt.origin이 일련의 사용자 작업을 트랜잭션으로 패키징하는 번들러의 주소를 반환하도록 합니다. 기본 계정 추상화는 txt.origin이 트랜잭션을 보내는 실제 계정을 가리키도록 만들어 EOA와 동일하게 동작하도록 하여 이 문제를 해결합니다.

• 검열에 저항하는: 제안자/구축자 분리의 과제 중 하나는 개별 트랜잭션을 검토하기가 더 쉬워진다는 것입니다. 이더리움 프로토콜이 단일 트랜잭션을 식별할 수 있는 세계에서 이 문제는 포함 목록을 통해 크게 완화될 수 있습니다. 이를 통해 제안자는 거의 모든 경우에 다음 두 슬롯에 포함되어야 하는 트랜잭션 목록을 지정할 수 있습니다. 그러나 프로토콜 외부의 ERC-4337은 단일 트랜잭션에 사용자 작업을 캡슐화하여 사용자 작업을 이더리움 프로토콜에 불투명하게 만듭니다. 따라서 이더리움 프로토콜에서 제공하는 포함 목록은 ERC-4337 사용자에게 검열 저항을 제공할 수 없습니다. 운영. ERC-4337을 래핑하고 사용자 작업을 적절한 트랜잭션 유형으로 만들면 이 문제가 해결됩니다.

현재 형태에서 ERC-4337은 기본 이더리움 거래보다 훨씬 더 비싸다는 점을 언급할 가치가 있습니다. 거래 비용은 21,000 가스인 반면 ERC-4337은 약 42,000 가스입니다.

이론적으로는 프로토콜 내 비용과 프로토콜 외부 저장소 액세스 비용이 일치할 때까지 EVM 가스 비용 시스템을 조정할 수 있어야 하며, 다른 유형의 저장소 편집 시 ETH를 전송하기 위해 9000 가스를 소비할 이유가 없습니다. 운영이 더 저렴합니다. 실제로 곧 출시될 Verkle 트리 변환과 관련된 두 개의 EIP가 실제로 바로 이러한 작업을 시도합니다. 그러나 그렇게 한다고 해도 EVM이 아무리 효율적이더라도 캡슐화된 프로토콜 기능이 필연적으로 EVM 코드보다 훨씬 저렴할 것이라는 분명한 이유가 있습니다. 캡슐화된 코드는 사전 로딩을 위해 가스를 지불할 필요가 없습니다.

완전한 기능을 갖춘 ERC-4337 지갑은 규모가 크며, 이 구현을 컴파일하여 온체인에 배치하면 약 12,800바이트를 차지합니다. 물론 이 코드를 한 번 배포하고 DELEGATECALL을 사용하여 각 개별 지갑에서 이를 호출할 수 있도록 할 수 있지만 여전히 이 코드가 사용되는 모든 블록의 코드에 액세스해야 합니다. Verkle 트리 가스 비용 EIP에서는 12,800바이트가 413개 청크를 형성하며, 이러한 청크에 액세스하려면 Witness Branch_cost의 2배(총 3,800가스)와 Witness Chunk_cost의 413배(총 82,600가스)를 지불해야 합니다. 버전 0.6.0에서는 온체인에 23,689바이트가 있는 ERC-4337 진입점 자체는 언급되지 않았습니다(Verkle 트리 EIP 규칙에 따라 로드할 가스는 약 158,700개).

이로 인해 문제가 발생합니다. 실제로 이러한 코드에 액세스하는 데 드는 가스 비용은 어떤 방식으로든 트랜잭션 전반에 걸쳐 상각되어야 합니다. ERC-4337에서 사용하는 현재 접근 방식은 그다지 좋지 않습니다. 번들의 첫 번째 트랜잭션은 일회성 저장/코드 읽기 비용을 소비하므로 다른 트랜잭션보다 훨씬 비쌉니다. 프로토콜 내 캡슐화를 통해 이러한 공용 공유 라이브러리가 프로토콜의 일부가 되고 모든 사람이 자유롭게 액세스할 수 있습니다.

이 예에서 무엇을 배울 수 있으며, 언제 캡슐화를 보다 일반적으로 실행해야 합니까?

이 예에서 우리는 프로토콜에 계정 추상화를 캡슐화하는 몇 가지 다른 근거를 볼 수 있습니다.

• 복잡성을 한계까지 끌어올리는 시장 기반 접근 방식은 고정 비용이 높을 때 실패할 가능성이 가장 높습니다.실제로 장기 계정 추상화 로드맵에는 블록당 고정 비용이 많이 들어갈 것으로 보입니다. 표준화된 지갑 코드를 로드하는 데 244,100 가스가 필요하지만, 집계를 통해 ZK-SNARK 검증을 위한 수십만 가스와 증명 검증을 위한 온체인 비용이 추가될 수 있습니다. 엄청난 시장 비효율성을 도입하지 않고서는 사용자에게 이러한 비용을 청구할 수 있는 방법이 없으며 이러한 기능 중 일부를 모든 사람이 자유롭게 액세스할 수 있는 프로토콜 기능으로 전환하면 이 문제를 매우 잘 해결할 수 있습니다.

• 코드 버그에 대한 커뮤니티 전반의 대응.모든 사용자 또는 매우 광범위한 사용자가 일부 코드 조각을 사용하는 경우, 발생하는 버그를 수정하기 위해 블록체인 커뮤니티가 하드 포크 책임을 맡는 것이 더 합리적입니다. ERC-4337은 전 세계적으로 공유되는 대량의 코드를 도입하고 있으며, 장기적으로 사용자가 대량의 ETH를 잃게 만드는 것보다 하드 포크를 통해 코드의 버그를 수정하는 것이 의심할 여지 없이 더 합리적입니다.

• 때로는 해당 기능을 직접 활용하여 더 강력한 형태의 프로토콜을 구현할 수도 있습니다.여기서 중요한 예는 포함 목록과 같은 프로토콜 내의 검열 저항성 기능입니다. 프로토콜 내 포함 목록은 프로토콜 외부 방법보다 더 나은 검열 저항을 보장할 수 있습니다. 사용자 수준 작업이 프로토콜 내에서 진정한 이점을 얻으려면 포함 목록, 개별 사용자 수준 작업에서는 프로토콜이 읽기 쉬워야 합니다. 잘 알려지지 않은 또 다른 예는 2017년 이더리움 지분 증명 설계에 지분 키의 계정 추상화가 있었는데, 이는 BLS가 프로토콜에서 구현해야 하는 집계 메커니즘을 지원했기 때문에 캡슐화된 BLS를 위해 포기되었습니다. 네트워크 수준에서는 이를 통해 많은 수의 서명을 보다 효율적으로 처리할 수 있습니다.

하지만 기억하는 것이 중요합니다.현재 상황과 비교하면 캡슐화 프로토콜 내의 계정 추상화조차 여전히 거대한 비캡슐화입니다.. 현재 최상위 이더리움 거래는 단일 secp 256k 1 타원 곡선 서명을 사용하여 검증된 외부 소유 계정(EOA)에서만 시작할 수 있습니다. 계정 추상화는 이를 제거하고 검증 조건을 사용자가 정의하도록 남겨둡니다. 따라서 계정 추상화에 대한 이 이야기에서 우리는 캡슐화에 반대하는 가장 큰 이유도 볼 수 있습니다.다양한 사용자의 요구를 충족할 수 있는 유연성。

최근 캡슐화에 대해 고려된 기능의 몇 가지 다른 예를 살펴봄으로써 이야기를 더욱 구체화해 보겠습니다. 우리는 다음에 특별한 주의를 기울일 것입니다:ZK-EVM, 제안자-빌더 분리, 개인 메모리 풀, 유동성 스테이킹 및 새로운 사전 컴파일。

패키지 ZK-EVM

이더리움 프로토콜의 또 다른 잠재적인 캡슐화 대상인 ZK-EVM에 주목해 보겠습니다. 현재 우리는 ZK-SNARK에서 유사한 이더리움 블록의 실행을 확인하기 위해 상당히 유사한 코드를 작성해야 하는 다수의 ZK 롤업을 보유하고 있습니다. PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth 등 상당히 다양한 독립적 구현 생태계가 있습니다.

EVM ZK 롤업 세계에서 최근 논란은 ZK 코드에서 발생할 수 있는 버그를 처리하는 방법과 관련이 있습니다. 현재 운영 중인 이러한 모든 시스템에는 버그 발생 시 증명 시스템을 제어하는 ​​일종의 보안 위원회 메커니즘이 있습니다. 작년에 저는 프로젝트가 얼마나 인증 시스템을 신뢰하는지, 그리고 안전 보장 이사회를 얼마나 신뢰하는지 명확히 하고 시간이 지남에 따라 해당 조직에 대한 권한을 점차적으로 축소하도록 장려하는 표준화된 프레임워크를 만들려고 노력했습니다.

중기적으로 롤업은 여러 인증 시스템에 의존할 가능성이 높으며, 안전보장이사회는 서로 다른 두 인증 시스템이 갈라지는 극단적인 경우에만 권한을 갖습니다.

하지만 이 작업 중 일부는 불필요하다고 느껴지는 부분이 있습니다. 우리는 이미 이더리움 기본 레이어와 EVM을 갖고 있으며 구현 시 버그를 처리하기 위한 작동 메커니즘을 이미 갖추고 있습니다. 버그가 있으면 클라이언트가 업데이트되어 이를 수정하고 체인은 계속 작동합니다. . 버그가 있는 클라이언트의 관점에서 볼 때 확정된 블록은 더 이상 확인되지 않을 것으로 보이지만 적어도 사용자가 자금을 잃는 것은 볼 수 없습니다. 마찬가지로 롤업이 단지 EVM과 동등한 역할을 유지하려는 경우 자체 거버넌스를 구현하여 내부 ZK-EVM 규칙을 지속적으로 변경하여 이더리움 기본 계층에 대한 업그레이드를 일치시켜야 합니다. 이는 궁극적으로 최상위에 구축되기 때문에 잘못된 느낌입니다. Ethereum 기본 계층 자체의 경우 업그레이드 시기와 새로운 규칙에 따라 알고 있습니다.

이러한 L2 ZK-EVM은 기본적으로 이더리움과 동일한 EVM을 사용하므로 ZK에서 EVM 실행 확인을 프로토콜 기능에 통합하고 버그 및 업그레이드와 같은 이더리움의 사회적 합의를 적용하여 예외를 처리할 수 있습니까? 기본 계층 EVM 실행 자체?

이것은 중요하고 도전적인 주제입니다.

기본 ZK-EVM의 데이터 가용성에 관한 논쟁의 가능한 주제 중 하나는 상태 저장입니다. ZK-EVM은 증인 데이터를 전달할 필요가 없다면 훨씬 더 데이터 효율적일 것입니다. 즉, 특정 데이터 조각이 이전 블록에서 이미 읽혀지거나 쓰여졌다면 증명자가 해당 데이터에 액세스할 수 있으므로 다시 사용할 수 있도록 할 필요가 없다고 간단하게 가정할 수 있습니다. 단순히 스토리지와 코드를 다시 로드하지 않는 것이 아니라 롤업이 데이터를 올바르게 압축한다면 상태 저장 압축은 상태 비저장 압축에 비해 데이터를 최대 3배까지 절약할 수 있는 것으로 나타났습니다.

이는 ZK-EVM 사전 컴파일의 경우 두 가지 옵션이 있음을 의미합니다.

1.사전 컴파일을 위해서는 모든 데이터를 동일한 블록에서 사용할 수 있어야 합니다.. 이는 증명자가 상태 비저장일 수 있음을 의미하지만 사전 컴파일된 ZK 롤업을 사용하는 것이 롤업용 사용자 정의 코드를 사용하는 것보다 훨씬 더 비용이 많이 든다는 의미이기도 합니다.

2.사전 컴파일을 통해 포인터는 이전 실행에서 사용되거나 생성된 데이터를 가리킬 수 있습니다.. 이로 인해 ZK 롤업이 최적에 가까워지지만 더 복잡해지고 증명자가 저장해야 하는 새로운 상태가 발생합니다.

우리는 이것으로부터 무엇을 배울 수 있습니까? 어떤 방식으로든 ZK-EVM 검증을 캡슐화하는 데에는 타당한 이유가 있습니다. 롤업은 이미 자체 사용자 정의 버전을 구축하고 있으며 이더리움은 다중 구현 및 오프체인 사회적 합의의 무게를 바탕으로 L1에서 EVM을 구현할 의향이 있습니다. 틀렸지만 L2는 정확히 동일한 작업을 수행하므로 보안 이사회와 관련된 복잡한 장치를 구현해야 합니다. 그러나 반면에 세부 사항에는 큰 문제가 있습니다. ZK-EVM에는 비용과 이점이 다른 다양한 버전이 있습니다. 상태 저장과 상태 비저장 사이의 구별은 단지 표면적일 뿐입니다. 다른 시스템에서 입증된 거의 EVM 사용자 정의 코드를 지원하려는 시도는 더 큰 설계 공간을 노출시킬 수 있습니다. 그러므로,패키징 ZK-EVM은 약속과 도전을 모두 가져옵니다。

캡슐화 제안자와 빌더 분리(ePBS)

MEV의 등장으로 블록 생산은 대규모 경제 활동이 되었으며, 정교한 행위자는 단순히 거래의 멤풀을 관찰하고 이를 포함하는 기본 알고리즘보다 더 많은 수익을 창출하는 블록을 생성할 수 있습니다. 지금까지 이더리움 커뮤니티는 MEV-Boost와 같은 오프 프로토콜 제안자-빌더 분리 체계를 사용하여 이 문제를 해결하려고 노력해 왔습니다. 이를 통해 일반 검증자(제안자)가 블록을 푸시할 수 있습니다. 빌딩은 전문 행위자(빌더)에게 아웃소싱됩니다. ).

그러나 MEV-Boost는 릴레이라고 하는 새로운 종류의 행위자에 대해 신뢰를 가정합니다. 지난 2년 동안 패키지형 PBS를 만들자는 제안이 많이 있었습니다. 이렇게 하면 어떤 이점이 있나요? 이 경우 대답은 매우 간단합니다. 프로토콜 기능을 직접 사용하여 구축한 PBS는 해당 기능을 사용하지 않고 구축한 PBS보다 더 강력합니다(신뢰 가정이 약하다는 점에서). 이는 프로토콜 내에 가격 오라클을 캡슐화하는 경우와 유사합니다. 하지만 이 경우에는 강한 반대가 있습니다.

개인용 메모리 풀 캡슐화

사용자가 트랜잭션을 보내면 체인에 포함되기 전에도 즉시 공개되어 모든 사람이 볼 수 있습니다. 이로 인해 많은 애플리케이션 사용자가 선행 실행과 같은 경제적 공격에 취약해졌습니다.

최근에는 블록에 되돌릴 수 없게 허용될 때까지 사용자의 거래를 암호화하는 비공개 멤풀(또는 암호화 멤풀) 생성을 전담하는 많은 프로젝트가 있었습니다.

그러나 문제는 이러한 방식에는 특별한 종류의 암호화가 필요하다는 것입니다. 사용자가 시스템을 범람시켜 먼저 해독하는 것을 방지하려면 거래가 실제로 되돌릴 수 없게 승인된 후에 암호화가 자동으로 해독되어야 합니다.

이러한 형태의 암호화를 구현하기 위해서는 서로 다른 절충안을 가진 다양한 기술이 있습니다. Jon Charbonneau는 이에 대해 다음과 같이 잘 설명했습니다.

• 중앙 집중식 운영자 암호화, Flashbots Protect와 같은。

• 시간 잠금 암호화, 이 암호화된 형식은 특정 순차적 계산 단계 후에 누구나 해독할 수 있으며 병렬화할 수 없습니다.

• 임계값 암호화, 데이터를 해독하는 정직한 다수 위원회를 신뢰합니다. 구체적인 제안 사항은 폐쇄형 비콘 체인 개념을 참조하세요.

• 신뢰할 수 있는 하드웨어, SGX와 같은.

안타깝게도,각 암호화 방법에는 서로 다른 약점이 있습니다. 각 솔루션마다 이를 신뢰하려는 사용자 세그먼트가 있지만 레이어 1에서 실제로 받아들일 만큼 충분히 신뢰할 수 있는 솔루션은 없습니다.따라서 적어도 지연된 암호화가 완성되거나 다른 기술적 혁신이 이루어지기 전까지는레이어 1에 선행 실행 방지 기능을 캡슐화하는 것은 어려운 제안인 것 같습니다., 많은 애플리케이션 솔루션이 등장할 만큼 충분히 가치 있는 기능임에도 불구하고.

캡슐화된 유동성 스테이킹

Ethereum DeFi 사용자의 일반적인 요구 사항은 ETH를 스테이킹과 다른 애플리케이션의 담보로 동시에 사용할 수 있는 능력입니다. 또 다른 일반적인 요청은 단순히 편의를 위한 것입니다. 사용자는 노드를 실행하고 항상 온라인으로 유지하는 복잡함 없이 스테이킹(및 온라인 스테이킹 키 보호)할 수 있기를 원합니다.

이 두 가지 요구 사항을 모두 충족하는 가장 간단한 스테이킹 인터페이스는 ERC 20 토큰입니다. 즉, ETH를 ETH 스테이킹으로 변환하고 보유했다가 다시 변환하는 것입니다. 실제로 Lido 및 Rocket Pool과 같은 유동성 스테이킹 제공업체는 이미 이 작업을 수행하고 있습니다. 그러나 유동성 스테이킹에는 몇 가지 자연스러운 중앙화 메커니즘이 있습니다. 사람들은 가장 친숙하고 유동적이기 때문에 자연스럽게 가장 큰 버전의 ETH를 스테이킹하게 됩니다.

스테이킹된 ETH의 각 버전에는 누가 기본 노드 운영자가 될 수 있는지 결정하기 위한 몇 가지 메커니즘이 필요합니다. 공격자가 합류하여 사용자 자금을 사용하여 공격을 확장하기 때문에 무제한일 수 없습니다. 현재 상위 2개는 DAO 화이트리스트 노드 운영자가 있는 Lido와 8ETH 예치금으로 누구나 노드를 실행할 수 있는 Rocket Pool입니다. 두 가지 방식은 위험도가 다릅니다. 로켓 풀(Rocket Pool) 방식은 공격자가 네트워크에 대해 51%의 공격을 감행하여 사용자가 비용의 대부분을 지불하도록 강요하는 반면, DAO 방식은 특정 스테이킹된 토큰이 지배하게 되면 다음과 같은 위험이 발생합니다. 잠재적으로 손상될 수 있는 단일 거버넌스 가젯이 모든 이더리움 유효성 검사기의 상당 부분을 제어합니다. Lido와 같은 프로토콜은 이미 안전 장치를 갖추고 있지만 단일 방어 계층만으로는 충분하지 않을 수 있습니다.

단기적으로 한 가지 옵션은 생태계 참가자가 다양한 유동성 스테이킹 공급자를 사용하여 지배적인 플레이어가 시스템적 위험을 초래할 가능성을 줄이도록 권장하는 것입니다. 그러나 장기적으로 볼 때 이는 불안정한 균형이며, 문제 해결을 위해 도덕적 압력에 지나치게 의존하는 것은 위험합니다. 자연스러운 질문이 생깁니다.유동성 스테이킹을 덜 중앙 집중화하기 위해 프로토콜에 일부 기능을 캡슐화하는 것이 합리적일까요?

여기서 중요한 질문은 어떤 종류의 프로토콜 내 기능인가입니다. 프로토콜 내에서 단순히 대체 가능한 ETH 스테이킹 토큰을 생성할 때의 한 가지 문제는 노드를 실행할 사람을 선택하기 위해 캡슐화된 이더리움 전체 거버넌스가 있어야 하거나 개방형이어야 한다는 것입니다. 도구.

흥미로운 아이디어는 유동성 스테이킹 극대화에 관한 Dankrad Feist의 기사입니다. 먼저, 이더리움이 51% 공격을 받으면 공격받은 ETH의 5%만 삭감될 수 있다고 가정해 보겠습니다. 이는 합리적인 절충안입니다. 현재 2,600만 개 이상의 ETH가 스테이킹되어 있고, 그 중 1/3(~800만 ETH)을 공격하는 비용은 과도합니다. 특히 한 번에 얼마나 많은 모델 외부 공격을 수행할 수 있는지 고려하면 더욱 그렇습니다. 더 낮은 비용. 실제로 단일 슬롯 최종성을 구현하기 위한 슈퍼 위원회의 제안에서 유사한 절충안이 이미 탐색되었습니다.

공격 ETH의 5%만 삭감된다는 점을 인정하면 스테이킹된 ETH의 90% 이상이 삭감의 영향을 받지 않으므로 프로토콜 내에서 대체 가능한 유동 스테이킹 토큰으로 사용될 수 있습니다. 다른 응용 프로그램.

이 길은 흥미롭습니다. 하지만 여전히 한 가지 질문이 남습니다.캡슐화란 정확히 무엇입니까?로켓 풀은 매우 유사하게 작동합니다. 각 노드 운영자가 일부 자금을 제공하고 유동성 스테이커가 나머지를 제공합니다. 최대 삭감 페널티를 2 ETH로 제한하기 위해 일부 상수를 간단히 조정할 수 있으며 Rocket Pool의 기존 rETH는 위험이 없게 됩니다.

간단한 프로토콜 조정으로 다른 영리한 작업도 수행할 수 있습니다. 예를 들어 노드 운영자(높은 담보 요구 사항)와 예금자(최소 담보 요구 사항이 없으며 언제든지 가입 및 탈퇴 가능)라는 두 가지 계층의 스테이킹을 갖춘 시스템을 원하지만 여전히 무작위로 샘플링된 노드를 부여하고 싶다고 가정해 보겠습니다. 예금자 위원회는 포함되어야 하는 거래 목록을 권장하고(검열 저항 이유로) 비활성 누출 중 포크 선택을 제어하거나 블록에 서명을 요구하는 등 노드 운영자의 중앙 집중화를 방지할 수 있는 권한을 갖습니다. 이는 각 유효성 검사기가 (i) 일반 스테이킹 키를 제공하고 (ii) 각 슬롯에서 사용할 수 있는 ETH 주소를 호출하여 출력하도록 프로토콜을 조정하여 본질적으로 프로토콜을 벗어나는 방식으로 수행될 수 있습니다. 보조 서약 키. 프로토콜은 두 키 모두에 권한을 부여하지만 각 슬롯에서 두 번째 키를 선택하는 메커니즘은 스테이킹 풀 프로토콜에 맡길 수 있습니다. 일부 기능을 직접 캡슐화하는 것이 더 나을 수도 있지만 어떤 것은 포함하고 다른 것은 사용자에게 맡기는 디자인 공간이 존재한다는 점은 주목할 가치가 있습니다.

추가 사전 컴파일 캡슐화

사전 컴파일된 계약(또는 사전 컴파일된 계약)은 EVM 스마트 계약 코드가 아닌 클라이언트 코드에서 기본적으로 구현된 논리를 사용하여 복잡한 암호화 작업을 구현하는 Ethereum 계약입니다. 프리코딩은 이더리움 개발 초기부터 채택된 절충안입니다. 가상 머신의 오버헤드는 일부 매우 복잡하고 고도로 전문화된 코드에 비해 너무 크기 때문에 일부 중요한 애플리케이션을 네이티브 코드로 구현할 수 있습니다. 오늘날 여기에는 기본적으로 일부 특정 해시 함수와 타원 곡선 작업이 포함됩니다.

현재 기본 이더리움 계정에 사용되는 secp 256 k 1과 약간 다른 타원 곡선인 secp 256 r 1에 대한 사전 컴파일을 추가하려는 추진이 진행 중입니다. 이는 신뢰할 수 있는 하드웨어 모듈에서 잘 지원되므로 널리 사용됩니다. 이를 사용하여 지갑 보안을 강화합니다. 최근 몇 년 동안 커뮤니티에서는 BLS-12-377, BW 6-761, 일반화된 페어링 및 기타 기능에 대한 사전 컴파일을 추가하도록 추진했습니다.

더 많은 사전 컴파일러가 필요하다는 이러한 요청에 대한 반론은 이전에 추가된 많은 사전 컴파일러(예: RIPEMD 및 BLAKE)가 예상보다 훨씬 적게 사용되었다는 것이며, 우리는 이로부터 배워야 합니다. 특정 작업에 대해 더 많은 사전 컴파일을 추가하는 대신 EVM-MAX 및 Hibernate-But-Always-Resumable SIMD 제안과 같은 아이디어를 기반으로 하는 보다 부드러운 접근 방식에 집중해야 할 것입니다. 이를 통해 EVM 구현을 더 낮은 비용으로 실행할 수 있습니다. 다양한 코드 클래스. 아마도 거의 사용되지 않는 기존 사전 컴파일도 제거되고 동일한 기능의 (필연적으로 덜 효율적인) EVM 코드 구현으로 대체될 수 있습니다. 즉, 속도를 높일 만큼 가치 있는 특정 암호화 작업이 여전히 있을 수 있으므로 미리 컴파일된 것으로 추가하는 것이 합리적입니다.

이 모든 것에서 우리는 무엇을 배웠습니까?

가능한 한 적게 캡슐화하려는 욕구는 이해할 수 있고 좋은 것입니다. 이는 사용자의 다양한 요구에 쉽게 적응하고 소프트웨어 팽창의 저주를 피할 수 있는 미니멀리스트 소프트웨어를 만드는 Unix 철학적 전통에서 비롯됩니다. 그러나 블록체인은 개인용 컴퓨팅 운영체제가 아닌 사회적 시스템이다. 이는 프로토콜에 특정 기능을 캡슐화하는 것이 합리적이라는 것을 의미합니다.

대부분의 경우 이러한 다른 예는 계정 추상화에서 본 것과 유사합니다. 하지만 우리는 몇 가지 새로운 교훈도 얻었습니다.

• 기능을 캡슐화하면 스택의 다른 영역에서 중앙 집중화 위험을 방지하는 데 도움이 될 수 있습니다.：

기본 프로토콜을 최소화하고 단순하게 유지하면 프로토콜 외부의 일부 생태계로 복잡성이 밀려나는 경우가 많습니다. 유닉스 철학의 관점에서 보면 이것은 괜찮습니다. 그러나 때로는 높은 고정 비용으로 인해 오프 프로토콜 생태계가 중앙 집중화될 위험이 있습니다. 캡슐화는 때때로 사실상 중앙 집중화를 줄일 수 있습니다.

• 너무 많이 캡슐화하면 프로토콜에 대한 신뢰와 거버넌스 부담이 과도하게 늘어날 수 있습니다.：

이것이 이더리움 합의를 오버로드하지 마세요에 대한 이전 기사의 주제입니다: 특정 기능을 캡슐화하는 것이 신뢰 모델을 약화시키고 이더리움 전체를 더욱 주관적으로 만들면 이는 이더리움을 약화시킵니다. 신뢰할 수 있는 중립성. 이러한 경우 특정 기능을 이더리움 자체로 가져오려고 하기보다는 이더리움 위에 메커니즘으로 특정 기능을 두는 것이 더 좋습니다. 암호화된 메모리 풀이 가장 좋은 예입니다. 적어도 대기 시간 암호화가 개선될 때까지는 캡슐화하기가 약간 어려울 수 있습니다.

• 너무 많이 캡슐화하면 프로토콜이 지나치게 복잡해질 수 있습니다.：

프로토콜 복잡성은 프로토콜에 너무 많은 기능을 추가함으로써 증가되는 시스템적 위험입니다. 사전 컴파일이 가장 좋은 예입니다.

• 사용자 요구 사항을 예측할 수 없기 때문에 기능을 캡슐화하는 것은 장기적으로 비생산적일 수 있습니다.：

많은 사람들이 중요하다고 생각하는 기능, 많은 사용자가 사용할 기능은 아마도 실제로는 그다지 자주 사용되지 않을 것입니다.

또한 유동성 스테이킹, ZK-EVM 및 사전 컴파일된 예는 중간 경로, 즉 최소 실행 가능한 암호화의 가능성을 보여줍니다. 프로토콜은 전체 기능을 캡슐화할 필요는 없지만 주요 문제를 해결하는 특정 부분을 포함할 수 있으므로 너무 편집증적이거나 너무 좁지 않게 기능을 쉽게 구현할 수 있습니다. 예는 다음과 같습니다:

• 완전한 유동성 스테이킹 시스템을 캡슐화하는 것보다 스테이킹 페널티 규칙을 변경하여 무신뢰 유동성 스테이킹을 더 실현 가능하게 만드는 것이 좋습니다.

• 더 많은 사전 컴파일러를 캡슐화하는 대신 EVM-MAX 및/또는 SIMD를 캡슐화하여 더 다양한 작업 클래스를 더 쉽게 효율적으로 구현할 수 있도록 해야 합니다.

• 롤업의 전체 개념을 캡슐화하는 대신 EVM 검증을 간단히 캡슐화할 수 있습니다.

이전 다이어그램을 다음과 같이 확장할 수 있습니다.

때로는 무언가를 캡슐화하는 것이 타당할 때도 있으며, 거의 사용되지 않는 사전 컴파일러를 제거하는 것이 한 가지 예입니다. 앞서 언급한 것처럼 전체적인 계정 추상화 역시 캡슐화 해제의 중요한 형태입니다. 기존 사용자에 대한 이전 버전과의 호환성을 지원하려는 경우 메커니즘은 실제로 사전 컴파일을 해제한 메커니즘과 놀랍게도 유사할 수 있습니다. 제안 중 하나는 EIP-5003으로, 이를 통해 EOA는 자신의 계정을 동일한( 또는 더 나은) 기능적 계약.

어떤 기능을 프로토콜에 도입해야 하고 어떤 기능을 생태계의 다른 계층에 남겨야 하는지는 복잡한 균형입니다. 사용자 요구 사항과 사용 가능한 아이디어 및 기술 제품군에 대한 이해가 계속 향상됨에 따라 이러한 절충안은 시간이 지남에 따라 계속해서 개선될 것으로 예상됩니다.