이더리움 계정 추상화(Account Abstraction)

Published in

Decipher Media ｜디사이퍼 미디어

11 min readOct 16, 2021

2021년 9월 29일 비탈릭은 꿈꿔왔던 이더리움 계정 추상화를 곧 사용할 수 있게 될 것이라는 글을 작성했다. 계정 추상화는 이더리움에서 아주 오래전부터 준비해온 기능이다. 계정 추상화를 통해 다양한 서명을 사용할 수 있으며 특정 계정에서 수수료를 대신 지불하는 기능을 구현하는 등 계정을 더 유연하게 사용할 수 있다. 이번 글에서는 계정 추상화에 대해 소개하고 어떤 장단점이 있는지, 이더리움에서 계정 추상화를 어떻게 구현했는지 소개한다.

이더리움의 계정

계정 추상화에 대해 설명하기 전에 현재 이더리움에서 사용하고 있는 계정에 대해서 간단하게 알아보자. 이더리움에서는 외부 소유 계정(EOA)과 계약 계정(CA) 두 가지 계정을 사용하고 있으며 각 계정의 역할이 다르다. 먼저 외부 소유 계정은 우리가 이더리움을 거래하기 위해 개인 키를 발급받아 생성하는 계정이다. 외부 소유 계정은 최상위(top-level) 계정으로 개인 키와 주소를 가지고 있어 트랜잭션을 발행하고 서명할 수 있는 권한을 가지고 있다. 컨트랙트 계정은 컨트랙트가 발행될 때 생성되며 외부 소유 계정과 달리 코드와 저장소를 가지고 있어 특정 시점에 코드를 실행할 수 있다. 하지만 트랜잭션과 컨트랙트를 발행하는 권한이 없기 때문에 컨트랙트에서 새로운 컨트랙트를 발행하거나 트랜잭션을 발행하기 위해서는 외부 소유 계정을 함께 사용해야 한다.

계정 추상화(Account Abstraction)란?

계정 추상화는 위에서 설명했던 이더리움의 두 가지 계정을 하나의 계정으로 합쳐 사용할 수 있도록 하는 것을 말한다. 현재 이더리움은 각 계정의 역할이 다르다. 특히 컨트랙트 계정에 트랜잭션 발행, 서명의 권한이 없어 컨트랙트로 기능을 구현할 때 제약이 많다. 트랜잭션을 발행하거나 서명이 필요한 경우 반드시 외부 소유 계정을 통해 트랜잭션을 발행해야 하므로 트랜잭션 발행에 필요한 기본 수수료 21000 가스를 사용해야 하며 계정 관리도 번거롭다. 계정 추상화는 두 종류의 계정을 사용하지 않고 컨트랙트 계정에 서명, 트랜잭션 발행이 가능하도록 하여 하나의 계정으로 외부 소유 계정과 컨트랙트 계정의 기능을 사용할 수 있도록 만든다. 하나의 계정에서 컨트랙트 실행과 트랜잭션 발행이 가능하다면 컨트랙트 지갑(Contract wallet)을 사용하여 계정을 한 번에 관리하거나 특정 계정에서 수수료를 대신 낼 수 있는 기능 등 현재 컨트랙트 계정으로 할 수 없는 다양한 기능을 구현할 수 있다.

이더리움에서 계정 추상화는 아주 오래전부터 준비해오던 기능이었다. EIP-2938에서는 계정 추상화를 위한 트랜잭션을 새로 추가하는 방법을 제안했는데 이 방법은 이더리움 프로토콜을 수정해야 한다는 문제점이 있었다. 이번에 소개하는 ERC-4337에서는 consensus layer를 수정할 필요 없이 트랜잭션 mempool의 기능을 그대로 사용하며, UserOperation을 사용하여 새로운 트랜잭션을 추가하지 않고 계정 추상화를 구현했다.

UserOperation

UserOperation은 스마트 컨트랙트로 구현된 구조체로 ABI인코딩 되어있으며 nonce, signature, sender 등 12개의 필드를 가지고 있다(그림1). UserOperation은 트랜잭션과 같은 역할을 하는 것처럼 보이는데, UserOperation은 트랜잭션이 아닌 스마트 컨트랙트로 구현된 구조체이다. UserOperation이 가지고 있는 필드를 살펴보면 트랜잭션이 가지고 있는 필드와 유사하다. 그리고 트랜잭션을 검증할 때 서명, nonce 값, 지불해야할 가스비용 등을 확인하는데, UserOperation 객체 역시 서명, nonce값, 지불해야할 가스비용을 컨트랙트를 통해 검증하고 코드를 실행한다. 실제 검증하는 과정은 트랜잭션과 다르지만, 외부 소유 계정에서 트랜잭션을 발행한다면, 계정 추상화를 통한 컨트랙트 계정에서는 UserOperation이 트랜잭션과 비슷한 역할을 한다고 이해하면 될 것 같다.

UserOperation 처리 과정

사용자가 UserOperation객체를 전송하면 mempool에 등록된다. Bundler는 UserOperation 객체를 선택할 때 기존 mempool에서 높은 수수료를 지불하는 트랜잭션을 선택하는 것과 같은 메커니즘을 사용한다. Mempool에 등록된 UserOperation객체 중 bundler에게 수수료를 많이 지불하는 객체를 모아 “bundle transaction”을 만들어 블록에 담는다. 위 그림은 UserOperation 객체가 처리되는 과정을 그림으로 나타낸 것이다.

bundler : UserOperation mempool에서 UserOperation객체를 모아 검증 및 실행하고 “bundle transaction”으로 만드는 노드

Wallet Contract

Wallet contract는 entry point contract에서 자동으로 만들어준다. UserOperation을 검증하는 validateUserOp 함수와 calldata를 실행하는 op execution 함수를 필수로 가지고 있어야 한다. validateUserOp 함수는 UserOperation의 서명과 nonce 값을 검증하고, 검증에 성공하면 가스비를 지불하고 nonce 값을 증가시킨다. 검증에 실패할 경우 예외를 발생시킨다. Op execution 함수는 validateUserOp 함수에서 검증에 성공한 경우 calldata를 실행한다.

Entry point contract

entry point contract는 UserOperation 객체들을 검증하고 실행하는 역할을 하며 verification loop와 execution loop가 필수로 구현되어 있어야 한다. verification loop는 UserOperation의 wallet contract가 존재하지 않는 경우 새로 생성하고, wallet contract에서 validateUserOp를 호출하여 UserOperation과 필요한 수수료를 전달한다. 그리고 wallet contract에서는 UserOperation의 서명과 작업이 유효하다면 wallet contract는 수수료를 지불해야 한다. execution loop는 wallet contract에서 op execution 함수를 호출하여 calldata를 실행하고, 남은 가스비를 환불해준다. 위 그림은 Bundler의 계정에서 Entry point contract를 통해 UserOperation 객체를 처리하는 과정을 나타낸 그림이다.

Paymasters

이더리움 계정 추상화에서 entry point contract로 paymasters 기능을 지원한다. paymasters는 애플리케이션 개발자가 사용자의 수수료를 대신 지불하거나 사용자가 ERC-20 토큰으로 수수료를 지불하는 등 사용자를 위한 기능을 제공한다. 수수료를 대신 지불할 계정의 주소를 UserOperation의 paymaster필드에 입력하여 보내면 paymaster의 지갑에서 잔액 확인 과정과 sender 확인 과정을 거쳐 수수료를 대신 지불한다. (paymasters 필드가 0인 경우 sender가 직접 수수료를 지불하는 것으로 간주한다.)

위 그림은 paymaster를 사용하는 경우 UserOperation 기능을 객체를 처리하는 과정을 나타낸 그림이다. paymasters를 사용하는 경우 entry point contract에서는 (2) 사용자 지갑에서 validateUserOp를 호출하여 사용자의 서명과 nonce 값을 검증한 후 (3) paymasters필드에 입력된 주소의 지갑으로 이동하여 paymaster가 수수료를 지불할 충분한 잔액이 있는지 확인하고 (4) validatePayMasterUserOp를 호출하여 paymaster가 요청한 작업에 대한 수수료를 지불할 의사가 있는지 확인한다. 그리고 사용자 지갑에서 (5) op execution 함수를 호출하여 실행을 마친 후 (6) Post-op를 호출하여 paymaster에서 수수료를 지불한다.
만약 사용자가 ERC-20 토큰으로 수수료를 지불하고 싶은 경우 paymaster는 사용자가 수수료를 지불할 충분한 ERC-20 토큰을 가지고 있는지 확인하고 paymaster는 가스비를 대신 지불하고 Post-op에서 사용자에게 ERC-20 토큰을 청구하여 수수료를 ERC-20 토큰으로 지불할 수 있다.

계정 추상화의 장단점

[장점]

모든 작업이 mempool을 사용하여 중앙집중식 시스템 없이 사용할 수 있다.
다양한 서명 알고리즘을 사용할 수 있다. 현재 외부 소유 계정에서는 ECDSA 서명 알고리즘만 사용이 가능하다. 하지만 계정 추상화로 스마트 컨트랙트에서 서명이 가능하다면 ECDSA뿐만아니라 슈노르 서명(Schnorr), BLS등 다양한 서명 알고리즘을 사용하고 검증할 수 있다.
ECDSA 서명 알고리즘은 양자컴퓨팅이 등장하면 실시간으로 암호가 해독되어 사용할 수 없는데 다양한 서명 알고리즘을 사용하면 양자 보안에 안전한다.
지갑에서 검증 로직은 stateful하기 때문에 공개키를 변경하거나 지갑을 업그레이드할 수 있다.
지갑의 실행 단계에서 사용자가 필요한 기능을 추가하는 등 실행 로직을 유연하게 사용할 수 있다.

[단점]

DOS공격에 아주 조금 취약해진다.
약 3000 가스를 소모하는 ECDSA에비해 다른 서명 알고리즘이 가스비를 더 많이 사용하기 때문에(more complex) DOS공격에 약간 취약해진다.
일반 트랜잭션보다 가스 오버헤드가 약간 증가할 수 있다.
계정이 하나의 트랜잭션만 처리할 수 있다.

결론

이번 글에서는 계정 추상화에 대한 개념과 구조에 대한 큰 틀을 설명했다. 지금 이더리움 계정은 두 종류로 나누어져 있고 각 계정의 역할도 다르다. 계정이 나누어져 있어 스마트 컨트랙트에서 트랜잭션을 발행해야 하거나 다른 컨트랙트를 발행해야 할 때 외부 소유 계정으로 발행해야 하는 불편함이 있다. 또 컨트랙트 계정으로 받은 화폐는 다시 사용자 소유 계정으로 옮겨 사용해야 하기 때문에 번거롭다. 계정 추상화가 구현되면 하나의 계정으로 사용할 수 있어 계정 관리가 편해지고 위에서 소개했던 paymaster 기능으로 ERC-20으로 수수료를 지불하거나 특정 계정에서 수수료를 대신 지불할 수 있어 디파이 서비스나 기업 등에서 사용자 유입을 위해 수수료를 대납해주는 등 혜택이 생기고 블록체인을 활용한 다양한 서비스가 출시될 것으로 예상된다.

계정 추상화는 현재 구현 중에 있으며, 초기 알파 버전이 곧 공개될 예정이라고 한다. 계정 추상화에 대해 더 알아보고 싶다면 EIP-4337 문서를 참고하거나, 개발 중인 계정 추상화 코드를 확인해볼 수 있다.

- CURG(Crypto United Research Group)는 2018년 5월 대학(원), 기업, 스타트업 등 다양한 분야의 열정적인 블록체인-er들이 모인 연합 연구 그룹입니다. CURG는 2018년 5월 출범된 이후, ‘Trendy, Thoughtful, and Transdisciplinary’ 한 자세로 한 주도 빠짐없이 블록체인 연구를 지속해오고 있습니다.

- 디사이퍼(DECIPHER)는 “건강한 블록체인 생태계 조성에 기여한다” 라는 미션 아래 블록체인에 대해 연구하고 이를 실용적으로 응용하는 서울대 블록체인 연구 학회입니다. 2018년 3월에 처음 조직 되어 현재까지 블록체인 기술을 다방면에서 연구하고 산업계에 응용하고 있는 100명 이상의 회원들을 배출해왔습니다. 다양한 팀별 연구활동과 프로젝트, 컨퍼런스 개최, 서울대학교 블록체인 강의 개설, 유수 기업들과의 산학협력과 파트너십 체결을 해오며 국내 최고의 블록체인 학회로 자리 잡았습니다.

커그와 디사이퍼는 향후 적극적인 협력을 통해 블록체인 필드에서의 강력한 시너지를 구축하고자 합니다.

Reference

[1]https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a
[2]https://github.com/ethereum/EIPs/blob/3fd65b1a782912bfc18cb975c62c55f733c7c96e/EIPS/eip-4337.md
[3]https://github.com/eth-infinitism/account-abstraction/blob/main/contracts/EntryPoint.sol
[4]https://eips.ethereum.org/EIPS/eip-2938