The problem Delivery Wallet solves

배경

Ether Denver 이후로, ERC-4337(계정 추상화)가 본격적으로 대중에게 알려졌다. 그리고 다양한 서비스들이 출현하였다. Stackup, Safe, Biconomy 등이 Bundler, Paymaster, Account Abstraction Wallet을 지원하고, Alchemy는 Rundler를 개발하고 있다. 최근에는 글로벌 기업인 Visa에서 Paymaster를 테스트넷에 배포했다.

문제점

많은 사람들이 새로운 지갑형태인 AA Wallet에 대한 UX의 변화와 사용의 편의성을 기대하고 있으나, 실제로는 AA Wallet을 사용하기에는 기대만큼 사용성이 편하지는 않다.

문제점1

기존에 메타마스크와 같은 EOA를 지원하는 지갑을 사용하는 유저는 계정추상화 지갑을 사용하기 위해서, 자산을 모두 이동시켜야 하는 불편함이 있다. 특히, 자산의 양 뿐만아니라 자산의 종류가 다양할 수록 이 허들은 매우 높아진다. 그리고 자산을 이동하는 과정에서 수수료 부과등의 이슈로 내 자산을 계정추상화 지갑으로 이동시키는 것이 깔끔하지는 않다. (Ex, 0.0000385939434 ETH -> Sludge Coin or Token)
다양한 자산을 이동시키기 위해서는 여러번의 서명이 필요하다.

문제점2

다양한 계정추상화 지갑을 지원하는 서비스는 많으나, 계정 추상화는 컨트랙트 기반 지갑이므로, 체인별로 컨트랙트 지갑이 존재해야 한다. 이에 따라, 체인별로 계정추상화 지갑을 생성해야하는 불편함이 있다. 물론 다중지갑을 지원해주는 일부 서비스가 있지만, 해당 서비스가 지원하는 체인에 한하여 지갑 생성이 가능하다. 그리고 이기종 체인간의 전송을 위해서는 브릿지 앱을 사용해야 하고, 전송의 절차도 복잡하다. (단계1. EOA계정 -> 브릿지드EOA계정, 단계2. 브릿지드EOA계정 -> AA계정)

해결방안

문제1 해결안

제안하는 컨트랙트를 이용하여, 쉽고 편하게 가스비 없이 계정 추상화 지갑으로 이동시키다. 대부분의 자산은 ERC-20 혹은 ERC-721, 1155 표준의 토큰이다. 해당 표준은 Trnasfer와 TransferFrom의 전송 방식을 가지고 있다. TransferFrom은 대부분의 DApp Contract에서 자산을 가져갈때 이미 많이 사용하고 있다. 유저는 우리팀이 제안하는 Contract에 자산의 이동을 승인만 하면, 서명을 여러번 할 필요 없이 다양한 자산을 계정추상화 지갑으로 이동시킬 수 있다.

문제2 해결안

체인별로 계정추상화 지갑을 각각 생성해야 하는데, 우리팀이 제안하는 서비스를 통해 한번의 클릭으로 여러체인의 계정추상화 지갑을 생성한다. 이는 체인별 Account Abstraction Wallet의 Factory Contract가 이미 여러개 배포되어있고, 이를 통해 새로운 AA Wallet Contract 생성이 가능하다.

Challenges we ran into

기술적 허들

AcountAbstraction Wallet(이하, AA Wallet) 생성

AA Wallet 생성을 위해서는 Entrypoint Contract와 Wallet Factory Contract의 주소를 알아야 하며, 유저의 개인키가 필요하다. Entrypoint가 배포되어있는 체인에서 AA Wallet 생성이 가능하나, 배포되어있지 않은 체인에서는 독자적인 인프라를 구축이 필요하다. 그래서 현재는 Stackup에서 지원하는 체인으로 한정하였다.

한번에 여러 자산을 이동시키기

토큰

토큰을 이동시키기 위해서는 유저가 Approve를 통해 우리팀에서 제안하는 Contract가 자산을 이동할 수 있도록 허가해야한다. 토큰의 종류가 많을 수록 많은 서명을 해야한다. 이를 위해서 한번의 서명으로 여러 Token Contract에 우리팀의 Contract의 주소 접근을 허가해주는 RawTransaction을 생성하고, 이를 Batch형태로 실행해야 하는데, BatchApprove 함수는 우림팀의 Contract에서 제공하고, 여기서 각 Contract에 Call로 실행하는 과정에서 msg.sender가 Owner가 아닌 이유로 Approve 처리가 원활하지 않은 문제가 있었다. 해당 문제는 데모에 적용되지 못하였고, 가능한 방법에 대한 리서치가 진행중이다.

코인

코인 자산은 토큰과는 다르게 Transfer로 User가 자산을 보내줘야 한다. 이 경우 가스수수료로 인하여 깔끔하게 전송이 어려운데, 이를 해결하기 위해서는 Wrapped 형태의 자산으로 변형하고 전송하는 방법이 있다. Wrapped형태의 토큰 자산으로 스왑하기 위한 De-Fi DApp 서비스 연결이 필요했으나, 데모 버전에는 지원하지 않았다.

AA Wallet의 제어를 위한 개인키 관리

개인키 관리가 중앙화 방식과 탈중앙화 방식이 존재하는데, 우리팀은 탈중앙화된 방식을 체택하였고, 사용자가 직접 AA Wallet의 개인키를 관리하도록 발급하였다.

환경(3rd party) 허들

체인별 AA Wallet 생성

체인별 AA Wallet생성을 지원하기 위해서는 체인에 Entrypoint 가 존재하여야 하는데, 현재는 특정 체인에만 Entrypoint가 생성되어 있으며, 이를 해결 하기 위해서는 Entrypoint 배포가 필요하다. 그래서 오로라 프로토콜에 Entrypoint Contract 배포를 시도하였으나, 코드사이즈 이슈로 배포에 실패하였다. 이 이유로 Stackup의 지원 체인으로 한정하였다.

이기종 체인간 자산 이동

위의 오로라 프로토콜을 통하여 Eth 자산을 Near 체인으로 이동하려고 했으나, Entrypoint 배포 실패로 현제 데모에는 지원하지 못하였다.