|
1 | 1 | --- |
2 | 2 | sidebar_position: 3 |
3 | 3 | --- |
| 4 | + |
4 | 5 | # Back To Genesis Issue(B2G) |
| 6 | + |
| 7 | +Introduction to what the Token tracing issue is and why tracing is needed. |
| 8 | + |
| 9 | +In UTXO-type contracts, it is necessary to maintain contract states. These contract states need to be implemented |
| 10 | +through tracing, requiring validation from the current state all the way back to the genesis state. This process can |
| 11 | +potentially lead to infinite state expansion. |
| 12 | + |
| 13 | +Let’s take a practical example: |
| 14 | + |
| 15 | +FT, or Fungible Token contract, is a standard token contract. Unlike Ethereum’s global contract ledger state, in MVC, |
| 16 | +its contract state is composed of individual UTXOs. The state of these FT UTXOs includes multiple pieces of information |
| 17 | +such as token code, creation information, token quantity, ownership, etc. The contract needs to allow those with FT |
| 18 | +ownership to unlock it, while those without control (private key) cannot unlock and transfer FT. The issue of control is |
| 19 | +easily solved by requiring the state transition function in the contract to carry the owner’s signature and only |
| 20 | +allowing ownership transfer if the signature is correct. |
| 21 | + |
| 22 | +However, there is another problem that cannot be solved merely through ownership verification, and that is the issue of |
| 23 | +token authenticity. Since UTXO itself is stateless, it cannot perceive information outside of itself unless external |
| 24 | +information is passed as a parameter to the function. Additionally, because the code and state data of the UTXO function |
| 25 | +are publicly available on the chain, anyone can forge an identical UTXO. This UTXO's state and code are correct, but it |
| 26 | +is not a genuine FT UTXO. If such behavior is allowed, it would mean FT could be arbitrarily over-issued, causing |
| 27 | +significant losses to the issuer and holders. |
| 28 | + |
| 29 | +In UTXO contracts, this issue can theoretically be solved. When writing the FT contract, we can forcibly require the |
| 30 | +parameters to carry all ancestor transaction information of the current FT (whether recursively or through loops) and |
| 31 | +then verify the legality of the ancestor transactions one by one, tracing back to the original transaction. Only those |
| 32 | +that can fully form a traceability evidence chain are considered legitimate transactions. The forged transaction |
| 33 | +mentioned earlier cannot construct such a traceability evidence chain. |
| 34 | + |
| 35 | +As we can see, with the accumulation of transfers or transactions of the FT contract, the data required for verifying |
| 36 | +the ancestor information increases, causing the data needed for unlocking the state to grow larger and larger. This |
| 37 | +process can lead to infinite state expansion, a very serious problem in UTXO contracts, severely affecting token |
| 38 | +usability. |
| 39 | + |
| 40 | + |
| 41 | + |
| 42 | +In some competing chain solutions, token correctness is generally resolved in two ways: one is through indexer |
| 43 | +consensus, establishing an indexer mechanism outside the UTXO state on layer one, where the indexer is responsible for |
| 44 | +verifying UTXO legitimacy. This is a layer two solution. The biggest drawback of the layer two solution is its inability |
| 45 | +to ensure consistency with the main chain. For example, BRC20 relies on the indexer, and you can mistakenly spend BRC20 |
| 46 | +tokens as ordinary satoshis. Additionally, there are scenarios where contracts unlockable on layer one are not valid on |
| 47 | +the indexer, meaning consensus is guaranteed not just by layer one but by both layer one and the indexer together, |
| 48 | +greatly increasing the likelihood of bugs and issues. Another solution is using oracles, which rely on external trusted |
| 49 | +data sources to ensure token correctness. However, the problem with oracles is their dependence on external data |
| 50 | +sources, and if these external sources fail, the token correctness is also affected (oracle malfeasance issue). |
| 51 | + |
| 52 | +MVC uses a technology called [MetaTxid](meta-txid.md) that can achieve traceability of pure layer one contracts without |
| 53 | +causing transaction expansion, no longer relying on external indexers and oracles to maintain state correctness. |
| 54 | +Instead, it uses only the UTXO itself and some previous transactions to identify token legitimacy. In other words, the |
| 55 | +information to determine whether the token is legitimate is already entirely contained within the contract, without |
| 56 | +needing external blockchain state for auxiliary judgment (this is an important feature of layer one). |
0 commit comments