[Tracking] Async Block-Production and Block-Validation (Excluding Consensus)

[apfitzge]

Problem

There have been long-term efforts towards enabling asynchronous (or semi-asynchrnous) block production and validation.
There are numerous changes required to enable this functionality, but there is currently no issue tracking what needs to be done.
This issue serves to track open tasks/projects in order to enable async or semi-async execution.

A specific note should be made that this is explicitly for block production and validation, and does not consider the consensus changes that are necessary for allowing for block validation to lag significantly behind the head of the chain.
This issue is only concerned with separating the necessity for execution and account-state from block validity.

Proposed Solution

A list of open tasks that are required for "semi" or "fully" asynchronous block production and validation.
Each item links to a proposal or tracking issue.
For items without a proposal or tracking issue, an brief additional description is provided.
Each item should also have a reason indicating why it is necessary for async execution.
This list may be edited to add items if new requirements are identified.

Semi-Asynchronous

Block-validation can be done without executing the transactions in the block. Some loading is still necessary, but all state used to verify the block is available at the start of the block.
In other words, block-validation requires execution of previous blocks but does not require execution of the block being verified.

• SIMD-0082: Relax Transaction Constraints solana-foundation/solana-improvement-documents#82
  • Description: Relax constraint on transaction that require account loading.
  • Reason: Current validation of these constraints requires loading accounts.
• Allow for non-fee paying transactions to be included in blocks.
  • Description: Relax constraint that requires transactions to pay fees. This will allow for transactions to be included in blocks without requiring the fee to be paid. The transaction will not be executed, and potentially punish the leader for including the transaction.
  • Reason: Current validation of this constraint requires loading accounts.
• Nonce Validity Relaxation
  • Description: Relax constraint that requires nonced-transactions to have a valid nonce, allowing us to skip account loading in validation. This will allow for transactions to be included in blocks without requiring the nonce to be valid. The transaction will not be executed, and potentially punish the leader for including the transaction.
  • Reason: Verifying nonce-validity requires loading the nonce account.
• Block-Limit Changes
  • Description: Current block-limits require us to execute transactions to determine the actual number of CUs used. This must change, but no clear consensus on how to do this - currently leading idea is to used the requested CUs.
  • Reason: Requires execution of transactions to determine the actual number of CUs in the block.

Fully-Asynchronous

Block-validation can be done without executing the transactions in the block, additionally it does it require loading any accounts.

• https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0083-relax-entry-constraints.md
  • Description: Relax constraint that requires entries to have non-conflicting transactions.
  • Reason: Current validation of these constraints requires loading accounts for ATLs.
• Address Table Lookup (ATL) Relaxation
  • Description: Relax constraint that requires ATLs to be resolved. This will allow for transactions to be included in blocks without requiring the ATL to be resolved. The transaction will not be executed, and potentially punish the leader for including the transaction.
  • Reason: Resolving ATLs requires loading the ATL account.