Extensión de Funcionalidad en Contratos ERC721 con OpenZeppelin

Curso de Dapps: Introducción al Desarrollo de Aplicaciones Descentralizadas

Contenido del curso

Presentación del proyecto

Arquitectura de DApps

Setup del proyecto

Desarrollo del contrato inteligente

Probando nuestro Smart Contract

Conclusión

24
Desarrollo de Aplicaciones Descentralizadas con Solidity y Node.js
03:17 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0011:04

Extensión de Funcionalidad en Contratos ERC721 con OpenZeppelin

Curso de Dapps: Introducción al Desarrollo de Aplicaciones Descentralizadas

Clase 15 de 24

Clase 15 / 24

Comentarios (24)24 comentarios

Omar Daniel Centeno

Hace 5 años

paco

Hace 5 años

Jean Nuñez

Hace 5 años

José Manuel Piña Rodríguez

Hace 5 años

Daniel Armando Contreras Rodriguez

Hace 5 años

José Manuel Piña Rodríguez

Hace 5 años

Luis Alejandro Vera Hernandez

Hace 5 años

Javier Flores

Hace 5 años

Carlos Daniel Osorio Benavides

Manuel Parra

Damian Spizzirri

Daniel Vaca

Franklin Gil

Jesus Beltran

Jose Luis Gonzalez Tirado

Jean Nuñez

Jean Nuñez

Jean Nuñez

Jean Nuñez

Ramses Colmenares

Guillermo Fragachan

Guillermo Fragachan

Juan Andrés Guillamet Chargué

Hace 4 años

Jose Luis Gonzalez Tirado

Hace 3 años

Andrés Muñoz

Hace 5 años

Favio Ismael Montealegre Covarrubias

Hace un año

Herlin Joan Echeverry

Hace un año

Axel Nicolas Montenegro

Hace 5 años

Arturo Mena

Hace 4 años

Jean Nuñez

Hace 5 años

Recursos

ATENCIÓN ⚠️

¡Hola!, si has llegado hasta aquí te felicito, ya que has comenzado con el trabajo técnico de tu contrato inteligente. No obstante, en esta clase se omitió un paso importante en la función mint, ya que no se añadió el incremento del _tokenId, lo cuál causaría un error después de que se crea el primer token, indicando que ese token ya fue minteado con anterioridad (siempre mintea el token 0).

Para solucionarlo, te pido que añadas la siguiente línea de código después del _safeMint(msg.sender, current):

_tokenId.increment()

Este problema se soluciona en la clase donde agregamos tests, así que no es mayor problema, pero es relevante, por si deseas realizar pruebas desde ahora.

Dale :green_heart: para que más personas se enteren de este cambio :pray

creo que la corrección correcta es

_idCounter.increment()

Buen aporte bro, gracias

++Resolviendo el RETO++: No pude usar de la sección Payment la función PullPayment por que esta hasta la v0.3, así que en la v0.4 está solo PaymentSplitter, aqui va la implementación:

Hacemos la importación:

import "@openzeppelin/contracts/finance/PaymentSplitter.sol";

Agregar la herencia al contracto:

contract PinaPunks is ERC721, ERC721Enumerable, PaymentSplitter { ...

Actualizar el constructor:

    constructor(address[] memory _payees, uint256[] memory  _shares, uint256 _maxSupply) ERC721("PinaPunks", "PP") PaymentSplitter(_payees, _shares) payable {
        maxSupply = _maxSupply;
    }

Note: payess y shares, son dos arreglos, en el primero agregar las wallets que desean recibir la recompensan y la segunda, la equidad de las mismas.

Actualizar la función mint :

    function mint() public payable {
        require(msg.value >= 50000000000000000,"you neet 0.05 ETH to mint the PinaPunks");

Ahora es ++payable++ y le agregue un require para garantizar un monto a al momento de hacer el mint.

Consulta para que se agrega el payable en el mint?

Aparte de esto tambien no habria que agregar los parametros del constructor en el deploy.js?

Excelente pregunta Daniel, se agrega el payable porque ya esta funcion require de un pago para funcionar, en este caso 0.05 ETH al menos, y si, hay que agregar los parametros al constructor en el deploy.js que quedaria asi:

 const deployed = await PinaPunks.deploy(["0x4317c44fD3143D8AC5723865CF046238A2cd8FD3", "0x128b13c88537ea482D318014720dd0De5aC0B22e"], [60, 40], 10000);

Me gusta que el profe nos muestre abiertamente como hace uso de la documentación y de las funciones que nos proveen porque creo yo que a la final eso es de lo mas normal y no que transcriba lo que esta en la documentación haciendo como que se lo sabe y que no lo esta copiando

Dejo mi implementacion. Me estuve peleando mas con el test que con la funcionalidad del contrato 🤦‍♂️ Saludos

contract PlatziPunks is ERC721, ERC721Enumerable{
    using Counters for Counters.Counter;
    uint256 immutable _maxSupply;
    address _owner;

    Counters.Counter private id_counter;

    constructor( uint256 maxSupply ) ERC721("PlatziPunks","PUNKS") {
        _maxSupply = maxSupply;
        _owner = msg.sender;
    }

    function getMaxSupply() public view returns(uint256){
        return _maxSupply;
    }

    function mint() public payable  {
        // pregunto si esta enviando 0.1 eth
        require( msg.value >= 0.1 ether, "Insufficient funds" );

        // me fijo si quedan PUNKS disponibles        
        uint256 current = id_counter.current();
        require( current < _maxSupply, "No PUNKS left");

        // transfiero los ethers
        payable(_owner).transfer( msg.value );

        // envio el NFT
        _safeMint(msg.sender, current);

        // incremento el contador
        id_counter.increment();
    }

    // Override required
    function _beforeTokenTransfer(address from, address to, uint256 tokenId) internal override(ERC721, ERC721Enumerable) {
        super._beforeTokenTransfer(from, to, tokenId);
    }

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

}

Gran ejemplooo

Tener algo de conocimiento en smart contracts y implementar estas funciones con esta clases + Github Copilot una delicia xd

El maxSupply debería ser privado, ¿no?, si no lo cambio y me salteo la validación.

Buena observación, creo que la solución está en declarar la variable maxSupply como IMMUTABLE y esto permite que sea inicializada en el constructor una sola vez y de ahí en adelante ya no pueda ser modificada, incluso esto permite eficiencia en el uso del GAS del contrato. La documentación al respecto: https://docs.soliditylang.org/en/latest/contracts.html#constant-and-immutable-state-variables

requerimos un curso intermedio de solidity porque con el using quede un poco en el aire.

Aca les dejo mi version super optimizada del contrato mostrado en esta clase.

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";

contract PlatziPunks is ERC721Enumerable {
    uint public maxSupply;

    constructor(uint _maxSuppy) ERC721("PlatziPunks", "PLPKS") {
        maxSupply = _maxSuppy;
    }

    function mint() public {
        uint _current = totalSupply();
        require(_current < maxSupply, "No PlatziPunks left :(");
        _safeMint(msg.sender, totalSupply());
    }

}

La optimización del código que proporcionaste parece adecuada y funciona correctamente para su propósito. La eliminación de la importación de Counters.sol y la eliminación del uso de una variable de contador no utilizada son medidas efectivas para simplificar el contrato y reducir el consumo de gas. Además, la eliminación de la función supportsInterface también es apropiada, ya que su implementación predeterminada es suficiente para satisfacer las necesidades del contrato. En general, esta optimización del contrato ERC721 cumple con los estándares de seguridad y funcionalidad esperados. Mil Gracias.....

En openzepelin hay seccion de MIsc y alli hay una seccion de utils, tiene una librerias de contadores

msg.sender -> tiene una direccion de aquel que ejecuta la funcion

con using podemos usar esas librerias

L aimplemtacion de standares es muy facil, solo hay que ver el constructor y ver que requiere

Buen dia, cuando copio el ejemplo me indica un error en OVERRIDE, diciendome que no hay nada que sobre escribit

yo obtengo este error, Derived contract must override function "_beforeTokenTransfer". Two or more base classes define function with same name and parameter types.

en typescript

Te recomiend que pruebes este codigo y revises la documentacion actualizada de openzeppelin

como en el ejemplo

Features : Enumerable

Access control : OWNABLE

function _beforeTokenTransfer(address from, address to, uint256 tokenId, uint256 batchSize)
        internal
        override(ERC721, ERC721Enumerable)
    {
        super._beforeTokenTransfer(from, to, tokenId, batchSize);
    }

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

No se si acá es el contexto de mi duda. Pero cuando importas la librería de open Zeppelin o otra al contrato. Las funciones heredadas quedan todas disponibles public o hay que generar un archivo de interfaces nuevo con las funciones a utilizar.? Perdón si la pregunta es una es muy básica

Ojo nota importante. Ya que el curso tiene mas de un Ano de haber sido publicado, esto es 1 tip sobre todo para los principiantes como yo! al intentar seguir la clase en el minuto 3:15 ; cuando el profesor esta construyendo las funciones con el Wizard actualmente estas cambian:

La diferencia es que las primeras dos funciones no tienen el parámetro "batchSize", mientras que las segundas dos sí lo tienen. Además, las primeras dos funciones llaman a la función "_beforeTokenTransfer" y "supportsInterface" de las clases padre ERC721 y ERC721Enumerable, mientras que las segundas dos funciones llaman a esas mismas funciones, pero también incluyen el parámetro adicional "batchSize" y heredan de las mismas clases padre.

Pero lo importante es que ademas hay que hacer una nueva importacion =

import "@openzeppelin/contracts/access/Ownable.sol";

Las funciones quedarian asi:


   function _beforeTokenTransfer(address from, address to, uint256 tokenId, uint256 batchSize)
        internal
        override(ERC721, ERC721Enumerable)
    {
        super._beforeTokenTransfer(from, to, tokenId, batchSize);
    }

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

Los tests quedarían algo así:

const { expect } = require("chai");
const { ethers } = require("hardhat");

describe("PlatziPunks", function () {
  let platzi_punks;
  beforeEach(async function(){
    const PlatziPunks = await ethers.getContractFactory("PlatziPunks");
    platzi_punks = await PlatziPunks.deploy(2);
    await platzi_punks.deployed();
  })

  it("Should init contract with name and symbol", async function () {
    expect(await platzi_punks.name()).to.equal("PlatziPunks");
    expect(await platzi_punks.symbol()).to.equal("PLPKS");
  });

  describe("When mint a token", async function (){
    let sender;
    beforeEach(async function() {
      [sender] = await ethers.getSigners();
    })

    it("Should increment the balanceof the sender by 1 every mint", async function () {
      expect(await platzi_punks.balanceOf(sender.address)).to.equal(0);
      await platzi_punks.mint()
      await platzi_punks.mint()
      expect(await platzi_punks.balanceOf(sender.address)).to.equal(2);
    });

    it("Should give the ownership of minted tokenId to the sender", async function () {
      await platzi_punks.mint()
      expect(await platzi_punks.ownerOf(0)).to.equal(sender.address);
    });

    it("Should increment tokenId in every mint", async function () {
      await platzi_punks.mint()
      expect(await platzi_punks.ownerOf(0)).to.equal(sender.address);
      await platzi_punks.mint()
      expect(await platzi_punks.ownerOf(1)).to.equal(sender.address);
    });
  }) 

  describe("Token Max supply", async function (){
    it("Should throw an error if minting exceeds the token max supply limit", async function () {
      try {
        await platzi_punks.mint()
        await platzi_punks.mint()
        await platzi_punks.mint()
        expect.fail('should throw a No Platzi Punks left :( error');
      } catch (error) {
        expect(error.message).to.contains('No Platzi Punks left :(');
      }
    });
  }) 
});

Hola! Alguien mas tomando este curso en 2025? tengo bastantes problemas con las dependencias, actualizare en cuanto pueda avanzar!

hola, lo estoy tamando actualmente, pero aqui en platzi nadie ni los profesores ayudan

que tema de vs code usa???

Cómo debería quedar la función mint:

    function mint () public {
        uint256 current = _idCounter.current();
        require(current < maxSupply, "No PlatziPunks left");
        _idCounter.increment();
        _safeMint(msg.sender, current);
    }

//Overrride required son necesarios para este amrt contract

Presentación del proyecto

Desarrollo de Aplicaciones Descentralizadas en Blockchain

Desarrollo de NFTs con Solidity y Contratos Inteligentes

Arquitectura de DApps

Características de Aplicaciones Descentralizadas (dApps)

Componentes Descentralizables en Aplicaciones Descentralizadas

Evaluación de Descentralización en Aplicaciones Blockchain

Autenticación en Aplicaciones Descentralizadas y Firma Digital

Setup del proyecto

Setup de Proyectos Blockchain con Node.js y Yarn

Instalación y configuración de Hard Hat para contratos inteligentes

Compilación y despliegue de contratos inteligentes con Hard Hat

Actualización de Testnets en Ethereum: Goerli y Sepolia

Despliegue de Contratos Inteligentes en Redes de Prueba con Hard Hat

Manejo seguro de llaves privadas en proyectos blockchain con .env

Alternativas a Hard Hat para Desplegar Contratos Inteligentes

Desarrollo del contrato inteligente

Implementación de OpenZeppelin en Smart Contracts Ethereum

Extensión de Funcionalidad en Contratos ERC721 con OpenZeppelin

Funciones de Metadata en NFTs y OpenSepaline

Cálculo y Diseño del ADN en PlatziPong NFTs

Implementación de contratos inteligentes en Solidity para NFTs

Generación de ADN Pseudoaleatorio en Contratos Solidity

Asignación de ADN y URL de imagen en NFTs con Solidity

Probando nuestro Smart Contract

Pruebas de Smart Contracts en Hardhat con Chai y Ethers.js

Despliegue y Verificación de Smart Contracts en Etherscan

Prueba de Contratos Inteligentes en OpenSea Testnet

Conclusión

Desarrollo de Aplicaciones Descentralizadas con Solidity y Node.js

Extensión de Funcionalidad en Contratos ERC721 con OpenZeppelin

Progreso del curso

Presentación del proyecto

Arquitectura de DApps

Setup del proyecto

Desarrollo del contrato inteligente

Probando nuestro Smart Contract

Conclusión

Recursos

Recursos