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

Published in

Decipher Media ｜디사이퍼 미디어

26 min readApr 22, 2023

서울대학교 블록체인 학회 디사이퍼(Decipher)에서 ‘UX관점에서 살펴보는 ERC-4337 Use case for Web3 Game’를 주제로 Weekly Session에서 발표한 내용을 담았습니다. 본 글은 Account Abstraction의 개념 설명과 함께 Web3 Game에 ERC-4337기반의 Account Abstraction이 도입된다는 가정하에 여러 Use case를 UX관점에서 살펴보았습니다.

Author

백용기(@grintkermit), 하서빈(@bina_seo)

Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)

Reviewed By (하성환, 임요한)

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가지 유형으로 존재합니다.

먼저 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(상태 데이터 스토리지 해시 값)로 구성되어 있습니다.

이러한 이더리움 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를 기점으로 이더리움 커뮤니티 내 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 실행] 순으로 이뤄집니다.

출처: UniPass Wallet Compatible With ERC-4337

UserOperation creation

먼저 UserOperation은 User(이하, sender)가 ERC-4337로 활성화된 Application 또는 Wallet과 상호작용할 때, 기존 트랜잭션 대신 생성되는 스마트 컨트랙트로 구현된 object입니다. UserOperation은 트랜잭션이 아니지만, 필드를 살펴보면 트랜잭션이 가지고 있는 필드와 유사합니다. 트랜잭션과 마찬가지로 ABI인코딩 되어있으며 nonce, signature, sender 등 11개의 필드를 가지고 있습니다.

sender: UserOperation을 생성하는 지갑(=User)
nonce, signature: UserOperation을 검증할 수 있도록 전달되는 매개변수
initCode: User의 지갑(계정)이 아직 존재하지 않는 경우, 지갑을 생성할 수 있는 코드
callData: 실제 실행 단계에서 지갑(sender)을 호출할 데이터
나머지 필드는 Gas fee와 관련이 있습니다.

트랜잭션을 검증할 때 signature, nonce, 지불해야할 Gas fee(maxFeePerGas, maxPriorityFeePerGas) 등을 확인합니다. 마찬가지로 UserOperation 역시 signature, nonce, 지불해야할 Gas fee(maxFeePerGas, maxPriorityFeePerGas)를 Entry contract 컨트랙트를 통해 검증하고 코드를 실행합니다. 즉, EOA에서 서명을 통해 트랜잭션을 검증하는 것과 같이. ERC-4337에서는 Entry point를 통해 UserOperation을 검증합니다.

Bundler processing

Bundler processing을 설명하기 전, Bundler란 UserOperation mempool에서 UserOperation 객체들을 모아 Bundle transaction으로 만들고 Entry point 컨트랙트를 호출하여 검증 및 실행하는 EOA 보유 블록 빌더 또는 사용자를 의미합니다.

Bundler processing은 우선 sender로부터 UserOperation이 생성되면 트랜잭션이 mempool에 전송되는 것처럼, UserOperation mempool로 전송 및 등록됩니다. Bundler는 UserOperation mempool 중 Gas fee를 많이 지불하는 UserOperation 객체들을 모아 Bundle transaction로 일괄 패키징합니다. 추후 모든 개별 UserOperation 실행의 일부로 지불된 Gas fee를 통해 보상받습니다. 그리고 Entry point contract를 handleOps로 호출하여 Bundle transaction내 각 UserOperation을 검증 및 실행 후 온체인에 배치합니다. Bundler는 Bundle transaction을 최종적으로 온체인에 배치하기 위해 Gas fee를 지불합니다.

출처: UniPass Wallet Compatible With ERC-4337 참고 및 이해를 돕기위해 편집

Entry point contract

위에서 Bundler가 호출하는 Entry point contract는 Bundle transaction의 UserOperation들을 검증하고 실행하는 역할의 컨트랙트입니다. Entry point contract는 검증을 위해 verification loop와 실행을 위한 execution loop를 필수로 구현해야 합니다. 각 loop에서 Wallet contract를 통해 UserOperation을 검증(validateUserOp) 및 실행(execution)합니다.

먼저 verification loop(②, ③)에서는 validateUserOp 함수 호출을 통해 Bundle transaction내 UserOperation의 signature과 nonce를 검증합니다. sender의 account에 Gas fee를 지불할 수 있는 자금이 있는지 확인한 다음 UserOperation을 검증합니다. 검증에 성공하면 sender의 account에서 Bundler에게 UserOperation에 대한 Gas fee를 지불하고 nonce가 증가합니다. 만약 UserOperation을 생성한 sender의 account가 존재하지 않는 경우, initCode필드를 통해 새 account를 생성합니다.

그 다음 Execution loop(④, ⑤)에서는 UserOperation의 calldata로 sender의 account 호출 후, execution함수로 calldata를 해석 및 실행합니다. UserOperation을 실행하기 전, 다시 한번 signature가 정확하고 실제로 Gas fee를 지불하는지 확인하며, Bundle transaction 실행 후 남은 Gas fee를 환불합니다.

Entry point extension: Paymasters (optional)

이더리움의 Account Abstraction는 Entry point의 logic을 확장하여 Paymasters 기능을 지원합니다. Paymasters 기능을 통해 Application 개발사가 sender에게 Gas fee를 지원하거나 ERC-20토큰과 같은 여러 case로 Gas fee 지불 옵션을 제공할 수 있습니다.

Paymasters 옵션 설계의 경우, 우선 sender가 UserOperation 전송 시, Gas fee를 대신 지불할 account의 주소를 UserOperation의 paymasterAndData 필드에 입력 후 UserOperation mempool에 전송해야 합니다. 만약 paymasterAndData 필드가 0인 경우, sender가 직접 Gas fee를 지불합니다.

② 기존 Entry point contract와 마찬가지로 validateUserOp함수 호출을 통해 UserOperation의 signature과 nonce를 검증합니다. 그리고 ③ paymasterAndData 필드에 입력된 주소의 지갑에 UserOperation을 수행할 수 있는 Gas fee를 충분히 가지고 있는지 확인합니다. ④ 충분하다면 validatePaymasterUserOp를 호출하여 paymasterAndData에 입력된 address가 Gas fee를 지불할 의사가 있는지 확인합니다. 지불의사가 있을 경우, validateUserOp은 sender account의 예치금이 Gas fee지불에 사용되지 않음을 나타냅니다. 그 다음 ⑤ execution 함수를 호출하여 UserOperation를 실행합니다. 마지막으로 ⑥ postOp 호출을 통해 paymasterAndData 필드에 입력된 주소의 지갑에서 Gas fee를 지불합니다. 만약 sender에게 Gas fee를 ERC-20 토큰으로 지불하는 옵션을 제공하고 싶다면, postOp에서 내부적으로 validatePaymasterUserOp를 통해 sender의 ERC-20 잔액이 충분한지 확인한 다음 sender에게 ERC-20 토큰을 청구 후 Gas fee를 대신 지불하면 됩니다.

ERC-4337 use case

이더리움 생태계 내 Application 혹은 Wallet은 ERC-4337기반의 Account Abstration 구현을 통해 다음과 같은 응용 사례를 기대할 수 있습니다.

1. 검증 방식 커스텀 가능

ERC-4337을 통해 검증을 프로토콜이 아닌 EVM에서 실행함으로써, 각 account마다 검증 방식을 커스텀할 수 있습니다. 이를 통해 이더리움에서 Multi-sig 혹은 키 변경 등 다양한 옵션 제공이 가능합니다. 즉, ERC-4337기반 지갑을 소유한 사용자는 개인 키 관리 및 의존도가 줄거나 사라집니다.

2. ECDSA 서명 방식 변경 가능

ERC-4337을 통해 이더리움의 ECDSA 서명방식 외에도 Schnorr 혹은 BLS 서명과 같은 다른 서명방식을 사용할 수 있습니다. 그 결과 이더리움에서 다양한 지갑 디자인이 가능해집니다.

3. ERC-4337을 적용한 스마트 컨트랙트 지갑 구현 가능

마지막으로 지갑에 ERC-4337을 적용함으로써 EVM 계열 메인넷에 스마트 컨트랙트 지갑구현이 가능합니다. 기존에도 지갑마다 다른 방식으로 Account Abstraction을 구현하고 있지만, 앞으로 ERC-4337을 적용한 스마트 컨트랙트 지갑 제공이 가능해집니다.

이 외에도 다양한 이점들을 누릴 수 있으며, 대부분 이를 UI/UX 개선을 위한 시도가 시작되었다고 언급합니다. 하지만 UI와 UX가 무엇이 다르고, ERC-4337을 통해 어떻게 UX가 개선되었는지 평가하기는 어렵습니다. 그래서 본 세션에서는 UX에 대해 이해하고, Blockchain service UX Framework를 통해 ERC-4337 Use case를 자세하게 살펴보고자 합니다.

User experience(UX)?

UX를 이해하기 위해 HCI와 UI에 대해서 간단하게 설명드리겠습니다.

HCI(Human Computer Interaction)

먼저 HCI란 인간의 특성을 이해하고 컴퓨터 시스템과 상호작용을 연구하는 다학제적 연구 분야를 의미합니다. HCI는 Usability를 중심으로 UI(1980s), UX(1990s) 분야로 발전하였습니다.

UI(User interface)

UI는 사용자가 컴퓨터 시스템(제품/서비스)과 상호작용을 매개하는 모든(아날로그, 디지털) 입출력 시스템을 의미합니다. UI는 사용자의 인지적 특성을 고려하고 사용자가 시스템을 쉽게 사용할 수 있도록 인터페이스룰 디자인함으로써 작업 효율성 향상시키는데 의의가 있습니다. UI는 Usability뿐만 아니라 시각적으로 보이기 때문에 Aesthetic을 중점적으로 고려합니다.

UX(User experience)

UX는 사용자가 컴퓨터 시스템(제품/서비스)과 상호작용하며 축적되는 총체적인 경험을 의미합니다. 이는 컴퓨터 시스템을 도구로서만 접근하는 Usability의 한계를 뛰어넘기 위해 등장한 개념입니다. UX는 제품/서비스 사용 전/ 중/ 후 일어나는 사용자의 맥락, 인식, 감정, 만족도 등 총체적으로 고려하는데, 이 때 사용자의 Needs, Motives, Attitude, Behavior를 반영합니다. 이러한 UX의 대표적인 특징은 다음과 같습니다.

주관성(Subjectivity): 똑같은 제품/서비스여도 사용자들은 각기 다른 경험을 할 수 있음
총체성(Holistic): 경험은 특정 시점에 특정 개인이 느끼는 총체적인 것
맥락성(Contextuality): 제품/서비스와의 상호작용이 일어나는 시점에서 환경이나 맥락에 영향

또한 UX는 사용자가 제품/서비스에서 가치를 효율적으로 얻을 수 있도록 지원하는 적절한 기능과 상호작용 메커니즘을 설계하는 것도 포함합니다. 서비스 제공자는 제품이나 서비스 설계 초기 단계에서 UX를 관리함으로써 제공자의 의도와 사용자의 경험 사이의 간극을 줄일 수 있습니다. 더 나아가 UX 개선은 사용자의 제품이나 서비스 수용과 사용 동기 큰 영향을 주며 사용자 이탈을 방지하는 효과가 있습니다.

출처: An Introduction to User Experience Design

Blockchain service UX Framework

저희는 ERC-4337의 UX를 평가하기 위해 User experience framework for understanding user experience in blockchain services 논문에서 제안한 UX Framework를 사용하였습니다. 본 논문에서는 블록체인 서비스의 UX를 사용자들이 블록체인 서비스와 상호작용하면서 겪는 모든 직간접적 경험으로 정의합니다. 본 연구에서 표준화 부족, 규제로 인한 개발 저해와 함께 블록체인의 열악한 UX는 블록체인 서비스 확산의 주요 장애 요인이라고 언급하며, 낮은 UX는 블록체인의 본질적인 가치 파악에 높은 진입장벽 형성한다고 주장합니다. 그렇기에 논문에서는 블록체인 서비스에서 UX의 본질을 이해하기 위한 UX Framework를 만들어 제안했습니다.

출처: User experience framework for understanding user experience in blockchain services

우선 블록체인 서비스가 제공할 수 있는 기능은 크게 Non-blockchain function(NBF)과 Blockchain function(BF)으로 분류했습니다. 예를 들어 사용자의 프로필 이미지 변경은 SNS에서 제공하는 기능으로 블록체인 기술과는 무관하기에 NBF이며, BF의 경우 dApp 사용을 위해 지갑을 연결하는 기능처럼 블록체인 기술 도입으로 인해 사용자가 새로운 유형의 기능과 상호작용하는 것을 의미합니다. 기능 분류 후, UX Framework 개발을 위해 문헌과 사례조사를 통해 블록체인 서비스에서 UX를 두 가지 범주로 구분하였습니다.

General UX

General UX는 일반적으로 제품이나 서비스를 사용하면서 얻는 경험을 의미합니다. General UX는 NBF와 BF에서 둘 다 측정 가능합니다. General UX의 경우 문헌조사를 통해 UX 요소를 도출하였습니다. 그 결과 General UX의 요소로 Usability, Affect, Sociability가 도출되었습니다. Usability는 제품, 시스템 또는 서비스의 사용 또는 예상되는 사용으로 인한 사용자의 인식 및 반응을 의미하며 주로 사용편의성에 초점이 맞춰져 있습니다. 그리고 Affect는 블록체인 서비스와의 상호작용에서 사용자가 경험하는 정서적인 느낌을 의미하며, 마지막으로 Sociability는 블록체인 서비스 이용이 사용자의 사회생활을 만족시키는 정도를 의미합니다.

