Solana no tiene funciones fallback ni receive
Una transacción en Solana debe especificar de antemano las cuentas que modificará o leerá como parte de la transacción. Si una función “fallback” accede a una cuenta indeterminada, entonces toda la transacción fallará. Esto pondría sobre el usuario la carga de anticipar las cuentas a las que accederá la función fallback. Como resultado, es mucho más simple prohibir directamente este tipo de funciones.
Solana no tiene la noción de una función “view” o “pure”
Una función “view” en Solidity crea la garantía de que el estado no cambiará utilizando dos mecanismos:
- Todas las llamadas externas en una función view son staticcalls (llamadas que se revierten si ocurre un cambio de estado)
- Si el compilador detecta opcodes que cambian el estado, arroja un error
Una función pure lleva esto aún más lejos, ya que el compilador verifica si hay opcodes que visualizan el estado.
Estas restricciones de función ocurren principalmente a nivel del compilador, y Anchor no implementa ninguna de estas comprobaciones del compilador. Anchor no es el único framework para construir programas en Solana. Seahorse es otro. Tal vez aparezca algún otro framework con anotaciones de función que indiquen explícitamente qué pueden y qué no pueden hacer las funciones, pero por ahora podemos confiar en la siguiente garantía: si una cuenta no está incluida en la definición del struct Context, esa función no accederá a esa cuenta.
Esto no significa que no se pueda acceder a la cuenta en absoluto. Por ejemplo, podríamos crear un programa separado para leer una cuenta y, de alguna manera, enviar esos datos a la función en cuestión.
Finalmente, no existe tal cosa como un staticcall en la máquina virtual o el entorno de ejecución (runtime) de Solana.
Las funciones view de todas formas no son necesarias en Solana
Debido a que un programa de Solana puede leer cualquier cuenta que se le pase, puede leer una cuenta que sea propiedad de otro programa.
El programa propietario de la cuenta no necesita implementar una función view para otorgar acceso a otro programa para ver esa cuenta. El cliente de web3 js — u otro programa — puede ver los datos de la cuenta de Solana directamente.
Esto tiene una implicación muy importante:
No es posible utilizar bloqueos de reentrada para defenderse directamente de la reentrada de solo lectura en Solana. El programa debe exponer un flag para que los lectores sepan si los datos son confiables.
La reentrada de solo lectura ocurre cuando un contrato víctima accede a una función view que está mostrando datos manipulados. Esto puede defenderse en Solidity agregando un modificador nonReentrant a la función view. Sin embargo, en Solana no hay forma de evitar que otro programa vea los datos en una cuenta.
Sin embargo, los programas en Solana aún pueden implementar los flags que utilizan las guardas de reentrada. Los programas que consumen la cuenta de otro programa pueden verificar esos flags para ver si la cuenta podría estar actualmente en un estado reentrante y no se debe confiar en ella.
No hay modificadores personalizados en Rust
Los modificadores personalizados como onlyOwner o nonReentrant son una construcción de Solidity, y no una característica disponible en Rust.
Las unidades personalizadas no están disponibles en Rust o Anchor
Debido a que Solidity está entrelazado con Ethereum, tiene palabras clave útiles como ethers o wei para medir Ethereum. Como era de esperar, LAMPORTS_PER_SOL no está definido en Rust, pero de manera un tanto sorprendente, tampoco está definido en el Anchor Rust Framework. Sin embargo, sí está disponible en la biblioteca web3 js de Solana.
De manera similar, Solidity tiene days como un alias conveniente para 84,600 segundos, pero no existe un equivalente en Rust/Anchor.
No existen las funciones “payable” en Solana. Los programas transfieren SOL desde el usuario, los usuarios no transfieren SOL al programa
Este es el tema del próximo tutorial.
Aprende más con RareSkills
Consulta nuestro curso de desarrollo en Solana para el próximo capítulo.
Publicado originalmente el 1 de marzo de 2024