1- # Trigger new build:
1+ # op-program-svc
2+
3+ This small service is a temporary measure until we come up with a better way
4+ of generating/serving prestate files based on chain information.
5+
6+ # API
7+
8+ The API is intentionally extremely simple:
9+ - ` POST / ` : generate new prestates from provided inputs
10+ - ` GET /HASH.(bin.gz|json) ` : get prestate data
11+ - ` GET /info.json ` : get prestates mapping
12+
13+ The idea is for this service to be basically a function
14+ (chains_specs, deptsets) -> prestates.
15+
16+ In the future, we definitely want to replace the implementation of that
17+ function (see implementation notes below)
18+
19+ ## Trigger new build:
20+
21+ Example using curl
222
323```
424$ curl -X POST -H "Content-Type: multipart/form-data" \
@@ -9,3 +29,30 @@ $ curl -X POST -H "Content-Type: multipart/form-data" \
9291030 http://localhost:8080
1131```
32+
33+ ## Retrieve prestates mapping
34+
35+ ```
36+ $ curl -q http://localhost:8080/info.json
37+ {
38+ "prestate": "0x03f4b7435fec731578c72635d8e8180f7b48703073d038fc7f8c494eeed1ce19",
39+ "prestate_interop": "0x034731331d519c93fc0562643e0728c43f8e45a0af1160ad4c57c4e5141d2bbb",
40+ "prestate_mt64": "0x0325bb0ca8521b468bb8234d8ba54b1b74db60e2b5bc75d0077a0fe2098b6b45"
41+ }
42+ ```
43+
44+ ## Implementation notes
45+
46+ Unfortunately, op-program-client relies on embedded (using ` //go:embed ` )
47+ configuration files to store unannounced chain configs.
48+
49+ This means that in the context of devnets, we need to store the configs
50+ (which are available only mid-deployment) into the ** source tree** and
51+ trigger a late build step.
52+
53+ So effectively, we need to package the relevant part of the sources into
54+ a container, deploy that one alongside the devnet, and run that build step
55+ on demand.
56+
57+ This is ugly, unsafe, easy to run a DOS against,... we need to do better.
58+ But for now this is what we have.
0 commit comments