출처: **User experience framework for understanding user experience in blockchain services** 참고

Technological UX

Technological UX는 서비스 제공자가 블록체인 기술을 서비스에 도입함으로써 사용자에게 새로운 경험을 제공할 수 있는 경험을 의미합니다. 따라서 Technological UX는 블록체인 기술과 직접적으로 관련된 BF에서만 측정 가능합니다. 본 연구에서는 General UX와 달리 블록체인 서비스에 특화된 Technological UX에 대한 기존연구는 찾아보기 어렵기 때문에 블록체인 서비스 분석을 통해 UX 요소를 도출하였습니다. 다양한 도메인의 블록체인 서비스 분석을 통해 BF(Reward, Curating, Transaction, Cryptocurrency wallet, Security, Authorization)를 6개로 정의 후, 브레인 스토밍을 통해 Technological UX의 요소로 Social value, Economic value, Trust가 도출되었습니다. Social value는 블록체인 기술의 특성으로 인해 얻을 수 있는 사회적 경험을 의미합니다. 그리고 Economic value는 블록체인을 도입하여 발생하는 시간적, 금전적 이익을 의미합니다. 마지막으로 Trust는 블록체인 서비스의 특성에서 발생하는 신뢰를 의미합니다.

Blockchain UX problem

ERC-4337의 UX 평가 전, 저희는 블록체인 및 이더리움의 UX 문제를 먼저 파악하고자 Vitalik Buterin’s website에서 여러 글 중 UX측면에서 다룬 내용들을 가져왔습니다.

What in the ETH App ecosystem excites me

비탈릭 부테릭은 블록체인은 확장성이 떨어지고, 최근까지 거래가 체인에 안정적으로 포함되기까지 상당히 오랜 시간이 걸렸으며, 현재의 지갑은 사용자에게 낮은 편의성과낮은 보안성 사이에서 불편한 선택을 강요하고 있다고 설명합니다. 그리고 이에 대해 ERC-4337과 계정 추상화 지갑의 등장은 대안으로서 기회를 제공할 수 있다고 언급합니다.

Some personal user experiences

비탈릭 부테릭이 블록체인 서비스를 사용하면서 느낀 내용들을 공유한 글입니다. 본 내용 중 Shamir’s secret sharing방식 기반의 Social recovery wallet 실패 경험을 공유하였습니다. 대책으로 계정 추상화를 활용하는 지갑을 언급하며 ERC-4337에 대한 필요성에 대해 설명합니다.

실제로 블록체인 서비스 및 암호화폐에 익숙하지 않은 사용자들은 블록체인 서비스를 위해 어렵고, 복잡하며 불편한 경험을 겪는 것을 확인할 수 있습니다. 사용자는 블록체인 서비스를 사용하기 위해 아래 그림과 같이 ① Wallet을 선택 및 생성해야하며, 그 과정에서 ② 개인 키를 잃어버리지 않게 보관해야 합니다. 지갑생성을 마쳤으면 이제 ③ 업비트, 빗썸과 같은 중앙거래소(CEX)에서 현금으로 암호화폐를 선택 및 구매합니다. 그리고 ④ 구매한 암호화폐를 사용자의 Wallet address로 암호화폐 송금하는 과정까지 복잡한 온보딩 과정을 거쳐야합니다.

복잡한 과정을 거쳐 블록체인 서비스에 연결했다면, 활용하기 위해 ⑤ 매 트랜잭션(Tx)마다 서명하고 ⑥ 트랜잭션 실행을 위해 Gas fee를 지불해야 합니다. 만약 Gas fee를 낼 수 있는 암호화폐가 없으면 ③단계 부터 다시 시작해야 합니다. ⑦ 사용자가 Gas fee를 성공적으로 지불했다면, 트랜잭션 체결까지 대기해야합니다. 만약 트랜잭션이 거절된다면 사용자는 이유도 모른채 사용에 어렵고 불편한 경험을 겪게됩니다. ERC-4337을 통해 사용자 입장에서 불편함 경험이 어떻게 UX 측면에서 개선될 수 있을지를 다음 편에서 다뤄보도록 하겠습니다.