Entendiendo los contratos inteligentes | ERC-20

7 min readMay 31, 2021

Esta es la continuación de los conceptos básicos de Ethereum y los smart contracts, si aún no has visto la primera parte, la puedes leer aquí.

En esta parte vamos a desarrollar nuestro propio token ERC-20 como también entenderemos que son los EIPs y cómo estos documentos guían el desarrollo de Ethereum y su ecosistema.

EIPs

EIP, acrónimo de Ethereum Improvement Proposal. En la practica, no es más que un issue en el repositorio de ethereum/EIPs, en donde se discute sobre algún nuevo feature, proceso, entre otros. Es importante recalcar el trabajo de la comunidad en afinar los detalles del proposal original así como también en la aceptación o rechazo de este. Además, hay un claro paralelo e inspiración en cómo se fue desarrollando internet, tal como lo demuestra el EIP-16, cuando se concibe el concepto de los ERC (Ethereum Request for Comments).

EIPs famosos son EIP-1, en donde se explica que son los EIPs (un poco recursivo), EIP-20 o más conocido como ERC-20 , el estándar de tokens como Tether USD (USDT), Uniswap (UNI) o incluso la memecoin SHIBA INU (SHIB), también EIP-721 o ERC-721, el estándar de las famosas NFT (esos memes que se terminan vendiendo por millones de dólares).

Para ver una lista de completa de los EIPS separados por etapa en que están puedes acceder aquí.

OpenZepellin

Si nos damos cuenta, los EIPs como el EIP-20 solo tienen especificaciones de lo que debe tener un token ERC-20 pero no la implementación propia de este.

Existen repositorios que implementan contratos de tokens como ConsenSys/tokens (DEPRECADO) o @openzeppelin/contracts, donde el último ha sido aceptado casi como un estándar para la comunidad.

Fun fact: El founder de OpenZepellin (Zepellin Solutions) es de nacionalidad argentina 🙌.

Dentro de @openzeppelin/contracts podemos encontrar utilidades cómo SafeMath (revierte si hay errores en la matemática), Ownable (permite ser el dueño de un contrato, y usar el modifier ownerOnly), y algunos ERCs.

Para desarrollar nuestro propio ERC-20, usaremos SafeMath, Ownable y obviamente ERC-20, pero antes de ir al código, tenemos que crear nuestro ambiente de desarrollo.

Remix

Remix es un IDE en browser que tiene todo lo necesario para partir desarrollando y probando smart contracts, es parte de los proyectos oficiales Ethereum y puedes ver su código fuente.

Dentro de este IDE, podremos escribir, compilar y hasta desplegar los contratos

Vamos a la carpeta contracts, eliminaremos todos los archivos y crearemos un nuevo contrato vacío

Vamos a compilar este contrato vacío, para esto nos cambiamos al tab marcado en la siguiente imagen, aquí podremos elegir la versión del compilador, permitir optimizaciones, entre otras opciones. Es importante anotar qué opciones se usaron para compilar, ya que en un futuro las necesitaremos para verificar nuestro contrato. Finalmente compilaremos el archivo que tiene nuestro contrato con el botón marcado.

Una vez compilado, nos aparecerá un ticket representando que la última versión de nuestro contrato está compilada (si hacemos algún cambio, veremos que el ícono cambia).

Ahora iremos al tab de DEPLOY & RUN TRANSACTIONS, aquí hay varias cosas que aclarar,

ENVIRONMENT : nos permite desplegar el contrato en Javascript VM (sandboxed, se reinicia cada vez que refrescas la página), injected Web3 (en la red que tengas configurado tu Metamask o simil) o Web3 provider (conecta a la red en que esté ese provider).
ACCOUNT : la cuenta con la cual vas a desplegar el contrato
GAS LIMIT : el limite de gas que estas dispuesto a gastar (recuerda que también debes definir el precio del gas). Es importante que pongas este limite con holgura, ya que si no se despliega el contrato porque llegó al limite de gas, perderás el gas utilizado y no desplegaras el contrato.
VALUE : es la cantidad de ether (en WEI) enviada a algún método de algún contrato. Está cantidad se refleja como msg.value dentro del contrato.
CONTRACT : es el contrato ya compilado a desplegar.

Para desplegar, simplemente presionamos el botón “deploy” y ya podremos interactuar con nuestro contrato.

Podemos notar que hay un icono para ver los métodos y campos públicos del contrato. Como nuestro contrato está vacío no podremos ver nada pero este ejercicio nos sirve para conocer el flujo desde código hasta despliegue. Además, podremos encontrar el icono para copiar la dirección del contrato.

Añadiendo funcionalidad

Para no reinventar la rueda, usaremos el contrato ERC20 de OpenZepellin

contrato con mint ilimitado

Los argumentos de ERC20 son el nombre (name) de nuestro token y su símbolo (symbol), tal como Tether USD es el name y USDT el symbol.

Además, por defecto nuestro token va a usar 18 decimales tal como ETH, es decir, 10¹⁸ recién equivale a 1 MPC. Esta complejidad se debe a que Solidity solo trabaja con números enteros, por lo que para representar decimales se debe trabajar con números grandes y luego decirle a quien lea el contrato cómo debe representar el token.

Tanto name, symbol y decimals no son requeridos por ERC-20 por lo cual no se debe escribir contratos que dependan de estos campos, pero en la práctica se espera que sí estén implementados.

ERC20 es agnóstico a la forma en que se “mintean” (crean) nuevos tokens, aquí es donde somos nosotros quienes implementamos la lógica que se adapte a nuestra necesidad.

En este caso, hicimos que cada vez que un usuario ejecute el método mint, se le dé 1 MPC (nuevamente, recordar los decimals).

Dado que nuestro token tiene 18 decimales, cada vez que alguien ejecute el método mint, obtendrá 1 MPC.

Extendiendo ERC20

En la documentación actual de ERC20 se encuentran 4 extensiones estables disponibles:

Como ejercicio, vamos a extender MediumPostCoin con Burnable y Capped.

Capped significa que existirá un limite de monedas máximas existentes. De esta manera, creamos escasez virtual (similar a bitcoin con su máximo de 21 millones).

Mientras que Burnable significa, a grosso modo, que se pueden destruir/quemar monedas (se agregan los métodos burn y burnFrom).

Como podemos notar, MediumPostCoin ahora es ERC20Burnable y ERC20Capped (podríamos haber agregado ERC20 también pero es redundante). Aparte, en el constructor debemos pasar la cantidad máxima de nuestra moneda (su cap), en este caso estoy usando 2 monedas (recordemos nuevamente que tiene 18 decimales).

Por último, debemos hacer un override al método _mint, ya que tanto ERC20Burnable como ERC20Capped tienen una versión de este, creando el famoso problema del diamante. En pocas palabras, debemos elegir con cuál de las versiones quedarnos.

Finalmente, vamos a agregar una condición al método mint para que cada dirección pueda mintear sola una vez.

Para lograr esto, es tan fácil como crear un registro que por cada dirección (address) nos dé un booleano (si ya ha minteado o no). Usamos require para verificar que este registro todavía no sea true, luego actualizamos al valor y minteamos las nuevas monedas.

Mint con condición

Experimento

Como experimento social, he desplegado nuestra MediumPostCoin en BSC (la cual es compatible con Ethereum) con un cap de 200 MPC, a un costo de 0.008594 en gas.

En la dirección 0xeE52fD37456b502fDEC83be6fAB1167094b6De7C puedes encontrar nuestra MediumPostCoin o verla en bscscan.

Puedes reclamar tu MCP gratis y jugar con ella, además puedes intercambiarla en pancakeswap (exchange descentralizado).

Conclusión

Hemos desarrollado nuestro propio ERC-20 con 2 extensiones y gracias al trabajo de la comunidad, podemos tener un contrato que en termino de código escrito por nosotros es corto y ha sido probado en cientos de otros proyectos.

Además, podemos usar otros proyectos del ecosistema (como pancakeswap) para potenciar nuestro token.

En el próximo artículo veremos cómo hacer un NFT y cómo crear un frontend en React para poder interactuar con este!