Hyperfridge Milestone 1

[wstrametz]

Milestone Delivery Checklist

• The milestone-delivery-template.md has been copied and updated.
• This pull request is being made by the same account as the accepted application.
• I have disclosed any and all sources of reused code in the submitted repositories and have done my due diligence to meet its license requirements.
• In case of acceptance, an invoice must be submitted and the payment will be transferred to the Polkadot/fiat account provided in the application.
• The delivery is according to the Guidelines for Milestone Deliverables.

Link to the application pull request: w3f/Grants-Program#2096

[wstrametz]

Hi - @takahser - is there still something missing from our side? Its ready for review - we are alredy working on the next milestone and would be happy to do the review. Thx a lot, Walter

[takahser]

@wstrametz sorry for the delay, I'm still working on the initial review. It's taking a bit longer since I need to get up to speed with some of the ZK tech you're using (e.g. Risc0), but I'm planning to give you feedback either today or tomorrow.
Sure, feel free to work on the next milestone in the meanwhile. 👍

[takahser]

@wstrametz thanks for your patience, I've finally completed this first evaluation iteration. You can find my evaluation report here. Basically, some parts of the code didn't pass and adding a few more inline comments might make sense. LMK if you have any questions.

[wasabrot]

@wstrametz thanks for your patience, I've finally completed this first evaluation iteration. You can find my evaluation report here. Basically, some parts of the code didn't pass and adding a few more inline comments might make sense. LMK if you have any questions.

Hi @takahser - just a quick note, we are on it since a couple of days and looking into a solution with multi-platform docker images with Rust-Zero to have a good MacOs "experience", but it takes a bit of time. Thanks a lot, walter

[takahser]

@wasabrot ok no problem, take your time. Thanks for the update!

[keeganquigley]

pinging @wstrametz for update :)

[wstrametz]

pinging @wstrametz for update :)

yes - 100 % aware; just this morning I pinged Dastan to do final tests with the macos images - will merge likely until upcoming Monday

[wstrametz]

pinging @wstrametz for update :)

yes - 100 % aware; just this morning I pinged Dastan to do final tests with the macos images - will merge likely until upcoming Monday

Hi @keeganquigley - the macos Image works, but the local build on macos takes forever and consumes massive storge for building. Rootcause is the installation of risczero toolkit. They provide binary install via binstall just for linux; on macos it triggers compilation automaically. Thats why we are having hard time getting the build into github actions, because this causes lot of runtime problems - splitting the build in multiple stages does not help. Would you be OK just to test with the docker images on macos? Thx

[keeganquigley]

Thanks for the update @wstrametz I will let @takahser answer this since he is doing the evaluation.

[takahser]

@wstrametz thanks for the update, I'm planning to give you feedback early next week.

[takahser]

@wstrametz is it normal that running the integration tests will "not generate valid, secure proofs"?

% docker run --env RISC0_DEV_MODE=true  fridge host test
    WARNING: proving in dev mode. This will not generate valid, secure proofs.
    WARNING: Proving in dev mode does not generate a valid receipt. Receipts generated from this process are invalid and should never be used in production.
    Commitment {
        hostinfo: "host:main",
        iban: "CH4308307000289537312",
        pub_bank_pem: "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvizgj/ppKl2zYD4mxsjs\no+4ji+wx9AMQFpKrdQ9AHFQL347BYicn0zvnnoDAwL5D012Z1EYJ+Zz1GIt83li4\nbBS7qnT9q0htl6x8pVszXyi7vA9qOWWICmp6jp/zO+nVWKEIkDekKW0uBwbXMsA3\nh+7yAPJapUwLNAmG2GsXQp1HWOKZkTFdDBG7nJJ5scc0AiwRjB2btvvNQnG+BGz4\n7a3i290J91Fjbgr+0BC2vhi3dHjDDDFw3y/+8Icjapi7UPhX9HDNum5lQzwvYECj\n3KsG7P7V2c3GRQdMA6t4kSub/d9AGpI5bRp4Iz+LaEWDFm4yN0YMK5sl9An8YPPg\ncwIDAQAB\n-----END PUBLIC KEY-----\n",
        pub_witness_pem: "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAngnoLec3QWzHkgGW7Uj2\ni2yFp86KDuKrFUus6pXHJmCnZILTAOiKzNCAB5qIDBwa9h50/OTZ6pv1X5mgVM2S\nPNKvZoUrfOU6Jg5m1b3GkyLj/3AfdS+nJbjUXFlyMWIi5c26WvvW2FsqsEoehAGF\nQpurZV6QKWSKEk16TKoI2kcD8sEAUb5TVwx+7D5kz8ZgUX0g/KqM+o2kUxBiSKdS\n1p9CDEhwWWe0MR0ja4Eh6+pFyIIjVsrybB9ufBuuBC31redFGZ4nBX43xts5Do6Z\n63U1lX15gNiJtVxldBfKm9o2ofPMxdPu3KXEg7f3Zm2n9eA1FxUKurwac7a31V8d\nLwIDAQAB\n-----END PUBLIC KEY-----\n",
        pub_client_pem: "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvlbtES+ljC3udEneaTyf\nXmLv4l4hwuXSEfCIYUfVZiDHzdeGK8wJ2gRSucBsxrr2NESdHuIrEPmDhWHnE4D6\nJy61WuL8QWVuiBTZFtSCgRIyeI9ojNTqq0vmO7Wj1Y9FYdIZ/iN8h9xOcuuQkja7\n2oTuM/aqGlycTbJSoioBkv5UbbcDz4MZ0Si9RAW3D+4IWePfKieTEeT3HYnBBChL\nS4pC1si44xz9vqJcj7zAOlpgaJ+vEhL3f/e4qYrb23R9KBY4Ui6UA1exMmWPbMs7\nni4bs93yyiNtpQlQ9sOV6HoPooKPHIufk/jlFdOIhB4m1XtErHIGSRp7Bt2NtFab\nHQIDAQAB\n-----END PUBLIC KEY-----\n",
        stmts: [
            Stmt {
                elctrnc_seq_nb: "247",
                fr_dt_tm: "2023-11-29T00:00:00",
                to_dt_tm: "2023-11-29T00:00:00",
                amt: "31709.14",
                ccy: "CHF",
                cd: "OPBD",
            },
            Stmt {
                elctrnc_seq_nb: "248",
                fr_dt_tm: "2023-11-30T00:00:00",
                to_dt_tm: "2023-11-30T00:00:00",
                amt: "31709.09",
                ccy: "CHF",
                cd: "OPBD",
            },
        ],
    }%

