Ethereum Block Building: piilotettu talous jokaisen transaktion takana

Block Building on keskeinen osa Ethereumin elinkaarta, joka koostuu useista liikkuvista osista. Se määrittää, mitkä tapahtumat sisällytetään lohkoon ja missä järjestyksessä, mikä vaikuttaa suoraan verkon tehokkuuteen, hajauttamiseen ja oikeudenmukaisuuteen. Ajan myötä Ethereumin lohkotuotantoprosessi on kehittynyt erityisesti MEV:n kasvavan roolin ja siirtymisen myötä validaattorilähtöisestä valinnasta erikoistuneisiin rakentajiin.

Tässä postauksessa keskustellaan siitä, miten Ethereum Block Building on kehittynyt yhdessä Proposer Builder Separationin ja tulevan tutkimuksen käyttöönoton kanssa.

Pohjamaali Ethereum Block -rakennuskomponenteille

Slotit ja aikakaudet

Ethereum järjestää ajan erillisiin yksiköihin:

• Aikaväli: Aikaväli on 12 sekunnin jakso, jonka aikana voidaan ehdottaa yhtä lohkoa. Jos mikään validaattori ei lähetä lohkoa aikavälissä, se ohitetaan.
• Epoch: Epookki koostuu 32 paikasta, yhteensä 6,4 minuuttia .

Kunkin aikakauden lopussa validaattorin tehtävät sekoitetaan hajauttamisen ja turvallisuuden varmistamiseksi. Ethereum saavuttaa taloudellisen lopullisuuden 2 epookin (~12,8 min) jälkeen, minkä jälkeen lohkojen palauttaminen on lähes mahdotonta.

komiteat

Ethereumilla on valtava määrä validaattoreita verkossa. Kirjoitushetkellä beaconcha.in mukaan aktiivisia validaattoreita on 1 051 349. Olisi mahdotonta, jos näin monen validaattorin olisi tarkistettava jokainen lohko 12 sekunnin välein. Tästä syystä validaattorit on jaettu komiteoihin transaktioiden tehokkaan validoinnin ja eston kelpoisuuden osoittamiseksi.

Jokainen toimikunta:

• Koostuu validaattoreiden osajoukosta, jotka on määrätty satunnaisesti aikakauden alussa RANDAO:n avulla.
• Varmistaa, ettei yhdelläkään validoijalla ole suhteettoman suurta vaikutusta.
• Osallistuu lohkojen äänestykseen (todistamiseen) ja niiden oikeellisuuden vahvistamiseen.

Komitean koko riippuu verkoston aktiivisten validoijien kokonaismäärästä, mutta yleensä jokaisessa komiteassa on vähintään 128 validaattoria.

Jokaisessa paikassa:

• Oletetaan, että paikkaa kohden on osoitettu N komiteaa ja sanotaan, että jokaisessa toimikunnassa on M validaattoria (jossa M >128). Tämä tarkoittaa, että jokaiselle paikkalle on NxM todistukset. Kuten ymmärrät, verkostolle voi nopeasti tulla ylivoimaista juorua näin moniin todistuksia.

• Kunkin komitean kokoajien tehtävänä on koota kunkin komitean todistukset. Tämä tarkoittaa M validaattorien komitean ulkopuolella. on vain 1 lopullinen Aggregated Attestation M sijasta.

• Joten jokaisessa paikassa on lopullinen N todistusta (1 kullekin kyseisen paikan komitealle), jotka juorutaan maailmanlaajuiseen aiheeseen. Seuraavan paikan ehdottaja poimii nämä N todistusta.

  
  

Muutama seikka pitää mielessä

• Epookin aikana jokainen aktiivinen validoija on täsmälleen yhden komitean jäsen, joten kaikki aikakauden komiteat ovat erillisiä.

• Protokolla säätää komiteoiden kokonaismäärää kullakin aikakaudella aktiivisten validaattoreiden lukumäärän mukaan.

• Nykyisessä suunnittelussa on 64 komiteaa per paikka eli N=64

  
  

Ehdotuksen tekijä

Majakkaketjun sekoitus on suunniteltu tarjoamaan vähintään 1 Epochin (32 paikkaa) ennakointia validaattorin tuleville komiteatehtäville sekoituksen ja välin sanelemaa todistusta varten. Huomaa , että tämä ennakointi ei koske ehdottamista, joka on tarkistettava kyseisen ajanjakson aikana.

get_committee_assignment voidaan kutsua jokaisen aikakauden alussa saadakseen tehtävän seuraavalle aikakaudelle ( current_epoch + 1 ). Näin validaattorit voivat myös laskea aliverkon tunnuksen, liittyä vastaavaan komiteaan ja valmistautua tehtäviinsä.

Lisäksi Validaattori voidaan määrätä tietyn komitean Aggregator . Jos näin on, heidän on myös tilattava vastaava aihe.

Ehdotuksen tekijän velvollisuudet

Jokaisesta aikavälistä valitaan yksi validoija vastaavasta komiteasta ehdottajaksi lohkon luomista ja lähettämistä varten.

Ehdotuksen tekijän rooli on ratkaiseva, koska hän:

• Muodosta lohko sisällyttämällä odottavat tapahtumat ja todistukset.
• Allekirjoita ja lähetä SignedBeaconBlock verkkoon.
• Ansaitse palkintoja kelvollisten lohkojen onnistuneesta ehdottamisesta.

Lyhyt pohjamaali MEV:lle

MEV on ylimääräinen voitto, jonka validaattorit (entiset kaivostyöläiset) keräävät järjestämällä uudelleen, mukaan lukien tai sensuroimalla tapahtumat lohkon sisällä.

Joitakin yleisiä MEV-strategioita ovat:

• Etukäteistoiminta : Kaupan tekeminen juuri ennen tunnettua kannattavaa kauppaa. Frontrunningia pidetään myös myrkyllisenä MEV:nä, koska se yllättää käyttäjän negatiivisella vaikutuksella.
• Takaisinkäynti : Tapahtuman suorittaminen heti tietyn tapahtuman jälkeen (esim. arbitraasibotit).
• Sandwich-hyökkäykset : Yhdistelmä etu- ja takajuoksua, erityisesti DeFi-kaupoissa.

Kuka poimii MEV:n?

• Validaattorit (Pre-PBS) : Kun validaattorit kontrolloivat lohkotuotantoa, heillä oli täysi harkintavalta tapahtumajärjestämisessä ja he voivat poimia MEV:n suoraan.
• Etsijät : Riippumattomat toimijat, jotka etsivät muistilistasta MEV-mahdollisuuksia ja lähettävät tapahtumat sen mukaisesti.
• Rakentajat (Post-PBS) : PBS:n jälkeen lohkon rakentajat ottavat roolin MEV-optimoitujen lohkojen rakentamisessa, kun taas validoijat valitsevat lohkot korkeimman tarjouksen tekijältä.

Block Building Pre-PBS: Validator-Centric MEV

Ennen kuin Ethereum siirtyi PBS:ään, ehdottajalla (aiemmin kaivostyöläiset PoW:ssa) oli täysi määräysvalta tapahtumajärjestämisessä . Tämä loi ekosysteemin, jossa validaattorit poimivat MEV:t suoraan tai ulkoistivat sen erikoistuneille etsijöille.

Kuinka se toimi ennen PBS:ää:

1. Tapahtumapooli : Tapahtumat lähetetään tavalliseen tapaan ja ne tulevat muistiin.
2. Validaattorit valitsivat tapahtumat mempoolista. Nämä voidaan tilata priority_fee , joka on maksuja, jotka käyttäjä on valmis maksamaan päästäkseen mukaan ensin. Se voidaan myös tilata tavalla, jolla Validator tuottaa enemmän tuloja (sandwich/frontrunning).
3. Validator rakentaa lohkon valitsemiensa tapahtumien perusteella.
4. Block Propagation : Allekirjoitettu lohko lähetetään verkkoon.

Tämä on hieman löyhästi abstraktoitu yksinkertaistamiseksi. Mutta tämä oli yleinen virtaus. Tätä voidaan kutsua Vanilla Block Buildingiksi

Ongelmia Pre-PBS-lohkorakennuksessa

• MEV-tehon keskittäminen : Suurilla validaattoreilla oli taloudellinen etu pienempiin verrattuna, koska ne pystyivät poimimaan MEV-energiaa tehokkaammin.
• Lisääntynyt sensuuririski : Validaattorit voivat halutessaan sulkea pois liiketoimet, jotka eivät olleet heidän taloudellisten kannustimiensa mukaisia.
• Verkon ruuhkautuminen ja korkeat kaasumaksut : MEV-tapahtumien tarjoussodat johtivat lohkotilan tehottomaan käyttöön, mikä lisäsi tavallisten käyttäjien kustannuksia.

PBS:n jälkeinen lohkorakennus: Hakijoiden ja rakentajien erottaminen

Validaattoriohjatun lohkorakentamisen keskittämisriskien ja tehottomuuden poistamiseksi otettiin käyttöön Proposer-Builder Separation (PBS) . PBS jakaa lohkotuotannon vastuut kahden erillisen kokonaisuuden kesken:

1. Block Builders : Yksiköt, jotka ovat erikoistuneet rakentamaan optimoituja lohkoja, jotka usein sisältävät MEV-strategioita.
2. Lohkojen ehdottajat (validaattorit) : Validaattorit eivät enää rakenna lohkoja itse; he vain valitsevat rakentajien tarjoaman kannattavimman lohkon.

Kuinka se toimii PBS:n jälkeen:

1. Builders Construct Blocks : Lohkonrakentajat kilpailevat kannattavimman lohkon rakentamisesta ottaen huomioon MEV-louhintamahdollisuudet.
2. Tarjous lohkon sisällyttämisestä : Rakentajat tekevät tarjouksen ehdottaakseen lohkoaan validaattoreille varmistaakseen, että validoijat saavat tuottoisimman vaihtoehdon.
3. Validaattorit valitsevat korkeimman tarjouksen : Yksittäisten tapahtumien valitsemisen sijaan vahvistajat valitsevat korkeimman tarjouksen tekevän lohkon maksimoiden palkkionsa.

Kuinka Ethereum-lohkorakennus toimii nyt

1. Käyttäjä lähettää tapahtuman JSON-RPC-liitetyn lompakon kautta.
2. Tämä tapahtuma lähetetään julkiseen muistiin. Kaikki tapahtumat jätetään tänne ennen kuin ne noudetaan ja vahvistetaan. Viime aikoina yksityiset tilausvirrat ovat nousseet keskeiseen asemaan, ja useimmat suuret pelaajat ovat valinneet tämän, koska se on kiertotapa lähettää tapahtumasi yleisölle käyttämällä sallittuja / yksityisiä kanavia. Katso lisää tietoa Dunen hallintapaneelista.

3. Hakijat → jotka ovat ulkoisia tahoja, jotka skannaavat muistipoolia jatkuvasti löytääkseen MEV-mahdollisuuksia ( lisätietoja alla ). He hakevat vastaavat tapahtumat ja lisäävät omat, jos ja kun se on tarpeen voiton saamiseksi. Luo sitten nippu näistä tapahtumista, joiden järjestystä on säilytettävä koko ajan, jotta Etsijä voi tehdä voittoa. Paketit ovat tilattuja tapahtumia, jotka on suoritettava atomaarisesti. Tämän paketin lisäksi he voivat lisätä paketin loppuun tapahtuman, joka ilmaisee "lahjuksen" rakentajalle. Tämä paketti lähetetään Builderille eth_sendBundle kutsun kautta.

   Huomautus : Hakijat ovat ulkoisia kokonaisuuksia ja vaikuttavat tapahtumien järjestykseen, mutta eivät osallistu lohkon validointiin tai konsensuspäätöksiin.

   

   
   

4. Rakentajat →Seuraava entiteetti on Rakentaja, joka itse asiassa rakentaa lohkon. He yrittävät maksimoida sekä maksutulot että MEV-tulot. Ne sisältävät Etsijien lähettämät niputetut tapahtumat (toivottavasti järjestyksessä) ja hyväksyvät Etsijien lähettämän maksun (lahjuksen). Rakentajat rakentavat suorituksen hyötykuormia vastaanotettujen tapahtumien avulla.

   Ne täyttävät lohkot:

   1. Etsijien lähettämät niput.

   2. Korkean prioriteetin liiketoimet.

   3. Tilaa yleiset tapahtumat pitämällä mielessä tuottojen maksimoiminen.

      
      

   He asettivat myös kentän feeRecipient omaan osoitteeseen, mikä tarkoittaa, että he saavat sekä Etsijän lahjuksia että kaikki palkkiot lähettämänsä lohkon tapahtumista. Rakentajat jättävät lohkonsa lopussa tapahtuman, joka toimii lahjuksena ehdotuksen tekijälle samalla tavalla kuin etsijä teki rakentajalle.

   
   

5. Releet → Builder-markkinat ovat kilpailevat markkinat, joilla useat rakentajat haluavat, että hyötykuormansa viimeistellään ansaitakseen palkkiot. Useimmat lohkot ovat kuitenkin muutaman tunnetun Block Builderin rakentamia, nimittäin BeaverBuild ja Titan. Tämän prosessin yksinkertaistamiseksi varsinaiselle ehdottajalle välittäjät ovat välittäjiä, jotka vahvistavat eri rakentajien lähettämät hyötykuormat ja valitsevat sen, jolla on suurin voitto/tarjous. Relay-Proposer-kommunikaatiossa käytetään sitovaa ja paljastamista vastaavaa siistiä temppua varmistaakseen, että ehdottaja ei huijaa jokaista entiteettiä tähän asti. Lisää täältä .

Laittamalla se yhteen

Relay Proposer Communication

On täysin mahdollista, että lohkohyötykuorman saatuaan ehdotuksen tekijä avaa lohkon, lisää tapahtumansa ja muuttaa järjestystä mielensä mukaan sekä asettaa feeRecipient vastaanottajan omaan osoitteeseen. Tämä tarkoittaisi, että jokainen yksittäinen entiteetti, joka on työskennellyt lohkonrakennusprosessissa tähän asti (Searcher → Builder → Relay), huijataan tai tekee "MEV-varastamista". Tämän estämiseksi välittäjä lähettää vain valitun lohkohyötykuorman otsikon. Tämä tapahtuu, kun ehdotuksen tekijä tekee eth_getPaylaodHeader kutsun. Rele lähettää nyt PayloadHeader tunnisteen, joka sisältää rungon tiivisteen, tarjouksen ja rakentajan allekirjoituksen.

Hakijalla on tässä vaiheessa kaksi vaihtoehtoa:

• Valitse releen tarjoama PayloadHeader (kutsutaan myös Blinded Block ). Jos näin on, ehdotuksen tekijän on allekirjoitettava otsikko avaimellaan ja lähetettävä se takaisin välittäjälle ja pyydettävä tämän seurauksena PayloadBody eth_returnSignedHeader -kutsulla. Nyt Relay suorittaa eth_sendPayload -kutsun, joka palauttaa koko ExecutionPayload kutsun ehdottajalle. Ehdotuksen tekijä yksinkertaisesti ehdottaa tätä lohkoa Ethereum Validator -verkostolle tai tarkemmin komitealle, johon hänet on määrätty.

  
  

• Hakija voi päättää olla hyväksymättä Releen lähettämää PayloadHeader , jolloin hänen on rakennettava lohko itse. Tämä sisältää MEV-mahdollisuuksien etsimisen ja tapahtumien tilaamisen sen mukaisesti. Tietysti tässä tapauksessa Ehdotuksen tekijä saa pitää koko tulot maksuista + MEV. Tämä ei kuitenkaan ole niin yksinkertaista kuin miltä näyttää. MEV:n löytäminen ja tulojen optimointi on melko laskentaa vaativa tehtävä, ja on mahdollista, että ehdotuksen tekijä ei ehkä pysty rakentamaan lohkoa ajoissa (12 sekuntia), jolloin jää väliin. Tässä skenaariossa ehdottaja saatetaan leikata verkosta.

Mutta entä tapauksessa 1, jos ehdottaja ei lähetä välittäjän lähettämää lohkoa?

Ehdotuksen tekijän on allekirjoitettava PayloadHeader juuri tästä syystä. Ennen otsikon lähettämistä rele lähettää PayloadBody Escrow säilytettäväksi. Kun välittäjä vastaanottaa allekirjoitetun PayloadHeader merkin ehdottajalta, se tarkistaa allekirjoituksen ja lähettää sulkutilaan tallennetun PayloadBody ehdottajalle. Oletetaan nyt, että ehdottaja ei sisällytä tätä lohkoa. Se rakentaa oman lohkonsa huomiotta tähän mennessä tehdyt tilaukset. Tässä tapauksessa allekirjoitus ei täsmää, koska otsikot ovat muuttuneet.

Rakentaja voi nyt lähettää nämä ristiriitaiset allekirjoitetut otsikot verkkoon, ja ehdottaja voidaan leikata verkosta.

Mikä estää Buildersia sensuroimasta liiketoimia?

No ei mitään. Yleisin syy siihen, miksi Builders saattaa sensuroida tapahtuman, on se, että se on vuorovaikutuksessa OFAC-osoitteiden kanssa. Yksinkertaistaen, OFAC käsittelee vuorovaikutteisia tapahtumia, joilla voi olla oikeudellisia seurauksia, joita kukaan ei selvästikään haluaisi päähänsä.

Censorship.pics:n mukaan Buildersin rakentamat lohkot sisältävät vain 0-7 % OFAC:n sanktioista tapahtumia.

Miten ratkaisemme tämän?

Yksi tunnetuimmista ratkaisuista tapahtumien sensurointiin tätä kirjoittaessa ovat Inclusion Lists .

Sisällysluettelot ovat luettelo tapahtumista (yhteenveto-nimisen kanssa), jotka paikan N ehdottaja lähettää yhdessä paikan N lohkon ehdotuksen kanssa.

Sisällysluettelot edellyttävät, että luettelon tapahtumat on sisällytettävä joko lohkoon N tai lohkoon N+1, muuten N+1-lohko on virheellinen. Näitä kutsutaan edelleenlähetysluetteloiksi.

Tämä IL-malli ei tietenkään mahdollista 100-prosenttista sensurointivastusta, mutta käynnissä on aktiivinen tutkimus näiden ehdotusten vahvistamiseksi ja monia siistejä optimointeja, joita voidaan soveltaa parantamaan kannustinrakennetta.

FOCIL

Fork Choice Enforced Inclusion Lists (FOCIL) on vuonna 2024 ehdotettu uusi muotoilu, joka kehittää ja parantaa sisällyttämistä koskevia luetteloita uskottavan neutraalisuuden lisäämiseksi.

FOCIL sallii useiden validoijien tarjota ehdotuksia sisällyttämisluetteloon tiettyä paikkaa varten. Tarkemmin sanottuna kuhunkin paikkaan valitaan satunnaisesti 16 validaattoria sisällyttämisluettelokomitean muodostamiseksi. Nämä jäsenet muodostavat kukin oman paikallisen IL:n ja juoruvat siitä verkostolle. Ehdotuksen tekijä kerää ja kokoaa saatavilla olevat paikalliset sisällyttämisluettelot lopulliseksi IL:ksi. IL-mallit ovat kevyitä, koska lohkoa ei tarvitse rakentaa uudelleen näiden tapahtumien sisällyttämiseksi; ne voidaan vain liittää lohkoon. Edellytys sille, että lohko täyttää IL-validointivaatimuksen, on " Lohko on voimassa, jos se sisältää kaikki tapahtumat kaikista IL:istä, kunnes lohko on täynnä."

PBS:n edut MEV-hallinnassa

• MEV-poiston hajauttaminen : Lohkojen rakentajat muutaman suuren validaattorin sijaan käsittelevät MEV-poiston, mikä vähentää validaattorin keskittämisriskejä. Tämä on kuitenkin kaksiteräinen miekka, koska Validatorin keskittämisen lieventämiseksi olemme ottaneet käyttöön rakentajien keskittämisen, jossa vain harvat rakentajat rakentavat suuren osan lohkoista.
• Oikeudenmukaisempi tulonjako : Validaattorit hyötyvät edelleen MEV:stä osallistumatta suoraan louhintaan, mikä tekee lohkotuotannosta oikeudenmukaisempaa.
• Tehokkaampi lohkotilan käyttö : Rakentajien välinen kilpailu johtaa optimoituihin lohkoihin, joilla on parempi kaasutehokkuus.

PBS:n haasteet

• Keskittämisriski rakentajien keskuudessa : Vaikka validaattorit ovat hajautettuja, muutamat hallitsevat rakentajat voisivat silti keskittää MEV-poiminnan.
• Luota ketjun ulkopuolisiin MEV-releisiin : PBS luottaa tällä hetkellä MEV-Boost-releisiin, jotka toimivat ketjun ulkopuolella ja aiheuttavat mahdollisia turvallisuusriskejä epäonnistumisena.

Viitteet:

Ethereumin ehdottajan ja rakentajan erottaminen: lupaukset ja todellisuus

Tutkimuksen tilanne: PBS:n sensuurin vastustus

Builder-sensuuri: ethereumin mätä ydin

EPF Wiki - PBS

Huomautuksia PBS:stä

Välitä mukaanottoluettelo

Kuka voittaa Ethereum Block -rakennushuutokaupat ja miksi?

FOCIL

Kiitokset