-
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
base: main
Are you sure you want to change the base?
Conversation
90b04f6
to
aaeddf4
Compare
Removed from draft for now. Have unit tests, and additional documentation to commit. |
195d65b
to
8d5041c
Compare
In this commit, we add an IsBurn bool to the Leaf struct. This is needed as we'll re-use this Leaf field for the burn proofs. However, for burns we always want to track the actual amt burned.
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.
8d5041c
to
648cb72
Compare
Pull Request Test Coverage Report for Build 14847982056Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed this PR to see how I might copy its state‑machine architecture for the verification work.
I saw your note about still adding unit tests and doc comments, so I'm leaving these review comments with that in mind and hoping they're helpful.
|
||
replace github.com/lightningnetwork/lnd => github.com/roasbeef/lnd v0.2.1-alpha.0.20250505223159-b58451faad16 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small reminder: this will need to be removed before merge. Maybe it can be removed now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that this is used for the state transition scaffolding. Is there an LND PR for this that I could help (review) get merged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// eventSealed is a special method that is used to seal the interface. | ||
func (c *CommitTickEvent) eventSealed() {} | ||
|
||
// UpdatePendingState is the state of the state machine when we have From this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unfinished sentence: when we have From
.
// StateMachine is a state machine that handles creating and updating the | ||
// on-chain universe supply commitment for a given asset. | ||
// | ||
// nolint:lll | ||
type StateMachine = protofsm.StateMachine[Event, *Environment] | ||
|
||
// Config is a configuration struct that is used to initialize a new supply | ||
// commit state machine. | ||
type Config = protofsm.StateMachineCfg[Event, *Environment] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think these are used and they might be the only reason for the lnd
replace in go.mod
. I'm not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the state machine isn't instantiated externally yet, once it is these will be used.
The lnd fork dep is needed to we can access the block block after confirmation, and also pass that into the state machine.
// State transitions: | ||
// - SignTxEvent -> CommitBroadcastState | ||
type CommitTxSignState struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I understand the state transition in the doc comment. Should this be:
// State transitions:
// - SignTxEvent -> CommitTxSignState
// - CommitTxSignState -> BroadcastEvent
Are we describing to and from states in doc State transitions
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is meant to indicate that from this state, we can go to the sign state.
// State transitions: | ||
// - BroadcastEvent -> CommitBroadcastState | ||
// - ConfEvent -> DefaultState | ||
type CommitBroadcastState struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand ConfEvent -> DefaultState
in the doc here.
Once our latest commitment transaction confirms on chain the state machine could transition to DefaultState
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is slightly out of date, a new CommitFinalizeState
state is was transitions us to the default.
Universe server components). | ||
|
||
* Managing commitments for multiple different assets simultaneously (each | ||
asset specifier typically gets its own state machine instance). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
asset specifier
-> asset group
@Roasbeef, remember to re-request review from reviewers when ready |
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.