Estoy capitulando, llamaré a Twitter "X" a partir de ahora. "Tweet" se convierte en un término genérico para los mensajes en cualquier plataforma que priorice contenido de texto corto con una experiencia de usuario similar a X, lingüísticamente similar a "kleenex". Guía de uso: * "Este año Vitalik solo tuitea en Farcaster y Lens, ¿no es horrible lo elitista de la torre de marfil que es?" * "¿Viste el impactante nuevo tuit racista de Donald Trump en Truth Social?" * "Cuando envié eso en 2019, era un tuit, y según esta nueva definición sigue siéndolo, pero ahora también podemos referirnos a ello ex-post como un X post" "Crypto Twitter" puede permanecer como una frase fija, de forma similar a cómo Peking Duck sigue llamándose Peking Duck, aunque por supuesto sería gracioso que más gente lo llamara CryptoX (también conocido como CrypTox). (Este tuit se envió simultáneamente en X, Farcaster y Lens a través de Firefly)

He estado siguiendo las reacciones a lo que dije sobre los L2 hace aproximadamente un día y medio. Una cosa importante que creo que es: "crear otra cadena EVM más y añadir un puente optimista a Ethereum con un retraso de una semana" es infrarestablecer lo que es bifurcar Compound para la gobernanza — algo que hemos hecho demasiado durante demasiado tiempo, porque nos acostumbramos, y que nos ha agotado la imaginación y nos ha dejado en un callejón sin salida. Si haces una cadena EVM *sin* un puente optimista hacia Ethereum (es decir, un L1 alternativo), eso es aún peor. No necesitamos ni una vez más cadenas de EVM de copypast, y desde luego no necesitamos aún más L1. L1 está escalando y va a traer mucho espacio de bloques EVM, no infinito (las IAs en particular necesitarán tanto más espacio de bloques como menor latencia que incluso una L1 muy escalada), pero mucho. Construye algo que aporte algo nuevo. He dado algunos ejemplos: privacidad, eficiencia específica de la aplicación, latencia ultrabaja, pero mi lista seguramente está muy incompleta. Otra cosa importante que creo es: en cuanto a la "conexión con Ethereum", las vibraciones deben estar a la altura del contenido. Personalmente, soy fan de muchas de las cosas que se pueden llamar "cadenas de aplicaciones". Por ejemplo, creo que hay muchas probabilidades de que la arquitectura óptima para los mercados de predicción sea algo así: el mercado se emite y resuelve en L1, las cuentas de usuario están en L1, pero el trading se realiza en algún sistema basado en rollup u otro tipo L2, donde la ejecución lee el L1 para verificar firmas y mercados. Me gustan las arquitecturas donde la conexión profunda con L1 es de primera clase y no una ocurrencia secundaria ("somos prácticamente una cadena separada, pero sí, tenemos un puente, y vale, pongamos a 1-2 desarrolladores para llevarlo a la fase 1 y así la gente de L2beat le ponga una marca verde para que a Vitalik le gustemos"). El otro extremo de la "cadena de aplicaciones", por ejemplo, La versión en la que convences a algún registro gubernamental, o plataforma de redes sociales, o algo de videojuegos, para que empiece a poner raíces Merkle en su base de datos, con STARKs que demuestren que cada actualización fue autorizada, firmada y ejecutada según un algoritmo precomprometido, onchain, también es razonable; esto es lo que más sentido me parece en términos de "L2 institucionales". Obviamente no es Ethereum, ni creíblemente neutral ni sin confianza: el operador siempre puede simplemente decir "ahora cambiamos a otra versión con reglas distintas". Pero permitiría una transparencia algorítmica verificable, una propiedad que a muchos nos encantaría ver en el gobierno, en los algoritmos de las redes sociales o en cualquier otro lugar, y podría posibilitar una actividad económica que de otro modo no sería posible. Creo que si eres lo primero, es válido y genial llamarte una aplicación Ethereum: no puede sobrevivir sin Ethereum ni siquiera tecnológicamente, maximiza la interoperabilidad y la componibilidad con otras aplicaciones Ethereum. Si eres lo segundo, entonces no eres Ethereum, pero (i) aportas a la humanidad más transparencia algorítmica y minimización de confianza, así que persigues una visión similar, y (ii) dependiendo de los detalles, probablemente sinergizco con Ethereum. ¡Así que deberías decir esas cosas directamente! Básicamente: 1. Haz algo que aporte algo realmente nuevo. 2. Las vibraciones deben estar a la altura del contenido: el grado de conexión con Ethereum en tu imagen pública debe reflejar el grado de conexión que tu cosa tiene con Ethereum en la realidad.

En realidad no creo que sea complicado. En mi opinión, el futuro del diseño de mecanismos onchain va a encajar principalmente en un mismo patrón: [algo que parezca un mercado de predicción] -> [algo que parezca un dispositivo resistente a la captura y no financiarizado para establecer preferencias] En otras palabras: * Una capa que sea lo más abierta que maximice la responsabilidad (es un mercado, cualquiera puede comprar y vender, si tomas buenas decisiones ganas dinero; si tomas malas decisiones pierdes dinero) * Una capa que es descentralizada y pluralista, y que maximiza el espacio para la motivación intrínseca. Esto no puede ser basado en tokens, porque los propietarios de tokens no son pluralistas y cualquiera puede comprar y obtener el 51% de ellos. Los votos aquí deberían ser anónimos, idealmente con MACI para reducir el riesgo de colusión. El mercado de predicciones es la forma correcta de hacer un "ejecutivo descentralizado", porque la primitiva más lógica para la "rendición de cuentas" en un concepto sin permisos es precisamente esa. Aunque a veces querrás mantenerlo sencillo y hacer un ejecutivo centralizado en esa capa en su lugar: [ejecutivo centralizado reemplazable] -> [algo que parezca un dispositivo de preferencia resistente a la captura y no financiarizado] Pensar explícitamente en estas dos capas: (i) qué está haciendo tu ejecución, (ii) qué está haciendo tu preferencia y juzgando al/los albacea(s), es lo mejor.