Architecture
Last updated
Last updated
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 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.
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.
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.
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.
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 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.
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 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.
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.
