-
Notifications
You must be signed in to change notification settings - Fork 120
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
universe: switch to 128-bit limbs for multiverse leaves or switch to top-level counter sum #479
Comments
Going with a mutli-pronged stop gap approach instead. |
3 tasks
github-project-automation
bot
moved this from 🏗 In progress
to ✅ Done
in Taproot-Assets Project Board
Oct 11, 2023
Re-opening as wasn't meant to be closed. |
Relevant to #1059 Unless we decide to go in the big int direction there. Would need to add |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
Today we use 64-bit sum values. Where relevant, we also ensure that we bail out if an overflow happens.
Related to this the multiverse and universe trees. The universe tree for issuance has a sum value that's the sum of all the issued assets for a base universe/asset. This can then be extended to also track all transfers for a given asset, with the sum value now being the total units of the assets that have been exchanged. If we then combine several of those trees into a single tree, we end up with a value that's the total amount of units moved over all assets. This is where we need to address over flow concerns.
One path here would be: for the multiverse and normal universe trees, we just tally a single integer which tracks the number of transition events. This works, but then for cases where you want to keep track of the total supply of a sparse set of assets, you lose the ability to track an aggregated sum. Maybe this is ok though, as we already have the asset group system for this use case.
Assuming we want to enable tracking that aggregate sum value (still an open question), then we can move to a 128-bit integer for the root sum.
A GPT-generated type for this looks something like:
Steps To Completion
64 bit
sum value for this128 bit
sum value. Type parameters will likely be useful here, as then we can retain the same tree, and bind the type at compile time.The text was updated successfully, but these errors were encountered: