原文标题：Mělo by být Ethereum v pořádku se zakotvením více věcí v protokolu?

Autor: Vitalik Buterin

Sestavil: Nian Yin Si Tang, Planet Daily

Od začátku projektu Ethereum existuje silná filozofie snažit se udělat jádro Etherea co nejjednodušší a dosáhnout toho co nejvíce tím, že na něm postavíme protokoly. V blockchainovém prostoru se debata „stavět na L1“ vs. „zaměření na L2“ často považuje za primárně o škálování, ale ve skutečnosti existují podobné problémy při uspokojování potřeb více uživatelů Etherea: digitální aktiva Výměna, soukromí , uživatelská jména, pokročilé šifrování, zabezpečení účtu, odolnost proti cenzuře, ochrana před spuštěním a další. V poslední době však došlo k několika opatrným pokusům začlenit více těchto funkcí do základního protokolu Ethereum.

Tento článek se ponoří do některých filozofických úvah za původní filozofií minimálního zapouzdření, stejně jako do některých současných způsobů uvažování o těchto myšlenkách. Cílem bude začít budovat rámec pro lepší identifikaci možných cílů, kde by zapouzdření určité funkčnosti mohlo stát za zvážení.

Raná filozofie protokolového minimalismu

V rané historii toho, co bylo tehdy známé jako „Ethereum 2.0“, existovala silná touha vytvořit čistý, jednoduchý a krásný protokol, který se snažil co nejméně stavět na sobě a téměř veškerou takovou práci přenechával uživatelům. V ideálním případě je protokol pouze virtuální stroj a ověření bloku je pouze volání virtuálního stroje.

Toto je přibližná rekonstrukce diagramu tabule, který jsem já a Gavin Gavin View More Wood nakreslili na začátku roku 2015, když jsem mluvil o tom, jak by Ethereum 2.0 vypadalo.

"Funkce přechodu stavu" (funkce, která zpracovává blok) bude pouze jediným voláním virtuálního počítače a veškerá další logika se bude dít prostřednictvím smluv: některých smluv na úrovni systému, ale většinou smluv poskytovaných uživateli. Velmi příjemnou vlastností tohoto modelu je, že i celý hard fork lze popsat jako jedinou transakci ke smlouvě o blokovém procesoru, která bude schválena off-chain nebo on-chain governance a následně upgradována oprávnění ke spuštění.

Tyto diskuse v roce 2015 se týkají konkrétně dvou oblastí, které zvažujeme: abstrakce účtů a škálování. V případě škálování je myšlenkou pokusit se vytvořit maximálně abstraktní formu škálování, která působí jako přirozené rozšíření výše uvedeného diagramu. Smlouvy mohou volat data, která nejsou uložena většinou uzlů Ethereum, a protokol to detekuje a vyřeší volání pomocí některé velmi obecné rozšířené výpočetní funkce. Z pohledu virtuálního stroje přejde hovor do nějakého samostatného subsystému a poté magicky vrátí správnou odpověď o nějaký čas později.

Krátce jsme tuto myšlenku prozkoumali, ale rychle jsme ji opustili, protože jsme se příliš soustředili na dokazování, že je možné jakékoli škálování blockchainu. I když, jak uvidíme později, kombinace vzorkování dostupnosti dat a ZK-EVM znamená, že možná budoucnost škálování Etherea ve skutečnosti vypadá velmi blízko této vizi! Na druhou stranu u abstrakce účtu jsme od začátku věděli, že nějaká implementace je možná, a tak se výzkum okamžitě začal snažit přiblížit něco co nejblíže čistému výchozímu bodu „transakce je jen hovor“.

Mezi zpracováním transakce a provedením skutečného základního volání EVM z adresy odesílatele je mnoho standardního kódu a poté další standardní kód. Jak snížíme tento kód co nejblíže nule?

Jedním z hlavních kódů je zde validate_transaction(state, tx), který je zodpovědný za kontrolu správnosti nonce a podpisu transakce. Skutečným cílem abstrakce účtu od začátku bylo umožnit uživatelům nahradit základní neinkrementální ověřování a ověřování ECDSA vlastní ověřovací logikou, aby uživatelé mohli snadněji využívat funkce, jako je sociální obnova a peněženky s více podpisy. Najít způsob, jak přebudovat apply_transaction do jednoduchého volání EVM, tedy není jen úkolem „vyčistit kód kvůli vyčištění kódu“, jde o přesun logiky do kódu uživatelského účtu, poskytnout uživatelům flexibilitu, kterou mají potřeba.

