I have a ERC-721 smart contract defined like this
contract MintNFT is ERC721Enumerable, Ownable {
constructor(string _name, string _symbol) ERC721(_name, _symbol){}
}
in which I mint the NFTs and few more functions. Then I have created a new contract to purchase the NFTs and manage some stuff, but it forces me to mark it as abstract no matter what I write in the contract. I defined it like this:
contract ManagerNFT is MintNFT, IERC721 {
constructor(string memory _name, string memory _symbol) MintNFT(_name, _symbol){}
}
It throws an error saying linearization of inheritance graph impossible it goes away when I mark this ManagerNFT contract to abstract.
I don't know why this happens, I'm setting the constructors correctly I think, any thoughts on how to do this? Thanks.
As the IERC721 name suggests, it's an interface.
So the ManagerNFT needs to implement all functions of the interface.
Related
I'm thinking about my smart contract and want to have a secure contract. But I really don't know that internal functions are safe or not.
This is a very BASIC contract that uses OpenZeppelin contracts:
contract MyContract is ERC20 {
constructor () ERC20("test", "test") {
_mint(msg.sender, 1000);
}
}
_mint is an internal function from Openzeppelin ERC20 contract.
Can someone deploy another contract and call the MyContract _mint() function?
If yes, How can we secure it?
The function _mint() from ERC20 is internal.
Internal functions can only be called within the contract or by the contracts inherited from the current one.
That means that no other contract can call MyContract._mint(), you can only call _mint() from inside MyContract.
I want to implement a burn feature in my ERC721 contract in Solidity. To do so, I have imported the function burn from ERC721Burnable.sol.
Since I have imported it I get the following error:
"Derived contract must override function _beforeTokenTransfer".
The same goes with supportsInterface function.
I did override both of them as you can see below. It works but I would like to understand why do I have to do that?
function _beforeTokenTransfer(
address from,
address to,
uint256 tokenId
) internal virtual override(ERC721, ERC721Enumerable) {
super._beforeTokenTransfer(from, to, tokenId);
}
function supportsInterface(bytes4 interfaceId)
public
view
virtual
override(ERC721, ERC721Enumerable)
returns (bool)
{
return super.supportsInterface(interfaceId);
}
I checked Openzeppelin repo, _beforeTokenTransfer is called inside _burn function. At first, I thought it was the main reason but the fact is that _beforeTokenTransfer is also called inside mint and I did not have that error before.
I have no idea why I have to override supportsInterface.
Thanks
ERC721Burnable inherits from two contracts:
abstract contract ERC721Burnable is Context, ERC721 {}
ERC721.sol contract has _beforeTokenTransfer and _afterTokenTransfer unimplemeted functions. you have to implement those in your contract.
from this github issue
ERC721Enumerable and ERC721Burnable both override the
_beforeTokenTransfer and supportsInterface functions. Solidity requires you to "fix" that overriding conflict. If we were able to
address that in our contract we would, but its a solidity requirement
that the child contract explicitly resolves this.
Looks like you 2 of contracts are conflicting inhering supportsInterface
When I deploy the below smart contract, the variable manager has the address 0x0000000000000000000000000000000000000000. It is only after I call the constructor (Lottery()) that the variable manager has an address that matches the account it is deployed by.
Why is my constructor not called automatically?
pragma solidity ^0.4.17;
contract Lottery {
address public manager;
function Lottery() public {
manager = msg.sender;
}
}
Your constructor should be called automatically.
I used Remix (https://remix.ethereum.org) with compiler version 0.4.17 and then deployed and manager was set to the deployment address as expected.
The issue you are experiencing would happen if the contract name and the constructor had different names, so the function was no longer a constructor.
Solidity 0.4.22 changed to use constructor instead of the contract name to avoid these type of bugs:
https://github.com/ethereum/solidity/releases/tag/v0.4.22
Constructors should now be defined using constructor(uint arg1, uint arg2) { ... } to make them stand out and avoid bugs when contracts are renamed but not their constructors.
I would suggest you look at using a later version of Solidity 0.5.x.
I am trying to make a contract that has two different tokens used for different aspects of the contract. I would like both of the tokens to be able to fit ERC20 standards but I am not sure how to specify unique variables and functions for each.
If you consider the structure of an ERC 20 token : https://github.com/ConsenSys/Tokens/blob/master/Token_Contracts/contracts/Token.sol , you will see that what you are proposing, although possible, would be a little messy. But more importantly it would transform your token contract into a non-ERC20 token.
uint256 public totalSupply; would need to be replaced with either a mapping or a two separate parameters.
The same would be for managing balances, you would need to change the signature of each method to take an additional parameter for specifying the token you want or create specific method for each token within the contract:
function balanceOf(address _owner) constant returns (uint256 balance);
Would need to be either:
function balanceOf(address _owner, uint256 token_id) constant returns (uint256 balance);
or
function balanceOfTokenA(address _owner) constant returns (uint256 balance);
function balanceOfTokenB(address _owner) constant returns (uint256 balance);
But like I said, either implementation would make your token contract a non-ERC20 token.
You would be better off having two contracts, then both would be ERC20 compatible. You could then write a third contract for managing them if your requirements are that they need to be interfaced via a single contract.
These days, ERC1155, a "multi-token" standard, seems like a good choice for contracts needing multiple tokens:
https://github.com/ethereum/EIPs/issues/1155
Simple Summary:
A standard interface for contracts that manage multiple token types. A
single deployed contract may include any combination of fungible
tokens, non-fungible tokens or other configurations (e.g.
semi-fungible tokens).
See also the openzeppelin implementation
Trying to follow the wiki example for go ethereum to create a basic contract:
https://github.com/ethereum/go-ethereum/wiki/Contracts-and-Transactions
Everything seems to work until I get down until the last line:
source = "contract test { function multiply(uint a) returns(uint d) { return a * 7; } }"
contract = eth.compile.solidity(source).test
primaryAddress = eth.accounts[0]
# **Problems start here **
MyContract = eth.contract(abi);
contact = MyContract.new(arg1, arg2, ...,{from: primaryAddress, data: evmCode})
What is the "abi" argument for the eth.contract method? Also, what would I put in the "evmCode" argument? In this particular example, seems like I would put in an integer for "arg1" but not sure what the full example should look like.
The ABI is the interface that your contract exposes. "evmCode" is the Ethereum byte code for your contract.
To work around your problem, go to https://chriseth.github.io/browser-solidity/ and plug your Solidity in. The Bytecode field on the right will give you the value for "evmCode" and Interface will give you the ABI.
You can also copy the snippet from "Web3 deploy" and paste it in your code to deploy your contract.
ABI is basically which is the public facing interface that shows what methods are available to call.
The simplest way to get the abi would be to use https://remix.ethereum.org . just paste in your code and in Contract tab At the bottom of the column you’ll find a link that says Contract details which is basically the ABI json
Conversely you could also use the contracts.Introduction.interface api of web3 to get the abi.
ABI is representation of smart contract that can be read using java script .To read the data from a deployed contract account in etherum , you'll need some extra details like abi.
Steps to get abi of any smart contract:
1.Each contract has contract hash address like this:0x0D8775F648430679A709E98d2b0Cb6250d2887EF
2.Go to etherscan.io and search your contract address hash in search bar and you will get contract.
3.In contract go to code and there you can find this abi
can check this link to find abi
You could try using tools like Etherlime shape or Truffle boxes to have a whole sample project with contract, tests, and usage into the js. From here you could start moving forward.
ABI is Application Binary Interface. A contract when compiled by solidity compiler returns an object with different methods. ABI and Bytecode are basically used methods. ABI is used to interact with your contracts and frontend (if using node) and bytecode is used for deploying to Rinkeby (or any Ethereum network).
For example:
Contract is:
pragma solidity ^0.4.17;
contract Inbox
{
string public message;
function Inbox(string initialMessage) public{
message = initialMessage;
}
function setMessage(string newMessage) public{
message = newMessage;
}
}
Its ABI is:
interface:
[{
"constant":false,"inputs":[{
"name":"newMessage","type":"string"
}]
,"name":"setMessage","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"
}
,{
"constant":true,"inputs":[],"name":"message","outputs":[{
"name":"","type":"string"
}]
,"payable":false,"stateMutability":"view","type":"function"
}
,{
"inputs":[{
"name":"initialMessage","type":"string"
}]
,"payable":false,"stateMutability":"nonpayable","type":"constructor"
}]
This is returned after compiling the contract. You can see it consists of methods used in our contract.