DEV Community: Armando Zlatkowicz

Estructura fundamental de un Smart Contract — Solidity

Armando Zlatkowicz — Wed, 06 Mar 2024 23:12:49 +0000

Un contrato funcional y descriptivo es mucho mejor que uno que solo funciona y no entienden porqué.

En el mundo blockchain, una vez que realizamos una transacción, ésta queda grabada a fuego en la red. No podemos modificarla de ninguna manera. Si bien esto evita cientos de problemas de seguridad y nos garantiza que los datos siempre sean los mismos, a la hora de crear código y documentarlo nos obliga a que el mismo sea lo más descriptivo posible.

Cuando uno quiere realizar un cambio en el código de cualquier otro lenguaje que no trabaje en la blockchain, lo podemos hacer sin problema alguno. Es cuestión de modificar y realizar un commit a nuestro repositorio si es que estamos trabajando con Git. Pero cuando se trata de trabajar con una red inmutable, esto se dificulta.

Por ende, documentar bien nuestros contratos es de vital importancia para los demás desarrolladores, ya que les brinda claridad a la hora de trabajar en una red que no permite margen de error. Veamos como podemos lograr esto en unos simples pasos:

Los comentarios son información valiosa

Si has visto o desarrollado cualquier Smart Contract, sabrás que estos mismos se ven mas o menos de la siguiente manera:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

contract Owner {
    address owner;

    function setOwner() public {
      owner = msg.sender;
  }
}

Ahora, si analizamos este código lo podemos entender fácilmente si tenemos conocimientos básicos de Solidity, pero cuando se trata de documentar nuestro código, este ejemplo está desastroso.

Solidity utiliza un estándar llamado NatSpec (Ethereum Natural Language Specification Format). Hagamos uso de este estándar y reescribamos el código anterior.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

/// @tittle <Título del contrato)
/// @author <Autor del contrato)
/// @notice <Para qué sirve este contrato)

contract Owner {
    address owner;

    /// @dev (Explicar que hace la función)
    function setOwner() public {
      owner = msg.sender;
  }
}

contract OwnerTransfer is Owner {
    /// @inheritdoc (Indica que el contrato hereda la documentación anterior)
    /// @param (Función del parámetro)
    /// @return msg.sender (Para qué sirve el retorno de la función)
    function setNewOwner(address _addr) public returns(address) {
      owner = _addr;
      return owner;
  }
}

Cada comentario tiene su propio contexto, acá te dejo una tabla para saber en que contexto y cuando utilizarlos:

Sigue aprendiendo sobre Solidity.

Si querés profundizar cada vez más sobre Solidity y poder desarrollar código limpio siguiendo las mejores prácticas, en mi perfil tenés más blogs acerca de cómo hacerlo.

Y recuerda: la blockchain es un ecosistema que requiere de conocimiento para utilizarla y no cometer errores graves, ayudémonos compartiendo información entre todos, por más mínima que sea. Todo comienza desde abajo.

📢 Redes sociales: Twitter, LinkdIn, Instagram.

GAS optimization en Solidity ⚡9 Tips para ahorrar

Armando Zlatkowicz — Wed, 06 Mar 2024 23:07:55 +0000

Al ser Ethereum una red con costos variables por transacción, ¡ahorrar la mayor cantidad de gas posible se vuelve algo indispensable! Veamos como podemos ahorrarnos unas monedas:

¿Qué es el GAS y cuál es su costo?

El GAS el que precio que debemos pagar por hacer una transacción en la red. Ya que para realizar las transacciones en la blockchain, se utiliza poder de computo (proveniente de todos los nodos participantes) para que estas puedan llevarse a cabo.

No solo es un costo por transacción, sino que también es la recompensa para aquellos validadores que prestan su computo para que la que red siga funcionando.

Pero cuidado: el costo de las transacciones también depende del contrato al que estemos llamando. Por lo que reducir este costo al mínimo mientras programamos es algo fundamental. Veamos cuales son las técnicas mas eficientes para lograr esto.

1. Memory vs Calldata📂

El lugar donde almacenamos nuestras variables influye directamente en el GAS utilizado, ya que dependiendo de en donde se guarde el dato va a costar más o menos. Entre memory y calldata, lo más económico es calldata.

Esto es gracias a que con memory estamos asignando un lugar en memoria para escribir y luego leer el dato. En cambio, calldata es de solo lectura.

2. Storage declaration

