Here we outline how the naive rollup rollers work. This page is only a quick summary - the full documentation of the API is coming soon.
The following diagram illustrates the most important parts of the plumbing present in the roller.
We elaborate on the components of this diagram below.
The roller communicates with the outside world via a JSON-RPC API, which is
implemented with a Gall agent
%roller-rpc. This is how Bridge communicates
with a roller. See the RPC
for detailed information on the API.
%roller is the Gall agent which collects layer 2 Azimuth transactions, which
are a concatenation of an
action and a
signature and forms them into
batches to be submitted periodically to the
See Bytestring Format for a technical description of how layer 2 transactions are formatted.
%roller maintains in its state a list of transactions that have been submitted
to it since the most recent roll it submitted to Ethereum. These are referred to as
Signing the batch
Each pending transaction already includes a signature from its sender, but the roller itself must also sign the entire batch of transactions with its private key to submit it as a single Ethereum transaction. This signed batch is known as a roll.
Once a roll has been submitted to an Ethereum node, there is a waiting period before a miner includes it in a block.
During this waiting period, the roller applies the submitted batch to the locally held Azimuth state to get a predicted state. This predicted state is presented to the user in Bridge, such as to show which points a given address owns.
Each roller may choose to submit rolls on a regular basis, periodically and/or whenever a certain number of pending transactions is reached.