In the context of adding support for the --authority mode regarding block creation as mentioned in #188, we need to implement a transaction pool that adheres to the current rules of the mainnet sequencer.
Request
This issue serves as a reference for implementing the transaction pool, which will be used to receive, re-execute, and order incoming transactions via the following methods:
The transaction pool will follow the system outlined below:
Creation of an empty block and start of the block time.
Reception of a transaction via the methods (add_invoke, declare, deploy_account).
Execution of this transaction:
a. Creation of a block context with block information, including fees.
b. Creation of the state adapter to have a snapshot of the chain at the moment of the block with all the methods to access the state for blockification.
c. Creation of a temporary cache from the state adapter.
d. Execution of the transaction with a caching system.
e. Retrieval of the execution trace, creation of the statediff using the cache.
f. Committing the temporary cache to the StateAdapter cache.
Ordering of the executed transactions.
End of block time, creation of the Block Header.
Storage of the block.
Note that during the entire process from block creation to storage, the block must be available in the pending state.
Solution
This is an overview for a primitive implementation of the transaction pool adhering to the current Starknet specifications. Changes may be made as more information about the protocol itself becomes available.
Addionatl UX feature mentioned by @tdelabro: add support for an add_deploy_account transaction if a wallet does an invoke but has not been deployed yet. This is used by argent and braavos on mainnet.
Is there an existing issue?
Motivation
In the context of adding support for the
--authority
mode regarding block creation as mentioned in #188, we need to implement a transaction pool that adheres to the current rules of the mainnet sequencer.Request
This issue serves as a reference for implementing the transaction pool, which will be used to receive, re-execute, and order incoming transactions via the following methods:
starknet_addInvokeTransaction
starknet_addDeclareTransaction
starknet_addDeployAccountTransaction
The transaction pool will follow the system outlined below:
Note that during the entire process from block creation to storage, the block must be available in the pending state.
Solution
This is an overview for a primitive implementation of the transaction pool adhering to the current Starknet specifications. Changes may be made as more information about the protocol itself becomes available.
Are you willing to help with this request?
Yes!