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

Metropolis

Следующий релиз протокола Эфириума называется Metropolis. Он представляет собой серию изменений, которые в сумме представляют собой более значительный шаг вперед, чем текущий релиз Homestead по сравнению с предыдущим Frontier. Основные изменения включают:

  • EIP 86 (абстракция безопасности аккаунта) – переносит всю логику подтверждения подписей и одноразовых кодов из основного кода протокола в контракты, позволяя разработчикам экспериментировать с новыми схемами подписей, технологиями приватности и другими модификациями, не требуя новых хардфорков или поддержки на уровне основного протокола. Кроме того, контракты будут платить за газ самостоятельно.
  • EIP 96 (Изменения опкода blockhash и дерева состояний) – упрощают код протокола и основных клиентов, разработчики будут иметь возможность апгрейда легких клиентов, ускоряют синхронизацию и повышают безопасность.
  • Компилированные и встроенные контракты операций с эллиптическими кривыми и арифметикой больших целых чисел, упрощающие разработку приложений на основе кольцевых подписей и RSA криптографии.
  • Ряд небольших изменений, увеличивающих скорость прохождения транзакций.

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

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

Serenity: PoS, шардинг и криптоэкономика

После хардфорка Metropolis наступит время радикальных изменений: следующий релиз Serenity предусматривает изменение механизма консенсуса с PoW на PoS и реализацию механизма шардинга. Исследования PoS велись в течение всего года, и в результате тестов первоначальная модель протокола претерпела значительные изменения. Модель PoC (Доказательство концепции) №2, тесты которой проводились в начале года, была отвергнута, а за основу Casper была принята PoC №3, описание которой приводится в Лиловой Книге.

Долгое время над протоколом Casper параллельно работали две группы: одна, под руководством Виталика Бутерина, и другая, возглавляемая Владом Замфиром (Vlad Zamfir).

Вариант Бутерина представляет собой сознательно упрощенный PoS, целью которого было достижение целевых параметров при минимальных отличиях от PoW (этот вариант и описан в Лиловой Книге), в то время как вариант Замфира – это последовательное конструирование алгоритма с нуля. Обе концепции были представлены на конференции Девкон-2.

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

Основной темой стало определение общей стратегии оптимальной мотивации участников протоколов консенсуса, будь то протокол, основанный на единой цепи (Замфир), масштабируемый протокол шардинга (Бутерин), или даже версия протокола, устойчивого к "проблеме византийских генералов" (PBFT): существует ли общий способ корректного назначения вознаграждений и наказаний всем участникам, если использовать только подтвержденное доказательство событий в блокчейне и оптимальные параметры теории игр. Был выработан ряд концепций; одна из них, в качестве эксперимента примененная в PoW, стала средством против «эгоистической атаки майнинга», что станет крайне полезным и в PoS.

В разделе, посвященном криптоэкономике рассматривалось три вопроса.

  • Возможно ли удержать совместимость мотиваций, в модели со сговором большинства? Другими словами, даже если атакующий контролирует 90% сети, есть ли способ сделать так, что если атакующий отклоняется от протокола любым вредоносным способом, он теряет деньги? В случае краткосрочного форка ответ положительный. В других случаях все гораздо сложнее, пример: цензура.
  • Определение «факторов ущерба» – создание таких условий, при которых атакующий не может нанести другим определенный ущерб, не потеряв при этом, по меньшей мере, такой же суммы.
  • Обеспечение работы протокола при произвольных экстремальных условиях: например, если одновременно отключаются 60% узлов валидаторов. Традиционные консенсусы, такие как PBFT, или простой POS на основе PBFT в таком случае просто останавливаются; Casper продолжает работу – это нельзя назвать нормальным функционированием, но протокол работает.

Одним из основных результатов воркшопа стало начало объединения двух подходов Casper. Обе группы работают над созданием оптимальной комбинации, которая возьмет лучшее от обеих моделей.

Текущая техническая информация по работам над Casper выложена здесь:

Контроль размера состояния

Еще одна важная тема протокола – контроль размера состояния; как можно максимально уменьшить объем информации о состоянии сети, который полные узлы должны постоянно контролировать. Сейчас это примерно один гигабайт (данные, которые geth или parity записывают в истории транзакций; эти данные могут быть выделены в отдельную ветку, когда появится надежный протокол легкого клиента). Последние атаки с раздуванием сети наглядно показали как деградирует производительность клиентов с увеличением размера состояния. Дискуссия по поводу контроля размера продолжается, способов решения множество и остается найти оптимальный

И в заключение нужно отметить еще одну задачу: это интеграция ZK-SNARK – доказательства с нулевой информацией, технологии, заимствованной у Zcash, которая обещает быть крайне востребованной среди корпоративных пользователей. Конкретный метод реализации еще не определен: это может быть 1) явный опкод ZKP или прекомпилированный контракт, или 2) тоже опкод или контракт, но только для ключевых ресурсоемких элементов ZKP, таких как парные вычисления эллиптических кривых, используемых в алгоритме шифрования.

В ближайшие несколько месяцев ожидается выпуск детальной спецификации Casper, которая уже в виде кода сможет работать в тестовой сети.