Mäta SNARK-prestanda: Frontends, backends och framtiden

En SNARK (Succinct Non-interactive Arguments of Knowledge) är ett viktigt kryptografiskt primitivt fyndapplikationer för skalbarhet i blockkedje (t.ex. L2-uppbyggnad) och integritet. SNARKs låter någon bevisa för en opålitlig verifierare V (t.ex. Ethereum-blockkedjan) att de känner till vissa data (t.ex. ett parti giltiga transaktioner). Ett naivt sätt att bevisa detta skulle vara att skicka data till V, som sedan direkt kan kontrollera dess giltighet. En SNARK uppnår samma sak, men med bättre kostnader för att V. I synnerhet bör ett SNARK-bevis vara kortare än det naiva som innehåller själva data. (För mer information, se utkastet till min lärobok, Bevis, argument och noll kunskap. För en introduktion till SNARKs, se Sarah Meicklejohns presentation vid a16z-krypten Sommarforskningsserien.)

Verifieringskostnaderna för SNARKs kan variera, men är väl förstådda och ofta ganska bra. Till exempel, PlonK bevis kostar ca 290,000 gas att verifiera på Ethereum, medan StarkWares provtryck kostade cirka 5 miljoner gas. SNARK är potentiellt tillämpliga i olika miljöer även utanför blockkedjor - till exempel möjliggör användning av snabba men opålitliga servrar och hårdvara. 

Men eftersom SNARK-verifiering vanligtvis är billig, är de viktigaste bestämningsfaktorerna för tillämplighet kostnaderna för SNARK-provaren P. I det här inlägget förklarar jag hur man uppskattar dessa kostnader för att avgöra när det är rimligt att använda SNARKs och hur SNARKs kan förbättras i framtiden. Det är värt att notera att detta är ett snabbt rörligt utrymme, och flera av projekten som diskuteras i det här inlägget förbättrar aktivt deras prestanda.

Men först: Hur SNARKs distribueras

I SNARK-distribution skriver en utvecklare vanligtvis ett datorprogram ψ som tar data som input w som bevisaren säger sig veta (w står för Vittne), och kontrollerar det w är giltig. Till exempel, i sammanslagningar, kommer programmet att kontrollera att alla transaktioner in w är digitalt signerade, får inte något kontosaldo att sjunka under noll, och så vidare. Programmet ψ matas sedan genom en SNARK frontend som kompilerar det till ett format som är mer mottagligt för tillämpning av SNARK-teknik. Detta SNARK-vänliga format kallas an mellanrepresentation (IR). 

Typiskt är IR någon form av krets-tillfredsställande instans som är likvärdig med ψ. Detta innebär att kretsen C tar data som indata w, samt några extra ingångar som vanligtvis kallas "icke-deterministisk rådgivning" och körningar ψ on w. Rådingångarna används för att hjälpa C köra ψ, medan du behåller C små. Till exempel varje gång ψ delar två tal x och y, kvoten q och resten r kan ges som råd till Coch C kan helt enkelt kolla det x = qy + r. Denna kontroll är billigare än att göra C kör en divisionsalgoritm för att beräkna q och r från början.

Slutligen appliceras ett SNARK för krets-tillfredsställelse C. Detta kallas SNARK backend. För en handfull högstrukturerade problem som t.ex matrismultiplikation, veckoch flera grafproblem, det finns kända SNARKs som undviker detta frontend/backend-paradigm och därigenom uppnår ett mycket snabbare bevis. Men fokus i det här inlägget ligger på SNARKs för allmänna ändamål.

Som vi kommer att se växer provningskostnaderna för SNARK-backend med C's storlek. Förvaring C liten kan vara utmanande, eftersom kretsar är ett extremt begränsat format för att uttrycka en beräkning. De består av grindar, ansluten av ledningar. Varje grind g matas med några värden och tillämpar en mycket enkel funktion till dessa värden. Resultatet matas sedan in i "nedströms" grindar via ledningarna som kommer från g.

SNARK-skalbarhet: Hur mycket tid tar det egentligen?

Nyckelfrågan är, hur mycket mer tid tar SNARK-provet, i förhållande till att bara köra om ψ på datan? Svaret är prova overhead av SNARK, i förhållande till direkt vittneskontroll. Det sistnämnda uttrycket syftar på att, i det naiva beviset i vilket P sänder w till V, V checkar ws giltighet genom att exekvera ψ på den. 

Det är bra att dela upp provaren overhead i "frontend overhead" och "backend overhead." Om man utvärderar kretsen C grind för grind är F gånger dyrare än att köra ψ, då säger vi att frontend-overheaden är F. Om du använder backend-provaren på C is B gånger dyrare än att utvärdera C gate-by-gate, då säger vi att backend-overheaden är B. Den totala prover-overheaden är produkt, F·B. Denna multiplikativa omkostnad kan vara betydande även om F och B är individuellt blygsamma. 

I praktiken, F och B kan båda vara ungefär 1000 eller större. Detta innebär att den totala provningskostnaden i förhållande till direkt vittneskontroll kan vara 1 miljon till 10 miljoner eller mer. Ett program som bara körs i en sekund på en bärbar dator kan lätt leda till att en SNARK-provare kräver tiotals eller hundratals dagars beräkningstid (entrådig). Lyckligtvis är detta arbete typiskt parallelliserbart i varierande utsträckning (beroende på SNARK). 

Sammanfattningsvis, om du vill använda en SNARK i en applikation idag, måste en av tre saker vara sanna:

1. Direkt vittneskontroll tar mycket mindre än en sekund på en bärbar dator.
2. Direkt vittneskontroll är särskilt mottaglig för representation i en krets, så frontend-overhead är liten.
3. Du är villig att vänta flera dagar på att SNARK-provaren ska avslutas och/eller betala för enorma parallella beräkningsresurser.

Tresten av det här inlägget förklarar var frontend- och backend-overheads kommer ifrån, och hur jag uppskattar dem för olika SNARKs. Vi kommer sedan att övergå till möjligheter till förbättring. 

Separera frontends och backends

Att helt separera frontends från backends kan vara utmanande eftersom olika backends stöder olika typer av kretsar. Därför kan gränssnitt skilja sig beroende på vilket gränssnitt de förväntar sig att gränssnittet.

SNARK backends stöder generellt så kallade aritmetiska kretsar, vilket innebär att ingångarna till kretsarna är element i något ändligt fält, och att kretsens grindar utför addition och multiplikation av två fältelement. Dessa kretsar motsvarar ungefär rätlinjiga datorprogram (inga grenar, villkorliga uttalanden och så vidare) som är algebraiska till sin natur - det vill säga deras primitiva datatyp är fältelement. 

De flesta backends stöder faktiskt en generalisering av aritmetiska kretsar som ofta kallas Rank-1 Constraint Satisfaction (R1CS)-instanser. Med det anmärkningsvärda undantaget Groth16 och dess föregångare, dessa SNARK kan göras för att stödja andra IR också. Till exempel använder StarkWare något som kallas Algebraic Intermediate Representation (AIR), som också liknar ett begrepp som kallas PlonKish aritmetisering som kan stödjas av PlonK och andra backends. Möjligheten hos vissa backends att stödja mer allmänna IR:er kan minska omkostnaderna för frontends som producerar dessa IR:er. 

Backends varierar också när det gäller de ändliga fält som de naturligt stöder. Jag kommer att diskutera detta vidare i nästa avsnitt.

Olika tillvägagångssätt för frontends

Vissa (mycket speciella) datorprogram motsvarar naturligtvis aritmetiska kretsar. Ett exempel är datorprogrammet som utför naiv multiplikation av matriser över något fält. Men de flesta datorprogram är varken raka eller algebraiska. De involverar ofta villkorliga uttalanden, operationer som heltalsdivision eller flyttalsaritmetik som inte naturligt motsvarar finita fältaritmetik, med mera. I dessa fall kommer frontend-overheaden att vara betydande. 

En populär frontend-metod är att producera kretsar som i huvudsak exekverar steg-för-steg en enkel CPU, även kallad en virtuell maskin (VM). Frontend-designers specificerar en uppsättning "primitiva operationer" analogt med monteringsinstruktioner för riktiga datorprocessorer. Utvecklare som vill använda gränssnittet kommer antingen att skriva "vittneskontrollprogram" direkt i assemblerspråket eller på något högre språk som Solidity, och få sina program automatiskt kompilerade till assemblerkod. 

Till exempel StarkWares Kairo är ett mycket begränsat assemblerspråk där monteringsinstruktioner grovt sett tillåter addition och multiplikation över ett ändligt fält, funktionsanrop och läser och skriver till ett oföränderligt (dvs. skriv-en gång) minne. Cairo VM är en von Neumann-arkitektur, vilket innebär att kretsarna som produceras av frontend i huvudsak tar ett Cairo-program som offentlig input och "kör" programmet på vittnet. Kairo-språket är Turing Complete - trots dess begränsade instruktionsuppsättning kan det simulera fler standardarkitekturer, även om det kan vara dyrt att göra det. Kairo-gränssnittet gör att Kairo-program körs T primitiva instruktioner till vad som kallas en "grad-2 LUFT med T rader och omkring 50 kolumner." Vad exakt detta betyder är inte viktigt för det här inlägget, men vad gäller SNARK-provare så motsvarar detta kretsar med mellan 50 och 100 grindar för var och en av T steg för Cairo CPU. 

RISC noll tar ett liknande förhållningssätt till Kairo, men med den virtuella maskinen som den så kallade RISC-V-arkitektur, en arkitektur med öppen källkod med ett rikt mjukvaruekosystem som växer i popularitet. Som en mycket enkel instruktionsuppsättning kan det vara relativt lätt att utforma ett effektivt SNARK-gränssnitt som stöder det (åtminstone i förhållande till komplicerade arkitekturer som x86 eller ARM). Från och med maj, RISC Zero vänder program exekvera T primitiva RISC-V instruktioner till grad-5 AIRs med 3T rader och 160 kolumner. Detta motsvarar kretsar med minst 500 grindar per steg för RISC-V CPU. Ytterligare förbättringar förväntas inom en snar framtid.

De olika zkEVM-projekten (t.ex. zkSync 2.0, Scroll, Polygons zkEVM) tar den virtuella maskinen för att vara (duh) den virtuella Ethereum-maskinen. Processen att förvandla varje EVM-instruktion till en likvärdig "gadget" (dvs. en optimerad krets som implementerar instruktionen) är betydligt mer involverad än för de enklare Kairo- och RISC-V-arkitekturen. Av detta och andra skäl, några av zkEVM-projekten implementerar inte direkt EVM-instruktionsuppsättningen utan kompilerar snarare Solidity-program på hög nivå till andra assemblerspråk innan de omvandlas till kretsar. Resultatresultat från dessa projekt väntar.

"CPU-emulator"-projekt som RISC-V och Cairo producerar en enda krets som kan hantera alla program i det tillhörande assemblerspråket. Alternativa tillvägagångssätt är "ASIC-liknande", som producerar olika kretsar för olika program. Detta ASIC-liknande tillvägagångssätt kan ge mindre kretsar för vissa program, speciellt när monteringsinstruktionen som programmet kör vid varje tidssteg inte beror på programmets input. Till exempel kan det potentiellt undvika frontend-overhead helt för linjära program som naiv matrismultiplikation. Men ASIC-metoden verkar också mycket begränsad; så vitt jag vet är det inte känt hur man använder det för att stödja loopar utan förutbestämda iterationsgränser. 

Den sista komponenten av frontend-overhead kommer från det faktum att alla SNARKs använder kretsar som fungerar över ändliga fält. CPU:n på din bärbara dator kan multiplicera eller lägga till två heltal med en enda maskininstruktion. Om en frontend matar ut en krets över ett fält med tillräckligt stor karakteristik, kan den i huvudsak simulera den multiplikationen eller additionen via motsvarande fältoperation. Men att implementera fältoperationen på en riktig CPU kräver vanligtvis många maskininstruktioner (även om vissa moderna processorer har inbyggt stöd för vissa fält). 

Vissa SNARK-backends möjliggör mer flexibla fältval än andra. Till exempel om backend använder en kryptografisk grupp G, måste kretsens fält matcha antalet element i G, vilket kan vara begränsande. Dessutom stöder inte alla fält praktiska FFT-algoritmer. 

Det finns bara en implementerad SNARK, Bromsning, som inbyggt stöder beräkningar över godtyckliga (tillräckligt stora) fält. Tillsammans med dess ättlingar, den har den snabbaste kända betongprovningsprestanda även över fält som andra SNARKs stödjer, men dess bevis är för närvarande för stora för många blockkedjeapplikationer. Senaste arbetet försöker förbättra bevisstorleken, men beviset är asymptotiskt långsammare och där verkar vara barriärer till det praktiska.

Vissa projekt har valt att arbeta över fält med särskilt snabb aritmetik. Till exempel, Plonky2 och andra använder ett fält med egenskap 2⁶⁴ - 2³² + 1 eftersom aritmetik i detta fält kan implementeras flera gånger snabbare än i mindre strukturerade fält. Användning av en så liten karakteristik kan emellertid leda till utmaningar i att effektivt representera heltalsaritmetik via fältoperationer (t.ex. multiplicera två 32-bitars heltal utan tecken kan ge ett resultat som är större än fältkarakteristiken). 

 Men oavsett vad, för att alla populära SNARKs idag ska uppnå 128 bitars säkerhet (utan en betydande ökning av verifieringskostnaderna), måste de arbeta över ett fält som är större än 2¹²⁸. Så vitt jag kan säga betyder detta att varje fältoperation kommer att kräva minst ett tiotal 64-bitars maskinmultiplikationer, och betydligt fler additioner och bitvisa operationer. Därför bör man räkna in minst en storleksordning frontend-overhead på grund av behovet av kretsar som fungerar över ändliga fält. 

Sammanfattningsvis producerar befintliga frontends som använder abstraktion av en virtuell maskin kretsar med 100x till 1000x grindar per steg av den virtuella maskinen, och möjligen mer för mer komplicerade virtuella maskiner. Ovanpå det är aritmetik med finita fält minst 10 gånger långsammare än analoga instruktioner på moderna processorer (med möjliga undantag om processorn har inbyggt stöd för vissa fält). En "ASIC frontend approach" kan minska vissa av dessa omkostnader men är för närvarande begränsad i de typer av program den kan stödja.

Vilka är backend-flaskhalsarna?

SNARKs för krets-tillfredsställelse är vanligtvis designade genom att kombinera ett informationsteoretiskt säkert protokoll som kallas "polynom IOP" med ett kryptografiskt protokoll som kallas "polynomiellt åtagandesystem.” I de flesta fall är den konkreta flaskhalsen för provaren det polynomiska åtagandesystemet. Dessa SNARKs har i synnerhet bevisaren att kryptografiskt binda sig till ett eller flera polynom vars grad är (minst) |C|, antalet grindar i kretsen C. 

I sin tur kommer betongflaskhalsen inom polynomåtagandeschemat att bero på det schema som används och kretsstorleken. Men det kommer alltid att vara en av följande tre operationer: beräkning av FFT, exponentiering i en kryptografisk grupp, eller Merkle-hashing. Merkle-hashing är vanligtvis bara en flaskhals om kretsen är liten, så vi kommer inte att diskutera det mer. 

Polynomåtaganden baserade på diskret logg

I polynomåtaganden baserade på hårdheten hos det diskreta logaritmproblemet i en kryptografisk grupp G (KZG, Skyddsskydd, doryoch Hyrax-commit), måste provaren beräkna en Pedersen vektor engagemang till polynomets koefficienter. Detta innebär en multi-exponentiering, av storlek lika med polynomets grad. I SNARKs är denna grad vanligtvis storleken |C| av kretsen C.

Gjort naivt, en multi-exponentiering av storlek |C| kräver cirka 1.5·|C|·log |G| ≈ 400·|C| koncernverksamhet, var |G| anger antalet element i gruppen G. Det finns dock ett tillvägagångssätt, kallat Pippengers algoritm, som kan minska detta med en faktor på ungefär log |C|. För stora kretsar (säg, |C| ≥ 225), denna logg |C| faktorn kan konkret vara 25 eller mer, det vill säga för stora kretsar förväntar vi oss att Pedersen vektorförpliktelse kan beräknas med lite över 10·|C| gruppverksamhet. Varje gruppoperation tenderar i sin tur att vara (som en mycket grov bollplank) ungefär 10 gånger långsammare än en finite field operation. SNARKs som använder dessa polynomåtaganden är lika dyra för P som cirka 100·|C| Fältoperationer. 

Tyvärr har befintliga SNARKs ytterligare omkostnader utöver 100x-faktorn ovan. Till exempel:

• Spartans prover, som använder Hyrax polynom engagemang, måste göra |C|^½ många multi-exponentieringar var och en av storlek |C|^½, vilket försvagar hastigheten från Pippengers algoritm med en faktor på ungefär två. 
• In Groth16, P måste arbeta över en parningsvänlig grupp, vars operationer vanligtvis är minst 2 gånger långsammare än grupper som inte är parningsvänliga. P måste också utföra 3 multi-exponentieringar snarare än 1. Tillsammans resulterar detta i minst en ytterligare faktor-6-bromsning i förhållande till 100·|C| uppskattning ovan. 
• Marlin och PlonK kräver också parningar, och deras prover för att binda sig till betydligt fler än 3 polynom. 
• För alla SNARK som använder Skyddsskydd (t.ex, Halo2, vilket är ungefär PlonK men med Bulletproofs snarare än KZG-polynomåtaganden), måste provaren logaritmiskt beräkna många multi-exponentieringar under "öppningsfasen" av åtagandeschemat, och detta raderar till stor del alla Pippenger-hastigheter. 

Sammanfattningsvis verkar kända SNARKs som använder Pedersen-vektoråtaganden ha en backend-overhead på minst 200x och upp till 1000x eller mer. 

Andra polynomåtaganden

För SNARKs som använder andra polynomåtaganden (som t.ex Fredag och Ligero-begå), flaskhalsen är att provaren behöver utföra stora FFTs. Till exempel i AIR-graden 2 som produceras av Kairo (med 51 kolumner och T rader, en per steg av Cairo CPU), StarkWares utplacerade prover gör minst 2 FFTs per kolumn, med längd mellan 16 ·T och 32 ·T. Konstanterna 16 och 32 beror på interna parametrar för FRI som ställts in av StarkWare och kan reduceras – men till bekostnad av ökade verifieringskostnader. 

Optimistiskt, en FFT med längden 32·T tar ca 64·T·log(32T) fältmultiplikationer. Detta innebär att även för relativt små värden på T (t.ex, T ≥ 2²⁰), antalet fältoperationer per kolumn är minst 64·25·T= 1600·T. Så backend-overheaden verkar vara åtminstone i tusental. Dessutom är det möjligt att stora FFT:er är ännu mer flaskhalsade av minnesbandbredd än av fältoperationer. 

I vissa sammanhang kan backend-overheaden för SNARK:er som utför stora FFT:er mildras med en teknik som kallas bevisaggregation. För rollups skulle detta betyda det P (sammansättningstjänsten) delar upp en stor grupp transaktioner i, säg, 10 mindre partier. För varje liten sats i, P producerar ett SNARK-bevis πi av partiets giltighet. Men P lägger inte upp dessa bevis till Ethereum, eftersom detta skulle leda till en nästan 10-faldig ökning av gaskostnaderna. Istället används SNARK ännu en gång, denna gång för att producera ett bevis π fastställa det P vet π₁ ...,π₁₀. Det vill säga vittnet att P påstår sig veta är de tio bevisen π₁,…,π₁₀, och direkt vittneskontroll tillämpar SNARK-verifieringsproceduren på vart och ett av bevisen. Detta enda bevis π är postat till Ethereum. 

I polynomåtaganden som FRI och Ligero-commit finns det en stark spänning mellan P tid och V kostnader, med interna parametrar som fungerar som en ratt som kan byta ut det ena mot det andra. Eftersom π₁ ,…,π₁₀ inte skickas till Ethereum, ratten kan ställas in så dessa bevis är stora och det går snabbare att producera dem. Endast i den slutliga tillämpningen av SNARK, att aggregera π₁ ,…,π₁₀ till ett enda bevis π, behöver åtagandeschemat konfigureras för att säkerställa ett litet bevis. 

StarkWare planerar att distribuera bevisaggregation överhängande. Detta är också fokus för projekt som t.ex Plonky2.

Vilka är de andra flaskhalsarna för SNARKs skalbarhet?

Det här inlägget har fokuserat på prover tid, men andra provningskostnader kan också vara skalbarhetsflaskhalsar. Till exempel, för många SNARK-backends behöver provaren lagra flera fältelement för varje gate i C, och denna utrymmeskostnad kan vara enorm. Till exempel ett program ψ körning på en sekund på en bärbar dator kan utföra kanske en miljard primitiva operationer på en modern processor. Som vi har sett bör man i allmänhet förvänta sig C att kräva långt över 100 grindar per sådan operation. Detta innebär 100 miljarder grindar, vilket, beroende på SNARK, kan innebära tiotals eller hundratals terabyte utrymme för P. 

Ett annat exempel: många populära SNARKs (t.ex. PlonK, Marlin, Groth16) kräver en komplicerad "trusted setup-ceremoni" för att generera en strukturerad "bevisnyckel", som måste lagras av provaren. Såvitt jag vet är största sådan ceremoni genererade en testnyckel som kan stödja kretsar med cirka 2²⁸≈250 miljoner grindar. Bevisnyckeln är flera dussin gigabyte stor. 

I sammanhang där bevisaggregation är möjlig kan dessa flaskhalsar mildras avsevärt. 

Framöver: utsikter för mer skalbara SNARKs

Både frontend och backend omkostnader kan vara tre storleksordningar eller mer. Kan vi förvänta oss att dessa kommer att minska avsevärt inom en snar framtid? 

Jag tror att vi kommer att göra det - till en viss grad. Först, de snabbaste backends idag (t.ex. Spartan och Bromsning, och andra SNARKs som kombinerar summakontrollprotokoll med polynomåtaganden) har stora bevis – vanligtvis kvadratroten i kretsens storlek – så folk använder dem inte riktigt. Jag förväntar mig att bevisstorleken och verifieringstiden kommer att reduceras på ett meningsfullt sätt inom en snar framtid via djup-ett-komposition med småsäkra SNARKs. I likhet med bevisaggregering betyder detta att en provare först genererar ett SNARK-bevis π med "snabbprovaren, storsäkra" SNARK, men inte skicka π till V. Snarare, P skulle använda ett småsäkert SNARK för att producera ett bevis π' att den vet π, och skicka π' till V. Detta skulle kunna raka bort en storleksordning från backend-omkostnaderna för SNARKs som är populära idag. 

För det andra kan hårdvaruacceleration hjälpa. En mycket grov generell regel är att GPU:er kan köpa en 10x speedup över CPU:er och ASICs en 10x speedup över GPU: er. Jag har dock tre bekymmer på denna front. För det första kan stora FFT:er ha flaskhalsar av minnesbandbredd snarare än fältoperationer, så SNARK:er som utför sådana FFT:er kan se begränsade hastigheter från specialiserad hårdvara. För det andra, medan det här inlägget fokuserade på flaskhalsen för polynomåtaganden, kräver många SNARK:er provaren för att utföra andra operationer som bara är något billigare. Så att bryta flaskhalsen för polynomengagemang (t.ex. påskynda multi-exponentieringen i diskreta loggbaserade SNARKs) kan lämna en ny flaskhalsoperation som inte är mycket bättre än den gamla. (Till exempel, SNARKs inklusive Groth16, Marlin och PlonK har också FFT:er, förutom multiexponentieringar.) Slutligen kan de fält och elliptiska kurvor som leder till de mest effektiva SNARKs fortsätta att utvecklas under en tid, och det kan skapa utmaningar för ASIC-baserad provacceleration.

