Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

End of Block Inherents (to tip block authors) #108

Open
JoshOrndorff opened this issue Oct 3, 2023 · 0 comments
Open

End of Block Inherents (to tip block authors) #108

JoshOrndorff opened this issue Oct 3, 2023 · 0 comments

Comments

@JoshOrndorff
Copy link
Contributor

Many UTXO chains, going all the way back to Bitcoin itself, give the block author a tip that includes the imbalanced amounts from all other transaction in that block.

Tuxedo and it's money piece have not done this yet because of two difficulties.

  1. Tracking a cumulative imbalance throughout the block is a challenge without storage items. Putting the sum in a UTXO is a no-go because users would need to include the imbalance output of the immediately previous transaction as an input. This would destroy the tx pool and fee market. We've solved this problem in Accumulators for intra-block book-keeping #105

  2. The second problem is creating the reward UTXO in a real transaction with a real output. It would be reasonably simple to add a reward UTXO to state at the close of a block, but it is important to also have that UTXO in a block body. All other UTXOs are in the block body, and wallets indexers etc rely on this to understand the state of the chain.

This issue is to create a custom block authorship worker, and probably a custom block builder trait. We will not need huge changes to the default Substrate infrastructure here, we just need a way to call into the runtime at the end of the block and get any end-of-block extrinsics just like the default does for beginning of block extrinsics.

Side quest: While we are making a custom block builder trait, we may choose to pass in the previous block in a more obvious way than the inherent data approach introduced in #100.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant