33 lines
4.3 KiB
Markdown
33 lines
4.3 KiB
Markdown
# ePBS (Enshrined Proposer Builder Separation)
|
|
|
|
## Overview
|
|
|
|
Enshrined Proposer Builder Separation (ePBS) is a protocol-level mechanism that separates the roles of block proposers and block builders to improve censorship resistance and MEV (Maximal Extractable Value) distribution in blockchain networks.
|
|
|
|
## Zenith's ePBS Implementation
|
|
|
|
Zenith implements ePBS through a lane-based architecture that prioritizes transaction bundles from associated and sponsored stars. Validator node operators configure their Galaxy point ID along with an associated Star ID in the [Janus configuration](https://github.com/Zenith-Foundation/zenithd/blob/main/janus/config.template.yaml#L23-L45). The associated star submits its bundles to the Galaxy Janus directly in-process without going through external endpoints, whereas standalone stars submit bundles to the Galaxy Janus over HTTP.
|
|
|
|
### Lane-Based Architecture
|
|
|
|
The Block SDK provides a lane abstraction over block construction and mempool management. Lanes split the block construction across multiple dedicated channels, with each lane maintaining its own mempool. The system processes `PrepareProposal` and `ProcessProposal` handlers through these lanes to ensure fair block space allocation.
|
|
|
|
The current [lane configuration](https://github.com/Zenith-Foundation/zenithd/blob/main/app/lanes/setup.go#L57) prioritizes block space in the following order. The [associated star lane](https://github.com/Zenith-Foundation/zenithd/blob/main/app/lanes/associated_star.go) receives 15% of block space and occupies the top of the block. The [sponsored stars lane](https://github.com/Zenith-Foundation/zenithd/blob/main/app/lanes/sponsored_stars.go) receives 75% of block space for bundles from other sponsored stars. The default lane handles regular transactions and takes up remaining block space, though this lane will be removed in future implementations.
|
|
|
|
### Bundle Processing
|
|
|
|
The Galaxy Janus maintains a FIFO bundle queue that feeds into the laned mempool system. A mempool syncer reads bundles from this queue every 100ms and [inserts them](https://github.com/Zenith-Foundation/zenithd/blob/main/app/lanes/utils/mempool_syncer.go#L61-L78) into the appropriate lane based on the bundle's origin. The laned mempool processes lanes in priority order, with the associated star lane accepting only bundles from the configured associated star, and the sponsored star lane accepting bundles from other sponsored stars tracked in the state.
|
|
|
|
In the current MVP implementation, the laned mempool allows direct transaction submission with these transactions ending up in the default lane. Cross-galaxy bundles are not yet supported in this version.
|
|
|
|
### Block Proposal
|
|
|
|
When a Galaxy's turn arrives to propose a block, each lane includes bundles from their respective mempools until exhausting their quota. The associated star lane fills the first 15% of block space with bundles from the associated star. The sponsored stars lane then fills the next 75% of block space with bundles from sponsored stars. Any bundles that don't fit remain in the mempools for consideration in the next block. The default lane uses any remaining block space for non-bundle transactions.
|
|
|
|
During block proposal in `PrepareProposal`, bundles are splayed out with all transactions from each bundle included in the block while maintaining their original order. To enable validation by non-leader validators, the system adds a pseudo transaction called [`IncludeBundleTx`](https://github.com/Zenith-Foundation/zenithd/blob/main/app/lanes/utils/include_bundle_tx.go) as a prefix to each bundle.
|
|
|
|
### Validation Process
|
|
|
|
In `ProcessProposal`, non-leader validators validate the bundles included in the block proposal by verifying the bundle signatures contained in each `IncludeBundleTx`. The `IncludeBundleTx` contains the Star ID and bundle signature, allowing validators to distinguish between bundles in the transaction list. This pseudo transaction is ignored during normal block execution.
|
|
|
|
The `ProcessProposal` validation also checks block structure and rejects malformed proposals, such as bundles appearing in the default lane. In the `PreBlocker` hook, the system emits a `bundle_inclusion` [event](https://github.com/Zenith-Foundation/zenithd/blob/main/abci/proposal.go#L249-L259) for each `IncludeBundleTx` to track bundle inclusion in blocks. |