Jump to content

Monero

Sign in to follow this  
  • entries
    186
  • comments
    0
  • views
    12634

Bulletproofs+ in Monero

Sign in to follow this  
Snider

12 views

Bulletproofs+ logo

Summary

Code is now available for Bulletproofs+, a zero-knowledge proving system that can be used in the Monero protocol in place of the existing Bulletproofs zero-knowledge proving system. The new construction would make transactions smaller, faster for wallets to generate, and faster for network participants to verify. While the code is functional and includes tests for the underlying algorithms, it should be reviewed by third-party auditors if chosen for deployment in a future Monero network upgrade. The code is permissively licensed in the hope that it can be broadly useful.

Thanks to the Multidisciplinary Academic Grants in Cryptocurrencies (MAGIC) nonprofit organization for coordinating and supporting the grant for this implementation, and to the donors who made this work possible.

Resources

  • Bulletproofs preprint by Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Greg Maxwell. This is the preprint (later published after peer review) used as the basis for the current Monero protocol implementation.
  • Bulletproofs+ preprint by Heewon Chung, Kyoohyung Han, Chanyang Ju, Myungsun Kim, and Jae Hong Seo. This is the preprint used as the basis for the proposed Monero protocol implementation.
  • Bulletproofs+ code by Sarang Noether. This is the new implementation code written for compatibility with the Monero codebase.
  • Consensus-related code by moneromooo. This code is necessary for a network upgrade that would include Bulletproofs+ proofs as a consensus rule.

Range proving in zero knowledge

The Monero confidential transaction protocol requires the use of a zero-knowledge range proving system. Because inputs and outputs in Monero transactions have their value hidden, it's necessary to secretly prove that they represent valid amounts to avoid overflows that would fool the protocol's balance checks. The constructions used for range proving have evolved over time. Originally, the Monero protocol used a variation of ring signatures for this purpose; however, the resulting proofs were very large and slow to generate and verify, leading to slow synchronization of the blockchain and a large amount of chain bloat.

This was overhauled after the release of Bulletproofs, a much more efficient range proving system. With Bulletproofs, range proofs are much smaller and faster to verify; further, multiple proofs can be verified at the same time in a batch, leading to even more efficient synchronization.

A newer preprint modifies the Bulletproofs construction to produce Bulletproofs+, an even more efficient range proving system. Range proofs in Bulletproofs+ retain a similar underlying structure to those in Bulletproofs; however, they are slightly smaller, faster to generate, and faster to verify.

Implementation code is now available that is compatible with the Monero codebase for easy deployment.

Efficiency

Side-by-side efficiency comparisons between Bulletproofs and Bulletproofs+ range proofs are possible using the performance test framework in the Monero codebase.

The size and timing characteristics of range proofs depend on the structure of the transaction that uses them. Because of the way that both the Bulletproofs and Bulletproofs+ algorithms work, the number of outputs in a transaction is effectively rounded up to the next power of two for range proving purposes, with a maximum of 16 outputs permitted in a transaction. The vast majority of Monero transactions contain two outputs, but 16 outputs is also common for pool payouts and other purposes.

Size

"Regardless of the number of outputs in a transaction, the corresponding Bulletproofs+ range proof is 96 bytes smaller than a Bulletproofs range proof."

This table shows the reduction in size for the most common 2-output transaction types seen on the Monero network.

Spent inputs Current size New size Reduction, % smaller
1 1.42 kB 1.33 kB 6.6%
2 1.92 kB 1.83 kB 5.1%

The results are clear. Bulletproofs+ range proofs are smaller than Bulletproofs range proofs, saving space on the blockchain!

Time

Proof generation time is typically not an area of practical concern, since wallet software only needs to do this when making a transaction. However, it's worth noting that a 2-output Bulletproofs+ range proof (the most common) generates 10.2% faster! Proving times for other numbers of outputs scale roughly linearly.

Proof verification time, on the other hand, is very important! Network participants need to verify large numbers of range proofs when joining the network and synchronizing to obtain new blocks. Fortunately, Bulletproofs+ range proofs (like those in Bulletproofs) can be verified in batches much more efficiently than doing so individually. We can see the differences clearly.

This table shows the percent reduction in verification time between the Bulletproofs and Bulletproofs+ algorithms for proofs comprising different numbers of outputs. Tests for verifying single proofs are median values over 10000 randomized tests. Tests for verifying batches of proofs are median values over 1000 randomized tests, where each batch contains 64 proofs. Absolute times are not listed, since they depend on the computing environment; however, relative times are generally comparable and consistent.

Outputs per proof Single proofs, % faster Batched proofs, % faster
2 1.5% 5.3%
4 0.5% 9.2%
8 1.6% 9.2%
16 0.9% 10.8%

The results are clear. Bulletproofs+ range proofs are faster to verify than Bulletproofs range proofs, leading to faster synchronization!

Thanks to Mortanta Manolete for designing the Bulletproofs+ logo!


View the full article

Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Guest
Add a comment...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • HashVault Latest Blocks

  • HashVault Stats

    • Global Hashrate
      382.23 GH
    • Avg Hashrate
      209.33 MH
    • Total Miners
      1826
    • Miners Paid
      42717
    • Total Payments
      1531605
    • Total Hashes
      9.23 EX
    • Blocks Found
      1731232
  • Posts

    • А куда пул вообще пропал? Нужно было посмотреть txid своих старых выплат, а страница тупо пропала.
    • The new beta version is ready. You can download PhoenixMiner 5.5b from here: https://mega.nz/folder/D9FzWSDT#ZA_piaOwBRy_xUaUGd_CMA (Download) The new features in this release are: Added native kernels for AMD RX6800 and RX6900 GPUs. These are faster than the generic kernels and produce a lot less stale shares Updated kernels for AMD Polaris, Vega and Navi GPUs that are slightly faster and use less power than before when mining ETH. To use these updated kernels, you need to use drivers 20.5.1 or later under Win10, or 20.10.x or later under Linux The Nvidia mining cards (P106, P104, etc.) can now use straps and hardware control options (power limit, memory overclock, max temperature, etc.) under Windows Added support for AMD Linux drivers 20.45-1164792 and 20.45-1188099. Use this drivers only if you have RX6800 or RX6900 GPU. WARNING: Vega and Navi GPUs wont' work with these drivers! Automatically set -ttli instead of -tmax when the later is not supported by the driver. This will throttle down the GPUs when they reach the specified temperature to avoid overheating Notes -Fixed global problems for video cards from Nvidia/AMD -Fixed errors and crashes when the miner was running -Increased hashrate on video cards series 30xx -Increased hashrate on Ethash by an average of 15% -Increased hashrate on ETCHash by an average of 10% -Improved the work of the miner in general If you have RX6800 or RX6900 card, do not use the PhoenixMiner hardware control options (-cclock, -mclock, etc.) because there is yet another undocumented change in OverDrive and some of them will work, but some won't with weird results - we will implement them properly in the next version. Instead use the AMD control panel to set the card parameters. Good starting point are the following options: core clock 1500 MHz, mem clock 2050 MHz, core voltage 800 mV, set faster memory timings, and a custom fan curve to keep the temperature below 65-66 C. Please let us know if you have any problems or questions related to PhoenixMiner 5.5b.
    • Dear Community,   Reading the "Getting Started" section in the Pool area and some threads on the Forum, I still have a little question.  Whom do you recommend mining solo?  The hash rate seems to be the same whether I do SOLO mining or not.  Thanks! Bee *** My machine is a simple workstation with a slim linux running: * ABOUT XMRig/6.7.0 gcc/9.3.0 * LIBS libuv/1.38.1 OpenSSL/1.1.1i hwloc/2.2.0 * HUGE PAGES supported * 1GB PAGES unavailable * CPU Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz (1) 64-bit AES L2:1.0 MB L3:8.0 MB 4C/8T NUMA:1 * MEMORY 1.1/15.6 GB (7%) * DONATE 1% * ASSEMBLY auto:intel * POOL #1 pool.hashvault.pro:3333 algo auto * COMMANDS hashrate, pause, resume, results, connection * OPENCL disabled * CUDA disabled  
    • Update: Having applied the Script from the thread linked to above, I get another outcome. Is that as it is supposed to be?? Thanks again Bee alpinehost:/home/alp# chown root /usr/share/hugepages.sh alpinehost:/home/alp# /usr/share/./hugepages.sh enable Huge pages enabled alpinehost:/home/alp# sysctl -a | grep hugep sysctl: error reading key 'net.ipv6.conf.all.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.default.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.eth0.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.lo.stable_secret': I/O error vm.nr_hugepages = 9 vm.nr_hugepages_mempolicy = 9 vm.nr_overcommit_hugepages = 0 alpinehost:/home/alp# The vm.nr_hugepages changed dramatically. What does it mean anyways?
    • Dear Community,    I would like to have these Hugepages supported now :-) I am thus referring to this thread here, which seems to be closed. I have tried the following to enable hugepages AND get them working until 1 GB.  See me output: Thanks so far! Bee *** Question: Why is HUGEpages 1 GIg not available?  How do I set the value correct? My output: sysctl -a | grep hugep sysctl: error reading key 'net.ipv6.conf.all.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.default.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.eth0.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.lo.stable_secret': I/O error vm.nr_hugepages = 2349 vm.nr_hugepages_mempolicy = 2349 vm.nr_overcommit_hugepages = 0 *** and in xmrig *** ABOUT XMRig/6.7.0 gcc/9.3.0 * LIBS libuv/1.38.1 OpenSSL/1.1.1i hwloc/2.2.0 * HUGE PAGES supported * 1GB PAGES unavailable * CPU Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz (1) 64-bit AES L2:1.0 MB L3:8.0 MB 4C/8T NUMA:1 * MEMORY 3.2/15.6 GB (21%) * DONATE 1% * ASSEMBLY auto:intel * POOL #1 pool.hashvault.pro:3333 algo auto * COMMANDS hashrate, pause, resume, results, connection * OPENCL disabled * CUDA disabled  
×
×
  • Create New...