Vitalik이 제안한 EIP-2938은 이더리움에 어떤 변화를 가져올까요?

편집자 주: 이 기사의 출처는크립토 밸리 라이브 (ID: cryptovalley)편집자 주: 이 기사의 출처는

크립토 밸리 라이브 (ID: cryptovalley)"크립토 밸리 라이브 (ID: cryptovalley)", 저자: Rajeev Gopalakrishna, 번역자: Olivia, Odaily는 허가를 받아 복제했습니다.

이더리움에는 두 가지 유형의 계정이 있습니다. 외부 자체 계정(EOA) 및 계약 계정(CA). EOA는 개인 키에 의해 제어되는 반면 CA는 그 안에 포함된 스마트 계약 코드에 의해 제어됩니다. EOA만이 가스를 지불하여 트랜잭션 실행을 시작할 수 있기 때문에 EOA는 항상 CA보다 더 많은 권한을 가지고 있습니다. 계정 추상화(AA)는 계약이

최상층

계정 추상화의 동기는 사용자가 지갑, DApp 및 DeFi와 같은 다양한 시나리오에서 Ethereum과 상호 작용할 때 사용자 경험을 크게 향상시키는 것입니다. 계정 추상화는 이더리움에서 가스를 지불할 수 있는 시기와 가스를 지불할 사람을 결정하는 기본 계층 기능을 제공합니다.

Status Messenger 앱은 Ethereum 지갑 및 Web3 DApp 브라우저와 함께 개인 정보 보호에 중점을 둔 메시징 시스템을 통합합니다. 상태 지갑은 현재 EOA 지갑으로, 다중 서명 보안, 소셜 복구, 이자율 제한, 허용/거부 주소 목록, 가스 없는 메타 거래와 같이 스마트 계약 지갑만이 할 수 있는 풍부한 사용자 경험을 제공하는 데 제한이 있습니다. . 현재 스마트 계약 지갑 사용자는 가스 요금 변동의 영향을 경험하고 있으며 타사 리피터는 이 문제를 효과적으로 해결할 수 없습니다. 계정 추상화는 이 문제를 해결하는 것을 목표로 합니다.

이 백서에서는 스마트 계약 지갑의 맥락에서 계정 추상화의 필요성을 다룹니다. 그런 다음 프로토콜 변경 사항과 노드에 미치는 영향을 설명하여 계정 추상화의 주요 측면을 살펴봅니다. 마지막으로 확장에 대한 몇 가지 제안에 대해 논의하고 계정 추상화의 영향을 모두 받을 수 있는 이더리움과 인터페이스하는 Status 프로젝트에 대해 계획된 로드맵을 합리화하여 결론을 내립니다."보조 제목"연혁 및 동기"계정 추상화는 원래 2017년에 EIP-86으로 제안되었습니다."

트랜잭션 출처 및 서명 요약

, 하지만 이 아이디어의 기원은 2016년으로 거슬러 올라갑니다. 그 당시 다음과 같이 제안되었습니다.

계정을 안전하게 유지하는 유일한 "표준" 방법으로 ECDSA와 기본 논스 체계를 사용하는 프로토콜 내 메커니즘을 사용하는 대신 초기 단계를 수행하고 장기적으로 모든 계정이 계약이고 모델을 구축하는 것이 좋습니다. 계약 가스를 지불할 수 있으며 사용자는 자신의 보안 모델을 자유롭게 정의할 수 있습니다.

초기 제안은 많은 프로토콜 변경이 필요하고 보안을 보장해야 하기 때문에 어려운 것으로 간주되었습니다. 보다 최근에 Vitalik 등은 EIP-2938의 초안을 제안했는데, 이는 프로토콜/합의 변경을 최소화하고 노드 멤풀 규칙을 통해 필요한 안전 보장을 시행함으로써 보다 달성 가능한 접근 방식을 설명합니다. Vitalik의 Ethereum Engineering Group Meetup 프레젠테이션과 Sam Wilson과 Ansgar Dietrichs(다른 2명의 EIP 작성자)의 ETH 온라인 프레젠테이션(및 관련 기사 1 및 2)은 이 주제에 대한 자세한 소개를 제공합니다. 이 기사에서는 이러한 모든 소스에서 얻은 주요 내용을 강조합니다.

동기: 계정 추상화 이면의 동기는 매우 간단하지만 근본적입니다. 오늘날 이더리움 트랜잭션은 프로그래밍 가능한 효과(스마트 계약 호출로 구현)가 있지만 고정된 유효성만 있습니다. 충분한 계정 잔액이 거래에 유효합니다. 계정 추상화는 새로운 계정 추상화 트랜잭션 유형을 도입하여 고정 유효성에서 프로그래밍 가능한 유효성으로 트랜잭션을 업그레이드합니다. 이 계정 추상화 트랜잭션 유형은 항상 특수 주소에서 나오며 프로토콜은 이에 대한 서명, 논스 또는 잔액 확인을 요구하지 않습니다. 이러한 계정 추상화 거래의 유효성은 자체 유효성 규칙을 시행할 수 있는 대상 스마트 계약에 의해 결정되며, 그 후에 그러한 거래에 대한 지불을 결정할 수 있습니다.

그렇다면 이것이 유용한 이유는 무엇입니까? 계정 추상화의 이점을 강조하기 위해 이더리움 지갑을 예로 사용합니다.

스마트 계약 지갑: 오늘날 대부분의 이더리움 지갑은 시드 문구에서 생성된 개인 키로 보호되는 EOA 지갑입니다. (BIP-39 시드 구는 2048개 단어에서 무작위로 선택된 12-24개 단어의 순서 목록입니다. 이것은 PBKDF2 함수를 사용하여 생성되는 이진 시드를 얻는 데 필요한 엔트로피를 제공합니다. 그런 다음 이진 시드를 사용하여 BIP-32 지갑용 비대칭 키 쌍.) 나중에 다른 지갑에서 키를 복구하는 데 필요할 수 있으므로 사용자는 시드 문구를 안전한 곳에 보관해야 합니다. 그러나 이러한 지갑은 개인 키 도난이나 시드 문구 분실에 취약하여 사용자 자금 손실을 초래합니다.

스마트 계약 지갑은 스마트 계약을 통해 온체인으로 구현됩니다. 이 지갑은 다중 서명 보안, 소셜 또는 시간 기반 복구, 트랜잭션 또는 금액에 대한 속도 제한, 주소 목록 허용/거부, 가스 없는 트랜잭션 및 일괄 트랜잭션과 같은 기능을 구현하여 프로그래밍 가능한 위험 완화 및 사용자 친화적인 경험을 제공합니다.

스마트 계약 지갑은 취약한 스마트 계약의 보안 위험에 노출되어 있지만 이 위험은 지갑 공급자가 수행하는 보안 테스트 및 감사를 통해 완화할 수 있습니다. EOA 지갑의 위험은 전적으로 지갑 사용자에게 있으며, 이들은 보안을 보장하기 위한 스마트 계약의 절차 없이 시드 문구의 보안을 위임받습니다.

스마트 계약 지갑의 예로는 Argent, Authereum, Dapper, Dharma, Gnosis Safe, Monolith 및 MYKEY가 있습니다. 아래 차트에서 볼 수 있듯이 이러한 지갑의 채택이 증가하고 있는 것으로 보입니다.

Argent는 가디언 개념을 통해 키리스 소셜 복구를 지원합니다. 여기서 가디언은 사용자가 자신의 지갑을 되찾는 데 도움을 주기 위해 신뢰하는 사람 또는 장치입니다. Argent는 또한 은행과 같은 보안(일일 거래 한도, 계정 잠금 및 신뢰할 수 있는 연락처와 같은 기능을 통해)과 Venmo와 같은 유용성(주소 대신 ENS 이름을 사용하고 메타 거래를 지원함으로써)의 조합을 달성하는 것을 목표로 합니다.

노시스 세이프(Gnosis Safe)는 팀 자금 관리에 초점을 맞춘 다중 서명 스마트 계약 지갑으로, 트랜잭션 발생을 승인하려면 최소 팀원 수(m-of-n)가 필요합니다. 또한 메타 트랜잭션을 통해 가스 없는 서명을 가능하게 합니다.

이러한 모든 고급 지갑 기능은 잘 구축된 스마트 계약을 사용해야 합니다. 월렛 사용자는 EOA와 상호 작용하거나 월렛 제공업체에 의존하여 공급자의 중계자 또는 주유소 네트워크와 같은 제3자 중계자 네트워크를 통해 메타 트랜잭션을 지원해야 합니다. 전자는 KYC 이후의 중앙 집중식 거래소에서 ETH 구매에 의존하는 반면, 후자는 사용자의 부담을 중계자에게 전가함으로써 온체인 사용자 경험 마찰을 줄이는 것을 목표로 합니다. 비용은 온체인/온라인 지갑 제공자가 부담합니다. -오프체인 및/또는 사용자 오프체인 보상.

그러나 릴레이 기반 아키텍처에는 세 가지 주요 단점이 있습니다. (1) 중앙 집중식 중개자로 간주되어 잠재적으로 거래를 검열할 수 있습니다. (2) 릴레이로 인한 거래에는 추가로 21,000 기본 가스 요금이 필요하며 비즈니스는 가스 요금 외에 수익을 내야 합니다. , 따라서 기술적으로/경제적으로 비효율적입니다(3). 릴레이어 전용 프로토콜을 사용하면 응용 프로그램이 사용자 기반이 더 작은 기본 계층이 아닌 Ethereum 인프라에 의존하게 되고 가용성 보장이 보장되지 않습니다.

Tornado Cash: 관련 동기 부여 애플리케이션은 tornado.cash와 같은 코인 믹서입니다. 여기서 Tornado는 나중에 다른 주소에서 인출할 수 있는 ETH 예금을 수락하는 스마트 계약을 사용하여 주소 간의 온체인 관계를 끊음으로써 거래 프라이버시를 개선합니다. 사용자는 입금할 때 비밀의 해시를 제공해야 하며 나중에 출금할 때 비밀이나 이전 입금 자체를 공개하지 않고 비밀에 대한 지식을 보여주기 위해 zkSnark 증명을 제공해야 합니다. 이것은 예금에서 인출을 분리합니다.

하지만 출금에 문제가 있는데, 새로 생성된 주소에서 출금 트랜잭션을 실행하기 위해서는 사용자가 가스를 지불하기 위해 일정량의 ETH를 가지고 있어야 합니다. 이 ETH(일반적으로 교환)의 출처는 Tornado의 개인 정보를 손상시킬 것입니다. 선호되는 대안은 다시 중계기 네트워크를 사용하는 것이지만 앞서 설명한 단점이 있습니다.

계정 추상화는 이 문제를 해결하여 Tornado 계약이 사용자의 출금 계정 추상화 거래를 수락한 다음 zkSnark를 확인하고 일부 가스 수수료를 공제(이전 입금액에서 공제)한 다음 나머지 입금액을 출금 주소로 전송할 수 있도록 합니다.

보조 제목

EIP-2938에서 제안한 계정 추상화는 계약이 수수료를 지불하고 트랜잭션 실행을 시작하는 최상위 계정이 될 수 있도록 합니다. 이것은 프로토콜 변경, NONCE 및 PAYGAS라는 두 개의 새로운 opcode가 필요한 새로운 계정 추상화 트랜잭션 유형, mempool 규칙 변경 및 고급 사용을 지원하는 확장을 도입함으로써 달성되었습니다. 여전히 두 가지 유형의 계정 유형(EOA 및 계약 계정)이 있으며 제안된 모든 변경 사항은 현재 트랜잭션, 스마트 계약 및 프로토콜과 역호환됩니다.

계정 추상화의 적용은 두 가지 고려 사항으로 나뉩니다. 1) 스마트 계약 지갑과 같은 단일 테넌트 애플리케이션은 각 사용자에 대한 새 계약을 생성합니다. 2) tornado.cash 또는 Uniswap과 같은 다중 테넌트 애플리케이션, 다중 사용자 및 동일한 세트 스마트 계약 상호 작용.

다중 테넌트 애플리케이션에 대한 계정 추상화 지원에는 더 많은 연구가 필요하며 향후 작업으로 제안됩니다. 따라서 이 기사에서는 단일 테넌트 계정 추상화 지원에 중점을 둘 것입니다.

보조 제목

프로토콜 변경

NONCE 및 PAYGAS를 지원하는 두 개의 opcode와 함께 새로운 트랜잭션 유형이 도입되었습니다. 이것이 유일한 프로토콜 변경 사항입니다.

계정 추상 트랜잭션: 새로운 계정 추상 트랜잭션 유형 AA_TX_TYPE이 도입되었습니다. 유효한 유형은 기존 트랜잭션 유형이 아닌 RLP([nonce, target, data])로 해석됩니다. 후자의 유효한 유형은 RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]) 입니다.

계정 추상화 트랜잭션에서 생략된 gas_price 및 gas_limit는 실행 중에 대상 계정 추상화 계약에 의해 지정됩니다. 계정 추상화 트랜잭션에서 생략된 ECDSA 서명 v, r, s는 특정 계약에 의한 데이터에 대한 검증 확인으로 대체됩니다. to 주소는 대상 계약 주소로 대체됩니다. 이 값이 생략된 이유는 모든 계정 추상 트랜잭션의 시작 주소가 연관된 EOA 값이 아니라 특수한 ENTRY_POINT 주소(0xFFFF...FFF)이기 때문입니다.

확인에 실패하면 트랜잭션이 유효하지 않은 것으로 간주되고, 그렇지 않으면 tx.target.nonce가 증가하고 트랜잭션이 진행됩니다.

계정 추상화 트랜잭션의 기본 가스 비용은 현재 21,000 대신 15,000으로 제안됩니다(고유 ECDSA 서명 부족으로 인한 비용 절감 반영). 또한 계정 추상 거래에는 본질적인 가스 한도가 없습니다. 실행 시작 시 가스 한도를 그룹의 나머지 가스로 설정하기만 하면 됩니다.

NONCE opcode: NONCE opcode(0x48)는 호출 수신자의 NONCE(즉, 계정 추상화 대상 계약)를 EVM 스택으로 푸시합니다. 따라서 Nonce는 EVM에 노출되어 계정 추상화 계약에서 검증의 일부로 모든 트랜잭션 필드(nonce 포함)의 서명 검증을 허용합니다.

PAYGAS opcode: PAYGAS opcode(0x49)는 스택에서 두 개의 매개변수를 가져옵니다. 현재 이 opcode의 의미 체계는 다음과 같습니다.

version_number == 0 확인(그렇지 않으면 예외 발생)

추출 gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])

추출 gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])

contract.balance >= gas_price * gas_limit 확인(그렇지 않으면 예외 발생)

globals.transaction_fee_paid == False 확인(그렇지 않으면 예외 발생)

AA 실행 프레임 == 상단 프레임을 확인하십시오. 즉, 현재 EVM 실행이 종료되거나 복원되면 전체 트랜잭션의 EVM 실행이 종료됩니다(그렇지 않으면 예외가 발생함).

contract.balance -= gas_price * gas_limit(limit)를 설정합니다.

globals.transaction_fee_paid = True로 설정

globals.gas_price = gas_price 및 globals.gas_limit = gas_limit를 설정합니다.

계정 추상화 트랜잭션의 실행이 끝나면 (globals.gas_limit - 잔여_가스)*globals.gas_price가 채굴자에게 전송되고 계정 추상화 계약은 잔여_가스 * globals.gas_price를 반환합니다.

PAYGAS는 EVM으로 체크포인트를 수행합니다. 이 시점 이후의 되돌리기는 여기에서만 되돌려지며 계약은 환불을 허용하지 않으며 globals.gas_limit * globals.gas_price가 채굴자에게 전송됩니다.

"Mempool "새로운 트랜잭션 유형과 두 개의 새로운 opcode는 프로토콜/합의 수준 변경을 구성하며 의미 체계는 상대적으로 이해하기 쉽습니다."보조 제목"멤풀 규칙"마이닝 전에 후보 트랜잭션을 저장하는 이더리움 노드 내부의 메모리 내 데이터 구조 집합을 나타냅니다. 게스가 부른다"트랜잭션 풀"; 패리티는 그것을 부른다"트랜잭션 대기열"

. 이름에 관계없이 블록에 포함되기를 기다리는 메모리에 있는 트랜잭션 풀입니다. 로 생각

