ERC-2981: Profundizando en el Estándar Royalty y Cómo puede ser Correctamente Implementado

Foto por Nenad Novaković en Unsplash

Entendiendo las Regalías NFT

Imagina un mundo donde los creadores se beneficien de sus trabajos luego que estén hechos. Un mundo donde se puedan enfocar únicamente en hacer lo que aman porque reciben los fondos adecuados. Como consumidores, podríamos apoyar a nuestros creadores favoritos. ¡Qué emocionante! Con la tecnología revolucionaria de Ethereum, ahora esto es posible como lo que se conocen como los tokens no fungibles (NFTs). Los NFTs permiten la posibilidad de regalías a los creadores. Con esto, cada vez que hay un intercambio de NFT entre coleccionistas, el creador del NFT mantiene una parte del intercambio monetario. Este concepto ha tomado al mundo por sorpresa porque permite que los creadores tengan fondos contínuos. Así que, ¿cómo se hacen efectivas estas regalías? Profundicemos.

La necesidad del ERC-2981

Al principio, las implementaciones de las regalías sólo existían en el nivel del mercado. Sin embargo, es aparente que esto creó un problema. Cada mercado tiene su propia implementación única de las regalías, que no son fácilmente compatibles o usables por otros mercados. Como resultado, los artistas sólo reciben sus pagos respectivos en un mercado en particular y no en otro. Pronto, se volvió evidente que necesitábamos

”Una manera estandarizada para retirar la información del pago de regalías para los tokens no fungibles (Burkes et al.)”

Aquí entra el ERC-2981: un revolucionario estándar de token que resuelve este problema. En esta exploración, profundizaremos sobre cómo implementar correctamente este estándar para que podamos recompensar a los creadores de NFT entre muchos mercados distintos.

El poder de la Simplicidad del ERC-2981

El ERC-2981 tiene un diseño simple que permite a los demás que construyan sobre este estándar, mejorando mucho más el escenario del NFT.

”Este ERC debería ser considerado como un bloque de construcción mínimo y eficiente con el gas, para que haya más innovación con los pagos de regalías de los NFT (Burkes et al.).”

Además, la simplicidad hace que sea fácil para los mercados de NFT adoptar este estándar y para que los desarrolladores lo incorporen dentro de sus códigos. Este acercamiento estratégico no sólo alienta implementaciones rápidas pero también pone el escenario para un ecosistema de posibilidades creativas que tiene el potencial para revolucionar el mundo de los NFTs.

Especificaciones Técnicas

Ahora, incluso si el diseño simple de este estándar permite la implementación fácil, todavía debemos cumplir con ciertas especificaciones para el cumplimiento:

1. La regalía del estándar ERC-2981 requiere dos funciones: royaltyInfo() y supportsInterface() desde el IERC165, como se ve abajo.

El siguiente código está tomado directamente desde el ERC-2981: NFT Royalty Standard

pragma solidity ^0.6.0;

import "./IERC165.sol";

///
/// @dev Interfaz para el Estándar NFT Royalty 
///

interface IERC2981 is IERC165 {
   /// Los bytes ERC165 para añadir al array de la interfaz, configurado en el contrato progenitor
   /// implementando este estándar

   ///
   /// bytes4(keccak256("royaltyInfo(uint256,uint256)")) == 0x2a55205a
   /// bytes4 private constant _INTERFACE_ID_ERC2981 = 0x2a55205a;
   /// _registerInterface(_INTERFACE_ID_ERC2981);
   /// @notice Llamado con el precio de venta para determinar cuántas regalías
   //  se deben y a quién.
   /// @param _tokenId - el activo NFT consultado para la información de la regalía
   /// @param _salePrice - el precio de venta del activo NFT, especificado por _tokenId
   /// @return receiver - dirección de a quién debería ser enviado el pago de la regalía
   /// @return royaltyAmount - la cantidad de pago de regalías para _salePrice

   function royaltyInfo(
       uint256 _tokenId,
       uint256 _salePrice
   ) external view returns (
       address receiver,
       uint256 royaltyAmount
   );
}

interface IERC165 {

   /// @notice Consulta si un contrato implementa una interfaz
   /// @param interfaceID El identificador de la interfaz, como está especificado en ERC-165
   /// @dev La identificación de la interfaz está especificado en el ERC-165. Esta función
   ///  usa menos de 30.000 gas.
   /// @return `true` si el contrato implementa `interfaceID` e
   ///  `interfaceID` no es 0xffffffff, `false` de otro modo
   function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

1. El royaltyAmount debe ser calculado como un porcentaje en el _salePrice.

2. Ya que este estándar permite el uso de cualquier unidad para intercambiar, el royaltyAmount regresado no debe ser una cantidad fija.

Para profundizar más sobre estas especificaciones, refiérete al EIP.

Implementar el ERC-2981: Un acercamiento Seguro con OpenZeppelin

Por suerte, para los desarrolladores, implementar el estándar de este token es tan fácil como importar el contrato ERC-2981 de OpenZeppelin. Haciendo esto, los desarrolladores están cumpliendo automáticamente con todas las especificaciones necesarias.

Aquí hay un proceso fácil de tres pasos para implementar el estándar de regalías en el contrato inteligente de un NFT ERC-1155 (NOTA, estos pasos también funcionan para el ERC-721):

1. Importa el contrato ERC-2891 de OpenZeppelin y hereda sus funciones con el keyword is

import "@openzeppelin/contracts/token/common/ERC2981.sol";

contract RoyaltyContract is ERC1155, ERC1155Supply, ERC2981 {

1. Llama a la función _setDefaultRoyalty(address receiver, uint96 feeNumerator), heredado desde el contrato ERC-298, en el constructor para configurar la información de la regalía en el despliegue, o crea una función para configurar esta información después.

constructor(
       string memory initialUri,
       uint96 feeNumerator,
       address receiver,
       string memory _name,
       string memory _symbol
       ) ERC1155(initialUri) {
       _setDefaultRoyalty(receiver, feeNumerator);
       name = _name;
       symbol = _symbol;
   }

**//Opcional.  Si implementas esta función, asegúrate que haya control de acceso como onlyOwner**
function setDefaultRoyalty(address _receiver, uint96 _feeNumerator) public onlyOwner {
     _setDefaultRoyalty(_receiver, _feeNumerator);
 }

1. Cuando usas el contrato ERC-2981 de OpenZeppelin mientras también hereda sus contratos ERC-1155 o ERC-721, puede que surja un problema así:

TypeError: Derived contract must override function “supportsInterface.” Two or more base classes define function with same name and parameter types.

Este error surge por el hecho que el ERC-2981 anula la función supportsInterface() y así como los contratos ERC-1155 y ERC-721. La solución es anular la función de nuevo en el contrato inteligente del NFT.

function supportsInterface(bytes4 interfaceId) public view virtual override(ERC1155, ERC2981) returns (bool) {
       return super.supportsInterface(interfaceId);
   }

• La función supportsInterface es anulada, especificando los contratos anulados ERC1155 y ERC2981.
• La llamada super.supportsInterface(interfaceId) asegura que la función trabaje como debería, delegando la implementación en los contratos progenitores.

Si creas un contrato ERC-721, reemplaza ERC-1155 con ERC721.

function supportsInterface(bytes4 interfaceId) public view virtual override(ERC721, ERC2981) returns (bool) {
       return super.supportsInterface(interfaceId);
   }

¡Eso es todo!

Siguiendo estos tres pasos, resultará en un ERC-2981 que cumpla con los NFT. El contrato de abajo en un ejemplo de cómo esto se vería en un contrato inteligente ERC-1155:

// SPDX-License-Identifier: MIT

pragma solidity 0.8.17;
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Supply.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/common/ERC2981.sol";
contract RoyaltyContract is ERC1155, ERC1155Supply, Ownable, ERC2981 {


   string public name;
   string public symbol;
   constructor(
       string memory initialUri,
       uint96 feeNumerator,
       address receiver,
       string memory _name,
       string memory _symbol
       ) ERC1155(initialUri) {
       _setDefaultRoyalty(receiver, feeNumerator);
       name = _name;
       symbol = _symbol;
   }

   function supportsInterface(bytes4 interfaceId) public view virtual override(ERC1155, ERC2981) returns (bool) {
       return super.supportsInterface(interfaceId);
   }
   function setURI(string memory newuri)
       public
    onlyOwner 
   {
       _setURI(newuri);
   }

   function mint(uint256 amount, uint256 tokenId)
       external
       payable
   {
       require(amount > 0, "Must mint at least 1 NFT");
         _mint(msg.sender, tokenId, amount, "");
   }

   function mintBatch(address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data) external {
       _mintBatch(to, ids, amounts, data);
   }
   function _beforeTokenTransfer(
       address operator,
       address from,
       address to,
       uint256[] memory ids,
       uint256[] memory amounts,
       bytes memory data
   )
       internal
       override(ERC1155, ERC1155Supply)
   {
       super._beforeTokenTransfer(operator, from, to, ids, amounts, data);
   }
}

Usando el contrato ERC-2891 de OpenZeppelin, tenemos un acercamiento seguro que cumple con los estándar de regalías del NFT.

Conclusión

El escenario cambiante NFT ha llevado a modelos de negocios revolucionarios como las regalías constantes de NFT. Estas regalías continúan el apoyo de los creadores de todos los tipos, mientras sus creaciones existan en la cadena.

Sin embargo, la distribución de estas regalías fue determinada en el nivel del mercado, lo cual lleva a que haya inconsistencias entre distintos mercados. Consecuentemente, la necesidad del ERC-2981 surgió, lo cual permitió los fondos continuos de estos creadores. Sigamos apoyando el estándar de este token a través de aplicaciones prácticas.

La batalla probada del contrato ERC-2891 de OpenZeppelin hace que sea fácil y confiable. Sobre todo, también contribuye al éxito del estándar de regalías de NFT y lleva a una gran adopción sobre distintos mercados.

Citas

Zack Burks (@vexycats), James Morgan (@jamesmorgan), Blaine Malone (@blmalone), James Seibel (@seibel), “ERC-2981: NFT Royalty Standard”, Ethereum Improvement Proposals, no. 2981, Septiembre 2020. [Serie Online]. Disponible en: https://eips.ethereum.org/EIPS/eip-2981.

Morgan, James. “EIP-2981 - Simple and Effective Royalty Standards for All”. Medium, 9 Dic. 2022, https://medium.com/@james.morgan/eip-2981-simple-and-effective-royalty-standards-for-all-dbd0b761a0f0.

Gracias por tomarte el tiempo para leer este artículo. Cuando implementé personalmente este estándar de este token en mis proyectos, encontré algunos problemas que pude haber resuelto fácilmente si hubiese tenido una fuente confiable para seguir. Si encuentras que esto es valioso, conéctate conmigo en las siguientes plataformas:

• Twitter: @woolcentaur
• GitHub: elkaholic6
• LinkedIn: Wyatt Chamberlin
• Página Web: wyattchamberlin.xyz

Tu engagement y feedback son gratamente apreciados.

Este artículo fue escrito por Wyatt Chamberlin y traducido por Delia Viloria T. Su original se puede leer aquí.

Sería genial escucharte en nuestro Discord, puedes contarnos tus ideas, comentarios, sugerencias y dejarnos saber lo que necesitas.
Si prefieres puedes escribirnos a @web3dev_eshttps://twitter.com/web3dev_es en Twitter.