Последние недели выдались для block.one весьма продуктивными, что проявилось в виде нескольких значимых обновлений, оказавших влияние на разработчиков, масштабируемость и стабильность.
Универсальный мультииндексный API базы данных
Разработка смарт-контрактов включает в себя определение схемы базы данных для отслеживания, хранения и поиска данных. Довольно часто разработчикам требуются одни и те же данные, отсортированные/индексированные по нескольким полям, а также согласованность всех индексов.
Люди, знакомые с разработкой Steem и BitShares, знают силу boost::multi_index_container. Эти контейнеры обеспечивают мощный, гибкий и безопасный API. Я давно хотел иметь столь же гибкую и мощную систему для наших контрактов на WebAssembly. И теперь я рад сообщить, что мы внесли изменения в путь получения смарт-контрактами доступа к базе данных, чтобы предоставить разработчикам похожий API.
Итераторы базы данных
Процесс достижения этой цели преимущественно заключался в создании нового API базы данных, основанного на итераторах. Итераторы дают WebAssembly возможность быстро перебирать и находить объекты в базе данных. Этот новый API обеспечивает значительное повышение производительности путем изменения сложности поиска последующего или предыдущего элемента в базе данных с O(log(N)) на O (1).
Внеконтекстные действия
Внеконтекстное действие включает в себя вычисления, зависящие только от данных транзакции. Основным примером такого вычисления является проверка подписи. Зная одни только данные транзакции и подпись, мы можем вычислить открытый ключ, подписавший транзакцию. Этот расчет является одним из самых затратных индивидуальных вычислений, выполняемых блокчейном. Поскольку это вычисление является внеконтекстным (т.е. не зависит от состояния блокчейна), оно может выполняться параллельно.
Внеконтекстные действия схожи с другими действиями пользователей, за исключением того, что у них отсутствует доступ к состоянию блокчейна для выполнения проверки. Это позволяет EOSIO параллельно обрабатывать все внеконтекстные действия путем, схожим с проверкой подписи. Еще более важно то, что становится возможна генерализованная проверка подписи.
Чтобы понять важность генерализованной проверки подписи, давайте рассмотрим случай использования межчейновой связи. В этом случае пользователь должен предоставить доказательство Меркла, которое включает в себя до 128 операций sha256 и/или 14 проверок подписи. Все эти данные и вычисления сделаны для того, чтобы доказать, что определенное действие произошло в конкретном блоке внешнего чейна, и/или что конкретный блок был проверен ⅔+ производителей. Бизнес-логике остается только проверить, действителен ли ID блока и что действие было произведено именно в этом блоке. Вычисления, доказывающие наличие действия в блоке, нужны бизнес-логике не больше, чем вычисления для получения открытого ключа из подписи.
С поддержкой внеконтекстных действий большинство методов масштабирования, предложенных Эфириумом (Sharding, Raiden, Plasma, State Channels и т.д.), становятся более эффективными, практичными и параллелизирующимися. Также это применимо к другим аспектам EOSIO и тем самым способно обеспечить эффективную межчейновую коммуникацию и неограниченную масштабируемость.
SegWit
Концепция SegWit, или Сегрегированного Заверителя (Segregated Witness), заключается в том, что подписи транзакций теряют актуальность после необратимого включения транзакций в блокчейн. Как только транзакция становится необратимой, эти подписи могут быть убраны, при этом все желающие сохраняют возможность определять текущее состояние. Поскольку подписи являют собой основную часть всех транзакций, данная концепция предлагает значительную экономию дискового пространства и времени синхронизации.
Эта же концепция может применяться к доказательствам Меркла, используемым в межчейновой связи. После того, как доказательство принято и необратимо записано в блокчейн, 2КБ хэшей sha256, ранее занятых доказательством, становятся больше не нужны для определения актуального состояния блокчейна. В случае межчейновой связи эта экономия оказывается в 32 раза больше, чем экономия на обычных подписях.
Другим примером SegWit служат посты в блогах на Steem. В этой модели пост содержит только sha256 (контент блога), и этот контент будет находиться в данных сегрегированного заверителя. Производитель блока должен заверить, что контент существует и соответствует указанному хэшу, однако нет необходимости хранить контент блога ради возможности восстановления состояния из лога блокчейна. Это позволяет доказать, что опубликованный контент уже был проверен, без необходимости его вечного хранения.
Существуют противоречия по поводу того, как SegWit реализован в Биткоине, но большинство аргументов против SegWit, актуальных для Биткоина, нерелевантны в контексте Делегированного доказательства долей. В частности, в DPOS можно:
- Требовать, чтобы производители блоков хранили полные записи
- Регенерировать межчейновые доказательства Меркла из публичных данных
- Возлагать на производителей блоков, как публичных персон, ответственность за предоставление доказательств того, что их блоки были действительны и что транзакции обладают соответствующими авторизованными подписями.
- С BFT-DPOS потеря подписи потребует сговора 100% производителей блоков, к тому же производится 21 независимая проверка.
Интерпретатор WebAssembly
Теперь EOSIO поддерживает ДВА разных модуля исполнения для Web Assembly. Первоначальная реализация JIT обеспечивает быстрое исполнение после начального “медленного” шага компиляции, а новый интерпретатор Binaryen предоставляет соответствующую стандартам эталонную реализацию без каких-либо медленных шагов запуска.
Производители блоков смогут использовать интерпретатор одновременно с компилятором, оптимизирующим x86. Кроме того, в случае спора о том, какой результат является “правильным”, мы сможем использовать задающий стандарт интерпретатор Binaryen, оставляя реализацию JIT в качестве оптимизации, которая должна производить тот же результат.
В наших тестах производительности интерпретатор Binaryen показал около 20% от скорости реализации JIT; однако для большинства транзакций время выполнения WASM составляет небольшой процент от всего времени обработки транзакций. Доступ к базе данных и другие вычисления блокчейна по-прежнему составляют большую часть времени обработки. По нашим оценкам, влияние интерпретатора на реальную производительность для простых контрактов (например, валют) составляет примерно 5%.
В рамках подготовки к нашему первоначальному июньскому релизу EOSIO мы продолжим фокусироваться в большей степени на корректности, стабильности и безопасности, нежели на номинальной производительности. Тем не менее, масштабируемость и оптимизация – это то, что мы всегда имеем в виду, и каждый компонент EOSIO разработан с учетом этих факторов.
Новый член команды
Команда block.one снова расширилась – мы рады приветствовать в своих рядах Архага! Arhag давно и активно участвует в жизни сообщества BitShares и Steem и теперь работает с нами над API базы данных.
Заключение
Разработка идет невероятно быстрыми темпами, и мы надеемся, что вам понравятся ее результаты!
Оригинал поста: ЗДЕСЬ