Home

Awesome

🛳️ Dreamboat

GoDoc Go Report Card Discord

⚠️ As of September 27, 2023 the Dreamboat code base is no longer being actively maintained by the Blocknative team. Please see this post for more context.

An Ethereum 2.0 Relay for proposer-builder separation (PBS) with MEV-boost. Commissioned, built, and put to sea by Blocknative.

blocknative-dreamboat

Quickstart

Installation

Install with go get, or download the latest release here.

$ go install github.com/blocknative/dreamboat

Usage

$ dreamboat --help

Documentation can be found here.

What is Dreamboat?

Dreamboat is a relay for Ethereum 2.0, it ships blocks from builders to validators. Dreamboat is for anyone who wants to strengthen the Eth network by running their own relay. Dreamboat's all-in-one design, modular code base and stunning performance will dazzle beginners and seasoned hackers alike. All aboard!

More precisely, Dreamboat is a spec-compliant builder and relay that allows block-builders and validators to interface with each other through MEV-boost.

Eventually Dreamboat will vanish, as if a dream, once in-protocol PBS is live. Until then, it sails the ephemeral seas of block space, delivering its trusted cargo of blocks to validators, guided simply by a lighthouse.

Dreamboat VS Others

Why should you opt for Dreamboat instead of other relays?

Decentralized Bid Delivery

Unlike centralized relays that heavily rely on a single centralized source of truth, such as Redis, for bid propagation, the Relay project takes a distributed approach. We deliver bids to distributed instances, allowing for improved scalability, fault tolerance, and reduced reliance on a single point of failure. This decentralized bid delivery mechanism ensures higher availability and robustness of the relay network.

Memory-Based Operations

One of the key differentiators of the Relay project is its heavy utilization of memory for serving various operations. Instead of relying on frequent database access, we leverage in-memory storage to serve most of the required data. This approach results in significantly faster response times and reduced latency for bid retrieval, payload retrieval, and other essential operations.

Efficient Data Storage

In contrast to relying solely on a costly PostgreSQL database for storing large volumes of data, the Relay project adopts a more cost-effective approach. We store increasing amounts of data in files, utilizing file-based storage systems. This strategy not only reduces infrastructure costs but also enhances performance and scalability, as file operations can be optimized and scaled more efficiently.

Relay Diversity

Relay diversity plays a crucial role in ensuring the resilience, security, and efficiency of the overall network. By running relays with different configurations and settings, we can achieve a more diverse and robust network architecture.

Command-line Flags

In addition to configuring the relay using the config.ini file (explained below), you can also use command-line flags to customize its behavior. The following flags are available:

The following flags control specific relay functionalities:

Configuration Options

The relay system provides various configuration options that can be customized through the config.ini file, specified through the -config flag. Each section and its respective items are explained below, along with their default values:

Please note that these values can be modified in the config.ini file according to your specific requirements.

Extend the blockchain networks

Do you need to make your relay work with a different blockchain that is not:

Then you need to extend the relay by creating a json file called networks.json, and put it inside datadir (datadir is a parameter you set when running the relay).

Inside the network.json file, you need to specify the network name and three other information:

Here is an example of how you should format the networks:

{
    "blocknative":{
        "GenesisForkVersion": "",
        "GenesisValidatorsRoot":"",
        "BellatrixForkVersion": ""
    },
    "myNetwork":{
        "GenesisForkVersion": "",
        "GenesisValidatorsRoot":"",
        "BellatrixForkVersion": ""
    },
}

Design Goals

This is a from-scratch implementation of a PBS relay–aimed at strengthening #RelayDiversity–with the following design goals:

  1. Extensibility. Dreamboat provides well-factored interfaces that make it easy to change its behavior, including the database, beacon connection and even the relay core logic.
  2. Performance. We have put significant engineering effort into tuning Dreamboat's performance, and have much, much more in store. Concurrency is carefully tuned, we cache as much as we can, and we try to serve requests from memory. The result is a ship that doesn't just sail... it glides.
  3. Transparency. Dreamboat implements the Relay Data API, so you can audit past proposals. But we take a much broader view of transparency, which includes code transparency. A major cleanup effort is underway to make–and keep–Dreamboat's code legible. We believe this is an essential part of ensuring transparency and reliability.

We are continuously improving Dreamoat's runtime performance, standards compliance, reliability and transparency. We would also like to thank the Flashbots team for their open-source tooling, which helped us get Dreamboat up and running in short order, and for their thoughtful comments on implementation.

Support

Stuck? Don't despair! Drop by our discord to ask for help, or just to say hello. We're friendly! đź‘‹

Developing

Building Locally

$ go run cmd/dreamboat

Architecture

Proposer Builder Separation is a solution to shield validators from the centralizing force the black hole of MEV has released. The next chapter in this saga is to protect builders from too extreme of centralizing forces.

<img width="874" alt="PBS Context Diagram" src="https://user-images.githubusercontent.com/22778355/188292682-421dee2e-b11c-46ca-af08-7f6c0e0d665e.png">

API Compatibility

Dreamboat follows semantic versioning. Changes to the REST API are governed by the Flashbots specifications.

The main branch is NOT guaranteed to be stable. Use the latest git tag in production!