Declarar variables en Solidity no tiene costo, este último solo se empieza a aplicar cuando las inicializamos. Esto significa que la mejor opción es declarar variables e inicializarlas posteriormente. Veamos un ejemplo:

uint256 x = 1000000000000000000;
// Costo de GAS elevado.
uint256 x;

// GAS optimizado.
function totalSupply(uint _supply) public {
  x = _supply;
}

3. Packaging variables📦

Solidity nos da la posibilidad de especificar el tamaño que ocupará nuestra variable en cada stack. Siendo las de mayor tamaño las que más cuestan y más tamaño ocupan. Por lo qué, almacenar pequeños valores en un mismo stack puede ser una práctica prudente para optimizar los costos de escritura:

/* 256 es la capacidad máxima de almacenamiento de un stack. 
Siendo 256 un stack completo. */

uint256 bigVariable = 100000000000000000000000000000000000000000000000000;

/* Estableciendo pequeños valores podemos guardar muchas variables 
en un mismo stack. */

uint8 smallVariable;
uint8 smallVariable2;

4. On-chain vs Off-chain⛓️

Si ya formas parte hace tiempo del ecosistema crypto, seguramente hayas escuchado sobre los oráculos, estos intermediarios para tomar información del mundo real (como el precio del dólar) y trasladarla a la web 3. Siguiendo la lógica de la blockchain, cada vez que consultamos un dato en la misma nos cuesta dinero, entonces: ¿Cómo hacen los oráculos para consultar información constantemente sin pagar?

Esto es gracias a que la información de los oráculos se encuentra Off-chain, es decir, no está en la blockchain como tal, sino que utilizan bases de datos tradicionales. Al tener la información fuera de la cadena, la consulta es gratis. La escritura de la información sí cuesta dinero, ya que se está escribiendo información en la blockchain, pero esta se realiza una única vez.

Por lo tanto, mantener la mayor cantidad de información posible fuera de la cadena es lo más económico, reservando los datos On-chain solo para la información que requiera perdurar en el tiempo y ser accesible.

5. Valores zero0️⃣

En algunos lenguajes de programación es común inicializar variables en 0, pero en Solidity tenemos que tener en cuenta el factor lectura y escritura. Como ya sabemos, la lectura no cuesta dinero, pero la escritura sí. El valor de las variables numéricas en Solidity es 0 por defecto. Por lo tanto, inicializar una variable en 0 no solo es inútil, sino costoso.

// Mucho GAS desperdiciado!
uint256 x = 0;

// GAS optimizado
uint256 x;

6. ¡Usa los Bytes a tu favor!

Las variables de tipo bytes son las más optimizadas en Solidity. Esto gracias a que es un tipo de dato más fácil de leer para la EVM y con un tamaño fijo (van desde bytes1 hasta bytes32).

Intenta utilizar el tipo de dato bytes lo más posible, es más eficiente que un string, ¡mientras más puedas reducir su tamaño (siendo 1 el más barato y 32 el más caro), más GAS vas a ahorrar!

7. Herencia🌱

Al heredar un contrato, evitamos tener que reescribir variables, funciones, eventos, etc. Reutilizar todas estás funciones es de gran ayuda para evitar generar más GAS.

8. Funciones🔎

Tanto la visibilidad como los parámetros de una función pueden afectar su costo de ejecución. Debemos marcar las funciones como “external” lo más posible, ya que es la visibilidad más optimizada en cuanto a uso de GAS. Y también procura reducir la cantidad de parámetros a lo más mínimo posible.

Aunque no lo parezca, las funciones de tipo “payable” son más eficientes que aquellas que no tienen este índice💸. Pero, ¿Por qué pasa esto? Esto sucede gracias a qué al indicar la función como payable, el compilador no verifica a quién enviamos el Ether, reduciendo la cantidad de pasos que realiza para ejecutar la función.

9. Usar Assembly

Incorporado en Solidity y la EVM como tal, podemos utilizar un lenguaje de bajo nivel conocido como Assembly para optimizar al máximo nuestro código. Por acá te dejo un ejemplo:

contract EjemploAssembly {
    // Variables de estado
    uint256 public resultado;

    // Función que realiza la multiplicación y suma de manera más eficiente
    function calcular(uint256 a, uint256 b, uint256 c) public {
        // Código Assembly optimizado
        assembly {
            // Multiplicación: a * b
            let multiplicacion := mul(a, b)

            // Suma: multiplicacion + c
            let suma := add(multiplicacion, c)

            // Se almacena el resultado en la variable de estado
            sstore(result_slot, suma)
        }
    }

    // Definición de la variable de estado para almacenar el resultado
    bytes32 constant result_slot = keccak256("resultado");
}

🛑¡Importante!: si bien Assembly nos ayuda a disminuir el uso de GAS, en algunos casos dificulta la legibilidad del código. Por lo tanto, ¡utilízalo con cuidado y solo en los momentos necesarios!

Conclusión

La optimización del uso del GAS en nuestros contratos es de vital importancia para el desarrollo sostenible de la red. Mientras más optimizados estén nuestros contratos, más fácil y económico será su ejecución, ya que no solo abaratamos costos de envío, sino que también de computo.

Si bien optimizar el GAS es muy importante, no se debe sacrificar funcionabilidad y mantenibilidad en el proceso. 🍁

📢 Redes sociales: Twitter, LinkdIn, Instagram.

Solidity: Bytecode vs ABI — EVM vs VM 🥊.

Armando Zlatkowicz — Sun, 03 Mar 2024 02:55:26 +0000

¿Alguna vez viste un bytecode o un **ABI **y no entendiste nada? ¿Cuál es la diferencia entre ambos? ¿Y que hay de las maquinas virtuales, sirven para lo mismo? Vamos a explicar un poco de estos conceptos, acompáñame:

Bytecode vs ABI

Bytecode

Cuando hacemos deploy de nuestros contratos en la blockchain, nuestro código de Solidity es traducido a un lenguaje que la EVM pueda entender. Si bien Solidity está pensando para ser compatible con la EVM, al compilarse se traduce en una secuencia de números y letras que indican cada función que especificamos en nuestro código. Los bytecode suelen ser extremadamente largos. ¿Pero cómo pueden reemplazar una secuencia de números y letras a todas nuestras funciones en Solidity?.

Esto es gracias a que _Ethereum _implementa algo conocido como los “opcodes”. Estos son conjuntos de 2 caracteres que representan una función. Acá te dejo la primera parte de la tabla de opcodes disponibles:

De esta manera, el compilador traduce todo nuestro código Solidity a bytecode para poder ser ejecutado por la EVM.

Application Binary Interface (ABI)

Si bien estamos explicando los conceptos por separado, estos trabajan en conjunto a la hora de interactuar y deployear nuestros contratos. Siendo el bytecode el qué se envía a la EVM y el ABI el encargado de mostrarnos los métodos y funciones que tiene el contrato para que podamos interactuar con el.

El ABI define los métodos y variables que están disponibles en un Smart Contract y que podemos usar para interactuar con ese contrato. Dado que los Smart Contracts se convierten en bytecode antes de implementarse en la cadena de bloques, el **ABI **nos brinda una forma de saber qué operaciones e interacciones podemos realizar con ellos.

Además, si vemos el formato que posee un ABI, nos daremos cuenta que nos permite leerlo de forma fácil e interactuar con lenguajes más populares, dado a que se compila en formato JSON. Veamos un ejemplo:

[ { "inputs": [], "stateMutability": "nonpayable", "type": "constructor" }, { "inputs": [ { "internalType": "bytes4", "name": "interfaceID", "type": "bytes4" } ], "name": "supportsInterface", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "view", "type": "function" } ]

EVM y VM ¿Cuál es la diferencia?

Pasemos a hablar sobre entornos de ejecución virtuales. Son el paso final para poder utilizar nuestro código.

VM

Las Virtual Machines son entornos de ejecución virtuales, es decir, no poseen un lugar físico. Son emulaciones de hardware en un entorno virtual. Esto sirve para poder generar poder de cómputo y procesamiento sin la necesidad de ocupar espacio físico. Existen muchas VM conocidas, como la JVM, la cuál es el entorno de ejecución de Java. Estos entornos virtuales nos permiten ejecutar software de manera controlada y aislada.

EVM

Una vez compilado y traducido nuestro código, se envía a la Ethereum Virtual Machine para ser ejecutado y poder utilizarlo. La EVM es específica para la plataforma de Ethereum, es descentralizada y vive en cada uno de los nodos que participan de la red. Es gracias a esta máquina virtual que todos nuestros Smart Contracts puede cumplir sus funciones.

En resumen, la EVM es una VM pero específicamente diseñada para la plataforma de Ethereum.

📢 Redes sociales: Twitter, LinkdIn, Instagram, Medium.