Как составить смарт контракт

Время на прочтение
11 мин

Количество просмотров 1.7K

В первой теоретической части мы поговорили про то:

1. Что такое обновляемые смарт-контракты?

2. Как работает обновление?

3. Про модель прозрачного прокси

4. Про шаблон UUPS

В этой части статьи мы перейдём от теории к практике и будем вести разработку обновляемого смарт-контракта.

Начинаем разработку

Для начала мы применим паттерн Transparent Proxy, используя инструментарий для обновления OpenZeppelin, который работает с обычными рабочими процессами разработки Web3, использующими JavaScript и Hardhat. OpenZeppelin предлагает плагины, которые интегрируются с Hardat и Truffle. Мы будем использовать Hardhat.

Плагин Hardhat предоставляет нам такие функции, как deployProxy, которые отслеживают для нас логический контракт и дают нам легкий доступ к функциям обновления. По умолчанию, адрес, который развернул контракт, является тем, который имеет права администратора для его обновления.

Давайте создадим проект Hardhat — вы можете назвать его как угодно — и, находясь в этом каталоге, начнем настраивать инструментарий проекта, выполнив следующие шаги.

Настройка проекта

Установите инструменты разработчика Hardhat, библиотеки Web3 и плагин обновлений, предоставляемый OpenZeppelin. Команда ниже создаст ваш файл package.json.

yarn add -D hardhat @openzeppelin/hardhat-upgrades @nomiclabs/hardhat-ethers ethers

Установите пакеты контрактов из NPM, которые содержат интерфейсы контрактов Chainlink и обновляемые библиотеки контрактов OpenZeppelin, которые мы хотим использовать:

yarn add @chainlink/contracts  @openzeppelin/contracts-upgradeable

Затем запустите yarn hardhat в корневом каталоге проекта, чтобы создать пустой файл hardhat.config.js в корне. Внутри этого конфигурационного файла вставьте следующее, чтобы сообщить Hardhat, какую версию компилятора будет использовать проект при импорте нужных зависимостей:

require("@nomiclabs/hardhat-ethers");

require("@openzeppelin/hardhat-upgrades");

const GOERLI_RPC_URL = process.env.GOERLI_RPC_URL_HTTP
const PRIVATE_KEY = process.env.WALLET_PRIVATE_KEY_DEV1;

const ETHERSCAN_KEY = process.env.ETHERSCAN_API_KEY;

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
 solidity: "0.8.17",
 defaultNetwork: "hardhat",
 networks: {
   localhost: {
     chainId: 31337,
   },
   goerli: {
     url: GOERLI_RPC_URL,
     accounts: PRIVATE_KEY ? [PRIVATE_KEY] : [],
     chainId: 5,
   },
 },
 etherscan: {
   apiKey: ETHERSCAN_KEY,
 },
};

Код смарт-контракта

В корне вашего проекта создайте файл /contracts/PriceFeedTrackerV1.sol Solidity и вставьте в него следующий смарт-контракт:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract PriceFeedTracker is Initializable {
   address private admin;

   function initialize(address _admin) public initializer {
       admin = _admin;
   }

   function getAdmin() public view returns (address) {
       return admin;
   }

   /**
    * Network: Goerli
    * Aggregator: ETH/USD
    * Address: 0xD4a33860578De61DBAbDc8BFdb98FD742fA7028e
    */
   function retrievePrice() public view returns (int) {

       AggregatorV3Interface aggregator = AggregatorV3Interface(

           0xD4a33860578De61DBAbDc8BFdb98FD742fA7028e
       );
       (
           ,
           /*uint80 roundID*/
           int price, /*uint startedAt*/ /*uint timeStamp*/ /*uint80 answeredInRound*/
           ,
           ,

       ) = aggregator.latestRoundData();

       return price;
   }
} 

Если теперь вы запустите yarn hardhat compile, вы увидите, что код Solidity успешно скомпилировался, а в каталоге проекта появились две новые папки «Artifacts» и «cache».

Вы заметите, что этот смарт-контракт V1 получает данные о цене ETH/USD из Chainlink Price Feeds в сети Goerli. В настоящее время адрес Price Feed’а жестко закодирован, что означает, что он может возвращать только цену ETH/USD. В будущем мы обновим его, чтобы он мог обрабатывать адрес Price Feed любой пары активов в сети Goerli.

Пока же давайте рассмотрим, что происходит с Initializable и функцией initialize(). Из-за некоторых особенностей Solidity, которые выходят за рамки этой статьи, мы не можем включить конструктор в наши смарт-контракты, когда используем обновляемые контракты Open Zeppelin. Вместо этого мы создаем собственную функциональность, подобную конструктору, расширяя базовый контракт Initializable, который помогает нам применить модификатор инициализатора к функции initialize(). Мы можем назвать функцию initialize как угодно, но при использовании initialize плагин Hardhat распознает ее и будет вызывать эту функцию по умолчанию. Если у нас есть функция инициализатора с другим именем, нам нужно будет указать имя нашего инициализатора.

Этот шаблон «Initialize» с модификатором имитирует функцию конструктора, гарантируя, что initialize() будет запущена только один раз. Здесь мы можем явно задать адрес нашего администратора, если захотим — по умолчанию это будет адрес развертывателя. Функция retrievePrice() вызывает смарт-контракт ETH/USD Price Feed и возвращает биржевую цену.

Скрипт развертывания

Давайте развернем этот контракт V1 с помощью следующего скрипта в scripts/deploy_upgradeable_pricefeedtracker.js .

// The Open Zeppelin upgrades plugin adds the `upgrades` property
// to the Hardhat Runtime Environment.
const { ethers, network, upgrades } = require("hardhat");

async function main() {
 // Obtain reference to contract and ABI.
 const PriceFeedTracker = await ethers.getContractFactory("PriceFeedTracker");
 console.log("Deploying PriceFeedTracker to ", network.name);

 // Get the first account from the list of 20 created for you by Hardhat
 const [account1] = await ethers.getSigners();

 //  Deploy logic contract using the proxy pattern.
 const pricefeedTracker = await upgrades.deployProxy(
   PriceFeedTracker,

   //Since the logic contract has an initialize() function
   // we need to pass in the arguments to the initialize()
   // function here.
   [account1.address],

   // We don't need to expressly specify this
   // as the Hardhat runtime will default to the name 'initialize'
   { initializer: "initialize" }
 );
 await pricefeedTracker.deployed();

 console.log("PriceFeedTracker deployed to:", pricefeedTracker.address);
}

main();

Используя deployProxy() в плагинах OpenZeppelin, этот развернутый экземпляр контракта может быть обновлен позже. По умолчанию только адрес, который первоначально развернул контракт, имеет права на его обновление.

deployProxy создаст следующие транзакции:

• Развертывание логического контракта (наш контракт PriceFeedTracker).

• Развертывание прокси-контракта и запуск любой функции инициализатора.

• Развертывание контракта ProxyAdmin (администратор для нашего прокси).

  Перед запуском сценария развертывания убедитесь, что у вас достаточно Goerli ETH. Вы можете получить Goerli ETH из фасета Chainlink. Убедитесь, что вы также задали URL узла RPC и закрытый ключ в переменных окружения, чтобы файл hardhat.config.js мог их прочитать!

Мы можем запустить наш сценарий развертывания с помощью следующей команды, чтобы развернуть контракт в тестовой сети Ethereum Goerli.

yarn hardhat run --network goerli scripts/deploy_upgradeable_pricefeedtracker.js

В результате в вашем терминале должно появиться подтверждение, похожее на приведенное ниже, но с другим адресом контракта. Запишите этот адрес контракта. Обратите внимание, что это адрес вашего прокси-контракта, а не логического контракта. Нам нужен адрес прокси-контракта, потому что это стабильный (неизменный) адрес, который мы будем использовать для взаимодействия с нашими логическими контрактами.

Deploying PriceFeedTracker...
PriceFeedTracker deployed to: 0x5FC8d32690cc91D4c39d9d3abcBD16989F875707

Вы можете изучить документацию по deployProxy() и ее опциям конфигурации здесь. Обратите внимание, что по умолчанию используется шаблон «прозрачный», но вы можете указать, что хотите, чтобы ваш прокси следовал шаблону UUPS, явно задав этот параметр конфигурации.

Консоль Hardhat

Прежде чем мы обновим наш контракт, давайте взаимодействовать с ним с помощью консоли Hardhat, которая позволяет нам писать JavaScript для взаимодействия с нашим логическим контрактом, развернутым через прокси-контракт.

В новом (третьем!) окне терминала выполните следующую команду, чтобы присоединить консоль к блокчейну Goerli:

yarn hardhat console --network goerli

Откроется приглашение консоли, в котором вы можете выполнить следующие команды по отдельности:

> const PriceFeedTracker = await ethers.getContractFactory("PriceFeedTracker");
undefined

> const priceFeedTracker = await PriceFeedTracker.attach('<<<< YOUR CONTRACT ADDRESS  >>>>') 
undefined

Затем вызовите функцию getAdmin(), которая должна вывести адрес вашего кошелька развертывателя — адрес, который вы передали в качестве аргумента функции initialize в сценарии развертывания.

> (await priceFeedTracker.getAdmin())
'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266'

Затем попробуйте получить цену ETH/USD. Это вызов только для представления, поскольку он не изменяет состояние и не вызывает никаких событий, поэтому вам не нужно платить за газ.

> (await v1.retrievePrice())
BigNumber { value: "150701000000" }

Ок! Если вы получаете эти результаты, значит прокси-контракт правильно взаимодействует с развернутым прокси-контрактом.

Вот полезный совет: перейдите по адресу goerli.etherscan.io/address/YOUR_CONTRACT_ADDRESS и перейдите на вкладку Events. Вы должны увидеть несколько событий, которые выглядят как на рисунке ниже. Найдите событие под названием «Upgrade» и нажмите на маленькую стрелку рядом с ним. Это покажет вам адрес контракта на внедрение. Именно этот адрес будет меняться каждый раз, когда вы будете обновлять свой смарт-контракт.

Модернизированный логический контракт

Теперь давайте соберем обновленный логический контракт, который имеет некоторые дополнительные функции. Посмотрите на PriceFeedTrackerV2 ниже. Вы заметите следующие изменения:

1. Существует новая публичная переменная хранения под названием price, которая имеет тип int и будет хранить полученную цену.

2. Есть новое событие, которое выдает две части данных при обновлении Price Feed.

3. Функция retrievePrice() больше не кодирует адрес ETH/USD, а получает адрес Price Feed от вызывающей стороны. Она также проверяет, что передан ненулевой адрес. Как только цена получена, она издает событие, а также сохраняет цену в переменной состояния price (обе операции изменяют состояние блокчейна, так что это больше не функция просмотра).

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract PriceFeedTrackerV2 is Initializable {
   address private admin;
   int public price; // NOTE: new storage slot

   // Emitted when the price is retrieved changes
   event PriceRetrievedFrom(address feed, int price);

   function initialize(address _admin) public initializer {
       admin = _admin;
   }

   function getAdmin() public view returns (address) {
       return admin;
   }

   // Fetches the price from the feed.
   // Note that the function is no longer a view function as it emits an event.
   function retrievePrice(address feed) public returns (int) {
       require(
           feed != address(0x0),
           "PriceFeedTrackerV2: Pricefeed address must not be zero address."
       );

       AggregatorV3Interface aggregator = AggregatorV3Interface(feed);
       (
           ,
           /*uint80 roundID*/
           int _price, /*uint startedAt*/ /*uint timeStamp*/ /*uint80 answeredInRound*/
           ,
           ,

       ) = aggregator.latestRoundData();

       price = _price;

       emit PriceRetrievedFrom(feed, _price);

       return price;
   }
}

1. Существует важный технический момент, касающийся переменных хранения, который мы должны отметить на этом этапе. Вы увидите, что переменная состояния admin осталась на прежней «позиции», а переменная цены объявлена после нее. Это связано с тем, что при обновлении логических контрактов они не должны менять порядок объявления переменных состояния, так как это может привести к столкновению хранилищ (иначе называемому коллизией хранилищ), поскольку контекст хранилища находится в прокси-контракте (как обсуждалось ранее в этом блоге). Это связано с тем, что переменным состояния обычно назначаются «слоты» расположения хранения в контексте прокси-контракта, и эти слоты должны оставаться неизменными во всех обновлениях логического контракта. Поэтому мы не можем заменять слоты хранения или вставлять новые между обновлениями. Все новые переменные состояния должны быть добавлены в конец, в слот, который ранее не был занят. OpenZeppellin использует слоты хранения EIP1967, чтобы избежать столкновений хранения в логических контрактах. Подробнее о более глубоких деталях паттернов прокси OpenZeppelin и хранения данных вы можете прочитать здесь.

Сценарий развертывания для контракта на обновление

Контракт логики обновления имеет другое название и новую функциональность. Мы можем обновить экземпляр V1, вызвав функцию upgradeProxy, которая создает следующие транзакции:

1. Развернуть обновленный логический контракт (наш контракт PriceFeedTrackerV2).

2. Вызов контракта ProxyAdmin (администратора нашего прокси) для обновления контракта прокси, чтобы он указывал на новый логический контракт.

Наш обновленный сценарий будет находиться в scripts/upgrade_pricefeedtracker.js и будет выглядеть следующим образом (обратите внимание, что мы используем upgradeProxy, а не deployProxy). Очень важно отметить, что вы должны добавить адрес развернутого контракта до запуска скрипта — забыв об этом, легко допустить ошибку, которая может запутать вас на несколько часов!

const { ethers, upgrades } = require("hardhat");

async function main() {
  // TODO Check this address is right before deploying.
  const deployedProxyAddress = "<<< YOUR PROXY CONTRACT ADDRESS HERE >>>";

  const PriceFeedTrackerV2 = await ethers.getContractFactory(
    "PriceFeedTrackerV2"
  );
  console.log("Upgrading PriceFeedTracker...");

  await upgrades.upgradeProxy(deployedProxyAddress, PriceFeedTrackerV2);
  console.log("PriceFeedTracker upgraded");
}

main(); 

Затем мы можем запустить сценарий с помощью

yarn hardhat run --network goerli scripts/upgrade_pricefeedtracker.js

И мы должны увидеть результат, который выглядит следующим образом

Compiled 2 Solidity files successfully
Upgrading PriceFeedTracker...
PriceFeedTracker upgraded

Обратите внимание, что адрес прокси не изменился. Но если вы вернетесь в Etherscan и посмотрите на испускаемые события вашего прокси-контракта, вы должны увидеть новое событие «Upgraded» и новый адрес контракта реализации.

Если развертывание вашего контракта занимает много времени, пожалуйста, прокрутите вниз до раздела этого блога, посвященного устранению неполадок.

Теперь давайте воспользуемся консолью Hardhat для взаимодействия с обновленным контрактом.

Выполните следующие команды, по одной за раз. Я рекомендую оставить 60-90 секунд после запроса цены, прежде чем проверять переменную состояния цены.

> var V2 = await ethers.getContractFactory("PriceFeedTrackerV2")
undefined