Trvání na tom, aby apply_transaction obsahovalo co nejméně pevné logiky, však vedlo ke vzniku mnoha výzev. Můžeme se podívat na jeden z prvních návrhů abstrakce účtu, EIP-86.

Pokud by byl EIP-86 zahrnut tak, jak je, snížilo by to složitost EVM za cenu masivního zvýšení složitosti ostatních částí zásobníku Ethereum, což by vyžadovalo, aby byl v podstatě stejný kód napsán jinde, navíc k zavedení celku. nová třída podivnosti Například stejná transakce se stejnou hodnotou hash se může v řetězci objevit vícekrát, nemluvě o problému vícenásobné invalidity.

Více problémů s neplatností v abstrakci účtu. Jedna transakce zahrnutá v řetězci by mohla zneplatnit tisíce dalších transakcí v mempoolu, takže by bylo snadné mempool levně naplnit.

Od té doby se abstrakce účtu vyvíjela po etapách. Z EIP-86 se později stal EIP-208 a nakonec praktický EIP-2938.

EIP-2938 je však všechno, jen ne minimalistické. Jeho obsah zahrnuje:

  • Nový typ transakce

  • Tři nové globální proměnné rozsahu transakcí

  • Dva nové operační kódy, včetně velmi neohrabaného operačního kódu PAYgas pro zpracování cen plynu a kontroly limitů plynu, jako hraniční body provádění EVM a pro dočasné uložení ETH pro jednorázové platby poplatků

  • Komplexní sada strategií těžby a opětovného vysílání, včetně seznamu zakázaných operačních kódů během fáze ověřování transakce

Ve snaze dosáhnout abstrakce účtů bez zapojení vývojářů jádra Ethereum (kteří se zaměřili na optimalizaci klientů Ethereum a implementaci sloučení), byl EIP-2938 nakonec přepracován na ERC-4337, který byl zcela mimo protokol.

ERC-4337. Spoléhá se výhradně na volání EVM!

Protože se jedná o ERC, nevyžaduje hard fork a technicky existuje „mimo protokol Ethereum“. Takže...problém vyřešen? Ukázalo se, že tomu tak není. Současný střednědobý plán ERC-4337 ve skutečnosti zahrnuje případné převedení velkých částí ERC-4337 do řady funkcí protokolu, což je užitečný příklad vodítka, proč je třeba zvážit tuto cestu.

Balíček ERC-4337

Existuje několik klíčových důvodů, proč nakonec ERC-4337 vrátit zpět do protokolu:

Efektivita plynu: Jakákoli operace prováděná uvnitř EVM představuje určitý stupeň režie virtuálního stroje, včetně neefektivity při používání funkcí drahých na plyn, jako jsou úložné sloty. V současné době tyto dodatečné neefektivity dávají dohromady nejméně 20 000 plynu, ne-li více. Vložení těchto součástí do protokolu je nejjednodušší způsob, jak tyto problémy odstranit.

Riziko chyby v kódu: Pokud má "smlouva o vstupním bodu" ERC-4337 dostatečně strašnou chybu, všechny peněženky kompatibilní s ERC-4337 by mohly vidět, že všechny jejich prostředky vyschnou. Nahrazení smluv funkčností v protokolu vytváří implicitní povinnost opravit chyby v kódu prostřednictvím hard forků, čímž se odstraní riziko, že uživatelům dojdou prostředky.

Podporuje operační kódy EVM, jako je txt.origin. ERC-4337 sám způsobí, že txt.origin vrátí adresu "svazovače", který zabalí sadu uživatelských akcí do transakce. Nativní abstrakce účtu řeší tento problém tím, že txt.origin ukazuje na skutečný účet odesílající transakci, takže se chová stejně jako EOA.

Odolnost vůči cenzuře: Jedním z problémů s oddělením navrhovatele a tvůrce je to, že je snadnější kontrolovat jednotlivé transakce. Ve světě, kde protokol Ethereum dokáže identifikovat jednotlivé transakce, lze tento problém výrazně zmírnit seznamy pro zařazení, které umožňují navrhovatelům specifikovat seznam transakcí, které musí být téměř ve všech případech zahrnuty do následujících dvou slotů. ERC-4337 mimo protokol však zapouzdřuje „uživatelské operace“ do jedné transakce, takže uživatelské operace jsou pro protokol Ethereum neprůhledné, a proto seznam zahrnutí poskytovaný protokolem Ethereum nebude schopen poskytnout uživateli ERC-4337 odolnost vůči cenzuře; operace. Tento problém by vyřešilo zabalení ERC-4337 a vytvoření „správného“ typu transakce uživatele.

