# Minimal viable Decentarlized Orderflow Distributer (DOFD) **Main Objective:** This write-up tries to define a minimal viable DOFD with the lowest level of complexity that enables the decentralization of the order flow, and is useful to all involved parties at the same time: - Why do blockchain users want to use the DOFD?: - transaction revert protection (hence it allows users to set tight slippages and be better protected against sandwiching) - fast mining time (faster compared to the situation where users just integrating with one block builder) - Why block builders should integrate with DOFD? - Additional order flow allows them to win more frequently in MEV-Boost - Why ethereum fans should support it: - It creates a fair builder market and hence decentralizes the builder infrastructure. - Why this is not SUAVE: - Suave's scope is much broader (e.g.intends to give MEV back to users). Suave's scope is much more challenging and could be done in later iterations(Non-MVP) of the DOFD. ## Specifications: #### Privacy options: Privacy of order flow is a very important concept for trading and hence the MVP will support 3 models of privacy from the start: 1. **Hidden order flow:** Here, only the tx-hash, and transaction meta information like gas limit, and max-gas-price + tip are shared. The real transaction will only be shared with block-builders after they included the tx into their block. 1. **Signature-Hidden order flow:** This order flow will be shared with everyone, but the signatures are cut out. The signature will only be shared later if the block was produced according to a set of rules from listed block-builders. This means that this information can not be shared with any malicious block-builder, as the DOFD would not share the signature and the block will not receive enough signatures, due to data unavailability. 1. **Open order flow:** Orders shared in this mode will be part of the public mempool visible to everyone. ### Single node specification First, we will only describe the infrastructure with one single node to avoid many complexities. Later on, we will describe it as a fully decentralized network. **Single DOFD node infrastructure** - The single DOFD node will receive unencrypted transaction messages with an encryption intention (hidden, signature-hidden, open). - The order flow received by the single DOFD node is shared minus the private data(for hidden orders, only the transaction hashes are shared, for signature-hidden the whole payload minus the signature is shared) - Each builder has to register themselves permissionless on the ethereum blockchain in a 'register-contract'. To prevent misuse, a registration fee/bond might be charged. During the registration, builders share their public builder key. - Block builders compete to build the best blocks according to the MEV boost specification, but they are constrained by the following rule: - They are not allowed to have any reversion of any signature-hidden transactions in their block. - Any violation of the rule will result in a delisting of the builders from the official builders' list, first via governance, later maybe via zk-proofs. Hence these builders would not get the order flow in the future - unless they register again under a different name and pay the listing fees/bonds again. - Block builders continuously build new blocks and provide their best solutions to the MEV relays. The MEV relay will double-check with the single DOFD node, whether the data is available for the proposed block and only then relay the block to validators. Properties of the system: - Private transactions require trust in the relayer and the DOFD node that their transaction are not leaked (as is the case today). - Users that wanna use the DOFD could just integrate with the DOFD similar to Metamask allows integrating `flashbots protect` today. For each different encryption level, they would talk to the node with a different URL - For delisting the system needs a minimal form of governance: Initially, this could just be a multi-sig of high-reputable people in the blockchain space - Since in theory, there could be several DOFD systems - as there are several relayers today, the censorship resistance will not be hampered with. Only, if DOFDs decide that one of their rules for builders is to not include non-public order flow - to make the market fairer for all builders - then the censorship-resistance will be influenced. ### Network specification The actual implementation will likely vary a little bit according to which PBS implementation is chosen by the ethereum community. For the following, we assume that PBS has implemented a similar to this [2-slot PBS](https://ethresear.ch/t/two-slot-proposer-builder-separation/10980) proposal. - The DOFD nodes will select per block a committee of 256 members. - A trader erasure-codes the hidden payload of their transaction into 256 chunks (85 needed to recover), encrypts the i’th chunk to the public key of the i’th committee member, and sends this info to the DOFD nodes. Additionally, the trader needs to generate a zk-proof verifying that the signatures are valid and certain meta information - like transaction gas limit and transaction gas price and tip - are valid. - The DOFD nodes share the order flow - minus the hidden part - to everyone and the committee signs off the data availability of the hidden part - Builders are again - as described above - permissionless register themselves. Though there might be some registration fee/bond, to prevent misuse of order flow - The block-builders are building their blocks and participating in the MEV-Boost auction - The proposer accepts the highest-bid header for which they found at least 170 signatures - During the MEV-Boost auction, the proposer asks for the winning block and then sign it off, and sends the proposal to the committee according to their risk preference - The committee will evaluate the chosen block according to a set of rules. Initially, these rules will be: - there are no reverted transactions from the open and signature-hidden order flow in the block - no private order flow is included. The order flow should be seen by the majority of the nodes and at least 80 committee signatures should be available. - After successful validation, the committee will decrypt and publish the whole block - liveness is given if 85 of the 256 nodes are publishing their erasure code - If a block is proposed by a non-registered builder, and this builder is using hidden or signature/hidden order flow of the DOFD network, the committee will not publish the data necessary to finalize the block. This is done to enforce the rules - e.g. no reverted transaction - over the registered builders. Properties of the system: - order flow stays private, if not 85 of 256 of the nodes collude - data availability is given if 85 of 256 nodes are online and share their secrets - revert protection and privacy are on the same level as we have today with flashbots protect
Last changed by  
 
josojo
189

Read more

Untitled

Account,Airdrop,GnoOption,UserOption,Investor,Team,Advisor 0xa4848704A3B3f61bDC42c40CA964eA7295eD101C,4397000000000000000000,,,,, 0x0062f81720D5ca31bC6efAEfEA15307dD51797c9,4397000000000000000000,4397000000000000000000,4397000000000000000000,4397000000000000000000,4397000000000000000000,

1/20/2022
Spec of solution-judge and solution submission

About This specification describes a system for multi-semi-trusted solver setup for the Gnosis Protocol. This specification is quite simple, still requires some trust from the solvers, and allows us to learn more about the solver competition before we commence to the more decentralized staker-only solution. There are 3 main objectives for introducing this solution-judge: One is to build a platform for other solvers in order to have a more scalabe platform. Secondly, to easily onboard new liquidity sources and ensurring that orders are matched with the best available on-chain liquidity. And lastly, to decentralize the price finding mechanism and to ensure its fairness via a fair competition. The solution-judge is a server-instance that receives different solutions for settling order within the Gnosis Protocol. Solutions are found by different solver instances and send to the judge via an API. Each solution of a solver will be investigated for certain acceptance criteria by the solution-judge and ranked with an objective criteria. Best solutions will be submitted on-chain to the Gnosis-Protocol. Actors

6/8/2021
Untitled

Cultural fit interview Onno Conclusion: Onno is a very promising candidate. He seems to be very selfdriven, honest, authentic personality. His interest in crypto and working on forward looking projects is astonishing and promising at the same time. He stands out as continous learner. Alex: Highly recommend the hiring Chen: I think Onno is a good cultural fit and recommend hiring him Cultural-Fit Interview: Starting:

6/4/2021
Untitled

7/15/2019
Read more from josojo
Published on HackMD