Transaction throughput on the Neptune Cash blockchain is restricted by computational power. The more proving power that comes online, the more transactions each block can include.
For this reason, several power users run neptune-core on powerful machines as this gives them income in the form of composer fees and transaction fees. We own a couple of machines with powerful processors and we just ran multiple benchmarks on Triton VM version 0.48.0, the version used by neptune-core.
For the benefit of our power users, we present these numbers below.
Triton VM performance
Threadripper 7995wx, RAM-hungry path
Log_2(padded height)
16
17
18
19
20
21
22
23
Proving time (seconds)
2.65
5.36
11.06
22.80
46.52
99.17
203.43
417.75
Max RAM consumption, approximated (GiB)
4.9
8.6
16.1
29.7
58.4
107.8
199.9
399.5
If you want to participate in competitive composition and transaction upgrading, you should probably be able to hit these numbers, or be close to them.
From these numbers, we can estimate the time it takes to create a block proposal as:
one proof of padded height 2^{21} (raise from ProofCollection to SingleProof)
one 2^{20} proof (a merge of two SingleProof)
one 2^{19} proof (BlockProgram).
Summing the time for each proof, gives a total of 168.47 seconds, a little less than three minutes. This assumes your node’s mempool is non-empty – that there is a synced SingleProof transaction ready to be merged into your coinbase transaction.
Happy to report that the newly released Triton VM v0.49.0 reduces proving time by 5-10 %. We can now build a proof with a padded height of 2^{21} in 93 seconds.
And with version 0.49.0, we can now do padded heights of 2^{24} on our machine (when the correct environment variables are set). This will allow for bigger transactions to be mined without going through the merge path.
Statistics show that 20% of block times are less than 3 minutes, and nearly 5% of blocks are around 1 minute. How is this achieved? Is it because blocks frequently undergo reorg?
Guessing is a Poisson process, meaning that the time it takes to solve this step is exponentially distributed. Are you suggesting that your observations are inconsistent with an exponential distribution?
In my personal experience, the compose process itself takes at least 3 minutes. Therefore, I’m curious about how to reduce the combined time of the compose and guess process to just 1 minute.
I haven’t paid attention for a month or two, but iirc, block proposals were regularly being generated within about 45 seconds, which means that a lucky guesser could find a block within the remaining 15 seconds, to achieve a 1 minute block time. I would not expect it to be a frequent occurrence however.
edit:
here are some under 2 minutes occurrences from a november log file, two under 1 minute:
I should also note that my node is not logging any block proposal for probably the majority of blocks, which may indicate that someone is solo mining without publishing the block proposal. It would I think make sense for mining pools to do this, so the pool’s own miners can guess before others have a shot.
The fastest we have achieved is around 175 seconds (three minutes) on a Threadripper 7995wx. You can probably get it 15-20 % faster on a Threadripper 9995wx. To get it even faster, you need to run the prover on a GPU. And that GPU needs at least 48GB VRAM and should probably have 96GB VRAM.
We don’t have a GPU prover, and we are not aware of any open sourced GPU prover. But since compositions time are less than one minute, I’m convinced that at least one has been developed.