Calea Ethereum de a rezista cenzurii: BRAID vs. FOCIL
În peisajul evolutiv al Ethereum, lupta pentru rezistența la cenzură a introdus mai multe mecanisme inovatoare. Dintre acestea, BRAID și FOCIL se remarcă ca două abordări promițătoare concepute pentru a proteja integritatea rețelei prin minimizarea riscului de cenzură a tranzacțiilor.
Ambele soluții abordează aspecte critice ale procesului de propuneri de bloc, dar adoptă abordări fundamental diferite pentru a-și atinge obiectivele. Acest articol analizează nuanțele acestor două mecanisme și analizează care s-ar putea dovedi în cele din urmă mai eficient.
Înțelegerea amenințării cenzurii în Ethereum
În centrul procesului de generare și validare a blocurilor Ethereum se află doi actori principali: builders și proposers. Constructorii sunt responsabili pentru sortarea tranzacțiilor și trimiterea unui bloc către propunători, care selectează apoi un bloc pe care îl semnează și îl propun blockchain.
Cu toate acestea, acest proces creează o vulnerabilitate potențială. Având în vedere că autorii propunerilor au ultimul cuvânt de spus în ceea ce privește blocul propus, există riscul unei înțelegeri între autorii propunerilor și constructori pentru a cenzura anumite tranzacții, amenințând astfel principiul Ethereum de rezistență la cenzură.
Rezistența la cenzură este esențială pentru menținerea echității și transparenței blockchain-ului. Dacă autorii propunerilor pot include sau exclude în mod selectiv tranzacții, acest lucru subminează natura descentralizată a rețelei și poate duce la exploatarea ordonării tranzacțiilor, ceea ce duce la probleme precum valoarea extractibilă a minerilor (MEV).
Soluții existente: MCP și FOCIL
Pentru a aborda această provocare, au fost propuse mai multe soluții rezistente la cenzură, două dintre cele mai discutate fiind mecanismele FOCIL (Force Inclusion List) și MCP (Multi-Concurrent Proposer).
Lista de incluziune a forței (FOCIL)
FOCIL este conceput pentru a asigura corectitudinea prin implicarea unui comitet de validatori selectat aleatoriu în fiecare interval de timp.
Acești validatori creează liste locale de includere pe baza opiniilor lor despre mempool și difuzează aceste liste.
Propunătorul agregă apoi aceste liste locale într-o listă finală de incluziune care este adăugată la bloc.
Acest mecanism asigură faptul că niciun propunător nu deține controlul deplin asupra tranzacțiilor incluse într-un bloc, reducând astfel riscul de cenzură.
Validatorii verifică dacă blocul aderă la regulile de consens înainte de a-l accepta în blockchain.
Propunător multi-concurent (MCP)
MCP introduce conceptul de multipli propunători concurenți, așa cum a sugerat pentru prima dată Max Resnick în mecanismul Multiplicity.
În acest sistem, mai mulți propunători lucrează în paralel, fiecare selectând o parte a tranzacțiilor din mempool.
Aceste tranzacții sunt grupate în „pachete de tranzacții speciale” și semnate de ofertanți. Propunerea principală trebuie să includă cel puțin două treimi din aceste pachete în blocul propus pentru ca acesta să fie considerat valid.
Această metodă descentralizează puterea unui singur propunător și reduce semnificativ probabilitatea cenzurării tranzacțiilor.
BRAID: O implementare MCP îmbunătățită
Pornind de la conceptul MCP, Max Resnick a dezvoltat BRAID, o implementare MCP mai sofisticată și mai completă.
Prezentat în cadrul seminarului „DeFi în era MEV” găzduit de Paradigm, BRAID permite mai multor propunători să propună simultan blocuri pe diferite lanțuri paralele.
Aceste blocuri sunt apoi sincronizate prin intermediul unui mecanism de consens pentru a asigura coerența între lanțuri.
Stratul de execuție al Ethereum consolidează toate blocurile generate în cadrul slotului într-un singur bloc de execuție, unde tranzacțiile sunt deduplicate, ordonate și executate în conformitate cu reguli predefinite.
Această abordare reduce semnificativ puterea unei singure entități de a manipula înregistrările tranzacțiilor.
Un avantaj cheie al BRAID este evitarea rolurilor suplimentare sau a structurilor complexe de stimulare, care pot adăuga complexitate.
Cu toate acestea, coordonarea sincronizării între mai multe sub lanțuri și gestionarea procesării datelor reprezintă propriile provocări.
Provocări și considerații în BRAID
În ciuda punctelor sale forte, BRAID nu este lipsit de probleme. O provocare notabilă este modelul „bacșișului condiționat”, care impune utilizatorilor să dispună de lichidități pentru a se asigura că tranzacțiile lor sunt rezistente la cenzură. Utilizatorii trebuie să stabilească două valori ale bacșișului atunci când trimit tranzacții:
- Vârf mai înalt (T): suma maximă pe care un utilizator este dispus să o plătească pentru a se asigura că tranzacția sa este inclusă chiar dacă se încearcă cenzurarea. În cazul în care un singur autor include tranzacția, acesta primește suma totală de T.
- Vârful inferior (t): un bacșiș mai mic care este plătit în cazul în care mai mulți propuși includ tranzacția. În acest caz, bacșișul este distribuit între ofertanții care includ tranzacția.
Acest model, deși eficient în descurajarea cenzurii, introduce complexitate și costuri suplimentare pentru utilizatori. Aceștia trebuie să rezerve lichidități suplimentare la momentul tranzacției, care pot fi înghețate până când se stabilește dacă vor fi necesare.
Pentru a aborda aceste probleme, Jonahb de la Blockchain Capital sugerează două soluții potențiale:
- Dovada lichidității post-statale: Această abordare permite utilizatorilor să facă dovada că vor avea suficiente lichidități pentru a plăti bacșișul mai mare după executarea tranzacției. Cu toate acestea, este necesar ca propușii să înțeleagă situația post-tranzacție, ceea ce este dificil în cazul tranzacțiilor care implică partajarea statului sau operațiuni financiare complexe.
- Asigurarea împotriva cenzurii: Acest concept introduce furnizori terți de asigurare de cenzură (CI) care garantează bacșișul utilizatorului în schimbul unei taxe. Acest lucru reduce povara imediată a lichidităților asupra utilizatorilor, dar necesită dezvoltarea unei piețe între utilizatori și furnizorii de CI.
Perspective comunitare: FOCIL vs. BRAID
Comunitatea Ethereum este divizată cu privire la meritele relative ale FOCIL și BRAID. Terence, un dezvoltator pentru clientul Ethereum Prysm, apreciază faptul că BRAID nu necesită participanți suplimentari, simplificând procesul în comparație cu FOCIL, care introduce constrângeri suplimentare de timp pentru depunerea și verificarea listelor de incluziune. Cu toate acestea, FOCIL este considerat, în general, mai ușor de implementat și mai flexibil.
Dan Robinson, cercetător la Paradigm, laudă BRAID pentru abordarea sa de prioritizare a tranzacțiilor, reducând în mod eficient riscurile legate de MEV. El subliniază, de asemenea, mecanismul de basculare condiționată ca fiind un stimulent puternic împotriva cenzurii – un aspect care lipsește FOCIL.
În schimb, dezvoltatorul Dev favorizează FOCIL pentru simplitatea sa și rezistența robustă la cenzură, sugerând că FOCIL oferă o implementare mai simplă, cu mai puține complicații.
Cercetătorul Ethereum barnabe.eth recunoaște că, deși BRAID poate oferi îmbunătățiri în anumite domenii, el este precaut în ceea ce privește abandonarea completă a modelului bazat pe lider pe care sunt construite FOCIL și alte modele de IL, menționând necesitatea unor cercetări și dovezi suplimentare pentru a valida fezabilitatea BRAID.
Concluzie: Care mecanism este superior?
Dezbaterea dintre BRAID și FOCIL evidențiază complexitatea obținerii rezistenței la cenzură în Ethereum. Abordarea inovatoare a BRAID de a descentraliza puterea propunerii și de a reduce riscul MEV este convingătoare, însă vine cu provocări semnificative de punere în aplicare și necesită o dezvoltare suplimentară.
FOCIL, deși mai simplu și mai flexibil, poate să nu ofere același nivel de robustețe împotriva încercărilor sofisticate de cenzură.
În cele din urmă, alegerea între BRAID și FOCIL poate depinde de prioritățile specifice ale rețelei Ethereum la un moment dat. Pe măsură ce ecosistemul continuă să evolueze, ambele mecanisme ar putea juca un rol în consolidarea rezistenței Ethereum la cenzură, asigurându-se că rețeaua rămâne fidelă principiilor sale descentralizate.