Za zmínku stojí, že ve své současné podobě je ERC-4337 výrazně dražší než „základní“ transakce Ethereum: transakce stojí 21 000 plynu, zatímco ERC-4337 stojí kolem 42 000 plynu.

Teoreticky by mělo být možné upravit systém nákladů na plyn EVM, dokud se náklady v protokolu a náklady na přístup k úložišti mimo protokol neshodují, není důvod utrácet 9 000 plynu za převod ETH při jiných typech úprav úložiště operace jsou levnější. Ve skutečnosti se o to pokoušejí dvě EIP související s nadcházející transformací stromu Verkle. Ale i když to uděláme, existuje zřejmý důvod, proč bez ohledu na to, jak efektivní se EVM stane, funkce zapouzdřeného protokolu budou nevyhnutelně mnohem levnější než kód EVM: zapouzdřený kód nemusí platit plyn za předběžné nabíjení.

Plně funkční peněženka ERC-4337 je velká, s touto implementací zkompilovanou a vloženou do řetězce zabírá asi 12 800 bajtů. Samozřejmě můžete tento kód nasadit jednou a použít DELEGATECALL, abyste umožnili každé jednotlivé peněžence jej zavolat, ale stále byste museli mít přístup ke kódu v každém bloku, kde se používá. V rámci EIP stromové ceny plynu Verkle bude 12 800 bajtů tvořit 413 bloků a přístup k těmto blokům bude vyžadovat zaplacení 2násobku nákladů na svědeckou větev (celkem 3 800 plynu) a 413násobku ceny svědeckého bloku (celkem 82 600 plynu). To ani nezačíná zmiňovat samotný vstupní bod ERC-4337, který má ve verzi 0.6.0 23 689 bajtů v řetězci (přibližně 158 700 plynu k načtení podle pravidel EIP Verkle tree).

To vede k problému: náklady na plyn za skutečný přístup k těmto kódům musí být nějakým způsobem amortizovány napříč transakcemi. Současný přístup používaný ERC-4337 není příliš dobrý: první transakce v balíčku spotřebovává jednorázové náklady na úložiště/čtení kódu, takže je mnohem dražší než jiné transakce. Zapouzdření v rámci protokolu umožní těmto veřejným sdíleným knihovnám stát se součástí protokolu a volně přístupné všem.

Co se můžeme z tohoto příkladu naučit a kdy by se mělo zapouzdření obecněji praktikovat?

V tomto příkladu vidíme několik různých důvodů pro zapouzdření abstrakce účtů v protokolech.

Tržní přístupy, které „posouvají složitost na okraj“, s největší pravděpodobností selžou, když jsou fixní náklady vysoké. Ve skutečnosti se zdá, že plán dlouhodobé abstrakce účtu má mnoho fixních nákladů na blok. 244 100 plynu za načtení standardizovaného kódu peněženky je jedna věc, ale agregace může přidat stovky tisíc plynu za ověření ZK-SNARK, stejně jako náklady na ověření v řetězci. Neexistuje způsob, jak účtovat uživatelům tyto náklady, aniž by došlo k masivní neefektivitě trhu, a přeměna některých těchto funkcí na funkce protokolu, které jsou volně přístupné všem, by tento problém velmi dobře vyřešilo.

Reakce celé komunity na chyby v kódu. Pokud nějaký kus kódu používají všichni uživatelé nebo velmi široká škála uživatelů, často dává větší smysl, aby blockchain komunita převzala odpovědnost hard forku za opravu jakýchkoliv vzniklých chyb. ERC-4337 zavádí velké množství globálně sdíleného kódu Z dlouhodobého hlediska je nepochybně rozumnější opravit chyby v kódu pomocí hard forku, než způsobit, že uživatelé ztratí velké množství ETH.

Někdy lze implementovat silnější formu protokolu přímým využitím jeho funkčnosti. Klíčovým příkladem jsou funkce protokolu odolné vůči cenzuře, jako jsou například seznamy začlenění: Seznamy zahrnuté v protokolu mohou zajistit odolnost proti cenzuře lépe než metody mimo protokol, aby operace na uživatelské úrovni skutečně těžily z protokolu včetně seznamů, jednotlivých uživatelů Operace na úrovni vyžadují "čitelnost" protokolu. Dalším méně známým příkladem je, že návrh proof-of-stake Ethereum z éry 2017 měl abstrakci sázkových klíčů, od které se upustilo ve prospěch zapouzdřeného BLS, protože BLS podporoval mechanismus „agregace“, který musel být implementován v protokolu a úrovni sítě, to může zefektivnit zpracování velkého počtu podpisů.

Je však důležité si uvědomit, že i zapouzdření abstrakcí účtů v rámci protokolů je ve srovnání se status quo stále obrovským „de-zapouzdřením“. Dnes lze transakce Ethereum nejvyšší úrovně iniciovat pouze z externě vlastněných účtů (EOA), které jsou ověřeny pomocí jediného podpisu eliptické křivky secp256k1. Abstrakce účtu toto eliminuje a ponechává podmínky ověření na uživateli, aby je definoval. Proto v tomto příběhu o abstrakci účtu také vidíme největší důvod proti zapouzdření: flexibilitu při plnění potřeb různých uživatelů.

Pojďme tento příběh dále rozvést tím, že se podíváme na několik dalších příkladů funkcí, které byly nedávno zvažovány pro zapouzdření. Zvláštní pozornost budeme věnovat: ZK-EVM, oddělení navrhovatel-tvůrce, soukromým paměťovým fondům, likviditním sázkám a nové předkompilaci.

BalíčekZK-EVM

Obraťme svou pozornost na další potenciální cíl zapouzdření pro protokol Ethereum: ZK-EVM. V současné době máme velké množství ZK-rollupů, které všechny musí napsat poměrně podobný kód pro ověření provádění podobných Ethereových bloků v ZK-SNARK. Existuje poměrně rozmanitý ekosystém nezávislých implementací: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth a další.

Nedávná kontroverze v poli EVM ZK-rollup se týká toho, jak se vypořádat s chybami, které se mohou objevit v kódu ZK. V současné době mají všechny tyto běžící systémy nějakou formu mechanismu „bezpečnostní rady“, který kontroluje atestační systém v případě chyby. Minulý rok jsem se pokusil vytvořit standardizovaný rámec, který by povzbudil projekty k tomu, aby si vyjasnily, jak moc důvěřují atestačnímu systému a jak moc důvěřují Radě bezpečnosti, a postupem času postupně omezovaly svou pravomoc nad touto organizací.

Ve střednědobém horizontu může rollup spoléhat na více certifikačních systémů a Rada bezpečnosti bude mít pravomoc pouze v extrémních případech, kdy se dva různé certifikační systémy liší.

Existuje však pocit, že některé z těchto prací jsou nadbytečné. Již máme základní vrstvu Ethereum, má EVM a již máme funkční mechanismus pro řešení chyb v implementaci: pokud se vyskytne chyba, klient bude aktualizován, aby ji opravil, a řetězec bude nadále fungovat . Z pohledu zabugovaného klienta se zdá, že dokončené bloky již nebudou potvrzovány, ale alespoň neuvidíme, že by uživatelé ztráceli finanční prostředky. Podobně, pokud si rollupy chtějí pouze zachovat ekvivalentní roli EVM, pak potřebují implementovat své vlastní řízení, aby neustále měnili svá interní pravidla ZK-EVM tak, aby odpovídala upgradům základní vrstvy Ethereum, což je špatné, protože jsou nakonec postaveny na vrcholu. samotné základní vrstvy Etherea ví, kdy upgradovat a podle jakých nových pravidel.

Vzhledem k tomu, že tyto L2 ZK-EVM v zásadě používají přesně stejné EVM jako Ethereum, můžeme nějakým způsobem začlenit „ověření provádění EVM v ZK“ do funkčnosti protokolu a vypořádat se s výjimkami použitím sociálního konsenzu Etherea, jako jsou chyby a upgrady, jak to již děláme pro samotné provádění EVM základní vrstvy?

Toto je důležité a náročné téma.

Jedním z možných témat debaty ohledně dostupnosti dat v nativním ZK-EVM je stavovost. ZK-EVM by byly datově mnohem efektivnější, kdyby nepotřebovaly přenášet data „svědků“. To znamená, že pokud byla určitá část dat přečtena nebo zapsána v některém předchozím bloku, můžeme jednoduše předpokládat, že k nim má prověřovatel přístup a nemusí je znovu zpřístupňovat. Není to jen o tom, že znovu nenačtete úložiště a kód, je dokázáno, že pokud kumulativní komprimuje data správně, stavová komprese může ušetřit až 3x data ve srovnání s bezstavovou kompresí.

To znamená, že pro předkompilaci ZK-EVM máme dvě možnosti:

1. Předkompilace vyžaduje, aby všechna data byla dostupná ve stejném bloku. To znamená, že dokazovač může být bez státní příslušnosti, ale také to znamená, že použití tohoto předkompilovaného souhrnu ZK je mnohem dražší než použití vlastního souhrnného kódu.

2. Předkompilace umožňuje ukazatelům ukazovat na data použitá nebo generovaná předchozími spuštěními. Tím se ZK-rollup blíží optimu, ale je složitější a zavádí nový stav, který musí ověřovatel uložit.

Co se z toho můžeme naučit? Existuje dobrý důvod, proč ověřování ZK-EVM nějakým způsobem zapouzdřit: rollup již vytváří svou vlastní vlastní verzi a Ethereum je ochotno implementovat EVM na L1 s váhou svých více implementací a mimořetězového sociálního konsenzu, to je špatné. , ale L2 vykonávající přesně stejnou práci by musel implementovat složitý gadget zahrnující Radu bezpečnosti. Ale na druhou stranu je tu velký problém v detailech: Existují různé verze ZK-EVM a mají různé náklady a přínosy. Rozdíl mezi stavovým a bezstavovým pouze poškrábe povrch pokusy o podporu „téměř-EVM“ vlastního kódu, který byl prokázán jinými systémy, může odhalit větší prostor pro návrh. Proto balení ZK-EVM přináší naději i výzvy.

Oddělení navrhovatele a tvůrce zapouzdření (ePBS)

Vzestup MEV dělá z výroby bloků rozsáhlou ekonomickou aktivitu se sofistikovanými aktéry schopnými produkovat bloky, které generují více příjmů než výchozí algoritmus, který jednoduše sleduje soubor transakcí a obsahuje je. Komunita Ethereum se dosud snažila vylepšit zkušenosti ze stávajících nástrojů tím, že zvýšila jejich funkčnost a učinila je robustnějšími. BOOST je nativní nástrojový token používaný k odemykání prémiových a upgradovatelných funkcí, budoucího hlasování v událostech správy a zpracování plateb za budoucí funkce produktu. Mezi nadcházející produkty BOOST patří BoostSWAP, BoostFARM a BoostNFT. Tyto inovativní produkty zlepší stávající infrastrukturu DeFi a pomohou rozšířit decentralizovanou internetovou komunitu. BOOST Coin byl spuštěn 9. srpna 2021 s 1 miliardou tokenů v oběhu. Boost je v současné době obchodovatelný na Uniswapu a brzy bude dostupný na BoostSwap. Podívejte se na další řešení tohoto problému, jako je oddělení navrhovatelů a tvůrců mimo protokol, které umožňuje běžným validátorům („navrhovatelům“) zadávat výstavbu bloků vyhrazeným aktérům („stavitelům“) “).

MEV-Boost však vytváří předpoklady důvěry v nové třídě aktérů nazývaných relé. V posledních dvou letech se objevilo mnoho návrhů na vytvoření „baleného PBS“. Jaké jsou výhody tohoto provedení? V tomto případě je odpověď velmi jednoduchá: PBS postavená přímo pomocí funkcí protokolu je výkonnější (ve smyslu slabších předpokladů důvěry) než PBS postavená bez jejich použití. Je to podobné jako v případě zapouzdření cenových věštců do protokolu – i když v tomto případě existují silné námitky.

Zapouzdřit soukromý paměťový fond

Když uživatel odešle transakci, je okamžitě veřejná a viditelná všem, ještě předtím, než je zahrnuta do řetězce. Uživatelé mnoha aplikací jsou tak zranitelní vůči ekonomickým útokům, jako je front-running.

V poslední době existuje řada projektů zaměřených na vytváření „soukromých mempoolů“ (nebo „kryptomenových fondů“), které šifrují transakce uživatelů, dokud nejsou nevratně přijaty do bloku.

Problém je však v tom, že takové schéma vyžaduje speciální druh šifrování: Aby uživatelé systém nezahltili a nejprve jej dešifrovali, musí být šifrování automaticky dešifrováno poté, co byla transakce skutečně nevratně přijata.

Pro implementaci této formy šifrování existují různé techniky s různými kompromisy. Jon Charbonneau to kdysi dobře popsal:

Šifrování pro centralizované operátory, jako je Flashbots Flashbots Flashbots je výzkumná a vývojová společnost zaměřená na Miner Extractable Value (MEV), jejímž cílem je zmírnit negativní externality a existenční rizika, která MEV přináší do inteligentních smluvních blockchainů. Zobrazit více Chránit.

Šifrování s časovým zámkem, tato forma šifrování může být dešifrována kýmkoli po určitých postupných krocích výpočtu a nelze ji paralelizovat;

