Ethereumin tie sensuurin vastustamiseen: BRAID vs. FOCIL

Ethereumin tie sensuurin vastustamiseen: BRAID vs. FOCIL

Ethereumin kehittyvässä maisemassa on otettu käyttöön useita innovatiivisia mekanismeja sensuurin vastustamiseksi. Näistä BRAID ja FOCIL erottuvat kahdeksi lupaavaksi lähestymistavaksi, jotka on suunniteltu suojaamaan verkon eheyttä minimoimalla transaktioiden sensuurin riski.

Molemmissa ratkaisuissa käsitellään kortteliehdotusprosessin kriittisiä kysymyksiä, mutta niiden tavoitteet saavutetaan täysin eri tavoin. Tässä artikkelissa perehdytään näiden kahden mekanismin vivahteisiin ja tutkitaan, kumpi niistä voisi lopulta osoittautua tehokkaammaksi.

Sensuurin uhan ymmärtäminen Ethereumissa

Ethereumin lohkojen luomis- ja validointiprosessin ytimessä on kaksi ensisijaista toimijaa: rakentajat ja ehdottajat. Rakentajat vastaavat transaktioiden lajittelusta ja lohkon lähettämisestä proposereille, jotka sitten valitsevat yhden lohkon allekirjoitettavaksi ja ehdotettavaksi blockchain.

Tämä prosessi luo kuitenkin mahdollisen haavoittuvuuden. Koska ehdotusten tekijöillä on lopullinen päätösvalta siitä, mitä lohkoa ehdotetaan, on olemassa riski, että ehdotusten tekijät ja rakentajat tekevät salaliittoa tiettyjen transaktioiden sensuroimiseksi, mikä uhkaa Ethereumin sensuurin vastustamisen periaatetta.

Sensuurin vastustaminen on ratkaisevan tärkeää lohkoketjun oikeudenmukaisuuden ja läpinäkyvyyden säilyttämiseksi. Jos ehdottajat voivat valikoivasti sisällyttää transaktioita tai jättää niitä pois, se heikentää verkon hajautettua luonnetta ja voi johtaa transaktioiden järjestyksen hyväksikäyttöön, mikä johtaa MEV:n (Miner Extractable Value) kaltaisiin ongelmiin.

Olemassa olevat ratkaisut: MCP ja FOCIL

Tämän haasteen ratkaisemiseksi on ehdotettu useita sensuuria kestäviä ratkaisuja, joista kaksi eniten keskustelua herättänyttä ovat Force Inclusion List (FOCIL) ja Multi-Concurrent Proposer (MCP) -mekanismit.

Voimien sisällyttämisluettelo (FOCIL)

FOCILin tarkoituksena on varmistaa oikeudenmukaisuus ottamalla mukaan satunnaisesti valittu validointikomitea kullakin aikavälillä.

Nämä validoijat luovat paikallisia sisällyttämisluetteloita, jotka perustuvat niiden näkemyksiin mempoolista, ja lähettävät nämä luettelot.

Tämän jälkeen ehdotuksen tekijä kokoaa nämä paikalliset luettelot lopulliseksi luetteloksi, joka lisätään lohkoon.

Tällä mekanismilla varmistetaan, ettei yksikään yksittäinen ehdotusten tekijä voi täysin hallita lohkoon sisältyviä transaktioita, mikä vähentää sensuurin riskiä.

Validoijat varmistavat, että lohko noudattaa konsensussääntöjä, ennen kuin ne hyväksyvät sen lohkoketjuun.

Monivirtaehdotuksen tekijä (MCP)

MCP:ssä otetaan käyttöön käsite useista samanaikaisista ehdokkaista, jota Max Resnick ehdotti ensimmäisenä Multiplicity-mekanismissa.

Tässä järjestelmässä useat tarjoajat työskentelevät rinnakkain ja valitsevat kukin osan tapahtumista mempoolista.

Nämä maksutapahtumat pakataan ”erityisiin maksutapahtumakokonaisuuksiin”, ja ehdotuksen tekijät allekirjoittavat ne. Päähakijan on sisällytettävä vähintään kaksi kolmasosaa näistä nipuista ehdotettuun lohkoon, jotta sitä voidaan pitää pätevänä.

Tämä menetelmä hajauttaa yksittäisen ehdottajan valtaa ja vähentää huomattavasti tapahtumien sensuurin todennäköisyyttä.

BRAID: Parannettu MCP-toteutus

Max Resnick kehitti MCP-konseptin pohjalta BRAIDin, joka on kehittyneempi ja täydellisempi MCP-toteutus.

Paradigmin järjestämässä ”DeFi in MEV Era” -seminaarissa esitelty BRAID mahdollistaa sen, että useat hakijat voivat ehdottaa lohkoja samanaikaisesti eri rinnakkaisketjuihin.

Nämä lohkot synkronoidaan sitten konsensusmekanismin avulla, jotta varmistetaan ketjujen välinen johdonmukaisuus.

Ethereumin suorituskerros yhdistää kaikki korttipaikan sisällä luodut lohkot yhdeksi suorituslohkoksi, jossa transaktiot deduplikoidaan, järjestetään ja suoritetaan ennalta määriteltyjen sääntöjen mukaisesti.

Tämä lähestymistapa vähentää merkittävästi yksittäisen tahon valtaa manipuloida tapahtumatietoja.

BRAIDin keskeinen etu on se, että siinä vältetään ylimääräisiä rooleja tai monimutkaisia kannustinrakenteita, jotka voivat lisätä monimutkaisuutta.

