Thank you @Nuh
Costings: verifyScript runs at ~2.1M cycles per input and is roughly linear. On a L40S that’s ~2.7s per input on an EC-dominated path. For example block 741,000 (670 inputs, segwit and taproot) proves in 55 minutes wall-clock across two L40S - 110 GPU-minutes. It is worth stating that 27 of those 55 mins are the 16 way aggregation - not the proving! That ratio could potentially be improved on.
Block 741,000 carries 670 inputs, whereas near tip blocks often carry 6k-10k inputs. With your application in mind, using 2 weeks as an example (~2016 blocks) on a single L40S:
Low case - 2016 blocks * 6000 inputs * 2.7s per input = 32,659,200s / 544,320m / 9,072h / 378 days
High case - 2016 blocks * 10000 inputs * 2.7s per input = 54,432,000s / 907,200m / 15,120h / 630 days
(I’m using 2.7s here; the running mean is already above it - see below)
N.B - Proving is parallelisable across multiple GPUs.
I was curious about a block closer to the tip, so I have started to measure block 962,000 (6,303 txs / 8,006 inputs / 16 chunks). This is running on an L40S (Proving only / No aggregation or accumulator).
- 44 input sample - 2.57s per input
- Chunk 0 (500 inputs) - 2.63s per input
- Chunk 1 (500 inputs) - 3.86s per input
The variance between the two chunk samples shows that Chunk 1 cost ~47% more than Chunk 0 for the same amount of inputs. This difference is the input types. A key path spend is one sig check, whereas a P2SH multisig or script path spend contains more. Transaction types cluster within a block, so each Chunk will have different quantities of types. Obviously we only have 2 chunks proven so far, which is not enough data to give a median per input value. When the data is in, we will have the median per input time, which will enable us to calculate an estimate for your 2 week (2016 blocks) period. I will reply again when the final benchmark for block 962,000 is in.
Currently the spine grows from genesis and reaches block 7,819 (as of writing). You need the most recent end, which won’t be reached for a long time. This is an anchoring issue, where I lean for correctness and believe anchoring from genesis is the better way. There is the argument that an anchor can be used at a mid-chain checkpoint, but this is a stated trust input that I wouldn’t like to pursue. Your proposal of hashrate-based checkpointing is interesting, you are trusting accumulated work either way. As such, a checkpoint anchored range near the tip isn’t a compromise for you.
With regards to the merge-mining check specifically, you don’t need the guest changed. The block proof already hashes every txid into header.merkle_root and verifies it, so a standard merkle branch to the coinbase verifies against a header the proof attests. The public journal gives you block_hash, prev_hash, height and cumulative_work, which establishes the chain and its work. The merge-mining tag then rides in as an ordinary inclusion proof against a root that’s already proven. No fork, no extra commitment.