Def not required but a diagram idea for this section could show the process of repeatedly applying a list of proof elements to the state.

A bit nit picky but considering we may need other data to calculate the SUs, maybe we could say:

all inputs which can be used to compute the state update. This often includes transactions & auxiliary data.

Maybe we could add a glossary section

link seems to be broken

Not to be pedantic but ideally people will either be sent PETH or exchange ETH for PETH using a swap predicate lol

Note that these variables will likely be set inside of the constructor of a "deposit contract factory" so that we can save on gas cost, so the constant modifier may not be used in practice.

We could consider beginning this section by talking about how this is a general purpose block structure. Something like the following:

While Plasma Cashflow uses a Merkle Interval Tree, other constructions may use alternative block formats. In order to generalize the plasma block structure, we can break it into two layers:

1. an asset ID tree which specifies the particular asset (which may use an alternative format to cashflow); and
2. our plasma cashflow specific block structure, a merkle interval tree.

This structure allows operators to commit blocks for multiple plasma chains, as well as aggregate blocks from multiple operators into the same commitment.

Additionally, even within our plasma cashflow construction we can make use of the asset ID by giving each it's own chain......[etc]

This is great

Maybe instead this could be "easily enforceable on Ethereum"? Somehow communicating the fact that we not only have a state transition model, but we have a general state transition adjudication model?

State transitions:
f(s_0, i_0) = s_1
f(s_1, i_1) = s_2
...

Enforcement:
verify( f(s_0, i_0) == s_1 )

Maybe we could add something along the lines of:

We define a system in which a "trusted" state execution layer (Ethereum) may enforce the validity of secondary (L2) state execution, in constant time & memory.

platform?

This is no longer the correct number of sections

Consider removing "Plasma Group" or changing to "PG" for a title that's a little less wordy?

Unsure how this is compares to ABI generated from writing the predicate contract

type o