What is the point of inheriting from ERC271 contract? - solidity

I have just started Solidity. For this question, I think it's useful if I first state my understanding of inheritance: If Contract B inherits from Contract A (ie. in contractB.sol we have
contract B is A {...
}
then Contract B will have access to functions from contract A.
Also, from my understanding, if I want to use some functions from another contract by someone else, I would have the following in my code:
contract someoneElsesInterface {
function someFunction() returns(something) }
contract myContract {
someoneElsesInterface someoneElsesContract = someonElsesInterface(address);
value = someoneElsesContract.someFunction();
}
My confusion arises when trying to implement the ERC721 standard. First, I must save the erc721.sol file in my directory; the file contains
contract ERC721 {
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
function balanceOf(address _owner) external view returns (uint256);
function ownerOf(uint256 _tokenId) external view returns (address);
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;
}
And then in a separate file, I must inherit from the ERC721 contract and then define the content of the four functions balanceOf, ownerOf, transferFrom, approve; as well as emitting the Transfer and Approve events. So the following:
contract myContract is ERC721 {
function balanceOf...
function ownerOf...
function transferrFrom...
...
}
This is what I don't understand: Why is ERC721 not inheriting from myContract, since we are defining functions in myContract and just stating the function name and returns in ERC721 like my example above? What even is the point of the ERC721 contract and having myContract inherit from ERC721, when we already defined all the function content in myContract? When working from on the front end, do I call the functions from myContract or from ERC721?
I hope my question is clear, if not I can clarify in comments. Thank you in advance for the replies.

First of all, you don't inherit an interface, but you implement it. In an interface contract, you don't define, you declare. You declare functionality, inputs, and outputs.
An interface can't inherit from a concrete (actual) contract. Only interfaces can inherit each other. If you think about it, concrete contracts contain more information than interfaces, how can an interface inherit from a concrete contract?
Generally speaking interfaces are contracts between user and program, and this is also true for Solidity. They guarantee a certain functionality to users. By implementing ERC721, you are declaring that your contract is ERC721 compatible. Because of this, the user does not need to know about your contract's implementation details, instead, they can call your contract using the ERC721 interface.
Consider following:
ContractA { ... }
vs
ContractB is ERC721 { ... }
Let's say both contracts are implementing ERC721 functionality.
To be able to call ContractA for ERC721 interaction, I have to import its ABI and verify that it is compatible. For example, I would call it like:
ContractA(ADDRESS_OF_CONTRACT_A).safeTransferFrom(...)
On the other hand to call ContractB, only thing I need is ERC721 ABI, I don't need to know about ContractB. So I can do:
ERC721(ADDRESS_OF_CONTRACT_B).safeTransferFrom(...)
Before I end, I would like to emphasize that your question is not actually about Solidity or smart contracts, but it is about object-oriented programming, inheritance, and interfaces. I recommend you to read about it more to have a better understanding of the concept.

Related

i am unable to use _totalSupply and _balances any private data type in OpenZeppelin and shows Undeclared identifier in solidity

Hey i am unable to implement _totalSupply and _balances in Remix but able to use remaining functions like name() and decimal() and symbol()
this is my code
pragma solidity ^0.8.0;
import "#openzeppelin/contracts/token/ERC20/ERC20.sol";
contract METoken is ERC20 {
constructor(uint256 initialSupply) ERC20 ("MAstering ther","MET")
{
_totalSupply=initialSupply;
_balances[msg.sender] = initialSupply;
emit Transfer(address(0), msg.sender, initialSupply);
}
}
i am using ERC20 and i have seen from ERC20.sol file from Github that there are _totalSupply and other variables to use the totalSupply() method but i am not able to use them plz help!
In the OpenZeppelin ERC20 implementation, that you're importing to your contract, properties _totalSupply and _balances have the private visibility.
From the Solidity docs page:
Private state variables are like internal ones but they are not visible in derived contracts.
So these specific properties (with private visibility) are not visible in your contract that derives from the contract that declares them.
Solution: The parent contract defines the _mint() function that effectively increases the balance of a selected address, the total supply, as well as emits the Transfer event.
constructor(uint256 initialSupply) ERC20 ("MAstering ther","MET")
{
// increases `msg.sender`'s balance, total supply, and emits the `Transfer` event
_mint(msg.sender, initialSupply);
}

Read contract variable with only interface definition

I'm playing ethernaut Level 3, the original contract is here: https://ethernaut.openzeppelin.com/level/0x4dF32584890A0026e56f7535d0f2C6486753624f
When consecutiveWins is bigger or equal to 10, the player wins:
// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;
import '#openzeppelin/contracts/math/SafeMath.sol';
contract CoinFlip {
using SafeMath for uint256;
uint256 public consecutiveWins;
...
}
Now I want to read the consecutiveWins value in my contract, so I defined an interface:
interface CoinFlip {
uint256 public consecutiveWins;
function flip(bool _guess) external returns (bool);
}
But it is not allowed to have a variable in an interface, what should I do?
Solidity compiler will automatically generate getter functions for public variables, so what you need is replacing consecutiveWins variable in your interface with a getter function like this:
function consecutiveWins() public view returns (uint256);
You can read more about it in Solidity docs here.

Lock transfer of erc721 NFT

Hi all I am building a blockchain-based game around an NFT project and am looking to understand if it's possible to implement the following.
Have a method on the NFT contract that when called can locks the transfer of all minted NFT's for a period. A bit like a game of tag than when your tag the contract all the (NFT / players) cant (move /transfer)
I assume I would need overide the transfer method then do a boolean check.
Something like
function safeTransferFrom(
address from,
address to,
uint256 tokenId
) public virtual override {
if(!isLocked){
safeTransferFrom(from, to, tokenId, "");
}
}
Will this work as I expect and is there any issues with this and would override the transfer method especially around security etc.
Sorry for such a broad question
Thanks
From the context, it seems like you're using the OpenZeppelin implementation. If that's the case, you can override their _beforeTokenTransfer() function, which is effectively called from all functions performing token transfer (as there is multiple of them).
pragma solidity ^0.8;
import "#openzeppelin/contracts/token/ERC721/ERC721.sol";
contract MyCollection is ERC721 {
constructor() ERC721("MyCollection", "MyC") {
_mint(msg.sender, 1);
}
// needs to be unlocked for the `_mint()` function in constructor
bool locked = false;
function setLocked(bool _locked) external {
locked = _locked;
}
function _beforeTokenTransfer(
address from,
address to,
uint256 tokenId
) internal override {
require(!locked, "Cannot transfer - currently locked");
}
}
If you're using other or custom implementation, or chose to only override the publicly visible functions, make sure that there is no other public or external function allowing the transfer without the lock mechanism.
Also few notes to your current code:
You probably won't need the virtual keyword. It allows the function to be further overridden. Unless you're expecting to override this function as well, you can safely remove the keyword.
You're calling the parent function with the same name but different argument set. If you wanted to call the parent function with the same name and the same argument set (assuming it's defined), you'd need to use the super keyword (same as in Java): super.safeTransferFrom(from, to, tokenId);

Why does Solidity suggest me to implement a receive ether function when I have a fallback function?

The recent change in Solidity changed the fallback function format from just function() to fallback(), which is pretty nice for beginners to understand what is going on, but I have a question about a suggestion that the compiler gives me when I implement such a fallback.
For example, a piece of code from my project:
pragma solidity ^0.6.1;
contract payment{
mapping(address => uint) _balance;
fallback() payable external {
_balance[msg.sender] += msg.value;
}
}
Everything goes fine, but the compiler suggests that:
Warning: This contract has a payable fallback function, but no receive ether function.
Consider adding a receive ether function.
What does it mean by a receive ether function? I tried looking it up and many examples I could find is just another fallback function.
I am using version 0.6.1+commit.e6f7d5a4
As a complement to the accepted answer, here's how you should define the unnamed fallback and receive functions to solve this error:
contract MyContract {
fallback() external payable {
// custom function code
}
receive() external payable {
// custom function code
}
}
According to solidity version 0.6.0, we have a breaking change.
The unnamed function commonly referred to as “fallback function” was split up into a new fallback function that is defined using the fallback keyword and a receive ether function defined using the receive keyword.
If present, the receive ether function is called whenever the call data is empty (whether or not ether is received). This function is implicitly payable.
The new fallback function is called when no other function matches (if the receive ether function does not exist then this includes calls with empty call data). You can make this function payable or not. If it is not payable then transactions not matching any other function which send value will revert. You should only need to implement the new fallback function if you are following an upgrade or proxy pattern.
https://solidity.readthedocs.io/en/v0.6.7/060-breaking-changes.html#semantic-and-syntactic-changes

get contract creator's address in a different separate smart contract

I want to create a dApp where one can do certain things related to a contract they've deployed. let's say it'll be used to manage a token listing site.
I need to figure out how to verify that the address that's calling the functions matches the address that created a particular contract.
eg. 0x01 is the contract creator of Contract A
0x01 calls a function along with the parameter of Contract A's contract address in Contract B
A function within Contract B then finds the contract creator's address of Contract A somehow and matches that against 0x01
Is this possible to do in solidity?
Code
pragma solidity ^0.4.20;
contract A {
address private owner_;
function A() public {
owner_ = msg.sender;
}
function getOwner() public view returns (address) {
return owner_;
}
}
contract B {
function findAsOwner() public view returns (bool) {
require(A(address of contract A).getOwner() == msg.sender);
return true;
}
}
I tested it on my remix. I called findAsOwner() and it passed the require part and returned true. You may use this pattern.