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
This is a big one that probably deserves a project.
Our current execution pipeline isn't multi-versioned, meaning that any new feature or code change would affect historic events that happened in the network. This is fine now since we're just starting with the protocol definition.
At some point, we should start including new functionality in the protocol spec that actives at a particular block number in each chain. If we don't do this, by creating new features we would be "rewriting history" and potentially changing the table state for users that shouldn't expect that to be happening.
To do this, we need to do some refactor of the execution pipeline to have multiple versioned Executor (and downstream) "packaged" that are "plugged"/"switched" depending on the block number we're in. At activation times, this also might require adding a functionality to run migrations in the database.
For example, if we announce that at block X in Mumbai the Tableland will have a database migration in all tables defined by some rule in the spec, we need to support that in the validator. Another example is mentioning that a new SQL statement will be supported starting at block X in Goerli (and not before, if you cold sync a validator).
Hopefully, this makes sense, but let me know if the idea isn't clear. Of course, we need to dedicate time to design and scope the work to do since this will take some work.
The text was updated successfully, but these errors were encountered:
This is a big one that probably deserves a project.
Our current execution pipeline isn't multi-versioned, meaning that any new feature or code change would affect historic events that happened in the network. This is fine now since we're just starting with the protocol definition.
At some point, we should start including new functionality in the protocol spec that actives at a particular block number in each chain. If we don't do this, by creating new features we would be "rewriting history" and potentially changing the table state for users that shouldn't expect that to be happening.
To do this, we need to do some refactor of the execution pipeline to have multiple versioned
Executor
(and downstream) "packaged" that are "plugged"/"switched" depending on the block number we're in. At activation times, this also might require adding a functionality to run migrations in the database.For example, if we announce that at block X in Mumbai the Tableland will have a database migration in all tables defined by some rule in the spec, we need to support that in the validator. Another example is mentioning that a new SQL statement will be supported starting at block X in Goerli (and not before, if you cold sync a validator).
Hopefully, this makes sense, but let me know if the idea isn't clear. Of course, we need to dedicate time to design and scope the work to do since this will take some work.
The text was updated successfully, but these errors were encountered: