Running Core's real consensus code inside a zkVM

The verifyScript function's performance has been tested and analyzed in detail, revealing significant insights about its operational efficiency. Running approximately 2.1 million cycles per input, the function exhibits a nearly linear time complexity on an L40S machine, translating to roughly 2.7 seconds per input when following an EC-dominated path. This analysis was particularly applied to block 741,000, which consists of 670 inputs including segwit and taproot transactions. The total processing time for this block spanned 55 minutes, with 27 of those minutes dedicated solely to a 16-way aggregation process, suggesting that improvements might be feasible in this area.

Further investigations into blocks with higher numbers of inputs, such as those near the blockchain's tip featuring between 6,000 to 10,000 inputs, highlighted the extensive computational demands placed on the system. For instance, processing approximately two weeks’ worth of blocks (about 2016 blocks) could take anywhere from 378 days for blocks at the lower end of input scale to as much as 630 days for those at the higher end under current conditions. These projections use a base calculation of 2.7 seconds per input, though actual times may vary as indicated by ongoing measurements that have already suggested a mean time higher than 2.7 seconds.

A deeper dive into block 962,000, which included 6,303 transactions and 8,006 inputs across 16 chunks, provided additional granularity. Initial results showed a variance in processing times between different chunks—specifically, Chunk 1 required around 47% more time than Chunk 0 for an equivalent number of inputs, attributed mainly to the complexity of transaction types like P2SH multisig or script path spends as opposed to simpler key path spends. This variability underscores the importance of considering input type in performance assessments.

On a broader technical level, the approach to blockchain anchoring is discussed, weighing the merits of starting from the genesis block versus using mid-chain checkpoints. The latter presents a trust issue that could be contentious, although the proposal for hash rate-based checkpointing offers a novel perspective by leveraging the accumulated proof-of-work as a trust mechanism. Additionally, regarding merge-mining, it’s noted that standard merkle branches to the coinbase are sufficient for verifying against a header that the proof attests without necessitating any changes to the guest or adding extra commitments, ensuring the integrity and continuity of the chain validation process.