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 on 12 sekunnin jakso, jonka aikana voidaan ehdottaa yhtä lohkoa. Jos mikään validaattori ei lähetä lohkoa aikavälissä, se ohitetaan. Aikaväli: Epookki koostuu 32 paikasta, yhteensä . Epoch: 6,4 minuuttia Kunkin aikakauden lopussa validaattorin tehtävät sekoitetaan hajauttamisen ja turvallisuuden varmistamiseksi. Ethereum saavuttaa taloudellisen lopullisuuden jälkeen, minkä jälkeen lohkojen palauttaminen on lähes mahdotonta. 2 epookin (~12,8 min) komiteat on valtava määrä validaattoreita verkossa. Kirjoitushetkellä 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 transaktioiden tehokkaan validoinnin ja eston kelpoisuuden osoittamiseksi. Ethereumilla beaconcha.in komiteoihin 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 komiteaa ja sanotaan, että jokaisessa toimikunnassa on validaattoria (jossa >128). Tämä tarkoittaa, että jokaiselle paikkalle on todistukset. Kuten ymmärrät, verkostolle voi nopeasti tulla ylivoimaista juorua näin moniin todistuksia. N M M NxM Kunkin komitean kokoajien tehtävänä on koota kunkin komitean todistukset. Tämä tarkoittaa validaattorien komitean ulkopuolella. on vain 1 lopullinen sijasta. M Aggregated Attestation M Joten jokaisessa paikassa on lopullinen todistusta (1 kullekin kyseisen paikan komitealle), jotka juorutaan maailmanlaajuiseen aiheeseen. Seuraavan paikan ehdottaja poimii nämä todistusta. N N 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 komiteaa per paikka eli 64 N=64 Ehdotuksen tekijä Majakkaketjun sekoitus on suunniteltu tarjoamaan vähintään ennakointia validaattorin tuleville komiteatehtäville sekoituksen ja välin sanelemaa todistusta varten. , että tämä ennakointi ei koske ehdottamista, joka on tarkistettava kyseisen ajanjakson aikana. 1 Epochin (32 paikkaa) Huomaa voidaan kutsua jokaisen aikakauden alussa saadakseen tehtävän seuraavalle aikakaudelle ( ). Näin validaattorit voivat myös laskea aliverkon tunnuksen, liittyä vastaavaan komiteaan ja valmistautua tehtäviinsä. get_committee_assignment current_epoch + 1 Lisäksi Validaattori voidaan määrätä tietyn komitean . Jos näin on, heidän on myös tilattava vastaava aihe. Aggregator Ehdotuksen tekijän velvollisuudet Jokaisesta aikavälistä valitaan lohkon luomista ja lähettämistä varten. yksi validoija vastaavasta komiteasta ehdottajaksi Ehdotuksen tekijän rooli on ratkaiseva, koska hän: Muodosta lohko sisällyttämällä odottavat tapahtumat ja todistukset. Allekirjoita ja lähetä verkkoon. SignedBeaconBlock 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: : 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. Etukäteistoiminta : Tapahtuman suorittaminen heti tietyn tapahtuman jälkeen (esim. arbitraasibotit). Takaisinkäynti : Yhdistelmä etu- ja takajuoksua, erityisesti DeFi-kaupoissa. Sandwich-hyökkäykset Kuka poimii MEV:n? : Kun validaattorit kontrolloivat lohkotuotantoa, heillä oli täysi harkintavalta tapahtumajärjestämisessä ja he voivat poimia MEV:n suoraan. Validaattorit (Pre-PBS) : Riippumattomat toimijat, jotka etsivät muistilistasta MEV-mahdollisuuksia ja lähettävät tapahtumat sen mukaisesti. Etsijät : PBS:n jälkeen lohkon rakentajat ottavat roolin MEV-optimoitujen lohkojen rakentamisessa, kun taas validoijat valitsevat lohkot korkeimman tarjouksen tekijältä. Rakentajat (Post-PBS) Block Building Pre-PBS: Validator-Centric MEV Ennen kuin Ethereum siirtyi PBS:ään, ehdottajalla (aiemmin kaivostyöläiset PoW:ssa) oli . Tämä loi ekosysteemin, jossa validaattorit poimivat MEV:t suoraan tai ulkoistivat sen erikoistuneille etsijöille. täysi määräysvalta tapahtumajärjestämisessä Kuinka se toimi ennen PBS:ää: : Tapahtumat lähetetään tavalliseen tapaan ja ne tulevat muistiin. Tapahtumapooli Validaattorit valitsivat tapahtumat mempoolista. Nämä voidaan tilata , 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). priority_fee Validator rakentaa lohkon valitsemiensa tapahtumien perusteella. : Allekirjoitettu lohko lähetetään verkkoon. Block Propagation 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 : Suurilla validaattoreilla oli taloudellinen etu pienempiin verrattuna, koska ne pystyivät poimimaan MEV-energiaa tehokkaammin. MEV-tehon keskittäminen : Validaattorit voivat halutessaan sulkea pois liiketoimet, jotka eivät olleet heidän taloudellisten kannustimiensa mukaisia. Lisääntynyt sensuuririski : MEV-tapahtumien tarjoussodat johtivat lohkotilan tehottomaan käyttöön, mikä lisäsi tavallisten käyttäjien kustannuksia. Verkon ruuhkautuminen ja korkeat kaasumaksut PBS:n jälkeinen lohkorakennus: Hakijoiden ja rakentajien erottaminen Validaattoriohjatun lohkorakentamisen keskittämisriskien ja tehottomuuden poistamiseksi otettiin käyttöön . PBS jakaa lohkotuotannon vastuut kahden erillisen kokonaisuuden kesken: Proposer-Builder Separation (PBS) : Yksiköt, jotka ovat erikoistuneet rakentamaan optimoituja lohkoja, jotka usein sisältävät MEV-strategioita. Block Builders : Validaattorit eivät enää rakenna lohkoja itse; he vain valitsevat rakentajien tarjoaman kannattavimman lohkon. Lohkojen ehdottajat (validaattorit) Kuinka se toimii PBS:n jälkeen: : Lohkonrakentajat kilpailevat kannattavimman lohkon rakentamisesta ottaen huomioon MEV-louhintamahdollisuudet. Builders Construct Blocks : Rakentajat tekevät tarjouksen ehdottaakseen lohkoaan validaattoreille varmistaakseen, että validoijat saavat tuottoisimman vaihtoehdon. Tarjous lohkon sisällyttämisestä : Yksittäisten tapahtumien valitsemisen sijaan vahvistajat valitsevat korkeimman tarjouksen tekevän lohkon maksimoiden palkkionsa. Validaattorit valitsevat korkeimman tarjouksen Kuinka Ethereum-lohkorakennus toimii nyt Käyttäjä lähettää tapahtuman JSON-RPC-liitetyn lompakon kautta. Tämä tapahtuma lähetetään julkiseen muistiin. Kaikki tapahtumat jätetään tänne ennen kuin ne noudetaan ja vahvistetaan. Viime aikoina 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 hallintapaneelista. yksityiset tilausvirrat Dunen → jotka ovat ulkoisia tahoja, jotka skannaavat muistipoolia jatkuvasti löytääkseen MEV-mahdollisuuksia ( ). 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 kutsun kautta. Hakijat lisätietoja alla eth_sendBundle : Hakijat ovat ulkoisia kokonaisuuksia ja vaikuttavat tapahtumien järjestykseen, mutta eivät osallistu lohkon validointiin tai konsensuspäätöksiin. Huomautus →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. Rakentajat Ne täyttävät lohkot: Etsijien lähettämät niput. Korkean prioriteetin liiketoimet. Tilaa yleiset tapahtumat pitämällä mielessä tuottojen maksimoiminen. He asettivat myös kentän 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. feeRecipient : Rakentajat ovat ulkoisia kokonaisuuksia, eivätkä ne ole suoraan vuorovaikutuksessa lohkoketjun kanssa. Huomautus → 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 ja 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ää . Releet BeaverBuild Titan. 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 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 kutsun. Rele lähettää nyt tunnisteen, joka sisältää rungon tiivisteen, tarjouksen ja rakentajan allekirjoituksen. feeRecipient eth_getPaylaodHeader PayloadHeader Hakijalla on tässä vaiheessa kaksi vaihtoehtoa: Valitse releen tarjoama (kutsutaan myös ). 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 -kutsulla. Nyt Relay suorittaa -kutsun, joka palauttaa koko kutsun ehdottajalle. Ehdotuksen tekijä yksinkertaisesti ehdottaa tätä lohkoa Ethereum Validator -verkostolle tai tarkemmin komitealle, johon hänet on määrätty. PayloadHeader Blinded Block PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload Hakija voi päättää olla hyväksymättä Releen lähettämää , 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. PayloadHeader Mutta entä tapauksessa 1, jos ehdottaja ei lähetä välittäjän lähettämää lohkoa? Ehdotuksen tekijän on allekirjoitettava juuri tästä syystä. Ennen otsikon lähettämistä rele lähettää säilytettäväksi. Kun välittäjä vastaanottaa allekirjoitetun merkin ehdottajalta, se tarkistaa allekirjoituksen ja lähettää sulkutilaan tallennetun 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. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Huomautus Kahden eri otsikon allekirjoittaminen samalle ehdotuspaikalle on rikos. 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 kanssa. OFAC-osoitteiden Yksinkertaistaen, OFAC käsittelee vuorovaikutteisia tapahtumia, joilla voi olla oikeudellisia seurauksia, joita kukaan ei selvästikään haluaisi päähänsä. mukaan Buildersin rakentamat lohkot sisältävät vain 0-7 % OFAC:n sanktioista tapahtumia. Censorship.pics:n Miten ratkaisemme tämän? Yksi tunnetuimmista ratkaisuista tapahtumien sensurointiin tätä kirjoittaessa ovat . Inclusion Lists ovat luettelo tapahtumista (yhteenveto-nimisen kanssa), jotka paikan N ehdottaja lähettää yhdessä paikan N lohkon ehdotuksen kanssa. Sisällysluettelot 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. : On olemassa myös käsite , joka tekee IL:n itse nykyiselle lohkolle N. Mutta tässä suunnittelussa oli taloudellisia puutteita, jotka johtivat Huomautus Spot Inclusion Lists eteenpäin sisällyttäviin luetteloihin. 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 on vuonna 2024 ehdotettu uusi muotoilu, joka kehittää ja parantaa sisällyttämistä koskevia luetteloita uskottavan neutraalisuuden lisäämiseksi. Fork Choice Enforced Inclusion Lists (FOCIL) 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ä." : IL-komitean jäsenet eivät voi taata minkäänlaista tapahtumajärjestystä, koska IL-tapahtumat voidaan sisällyttää mihin tahansa tilaukseen. Ne takaavat vain tapahtuman sisällyttämisen. Huomautus PBS:n edut MEV-hallinnassa : 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. MEV-poiston hajauttaminen : Validaattorit hyötyvät edelleen MEV:stä osallistumatta suoraan louhintaan, mikä tekee lohkotuotannosta oikeudenmukaisempaa. Oikeudenmukaisempi tulonjako : Rakentajien välinen kilpailu johtaa optimoituihin lohkoihin, joilla on parempi kaasutehokkuus. Tehokkaampi lohkotilan käyttö PBS:n haasteet : Vaikka validaattorit ovat hajautettuja, muutamat hallitsevat rakentajat voisivat silti keskittää MEV-poiminnan. Keskittämisriski rakentajien keskuudessa : PBS luottaa tällä hetkellä MEV-Boost-releisiin, jotka toimivat ketjun ulkopuolella ja aiheuttavat mahdollisia turvallisuusriskejä epäonnistumisena. Luota ketjun ulkopuolisiin MEV-releisiin 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 Kiitos , ja arvioinnista ja ehdotusten antamisesta. @mteam @Gajpower @unnawut
