Owners: @David Rusu @Álvaro Castro-Castilla

<aside> 💡 Censorship resistant transactions will be dealt with separately (using an on-chain message buffer). We only consider the standard transaction path here.

</aside>

<aside> 🚨 Careful! This document is quite outdated

</aside>

Overview

This document describes the high level architecture of CL. CL is composed of three high level actors.

1. The User

   Submits partial (or full) transactions to CL.

2. The Executor

   Consumes partial transactions from the message buffer, solves them and submits them to the mempool.

3. The Consensus Slot Leader

   Combines solved transactions (or bundles) into a block and proposes it.

The communication channels used between these actors are

1. Message Buffers

   Users communicate with Executors using light weight Message Buffers.

2. Mempool

   Executors communicate with Leaders through the Mempool. Users have the option to skip the executors and interact directly with leaders by submitting transactions to the mempool as well

Transaction flow from User to Leader through the CL architecture. Users can choose to bypass Executors and submit full transactions directly into the mempool.

Users are interacting with Zones on chain using the above network topology. We will now go into the reasoning for this decomposition

The User

Users have two options to interact with CL, either they submit complete transactions to the mempool or they submit partial transactions to message buffers. Users may still opt to send complete transactions to message buffers if Executors are able to provide lower fees through clever sequencing and aggregation.

Message buffers will almost always provide a better experience but there will be cases where a user must submit transactions directly to a mempool (e.g. if the user is interacting with an unpopular Zone that has lost it’s dedicated executor.)

The user is often times interacting with Nomos via. a thin client. Underpowered clients will put an upper bound on the types of transactions that can be performed on device. To address this, we have the user signal their intent by constructing a partial transaction and submitting to a message buffer.

These partial transactions are not balanced (input value ≠ output value), they need to be “solved” by a third party Executor.

The Message Buffer

A message buffer is a light weight (unordered) pool of messages that is interacting with a set of Zones. We can define a message buffer as an N-tuple $(\mathcal{Z}_1, \mathcal{Z}_2, \cdots, \mathcal{Z}n)$, where $\mathcal{Z_i} < \mathcal{Z}{i+1}$.

The message buffers serve a multiple purposes:

• Support light clients interacting with heavy Zones.

  Light clients are supported through lightweight partial transactions that are solved into larger full transactions.

• Reduce contention through sequencing.

  Contention is solved by having the User define partial transactions that are not directly coupled to a specific instance of a Zone’s state Note.

• Amortize fees of submitted transactions

  Executors may be able to reduce transaction fees through clever aggregation techniques providing users with. Users may choose to use Message Buffers even if their transactions don’t touch shared state to take advantage of this.

Transaction Flow

The intended flow is as follows: