core/vm, cmd/evm: implement eof validation #30418

holiman · 2024-09-11T08:02:05Z

The bulk of this PR is authored by @lightclient , in the original EOF-work.
More recently, the code has been picked up and reworked for the new EOF specification, by @MariusVanDerWijden , in #29518, and also @shemnon has contributed with fixes.

They are the main authors to be credited for the code in this PR.

This PR is an attempt to start eating the elephant one small bite at a time, by selecting only the eof-validation as a standalone piece which can be merged without interfering too much in the core stuff.

In this PR:

Validation of eof containers, lifted from WIP mega eof #29518, along with test-vectors from consensus-tests and fuzzing, to ensure that the move did not lose any functionality.
Definition of eof opcodes, which is a prerequisite for validation
Addition of undefined to a jumptable entry item. I'm not super-happy with this, but for the moment it seems the least invasive way to do it. A better way might be to go back and allowing nil-items or nil execute-functions to denote "undefined".
Gas-calculators. These do not strictly need to be here, I can remove them if we want to reduce the diff even further.
benchmarks of eof validation speed

It would have been nice to break it up further, core/vm is growing very very large. However, it's not easy to put eof in a submodule.

eof validation requires at least the opcodes, and certain opcode-specific info (e.g. stack usage)
interpreter requires eof to tell it to validate

So what we might do is move the opcodes, and the jumptable definition to a new low-level module. And in core/vm keep the jumptable instantiations, so we can pass the actual jumptables to eof. Then eof doesn't have to import core/vm, I think.

Even with this smaller piece cherry-picked, there's quite a bit of work to do to improve it, better documentation and test coverage. I'll push commits here and rebase quite a bit.

To do in follow-up PR(s) is to modify the interpreter a bit more in-depth, to operate differently in eof-mode versus non-eof-mode.

Co-authored-by: lightclient lightclient@protonmail.com
Co-authored-by: Marius van der Wijden m.vanderwijden@live.de
Co-authored-by: Danno Ferrin danno.ferrin@shemnon.com

core/vm/jump_table.go

core/vm/validate.go

core/vm/memory_table.go

core/vm/validate.go

holiman · 2024-09-11T11:03:03Z

Added benchmarks, based on some of the worst-cases from the consensus-tests + fuzzing vectors.

goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/cmd/eofdump
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
BenchmarkEofParse
BenchmarkEofParse/test-1
BenchmarkEofParse/test-1-8               1043824              1145 ns/op          17.47 MB/s         352 B/op          9 allocs/op
BenchmarkEofParse/test-2
BenchmarkEofParse/test-2-8                717020              1526 ns/op          13.77 MB/s         416 B/op         12 allocs/op
BenchmarkEofParse/test-3
BenchmarkEofParse/test-3-8                645865              1830 ns/op          12.56 MB/s         464 B/op         16 allocs/op
BenchmarkEofParse/test-4
BenchmarkEofParse/test-4-8                666870              1875 ns/op          12.27 MB/s         464 B/op         16 allocs/op
BenchmarkEofParse/test-5
BenchmarkEofParse/test-5-8                614787              2180 ns/op          11.01 MB/s         488 B/op         18 allocs/op
BenchmarkEofParse/test-6
BenchmarkEofParse/test-6-8                337408              3773 ns/op          21.20 MB/s        1064 B/op         35 allocs/op
BenchmarkEofParse/test-7
BenchmarkEofParse/test-7-8                   282           4462357 ns/op          11.00 MB/s     1058652 B/op      38282 allocs/op
BenchmarkEofParse/test-8
BenchmarkEofParse/test-8-8                342518              4078 ns/op          15.69 MB/s         934 B/op         35 allocs/op
BenchmarkEofParse/test-9
BenchmarkEofParse/test-9-8                301110              3716 ns/op          17.22 MB/s         934 B/op         35 allocs/op
BenchmarkEofParse/test-10
BenchmarkEofParse/test-10-8               288266              4832 ns/op           6.83 MB/s        1031 B/op         37 allocs/op
BenchmarkEofParse/test-11
BenchmarkEofParse/test-11-8               277754              4582 ns/op           7.20 MB/s        1031 B/op         37 allocs/op
BenchmarkEofParse/test-12
BenchmarkEofParse/test-12-8                  632           1874380 ns/op          13.11 MB/s      453325 B/op      18881 allocs/op
BenchmarkEofParse/test-13
BenchmarkEofParse/test-13-8               185851              6186 ns/op           5.50 MB/s        1696 B/op         40 allocs/op
BenchmarkEofParse/test-14
BenchmarkEofParse/test-14-8                97939             13215 ns/op           4.09 MB/s        3557 B/op         80 allocs/op
BenchmarkEofParse/test-15
BenchmarkEofParse/test-15-8               104028             13065 ns/op          11.48 MB/s        3557 B/op         80 allocs/op
BenchmarkEofParse/test-16
BenchmarkEofParse/test-16-8                36811             36740 ns/op          14.59 MB/s       12777 B/op        279 allocs/op
BenchmarkEofParse/test-17
BenchmarkEofParse/test-17-8                 9140            117813 ns/op           6.25 MB/s       30370 B/op        739 allocs/op
BenchmarkEofParse/test-18
BenchmarkEofParse/test-18-8                 3262            368707 ns/op           2.83 MB/s      110391 B/op       2091 allocs/op
BenchmarkEofParse/test-19
BenchmarkEofParse/test-19-8               720025              1415 ns/op          22.62 MB/s         408 B/op         12 allocs/op
PASS
ok      github.com/ethereum/go-ethereum/cmd/eofdump     31.290s

holiman · 2024-09-11T13:04:50Z

Sped it up quite a bit, the slowest vector is now improved by a factor of 10 :)

goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/cmd/eofdump
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
                   │  eof.bench.1  │             eof.bench.2             │
                   │    sec/op     │    sec/op     vs base               │
EofParse/test-1-8     1.062µ ± ∞ ¹   1.105µ ± ∞ ¹        ~ (p=0.151 n=5)
EofParse/test-2-8     1.451µ ± ∞ ¹   1.442µ ± ∞ ¹        ~ (p=0.151 n=5)
EofParse/test-3-8     1.770µ ± ∞ ¹   1.533µ ± ∞ ¹  -13.39% (p=0.008 n=5)
EofParse/test-4-8     1.775µ ± ∞ ¹   1.550µ ± ∞ ¹  -12.68% (p=0.008 n=5)
EofParse/test-5-8     2.035µ ± ∞ ¹   1.631µ ± ∞ ¹  -19.85% (p=0.008 n=5)
EofParse/test-6-8     3.484µ ± ∞ ¹   3.039µ ± ∞ ¹  -12.77% (p=0.008 n=5)
EofParse/test-7-8     3.990m ± ∞ ¹   2.896m ± ∞ ¹  -27.43% (p=0.008 n=5)
EofParse/test-8-8     3.868µ ± ∞ ¹   1.225µ ± ∞ ¹  -68.33% (p=0.008 n=5)
EofParse/test-9-8     3.765µ ± ∞ ¹   1.170µ ± ∞ ¹  -68.92% (p=0.008 n=5)
EofParse/test-10-8    4.252µ ± ∞ ¹   1.838µ ± ∞ ¹  -56.77% (p=0.008 n=5)
EofParse/test-11-8    4.727µ ± ∞ ¹   1.829µ ± ∞ ¹  -61.31% (p=0.008 n=5)
EofParse/test-12-8    1.745m ± ∞ ¹   1.106m ± ∞ ¹  -36.63% (p=0.008 n=5)
EofParse/test-13-8    5.778µ ± ∞ ¹   1.836µ ± ∞ ¹  -68.22% (p=0.008 n=5)
EofParse/test-14-8   12.637µ ± ∞ ¹   2.335µ ± ∞ ¹  -81.52% (p=0.008 n=5)
EofParse/test-15-8   12.224µ ± ∞ ¹   2.856µ ± ∞ ¹  -76.64% (p=0.008 n=5)
EofParse/test-16-8    33.30µ ± ∞ ¹   15.61µ ± ∞ ¹  -53.12% (p=0.008 n=5)
EofParse/test-17-8   106.47µ ± ∞ ¹   11.42µ ± ∞ ¹  -89.27% (p=0.008 n=5)
EofParse/test-18-8   337.85µ ± ∞ ¹   27.20µ ± ∞ ¹  -91.95% (p=0.008 n=5)
EofParse/test-19-8    1.368µ ± ∞ ¹   1.365µ ± ∞ ¹        ~ (p=0.889 n=5)
geomean               11.30µ         5.055µ        -55.27%
¹ need >= 6 samples for confidence interval at level 0.95

                   │  eof.bench.1  │               eof.bench.2               │
                   │      B/s      │      B/s        vs base                 │
EofParse/test-1-8    17.96Mi ± ∞ ¹    17.27Mi ± ∞ ¹          ~ (p=0.151 n=5)
EofParse/test-2-8    13.80Mi ± ∞ ¹    13.89Mi ± ∞ ¹          ~ (p=0.151 n=5)
EofParse/test-3-8    12.39Mi ± ∞ ¹    14.31Mi ± ∞ ¹    +15.47% (p=0.008 n=5)
EofParse/test-4-8    12.36Mi ± ∞ ¹    14.15Mi ± ∞ ¹    +14.51% (p=0.008 n=5)
EofParse/test-5-8    11.24Mi ± ∞ ¹    14.04Mi ± ∞ ¹    +24.85% (p=0.008 n=5)
EofParse/test-6-8    21.90Mi ± ∞ ¹    25.11Mi ± ∞ ¹    +14.68% (p=0.008 n=5)
EofParse/test-7-8    11.74Mi ± ∞ ¹    16.17Mi ± ∞ ¹    +37.77% (p=0.008 n=5)
EofParse/test-8-8    15.78Mi ± ∞ ¹    49.84Mi ± ∞ ¹   +215.77% (p=0.008 n=5)
EofParse/test-9-8    16.21Mi ± ∞ ¹    52.18Mi ± ∞ ¹   +221.82% (p=0.008 n=5)
EofParse/test-10-8   7.401Mi ± ∞ ¹   17.118Mi ± ∞ ¹   +131.31% (p=0.008 n=5)
EofParse/test-11-8   6.657Mi ± ∞ ¹   17.204Mi ± ∞ ¹   +158.45% (p=0.008 n=5)
EofParse/test-12-8   13.43Mi ± ∞ ¹    21.20Mi ± ∞ ¹    +57.88% (p=0.008 n=5)
EofParse/test-13-8   5.608Mi ± ∞ ¹   17.662Mi ± ∞ ¹   +214.97% (p=0.008 n=5)
EofParse/test-14-8   4.072Mi ± ∞ ¹   22.058Mi ± ∞ ¹   +441.69% (p=0.008 n=5)
EofParse/test-15-8   11.70Mi ± ∞ ¹    50.09Mi ± ∞ ¹   +328.04% (p=0.008 n=5)
EofParse/test-16-8   15.35Mi ± ∞ ¹    32.74Mi ± ∞ ¹   +113.23% (p=0.008 n=5)
EofParse/test-17-8   6.590Mi ± ∞ ¹   61.455Mi ± ∞ ¹   +832.56% (p=0.008 n=5)
EofParse/test-18-8   2.947Mi ± ∞ ¹   36.602Mi ± ∞ ¹  +1142.07% (p=0.008 n=5)
EofParse/test-19-8   22.31Mi ± ∞ ¹    22.36Mi ± ∞ ¹          ~ (p=0.841 n=5)
geomean              10.65Mi          23.81Mi         +123.64%
¹ need >= 6 samples for confidence interval at level 0.95

                   │   eof.bench.1   │              eof.bench.2               │
                   │      B/op       │     B/op       vs base                 │
