ERC-4337 더미 서명과 가스 토큰 전송

ERC-4337 Gas Estimation에서는 ERC-4337에서 가스가 어떻게 작동하는지, 그리고 가스 추정을 위한 저희의 방법에 대해 다뤘습니다. 이 방법을 사용하면 사용자에게 user operation을 제출하기 위한 정확한 값을 제공할 수 있습니다. 하지만 항상 그렇게 간단하지는 않습니다.

ERC-4337 가스 추정을 복잡하게 만드는 몇 가지 다른 문제들을 살펴보겠습니다.

dummy signature 값이란 무엇인가?

대부분의 스마트 컨트랙트 계정 구현에서 signature 필드는 user operation을 해싱하고 해당 해시를 어떤 서명 체계(ECDSA가 가장 일반적)를 사용해 서명함으로써 오프체인에서 계산됩니다. 이 signature는 검증 단계 동안 계정 컨트랙트에 의해 온체인에서 검증됩니다.

예를 들어, SimpleAccount은 EIP-191 signature 체계를 사용하며, 이 해시는 OpenZeppelin의 ECDSA library를 사용하는 validateUserOp 함수 내에서 온체인으로 검증됩니다.

이 signature는 가스 추정 이후에 계산되어야 하는데, 이는 해당 필드들이 해시에 포함되기 때문입니다.

하지만, 가스 추정 단계 중 일부는 signature 필드가 채워져 있어야 합니다: preVerificationGas과 verificationGasLimit 입니다.

preVerificationGas

이 시리즈 1부의 preVerificationGas 추정 섹션에서, 번들러가 미터링되지 않은 가스를 계산하기 위해 사용하는 세 가지 계산 방식을 다뤘습니다.

2단계와 3단계(calldata 가스 비용에서 user op가 차지하는 몫과, 실행 가스 오버헤드에서 user op가 차지하는 몫을 계산하는 것) 모두 signature 필드를 포함하여 user operation의 길이와 내용에 직접적으로 의존한다는 점에 주목해야 합니다.

verificationGasLimit

거의 모든 유용한 스마트 컨트랙트 계정 구현은 어떤 형태로든 signature 검증을 필요로 합니다. 이 가스는 추정되어야 합니다! 이 추정 과정은 되돌려지면(revert) 안 되며, 그렇지 않으면 verification gas를 구현할 수 없습니다.

어떤 signature를 사용할지 어떻게 결정할까요?

dummy signature 값을 계산하는 방법

이러한 문제를 해결하기 위해 많은 ERC-4337 bundler는 계정 유형에 따라 eth\_estimateUserOperationGas 호출자가 제공해야 하는 "Dummy Signature"를 사용합니다.

제약 조건

이 dummy signature에는 몇 가지 제약 조건이 있습니다:

1. dummy 값의 길이는 최대 signature 길이와 같아야 하며, 해당 계정에 유효한 최대 개수의 0이 아닌 바이트를 포함해야 합니다. a. 이를 통해 preVerificationGas 계산이 최악의 경우 signature가 calldata 및 entry point 오버헤드 비용에 미치는 기여도를 반영할 수 있습니다.
2. dummy 값은 계정의 검증 함수에 전달되었을 때 최악의 경우의 가스 사용량을 유발해야 하며 revert를 발생시켜서는 안 됩니다.
3. dummy 값은 어떠한 유효한 user operation에 대해서도 유효한 signature가 아니어야 합니다.

SimpleAccount에 대한 dummy signature 값은 eth_estimateUserOperationGas 메서드에 대한 저희 문서에서 확인할 수 있습니다.

이 dummy signature는 다음과 같은 속성을 가집니다:

1. ECDSA signature와 정확히 같은 길이를 가짐
2. ECDSA signature에서 허용되는 최대 개수의 0이 아닌 바이트를 가짐
3. 유효한 ECDSA signature임(따라서 .recover\(\) 호출이 revert되지 않음)
4. 알려진 어떠한 user operation에 대한 signature도 아니므로, SimpleAccount는 항상 SIG\_VALIDATION\_FAILED을 반환함

계정 구현자는 dummy signature를 제공하는 것이 가능하도록 검증 함수를 작성해야 합니다.

이는 다음을 의미합니다:

