You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: