Původní název: Glue and coprocessor architectures

Autor: Vitalik, zakladatel Etherea Překladač: Deng Tong, Golden Finance

Zvláštní poděkování patří Justinu Drakeovi, Georgiosu Konstantopoulosovi, Andreji Karpathymu, Michaelu Gao, Tarun Chitra a různým přispěvatelům Flashbots za jejich zpětnou vazbu a komentáře.

Pokud podrobně analyzujete jakýkoli výpočet náročný na zdroje probíhající v moderním světě, jednou z vlastností, kterou budete znovu a znovu objevovat, je to, že výpočet lze rozdělit na dvě části:

  • Relativně malé množství složité, ale ne výpočetně náročné „obchodní logiky“;

  • Mnoho intenzivní, ale vysoce strukturované „drahé práce“.

Tyto dvě formy výpočetní techniky se nejlépe ovládají různými způsoby: první, jejíž architektura může být méně efektivní, ale musí být velmi obecná, druhá, jejíž architektura může být méně obecná, ale musí být velmi efektivní.

Jaké jsou příklady tohoto odlišného přístupu v praxi?

Nejprve se podívejme na prostředí, které znám nejvíce: Ethereum Virtual Machine (EVM). Zde je stopa ladění geth nedávné transakce Ethereum, kterou jsem provedl: Aktualizace hash IPFS mého blogu na ENS. Tato transakce spotřebovala celkem 46924 plynu a lze ji klasifikovat takto:

  • Základní cena: 21 000

  • Údaje o hovoru: 1 556

  • Provedení EVM: 24 368

  • Operační kód SLOAD: 6 400

  • Operační kód SSTORE: 10 100

  • Operační kód LOG: 2 149

  • Ostatní: 6 719

JaES4D3UNAAlSuVhxkNkxqkNuopjvB5MPpwGUbYe.jpeg

EVM trace aktualizací ENS hash. Předposlední sloupec je spotřeba plynu.

Morálka příběhu je: většina provádění (asi 73 %, pokud se podíváte pouze na EVM, asi 85 %, pokud zahrnete základní nákladovou část, která pokrývá výpočty) je soustředěna ve velmi malém počtu strukturovaných nákladných operací: úložiště čte a zapisuje, protokoluje a šifruje (základní cena zahrnuje 3000 za ověření podpisu platby, EVM také zahrnuje 272 za hashování platby). Zbytek provádění je „obchodní logika“: prohození bitů dat volání pro extrakci ID záznamu, který se snažím nastavit, a hash, na který jej nastavuji atd. V tokenovém přenosu by to zahrnovalo přidávání a odečítání zůstatků, v pokročilejších aplikacích by to mohlo zahrnovat rotace atd.

V EVM jsou tyto dvě formy provedení řešeny odlišně. Obchodní logika na vysoké úrovni je napsána v jazyce vyšší úrovně, obvykle Solidity, který se zkompiluje do EVM. Nákladnou práci stále spouštějí operační kódy EVM (SLOAD atd.), ale více než 99 % skutečných výpočtů se provádí ve vyhrazených modulech napsaných přímo v kódu klienta (nebo dokonce v knihovnách).

Abychom tomuto vzoru lépe porozuměli, pojďme ho prozkoumat v jiném kontextu: AI kód ​​napsaný v pythonu pomocí pochodně.

pLGF8omDmigyKSG9Holtr0YEeXlqkEiqjW833sdP.jpeg

Dopředný průchod bloku modelu transformátoru

co tady vidíme? Viděli jsme relativně malé množství „obchodní logiky“ napsané v Pythonu, která popisuje strukturu prováděných operací. Ve skutečné aplikaci bude existovat jiný typ obchodní logiky, který určuje podrobnosti, jako je způsob získání vstupu a co dělat s výstupem. Pokud však pronikneme do každé jednotlivé operace samotné (jednotlivé kroky uvnitř self.norm, torch.cat, +, *, self.attn...), uvidíme vektorizované výpočty: stejné operace jsou počítány masivně paralelně. . Podobně jako v prvním příkladu se malá část výpočtů používá pro obchodní logiku a většina výpočtů se používá k provádění velkých strukturovaných maticových a vektorových operací - ve skutečnosti je většina z nich pouze násobení matic.

Stejně jako v příkladu EVM jsou tyto dva typy práce řešeny dvěma různými způsoby. Kód obchodní logiky na vysoké úrovni je napsán v Pythonu, což je vysoce univerzální a flexibilní jazyk, ale také velmi pomalý, a my jednoduše akceptujeme neefektivitu, protože zahrnuje pouze malý zlomek celkových nákladů na výpočetní techniku. Mezitím jsou intenzivní operace psány ve vysoce optimalizovaném kódu, často CUDA kódu, který běží na GPU. Stále častěji dokonce začínáme vidět LLM odvození prováděné na ASIC.

Moderní programovatelná kryptografie, jako je SNARK, se opět řídí podobným vzorem na dvou úrovních. Za prvé, prover může být napsán v jazyce na vysoké úrovni, kde se těžké zvedání provádí pomocí vektorizovaných operací, jako v příkladu AI výše. Kruhový STARK kód, který zde mám, to dokazuje. Za druhé, samotné programy spouštěné v kryptografii lze psát způsobem, který rozděluje obecnou obchodní logiku a vysoce strukturovanou nákladnou práci.

Abychom pochopili, jak to funguje, můžeme se podívat na jeden z nejnovějších trendů, které předvádí STARK. Aby byly všestranné a snadno použitelné, týmy stále více staví STARK provery pro široce používané minimální virtuální stroje, jako je RISC-V. Jakýkoli program, jehož provedení je třeba dokázat, lze zkompilovat do RISC-V a dokazovač pak může prokázat provedení tohoto kódu RISC-V.

AugPMolB2AGUDGPrqj7hJFwSEO1nzB8CVvPhFXwq.jpeg

Diagram z dokumentace RiscZero

To je velmi výhodné: to znamená, že stačí napsat logiku důkazu jednou a od té doby může být jakýkoli program, který potřebuje důkaz, napsán v jakémkoli "tradičním" programovacím jazyce (např. RiskZero podporuje Rust). Je tu však problém: tento přístup vyžaduje spoustu režií. Programovatelné šifrování je již neúnosně drahé přidání režie spouštění kódu v interpretu RISC-V je příliš mnoho. Vývojáři tedy přišli s trikem: identifikovat konkrétní drahé operace, které tvoří většinu výpočtu (obvykle hash a signatury), a poté vytvořit specializované moduly, které tyto operace velmi efektivně prokážou. Pak už jen zkombinujete neefektivní, ale obecný nátiskový systém RISC-V s účinným, ale specializovaným nátiskovým systémem a získáte to nejlepší z obou světů.

Programovatelné šifrování jiné než ZK-SNARK, jako je multi-party computing (MPC) a plně homomorfní šifrování (FHE), může být optimalizováno pomocí podobných metod.

Celkově vzato, jaký je tento fenomén?

Moderní výpočetní technika se stále více řídí tím, co nazývám architekturami lepidla a koprocesoru: máte nějakou centrální „lepící“ komponentu, která je vysoce univerzální, ale neefektivní, zodpovědná za spouštění úloh mezi jednou nebo více komponentami koprocesoru Tyto komponenty koprocesoru mají nízkou obecnost, ale vysokou účinnost přenosu data mezi nimi.

abhGUxtZnxYpz5SurIDkzwKHbrWsETbobFSspMFw.jpeg

Jde o zjednodušení: v praxi má křivka kompromisu mezi účinností a všestranností téměř vždy více než dvě úrovně. GPU a další čipy, často označované v průmyslu jako „koprocesory“, jsou méně všestranné než CPU, ale všestrannější než ASIC. Kompromis specializace je složitý a závisí na předpovědích a intuici o tom, které části algoritmu zůstanou stejné za pět let a které části se změní za šest měsíců. V architektuře ZK proof často vidíme podobné vícevrstvé specializace. Ale pro široké mentální modely stačí uvažovat o dvou úrovních. Podobné situace existují v mnoha oblastech výpočetní techniky:

HcKioeJGDdAT3f9IGBEstGubJoZSMnmddZoSxEYk.jpeg

Z výše uvedených příkladů se jistě jeví jako přirozený zákon, že výpočty lze takto rozdělit. Ve skutečnosti můžete najít příklady specializace na výpočetní techniku ​​v rozsahu desetiletí. Domnívám se však, že toto oddělení se zvyšuje. Myslím, že to má svůj důvod:

Na limity vylepšení taktu CPU jsme dosáhli teprve nedávno, takže dalších zisků lze dosáhnout pouze paralelizací. O paralelizaci je však obtížné uvažovat, takže pro vývojáře je často praktičtější pokračovat v uvažování postupně a nechat paralelizaci probíhat na backendu, zabaleném do specializovaných modulů vytvořených pro konkrétní operace.

Výpočetní rychlost se teprve nedávno stala tak vysokou, že výpočetní náklady na obchodní logiku se staly skutečně zanedbatelnými. V tomto světě má také smysl optimalizovat virtuální počítače, na kterých běží obchodní logika, k dosažení jiných cílů, než je výpočetní efektivita: přívětivost pro vývojáře, znalost, bezpečnost a další podobné cíle. Mezitím mohou být vyhrazené „koprocesorové“ moduly i nadále navrhovány s ohledem na efektivitu a odvozovat svou bezpečnost a přívětivost pro vývojáře z jejich relativně jednoduchého „rozhraní“ s lepidlem.

Stále více se ukazuje, jaké jsou nejdůležitější nákladné operace. Nejzřetelnější je to v kryptografii, kde se s největší pravděpodobností používají určité typy drahých operací: modulové operace, lineární kombinace eliptických křivek (alias multiskalární násobení), rychlé Fourierovy transformace a tak dále. To se také stále více projevuje v umělé inteligenci, kde po více než dvě desetiletí byla většina výpočtů „primárně maticovým násobením“ (i když s různou úrovní přesnosti). Podobné trendy se objevují i ​​v jiných oblastech. V (výpočetně náročných) výpočtech je mnohem méně neznámých neznámých než před 20 lety.

co to znamená

Klíčovým bodem je, že lepiče by měly být optimalizovány tak, aby byly dobrými lepiči, a koprocesory by měly být optimalizovány tak, aby byly dobrými koprocesory. Důsledky toho můžeme prozkoumat v několika klíčových oblastech.

EVM

Blockchainový virtuální stroj (např. EVM) nemusí být efektivní, stačí, aby byl známý. Pouhým přidáním správných koprocesorů (aka „předkompilace“) mohou být výpočty v neefektivním VM ve skutečnosti stejně efektivní jako výpočty v nativně efektivním VM. Například režijní náklady spojené s 256bitovými registry EVM jsou relativně malé, zatímco výhody známosti EVM a stávajícího vývojářského ekosystému jsou značné a dlouhodobé. Vývojové týmy optimalizující EVM dokonce zjistily, že nedostatek paralelizace často není hlavní překážkou škálovatelnosti.

Nejlepším způsobem, jak zlepšit EVM, může být pouze (i) přidání lepších předkompilovaných nebo specializovaných operačních kódů, například nějaká kombinace EVM-MAX a SIMD by mohla být rozumná, a (ii) zlepšení rozložení paměti, například stromů Verkle Změna , jako vedlejší efekt výrazně snižuje náklady na přístup k úložným slotům, které spolu sousedí.

H4kLdEP1RkmcZdXMTO4gmlj9eeT702lD1QmrTAwB.jpeg

Optimalizace úložiště v návrhu stromu Ethereum Verkle, umístění sousedních klíčů úložiště k sobě a přizpůsobení ceny plynu tak, aby to odráželo. Optimalizace, jako je tato, spolu s lepší předkompilací mohou být důležitější než vyladění samotného EVM.

Bezpečný výpočetní a otevřený hardware

Jednou z výzev při zlepšování bezpečnosti v moderních počítačích na hardwarové úrovni je její příliš složitá a proprietární povaha: čipy jsou navrženy tak, aby byly efektivní, což vyžaduje vlastní optimalizaci. Zadní vrátka lze snadno skrýt a zranitelnost postranních kanálů se neustále objevuje.

Úsilí nadále prosazuje otevřenější a bezpečnější alternativy z různých úhlů. Některé výpočty se stále více provádějí v důvěryhodných spouštěcích prostředích, včetně telefonů uživatelů, což zlepšilo zabezpečení uživatelů. Snaha o více open source spotřebitelského hardwaru pokračuje, s některými nedávnými výhrami, jako jsou notebooky RISC-V s Ubuntu.

oJ7THWtWl9L3a5Z10FqgQ065AzAGSBaBhWHRf04K.jpeg

Notebook RISC-V s Debianem

Otázkou však zůstává efektivita. Autor výše odkazovaného článku píše:

Novější návrhy čipů s otevřeným zdrojovým kódem, jako je RISC-V, pravděpodobně nebudou konkurovat procesorové technologii, která již existuje a byla zdokonalována po celá desetiletí. Pokrok má vždy výchozí bod.

Paranoidnější nápady, jako je tento návrh sestavení počítače RISC-V na FPGA, čelí větší režii. Ale co když lepení a architektura koprocesoru znamenají, že na této režii ve skutečnosti nezáleží? Pokud připustíme, že otevřené a zabezpečené čipy budou pomalejší než proprietární, dokonce i opuštění běžných optimalizací, jako je spekulativní provádění a predikce větví, pokud je to nutné, ale pokusíme se to kompenzovat přidáním (v případě potřeby proprietárními) moduly ASIC, které se používají ve většině Intensive konkrétní typy výpočtů, co s tím? Citlivé výpočty lze provádět v „hlavním čipu“, který bude optimalizován pro zabezpečení, open source design a odolnost postranních kanálů. Intenzivnější výpočty (např. ZK proofs, AI) budou prováděny v modulech ASIC, které budou znát méně informací o prováděných výpočtech (možná prostřednictvím kryptografického zaslepení v některých případech dokonce nulové informace).