EofParse/test-1-8        352.0 ± ∞ ¹     352.0 ± ∞ ¹        ~ (p=1.000 n=5) ²
EofParse/test-2-8        416.0 ± ∞ ¹     416.0 ± ∞ ¹        ~ (p=1.000 n=5) ²
EofParse/test-3-8        464.0 ± ∞ ¹     424.0 ± ∞ ¹   -8.62% (p=0.008 n=5)
EofParse/test-4-8        464.0 ± ∞ ¹     424.0 ± ∞ ¹   -8.62% (p=0.008 n=5)
EofParse/test-5-8        488.0 ± ∞ ¹     440.0 ± ∞ ¹   -9.84% (p=0.008 n=5)
EofParse/test-6-8       1064.0 ± ∞ ¹    1016.0 ± ∞ ¹   -4.51% (p=0.008 n=5)
EofParse/test-7-8     1033.8Ki ± ∞ ¹   910.3Ki ± ∞ ¹  -11.95% (p=0.008 n=5)
EofParse/test-8-8        934.0 ± ∞ ¹     368.0 ± ∞ ¹  -60.60% (p=0.008 n=5)
EofParse/test-9-8        934.0 ± ∞ ¹     368.0 ± ∞ ¹  -60.60% (p=0.008 n=5)
EofParse/test-10-8      1031.0 ± ∞ ¹     472.0 ± ∞ ¹  -54.22% (p=0.008 n=5)
EofParse/test-11-8      1031.0 ± ∞ ¹     472.0 ± ∞ ¹  -54.22% (p=0.008 n=5)
EofParse/test-12-8     442.7Ki ± ∞ ¹   369.0Ki ± ∞ ¹  -16.64% (p=0.008 n=5)
EofParse/test-13-8      1697.0 ± ∞ ¹     472.0 ± ∞ ¹  -72.19% (p=0.008 n=5)
EofParse/test-14-8      3557.0 ± ∞ ¹     568.0 ± ∞ ¹  -84.03% (p=0.008 n=5)
EofParse/test-15-8      3557.0 ± ∞ ¹     984.0 ± ∞ ¹  -72.34% (p=0.008 n=5)
EofParse/test-16-8     12.48Ki ± ∞ ¹   10.69Ki ± ∞ ¹  -14.34% (p=0.008 n=5)
EofParse/test-17-8    29.664Ki ± ∞ ¹   3.297Ki ± ∞ ¹  -88.89% (p=0.008 n=5)
EofParse/test-18-8   107.798Ki ± ∞ ¹   4.789Ki ± ∞ ¹  -95.56% (p=0.008 n=5)
EofParse/test-19-8       408.0 ± ∞ ¹     408.0 ± ∞ ¹        ~ (p=1.000 n=5) ²
geomean                3.065Ki         1.472Ki        -51.96%
¹ need >= 6 samples for confidence interval at level 0.95
² all samples are equal

                   │  eof.bench.1  │              eof.bench.2              │
                   │   allocs/op   │  allocs/op    vs base                 │
