Account abstraction

인범·2023년 1월 24일

Web3

오늘은 비탈릭 부테린이 제안한 EIP4337 account abtraction에 대해 알아볼 예정입니다.
우선 두 종류의 account인 EOA와 CA에 대해 먼저 알아보도록 합시다.

EOA(Externally owned accounts)

메타마스크와 같은 지갑 어플리케이션을 통해 만드는 계정
private key에 의해 control되는 account
트랜잭션을 실행할 수 있습니다.
단점
- 비밀키의 분실이 곧 account의 분실이다.
- ECDSA 검증 방식은 양자 컴퓨터에 취약하다.

CA(contract accounts)

스마트 컨트랙트를 배포했을 때 생성되는 account입니다.
배포된 코드에 의해 control되는 account
스스로 트랜잭션을 실행할 수 없으며 오직 EOA를 통해서만 실행할 수 있습니다.

Account abstraction

: 계정 추상화
*추상화 : 복잡한 내부적인 작동 과정을 숨기고 핵심적인 기능만 간추리는 과정을 의미

=> abtraction의 목적은 EOA와 CA의 두 타입으로 나눠진 account를 contract account 하나로 만드는 것. 즉 기존에 서로 다른 타입으로 존재하는 두 account를 하나로 추상황시킴으로써 사용자들이 이를 구별할 필요가 없도록 만드는 것

기술적 장벽

EOA에서 시작되는 트랜잭션의 검증이 이더리움 가상머신이 아닌, 가상머신 이전에 이더리움 프로토콜에서 이루어진다는 점입니다.
이를 해결하기 위해서는 CA로 트랜잭션의 verification이 가능하도록 만들어야 합니다. 즉 트랜잭션의 검증과 실행까지 모든 과정을 이더리움 가상머신에서 수행되도록 만들어야 합니다.

Use case of account abtraction

이를 구현하기 위한 변화는 코어 레벨에서 시작되나, 이러한 코어 레벨에서의 변화를 통해 다양한 어플리케이션의 변화가 발생한다.

검증 로직 자체를 커스텀 가능
현재는 키 쌍의 private key로 서명을 생성하고 이 서명으로 올바른 account가 맞는지 확인하는 방식을 사용하고 있었습니다. 그러나 verification logic이 EVM에서 실행될 수 있다면 각 account마다 검증 로직을 원하는대로 변경할 수 있습니다.
1) 하나의 account가 여러 signer를 통해 제어될 수 있도록 검증 로직을 변경 = multi sig
2) private key가 변경될 수 있는 이더리움 account의 구현도 가능 = upgradeable wallet
특정한 암호학적 서명 방식에 의존하지 않아도 됩니다. BLS서명 방식을 사용하여 가스비를 절감할 수도 있고 양자 내성이 있는 알고리줌을 선택할 수도 있을 것입니다.

history of account abstraction

2016부터 제안되어져 와서 비탈리부테린을 기점으로 EIP86, EIP2938 등이 제안되어 왔지만 프로토콜을 변경해야한다는 문제로 적용되기는 어려운 제안이었으나
컨선서스 레벨을 바꾸지 않고 등장한 제안이 ERC4337입니다. 아래에 ERC4337 제안자들이 구현한 코드입니다
https://github.com/eth-infinitism/account-abstraction