Commit graph

8 commits

Author SHA1 Message Date
Harald Hoyer
95b6a2d70a
refactor(verify-era-proof-attestation): replace watch channel with CancellationToken
Refactored stop signal handling in all components to use `tokio_util::sync::CancellationToken` instead of `tokio::sync::watch`.

- Improved cancellation logic by leveraging `CancellationToken` for cleaner and more efficient handling.
- Updated corresponding dependency to `tokio-util` version `0.7.14`.
2025-04-07 08:54:00 +02:00
Harald Hoyer
2605e2ae3a
refactor(verify-era-proof-attestation): modularize and restructure proof verification logic
- Split `verify-era-proof-attestation` into modular subcomponents for maintainability.
- Moved client, proof handling, and core types into dedicated modules.
2025-04-04 17:05:30 +02:00
Harald Hoyer
f8bd9e6a08
chore: split-out vault code from teepot in teepot-vault
Signed-off-by: Harald Hoyer <harald@matterlabs.dev>
2025-03-06 09:47:51 +01:00
Harald Hoyer
45309e58f4
chore: cargo deps update
with code fixes for the new versions.

Signed-off-by: Harald Hoyer <harald@matterlabs.dev>
2025-02-10 15:44:16 +01:00
Patryk Bęza
9bf40c9cb9
feat(tee): use hex deserialization for RPC requests
Following Anton's suggestion, we have switched to hex serialization for
API/RPC requests and responses. Previously, we used default JSON
serialization for Vec<u8>, which resulted in a lengthy comma-separated
list of integers.

This change standardizes serialization, making it more efficient and
reducing the size of the responses. The previous format, with a series
of comma-separated integers for pubkey-like fields, looked odd.

Then:
```
curl -X POST\
     -H "Content-Type: application/json" \
     --data '{"jsonrpc": "2.0", "id": 1, "method": "unstable_getTeeProofs", "params": [491882, "Sgx"] }' \
        https://mainnet.era.zksync.io
{"jsonrpc":"2.0","result":[{"attestation":[3,0,2,0,0,0,0,0,10,<dozens of comma-separated integers here>
```

Now:
```
$ curl -X POST \
       -H "Content-Type: application/json" \
       --data '{"jsonrpc": "2.0", "id": 1, "method": "unstable_getTeeProofs", "params": [1, "sgx"] }' \
          http://localhost:3050
{"jsonrpc":"2.0","result":[{"l1BatchNumber":1,"teeType":"sgx","pubkey":"0506070809","signature":"0001020304","proof":"0a0b0c0d0e","provedAt":"2024-09-16T11:53:38.253033Z","attestation":"0403020100"}],"id":1}
```

This change needs to be deployed in lockstep with:
https://github.com/matter-labs/zksync-era/pull/2887.
2024-09-18 14:10:21 +02:00
Harald Hoyer
7743c1321a
chore: prepare release tags
* set `publish = false` for multiple Cargo.toml files
* cargo update
* fix taplo.toml
* sort `workspace.dependencies`
* add `cargo-release` to nix shell

Signed-off-by: Harald Hoyer <harald@matterlabs.dev>
2024-09-16 16:14:26 +02:00
Patryk Bęza
4fcaaa7398
feat(verify-era-proof-attestation): continuous mode with attestation policies
This PR introduces TEE Prover continuous mode with attestation policies.

Attestation policies are a set of criteria that determine whether an SGX
attestation should be considered valid or invalid. In practice, this
means checking against a specified set of mrsigners, mrenclaves, and TCB
levels. If the attestation’s mrenclave/mrsigner/TCB levels matches those
in the provided --sgx-mrenclaves/--sgx-mrsigners/--sgx-allowed-tcb-levels,
we treat the attestation as successfully verified. Otherwise, the
attestation is considered invalid.

The --continuous mode for the TEE Prover allows it to run continuously,
verifying new batches exposed by the node's RPC API in real-time.

To try it out, run the following commands:

    $ nix build -L .#container-verify-era-proof-attestation-sgx
    $ export IMAGE_TAG=$(docker load -i result | grep -Po 'Loaded image.*: \K.*')
    $ docker run  -i --init --rm $IMAGE_TAG --continuous 11505 --rpc https://sepolia.era.zksync.dev --sgx-allowed-tcb-levels Ok,SwHardeningNeeded --log-level debug
    $ docker run  -i --init --rm $IMAGE_TAG --batch 11509 --rpc https://sepolia.era.zksync.dev --sgx-allowed-tcb-levels Ok,SwHardeningNeeded --log-level debug
2024-09-13 19:34:37 +02:00
Patryk Bęza
5e4b8901b0
feat(verify-attestation): RPC attestation and batch signature verification binary
This is another variant of the binary tool for verifying attestation and
the signature of a given batch. Unlike the existing tool, this variant
does not require you to provide two separate files—one for the
attestation and one for the signature. Instead, it automatically fetches
both from the RPC node.

Unfortunately, after discussing with @popzxc, we found that there is no way
to reuse the RPC client because our published crates on crates.io are
outdated and do not include the recently merged TEE-specific code
changes. To be fixed in the future.
2024-08-30 12:14:55 +02:00