alpha mev-boost relay

  • By Blocknative Corp
  • Last update: Dec 28, 2022
  • Comments: 17

🛳️ Dreamboat

GoDoc Go Report Card Discord

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 eachother 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.

Design Goals

Special thanks to Flashbots for their commiment to open source. This project was orginally based on the relay in Flashobot's boost-geth-builder and mev-boost-relay. We hope to continue to diverge in implementation over time to help strengthen #RelayDiversity as we continue to work on Dreamboat's core design goals:

  1. Extensibility. Dreamboat provides well-factored interfaces that make it easy to change its behavior. We use Go Datastore for its persistence layer, so you can swap out the default BadgerDB store with your favorite database, and provide a clean separation between core relay logic, the beacon-chain client, and the HTTP server.
  2. Reliability. Work is ongoing implement a supervision-tree architecture in Dreamboat, so that you never miss a block.
  3. Performance. We have put significant engineering effort into tuning Dreamboat's performance, and have much, much more in store. The HTTP server's hot paths are 100% lock-free, concurrency is carefully tuned, and there are ongoing efforts to optimize the garbage collector and speed up signature validation. The result is a ship that doesn't just sail... it glides.
  4. 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 Dreaboat's runtime performance, standards compliance, reliability and transparency.

Planned Features & Enhancements

The following features and enhancements are in-progress.

  • Support for multiple storage backends (Redis, Postgres, BadgerDB, Filesystem, etc.)
  • Runtime profiling & tracing endpoint
  • Parallel validator-signature verification
  • Contention-free execution along hot paths
  • Support for multiple beacon clients (in testing stage)
  • Support for multiple external block builders

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.

PBS Context Diagram

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!

Download

dreamboat.zip

Comments(17)

  • 1

    Add extensibility for adding arbitrary networks

    What 🕵️‍♀️

    This PR adds extensibility, by letting users to specify any arbitrary networks

    How ⚙️

    For adding new networks, users MUST do 1 things:

    • Write the network configuration in JSON format under <datadir>/networks.json

    A simple example of a network specification file would be:

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

    This is only in case you want to extend the networks. The default networks (e.g., mainnet) are hardcoded.

  • 2

    Feature/multi builder support

    What 🕵️‍♀️

    Explain what this PR accomplishes

    • Changes the check-builder flag to simulation and adds validation. This is in preparation for adding support for external builders, the rest of this PR simply focuses on multiple builder support.

    Support for multiple builders:

    • The main consideration in this implementation is preserving the ability for builders to cancel blocks, this is inline with comments brought up in mev-boost and also with issue #202 in the flashbots relay
    • this implementation stores every builders last valid submission and updates the best payload stored in the relay upon receiving a valid payload.

    Why 🔑

    Explain the need or decisions which make this change necessary

    How ⚙️

    Briefly explain what components you modified or added, and how, to give context to your reviewers

    Testing 🧪

    • [ ] go test ./... from root
  • 3

    Build seems broken?

    What doesn't work

    Build Binary + Run

    Repro steps

    ❯ cd dreamboat

❯ git pull
Already up to date.

❯ make build
go build ./cmd/dreamboat
# github.com/blocknative/dreamboat/cmd/dreamboat
ld: warning: could not create compact unwind for _blst_sha256_block_data_order: does not use RBP or RSP based frame

❯ ./dreamboat 
Caught SIGILL in blst_cgo_init, consult <blst>/bindinds/go/README.md.

    Run directly

    go run ./cmd/dreamboat

    What does work

    CGO_CFLAGS="-O -D__BLST_PORTABLE__" CGO_CFLAGS_ALLOW="-O -D__BLST_PORTABLE__" go run ./cmd/dreamboat
  • 4

    Additional metric set

    What 🕵️‍♀️

    Enabling Prometheus default metrics over internal, additional, http port. Added badgerdb expvar metrics into prometheus.
    Removed pprof bindings from regular http interface, moved it into internal http - always enabled.

    Why 🔑

    To keep track of metrics and performance of the relay and database processed

  • 5

    Multiple builder submissions

    What 🕵️‍♀️

    This PR makes Dreamboat to be multi-builder, so that multiple builders can submit blocks. The relay chooses the highest bid among different builders. The intuition of the implementation is that a separate list of max profit bids is stored. In this list we keep the latest submission of every builder. So when a validator queries for a header, we get the max profit headers list, we sort them by bid (descending), and we select the highest bid.

    Testing 🧪

    • [x] Submissions from different builders
    • [x] Submissions from same builder, for cancelling with a lower value bid
  • 6

    fix registration logic

    What 🕵️‍♀️

    This PR improves validator registration logic. Currently, as soon as registration fails, the remaining validators are not registered. However, with this PR even if a single registration fails, then the rest of validators are registered.

  • 7

    Fix/blocks received

    What 🕵️‍♀️

    This PR fixes the builder_blocks_received Data API call, so that now all blocks for every slot are returned. previously just the latest block per slot was returned

    Testing 🧪

    The corresponding tests have been fixed, and all pass

  • 8

    getPayload has insufficient checks, allows validator to access the block contents without slashing

    The getPayload checks in https://github.com/blocknative/dreamboat/blob/main/pkg/api.go#L172 / https://github.com/blocknative/dreamboat/blob/main/pkg/relay.go#L312 are insufficient, and allow a validator to steal the payload without risk of slashing. besides checking the blockhash, also the correct slot and proposer index need to be verified.

    See the mev-boost audit for more details: https://github.com/flashbots/mev-boost/blob/main/docs/audit-20220620.md#relayer-signedblindedbeaconblock-validation

    Relayer SignedBlindedBeaconBlock validation

    To be slashed, a validator would need to sign two competing blocks for the block of the slot they are in charge of producing.

    As such, relayers need to validate the SignedBlindedBeaconBlock signed by validators to be of the correct Slot and ProposerIndex before showing the unblinded block to the validator. If this is not checked, validators will be able to access the block contents and use these transactions to craft a new block, where they extract the MEV for themselves.

  • 9

    fix submitBlock default error

    What 🕵️‍♀️

    Explain what this PR accomplishes

    "Manually fuzz testing" and noticed submitBlock returns errors like:

    {"code":400,"message":"EOF"}

    when it should be

    {"code":400,"message":"EOF"}

    like the other endpoints

    Why 🔑

    Explain the need or decisions which make this change necessary

    API consistency

    Testing 🧪

    • [x] go test -race ./... from root
  • 10

    Data API error vs empty response

    When Data API does not find a value based on a specific field like the slot, currently, we return an error. Instead we should return an empty array, in order to comply with the same format of Flashbots and the rest of the relays

  • 11

    Stable/log+bid

    What 🕵️‍♀️

    This PR:

    • Cleans up logs, since previously it was too noisy
    • Does not accept blocks after payload is delivered. This allows to signal the builder to stop building blocks for that slot
  • 12

    Typo: Dreaboat -> Dreamboat

    Typo fix

    What 🕵️‍♀️

    Explain what this PR accomplishes

    Why 🔑

    Explain the need or decisions which make this change necessary

    How ⚙️

    Briefly explain what components you modified or added, and how, to give context to your reviewers

    Testing 🧪

    • [ ] go test -race ./... from root
  • 13

    Clean logs, add metrics and reorg code

    What 🕵️‍♀️

    • Cleans and improves logging
    • Adds logs and metrics for understanding when a request fails

    Why 🔑

    Currently there are too many logs and there is no clear rules to follow for implementing them. Moreover, there is no understanding on why a GetHeader fails, since it may fail because they query an old slot, or because there was no block submission for the slot

    Testing 🧪

    • [ ] go test -race ./... from root
  • 14

    Publish beacon block to network

    We should publish the beacon block to beacon network after sending the block through mev-boost. Inspiration: https://github.com/flashbots/mev-boost-relay/pull/103

  • 15

    Streaming layer for high performance bids

    What 🕵️‍♀️

    This PR adds a streaming layer to the relay, so that when the relay is distributed it delivers bids and payloads from memory instead of an external DB

    Why 🔑

    GetHeader and GetPayload requests are very critical and they have low latency requirements. So, it is important to optimize how fast the bids and payloads are retrieved

    How ⚙️

    We add a streaming layer, so that every block a relay receives it streams to the other relays. This way, if the other relays receive a payload request it is very likely they can serve it from memory instead of querying an external DB.

    Testing 🧪

    • [ ] go test -race ./... from root
  • 16

    verify fee recipient of submitted block

    What 🕵️‍♀️

    Explain what this PR accomplishes

    Adds a check to verify that a block submissions proposer fee recipient matches the fee recipient validators have registered. Thanks to @metachris for pointing this out!

    Why 🔑

    Explain the need or decisions which make this change necessary

    Currently dreamboat does not support external builders, but instead a loosely defined trusted builder. We are in the process of hardening to be able to support any external builder with hopefully 0 trust.

    How ⚙️

    Briefly explain what components you modified or added, and how, to give context to your reviewers

    On block submission we grab the validators registered fee recipient and compare it to the value in the block.

    Testing 🧪

    • [ ] go test -race ./... from root
  • 17

    Fix/prevrandao

    What 🕵️‍♀️

    Implements randao validation on block submissions

    Why 🔑

    Otherwise it may cause security vulnerabilities

    How ⚙️

    Query the randao from the beacon whenever the headslot is updated and check for validation on block submission

    Testing 🧪

    • [x] go test -race ./... from root
    • [x] add unit test to check for invalid randao
    • [ ] end-to-end testing in testnet

    Special mentions

    Thank you to @metachris for notifying about this, and help make the relay more robust.

Popular Tag

Related