Blog > What Upgrades Will Bulletproof++ Bring to the Beldex Network?

What Upgrades Will Bulletproof++ Bring to the Beldex Network?

September 05,2025

10:00 am UTC

Range Proofs

private transactions were first developed in 2015 with range proofs.

Range proofs proved not the amounts of a transaction but the sum total of inputs and outputs of a transaction equalled to 0. This is called a Pedersen commitment.

The transaction can be proved legitimate if the sum total of inputs, say, A+B+C and the sum total of outputs, D+E+F, were equal to 0.

Greg Maxwell created a modified range proof in 2015 which proves that the outputs of a transaction are within a specific range: 0 to 264.

However, these are 64 bit range proofs, almost 4 kilobytes in size. In contrast, a single transaction output is only 40 bytes of data.

This means that the size of a 40 byte transaction will become 4040 bytes, 10 times large. Sometimes, it is even 6 to 7 kB (6000 to 7000 bytes) long. With 2 to 3 transactions, this could easily add up to 12 kB, 18 kB, or 21 kB. If more transactions were involved, then the block size could explode. Even though networks like Monero do not have a blocksize limit, such large transactions are more likely to congest the network as it scales.

Bulletproofs

In 2018, Bulletproofs were developed by a team of researchers at Stanford University. They’re short non-interactive zero knowledge proofs that require no trusted setup.

Bulletproofs are efficient range proofs as they scale logarithmically and not linearly, meaning that even if we were to prove a large set of data, the size of the proof would only increase marginally.

With Bulletproofs, multiple outputs within a single transaction could be proven together, also earning them the name, aggregate range proofs. The size of bulletproof transactions were 600 to 700 bytes per output, significantly reducing the size from the previous 4000 to 6000 bytes range.

Bulletproof+

Bulletproofs+ are slightly smaller and faster to generate and verify, when compared to bulletproofs. They’re about 5 to 6% smaller than the original bulletproofs.

A bulletproofs+ range proof is always 96 bytes smaller than a Bulletproofs range proof, irrespective of the number of outputs in a transaction.

The size of the most-common two outputs in Bulletproofs were 1.7 kB and with bulletproofs+, it was 1.6 kB, a noticeable 5 to 7% difference.

Considering this at scale for 100 transactions, for BP it would be 170 kB and BP+, it would be 160 kB.

Bulletproofs+ could also aggregate multiple outputs within a single transaction, however, all things considered, the difference is marginal and before Bulletproofs+ could be implemented, Bulletproofs++ came along, introducing even smaller and faster transactions.

Bulletproofs++

Bulletproofs++ further enhances Bulletproofs+. BP++ transactions, along with the proofs, were only 400 to 450 bytes in size. This is 38% smaller than BP and 27% smaller than BP+. Additionally, proving times were 5 times faster and verification times were 3 times faster than BP. Aggregation and batch transactions were even more efficient, proving 9.5 times and verification 5.5 times.

BP++ could also aggregate assets across transactions (cross-transaction aggregation) and across protocols in some designs. Though BP++ is still in R&D, it represents a critical path for scaling private networks like Beldex and Monero as adoption grows.

Comparing 2-Output Transactions

Let’s take an example block with 100 transactions, each with 2 outputs:

  • Borromean Range Proofs (pre-2018)
    ~6–7 kB per output.
    2 outputs → ~12–14 kB per transaction.
    100 transactions → 1.2–1.4 MB per block just for range proofs.
    In heavy usage, blocks could bloat up to 2–4 MB.
  • Bulletproofs (2018 upgrade)
    Aggregated proof across all outputs in a single transaction.
    2 outputs → ~1.7 kB (not 12–14 kB).
    100 transactions → ~170 kB for proofs.
    Block size shrank by ~90%.
  • Bulletproof+ (2022 upgrade)
    ~5–7% smaller than Bulletproofs.
    2 outputs → ~1.6 kB.
    100 transactions → ~160 kB for proofs.
  • Bulletproof++ (research)
    Promises ~20–30% smaller than Bulletproof+.
    2 outputs → ~1.2–1.3 kB (estimated).
    100 transactions → ~120–130 kB.

👉 So: what was ~1.2–4 MB per block with Borromean shrank to ~160–200 kB with Bulletproofs/+, and could drop further to ~120 kB with Bulletproof++.

Bulletproof++ Implementation in Beldex

Unlike Monero, blocksize in Beldex is fixed. The block size of a Beldex block is 300 kB to 600 kB. Even though the block size is dynamic, it has an upper and a lower limit.

With Borromean or even Bulletproof range proofs, larger transactions could quickly fill Beldex’s fixed block size, limiting scalability and throughput. While the PoS consensus offers some relief when it comes to block verification, long term scalability can only be achieved with BP++.

By introducing Bulletproof++, the network ensures that more transactions can fit within each block. This will allow Beldex to handle a higher transaction volume per block (higher network throughput) while maintaining smaller proof sizes, faster proof generation and validation, as well as improved efficiency.

This implementation, coupled with the enhanced VRF consensus (also a WIP), could significantly enhance the security and efficiency of transaction verification and proving times in Beldex.

Bulletproof++ is currently in R&D by Beldex Research Labs, expected to roll out in stages by Q4, 2025.

Closing Thoughts

Bulletproof++ is more than just a technical upgrade. For private networks, it is a step towards sustainable scalability. Beldex’s growing ecosystem can overcome potential future bottlenecks with Bulletproof++.

As the network adoption increases, these optimizations will allow it to remain efficient, sustainable, secure, and future-ready, building a strong foundation for our private dApps and services.

Join our community to know more about our recent developments.

Follow us on

Telegram | Twitter | Discord | Facebook | Instagram | LinkedIn | Medium | CoinMarketCap

Listen

0:00
0:00

1x

back to blog
previous post Previous Post
Next Post next post