대기 장소

현재 고정된 트랜잭션 유효성 규칙을 통해 채굴자와 기타 노드는 최소한의 노력으로 멤풀에서 트랜잭션을 확인할 수 있으므로 DoS 공격을 피할 수 있습니다. 예를 들어 채굴자가 유효한 ECDSA 서명, 유효한 nonce 및 충분한 계정 잔액을 가지고 있다면 거래가 실제로 수수료를 지불할 것이라고 확신할 수 있습니다. 광부의 mempool에 있는 다른 트랜잭션은 동일한 주소에서 발생하고 nonce를 늘리거나 계정 잔액을 충분히 줄이는 경우에만 이 보류 중인 트랜잭션을 무효화할 수 있습니다. 이러한 조건은 채굴자와 노드가 각각 블록 대기 또는 재생을 수행하기 위해 mempool에서 충분한 신뢰를 가질 수 있도록 계산적으로 최소입니다.

Opcode Restriction

계정 추상화 트랜잭션은 프로그래밍 가능한 효율성으로 인해 추가적인 복잡성을 야기합니다. 계정 추상화 트랜잭션은 선불 가스를 지불하지 않으며 대상 계정 추상화 계약에 따라 가스 비용을 지불합니다(PAYGAS를 통해). 개념적으로 계정 추상화 트랜잭션 처리는 짧은 확인 단계(PAYGAS 이전)와 긴 실행 단계(PAYGAS 이후)의 두 단계로 나뉩니다. 확인 단계가 실패하거나 예외가 발생하면 트랜잭션은 유효하지 않으며(오늘날 서명이 유효하지 않은 비계정 추상화 트랜잭션과 같이) 블록에 포함되지 않으며 채굴자는 수수료를 받지 않습니다.

보조 제목

계정 추상화 트랜잭션의 유효성이 계정 추상화 계약 자체 이외의 요인에 의존하지 않도록 하기 위해 다음 opcode는 확인 단계(예: PAYGAS 전: BEFORE PAYGAS) 동안 유효하지 않은 것으로 간주됩니다. 환경 opcode(BLOCKHASH, COINBASE, TIMESTAMP) , NUMBER, DIFFICULTY, GASLIMIT), BALANCE(대상 자체를 포함한 모든 계정), 대상 이외의 항목에 대한 외부 호출/생성 또는 사전 컴파일(CALL, CALLCODE, STATICCALL, CREATE, CREATE2) 및 코드 읽기에 대한 외부 상태 액세스( 주소가 대상이 아닌 경우 EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL).

노드는 mempool에서 계정 추상화 계약을 대상으로 하는 계정 추상화 트랜잭션을 포기하고 이 opcode 제한 규칙을 깨야 합니다. 이렇게 하면 계정 추상화 계약 상태가 변경되지 않는 한 mempool의 유효한 계정 추상화 트랜잭션이 유효하게 유지됩니다.

보조 제목

바이트코드 접두사 제한

노드는 바이트코드 진입점에 이 AA_PREFIX가 없는 계정 추상화 계약에 계정 추상화 트랜잭션을 던져야 합니다.

함께 계정 추상화 계약에 부과된 이 두 가지 제한 사항은 (1) 계정 추상화 트랜잭션의 유효성 논리에 액세스할 수 있는 유일한 상태가 계정 추상화 계약 내부의 상태이고 (2) 이 상태는 다른 사람에 의해서만 액세스될 수 있음을 보장합니다. 계정 추상화 계약의 계정 추상화 트랜잭션 수정.

따라서 미결 계정 추상화 트랜잭션은 동일한 계정 추상화 계약에 대해 보류 중인 다른 트랜잭션이 있는 경우에만 무효화됩니다. 그러나 이것이 프로토콜/합의 변경이 아니라는 점을 감안할 때 채굴자는 이러한 규칙을 위반하는 트랜잭션을 블록에 자유롭게 포함할 수 있습니다.

보조 제목

확장하다

앞서 언급한 프로토콜 변경 및 멤풀 규칙을 통해 기본 계정 추상화 계약이 스마트 계약 지갑과 같은 단일 테넌트 애플리케이션을 완전하고 안전하게 구현할 수 있습니다. 위의 규칙을 완화해야 하거나 다중 테넌트 애플리케이션을 구현해야 하는 다른 고급 사용에는 확장의 형태로 더 많은 지원을 제공하기 위해 계정 추상화가 필요합니다.

IS_STATIC opcode는 현재 컨텍스트가 정적이면 true를 반환하여 비계정 추상화 트랜잭션 호출자가 이전 바이트코드 접두사 제한을 재정의하여 계정 추상화 계약에서 값을 안전하게 읽을 수 있도록 합니다.

RESERVE_GAS opcode는 비계정 추상화 트랜잭션에서 호출될 때 계약 상태에 쓰기를 시도하는 계정 추상화 계약에서 소비하는 가스에 대한 하한을 설정합니다. 이것이 하는 일은 공격자가 mempool의 계정 추상 트랜잭션을 무효화하려는 시도를 억제하기 위해 최소량의 가스를 소비하지 않도록 하는 것입니다.

Tornado Cash와 같은 다중 테넌트 애플리케이션 및 zk 증명을 지원하는 데 필요한 여러 개의 보류 중인 트랜잭션, 유효성 검사를 위한 캐시된 결과, 유효성 검사를 위한 동적 가스 한도 및 스폰서 트랜잭션과 같은 다른 것들이 있습니다. 이에 대한 자세한 내용은 이 문서의 범위를 벗어납니다.

보조 제목

작업의 다음 단계

계정 추상화 EIP-2938은 현재 초안 모드에 있으며 Ethereum Research Forum에서 논의되고 있습니다. EIP의 다음 단계는 다가오는 하드포크 중 하나에 포함하는 것을 고려하는 것입니다. EIP 저자의 목표는 분명히 베를린(베를린은 2021년 초로 잠정적으로 예정되어 있음) 이후의 하드포크이며 그 일정은 현재 불분명합니다. 따라서 EIP-2938에는 너무 이릅니다.

상태: Status 지갑은 현재 EOA 지갑으로 개인 정보 보호에 중점을 둔 SMS 시스템을 번들로 제공하고 채팅 결제 또는 Keycard의 보안 강화와 같은 통합을 가능하게 함으로써 차별화됩니다. 다중 서명 및 소셜 복구와 같은 스마트 계약 지갑 기능이 고려되고 있으며 계정 추상화 EIP-2938에 대한 지원은 앞에서 설명한 것처럼 중앙 집중식 및 비효율적인 릴레이 기반 아키텍처에 대한 의존성을 제거하는 데 도움이 될 것입니다.

요약하다

Status는 또한 지갑에서 다중 체인을 지원하고 이전 게시물에서 다룬 것처럼 다양한 사용 사례에 필요한 확장성을 제공하기 위해 L2 솔루션을 평가하고 있습니다. 예를 들어, Keycard는 신용 카드 수준의 확장성과 거의 즉각적인 완결성에 대한 설계 요구 사항이 현재 Ethereum 네트워크에서 충족되지 않는 결제 네트워크를 탐색하고 있습니다. 또한 추천 프로그램, Tribute-to-Talk 및 ENS 이름과 같은 다른 많은 프로그램이 있으며 모두 실행 가능한 배포 및 합리적인 사용자 경험을 위해 L2 확장성의 이점을 얻을 수 있습니다. 실행 가능한 L2 솔루션이 계정 추상화를 구현하는 경우 해당 L2에 구축된 프로젝트는 L1에 의존하지 않고도 계정 추상화를 활용할 수 있습니다.

보조 제목

요약하다

이더리움 프로토콜의 근본적인 측면은 외부 소유 계정(EOA)만이 가스 요금을 지불하고 트랜잭션 실행을 시작할 수 있다는 것입니다. 계약 계정(CA)에서는 이 작업을 수행할 수 없습니다. AA(계정 추상화)는 이러한 구분을 변경하기 위한 제안으로, 특수 제작된 CA가 프로그래밍 방식으로 새 계정 추상화 거래의 유효성을 확인하고 대신 가스 요금을 지불하기로 결정하여 EOA 없이도 효과적으로 실행을 시작할 수 있습니다. .