Ethereums pad naar censuurbestendigheid: BRAID vs. FOCIL
In het evoluerende landschap van Ethereum heeft de strijd om censuurbestendigheid verschillende innovatieve mechanismen geïntroduceerd. BRAID en FOCIL springen eruit als twee veelbelovende benaderingen die zijn ontworpen om de integriteit van het netwerk te beschermen door het risico op censuur van transacties te minimaliseren.
Beide oplossingen pakken kritieke problemen in het proces van groepsvoorstellen aan, maar hanteren fundamenteel verschillende benaderingen om hun doelen te bereiken. Dit artikel gaat in op de nuances van deze twee mechanismen en onderzoekt welke uiteindelijk effectiever zou kunnen blijken.
De dreiging van censuur in Ethereum begrijpen
De kern van het Ethereum blokgeneratie- en validatieproces wordt gevormd door twee primaire actoren: builders en proposers. Bouwers zijn verantwoordelijk voor het sorteren van transacties en het indienen van een blok bij de voorstellers, die vervolgens één blok selecteren om te ondertekenen en voor te stellen aan de blockchain.
Dit proces creëert echter een potentiële kwetsbaarheid. Omdat indieners het laatste woord hebben over welk blok wordt voorgesteld, bestaat het risico dat indieners en bouwers samenspannen om bepaalde transacties te censureren, waardoor het principe van censuurbestendigheid van Ethereum in gevaar komt.
Weerstand tegen censuur is cruciaal om de eerlijkheid en transparantie van de blockchain te behouden. Als indieners selectief transacties kunnen opnemen of uitsluiten, ondermijnt dit de gedecentraliseerde aard van het netwerk en kan dit leiden tot het uitbuiten van het ordenen van transacties, wat resulteert in problemen zoals Miner Extractable Value (MEV).
Bestaande oplossingen: MCP en FOCIL
Om dit probleem aan te pakken zijn er verschillende censuurbestendige oplossingen voorgesteld, waarvan de twee meest besproken de Force Inclusion List (FOCIL) en de Multi-Concurrent Proposer (MCP) mechanismen zijn.
FOCIL (Force Inclusion List)
FOCIL is ontworpen om eerlijkheid te garanderen door een willekeurig gekozen comité van validators te betrekken bij elk tijdslot.
Deze validators maken lokale inclusielijsten aan op basis van hun kijk op de mempool en zenden deze lijsten uit.
De voorsteller voegt deze lokale lijsten samen tot een uiteindelijke insluitingslijst die aan het blok wordt toegevoegd.
Dit mechanisme zorgt ervoor dat geen enkele indiener de volledige controle heeft over de transacties in een blok, waardoor het risico op censuur kleiner wordt.
Validators controleren of het blok voldoet aan de consensusregels voordat ze het accepteren in de blockchain.
Multi-Concurrent Proposer (MCP)
MCP introduceert het concept van meerdere gelijktijdige indieners, zoals voor het eerst voorgesteld door Max Resnick in het Multiplicity mechanisme.
In dit systeem werken meerdere indieners parallel, waarbij ze elk een deel van de transacties uit de mempool selecteren.
Deze transacties worden verpakt in “speciale transactiebundels” en ondertekend door de indieners. De hoofdindiener moet ten minste tweederde van deze bundels in het voorgestelde blok opnemen om als geldig te worden beschouwd.
Deze methode decentraliseert de macht van een enkele indiener en verkleint de kans op transactiecensuur aanzienlijk.
BRAID: Een verbeterde MCP-implementatie
Voortbouwend op het MCP-concept ontwikkelde Max Resnick BRAID, een geavanceerdere en completere MCP-implementatie.
BRAID, dat werd geïntroduceerd tijdens het “DeFi in MEV Era” seminar georganiseerd door Paradigm, maakt het mogelijk dat meerdere indieners tegelijkertijd blokken voorstellen op verschillende parallelle ketens.
Deze blokken worden vervolgens gesynchroniseerd via een consensusmechanisme om consistentie tussen ketens te garanderen.
De uitvoeringslaag van Ethereum consolideert alle blokken die binnen het slot worden gegenereerd in een enkel uitvoeringsblok, waar transacties worden ontdubbeld, geordend en uitgevoerd volgens vooraf gedefinieerde regels.
Deze aanpak vermindert de macht van een enkele entiteit om transactierecords te manipuleren aanzienlijk.
Een belangrijk voordeel van BRAID is het vermijden van bijkomende rollen of complexe incentivestructuren, die complexiteit kunnen toevoegen.
Het coördineren van synchronisatie over meerdere subketens en het verwerken van gegevens brengt echter zijn eigen uitdagingen met zich mee.
Uitdagingen en overwegingen bij BRAID
Ondanks de sterke punten is BRAID niet zonder problemen. Een opmerkelijke uitdaging is het “voorwaardelijke fooi”-model, dat vereist dat gebruikers liquide middelen beschikbaar hebben om ervoor te zorgen dat hun transacties bestand zijn tegen censuur. Gebruikers moeten twee fooiwaarden instellen bij het indienen van transacties:
- Hogere tip (T): Het maximale bedrag dat een gebruiker bereid is te betalen om er zeker van te zijn dat zijn transactie wordt opgenomen, zelfs als censuur wordt geprobeerd. Als slechts één indiener de transactie opneemt, ontvangt deze het volledige bedrag van T.
- Onderste punt (t): Een kleinere fooi die wordt betaald als meerdere indieners de transactie vermelden. In dit geval wordt de fooi verdeeld over de indieners die de transactie vermelden.
Dit model is effectief om censuur te ontmoedigen, maar introduceert extra complexiteit en kosten voor gebruikers. Ze moeten extra liquiditeit reserveren op het moment van de transactie, die kan worden bevroren totdat wordt bepaald of het nodig zal zijn.
Om deze problemen aan te pakken, stelt Jonahb van Blockchain Capital twee mogelijke oplossingen voor:
- Bewijs van liquiditeit na de staat: Met deze aanpak kunnen gebruikers aantonen dat ze voldoende liquiditeit zullen hebben om de hogere fooi te betalen nadat de transactie is uitgevoerd. Dit vereist echter dat indieners inzicht hebben in de post-transactietoestand, wat een uitdaging is bij transacties met gedeelde staat of complexe financiële transacties.
- Censuur Verzekering: Dit concept introduceert externe aanbieders van censuurverzekeringen (CI’s) die de tip van de gebruiker garanderen in ruil voor een vergoeding. Dit vermindert de onmiddellijke liquiditeitslast voor gebruikers, maar vereist de ontwikkeling van een markt tussen gebruikers en CI-aanbieders.
Perspectieven van de gemeenschap: FOCIL vs. BRAID
De Ethereum gemeenschap is verdeeld over de relatieve verdiensten van FOCIL en BRAID. Terence, een ontwikkelaar voor de Ethereum client Prysm, waardeert het dat BRAID geen extra deelnemers vereist, wat het proces vereenvoudigt in vergelijking met FOCIL, dat extra tijd in beslag neemt voor het indienen en verifiëren van inclusielijsten. FOCIL wordt echter over het algemeen beschouwd als eenvoudiger te implementeren en flexibeler.
Dan Robinson, een onderzoeker bij Paradigm, prijst BRAID voor zijn benadering van het prioriteren van transacties, waardoor MEV-risico’s effectief worden verminderd. Hij benadrukt ook het voorwaardelijke kantelmechanisme als een sterke stimulans tegen censuur – een aspect dat FOCIL mist.
Omgekeerd geeft ontwikkelaar Dev de voorkeur aan FOCIL vanwege de eenvoud en robuuste censuurbestendigheid, wat suggereert dat FOCIL een eenvoudigere implementatie biedt met minder complicaties.
Ethereum-onderzoeker barnabe.eth erkent dat BRAID weliswaar op bepaalde gebieden verbeteringen kan bieden, maar dat hij voorzichtig is met het volledig loslaten van het leidergebaseerde model waarop FOCIL en andere IL-ontwerpen zijn gebouwd, en wijst op de noodzaak van verder onderzoek en bewijs om de haalbaarheid van BRAID te valideren.
Conclusie: Welk mechanisme is superieur?
Het debat tussen BRAID en FOCIL onderstreept de complexiteit van het bereiken van censuurbestendigheid in Ethereum. BRAID’s innovatieve benadering van het decentraliseren van de macht van de voorsteller en het verminderen van het MEV-risico is overtuigend, maar gaat gepaard met aanzienlijke implementatie-uitdagingen en vereist verdere ontwikkeling.
FOCIL is weliswaar eenvoudiger en flexibeler, maar biedt mogelijk niet dezelfde mate van robuustheid tegen geraffineerde censuurpogingen.
Uiteindelijk kan de keuze tussen BRAID en FOCIL afhangen van de specifieke prioriteiten van het Ethereum netwerk op een bepaald moment. Naarmate het ecosysteem zich verder ontwikkelt, kunnen beide mechanismen een rol spelen in het versterken van de weerstand van Ethereum tegen censuur en ervoor zorgen dat het netwerk trouw blijft aan zijn gedecentraliseerde principes.