La acumulación de deuda técnica, ¿cómo puede Ethereum reconstruir la arquitectura técnica con RISC-V y encontrar una solución?

Escrito por: jaehaerys.eth

Compilado por: Glendon, Techub News

TL;DR

Ethereum está experimentando la transformación arquitectónica más importante desde su creación: reemplazar la Máquina Virtual de Ethereum (EVM) por RISC-V. La razón fundamental que impulsa este cambio es que, en la era de las pruebas de conocimiento cero (ZK), la EVM se ha convertido en el mayor cuello de botella:

El zkEVM actual depende de la ejecución del intérprete, lo que provoca una reducción de velocidad de 50 a 800 veces;

Los contratos precompilados (Precompiles) hacen que el protocolo sea demasiado complejo y aumentan el riesgo;

El diseño de pila de 256 bits es extremadamente ineficiente en la prueba.

RISC-V puede resolver estos problemas:

Minimalismo (aproximadamente 47 comandos básicos) + un ecosistema de LLVM maduro (compatible con Rust, C++, Go);

Se ha convertido en el estándar de zkVM de facto (90% de los proyectos lo adoptan);

La especificación SAIL formalizada (en comparación con el ambiguo libro amarillo) puede soportar una verificación estricta;

La ruta de prueba de hardware (ASIC/FPGA) está en prueba (SP1, Nervos, Cartesi).

La migración se divide en tres fases:

RISC-V como un reemplazo de contrato precompilado (pruebas de bajo riesgo);

Era de las dos máquinas virtuales: EVM + RISC-V tienen completa interoperabilidad;

EVM implementado internamente en RISC-V (similar a la estrategia Rosetta).

Impacto del ecosistema:

Las Optimistic Rollups no se ven afectadas; la mainnet de RISC-V no eliminará las pruebas de fraude, los programas de prueba existentes pueden compilarse para adaptarse a RISC-V (actualmente basado en MIPS); ruta de migración: expandir la infraestructura de tolerancia a fallos actual al RISC-V objetivo, en lugar de una reconstrucción completa;

ZK Rollup se beneficiará enormemente (Polygon, zkSync, Scroll → más barato, más rápido, más simple);

Los desarrolladores pueden usar bibliotecas de Rust/Go/Python directamente en L1;

Los usuarios pueden obtener costos de prueba aproximadamente 100 veces más baratos, avanzando hacia el nivel Gigagas (aproximadamente 10k TPS) en la ruta L1.

Finalmente, Ethereum evolucionará de la «máquina virtual de contratos inteligentes» a una capa de confianza en Internet mínima y verificable, cuyo objetivo último es: «todo será ZK-Snark».

Ethereum se encuentra en una encrucijada

Con el objetivo final de "todo ser ZK-Snark", Ethereum se encuentra ahora en el umbral de la evolución arquitectónica más importante desde su creación. Esta discusión ya no se limita a actualizaciones incrementales, sino que se trata de una reestructuración fundamental de su núcleo computacional, es decir, la alternativa a la Máquina Virtual de Ethereum (EVM). Esta iniciativa es la piedra angular de la más amplia visión de "Ethereum Lean", que busca simplificar sistemáticamente todo el protocolo, dividiéndolo en tres componentes clave: Consenso Lean, Datos Lean y Ejecución Lean. La cuestión central de la Ejecución Lean es: ¿se ha convertido ahora la EVM, como motor de la revolución de los contratos inteligentes, en el principal cuello de botella para el desarrollo futuro de Ethereum?

Como dijo Justin Drake de la Fundación Ethereum, el objetivo a largo plazo de Ethereum siempre ha sido "snarkizar todo", una poderosa herramienta que puede mejorar las diversas capas del protocolo. Pero durante mucho tiempo, este objetivo parecía más bien un "castillo en el aire", porque su realización requería una prueba en tiempo real de este concepto. Sin embargo, hoy en día, a medida que la prueba en tiempo real se convierte gradualmente en una realidad, la ineficiencia teórica de la EVM se ha transformado en un problema práctico que necesita ser abordado.

Este análisis explorará los argumentos técnicos y estratégicos para la migración de Ethereum L1 a la arquitectura de conjunto de instrucciones RISC-V (ISA), una medida que promete liberar una escalabilidad sin precedentes, simplificar la estructura del protocolo y alinear a Ethereum con el futuro de la computación verificable.

¿Qué cambios han ocurrido realmente?

Antes de profundizar en el "por qué", primero es necesario entender "qué" está cambiando.

EVM es el entorno de ejecución de contratos inteligentes de Ethereum, es la "computadora mundial" que maneja transacciones y actualiza el estado de la blockchain. A lo largo de los años, su diseño ha sido revolucionario, creando una plataforma sin permisos y dando lugar a todo un ecosistema de DeFi y NFT. Sin embargo, esta arquitectura personalizada de hace casi diez años ha acumulado una pesada deuda técnica.

En comparación, RISC-V no es un producto, sino un estándar abierto: un "alfabeto" de diseño de procesadores gratuito y universal. Como enfatizó Jeremy Bruestle en la conferencia telefónica de Ethproofs, sus principios clave lo convierten en la opción perfecta para este papel:

Minimalismo: el conjunto de instrucciones básicas es extremadamente simple, con solo alrededor de 40-47 instrucciones. Jeremy lo describe como "casi el caso de uso perfecto para la máquina universal super simplificada que necesitamos".

Modular: Agregar funcionalidades más complejas a través de extensiones opcionales. Esto es crucial, ya que permite un núcleo simple y se puede expandir según sea necesario, sin imponer complejidades innecesarias al protocolo base;

Sistema ecológico abierto: cuenta con un gran y maduro soporte de herramientas, incluyendo el compilador LLVM, que permite a los desarrolladores usar lenguajes populares como Rust, C++ y Go. Como dijo Justin Drake: "Hay muchas herramientas relacionadas con compiladores, y construir un compilador es extremadamente difícil... por lo tanto, tener estas herramientas de compilador tiene un gran valor." RISC-V permite que Ethereum herede gratuitamente estas herramientas ya disponibles.

Problemas de sobrecarga del intérprete

La necesidad de reemplazar EVM no proviene de un único defecto, sino de una serie de limitaciones fundamentales que, en el contexto del futuro nativo de las pruebas de conocimiento cero (ZK), se han vuelto imposibles de ignorar. Estos problemas abarcan graves cuellos de botella de rendimiento en los sistemas de prueba ZK, así como los riesgos derivados de la complejidad que se acumula cada vez más dentro de los protocolos.

Problemas de sobrecosto del intérprete

El impulso más urgente para esta transformación es la ineficiencia inherente de EVM en los sistemas de pruebas de conocimiento cero. A medida que Ethereum avanza gradualmente hacia un modelo que valida el estado de L1 a través de pruebas ZK, el rendimiento del probador se convertirá en el cuello de botella final.

El problema radica en el funcionamiento actual de zkEVM. No realizan pruebas de conocimiento cero directamente sobre EVM, sino que prueban un intérprete de EVM, que a su vez ha sido compilado en RISC-V. Vitalik Buterin señaló de manera incisiva este problema central:

"Si la implementación de zkVM consiste en compilar la ejecución de EVM en contenido que finalmente se convierte en código RISC-V, ¿por qué no abrir directamente el RISC-V subyacente a los desarrolladores de contratos inteligentes? Esto podría eliminar completamente el costo de la máquina virtual externa."

Esta capa de explicación adicional conlleva una gran pérdida de rendimiento. Según estimaciones, en comparación con los programas nativos de prueba, esta capa puede provocar una disminución del rendimiento de entre 50 a 800 veces. Después de optimizar otros cuellos de botella (como al cambiar al algoritmo de hash Poseidon), esta parte de "ejecución de bloques" seguirá consumiendo entre el 80 y el 90% del tiempo de prueba, convirtiendo a EVM en el obstáculo final y más obstinado para escalar L1. Si se elimina esta capa, Vitalik predice que la eficiencia de ejecución podría mejorar hasta 100 veces.

La trampa de deuda de los contratos precompilados

Para abordar el problema del rendimiento insuficiente de EVM en ciertas operaciones criptográficas, Ethereum introdujo contratos precompilados: funciones especializadas codificadas directamente en el protocolo. Aunque esto fue una solución pragmática en su momento, hoy ha llevado a lo que Vitalik Buterin denominó una "situación catastrófica":

"La precompilación es desastrosa para nosotros... ha expandido enormemente el repositorio de código confiable de Ethereum... y en el borde de un fallo de consenso, nos ha hecho estar al borde del colapso en varias ocasiones."

Su complejidad es asombrosa. Vitalik señala, al comparar el código de envoltura de un único contrato precompilado (modexp) con un intérprete RISC-V completo, que la lógica precompilada es en realidad más compleja. La adición de nuevas precompilaciones debe pasar por un proceso de bifurcación dura lento y lleno de luchas políticas, lo que obstaculiza gravemente la innovación de aplicaciones que dependen de nuevos tipos de primitivas criptográficas.

Por lo tanto, Vitalik llegó a una conclusión firme: "En realidad, creo que deberíamos detenernos de inmediato en la creación de cualquier contrato precompilado."

La deuda técnica de la arquitectura de Ethereum

El diseño central de EVM refleja las necesidades de una era pasada, pero ya no se adapta a la computación moderna. EVM eligió una arquitectura de 256 bits para manejar valores criptográficos, lo que resulta en una eficiencia extremadamente baja para los enteros de 32 o 64 bits que se utilizan comúnmente en los contratos inteligentes. Este costo de baja eficiencia es especialmente alto en los sistemas de prueba de conocimiento cero.

Como explicó Vitalik: "Cuando se usan números más pequeños, cada número en realidad no ahorra ningún recurso, y la complejidad aumenta de 2 a 4 veces."

Además, la arquitectura de pila de EVM es menos eficiente que la arquitectura de registros de RISC-V y las CPU modernas. Se requieren más instrucciones para realizar la misma operación, lo que también complica la optimización del compilador.

Estos factores combinados, incluidos los cuellos de botella en el rendimiento de ZK proofs, la complejidad de las precompilaciones y las elecciones arquitectónicas obsoletas, constituyen una razón convincente y urgente para que Ethereum supere la EVM.

RISC-V plano: construir una base más sólida

Las ventajas de RISC-V no solo provienen de las deficiencias de EVM, sino que también radican en sus filosofías de diseño y ventajas inherentes. Su arquitectura proporciona una base robusta, simple y verificable, lo que la hace muy adecuada para entornos de alto riesgo como Ethereum.

¿Por qué los estándares abiertos son mejores que el diseño personalizado?

A diferencia de las arquitecturas de conjunto de instrucciones (ISA) personalizadas que necesitan construir todo el ecosistema de software desde cero, RISC-V es un estándar abierto maduro que puede ofrecer tres ventajas clave:

ecosistema maduro

Al adoptar RISC-V, Ethereum se beneficia de los avances colectivos en el campo de la informática de las últimas décadas. Como explicó Justin Drake, esto proporciona a Ethereum un camino directo para utilizar herramientas de clase mundial: "Hay un componente de infraestructura llamado LLVM, que es un conjunto de herramientas de compilador que permite a los desarrolladores compilar lenguajes de programación de alto nivel en varios backends. RISC-V es uno de los backends compatibles. Así que si apoyas RISC-V, automáticamente puedes soportar todos los lenguajes de alto nivel que LLVM admite."

Esto reduce enormemente la barrera de entrada para millones de desarrolladores familiarizados con lenguajes como Rust, C y Go.

filosofía de diseño minimalista

El minimalismo de RISC-V es una característica intencionada, no una limitación. Su conjunto de instrucciones básico contiene solo alrededor de 47 instrucciones, lo que hace que el núcleo de la máquina virtual sea extremadamente simple. Esta simplicidad es una gran ventaja para la seguridad, ya que una base de código confiable más pequeña es más fácil de auditar y verificar formalmente.

Estándar de hecho en el campo ZK

Lo más importante es que el ecosistema zkVM ha tomado decisiones autónomas. Como enfatizó Justin Drake, se puede ver una clara tendencia en los datos de Ethproofs: "RISC-V es la ISA líder para el backend de zkVM."

En 10 zkVM capaces de probar bloques de Ethereum, 9 han elegido RISC-V como arquitectura objetivo. Esta convergencia del mercado libera una señal poderosa: la adopción de RISC-V por parte de Ethereum no es un intento especulativo, sino que está siguiendo un estándar validado por el mercado.

Diseñado para la confianza, no solo para la ejecución

Además del ecosistema, la arquitectura interna de RISC-V también es especialmente adecuada para construir sistemas seguros y verificables.

Primero, RISC-V tiene una especificación formal y legible por máquina, llamada SAIL. Esto representa una gran mejora con respecto a la especificación de la máquina virtual de Ethereum (EVM), que existe principalmente en forma de documentación (libro amarillo) y puede ser ambigua. La especificación SAIL proporciona un "estándar de oro" que puede ofrecer pruebas matemáticas cruciales para la corrección del protocolo, lo cual es vital para proteger protocolos de gran valor. Como señaló Alex Hicks de la Fundación Ethereum (EF) en la conferencia telefónica de Ethproofs, esto permite que los circuitos zkVM se validen "de acuerdo con la especificación oficial de RISC-V".

En segundo lugar, RISC-V incluye una arquitectura privilegiada, una característica que a menudo se pasa por alto, pero que es crucial para la seguridad. Define diferentes niveles de operación, que incluyen principalmente el modo de usuario (para aplicaciones no confiables, como contratos inteligentes) y el modo de supervisor (para un "núcleo de ejecución" confiable).

En el modelo de RISC-V, los contratos inteligentes que se ejecutan en modo de usuario no pueden acceder directamente al estado de la blockchain. En cambio, deben hacer una solicitud a un núcleo de confianza que se ejecuta en modo de supervisor a través de una instrucción ECALL (llamada de entorno) especial. Este mecanismo construye un límite de seguridad impuesto por hardware, que es más robusto y más fácil de verificar que el modelo de sandbox EVM basado puramente en software.

La visión de Vitalik

Esta transformación se concibe como un proceso gradual y en múltiples etapas, con el fin de asegurar la estabilidad del sistema y la compatibilidad hacia atrás. Este enfoque, esbozado por Vitalik Buterin, busca lograr un desarrollo progresivo en lugar de un cambio revolucionario.

Primer paso: reemplazo de precompilación

En la fase inicial, se adoptará el enfoque más conservador, introduciendo funciones limitadas de la nueva máquina virtual (VM). Como sugirió Vitalik, "podemos comenzar a usar la nueva máquina virtual en escenarios limitados, como reemplazar las funciones precompiladas." Esto implicará pausar las nuevas funciones precompiladas de EVM, reemplazándolas por la implementación de funciones requeridas a través de programas RISC-V aprobados por una lista blanca. Este enfoque permite que la nueva máquina virtual realice pruebas en condiciones reales en la red principal en un entorno de bajo riesgo, mientras que el cliente de Ethereum actúa como intermediario entre los dos entornos de ejecución.

Segundo paso: coexistencia de dos máquinas virtuales

La siguiente etapa abrirá "nuevas máquinas virtuales directamente a los usuarios". Al desplegar contratos inteligentes, se podrá añadir una bandera para indicar si su bytecode es EVM o RISC-V. La característica clave es garantizar una interoperabilidad sin fisuras: "los dos tipos de contratos podrán llamarse entre sí". Esto se logrará a través de llamadas del sistema (ECALL), con el cliente de Ethereum actuando como intermediario del entorno de ejecución.

Paso tres: EVM como contrato simulado (estrategia "Rosetta")

El objetivo final es lograr la simplificación definitiva del protocolo. En esta fase, «implementaremos EVM como una de las implementaciones de la nueva máquina virtual». La EVM estandarizada se convertirá en un contrato inteligente formalmente verificado que se ejecuta en RISC-V L1 nativo. Esto no solo asegura el soporte permanente para aplicaciones heredadas, sino que también permite a los desarrolladores de clientes mantener únicamente un motor de ejecución simplificado.

Reacción en cadena de todo el ecosistema

El plan de transición de EVM a RISC-V va mucho más allá del protocolo central; tendrá un profundo impacto en todo el ecosistema de Ethereum, con la esperanza de remodelar la experiencia de los desarrolladores, cambiar fundamentalmente el panorama competitivo de las soluciones de Layer-2 y abrir nuevos modelos económicos de prueba.

Reestructuración del patrón Rollup: Divergencias de caminos entre Optimistic y ZK

La transición a la capa de ejecución RISC-V en L1 tendrá un impacto radicalmente diferente en los dos tipos principales de Rollups.

Los modelos de seguridad de los Optimistic Rollups (como Arbitrum y Optimism) dependen de la reejecución de transacciones disputadas en Layer-1 para resolver pruebas de fraude. Incluso si Ethereum Layer-1 se migra a RISC-V, estos sistemas no experimentarán cambios fundamentales. Como explicó uno de los cofundadores de Optimism: "Si migramos Ethereum a RISC-V, la cadena Optimistic tampoco se interrumpirá. Solo necesitas compilar la máquina virtual RISC-V en el programa de prueba. No es necesario usar Asterisc. Los sistemas de prueba basados en MIPS existentes tampoco se interrumpirán; solo necesitas compilar la máquina virtual RISC-V en MIPS."

Esto significa que el modelo antifraude sigue intacto. El ajuste es técnico: compilar una nueva máquina virtual RISC-V en la infraestructura existente, en lugar de rediseñar el sistema desde cero. Los desafíos restantes son los detalles de ingeniería, como la medición de Gas, la eficiencia y el costo.

En comparación, los ZK Rollups obtendrán una gran ventaja estratégica. La gran mayoría de los ZK Rollups ya han adoptado RISC-V como su ISA interna. El uso del mismo lenguaje nativo en L1 permite una integración más estrecha y eficiente. Justin Drake describió la visión futura de los "Rollups nativos", donde L2 es esencialmente una instancia especializada del entorno de ejecución de L1, utilizando la VM de L1 incorporada para lograr liquidaciones sin problemas. Esta integración traerá los siguientes cambios:

Simplificación de la pila tecnológica: eliminar el complejo puente entre la ejecución interna de RISC-V en L2 y EVM;

Implementar la reutilización de herramientas y código: los compiladores, depuradores y herramientas de verificación formal desarrollados para el entorno L1 RISC-V pueden ser utilizados directamente por L2 para reducir los costos de desarrollo.

Incentivos económicos coordinados: Las tarifas de Gas de L1 reflejarán de manera más precisa el costo real de la ejecución de pruebas ZK RISC-V, creando así un modelo económico más razonable.

La nueva era de desarrolladores y usuarios

Para los desarrolladores del ecosistema de Ethereum, este cambio será gradual y no disruptivo.

Para los desarrolladores, la ventaja clave radica en su capacidad para ingresar a un mundo de desarrollo de software más amplio y maduro. Como señaló Vitalik Buterin, los desarrolladores "podrán escribir contratos en Rust, y estos dos lenguajes comenzarán a coexistir". Al mismo tiempo, predijo que "Solidity y Vyper continuarán siendo populares durante mucho tiempo", ya que tienen una lógica de contratos inteligentes elegantemente diseñada. La capacidad de utilizar lenguajes de uso general y sus ricas bibliotecas a través de la cadena de herramientas LLVM, será un cambio revolucionario. Vitalik lo describió como una "experiencia similar a Node.JS", en la cual los desarrolladores básicamente pueden usar el mismo lenguaje para escribir código en cadena y fuera de cadena.

Para los usuarios, el retorno final es una red más económica y poderosa. Se espera que el costo de la prueba se reduzca aproximadamente 100 veces, pasando de varios dólares por transacción a unos pocos centavos, lo que se traducirá directamente en menores costos de liquidación en Layer-1 y Layer-2. Esta viabilidad económica abrirá la visión de "Gigagas L1", con el objetivo de lograr un rendimiento de aproximadamente 10000 TPS en L1, apoyando así aplicaciones en cadena más complejas y de mayor valor en el futuro.

Succinct Labs y SP1: demostrar que el futuro está aquí y ahora

Las ventajas teóricas de RISC-V han sido llevadas a la práctica por equipos como Succinct Labs, y sus resultados de trabajo proporcionan un sólido estudio de caso para toda la propuesta.

SP1, desarrollado por Succinct Labs, es una zkVM de alto rendimiento y de código abierto basada en RISC-V, que verifica la viabilidad de un nuevo enfoque arquitectónico. Su diseño se basa en la filosofía de "precompilación centralizada", resolviendo perfectamente el problema del cuello de botella criptográfico del EVM. A diferencia del enfoque tradicional que depende de métodos de precompilación lentos y codificados de forma rígida, SP1 descarga operaciones intensivas como el hash Keccak a través de llamadas estándar de instrucciones ECALL y circuitos ZK diseñados y optimizados manualmente. Esto proporciona tanto el rendimiento del hardware personalizado como la flexibilidad del software.

El impacto práctico del equipo se ha manifestado claramente; su producto OP Succinct utiliza SP1 para lograr la "ZK-ificación" (ZK-ify) del Optimistic Rollup. Como explicó Uma Roy, cofundadora de Succinct:

"Tu OP Stack Rollup no necesita esperar 7 días para completar la confirmación final y el retiro... ahora solo toma 1 hora. Esto mejora drásticamente la velocidad de confirmación final, ¡es increíble!"

Esto resuelve un punto crítico en todo el ecosistema de OP Stack. Además, la infraestructura de Succinct, "Succinct Prover Network", está diseñada como un mercado descentralizado de generación de pruebas, mostrando un modelo económico viable para el futuro de la computación verificable. Su trabajo no es solo una prueba de concepto, sino también un plano viable para el futuro descrito en este documento.

¿Cómo reduce Ethereum el riesgo?

Una de las ventajas clave de RISC-V es que hace que el objetivo último de la verificación formal—demostrar matemáticamente la corrección del sistema—se convierta en un objetivo alcanzable. La especificación de EVM está escrita en lenguaje natural en el Yellow Paper, lo que hace que la formalización sea extremadamente difícil. En cambio, RISC-V cuenta con una especificación oficial y legible por máquina en SAIL, que proporciona una "referencia dorada" clara para su comportamiento.

Esto abre un camino claro hacia una mayor seguridad. Como señaló Alex Hicks de la Fundación Ethereum, actualmente se está trabajando en "extraer circuitos zkVM RISC-V y la especificación oficial RISC-V a Lean para su verificación formal". Este es un avance monumental que transfiere la confianza de implementaciones humanas propensas a errores a pruebas matemáticas verificables, logrando así un avance en términos de seguridad.

Los principales riesgos de la transformación

A pesar de las numerosas ventajas de la arquitectura L1 de RISC-V, también enfrentará nuevos desafíos complejos.

Problemas de medición de Gas: crear un modelo de Gas determinista y justo para el ISA genérico es uno de los problemas más difíciles de resolver. Los métodos simples de conteo de instrucciones son vulnerables a ataques de denegación de servicio. Por ejemplo, un atacante puede diseñar un programa que active repetidamente un programa en caché, logrando una alta ocupación de recursos con un costo de Gas muy bajo.

Problemas de seguridad de la cadena de herramientas y "construcción reproducible": este puede ser el riesgo más importante y subestimado en el proceso de transformación. El modelo de seguridad ha pasado de una máquina virtual de confianza en la cadena a confiar en los compiladores fuera de la cadena utilizados por cada desarrollador (por ejemplo, LLVM), y estos compiladores son extremadamente complejos y se sabe que contienen vulnerabilidades. Los atacantes pueden aprovechar las vulnerabilidades del compilador para convertir código fuente aparentemente inofensivo en bytecode malicioso. Además, garantizar que los binarios compilados en la cadena coincidan exactamente con un código fuente público específico, es decir, el problema de "construcción reproducible", también es muy difícil de lograr, ya que las pequeñas diferencias en el entorno de construcción pueden producir diferentes binarios.

estrategia de mitigación

El camino hacia adelante requiere estrategias de defensa de múltiples niveles.

Lanzamiento por etapas: un plan de transición gradual y multifásico es la principal estrategia de mitigación de riesgos. Al introducir RISC-V primero como una alternativa precompilada y luego desplegarlo en un entorno de doble máquina virtual, la comunidad puede acumular experiencia operativa y construir confianza en un entorno de bajo riesgo antes de que ocurran cambios irreversibles.

Auditoría completa: pruebas difusas y verificación formal. Aunque la verificación formal es el objetivo final, debe ir acompañada de pruebas continuas y de alta intensidad. Como mostró Valentine de Diligence Security en la conferencia telefónica de Ethproofs, su probador difuso Argus ha descubierto 11 vulnerabilidades críticas de solidez e integridad en el zkVM líder. Esto demuestra que incluso los sistemas mejor diseñados pueden tener fallos, y solo a través de pruebas adversariales rigurosas se pueden descubrir.

Estandarización: Para evitar la fragmentación del ecosistema, la comunidad debe adoptar un único perfil RISC-V estandarizado. Lo más probable es que esta combinación sea el ABI compatible con RV64 GC y Linux, ya que esta combinación puede ofrecer el apoyo más amplio de lenguajes y herramientas de uso general, maximizando así las ventajas del nuevo ecosistema.

ETH-1.78%
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
  • Recompensa
  • Comentar
  • Republicar
  • Compartir
Comentar
0/400
Sin comentarios
Opere con criptomonedas en cualquier momento y lugar
qrCode
Escanee para descargar la aplicación Gate
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)