Account Abstraction에 대하여
이더리움 커뮤니티의 꿈 : Account Abstraction과 ERC-4337
Authors: Mark Kim (@MAZY_8)
Boom Labs는 Web 3 개발자들을 온보딩시키고, 생태계를 활성화시키기 위해 교육을 비롯한 여러 활동들을 하고 있습니다. 저희 비전에 공감하여 동참하고자 하는 분들은 Boom Labs의 문을 두드려주세요!
Disclaimer: 이 글은 정보 전달을 위한 목적으로 작성되었으며, 특정 프로젝트에 대한 투자 권고, 법률적 자문 등 목적으로 하지 않습니다. 모든 투자의 책임은 개인에게 있으며, 이로 발생된 결과에 대해 어떤 부분에서도 Boom Labs는 책임을 지지 않습니다. 본문이 포괄하는 내용들은 특정 자산에 대한 투자를 추천하는 것이 아니며, 언제나 본문의 내용만을 통한 의사결정은 지양하시길 바랍니다.
Account Abstraction은 이더리움에서 아주 오래전부터 준비해온 기능이며 2021년 9월에는 비탈릭이 이와 관련해서 블로그를 작성하기도 했다. Account Abstraction을 통해서 다양한 서명을 사용할 수 있으며 특정 계정(Account)에서 수수료를 대신 지불하는 기능을 구현하는 등 계정을 더 유연하게 사용할 수 있다. Account Abstraction과 이를 실제로 구현하기 위한 ERC-4337에 대해서 자세하게 소개하고자 한다.
이더리움 계정 시스템
먼저 Account Abstraction을 이해하기 위해서는 이더리움의 계정이 어떻게 이뤄졌는지 이해해야할 필요가 있다. 이더리움에서는 외부 소유 계정(EOA, Externally-owned Account)와 컨트랙트 계정(CA, Contract Account) 두 가지 계정을 사용하고 있으며 각각의 역할은 다르다. 외부 소유 계정은 이더리움을 거래하기 위해 개인 키를 발급받아 생성하는 계정이다. 이를 통해 트랜잭션을 발생시키고 다른 외부 소유 계정이나 컨트랙트 계정에 전송할 수 있다. 대표적인 예로 메타마스크가 생성한 계정을 생각해볼 수 있다. 컨트랙트 계정은 컨트랙트가 발행될 때 생성 되며 외부 소유 계정과 다르게 코드와 저장소를 가지고 있으며 특정 시점에 코드를 실행할 수 있다. 하지만 트랜잭션과 컨트랙트를 발행하기 위한 권한이 없기 때문에 컨트랙트에서 새로운 컨트랙트를 발행하기 위해 외부 소유 계정을 함께 사용해야 한다는 특징을 가지고 있다.
그러면 Account Abstraction은 도대체 무엇인가?
Account Abstraction을 간단하게 얘기하면 두 가지 다른 외부 소유 계정과 컨트랙트 계정을 하나의 계정처럼 합쳐 사용할 수 있도록 만드는 것을 뜻한다.
현재 이더리움은 각 계정의 역할이 다르다. 이때문에 컨트랙트 계정은 트랜잭션 발행 및 서명의 권한이 없어 컨트랙트로 기능을 구현 할 때 제약사항이 많게 된다. 트랜잭션을 발행하거나 서명이 필요한 경우에는 반드시 외부 소유 계정을 통해 트랜잭션을 발행해야 하므로 트랜잭션 발행에 필요한 기본 수수료 21,000 Gas를 사용해야 하며 계정 관리도 별도로 해야한다는 점이 발생하기 때문이다. Account Abstraction은 두 종류의 계정을 사용하지 않고 컨트랙트 계정에 서명, 트랜잭션 발행이 가능하도록 하여 하나의 계정으로 외부 소유 계정과 컨트랙트 계정의 기능을 사용할 수 있도록 만들어준다. 이런 변화를 통해 계정을 한 번에 관리하거나 특정 계정에서 수수료를 대신 낼 수 있는 기능 등 현재 컨트랙트 계정으로 할 수 없는 다양한 기능을 구현할 수 있게 된다.
Account Abstraction은 예전부터 이더리움 생태계에서 준비하고 있던 기능으로 EIP-2938에서 이더리움 프로토콜을 수정해 Account Abstraction을 구현하려고 했으나 기존 프로토콜을 수정한다는 한계로 인해 적용이 힘들었다. 그러나, ERC-4337에서는 Consensus Layer를 수정할 필요 없이 트랜잭션 Mempool의 기능을 그대로 사용하고 UserOperation이라는 구조를 새로 만들어 기존 프로토콜 단에서 새로운 트랜잭션을 추가하지 않고 Account Abstraction을 구현했다.
ERC-4337의 구조
ERC-4337에서는 UserOperation이라는 구조체를 사용하게 된다. UserOperation은 스마트 컨트랙트로 구현된 구조체로 ABI인코딩 되어 있으며 아래 그림과 같이 nonce, sender, 등 12개의 필드를 가지고 있다. UserOperation이 가지고 있는 필드를 살펴보면 트랜잭션이 가지고 있는 필드와 유사하다. 트랜잭션에서와 마찬가지로UserOperation은 서명, nonce 값, 지불해야할 가스비용을 컨트랙트를 통해 검증하고 코드를 실행한다.
동작 과정
먼저 그림의 우측 상단에서 보이는 것처럼 사용자가 UserOperation 객체를 전송하면 이것들이 Mempool에 등록된다. Bundler는 UserOperation 객체를 선택할 때 기존 Mempool에서 높은 수수료를 지불하는 트랜잭션을 선택하는 것과 같은 메커니즘을 사용한다. 그래서 Mempool에 등록된 UserOperation 객체 중 Bundler에게 수수료를 많이 지불하는 객체를 모아 “Bundle Transaction”으로 만들어 이더리움 블록에 담는다. Bundler는 UserOperation Mempool에서 UserOperation 객체를 모아 검증하고 실행하여 “Bundle Transaction”을 만드는 노드라고 볼 수 있다. Bundler는 해당 작업에 대한 수수료를 ETH로 지불하고 모든 개별 UserOperation 실행의 일부로 지불된 수수료를 통해 보상을 받게 된다.
Entry Point 구조
지갑의 로직을 간단하게 만들기 위해 보안을 위해 필요한 복잡한 스마트 컨트랙트 로직의 상당수는 지갑에서 이뤄지는게 아니라 Entry Point라고 하는 글로벌 컨트랙트 안에서 작업된다. Entry Point 컨트랙트는 UserOperation 객체들을 검증하고 실행하는 역할을 하며 verification loop와 execution loop를 필수로 구현해야한다. verification loop는 UserOperation의 지갑 컨트랙트가 존재하지 않는 경우 새로 생성하고, 지갑 컨트랙트에서 validateUserOp를 호출하여 UserOperation과 필요한 수수료를 전달한다. 그리고 지갑 컨트랙트에서는 UserOperation의 서명과 작업이 유효하다면 지갑 컨트랙트에서 수수료를 지불하는 과정을 말한다. Execution Loop는 지갑 컨트랙트에서 op execution 함수를 호출하여 calldata를 실행하고 남은 가스비는 환불해준다.
지불 계좌 : Paymasters
Account Abstraction에서는 Entry Point 컨트랙트로 paymasters 기능을 지원한다. paymasters는 애플리케이션 개발자가 사용자의 수수료를 대신 지불하거나 사용자가 ERC-20 토큰으로 수수료를 지불하는 등 사용자를 위한 기능을 제공한다. 수수료를 대신 지불할 계정의 주소를 UserOperation의 paymaster 필드에 입력하면 paymaster의 지갑에서 잔액 확인 과정과 sender 확인 과정을 거쳐 수수료를 대신 지불한다. 이 때 paymasters 필드가 0인 경우 sender가 직접 수수료를 지불하는 로직이다.
- paymasters를 사용하는 경우 Entry Point 컨트랙트에서 사용자 지갑에서 validateUserOp를 호출하여 사용자의 서명과 nonce 값을 검증한다.
- paymasters 필드에 입력된 주소의 지갑으로 이동하여 paymaster가 수수료를 지불할 충분한 잔액이 있는지 확인하고 validatePayMasterUserOp를 호출하여 paymaster가 요청한 작업에 대한 수수료를 지불할 의사가 있는지 확인한다.
- 사용자 지갑에서 op execution 함수를 호출하여 실행을 마친 후 Post-op를 호출하여 paymaster에서 수수료를 지불한다.
만약 사용자가 ERC-20 토큰으로 수수료를 지불하고 싶은 경우 paymaster는 사용자가 수수료를 지불할 충분한 ERC-20 토큰을 가지고 있는지 확인하고 paymaster는 가스비를 대신 지불하고 Post-op에서 사용자에게 ERC-20 토큰을 청구하여 수수료를 ERC-20 토큰으로 지불할 수 있게 해준다.
Account Abstraction의 장단점
장점
- 모든 작업이 Mempool을 사용하여 중앙집중식 시스템 없이 사용할 수 있다.
- 다양한 서명 알고리즘을 사용할 수 있다. 외부 소유 계정에서는 ECDSA 서명 알고리즘만 사용이 가능하지만 Account Abstraction을 통해 스마트 컨트랙트에서 서명이 가능하다면 슈노르 서명(Schnorr), BLS 등 다양한 서명 알고리즘을 사용하고 검증할 수 있다. ECDSA 서명 알고리즘은 양자 컴퓨팅이 등장하면 실시간으로 해독되어 사용할 수 없는데 다양한 서명 알고리즘을 사용하면 양자 보안에 안전하게 된다.
- 지갑에서 검증 로직은 Stateful 하기 때문에 공개키를 변경하거나 지갑을 업그레이드 할 수 있다.
- 지갑의 실행 단계에서 사용자가 필요한 기능을 추가하는 등 실행 로직을 유연하게 사용할 수 있다.
단점
- DOS 공격에 조금 취약해진다. ECDSA에 비해 다른 서명 알고리즘이 검증 논리 측면에서 다소 복잡할 수 있기 때문에 DOS 공격에 약간 취약해진다.
- 가스 오버헤드, 일반 트랜잭션보다 약간 더 많은 가스 오버헤드가 발생할 수 있다.
- 하나의 트랜잭션만 보낼 수 있다. 여러 트랜잭션을 Mempool에 보낼 수 없다는 한계가 있다 하지만 원자적 다중 작업 기능으로 인해 극복 가능할 것이라 예상함. (EIP-3074의 목표)
Use Case
Argent — zkSync의 Account Abstraction 기술을 활용한 Wallet 서비스
핵심 기능
- 키 복구 (Key Recovery) : 프라이빗 키를 분실하거나 손상된 경우 스마트 컨트랙트 지갑은 계정을 제어하는 키를 안전하게 교체하는 메커니즘을 추가할 수 있음. 그래서 seed 구문을 잊어버리는 것을 고민하지 않아도 됨.
- 사기 모니터링(Fraud Monitoring) : 모든 트랜잭션을 검사하여 정의된 보안 규칙을 준수하는지 확인하고 사용자가 잘못된 주소 및 컨트랙트로 자산을 보내는 것을 방지함.
- 미래를 대비한 서명 구조 (Future-Proof Signatures) : 스마트 컨트랙트 지갑들은 더 단순하거나 효율적인 형태의 서명 구조로 바꿀 수 있음. 또는 iOS 및 안드로이드 장치의 보안 기능을 사용해서 모든 전화기를 하드웨어 지갑으로 바꿀 수 있기에 대비가 가능해야함.
- 멀티콜(Multicall) : 멀티콜을 통해 여러 트랜잭션을 하나로 묶으면 더 이상 원하는 작업을 수행하기 위해 tx 뒤에 서명하고 tx를 만들 필요가 없음. dapp과 상호작용하는 것이 더 빠르고, 쉽고, 더 안전할 것.
- 어떤 토큰으로든 지불하기(Pay fees in any token) : 사용자는 특정 토큰으로 수수료를 지불하는 것에 대해 걱정할 필요가 없음. Account Abstraction을 사용하면 수수료에 대한 지불은 모든 종류의 메커니즘으로 이루어질 수 있다. 사용자는 자신이 소유한 모든 자산으로 지불할 수 있다.
- 세션 키(Session Keys) : 이를 통해 사용자가 주어진 기간, 최대 가스량, 특정 토큰의 최대 거래량 또는 특정 계약의 특정 기능과 같은 일련의 기준에 따라 애플리케이션의 거래를 사전 승인할 수 있도록 함으로써 블록체인 게임에 대한 원활한 경험을 만들 수 있음.
참고 자료 :
ERC 4337: account abstraction without Ethereum protocol changes — Vitalik Buterin
