for ontake fork, we need a new inclusive_block_number to tell raiko the block number which the block is proposed, so that raiko can parse the correct block propose event. so in next ontake fork, the API will be like:
{
network: taiko_a7,
l1_network: holesky,
block_number: 23,
l1_inclusive_block_number: 87, // name subjects to change for some reasons.
prover: 0x0000..0000,
graffiti: 0x0000..0000,
}
in future we will have multi-zk proof system, so the tier_zk verifier will support all of them and give/or-not-give a zk pass signal. a rough arch is like: from https://github.com/taikoxyz/taiko-mono/pull/17894 .
so client need to sync with tier_zk verifier for supported types, like:
{301: "risc0", 302: "sp1", 303: "jolt", ...}
the contract & client can agree on a protocol to handle it, like simple concat:
{proof: "0x012d" (i.e., 301) + "0x0123...cdef"}
Spam policy
[X] I verify that this issue is NOT SPAM and understand SPAM issues will be closed and reported to GitHub, resulting in ACCOUNT TERMINATION.
Describe the feature request
{301: "risc0", 302: "sp1", 303: "jolt", ...}
the contract & client can agree on a protocol to handle it, like simple concat:{proof: "0x012d" (i.e., 301) + "0x0123...cdef"}
Spam policy