Commit graph

7 commits

Author SHA1 Message Date
arnaucube
423605f867
Featurize middleware types that are actually defined by the backend (#94)
At the middleware we were defining some types that actually are dependant on the
backend no matter how we define them in the middleware.

For example, we were hardcoding the `Hash` and `Value` types and their related
behaviour (eg. `.to_fields()`) to be based on the length of 4 field elements,
but that's not a choice of the middleware, and in fact this is determined by the
backend itself. On the same time, those types and related methods do not belong
to the backend, since conceptually they are part of the middleware reasoning.

The intention of this PR is not to prematurely abstract the library, but to
avoid inconsistencies where a type or parameter is defined in the middleware to
have certain carachteristic and later in the backend it gets used differently.
The idea is that those types and parameters (eg. lengths) have a single source
of truth in the code; and in the case of the "base types" (hash, value, etc)
this is determined by the backend being used under the hood, not by a choice of
the middleware parameters.

The idea with this approach, is that the frontend & middleware should not need
to import the proving library used by the backend (eg. plonky2, plonky3, etc).

As mentioned earlier, the `Hash` and `Value` types are types belonging at the
middleware, and is the middleware who reasons about them, but depending on the
backend being used, the `Hash` and `Value` types will have different sizes. So
it's the backend being used who actually defines their nature under the hood.
For example with a plonky2 backend, these types will have a length of 4 field
elements, whereas with a plonky3 backend they will have a length of 8 field
eleements.

Note that his approach does not introduce new traits or abstract code, just
makes use of rust features to define 'base types' that are being used in the
middleware.
2025-02-27 14:15:31 +01:00
arnaucube
e074d34078
Extend merkletree spec, init SignedPod section, add typos checker in CI (#31)
Extend merkletree spec, init SignedPod section, add typos checker in CI

- extend merkletree spec, converting old hand-drawn diagrams to drawio
  diagrams, and adding new diagrams (related: #6)
- init SignedPod section (related: #2)
- initial draft of the types dictionary, set, array (related: #26)
- add typos checker in CI (and correct the ones that were detected)

Note on drawio diagrams: each image file contains the metadata to edit the diagram in the draw.io website.
2025-02-05 16:37:16 +01:00
arnaucube
5b455acbd6
add initial MerkleTree implementation (#13)
Add initial MerkleTree implementation, which is a wrapper on top of
Plonky2's MerkleTree, with the idea that the future iteration will
replace it by the MerkleTree specified at
https://0xparc.github.io/pod2/merkletree.html .
2025-02-03 18:03:45 +01:00
arnaucube
62a140569e
add initial spec of the merkletree (#10)
* add initial spec of the merkletree

* update gh workflow to work with the new book path

* rephrase non-inclusion section
2025-01-31 17:21:18 +01:00
ef3dd308e8
feat: move code here (#11) 2025-01-31 16:20:57 +01:00
arnaucube
5bb98e2645 add gh-pages action to autodeploy rendered site 2025-01-31 10:33:38 +01:00
arnaucube
ceeddba2b5 init repo, add initial structure 2025-01-30 17:32:09 +01:00