codecov[bot]
commented
7 months ago Codecov Report
Attention: Patch coverage is 0% with 51 lines in your changes are missing coverage. Please review.
Project coverage is 15.4%. Comparing base (
fc36c39) to head (4c2ba39).
| Files | Patch % | Lines |
|---|---|---|
| src/contract/assignments.rs | 0.0% | 39 Missing :warning: |
| src/contract/commit.rs | 0.0% | 10 Missing :warning: |
| src/lib.rs | 0.0% | 1 Missing :warning: |
| src/schema/schema.rs | 0.0% | 1 Missing :warning: |
Additional details and impacted files
```diff @@ Coverage Diff @@ ## master #213 +/- ## ======================================== - Coverage 15.5% 15.4% -0.1% ======================================== Files 33 33 Lines 4164 4196 +32 ======================================== Hits 645 645 - Misses 3519 3551 +32 ``` | [Flag](https://app.codecov.io/gh/RGB-WG/rgb-core/pull/213/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RGB-WG) | Coverage Δ | | |---|---|---| | [rust](https://app.codecov.io/gh/RGB-WG/rgb-core/pull/213/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RGB-WG) | `15.4% <0.0%> (-0.1%)` | :arrow_down: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RGB-WG#carryforward-flags-in-the-pull-request-comment) to find out more.:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Doing inter-contract interactions is simple. Doing them right - really hard.
Yes, we can add op-codes observing state of other contracts - but this is “simple” way. Why it is not the right one? Since this mingles contracts together: we would need to forward all the history for interacting contracts in each consignment, quite quickly getting back to the square 1: converting the history into an Ethereum-sized blockchain, just not pre-validated and instead transferred & validated at its whole on every and each transaction. This would scale even worse than any blockchain!
So what is the right and hard way? ZK proofs: one contract has to be able to prove its state to another one in a compact form. Thus, to unlock this in the future, I have added a witness to the operations, which will be a storage for such proofs.
But this is not enough: one contract must be able to lock some of its state (like tokens) to the conditions defined by another contract. This is the hardest part in the client-side validation. How we can do that? There is two ways: Lightning-based, requiring multi-peer channels (and here last year proposal called Nucleon comes handy), and onchain, which I believe is possible, but I do not have a design for it yet.
The problem we need to solve here is “what the transaction UTXO for a single-use seal, locking state of one contract to another, should have as a spending condition”? Bitcoin UTXO can’t verify RGB contract conditions! Thus, it should be either a lightning multisig, onchain “anyone-can-spend” - or onchain ZKP, if we would have them one day in Bitcoin. The first leads us to “all parties of a contract must be in the same Lightning channel”, which is Nucleon is about; the second - to “what if a UTXO is spent without fullfilling RGB requirements”, leading to a need in some new form of single-use-seals for this case (like I have in Prime bitcoin anchoring mechanism); the third - to “we can’t do this without softfork, and we do not know when and wether it would happen at all”.
So, as of today, there is no way how we can make RGB contracts interacting in v0.11 - all three alternative would require a lot of design and development (LNP with multipeer channels in the first, new single-use seal primitives in the second, Bitcoin softfork in the third).
Anyway, all of this options require the same thing in RGB: ability for an assingment to hold lock conditions - and ability for an input to provide a witness satisfying them. We already have a witnesses from the first story above, but we didn’t had ability for the locks. Thus, I have reserved lock field in assignments - and space for custom scripts in the operations.
In such way when we will have a working ZKP+second problem solution, we will be able to introduce inter-contract operations into RGB in a non-breaking way (as a fast-forward and not a pushback).