Account Abstraction on BSC

1

Account Abstraction on BSC

Hello everyone! I lead a team here at BNB labs working on the core infrastructure. We have been tasked with ensuring that Account Abstraction bundlers work with the BSC node. We have been addressing compatibility with the current ETH-Infinitism and StackUp bundlers coupled with a BSC node. During our investigations we have determined that the current suite of Account Abstraction bundler implementations have been designed to work with EVM chains that have both the London and Berlin upgrades completed.

With that knowledge, we need to ensure that any of the EIPs that we decide to enable on BSC to support Account Abstraction is in line with community expectations. We have determined that we need to tweak some of the EIPs to ensure that there aren’t drastic changes to expected gas fees, rewards accrued by validators, and expected user experience.

We intend to enable the Berlin and London upgrades sequentially in the coming months first on testnet, and finally on mainnet. The following upgrades have been enabled on a development branch that we are currently testing locally. After that it’s regression testing, and if there are no issues, a release to the public testnet. All the original EIPs that we intend to use are linked, along with their associated BEP, as well as a high level description of the EIP and changes that we consider necessary to maintain the expected user experience of BSC.

Berlin Upgrade

EIP-2565: Modexp Gas Cost [EIP, BEP]

To accurately reflect the real world operational cost of the ModExp precompile, this EIP specifies an algorithm for calculating the gas cost. This algorithm approximates the multiplication complexity cost and multiplies that by an approximation of the iterations required to execute the exponentiation.

This change will be integrated into BSC unchanged. The gas cost for the ModExp precompile will be reduced.

EIP-2718: Typed Transaction Envelope [EIP, BEP]

TransactionType || TransactionPayload is a valid transaction and TransactionType || ReceiptPayload is a valid transaction receipt where TransactionType identifies the format of the transaction and *Payload is the transaction/receipt contents, which are defined in future EIPs.

This change will be integrated into BSC unchanged. We intend to support all future transaction types as well.

EIP-2929: Gas cost increases for state access opcodes [EIP, BEP]

Increase the gas cost of SLOAD (0x54) to 2100, and the *CALL opcode family (0xf1, f2, f4, fA), BALANCE 0x31 and the EXT* opcode family (0x3b, 0x3c, 0x3f) to 2600. Exempts (i) precompiles, and (ii) addresses and storage slots that have already been accessed in the same transaction, which get a decreased gas cost. Additionally reforms SSTORE metering and SELFDESTRUCT to ensure “de-facto storage loads” inherent in those opcodes are priced correctly.

This change will be integrated into BSC unchanged. Gas costs for certain opcodes will increase. Since this change was implemented into Ethereum on April 15, 2021 we have not observed many complaints from the community regarding this change, and other EVM chains have already implemented this.

EIP-2930: Optional access lists [EIP, BEP]

We introduce a new EIP-2718 transaction type, with the format 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS]).

The accessList specifies a list of addresses and storage keys; these addresses and storage keys are added into the accessed_addresses and accessed_storage_keys global sets (introduced in EIP-2929). A gas cost is charged, though at a discount relative to the cost of accessing outside the list.

This upgrade will be integrated into BSC unchanged. We want to support access lists in BSC, as well as EIPs in the London upgrade require this to be enabled to function correctly.

London Upgrade

EIP-3529: Reduction in refunds [EIP, BEP]

Remove gas refunds for SELFDESTRUCT, and reduce gas refunds for SSTORE to a lower level where the refunds are still substantial, but they are no longer high enough for current “exploits” of the refund mechanism to be viable.

This change will be integrated into BSC unchanged. We have a BEP proposal as well that enables this upgrade on BSC, which tackles an issue that was created on the BEPs repository.

EIP-1559: Fee market change for ETH 1.0 chain [EIP, BEP]

We introduce a new EIP-2718 transaction type, with the format 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]).

There is a base fee per gas in protocol, which can move up or down each block according to a formula which is a function of gas used in parent block and gas target (block gas limit divided by elasticity multiplier) of parent block. The algorithm results in the base fee per gas increasing when blocks are above the gas target, and decreasing when blocks are below the gas target. The base fee per gas is burned. Transactions specify the maximum fee per gas they are willing to give to miners to incentivize them to include their transaction (aka: priority fee). Transactions also specify the maximum fee per gas they are willing to pay total (aka: max fee), which covers both the priority fee and the block’s network fee per gas (aka: base fee). The transaction will always pay the base fee per gas of the block it was included in, and they will pay the priority fee per gas set in the transaction, as long as the combined amount of the two fees doesn’t exceed the transaction’s maximum fee per gas.

This change will be integrated into BSC with a few key changes. Since BSC already has a burning mechanism in place, we have decided not to follow the EIP and pin the base fee to 0. This means that the gas fee market will not burn any utility tokens for transactions that have been included in a block. This essentially means that the fee structure is essentially unchanged, since the base fee does not dynamically expand or contract, which is the current expected behaviour. Transactions are now expected to include the same transaction payload used by other EVM chains that have EIP-1559 enabled.

Based on our investigations with the current suite of Account Abstraction bundlers, we were not able to successfully get bundlers to submit user op bundles through to the BSC node until EIP-1559 was enabled along with its prerequisite EIPs.

EIP-3198: BASEFEE opcode [EIP]

Add a BASEFEE (0x48) that returns the value of the base fee of the current block it is executing in.

This upgrade will be integrated into BSC unchanged. This change is related to EIP-1559 in that this opcode is supposed to return the base fee of the current block. Given that we have decided to pin the base fee to 0, this should return 0 for any invocations of this operation. We are also including it so that smart contracts that use this operation do not have to be rewritten to be deployed on BSC.

Supplemental

Active Pull Requests

Account Abstraction Bundlers

Account Abstraction Resources