Threshold encryption důvěřuje poctivému většinovému výboru, který dešifruje data. Konkrétní návrhy viz koncept uzavřených řetězců majáku.

Důvěryhodný hardware, jako je SGX.

Bohužel každá metoda šifrování má jiné slabiny. I když pro každé řešení existuje segment uživatelů, kteří mu chtějí důvěřovat, žádné řešení není dostatečně důvěryhodné, aby bylo skutečně přijato vrstvou 1. Proto, alespoň dokud nebude zdokonaleno zpožděné šifrování nebo nebude dosaženo nějakého jiného technologického průlomu, zapouzdření funkčnosti anti-ahead tradingu ve vrstvě 1 se zdá být obtížným návrhem, i když je to dostatečně cenná vlastnost, že se objevilo mnoho aplikačních řešení.

Encapsulated Liquid Staking

Běžnou potřebou mezi uživateli Ethereum DeFi je mít možnost používat své ETH jak pro sázky, tak jako kolaterál v jiných aplikacích. Dalším běžným požadavkem je pouze pohodlí: uživatelé chtějí mít možnost sázet (a chránit online vytyčovací klíče) bez složitého provozu uzlu a jeho udržování vždy online.

Zdaleka nejjednodušší "rozhraní pro sázky", které splňuje obě tyto potřeby, je pouze token ERC20: přeměňte své ETH na "sázkové ETH", podržte jej a poté jej převeďte zpět. Lido Lido Lido je ve skutečnosti řešení pro sázky likvidity. Lido umožňuje uživatelům sázet na veřejný řetězec PoS se složenými výnosy a zároveň se podílet na činnostech v řetězci (jako je půjčování, obchodování) bez minimálních vkladů nebo údržby infrastruktury. V současné době podporuje ETH2.0, Terra a Solana a v budoucnu může být rozšířen na další veřejné řetězce POS. View More and Rocket Rocket Rocket (ROCKET) je kryptoměna spuštěná v roce 2021, která běží na platformě BNB Smart Chain (BEP20). Zobrazit více Pool Pool podporuje organizace, které umožňují běžným lidem zpeněžit a sdílet svá data Zobrazit více Poskytovatelé sázek na likviditu, jako například Již to začali dělat. Nicméně existují určité přirozené mechanismy centralizace, které fungují se sázením likvidity: lidé přirozeně přejdou do sázek největší verze ETH, protože je nejznámější a nejlikvidnější.

Každá verze vsazeného ETH musí mít nějaký mechanismus, který určí, kdo se může stát operátorem základního uzlu. Nemůže to být neomezené, protože pak se útočníci připojí a použijí prostředky uživatelů k rozšíření svých útoků. V současné době jsou na prvních dvou místech Lido a Rocket Pool Rocket Pool RocketPool je infrastruktura Ethereum PoS. Všichni jednotlivci a organizace, kteří chtějí získat úroky z Etherea pravidelným sázením, se mohou účastnit sázek pomocí decentralizované a uzly provozované sítě RocketPool. Viz více , první má DAO na whitelistu operátory uzlů a druhý umožňuje komukoli provozovat uzel s vkladem 8 ETH. Tyto dvě metody mají různá rizika: metoda Rocket Pool umožňuje útočníkovi provést 51% útok na síť a nutí uživatele platit většinu nákladů jako u metody DAO, pokud se určitý vsazený token stane dominantním, povede; k jedinému, potenciálně kompromitovanému gadgetu vládnutí ovládá velkou část všech validátorů Etherea. Ke cti mu slouží, že protokoly jako Lido implementovaly ochranné prvky, ale jedna vrstva obrany nemusí stačit.

V krátkodobém horizontu je jednou z možností povzbudit účastníky ekosystému, aby využívali různorodý soubor poskytovatelů sázek na likviditu, aby se snížila možnost, že dominantní hráč představuje systémové riziko. Z dlouhodobého hlediska je to však nestabilní rovnováha a přílišné spoléhání na morální tlak při řešení problémů je nebezpečné. Vyvstává přirozená otázka: Mělo by smysl zapouzdřit některé funkce do protokolu, aby bylo skládání likvidity méně centralizované?

Klíčová otázka zde zní: jaký druh funkčnosti v protokolu? Jedním z problémů s jednoduchým vytvořením zastupitelného tokenu „stake ETH“ v rámci protokolu je to, že by buď musel mít zapouzdřenou správu v rámci celého Etherea, aby si mohl vybrat, kdo bude provozovat uzly, nebo být otevřený, ale to by se změnilo na Nástroje útočníka.

