Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AA-419: "signature" -> "authorizationData" & "calldata" -> "executionData" #35

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

AA-419: "signature" -> "authorizationData" & "calldata" -> "executionData" #35

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 24 additions & 20 deletions RIPS/rip-7560.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ smart contracts. This, however, is impossible without an addition of Native Acco

A new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction with type AA_TX_TYPE is introduced.
Transactions of this type are referred to as
“AA transactions”. Their payload should be interpreted as:
"AA transactions". Their payload should be interpreted as:

```

Expand All @@ -80,18 +80,18 @@ Transactions of this type are referred to as
sender,
deployer, deployerData,
paymaster, paymasterData,
callData,
executionData,
builderFee,
maxPriorityFeePerGas, maxFeePerGas,
validationGasLimit, paymasterValidationGasLimit, paymasterPostOpGasLimit
callGasLimit,
accessList,
signature
authorizationData
])

```

The base gas cost of this transaction is set to `AA_BASE_GAS_COST` instead of 21000 to reflect the lack of “intrinsic”
The base gas cost of this transaction is set to `AA_BASE_GAS_COST` instead of 21000 to reflect the lack of "intrinsic"
ECDSA signature verification.

### Gas fees are charged directly from the contract balance
Expand Down Expand Up @@ -123,8 +123,8 @@ The meanings of the `maxPriorityFeePerGas` and `maxFeePerGas` are unchanged from
For all the existing transaction types, G_txdatazero (4 gas) and G_txdatanonzero (16 gas) per byte is
charged for the `data` parameter.

Transaction Type AA_TX_TYPE introduces the following dynamic length inputs: `callData`, `paymasterData`,
`deployerData`, `signature`. Each of these parameters' gas cost is counted towards transaction data cost.
Transaction Type AA_TX_TYPE introduces the following dynamic length inputs: `executionData`, `paymasterData`,
`deployerData`, `authorizationData`. Each of these parameters' gas cost is counted towards transaction data cost.
This transaction data gas cost is referred to as `calldataGasUsed` and is subtracted from the `validationGasLimit`
before execution of the transaction.
The transaction is considered INVALID if `validationGasLimit` is smaller than `calldataGasUsed`.
Expand Down Expand Up @@ -212,8 +212,8 @@ struct TransactionType4 {
uint256 callGasLimit;
bytes deployerData;
bytes paymasterData;
bytes callData;
bytes signature;
bytes executionData;
bytes authorizationData;
}

```
Expand All @@ -228,7 +228,8 @@ function validateTransaction(uint256 version, bytes32 txHash, bytes transaction)

The gas limit of this frame is set to `validationGasLimit - senderCreationGasUsed - calldataGasUsed`.\
The `transaction` parameter is interpreted as an ABI encoding of `TransactionType4`.\
The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section
The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty `authorizationData`,
as defined in section
[Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash).\
The `version` parameter is added in order to maintain the Solidity method ID in case of changes to this struct
in future revisions of this EIP.
Expand All @@ -248,7 +249,8 @@ function sigFailAccount(uint256 validAfter, uint256 validUntil);
Calls to the `AA_ENTRY_POINT` approval callbacks have the following meaning:

- `acceptAccount` - This callback is called by the account after it verified the transaction and agreed to pay for its execution.
- `sigFailAccount` - This callback is called by the account if the transaction is syntactically valid, but the signature is incorrect.
- `sigFailAccount` - This callback is called by the account if the transaction is syntactically valid,
but the `authorizationData` is incorrect.\
Note that this callback is used during gas estimation and does **not** indicate a valid transaction.

The parameters passed to the callback functions have the following meaning:
Expand Down Expand Up @@ -277,7 +279,8 @@ The amount of gas used by this frame is referred to as `paymasterValidationGasUs

- The `version` parameter is `VERSION`
- The `transaction` parameter is interpreted as an ABI encoding of `TransactionType4`.\
- The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section
- The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty `authorizationData`,
as defined in section
[Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash).


Expand All @@ -294,7 +297,8 @@ function sigFailPaymaster(uint256 validAfter, uint256 validUntil, bytes context)
Calls to the `AA_ENTRY_POINT` approval callbacks have the following meaning:

- `acceptPaymaster` - This callback is called by the paymaster after it verified the transaction and agrees to pay for its execution.
- `sigFailPaymaster` - This callback is called by the paymaster if its paymasterData is expected to contain a signature, but its signer is incorrect.
- `sigFailPaymaster` - This callback is called by the paymaster if its `paymasterData` is expected to contain
some kind of signature, but it does not contain a valid one.\
Note that this callback is used during gas estimation and does **not** indicate a valid transaction.

The parameters passed to the callback functions have the following meaning:
Expand All @@ -313,7 +317,7 @@ and the transaction is rejected and not included on-chain.

#### Sender execution frame

The `sender` address is invoked with `callData` input.
The `sender` address is invoked with `executionData` input.

The gas limit of this frame is set to `callGasLimit`.\
Calculation of the `calldataGasUsed` value is defined in the
Expand Down Expand Up @@ -381,7 +385,7 @@ func validateAccountAbstractionTransaction(tx *Transaction) {
assert callbackParamsSender != nil
assert Date.now() <= callbackParamsSender.validUntil
assert Date.now() >= callbackParamsSender.validAfter
assert callbackParamsSender.isValidSignature
assert callbackParamsSender.isValidAuthorizationData

if (paymaster != address(0)) {
paymasterInput := ABI.encodeWithSelector('validatePaymasterTransaction', tx, tx.hash)
Expand All @@ -394,7 +398,7 @@ func validateAccountAbstractionTransaction(tx *Transaction) {
assert callbackParamsPaymaster != nil
assert Date.now() <= callbackParamsPaymaster.validUntil
assert Date.now() >= callbackParamsPaymaster.validAfter
assert callbackParamsPaymaster.isValidSignature
assert callbackParamsPaymaster.isValidAuthorizationData
}
}

Expand Down Expand Up @@ -445,7 +449,7 @@ Note that the `chainId` and `accessList` parameters are included in the transact
available on-chain as part of the `TransactionType4` struct.

In order to calculate the transaction hash that will be used during the signing of the transaction and validation of
the transaction signature by the `sender`, the value of the `signature` parameter is considered to be an empty
the transaction signature by the `sender`, the value of the `authorizationData` parameter is considered to be an empty
byte array.

## Rationale
Expand Down Expand Up @@ -475,14 +479,14 @@ RIP-7560 transaction validation, which may lead to this contract being drained.

To do so we require specific call to the `AA_ENTRY_POINT` address to indicate RIP-7560 transaction acceptance.

### The Usage of `sigFailAccount` and `sigFailPaymaster` for signature failure
### The Usage of `sigFailAccount` and `sigFailPaymaster` for `authorizationData` check failure

This callback is called by an account or a paymaster during their respective validation frames if they can verify
all relevant details of the transaction except for the transaction signature.
all relevant details of the transaction except for the transaction `authorizationData`.

This callback is used during gas estimation, and it helps wallet and apps to determine the gas used by the validation
process before generating any real signatures.
The transaction is expected to consume the same amount of gas when updated with a valid signature.
process before generating any real signatures.\
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "" not needed

The transaction is expected to consume the same amount of gas when updated with a valid `authorizationData`.

## Backwards Compatibility

Expand Down