ed255/pod2
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Organize docs: front and back end; custom predicates. (#96)

Browse source 
* Organize docs: front and back end; custom predicates.

* Whoops forgot to hit save before git commit last time -- delete stuff moved out of values.md

* Update book/src/values.md

---------

Co-authored-by: Ahmad Afuni <root@ahmadafuni.com>
This commit is contained in:
tideofwords 2025-03-02 08:26:29 -08:00 • committed by GitHub
parent 7373b959f6
commit c9f7427967
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
8 changed files with 112 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

17
book/src/front_and_back.md
View file

@ -1,4 +1,17 @@
# Frontend and backend
The frontend is what we want the user to see.
The backend is what we want the circuit to see.
The POD2 system consists of a frontend and a backend, connected by a middleware. This page outlines some design principles for deciding which components go where.
```
user -- frontend -- middleware -- backend -- ZK circuit
```
The frontend is what we want the user to see; the backend is what we want the circuit to see.
## Circuit and proving system
The first implementation of POD2 uses Plonky2 as its proving system. In principle, a future implementation could use some other proving system. The frontend and middleware should not be aware of what proving system is in use: anything specific to the proving system belongs to the backend.
## User-facing types versus in-circuit types
The frontend type system exposes human-readable types to POD developers: strings, ints, bools, and so forth. On the backend, all types are build out of field elements. The middleware should handle the conversion.