This week by the numbers
Bootstrap Mode
@sword-smith implemented a new bootstrap mode. This provides the ability to sync from downloaded blocks, which could for example be obtained via torrent. This mode is initiated by a new command-line flag --bootstrap-from-directory=<DIR>. Details are here.
RemovalRecordList as Standalone Data Structure
@aszepieniec and @sword-smith finished implementing the removal record list as a standalone data structure. This is an intermediate step for more efficient packing of removal records. Integrating this required versioning the consensus programs, creating a new merge branch and two versions of the single proof program.
Investigating a Reported TritonVm Performance Drop
@jfs did a bunch of investigative work last week.
Various continuous-integration workflows broke (on github) because third party code we rely on changed behavior subtly. Figuring out those differences and which commands to invoke from now on feels at times feels closer to a mystic art than to engineering.
The other investigative work did not bear much fruit, unfortunately: a user-reported performance problem in Triton VM remains elusive to date. If you are observing performance problems in Triton VM, please join the discussion. It’s important to us that you don’t have ugly surprises.
In order to aid future investigations it was decided that neptune-core will log TritonVM inputs under certain conditions. This logging would be enabled by an environment variable and could then be sent to core developers so they would have the exact inputs used.
As an upside of that investigation, we now have a lot more data of all the individual steps of the Triton VM prover, which will probably lead to improved performance down the road. Also, the performance profiler got a bit more powerful: as of the next release (or the latest commit), the Triton VM performance profile also reports total memory consumption. Just run triton-cli --profile prove as before to see the new goodies.
TxProvingCapability becomes VmProvingCapability
@danda performed some housekeeping to correct and future-proof the “proving-capability” abstraction used by neptune-core. Previously TxProvingCapability was an enumeration (list) of possible proof-types used by a transaction. However it was being used by code that could deal with arbitrary proof-types. The new VmProvingCapability type instead uses a “padded-height” program complexity score to indicate the device’s proving ability. This is considered a more correct abstraction as it applies to any proof that can possibly be generated.
Contributors updates
-
- consensus program versioning
- slides for upcoming presentations
- feedback on Bitcoin and quantum computing SoK
-
- finished up and merged network-mock #599
- raised #603 VmProvingCapability re-write
- raised #604 test genesis block hash of all networks
- closed #595, #591