System architecture
Last updated
Last updated
Alpen is an EVM blockchain that uses bitcoin as the source of truth for state commitments and proof of valid state transitions. The application layer interacts with Alpen in three ways:
Through the full node, which provides both Ethereum-compatible RPCs and additional Alpen RPCs, enabling users to send EVM transactions to Alpen.
Through the bundler, which handles the bundling of account abstraction (ERC-4337) transactions, also known as UserOperations.
Through bitcoin, which enables users to transfer BTC to the bridge and receive an equivalent deposit amount on Alpen.
The diagram above illustrates the overall system architecture and the data flow between different components of Alpen and the entities interacting with the system. There are three layers: bitcoin layer at the base, Alpen layer above it, and the application layer that sits on top of the Alpen layer. The direction of arrows indicate the direction of data flow between the components, and the text in the arrows indicate the data. The centralized services are the services that are run by Alpen Labs. Other components within the Alpen layer (the bundler and the full node) can be run by anyone.
The application layer includes any interface or application that acts as a gateway for users to interact with Alpen. These applications include wallets (e.g. EOA wallets, account abstraction wallets, bitcoin wallets), decentralized applications (e.g. Uniswap), smart contract deployment tools (e.g. Foundry), and command-line interface tools (e.g. Cast). They interact programmatically with an Alpen full node, bundler, and bitcoin through an RPC interface provided by each service, and the RPC interfaces enable applications to interact with Alpen, including deploying smart contracts, sending EOA or account-abstraction transactions, and initiating deposits into Alpen.
Alpen Labs provides a bundler that developers can use as a service to send UserOperations. Anyone else can also run their own bundler to connect with the full node network independently.
A full node is client-side software that runs Alpen's core logic and provides an RPC interface for programs to interact with Alpen. It receives transactions from the application layer or bundler and relays them to the sequencer. Periodically, the full node polls the sequencer for new blocks. If new blocks are available, then the full node downloads and executes them against its current state, advancing the chain state. Once the full node detects that a state checkpoint committed by the sequencer to bitcoin has reached finality (i.e., six confirmations), it marks the corresponding chain states as finalized.
Internally, a full node is constructed similarly to a post-merge Ethereum full node, keeping modularity in mind, separating the node into an execution layer and an orchestration layer. These layers interact with each other through a slightly modified Engine API, which we extended to handle bridge transfers in/out of the execution layer.
The sequencer is currently a centralized component that performs the functions of sequencing transactions in its mempool into a new block (every 5 seconds) and sharing blocks with full nodes upon request. The sequencer also decides on a new batch (the range of Alpen blocks) to be proven, relays that information to the prover upon request, and posts the batch checkpoint to bitcoin. A batch checkpoint includes the batch data, chain state commitment, and the proof generated by the prover.
The sequencer is therefore the primary component in the Alpen system, performing the necessary actions that enable full nodes to advance the chain to the next state.
Internally, the sequencer is similar in construction to a full node, with its own execution and orchestration layers. The diagram doesn't show these layers for simplicity.
For testnet, Alpen Labs operates the sequencer.
The prover proves the validity of batches. It receives information about a new batch, when it's available, from the sequencer, and then produces a validity proof that proves the validity of Alpen's state transition corresponding to the current batch. It also proves that the previous checkpoint proof, for the previous batch, is valid, recursively proving the validity of all previous batches in a single proof. At a high level, the proof ensures that:
Batch validity: the state transition resulting from executing the current batch and deposit transactions is valid.
Rollup chain validity: the current batch builds upon the previous valid batch, confirmed in a checkpoint, and the proof contained in that checkpoint is also valid.
L1 blockscan: all bitcoin blocks until the one containing the previous checkpoint (starting from the block from two checkpoints ago) have been scanned for deposit and checkpoint transactions. In addition, we prove that all deposits that were finalized between the last two checkpoints are included in the current batch, and that the rollup follows a canonical "checkpoint chain" that proceeds sequentially from one checkpoint to the next (no forking or skipping checkpoints allowed).
This recursive proof enables a verifier to validate the Alpen chain's entire history, from genesis to the latest state. The proof is passed to the sequencer, who then includes it in a new batch checkpoint and posts it to the bitcoin network.
A bridge operator is one of N nodes collectively performing the functions of processing user deposit requests by locking a user's BTC in the N-of-N bridge address on bitcoin, and processing user withdrawal requests by releasing the appropriate amount of BTC back to a user's bitcoin address. Each bridge operator monitors bitcoin for a Deposit Request Transaction, in which the user allows the bridge operators to transfer the user's BTC to an N-of-N multisig address within a specified amount of time. Once the bridge operators see this transaction on bitcoin, they pre-sign a number of transactions that ensure that in the future a functional operator can fulfill a user's withdrawal request and receive a reimbursement. At the end of this pre-signing process, the bridge operators sign and broadcast to bitcoin a Deposit Transaction that transfers the user's funds to an N-of-N bridge address. When this transaction is confirmed on bitcoin and reaches the finality depth, an equivalent amount of BTC is minted to the user's designated Alpen address.
Similarly, after each confirmed Withdrawal Request Transaction on Alpen, in which a user burns their BTC on Alpen, the protocol assigns a bridge operator to process the withdrawal on bitcoin. The assigned operator then initiates the withdrawal process, which involves multiple bitcoin transactions and results in one bridge UTXO being spent and the user receiving their BTC withdrawal on bitcoin. In case an operator processes a withdrawal incorrectly, the bridge provides a mechanism by which anyone with a sufficient amount of BTC can challenge the operator.
The bundler supports account abstraction by accepting UserOperation transactions as defined by . It bundles these transactions and relays them to a full node via a special entrypoint contract deployed on Alpen.
The bridging mechanism is based on the . Detailed description can be found in the . Currently, all bridge operators are run by Alpen Labs. Incorporating external bridge operators is planned for a future Alpen release.
