Mev-boost: A middleware server written in Go

Related tags

Network mev-boost
Overview

mev-boost

A middleware server written in Go, that sits between an ethereum PoS consensus client and an execution client. It allows consensus clients to outsource block construction to third party block builders as well as fallback to execution clients. See ethresearch post for the high level architecture.

Implementation Plan

A summary of consensus client changes can be found here.

milestone 1 - kintsugi testnet

simple middleware logic with minimal consensus client changes, simple networking, no authentication, and manual safety mechanism

middleware behavior

  • middleware sends feeRecipient to relay with direct engine_forkchoiceUpdatedV1 request at beginning of block
  • middleware fetches signed payloads from relay using unauthenticated getPayloadHeader request
  • middleware selects best payload that matches expected payloadId and requests signature from consensus client, this requires passing header object to the consensus client and flagging that it should be returned to the middleware once signed
  • middleware returns signed block + initial payload header to relay with direct request

required client modifications

milestone 2 - security & reputation

cleanup consensus client and add security fallbacks

middleware behavior

  • add middleware module for verifying previous relay payload validity and accuracy with hard or statistical blacklist (may require modifications to execution client)
  • add middleware module for subscribing to 3rd party relay monitoring service

required client modifications

  • in event of middleware crash, consensus client must be able to bypass the middleware to reach a local or remote execution client

milestone 3 - authentication & privacy (optional)

add authentication and p2p comms mechanisms to prevent validator deanonymization

middleware behavior

  • middleware signs feeRecipient message and gossips over p2p at regular interval
  • middleware gossips signed block + initial payload header over p2p

required client modifications

milestone 4 - configurations (optional)

add optional configurations to provide alternative guarantees

  • consider adding direct engine_forkchoiceUpdatedV1 call to relay for syncing state
  • consider returning full payload directly to validator as optimization
  • consider adding merkle proof of payment to shift verification requirements to the relay

API Docs

relay_proposePayloadV1

Request

Response

  • result: object
    • status: enum - "VALID" | "INVALID" | "SYNCING"
    • latestValidHash: DATA|null, 32 Bytes - the hash of the most recent valid block in the branch defined by payload and its ancestors
    • validationError: String|null - a message providing additional details on the validation error if the payload is deemed INVALID
  • error: code and message set in case an exception happens while executing the payload.

engine_executePayloadV1

Request

Response

  • result: object
    • status: enum - "VALID" | "INVALID" | "SYNCING"
    • latestValidHash: DATA|null, 32 Bytes - the hash of the most recent valid block in the branch defined by payload and its ancestors
    • validationError: String|null - a message providing additional details on the validation error if the payload is deemed INVALID
  • error: code and message set in case an exception happens while executing the payload.

engine_forkchoiceUpdatedV1

Request

Response

  • result: object
    • status: enum - "SUCCESS" | "SYNCING"
    • payloadId: DATA|null, 8 Bytes - identifier of the payload build process or null
  • error: code and message set in case an exception happens while updating the forkchoice or initiating the payload build process.

engine_getPayloadV1

Request

  • method: engine_getPayloadV1
  • params:
    1. payloadId: DATA, 8 Bytes - Identifier of the payload build process

Response

  • result: ExecutionPayloadV1
  • error: code and message set in case an exception happens while getting the payload.

Build

make build

and then run it with:

./mev-boost

Test

make test

Lint

We use revive as a linter. You need to install it with go install github.com/mgechev/[email protected]

make lint
Comments
  • Remove use of `engine_forkchoiceUpdatedV1`

    Remove use of `engine_forkchoiceUpdatedV1`

    Currently engine_forkchoiceUpdatedV1 is used to communicate to relays the feeRecipient that a validator will be using. As a side effect, a lot of unnecessary information is communicated to the relays.

    I propose two potential alternatives:

    1. builder_getPayloadHeader(hash, feeRecipient) -> PayloadHeader
    2. builder_preparePayload(hash, feeRecipient) -> uint64 + builder_getPayloadHeader(payloadId) -> PayloadHeader

    I don't know if I have enough of an understanding of the latency of 1) to choose it over 2), but it is naively my preference.

    opened by lightclient 15
  • Recently proposed blocks

    Recently proposed blocks

    I'd like to discuss the idea of adding a method to relay API that returns blocks that have recently been proposed using relay.

    Goal

    The goal is to understand whether MEV-Boost was used to build a particular block and which relay was used for it. This is useful for participants such as staking pools to organize monitoring after validators that are operated by a third party.

    Proposed solution

    The goal can be achieved by adding a method that returns a block if it has been proposed using the current relay. Blocks can be stored in memory, and the stored number can be limited. Data for the last 32 slots should be enough for a third-party service to collect data about the last proposed blocks. All necessary data can be collected after a successful call to relay_proposeBlindedBlockV1 method.

    relay_getProposedBlindedBlockV1

    Request

    • method: relay_getProposedBlindedBlockV1
    • params:
      1. slot: slot number

    Response

    • result: ProposedBlock
    • error: code and message set in case an exception happens while performing the request.

    Types

    ProposedBlock

    Specification

    • Relay software MUST return proposed block if it has been proposed using the relay in the last 32 slots, otherwise return -32004: Unknown block.

    Alternatives

    This may not be the best solution, and I suggest discuss how to achieve the goal. Since Flashbots has a centralized API (blocks.flashbots.net) and probably want to support it after the Merge, I assume you may have a vision of collecting such data.

    validator relay 
    opened by avsetsin 12
  • SIGILL: illegal instruction

    SIGILL: illegal instruction

    Since version 0.7.10 I'm getting the following error when trying to run -help or -version..

    SIGILL: illegal instruction
    PC=0x6db7ae m=0 sigcode=2
    signal arrived during cgo execution
    instruction bytes: 0xf3 0x4c 0xf 0x38 0xf6 0xcf 0x66 0x4c 0xf 0x38 0xf6 0xd5 0xc4 0xe2 0xc3 0xf6
    
    goroutine 1 [syscall, locked to thread]:
    runtime.cgocall(0x6bda00, 0xc00013dba8)
    	/usr/local/go/src/runtime/cgocall.go:157 +0x5c fp=0xc00013db80 sp=0xc00013db48 pc=0x4097bc
    github.com/supranational/blst/bindings/go._Cfunc_blst_sk_to_pk2_in_g1(0x0, 0xc00012a240, 0xc000132ce0)
    	_cgo_gotypes.go:1317 +0x45 fp=0xc00013dba8 sp=0xc00013db80 pc=0x66f7e5
    github.com/supranational/blst/bindings/go.(*_Ctype_struct___4).From(...)
    	/home/ethereum/go/pkg/mod/github.com/supranational/[email protected]/bindings/go/blst.go:219
    github.com/flashbots/go-boost-utils/bls.PublicKeyFromSecretKey(...)
    	/home/ethereum/go/pkg/mod/github.com/flashbots/[email protected]/bls/bls.go:40
    github.com/flashbots/mev-boost/server.init()
    	/home/ethereum/go/pkg/mod/github.com/flashbots/[email protected]/server/mock_relay.go:25 +0xec fp=0xc00013dbf0 sp=0xc00013dba8 pc=0x6bb1cc
    runtime.doInit(0x990f40)
    	/usr/local/go/src/runtime/proc.go:6222 +0x126 fp=0xc00013dd20 sp=0xc00013dbf0 pc=0x4491e6
    runtime.doInit(0x98f000)
    	/usr/local/go/src/runtime/proc.go:6199 +0x71 fp=0xc00013de50 sp=0xc00013dd20 pc=0x449131
    runtime.doInit(0x98a600)
    	/usr/local/go/src/runtime/proc.go:6199 +0x71 fp=0xc00013df80 sp=0xc00013de50 pc=0x449131
    runtime.main()
    	/usr/local/go/src/runtime/proc.go:233 +0x1d3 fp=0xc00013dfe0 sp=0xc00013df80 pc=0x43c373
    runtime.goexit()
    	/usr/local/go/src/runtime/asm_amd64.s:1571 +0x1 fp=0xc00013dfe8 sp=0xc00013dfe0 pc=0x468ac1
    
    rax    0x0
    rbx    0x7f9f20
    rcx    0x7f99a0
    rdx    0x7817fc679976fff5
    rdi    0xc25f1572e1a87b0e
    rsi    0x7f9ea0
    rbp    0x2b7cd71362065849
    rsp    0x7ffc88619968
    r8     0x1f36a914d1d1ca54
    r9     0xe3f09cc9f448ab2c
    r10    0x53ae4ce3194e4adf
    r11    0x988f6b1f351f9469
    r12    0xf0030d9fa553ae92
    r13    0x8e738258ad84f1f6
    r14    0x685276af035ca2f
    r15    0x0
    rip    0x6db7ae
    rflags 0x10246
    cs     0x33
    fs     0x0
    gs     0x0
    
    

    I did not get this error with the previous two versions. How can I resolve this problem?

    opened by Jor-Tech 10
  • Open-source relay - which license to use?

    Open-source relay - which license to use?

    We will open source our mev-boost relay!

    (ETA early September)

    For context, this is our Ropsten relay: https://builder-relay-ropsten.flashbots.net (see also the Relay API Documentation)

    What's your opinions on the license we should use, and why?

    See also https://choosealicense.com/licenses

    Note: We were strongly considering AGPL, which would oblige anyone making changes to publish them as well, in order to foster a thriving development ecosystem around the mev-boost relays.

    brainstorming relay 
    opened by metachris 9
  • Reflect relays statuses in `status` endpoint

    Reflect relays statuses in `status` endpoint

    I think mev-boost status endpoint should call status endpoints for each relays and return OK if at least one returned OK. Otherwise it should return KO (503?).

    enhancement brainstorming 
    opened by tbenr 9
  • Simplify spec, update based on recent discussions

    Simplify spec, update based on recent discussions

    I took a stab at updating the spec based on our recent discussions about the spec. I need to update sequence diagram and the process overview, but I think it's relatively straightforward.

    A few notes:

    • I removed the concept of builder vs. relay methods and combined them. The CL can ignore things like feeRecipientDiff and signatures, or it can use that info to compare against it's local payload. I think this really simplifies things a lot.
    • I decided to go with SSZ encoding the block because it simplifies the spec a lot and is already the form that the builder will need it in to validate the signature.
    opened by lightclient 9
  • getHeader and submitBlindBlock latencies

    getHeader and submitBlindBlock latencies

    Not sure if this is the best place to track this. Feel free to close this and let me know a more appropriate place, we can move the issue somewhere else.

    I've been observing high latencies with both getStatus, getHeader and submitBlindBlock calls using the Kiln relay.

    getStatus, between 100-500ms Screen Shot 2022-07-11 at 2 34 00 PM

    getHeader, this gotten worse in the last 24 hours, many calls exceeded 1-2s Screen Shot 2022-07-11 at 2 33 26 PM

    submitBlindBlock, mostly around 200ms Screen Shot 2022-07-11 at 2 32 49 PM

    This is a prysm beacon node getting a beacon block for validator to sign. We are seeing 10-25x latency increases Screen Shot 2022-07-11 at 2 37 25 PM

    I understand that many moving parts are currently under optimized, but I still want to open an issue for tracking

    testing latency 
    opened by terencechain 8
  • could not register validator(s): code=502

    could not register validator(s): code=502

    describe:

    mev-boost runs on the Goerli/Prater testnet, mev-boost and geth run on the same server.

    running log:

    [2022-08-04 06:54:30]  WARN validator: Push proposer settings error, could not submit signed registrations to beacon node: rpc error: code = InvalidArgument desc = Could not register block builder: could not register validator(s): code=502, url=http://xx.xxx.xxx.xxx:18550/eth/v1/builder/validators, body=response body:
    {"code":502,"message":"no successful relay response"}
    : did not receive 2xx response from API: Builder API validator registration unsuccessful
    
    

    mev-boost version: mev-boost v0.7.8-2-ge63e526

    opened by 2019jack 7
  • Update instructions for running local ETH2 Beacon/Execution chain pair

    Update instructions for running local ETH2 Beacon/Execution chain pair

    tried to follow instructions, added a couple small clarifications

    📝 Summary

    some updates and missing steps for the setup instructions for a local PoS ETH2 net

    ⛱ Motivation and Context

    helps with developing against a local ETH network

    📚 References


    ✅ I have run these commands

    • [x] make lint
    • [x] make test
    • [x] make run-mergemock-integration
    • [x] go mod tidy
    opened by sourdzl 7
  • Bootstrapping fee recipient mapping to new relays/builders

    Bootstrapping fee recipient mapping to new relays/builders

    As we move to a p2p relay network, we need a mechanism that ensure that relays and builders who are new or go offline for a period of time are able to catch up to the latest. With the SetFeeRecipient method, this can be achieved roughly by sending announcements at regular intervals. However, this creates a lot of unnecessary network traffic. It would be better if there was a pull mechanism that a relay/builder could invoke when they wish to calculate the mapping. Here are a few ideas:

    • Fee recipient bulletin -- there could be a smart contract on mainnet that validators submit signed announcements to and builders could process all events from the contract to calculate the mapping. Since there is still no BLS primitive on mainnet, the mapping couldn't be authenticated on-chain. Thus, it is more of a bulletin.
    • Fee recipient DHT -- since the p2p network will likely already use discv5, we could use one of the extensions to store a mapping of validator to fee recipient. It's not clear how expensive it would be to iterate through this DHT, but at worst the relay/builder should be able to quickly get the proposers for the next epoch.
    • Fee recipient syncing -- as each announcement is signed, it would be possible to create a syncing strategy to acquire the mapping. It could be ranged over either validator indexes or unix time (e.g. "get latest announcements for validators n...m" or "get all announcements from n...m).

    Are there other approaches? I'm leaning a bit towards the syncing strategy as it seems simplest and most robust of the above ideas.

    brainstorming 
    opened by lightclient 7
  • JWT Auth

    JWT Auth

    How will MEV-boost handle auth for CL<>EL communication? https://github.com/ethereum/execution-apis/blob/main/src/engine/authentication.md

    Seems like most requests could just be forwarded, but engine_forkchoiceUpdatedV1 will need to be sent to the relay. So I think MEV-boost will need to accept a jwt-secret to let it decrypt engine_forkchoiceUpdatedV1 before sending it to the relay.

    opened by realbigsean 7
  • Requests to other relays are canceled as soon as one relay returns

    Requests to other relays are canceled as soon as one relay returns

    After proposing a block today, I saw the following messages:

    level=info msg="best bid" blockHash=<REDACTED> blockNumber=<REDACTED> method=getHeader module=service parentHash=<REDACTED> pubkey=<REDACTED> relays="https://<REDACTED>@bloxroute.max-profit.blxrbdn.com" slot=<REDACTED>  txRoot=<REDACTED> value=<REDACTED> 
    level=info msg="http: GET /eth/v1/builder/header/<REDACTED> /<REDACTED>/<REDACTED> 200" duration=0.180380465 method=GET module=service path=/eth/v1/builder/header/<REDACTED> /<REDACTED>/<REDACTED> status=200
    level=info msg="received payload from relay" blockHash=<REDACTED> method=getPayload module=service url="https://bloxroute.max-profit.blxrbdn.com/eth/v1/builder/blinded_blocks"
    level=error msg="error making request to relay" blockHash=<REDACTED> error="Post \"https://boost-relay.flashbots.net/eth/v1/builder/blinded_blocks\": context canceled" method=getPayload module=service url="https://boost-relay.flashbots.net/eth/v1/builder/blinded_blocks"
    level=info msg="http: POST /eth/v1/builder/blinded_blocks 200" duration=0.185630197 method=POST module=service path=/eth/v1/builder/blinded_blocks status=200
    

    Notably, the call to the flashbots relay was canceled, which would have returned a block with a larger reward than the bloxroute relay did.

    Glancing at the code, it seems that the requests to the rest of the relays might be cancelled upon the first relay returning: https://github.com/flashbots/mev-boost/blob/97207c6118778725f1703226f774e91e5395909d/server/service.go#L459

    opened by kwood 0
  • check for new releases on github, and log a warn if update is possible

    check for new releases on github, and log a warn if update is possible

    📝 Summary

    This is a proposal and request for comments and input.

    • check for new mev-boost releases on Github regularly, and log (info) if update is possible
    • can be disabled with setting env var DISABLE_NEW_RELEASE_CHECK=1
    • default check time: at startup and every 2 hours
    • timeout can be configured with NEW_RELEASE_CHECK_INTERVAL_H

    Question: should this be opt-in or opt-out?

    ⛱ Motivation and Context

    mev-boost users should get notified if new releases are available


    ✅ I have run these commands

    • [x] make lint
    • [x] make test-race
    • [x] go mod tidy
    opened by metachris 1
  • Cannot connect to Builder

    Cannot connect to Builder

    Hi I am running mev-boost client on goerli testnet with the following commands: sudo docker run flashbots/mev-boost -goerli -relay-check -relays=https://0xafa4c6985aa049fb79dd37010438cfebe[email protected]builder-relay-goerli.flashbots.net

    Iam get the following logs: mev.

    I am running my beacon node on goerli prater test net with the following commands: docker run -d -it -v /home/lucy/launch/prysm:/root -v /home/lucy/launch/geth/genesis.ssz:/genesis.ssz -v /home/lucy/launch/jwt.hex:/jwt.hex -p 4000:4000 -p 13000:13000 -p 12000:12000/udp --name beacon --net=host gcr.io/prysmaticlabs/prysm/beacon-chain:stable --datadir=/root --genesis-state=/genesis.ssz --accept-terms-of-use=true --rpc-host=0.0.0.0 --monitoring-host=0.0.0.0 --execution-endpoint=http://localhost:8551 --jwt-secret=/jwt.hex --suggested-fee-recipient=0x7Db8bD7FF6a856c1715a58BB4fd83BF43519bDa3 --http-mev-relay=http://localhost:18550 --prater

    I am getting the following error in the logs:

    beacon_error

    ERROR main: could not connect to builder: Get "http://localhost:18550/eth/v1/builder/status": dial tcp 127.0.0.1:18550: connect: connection refused

    opened by lucy-sha512 1
  • Allow more verbose logging of received payloads

    Allow more verbose logging of received payloads

    Even with https://github.com/flashbots/mev-boost/pull/309 it can be useful it can be useful to have a record of exactly what payload was not properly decoded, to determine whether it's a hitherto unspecified interoperability edge case between different assumptions of different JSON libraries or REST encoding/decodings.

    opened by tersec 0
  • Add more linters

    Add more linters

    Hi, I've worked quite a bit with linters. Is it interesting if I add golangci-lint as an Action and add linters one-by-one? It's been very useful in some projects I've been working on.

    opened by estensen 1
Releases(v1.3.1)
  • v1.3.1(Sep 16, 2022)

    What's Changed

    • Fix getPayload bug when deposit is included (by updating to go-boost-utils v1.1.1) in https://github.com/flashbots/mev-boost/pull/324 / https://github.com/flashbots/mev-boost/pull/322

    Thanks to @lightclient @terencechain @tbenr @StefanBratanov @tersec for collaboration on the solution ⭐

    Minor improvements

    • additional getPayload logging by @metachris in https://github.com/flashbots/mev-boost/pull/321

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v1.2.1...v1.3.1

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
    checksums.txt(509 bytes)
    mev-boost_1.3.1_darwin_amd64.tar.gz(5.38 MB)
    mev-boost_1.3.1_darwin_arm64.tar.gz(5.08 MB)
    mev-boost_1.3.1_linux_amd64.tar.gz(4.87 MB)
    mev-boost_1.3.1_linux_arm64.tar.gz(4.54 MB)
    mev-boost_1.3.1_windows_amd64.tar.gz(4.98 MB)
  • v1.2.1(Sep 14, 2022)

    Enhancements

    • -relay-check on startup: only log error if relays have errors (but don't fail) by @metachris in https://github.com/flashbots/mev-boost/pull/313
    • Add linter action by @estensen in https://github.com/flashbots/mev-boost/pull/307
    • ci cleanup and add golangci-lint to 'make clean' by @metachris in https://github.com/flashbots/mev-boost/pull/315
    • Log relay and value of received bids by @pietjepuk2 in https://github.com/flashbots/mev-boost/pull/305
    • Add SECURITY.md by @avalonche in https://github.com/flashbots/mev-boost/pull/302

    Changelog

    • ea15462 v1.2.1
    • b808c82 only log relay monitors on startup if provided
    • b00546b Add SECURITY.md (#302)
    • 8c8e7a9 WIP: (Feedback wanted) Log relay and value of received bids (#305)
    • aa7388f ci cleanup and add golangci-lint to 'make clean' (#315)
    • a718e39 Add linter action (#307)
    • 7bcc2ab only error if relays on startup have errors (#313)
    • c5344c2 goreleaser: prepare headers of release info
    • 70a8404 readme: improved installing instructions
    • 3b6406d v1.2.1-dev

    New Contributors

    • @pietjepuk2 made their first contribution in https://github.com/flashbots/mev-boost/pull/305

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v1.2.0...v1.2.1

    Source code(tar.gz)
    Source code(zip)
    checksums.txt(509 bytes)
    mev-boost_1.2.1_darwin_amd64.tar.gz(4.85 MB)
    mev-boost_1.2.1_darwin_arm64.tar.gz(4.58 MB)
    mev-boost_1.2.1_linux_amd64.tar.gz(4.41 MB)
    mev-boost_1.2.1_linux_arm64.tar.gz(4.11 MB)
    mev-boost_1.2.1_windows_amd64.tar.gz(4.50 MB)
  • v1.2.0(Sep 13, 2022)

    What's Changed

    • binary builds as release attachments by @franciscodiazydiaz and @metachris in https://github.com/flashbots/mev-boost/pull/289
    • additional getPayload logging by @metachris in https://github.com/flashbots/mev-boost/pull/309
    • reproducible builds by @metachris in https://github.com/flashbots/mev-boost/pull/310

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v1.1.0...v1.2.0

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
    checksums.txt(509 bytes)
    mev-boost_1.2.0_darwin_amd64.tar.gz(4.85 MB)
    mev-boost_1.2.0_darwin_arm64.tar.gz(4.58 MB)
    mev-boost_1.2.0_linux_amd64.tar.gz(4.41 MB)
    mev-boost_1.2.0_linux_arm64.tar.gz(4.11 MB)
    mev-boost_1.2.0_windows_amd64.tar.gz(4.50 MB)
  • v1.0.0(Sep 12, 2022)

    What's Changed

    • getHeader request timeout 950ms, allow setting timeouts individually for different requests by @metachris in https://github.com/flashbots/mev-boost/pull/290
    • Added note on configuration modifications for consensus clients by @fiiiu in https://github.com/flashbots/mev-boost/pull/291
    • readme typo by @kailinr in https://github.com/flashbots/mev-boost/pull/283
    • fix readme portable instructions by @metachris in https://github.com/flashbots/mev-boost/pull/288
    • Add relay monitor URLs by @avalonche in https://github.com/flashbots/mev-boost/pull/296
    • cleanup empty -relay-monitors handling by @metachris in https://github.com/flashbots/mev-boost/pull/300
    • fix endless loop on sending validations to relay monitor by @metachris in https://github.com/flashbots/mev-boost/pull/306

    New Contributors

    • @fiiiu made their first contribution in https://github.com/flashbots/mev-boost/pull/291

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.8.2...v1.0.0

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.8.2(Aug 31, 2022)

    What's Changed

    • portable blst build in docker images by @metachris - https://hub.docker.com/r/flashbots/mev-boost/tags
    • ignore bids with 0 value by @metachris in https://github.com/flashbots/mev-boost/pull/261
    • Use blockhash as tiebreaker for equal bids by @metachris in https://github.com/flashbots/mev-boost/pull/238
    • Parse slot/gas as uint64 in test code to prevent downcasting by @jtraglia in https://github.com/flashbots/mev-boost/pull/252
    • getPayload: error if payload parts are missing by @metachris in https://github.com/flashbots/mev-boost/pull/276
    • Documentation Update - README - Part 1 by @kailinr in https://github.com/flashbots/mev-boost/pull/254
    • feat: add dependabot support by @0xpanoramix in https://github.com/flashbots/mev-boost/pull/263
    • Check unchecked errors by @estensen in https://github.com/flashbots/mev-boost/pull/272

    New Contributors

    • @kailinr made their first contribution in https://github.com/flashbots/mev-boost/pull/254
    • @dmarzzz made their first contribution in https://github.com/flashbots/mev-boost/pull/264
    • @estensen made their first contribution in https://github.com/flashbots/mev-boost/pull/272

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.10...v0.8.2

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.7.10(Aug 15, 2022)

    What's Changed

    • Upgrade go-boost-utils to v0.3.5 by @Ruteri in https://github.com/flashbots/mev-boost/pull/249
    • getHeader: verify that pubkey in message is the relay-key we trust by @metachris in https://github.com/flashbots/mev-boost/pull/239
    • Upgrade from ioutil to os by @Ruteri in https://github.com/flashbots/mev-boost/pull/248
    • Respond to validator registration as soon as a single relay returns OK by @Ruteri in https://github.com/flashbots/mev-boost/pull/234
    • Adjust mergemock integration test cleanup by @Ruteri in https://github.com/flashbots/mev-boost/pull/235
    • readme cleanup by @metachris in https://github.com/flashbots/mev-boost/pull/236
    • Update table of contents & fix typo by @jtraglia in https://github.com/flashbots/mev-boost/pull/240
    • Fix data race in service test by @0xpanoramix in https://github.com/flashbots/mev-boost/pull/242

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.9...v0.7.10

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.7.8(Aug 3, 2022)

    What's Changed

    • -goerli flag by @metachris in https://github.com/flashbots/mev-boost/pull/228
    • if no payload is received, log which relays sent the corresponding bid by @metachris in https://github.com/flashbots/mev-boost/pull/229
    • Add the audit report by @elopio in https://github.com/flashbots/mev-boost/pull/223
    • readme update, remove goerli sf5 by @metachris in https://github.com/flashbots/mev-boost/pull/226

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.7...v0.7.8

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.7.7(Jul 20, 2022)

    What's Changed

    • allow go install github.com/flashbots/mev-boost by @metachris in https://github.com/flashbots/mev-boost/pull/214
    • Update instructions for running local ETH2 Beacon/Execution chain pair by @sourdzl in https://github.com/flashbots/mev-boost/pull/187
    • print usage when run without args (fails because it needs a network) by @metachris in https://github.com/flashbots/mev-boost/pull/216
    • We have a logo now :) by @thegostep in https://github.com/flashbots/mev-boost/pull/217
    • support for goerli-shadow-fork-5 by @metachris in https://github.com/flashbots/mev-boost/pull/218
    • server read + readheader timeout by @metachris in https://github.com/flashbots/mev-boost/pull/212

    New Contributors

    • @sourdzl made their first contribution in https://github.com/flashbots/mev-boost/pull/187

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.6...v0.7.7

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.7.6(Jul 15, 2022)

    • Added -version flag
    • fixed version in the Docket images

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.4...v0.7.5

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.7.5(Jul 15, 2022)

    What's Changed

    • Disallow indefinite http client timeout by @avalonche in https://github.com/flashbots/mev-boost/pull/210
    • Disallow unknown json fields in payload by @avalonche in https://github.com/flashbots/mev-boost/pull/211
    • Remove redundant signature check by @terencechain in https://github.com/flashbots/mev-boost/pull/209
    • Send version in User-Agent header by @metachris in https://github.com/flashbots/mev-boost/pull/213

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.4...v0.7.5

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.7.4(Jul 14, 2022)

    What's Changed

    • Handle unhandled errors by @terencechain in https://github.com/flashbots/mev-boost/pull/195
    • Move mergemock-integration to separate bash script by @jtraglia in https://github.com/flashbots/mev-boost/pull/193
    • Cleanup makefile by @jtraglia in https://github.com/flashbots/mev-boost/pull/194
    • Add redirect checks by @avalonche in https://github.com/flashbots/mev-boost/pull/205
    • Document the machine setup for installing mev-boost by @elopio in https://github.com/flashbots/mev-boost/pull/204
    • Default MaxHeaderSize to 4kb by @avalonche in https://github.com/flashbots/mev-boost/pull/206
    • RelayEntry arg support by @metachris in https://github.com/flashbots/mev-boost/pull/208

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.3...v0.7.4

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost

    Source code(tar.gz)
    Source code(zip)
  • v0.7.3(Jul 6, 2022)

    What's Changed

    • Add verifications in getHeader handler by @0xpanoramix in https://github.com/flashbots/mev-boost/pull/182
    • status-check: proxy relay check until first responds ok, enabled with… by @metachris in https://github.com/flashbots/mev-boost/pull/185
    • update go-boost-utils to v0.2.0 by @metachris in https://github.com/flashbots/mev-boost/pull/188
    • Fix some things I noticed when reviewing by @jtraglia in https://github.com/flashbots/mev-boost/pull/191
    • getHeader 204 (no content) by @metachris in https://github.com/flashbots/mev-boost/pull/190

    New Contributors

    • @jtraglia made their first contribution in https://github.com/flashbots/mev-boost/pull/191

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.0...v0.7.3

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost/tags

    Source code(tar.gz)
    Source code(zip)
  • v0.7.2(Jul 6, 2022)

    What's Changed

    • Add verifications in getHeader handler by @0xpanoramix in https://github.com/flashbots/mev-boost/pull/182
    • status-check: proxy relay check until first responds ok, enabled with… by @metachris in https://github.com/flashbots/mev-boost/pull/185
    • update go-boost-utils to v0.2.0 by @metachris in https://github.com/flashbots/mev-boost/pull/188 (issue reported by @jtraglia)

    Full Changelog: https://github.com/flashbots/mev-boost/compare/v0.7.0...v0.7.2

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost/tags

    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Jun 30, 2022)

    Updates https://github.com/flashbots/mev-boost/compare/v0.6.0...v0.7.0:

    • json logging (-json), and custom loglevel (-loglevel): #175 (@metachris)
    • registerValidator: remove signature check, leave up for relay: #176 (@metachris)
    • Simplify OK responses across handlers: #171 (@0xpanoramix)
    • improved error and ok response (with error handling): #177 (@metachris)
    • Add relays statuses calls in boost status endpoint: #172 (@0xpanoramix)

    Updated images are available on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost/tags

    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Jun 24, 2022)

    Updates https://github.com/flashbots/mev-boost/compare/v0.5.0...v0.6.0:

    • Returns correct error structs: #166
    • Disable server timeout: #165
    • Prepare sepolia genesis fork version: #168 (new -sepolia flag)

    Updated images on Docker Hub: https://hub.docker.com/r/flashbots/mev-boost/tags

    Source code(tar.gz)
    Source code(zip)
Owner
Flashbots
Flashbots
server-to-server sync application, written in go/golang.

svcpy: server to server copy a basic server-to-server copy application. on a single binary, it can be a server or a client. example usage: on the serv

Mert Akengin 0 Nov 4, 2021
Pape-server - A small server written in golang to serve a random wallpaper.

pape-server I like to inject custom CSS themes into a lot of websites and electron apps, however browsers don't let websites access local disk through

null 0 Dec 31, 2021
Server - Dupman server written in Go

server dupman server written in Go Requirements Go (>=1.17) Installation Usage C

dupman 9 Feb 22, 2022
HTTP API traffic recording and replay middleware based on GoReplay, can be used for migration and refactoring testing

gorc HTTP API traffic recording and replay middleware based on GoReplay, can be used for migration and refactoring testing. English | 中文 Requirements

Jioby 2 Feb 13, 2022
The seed repository for your Flamego middleware modules

seed This repository contains seed files that almost every repository of Flamego middleware module should have. Using the content Create an empty repo

Flamego 1 Dec 11, 2021
Header Block is a middleware plugin for Traefik to block request and response headers which regex matched by their name and/or value

Header Block is a middleware plugin for Traefik to block request and response headers which regex matched by their name and/or value Conf

null 3 May 24, 2022
Log4Shell is a middleware plugin for Traefik which blocks JNDI attacks based on HTTP header values.

Log4Shell Mitigation Log4Shell is a middleware plugin for Traefik which blocks JNDI attacks based on HTTP header values. Related to the Log4J CVE: htt

Traefik Labs 33 Jul 26, 2022
Middleware for Blocking IP ranges by inserting CIDR Blocks and searching IPs through those blocks

firewall Middleware for Blocking IP ranges by inserting CIDR Blocks and searching IPs through those blocks. Features Easy to use Efficient and Fast Co

Golang libraries for everyone 5 May 20, 2022
SubCenter is a middleware that integrate task subscriptions and real-time push

Subscription Center SubCenter是一个集成各种任务并进行实时推送的中间件,本身不提供数据与推送服务。

Zhimin Sun 5 Aug 27, 2022
🧬 fiber middleware to automatically generate RESTful API documentation with Swagger

Swagger fiber middleware to automatically generate RESTful API documentation with Swagger Usage Add comments to your API source code, See Declarative

Fiber 82 Sep 23, 2022
A Language Server Protocol (LSP) server for Jsonnet

Jsonnet Language Server Warning: This project is in active development and is likely very buggy. A Language Server Protocol (LSP) server for Jsonnet.

Jack Baldry 17 Apr 29, 2022
The server-pubsub is the main backend of DATAVOC project that manages all the other web-server modules of the same project such as the processor

server-pubsub The server-pubsub is the main backend of DATAVOC project that manages all the other web-server modules of the same project such as the p

null 0 Dec 3, 2021
Server and client implementation of the grpc go libraries to perform unary, client streaming, server streaming and full duplex RPCs from gRPC go introduction

Description This is an implementation of a gRPC client and server that provides route guidance from gRPC Basics: Go tutorial. It demonstrates how to u

Joram Wambugu 0 Nov 24, 2021
Cert bound sts server - Certificate Bound Tokens using Security Token Exchange Server (STS)

Certificate Bound Tokens using Security Token Exchange Server (STS) Sample demonstration of Certificate Bound Tokens acquired from a Security Token Ex

null 0 Jan 2, 2022
Echo-server - An HTTP echo server designed for testing applications and proxies

echo-server An HTTP echo server designed for testing applications and proxies. R

Erik Cavalcanti 6 Sep 16, 2022
Broadcast-server - A simple Go server that broadcasts any data/stream

broadcast A simple Go server that broadcasts any data/stream usage data You can

Zack 55 Sep 24, 2022
Videos2gether-server - Server for the Realtime video streaming app Videos2Gether

Videos Together server Server source code for the https://videos2gether.com Arch

Tiago Taquelim 0 Jan 9, 2022
JPRQ Customizer is a customizer that helps to use the JPRQ server code and make it compatible with your own server with custom subdomain and domain

JPRQ Customizer is a customizer that helps to use the JPRQ server code and make it compatible with your own server with custom subdomain and domain.You can upload the generated directory to your web server and expose user localhost to public internet. You can use this to make your local machine a command center for your ethical hacking purpose ;)

Abir Ghosh 1 Jan 19, 2022
Envoy-eds-server - Envoy EDS server is a working Envoy Discovery Service implementation

envoy-eds-server Intro Envoy EDS server is a working Envoy Discovery Service imp

Radu Crisan 2 Apr 2, 2022