비탈릭의 최신 제안 EIP-7702 설명: EIP-3074의 대체품

저자: 비탈릭, 이더리움 창립자, 번역: xiaozou@Golden Finance

1, 개요

계약_코드 필드와 서명을 추가하고 해당 거래 기간 동안 서명 계정(txt .origin과 동일할 필요 없음)을 스마트 컨트랙트 지갑으로 변환하는 새로운 거래 유형을 추가하여 유사한 EIP-3074 기능을 제공하는 것을 목표로 합니다.

2, 동기

애플리케이션의 사용성을 높이고 경우에 따라 보안 강화를 지원하기 위해 EOA에 단기 기능 향상을 추가하는 것은 많은 사람에게 큰 관심을 받고 있습니다. 관심이 있습니다. 세 가지 구체적인 애플리케이션은 다음과 같습니다:

• 일괄 처리: 동일한 사용자가 단일 원자 트랜잭션에서 여러 작업을 수행할 수 있도록 합니다. 일반적인 예로 ERC-20을 승인한 다음 다시 사용하는 것이 있으며, 이는 두 번의 트랜잭션이 필요한 오늘날의 탈중앙화 거래소에서 흔히 볼 수 있는 워크플로입니다. 일괄 처리의 높은 수준의 사용 사례에는 첫 번째 작업의 출력이 두 번째 작업의 입력의 일부가 되는 종속성이 포함되기도 합니다.

• 후원: 계정 X가 계정 Y를 대신해 거래 수수료를 지불합니다. 계정 X는 다른 ERC를 통해 거래 수수료를 지불할 수 있습니다. 계정 X는 다른 ERC-20을 통해 이 서비스 비용을 지불하거나 사용자의 트랜잭션을 무료로 포함하는 앱 운영자가 될 수 있습니다.

• 권한 저하: 사용자는 서브키에 서명하고 계정의 글로벌 액세스 권한보다 훨씬 약한 특정 권한을 부여할 수 있습니다. 예를 들어, 이더리움 대신 ERC-20 토큰으로 결제하거나 하루 총 잔액의 1%를 사용하거나 특정 애플리케이션과만 상호 작용할 수 있는 권한을 부여하는 것을 상상할 수 있습니다.

EIP-3074는 이러한 모든 사용 사례 문제를 해결하지만, 향후 호환성에 대한 우려가 있습니다.

• 이것은 결국 모든 사용자가 스마트 컨트랙트 지갑을 사용하는 '계정 추상화 엔드게임'의 세계에서는 쓸모없는 두 가지 옵코드인 AUTH와 AUTHCALL을 도입합니다(결국 그렇게 될 것으로 보입니다). (결국에는 그렇게 될 것으로 보이는데, 적어도 양자 컴퓨터가 EOA에서 사용하는 ECDSA를 종료할 것이기 때문입니다).

• 이는 "스마트 콘트랙트 지갑" 생태계와는 독립적인 "인발자 콘트랙트" 생태계의 발전으로 이어질 것입니다. 이는 "스마트 컨트랙트 지갑" 생태계와 독립적인 "인발자 컨트랙트" 생태계로 발전하여 노력의 분열과 시너지 부족을 초래할 것입니다.

이 EIP의 목표는 이 두 가지 문제 없이 EIP-3074의 모든 사용 사례를 가능하게 하는 것입니다.

3, 사양

이 문서에서 "MUST" 키워드를 사용합니다, "해서는 안된다", "필수", "하여야한다", "해서는 안된다", "해서는 안된다 ", "해야 한다", "하지 말아야 한다", "권장", "MAY" 및 RFC 2119에 설명된 "OPTIONAL".

매개 변수:

• FORK_BLKNUM = TBD

• TX_TYPE = TBD

• MAGIC = TBD

• MAGIC = TBD

• PER_CONTRACT_CODE_BASE_COST = 5000

포크_블록_넘버부터 새로운 EIP-가 도입되었습니다. 트랜잭션 유형이 TX_TYPE(미정)인 2718 트랜잭션입니다.

이 트랜잭션에 대한 EIP-2718 트랜잭션 페이로드는 다음과 같습니다:

rlp([chain_id, nonce, max_priority_fee _per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s], ...]) 서명_y_패리티, 서명_r, 서명_s])

새 트랜잭션의 내재 비용은 EIP-2930에서 상속되며 다음과 같습니다: 21000 + 16 * 0이 아닌 콜데이터 바이트 수 + 4 * 0 콜데이터 바이트 + 1900 * 액세스 목록 저장 키 수 + 2400 * 액세스 목록 주소 수

