Skip to content
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

Closed
Brechtpd opened this issue May 9, 2023 · 6 comments
Closed

feat(protocol): Even more basic multi-prover with PoA #13731

Brechtpd opened this issue May 9, 2023 · 6 comments

Comments

@Brechtpd
Copy link
Contributor

Brechtpd commented May 9, 2023

Simplify oracle/system prover system, in a way that will be compatible with #13693:

  • Blocks need a zk proof + a signature (currently just one we generate and share somehow)
  • For proofs that need to be skipped only a valid signature is required, the zk proof verification is skipped. Here we force the proof time to be the target proof time to not impact the base fee calculation.

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.

@dantaik
Copy link
Contributor

dantaik commented May 11, 2023

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?

@Brechtpd
Copy link
Contributor Author

Brecht, do you know what will need to be verified onchain for SGX?

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.

Will the protocol be aware of the existence of multiple clients and has to handle each differently?

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.

@adaki2004
Copy link
Contributor

Simplify oracle/system prover system, in a way that will be compatible with #13693:

* Blocks need a zk proof + a signature (currently just one we generate and share somehow)

So block can be verified only if have both ? (Are we talking about testnet too ?).

* For proofs that need to be skipped only a valid signature is required, the zk proof verification is skipped. Here we force the proof time to be the target proof time to not impact the base fee calculation.

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 ?

  1. Can skip 9 real proofs and require 1 (for every 10 block) - but oracle proofs are not verifiable but have to be overwritten.
    9 signatures coming from our node - and they verifiable afterwards or still needs (overwriteable) oracle proofs OR real proofs ?
  2. System proof is verifiable (but having cool down time to be able to overwrite it): How we signal, this block is OK - dont need to overwrite it ? (Maybe with a different node's signature?)

@adaki2004
Copy link
Contributor

Meeting minutes:

How to rearrange / map out this same functionality ? Oracle: throw away, System: throw away
When a prover wants to prove:
1. It queries the signature from the provider
2. Provides with normal signature (signature: same but graffiti and prover, but that to be double checked so just go with them first !).

Structure: array of proofs 1.: normal, 2: signature

Modify ForkChoice: allow some address to modify FK directly - and then lock it. (Only non-verified proofs). (Failsafe mechanism only).

@dong77
Copy link
Contributor

dong77 commented May 15, 2023

My understanding is that we need 3 types of proofs (TypedProof):

  1. ZKP
  2. SignatureProof
  3. SuperSignatureProof

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.

@Elpadronegeorge
Copy link

It would be easy to interact with less proof-tie time, the relayer should be able to interact directly .

@dantaik dantaik moved this from 🏗 In progress to 📝 Todo in Taiko Project Board Jul 15, 2023
@github-project-automation github-project-automation bot moved this from 📝 Todo to ✅ Done in Taiko Project Board Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

6 participants