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: Keep a extended proposeblock API with assignment check in proverset to support proposer and prover separation #17760

Open
1 task done
hugo-blue opened this issue Jul 6, 2024 · 0 comments

Comments

@hugo-blue
Copy link

hugo-blue commented Jul 6, 2024

Describe the feature request

Background
We've observed the latest protocol change in the mainnet, which is also described in https://github.com/taikoxyz/taiko-mono/issues.

With the standard proposeblock API in proverset (with onlyProver property), the proposer and prover must be the same. Now, even though we have set up a separate proverset contract, the community proposer couldn't join and use our prover pool permissionlessly.

We aim to establish a prover pool to allow community proposers to join, which will be beneficial for decentralizing proposers. It's not feasible for every proposers to run an SGX prover, especially with the upcoming multi-provers including zk-prover. Therefore, we believe that having a prover pool to assist people in running proposer only by connecting to our prover pool is beneficial for Taiko project.

Proposal
We propose to maintain an extended proposeblock API, which can verify whether the proposer has the correct assigned prover and the corresponding signature. This means we hope to keep part of the protocol design of the previous version. Then, we can have two APIs for proposing, and the prover pool can utilize the extended API.

Is this the necessary approach?
Alternatively, a solution could be for a prover pool, such as ZKPool, to customize the proverset to support this extended API. The drawback of this approach is that ZKPool also has to provide a customized taiko-client. It will pose an additional challenge for proposers, as they would need to learn and trust ZKPool's client.

Therefore, we hope Taiko could maintain such an extended proposeblock API, while also ensuring that the official taiko-client is compatible with such an API. Then, proposers who wish to use a 3rd party prover pool can set a flag in taiko-client to call the extended proposeblock API.

The Pseudocode code of the extended API will be like this:

function proposeBlockEx(
bytes calldata _params,
bytes calldata _txList
)
external
payable
// onlyProver -> Remove this to make proposeBlock permissionless by anyone.
nonReentrant
{
// Check if proposer has valid signature from prover:
// 1. decode data
TaikoData.BlockParamsEx params = abi.decode(_params, (TaikoData.BlockParamsEx));
// 2. get assignment from decoded data
Assignment assignment = getAssignment(params);
// 3. calculate signatured hash
bytes32 hash = hashAssignment(assignment, msg.sender, params.blobHash);
// 4. check if the assigned prover is within our prover list && signer is the assigned prover
if (!isProver[params.assignedProver] && !params.assignedProver.isValidSignatureNow(hash, assignment.signature))
{
revert NOT_ASSIGNED_BY_PROVER();
}
ITaikoL1(taikoL1()).proposeBlock(_params, _txList);

Spam policy

  • I verify that this issue is NOT SPAM and understand SPAM issues will be closed and reported to GitHub, resulting in ACCOUNT TERMINATION.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants