search

taikoxyz / raiko

Multi-proofs for Taiko. SNARKS, STARKS and Trusted Execution Enclave. Our previous ZK-EVM circuits are deprecated.
Apache License 2.0
124 stars 91 forks source link

Make Docker container work again! #102

Closed pbeza closed 7 months ago

pbeza commented 7 months ago

@smtmfft @johntaiko @Brechtpd The SGX Docker container seems to be running fine now (howto; I tested it using prove_block.sh). Feel free to review the code & test Raiko's SGX direct mode (a.k.a. simulation mode) the way you usually do without using Docker container. I mostly run it with a Docker container, so I might have messed something up with the simulation mode. Let's merge this once you confirm everything works well, just to make sure this PR doesn't get out of sync again.

pbeza commented 7 months ago

Once you become more familiar with launching the container, we can think about adding and testing other provers to the Docker image. This will make it much easier for @davidtaikocha to deploy new prover instances with k8s if he's going to handle DevOps stuff for the provers' infrastructure.

Brechtpd commented 7 months ago

How hard would it be to add CI testing of the docker image (generated automatically with some accounts owned by Taiko)? Because running the docker requires following a guide currently (so nobody working on raiko will normally not do that because it takes quite a while to set up, and then still requires SGX to actually run), it will be hard to keep both the docker and SGX working without some good automatic testing I'm afraid.

smtmfft commented 7 months ago

How hard would it be to add CI testing of the docker image (generated automatically with some accounts owned by Taiko)? Because running the docker requires following a guide currently (so nobody working on raiko will normally not do that because it takes quite a while to set up, and then still requires SGX to actually run), it will be hard to keep both the docker and SGX working without some good automatic testing I'm afraid.

I think with a pre-setup SGX machine like our current devnet machine, it should be easy as we know none sgx init problem exists, so CI can focus on docker image build and deployment. Maybe remote cloud deployment is relatively complex in github CI flow? For testcases, I assume CI is irrelevent with real devnet env (it can, but to make it simple it doesn't), we can just prepare some simple data checking tests for setup/bootstrap/prove, and leave registration & verify to integration test (manually & not have auto one yet....)

pbeza commented 7 months ago

How hard would it be to add CI testing of the docker image (generated automatically with some accounts owned by Taiko)? Because running the docker requires following a guide currently (so nobody working on raiko will normally not do that because it takes quite a while to set up, and then still requires SGX to actually run), it will be hard to keep both the docker and SGX working without some good automatic testing I'm afraid.

I just added a CI test that builds SGX Docker image: https://github.com/taikoxyz/raiko/blob/d66b3d3538becfcd853877f643027e76be625077/.github/workflows/ci.yml#L79-L89 To implement a more comprehensive test that includes running Raiko's SGX prover, we need a machine that is already subscribed to the Intel PCCS service, as Yue correctly pointed out (this is the only manual step we are not able to automate – details here). We can either use an additional, pre-subscribed machine for CI or utilize the one we already have (43.153.195.212).

I'm going to experiment with CI a bit more to ensure that it's not easy to accidentally break the Docker build and deployment process.