또한 각 contract_code에 16 * 0이 아닌 콜데이터 바이트가 추가됩니다. 코드에 16 * 0이 아닌 콜데이터 바이트 + 4 * 0 콜데이터 바이트, 그리고 계약_코드 배열의 길이를 곱한 PER_CONTRACT_CODE_BASE_COST를 더합니다.

거래 실행 시작 시, 각 [contract_code, y_parity, r, s] 튜플에 대해:

• set signer = ecrecover(keccak(MAGIC + contract_code), y_parity, r, s]

• 서명자의 컨트랙트 코드가 null인지 확인합니다

• 서명자의 컨트랙트 코드를 contract_code로 설정합니다

트랜잭션이 끝날 때 각 서명자의 컨트랙트 코드를 null로 재설정합니다.

계약 코드 서명자와 트랜잭션의 txt .origin이 다를 수 있습니다.

4, 기초

(1) EIP-3074. Strong>유스케이스 변환

이 설계에서는 기존 EIP-3074 워크플로우를 큰 노력 없이 변환할 수 있습니다. 구체적으로, AUTH와 AUTHCALL은 이 EOA에 대한 호출로 대체됩니다. 한 가지 접근 방식은 계약_코드가 사용자 지갑(가스를 절약하기 위해 DELEGATECALL 전달자가 될 수 있음)이 되어 확인과 실행이라는 두 가지 기능을 노출하는 것입니다.

• AUTH는 TSTORE를 사용하여 authorized[msg.sender, ...] = True를 로컬로 설정하는 verify 코드로 대체됩니다. = True

• AUTHCALL은 TLOAD를 사용하여 authorized[msg.sender, ...]의 유효성을 검사하는 실행 호출로 대체됩니다. 를 확인한 다음 거기서부터 실행합니다.

따라서 "기존 EIP-3074 워크플로"에서 이 새로운 시나리오의 워크플로로 변환하는 것은 매우 간단합니다.

(2) 향후 계정 추상화와의 호환성

이 EIP는 향후 계정 추상화와 매우 높은 수준의 호환성을 갖도록 설계되었으며 과도하게 보존되지는 않을 것입니다. ERC-4337 또는 RIP-7560의 모든 세부 사항은 보존되지 않습니다.

자세한 내용은 다음과 같습니다:

• . 사용자가 서명해야 하는 컨트랙트 코드는 기존 ERC-4337 지갑 코드일 수 있습니다.

• 사용된 "코드 경로"는 순수 스마트 컨트랙트 지갑 공간에서 전부는 아니지만 많은 경우에 계속 "작동"하는 경로입니다. "사용된 "코드 경로"는 순수 스마트 컨트랙트 지갑 공간에서 많은(전부는 아닐 수도 있지만) 경우에 계속 "작동"하는 경로입니다.

• 따라서 대체로 동일한 생태계가 될 것이므로 "두 개의 별도 코드 생태계를 만드는" 문제를 피할 수 있습니다. 이 솔루션에서 결합해야 하는 일부 워크플로가 있을 수 있으며, 계정 추상화 엔드포인트 아래의 다양한 "보다 네이티브" 환경에서 더 잘 작동할 수 있지만 이는 상대적으로 작은 부분입니다.

• 옵코드를 추가할 필요가 없으며, EOA 이후 환경에서는 쓸모가 없어질 것입니다.

• 이를 통해 EOA는 기존 엔트리포인트와 호환되는 방식으로 일시적으로 자신을 컨트랙트로 변환하여 ERC-4337 트랜잭션 패키지에 포함시킬 수 있습니다.

• 배포되면 EIP-5003은 "한 줄의 코드"가 됩니다. 트랜잭션이 끝날 때 코드를 null로 설정하지 않도록 플래그를 추가하기만 하면 됩니다.

5, 하위 호환성

EIP는 계정 잔액이 해당 계정에서 발생한 거래에 의해서만 줄어들 수 있는 틀을 깨뜨리고 있습니다. 이는 메모리 풀 설계와 포함 목록과 같은 다른 EIP에 영향을 미칩니다. 그러나 이러한 문제는 EIP-3074를 포함해 유사한 기능을 제공하는 모든 제안에 공통적으로 적용됩니다.

6, 보안 우려

EIP-. 3074 보안 우려 사항 중 많은 부분이 일반적입니다. 특히 사용자 지갑은 계약 코드에 서명할 때 각별히 주의해야 합니다.