Batch Calls Encoding (BCE) outlines a solution for Smart Contract Account (SCA) wallets to consolidate multiple calls into a single call, encoding multiple parameters into bytes, compressing on-chain data, and saving gas. It can be used to implement atomic operations as well as non-atomic operations.
Typically, interactions between users and contracts involve a series of coherent operations, such as approve-transferFrom. While EOA wallets require users to confirm each operation sequentially, SCA wallets can confirm all operations with a single confirmation, completing all operations within a single call, thus achieving atomicity. If approve succeeds but transferFrom fails, it poses a security risk. The secure approach is to ensure that if one operation fails, all associated operations also fail, thereby ensuring atomicity. Therefore, we propose this encoding method to encode multiple parameters into bytes, compress on-chain data, and save gas. It can be used to implement both atomic and non-atomic operations.
In addition to the atomic operation of approve-transferFrom mentioned above, gas payment delegation can also be achieved. It involves users and bundlers signing a set of calls, where the content of the calls includes:
The user encodes the content of the calls, attaches their signature to ensure its integrity, and sends it to the bundler. If the bundler considers the gas payment insufficient, they may choose not to submit it. However, if they approve the content of the calls, the signed transaction can be submitted. After execution, the user obtains the desired operations, and the bundler receives the fee.
EIP-4337 also implements gas payment delegation. BCE and EIP-4337 are not mutually exclusive and can be implemented concurrently within an SCA.
Based on empirical testing, BCE is simpler and more gas-efficient compared to alternative methods.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
This ERC REQUIRED SCA to be implemented in the contract, where the Dapp communicates with the SCA wallet extension to communicate the user's intentions to the wallet, which uses Batch Calls Encoding to send multiple calls as bytes to the user's SCA contract.
Batch Calls comprises multiple Call bytes, each defined by the encoding of to`value\data` as follows:
Let:
to: The address of the called contract, corresponding to the Solidity address type, 20 bytes.value: The amount of ETH(in wei) sent to the contract, in wei, corresponding to the Solidity uint type, 32 bytes.data length: The length of the data(in bytes), corresponding to the Solidity uint type, 32 bytes.data: The encoded functionData sent to the contract, corresponding to the Solidity bytes type, with a length defined by data length.Multiple Call units are concatenated to form an Batch Calls sequence.
Each call encapsulates 3 parameters: to`value\data. The conventional approach involves packaging these 3 parameters into a struct and then placing multiple structs into an array. However, using a struct adds overhead as it also packages the types of to\value\data, increasing the size of the encoding. Since to\value\datahave fixed types, this additional encoding can be omitted. In Solidity, reading data frombytes calldata` using slice is a gas-efficient method. Considering these factors, Batch Calls Encoding can compress on-chain data and save gas.
This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole.
This ERC does not change other ERC standards, so there are no backwards compatibility issues for Ethereum applications.
This proposal only specifies the encoding of Batch Calls, while the specific implementation and naming are left to the discretion of the project. Below is an example of an SCA contract utilizing Batch Calls (referred to as atomCallbytes), where the user atomically signs multiple operations, enabling the bundler to pay gas on behalf of the user:
SmartWallet.solBundler.solThis proposal introduces a data encoding scheme aimed at data compression. It solely concerns data compression and does not lead to data loss or concealment of private data.
Copyright and related rights waived via CC0.