Para pasar de EVM a SVM (Solana) es necesario comprender varias diferencias clave entre las máquinas virtuales. Este artículo analizará varias de esas diferencias, incluidas cuentas, tarifas, transacciones, contratos (programas) inteligentes y más. También explorará la configuración del desarrollador, incluidas las herramientas y los SDK.
Al final, los desarrolladores tendrán el conocimiento necesario para comenzar su viaje a Solana.
Comprender las diferencias fundamentales
Para empezar, veamos la diferencia más significativa entre EVM y SVM: el diseño del modelo de cuenta.
Modelo de cuenta
A diferencia de Ethereum, Solana fue diseñada para aprovechar múltiples núcleos y admitir transacciones paralelas. Para lograrlo, Solana utiliza un modelo de cuenta.
Una cuenta en Solana es un registro en el libro mayor de Solana que contiene datos (una cuenta de datos) o es un programa ejecutable (un contrato o programa inteligente en Solana).
Al igual que Ethereum, cada cuenta tiene un identificador de dirección. Sin embargo, a diferencia de Ethereum, donde cada contrato inteligente es una cuenta con la lógica de ejecución y el almacenamiento unidos, los contratos inteligentes de Solana no tienen ningún estado. El estado debe pasarse a las cuentas para que se ejecuten.
Veamos un ejemplo de código. En el código de Solidity a continuación, el estado está vinculado al contrato inteligente con la línea int private count = 0.
Con Rust (Solana) hay una estructura dentro del contrato inteligente que indica initialize_counter. Este contador inicial crea una cuenta con un recuento de 0. La cuenta se pasa a este contador para incrementar el recuento. Esto evita que el estado se mantenga dentro del propio contrato inteligente.
Con Solana, los datos se almacenan en cuentas separadas fuera del programa. Para ejecutar la lógica en un programa, pase la cuenta en la que se realizará.
En el caso de este programa de contador, pase una cuenta de contador al programa cuando llame a la función de incremento y el programa luego incrementará el valor en la cuenta de contador.
Beneficios del diseño del modelo de cuenta
Uno de los principales beneficios de este modelo de cuenta es la reutilización del programa.
Con la interfaz ERC20 en Ethereum, cada vez que un desarrollador crea un nuevo token, debe volver a implementar el contrato inteligente ERC20 en Ethereum con sus valores especificados. Esta redistribución supone un coste elevado.
Pero con Solana, no es necesario crear e implementar un nuevo contrato inteligente para crear un nuevo token. En su lugar, cree una nueva cuenta, conocida como cuenta mint, utilizando el programa de tokens de Solana, pasando detalles como la cantidad de tokens, puntos decimales, quién puede acuñar y más.
Y esto se puede hacer simplemente enviando una transacción al Programa de Tokens. Usando la CLI de la biblioteca de programas de Solana, por ejemplo, es solo un comando:
Mercados de tarifas locales
Otro beneficio del modelo de cuenta es que los mercados de tarifas son locales por cuenta.
En Ethereum, los mercados de tarifas son globales. Si una colección de NFT se vuelve viral y todos están acuñando, las tarifas aumentan para todos. Pero en Solana, dado que los mercados de tarifas son locales por cuenta, solo las personas que acuñan esa colección de NFT pagan las tarifas elevadas. Los usuarios que no participan no se ven afectados.
Honorarios
Profundicemos en las tarifas. En Solana, las tarifas se dividen en tres categorías: tarifa base, tarifa de prioridad y alquiler. Veamos cada uno.
La tarifa base se calcula en función del número de firmas en una transacción. Cada firma cuesta 5000 lamports (0,000000001 sol = 1 lamport). Si una transacción tiene 5 firmas, la tarifa base es de 25000 lamports.
La tarifa de prioridad es una tarifa opcional que se puede agregar a una transacción para darle prioridad. Esta tarifa se basa en la cantidad de unidades informáticas utilizadas en la transacción. Al igual que el gas Ethereum, esta tarifa es una medida simple de los recursos informáticos necesarios para la transacción.
La tarifa final, el alquiler, se parece más a un depósito. Cuando los desarrolladores crean cuentas o asignan espacio en la red, deben depositar SOL para que la red conserve su cuenta. El alquiler se calcula en función de la cantidad de bytes almacenados en la red y se cobra una tarifa base adicional por la asignación de espacio.
Actas
En Solana, la ejecución del programa comienza con el envío de una transacción al clúster. Cada transacción en Solana consta de cuatro partes:
Una o más instrucciones. Las instrucciones son la lógica de ejecución más pequeña en Solana. Se pueden considerar como llamadas a funciones en un contrato inteligente de Ethereum. Invocan programas que realizan llamadas al tiempo de ejecución de Solana para actualizar el estado (por ejemplo, llamando al programa de tokens para transferir tokens de una cuenta a otra).
Una variedad de cuentas para leer o escribir
Una o más firmas
Un blockhash o nonce reciente. En lugar de utilizar un nonce incremental como en Ethereum, en Solana se extrae un blockhash reciente del clúster. Con este blockhash, la transacción solo es válida para 150 bloques, lo que evita que las firmas de transacciones de larga duración se ejecuten en una fecha mucho más posterior.
Otra diferencia significativa entre Ethereum y Solana es que con Solana, las transacciones pueden tener múltiples instrucciones (llamadas a funciones en Ethereum). Esto significa que no es necesario crear contratos inteligentes personalizados para encadenar funciones en una sola transacción. Cada instrucción puede ser una llamada de función separada, realizada en orden en la transacción. Las transacciones también son atómicas: si una instrucción falla, toda la transacción fallará.
Limitaciones de transacciones
Al igual que con las limitaciones de gas de Ethereum, existen limitaciones de unidades de cómputo en las transacciones de Solana.
Otras limitaciones incluyen:
Cada cuenta a la que se hace referencia puede tener como máximo 12.000.000 de unidades informáticas utilizadas por bloque.
Las instrucciones solo se pueden llamar a una profundidad de 4 antes de que se revierta la transacción.
grupo de memoria
A diferencia de Ethereum, Solana no tiene mempools. En cambio, los validadores de Solana reenvían todas las transacciones a hasta cuatro líderes en el programa de líderes. No tener un mempool obliga a las transacciones a saltar de un líder a otro hasta que expire el blockhash, pero también reduce la sobrecarga de chismes en todo el clúster.
El entorno de desarrollo de Solana
Ahora veamos algunas de las herramientas de desarrollo de Solana.
Lenguajes de programación
Mientras que Ethereum usa principalmente Solidity para escribir contratos inteligentes, Solana usa Rust. Si pasa de Ethereum, considere el marco Anchor o Neon, los cuales pueden ayudar a los desarrolladores a comenzar más rápido al permitirles construir en Solana utilizando herramientas EVM familiares.
Al igual que Ethereum, existen SDK del lado del cliente disponibles para muchos de los lenguajes de programación más populares, incluidos JavaScript, Python y Java.
Herramientas para desarrolladores
Solana no tiene actualmente un equivalente a Foundry, pero sí un amplio conjunto de herramientas equivalentes a las utilizadas para Solidity.
Para profundizar más, aquí hay una lista más amplia de recursos para desarrolladores.
Creando contratos inteligentes
Al crear programas en Solana (o al migrar contratos inteligentes de Ethereum existentes), existen varias diferencias fundamentales, demasiadas para cubrirlas aquí. Pero veamos algunos de los más comunes:
El mapeo no existe directamente en Solana. En su lugar, utilice direcciones derivadas del programa. Al igual que el mapeo, las direcciones derivadas de programas brindan la posibilidad de crear un mapa desde una clave o cuenta hasta un valor almacenado en la cadena.
En Solana, los programas se pueden actualizar de forma predeterminada. Un contrato inteligente se puede actualizar mediante un simple comando CLI: implementación del programa solana <program_filepath>.
Al escribir un contrato inteligente de solidez, es común buscar msg.sender o tx.origin. No existe ningún equivalente a esto en Solana. Cada transacción puede tener varios firmantes y la persona que envía la transacción no es necesariamente la que la firmó.
Para obtener más información sobre programas y cómo implementarlos, consulte esta guía.
Aprende más
Esas son algunas de las diferencias más críticas entre desarrollar en Ethereum y Solana. Por supuesto, hay mucho más que aprender. ¡Y la mejor manera de comenzar es comenzar de inmediato! Aquí hay algunos recursos para los próximos pasos:
Solana Playground, donde los desarrolladores pueden escribir, crear e implementar programas Solana desde el navegador.
Una introducción al desarrollo de Solana utilizando Solana Playground
Una mirada más detallada a las diferencias entre desarrollar en Ethereum y Solana
El campo de entrenamiento de Solana