BRAIDin MMC

Synkronoinnin koordinointi useiden alaketjujen välillä ja tietojenkäsittelyn käsittely asettaa kuitenkin omat haasteensa.

BRAID-järjestelmän haasteet ja näkökohdat

Vahvuuksistaan huolimatta BRAID ei ole ongelmaton. Yksi merkittävä haaste on ”ehdollisen tippauksen” malli, joka edellyttää, että käyttäjillä on oltava likviditeettiä, jotta heidän liiketoimensa ovat sensuurin kestäviä. Käyttäjien on asetettava kaksi tippiarvoa, kun he lähettävät tapahtumia:

  1. Korkeampi kärki (T): Enimmäissumma, jonka käyttäjä on valmis maksamaan varmistaakseen, että hänen tapahtumansa on mukana, vaikka sensuuria yritettäisiinkin. Jos vain yksi ehdotuksen tekijä sisällyttää tapahtuman, hän saa koko T:n summan.
  2. Alempi kärki (t): Pienempi juomaraha, joka maksetaan, jos useampi hakija osallistuu maksutapahtumaan. Tässä tapauksessa juomaraha jaetaan niiden ehdotuksen tekijöiden kesken, jotka sisällyttävät tapahtuman.

Vaikka tämä malli ehkäisee tehokkaasti sensuuria, se aiheuttaa käyttäjille lisää monimutkaisuutta ja kustannuksia. Käyttäjien on varattava ylimääräistä likviditeettiä tapahtumahetkellä, ja se voidaan jäädyttää, kunnes selviää, tarvitaanko sitä.

Näiden ongelmien ratkaisemiseksi Jonahb Blockchain Capitalista ehdottaa kahta mahdollista ratkaisua:

  • Todisteet valtion jälkeisestä maksuvalmiudesta: Tämän lähestymistavan avulla käyttäjät voivat todistaa, että heillä on riittävästi likviditeettiä korkeamman tipin maksamiseen transaktion toteuttamisen jälkeen. Tämä edellyttää kuitenkin, että ehdotuksen tekijät ymmärtävät transaktion jälkeisen tilan, mikä on haastavaa transaktioissa, joihin liittyy jaettua tilaa tai monimutkaisia rahoitustoimia.
  • Sensuurivakuutus: Tässä konseptissa otetaan käyttöön kolmannen osapuolen sensuurivakuutuksen (CI) tarjoajat, jotka takaavat käyttäjän kärjen maksua vastaan. Tämä vähentää käyttäjien välitöntä likviditeettitaakkaa, mutta edellyttää käyttäjien ja CI-tarjoajien välisten markkinoiden kehittämistä.

Yhteisön näkökulmat: FOCIL vs. BRAID

Ethereum-yhteisö on eri mieltä FOCILin ja BRAIDin suhteellisista eduista. Ethereum-asiakasohjelman Prysm kehittäjä Terence arvostaa sitä, että BRAID ei vaadi ylimääräisiä osallistujia, mikä yksinkertaistaa prosessia verrattuna FOCILiin, joka aiheuttaa ylimääräisiä aikarajoituksia sisällyttämislistojen toimittamiseen ja tarkistamiseen. FOCILia pidetään kuitenkin yleisesti helpompana toteuttaa ja joustavampana.

Paradigmin tutkija Dan Robinson kehuu BRAIDin lähestymistapaa liiketoimien priorisointiin, mikä vähentää tehokkaasti MEV-riskejä. Hän korostaa myös ehdollista tippimekanismia vahvana kannustimena sensuuria vastaan, mikä puuttuu FOCILista.

Sitä vastoin kehittäjä Dev suosii FOCILia sen yksinkertaisuuden ja vankan sensuurinsietokyvyn vuoksi, mikä viittaa siihen, että FOCIL tarjoaa suoraviivaisemman toteutuksen, jossa on vähemmän komplikaatioita.

Ethereumin tutkija barnabe.eth myöntää, että vaikka BRAID voi tarjota parannuksia tietyillä alueilla, hän on varovainen luopumaan täysin johtajiin perustuvasta mallista, johon FOCIL ja muut IL-mallit perustuvat, ja vetoaa siihen, että tarvitaan lisätutkimuksia ja todisteita BRAIDin toteutettavuuden validoimiseksi.

Johtopäätökset: Kumpi mekanismi on parempi?

BRAIDin ja FOCILin välinen keskustelu korostaa, miten monimutkaista on saavuttaa sensuurin vastustaminen Ethereumissa. BRAIDin innovatiivinen lähestymistapa ehdotusvallan hajauttamiseen ja MEV-riskin pienentämiseen on vakuuttava, mutta siihen liittyy kuitenkin merkittäviä täytäntöönpanohaasteita, ja se vaatii edelleen kehittämistä.

Vaikka FOCIL on yksinkertaisempi ja joustavampi, se ei ehkä ole yhtä kestävä monimutkaisia sensuuriyrityksiä vastaan.

Viime kädessä valinta BRAIDin ja FOCILin välillä voi riippua Ethereum-verkon erityisistä prioriteeteista kulloinkin. Ekosysteemin kehittyessä molemmat mekanismit voivat olla tärkeässä roolissa vahvistamassa Ethereumin vastustuskykyä sensuuria vastaan ja varmistamassa, että verkko pysyy uskollisena hajautetuille periaatteilleen.