From 650b60d984633190b1f3abfc32e0346f3d4f26d3 Mon Sep 17 00:00:00 2001 From: Emanuele Scala Date: Wed, 3 Dec 2025 18:55:42 +0000 Subject: [PATCH] adding application scenarios of folding --- emsczkp-research-folding-gbp.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/emsczkp-research-folding-gbp.md b/emsczkp-research-folding-gbp.md index 48b7bf0..ef9f2b6 100644 --- a/emsczkp-research-folding-gbp.md +++ b/emsczkp-research-folding-gbp.md @@ -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.