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.
Related
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
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.
I created an ERC-721 contract that has a mint function that is payable. I have used a nonReentrant modifier with it which is found in the Openzeppelin contracts under Renterancy. Does this cause errors?
Does payable invoke the nonreenterant modifier?
The OpenZeppelin nonReentrant modifier (link) prevents the reentrancy attack (link).
But it does not affect the function state mutability (such as payable).
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.
Why does Remix fail to deploy the simple contract (simplified from the Mastering Ethereum book https://github.com/ethereumbook/ethereumbook/blob/develop/code/Solidity/Faucet2.sol )? --
pragma solidity ^0.4.19;
contract Faucet {
function withdraw(uint withdraw_amount) public {
require(withdraw_amount <= 100000000000000000);
msg.sender.transfer(withdraw_amount);
}
function () external payable {}
}
No matter how I raise gasLimit and/or gasPrice
Your code is fine (I have also tried it myself). From what I see above you are also sending a value along with the deploy. Since you have not defined a constructor yourself the default one is being called which is not payable. If you want to send ether when you deploy the contract you should also define a payable constructor.