Zk improvements

[dr-orlovsky]

Consider removing bulletproof data from single-use-seal commitments: this will add scalability with aggregation over history + zk upgredabiliy and replacability

Update: during dev call on the 23rd of Sept 2020 it was decided to take the following route:

1. Phase I: use hashing as a strategy for committing to bulletproofs, such as in the future if it will be decided that bulletproof commitments are not required the size of historical data may be reduced from ~500-750 bytes to 32 bytes per bulletproof. Timeline: immediate
2. Phase II: separate individual bulletproofs from Pedersen commitments (alike SegWit) and merkelize bulletproofs inside single state transition independently from Pedersen commitments, such that the total size of commitment-critical data will be further reduced to 32 bytes per transition (independently from the number of bulletproofs inside the transition). Timeline: after completion of initial LN implementation.
3. Phase III: after appropriate consultations with cryptography experts remove bulletproof from commitment data and aggregate them across the whole history. which will allow to:
   • reduce the overall size of bulletproof data for ~10k of historical transitions from ~7.5MB to ~10kB (three orders of magnitude)
   • make it possible to use alternative/more advanced version of range proofs and/or replace rangeproof algorithms without hard forks/asset re-issuance Timeline: RGB v1.0 (~half a year from now)
4. Phase IV: Pedersen commitment cut-through in a Mimble-wimble style (requires separate Merkle tree for Pedersen commitments from phase 2)

[dr-orlovsky]

Update: since we have pedersen commitments, participating in the consensus commit process, commitments to bulletproofs are not required (if your pedersen commitment commits to a negative value, you still will not be able to construct bulletproof passing the validation). Thus, Phase III may be partially implemented instead of Phase II