Tanto los tokens ERC20 como los ERC721 ofrecen interesantes funcionalidades para la emisión de activos digitales. Pero tienen sus limitaciones que el estándar ERC1155 propone solucionar como un estándar multitoken, más eficiente, rápido y seguro.

Limitaciones de los tokens ERC20 y ERC721#

Por un lado, en el estándar ERC20 pueden ocurrir pérdidas de tokens debido a que si se envía por error los mismos a direcciones inexistentes, estos serán irrecuperables.

Por otro lado, el estándar ERC721 tiene sus problemas de emisión de tokens. Solo se puede emitir y transferir de a un token a la vez. Si queremos transferir 10 tokens, esto representa 10 transacciones y 10 comisiones para la red. Otra limitación muy grande es la falta de posibilidades de obtener el tokenId de un token en particular para identificar el mismo.

Tanto el estándar ERC20 como el ERC721, son incompatibles entre sí. Solo permiten que una colección de tokens viva dentro de un contrato.

Características de los tokens ERC1155#

El estándar ERC1155, propuesto en el EIP1155, define que un contrato inteligente puede tener múltiples tokens a la vez. Los mismos conviven en el mismo contrato y pueden actuar como tokens fungibles o no-fungibles según nuestra necesidad.

Resuelve los problemas de seguridad del estándar ERC20 para evitar la perdida de tokens y se vuelve más amigable con la red que el estándar ERC721 al permitir la emisión y transferencia de muchos tokens a la vez.

Implementación de tokens ERC1155 A lo igual que con el estándar ERC20 y ERC721, OpenZeppelin posee su propia implementación del estándar ERC1155.

Su implementación no deja de ser sencilla. Debemos definir los múltiples tokens que vamos a utilizar con la diferencia de que esta vez, el tokenId no hace referencia a un solo token, sino a toda la colección.

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

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract MultiToken is ERC1155 {
  // Definimos los IDs de cada colección de tokens
  uint256 public constant Fungible = 0;
  uint256 public constant NoFungible = 1;
  uint256 public constant OtroFungible = 2;

  constructor() public ERC1155("URI del proyecto") {
    _mint(msg.sender, Fungible, 1000, "");
    _mint(msg.sender, NoFungible, 1, "");
    _mint(msg.sender, OtroFungible, 5000, "");
  }
}

Al emitir tokens de cada tipo, debemos especificar el ID de la colección que guardamos en variables públicas, la cantidad de emisión de ese token determinará si el mismo es fungible o no, y una metadata opcional que acompaña a los mismos.

También es posible configurar una URI que podría utilizarse para redireccionar a la web oficial del proyecto, donde se dé explicación de la utilidad de cada tipo de token que el contrato posee.

Casos de uso del estándar ERC1155#

La existencia de este estándar, no quiere decir que debamos dejar de implementar los estándares ERC20 y ERC721. Ambos continuarán siendo completamente útiles para determinadas reglas de negocio y son fáciles de emplear.

El estándar ERC1155 permite solucionar casos de uso más avanzados donde múltiples tokens deben trabajar juntos. Los videojuegos “play to earn” utilizan este estándar para crear tokens con valor económico para el intercambio de otros tokens no-fungibles con las características de los personajes del juego. Sin duda, el caso de uso que más provecho sacará de este estándar.

Solo se requiere que la imaginación vuele para encontrar los mejores usos tanto para el estándar ERC1155, como para el ERC20 y ERC721. Saber cuándo aplicar cada uno y desarrollar de la forma más eficiente nuestros contratos inteligentes y resolver variadas reglas de negocio.

Post creado en colaboración con el Curso de OpenZeppelin de Platzi.