blockchained

7 лет назад

🌐 Релиз EOSIO Dawn 3.0 доступен для тестирования (Daniel Larimer)

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

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

Свойства масштабирования

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

Межчейновая коммуникация

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

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

Верификация неполного заголовка

Ожидается, что традиционные легкие клиенты будут обрабатывать каждый заголовок блока, а затем проверять доказательства относительно этих заголовков. Теперь, когда EOSIO может генерировать два блока в секунду, для обработки каждого заголовка блока блокчейну потребуется не менее 2 транзакций в секунду. Это не масштаб для сценариев, где есть относительно редкие межчейновые коммуникации. Для решения этой проблемы мы создали первый блокчейн с византийской отказоустойчивой проверкой неполных заголовков. В частности, для попытки обмана легкого клиента потребуется, чтобы были коррумпированы более 2/3 (например, 15+ из 21) производителей блоков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Блок-интервал в 500 мс & BFT DPOS

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

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

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

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

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

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

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

Безопасные отложенные транзакции

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

Восстановление утерянного пароля

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

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

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

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

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

Чтобы внедрить эту систему, мы добавили новые API, позволяющие контрактам оценивать, является ли набор разрешений аккаунта достаточным для авторизации транзакции. Это позволяет нам обновить процесс мультиподписи путем развертывания нового 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) )

Поддержка плавающей точки

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

Мы решили вопрос недетерминированного характера аппаратной плавающей точки, интегрировав библиотеку программного обеспечения с плавающей точкой, которая прозрачно используется контрактами 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-битную плавающую точку (doubles). Поддержка строковых индексов будет добавлена перед релизом EOSIO 1.0. Это является значительным улучшением гибкости и простоты разработки, чему способствует появившаяся возможность иметь почти что неограниченное количество индексированных полей в одной таблице.

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

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

Наименьший кейс — 1000 TPS

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

Средний кейс— 3000 TPS

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

Лучший кейс — 6000 TPS

После имплементации параллельной проверки подписи мы можем предположить, что по мере увеличения уровня параллелизма и количества подписей требуемое для подписи время выполнения будет приближаться к нулю. Мы можем имитировать такую среду, отключив проверку подписи. С этой моделью мы можем достичь 6000 TPS в сети из нескольких нод с jit-компилятором.

Теоретический кейс — 8000 TPS

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

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

Определение “транзакций в секунду” часто представляет собой сравнение яблок с апельсинами. С помощью межчейновой коммуникации мы можем разделить нагрузку на любое желаемое количество блокчейнов. Токены могут надежно и безопасно передаваться между различными чейнами. С 1000 чейнов, работа которых параллельно поддерживается одними и теми же (или разными) производителями блоков, мы можем достичь миллионов транзакций в секунду. Это представляет собой практическую реализацию теоретических предложений по масштабированию, представленных другими блокчейнами.

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

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

Предстоящие работы

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

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

Итог

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

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

Переведено @blockchained

Оригинал поста: ЗДЕСЬ