Skip to content

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
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

Roasbeef
Copy link
Member

@Roasbeef Roasbeef commented Apr 9, 2025

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.

@levmi levmi moved this from 🆕 New to 🏗 In progress in Taproot-Assets Project Board Apr 10, 2025
@Roasbeef Roasbeef force-pushed the asset-commitment-creator branch 2 times, most recently from 90b04f6 to aaeddf4 Compare May 3, 2025 02:18
@Roasbeef Roasbeef changed the base branch from burn-tree to main May 3, 2025 02:18
@Roasbeef Roasbeef marked this pull request as ready for review May 3, 2025 02:18
@Roasbeef
Copy link
Member Author

Roasbeef commented May 3, 2025

Removed from draft for now. Have unit tests, and additional documentation to commit.

@Roasbeef Roasbeef changed the title Asset commitment creator universe/supplycommit: create new state machine responsible for maintaining the supply commitment for an aseset May 3, 2025
@Roasbeef Roasbeef changed the title universe/supplycommit: create new state machine responsible for maintaining the supply commitment for an aseset universe/supplycommit: create new state machine responsible for maintaining the supply commitment for an asset May 3, 2025
@Roasbeef Roasbeef force-pushed the asset-commitment-creator branch from 195d65b to 8d5041c Compare May 5, 2025 22:45
Roasbeef added 9 commits May 5, 2025 15:54
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.
@Roasbeef Roasbeef force-pushed the asset-commitment-creator branch from 8d5041c to 648cb72 Compare May 5, 2025 23:02
@coveralls
Copy link

Pull Request Test Coverage Report for Build 14847982056

Details

  • 1 of 789 (0.13%) changed or added relevant lines in 6 files are covered.
  • 22 unchanged lines in 7 files lost coverage.
  • Overall coverage decreased (-0.4%) to 36.563%

Changes Missing Coverage Covered Lines Changed/Added Lines %
universe/interface.go 0 5 0.0%
universe/ignore_records.go 0 11 0.0%
universe/supplycommit/env.go 0 77 0.0%
universe/supplycommit/supply_commit_states.go 0 139 0.0%
universe/supplycommit/supply_commit_transitions.go 0 556 0.0%
Files with Coverage Reduction New Missed Lines %
address/address.go 2 67.47%
tapgarden/planter.go 2 60.85%
asset/asset.go 3 46.84%
tapchannel/aux_leaf_signer.go 3 43.43%
asset/mock.go 4 64.71%
commitment/tap.go 4 71.59%
tapgarden/caretaker.go 4 68.68%
Totals Coverage Status
Change from base Build 14790497726: -0.4%
Covered Lines: 26474
Relevant Lines: 72406

💛 - Coveralls

@levmi levmi moved this from 🏗 In progress to 👀 In review in Taproot-Assets Project Board May 8, 2025
Copy link
Contributor

@ffranr ffranr left a 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.

Comment on lines +219 to +220

replace github.com/lightningnetwork/lnd => github.com/roasbeef/lnd v0.2.1-alpha.0.20250505223159-b58451faad16
Copy link
Contributor

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?

Copy link
Contributor

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?

Copy link
Member Author

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
Copy link
Contributor

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.

Comment on lines +65 to +73
// 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]
Copy link
Contributor

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.

Copy link
Member Author

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.

Comment on lines +404 to +406
// State transitions:
// - SignTxEvent -> CommitBroadcastState
type CommitTxSignState struct {
Copy link
Contributor

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?

Copy link
Member Author

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.

Comment on lines +461 to +464
// State transitions:
// - BroadcastEvent -> CommitBroadcastState
// - ConfEvent -> DefaultState
type CommitBroadcastState struct {
Copy link
Contributor

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?

Copy link
Member Author

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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

asset specifier -> asset group

@guggero guggero self-requested a review May 28, 2025 06:57
@lightninglabs-deploy
Copy link

@Roasbeef, remember to re-request review from reviewers when ready

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

Successfully merging this pull request may close these issues.

4 participants