Hace más de un año, comenzamos una iniciativa interna de moonshot en @Covalent_HQ para reimaginar la infraestructura blockchain desde los principios básicos.
La llamamos nuestro Proyecto Manhattan - como el esfuerzo de I+D en tiempos de guerra que reunió a las mentes más brillantes para resolver un problema urgente.
Pero el nuestro no se trata de física. Se trata de datos blockchain.
¿Por qué?
Porque algo ha cambiado fundamentalmente.
Las cadenas ahora producen bloques en menos de un segundo.
Sin embargo, la mayoría de las aplicaciones aún dependen de APIs que se actualizan cada 5-30 segundos.
Indexadores heredados. Bucles de sondeo. Instantáneas obsoletas.
Llamamos a esto la Crisis de Latencia - y no es solo un inconveniente para los desarrolladores.
Es un fallo sistémico en la base de Web3.
↠ Los oráculos están desactualizados para cuando publican. ↠ Los exploradores de bloques están rezagados respecto al estado real de la cadena. ↠ Los paneles de control se sienten rotos. ↠ Los bots pierden operaciones rentables. ↠ Las carteras muestran saldos obsoletos y confunden a los usuarios.
Este no es un caso aislado. Es el comportamiento predeterminado en todo el ecosistema.
Después de más de 5 años construyendo Covalent, puedo decir esto con confianza:
La arquitectura que nos trajo aquí no nos llevará más lejos.
El problema ha superado las herramientas.
Así que dejamos de parchear el código heredado. Dejamos de recomendar soluciones a corto plazo a nuestros más de 40K desarrolladores en la API @goldrushdev.
Reconstruimos la pila - desde la ingestión de bloques en crudo hasta la entrega de datos en menos de un segundo. De principio a fin.
En los próximos días, compartiré lo que hemos aprendido, lo que hemos construido y por qué la próxima ola de aplicaciones blockchain no será posible sin resolver la latencia desde la raíz.
Estoy tomando una dirección diferente en X en lugar de la habitual charla y promoción de KOL. Estoy profundizando.
Estamos explorando opciones para una cuenta / billetera inteligente para un próximo proyecto y me sorprende un poco cómo está estructurado el mercado actual:
Parece que @safe, seguido por @Alchemy, @zerodev_app, Pimlico, Biconomy lideran en implementaciones históricas - pero si estudias las tasas de crecimiento, en realidad son Zerodev y Pimlico los que están creciendo en los últimos 3 meses.
Cuando se trata de transacciones reales de estas implementaciones, parece que Zerodev/Pimlico se mantienen estables.
¿Qué hace que Zerodev se destaque aquí? No estoy muy familiarizado con este mercado.
Como constructor de EVM, he comenzado a notar algo incómodo: la nueva ola de desarrolladores en estas cadenas de bloques más rápidas como Solana, MegaETH, Monad, Sonic entre otras ya están operando en un paradigma diferente: primero el streaming, baja latencia y construido para una experiencia de usuario en tiempo real.
Mientras tanto, muchos de nosotros en el mundo de Ethereum todavía estamos atrapados pensando en bloques e intervalos de sondeo. Estamos tratando de injertar velocidad en sistemas que nunca fueron diseñados para ello, y se nota.
A medida que cadenas como @base se mueven a un tiempo de bloque de menos de un segundo, los desarrolladores de EVM necesitarán mejorar o quedarse atrás.
Aquí hay cuatro ejemplos que me impactan:
1️⃣ Fuentes de precios de billetera Si hay un intercambio cada bloque, entonces los precios cambian cada bloque. Una estrategia de sondeo simplemente no funciona para reflejar los últimos precios.
2️⃣ Juegos en cadena Los juegos de Ethereum son en su mayoría simulaciones fuera de la cadena con liquidación en cadena. Los juegos más nuevos transmitirán eventos en cadena (como movimientos de usuarios, acciones de enemigos o caídas de botín) sin retraso perceptible. Los juegos de EVM hoy son en su mayoría juegos por turnos.
3️⃣ Agentes de IA Mientras desarrollábamos nuestro SDK de Agente de IA, queríamos construir un copiloto de trading de IA que ingiera datos del mercado en tiempo real cada 400ms, detecte patrones como la manipulación o actividad de ballenas, y transmita información en tiempo real directamente a la interfaz de usuario, sugiriendo órdenes pre-llenadas o ajustándose al riesgo. Solo diré que esto fue difícil de construir cuando los datos estaban retrasados, agrupados y tenían que ser sondeados fuera de RPCs e indexadores.
4️⃣ Flujos de datos composables La infraestructura de datos del futuro será el streaming de cambios de estado a través de protocolos, como sincronizar cambios en las tasas de interés directamente en los agregadores de rendimiento. En el mundo de EVM, unimos APIs y rezamos por consistencia.
Esto no es solo teórico, este es un problema hoy con aplicaciones en testnets para Monad y MegaETH. Vemos estos problemas de primera mano hablando con desarrolladores que trabajan con @Covalent_HQ.
Estamos construyendo una solución: ¡mantente atento! 👀
Cada constructor necesitará mejorar sus habilidades para prepararse para el nuevo mundo de cadenas rápidas y de alto rendimiento. Si los bloques se transmiten a ~250ms, aquí tienes tu hoja de trucos para la latencia:
🔄 Caché L1: 0.5 ns 🔄 RAM: 100 ns 🔄 Lectura de SSD: 100 µs 🔄 Búsqueda en disco: 10 ms
Dentro de un centro de datos en una sola zona de disponibilidad:
↔️ 5ms
Tiempo de ida y vuelta global desde la costa oeste:
↔️ NY: 70 ms ↔️ Londres: 160 ms ↔️ Tokio: 120 ms ↔️ Singapur: 200 ms ↔️ Dubái: 280 ms
💡 En un mundo de cadenas de subsegundos, cada ms cuenta. La velocidad de la luz es tu nuevo cuello de botella. Optimiza en consecuencia.
el nombre de la última actualización de Ethereum, es un portmanteau de:
• Praga - el nombre para la capa de ejecución • Electra - el nombre para la capa de consenso
Juntos: Pectra = Praga + Electra
Pectra representa la coordinación conjunta de los cambios de EL y CL en un solo hard fork - continuando con la cadencia de actualizaciones de Ethereum después de la fusión.