EofParse/test-1-8      9.000 ± ∞ ¹    9.000 ± ∞ ¹        ~ (p=1.000 n=5) ²
EofParse/test-2-8      12.00 ± ∞ ¹    14.00 ± ∞ ¹  +16.67% (p=0.008 n=5)
EofParse/test-3-8      16.00 ± ∞ ¹    14.00 ± ∞ ¹  -12.50% (p=0.008 n=5)
EofParse/test-4-8      16.00 ± ∞ ¹    14.00 ± ∞ ¹  -12.50% (p=0.008 n=5)
EofParse/test-5-8      18.00 ± ∞ ¹    14.00 ± ∞ ¹  -22.22% (p=0.008 n=5)
EofParse/test-6-8      35.00 ± ∞ ¹    31.00 ± ∞ ¹  -11.43% (p=0.008 n=5)
EofParse/test-7-8     38.28k ± ∞ ¹   28.30k ± ∞ ¹  -26.08% (p=0.008 n=5)
EofParse/test-8-8      35.00 ± ∞ ¹    11.00 ± ∞ ¹  -68.57% (p=0.008 n=5)
EofParse/test-9-8      35.00 ± ∞ ¹    11.00 ± ∞ ¹  -68.57% (p=0.008 n=5)
EofParse/test-10-8     37.00 ± ∞ ¹    14.00 ± ∞ ¹  -62.16% (p=0.008 n=5)
EofParse/test-11-8     37.00 ± ∞ ¹    14.00 ± ∞ ¹  -62.16% (p=0.008 n=5)
EofParse/test-12-8    18.88k ± ∞ ¹   10.71k ± ∞ ¹  -43.29% (p=0.008 n=5)
EofParse/test-13-8     40.00 ± ∞ ¹    14.00 ± ∞ ¹  -65.00% (p=0.008 n=5)
EofParse/test-14-8     80.00 ± ∞ ¹    14.00 ± ∞ ¹  -82.50% (p=0.008 n=5)
EofParse/test-15-8     80.00 ± ∞ ¹    14.00 ± ∞ ¹  -82.50% (p=0.008 n=5)
EofParse/test-16-8    279.00 ± ∞ ¹    22.00 ± ∞ ¹  -92.11% (p=0.008 n=5)
EofParse/test-17-8    739.00 ± ∞ ¹    11.00 ± ∞ ¹  -98.51% (p=0.008 n=5)
EofParse/test-18-8   2091.00 ± ∞ ¹    11.00 ± ∞ ¹  -99.47% (p=0.008 n=5)
EofParse/test-19-8     12.00 ± ∞ ¹    12.00 ± ∞ ¹        ~ (p=1.000 n=5) ²
geomean                93.51          29.15        -68.82%
¹ need >= 6 samples for confidence interval at level 0.95
² all samples are equal

holiman · 2024-09-12T08:11:39Z

core/vm/validate_test.go

