Mi sto arrendendo, d'ora in poi chiamerò Twitter "X". "Tweet" diventa un termine generico per i messaggi su qualsiasi piattaforma che dà priorità ai contenuti testuali brevi con un'esperienza utente simile a quella di X, linguisticamente simile a "kleenex". Guida all'uso: * "Vitalik sta twittando solo su Farcaster e Lens quest'anno, non è terribile quanto sia elitista in una torre d'avorio?" * "Hai visto il nuovo tweet razzista scioccante di Donald Trump su Truth Social?" * "Quando l'ho inviato nel 2019, era un tweet, e secondo questa nuova definizione lo è ancora, ma ora possiamo anche riferirci ad esso ex-post come a un post X" "Crypto Twitter" può rimanere come frase fissa, similmente a come il Peking Duck è ancora chiamato Peking Duck, anche se ovviamente sarebbe divertente se più persone lo chiamassero CryptoX (alias CrypTox). (Questo tweet è stato inviato simultaneamente su X, Farcaster e Lens tramite Firefly)

Ho seguito le reazioni a ciò che ho detto sugli L2 circa 1,5 giorni fa. Una cosa importante che credo sia: "creare un'altra catena EVM e aggiungere un ponte ottimista a Ethereum con un ritardo di 1 settimana" è per l'infrastruttura ciò che il fork di Compound è per la governance - qualcosa che abbiamo fatto troppo a lungo, perché ci siamo sentiti a nostro agio, e che ha prosciugato la nostra immaginazione e ci ha messi in un vicolo cieco. Se crei una catena EVM *senza* un ponte ottimista verso Ethereum (alias un alt L1), è ancora peggio. Non abbiamo bisogno di più catene EVM copiate, e sicuramente non abbiamo bisogno di ancora più L1. L1 sta scalando e porterà molto spazio blocco EVM - non infinito (le IA in particolare avranno bisogno di più spazio blocco e di una latenza inferiore di quanto possa offrire anche un L1 molto scalato), ma tanto. Costruisci qualcosa che porti qualcosa di nuovo sul tavolo. Ho dato alcuni esempi: privacy, efficienza specifica per app, latenza ultra-bassa, ma la mia lista è sicuramente molto incompleta. Una seconda cosa importante che credo sia: riguardo alla "connessione a Ethereum", le vibrazioni devono corrispondere alla sostanza. Personalmente sono un fan di molte delle cose che possono essere chiamate "app chains". Ad esempio, penso che ci sia una grande possibilità che l'architettura ottimale per i mercati delle previsioni sia qualcosa del tipo: il mercato viene emesso e risolto su L1, gli account utente sono su L1, ma il trading avviene su un rollup basato o su un altro sistema simile a L2, dove l'esecuzione legge l'L1 per verificare le firme e i mercati. Mi piacciono le architetture in cui la connessione profonda a L1 è di prima classe, e non un pensiero secondario ("siamo praticamente una catena separata, ma oh sì, abbiamo un ponte, e ok va bene mettiamo 1-2 sviluppatori per portarlo alla fase 1 così le persone di l2beat metteranno un segno di spunta verde su di esso così vitalik ci piacerà"). L'altro estremo di "app chain", ad esempio, la versione in cui convinci qualche registro governativo, o piattaforma di social media, o gioco, a iniziare a mettere le radici merkle del suo database, con STARK che dimostrano che ogni aggiornamento è stato autorizzato, firmato ed eseguito secondo un algoritmo pre-impegnato, on-chain, è anche ragionevole - questo ha molto senso per me in termini di "L2 istituzionali". Non è ovviamente Ethereum, non è credibilmente neutrale e non è senza fiducia - l'operatore può sempre semplicemente scegliere di dire "stiamo passando a una versione diversa con regole diverse ora". Ma consentirebbe una trasparenza algoritmica verificabile, una proprietà che molti di noi vorrebbero vedere nel governo, negli algoritmi dei social media o altrove, e potrebbe abilitare attività economiche che altrimenti non sarebbero possibili. Penso che se sei la prima cosa, è valido e fantastico chiamarti un'applicazione Ethereum - non può sopravvivere senza Ethereum anche tecnologicamente, massimizza l'interoperabilità e la composizione con altre applicazioni Ethereum. Se sei la seconda cosa, allora non sei Ethereum, ma stai (i) portando all'umanità più trasparenza algoritmica e minimizzazione della fiducia, quindi stai perseguendo una visione simile, e (ii) a seconda dei dettagli probabilmente sinergico con Ethereum. Quindi dovresti semplicemente dire queste cose direttamente! Fondamentalmente: 1. Fai qualcosa che porti qualcosa di realmente nuovo sul tavolo. 2. Le vibrazioni dovrebbero corrispondere alla sostanza - il grado di connessione a Ethereum nella tua immagine pubblica dovrebbe riflettere il grado di connessione a Ethereum che la tua cosa ha nella realtà.

In realtà non penso sia complicato. A mio avviso, il futuro del design dei meccanismi onchain si adatterà principalmente a uno schema: [qualcosa che assomiglia a un mercato delle previsioni] -> [qualcosa che assomiglia a un dispositivo di impostazione delle preferenze resistente alla cattura e non finanziarizzato] In altre parole: * Un livello che è massimamente aperto e massimizza la responsabilità (è un mercato, chiunque può comprare e vendere, se prendi buone decisioni guadagni soldi, se prendi cattive decisioni perdi soldi) * Un livello che è decentralizzato e pluralistico, e che massimizza lo spazio per la motivazione intrinseca. Questo non può essere basato su token, perché i possessori di token non sono pluralistici, e chiunque può entrare e ottenere il 51% di essi. I voti qui dovrebbero essere anonimi, idealmente MACID per ridurre il rischio di collusione. Il mercato delle previsioni è il modo corretto per fare un "esecutivo decentralizzato", perché il primitivo più logico per "responsabilità" in un concetto senza permessi è esattamente quello. Anche se a volte vorrai mantenerlo semplice e fare un esecutivo centralizzato a quel livello invece: [esecutivo centralizzato sostituibile] -> [qualcosa che assomiglia a un dispositivo di impostazione delle preferenze resistente alla cattura e non finanziarizzato] Pensare esplicitamente a questi due livelli: (i) chi sta eseguendo, (ii) chi sta impostando le preferenze e giudica l'esecutore(i), è la cosa migliore.