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
The dependency set for interop will be stored within the RollupConfig. The proposed schema from the Go team is something like:
dependencySets: {
1000: [1,2,3,4], // timestamp to list of chain IDs
3500: [1,2,3,4,5],
7000: [1,2,3]
}
The FPP will need this field added to be able to reference the canonical dependency set of the chain to perform validation on the SuperRoot it receives.
The text was updated successfully, but these errors were encountered:
I don't like the proposed schema. It makes no sense to have to define dependency set timestamps separate from hardfork timestamps imo.
We still don't have a great idea of how the dependency set will be updated - on-chain, or through the client software. If through the client software, I think I'd rather pair dependency sets with forks, rather than timestamps (just because there's more room for error if the timestamps are set in 2 places.) If not through the client software, we have to do something different & this ticket can be closed.
We can't directly combine the dependency set updates and the hard forks because while dep set updates are a hard fork, they are also unique to an interop cluster. So you can't say that Holocene added Base to the dependency set because on a different cluster that may not be the case. So somewhere in the rollup you need a mapping from activation timestamp to the list of chains being added to the dependency set (removal is not possible). The activation timestamp might be the same as a named hard fork like holocene, but it doesn't have to be (it is still a hard fork though). There's a bunch of ways you might try and express that in JSON and I don't really mind which we go with, but the simple version above seems pretty reasonable to me.
Overview
The dependency set for interop will be stored within the
RollupConfig
. The proposed schema from the Go team is something like:The FPP will need this field added to be able to reference the canonical dependency set of the chain to perform validation on the
SuperRoot
it receives.The text was updated successfully, but these errors were encountered: