我在这里跟踪文档:。并有一份巧妙的形式合同:
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
contract NFTA is ERC721, Ownable {
using Counters for Co
测试文件:
const {expect} = require("chai");
const {ethers} = require("hardhat");
describe("NFT Marketplace", function () {
let NFTMarket;
let nftMarket;
let listingPrice;
let contractOwner;
let buyerAddress;
let nftMarketAddress
// returns a BigNumbe
我刚开始踏实,只是对我部署的合同中的一个uint的返回值感到困惑--我写了这样的合同:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
// import ERC721 standard
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
// inherit from the ERC721 library to make it compliant
contract NFT is ERC721URIStor
关于元数据URI扩展,我认为不应该要求每个令牌ID都有一个单独的元数据URI。我认为应该有一个可以从globalTokenURI返回的tokenURI()状态变量。如果知道每个令牌都有相同的令牌URI,那么如果令牌URI曾经被更新过,并且您有1000个令牌,则需要遍历每个令牌并更新令牌URI。如果它们都是一样的,那就没有意义了。我认为应该允许tokenURI()函数接受一个令牌ID,但是如果不需要参数,那么它应该返回一个全局URI。我提议:
function globalTokenURI() public view returns (string) {
return _globalToke
我正在写一份可靠的、聪明的合同,我想决定哪一份
performantsaves is
这是基于NFT市场的。
选项1: Mint 10,000 NFTs to my wallet, and then transfer each NFT to a buyers wallet on purchase
选项2: Mint directly to the buyers wallet on purchase
Assumptions:
现在让我们假设tokenURI是常量的,我们不需要每次在选项2中重建它,因为上传到IPFS的时间可以是大量的。
问题:
造币成本是否比转移成本更高,还是它们是一样的? ef
function _safeMint(address to, uint256 tokenId) internal virtual {
_safeMint(to, tokenId, "");
}
/**
* @dev Same as {xref-ERC721-_safeMint-address-uint256-}[`_safeMint`], with an additional `data` parameter which is
* forwarded in {IERC721Receiver-onERC721Received} to contract recipie