How Pivotal Works
Last updated
Last updated
Pivotal is being built on the Bedrock release of the OP (Optimism) Stack which is designed to make Optimism as close & equivalent as possible to Ethereum. The Bedrock release brings maximum compatibility with the existing Ethereum developer experience.
Current OP Stack landscape. Credit: OP Stack Docs
The OP Stack is a series of modules across the consensus, execution and settlement layers that work together to form coherent and reliable blockchains. The Bedrock release has streamlined the ability to swap out different components of the OP Stack codebase and add new functionalities & capabilities.
This modular architecture allows you to not only modify specific modules but swap them out entirely (for example swapping out Ethereum in favour of Celestia for the data availability layer).
Source: Introducing the OP Stack
The above diagram from the Optimism Collective highlights how modules can be swapped out across the Consensus, Execution and Settlement Layers. The items highlighted in white are modules that were released as a part of the Bedrock upgrade, whereas the items highlighted in yellow represent WIPs or simply are there to emphasise that you could create your own new module to provide functionality to that particular layer - hence the “Pokemon?!” callout.
As of today, the above diagram notes that the Execution Layer has an Ethereum Virtual Machine (EVM) module.
The Ethereum Virtual Machine is a piece of software that executes smart contracts & computes the state of the Ethereum network after each new block is added.
In the case of the modular OP Stack, this is a lightly modified version of the EVM that adds functionality for L2 transactions initiated on the L1 (Ethereum) and adds an additional L1 data fee for each transaction to account for the fee/gas needed to publish this transaction to the L1 (Ethereum).
Additionally, the diagram references a Governance module in the Settlement Layer, which is a set of tools & processes to manage system configurations, upgrades, and design decisions.
The OP Stack utilises an Optimistic Rollup to govern how state commitments are published to the L1 (Ethereum). An optimistic rollup is a way of scaling Ethereum that involves moving computation and state storage off-chain - e.g. off Ethereum. Optimistic rollups, such as Pivotal, execute transactions outside of Ethereum, but post transaction data to the Ethereum mainnet as calldata.
Pivotal combines off-chain transactions together in batches before sending them to Ethereum, which enables the spreading of fixed costs across multiple transactions in each batch - leading to reduced fees for those using Pivotal and other Optimistic rollups.
Optimistic rollups are called ‘Optimistic’ because they assume off-chain transactions are valid and don’t publish proofs of validity for transaction batches posted on-chain. Optimistic rollups instead rely on a fraud-proving process whereby anyone can challenge a rollup batch during a set time window by computing a fault proof.
Rollups built using the OP Stack interact with the Layer 1 through a series of smart contracts deployed on the Ethereum network. There are two key components of the optimistic rollup architecture:
On-chain Contracts: The optimistic rollup utilises smart contracts running on Ethereum. This includes contracts that: store rollup blocks, monitor state updates on the rollup, and track user deposits.
Off-chain Virtual Machine: Computation and state storage occur on Pivotal and not the Ethereum Virtual Machine. This off-chain virtual machine is where applications live and operate.
Source: Optimistic Rollups
L2s built on the OP Stack, such as Pivotal, have sequencer(s) that post data to the underlying L1 (Ethereum).
A sequencer has the task of accurately executing transactions received.
Provides transaction confirmations and state updates
Constructs and executes L2 blocks
Submits user transactions to the L1 (Ethereum)
Source: Rollup Protocol
Pivotal blocks are produced every two seconds, regardless of whether they are empty (no transactions), filled up to the block gas limit with transactions, or somewhere in the middle.
Transactions submitted on the L1 (which are called deposits in the OP Stack) are included in the chain in the appropriate L2 block. Every L2 block is identified by the ‘Epoch’, which is the L1 (Ethereum) block to which it corresponds. The first block of the epoch includes all the deposits that happened in the L1 block to which it corresponds. If a sequencer attempts to ignore a legitimate L1 transaction it ends up with a state that is inconsistent with the verifiers, just as if the sequencer attempted to fake the state through another mechanism. This provides L2s built using the OP Stack with Ethereum level censorship resistance.
Transactions submitted directly to the sequencer on the L2.
Source: Rollup Protocol
The Requirements for the Processing of a Rollup Transaction
The transaction needs to be written to L1 (Ethereum). This role is normally performed by op-batcher, but any user can send an L1 transaction to submit an L2 transaction (known as "forced inclusion"), in which case op-batcher is bypassed.
The transaction needs to be executed to modify the state (by op-geth). Periodically, op-proposer writes a commitment of the post-transaction state to L1. Note that op-proposer does not need to write an L1 commitment after each L2 block; instead it happens at a consistent period measured in L1 blocks.
Source: Transaction Flow
The batcher combines sequencer batches into channels. When a channel is full, it is posted to the L1 either as a stand alone transaction or as a batch of multiple transactions.
Source: Transaction Flow
Pivotal is designed to allow users to send arbitrary messages between smart contracts on the L2 (Pivotal) and L1 (Ethereum), making it feasible to transfer digital assets, including ERC20 tokens, between the two layers. Pivotal uses a smart contract bridge to allow users to deposit digital assets from Ethereum to Pivotal and also to allow withdrawals from Pivotal back to Ethereum.
In the OP Stack, transactions going from the L1 (Ethereum) to the L2 (Pivotal) are called deposits, regardless of whether or not they involve assets. Deposit transactions become part of the canonical blockchain in the first L2 block of the “epoch” that corresponds to the L1 block where the deposits occurred. The L2 block will usually be created a few minutes after the corresponding L1 block.
In the OP Stack, transactions going from the L2 (Pivotal) to the L1 (Ethereum) are called withdrawals, regardless of whether or not they involve assets. These transactions have three stages:
User initialises the withdrawal with a transaction on the L2 (Pivotal).
Wait for the next output root to be submitted to the L1 (Ethereum) so the withdrawal can be proven.
After the fault challenge period ends, the proven withdrawal is finalised.
