State unification with removal of Pedersen commitments and bulletproofs

[dr-orlovsky]

Tracking issue: RGB-WG/rgb#263

The PR demonstrates how to remove bulletproofs and Pedersen commitments in a way that they might be introduced later in a non-breaking way (fast-forward).

As was expected, this is huge. Downstream (in RGB std, interfaces and schemata) there would be even much more changes (interfaces have to be fully refactored; schemata as well, plus all fungible scripts rewritten)... We would also need to rewrite nearly all existing docs.

On the good side this is a significant simplification and reduction of the consensus code, which also makes audit much smaller/easier.

Downstream PRs:

• State unification with removal of Pedersen commitments and bulletproofs rgb-std#279
• State unification with removal of Pedersen commitments and bulletproofs rgb#262
• State unification rgb-interfaces#15
• State unification rgb-schemata#50
• TBD in rgb-tests

[codecov]

Codecov Report

Attention: Patch coverage is 26.66667% with 165 lines in your changes missing coverage. Please review.

Project coverage is 13.1%. Comparing base (5002749) to head (78ee971).
Report is 3 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/operation/assignments.rs	3.3%	59 Missing ⚠️
src/validation/logic.rs	0.0%	41 Missing ⚠️
src/operation/state.rs	69.5%	25 Missing ⚠️
src/operation/operations.rs	0.0%	11 Missing ⚠️
src/vm/op_contract.rs	0.0%	8 Missing ⚠️
src/schema/schema.rs	0.0%	5 Missing ⚠️
src/validation/schema.rs	0.0%	5 Missing ⚠️
src/schema/state.rs	0.0%	4 Missing ⚠️
src/operation/commit.rs	0.0%	3 Missing ⚠️
src/operation/global.rs	25.0%	3 Missing ⚠️
... and 1 more

Additional details and impacted files

@@            Coverage Diff            @@
##           develop    #279     +/-   ##
=========================================
- Coverage     14.2%   13.1%   -1.1%     
=========================================
  Files           29      26      -3     
  Lines         3942    3170    -772     
=========================================
- Hits           558     415    -143     
+ Misses        3384    2755    -629     

Flag	Coverage Δ
rust	13.1% <26.7%> (-1.1%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[St333p]

Would these changes allow for a schema that performs validation on revealed state even after the introduction of pedersen and bulletproof?

[dr-orlovsky]

With this PR there is no more revealed/concealed state. If someone would need it they would have to implement it at the schema level using AluVM as a Turning complete system (so there might be multiple ways of doing it, not just with Pedersen commitments).

But overall idea is that this won't be needed at alll, since the whole history will be zk-STARK-compressed, providing all necessary confidentiality

[crisdut]

might be introduced later in a non-breaking way (fast-forward).

Hi @dr-orlovsky,

Could you explain this statement?

What change did you make that would avoid a future compatibility break?

I assume I tried to find it, but it wasn't very clear.

Thanks.

[dr-orlovsky]

Quite simple: when you have a specific program (like bulletproofa), every change is breaking.

If you have a Turing-complete virtual machine, everything is possible in a non-breaking way.

This PR removes all specifics and leaves RGB with pure Turing completeness.

[crisdut]

If you have a Turing-complete virtual machine, everything is possible in a non-breaking way.

That's make sense.

If we decide to go back with bulletproof, would this be done via the AluVM opcode, for example?

Going further, if we including adding other forms of ZKP that use the Poseidon hash function, would they be via the addition of AluVM OPCODE?

So, from now on, will all our evolution in RGb be at the script level (AluVM)?

[dr-orlovsky]

If we decide to go back with bulletproof, would this be done via the AluVM opcode, for example?

Yes.

Of course you may also implement bulletproofs with just AluVM math functions, but this would be exteremelly slow and huge effort. So yes, all computation-intensive cryptographic functions should be added to AluVM as jets put into an ISA extensions (what you call "add op-codes").

BTW one may also have just Secp256k1 ISA extension and do bulletproofs with them. This won't slow them down (since 99.9% of computing time is taken by EC operations in secp256k1 C lib anyway).

But anyway I think we do not need bulletproofs, which are ultra-slow, and should use zk-STARKs

Going further, if we including adding other forms of ZKP that use the Poseidon hash function, would they be via the addition of AluVM OPCODE?

Yes. The right way to say "they will be added as jets inside a new ISA extension (which will probably include more useful jets)".

So, from now on, will all our evolution in RGb be at the script level (AluVM)?

Not all. For instance, zk-STARK history recursive compression can't be done with it. There are many other things which are not doable at just script level: https://github.com/orgs/RGB-WG/projects/19/views/1

[crisdut]

But anyway I think we do not need bulletproofs, which are ultra-slow, and should use zk-STARKs

Yes, sure. I followed the discussions. I used bulletproof just as an illustration for my doubt.

Yes. The right way to say "they will be added as jets inside a new ISA extension (which will probably include more useful jets)".

Okay, got it.

Not all. For instance, zk-STARK history recursive compression can't be done with it.

This statement is true because this computation produces an output (in this case, the proof), and this operation falls outside the scope of the contract script.

On the other hand, once the proof is generated and stored in the consignment metadata, we could have an ISA extension that performs the proof verification. So, we could create a AluVM script that retrieves the proof from the metadata and executes the verification.

Does this make sense?

There are many other things which are not doable at just script level: https://github.com/orgs/RGB-WG/projects/19/views/1

Thanks for sharing the highlights of the RGB evolution!

[Gigi3d]

this is a great decision and probably the best for RGB from technological, ease of use for crypto natives and regulatory perspectives

[dr-orlovsky]

This statement is true because this computation produces an output (in this case, the proof), and this operation falls outside the scope of the contract script.

On the other hand, once the proof is generated and stored in the consignment metadata, we could have an ISA extension that performs the proof verification. So, we could create a AluVM script that retrieves the proof from the metadata and executes the verification.

Does this make sense?

I am not sure we are talking about the same thing...

What I am saying is that zk-STARKs history compression would require all historical RGB validation to be represented as an operations over finite field objects. Wille elliptic curve operations (used in both Pedersen commitments and bulletproofs) can be represented that way, the representation for Secp256k1 points group operations would take x1000 more complexity that all the rest of the validation, meaning it will make any zk-STARKs on top practically impossible/unusable (for instance proof production time may be days instead of minutes).

I propose the following: https://github.com/orgs/RGB-WG/discussions/265

[crisdut]

I am not sure we are talking about the same thing...

I was thinking it was for another more "naive" reason than what you explained.

That reason you mentioned didn't cross my mind, thanks for clarifying.