cyberevents

7 лет назад

Не столь умные контракты: дилемма на дилемме. Спикер: Александр Чепурной (Часть 2)

Данная лекция - продолжение доклада Александра Чепурного, который посвящен дилеммам в умных контрактах.
(Вторая часть начинается с момента времени 01:14:10)

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

Разграничим понятия умные контракты и умные подписи:

Умная подпись - атрибут цифрового объекта, который связан с определенной программой

Умный контракт - субъект цифрового мира, автономный агент - кусок кода, который создается и далее может функционировать самостоятельно в заданной среде

В Эфириум помимо контракта существуют пользовательские счета, которые контролируются людьми. Соответственно, данные счета ассоциированы с публичными ключами.

Умный контракт не ассоциирован с ключом и содержит следующие компоненты:

Снимок экрана 2018-04-03 в 16.57.19.png

Идентификатор - адрес контракта
Баланс, который связан с умным контрактом
Код
Состояние

Маркетологи сети Эфириум утверждают, что блокчейн Эфириум - Децентрализованный Всемирный Компьютер, поскольку:

Сеть является хранилищем умных контрактов
Сообщения умным контрактам обрабатываются всеми узлами сети
Все узлы сети видят одно и то же состояние компьютера

В данном случае релевантно использовать термин реплицируемый компьютер вместо децентрализованного.

Отметить особенности данного компьютера:

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

Одна из основных проблем компьютера - постоянный рост состояния

Снимок экрана 2018-04-04 в 0.57.24.png

Рост базы данных, которая используется полным узлом Биткоина:

Снимок экрана 2018-04-04 в 1.00.43.png

Решение задачи

Можно загружать и проверять все блоки с начального момента времени.

Снимок экрана 2018-04-04 в 1.09.39.png

Но, поменять транзакции в блоке невозможно без изменения работы.

Снимок экрана 2018-04-04 в 1.17.47.png

Работа, как и транзакции в блоке, фиксируется через заголовок.

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

Соответственно, немногие запускают узел Эфириума в полном режиме. Чаще пользователи загружают в режиме fast в клиенте Geth.

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

Учитывая подобное допущение, встает вопрос безопасности режима fast

Детальную информацию можно узнать из статьи https://eprint.iacr.org/2018/219 , которая написана в соавторстве со спикером.

Отметим, что состояние валидации небезопасно хранить на жестком/SSD диске

Снимок экрана 2018-04-04 в 1.52.27.png

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

В свою очередь, использование медленного хранилища облегчает совершение атак

Снимок экрана 2018-04-04 в 2.04.10.png

По указанным ссылкам можно найти информацию о совершенных атаках в сетях Биткоин и Эфириум.

Варианты решения проблемы:

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

Вернемся к умным контрактам

Умный контракт в Эфириум создается путем отправки транзакции в сеть, которая содержит код. Данный код имеет определенную стадию инициализации.

Далее контракт взаимодействует с сообщениями

Снимок экрана 2018-04-04 в 2.33.17.png

Особенности смарт контрактов в Эфириуме:

Контракты реализованы на языке программирования, который позволяет писать Тьюринг полной программы
Вычисление ограничены газом - за каждую инструкцию виртуальной машины, за каждую инструкцию контракта при обработке сообщения необходимо платить
В виртуальной машине используется низкоуровневый язык и языки высокого уровня (Solidity, Serpent)

Дилемма №2

Подробная информация представлена в статье https://eprint.iacr.org/2015/702

Выдержка из статьи: «… рациональным майнерам выгодно пропускать валидацию блокчейна»

Это значит, что пропуск валидации блоков позволяет зарабатывать больше и, как следствие, блоки могут оказаться невалидными.

Снимок экрана 2018-04-04 в 9.39.34.png

График демонстрирует сложившуюся ситуацию, только с другого ракурса, иллюстрируя количество работы, которая была потрачена впустую, то есть потрачена не на основную цепочку.

Дилемма №3

Теоретический вопрос проблемы - является ли Эфириум система Тьюринг полным решением?

Практическое следствие - возможно ли заменить в 95% самых популярных умных контрактах данное псевдо полное решение более простым и анализируемым.

Выделим проблемы, с которыми сталкиваются разработчики

Тяжело генерировать случайность
Не всегда однозначное исполнение контрактов
Сложности при работе с языком Solidity
Постоянный учет цены и лимита на газ
Трудное взаимодействие платформы с внешним миром

Если у вас остались вопросы, можете задать их непосредственно спикеру лекции http://chepurnoy.org