Vitalik: 이더리움의 계정 추상화로 가는 길

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

Vitalik: 이더리움의 계정 추상화로 가는 길

DeFi之道

2022-06-28 12:30

本文约4073字，阅读全文需要约16分钟

ERC-4337‌ 컨센서스 변경이 필요하지 않은 이 대안은 많은 진전을 이루었습니다.

원문 편집: The Way of DeFi

계정 추상화를 통해 스마트 계약 논리를 사용하여 수수료 지불 및 확인 논리뿐만 아니라 거래의 효과를 지정할 수 있습니다. 이는 다중 서명 및 스마트 복구 지갑, 지갑을 변경하지 않고 키를 변경할 수 있는 기능, 양자 보안과 같은 여러 가지 중요한 보안 이점을 제공합니다.

계정 추상화에 대한 많은 접근 방식이 다양한 정도로 제안되고 구현되었습니다. EIP-86, EIP-2938 및 2년 전의 이 문서를 참조하십시오. 오늘날 이러한 EIP의 개발은 개발자가 병합 및 샤딩에 집중하기를 원하기 때문에 중단되었으며, 합의 변경이 필요하지 않은 대안인 ERC-4337은 큰 진전을 이루었습니다.

ERC-4337은 추가 프로토콜 수단을 통해 EIP-2938과 동일한 것을 달성하려고 합니다. 사용자는 블록 제안자 또는 블록 제안자를 위한 번들을 생성하고 단일 트랜잭션으로 패키지화하는 빌더가 배치로 수집하는 사용자 작업이라는 오프체인 메시지를 보내야 합니다. 제안자 또는 빌더는 수수료를 지불하는 작업만 수락하도록 작업을 필터링할 책임이 있습니다. 사용자 작업을 위한 별도의 mempool이 있으며 이 풀에 연결하는 노드는 ERC-4337 관련 유효성 검사를 수행하여 사용자 작업이 전달되기 전에 지불되도록 합니다.

ERC-4337은 순전히 자발적인 ERC로서 많은 일을 할 수 있습니다. 그러나 다음과 같은 몇 가지 주요 영역에서 진정한 프로토콜 내 솔루션보다 약합니다.

기존 사용자는 모든 자산과 활동을 새 계정으로 이동하지 않고는 업그레이드할 수 없습니다.
추가 가스 오버헤드(기본 UserOperation 사용자 작업은 약 42k이고 기본 트랜잭션은 약 21k입니다.)
트랜잭션을 대상으로 하고 사용자 작업을 놓치는 프로토콜 내 검열 방지 기술(예: crLists)의 이점 감소

최상의 결과를 얻기 위한 현실적인 경로는 단기적으로 ERC-4337에 대한 강력한 지원으로 시작한 다음 시간이 지남에 따라 EIP를 추가하여 약점을 보완하는 것입니다.모든 사람이 ERC-4337 준수를 구체적으로 약속할 필요는 없습니다. 대신, 프로토콜 내 지원은 보다 일반적이고 ERC-4337과 그 대안 및 개선 사항을 지원하도록 설계될 수 있습니다.

보조 제목

EOA 지갑을 스마트 계약 지갑으로 전환

기존 EOA 지갑을 ERC-4337 지갑으로 업그레이드하기 위해 EOA가 계약 코드를 설정하는 작업을 수행할 수 있도록 EIP를 만들 수 있습니다. EOA가 이를 달성하면 전환을 되돌릴 수 없습니다. 그때부터 해당 계정은 스마트 계약 지갑으로만 사용됩니다. 다행스럽게도 ERC-4337 계정은 DELEGATECALL 프록시이므로 원하는 경우 나중에 지갑을 다른 ERC 호환 스마트 계약으로 변환할 수 있습니다.

이 업그레이드 프로세스를 구현하는 방법에 대한 몇 가지 제안이 있습니다.

1. "코드 교체" 거래 유형

이것은 아직 공식 EIP로 도입되지 않았지만 방법은 간단합니다. 새 EIP-2718 트랜잭션 유형을 추가하고 account_code를 calldata로 바꾸면 됩니다.

2、AUTH_USURP (EIP-5003)

EIP-5003은 새로운 AUTHUSURP opcode를 도입하는 EIP-3074(AUTH 및 AUTHCALL)에 대한 확장 제안입니다. AUTHUSURP는 EIP-3074 메커니즘을 사용하여 EOA 주소 A가 다른 주소 B가 자신을 대신하여 작동하도록 승인한 경우 B가 A의 코드를 설정하도록 허용합니다.

보조 제목

강제 변환

장기적으로 프로토콜을 단순화하고 계약을 유일한 계정 유형으로 만들어 프로토콜에서 ECDSA를 제거하기 위해 필수 변환을 수행할 수 있습니다.한 가지 가능한 접근 방식은 특정 블록부터 시작하여 코드가 없는 계정을 특정 표준화된 "ERC-4337 EOA 지갑" 코드가 있는 계정으로 취급하는 재정의 규칙을 추가하는 것입니다.

질문

계약 내 ECRECOVER 검증:일부 스마트 계약은 ECRECOVER의 서명을 특정 계정에 제공하면 해당 계정을 소유한다는 가정에 의존합니다. EOA가 계약으로 변환된 후 확인 키가 변경된 경우 원래 키는 여전히 이러한 특정 컨텍스트에서 계정을 "나타낼" 수 있습니다. 계정에 코드가 있는 경우 이러한 모든 프로젝트가 ECRECOVER 대신 EIP-1271 인증을 사용하도록 변경하도록 장려하기 시작하면 됩니다.
아직 감지되지 않은 계정:강제 변환의 한 가지 문제는 자산(예: ERC20, ERC721, ETH 제외)을 소유하고 있지만 트랜잭션을 보내거나 받지 않은 계정이므로 프로토콜이 이러한 계정을 안정적으로 감지할 수 없습니다. 프로토콜은 이러한 계정을 기본 지갑으로 영구적으로 변환하는 기능을 유지하거나 변환되지 않은 계정이 소각되는 데드라인(예: 배포 후 4년)이 있어야 합니다.
EOA는 양도 불가능 여부만 확인합니다.보조 제목

가스 비용 절감

ERC-4337 지갑은 다음과 같은 이유로 더 높은 가스 비용에 직면합니다(기본 ERC-4337 작업의 경우 약 42,000 가스, 기본 정기 트랜잭션의 경우 21,000 가스).

1. 개별 스토리지 읽기/쓰기 비용을 많이 지불해야 합니다.EOA의 경우 이러한 비용은 21000 가스의 단일 지불로 묶입니다.

(1) pubkey+nonce(~5000)를 포함하는 스토리지 슬롯을 편집합니다.

(2) 사용자 조작 호출 데이터 비용(약 4500, 압축을 통해 약 2500으로 줄일 수 있음);

（3）ECRECOVER (~3000)；

(4) 지갑 자체에 대한 최초 액세스(~2600)

(5) 수취인 계좌 최초접속(~2600)

(6) 수취인 계좌로 ETH 이체 (~9000)

(7) 수수료를 지불하기 위한 보관소 수정 (~5000)

(8) 에이전트가 포함된 스토리지 슬롯(~2100)에 액세스한 다음 에이전트 자체(~2600)에 액세스합니다.

2. 위의 스토리지 읽기/쓰기 비용 외에도 계약은 "비즈니스 로직"(Unpack UserOperation, 해시, 변수 섞기 등)을 실행해야 합니다.

3. 로그 수수료를 지불하기 위해 가스를 소비해야 함(EOA는 로그를 게시하지 않음)

4. 일회성 계약 생성 비용(약 32,000 가스, 프록시의 각 코드 바이트당 200 가스, 프록시 주소 설정을 위한 20,000 가스 추가)

이러한 문제 중 많은 부분이 Verkle 트리 감시 가스 비용 EIP 및 쓰기 가스 비용 개혁 EIP에서 자동으로 해결되어 대용량 스토리지 비용을 더 적은 시스템으로 대체합니다. 예를 들어 pubkey와 nonce는 슬롯 0~63에 저장될 수 있으므로 액세스 비용이 1000 미만으로 줄어듭니다. 대상 계정과 수신 계정은 처음에 한 번만 액세스하면 되므로 사용자는 ETH를 전송하고 수수료를 지불할 때 더 적은 비용을 지불합니다.