Also, how does running this test compare to running the following native tests:

• Host tests: RISC0_DEV_MODE=true cargo test -- --nocapture
• Running tests with a new ebics response; xml_file=myrequest.xml ./createTestResponse.sh

[takahser]

@wstrametz I've accepted the Docker deliverables, see my updated eval. However, please clarify the testing deliverables, see my previous comment.

[wstrametz]

@wstrametz I've accepted the Docker deliverables, see my updated eval. However, please clarify the testing deliverables, see my previous comment.

Hi @takahser - thx a lot for your review!

Is it "normal"? Yes, because we are using RISC0_DEV_MODE=true. This is a flag provided by the risc0 framework to do everything but the CPU intense computation when creating the Stark, and accepting a "fake" Stark when validating. On my Laptop (brand new lenovo legion 5) it takes 200 minutes to produce a real Stark. Its easy to switch on or off, so we left it off because we are at Milestone 1 and switching it on will not test or prove any work done on our side. There is also a note in the README.md of the project about that.

But we experimented quite a lot with dev-mode off to learn about the runtime behaviour - details here. Apart from measurements, we we learned that you can not run it with normal gaming hardware acceleration on e.g. Geforce 4070 8GB due to lack of memory. Anyway, smaller samples showed a speed-up of around 80-100x on consumer hardware. Note that Risc0 provides an accelerated AWS machine as-a-service (risc0 bonsai) which most likely will offer more acceleration.

To your next question - how do tests compare?

The docker images use pre-made test data, configs and commands, e.g. having RISC0_DEV_MODE turned on - pretty much all "hardcoded" so that is easy to spin up and do shakedown tests. Running it natively allows you to turn off the Dev-Mode and also to use other risc0 features like hardware acceleration. The third tests are about changing test data and shows what actually happens when the data arrives at the backend which triggers the generation of a new proof. This part covers the preparation of the input data, where we off-load computation as much as possible. For example we decrypt payload outside of Stark generation and provide it as private input, because encrypting payload and comparing it with provided backend data (instead of just de-crypting) saved about 70 % computation time, because encrypting the payload with the session key is much cheaper then decrypting.

Hope this answers your questions :)

Thx, Walter

[wstrametz]

Hi - @takahser - just pinging, was my comment above OK? Thx Walter

[takahser]

@wstrametz I'll get back to you on Monday.

[takahser]

@wstrametz thx for your patience. I've updated my eval again. The only thing missing is the published crate.

[wstrametz]

Hello @takahser thx for feedback - Verifier crate is here: cates.io now; this crate will be later used in the OCW to verify the JSON-STARK-Proof. Thanks for pointing this out, and hope that is OK, Walter

[takahser]

@wstrametz thanks, I've approved it. Final eval can be found here.

[github-actions]

🪙 Please fill out the invoice form in order to initiate the payment process. Thank you!

[github-actions]

Congratulations on completing the first milestone of this grant! As part of the Grants Program, we want to help grant recipients acknowledge their grants publicly. To that end, we've created a badge for projects that successfully deliver their first milestone. Please use the badge only in reference to the work that has been completed as part of this grant, so please do not display it on your team or project's homepage unless accompanied by a short description of the grant. Furthermore, you're now welcome to announce the grant publicly. Please remember to observe the foundation's guidelines in doing so. If you haven't already, reach out to [email protected] for feedback on your announcement and cross-promotion.

Thank you for your contribution, and good luck! If you have any remaining milestone, let us know if you encounter any delays by leaving a comment on the application PR or submitting an amendment.

[RouvenP]

hi @wstrametz we sent the payment today