File tree Expand file tree Collapse file tree 1 file changed +20
-2
lines changed Expand file tree Collapse file tree 1 file changed +20
-2
lines changed Original file line number Diff line number Diff line change @@ -9,5 +9,23 @@ Due to the SNARK compression, the SNARK proofs take longer to generate and requi
9
9
The worst case latency (described [ here] ( ../design/edge_cases.md ) ) can be evaluated by running the end-to-end benchmark
10
10
for each of the two proofs, and looking at the maximum of the time it took to genereate each proof.
11
11
12
- The numbers we've measured using our [ production configuration] ( ../run/overview.md ) are present in the
13
- [ E2E Benchmarks] ( ./e2e.md ) section.
12
+ The numbers we've measured using our [ production configuration] ( ../run/overview.md ) are further detailed in the
13
+ [ E2E Benchmarks] ( ./e2e.md ) section. They are included below as well for reference:
14
+
15
+ For STARKs:
16
+ ```
17
+ TODO FIXME
18
+ ```
19
+
20
+ For SNARKs:
21
+ ```
22
+ TODO FIXME
23
+ ```
24
+
25
+ ## Blob proofs on Ethereum
26
+
27
+ We're also working on a STARK verifier that could be used alongside Ethereum's new
28
+ [ blob transactions] ( https://eips.ethereum.org/EIPS/eip-4844 ) , which can be used to drastically minimize the gas costs
29
+ for large data such as STARK proofs. This is still experimental and an early work-in-progress, but
30
+ [ preliminary] ( https://github.com/lurk-lab/sphinx/pull/51 ) benchmarks using an Ethereum-friendly hash function and
31
+ compression show that proof generation could be achieved at around 6 to 7 minutes.
You can’t perform that action at this time.
0 commit comments