Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

Смарт-контракт на Solidity: Частина 6 — токен ERC20 — рефакторинг

отредактировано December 2017 Раздел: Смарт Контракты

Серія уроків була взята з сайту inaword.ru

На минулому уроці ми з Вами написали свій перший токен ERC20. Код ми писали на ходу та помістили практично увесь функціонал в один контракт. Для швидкості вивчення це було добре. Але тепер потрібно навчитися писати контракти як дорослі. От деякі рекомендації з написання доброго(хорошого) контракту:

  1. Не винаходити велосипед, а намагатися брати вже готові рішення та змінювати їх під себе. Якщо задача популярна, тоді до Вас вже наступили на всі граблі та знайшли рішення. Токенів ERC20 вже написано доволі багато. Та на GitHub’і можно завжди подивитися код. Наприклад, ось цей.
  2. Використовувати усталені шаблони проектування. Такі шаблони побудовані на основі досвіду вирішення задач іншими програмістами. Так контракт токена ERC20 зазвичай має структуру наслідування, яка не істотно відрізняється від проекта до проекту.
  3. Намагатися виділяти код, який можно перевикористати. Ми з Вами на минулих уроках виділили контракт Ownable. І вже переконалися що не дарма. Ми його використовували в контракті-візітці і в нашому токені.
  4. Виділяти стандарти у вигляді інтерфейсів. Одна з причин такого підходу - у нашому коді неможливо зрозуміти які з функцій відносяться до стандарту, а які ні.
    Давайте подивимося на структуру, яка часто зустрічається, наслідування токена ERC20.

Назва контрактів можуть відрізнятися від проекта до проекту, але ми будемо орієнтуватися на цей репозиторій. Така ж структура, але з назвою контрактів.

На минулому уроці ми говорили тільки про стандарт ERC20. А тут з’явився якийсь ERC179. Тут все просто. Як виявилося не всім потрібна частина, яка відповідає за представлення дозволів на зняття коштів. Тому всі функції, які не відносяться до механізму надання дозволів, винесли в ERC179. Тому стандарт ERC20 це той же ERC179 тільки з додатковими функціями та подіями.

Контракти StandartToken та BasicToken - це частково реалізації стандартів.

Оскільки наш токен повністю відповідає ERC20, то ми будемо наслідуватися від контракту StandartToken.

Крім задач ERC20 в нашому токені є ще функції, які відповідають за емісію нових монет. Це теж широко-використований шаблон. Контракти, які можуть випускати нові монети, зазвичай, називають Mintable. А оскільки випускати нові монети можуть тільки власник контракту, то Mintable наслідується від Ownable.

А тепер давайте згадаємо, що в нашому контракті були перевірки на негативний (отрицательный) баланс, перевірки на наповнення. У майбутньому нам можуть стане в нагоді перевірки ділення на ноль і так далі. Усі ці перевірки у разі невдачі переривають виконання функції. Вони використовуваються дуже часто, тому прийнято їх виділяти в окрему бібліотеку захищених математичних операцій - SafeMath. У більшості проектів вона скопійована один в один.

З урахуванням всього вищесказаного структура контрактів нашого токена тепер виглядає так:

Важливо розуміти, що від бібліотек не наслідується. Їх “використовують”, тобто підключають до контракту. Наприклад, для SafeMath це виглядає так:

using SafeMath for uint256;

Візьмемо готовий код стандартних шаблонів із репозиторію ZeppelinSolidity та перепишемо наш токен:

  1. ERC20Basic — інтерфейс ERC179, тобто ERC20 без механізму надання дозволів
  2. ERC20 — інтерфейс ERC20
  3. BasicToken — абстрактна реалізація ERC179
  4. StandartToken — абстрактна реалізація ERC20
  5. Ownable — надає можливість обмежувати доступ до функцій усім крім власника контракту
  6. SafeMath — бібліотека безпечних математичних операцій. У випадку проблем з виповненням операцій, робота функції переривається
  7. MintableToken — надає можливість випуску нових монет. Якщо випуск нових монет більше не потрібен, то викликається finishMinting (у ICO викликається, як правило, після закінчення розпродажу монет). Відновити випуск монет більше неможна буде. Звичайно можно було б дописати функцію, яка дозволяє додаткову емісію монет. Але шаблон, скоріш за все, часто використовується в ICO. У випадку додаткової емісії, після ICO ціна монети може розмиватися. А це погано для покупців нашої монети. Тому якщо покупець бачить, що після закінчення ICO не буде мати фізичну змогу випускати нові монети, то довіра до нас підвищиться.

А тепер подивіться скільки рядків коду ми повинні були б написати з нуля, якщо б ми відразу використовували готові рішення:

pragma solidity ^0.4.13;

contract SimpleTokenCoin is MintableToken {

    string public constant name = "Simple Coint Token";

    string public constant symbol = "SCT";

    uint32 public constant decimals = 18;

}

Усе інше ми би просто скопіювали. А ось повний код:

pragma solidity ^0.4.13;

/**
 * @title ERC20Basic
 * @dev Simpler version of ERC20 interface
 * @dev see https://github.com/ethereum/EIPs/issues/179
 */
contract ERC20Basic {
  uint256 public totalSupply;
  function balanceOf(address who) constant returns (uint256);
  function transfer(address to, uint256 value) returns (bool);
  event Transfer(address indexed from, address indexed to, uint256 value);
}

/**
 * @title ERC20 interface
 * @dev see https://github.com/ethereum/EIPs/issues/20
 */
contract ERC20 is ERC20Basic {
  function allowance(address owner, address spender) constant returns (uint256);
  function transferFrom(address from, address to, uint256 value) returns (bool);
  function approve(address spender, uint256 value) returns (bool);
  event Approval(address indexed owner, address indexed spender, uint256 value);
}

/**
 * @title SafeMath
 * @dev Math operations with safety checks that throw on error
 */
library SafeMath {

  function mul(uint256 a, uint256 b) internal constant returns (uint256) {
    uint256 c = a * b;
    assert(a == 0 || c / a == b);
    return c;
  }

  function div(uint256 a, uint256 b) internal constant returns (uint256) {
    // assert(b > 0); // Solidity automatically throws when dividing by 0
    uint256 c = a / b;
    // assert(a == b * c + a % b); // There is no case in which this doesn't hold
    return c;
  }

  function sub(uint256 a, uint256 b) internal constant returns (uint256) {
    assert(b <= a);
    return a - b;
  }

  function add(uint256 a, uint256 b) internal constant returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;
  }

}

/**
 * @title Basic token
 * @dev Basic version of StandardToken, with no allowances. 
 */
contract BasicToken is ERC20Basic {

  using SafeMath for uint256;

  mapping(address => uint256) balances;

  /**
  * @dev transfer token for a specified address
  * @param _to The address to transfer to.
  * @param _value The amount to be transferred.
  */
  function transfer(address _to, uint256 _value) returns (bool) {
    balances[msg.sender] = balances[msg.sender].sub(_value);
    balances[_to] = balances[_to].add(_value);
    Transfer(msg.sender, _to, _value);
    return true;
  }

  /**
  * @dev Gets the balance of the specified address.
  * @param _owner The address to query the the balance of. 
  * @return An uint256 representing the amount owned by the passed address.
  */
  function balanceOf(address _owner) constant returns (uint256 balance) {
    return balances[_owner];
  }

}

/**
 * @title Standard ERC20 token
 *
 * @dev Implementation of the basic standard token.
 * @dev https://github.com/ethereum/EIPs/issues/20
 * @dev Based on code by FirstBlood: https://github.com/Firstbloodio/token/blob/master/smart_contract/FirstBloodToken.sol
 */
contract StandardToken is ERC20, BasicToken {

  mapping (address => mapping (address => uint256)) allowed;

  /**
   * @dev Transfer tokens from one address to another
   * @param _from address The address which you want to send tokens from
   * @param _to address The address which you want to transfer to
   * @param _value uint256 the amout of tokens to be transfered
   */
  function transferFrom(address _from, address _to, uint256 _value) returns (bool) {
    var _allowance = allowed[_from][msg.sender];

    // Check is not needed because sub(_allowance, _value) will already throw if this condition is not met
    // require (_value <= _allowance);

    balances[_to] = balances[_to].add(_value);
    balances[_from] = balances[_from].sub(_value);
    allowed[_from][msg.sender] = _allowance.sub(_value);
    Transfer(_from, _to, _value);
    return true;
  }

  /**
   * @dev Aprove the passed address to spend the specified amount of tokens on behalf of msg.sender.
   * @param _spender The address which will spend the funds.
   * @param _value The amount of tokens to be spent.
   */
  function approve(address _spender, uint256 _value) returns (bool) {

    // To change the approve amount you first have to reduce the addresses`
    //  allowance to zero by calling `approve(_spender, 0)` if it is not
    //  already 0 to mitigate the race condition described here:
    //  https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
    require((_value == 0) || (allowed[msg.sender][_spender] == 0));

    allowed[msg.sender][_spender] = _value;
    Approval(msg.sender, _spender, _value);
    return true;
  }

  /**
   * @dev Function to check the amount of tokens that an owner allowed to a spender.
   * @param _owner address The address which owns the funds.
   * @param _spender address The address which will spend the funds.
   * @return A uint256 specifing the amount of tokens still available for the spender.
   */
  function allowance(address _owner, address _spender) constant returns (uint256 remaining) {
    return allowed[_owner][_spender];
  }

}

/**
 * @title Ownable
 * @dev The Ownable contract has an owner address, and provides basic authorization control
 * functions, this simplifies the implementation of "user permissions".
 */
contract Ownable {

  address public owner;

  /**
   * @dev The Ownable constructor sets the original `owner` of the contract to the sender
   * account.
   */
  function Ownable() {
    owner = msg.sender;
  }

  /**
   * @dev Throws if called by any account other than the owner.
   */
  modifier onlyOwner() {
    require(msg.sender == owner);
    _;
  }

  /**
   * @dev Allows the current owner to transfer control of the contract to a newOwner.
   * @param newOwner The address to transfer ownership to.
   */
  function transferOwnership(address newOwner) onlyOwner {
    require(newOwner != address(0));      
    owner = newOwner;
  }

}

/**
 * @title Mintable token
 * @dev Simple ERC20 Token example, with mintable token creation
 * @dev Issue: * https://github.com/OpenZeppelin/zeppelin-solidity/issues/120
 * Based on code by TokenMarketNet: https://github.com/TokenMarketNet/ico/blob/master/contracts/MintableToken.sol
 */

contract MintableToken is StandardToken, Ownable {

  event Mint(address indexed to, uint256 amount);

  event MintFinished();

  bool public mintingFinished = false;

  modifier canMint() {
    require(!mintingFinished);
    _;
  }

  /**
   * @dev Function to mint tokens
   * @param _to The address that will recieve the minted tokens.
   * @param _amount The amount of tokens to mint.
   * @return A boolean that indicates if the operation was successful.
   */
  function mint(address _to, uint256 _amount) onlyOwner canMint returns (bool) {
    totalSupply = totalSupply.add(_amount);
    balances[_to] = balances[_to].add(_amount);
    Mint(_to, _amount);
    return true;
  }

  /**
   * @dev Function to stop minting new tokens.
   * @return True if the operation was successful.
   */
  function finishMinting() onlyOwner returns (bool) {
    mintingFinished = true;
    MintFinished();
    return true;
  }

}

contract SimpleTokenCoin is MintableToken {

    string public constant name = "Simple Coint Token";

    string public constant symbol = "SCT";

    uint32 public constant decimals = 18;

}

На цьому уроці ми познайомилися з загальним підходом написання контрактів монети ERC20. Навчилися використовувати готові рішення, що сильно спростило нам задачу та позбавило від помилок. Слід також відмітити, що багато контрактів написані так, щоб уникнути уразливості. Це може бути банальне переміщення двух рядків коду, що не завжди очевидно для початківця.

Фактично з цих контрактів-цеглинок ми можемо зібрати свій контракт на будь-який смак з найменшими зусиллями. Насправді таких усталених шаблонів проектування в solidity дуже багато. Далі ми познайомимося з деякими з них. А поки тут можна знайти документацію по найпопулярнішим шаблонам від OpenZeppelin.

Продовження читати тут.

Войдите или Зарегистрируйтесь чтобы комментировать.