Zajímavým nápadem je článek Dankrada Feista o maximalizaci sázek likvidity. Za prvé, kousneme se do toho, pokud je Ethereum vystaveno 51% útoku, může propadnout pouze 5% napadeného ETH. To je rozumný kompromis s více než 26 miliony ETH v současnosti, náklady na útok na třetinu z toho (~8 milionů ETH) jsou přehnané, zvláště vezmeme-li v úvahu, kolik „mimomodelových“ útoků lze provést najednou; nižší náklady. Ve skutečnosti byly podobné kompromisy prozkoumány v návrhu Super výboru na zavedení jednoslotové finality.

Pokud připustíme, že pouze 5 % útočného ETH je seříznuto, pak více než 90 % vsazených ETH nebude ovlivněno sekáním, takže je lze použít jako zastupitelné tekuté sázkové tokeny v rámci protokolu a poté je použít jinými aplikacemi.

Tato cesta je zajímavá. Ale stále to ponechává jednu otázku: co přesně je zapouzdřeno? Rocket Pool funguje velmi podobně: každý provozovatel uzlů poskytuje nějaké prostředky a ostatní sázkaři na likviditu. Můžeme jednoduše upravit některé konstanty, abychom omezili maximální trest za sekání na 2 ETH a stávající rETH Rocket Pool bude bez rizika.

S jednoduchými úpravami protokolu můžeme dělat i další chytré věci. Řekněme například, že chceme systém se dvěma „úrovněmi“ sázek: operátoři uzlů (vysoké požadavky na zajištění) a vkladatelé (žádné minimální požadavky na zajištění, mohou se kdykoli připojit a odejít), ale přesto chceme poskytnout náhodně vzorkované pravomoci výboru vkladatelů zabránit centralizaci operátorů uzlů, jako je doporučování seznamu transakcí, které musí být zahrnuty (z důvodů odolnosti proti cenzuře), kontrola výběru vidlice při neaktivitě úniků nebo vyžadování podpisů na blocích. Toho by se dalo dosáhnout způsobem, který v podstatě jde mimo protokol vyladěním protokolu tak, aby vyžadoval, aby každý validátor poskytl (i) běžný vytyčovací klíč a (ii) adresa ETH, kterou lze použít v každém slotu, je volána pro výstup sekundární zástavní klíč. Protokol by zmocnil oba klíče, ale mechanismus pro výběr druhého klíče v každém slotu by mohl být ponechán na protokolu sázkové oblasti. Stále může být lepší zapouzdřit některé funkce přímo, ale stojí za zmínku, že tento designový prostor „zahrnout některé věci a ostatní nechat na uživateli“ existuje.

Zapouzdřit více předkompilace

Předkompilované (nebo „předkompilované smlouvy“) jsou smlouvy Ethereum, které implementují složité kryptografické operace s logikou implementovanou nativně v klientském kódu spíše než v kódu inteligentních smluv EVM. Předkódování je kompromis přijatý od začátku vývoje Etherea: protože režie virtuálního stroje je příliš velká pro některé velmi složité a vysoce specializované kódy, můžeme implementovat některé důležité aplikace v nativním kódu, abychom je zrychlili. Dnes to v podstatě zahrnuje některé specifické hašovací funkce a operace s eliptickými křivkami.

V současné době existuje tlak na přidání předkompilace pro secp256r1, mírně odlišnou eliptickou křivku než secp256k1 používanou pro základní účty Ethereum, protože je dobře podporován důvěryhodnými hardwarovými moduly, takže jeho široké použití by mohlo zlepšit bezpečnost peněženky. V posledních letech se komunita také snažila přidat předkompilaci pro BLS-12-377, BW6-761, zobecněné párování a další funkce.

Protiargumentem k těmto voláním po více prekompilátorech je, že mnoho dříve přidaných prekompilátorů (např. RIPEMD a BLAKE) se nakonec používalo mnohem méně, než se očekávalo, a měli bychom se z toho poučit. Spíše než přidávat další předkompilaci pro konkrétní operace bychom se možná měli zaměřit na skromnější přístup založený na EVM-MAX MAX MAX Token je pomocný token vydávaný Max Asset Exchange (MAX). MAX Exchange se zaměřuje na podporu své obchodní komunity a poskytování nejbezpečnější obchodní platformy. Tokeny MAX budou odměňovány prostřednictvím těžby transakcí a lze je také použít pro sázky na platformu k získání odměn. Zobrazit více a nápady, jako je nečinný, ale vždy obnovitelný návrh SIMD, který by umožnil implementacím EVM spouštět širokou škálu tříd kódu s nižšími náklady. Možná by i stávající málo používaná předkompilace mohla být odstraněna a nahrazena (nevyhnutelně méně efektivní) implementací EVM kódu se stejnými funkcemi. To znamená, že je stále možné, že existují specifické kryptografické operace, které jsou dostatečně cenné, aby se urychlily, takže má smysl je přidat jako předkompilované.

