Представляем MultiChain Streams

Отметка времени: 15 сентября 2016 г., 8:56
Исходный узел: 1213525

Для общих неизменяемых баз данных ключ-значение и временных рядов

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

  1. База данных значений ключей или хранилище документов в стиле NoSQL.
  2. База данных временных рядов, которая фокусируется на упорядочении записей.
  3. База данных, основанная на идентичности, где записи классифицируются в соответствии с их автором.

Их можно рассматривать как «что», «когда» и «кто» в общей базе данных.

Основы потоков

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

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

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

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

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

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

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

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

Извлечение из потоков

Основная ценность потоков в индексировании и поиске. Каждый узел может выбирать, на какие потоки подписываться, при этом блокчейн гарантирует, что все узлы, которые подписываются на определенный поток, будут видеть одни и те же элементы внутри. (Узел также можно настроить для автоматической подписки на каждый новый созданный поток.)

Если узел подписан на поток, информация может быть получена из этого потока несколькими способами:

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

Как уже упоминалось в начале, эти методы поиска позволяют использовать потоки для базы данных ключ-значение, базы данных временных рядов и управляемые идентичностью базы данных. Все поисковые API предлагают Начало и считать параметры, позволяющие эффективно извлекать подразделы длинных списков (например, предложение LIMIT в SQL). Отрицательные значения для Начало позволяют получать самые последние элементы.

Потоки могут содержать несколько элементов с одним и тем же ключом, и это, естественно, устраняет противоречие между неизменностью цепочки блоков и необходимостью обновления базы данных. Каждой действующей «записи» базы данных должен быть присвоен уникальный ключ в вашем приложении, причем каждое обновление этой записи представлено новым элементом потока с его ключом. Затем API-интерфейсы MultiChain для потокового поиска можно использовать: (а) для получения первой или последней версии данной записи, (б) для получения полной истории версий для записи, (в) для получения информации о нескольких записях, включая первую и последнюю. версии каждого.

Обратите внимание, что из-за одноранговой архитектуры блокчейна элементы в потоке могут поступать в разные узлы в разных порядках, и MultiChain позволяет извлекать элементы до того, как они будут «подтверждены» в блоке. В результате все поисковые API предоставляют выбор между глобальным (по умолчанию) или локальным порядком. Глобальный порядок гарантирует, что, как только цепочка достигнет консенсуса, все узлы получат одинаковые ответы от одних и тех же вызовов API. Локальное упорядочение гарантирует, что для любого конкретного узла упорядочение элементов потока никогда не изменится между вызовами API. Каждое приложение может сделать соответствующий выбор для своих нужд.

Потоки и дорожная карта MultiChain

С выпуском потоков мы выполнили последний важный этап работы над MultiChain 1.0 и теперь твердо находимся на пути к бета-версии. Мы ожидаем потратить следующие несколько месяцев на расширение нашего внутреннего набора тестов (уже довольно большого!), Завершение работы портов Windows и Mac, добавление еще нескольких полезных API, обновление Explorer для потоков - настройка аспектов механизма консенсуса, выпуск нашей веб-демонстрации и, как правило, приведение в порядок кода и сообщений справки. Самое главное, мы продолжим исправлять любые ошибки, как только они будут обнаружены, чтобы наши ошибки не прерывали вашу работу.

В более долгосрочной перспективе, где потоки вписываются в дорожную карту MultiChain? Сделав шаг назад, MultiChain теперь предлагает три области функциональности высокого уровня:

  • Разрешения... контролировать, кто может подключаться, осуществлять транзакции, создавать активы / потоки, анализировать / проверять и администрировать.
  • Активы включая выпуск, переиздание, передачу, атомный обмен, условное депонирование и уничтожение.
  • Стримы с API для создания потоков, записи, подписки, индексации и поиска.

Что будет в этом списке после выпуска MultiChain 1.0 (и премиум-версии)? Если вы посмотрите на Команда API который используется для создания потоков, вы заметите явно лишний параметр с фиксированным значением stream, Этот параметр позволит MultiChain поддерживать другие типы объектов высокого уровня в будущем.

Возможные будущие значения для параметра включают evm (для Эфириум-совместимая виртуальная машина), sql (для базы данных в стиле SQL) или даже wiki (для совместно отредактированного текста). Любой общий объект, состояние которого определяется упорядоченной серией изменений, является потенциальным кандидатом. Каждому такому объекту понадобятся: (a) API, которые предоставляют правильную абстракцию для обновления своего состояния, (b) соответствующие механизмы для подписанных узлов для отслеживания этого состояния и (c) API для эффективного извлечения части или всего состояния. Мы ждем, чтобы узнать, какие другие высокоуровневые объекты были бы наиболее полезными для реализации нами или третьими лицами с помощью архитектуры подключаемых модулей.

А как насчет умных контрактов?

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

  • Каждый узел должен выполнять все вычисления, независимо от того, интересны они или нет. Напротив, в MultiChain каждый узел решает, на какие потоки подписаться, и может игнорировать данные, содержащиеся в других.
  • Виртуальная машина, используемая для интеллектуальных контрактов, имеет значительно худшую производительность, чем код, который был скомпилирован для конкретной компьютерной архитектуры.
  • Код смарт-контракта всегда встроен в цепочку, предотвращая добавление функций и исправление ошибок. Это было убедительно продемонстрировано в кончина DAO.
  • Транзакции, отправленные на смарт-контракт не может обновить состояние блокчейна до их окончательного упорядочения известно из-за характера вычислений общего назначения. Это приводит к задержкам (до подтверждения транзакции в блоке), а также к возможным изменениям (в случае разветвления в цепочке). В отличие от этого, MultiChain может обрабатывать каждый тип неподтвержденной транзакции надлежащим образом: (a) входящие активы немедленно обновляют неподтвержденный баланс узла, (b) элементы входящего потока мгновенно доступны с последующим завершением их глобального заказа, (c) изменения разрешений применяются немедленно и затем воспроизводятся во входящих блоках.

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

 

Пожалуйста, оставьте любые комментарии на LinkedIn.

 

Техническое приложение

Все команды, связанные с потоками, полностью документированы в Страница API MultiChain, но вот краткое резюме:

  • Создать поток, используя create stream or createfrom ... stream
  • Добавить элемент в поток с publish or publishfrom
  • Получить список потоков, используя liststreams
  • Начать или остановить отслеживание потока с subscribe и unsubscribe
  • Извлекайте элементы потока, используя liststreamitems, liststreamkeyitems и liststreampublisheritems
  • Список ключей потока и издателей с liststreamkeys и liststreampublishers
  • Для больших потоковых данных извлеките полные данные, используя gettxoutdata (См. maxshowndata ниже)
  • Управление разрешениями для каждого потока с помощью вызовов, таких как grant [address] stream1.write
  • Просмотр разрешений потока с помощью listpermissions stream1.*

Некоторые другие замечания разработчиков, касающиеся потоков:

  • Ассоциация create разрешение позволяет адресу создавать потоки.
  • Соответствующие разрешения для каждого потока write, admin и activate
  • Новые параметры блокчейна: root-stream-name (оставить пустым) root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
  • Новые параметры времени выполнения: autosubscribe автоматически подписываться на новые созданные потоки и maxshowndata ограничить объем данных в ответах API (см. gettxoutdata выше).
  • Максимальный размер данных элемента потока устанавливается max-std-op-return-size параметр блокчейна, а также меньший из maximum-block-size и max-std-tx-size значения минус несколько сотен байтов.
  • Узлы, использующие старый формат кошелька, не могут подписаться на потоки, и следует обновить.

 

Отметка времени:

Больше от многоцепочечного