jsign

##### Raw polynomials multiproof benchmark #####
For 1 polynomials:
        Proving:
                Proof serialization duration: 0.10ms
                Proof creation duration: 51ms
                Duration per step:
                        Generate challenge r and powers : 0.02ms
                        Calculate t, g(x) and D         : 3.50ms
                        Calculate h(x) and E            : 3.37ms
                        Calculate (h-g)(x) and E-D      : 0.00ms

jsign

Link: https://github.com/gballet/go-ethereum/commit/8622bdcfb7238a94bedb68c4e18dd63e7e7e373b


Result:
```
$ go test ./trie/utils -run=TestPedersenHashDistribution -count=1 -v
=== RUN   TestPedersenHashDistribution
Generating...
Aggregating...
Bit 0: 8000196 (deviation from expected 0.00%)

jsign

CPU: AMD Ryzen 7 3800XT 8-Core Processor

Client: geth

Random key-values proving in a VKT

##### VKT proof benchmark #####
Setup: **in-memory** tree with 1000000 random key-values...

jsign

So, for the verifying part of the proof, parallelization makes a difference.

Verifying proof of 16k openings:

Total duration: 56ms
Duration per step:
      Generate challenge r and powers                       : 32.02ms
      Calculating helper_scalars r^i/(t-z_i)                : 0.72ms
 g_2(t) = SUM y_i*(r^i/(t-z_i))=SUM y_i*helper_scalars : 0.03ms

jsign

This gist shares an experiment on an alternative implementation for JUMPDEST analysis.

Some quick notes:

• The linked branch passes all go test ./... tests.
• I'm not opening a PR since I'm not sure yet this might be convincing (explaining why below).

The main idea is to minimize the amount of bitwise operations by switching from a vector of byte to uint64. Using byte means that PUSHN where N is greater than 8 will have to span multiple bytes, thus requiring "internal loops".

Using uint64 means having more space to resolve any PUSHN in a single write attempt with at most one overflow without today's 2^16+2^8 decomposition.