Пре-релиз EOSIO Dawn 3.0

Katya_CryptoLionsKatya_CryptoLions Posts: 29 Brand New

Переведено: 21.04.2018
Oригинал: https://medium.com/eosio/eosio-dawn-3-0-now-available-49a3b99242d7

Block.one сообщает о выходе первого полнофункционального пре-релиза EOSIO Dawn 3.0. Этот пре-релиз отражает важные вехи развития EOSIO 1.0, запуск которого намечено на июнь 2018 года. Наша большая команда разработчиков со всего мира провела огромную работу чтобы превратить EOSIO в самую мощную платформу для разработки блокчейн приложений. С момента запуска EOSIO 2.0 прошло 4 месяца и за это время мы достигли значительных результатов.

Разработка современной блокчейн архитектуры - это процесс в котором дизайн развивается вместе с приобретением новых знаний. Многие функции, которые мы завершили в Dawn 3.0 даже не рассматривались в белой бумаге EOSIO, но были внедрены при разработке более совершенной, гибкой и простой в разработке платформы.

Масштабирование

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

Взаимодействие с другими блокчейнами

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

На наш взгляд, коммуникация между блокчейнами - это всего лишь возможность внедрения light client в виде смарт-контракта. Light client может проводить валидацию транзакций без согласования с целым блокчейном. Этот процесс соответствует построению блокчейна на алгоритме подтверждения доли с эффективной и безопасной валидацией light client. Таким образом, валидация light client должна учитываться в дизайне протокола, так как после внедрения сделать это невозможно.

Нечастая проверка заголовков

Традиционно, клиенты должны проверять каждый заголовок блока, а затем доказательства соответствия заголовка содержимому. Так как EOSIO может генерировать два блока в секунду, блокчейну требуется как минимум две транзакции в секунду, чтобы обрабатывать заголовок каждого блока. Это не может соизмеряется со сценариями в которых коммуникация между блокчейнами происходит относительно редко. Чтобы решить эту проблему, мы разработали первый блокчейн с отказоустойчивой, нечастой проверкой заголовков. Согласно новому алгоритму, для того чтобы обмануть light client, нужно подкупить более 2/3 производителей блоков (15+ с 21). Более того, light clients должны обрабатывать только заголовки тех блоков, где есть изменения или блоки, которые включают межсетевые сообщения. Это сводит к минимуму накладные расходы на обслуживание отказоустойчивого light client и повышает эффективность коммуникации между блокчейнами.

Внеконтекстные действия

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

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

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

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

Внеконтекстные встроенные действия как события

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

Сжатие транзакций

Существует много транзакций, которые содержат сжимаемые данные. Одним из самых очевидных примеров является сам код контракта WebAssembly. Среди других примеров можно указать ABI спецификацию и Рикардианский контракт связан с аккаунтом/контрактом. На некоторых платформах, например в социальных сетях, иногда требуется включить сжимаемый пользовательский контент в блокчейн.

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

Интерпретатор и JIT-компиляция

Одним из самых существенных изменений, которое было внесено после Dawn 2.0 является абстракция временной среды WebAssembly. Вместо быстрого Just-In-Time (JIT) компилятора, Dawn 3.0 по умолчанию использует Binaryan WebAssembly интерпретер. Хоть это решение и снижает эффективность, использование интерпретатора повышает стабильность и гарантирует соответствие стандартам. При этом, чтобы повысить продуктивность требуется просто поменять JIT среду. Интерпретатор также помог решить одну из самых больших проблем, с которой мы столкнулись в Dawn 2.0: задержку, вызванную компиляцией контракта. В будущем, мы сможем использовать интерпретатор чтобы замедлить низколатентное развертывание нового контракта в то время как другой контракт будет компилироваться и оптимизироваться на заднем фоне. Такая двойная реализация позволит тестирование всех наших модулей как на скомпилированном, так и на интерпретируемом коде. Это поможет идентифицировать потенциально недетерминированные и не отвечающие стандартам действия до того как гибридный подход будет применен.

Ограничение скорости на основе измерения ресурсов

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

Главной причиной использования такого подхода является возможность проводить намного больше подсчетов на одной транзакции, чем раньше. Теоретически, один блок, на сегодня, может вмещать транзакцию, время проведения которой - 100 мс. Для сравнения, в старой модели, максимальное время проведения транзакции - 1 мс.

Другим изменением ограничения скорости является отделение ограничений от необходимость определения токена. Это позволяет использовать EOSIO в закрытом, разрешенном блокчейне, без использования токенов. Открытый блокчейн может принимать системный контракт, который реализует лимиты через обозначение пределов, а сообщество может обновлять способы распределения ресурсов независимо от того, как выполняется распределение.

Подтверждение блока за 500 мс & BFT DPOS

В Dawn 3.0 мы развили блочный интервал с 3-секундного до 0,5-секундного. Это значительно сокращает время ожидания до подтверждения. В сочетании с BFT DPOS, транзакции могут быть необратимо подтверждены менее чем за 1 секунду. Задержка до необратимости имеет серьезное влияние на интер-коммуникацию в блокчейне, так как другой блокчейн не может включить доказательство из чужой цепи до того как наступит момент необратимости. Два EOSIO блокчейны должны осуществлять двусторонний обмен информации менее чем за 3 секунды. Осуществление аналогичного коммуникационного акта на Ethereum займет 9 минут, а на биткойне - больше 3х часов.

BFT DPOS еще не используется, так как это требует оптимизации без проведения хардфорка. Внедрение BFT DPOS будет осуществлено до выпуска EOSIO 1.0.

BIOS Архитектура

Использование BIOS архитектуры является одним из самых существенных архитектурных изменений. В EOSIO Dawn 3.0 огромное количество логических блокчейн операций было переведено на смарт контракт, который может динамически обновляться участниками сообществом без применения хардфорка. Базовый EOSIO блокчейн теперь является единственным производителем, без каких-либо токенов, голосования или делегированного подтверждения доли. Единственное, что реализовано в базовом коде блокчейна - это система разрешений, которая позволяет создавать аккаунты, проводить развертывания контрактов, и применять ресурсные квоты. Все составляющие делегированного подтверждения доли, включая токены, голосование, ставки, и распределение ресурсов, теперь определяются системным контрактом WebAssembly.

C новой архитектурой нам удалось сфокусировать разработку на статических частях блокчейна, которые не основаны на WebAssembly. Именно эти части являются самыми важными в поддержке стабильности, а также самыми тяжело обновляемыми. В период между выпуском EOSIO Dawn 3.0 и EOSIO 1.0, мы будем работать над усовершенствованием системного контракта, ставки и голосования.

Функции безопасности

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

Задержка транзакции с целью обеспечения безопасности

Одной из наиболее важных функций в EOSIO Dawn 3.0 является возможность осуществлять задержку любого действия с инициативы пользователя. Когда выполняется задержка, транзакция передается на блокчейн за несколько часов или дней до того как она должна быть проведена. За это время пользователь имеет возможность установить более высокий уровень защиты на своем аккаунте, а потом удалить транзакцию. Эта функция является существенным преимуществом EOSIO, учитывая тот факт что при работе с другими блокчейнами, вы узнаете о взломе только тогда, когда будет уже поздно принимать меры.

Восстановление забытого пароля

Каждый аккаунт имеет как минимум два уровня разрешения: «владелец» и «активный». Уровень разрешения “владелец” должен быть N из M Multisig, где нет N, которое не включает ключ(ы) владельца. Уровень разрешения “владелец” может сбросить активное разрешение в случае если активный ключ будет потерян или украден.

Если вы теряете ключ владельца, или же ваши Multisig партнеры отказываются от сотрудничества, активное разрешение аккаунта может запросить сброс разрешения владельца после 30 дней неактивности. Затем у владельца есть 7 дней, чтобы оспорить запрос, обновив активность на аккаунте.

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

Система предложений транзакций

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

Чтобы внедрить эту систему, мы добавили новые API, которые позволяют контрактам оценить собирать все разрешения, которые нужны для авторизации транзакции. Это позволяет улучшить multisig процесс, используя новую WebAssembly вместо хардфорка.

Упрощенная разработка контрактов

Одной из наших главных целей во внедрении EOSIO является максимальное упрощение разработки контрактов. Если разработчик знает методы написания классов в C ++, то можно рассчитывать на написание смарт-контрактов с минимальной сложностью шаблонов.

Нам удалось упростить «hello world» контракт до нескольких простых строк кода. Наш набор инструментов помог автоматизировать процесс генерации ABI контракта и отправки действий пользователя методам, определенным в вашем классе. Это самый простой способ разработки контракта известный сегодня.

#include <eosiolib/eosio.hpp>
#include <eosiolib/print.hpp>
using namespace eosio;

struct hello : public contract {
    using contract::contract;
  
    void hi( name user ) {
        print( “Hello, “, user );
    }
};

EOSIO_ABI( hello, (hi) )

Поддержка плавающей запятой

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

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

Поддержка стандартной библиотеки шаблонов C++

Важным аспектом нашей работы с EOSIO Dawn 3.0 является внедрение поддержки для большой части стандартной библиотеки шаблонов C ++. Это позволяет разработчикам использовать инструменты, библиотеки и алгоритмы, с которыми они знакомы, устраняя при этом вероятность возникновения багов, вызванных нестандартной реализацией этих алгоритмов.

Запланированные транзакции

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

Автоматическое определение диапазона действия

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

Мультииндекс API базы данных

EOSIO Dawn 3.0 представляет новый API баз данных, который отражает boost :: multi_index_container. С помощью этого API можно очень просто управлять таблицами, которые сортируются по нескольким ключам, а также легко находить элементы, использовать нижние/верхние границы и навигировать вперед/назад по базе данных. Этот новый API использует итератор интерфейс, который помогает существенно повысить эффективность использования таблицы.

Также теперь возможно иметь индексы в 64-битных, 128-битных, 256-битных и 512-битных целых числах, а также 64-битных с плавающей запятой (двойные). Поддержка массивов индексов будет внедрена ​​до выпуска EOSIO 1.0. Это является существенным улучшением в отношении гибкости и простоты разработки, так как теперь можно собирать почти неограниченное количество проиндексированных полей в одной таблице.

Производительность

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

Худший сценарий - 1000 TPS

Это наша базовая производительность, которую можно достигнуть без оптимизации. Используя многоузловую сеть, на которой работает интерпретатор с однопоточной проверкой подписи, можно проводить более 1000 транзакций в секунду (TPS).

Средний сценарий - 3000 TPS

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

Лучший сценарий - 6000 TPS

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

Теоретический сценарий - 8000 TPS

Если из уравнения вывести сетевой код и сосредоточится только на возможностях процессора без проверки подписи и с использованием JIT, мы сможем проводить 8000 однопоточных транзакций в секунду. Чтобы получить возможность проводить больше транзакций на одной цепочке, нужно параллельное выполнение WebAssembly и более продвинутый планировщик. В этом же сценарии, при использовании интерпретатора вместо JIT, мы можем проводить 2700 транзакций. Это говорит о том что относительно простое изменение использования JIT даст нам примерно 3-кратное увеличение производительности. Эти измерения были сделаны на MacBook 2.8Ghz i7.

Неограниченное число транзакций в секунду

Определение «транзакции в секунду» часто представляет собой концепт, который не подлежит никаким сравнениям. В интер-коммуникации на блокчейне, объем работы можно, по желанию, разделить между любым количеством блокчейнов. Токены можно надежно и безопасно переносить между различными цепями. Если допустить что много разных (или тех же) производителей блоков будут работать параллельно с 1000 цепочками, можно проводить миллионы транзакций в секунду. Это представляет собой практическую реализацию теоретических предложений по масштабированию, представленных другими блокчейнами.

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

Предстоящий путь

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

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

Краткое изложение

EOSIO Dawn 3.0 - это релиз, разработанный как полнофункциональная платформа, которая работает со стабильными API. Мы полагаем, что платформа, на сегодня, достаточно стабильна для серьезной разработки приложений. EOSIO стал намного мощнее и легче в использовании, чем было задумано год назад.

Наша команда растет, и в разработке отмечаются рекордные темпы. Наш репозиторий был в десятке самых активных репозиториев C ++ на github за последний месяц. Готовимся к выпуску EOSIO 1.0 в июне!


Перевод: CryptoLions
Website
Telegram
Steemit
Twitter
GitHub
Meetup

Sign In or Register to comment.