New inboxes

Specification of an infinite inbox with SOL/EOL

Given M a set that aims to represent messages, we define M as:

M=MSOLEOL

where represents the disjoint union.

An inbox is defined as a function I:N×N>M such that:

  • I(l,i)=EOLj,j<i,m,I(l,j)=m
  • I(l,0)=SOL

with l a block level, and i is the message position.

Consequently, a function sizeI:NN can be defined such that

sizeI(l)=i such that I(l,i)=EOL

If the inbox can be inferred from the context, we will just note size(l).

We also define the set Dom(I)={(l,i)mM,I(l,i)=m}.

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 S:N×NN×N such that

  • S(l,i)=(l,i+1)i<sizeI(l)
  • S(l,i)=(l+1,0)i=sizeI(l)

Note that there is a nice property with this definition which is:

  • (l,i)Dom(I)S(l,i)Dom(I) (1)

The specification of the refutation game for the inbox is given (l,i), to write to functions prove and verify such that:

  • prove(l,i)=(m,p) where mM
  • verify((l,i),p)=m

such that:

l,i,m,p,prove(S(l,i))=(m,p)verify(S(l,i),p)=m

This has the consequence that prove and verify functions are properly defined only on Dom(I)

As a consequence, and because of (1), this property is the same as:

l,i,m,p,prove(l,i)=(m,p)verify((l,i),p)=m

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 0.

Finite inboxes

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 3uples: (I,ls,le) such that:

  • I is an infinite inbox
  • l,i,l<lsI(l,i)= (it is undefined)
  • I(ls,1)=EOL
  • l,l>leI(l,0)=SOL

Consequently, we can define the domain of a finite inbox as
Domf(I,ls,le)=Dom(I){(l,i)l>lslle}

The function S is not longer stable over the domain Domf. This is one difficulty we identified in the current implementation.

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 Initial constructor. In the context of SCORU, this means that the input state after initialisation will be First_after(ls,0).

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:

Domf+(I,ls,le)=Domf(I,ls,le){(le+1,0)}

Consequently S:Domf(I,ls,le)Domf+(I,ls,le), and we will define prove and verify on Domf+(I,ls,le).

In practice, ls will be the level for which the rollup was originated, while le will be the commitment level.

How to integrate those ideas into the current code

Get rid of Initial constructor

As 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 EOL. Considering that such inbox exists or not, this will be already the case. We could also ensure that from the level of activation of SCORU, there is a new inbox that will be populated by SOL/EOL messages.

This design forbids rollup originations at level 0.

Inbox proof

A major change in this design, is that it will be the responsibility of the rollup node to compute the successor of a pair (l,i). The code producing the proof does not need to find the next message. Looking for the successor becoming trivial with SOL/EOL.

For example, assume the level 5 contains 3 messages and the level 6 contains 1 message. Right now, calling the function prove with parameters (5,10) is equivalent to calling it with parameters (6,0). In the formalism proposed here, calling this function with (5,0) will simply produce an error.

How to prove SOL

Assume we want to prove that the next message at level l+1 is SOL, then we only need to prove that the message at level l for some position i is EOL.

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.

How to prove EOL

Proving EOL is the message as proving any other message of the inbox.

Cutting the inbox

Cutting the inbox is not needed anymore:

  • There is no message for level lls
  • There is no message for level l>le

By definition, the next message after EOL at level le is SOL at level le+1.