Access Lists and Gas Savings
Access lists were introduced with EIP-2930 (came online with the Berlin network upgrade on Ethereum at block 12,244,000 on April 15, 2021) in the context of the Ethereum network to optimize the gas usage of transactions, especially when contracts access storage.
Prepayment at Discounted Rates:
By specifying storage slots and addresses upfront in the access list, the EIP-2930 transaction allows you to prepay the "cold access" of these storage slots at a discounted rate. Cold storage access is typically more expensive because the Ethereum Virtual Machine (EVM) has to fetch this data for the first time. By prepaying, you effectively avoid the higher cost associated with on-the-fly fetching during the actual execution.
Optimized Execution:
Since the Ethereum node is made aware of which storage slots will be accessed during the transaction's execution, it can prefetch these values. This prefetching means that during execution, only the "warm fee" is paid, which is typically lower than the cold fee. This optimization reduces the computational overhead, leading to gas savings.
Less Surprise Costs:
One of the challenges with executing smart contracts is unpredicted costs due to storage reads and writes. By specifying an access list, the transaction sender has better predictability over the gas consumption, which can lead to fewer surprise costs.
Application to the DBXen Protocol:
Given that the DBXen Protocol calculates the protocol fee based on the gas consumed for the burn, optimizing the gas usage can directly translate to savings on the protocol fee. By utilizing an access list and pre-specifying the storage keys and addresses that the burn function would interact with, users can:
- Reduce the overall gas used for the transaction.
- Have a more predictable gas estimate for their transaction.
- Potentially pay a lower protocol fee since it's calculated based on gas consumed.
DBXEN Example:
As can be seen in the JSON structure above, it specifies two addresses and their respective storage keys to be accessed during the transaction. As these are the keys relevant to the burn function in the DBXBen Protocol, by including them in an access list, users has achieved further optimization and cost reduction.
I haven't tested this, but adding access keys to DBXEN Ethereum transaction should be as easy as just adding another accessList parameter to your transaction:
# Transaction details
nonce = w3.eth.getTransactionCount(from_address)
gas_price = w3.eth.gasPrice
chain_id = w3.eth.chainId
# Access list
access_list = [
{
"address": "0xf5c80c305803280b587f8cabbccdc4d9bf522abd",
"storageKeys": [
"0x0000000000000000000000000000000000000000000000000000000000000006",
# ... other storage keys for this address
]
},
{
"address": "0x06450dee7fd2fb8e39061434babcfc05599a6fb8",
"storageKeys": [
"0x6bbdb462c01c928cab3f983428335ef08af69ac4d8f9eadb09c31648c796ec2a",
# ... other storage keys for this address
]
}
]
# Create the transaction data
transaction = {
'to': 'TO_ADDRESS',
'value': w3.toWei(0.1, 'ether'),
'gas': ....,
'gasPrice': gas_price,
'nonce': nonce,
'chainId': chain_id,
'accessList': access_list
}
# Sign the transaction
signed_tx = w3.eth.account.signTransaction(transaction, private_key)
This way, the accessList specifies a list of addresses and storage keys and a gas cost is charged, though at a discount relative to the cost of accessing outside the list.
I am unsure of the total discount, but EIP proposes only a 10% initial discount to access lists, so the additional DBXEN discount could be somewhere in this range and combined with max batching transaction could easily become 60% cheaper when compared to a single batch burn without access lists.
Comparison of two methods
EIP-2930 Access Lists
A detailed specification and rationale behind access lists are provided here: https://eips.ethereum.org/EIPS/eip-2930
