OpenZeppelin起动平衡
我相信openzeppelin项目已经更新了他们的StandardToken智能合同，现在被称为ERC20.sol。
我遇到的一个问题是，新的smart合同有一些我们以前缺少的功能。在过去，当您将StandardToken导入到智能契约中时，您将能够像这样初始化令牌：
pragma solidity ^0.4.19;
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/ownership/Ownable.sol";
/**
* @title ExampleToken is a basic ERC20
*/
contract ExampleToken is ERC20, Ownable {
uint256 public totalSupply;
string public name;
string public symbol;
uint32 public decimals;
/**
* @dev assign totalSupply to owner of contract
*/
constructor() public {
symbol = "EXM";
name = "ExampleCoin";
decimals = 4;
totalSupply = 10000000000;
owner = msg.sender;
balances[msg.sender] = totalSupply;
emit Transfer(0x0, msg.sender, totalSupply);
}
}因为我使用的是新的智能合同，我不能再这么做了：
balances[msg.sender] = totalSupply; 因为openzeppelin没有实现这个错误，所以我得到了这个错误：
DeclarationError:未声明的标识符。你是说"balanceOf“吗？
balanceOf显然不合适，因为这是一个在给定地址返回余额的函数。
初始化余额最合适的方法是什么？
把它寄到主人的地址好吗?还是把它留在聪明的合同里？是否存在将余额留在智能合同中的风险，这一程序是否被广泛使用？
如果我不应该把它放在智能合同中，那么给合同创建者提供总供给的最好方法是什么？
或者，当StandardToken存在时，是否可以导入以前的openzeppelin智能合同？
回答 2
Ethereum用户
发布于 2019-01-11 20:00:59
正如Rob所建议的，我应该使用薄荷作为初始供应。我使用的是ERC20Detailedtoken而不是ER20Capped。
首先，导入我建议检查的ERC20Detailedtoken。从前面的代码中，我的实现如下：
pragma solidity ^0.4.19;
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/ownership/Ownable.sol";
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol";
/**
* @title ExampleToken is basic ERC20 Token
*/
contract ExampleToken is ERC20, ERC20Detailed, Ownable{
uint256 public initialSupply = 100000000000;
string public name;
string public symbol;
uint32 public decimals;
/**
* @dev assign totalSupply to account creating this contract
*/
constructor() public ERC20Detailed("ExampleCoin", "EXM", 4) {
_mint(msg.sender, initialSupply);
}}Ethereum用户
发布于 2019-01-11 18:36:51
如果我没有弄错，您将使用ERC20Capped.sol和mint()令牌作为迁移/部署过程中的第二步。
对于我来说，这似乎是明智的，因为mintable令牌可以完成非mintable令牌所能做的一切。“上限”变体限制了铸币供应，似乎是对构造函数中初始化供应和minter平衡的旧样式的替代。
希望能帮上忙。
https://ethereum.stackexchange.com/questions/65396
复制相似问题
腾讯云开发者