På frontend-sidan kan vi i allt högre grad upptäcka att "CPU-emulator"-metoden för projekt som Cairo, RISC Zero, zkEVMs och andra faktiskt skalas ganska bra (i termer av prestanda) med komplexiteten hos CPU-instruktionsuppsättningar. Detta är faktiskt just förhoppningen om olika zkEVM-projekt. Detta kan innebära att, medan frontend-overheaden förblir tre storleksordningar eller mer, lyckas frontends stödja virtuella datorer som i allt högre grad matchar verkliga CPU-arkitekturer. En motverkande oro är att gränssnitten kan bli komplicerade och svåra att granska, eftersom handkodade prylar som implementerar allt mer komplicerade instruktioner ökar. Formella verifieringsmetoder kommer sannolikt att spela en viktig roll för att ta itu med detta problem. 

Slutligen, åtminstone i blockchain-applikationer, kan vi upptäcka att de flesta smarta kontrakt som dyker upp i naturen i första hand använder enkla, SNARK-vänliga instruktioner. Detta kan möjliggöra låga gränsöverskridande omkostnader i praktiken samtidigt som den generella och förbättrade utvecklarupplevelsen som kommer med stöd för högnivåprogrammeringsspråk som Solidity och rika instruktionsuppsättningar, inklusive de i EVM, bibehålls. 

***

Justin Thaler is en docent vid Georgetown University. Innan han började på Georgetown tillbringade han två år som forskare vid Yahoo Labs i New York, innan han var forskare vid Simons Institute for theory of Computing vid UC Berkeley. 

***

Tack: Jag är tacksam för Elena Burger för att ha föreslagit ämnet för detta inlägg, och för att Arasu Arun, Joseph Bonneauoch Sam Ragsdale för insiktsfulla kommentarer. Ett särskilt tack även till min redaktör, Tim Sullivan.

***

De åsikter som uttrycks här är de från den individuella AH Capital Management, LLC (“a16z”) personal som citeras och är inte åsikterna från a16z eller dess dotterbolag. Viss information som finns här har erhållits från tredjepartskällor, inklusive från portföljbolag av fonder som förvaltas av a16z. Även om den är hämtad från källor som anses vara tillförlitliga, har a16z inte självständigt verifierat sådan information och gör inga utfästelser om informationens varaktiga riktighet eller dess lämplighet för en given situation. Dessutom kan detta innehåll innehålla tredjepartsannonser; a16z har inte granskat sådana annonser och stöder inte något reklaminnehåll i dem.

Detta innehåll tillhandahålls endast i informationssyfte och bör inte litas på som juridisk rådgivning, affärs-, investerings- eller skatterådgivning. Du bör rådfråga dina egna rådgivare i dessa frågor. Hänvisningar till värdepapper eller digitala tillgångar är endast i illustrativt syfte och utgör inte en investeringsrekommendation eller erbjudande om att tillhandahålla investeringsrådgivningstjänster. Dessutom är detta innehåll inte riktat till eller avsett att användas av några investerare eller potentiella investerare, och får inte under några omständigheter lita på när man fattar ett beslut om att investera i någon fond som förvaltas av a16z. (Ett erbjudande om att investera i en a16z-fond kommer endast att göras av det privata emissionsmemorandumet, teckningsavtalet och annan relevant dokumentation för en sådan fond och bör läsas i sin helhet.) Alla investeringar eller portföljbolag som nämns, hänvisas till, eller beskrivna är inte representativa för alla investeringar i fordon som förvaltas av a16z, och det finns ingen garanti för att investeringarna kommer att vara lönsamma eller att andra investeringar som görs i framtiden kommer att ha liknande egenskaper eller resultat. En lista över investeringar gjorda av fonder som förvaltas av Andreessen Horowitz (exklusive investeringar för vilka emittenten inte har gett tillstånd för a16z att offentliggöra såväl som oanmälda investeringar i börsnoterade digitala tillgångar) finns tillgänglig på https://a16z.com/investments /.

Diagram och grafer som tillhandahålls i är endast i informationssyfte och bör inte litas på när man fattar investeringsbeslut. Tidigare resultat är inte en indikation på framtida resultat. Innehållet talar endast från det angivna datumet. Alla prognoser, uppskattningar, prognoser, mål, framtidsutsikter och/eller åsikter som uttrycks i detta material kan ändras utan föregående meddelande och kan skilja sig åt eller strida mot åsikter som uttrycks av andra. Se https://a16z.com/disclosures för ytterligare viktig information.