TL;DR

La inteligencia artificial domina como el sector más moderno en la escena de capital de riesgo, seguida de cerca por iniciativas centradas en Bitcoin. En cualquier día dado, las discusiones sobre estos temas pueden dominar hasta el 80% de todas las conversaciones sobre proyectos, con registros personales alcanzando cinco o seis proyectos de inteligencia artificial.

Se espera que el sector de la IA alcance su pico especulativo en los próximos años. A pesar de la eventual explosión de esta burbuja, que probablemente causará importantes perturbaciones en el mercado, se predice que esta fase también dará lugar a unicornios que logren combinar con éxito la IA con la criptomoneda, impulsando un impulso sustancial en la industria.

A la luz del actual revuelo en torno a la IA, es beneficioso hacer una pausa y reflexionar sobre las evoluciones infraestructurales dentro de las blockchains públicas en los últimos meses. Algunas innovaciones en esta área son particularmente dignas de mención y merecen un examen más detenido.

1. La Evolución y Expansión de Ethereum y las Cadenas de Bloques de una Sola Capa

Los conceptos de capas de modularidad y Disponibilidad de Datos (DA), propuestos por primera vez por Celestia, se han convertido ahora en una piedra angular de la infraestructura blockchain, profundamente arraigados en la conciencia de la comunidad. Esto ha llevado a una explosión en el número de infraestructuras de Rollup como Servicio (RaaS), superando ahora tanto a las aplicaciones que respaldan como a sus usuarios, una clara indicación de la saturación del mercado.

En los últimos meses, ha habido avances tecnológicos notables en las capas de ejecución, DA y liquidación de la infraestructura de la cadena de bloques, cada capa evolucionando con su propio conjunto de nuevas soluciones. La capa de liquidación, antes dominada por Ethereum, es ahora más competitivamente diversa.

1. Desarrollos en la Capa de Ejecución

El concepto de Parallel EVM, liderado por proyectos como Monad, Sei y MegaETH, destaca como el más innovador en la capa de ejecución. Proyectos existentes como FTM y Canto se están adaptando para abrazar esta dirección innovadora. Sin embargo, es importante tener en cuenta que no todos los proyectos asociados con el Parallel EVM comparten los mismos caminos tecnológicos u objetivos finales.

Por ejemplo, los diagramas de Sei ilustran vívidamente los posibles aumentos de rendimiento que se pueden lograr al pasar de un procesamiento secuencial a uno paralelo en condiciones ideales.

Las tecnologías EVM paralelas se pueden categorizar según su enfoque de paralelización de transacciones:

Los métodos de prevalidación, como los utilizados por Solana y Sui, requieren que las transacciones especifiquen qué partes del estado de la cadena modifican, lo que permite la detección de conflictos en el empaquetado previo al bloque y el descarte de transacciones conflictivas.

Los métodos de post-validación, conocidos como paralelismo optimista y ejemplificados por BlockSTM de Aptos, asumen que no hay conflictos iniciales, procesando las transacciones primero y resolviendo los conflictos detectados posteriormente invalidando transacciones en conflicto y reprocesándolas según sea necesario. Este método también es empleado por Sei, Monad, MegaETH y Canto.

También hay soluciones emergentes diseñadas para manejar conflictos de estado, como los que implican acceso simultáneo al mismo Automated Market Maker (AMM) pool, aunque estas soluciones parecen ser más complejas y su viabilidad comercial sigue bajo evaluación.

Perspectives on Parallel EVM -

Hay dos perspectivas principales sobre la importancia de Parallel EVM:

La primera perspectiva, defendida por proyectos como Monad y Sei, coloca la paralelización de transacciones en la vanguardia de su estrategia de escalabilidad. Monad, por ejemplo, no solo aboga por el procesamiento paralelo optimista, sino que también ha desarrollado herramientas especializadas como MonadDB y E/S asincrónica para apoyar estos esfuerzos.

La segunda perspectiva, representada por Fantom, Solana y MegaETH, ve la paralelización como una de varias estrategias de escalabilidad, no como el único enfoque. Estos proyectos también dependen de otros avances tecnológicos para mejorar el rendimiento.

Por ejemplo, la actualización Sonic de Fantom se centra en su máquina virtual FVM y en un mecanismo de consenso Lachesis mejorado. Las próximas iniciativas de Solana se centran en la arquitectura modular de su cliente Firedancer y en mejoras en las comunicaciones de red y validaciones de firmas.

MegaETH @megaeth_labs tiene como objetivo empujar los límites de las capacidades de Ethereum hacia la consecución de una "Blockchain en Tiempo Real", mejorando varios aspectos como la sincronización de estado, las configuraciones de hardware para Secuenciadores y la estructura de datos del Trie de Merkle, todo con el objetivo de maximizar la eficiencia y velocidad de las operaciones blockchain.

1. Capa de Disponibilidad de Datos (DA)

La capa DA no ha experimentado ninguna iteración tecnológica importante, por lo que el grado de desarrollo aquí no es tan intenso como en la capa de ejecución. Básicamente, solo hay unos pocos actores clave:

La actualización CallData de Ethereum a Blob ha reducido significativamente los costos para varios Layer 2, haciendo que ETH sea una opción "no tan cara" para DA ahora.

El papel principal de Celestia, después de su lanzamiento, fue ser el primer proyecto en introducir el concepto de capa DA. Este proyecto aumentó el techo para la pista DA de $2 mil millones en Valor Total Diluido (FDV) a $20 mil millones, abriendo nuevos marcos y posibilidades imaginativas. Muchas nuevas Appchains de Capa 2 prefieren naturalmente Celestia para su DA.

Avail, que se separó de Polygon, se asemeja técnicamente a una “versión mejorada de Celestia,” como el uso del mecanismo de consenso Grandpa+BABE similar al de Polkadot, teóricamente admitiendo más nodos descentralizados que Tendermint de Celestia. También admite Pruebas de Validez que Celestia no tiene. Por supuesto, las diferencias técnicas no son tan críticas como el desarrollo del ecosistema, y Avail necesita ponerse al día en términos de su ecosistema.

EigenDA también se lanzó junto con la red principal de EigenLayer hace unos días. Con EigenLayer siendo una de las narrativas más fuertes en esta ronda y la mejor en asociaciones comerciales, siento que la tasa de adopción de EigenDA será alta. Teóricamente, siempre y cuando se sienta seguro y el precio sea correcto, a muchos proyectos no les importa si se utiliza Prueba de Validez o Prueba de Fraude, o si se admite DAS, etc.

Vale la pena mencionar las siguientes tres DAs:

• Near DA - Near es una blockchain única originalmente centrada en el particionamiento, y aún lo hace, pero al hacerlo, también desarrolló un DA - más barato que Celestia y compatible con liquidaciones rápidas para L2s. Abstracción de cadena - Recientemente, Near introdujo firmas de cadena, que permiten a los usuarios solicitar firmas de transacción para cualquier blockchain a través de una sola cuenta NEAR; IA - El fundador Illia, uno de los 'ocho hijos de Transformer' que fue palmado en el hombro por Jensen Huang en la conferencia de NVIDIA, ahora planea contratar ingenieros de IA y publicará anuncios relacionados conhttp://near.aiel próximo mes... También lo he colocado en la pista de DA.
• BTC & CKB - Debido a que la primera capa de BTC no admite contratos inteligentes y no puede liquidar directamente, docenas de capas 2 de EVM de BTC están utilizando esencialmente BTC como DA. La diferencia radica en si colocar la Prueba ZK directamente en BTC o solo el hash de la Prueba ZK, ya que de lo contrario se descalificaría como una “BTC Layer 2”. Recientemente me encontré con un nuevo proyecto que dice “Ya no finjo más, soy un ETH L2, los acuerdos se realizan en ETH, ¡pero sirvo al ecosistema BTC!”, lo cual es bastante humorístico... El único esquema de expansión alternativo es RGB++ de CKB, donde CKB se ha convertido en una especie de existencia DA, y BTC, debido a la tecnología de enlace homomórfico UTXO, casi se ha convertido en la capa de liquidación para RGB++.
• Nueva DA - Discute dos nuevas ideas de DA que he visto, sin nombrar los proyectos: una combina DA con IA, no solo sirviendo como un DA de alto rendimiento, sino también actuando como una capa de almacenamiento para datos y trayectorias de entrenamiento de modelos grandes de IA. Otra mejora en el mecanismo de código de corrección de errores subyacente a DAs como Celestia, proporcionando una estabilidad de red más robusta en redes dinámicas (donde algunos nodos se desconectan aleatoriamente cada ronda).

1. Capa de liquidación

Originalmente, esta capa estaba casi exclusivamente dominada por ETH, con DA compitiendo con Celestia, y la ejecución teniendo su gran cantidad de L2s. Solo en la liquidación, otras cadenas como Solana, Aptos, etc., no tienen L2s, y los L2s de BTC no pueden usar BTC para liquidación, por lo que la única capa de liquidación que se puede considerar es esencialmente solo ETH.

Sin embargo, esta situación está a punto de cambiar. He visto varios nuevos proyectos moviéndose en la dirección mencionada al principio del artículo, y algunos proyectos antiguos también están pivotando en esta dirección, es decir, la capa de verificación/liquidación ZK - desglosando aún más ETH (robando el negocio de ETH).

¿Por qué ha surgido este concepto?

Desde un punto de vista técnico, ejecutar contratos en ETH L1 para verificar Pruebas de Conocimiento Cero (ZK Proofs) no es realmente la elección óptima. Para verificar la corrección de ZK Proofs, los desarrolladores necesitan escribir contratos de verificación en Solidity basados en el proyecto ZK y su sistema de Prueba de Conocimiento Cero elegido, lo que implica algoritmos criptográficos complejos como diferentes curvas elípticas. Estos algoritmos suelen ser complejos, y la arquitectura EVM-Solidity no es la plataforma óptima para implementar estos algoritmos criptográficos complejos. Para algunos proyectos ZK, escribir y verificar estos contratos de verificación también resulta costoso.

Esto dificulta en cierta medida la integración nativa de algunos ecosistemas ZK en el ecosistema EVM, por lo que idiomas como Cairo, Noir, Leo y Lurk actualmente solo pueden ser verificados en sus Capas 1. Además, actualizar o mejorar tales cosas en ETH siempre es "difícil darle la vuelta a un gran barco".

Desde una perspectiva de costos, aunque las "tarifas de protección" en L2 representan la mayor parte, la verificación del contrato ZK también requiere tarifas de Gas, y Ethereum ciertamente no es una opción barata para la verificación. Con las tarifas de Gas de ETH que ocasionalmente se disparan, convirtiéndolo en una "cadena noble", el costo de verificación también se ve enormemente afectado.

Así, han aparecido nuevos proyectos conceptuales de capa de verificación/liquidación ZK, aún relativamente tempranos, con Nebra como representante. Los proyectos antiguos también están pivotando en esta dirección, como Mina y la propuesta nueva recientemente aprobada por Zen.

La mayoría de los proyectos en esta pista generalmente tienen como objetivo:

• Soporte para múltiples idiomas ZK.
• Soporte de pruebas ZK agregadas, que son más eficientes y económicas.
• Lograr tiempos de finalidad más rápidos.

Es bastante probable que la capa de liquidación ZK y el mercado descentralizado de Pruebas estén vinculados, ya que tener la tecnología también requiere poder computacional. Podríamos ver algunos proyectos de capa de liquidación cooperar con proyectos de Mercado de Pruebas, capas de liquidación poderosas podrían comenzar sus propios Mercados de Pruebas, o Mercados de Pruebas técnicamente competentes podrían ingresar ellos mismos al campo de la capa de liquidación. En última instancia, el mercado decidirá.

Otras áreas de Infra, como el campo de Oracle y MEV con OEV, y el campo de interoperabilidad con clientes ligeros ZK, están bien cubiertas en artículos en línea, sobre los cuales no me extenderé aquí. La próxima vez que vea algunas cosas nuevas e interesantes, las compartiré con todos.

Renuncia:

1. Este artículo es reimpreso de [GateTwitter], Todos los derechos de autor pertenecen al autor original [@Wuhuoqiu]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen consejo de inversión alguno.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.