From 91f049bb9f04de585504cc1c78f8a9ebb3771dfb Mon Sep 17 00:00:00 2001 From: Shea Ketsdever Date: Mon, 10 Jul 2023 21:03:19 -0400 Subject: [PATCH 1/2] Rename matchmaker to node --- README.md | 14 ++++++++------ architecture.md | 2 +- specs/bundles/refund-recipient.md | 2 +- specs/bundles/v0.1.md | 4 ++-- 4 files changed, 12 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 560db89..58dd732 100644 --- a/README.md +++ b/README.md @@ -12,20 +12,22 @@ Today, orderflow originators like wallets and dapps do not actively participate Importantly, **MEV-Share is an open-source protocol, not a product or company**. MEV-share uses commitments and privacy to facilitate permissionless collaboration between orderflow originators and searchers, similarly to what MEV-Boost did for builders and validators. It is credibly neutral, permissionless for searchers, and does not enshrine a single block builder. Aggregating order flow to MEV-Share will greatly reduce proprietary order flow as a centralizing force on Ethereum while enabling orderflow originators to participate in the MEV supply chain. +> Note: The MEV-Share Matchmaker was renamed to the MEV-Share Node. This change is reflected in the specifications after June 2023. + ## Minimum standardizable interfaces There are many parties that may interact as part of the MEV-share protocol: 1. Orderflow providers / sources (users, wallets, dapps) 2. Searchers -3. Matchmakers +3. MEV-Share Nodes 4. Blockspace providers / proxies (builders, sequencers, validators, bundlers) A minimum set of interfaces includes: -1. How orderflow providers send orderflow and preferences (eg. privacy, redistribution) to matchmakers -2. How matchmakers share information about orderflow with searchers -3. How searchers send bids, orderflow, and preferences (eg. validity conditions) to matchmakers -4. How matchmakers send orderflow and preferences to blockspace providers -5. How value is redistributed to orderflow providers, blockspace providers, and matchmakers +1. How orderflow providers send orderflow and preferences (eg. privacy, redistribution) to MEV-Share Nodes +2. How MEV-Share Nodes share information about orderflow with searchers +3. How searchers send bids, orderflow, and preferences (eg. validity conditions) to MEV-Share Nodes +4. How MEV-Share Nodes send orderflow and preferences to blockspace providers +5. How value is redistributed to orderflow providers, blockspace providers, and MEV-Share Nodes ## Current architecture and APIs diff --git a/architecture.md b/architecture.md index a658652..7645cd4 100644 --- a/architecture.md +++ b/architecture.md @@ -1,3 +1,3 @@ ![mev-share-architecture-diagram](https://user-images.githubusercontent.com/2029632/233164770-a00f1d14-3361-486d-9b80-2af8ed2ee90c.png) -https://excalidraw.com/#json=elsgQaxoLJEizeh4iq-Wz,NsdOenLkg9gTy_CdMIWGgw +https://excalidraw.com/#json=1l2qz7Dp_bbEnOtwb8Wk5,bFNry1-SY4W34J59xkiFzA diff --git a/specs/bundles/refund-recipient.md b/specs/bundles/refund-recipient.md index ac516ba..ad0a09d 100644 --- a/specs/bundles/refund-recipient.md +++ b/specs/bundles/refund-recipient.md @@ -1,6 +1,6 @@ # `eth_sendBundle` -Matchmakers can use the `eth_sendBundle` method to send a bundle of transactions to a block builder. Specifically, the `refund-recipient` version of `eth_sendBundle` extends the [standard `eth_sendBundle` API](https://docs.flashbots.net/flashbots-auction/searchers/advanced/rpc-endpoint#eth_sendbundle) to support two additional fields (`refundPercent` and `refundRecipient`) which can optionally be set to specify how refunds from MEV-Share should be distributed. +MEV-Share Nodes can use the `eth_sendBundle` method to send a bundle of transactions to a block builder. Specifically, the `refund-recipient` version of `eth_sendBundle` extends the [standard `eth_sendBundle` API](https://docs.flashbots.net/flashbots-auction/searchers/advanced/rpc-endpoint#eth_sendbundle) to support two additional fields (`refundPercent` and `refundRecipient`) which can optionally be set to specify how refunds from MEV-Share should be distributed. * [`eth_sendBundle`](#eth_sendbundle) diff --git a/specs/bundles/v0.1.md b/specs/bundles/v0.1.md index bbc6e74..07bf7fd 100644 --- a/specs/bundles/v0.1.md +++ b/specs/bundles/v0.1.md @@ -1,6 +1,6 @@ # `mev_sendBundle` -Users and searchers can use `mev_sendBundle` to send a bundle of transactions [and transaction hashes] to a MEV-Share Matchmaker. Matchmakers can use `mev_sendBundle` to send a bundle of transactions to a block builder. +Users and searchers can use `mev_sendBundle` to send a bundle of transactions [and transaction hashes] to a MEV-Share Node. Nodes can use `mev_sendBundle` to send a bundle of transactions to a block builder. * [`mev_sendBundle`](#mev_sendbundle) @@ -179,7 +179,7 @@ For example, refund (MEV kickback) parameters are considered as a post-inclusion The `refundConfig` is specified by the original party (eg. user) who sends an input to MEV-Share. Given some refund X, the `refundConfig` specifies what % of X should be paid to what address(es). The `refundConfig` is not aware of the precise refund amount X, because this is not known until after the input has been sent to MEV-Share. -The `refund` is set by the matchmaker. It identifies what items in the bundle should be refunded -- ie. when a searcher submits a new bundle back to the Matchmaker, what indices contained hashes. The builder must simulate the bundle without these input transactions to determine what portion of the overall bundle payment came from searcher bids and should be redistributed. If bundles contain multiple input items then the Matchmaker is responsible for allocating the searcher bids across the other items in the bundle. The party who submits the input to the matchmaker could also use this field to specify their preference for what percentage of the searcher bid they receive. The matchmaker would use this information when producing the final `refund` field that is sent to a block builder. +The `refund` is set by the MEV-Share Node. It identifies what items in the bundle should be refunded -- ie. when a searcher submits a new bundle back to the MEV-Share Node, what indices contained hashes. The builder must simulate the bundle without these input transactions to determine what portion of the overall bundle payment came from searcher bids and should be redistributed. If bundles contain multiple input items then the MEV-Share Node is responsible for allocating the searcher bids across the other items in the bundle. The party who submits the input to the MEV-Share Node could also use this field to specify their preference for what percentage of the searcher bid they receive. The MEV-Share Node would use this information when producing the final `refund` field that is sent to a block builder. ### `privacy` From aebfc55074fe9f6668f345c5a450756637c666f7 Mon Sep 17 00:00:00 2001 From: sketsdever Date: Mon, 10 Jul 2023 21:04:01 -0400 Subject: [PATCH 2/2] New architecture diagram --- architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/architecture.md b/architecture.md index 7645cd4..97e12f3 100644 --- a/architecture.md +++ b/architecture.md @@ -1,3 +1,3 @@ -![mev-share-architecture-diagram](https://user-images.githubusercontent.com/2029632/233164770-a00f1d14-3361-486d-9b80-2af8ed2ee90c.png) +![mev-share architecture diagram](https://github.com/flashbots/mev-share/assets/2029632/35e0a2b9-6334-4cfd-94a4-679a788874dd) https://excalidraw.com/#json=1l2qz7Dp_bbEnOtwb8Wk5,bFNry1-SY4W34J59xkiFzA