I know the nft is minting through a smart contract into the blockchain. But where is the owner wallet stored? and also changing the owner requires additionl smart contract?
Owner address of each token is stored in its collection contract.
The ERC-721 standard only defines that the owner should be retrievable by calling the ownerOf() function, passing it the token ID as the only argument. It doesn't define how exactly the information should be stored.
But many implementations use a mapping. For example the OpenZeppelin implementation:
mapping(uint256 => address) private _owners;
function ownerOf(uint256 tokenId) public view virtual override returns (address) {
address owner = _owners[tokenId];
require(owner != address(0), "ERC721: owner query for nonexistent token");
return owner;
}
changing the owner requires additionl smart contract?
Assuming the collection contract follows the standard, it's able to change the token owner (i.e. transfer the token) by executing any of the transfer functions from the owner's (non-contract) address.
So it doesn't require an additional smart contract to transfer a token.
Related
What I see in several smart contracts, written with solidity, is that a public function is written whose job is just calling another function, which is private or internal.
Here is an example from erc20burnable.sol
In this function _burn is internal, but burn is public.
`
function burn(uint256 amount) public virtual {
_burn(_msgSender(), amount);
}
`
or here is another one in erc1155.sol
`
function safeBatchTransferFrom(
address from,
address to,
uint256[] memory ids,
uint256[] memory amounts,
bytes memory data
) public virtual override {
require(
from == _msgSender() || isApprovedForAll(from, _msgSender()),
"ERC1155: caller is not token owner or approved"
);
_safeBatchTransferFrom(from, to, ids, amounts, data);
}
`
What is the benefit of this structure? why it is common in smart contracts?
Thanks.
One reason for this, I guess, is this way we will be able to override parents, or add modifiers, etc.
It's a common practice used in other OOP languages as well.
One of the reasons is code reusability. If the same snippet (e.g. decrease balance of one address, increase balance of other address, and emit an event) is used in multiple methods (e.g. both transfer() and transferFrom()), you can bundle them into one private function (e.g. _transfer()). And then call this private function from both public functions. When you need to make a change in the code logic, you'll be able to make it in just one place instead of having to search for multiple places and leaving some out by mistake.
Other common reason - you already answered it yourself. This approach allows you to allow the user to specify only some params - for example the amount. But the user cannot specify from which address are the tokens going to be burned - it's always from their address. Even though the private function _burn() allows to specify the burner, the user is not allowed to specify it.
Source code:
/**
* #dev See {IERC721-safeTransferFrom}.
*/
function safeTransferFrom(
address from,
address to,
uint256 tokenId
) public virtual override {
safeTransferFrom(from, to, tokenId, "");
}
/**
* #dev See {IERC721-safeTransferFrom}.
*/
function safeTransferFrom(
address from,
address to,
uint256 tokenId,
bytes memory data
) public virtual override {
require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner or approved");
_safeTransfer(from, to, tokenId, data);
}
Hi everyone.
While reading the Openzeppelin ERC-721 source code, I found that it defined two safeTransferFrom method with different implementations.
I am curious why it's made in this way. Could anyone help me with it?
Many thanks.
It follows the ERC-721 standard that also defines two functions with the same name - but with different input params. Generally in OOP, this is called function overloading.
As you can see in the OpenZeppelin implementation, when you call the function without the data param, it passes an empty value.
I can't speak for the authors of the standard, but to me it seems like a more developer friendly approach compared to having to explicitly pass the empty value, since Solidity doesn't allow specifying a default param value.
I know what they are but I don't quite understand the raw fundamentals of how they're expressed, recorded, and sent on the blockchain.
If tokens are just smart contracts, then how do you send them exactly? How do those token transactions get recorded on the blockchain? What are the raw fundamentals of how a token is created from a smart contract?
Token balance of an address is recorded on the token contract. A token contract is considered a contract that meets all criteria required by the ERC-20 standard, such as implementing the specified interface and emitting events when required by the standard.
Balances are mostly stored in the form of a mapping where the key is the holder address, and the value is the amount of tokens they own, because it's convenient for most cases. However the standard does not specify and particular way so if it suits your needs, you can store the balances in an array, or any other way.
Token transfer is an interaction with the token contract transfer() function (standardized in ERC-20), which should perform validations (my example skips that for simplicity), update the local variables storing balances, and emit the (again standardized) Transfer event.
Offchain apps, such as Etherscan, can listen to these events and update their own database of token holders. This allows them to filter all tokens by an address in their own database and show them on the website. But again, this is not part of the blockchain data, it's an aggregated database built on top of blockchain.
Example: Address 0x123 owns 1 USDT and 2 DAI. The USDT balance is stored in the USDT contract, and the DAI balance is stored in the DAI contract. There's no global property of the 0x123 address keeping track of its tokens.
contract USDT {
// for the key `0x123`, the value is 1 (and decimals)
mapping (address => uint256) balances;
event Transfer(address indexed from, address indexed to, uint256 amount);
function transfer(address to, uint256 amount) public {
balances[msg.sender] -= amount;
balances[to] += amount;
emit Transfer(msg.sender, to, amount);
}
}
contract DAI {
// for the key `0x123`, the value is 2 (and decimals)
mapping (address => uint256) balances;
}
For a full code example, see the OpenZeppelin implementation, and their docs related to this specific implementation. Just to clarify, OpenZeppelin is an organization that publishes open source code, but you can also build your own implementation of the standard or use another one, if that fits your use case.
I've read here that it is possible to mint 2^256 nfts in a single transaction. I've tried to achieve this by directly assigning _owners and _balances mappings but ofc these are private variables so i can't change them. I tried making an _mint() override but that also didn't work. How does this process work?
For simplification, let's do a 10k NFTs scenario.
It's not about invoking a single mint() function 10k times, rather than building your contract logic in a way that allows setting up a range of valid IDs.
Using the MFS part of IPFS, you can upload multiple files into a folder using the same directory ID and actual file names. Example:
https://ipfs.io/ipfs/<dir_id_abc>/1.json
https://ipfs.io/ipfs/<dir_id_abc>/2.json
https://ipfs.io/ipfs/<dir_id_abc>/3.json
etc...
These metadata files contain links to the images.
Your contract can then implement a custom function that shadows an authorized address as an owner of the NFT if both following conditions are met:
The ID is in a valid range (in our case 1-10k)
The NFT is not owned by anybody else (i.e. it's owned by the default address 0x0)
function _exists(uint256 tokenId) override internal view returns (bool) {
if (tokenId >= 1 && tokenId <= 10000) {
return true;
}
return super._exists(tokenId);
}
function ownerOf(uint256 tokenId) override public view returns (address) {
address owner = _owners[tokenId];
// The ID is in a valid range (in our case 1-10k)
// The NFT is not owned by anybody else (i.e. it's owned by the default address 0x0)
if (tokenId >= 1 && tokenId <= 10000 && owner == address(0x0)) {
// shadows an authorized address as an owner
return address(0x123);
}
return super.ownerOf(tokenId);
}
The tokenURI() function then validates the token existence (using the _exists() function) and returns the final URI concatenated from the base URI (https://ipfs.io/ipfs/<dir_id_abc>/), the ID, and the .json suffix.
Mind that this approach does not work on the OpenZeppelin implementation, as their _owners property is private and not readable from child contracts. But you can take this snippet as an inspiration for a custom implementation that allows simulating an arbitrary default owner of 10k (or even 2^256) tokens.
Tbh I don't know how that could be possible without paying ungodly amounts of gas. Why are you trying to mint that many tokens? Are you trying to get all the NFTs in a collection? If so, you'll have to pay the gas costs for every mint regardless.
I wanted to create a smart contract that only interacts with a specific NFT. I know there is a "tokenID" attribute I don't think this is unique. Cronoscan shows multiple collections that have the same tokenIDs. Does anyone know if smart contracts can filter based on a contract address? I'd like to accomplish this with as little gas as possible.
Sorry if this is a basic question but I've Googled and searched this message board for the answer but was not able to find on other that someone trying to sell their service.
I Google and search Stack Overflow but could not find an answer.
Yes, each contract will have their own set of ids and therefore they are not unique between contracts only unique for each contract.
This checks if the code size for the address is > 0. This will have to be implemented on a new contract or you will have to find an existing contract with this functionality to view/execute it
function isContract(address addressValue) public view returns (bool) {
uint size;
assembly { size := extcodesize(addressValue) }
return size > 0;
}
Also notice this is a view function and for that reason wont cost any gas to execute.
In regards to someone selling it as a service, you can get it yourself by just deploying this contract on whatever main net you want (by the sounds of it Cronos).
'// SPDX-License-Identifier: MIT
pragma solidity 0.8.7;
contract ContractIdentifier{
function isContract(address addressValue) public view returns (bool) {
uint size;
assembly { size := extcodesize(addressValue) }
return size > 0;
}
}