Git-Mirrors/monero-ccs-proposals
1
0
Fork 0
mirror of https://repo.getmonero.org/monero-project/ccs-proposals.git synced 2025-12-10 22:25:50 -05:00
Code Issues Projects Releases Packages Wiki Activity

adding application scenarios of folding

Browse source
This commit is contained in:
Emanuele Scala 2025-12-03 18:55:42 +00:00
parent 6aab14f264
commit 650b60d984
1 changed files with 11 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

11
emsczkp-research-folding-gbp.md
View file

@ -48,6 +48,17 @@ GBP is linear to the amount of commitments and logarithmic to program size. With
The idea is that, by combining IVC folding and GBPs, we can support many-input transactions, using only a fraction of the bandwidth and verification time, and without having to build so many trees as seen with Curve Forests (dramatically extending the time to update the state after importing a block). Finally, this work would naturally extend to BP+ aggregate range proofs as well.
**How does this translate in practice?** There are several application scenarios for folding in Monero, including (but not limited to) the following:
“Chain folding”. Suppose Alice and Bob each include their own membership proof in a single transaction without revealing their witnesses to each other: Alice creates her proof, passes it to Bob, and Bob adds his proof on top. In this case, we aggregate single-input transactions into one many-input transaction and create a single folded proof.
“Stream proving”. This would enable zkRollups, where many statements are collected across transactions and a folded proof is generated for a batch of transactions.
“Transaction uniformity”. In this scenario, all transactions have a fixed number of inputs and outputs so that all transactions look the same, improving privacy. We currently lack such a feature because larger transactions are too expensive for it to be worth the benefit to privacy. Cheaper standalone multi-input transactions through folding would address this issue.
Clearly, the first two scenarios require an additional scheme on top to fold proofs across transactions, while the third does not.
However, to identify the simplest and common pattern to start designing Bulletproofs*, we can phrase the following: “we want to optimize the current FCMP from n invocations of the circuit, executed sequentially in one proof with linear computation and logarithmic bandwidth, to n folded invocations in a way that reduces the verifier’s computational complexity”.
Given this, discussions about changes to the network (or similar system-level aspects) may be deferred until we obtain such proofs.
**What to be done**:
The first step is to adapt the (algebraic) verifier to the Protostar form. A second step is to ensure that this modification does not break the security of Bulletproofs. Given the abstraction of the Protostar paper, this provides solid steps toward that goal.
One more step is to extend the approach to the Generalized Bulletproofs (GBPs) proof system, while still supporting its arithmetic circuits.