Эта статья является продолжением цикла о написании умных контрактов на платформе Ethereum. В первой части я пообещал показать, как создать новую криптовалюту на Solidity (в мире блокчейна это является чем-то вроде аналога "Hello, world!"). Но на самом деле в этом нет смысла, так как об этом уже написано несколько хороших статей (пример из доков Solidity, пример с главной страницы Ethereum).


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


BTW все написанное ниже имеет чисто образовательный характер.



Общая идея


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


  • Оплата выкупа через *coin
  • Отправка некоторого ID зараженного ПК + ID транзакции преступникам
  • Получение ключа для расшифровки файлов

Вот эти три фрагмента системы мы и попытаемся перенести в блокчейн.


Общая структура проекта


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


Tool box


Писать будем на Solidity версии 0.4.2 (текущая версия на 26 октября 2016). В качестве среды разработки можно использовать онлайн компилятор или только что вышедшую онлайн платформу Ethereum studio. Последняя сделана на базе c9.io, но с фичами для разработки под Ethereum. Сам не пользовался, так как вышла только-только, но выглядит симпатично, хотя документацию ее создатели прячут, наверное, специально.


В качестве клиента-кошелька возьмем Mist, а так как мы делаем просто PoC, то и запускать все контракты будем на своем private блокчейне (как это сделать я рассказывал здесь). Так будет проще, дешевле (в смысле бесплатно) и быстрее.


Пишем код


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


pragma solidity ^0.4.2; // Указываем версию языка - любая, начиная с 0.4.2 до 0.5 не включительно

contract admin {
     // VARIABLES
     struct user {
          address addr;
          string name;  // '$uPeR_p0wner_1999'
          string desc;  // 'CEO & CTO'
     }

     user owner;
     mapping (address => user) adminInfo;
     mapping (address => bool) isAdmin;

     function admin (string _name, string _desc) {
          owner = user({
               addr : msg.sender, // msg - дефолтная переменная с информацией о пользователе
               name : _name,      // вызвавшем контракт. msg.sender - его адрес
               desc : _desc       // msg.value - сумма в wei, переданная контракту и т.д.
          });

          isAdmin[msg.sender] = true;
          adminInfo[msg.sender] = owner;
     }
}

Сам по себе код прост и понятен, благо синтаксис напоминает C++, JS, C, etc. На всякий случай напомню, что оператор struct позволяет создавать кастомные типы данных из уже имеющихся . Mapping, как можно догадаться реализует ассоциативный массив (dict в Python, map в C++).


Здесь мы создали переменную owner, в которой с помощью struct храним адрес, имя и какой-нибудь description для создателя контракта. Контракты в Ethereum имеют так называемый state, то есть в дальнейшем, когда кто-то вызовет контракт, мы сможем воспользоваться этой переменной.


Далее добавим функции, отвечающие за добавление / удаление администратора, вывод денег и уничтожение контракта. Здесь все вообще тривиально, кроме одной штуки — оператора event. Это очень симпатичный, с точки зрения UI и юзабилити вообще, оператор, который позволяет реализовать что-то вроде push уведомлений внутри контракта. Чуть нижу будет скриншот, из которого понятно, как это выглядит на практике.



         // EVENTS
     event adminAdded(address _address, string _name, string _desc);
     event adminRemoved(address _address, string _name, string _desc);
     event moneySend(address _address, uint _amount);

     // FUNCTIONS
     function addAdmin (address _address, string _name, string _desc) {
          if (owner.addr != msg.sender || isAdmin[_address]) throw;    // Только владелец может добавлять / удалять админов

          isAdmin[_address] = true;
          adminInfo[_address] = user({addr : _address, name : _name, desc : _desc});

          adminAdded(
              _address,
              _name,
              _desc
          ); // Call event
     }

     function removeAdmin (address _address) {
          if (owner.addr != msg.sender || !isAdmin[_address]) throw;

          isAdmin[_address] = false;
          adminRemoved(
              _address,
              adminInfo[_address].name,
              adminInfo[_address].desc
          ); // Call event
          delete adminInfo[_address];
     }

     function getMoneyOut(address _receiver, uint _amount) {
          if (owner.addr != msg.sender || _amount <= 0 || this.balance < _amount) throw;
          // Функцию может вызвать только владелец, требуемая сумма должна быть положительна
          // Последняя проверка - баланс контракта должен быть больше требуемой суммы

          if (_receiver.send(_amount)) moneySend(_receiver, _amount); // В случае успеха - вызвать event
     }

     function killContract () {
          if (owner.addr != msg.sender) throw;
          selfdestruct(owner.addr); // Все средства на счету контракта будут переведены на адрес владельца
     }

Весь этот код просто добавим внутри contract admin {...} после уже написанного и наш модуль для администрирования готов.


Заливаем в блокчейн и наслаждаемся результатом


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



А вот так выглядят обещанные event-ы:



Магазин


Сначала суть: мы просто сделаем очередь из уже оплаченных заявок на получение ключа. В нашем случае администраторы будут разгребать эту кучу руками (можно автоматизировать, но опять же — как нибудь в следующий раз) и добавлять для каждой заявки ключ в импровизированную БД (сделаем map вида _id > _key). ID, для простоты, у нас будет натуральным числом, а ключом будет string (например ссылка на pastebin).


Сам код поместился в 85 строк, вот он:


contract shop is admin {
    // VARIABLES
    uint[] orders; // Очередь из оплаченных заказов
    uint currentOrder = 0; // Номер последнего необработанного заказа
    mapping (uint => string) keys; // Пары ID - ключ

    // EVENTS
    event keyAdded(uint _ID, string _name, string _desc);
    event keyBought(address _address, uint _ID);

    // FUNCTIONS
    function buyKey(uint _ID) payable { // Без модификатора payable на функцию нельзя отправлять эфир
        if (msg.value < 15000000000000000000) throw; // Проверяем, что пользователь отправил нам минимум 15 этеров
        orders.push(_ID); // Добавляем его в массив оплаченных заказов

        keyBought(
            msg.sender,
            _ID
        );
    }

    function getKeyByID(uint _ID) returns (string) { // Таким специфическим образом указывается, что вернет функция
        return keys[_ID]; // Если ключ для этого ID еще не добавлен, то вернется пустая строка
    }

    function getLastOrder() returns (uint) {
        if (!isAdmin[msg.sender]) throw;
        return orders[currentOrder]; // Возвращаем первый ID
        currentOrder += 1;
    }

    function addKey(uint _ID, string _key) {
        if (!isAdmin[msg.sender]) throw; // Только администратор может добавить ключ для какого-то ID
        keys[_ID] = _key;

        keyAdded(
            _ID,
            adminInfo[msg.sender].name,
            adminInfo[msg.sender].desc
        );
    }
}

Итог


Еще раз подчеркну, что написанное здесь — это прототип с кучей погрешностей и недоделок. Простой пример — в нашем случае массив заявок никак не чистится и только набирает в размере. Из-за этого, когда-нибудь стоимость вызова функции buyKey вырастет до стоимости самого ключа, что как-то неправильно.


Другой, более сложный момент — для того, чтобы хранить порядковый номер последнего обработанного заказа, мы используем переменную currentOrder. А теперь представим ситуацию — есть два админа: Вася в Пекине и Петя в Нью-Йорке. В один момент времени они обратились к функции getLastOrder и оба получили какой-то номер — пусть 23412. Далее каждый из них вызвал функцию addKey и добавил в "базу" ключ для этого заказа, а вместе с ним сохранился его name и desc. В результате, когда майнеры начинают выполнять эти действия, те что поближе к Пекину, быстрее выполнят Васин запрос и state будет иметь один вид, а те что поближе к Нью-Йорку — Петин и state получится другой. В результате какой-то merge conflict.


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


В следующей статье скорее всего напишу, как прикручивать к контрактам интерфейсы отличные от Mist (например взаимодействие через обычный сайт) ну или как работать с Ethereum в связке с каким-нибудь языком программирования, например Python. Но если есть какие-то предложения — обязательно пишите в комментарии.

Поделиться с друзьями
-->

Комментарии (0)