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
blockchain: scalable state proposal #249
Comments
Just to clarify, each core node will track:
Maybe a nit, but it seems like it might be easier to have UTXOs committed to the UTreeXO struct every |
Only nonce-minting utxos have to sit in the maturity buffer to prevent their spending until 48h in the future. This has nothing to do with remembering N most recent utxos (per each node's RAM availability) which helps avoiding transmitting the utreexo proofs. Separate topic, whether utreexo has to be recomputed every M blocks (or every M utxos), or on every block. This may help with performance:
Problems with this choice:
|
On representation of minted utxos:
|
Update: Instead of special-cased nits, we can have a rule that initial block is tied to a utxo set that's pre-defined (which means the utxo set is height=0, and initial block has height=1). Initial UTXO set then can define something like nits, or any arbitrary asset possibly representing a "share in the network" or whatever. |
This removes nonces from the design. This dramatically simplifies blockchain state and validation rules: every tx must spend an input to be unique. Initial anchoring can be provided in a number of ways: pegged assets from a parent chain, and/or minted synthetic nonce-units at each block, etc. See #230 and #249 for details. To bootstrap anchoring, the initial block can start with an initial UTXO set (this API is necessary to have until we have minteable nonce-units (if at all), and even then it may be useful in its own right). UTXO set commitment is changed to a normal merkle tree (instead of radix/patricia trie), in order to support utreexo (see #258). The state machine spec is still assuming presence of the entire set, this will be updated later. Closes #262. Closes #263.
Nonce units are being developed here: #317 |
Per discussion in #230, here's a concrete proposal for addressing scalability of the blockchain state:
nonce
can be removed.The text was updated successfully, but these errors were encountered: