[Xangle Digest]

※해당 컨텐츠는 8월 9일 외부에서 기발간 된 컨텐츠입니다. 컨텐츠에 대한 추가적인 주의사항은 본문 하단에서 확인해주세요.

목차
계정 추상화 배경
계정 추상화는 어떻게 하면 가능할까?
ERC-4337 계정 추상화는 어떻게 동작할까?
EOA 계정과 Smart Contract
Problem1 : Smart Contract can’t generate Transaction.
Problem 2: Contract Deploy
맺으며 

본 글은 CURG에서 기획한 계정 추상화(Account Abstraction) 시리즈 첫 번째로, 계정 추상화 기술의 동기와 현재 표준이 된 ERC-4337에 대해 개괄적으로 다루고, 이에 대한 구현 방식과 기술적 세부 내용을 살펴본다. 다음 편에서는 가스비 대납 솔루션 Paymaster와 가스비 최적화를 위한 Aggregator를 살펴보고, 실제 계정 추상화를 구현한 프로젝트를 리뷰할 예정이다. 

계정 추상화 배경

이더리움은 상태 전이 시스템(State Transition System)이며, 상태 전이 요청은 계정을 중심으로 이루어진다. 계정의 분실은 상태 전이 요청(트랜잭션)을 할 수 없게 되며, 계정 정보(Mnemonic or Private Key)의 보관은 이더리움 환경에서 매우 중요하다. Vitalik은 자신의 블로그에 2019년 소셜 복구 기능을 제공하는 지갑 테스트에 관한 경험과 그에 대한 교훈을 작성하였다. 교훈은 다음과 같다. “비밀 공유 기반 오프체인 소셜 복구는 매우 취약하며, 복구를 위한 별도의 앱은 분실이 쉽고, 별도의 중앙 집중식 커뮤니케이션 채널은 여러 종류의 문제가 발생할 수 있다. 대신 guardians를 추가하는 방식은 이더리움 주소를 제공해야 하고, ERC-4337 계정 추상화 지갑을 사용하는 스마트 컨트랙트에 의하여 복구가 되어야 한다. guardians는 이더리움 지갑을 잃어버리지 않으면 되는데, 이는 이미 다른 이유로 신경 쓰고 있는 부분이다.”

계정 추상화 지갑 사용은 계정 복구와 같은 UX(User Experience)의 변화를 가능하여지도록 한다. 블록체인 사용에 있어서 여전히 많은 불편함이 존재하고, 이는 사용자들이 블록체인 기술을 사용하면서 쉽게 적응하지 못하도록 하고 있다. 계정 추상화는 무엇이며, 어떤 사용 사례가 이 아이디어의 동기가 되었을까? 다음은 계정 추상화 아이디어의 동기가 된 UseCase들이다.

1. Multisig
2. Cryptography other than ECDSA
3. Privacy solutions
4. On-chain DEXes

Multisig

출처: Coindesk.com (작성: Colin Harper)

Multisig(다중 서명) 지갑이나 Smart Contract 지갑(예, 소셜 복구)들은 거래 수수료를 지불하기 위해 소량의 이더리움을 저장하는 별도의 계정(EOA)이 필요하며, 시간이 지남에 따라 해당 계정이 이더리움을 재충전해야 하는 불편한 구조로 되어 있다. 다른 계정에 의하여 거래 수수료를 대납 될 수 있다면, 별도의 계정에 이더리움을 재충전해야 하는 불편함을 개선할 수 있다.

Cryptography other than ECDSA

출처: Medium @Level Up Coding- ECDSA — How to programmatically sign a transaction

이더리움에서는 전자서명에 ECDSA를 사용하며, 이외의 암호화 알고리즘을 사용하기 어렵다. ECDSA 이외의 암호화, Schnorr 서명, BLS 서명, 기타 곡선 및 Lamport/Winternitz와 같은 양자 증명 알고리즘을 모두 구현할 필요가 있을 수 있다.

Privacy Solutions

프라이버시 솔루션은 증명 검증이 인증 로직으로 이동하고 수수료 지급 조건이 되기 때문에 더 이상 “릴레이어(Relayer)”를 필요로 하지 않을 것이다.

On-chain DEXes

온체인 탈중앙 거래소 및 유사 시스템에서는 많은 사용자가 동일한 차익거래 기회를 얻기 위해 여러 트랜잭션을 시도하는 경우가 많다. 현재는 실패한 트랜잭션이 체인에 게시되기 때문에 비효율적이지만, 추상화를 사용하면 이론적으로 실패한 트랜잭션이 체인에 전혀 포함되지 않도록 할 수 있어 가스 효율성을 개선할 수 있다.

계정 추상화는 어떻게 하면 가능할까?

계정 추상화를 설명하는 가장 쉬운 방법은 기술의 접근 체계를 살펴보고 각 체계의 결함이 어디에 있는지 이해하는 것이다. 계정 추상화를 위한 기술의 발전 역사를 살펴보자.

Scheme 1 : Naive total abstraction

사용자는 일반적인 메커니즘을 사용해 가스비를 지불하지 않고도 ENTRY_POINT라고 하는 새로운 특수 주소(예: 2**160–1로 설정)에서 모든 계정으로 트랜잭션을 전송할 수 있다. 시사점은 이러한 트랜잭션의 “target”은 발신자의 계정이며, 계정 코드는 해당 데이터로 트랜잭션을 처리하고 원하는 작업을 수행한다는 의미이다.

채굴자는 거래를 완전히 처리하기 전에 계정 잔액을 확인하고, 거래를 완전히 처리한 후 계정 잔액을 확인하며, 차액이 충분한 수수료인지 확인하는 등 간단한 필터를 사용해 수락할 트랜잭션을 결정한다. 사용자는 요구되는 어떤 인증 단계를 거친 후, 수수료 지급을 위해 트랜잭션에 send(Coinbase(), fee)를 포함하기만 하면 된다.

이 접근 방식은 간단하고 최대한 유연하지만 두 가지 큰 문제가 있다.

• 마이너가 트랜잭션을 수락해야 하는지 여부를 알기 전에 모든 트랜잭션을 완전히 실행해야 한다는 것이다. DAO 소프트포크 시도에서 보았듯이, 이는 높은 수준의 DoS 취약성을 초래하는 나쁜 아이디어이다.
• 네트워크의 노드들은 트랜잭션을 전파할지 여부를 판단하는데 더 큰 어려움을 겪게 되는데, 트랜잭션을 실행하여 채굴자에게 보상을 지급할 것 같더라도 하나의 트랜잭션이 다른 모든 트랜잭션의 수수료 지급 속성을 무효로 할 수 있기 때문이다. 따라서 네트워크 수준의 DoS 위험은 훨씬 더 크다.

Scheme 2 : Signature abstraction only

“지갑 계정”이라고 하는 세 번째 계정 타입을 생성한다. 지갑 계정은 컨트랙트와 비슷하지만 두 가지 코드가 있는데: (i) 인증 코드와 (ii) 실행 코드다. ENTRY_POINT에서 지갑 계정으로 호출하는 과정은 두 단계로 이루어진다: (i) 전체 트랜잭션을 입력으로 사용하여 검증 코드를 실행하고 출력이 0이 아닌지 확인한 다음 (ii) 실행 코드를 정상적으로 실행한다. 검증 코드 실행은 외부 호출(사전 컴파일 제외), 컨트랙트 저장소 또는 어떤 것에 ‘쓰기’ 기능을 사용할 수 없으며, pure 함수여야 한다. 또한 검증 코드 실행에는 400,000의 고정 가스 제한이 있다.

이 방식은 마이너와 네트워크 노드가 해야 하는 모든 것이 이전과 동일하므로 기본적으로 보안 위험이 없다. 유일한 차이점은 마이너가 ECDSA 검증(순수 함수) 대신 제한된 환경 내에서 일부 EVM 코드(또 다른 순수 함수)를 실행해야 한다는 것이다. 그러나 이 방식은 추상화의 이점 중 일부만 제공한다.

Scheme 3 : 제안된 체계(EIP-2938)

출처: ethereum-magicians.org

다음은 대부분의 위험 없이 완전한 추상화의 많은 이점을 제공하는 구체적인 계획이다. 첫째, EVM 레벨이 변경된다:

• 우리는 두 가지 유형의 계정, 즉 EOA와 컨트랙트 계정(CA)이 있다는 속성을 유지하며, 후자는 하나의 코드만 가지고 있다.
• 서명이 (0, 0)인 트랜잭션은 tx.origin(따라서 top-level sender)이 ENTRY_POINT 주소(= 2**160–1)인 트랜잭션으로 취급된다.
• PAYGAS라는 opcode 추가. _{(PAYGAS는 스택에서 하나의 인수(gasprice)를 가져오고, 잔액에서 tx.startgas * gasprice를 차감하고, 트랜잭션 실행이 끝날 때 remaining_gas * gasprice를 환불해야 함을 기록하고, 트랜잭션이 실패할 경우 opcode를 호출한 시점으로 revert 하도록 기록).} 최상위 호출 프레임에서 사용되지 않으면 아무것도 하지 않으며_{(예시: msg.sender == ENTRY_POINT)}, opcode가 이미 활성화된 상태에서 사용되면 아무것도 하지 않는다. 성공하면 스택에 1을 푸시하고 실패하면 0을 푸시.

이제 마이너(채굴자)와 네트워크 노드, 정책을 살펴보면:

• 채굴자나 네트워크 노드는 트랜잭션을 수신하면 최상위 컨트랙트의 코드가 require(msg.sender == ENTRY_POINT)로 시작하는지 확인한다(정확한 EVM 바이트 시퀀스 보류 중). 그렇지 않다면 트랜잭션을 거부한다.
• 다음 세 가지 상황 중 하나에 도달할 때까지 코드를 실행한다:
  1. 호출(프리컴파일 제외)이 이루어졌거나 외부 상태 읽기 연산자 코드(BALANCE, EXTCODE*) 또는 환경 연산자 코드(TIMESTAMP, DIFFICULTY, NUMBER, BLOCKHASH, COINBASE, GASLIMIT)가 사용되었다면, 이 경우 트랜잭션이 거부된다.
  
  2. 400,000 가스가 사용되었다면, 이 경우 트랜잭션이 거부된다.
  
  3. PAYGAS opcode가 사용된다면, 이 경우 opcode에 주어진 가스 가격이 충분한지 여부에 따라 거래를 수락하거나 거부한다.
• 마이너와 네트워크 노드는 각 계정에 대해 두 개 이상의 트랜잭션을 중계하지 않는다. 계정 추상화는 부수적으로 하나의 트랜잭션 내에서 여러 작업을 수행할 수 있는 계정을 지원하기 때문에 사용성에 미치는 영향은 낮다.

이 방식은 이더리움의 프로토콜 레벨에서 수정해야 하는 큰 문제를 가지고 있다.

Scheme 4 : 제안된 체계(EIP-4337)

이 방식은 이더리움 프로토콜의 변경 없이 분산 방식으로 네이티브 스마트 계약 지갑을 지원하기 위한 첫 번째 단계이다. 스마트 계약 지갑을 지원하기 위해 합의 레이어를 수정하는 대신, 일반적인 트랜잭션 gossip 프로토콜과 별도로 새로운 시스템이 추가된다. 이 상위 레벨 시스템은 사용자 작업(UserOperation)이라는 새로운 개체를 기반으로 구축되며, 사용자의 작업과 관련된 서명과 함께 패키징된다. 이 UserOperation 개체는 전용 메모리 풀로 브로드캐스트되어 검증자들이 이를 “번들 트랜잭션”으로 수집할 수 있게 된다. 번들 트랜잭션은 많은 개별 UserOperation의 연속을 나타내며, 일반 트랜잭션과 마찬가지로 이더리움 블록에 포함될 수 있으며, 검증자들은 유사한 수수료 최대화 선택 모델을 사용하여 이를 선택한다.

EIP-4337에 따라 지갑의 작동 방식도 변경된다. 각 지갑이 일반적이지만 복잡한 안전성 로직을 재구현하는 대신, 해당 기능은 “Entry Point”이라고 알려진 global 지갑 컨트랙트에 외부로 아웃소싱된다. 이를 통해 수수료 지불 및 EVM 코드 실행과 같은 작업을 처리하여 지갑 개발자가 훌륭한 사용자 경험을 제공하는 데 집중할 수 있게 된다.

참고로, EIP-4337 Entry Point 컨트랙트는 2023년 3월 1일에 Ethereum Mainnet에 배포되었고, 최근까지 지속해서 업데이트 되고 있다.

그외 다른 접근

EIP-2771 : 메타 트랜잭션을 사용한 계정 추상화

EIP-2771는 이더리움 프로토콜을 변경하지 않고도 제삼자가 사용자의 가스 비용을 지불할 수 있는 메타 트랜잭션 개념을 도입한다. 사용자에 의해 서명된 트랜잭션은 Forwarder 계약에 전송된다. 포워더는 트랜잭션이 유효한지 검증한 후 가스 릴레이로 전송하는 신뢰할 수 있는 개체이다. 이는 오프체인에서 이루어지며, 가스를 지불할 필요가 없어진다. 가스 릴레이는 트랜잭션을 수신자 컨트랙트에 전달하고, 이를 실행하기 위해 필요한 가스를 이더리움에 지불한다. 포워더가 수신자에게 알려진 신뢰할 수 있는 개체인 경우에만 트랜잭션이 실행된다. 이 모델은 개발자가 사용자를 위해 가스 비용이 없는 트랜잭션을 구현하기 쉽게 만든다.

EIP-3074 : EOA 업그레이드를 통해 계정 추상화 지원

EIP-3074은 이더리움의 외부 소유 계정을 업데이트하여 스마트 컨트랙트에게 제어 권한을 위임할 수 있도록 하는 것을 목표로 한다. 이는 스마트 컨트랙트 로직이 외부 소유 계정에서 시작된 트랜잭션을 승인할 수 있다는 것을 의미한다. 이를 통해 가스 후원 및 일괄 처리된 트랜잭션과 같은 기능을 구현할 수 있다. 이를 위해 EVM에는 AUTH와 AUTHCALL이라는 두 개의 새로운 OP코드가 추가되어야 한다. EIP-3074를 통해 스마트 계약 지갑의 이점을 계약 없이도 활용할 수 있게 되며, 대신 “인보커(invoker)”라고 하는 특정 유형의 상태를 가지지 않고 신뢰할 수 있는 업그레이드 불가능한 계약이 트랜잭션을 처리한다.

ERC-4337 계정 추상화는 어떻게 동작할까?

출처: notes.ethereum.org -The road to account abstraction

사용자는 기존의 Transaction 대신, UserOperation 객체를 전송하고, 전송된 UserOperation 객체는 Bundler의 mempool에 등록된다. Bundler는 높은 수수료를 지불하는 UserOperation 객체를 우선 선택하여, 이것을 모아 “Bundle Transaction”을 만들고, 이를 이더리움 블록에 넣기 위해 Transaction을 전송한다. 위 그림은 UserOperation 객체가 처리되는 과정을 그림으로 나타낸 것이다.

출처: eips.ethereum.org

Bundler는 Bundle Transaction에 포함된 UserOperation 객체가 실패하는 경우, 가스 낭비가 발생하기 때문에, 사전에 검증할 필요가 있다. Entry point contract는 UserOperation 객체들을 검증하고 실행하는 역할을 하며 Verification 단계와 Execution 단계가 필수로 구현되어 있어야 한다. Verification 단계에서는 UserOperation의 wallet contract가 존재하지 않는 경우 새로 생성하고, wallet contract에서 ValidateUserOp를 호출하여 UserOperation과 필요한 수수료를 전달한다. 그리고 wallet contract에서는 UserOperation의 서명과 작업이 유효하다면 wallet contract는 수수료를 지불해야 한다. Execution 단계는 wallet contract에서 op execution 함수를 호출하여 calldata를 실행하고, 남은 가스비를 환불해 준다. 위 그림은 Bundler의 계정에서 Entry point contract를 통해 UserOperation 객체를 처리하는 과정을 나타낸 그림이다. UserOperation 객체가 처리 완료되면, 사용자가 원하는 요청이 수행된 것이다.

계정 추상화 지갑의 이점

• 다른 사람의 가스를 지불하거나, 다른 사람이 귀하의 가스를 지불
• 이더가 아닌 ERC-20 토큰으로 수수료 지불
• 자신만의 유연한 보안 규칙 정의
• 키를 분실한 경우 계정 복구
• 신뢰할 수 있는 장치 또는 개인 간에 계정 보안 공유
• 배치 트랜잭션(예: 한 번에 스왑 승인 및 실행)
• dapp 및 지갑 개발자가 사용자 경험을 혁신할 수 있는 더 많은 기회

ERC-4337기반의 계정 추상화 지갑의 이점은 블록체인 UX의 많은 변화를 가져올 수 있을 것으로 기대된다. 다른 사람이 대신 가스비를 지불 해주거나, 내가 가진 ERC-20토큰으로 수수료를 지불 할 수 있다면, 가스비가 부족하여 이더를 구매하고 지갑에 옮기는 불편함이 없어질 것이다. 계정을 복구 할 수 있으면, 계정 분실에 대한 걱정을 덜어줄 수 있으며 블록체인 사용이 더 증가 할 수 있다. 배치 트랜잭션으로 여러 요청을 한번에 처리 할 수 있는 것 역시 가스비 감소와 사용 편의성이 커지는 장점이 있다. 하지만, 물론 장점만 있는 것은 아니다. 트랜잭션 처리에 있어서 기존에 사용하는 방식대비 UserOperation을 통해 처리하는 것에는 가스비가 증가하는 문제가 있고, 여전히 더 발전해나가야 하는 부분이 있다. 

EOA 계정과 Smart Contract

현재 우리가 메타마스크에서 사용하는 계정은 EOA 계정이다. 즉, 패스워드같이 작동하는 개인 키를 사용하여 Transaction에 대해 서명하는 방식이다. 반면 Smart Contract는 Code로 동작하는 계정이다. 계정 내부에 Code를 가지고 있으며 Smart Contract를 사용하기 위해서는 먼저 Transaction을 통한 배포과정(Contract Creation)이 필요하고 이후 EOA 계정에서 해당 Smart Contract로 Transaction을 전송하여 Code를 실행시킬 수 있다. 즉, 정리하자면 다음과 같이 요약할 수 있다.

1. Smart Contract는 Transaction을 만들 수 없다.
2. Smart Contract는 배포 과정이 필요하다.

Problem1 : Smart Contract can’t generate Transaction.

출처: steemit @yahweh87

위 그림은 이더리움의 3가지 Transaction을 나타낸 것이다.

첫 번째는 EOA에서 EOA로 보내는 Transaction. 직관적으로는 ETH를 송금하는 과정이다.

두 번째는 EOA에서 CA(Contract Account : Smart Contract를 계정으로 사용할 때의 용어)로 Transaction을 전송해 Code를 실행시키는 것이다. 예를 들면 우리가 Uniswap을 통해 Swap을 실행시키는 경우이다.

세 번째는 EOA에서 CA로 Transaction을 Code를 실행시켰는데 Code가 Internal Transaction을 생성하여 다른 CA의 Code를 실행시켜 주는 상황이다.

해당 그림을 통해 모든 Transaction의 첫 발생 주체는 EOA 이며, 이후 Internal Transaction의 형태로 CA가 CA로 Transaction을 생성할 수 있다는 것을 알 수 있다. 따라서 CA가 자체적으로 Tx을 생성할 수 없으므로, CA 의 코드를 실행시키기 위해서는 EOA 계정이 Tx을 생성해줘야 한다. ERC-4337에서는 이 문제를 해결하기 위해 UserOp와 Bundler의 개념을 추가한다.

Module : UserOp & Bundler

출처: steemit @yahweh87

위 그림에서 3번째 Transaction을 아이디어로 가져왔다. 이제 Transaction을 생성하기 전에 상위 Level의 요청이 추가되었다. 새로운 방식에서는 Bundler 라는 Transaction을 생성시켜주는 새로운 주체를 설정한다. 이 주체는 요청이 들어오면 User’s CA로 Transaction을 발생시켜주는 역할을 하고 해당 요청을 UserOp라고 부른다.

정리하자면,

• UserOp : CA을 사용하는 User가 Bundler에게 Tx의 실행을 요청하는 요청 단위
• Bundler : CA을 대신해서 자신의 EOA계정으로 Tx을 실행시켜주는 주체

User는 EOA 계정을 보유하지 않아도 자신의 CA 계정으로 Tx을 생성할 수 있는 효과를 만들 수 있다. 아래는 실제 UserOp의 필드이다.

User의 입장에서는 완벽하지만, Bundler에게는 남은 문제가 존재한다. Bundler의 관점에서는 User가 요청하는 임의의 Contract에게 임의의 데이터를 전송해야 하는 것이다.

생각해보면 그 임의의 Contract 가 USDT 일 수 있고, 임의의 데이터가 approve 함수를 호출할 수 있다. 물론 시뮬레이션을 통해서 어느 정도 그러한 악의적인 UserOp를 거를 수 있지만 Transaction이 실제로 다르게 동작할 수 있으므로 잠재적 위협에서 안전하지 못하다.

Entry Point라는 신뢰 가능한 컨트랙트를 도입해서 이 문제를 해결하고자 한다.

Module : Entry Point

Entry Point는 이러한 문제점을 해결하기 위해서 나온 중앙의 싱글 톤 컨트랙트이다. 해당 Contract의 코드는 오픈소스로 공개되어 있으며 ERC-4337을 제안한 프로젝트 팀에서 배포되었다. [소스 확인]

중앙에 단 하나의 Contract 인 Entry Point를 배포했으므로, 이제 해당 Contract로 UserOp를 전송함으로써 Bundler가 임의의 Contract를 실행시키지 않아도 된다.

출처: Etherscan

간단하게 etherscan.io 에서 Entry Point 를 입력하면 해당 컨트랙트를 확인할 수 있다.

출처: Etherscan

모든 ERC-4337 를 사용한 UserOp는 해당 중앙 Entry Point를 사용하므로 얼마나 ERC-4337이 활성화되어있는지 쉽게 확인할 수도 있다. 들어가서 어떤 Tx이 오가는지 확인해보면 구조를 더 쉽게 이해할 수 있다.

Entry Point가 도입된 이후 동작 과정을 살펴보자.

1. Bundler가 UserOp를 받으면 Tx을 생성하여 CA가 아닌 Entry Point로 UserOp를 전달한다.
2. Entry Point에서 Contract Wallet로 UserOp가 전달된다.
3. Contract Wallet에서 해당 UserOp가 실행된다.

출처: Medium @CURG 원문 

지금까지 ERC-4337의 가장 간단한 형태의 Transaction을 설명했다. 이제 조금 더 들어가서 실제 Gas Fee가 어떠한 흐름으로 이동하는지 살펴보자.

Gas Fee Refund Case1 : Tx Success

Transaction은 반드시 실행한 계정에서 Gas Fee가 지불되게 된다. 이것은 프로토콜에서 정해진 규칙이다. 하지만 여기서는 Bundler가 Transaction을 실행하므로 Gas Fee를 부담해야 한다. 지속할 수 있는 모델을 위해서는 User의 계정으로부터 Bundler가 Gas Fee를 환급받는 절차가 필요하게 된다.

기본적인 아이디어는 UserOp가 담긴 Tx이 처리되면서 Gas Fee를 추적하고, Tx이 끝나기 전에 Bundler에게 사용된 Gas Fee를 환급해주는 것이다.

동작 과정 :

1. 지정한 최대 가스양만큼 Contract Wallet → Entry Point 미리 예치
2. Tx 실행하면서 실제 Gas Fee 추적
3. UserOp가 모두 실행되면 추적된 Gas Fee를 Entry Point → Bundler 송금
4. 남은 가스양은 Entry Point에 남는다.

출처: Medium @CURG 원문 

실제 실행결과는 다음과 같다. txHash : 0x38b322582f1cbbb537bccc86b7c5fd3ed78f04dc600107e3a0a11f6dca7fad85

출처: Etherscan

해당 Transaction에서 UserOp는 0x42… 에게 1000 DTC 를 전송하는 것이다.
사진에서 3가지 Transfer 를 확인할 수 있다.

• 0x659f(Contract Account) → Entry Point
• Entry Point → 0x01a4(Bundler)
• 0x659f(Contract Account) → 0x42A0 (DTC 전송)

0x01a4… 주소는 Transaction이 시작된 주소 즉, Bundler이다.
따라서 1번 2번 Transfer는 Gas Fee가 Entry Point를 갔다가 최종적으로 Bundler에게 환급된 것을 확인할 수 있다. 또한 아래에 Transaction Fee($0.0021)보다 Bundler에게 환급된 Gas Fee(0.0022)가 조금 더 크다는 것을 확인할 수 있다. 즉, Bundler가 Gas Fee + 추가적인 수수료를 더 가져가는 것이다.

해당 추가적인 수수료는 UserOp에서 User가 Bundler에게 얼마만큼 더 줄것인지 정하는 maxPriorityFeePerGas 변수에 의해 정해지게 된다.

이제 Transaction이 실패하는 경우를 살펴보자.

Gas Fee Refund Case2 : Tx Fail

이더리움은 Transaction이 도중에 실패하더라도 Gas Fee가 부과된다. 해당 Gas Fee는 누가 지불하게 될까?

1) Contract Wallet의 주인이 아닌 악의적인 제삼자가 보낸 UserOp

만약 이 경우 Wallet의 주인이 Gas Fee를 지급하게 되면 어떤 일이 발생할까? 아마 악의적인 제삼자가 UserOp를 임의로 만들어서 전송할 수 있으므로 Contract Wallet의 잔액은 제삼자에 의해 0원이 될 수 있다.

따라서 이 경우 Bundler가 Gas Fee를 지급하게 된다. 또한 악의적인 제삼자가 UserOp를 임의로 만들어서 보내더라도 Bundler는 시뮬레이션을 통과한 UserOp만 Transaction으로 만들 수 있으므로 Bundler가 자산을 잃지는 않는다.

2) Contract Wallet의 주인이 보낸 UserOp

해석해보면 Bundler는 Wallet의 주인이 보낸 UserOp를 실행시켰는데 Transaction이 실패한 경우이다. 따라서 Bundler에게는 아무런 잘못이 없으므로 Wallet의 주인이 Gas Fee를 지급해야 한다.

우리는 기본적으로 Transaction이 Revert 될 때 모든 변경 사항이 취소되므로 Transaction의 실행 전 상태로 돌아가는 것으로 알고 있다. 하지만 우리가 알아야 할 것은 Transaction의 Revert 종류는 2가지라는 것이다.

일반적인 Revert의 경우 Tx으로 인한 상태 변경이 모두 취소되지만, 예외적으로 try/catch 사용된 코드 내에서 Revert가 발생하면 해당 try/catch 의 실행만 취소되고 이후 코드가 정상적으로 실행된다. 이것을 사용하면 Revert 되더라도 이후 Gas Fee 환급 코드를 넣어 계속 Transaction을 진행할 수 있다.

• 참고자료 : https://solidity-by-example.org/try-catch/

Bundler는 어떻게 UserOp를 보고 악의적인 제삼자가 보낸 것인지, 주인이 보낸 것인지 확인할 수 있을까? 그것은 검증과 실행을 분리하면서 가능해진다.

1.  UserOp의 Signature 값을 검증하는 과정 : validateOp
2.  UserOp의 Op를 실행하는 과정 : executeOp

이를 둘로 나누고 검증 과정에서 실패했으면 악의적인 제삼자가 보낸 UserOp로 인식하고, 실행 과정에서 실패했으면 주인이 보낸 UserOp로 인식한다.

1. UserOp 전달 : User → Bundler
2. Simulation : Bundler Local
3. Tx 생성 : Bundler → Entry Point
4. ValidateOp : Entry Point → Contract Wallet & Deposit
5. ExecuteOp : Entry Point → Contract Wallet
6. UserOp 실행
7. Gas Fee Refund : Entry Point → Bundler

출처: Medium @CURG 원문 

Extension : Paymaster

지금까지 사용자는 EOA 계정을 사용하면서 반드시 여분의 Gas Fee를 가지고 있어야 했다. 이더리움 프로토콜에서 Gas Fee는 Transaction을 발생시킨 주체가 지급한다고 정했기 때문이다.

하지만 위에서 살펴봤듯이 Contract Account를 사용할 때 Transaction 실행 주체는 Bundler이고 이후 Gas Fee 환급은 컨트랙트 코드로 이뤄진다. 즉 컨트랙트의 코드로 Gas Fee 지급 주체를 지정할 수 있게 되었다.

ERC-4337 에서는 Gas Fee 대납에 대한 표준도 지정하고 있다. Paymaster Contract를 배포하고 해당 Contract에서는 White List 와 같은 방식으로 대납해줄 사용자를 지정하고, 사용자는 UserOp를 생성할 때 Paymaster Contract address에 대한 정보를 담는다. 이후 UserOp가 Bundler에 의해 Transaction이 되고 Paymaster Contract로 가서 대납이 이뤄지게 된다.

Code : Entry Point

• 실제 Bundler는 Entry Point 안에 있는 handleOps를 통해 UserOp를 전달한다.
• 내부에서 _validatePrepayment 통해 validateOp 를 수행하고 수행이 완료된 후_executeUserOp 수행하는 것을 확인할 수 있다.
• _compensate : Gas Fee가 환불된다.

• _executeUserOp 함수 내부에서는 try catch를 통해 Tx이 Revert 되더라도 계속 수행될 수 있다.
• Revert가 발생하여 catch 안으로 들어가더라도 collected 변수에 계속 Gas Fee를 추적하는 것을 확인할 수 있다.

처음으로 돌아와서 우리는 Contract를 EOA처럼 사용하기 위해서 문제를 해결하고 있다. 첫 번째 문제는 Transaction을 생성하는 것이었고, 두 번째 문제는 Contract 배포와 관련된 이슈이다. 이제 두 번째 문제로 넘어가자.

Problem2 : Contract Deploy

우리가 평상시 메타마스크를 통해 사용하는 계정인 EOA는 32bytes 개인 키를 임의로 생성해서 사용하면 된다. 반면 Contract는 배포되기 전에 존재하지 않는다. 어떻게 Contract Account를 바로 사용할 수 있을까?

언제 배포해야 할까?

직관적으로 Contract Wallet을 배포하기 가장 적절한 시기는 첫번째 UserOp가 생성될때이다. 하지만 지갑을 사용하기 전에 입금을 받는 경우는 매우 흔한 경우이므로 미래에 배포될 Contract Wallet의 주소를 알아야 한다.

CREATE2

이더리움은 Create2 라는 Opcode를 제공한다. 해당 Opcode는 이더리움 World State에 무슨일이 발생하든, 미래에 배포될 컨트랙트의 주소를 보장해준다. 따라서 미래에 배포될 주소를 미리 알 수 있다. 주소를 구하는 식은 다음과 같다.

• 0xFF : CREATE Opcode와 구별되는 상수
• sender : 발신자의 주소
• salt : 임의의 상수
• bytecode : 배포할 Contract의 bytecode

어떤 Contract를 배포해야 할까 ?

가장 단순한 아이디어는 User가 배포하고 싶은 Wallet Contract에 대한 bytecode를 UserOp에 넣어서 보내는 것이다. 이 방법은 몇가지 문제점이 존재한다.

1. 배포이므로, 시뮬레이션 결과가 실제 결과와 다를 수 있다. 이 경우 Bundler가 Gas Fee를 잃으므로, 금전적 손실을 입게된다.
2. Wallet Code에 백도어가 심어져 있을 수 있다. 유저가 Wallet Contract의 코드르 보고 악의적인 코드가 심겨져 있는지 알기 힘들다.

Wallet Factory

위 문제가 발생하지 않는 Wallet Contract를 만드는 방법은 Factory Contract를 배포하여 해당 Factory Contract를 통해 Wallet Contract를 배포하는 것이다. 유저는 믿을만한 Factory Contract를 사용하여 배포할 수 있으며, 바이트코드에 대한 이해가 없어도 편하게 사용할 수 있다.

최종적으로 다음과 같이 동작한다.

1. UserOp 전달 : User → Bundler
2. Simulation : Bundler Local
3. Tx 생성 : Bundler → Entry Point
4. 만약 Factory Call : Entry Point → Factory & Wallet Depoly : Factory → 0x0
5. ValidateOp : Entry Point → Contract Wallet & Deposit
6. ExecuteOp : Entry Point → Contract Wallet
7. UserOp 실행
8. Gas Fee Refund : Entry Point → Bundler

Bundling

지금까지 우리는 단 하나의 Entry Point로 Transaction을 전송했다. 또한 EntryPoint로 전송된 Transaction은 유저의 Wallet에 대한 Data가 포함되어 있었다.

즉, 각각의 UserOp에 대해서 Transaction을 만들지 않고, 모든 UserOp를 배열 형태의 데이터로 단 하나의 Transaction에 넣어 전송하면 하나의 Transaction이 여러 개의 UserOp를 처리할 수 있다.

출처: Medium @CURG 원문

구현하는 방법 또한 매우 간단하다.

간단하게 UserOption을 배열로 바꿔서 전달하면 된다. 이제 Bundler는 유저가 보낸 UserOp들을 하나의 번들 형태로 Transaction을 만들어줄 수 있다.

여기서 재밌는 점은 Bundler는 자신이 보낼 Bundle 생성하게 되는데, Bundle안에 UserOp의 순서 또한 임의로 결정하게 된다. 블록을 생성하는 사람이 블록 안에 들어있는 Transaction의 순서를 결정함으로써 수익을 발생시키는 것을 MEV 라고 한다.

Bundling에서 순서 를 마음대로 결정함으로써 수익을 발생시킬 수 있으며 관련된 아티클은 MEV 리서치에서 다뤘으니 관심 있으면 해당 아티클도 읽어보길 추천한다.

다시 본론으로 돌아와서 위에서는 UserOp가 처리될 때 해당 UserOp를 검증하는 ValidateOp가 실행된 후 해당 UserOp를 실행하는 ExecuteOp가 실행되었다. 만약 Bundling이 추가되면 해당 로직은 어떻게 변경될까?

출처: Stackup

다시 언급하자면 ValidateOp에서 검증이 실패하게 되면 Transaction 자체가 모두 취소되고 원상태로 돌아가게 된다. 즉, ValidateOp에서 단 하나의 UserOp가 실패하더라도 해당 Transaction은 취소되고 모든 UserOp가 실패하게 된다. 그러므로 모든 UserOp의 ValideteOp를 먼저 실행하고 모든 검증이 완료된 후 ExecuteOp를 실행하게 된다.

이러한 UserOp들의 ValidateOp들을 모두 실행하는 것을 Validation loop, 이러한 UserOp들의 ExecuteOp들을 모두 실행하는 것을 Execution loop 라 부른다. Bundling을 함으로써 우리는 가스비 절감 효과를 얻을 수 있으며, 이후 Aggregator라는 추가적인 모듈을 도입하면 더더욱 가스비가 저렴해지는 효과를 얻을 수 있다. Aggregator와 관련된 자세한 내용은 [Account Abstraction] 계정 추상화 시리즈- 2편에서 다룰 예정이다. 

맺으며

지금까지 ERC-4337의 개념과 Smart Contract를 개인 계정으로 사용하는 표준이 어떻게 동작하는지 내부 구조에 대해 알아봤다. 해당 표준은 사용자가 가스비에 대한 개념 또는 해당 고민 없이 Tx을 생성하며 사용자 경험을 크게 개선할 수 있다며 주목받게 되었다. 해당 표준이 실제로 사용자의 경험을 향상할 수 있을지는 실제 프로젝트에 적용되어야 알겠지만, 필자는 블록체인 기술을 좀 더 편하게 사용하기 위한 표준이라는 점에서 매우 긍정적인 방향이라고 생각하며 더욱 사용자 경험을 개선할 수 있는 표준이 많이 나오길 기대한다. 

※참고자료 

•  Some personal user experiences
• Ethereum Accounts
•  ERC-4337: Account Abstraction Using Alt Mempool
• EIP-4337 — Ethereum Account Abstraction Audit — OpenZeppelin blog
• EIP-4337 — Ethereum Account Abstraction Incremental Audit — OpenZeppelin blog
• Unified ERC-4337 mempool — HackMD
•  Ethereum Account Abstraction: All you Need to Know | Shardeum
• Implementing account abstraction as part of eth1.x
• https://www.alchemy.com/blog/account-abstraction
• https://eips.ethereum.org/EIPS/eip-4337
• https://ethereum.stackexchange.com/questions/78562/is-it-possible-to-perform-a-try-catch-in-solidity
• https://medium.com/decipher-media/ux관점에서-살펴보는-erc-4337-use-case-for-web3-game-7a4f81c46256
• https://docs.openzeppelin.com/cli/2.8/deploying-with-create2
• https://github.com/eth-infinitism
• https://www.alchemy.com/blog/account-abstraction-wallet-creation

-> ‘[Account Abstraction] 계정 추상화 시리즈- 1편’ 원문 보러가기
_{*[AA Series #1] Account Abstraction : Candidate of Final
*[AA Series #2] Account Abstraction : How to work?}