> var v2 = await V2.attach(///// INSERT PROXY CONTRACT ADDRESS /////)
undefined

// ETH/USD
> var ethusdTx = await v2.retrievePrice('0xD4a33860578De61DBAbDc8BFdb98FD742fA7028e') 
undefined

// Wait about 60-90 seconds then read the updated state variable.
> (await v2.price())
BigNumber { value: "150701000000" }

// Change to LINK/ETH
> var linkEthTx = await v2.retrievePrice('0xb4c4a493AB6356497713A78FFA6c60FB53517c63')

// Wait about 60-90 seconds then read the updated state variable.
> (await v2.price())
BigNumber { value: "4659009800000000" }

Вы заметите, что мы обновили переменную price, чтобы сохранить полученную цену из контракта агрегатора ETH/USD Price Feed, а затем снова из LINK/ETH Price Feed.

Вот и все! Вы только что обновили свой логический контракт, а контракт, с которым вы взаимодействуете (прокси-контракт), не изменился! Прокси-контракт делегирует вызовы логических функций логическому контракту, который зарегистрирован в прокси-контракте как последний логический контракт!

Устранение неполадок

Существует несколько проблем, которые могут возникнуть при выполнении транзакций с обновляемыми контрактами в сети Goerli. Одна из проблем, с которой я столкнулся во время написания этого блога, заключалась в том, что мои транзакции застревали в mempool. Это происходило потому, что количество газа, отправляемого из моего кошелька, было меньше, чем требовалось сети в то время — на момент написания статьи в Goerli наблюдались скачки газа. Не было никаких ошибок, указывающих на то, что это произошло, поэтому мне потребовалось время, чтобы разобраться! Я использую Alchemy в качестве RPC-провайдера для подключения к Goerli, поэтому я нашел это видео, которое помогло мне разобраться. Я создал этот сценарий для запуска в качестве сценария Hardhat, который помог мне очистить транзакции mempool.

Также обратите внимание, что лучше всего подождать около 60 секунд после любой транзакции, которая изменяет состояние блокчейна. Например, чтение из переменной хранения цены слишком быстро после выполнения retrievePrice() вернет более старые данные из блокчейна, поскольку транзакции записи, изменяющие состояние, возможно, еще не были подтверждены блоками.

Заключение

Мы рассказали о том, как обновлять смарт-контракты, зачем это нужно и какова новая практика обновления смарт-контрактов. Мы изучили несколько паттернов проектирования, некоторые проблемы, которые могут поставить вас в тупик, а также запустили код для развертывания и обновления смарт-контракта, который потребляет данные из Price Feeds.

Телеграм канал про web3 разработку, смарт-контракты и оракулы.

Всем привет! В этой статье я расскажу вам, как за 5 минут и несколько команд в терминале запустить смарт-контракт сбора денег для своего ICO на Ethereum. Этот очерк потенциально сэкономит вам десятки тысяч американских долларов, так как любой программист — да и не программист тоже — сможет запустить проаудированный и безопасный смарт-контракт (вместо того, чтобы платить $15,000 – $75,000 за разработку). Вкратце, на этот смарт-контракт можно будет отправить денег и получить за это ERC20 токены. Можно сказать, эта статья — сборник всего опыта, который я получил, запуская ICO для своего проекта.

В Интернетах этих ваших и так полно статьей про смарт-контракты, но как только начинаешь писать оный, сталкиваешься с тем, что информация везде повторяется, а туториалов, как запулить свой ERC20 попросту либо нет, либо они устарели что аж донельзя. К слову, чтобы эта статья оставалась актуальной, постараюсь указать потенциальные места, где она может устареть (и как это поправить). Поехали!

Solidity

Это название главного языка, который разработала команда кефира для запуска смарт-контрактов. Если вы программист, то просто пробегитесь глазами по документации языка — он неприлично простой. К слову, сделали его простым, чтобы было сложнее ошибиться в написании смарт-контракта. Так что абсолютно любой программист хотя бы уровня джуниора сможет разобраться в нем. Абсолютно нет смысла платить огромные деньги разработчикам, которые знают солидити — обучить уже существующего разработчика будет на порядок дешевле.

Смарт-контракты

… и все, что вам нужно о них знать. Пропустите эту секцию, если вы не программист. Смарт-контракт — это кусок кода. В принципе, это класс в солидити (ООП, да), у которого есть два типа функций: изменяющие состояние и не изменяющие. Ну и чтобы запускать функции в смарт-контракте просто отправив на него кефир, нужно эту функции пометить payable.

Состояние — это хранилище данных, блокчейн, епта. Контракты могут изменять блокчейн (состояние, хранилище) — но чтобы изменить блокчейн нужно заплатить кефира майнерам. Как они будут делить кефир разбирать не будем в рамках этой статьи. Оплата майнерам за запуск кода, изменяющий состояние, называется Газом (Gas). Если кто-то извне закинет кефира на адрес смарт-контракта с вызовом функции, помеченной payable, но не помеченной Constant, View или Pure, то из отправленной суммы будет вычтено нужное количество кефира для оплаты майнерам. Обычно в ERC20 токенах это функции, которые либо выдают отправителю токенов за кефир, либо переводят токены от одного держателя токенов другому.

А если вы пометите функцию в контракте словами Constant или View (означают одно и то же, разрешают только читать состояние), либо Pure (то же самое, только даже состояние не читает), то на исполнение этой функции даже кефир тратить не нужно будет! Даже больше скажу, эти функции не нужно вызывать транзакциями — ведь любой клиент кефира, теоретически, сможет ее выполнить у себя — и никому больше об этом знать не нужно (в блокчейн ведь ничего не пишется).

А еще есть две важные штуки в солидити: множественное наследование и модификаторы функций. Про них тоже нужно знать.

Первое — просто контракты могут наследоваться одновременно с нескольких классов типа TimedCrowdsale, CappedCrowdsale, MintedCrowdsale, Ownable — при этом функции конструкторов тоже запускаются друг за другом — но это я объясню на примере уже дальше.

Второе — это возможности создавать функции, которые потом будут вставлены в другие функции. Это как простая инкапсуляция, только чуть более гибкая — это буквально шаблон функции. Когда вы создаете модификатор, вы пишете специальный символ _ там, где подразумеваете код функции, использующей этот модификатор. То есть модификаторы — это не просто инкапсулированный функционал, который возвращает значение; это — шаблон функции, когда код из модификатора буквально вставляется в функцию, использующую этот модификатор.

Перейдем к практике.

Готовим окружение

Если вы не знаете, что такое Терминал — почитайте вот эту статью. Если вы на окнах, ставьте себе Терминал через WLS. Если вы уже знакомы с Терминалом, продолжим. Алсо, сразу поставьте себе Node.js — он будет необходим для следующих шагов. Лучше ставить LTS, но, на самом деле, абсолютно без разницы, какую из современных версий ноды ставить.

Первое, что мы сразу поставим и запустим процесс синхронизации блоков — это geth. Короче, это утилита, написанная на Go, которая позволит нам запускать ноду эфира на локальном компе и коннектиться к тестовой и реальной сети. Установить можно через инсталяторы, но я крайне советую фигачить geth сразу в Терминал, как описано вот тут. Проверить, установился ли у вас норм geth, можно, запустив команду в Терминале:

geth version

Если вам выплюнуло версию geth — все в ажуре, продолжаем туториал. Если нет — хреново, исправляйте; придется, похоже, заняться любовными ласками с Терминалом и своей операционной системой — но вам не впервой, разберетесь. Как установите geth, запускайте в Терминале команду:

geth --testnet console

Это запустит процесс синхронизации вашей ноды с тестовым сервером, блоки которого можно глянуть вот тут. Проверить, синхронизировались ли вы с сетью в консоли geth можно, прописав:

eth.blockNumber # если 0 — то еще не синхронизировались
eth.syncing # выплюнет прогресс синхронизации или false, если ничего не происходит

Процесс синхронизации у меня занимал от 1 до 4 часов — когда как. Алсо, помимо синхронизации блоков, придется ждать еще и синхронизации состояний — это чаще дольше, чем синхронизация блоков. Также можно использовать команды geth с флагом --light — тогда синхронизация длится от нескольких секунд до минуты и вы все еще можете деплоить контракты.

Ладно, первую утилиту мы поставили — ставим следующую. Нам нужно поставить аналог geth, только совсем уж локальную симуляцию блокчейна — testrpc. Да-да, у нас 3 блокчейна:

• testrpc — локальная симуляция блокчейна; быстрая, но ненастоящяя и хранится только у вас на машине
• geth --testnet — уже реальный блокчейн, но тестовая сеть, где можно бесплатно получать кефир и тестить всякие непотребства, денег не потеряете
• geth — мейннет, главный, реальный блокчейн, настоящий кефир; все по-взрослому, ошибки тут — потери реального кефира

Соответственно, начнем мы тест контрактов с testrpc, потом задеплоим в geth --testnet, а потом зафигачим прямо в geth.

Ставим testrpc, запустив следующую команду:

npm install -g ethereumjs-testrpc

Ну или встанет сразу с трюфелем, так как теперь testrpc под крылом трюфеля и зовется ganache-cli. Хотя черт его знает, у меня все и с ванильным testrpc сработало. А если работает — не трогай, как учили меня в межгалактической академии. Можно еще его и запустить, чтобы проверить установку, прописав truffle в консоли, но у нас уже синхронизируется тестовый блокчейн — не будем ему мешать.

Ну что, разобрались с блокчейнами? Ноды теперь есть и тестовая даже синхронизируется? Ставим удобную утилиту для работы со смарт-контрактами на кефире — truffle, следующей командой:

npm install -g truffle
truffle version # сразу чекнем, установился ли, проверив версию

Трюфель — это тулза, которая позволяет держать смарт-контракты в разных файлах, импортировать другие файлы, а так же компилирует ваш код смарт-контрактов в один большой байт-код (нечитаемый человеком), автоматически находит у вас локально запущенный geth (тестовый и реальный) или testrpc, деплоит ваш смарт-контракт в эту сеть. Алсо, проверяет ваш код смарт-контракта на ошибки и с недавних пор еще и дебажить помогает завершенные транзакции. Мастхев, короче.

На этом этапе у вас должны быть установлены: testrpc, geth, truffle — если чего-то из этого нет или версия не выплевывается в консоль по запросу, то поправьте это; иначе не получится у вас ничего.

Алсо, я накидал простенький баш-скриптик, который установит все за вас. Вызывается вот так:

source <(curl -s https://raw.githubusercontent.com/backmeupplz/eth-installer/master/install.sh)

— но я его ни разу не тестил еще, так что не уверен в его работоспособности. Однако пулл-реквестам буду только рад.

Фигачим контракт

За вас все уже придумано и написано — это хорошо. Немного головняка будет все равно — но я постараюсь вам его минимизировать. Использовать мы будем уже готовые ERC20 контракты от OpenZeppelin — это сейчас стандарт индустрии, они прошли аудит, да и вообще все их код используют. Спасибо им огромное за вклад в опенсоус.

Сделайте cd в какую-нибудь безопасную папку и после пропишите:

mkdir contract && cd contract

В этой папке и будем работать. Создадим здесь заглушку для нашего смарт-контракта:

truffle init

Зашибись, четко. У нас теперь есть две очень важные папки, в которые мы и будем лезть: contracts и migrations. Первая — код наших контрактов, вторая — код для truffle, чтобы знать, что делать при деплое контрактов в блокчейн.

Дальше нам нужно забрать текущий код смарт-контрактов из npm и, собственно говоря, начать сам проект:

npm init -y # создадим проект без вопросов (флаг -y)
npm install -E openzeppelin-solidity # заберем контракты и зафиксируем текущую версию (флаг -E)

Отлично, код смарт-контрактов от OpenZeppelin у нас в кармане в папке node_modules/openzeppelin-solidity/contracts. Теперь заходим в главную папку contracts, удаляем там все файлы и добавляем файлы MyToken.sol и MyCrowdsale.sol — естественно, свои контракты вы назовете иначе. Первый будет контрактом на наш ERC20 Токен, а второй — контрактом нашего ICO, который будет принимать кефир и раздавать людям MyToken. Эта статья может устареть, но вы всегда можете глянуть, как OpenZeppelin предлагают вам создавать контракты у них в репозитории. Вот так у нас будет выглядеть MyToken.sol:

pragma solidity ^0.4.23;

// Imports
import "../node_modules/openzeppelin-solidity/contracts/token/ERC20/MintableToken.sol";

// Main token smart contract
contract MyToken is MintableToken {
  string public constant name = "My Token";
  string public constant symbol = "MTKN";
  uint8 public constant decimals = 18;
}

Найс — у вас есть смарт-контракт собственного токена (только смените названия в константах)! Можете глянуть, что там за наследование от MintableToken — но там все максимально просто. Это токен, который можно выпускать (от англ. «Mint» — чеканить), и выпускать его имеет право только владелец, так как MintableToken еще и наследуется от Ownable. Алсо, MintableToken еще и наследуется от классов ERC20 токенов, написанных OpenZeppelin, в которых и реализован интерфейс ERC20:

contract ERC20Basic {
  function totalSupply() public view returns (uint256);
  function balanceOf(address who) public view returns (uint256);
  function transfer(address to, uint256 value) public returns (bool);
  event Transfer(address indexed from, address indexed to, uint256 value);
}

Ага, вот вам и весь ERC20 интерфейс. Сложно? Не думаю. Дает возможность глянуть, сколько было выпущено токенов, проверить баланс адреса и перевести токенов на другой адрес, выплюнув в сеть событие перевода для легких клиентов кефира. И все это вы получаете фор фри в вашем MyToken.sol благодаря работе OpenZeppelin — они молодцы.

А теперь перейдем к главной части нашего ICO — нам же нужно принимать кефиры и раздавать MyToken! Вот так будет выглядеть ваш MyCrowdsale.sol:

pragma solidity ^0.4.23;

// Imports
import "../node_modules/openzeppelin-solidity/contracts/crowdsale/emission/MintedCrowdsale.sol";
import "../node_modules/openzeppelin-solidity/contracts/crowdsale/distribution/RefundableCrowdsale.sol";
import "../node_modules/openzeppelin-solidity/contracts/crowdsale/validation/CappedCrowdsale.sol";
import "../node_modules/openzeppelin-solidity/contracts/token/ERC20/MintableToken.sol";

contract MyCrowdsale is CappedCrowdsale, RefundableCrowdsale, MintedCrowdsale {
 constructor(
  uint256 _openingTime,
  uint256 _closingTime,
  uint256 _rate,
  address _wallet,
  uint256 _cap,
  MintableToken _token,
  uint256 _goal
 )
  public
  Crowdsale(_rate, _wallet, _token)
  CappedCrowdsale(_cap)
  TimedCrowdsale(_openingTime, _closingTime)
  RefundableCrowdsale(_goal)
 {
  // Это тут просто, чтобы показать, что можно сделать
  // Проверяем, что софткеп ниже хардкепа
  require(_goal <= _cap);
 }
}

Так-так-так, что тут у нас? Что, пацаны, смарт-контракты? Наша публичная продажа токенов наследует три самых популярных свойства: у нее есть хард-кап, больше которого собрать не получится; софт-кап, не собрав который эфиры возвращаются; время начало и конца продажи токенов. Собственно говоря, а что еще для счастья нужно?

Программисты, обратите внимание, как конструкторы классов множественного наследования выстроены в ряд и получают аргументы из главного конструктора MyCrowdsale. Алсо, мы проверяем, что хардкеп у нас выше софткепа — алес гут! Алсо, не пугайтесь туче параметров в конструкторе MyCrowdsale — мы передадим их на этапе деплоя контракта в трюфеле.

Вот и все — у вас есть готовые контракты вашего собственного ERC20 токена и даже смарт-контракт ICO, который настраивается по вашему желанию и раздает ваши токены за кефир. Алсо, его поддерживают все ERC20 кошельки — ляпота! Перейдем к ручным тестам и деплою.

Миграции

Как я уже говорил ранее, тестировать мы будем последовательно на трех блокчейн-сетях, но процесс тестирования ручками всегда будет один и тот же. Начнем с testrpc, потом перейдем к geth --testnet и дальше в geth. Соу фар мы только писали код, давайте его попробуем скомпилировать. В папке проекта пропишите:

truffle compile

Если все скомпилировалось без проблем — то у вас появится папочка build, в которой будет содержаться кракозябра для трюфеля, чтобы он смог задеплоить в блокчейн байт-код ваших смарт-контрактов. Перед тем, как деплоить смарт-контракты, нам нужно рассказать трюфелю, что вообще нужно делать. Деплой смарт-контрактов в трюфеле называется миграцией — ну, что же, будем придерживаться этой терминологии. Зайдите в migrations/1_initial_migration.js и измените его следующим способом:

const token = artifacts.require("../contracts/MyToken.sol");
const crowdsale = artifacts.require("../contracts/MyCrowdsale.sol");

module.exports = function(deployer, network, accounts) {
    const openingTime = 1514764800; // 15 Июня 2018
    const closingTime = 1561939200; // 1 Июля 2019
    const rate = new web3.BigNumber(1); // 1 токен за 1 эфир
    const wallet = '0x281055afc982d96fab65b3a49cac8b878184cb16'; // Кошелек-бенефициар
    const cap = 200 * 1000000; // Хардкеп
    const goal = 100 * 1000000; // Софткеп

    return deployer
        .then(() => {
            return deployer.deploy(token);
        })
        .then(() => {
            return deployer.deploy(
                crowdsale,
                openingTime,
                closingTime,
                rate,
                wallet,
                cap,
                token.address,
                goal
            );
        })
        .then(() => {
            // Crowdsale должен владеть токеном
            var tokenContract = web3.eth.contract(token.abi).at(token.address);
            web3.eth.defaultAccount = web3.eth.accounts[0];
            tokenContract.transferOwnership(crowdsale.address);
        });
};

Это тот самый файл, который будет использоваться трюфелем для деплоя контрактов. Что же мы тут такого наворотили? Во-первых, мы запросили скомпилированные MyToken и MyCrowdsale. После, мы установили константы со всеми аргументами нашего ICO — установили время начала и конца; сколько токенов будут получать люди за 1 вей кефира (0.000000000000000001 eth = 1 wei; установка decimals указывает, сколько нужно порядков wei, чтобы получить 1 ваш новоиспеченный токен); кошелек, куда придут полученные на продаже кефиры; хард-кеп и софт-кеп. Учтите, что openingTime всегда должен быть после времени текущего блока в блокчейне — иначе ваш смарт-контракт не задеплоится из-за проверки условия в TimedCrowdsale. Я на эти грабли наступал, а провалившиеся транзакции вообще никак не получается дебажить. Меняйте эти константы по своему усмотрению.

Следующий шаг — это именно деплой смарт-контрактов. Тут ничего интересного: у нас есть объект deployer, который деплоит артефакты смарт-контрактов и передает туда аргументы. Заметьте, что сначала деплоится MyToken, и только потом MyCrowdsale — и во второй передается аргументом адрес первого.

Дальше самое интересное — то, о чем не пишут ни в документации, ни в книжках. Когда вы создаете с кошелька MyToken, этот кошелек становится владельцем MyToken по суперклассу Ownable — то же самое происходит и с MyCrowdsale. Если глубоко копнуть в MintableToken, то можно увидеть, что чеканить монеты-то может только Owner! А кто владелец MyToken? Правильно: адрес, который его и задеплоил. А кто будет отправлять запросы на чеканку монет? Правильно: смарт-контракт MyCrowdsale. Напомню, что адрес, создавший MyToken и адрес MyCrowdsale — это два разных адреса.

Поэтому у нас добавляется неправославный третий шаг деплоя, где адрес, задеплоивший контракты (web3.eth.accounts[0]) вызывает функцию transferOwnership на контракте MyToken, чтобы MyCrowdsale владел MyToken и мог чеканить монеты. А MyCrowdsale все еще под владением web3.eth.accounts[0] — так что все пучком.

Заметка про web3.eth.accounts[0]: когда деплоите смарт-контракт, убедитесь, что geth или testrpc имеют правильный кошелек в web3.eth.accounts[0] — не теряйте приватный ключ к нему, хоть это никак вам не навредит, но вдруг владельцу что-нибудь потом нужно будет сделать, а ключа уже нет?

В testrpc, как правило, аккаунты создаются сразу при запуске и они сразу же разлочиваются; однако на тестовом и реальном блокчейне эфира стоит создать аккаунт через personal.newAccount() — дальше пополнить этот адрес через Faucet на тестовом блокчейне или реальным кефиром на реальном блокчейне. Не теряйте пароль и приватные ключи.

Алсо, вы можете в аккаунты добавить уже существующий кошелек, вызвав web3.personal.importRawKey('pvt_key', 'password'), но для этого нужно вызывать geth с дополнительным параметром --rpcapi="db,eth,net,web3,personal,web3". Думаю, разберетесь.

Тестирование и деплой

Йес, контракты готовы, миграции написаны, осталось только задеплоить и проверить. Как geth (тестовый и реальный), так и testrpc управляются одинаково через truffle console — так что опишу способ проверки для testrpc и просто расскажу, как включить geth после. И так, запускаем тестовый локальный блокчейн кефира:

testrpc

Эм… вот и все. У вас локально работает симуляция блокчейна кефира.

А чтобы задеплоить в тестовый блокчейн эфира, вы вместо этой команды сделаете geth --testnet --rpc. А чтобы задеплоить в реальный блокчейн эфира, вы пропишите просто geth --rpc. Флаг --rpc нужен, чтобы трюфель смог подключиться. Следующие шаги деплоя и теста более-менее одинаковы для всех трех типов блокчейна. Единственное что — после того, как вы запустите тестовый или реальный блокчейн через geth, он начнет синхронизировать блоки — а это может занять до 4-5 часов на хорошем Интернет-соединении. Ремарка про эта была в самом начале статьи. Перед деплоем смарт-контрактов рекомендую дождаться полной синхронизации. Алсо, блокчейн весит в районе 60-100 гигабайт, так что подготовьте для этого место на диске.

Алсо-алсо, убедитесь, что web3.eth.accounts[0] разлочен. Обычно можно прописать в консоли testrpc, которая открывается сразу, либо в отдельном окошке Терминала в консоли, которая открывается через geth console: eth.unlockAccount(eth.accounts[0], "Пароль, полученный при создании учетки", 24*3600) — это разлочит ваш аккаунт, который должен создать смарт-контракт

Теперь открываем новое окошко Терминала (testrpc не закрываем — он должен работать) и прописываем в папке проекта:

truffle migrate --reset

Эта магическая команда скомпилирует смарт-контракт (то есть не нужно каждый раз писать truffle compile) и задеплоит его на микро-сервер блокчейна, найденный открытым локально. Стоит отметить, что если testrpc сделает это мгновенно, то тестовый и реальный блокчейны будут гораздо дольше включать транзакцию в следующие блоки. После этого у вас должно выплюнуться нечто подобное в консольку:

Using network 'development'.

Running migration: 1_initial_migration.js
 Running step...
 Replacing MyToken...
 ... 0x86a7090b0a279f8befc95b38fa8bee6918df30928dda0a3c48416454e2082b65
 MyToken: 0x2dc35f255e56f06bd2935f5a49a0033548d85477
 Replacing MyCrowdsale...
 ... 0xf0aab5d550f363478ac426dc2aff570302a576282c6c2c4e91205a7a3dea5d72
 MyCrowdsale: 0xaac611907f12d5ebe89648d6459c1c81eca78151
 ... 0x459303aa0b79be2dc2c8041dd48493f2d0e109fac19588f50c0ac664f34c7e30
Saving artifacts...

Думаю, вы уже поняли, что консолька вам выдала адреса смарт-контрактов MyToken и MyCrowdsale. Все! Смарт-контракт задеплоен в тот блокчейн, микро-сервер которого у вас открыт. Осталось лишь проверить, что токены и вправду раздаются юзерам, которые присылают кефир на смарт-контракт MyCrowdsale. Прописываем в Терминале следующее, чтобы зайти в консоль трюфеля:

truffle console

Прописываем следующее в теперь уже трюфеле (без комментариев только):

// Сохраняем адреса смарт-контрактов
t="0x2dc35f255e56f06bd2935f5a49a0033548d85477" // Замените на адрес своего MyToken
с="0xaac611907f12d5ebe89648d6459c1c81eca78151" // Замените на адрес своего MyCrowdsale

// Получаем инстансы смарт-контрактов
token=MyToken.at(t)
crowdsale=MyCrowdsale.at(c)

// Сохраним аккаунт в более короткое имя
account=web3.eth.accounts[0]

// Проверяем, сколько токенов у нашего аккаунта
token.balanceOf(account) // должно быть 0

// Отправляем кефира на смарт-контракт
web3.eth.sendTransaction({from: account, to:c, value: web3.toWei(0.1, 'ether'), gas: 900000})

В случае с testrpc можно сразу же проверять снова баланс нашего кошелька, но в случае с тестовым и реальным блокчейном нужно подождать, пока транзакция наша будет включена в блок — обычно, когда это происходит, трюфель выдает вам номер транзакции. Подождали? Проверяем снова наш баланс в MyToken:

// Проверяем, сколько токенов у нашего аккаунта
token.balanceOf(account) // должно быть больше нуля

Вот и все! Сначала тестите свой контракт на testrpc, потом на geth --testnet, потом деплойте на geth. Вот и запустили вы свое собственное ICO! И не пришлось вам тратить десятки килобаксов на аудит и запуск. Накосячить с тем, что нам предоставили ребята из OpenZeppelin, на самом деле, очень сложно. А когда вы используете truffle — так разработка на солидити вообще в сказку превращается. Ну, кроме случаев, когда транзакции ревертятся еще во время выполнения на смарт-контракте — дебажить их сущий ад. Но дебаггинг смарт-контрактов, воистину, достоин отдельной статьи.

Заключение

Огромное спасибо, что дочитали до конца этой статьи! Если мне удалось сэкономить вам время или деньги, либо если вы узнали что-то новое из этой статьи, то я этому буду очень рад. Буду так же очень признателен, если поделитесь этой статьей со своими друзьями или знакомыми, которые хотят провести ICO — сэкономьте им $75,000 на недо-программистов, которые высасывают деньги из крипто-рынка, как паразиты, копи-пастя одни и те же 25 строк кода.

Удачи в разработке смарт-контрактов! Остались вопросы? Милости прошу в комментарии — с удовольствием на все отвечу и постараюсь помочь с проблемами.

Бонус

А что, если вы хотите изменить логику, по которой считается цена покупки токенов? Конечно, можно изменить правильно rate или использовать один из классов контрактов от OpenZeppelin, но вдруг вы хотите чего-нибудь еще более извращенного? В смарт-контракте можно оверрайтнуть функцию getTokenAmount следующим образом:

function _getTokenAmount(uint256 _weiAmount)
    internal view returns (uint256)
  {
    if (block.timestamp < 1533081600) { // August 1st, 2018
      rate = rate * 4;
    } else if (block.timestamp < 1546300800) { // January 1st, 2019
      rate = rate * 2;
    }
    return _weiAmount.mul(rate);
  }

В общем, так можно сделать цену токена зависящей от времени покупки — чем дальше в лес, тем дороже токены. Не бойтесь экспериментировать и переписывать некоторые функции смарт-контрактов — это весело!

Новомодные словечки «блокчейн» и «смарт-контракты» сейчас можно часто услышать, и на них возлагаются большие надежды. Некоторые считают, что они способны привести к изменениям, подобным тем, что произошли с появлением Интернета, а также к исчезновению традиционных договоров, которые в будущем будут заключаться быстро и в цифровой форме — в виде программного кода. Что же на самом деле стоит за этими двумя терминами и как они связаны? И оправданы ли такие большие надежды? Давайте попробуем ответить на эти вопросы и понять, какие возможности открывает развитие блокчейна и смарт-контрактов как с практической, так и с юридической точки зрения.

Любая коммерческая деятельность сопряжена с заключением соглашений. И чаще всего это не один договор. Их может быть несколько сотен. Этот процесс требует множества действий персонала, и могут пройти недели или даже месяцы, прежде чем договор станет юридически действительным. Традиционные договоры требуют существенных затрат времени и денег из-за большого количества участвующих сторон. Кроме того, одним из основных недостатков таких договоров является то, что они могут быть обжалованы в суде. В настоящее время благодаря стремительному развитию технологий компании могут с легкостью автоматизировать свою текущую деятельность. Смарт-контракты для вас, если вы готовы обновить бизнес-логику, ускорить процессы, сократить административные затраты и бюрократию.

Почему технологию смарт-контрактов имеет смысл использовать в бизнес-логике?

Разработка смарт-контракта — это цифровой аналог заключения обычного договора. В его основе лежат протоколы блокчейна, которые регулируют условия контрактов между компаниями. В нем используется самоисполняющийся код на базе блокчейна. Смарт-контракты создаются таким образом, что должны быть выполнены все предусмотренные в них условия. Если что-то будет сделано не так, обмен валюты или активов не произойдет, и договор будет расторгнут. Смарт-контракты обеспечивают максимальную безопасность, прозрачность, эффективность и многое другое.

Зачем вам разрабатывать смарт-контракты?

Давайте рассмотрим все преимущества разработки смарт-контрактов:

• Отсутствие стресса. Не нужно искать адвокатов и нотариусов.
• Отсутствие бюрократии. Не нужно волноваться из-за несовершенного государственного регулирования.
• Децентрализация. Смарт-контракты имеют механизм самопроверки.
• Экономическая эффективность. Минимальное участие людей снижает затраты на обработку.
• Безопасность. Риск мошенничества исключен, так как смарт-контракт контролируется всей сетью.
• Надежная среда. После создания смарт-контракта код не может быть изменен.
• Автоматизация. Автоматизированное выполнение заказов.

Выберите собственную команду по разработке смарт-контрактов прямо сейчас, чтобы узнать о преимуществах технологии блокчейна.

Блокчейн-сеть и смарт-контракты: хороший способ решения юридических вопросов?

Технология блокчейна приобрела особенную популярность на фоне ажиотажа вокруг биткоина, поэтому она часто ассоциируется только с криптовалютами. Однако технология уже давно является независимой, а ее особый функционал можно использовать для самых разных целей. Блокчейн представляет собой сеть, к которой имеют доступ многочисленные участники. Сами участники выполняют роль резервных узлов в сети, что сводит к минимуму риск махинаций.

В сети информация (обычно транзакции) хранится в блоках. Как только блок заполнен, используется следующий блок, в итоге постепенно создается цепочка транзакций — цепочка из блоков. В результате формируется децентрализованный цифровой реестр. Это дает возможность не только просматривать текущее состояние хранимой в блоках информации, но и отслеживать всю историю с самого начала. Важно, чтобы информация была зашифрована, а из сохраненных данных было сформировано хэш-значение, то есть, контрольная сумма. Хэш-значение одного блока связано с предыдущим. Это сводит к минимуму риск махинаций: если значение изменено, вся цепочка теряет связность, и изменение становится очевидным. Главным побочным эффектом этого является отсутствие необходимости в участии банка, поэтому издержки (транзакционные) по большему счету исчезают.

Технология блокчейна идеально подходит для доказательства и документирования совершенных операций. Подлинность документов и информации разного рода можно быстро проверить. В Китае сеть блокчейна даже была принята в качестве доказательства в суде, и подобные попытки предпринимаются во многих других странах.

Смарт-контракт: больше, чем договор?

В то же время технология блокчейна сделала смарт-контракты более важными, и их потенциал может быть реализован полностью. Во-первых, смарт-контракты не являются соглашениями в классическом понимании и сами по себе не являются интеллектуальными. По сути, это компьютерные программы, которые при наступлении определенных событий выполняют заранее запрограммированные процессы, например, перевод средств или активацию доступа. Для этого условия и последствия наступления событий формулируются и фиксируются в программе.

Пользователям следует учитывать, что договора в юридическом смысле не возникает. Во многих случаях смарт-контракты не удовлетворяют необходимым требованиям, когда для вступления договора в силу требуется собственноручная подпись. Поэтому на практике рекомендуется применять следующую модель: сначала заключить обычный договор, на основе которого пишется код смарт-контракта, который затем быстро и автономно обеспечивает исполнение ранее заключенного договора.

Хотя смарт-контракты пока еще не способны выполнять сложные юридические оценки, четкие причинно-следственные отношения могут быть реализованы быстро, за небольшую стоимость и безопасно. Этого достаточно для многих потенциальных договорных отношений, в которых процессы должны быть автоматизированы. Типичными примерами являются активация лицензии после оплаты лицензионного сбора, а также немедленная выплата компенсации в случае задержки поезда или самолета. В секторе Интернета вещей (IoT) возможны другие способы применения. Смарт-контракт может напрямую инициировать платеж во время зарядки электромобиля, а в случае 3D-принтера он может инициировать процесс печати после подтверждения авторизации.

Разработка смарт-контрактов поможет вашему бизнесу идти в ногу со временем. Используйте это решение в блокчейн-сетях, чтобы заключать договоры онлайн. Разработка смарт-контрактов повышает степень прозрачности вашего бизнеса.

Разработка смарт-контрактов и блокчейна: отличная комбинация

Смарт-контракты не обязательно должны работать на блокчейне, но блокчейн-сети обеспечивают следующие преимущества для смарт-контрактов. Блокчейн отличается от обычных договоров высоким уровнем защиты от махинаций, что повышает доверие сторон. Кроме того, четкое и недвусмысленное указание условий до запуска смарт-контракта, а также последующее автоматическое и обязательное их выполнение позволяют избежать нежелательных судебных разбирательств. Смарт-контракт даже способен заменить собой арбитражную комиссию. Эта ясность значительно снижает вероятность возникновения споров, однако это достигается только в том случае, если условия смарт-контракта заранее прошли полноценную юридическую проверку и соответствуют волеизъявлению двух или более сторон, а также применимым законам.

Это конец классических договорных отношений?

Почему же мы до сих пор используем бумажные договоры, спросите вы. Но прогнозы о том, что блокчейн и смарт-контракты полностью заменят собой значительную часть судебной системы или классические договорные отношения, вряд ли сбудутся в ближайшем будущем, несмотря на всю эйфорию. Также вызывает сомнения, нужно ли нам это вообще. В конце концов, контракты — это не что иное, как зафиксированные, последовательные заявления о намерениях договаривающихся сторон. Даже в эру цифровых технологий стороны не захотят заключать какие-либо соглашения в отсутствие заявлений о намерениях, поэтому эти требования будут продолжать действовать, а смарт-контракты, возможно, будут интегрированы в существующую правовую систему.

Однако, несмотря на высокий уровень безопасности и эффективности, использование блокчейна сопряжено с проблемами. Быстро растущий объем данных, которые необходимо хранить на всех компьютерах-участниках сети, требует значительных технических ресурсов, поэтому возможности применения блокчейна также ограничены, и пока неизвестно, что будет с проблемой производительности в дальнейшем. С юридической точки зрения тоже не все так просто. Как упоминалось выше, практическое применение должно ограничиваться тем, что технически осуществимо на данный момент, а юридически сложные вопросы, в частности, употребление и толкование расплывчатой юридической терминологии, не должны решаться с помощью смарт-контрактов.

Также необходимо прояснить аспекты защиты данных. Любой, кто использует смарт-контракты в блокчейне и действует на основании согласия в соответствии с законом о защите данных, должен знать, что записи в блокчейне нельзя просто удалить, поэтому возникают проблемы в случае необходимости отозвать согласие.

Разработка смарт-контрактов на блокчейне

Процесс разработки смарт-контрактов основан на технологии блокчейна. Для расчетов используются цифровые валюты. Самой популярной и одной из лучших платформ для создания смарт-контрактов является блокчейн ETH. Для написания смарт-контрактов в сети Ethereum используется язык Solidity. У всех участников сети имеется копия кода смарт-контракта. Эти контракты полностью прозрачны для всех участников блокчейна. Таким образом, условия контракта не могут быть изменены так, чтобы об этом не узнала вся сеть. При этом не стоит волноваться о том, в сеть попадут данные о личностях сторон и условиях соглашения. Смарт-контракты считаются одним из лучших инструментов по соображениям безопасности.

Виртуальная машина и блокчейн Ethereum

Разработка смарт-контрактов используется в различных отраслях:

• финансы;
• международная торговля;
• бухгалтерский учет;
• здравоохранение;
• страхование;
• логистика;
• образование;
• недвижимость.

Вы можете создать собственный смарт-контракт для осуществления платежей, обмена товарами или криптовалютами, запуска ICO, организации краудфандинговых кампаний и не только. Ограничений нет. Просто попробуйте воспользоваться преимуществами разработки смарт-контрактов, найдя подходящую компанию по разработке смарт-контрактов. Стоимость смарт-контрактов зависит от компании, которая занимается их разработкой. Выберите разработчика смарт-контрактов и создавайте высокотехнологичные решения для своей компании.

Что вам нужно знать о процессе разработки смарт-контрактов?

Разработка смарт-контракта — это сложный процесс, состоящий из нескольких этапов. Сложность разработки смарт-контракта зависит от следующих параметров:

• сложность алгоритма;
• многозадачность;
• уровень надежности;
• персонализация;
• опыт программистов.

Это также влияет на стоимость разработки смарт-контрактов. Получите более подробную информацию у разработчиков. Смарт-контракты эффективнее традиционных договоров, и вы сможете отслеживать все транзакции с помощью смарт-контрактов и технологии блокчейн.