В апреле Block.one объявили о полном запуске EOSIO 3.0. Этот предварительный релиз представляет собой важную веху на пути к EOSIO 1.0, которая выйдет в июне 2018 года. За 4 месяца после выпуска EOSIO 2.0 командой разработчиков было внедрено множество инноваций. Многие из функций, которые внедрены в версии 3.0, даже не рассматривались в оригинальной WhitePaper EOSIO, но были добавлены в процессе создания платформы, которая является эффективной, гибкой и простой в разработке. Рассмотрим, как проект позиционируется самой командой.
Возможности масштабируемости EOSIO 3.0
Масштабируемость означает способность «расширяться» для удовлетворения рыночного спроса. На каждом шагу наша команда учитывала будущие потребности в масштабировании в дизайне. Тем не менее, версия 3.0 реализует лишь часть потенциальных оптимизаций, которые позволят EOSIO масштабироваться до нужного порядка. Мы разработали EOSIO, чтобы будущие версии могли использовать параллельные вычисления для ускорения пропускной способности без существенных изменений.
Интер-блокчейн
Связь между блочными цепями — это непревзойденная функция масштабирования, святой Грааль, который отрасль криптовалют ищет в таких предложениях, как сайдчейны, Plasma и шардинги. Связь между блочными цепями позволяет одной блочной цепочке проверять подлинность события на другой блок-цепочке в доказательно-защищенном виде. Цель состоит в том, чтобы межблочная связь была такой же безопасной, как внутрицепочная между интеллектуальными контрактами, и мы думаем, что мы достигли этой цели.
С нашей точки зрения, межблочная связь — это не что иное, как возможность реализовать легкий клиент в качестве смарт-контракта. Легкий клиент способен проверять транзакции из блокчейна, не обрабатывая целую цепочку. Таким образом, проверка правильности работы с клиентом должна учитываться в структуре протокола.
Проверка разрешенного заголовка
Ожидается, что традиционные легкие клиенты будут обрабатывать каждый заголовок блока, а затем подтверждать доказательства относительно этих заголовков блоков. Теперь, когда EOSIO может генерировать два блока каждую секунду, блок-цепочка потребует по меньшей мере 2 транзакций в секунду для обработки каждого заголовка блока.
Такое решение не масштабируется для сценариев, где не имеется частой межблочной связи. Чтобы решить эту проблему, мы создали первую блочную цепочку с византийской отказоустойчивой проверкой заголовка. В частности, для того, чтобы попытаться обмануть легкий клиент, требуется более 2/3 (например, 15+ из 21) производителей блоков. Кроме того, легким клиентам необходимо обрабатывать заголовки блоков, где изменяется набор активных производителей блоков, и те, которые содержат релевантные межблочные сообщения. Это значительно снижает накладные расходы при сохранении византийского отказоустойчивого легкого клиента и значительно повышает эффективность межблочной связи.
Бесплатные контекстные действия
Бесплатные контекстные действия являются одной из ключевых функций, которые обеспечивают эффективную межблочную связь. Они могут быть включены в транзакцию, но не зависят от состояния блока, следовательно, они являются «контекстно-свободными». Примером контекстного действия является проверка доказательства или подписи. Поскольку эти вычисления не имеют контекста, они могут быть проверены параллельно, а само вычисление может быть сокращено.
Каждое контекстно-свободное действие может также ссылаться на специальный раздел данных транзакции. Это означает, что большие доказательства Меркель можно обрезать, а их дорогостоящее вычисление может быть пропущено во время повторного воспроизведения последовательности блоков.
Контекстные бесплатные действия позволяют нам разделить подавляющее большинство служебных данных, связанных с межблочной связью. Они позволяют нам разделять и сокращать накладные расходы дорогостоящих методов конфиденциальности, таких как конфиденциальные транзакции, доказательства и zkSNARK.
Чтобы стимулировать использование контекстно-свободных действий, блокчейн-производители будут взимать с пользователей лишь часть использования ЦП, когда вычисление выполняется как часть контекстно-свободных действий, а не как часть традиционной транзакции.
Контекстно-свободные встроенные действия как события
Одной из особенностей, которую искали разработчики EOSIO версии 2.0, был эффективный способ генерации событий, которые обрабатываются внешними источниками. В Ethereum эти события используются для представления структурированной информации о внутренней работе контракта.
С добавлением контекстно-свободных действий мы также имеем возможность делать бесконтактные встроенные действия. Встроенное действие — это действие, которое генерируется кодом контракта и выполняется как часть текущей транзакции. Бесконфликтное встроенное действие может обрабатываться дешево и параллельно. Поскольку все встроенные действия также включены в корень Меркель, эти действия можно использовать как доказуемые уведомления для внешних служб и других цепочек.
Сжатие транзакций
Существует много транзакций, которые содержат сжимаемые данные. Одним из примеров подобных переводов является сам код WebAssembly-контракта. В некоторых приложениях, например, в социальных сетях также может потребоваться включить сжимаемый пользовательский контент в блок-цепочку.
Используя сжатие транзакции, блок-цепочка может более эффективно хранить и передавать большое количество транзакций.
Интерпретатор и компилятор «Just-In-Time»
Dawn 3.0 использует интерпретатор Binaryen WebAssembly по умолчанию, а не более быстрый компилятор Just-in-Time (JIT). Это решение снижает производительность, но повышает стабильность и соответствие стандартам, позволяя нам, когда это необходимо, переключаться в более высокую производительность JIT. Интерпретатор также решил одну из самых больших проблем, с которой мы столкнулись с версии 2.0: задержка, вызванная составлением контракта.
В будущем мы сможем использовать интерпретатор для выполнения недавно развернутых контрактов при компиляции и оптимизации контракта в фоновом режиме без задержек. Эта двойная реализация означает, что все наши модульные тесты проводятся как со скомпилированным, так и с интерпретированным кодом, поэтому мы сможем обнаружить нестандартное поведение, прежде чем мы начнем использовать гибридный подход.
Ограничение скорости ресурса
В версии EOSIO 3.0 теперь имеется совершенно новая система ограничения скорости ресурса. Возможно, самым большим изменением является введение объективного алгоритма подсчета операций. Когда мы планировали создать EOSIO, у нас была цель использовать полностью субъективное ограничение скорости. Мы обнаружили, что стоимость субъективного принуждения почти идентична объективному подходу. Теперь мы используем гибридное решение.
Одной из основных причин, по которым мы приняли этот подход — позволить отдельным транзакциям выполнить гораздо больше расчетов, чем это было возможно ранее. В настоящее время теоретически возможно, чтобы блок включал одну транзакцию, которая занимает 100 мс для запуска, тогда как при старой модели каждая транзакция должна была работать менее 1 мс.
Другим изменением ограничения скорости является разделение ограничений без необходимости определения токена. Это позволяет использовать EOSIO в частных, разрешенных блочных цепях без использования токенов. Общественный блок-чартер может принять системный контракт, который реализует лимиты посредством разбивки, а сообщество может динамически обновлять способы выделения ресурсов независимо от того, как выполняется распределение.
500 мс интервал между блоками и BFT DPOS
С EOSIO 3.0 мы снизили интервал с 3 секунд до 0,5 секунды. Это значительно сокращает время ожидания до подтверждения. В сочетании с BFT DPOS транзакции могут быть подтверждены менее чем за 1 секунду.
Задержка имеет серьезные последствия для межблочной связи, потому что другая блочная цепь должна ждать подтверждения, прежде чем включать доказательство из чужой цепи. Две блок-цепи на основе EOSIO должны иметь возможность осуществлять связь в оба конца менее чем за 3 секунды. Аналогичная схема связи на Ethereum займет 9 минут, а на биткоине — 3 часа.
BFT DPOS еще не реализован. Мы будем внедрять BFT DPOS до выпуска EOSIO 1.0.
Архитектура BIOS
Архитектура BIOS является одним из самых больших архитектурных изменений в EOSIO 3.0 в сравнении с EOSIO 2.0. Подавляющее большинство бизнес-логики блокчейна перешло в умный контракт, который может динамически обновляться сообществом без хардфорков.
Единственное, что реализовано в основном блочном коде, — это система разрешений, которая включает в себя возможность создания учетных записей, развертывания контрактов и обеспечения соблюдения квот ресурсов. Все, что делает блокчейн делегированным доказательством ставки, включая токен, голосование, распределение ставок и распределение ресурсов, теперь определяется системным контрактом на основе WebAssembly.
Благодаря этой новой архитектуре, нам удалось сосредоточить разработку на статических не-WebAssembly частях блока. Это части, которые наиболее важны для стабильности — и наиболее трудно поддаются обновлению. Между выпуском EOSIO 3.0 и EOSIO 1.0 мы будем разрабатывать окончательные детали системного контракта, ставки и голосования.
Таким образом, в EOSIO 3.0 внедрено множество нововведений. С полным их перечнем вы сможете ознакомиться по ссылке.
