-
Notifications
You must be signed in to change notification settings - Fork 18
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
feat(iota-genesis-builder): Add native token circulating supply validation #2126
Conversation
Mismatching native tokens in IOTA (from a quite old hornet snapshot)
|
crates/iota-genesis-builder/src/stardust/migration/verification/util.rs
Outdated
Show resolved
Hide resolved
Co-authored-by: Thoralf-M <46689931+Thoralf-M@users.noreply.github.com>
crates/iota-genesis-builder/src/stardust/migration/verification/util.rs
Outdated
Show resolved
Hide resolved
crates/iota-genesis-builder/src/stardust/migration/verification/alias.rs
Outdated
Show resolved
Hide resolved
…tive-tokens-validation
…tive-tokens-validation
Latest mismatching IOTA native tokens:
|
@miker83z I don't quite see how this patch handles #440. With this comment you report the same inconsistencies reported by #440, i.e. 0 total supply for multiple native tokens. |
@kodemartin this PR aims to not modify the migration logic, but just enhance the information that we can extract during the process -> it provides us with real circulating supply of all created tokens. Pls, bear in mind that the native tokens potentially suffering from the issue indicated in #440 are only:
|
Description of change
Based on #440 discussion, some native token supplies in the final ledger state were expected to be broken due to the adaptation of a native token supply value from
u256
tou64
. This because the total supply of a token could be easily calculated (minted - melted tokens) and set in the dedicatedSupply
object of aCoin
. But, instead, each native token coin instance balance is set in a context where the real circulating supply cannot be known a priori and thus can be incorrect (where incorrect means that due to the big difference betweenu256
andu64
and rounding, some balances could not represent the original coin-instance-balance/total-supply ratio equivalently after the adaptation).The analysis in #440 comments shows that all Foundries using a supply greater than u64::MAX were correctly adapted when converted into
Coin
s. This PR provides a way to compute the real circulating supply of all created tokens. It provides a warning during the validation of the created object snapshot, indicating theCoin
s that have a mismatch between real circulating supply and the expected one.The output is shown below in a PR comment.
The results show that adapted Foundries (from
u256
tou64
supply) only differ by an amount of 1 coin (18446744073709551613 instead of 18446744073709551614, which is the expected supply obtained by u64::MAX - 1).There are other native tokens that have a mismatch but were not part of the adaptation process. In this case, I assume that something was done already in Stardust (e.g. burn some tokens without affecting the melting in the Foundry?). E.g., in IOTA
0xabfe2fe5e9f5af219f775abafe2a527a18e50a818c5e0c2af60a747f7a3a8843::spig::SPIG: found 200000000, expected 1000000000
we can se that the address who created this (test?) token owns only an output with an amount of 200000000 SPIG (how can we check if the other 800000000 are still around somewhat?).Links to any relevant issues
Closes #5001.
Type of change
How the change has been tested
cargo run --release --bin iota-genesis-builder -- --disable-global-snapshot-verification iota --snapshot-path ../latest-full_snapshot-iota.bin --target-network alphanetv0.1.1
Change checklist