-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
Add new operators to avoid pedersen commitments in amount validation #276
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #276 +/- ##
========================================
- Coverage 13.2% 13.0% -0.2%
========================================
Files 29 29
Lines 3883 3932 +49
========================================
Hits 513 513
- Misses 3370 3419 +49
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Well, I don't think this is going to work in the real-world cases: once we add bulletproofs and just a single user apply them, he will lose all his assets. This is a footgun. That's why I was saying it is not that easy: to do a proper support for non-pedersen fungible state you need to introduce a completely new type of fungible state into Core, re-write state management in RGB Std and re-write the whole body of RGB20 interfaces |
Why would a user apply bulletproof to an asset using a schema that cannot support bulletproof? He would need a wallet that supports this. If we are concerned about evil/stupid wallet developers implementing buttons in the UI that lead to the destruction of the user's assets there are already plenty of simpler ways to do it. |
This PR doesn't introduce such schema, so there is no such thing as a "schema that does not support bulletproof" |
But it introduces new AluVM operators that would make it possible for schema developers to create such schemas, i.e. schemas that don't rely on pedersen commitment to verify that the sum of inputs equals the sum of outputs and as a consequence would not be able to support bulletproof whenever it becomes available. |
Yes, and this converts additions of bulletproofs in the future from fast-forward into a consensus-breaking push-back. Basically, we would be able to add bullteproofs with this only with a new RGB v2, backward-incompatible to RGBv1 |
I honestly don't understand how this bulletproof addition will work then. Is it an RGB-wide update that applies to all schemas regardless if they need it or not? What about existing schemas (like UDA) that have no pedersen commitments in validation, will all holders lose those assets when we'll add bulletproofs? I also tried creating a new NIA-like schema with these new operators and everything seems to work correctly, so I'd say the one issue we should address is how to selectively apply the bulletproof update only to schemas that require it. This would allow both UDA and a new schema using the operators from this PR to be unaffected by a bulletproof addition. |
Please forget about schemas in context of bulletproofs; they are unrelated! Bulletproofs apply at the level of RGB basic data structures, much before any schema do exist. Also, UDA has nothing to do with bulletproofs - this is a specific schema, existing outside of
Yes, as I said it will work until we activate bulletproofs :) Thus, with this PR we would either be unable to ever activate them - or their activation would mean loss of the assets using scripts with the opcodes introduced in this PRs (or there would be two RGB versions, incompatible with each other).
Not just bulletproof: if you add something to RGB (or any client-side validation) which was valid before, but becomes invalid later, than this is called a push-back, which means loss of assets affected by those features - or a protocol split into two incompatible versions. If you introduce opcodes from this PR, they will be working only when fungible state is not stored as Pedersen commitments (i.e. bulletproofs are not active). Once they are active, the state got concealed and this opcodes will fail for the users - meaning a push-back ("something was valid, becomes invalid"). The only right way to allow non-Pedersen fungible state is to add a new data type to |
This is how the removal of bulleptroofs means: #279 |
I brought up UDA just an example of a usecase that requires some state that should not be concealed. For instance, RGB21 supports fractioning non-fungible assets, which seems to require some sort of fungible-like state. Would that be concealed in a future bulletproof update as well?
There is a need for schemas that only work with revealed state regardless of any future updates enabling concealed fungible state. At the very least, it would be pretty weird if a system that "was designed to allow everything that is possible with blockchain-based smart contracts" could not support simple fungible assets without computationally intensive privacy features. |
With this PR is no more concealements of the state at the consensus level, as well as no more difference between fungible and non1fungible state. It all becomes implementation detail up to specific schemata. They way it would work will depend on how you will write the schemata logic; it is Turing-complete and you can do whatever you like.
See the answer in previous paragraph.
The design goal for RGB was always agreed between all stakeholders as "we need system where privacy is non-optional, even at the cost of poor UX". But now, taking into account the combination of the following facts
we have no other reasonable option than to remove Pedersen commitments and state concealment altogether, which will not make privacy worse and will fix the UX. This PR does exactly that. |
Validation for NIA contracts currently involves pedersen commitments to verify that the sum of inputs equals the sum of outputs. Since bulletproofs are still not an option, amounts are included in clear within the consignment. Hence, given pedersen commitments are constructed by the receiver during validation, this currently brings no advantages over a simple sum verification, but we still want to keep them so that bulletproof can be added in a backwards compatible update.
This PR introduces 3 new AluVM operators that behave like their pedersen commitment counterparts but only do simple sums. This should bring the following advantages:
secp256k1-zkp
in case we put pedersen commitment operations behind a feature flagThe new operators can be used by schema developers to create schemas corresponding to NIA and CFA that only work with revealed state.