Automatic mainnet migration test
Perform an automatic migration test on a mainnet context by using the voting procedure instead of user activated upgrades.
A migration test compatible with a context from mainnet requires to do some tricks so that we can effectively bake blocks and goes to the classic voting procedure. Moreover, such test should be automatic so that it can be reproduced easily.
The idea is to provide a test written with the Tezt
framework which is generic in a following sense:
- It can be run from any network, in particular
mainnet
andsandboxed
- It is automatic in the sense it can be run in the CI at least for the
sandboxed
mode. Formainnet
, the problem is discussed below
Moreover, we aim to provide a test which should be maintainable by having the less possible of hacky things.
Migration test for the sandboxed mode
In sandboxed mode, the test is quite easy. Assume we want to test the migration from protocol A
to protocol B
:
- We start from an empty context
- We activate
A
from the genesis protocol - We run the voting procedure with bootstrap keys until migration
Notice that the test works also if we start from a non-empty context already on protocol A
Migration test for mainnet
The difficulty with respect to the sandboxed mode are the following:
- There are no bootstrap keys. Hence, for baking blocks we need to fake signatures of real bakers
- We need to figure out who can bake at each level
- We need to ensure to have enough voting power if we want to pass through some voting periods such as
Promotion
- The minimal time between to blocks is not compressible: Hence we need to be able to bake block in the future.
- When we want to test the migration of a protocol from
A
toB
, the mainnet context might be on the protocolZ
with a voting procedure in progress forA
- The number of blocks to bake is actually huge, and the test may take hours to run. Baking using the debug command
bake for
can be donne at the speed of 5 blocks per second on my machine - We need to be able to get a mainnet context easily
If the mainnet context is on a protocol Z
, with a voting procedure for A
we need to first:
- Do a
user-activated
upgrade fromZ
toA
- Then register a
protocol override
so that instead of activatingA
we activateB
Progress of the test
You can follow the current work on the branch francois@generic-migration-test
. Here are the different steps to have a full working test:
-
A working test for the sandboxed mode -
A script to fetch and import a snpashot -
Generate a wallet with enough baking power (currently the wallet keys are hard-coded) -
Compute who can bake at each cycleuse the option--max_priority
instead. Not reliable 100% but easy to implement and works in practice -
Implement a user-activated upgrade
fromZ
toA
if applicable -
Implement a protocol override
fromA
toB
if applicable
Running the test on the CI
While we can easily add the test for the sandboxed mode in the CI it is complicated. For mainnet, running such test might takes days currently (it is shorter as we are far in the voting process since less blocks need to be baked).
An idea might be to run the test every night once the number of blocks to bake is shorter than some constant.