Har fulgt med på reaksjonene på det jeg sa om L2 for omtrent 1,5 dag siden. En viktig ting jeg mener er: «lag enda en EVM-kjede og legg til en optimistisk bro til Ethereum med en ukes forsinkelse» er å forklare hva forking av Compound er for styring – noe vi har gjort altfor mye og altfor lenge, fordi vi ble komfortable, og som har tappet fantasien vår og satt oss i en blindvei. Hvis du lager en EVM-kjede *uten* en optimistisk bro til Ethereum (alta en alternativ L1), er det enda verre. Vi trenger ikke flere copypasta-EVM-kjeder, og vi trenger definitivt ikke enda flere L1-er. L1 skalerer og vil gi mye EVM-blokkplass – ikke uendelig (spesielt AI-er vil trenge både mer blokkplass og lavere latens enn selv en kraftig skalert L1 kan tilby), men mye. Bygg noe som bringer noe nytt til bordet. Jeg ga noen eksempler: personvern, app-spesifikk effektivitet, ultralav latenstid, men listen min er sikkert veldig ufullstendig. En annen viktig ting jeg mener er: når det gjelder «tilkobling til Ethereum», må vibber matche substansen. Personlig er jeg fan av mange av tingene som kan kalles «app-kjeder». For eksempel tror jeg det er stor sjanse for at den optimale arkitekturen for prediksjonsmarkeder er noe sånt som: markedet blir utstedt og løst på L1, brukerkontoene er på L1, men handelen skjer på en basert rollup eller et annet L2-lignende system, hvor utførelsen leser L1 for å verifisere signaturer og markeder. Jeg liker arkitekturer hvor dyp tilknytning til L1 er førsteklasses, og ikke en ettertanke ("vi er stort sett en separat kjede, men å ja, vi har en bro, og ok, greit, la oss sette 1-2 utviklere for å få det til fase 1 så L2Beat-folkene setter et grønt hakemerke på det, så Vitalik liker oss"). Det andre ytterpunktet av «appkjede», f.eks. versjonen hvor du overbeviser et statlig register, en sosial medieplattform, eller en spillgreie, til å begynne å legge Merkle-røtter i databasen sin, med STARK-er som beviser at hver oppdatering var autorisert, signert og utført etter en forhåndsbestemt algoritme, onchain, er også rimelig – dette er det som gir mest mening for meg når det gjelder «institusjonelle L2». Det er åpenbart ikke Ethereum, ikke troverdig nøytralt og ikke tillitsløst – operatøren kan alltid bare velge å si «vi bytter til en annen versjon med andre regler nå». Men det vil muliggjøre verifiserbar algoritmisk transparens, en egenskap mange av oss gjerne vil se i regjeringen, sosiale mediers algoritmer eller hvor som helst ellers, og det kan muliggjøre økonomisk aktivitet som ellers ikke ville vært mulig. Jeg tror at hvis du er det første, er det gyldig og flott å kalle deg en Ethereum-applikasjon – den kan ikke overleve uten Ethereum, selv teknologisk, den maksimerer interoperabilitet og komponerbarhet med andre Ethereum-applikasjoner. Hvis du er det andre, er du ikke Ethereum, men du (i) gir menneskeheten mer algoritmisk åpenhet og tillitsminimering, så du følger en lignende visjon, og (ii) avhengig av detaljer sannsynligvis synergistisk med Ethereum. Så du bør bare si de tingene direkte! I bunn og grunn: 1. Gjør noe som faktisk bringer noe nytt til bordet. 2. Vibber bør samsvare med innhold – graden av tilknytning til Ethereum i ditt offentlige image bør reflektere graden av tilknytning til Ethereum som produktet ditt faktisk har.

Jeg synes faktisk ikke det er komplisert. Etter min mening vil fremtiden for onchain-mekanismedesign stort sett passe inn i ett mønster: [noe som ser ut som et prediksjonsmarked] -> [noe som ser ut som en fangstresistent, ikke-finansialisert preferanseinnstillingsenhet] Med andre ord: * Ett lag som er maksimalt åpent og maksimerer ansvarlighet (det er et marked, hvem som helst kan kjøpe og selge, hvis du tar gode beslutninger vinner du penger, hvis du tar dårlige avgjørelser taper du penger) * Ett lag som er desentralisert og pluralistisk, og som maksimerer rom for indre motivasjon. Dette kan ikke være tokenbasert, fordi token-eiere ikke er pluralistiske, og hvem som helst kan kjøpe seg inn og få 51 % av dem. Avstemningene her bør være anonyme, ideelt sett MACID for å redusere risikoen for sammensvergelse. Prediksjonsmarkedet er den riktige måten å gjøre en «desentralisert leder» på, fordi den mest logiske primitiven for «ansvarlighet» i et tillatelsesløst konsept er nettopp det. Men noen ganger vil du holde det enkelt, og heller ha en sentralisert leder på det laget: [utskiftbar sentralisert leder] -> [noe som ser ut som en fangstresistent, ikke-finansialisert preferanseinnstillingsenhet] Å tenke eksplisitt i disse to lagene: (i) hva som utfører din utførelse, (ii) hva som gjør din preferanseinnstilling og vurderer eksekutoren(e), er best.