+	}
+}
+
+func BenchmarkEOFValidation2(b *testing.B) {


All the benchmark-function in this file appears to be non-functional, should we nuke them or salvage them, @MariusVanDerWijden ?

example

[user@work vm]$ go test . -run - -bench EOFV --- FAIL: BenchmarkEOFValidation validate_test.go:353: callf into non-returning section: section 1 --- FAIL: BenchmarkEOFValidation2 validate_test.go:403: callf into non-returning section: section 1 --- FAIL: BenchmarkEOFValidation3 validate_test.go:452: callf into non-returning section: section 1

I will try to salvage

MariusVanDerWijden

LGTM

cmd/eofdump/eofparser.go

core/vm/validate_linear.go

fjl · 2024-09-26T09:09:55Z

Let's move the new utility commands into cmd/evm. It's better to use an existing command.

fjl · 2024-09-26T09:11:36Z

Would also be nice to remove some complexity in the validation code by moving statements out of if

if have, want := currentStackMax, int(metadata[section].outputs)+int(newSection.inputs)-int(newSection.outputs); have != want {

should become

wantStack := int(metadata[section].outputs)+int(newSection.inputs)-int(newSection.outputs)
if currentStackMax != wantStack {

And perhaps we can find a way to reduce conversions.

holiman · 2024-09-26T12:42:12Z

Let's move the new utility commands into cmd/evm. It's better to use an existing command.

Done

Would also be nice to remove some complexity in the validation

Done

Also fixed up the eofdump command to print nicer output, and read from stdin if --hex is not given. Also made the commands use the std logging facilities more, not fmt.Printf so much (Note though: for eofparse it's part of the spec that it prints out "OK" or "err..." on stdout, so it can be used to compare across clients)

holiman · 2024-09-26T12:43:43Z

cmd/evm/eofparse.go

-			executedTests atomic.Int32
-			passedTests   atomic.Int32
+			file          = ctx.String(refTestFlag.Name)
+			executedTests int


filepath.Walk is sequential, there was no need to use atomics here

holiman · 2024-09-26T12:44:18Z

cmd/evm/eofparse.go

-				executedTests.Add(int32(total))
-				return err
-			})
+		err := filepath.Walk(file, func(path string, info fs.FileInfo, err error) error {


Also, filepath.Walk behaves fine if you point it directly at a file, as opposed to a dir. So no need to special case that, like the code did earlier

holiman · 2024-09-26T12:54:24Z

`evm eofdump`

Example invocations of eofdump:

$ go run ./cmd/evm/ eofdump  --hex 0xef000101000402000100010400020000800000feaabb 
Header
  - EOFMagic: ef00
  - EOFVersion: 01
  - KindType: 01
  - TypesSize: 0004
  - KindCode: 02
  - KindData: 04
  - DataSize: 0002
  - Number of code sections: 1
    - Code section 0 length: 0001
  - Number of subcontainers: 0
Body
  - Type 0: 00800000
  - Code section 0: 0xfe
  - Data: 0xaabb

$ yes "0xef000101000402000100010400020000800000feaabb" | head -n2 | go run ./cmd/evm/ eofdump  
Header
  - EOFMagic: ef00
  - EOFVersion: 01
  - KindType: 01
  - TypesSize: 0004
  - KindCode: 02
  - KindData: 04
  - DataSize: 0002
  - Number of code sections: 1
    - Code section 0 length: 0001
  - Number of subcontainers: 0
Body
  - Type 0: 00800000
  - Code section 0: 0xfe
  - Data: 0xaabb

Header
  - EOFMagic: ef00
  - EOFVersion: 01
  - KindType: 01
  - TypesSize: 0004
  - KindCode: 02
  - KindData: 04
  - DataSize: 0002
  - Number of code sections: 1
    - Code section 0 length: 0001
  - Number of subcontainers: 0
Body
  - Type 0: 00800000
  - Code section 0: 0xfe
  - Data: 0xaabb

`evm eofparse`

Example invocation of eofparse

$ cat ./cmd/evm/testdata/eof/eof_corpus_1.txt | head -n10 | go run ./cmd/evm eofparse 
err: invalid container size: have 24, want 23
err: invalid container size: have 21, want 20
err: invalid container size: have 22, want 21
err: invalid max stack height in code section 0: have 0, want 48
err: invalid max stack height in code section 0: have 0, want 48
err: invalid container size: have 53, want 52
err: truncated immediate: op PUSH2, pos 1
err: invalid container size: have 38, want 37
err: invalid container size: have 48, want 47
err: invalid container size: have 48, want 47

core/vm/eof_control_flow.go

cmd/eofdump: benchmarks of eof validation speeds core/vm: move eof instructions to separate file core/vm: unexport fields Co-authored-by: lightclient <lightclient@protonmail.com> Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de> Co-authored-by: Danno Ferrin <danno.ferrin@shemnon.com>

core/vm: some clarifications in the eof code core/vm: clarifications + minor speedup core/vm: clarifications + lint + minor speedup core/vm, core/asm: support eof in asm instruction iteration core/vm: comment out unused core/vm: remove gasfunctions

…analysis Using the immediates-map in jumpdest analysis leads to less error prone code (only one place to update it) and it improves the worst case from ``` BenchmarkJumpdestOpEOFAnalysis/EOFCREATE-24 724 1471215 ns/op 835.23 MB/s ``` to ``` BenchmarkJumpdestOpEOFAnalysis/EOFCREATE-24 1710 693609 ns/op 1771.60 MB/s ``` which is a quite significant 2x improvement and brings them in line with the average case

@shemnon

…sts, last fix Changes include: - unexporting errors, removing error-to-code mapping - new test vectors from execution-spec-tests v eip7692@v1.1.1 - remaining fix from @shemnon in MariusVanDerWijden#56 - core/vm: address review-comments - simplify code - cmd/evm: move eofdump/eofparse into `evm` binary - Also makes eofdump read from stdin if hex is not provided, and makes the output of eofdump a bit more eye-friendly. - core/vm: refactor check in eof control-flow validation - core/vm: refactor some control flow checks for readability

@lightclient

The bulk of this PR is authored by @lightclient , in the original EOF-work. More recently, the code has been picked up and reworked for the new EOF specification, by @MariusVanDerWijden , in ethereum#29518, and also @shemnon has contributed with fixes. This PR is an attempt to start eating the elephant one small bite at a time, by selecting only the eof-validation as a standalone piece which can be merged without interfering too much in the core stuff. In this PR: - [x] Validation of eof containers, lifted from ethereum#29518, along with test-vectors from consensus-tests and fuzzing, to ensure that the move did not lose any functionality. - [x] Definition of eof opcodes, which is a prerequisite for validation - [x] Addition of `undefined` to a jumptable entry item. I'm not super-happy with this, but for the moment it seems the least invasive way to do it. A better way might be to go back and allowing nil-items or nil execute-functions to denote "undefined". - [x] benchmarks of eof validation speed --------- Co-authored-by: lightclient <lightclient@protonmail.com> Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de> Co-authored-by: Danno Ferrin <danno.ferrin@shemnon.com>

@lightclient

The bulk of this PR is authored by @lightclient , in the original EOF-work. More recently, the code has been picked up and reworked for the new EOF specification, by @MariusVanDerWijden , in ethereum#29518, and also @shemnon has contributed with fixes. This PR is an attempt to start eating the elephant one small bite at a time, by selecting only the eof-validation as a standalone piece which can be merged without interfering too much in the core stuff. In this PR: - [x] Validation of eof containers, lifted from ethereum#29518, along with test-vectors from consensus-tests and fuzzing, to ensure that the move did not lose any functionality. - [x] Definition of eof opcodes, which is a prerequisite for validation - [x] Addition of `undefined` to a jumptable entry item. I'm not super-happy with this, but for the moment it seems the least invasive way to do it. A better way might be to go back and allowing nil-items or nil execute-functions to denote "undefined". - [x] benchmarks of eof validation speed --------- Co-authored-by: lightclient <lightclient@protonmail.com> Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de> Co-authored-by: Danno Ferrin <danno.ferrin@shemnon.com>

@lightclient

The bulk of this PR is authored by @lightclient , in the original EOF-work. More recently, the code has been picked up and reworked for the new EOF specification, by @MariusVanDerWijden , in #29518, and also @shemnon has contributed with fixes. This PR is an attempt to start eating the elephant one small bite at a time, by selecting only the eof-validation as a standalone piece which can be merged without interfering too much in the core stuff. In this PR: - [x] Validation of eof containers, lifted from #29518, along with test-vectors from consensus-tests and fuzzing, to ensure that the move did not lose any functionality. - [x] Definition of eof opcodes, which is a prerequisite for validation - [x] Addition of `undefined` to a jumptable entry item. I'm not super-happy with this, but for the moment it seems the least invasive way to do it. A better way might be to go back and allowing nil-items or nil execute-functions to denote "undefined". - [x] benchmarks of eof validation speed --------- Co-authored-by: lightclient <lightclient@protonmail.com> Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de> Co-authored-by: Danno Ferrin <danno.ferrin@shemnon.com>

holiman requested review from karalabe and rjl493456442 as code owners September 11, 2024 08:02

holiman force-pushed the eof-validation branch from e1feb9c to 6ebbbd9 Compare September 11, 2024 08:07