# Architecture

**Pi Squared’s USL** is a layer that facilitates transaction settlement across various systems. It transparently identifies and verifies the trust base of a transaction, which is essential for achieving the intended state transition. It supports upper computational layers while relying on lower layers for consensus (finality) and data accessibility.

The diagram below provides a general illustration of the target architecture for **Pi Squared’s USL** and its placement in the modular blockchain stack. The following sections will explain the diagram in detail.

**The Computations Layer **

**The Computations Layer**

The *Computations Layer* is at the top, where computations are performed in various languages and virtual machines (VMs) using different systems. These systems can include transaction execution engines (MegaETH), fully-fledged AppChains, and execution rollups. The computations performed on this level could potentially be extremely complex.

The environments where these computations are performed can implement their own optimizations and use parallelization as needed. **USL** does not need to know how these computations were actually performed.

### Sequencer Network

Sequencing services are found in the *Computations Layer*. These services mediate the processing of transactions between higher-layer applications and rollups on one side and **USL** on the other.

To maintain a minimal design, **USL** does not incorporate sequencing. Instead, it interfaces with the *Sequencers* through a standard interface.

*Sequencers* validate and collect transactions into blocks, promoting efficiency and increased transaction throughput. Each block also includes its combined .

These *Sequencers* are typically decentralized and run a consensus algorithm to order transactions securely. Sequencer validation is typically lightweight (e.g., Espresso, by default, does not validate the post-state of a transaction). Therefore, the pre-confirmation provided by the *Sequencing Network Layer* is optimistic and can be reverted if the transaction is shown invalid in the **USL** (or lower layers).

In addition to submitting sequenced blocks to **USL** for further processing, sequencers also submit a commitment to the block to the sequencing layer’s contract in L1. For an example, look at Espresso’s architecture.

Alternatively, we can define sequencing as a language where specific sequences are programs in this language. Through its formal semantics, we can prove that sequencing programs are equivalent to sequencing performed by a *Sequencer Network Layer*.

This approach will require sequencer services/components to use the sequencing language, potentially adding complexity to these services or components. Further investigation of existing solutions is needed to determine the best design choice.

## The Execution Layer Interface

Below the *Computations Layer* is the *Execution Layer Interface*. This layer is required so the systems in the *Computations Layer* can communicate with **USL**.

The *Execution Layer Interface* accepts “computation transactions,” which include the transaction, the , and transition metadata. This metadata defines the program performing the computation, the list of trusted entities for the program’s execution, and other details. The interface specification must also define the format of these “computation transactions.” Users in the *Computations Layer* may generate many of these transactions.

**Pi Squared's** USL Layer

**Pi Squared's**USL Layer

Below the *Execution Layer Interface* is **Pi Squared****’s USL*** Layer*. This layer functions as an optimistic rollup. It interprets a computation transaction (or possibly a sequence of computation transactions) as a mathematical claim within the logical theory. This corresponds to the system where these computations are claimed to have been performed. The claim includes several parameters, such as the following:

The transaction’s pre-state and post-state

The transaction’s computation or program

A list of all the entities assumed for execution, known as the trust base

To minimize the trust base of a transaction, **USL** can generate a mathematical proof of correctness for the computation sequence in Matching Logic. This proof can only be produced if the computation sequence is correct. Therefore, **USL** primarily consists of two key components: The * π² Network* and

*The Prover Pool*.

### π² Network

The * π² Network* consists of nodes running a consensus protocol to confirm the validity of the claimed post-state based on the trust assumptions bundled in the transaction. The validation of a transaction verifies the following claim:

“When the transaction’s computation is executed on the given pre-state within an execution environment meeting the transaction's trust assumptions, the resulting post-state will match the claimed post-state.”

This validation process is transparent, reproducible, and can be independently verified. Furthermore, the network may utilize the services of the** ***Prover Pool* to generate (and agree on) Zero-Knowledge Proofs (ZKPs) to confirm correctness proofs of transaction executions, ultimately minimizing the trust base of the transaction.

### The Prover Pool

The* Prover Pool* consists of prover nodes. Each prover node runs the proof generation pipeline on a transaction or block to produce a succinct ZKP that attests to the correctness of the transaction. This is achieved by re-executing the transaction or block and generating a Matching Logic correctness proof, which is then used to produce a ZKP. The proof generation pipeline is efficient and self-contained within the node, eliminating the need to store or share large Matching Logic proofs.

Since generated ZKPs can be independently verified, the* Prover Pool* doesn’t need to be trusted and is viewed as a service provider to the * π² Network*. However, a rewards/penalty system must be established to incentivize users to join the

*Pool*and properly run the proof generation pipeline.

The generated ZKP is returned to the * π² Network* for further processing. It is important to note that the ZKP is much smaller and can be transported and verified much faster than the original mathematical proof.

## The Consensus and Data Availability Layer(s)

Below the **Pi Squared**** USL ***Layer* is the *Consensus and Data Availability Layer*. This layer provides finality consensus and data validation services. There are two relevant smart contracts deployed at the consensus layer (L1):

### The π² Verifier Contract

The **π² ***Verifier Contract* verifies the ZKP certificate and validates the with the data availability provider. Checking the ZKP certificate ensures that the state transition is valid and provable mathematically using Matching Logic. It also validates the initial state’s data availability, ensuring the transaction can be independently verified. This means anyone can reconstruct and verify the state of * π²’s USL*. After successful validation, the ZKP is sent to the L1

**π²**Contract, recording the proven correctness of the corresponding blocks in the layer’s state.

### The π² State Contract

After the verification step is completed, the* ***π²*** State Contact* is responsible for updating the stored state of **Pi Squared*** ’s USL* in L1. This is accomplished by replacing the previously stored state Merkle root with the one included in the verified transaction, which is computed by aggregator nodes in

**USL**.

Last updated