Given
where
An inbox is defined as a function
with
Consequently, a function
If the inbox can be inferred from the context, we will just note
We also define the set
For the refutation game, we need to prove that the successor of a message is part of the inbox. A naive definition for the successor could be the function
Note that there is a nice property with this definition which is:
The specification of the refutation game for the inbox is given
such that:
This has the consequence that
As a consequence, and because of
It is not reasonable in practice to work with infinite inboxes. Instead, an inbox is always finite with an upper bound. Moreover, the starting point of an inbox is not always the level
Because a commitment will commit only a finite number of level and that the data-structure associated
A finite inbox can be represented as a
Consequently, we can define the domain of a finite inbox as
The function
A second issue is the base case. In this formalisation, we requires the first level of a finite inbox to be empty. This trick allows to simplify cases, in particular to get rid off the
To recover the property that proving and verify a message in the inbox is the same as proving and verify the successor of a message in the inbox, we can just extend the domain of the finite inbox:
Consequently
In practice,
Initial
constructorAs mentioned above, it seems that the particular case for Initial
could be removed by forcing the inbox of the original level to be empty and containing the single but implicit message
This design forbids rollup originations at level
A major change in this design, is that it will be the responsibility of the rollup node to compute the successor of a pair
For example, assume the level
Assume we want to prove that the next message at level
The proof of such message does not need to be implicit because if we have only one inbox, this message will be added by the protocol during the block finalisation.
Proving
Cutting the inbox is not needed anymore:
By definition, the next message after