AA(Account abstraction) 구현

[she110ff]

No description provided.

[she110ff]

사용 예

• 멀티 시그 계정
• 일일 전송 제한 계정
• 소셜 리커버리

개요

이더리움에는 두 가지 유형의 계정이 있습니다:

1. 외부 소유 계정(EOA)
2. 컨트랙트 계정(CA)

전자는 트랜잭션을 시작할 수 있는 유일한 유형이며, 후자는 임의의 로직을 구현할 수 있는 유일한 유형입니다.
스마트 월렛과 같은 다른 두 계정 사이에서 마찰을 만들면서 동시에 의존성을 가지게 됩니다.

zkSync era(이하 zkSync)의 계정은 EOA처럼 트랜잭션을 시작할 수 있고, 스마트 컨트랙트처럼 임의의 로직을 구현할 수도 있습니다. "계정 추상화"(AA)라고 하는 이 기능은 위에서 설명한 문제를 해결하는 것을 목표로 합니다.

zkSync의 기본 계정 추상화는 스마트 계정과 페이마스터라는 개념을 도입하여 계정 운영 방식을 근본적으로 바꿉니다.

• 스마트 계정은 완전히 프로그래밍이 가능하므로 서명 체계, 기본 다중 서명 기능, 지출 한도, 애플리케이션별 제한 등 다양한 사용자 지정이 가능합니다.
• 반대로 페이마스터는 사용자의 트랜잭션을 후원할 수 있으며, 사용자가 ERC20 토큰으로 트랜잭션 수수료를 지불할 수 있도록 지원합니다.

계정 관리에 대한 이러한 혁신적인 접근 방식은 사용자 경험, 보안, 유연성을 크게 향상시켜 블록체인 기술의 광범위한 채택을 위한 기반을 마련합니다.

디자인

zkSync의 계정 추상화 프로토콜은 EIP4337와 매우 유사하지만, 효율성과 더 나은 UX를 제공합니다.

고유한 nonce 유지

• 현재 모델에서는 사용자 지정 지갑이 동시에 여러 트랜잭션을 전송하고 결정론적 순서를 유지하는 것이 허용되지 않습니다.
• EOA의 경우 논스는 순차적으로 증가할 것으로 예상되지만, 커스텀 계정 계정의 경우 거래 순서를 보장할 수 없습니다.
• 향후에는 계정이 순차적 또는 임의의 논스 주문 중에서 선택할 수 있는 모델로 전환할 계획입니다.

모든 블록체인의 중요한 불변성 중 하나는 각 트랜잭션이 고유한 해시를 가지고 있다는 것입니다. 임의의 계정 추상화를 통해 이 속성을 유지하는 것은 간단하지 않습니다. 일반적으로 계정은 여러 개의 동일한 트랜잭션을 수락할 수 있습니다. 이러한 트랜잭션이 블록체인 규칙에 따라 기술적으로 유효하더라도 해시 고유성을 위반하면 인덱서 및 기타 도구가 처리하기가 매우 어렵습니다. 따라서 프로토콜 수준에서 사용자에게는 저렴하면서도 악의적인 운영자의 공격에 강력하게 대응할 수 있는 솔루션이 필요합니다. 트랜잭션 해시가 반복되지 않도록 하는 가장 쉬운 방법 중 하나는 한 쌍(발신자, 논스)이 항상 고유하도록 하는 것입니다.

다음 프로토콜이 사용됩니다:

• 각 트랜잭션이 시작되기 전에 시스템은 논스홀더(NonceHolder)를 쿼리하여 제공된 논스가 이미 사용되었는지 여부를 확인합니다.
• 논스가 아직 사용되지 않은 경우 트랜잭션 유효성 검사가 실행됩니다. 이 기간 동안 제공된 논스는 "사용됨"으로 표시될 것으로 예상됩니다.
• 유효성 검사 후 시스템은 이 논스가 이제 사용됨으로 표시되었는지 확인합니다

사용자는 256비트 숫자를 논스로 사용할 수 있으며, 시스템 컨트랙트의 해당 키 아래에 0이 아닌 값을 넣을 수 있습니다. 이는 이미 프로토콜에서 지원됩니다.
현재로서는 논스의 순차적 순서를 실질적으로 강제하는 incrementMinNonceIfEquals 메서드만 사용하는 것을 권장합니다.

IAccount

• validationTransaction : nonce 유효성, ETH 가능 잔고, signature 체크
• executeTransaction : 트랜잭션 실행 - 수수료 징수 후에 호출
• payForTransaction(optional) : 트랜잭션이 페이마스터를 포함하지 않는 경우 사용됨
• prepareForPaymaster(optional) : 트랜잭션이 페이마스터를 포함하는 경우 사용됨
• executeTransactionFromOutside(optional) : EOA

IPaymaster

• validateAndPayForPaymasterTransaction
• postTransaction

구현

컨트랙트

1. AA 를 작성한다.
2. AA Factory 를 작성, 배포한다. (AA bytecode 사용)
3. Factory를 통해 AA (salt, wallet.address) 를 배포한다.
4. utils.create2Address 를 사용하여 AA 주소 획득한다.

트랜잭션

1. populateTransaction
2. set Tx(from, chainId, nonce, type)
3. set customData(gasPerPubdata, customSignature)
4. provider.sendTransaction(utils.serialize(setLimitTx))

Paymaster 와 비교하여

• EIP712 : 구조화된 데이터 해싱 및 서명 - 데이터를 digest 하여 시그니처(v,r,s)와 address recover에 사용

• 113 타입 값을 포함하는 트랙잭션을 직렬화 하여 전송

• EIP1271(isValidSignature) : 컨트랙트 소유 증명