-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(protocol): Even more basic multi-prover with PoA #13731
Comments
Maybe we should consider the SGX integration when we change the protocol interface. Brecht, do you know what will need to be verified onchain for SGX? Another question regarding SGX is how it impact our multi client strategy. Will the protocol be aware of the existence of multiple clients and has to handle each differently? |
Just an ECDSA signature, which could even sign the same hash that we use as the circuit input. So onchain the approach in this issue or using SGX will look exactly the same, just a signature that needs to be verified.
They will all look the same on-chain, just a signature per node likely (to not increase the load per SGX having to run multiple nodes). We should probably even abstract everything away in verifier contracts, the protocol doesn't need to know if it's a zk-proof or something else. The protocol would just need to know it needs N proofs corresponding to some verifier contracts. |
So block can be verified only if have both ? (Are we talking about testnet too ?).
Ok so basically in such case set the proof time as proofTimeTarget. But are they overwriteable or not ? (I guess we run them not the community (?)). Situations/scenarios we handling now, how would they look like in this setup ?
|
Meeting minutes:
|
My understanding is that we need 3 types of proofs (TypedProof):
A block is verifiable if it has (3) or the combination of (1, 2). Technically, 2, and 3 should be using the same code, but probably different signers. If this is true, I'm not sure what's the best way to express the such logics in our smart contract. |
It would be easy to interact with less proof-tie time, the relayer should be able to interact directly . |
Simplify oracle/system prover system, in a way that will be compatible with #13693:
Then, currently optional because not needed, we just have an additional fail safe mechanism to overwrite and lock a fork choice directly, not going through the normal proving code in proveBlock.
The text was updated successfully, but these errors were encountered: