-
Notifications
You must be signed in to change notification settings - Fork 131
universe/supplycommit: create new state machine responsible for maintaining the supply commitment for an asset #1464
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
Open
Roasbeef
wants to merge
8
commits into
lightninglabs:main
Choose a base branch
from
Roasbeef:asset-commitment-creator
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8615e44
to
90b04f6
Compare
This makes the generator more consistent and useful.
…achine In this commit, we add the initial set of states for the SupplyCommit state machine. This will be the primary state machine that'll be used to stage, then apply updates to the root supply tree as well as the sub supply trees associated with the root tree.
In this commit, we populate the environment that the state machine will use. This includes the set of fundamental interfaces (related to persistence and the new supply trees).
…state machine In this commit, we build on the two prior commits and add defined state transitions for the supply commit state machine. We start in a default state, until we hear about a new update. We'll continue in that state untli we get a commit tick, at which point we'll enter the main logic of the state machine. After a tick, we'll construct the final tree, make a commit transaction from that, sign it, then write everything to disk. We'll then resume by broadcasting the commit tx. Once we reecive a confirmation, we'll apply the state tranition which will update all the relevant state on disk.
These were from a much earlier draft, well before the current design of the commit state machine.
90b04f6
to
aaeddf4
Compare
Removed from draft for now. Have unit tests, and additional documentation to commit. |
This was referenced May 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this commit, we add a new sub-package to the
universe
package which adds a new state machine responsible for managing the supply commitment for a given grouped asset.A supply commitment is a special MS-SMT tree that tracks the total supply of a grouped asset. A supply can be modified by: minting new assets, doing an official burn of some assets, or adding some assets to the ignore proof cache.
To create a supply commitment (for an asset that opts into this), we'll spend the pre-commitment from all past minting batches that have been confirmed on chain. We'll then stage all the pending updates, to create new sub-trees (ignore, burn mint) for the grouped asset. With those trees created, we'll create the new root supply commitment.
With the root supply commitment created, we'll make a new transaction and commit to that using the non spendable script leaf that we use elsewhere to commit to asset IDs for a group key.
During this process, we'll continue to serve the old supply commitments. Only once the supply commitments have been confirmed on disk will we apply all the state transitions on disk. After we apply these state transitions, we'll start to serve the new commitments, and go back to our default state.
See the last commit's readme for more details.