¿Es Solana compatible con EVM? SVM vs EVM
Solana is not natively EVM compatible. Learn how Neon EVM enables Solidity on Solana, key differences between SVM and EVM, and which path is right for...
Nota de precisión: El rendimiento de la red, el recuento de validadores, las tarifas, las características del protocolo, el soporte de billeteras y las integraciones de terceros cambian con el tiempo. Trate las cifras fechadas como instantáneas históricas y verifique la documentación actual de las fuentes primarias.
¿Es Solana compatible con EVM de forma nativa? No: Solana utiliza la SVM y un modelo de cuenta y ejecución diferente. Los entornos de terceros pueden proporcionar una compatibilidad parcial con EVM, pero su arquitectura, estado y soporte de herramientas deben evaluarse por separado.
Solana no es nativamente compatible con EVM. Utiliza la Máquina Virtual Solana (SVM) y un modelo de ejecución diferente. Los programas de Solana se escriben comúnmente en Rust, con cadenas de herramientas compatibles adicionales, en lugar de desplegarse como código de bytes nativo de la EVM. Neon EVM es un entorno de ejecución de EVM de terceros asociado con Solana, no un soporte nativo de la SVM y no simplemente un puente de tokens.
¿Es Solana compatible con EVM? La respuesta corta
Solana es una blockchain de capa 1 de alto rendimiento, lo que significa que es una red de capa base que procesa y finaliza las transacciones de forma independiente. No utiliza la Máquina Virtual Ethereum (EVM). En su lugar, Solana construyó su propio tiempo de ejecución desde cero, y esa diferencia arquitectónica es la razón por la que los contratos inteligentes de Ethereum no pueden ejecutarse en Solana de forma nativa.
Para los usuarios que preguntan si su billetera Ethereum funciona en Solana, si las aplicaciones descentralizadas de Ethereum (dApps, aplicaciones de software que se ejecutan en una blockchain en lugar de en un servidor centralizado) pueden trasladarse a Solana, o si los desarrolladores de Solidity necesitan volver a aprender todo: las dos redes están arquitectónicamente separadas. Existe una compatibilidad parcial a través de Neon EVM, y el resto de este artículo explica qué significa eso en la práctica.
¿Qué es la Máquina Virtual Ethereum (EVM)?
La Máquina Virtual Ethereum (EVM) es el motor de computación que procesa y ejecuta el código de los contratos inteligentes en la red Ethereum. Los contratos inteligentes son programas de ejecución automática almacenados en una blockchain que aplican automáticamente reglas predefinidas cuando se cumplen las condiciones. La EVM lee el código de bytes (bytecode) al que se compilan esos contratos y ejecuta las instrucciones.
Piense en la EVM como un sistema operativo específico. Cualquier ordenador que ejecute ese sistema operativo puede ejecutar el mismo software. Las Blockchain que adoptan el estándar EVM pueden ejecutar el mismo código de contrato inteligente y admitir las mismas herramientas de desarrollo que Ethereum, sin que el desarrollador tenga que reescribir nada. Esto es lo que significa la compatibilidad con EVM en el mundo cripto en la práctica: portabilidad de código y herramientas entre cadenas.
¿Qué significa ser compatible con EVM?
Una blockchain es compatible con EVM cuando puede ejecutar código de bytes compilado en Solidity y admitir la cadena de herramientas de desarrollo estándar de Ethereum. En términos concretos, los contratos de Solidity se despliegan sin modificaciones, y herramientas como MetaMask (billetera), Hardhat (entorno de desarrollo), Truffle (suite de despliegue), Foundry (entorno de pruebas) y Ethers.js (biblioteca front-end) funcionan sin cambios significativos. La cuestión de la compatibilidad con EVM es fundamental para la forma en que los desarrolladores de Web3 eligen en qué blockchain construir, porque determina si el código y las habilidades existentes se transfieren directamente.
Las cadenas que son compatibles con EVM incluyen a la propia Ethereum (la cadena de origen), la C-Chain de Avalanche, BNB Chain (anteriormente Binance Smart Chain), Polygon y redes de capa 2 como Arbitrum y Optimism. Cada una adoptó el estándar EVM, lo que significa que un desarrollador de Solidity puede realizar despliegues en cualquiera de ellas con una fricción mínima. Solana no adoptó este estándar.
¿Es Solana nativamente compatible con EVM? La respuesta completa
Solana no admite de forma nativa la Máquina Virtual Ethereum. Utiliza un entorno de ejecución diferente, por lo que el código de bytes de la EVM requiere una capa de compatibilidad o un entorno de ejecución independiente. Se trata de una distinción arquitectónica más que de un ajuste que falte.
El lenguaje de desarrollo nativo de Solana es Rust, un lenguaje de programación a nivel de sistema elegido por su rendimiento y sus características de seguridad de memoria. Rust no es exclusivo de Solana; se utiliza ampliamente en la programación de sistemas y en contextos de WebAssembly. Lo que Ethereum llama contratos inteligentes, Solana lo llama programas, y esos programas se escriben principalmente en Rust, con C y C++ como alternativas. El código de bytes de la EVM escrito para Ethereum no se ejecuta en Solana de forma nativa.
Por qué Solana no ejecuta la EVM de forma nativa
Los fundadores de Solana construyeron su propia máquina virtual, la Máquina Virtual Solana (SVM), también llamada tiempo de ejecución Sealevel, para lograr el procesamiento paralelo de transacciones. La EVM procesa las transacciones de forma secuencial, una por una. El tiempo de ejecución Sealevel de Solana procesa múltiples transacciones simultáneamente, lo que constituye una fuente fundamental de su ventaja de rendimiento (throughput). Este modelo paralelo requería una base arquitectónica diferente a la que proporciona la EVM. En resumen: la SVM utiliza programas basados en Rust y un modelo de cuentas independiente; la EVM utiliza contratos de Solidity con el estado almacenado dentro de cada contrato. Estas diferencias de diseño se exploran en detalle en la tabla comparativa que figura a continuación.
Solana logra su alto rendimiento a través de Proof of History (PoH), un mecanismo de cronometraje distinto tanto de la Prueba de Trabajo (Proof of Work) como de la Prueba de Participación (Proof of Stake). PoH permite a los validadores acordar el orden de las transacciones sin una coordinación constante, y el diseño es arquitectónicamente incompatible con el modelo de consenso de Ethereum.
Para los usuarios de billeteras: el soporte de MetaMask y Solana ha cambiado con el tiempo. Verifique el soporte nativo actual o basado en extensiones directamente desde MetaMask y distinga una cuenta de Solana de una conexión RPC de Neon EVM.
Cómo Neon EVM proporciona un entorno EVM independiente
Neon EVM es un entorno de ejecución de EVM de terceros asociado con Solana. Puede admitir contratos de Solidity y partes de la cadena de herramientas de Ethereum, pero el estado actual del despliegue, la arquitectura, la compatibilidad, los costes y las limitaciones deben verificarse de forma independiente. No es un soporte nativo de EVM en la SVM.
¿Qué es Neon EVM?
Neon EVM es desarrollado y mantenido por Neon Labs, una empresa independiente. No es un producto oficial de la Fundación Solana. Neon Labs construyó Neon EVM como una plataforma de contratos inteligentes desplegada sobre Solana que presenta una interfaz compatible con EVM a los desarrolladores. Internamente, intercepta las transacciones en formato Ethereum, las envuelve en estructuras de transacciones compatibles con Solana y dirige la ejecución a través de la capa de consenso y tiempo de ejecución de Solana. Desde la perspectiva del desarrollador, la interfaz se parece a cualquier otro entorno EVM. La computación real ocurre en Solana.
Esta arquitectura crea un entorno EVM distinto en lugar de convertir la SVM en una EVM. El puenteo de tokens (bridging), la representación de activos y la ejecución de contratos son cuestiones separadas y no deben confundirse.
¿Qué herramientas de desarrollo de Ethereum funcionan con Neon EVM?
El borrador de la fuente enumera las siguientes herramientas de Ethereum como compatibles con Neon EVM. Verifique las versiones actuales y las limitaciones antes de confiar en cualquier elemento:
- MetaMask: conectividad de billetera a través del endpoint RPC de Neon EVM
- Hardhat: entorno de compilación y despliegue de contratos
- Truffle: suite de desarrollo y pruebas
- Foundry: entorno de pruebas de contratos inteligentes
- Ethers.js y Web3.js: integración de bibliotecas front-end
El flujo de trabajo de despliegue refleja el despliegue estándar de la EVM: Solidity se compila en código de bytes de la EVM, que luego Neon EVM procesa en la red Solana. El código front-end que utiliza Ethers.js o Web3.js debería funcionar con cambios mínimos, aunque los desarrolladores deberían realizar pruebas para detectar diferencias de comportamiento en casos extremos, ya que no se garantiza la paridad total con la EVM nativa.
¿Cómo se debe evaluar la preparación de Neon EVM?
El borrador de origen describe un despliegue en Mainnet, pero la preparación para producción no puede inferirse solo del estado del despliegue. Revise la actividad actual, los lanzamientos, el historial de incidentes, las auditorías, las dependencias del operador, la disponibilidad de RPC, las versiones de las herramientas, las comisiones y las diferencias de comportamiento antes de comprometer sistemas de producción.
Neon EVM también evoluciona independientemente del protocolo principal de Solana. Los desarrolladores deben verificar las capacidades actuales, las versiones de herramientas compatibles y las limitaciones conocidas en la documentación oficial de Neon EVM antes de comprometerse con un despliegue de producción. Los equipos deben realizar su propia diligencia debida en devnet antes de entrar en funcionamiento.
Solana Virtual Machine (SVM) vs. Máquina Virtual Ethereum (EVM): Diferencias clave
La SVM de Solana y la EVM de Ethereum difieren fundamentalmente en cómo procesan las transacciones. La SVM ejecuta múltiples transacciones en paralelo a través de su modelo de ejecución Sealevel, mientras que la EVM procesa las transacciones secuencialmente, una a la vez. Esta única diferencia arquitectónica explica la mayor parte de la brecha de rendimiento entre las dos redes.
Para los desarrolladores, la diferencia de lenguaje de programación es el punto de fricción más inmediato. Los programas de Solana se escriben en Rust (o C y C++), mientras que los contratos inteligentes de Ethereum se escriben en Solidity. Rust ofrece garantías de seguridad de memoria y ventajas de rendimiento, pero su curva de aprendizaje es más pronunciada que la de Solidity, particularmente para los desarrolladores que provienen de entornos EVM con mucho JavaScript y TypeScript. Solidity, a su vez, tiene una biblioteca más grande de contratos auditados y una mayor familiaridad entre los desarrolladores en la Web3.
La siguiente tabla compara los dos entornos de ejecución a través de las dimensiones que más importan a los desarrolladores y equipos de producto que evalúan qué camino tomar. Para los detalles de la arquitectura de Solana, la documentación oficial de Solana es la fuente de autoridad.
| Atributo | Solana SVM | Ethereum EVM |
|---|---|---|
| Lenguaje principal de contratos inteligentes | Rust (también C, C++) | Solidity |
| Terminología de contratos inteligentes | Programas | Contratos inteligentes |
| Modelo de ejecución | Paralelo (entorno de ejecución Sealevel) | Secuencial |
| Modelo de almacenamiento de estado | Estructuras de cuentas separadas (programas sin estado) | Almacenamiento interno del contrato |
| Rendimiento aprox. | Los hitos teóricos históricos citan ~65.000 TPS; los resultados reales varían | Las estimaciones históricas de la capa base citan ~15–30 TPS; la ejecución en L2 difiere |
| Modelo de comisión de transacción | Comisiones base y de prioridad opcionales; el coste varía | Comisiones de gas variables; los modelos de comisiones en L2 difieren |
| Soporte de bytecode de EVM | No (parcial a través de Neon EVM) | Sí (nativo) |
| Herramientas clave para desarrolladores | Anchor, Solana CLI, conjunto de herramientas de Rust | MetaMask, Hardhat, Truffle, Foundry, Ethers.js |
| Soporte nativo de billetera | Phantom, Solflare | MetaMask, WalletConnect |
Las cifras de TPS son aproximadas y pueden variar según las condiciones de la red y la metodología de medición. Neon EVM cambia el panorama práctico del soporte de bytecode de EVM sin que los programas nativos de SVM sean compatibles con EVM; consulte la sección anterior.
Nota sobre las comisiones: Solana utiliza un modelo de comisiones diferente al sistema de gas de Ethereum. Referirse a las comisiones de transacción de Solana como "comisiones de gas" introduce un marco de Ethereum que no se aplica; las comisiones de Solana se calculan de forma diferente y suelen ser una fracción de céntimo por transacción.
Cómo se compara Solana con las blockchains compatibles con EVM
La arquitectura no EVM de Solana la sitúa en una categoría distinta de las alternativas compatibles con EVM como la C-Chain de Avalanche, la BNB Chain y Polygon. Cada cadena realiza diferentes concesiones entre la familiaridad del desarrollador, el rendimiento bruto y la madurez del ecosistema. Ninguna cadena es óptima para todos los casos de uso; la elección correcta depende de lo que más necesite un equipo.
La siguiente tabla muestra dónde se sitúa Solana en relación con las principales cadenas compatibles con EVM.
| Cadena | ¿Compatible con EVM? | Lenguaje nativo | TPS aprox. | Diferenciador clave |
|---|---|---|---|---|
| Solana | Parcial (a través de Neon EVM) | Rust | Los hitos teóricos históricos citan ~65.000 | Ejecución paralela de SVM; las cifras reales varían según la metodología |
| Ethereum | Sí (cadena de origen) | Solidity | ~15–30 | El mayor ecosistema de desarrolladores y DeFi TVL |
| Avalanche C-Chain | Sí | Solidity | ~4.500 | L1 de alto rendimiento compatible con EVM |
| BNB Chain | Sí | Solidity | ~2.000 | Comisiones bajas; gran base de usuarios minoristas |
| Polygon (PoS) | Sí | Solidity | ~7.000 | Cadena lateral de Ethereum; bajo coste de despliegue |
Las cifras de TPS son aproximadas y pueden variar según las condiciones de la red y la metodología de medición.
Para los desarrolladores que eligen entre Solana y las cadenas compatibles con EVM, la compensación principal es clara: las cadenas compatibles con EVM como Avalanche C-Chain, BNB Chain y Polygon ofrecen a los equipos de Solidity un entorno familiar con una fricción mínima de incorporación, mientras que Solana ofrece ventajas de rendimiento y comisiones más bajas a cambio de aprender Rust o pasar por Neon EVM. Para los equipos interesados en cómo encaja específicamente la BNB Chain en un flujo de trabajo de MetaMask, la guía sobre cómo añadir la BNB Chain a MetaMask) cubre esa configuración en detalle.
La arquitectura no EVM de Solana no ha impedido que construya un ecosistema sustancial de desarrolladores nativos y finanzas descentralizadas (DeFi). Solana alberga protocolos de exchange descentralizado (DEX) activos, incluidos Jupiter y Raydium, junto con agregadores de liquidez como Orca, todos construidos de forma nativa en la SVM y operando independientemente de la infraestructura DeFi basada en EVM. Las cadenas compatibles con EVM han atraído a grandes comunidades de desarrolladores de Solidity debido a la transferencia de herramientas con poca fricción, pero Solana ha aumentado su propia base de desarrolladores a través de las ventajas de rendimiento que permite su arquitectura.
¿Debería construir en Solana o en una cadena EVM? Un marco de decisión para desarrolladores
La elección entre Neon EVM y el desarrollo nativo en Solana, o elegir directamente una cadena compatible con EVM, depende de tres factores: las habilidades lingüísticas existentes de su equipo, sus requisitos de rendimiento y cuánto riesgo técnico puede absorber de una dependencia de un tercero. La siguiente tabla mapea los criterios clave a través de los dos caminos de Solana.
| Criterio | Camino Neon EVM | Camino nativo de Solana |
|---|---|---|
| Requisito de lenguaje | Solidity (no se necesita un lenguaje nuevo) | Rust (inversión significativa en aprendizaje) |
| Tiempo para el primer despliegue | Rápido (el conjunto de herramientas existente funciona) | Más lento (nuevo conjunto de herramientas y modelo mental) |
| Techo de rendimiento | Limitado por la sobrecarga de abstracción | Rendimiento total de Solana |
| Dependencia de compatibilidad con terceros | Sí | No hay una capa EVM separada; aún depende del protocolo y las herramientas de Solana |
| Compatibilidad con herramientas EVM | Total (MetaMask, Hardhat, Ethers.js) | Ninguna de forma nativa |
| Integración en el ecosistema | Parcial (entorno Neon EVM) | Total (ecosistema de dApps nativo de Solana) |
| Ajuste potencial | Equipos de Solidity; lanzamientos con tiempo limitado | Inversión a largo plazo en Solana; aplicaciones críticas para el rendimiento |
Tres escenarios cubren a la mayoría de los equipos que evalúan Solana:
Escenario 1: Su equipo conoce Solidity y está evaluando un camino de migración más rápido. Compare Neon EVM con las L2 de EVM y una reescritura nativa en SVM antes de seleccionar una arquitectura. Sus contratos existentes, el flujo de despliegue y la configuración de la billetera se transfieren con cambios mínimos. La compensación es aceptar la sobrecarga de abstracción de Neon EVM y la dependencia de un protocolo de un tercero que evoluciona independientemente del núcleo de Solana.
Escenario 2: Su equipo está evaluando el desarrollo nativo en SVM. Compare los conjuntos de herramientas compatibles de Solana, el modelo de cuentas, los recursos de auditoría, los requisitos operativos y las dependencias del marco de trabajo. Anchor es un ejemplo de marco de trabajo en lugar de un requisito universal.
Escenario 3: Sus requisitos exigen un entorno EVM nativo. Compare las redes EVM y las L2 por compatibilidad, supuestos de seguridad, liquidación, costes, operaciones y soporte del ecosistema. Ninguna red o ruta de migración está libre de riesgos.
Guía de decisión rápida:
- ¿Conoces Solidity? Evalúa la compatibilidad de terceros, las capas 2 de EVM y una reescritura nativa en SVM frente a los mismos requisitos.
- ¿Estás evaluando el desarrollo nativo en SVM? Compara los lenguajes actuales, los marcos de trabajo (frameworks) y las herramientas de auditoría.
- ¿Necesitas una EVM nativa? Compara las redes EVM actuales y las capas 2 utilizando los mismos requisitos.
Independientemente de la ruta, realiza pruebas exhaustivas en la devnet de Solana antes de cualquier despliegue en Mainnet. Para la ruta de Neon EVM, verifica la compatibilidad actual de las herramientas en neonevm.org antes de comprometerte con una arquitectura de producción.
Preguntas frecuentes: Solana y la compatibilidad con EVM
¿Es Solana compatible con EVM?
Solana no es compatible de forma nativa con EVM. Utiliza la SVM y un modelo de cuenta y ejecución diferente. Neon EVM aparece aquí como un entorno EVM de un Tercero; no hace que la propia SVM sea compatible con EVM. Verifica sus capacidades actuales antes de confiar en el soporte específico de Solidity o de herramientas.
¿Se puede usar MetaMask en Solana?
El soporte de MetaMask y Solana ha cambiado con el tiempo. Verifica el soporte nativo actual o basado en extensiones directamente desde MetaMask y distingue una cuenta de Solana de una conexión RPC de Neon EVM.
Solana utiliza la Máquina Virtual Solana (SVM), también llamada entorno de ejecución Sealevel. La SVM es arquitectónicamente distinta e incompatible con la Máquina Virtual Ethereum (EVM). Su principal ventaja de diseño es el procesamiento paralelo de transacciones: la SVM ejecuta múltiples transacciones simultáneamente, mientras que la EVM las procesa una a una. Este modelo paralelo es una fuente fundamental de la ventaja de rendimiento de Solana sobre la Mainnet de Ethereum.
¿Cuál es la diferencia entre EVM y SVM?
La EVM procesa las transacciones de forma secuencial, utiliza Solidity como lenguaje principal y almacena el estado del contrato dentro de cada contrato. La SVM procesa las transacciones en paralelo a través de su entorno de ejecución Sealevel, utiliza Rust como lenguaje nativo y separa los datos en estructuras de cuentas distintas. Los dos entornos de ejecución utilizan modelos de cuenta, lenguajes de programación y ecosistemas de herramientas incompatibles.
Los puntos de referencia históricos citan una cifra teórica de Solana cercana a los 65,000 TPS, mientras que las estimaciones comúnmente citadas para la Mainnet de Ethereum son mucho más bajas. Estas cifras no son mediciones en tiempo real comparables: las definiciones de transacción, la carga de trabajo, el tráfico de votos, el procesamiento por lotes, la capa de ejecución y el umbral de finalidad son factores determinantes. Las redes de capa 2 de Ethereum deben evaluarse por separado cuando un equipo necesita tanto rendimiento como herramientas de Solidity.
Las principales blockchains compatibles con EVM incluyen Ethereum (la cadena de origen), BNB Chain (anteriormente Binance Smart Chain), Avalanche C-Chain, Polygon (PoS), Arbitrum y Optimism. Todas estas cadenas admiten contratos de Solidity y el conjunto de herramientas estándar para desarrolladores de Ethereum sin modificaciones. Solana no es compatible de forma nativa con EVM; utiliza la SVM. La compatibilidad parcial con EVM en Solana está disponible a través de Neon EVM, desarrollado por Neon Labs.
El código de bytes (bytecode) de EVM compilado con Solidity no se ejecuta de forma nativa en la SVM. Una capa de ejecución de EVM separada puede admitir contratos de Solidity, mientras que los programas nativos de Solana utilizan cadenas de herramientas compatibles con SVM. Verifica el soporte actual de lenguajes y marcos de trabajo en lugar de tratar un entorno de Tercero como el único camino posible.
Neon EVM es desarrollado y mantenido por Neon Labs, una empresa independiente, no por la Fundación Solana. Opera como una capa de compatibilidad sobre la red de Solana, permitiendo a los desarrolladores desplegar contratos de Solidity y usar herramientas como MetaMask y Hardhat sin aprender Rust. Funciona envolviendo las transacciones con formato Ethereum en estructuras compatibles con Solana y dirigiéndolas a través de la capa de consenso de Solana. Verifica las capacidades actuales en neonevm.org.
Solana se diseñó desde cero con su propia máquina virtual, optimizada para el procesamiento paralelo de transacciones y un alto rendimiento. Lograr esos objetivos de rendimiento requirió elecciones arquitectónicas fundamentalmente incompatibles con el modelo de ejecución secuencial de la EVM. Los fundadores de Solana eligieron la optimización del rendimiento por encima de la compatibilidad con EVM como una decisión de diseño deliberada. La SVM y el entorno de ejecución Sealevel reflejan esa prioridad, no una deficiencia en la Plataforma.
Solana ofrece comisiones de transacción más bajas y una finalidad más rápida, lo que beneficia a los protocolos DeFi que requieren transacciones de alta frecuencia. Ethereum tiene el valor total bloqueado (TVL) de DeFi más grande, los protocolos más probados y la Liquidez más profunda en todo su ecosistema. La compatibilidad con EVM facilita la portabilidad de los protocolos DeFi nativos de Ethereum a otras cadenas EVM. Cada red sirve a diferentes casos de uso de DeFi; la elección correcta depende de los requisitos específicos de un protocolo.
Los lectores pueden revisar la información actual del mercado de SOL o el mercado Spot SOL/USDT.). Estos enlaces proporcionan acceso al mercado y no demuestran que Solana, un monedero o un protocolo de Tercero sean adecuados para cada lector.
Conclusiones clave: Solana y la compatibilidad con EVM
Aquí están los cinco hechos más importantes sobre el estado de compatibilidad con EVM de Solana:
- Solana no es compatible de forma nativa con EVM. Utiliza la Máquina Virtual Solana (SVM), no la Máquina Virtual Ethereum (EVM).
- Rust es el lenguaje de desarrollo nativo más común en Solana. El código de bytes de EVM no se ejecuta en la SVM sin una capa de ejecución compatible con EVM independiente.
- Neon EVM, desarrollado por Neon Labs, proporciona compatibilidad parcial con EVM en Solana. Es una capa de Tercero, no un producto oficial de la Fundación Solana. Admite herramientas como MetaMask y Hardhat, junto con Truffle, Foundry, Ethers.js y Web3.js.
- El soporte de MetaMask y Solana ha cambiado con el tiempo. Verifica el soporte nativo actual o basado en extensiones directamente desde MetaMask y distingue una cuenta de Solana de una conexión RPC de Neon EVM.
- La arquitectura no EVM de Solana es un compromiso de rendimiento deliberado. El modelo de ejecución paralela de la SVM le da a Solana su ventaja de rendimiento sobre las cadenas EVM.
Los ecosistemas de Solana y Neon EVM evolucionan rápidamente. Verifica las capacidades actuales en la documentación oficial de Neon EVM y la documentación oficial de Solana antes de tomar decisiones sobre infraestructura.
Guías relacionadas de EVM
- Trading de Ethereum para principiantes: contratos de ETH
- Cómo añadir BNB Chain a MetaMask y usarla de forma segura