kryptografie

Dalším klíčovým bodem je, že toto vše je velmi optimistické, pokud jde o kryptografii, zejména programovatelnou kryptografii, která se stává mainstreamem. Viděli jsme některé hyperoptimalizované implementace určitých vysoce strukturovaných výpočtů v SNARK, MPC a dalších nastaveních: některé hashovací funkce jsou jen několik setkrát dražší než přímé spuštění výpočtu a umělá inteligence (především násobení matic) Režie je také velmi nízká. Další vylepšení, jako je GKR, mohou tuto úroveň dále snížit. Plně generické provádění virtuálního počítače, zejména pokud je prováděno v interpretu RISC-V, může i nadále vyžadovat přibližně deset tisíckrát vyšší režii, ale z důvodů popsaných v tomto článku na tom nezáleží: pokud se používají účinné specializované techniky, resp. Díky manipulaci s výpočetně nejnáročnějšími součástmi jsou celkové náklady kontrolovatelné.

hTatkTj6wZCWRGAgr4NNmcxFZkkuGq7oW1PT3U2P.jpeg

Zjednodušený diagram MPC věnovaný násobení matic, největší komponentě v odvození modelu AI. V tomto článku najdete další podrobnosti, včetně toho, jak zachovat soukromý model a vstupy.

Výjimkou z myšlenky, že „vrstvy lepidla musí být pouze známé, ne efektivní“ je latence a v menší míře i šířka datového pásma. Pokud výpočet zahrnuje mnohonásobné náročné operace se stejnými daty (jako v kryptografii a umělé inteligenci), pak jakákoli zpoždění způsobená neefektivními vrstvami lepidla se mohou stát hlavním úzkým hrdlem za běhu. Proto mají lepicí kurzy také požadavky na účinnost, i když tyto požadavky jsou specifičtější.

na závěr

Celkově si myslím, že výše uvedené trendy jsou velmi pozitivním vývojem z mnoha úhlů pohledu. Zaprvé, je to logický způsob, jak maximalizovat výpočetní efektivitu a zároveň zůstat přívětivý pro vývojáře, a možnost získat více obojího je dobré pro každého. Zejména zlepšuje naši schopnost spouštět citlivé a na výkon náročné výpočty (např. ZK proofs, LLM inference) lokálně na hardwaru uživatele tím, že umožňuje specializaci na straně klienta pro vyšší efektivitu. Za druhé, vytváří obrovské okno příležitostí, jak zajistit, aby snaha o efektivitu neohrozila ostatní hodnoty, zejména bezpečnost, otevřenost a jednoduchost: zabezpečení postranních kanálů a otevřenost v počítačovém hardwaru, snížená složitost obvodů v ZK-SNARK a snížení složitost virtuálních strojů. Historicky snaha o efektivitu způsobila, že tyto další faktory ustoupily do pozadí. S architekturou lepidla a koprocesoru už to není potřeba. Jedna část stroje optimalizuje efektivitu, další část optimalizuje všestrannost a další hodnoty a obě spolupracují.

Tento trend je také velmi dobrý pro kryptografii, která je sama o sobě ukázkovým příkladem „drahého strukturovaného počítání“ a tento trend tento trend urychluje. To přináší další příležitost ke zlepšení zabezpečení. Zlepšené zabezpečení je možné i ve světě blockchainu: můžeme se méně starat o optimalizaci virtuálního stroje a více se soustředit na optimalizaci předkompilace a dalších funkcí, které s virtuálním strojem koexistují.

Za třetí, tento trend poskytuje příležitosti k účasti pro menší, novější hráče. Pokud se výpočetní technika stane méně monolitickou a modulárnější, výrazně se tím sníží překážka vstupu. Dokonce i použití ASIC pro jeden typ výpočetní techniky může potenciálně znamenat rozdíl. To platí i v oblasti nátisků ZK a optimalizace EVM. Psaní kódu s téměř špičkovou efektivitou se stává jednodušší a dostupnější. Auditování a formální ověřování takového kódu se stává jednodušší a dostupnější. A konečně, protože tyto velmi odlišné oblasti výpočetní techniky se sbližují na některých společných vzorcích, existuje mezi nimi více prostoru pro spolupráci a učení.