단순화하는 데 도움이 되는 더 많은 EIP가 있습니다. 예를 들어:

슬롯 0의 자발적인 ERC를 사용하지 못하도록 스마트 계약 논리를 비활성화하면 저장소 프록시에 사용할 수 있으므로 더 저렴한 가스 비용의 이점을 누릴 수 있습니다.
"코드 주소" 필드를 사용하면 프록시를 더 쉽게 수행하고 가스를 덜 소비할 수 있습니다.
"빠른 압축" 사전 컴파일을 통해 모든 0바이트에 대한 calldata 가스 비용을 지불하지 않고도 ABI 개체를 더 쉽게 사용할 수 있습니다.

보조 제목

crLists

crLists는 전체 프로토콜 제안자/빌더 분리 체계가 활성화된 경우에만 실제로 적용할 수 있기 때문에 이것은 장기적인 문제입니다. 문제는 제안자가 포함할 가치가 있는(즉, 충분한 수수료를 지불하는) 사용자 작업을 식별하여 프로토콜이 공간이 있는 다음 블록에 포함되도록 강제할 수 있기를 바라는 것입니다.

이를 위해서는 프로토콜에서 "유효성 검사" 및 "실행"의 개념을 명시해야 합니다. 사용자 작업의 경우 작업을 검증하는 정의된 방법과 작업을 수행하는 정의된 방법이 있어야 합니다. 즉, 작업이 검증되면 작업을 수행하려는 시도는 검증 중에 읽기 상태가 수정되지 않는 한 지불이 보장됩니다. . 이러한 작업은 ABI 메서드를 포함하거나 EOF EIP가 구현된 경우 전용 EOF 섹션을 추가하여 구현할 수 있습니다.

다행스럽게도 이것은 ERC-4337을 최종 표준으로 취급할 것을 요구하지 않고 대신에 ERC-4337이 지원하는 약한 개념을 통합하여 다른 ERC에서 쉽게 지원할 수 있습니다.

그 이유는 ERC-4337 및 EIP-2938의 복잡성이 더 강한 DoS 저항 문제를 해결하는 것과 크게 관련되어 있기 때문입니다. 하나의 작업이 수백 개의 다른 작업을 취소하도록 하는 것은 불가능합니다. 공격. 이를 위해서는 어떤 계정 확인이 액세스할 수 있는지에 대한 제한을 부과해야 합니다. 여기에서 더 간단한 작업을 수행할 수 있습니다. 유효성 검사 중에 터치된 상태 개체를 기록하고 해당 상태 개체가 편집된 경우 포함할 필요가 없습니다.

이를 통해 개별 계정은 검열 저항과 유연성 사이에서 자체적인 절충안을 선택할 수 있습니다. 극단적인 경우 계정은 원하는 경우 Uniswap을 통해 확인하는 동안 수수료를 지불할 수 있지만 Uniswap 상태에 영향을 미치는 거래를 누구나 보낼 수 있기 때문에 그러한 계정은 사실상 검열 저항성을 보장하지 않습니다.

crList 설계의 일반적인 개요는 다음과 같습니다.

제안에는 포함할 작업 목록을 지정하는 crList와 각 작업이 읽는 상태 개체(키, 값) 쌍 목록이 포함될 수 있습니다. crList를 수락하는 빌더(또는 다른 사용자)는 모든 작업이 유효성 검사를 통과하는지 확인해야 합니다.
블록에 남은 가스가 충분하지 않거나 실행 시 현재 상태가 작업에서 읽은 상태 개체 중 하나를 편집하지 않는 한 crList의 모든 작업을 실행하려면 블록이 필요합니다.

ERC-4337의 나머지 복잡성은 mempool 보안에만 사용됩니다. 원칙적으로 모두 동일한 검증 및 시행 표준을 준수하는 한 서로 다른 방식으로 이 목표를 달성하는 여러 경쟁 ERC가 있을 수 있습니다.

보조 제목