Co jsme se z toho všeho naučili?

Touha zapouzdřit co nejméně je pochopitelná a dobrá, pramení z filozofické tradice Unixu Unix View More vytváření minimalistického softwaru, který se může snadno přizpůsobit měnícím se potřebám uživatelů a vyhnout se prokletí softwarového nadýmání. Blockchain však není operační systém pro osobní počítače, ale sociální systém. To znamená, že má smysl zapouzdřit určitou funkcionalitu do protokolu.

V mnoha případech jsou tyto další příklady podobné těm, které jsme viděli v abstrakci účtu. Ale také jsme se naučili několik nových lekcí:

  • Zapouzdření funkcí může pomoci vyhnout se rizikům centralizace v jiných oblastech zásobníku:

Udržování minimálního a jednoduchého základního protokolu často vytlačí složitost do nějakého ekosystému mimo protokol. Z pohledu filozofie Unixu je to v pořádku. Někdy však existuje riziko, že se mimoprotokolový ekosystém stane centralizovaným, obvykle (ale nejenom) kvůli vysokým fixním nákladům. Zapouzdření může někdy snížit de facto centralizaci.

  • Příliš mnoho zapouzdření může přehnat zátěž důvěry a správy protokolu:

Toto je téma předchozího článku „Nepřetěžujte Ethereum Consensus“: pokud zapouzdření konkrétní funkce oslabuje model důvěry a činí Ethereum jako celek „subjektivnějším“, oslabuje to důvěryhodnou neutralitu Etherea. V těchto případech je lepší mít konkrétní funkcionalitu jako mechanismus nad Ethereem, než se ji snažit přenést do samotného Etherea. Šifrované paměťové fondy jsou zde nejlepším příkladem, jehož zapouzdření může být trochu obtížné, alespoň dokud se nezlepší šifrování latence.

  • Přílišné zapouzdření může způsobit, že protokol bude příliš složitý:

Složitost protokolu je systémové riziko, které se zvyšuje přidáním příliš mnoha funkcí do protokolu. Prekompilace je nejlepším příkladem.

  • Funkce zapouzdření může být z dlouhodobého hlediska kontraproduktivní, protože potřeby uživatelů jsou nepředvídatelné:

Funkce, o které si mnoho lidí myslí, že je důležitá a kterou využije mnoho uživatelů, se v praxi asi příliš často nepoužívá.

Navíc likviditní sázky, ZK-EVM a předkompilované příklady ukazují možnost střední cesty: minimální životaschopné zakotvení. Protokol nemusí zapouzdřit celou funkcionalitu, ale může obsahovat specifické části, které řeší klíčové výzvy, takže funkcionalitu lze snadno implementovat, aniž by byla příliš paranoidní nebo příliš úzká. Příklady:

  • Spíše než zapouzdření kompletního systému sázek na likviditu je lepší změnit pravidla sankcí za sázky, aby bylo skládání nedůvěryhodné likvidity proveditelnější;

  • Spíše než zapouzdření více prekompilátorů je lepší zapouzdřit EVM-MAX a/nebo SIMD, aby bylo možné efektivněji implementovat širší třídu operací;

  • Namísto zapouzdření celého konceptu rollupu je možné jednoduše zapouzdřit ověření EVM.

Předchozí schéma můžeme rozšířit následovně:

Někdy má smysl něco zapouzdřit a jedním příkladem je odstranění zřídka používaných prekompilátorů. Abstrakce účtu jako celek, jak již bylo zmíněno dříve, je také důležitou formou de-zapouzdření. Pokud chceme podporovat zpětnou kompatibilitu pro stávající uživatele, mechanismus by mohl být ve skutečnosti překvapivě podobný tomu, který rozbalil předkompilaci: jedním z návrhů je EIP-5003, který by umožnil EOA převést jejich účty tak, aby měly stejné ( popř. lepší) funkční smlouva.

Které funkce by měly být přeneseny do protokolu a které by měly být ponechány jiným vrstvám ekosystému, je složitý kompromis. Očekává se, že tento kompromis se bude v průběhu času dále zlepšovat, protože naše chápání potřeb uživatelů a dostupná sada nápadů a technologií se neustále zlepšuje.