UX관점에서 살펴보는 ERC-4337 Use case for Web3 Game

user-image
+1
백용기(Grint)외 1명
junior Researcher /
Decipher
2023.05.26

[Xangle Digest]

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

 

목차

이더리움 계정이란?
Account Abstraction(계정 추상화)는 무엇인가
Account Abstraction 역사
ERC-4337 use case
User experience(UX)?
Blockchain service UX Framework
Blockchain UX problem

 

 

 

 

 

Introduction

3월 1일 이더리움 블록체인 개발자 컨퍼런스인 ETH Denver 현장에서 16년부터 논의되었던 ERC-4337 Account Abstraction를 EVM 계열 메인넷에 배포했다는 발표를 했습니다. (자세한 관련 어나운스는 OpenZeppelin Blog 를 통해 확인하실 수 있습니다) Account Abstraction는 이더리움의 진입장벽 중 하나인 UX개선에 앞장서게 되었습니다. ERC-4337 기반의 Account Abstraction의 개념이 Game에 도입된다는 가정 하에 여러 USE CASE를 제안하며 학술적인 Blockchain Service UX Framework 관점에서 살펴보았습니다.

 

이더리움 계정이란?

계정 추상화를 이해하기 위해서는 이더리움의 account에 대한 이해가 필요합니다. 이더리움의 State는 account로 불리는 객체들로 구성되어 있으며, 각 계정은 20byte 길이의 주소(address)와 1:1로 매칭되어있습니다. 이러한 account는 각기 다른 역할을 하는 2가지 유형으로 존재합니다.

이더리움 계정의 종류
출처: Ethereum EVM illustrated

 

먼저 EOA(Externally owned account)는 사용자가 직접 계정을 제어할 수 있도록 개인 키(Private key)를 보유한 account(예. 메타마스크)를 의미합니다. EOA는 개인 키를 가지고 있기 때문에 트랜잭션을 생성하고 서명할 수 있습니다. EOA state는 nonce(성공적으로 전송한 트랜잭션 수), balance(ETH 잔액)로 구성되어 있습니다.

그 다음으로 CA(Contract account)는 스마트 컨트랙트를 배포했을 때 생성되는 account이며, 네트워크에 배포된 컨트랙트 코드에 의해 통제되는 account를 의미합니다. CA는 코드와 스토리지를 가지고 있어 특정 시점에 코드를 실행할 수 있습니다. CA state는 nonce(해당 컨트랙트가 생성한 컨트랙트 수), balance, code hash(스마트 컨트랙트 코드 해시 값), storage hash(상태 데이터 스토리지 해시 값)로 구성되어 있습니다.

 

EOA, CA의 작동원리
출처: Ethereum EVM illustrated

이러한 이더리움 account모델은 다음과 같은 특징과 한계점을 갖고 있습니다. 먼저 EOA의 경우, 자체적으로 개인 키를 통해 서명하여 검증(verification)이 가능합니다. 그리고 검증 후 트랜잭션 실행을 위해 사용자가 Gas fee를 지불해야 실행(execution)이 가능하기 때문에 EOA에서 트랜잭션(예, EOA간 송금 or CA 코드 실행 등)을 생성할 수 있습니다. 즉, 트랜잭션을 개인 키로 서명하여 검증해야 실행이 가능하기 때문에, 개인 키의 존재가 굉장히 중요합니다. 하지만 만약 사용자가 개인 키를 분실했을 경우, 사용자가 자신의 EOA에 액세스할 수 있는 방법이 없기 때문에 어렵고 불편한 사용자 경험을 제공합니다. 또한 EOA는 ECDSA방식으로만 서명을 생성할 수 있기 때문에 다양한 지갑 설계에 있어 한계점이 존재합니다.

반면 CA의 경우, 자체적으로 트랜잭션을 검증 및 실행할 수 없기 때문에 EOA로부터 트랜잭션을 실행하라는 응답에 대해서만 트랜잭션을 실행할 수 있습니다. 즉, CA는 개인 키가 없어 자체적으로 검증 및 트랜잭션 실행이 불가능하기 때문에 컨트랙트 기능 구현에 제약이 존재합니다.

 

Account Abstraction(계정 추상화)는 무엇인가

이더리움에서는 Account Abstraction를 통해 사용자의 account가 개인 키가 없는 상태로 트랜잭션을 검증 및 실행할 수 있도록 2017년 부터 꾸준히 EIP를 제안했습니다. Account Abstraction는 하나의 account가 EOA와 CA의 역할을 둘 다 할 수 있도록 추상화하는 개념을 의미합니다. 즉, 개인 키가 없어도 CA와 같은 account가 자체적으로 검증 가능하도록 하는 개념입니다.

컴퓨터 공학에서 abstraction(추상화)이란 복잡한 내부적인 작동 과정을 숨기고, 핵심적인 기능만 간추리는 과정을 의미합니다. 예를 들어, 우리가 메타마스크로 트랜잭션을 실행한다고 할 때, 내부적으로는 트랜잭션 데이터를 생성하고, 생성된 트랜잭션 데이터에 private key로 서명하고 이를 블록체인에 전파하는 복잡한 과정을 거칩니다. 그러나 메타마스크는 ‘전송’ 이라는 하나의 기능으로 위 복잡한 과정을 숨기고 핵심적인 기능만을 제공합니다. 이러한 과정을 추상화라 일컫습니다. (출처: decipher media)

 

Account Abstraction 역사

Account Abstraction구현이 EIP에서 어떤 형태로 제안되어 왔는지, 그리고 최근 배포된 ERC-4337까지 순서대로 살펴보겠습니다.

1. EIP-86 Abstraction origin and signature (2017)

2017년 비탈릭 부테린이 프로토콜에 검증 로직 내장되어 있기에 다른 추가적인 검증 로직을 적용할 수 없는 문제점을 EIP-86을 통해 제기하였습니다. 문제점을 이해하기 위해서는 구조에 대해서 이해가 조금 필요합니다. 먼저 EOA에서 시작되는 트랜잭션의 검증은 이더리움 프로토콜에서 발생합니다. 따라서 프로토콜이 아닌 EVM에서 트랜잭션이 검증 가능하도록 함으로서 Account Abstration을 구현할 수 있습니다.

  • 검증 = 서명(개인 키 + 메시지) + 공개 키 + 메시지
  • EVM 맥락에서 메시지 = 트랜잭션

EIP-86 Abstraction origin and signature

출처: Decipher media

해당 EIP를 기점으로 이더리움 커뮤니티 내 Account Abstraction의 필요성을 인지하였고, 그 결과 다양한 EIP 논의 및 제안이 이뤄졌습니다.

2. EIP-2938 Account Abstraction (2020)

다양한 논의 중 대표적으로 EIP-2398이 있으며, EIP-2398은 CA가 Gas fee를 지불하고 트랜잭션을 실행할 수 있는 EOA와 같은 최상위 계정이 될 수 있도록 프로토콜을 변경하자는 제안입니다. 구체적으로는 CA가 자체적으로 트랜잭션을 검증할 수 있고, Gas fee를 지불 가능하도록 EVM OPCODE(PAYGAS, NONCE) 추가를 제안했으며, 기존 트랜잭션 타입에 더해 AATransaction(Account Abstraction Transaction)를 제안하였습니다. 하지만 해당 제안은 이더리움의 컨센서스 레벨에서 변경이 필요한 제안이기 때문에 프로토콜 업그레이드 혹은 하드포크 작업 필요하며, 동시에 Ethereum 2.0을 개발하고 있는 상황에서 적용되기 어려운 제안이기 때문에 적용되지 못했습니다.

3. EIP-3074 AUTH and AUTHCALL opcodes (2020)

EIP-2938 직후에 제안된 EIP-3074은 기존까지 제안된 Account Abstraction개념과는 정반대 접근 방식으로 제안되었습니다. OPCODE(AUTH, AUTHCALL) 추가를 통해 EOA에 대한 제어권을 CA에 위임함으로써, CA가 마치 EOA인 것 처럼 트랜잭션을 보내는 것을 제안하였습니다.

ERC-4337: Account Abstraction Using Alt Mempool

그리고 2021년 비탈릭 부테린은 ERC-4337을 제안하였고, 2023년 EVM 계열 메인넷에 배포되었습니다. ERC-4337에서는 컨센서스 레이어를 수정할 필요 없이 트랜잭션 mempool의 기능을 복제하여 Account Abstraction을 구현할 수 있는 제안입니다. ERC-4337은 EIP-2938과 동일한 작업을 시도하지만 온체인과 오프체인을 동시에 활용하며, 트랜잭션이 아닌 UserOperation을 사용하여 Account Abstraction을 구현합니다. 아래 그림은 ERC-4337의 과정으로, UserOperation creation → Bundler processing → Entry point contract [UserOperation 검증 → Paymasters(옵션) → UserOperation 실행] 순으로 이뤄집니다.