1. dummy signature가 될 수 없는 signature에 대해서만 REVERT를 사용해야 합니다. dummy signature가 제공되면 SIG\_VALIDATION\_FAILED를 반환해야 합니다.
2. dummy signature에 대해 실패를 "단락(short-circuit)"시키지 않도록 주의해야 합니다. 즉, dummy 값은 검증 함수 전체를 거쳐 실행되어야 하며 최대 가스량을 사용해야 합니다.
3. 실질적으로 이는 조기 반환(early return)을 모두 제거하는 것을 의미합니다. 계정 검증 함수는 signature가 유효하지 않다는 것을 조기에 판단할 수는 있지만, 함수 로직을 끝까지 실행한 후 마지막에 실패를 반환해야 합니다.

dummy paymasterAndData 값을 계산하는 방법

위와 동일한 요구 사항이 가스 추정 중 paymasterAndData 필드에도 적용됩니다: 가스 필드 값에 의존하는(예: signature 계산을 위해) 모든 paymaster 구현에 대해, 저희는 dummy 값을 제공하는 동일한 문제를 해결해야 합니다.

제약 조건

이 dummy paymasterAndData에는 몇 가지 제약 조건이 있습니다:

1. dummy 값의 길이는 최대 paymasterAndData 길이와 같아야 하며, 해당 계정에 유효한 최대 개수의 0이 아닌 바이트를 포함해야 합니다. a. 이를 통해 preVerificationGas 계산이 최악의 경우 paymasterAndData이 calldata 및 entry point 오버헤드 비용에 미치는 기여도를 반영할 수 있습니다.
2. dummy 값은 paymaster의 검증 함수에 전달되었을 때 최악의 경우의 가스 사용량을 유발해야 하며 revert를 발생시켜서는 안 됩니다.
3. dummy 값은 어떠한 유효한 user operation에 대해서도 유효한 paymasterAndData가 아니어야 합니다.

예를 들어, user operation 해시에 대한 sponsorship signature의 검증에 의존하는 sponsoring paymaster는 추정 과정에서 위에서 설명한 것과 유사한 속성을 가진 dummy paymasterAndData 값을 제공해야 합니다:

1. dummy 값은 유효한 paymaster 컨트랙트 주소를 포함해야 합니다
2. preVerificationGas 계산을 위한 최대 길이와 바이트 값
3. paymaster의 검증 함수에 전달되었을 때 최대 가스를 소비하고 SIG\_VALIDATION\_FAILED 반환 값을 결과로 내야 합니다

paymaster 구현자는 dummy paymasterAndData을 제공하는 것이 가능하도록 검증 함수를 작성해야 합니다.

이는 다음을 의미합니다:

1. dummy의 일부가 될 수 없는 데이터에 대해서만 revert을 사용해야 합니다. 대신  SIG\_VALIDATION\_FAILED을 반환해야 합니다.
2. dummy에 대해 실패를 "단락(short-circuit)"시키지 않도록 주의해야 합니다. 즉, dummy는 검증 함수 전체를 거쳐 실행되어야 하며 최대 가스량을 사용해야 합니다. a. 실질적으로 이는 조기 반환을 모두 제거하는 것을 의미합니다. paymaster 검증 함수는 signature가 유효하지 않다는 것을 조기에 판단할 수는 있지만, 함수 로직을 끝까지 실행한 후 마지막에 실패를 반환해야 합니다.

가스 토큰 전송

verificationGasLimit에 대한 추정은 검증 단계 동안 발생하는 토큰 전송의 가스 비용을 고려해야 합니다. 많은 user op는 가스를 선지급하기 위해 검증 중 토큰 전송을 포함하며, 소비되지 않은 가스에 대해서는 operation이 끝날 때 환불이 이루어집니다.

두 가지 경우가 있습니다:

1. Paymaster가 없는 경우 - sender로부터 entry point 컨트랙트로의 ETH 전송입니다.
2. Paymaster가 있는 경우 - 이는(스펙에서 허용하는 규칙 내에서) 무엇이든 될 수 있지만, 주로 sender로부터 paymaster로의 ERC-20 토큰 전송의 형태를 취합니다.

계정에 충분한 자금이 없으면 어떻게 될까?

maxFeePerGas이 0이 아닌 값으로 설정되어 있는 경우, 계정이 수수료를 지불할 만큼 충분한 토큰을 보유하고 있지 않으면 검증 중 전송이 revert됩니다. 이는 사용자가 가스를 추정하기 전에 미리 계정에 자금을 충전해야 함을 의미합니다.

현재는 불가능한, 바람직한 워크플로우:

1. 가스 추정
2. 가스를 위한 계정 충전
3. Operation 전송

여기서 가능한 해결책 중 하나는 eth\_estimateUserOperationGas를 호출할 때 사용자에게 maxFeePerGas을 설정하지 않거나 0으로 설정하도록 안내하는 것입니다. 하지만 이렇게 하면 가스 비용이 0이 되고, 따라서 발생해야 하는 토큰 전송도 0 값이 됩니다. 많은 계정/paymaster 유형에서 가스 비용이 0이면 transfer에 대한 호출이 생략됩니다. 이는 0 값의 maxFeePerGas를 사용할 때 가스 과소 추정으로 이어집니다.

또 다른 문제는 0이 아닌 maxFeePerGas를 사용하면서, 이 시리즈의 1부 "Attempt 3: Binary Search"에서 정의한 이진 탐색 추정 방식을 시도하는 것과 관련이 있습니다.

이 방식의 첫 번째 단계는 최대 가스 값을 사용하여 operation이 가능한지 확인하는 것입니다. sender는 해당 최대 값에 대해 가스를 지불할 만큼 충분한 자산을 갖고 있지 않을 수 있으며, 번들러는 올바른 상한을 결정하기 위해 수수료 토큰(즉, ERC-20 paymaster의 경우)의 잔액을 항상 파악할 수 있는 것은 아닙니다.

Alchemy의 번들러는 토큰 전송이 있는 가스 추정 문제를 어떻게 해결하는가?

eth\_estimateUserOperationGas에 대해 Rundler가 취하는 접근 방식은 다음과 같습니다:

Paymaster가 없는 경우

• Rundler는 항상 maxFeePerGas과 maxPriorityFeePerGas을 무시하고 0으로 설정합니다.
• Rundler는 sender로부터 entry point로의 ETH deposit 전송을 반영하기 위해 항상 verificationGasLimit에 고정된 10K 가스를 추가합니다.
• 클라이언트 측 변경은 필요하지 않습니다.

Paymaster가 있는 경우

• Rundler는 항상 maxFeePerGas과 maxPriorityFeePerGas을 무시하고 0으로 설정합니다.
• paymaster 로직이 수수료 값에 조건부로 의존하는 경우(ERC-20 전송이 그렇듯) Rundler의 verificationGasLimit는 항상 과소 추정됩니다
• 이러한 paymaster의 사용자는 0이 아닌 수수료로 인해 클라이언트 측에서 발생할 추가 가스를 직접 반영해야 합니다.

예를 들어, 검증 단계에서 전송을 수행하는 ERC-20 paymaster를 사용하는 경우, eth\_estimateUserOperationGas의 verificationGasLimit 반환 값에 항상 고정된 75K 가스를 추가해야 합니다. 이를 위해서는 클라이언트가 자신이 호출하는 paymaster 컨트랙트를 인지하고, 전송으로 인해 과소 추정되는 가스 비용에 대해 사전 지식을 가지고 있어야 합니다.

이것이 개발자에게 의미하는 바는 무엇인가?

dummy 값과 토큰 전송 문제는 스마트 컨트랙트 계정, paymaster, 그리고 계정 클라이언트를 구축하는 개발자들에게 영향을 미칩니다.

스마트 컨트랙트 계정 개발자

스마트 컨트랙트 계정 개발자는 계정 검증 함수가 실행되는 방식에 기반하여 dummy signature 값을 항상 클라이언트 측에서 결정할 수 있도록 해야 합니다. 이 signature는 revert를 유발해서는 안 되며 최대 가스 추정치를 결과로 내야 합니다.

Paymaster 개발자

Paymaster 개발자는 paymaster 검증 함수가 실행되는 방식에 기반하여 dummy paymasterAndData 값을 항상 결정할 수 있도록 해야 합니다. 이 값은 revert를 유발해서는 안 되며 최대 가스 추정치를 결과로 내야 합니다.

계정 클라이언트 개발자

검증 단계 중 전송을 수행하는(또는 수수료 값에 기반한 다른 로직을 수행하는) paymaster와 통합하고 Alchemy의 엔드포인트를 가스 추정에 사용하는 계정 클라이언트 개발자는, 전송과 관련된 잠재적인 가스를 추정치가 반환하는 verificationGasLimit에 추가해야 합니다.

ERC-4337 가스 추정의 더 많은 복잡한 문제를 다룰 다음 게시글을 기대해 주세요!

🦀

계속 읽기

이 4부작 시리즈의 다음 글들은 Optimism과 Arbitrum 같은 layer 2 블록체인에서 가스를 추정하는 과제와 signature aggregator를 다룹니다.

이 시리즈는 user operation 수수료 추정 과정에 대한 안내로 마무리됩니다. 1부를 놓치셨다면, ERC-4337 가스 추정이 어떻게 작동하는지 확인해 보세요!

• How ERC-4337 Gas Estimation Works
• L2 Gas and Signature Aggregators
• User Operation Fee Estimation