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

Мітка часу: 15 вересня 2016 р., 8:56
Вихідний вузол: 1213525

Для спільних незмінних баз даних "ключ-значення" та часових рядів

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

  1. База даних ключ-значення або сховище документів у стилі NoSQL.
  2. База даних часових рядів, яка зосереджена на впорядкуванні записів.
  3. База даних, керована ідентифікацією, де записи класифікуються відповідно до їх автора.

Їх можна розглядати як «що», «коли» і «хто» спільної бази даних.

Основи потоків

У блокчейні MultiChain можна створити будь-яку кількість потоків, і кожен потік діє як незалежна колекція елементів, яка лише додається. Кожен елемент у потоці має такі характеристики:

  • One or more видавців які підписали цей елемент цифровим підписом.
  • Необов’язковий ключ для зручного подальшого пошуку.
  • Дещо дані, який може варіюватися від невеликого фрагмента тексту до багатьох мегабайтів необробленого двійкового файлу.
  • A відмітка часу, який береться із заголовка блоку, в якому підтверджується елемент.

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

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

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

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

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

Це забезпечує ефективний спосіб архівувати дані в блокчейні, роблячи їх видимими лише для певних учасників.

Отримання з потоків

Основна цінність потоків полягає в індексуванні та пошуку. Кожен вузол може вибрати, на які потоки підписатися, при цьому блокчейн гарантує, що всі вузли, які підписалися на певний потік, бачитимуть ті самі елементи в ньому. (Вузол також можна налаштувати для автоматичної підписки на кожен новий створений потік.)

Якщо вузол підписаний на потік, інформацію можна отримати з цього потоку кількома способами:

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

Як згадувалося на початку, ці методи пошуку дозволяють використовувати потоки бази даних ключ-значення, бази даних часових рядів і бази даних, керовані ідентифікацією. Пропонуються всі API пошуку старт та вважати параметри, що дозволяє ефективно отримувати підрозділи довгих списків (як пропозиція LIMIT у SQL). Від’ємні значення для старт дозволити отримати найновіші елементи.

Потоки можуть містити кілька елементів з однаковим ключем, і це природним чином усуває суперечність між незмінністю блокчейну та необхідністю оновлення бази даних. Кожному ефективному «запису» бази даних слід призначити унікальний ключ у вашій програмі, причому кожне оновлення цього запису представлено новим елементом потоку з його ключем. API потокового пошуку MultiChain можна використовувати для: (a) отримання першої або останньої версії певного запису, (b) отримання повної історії версій для запису, (c) отримання інформації про кілька записів, включаючи першу й останню версії кожного.

Зауважте, що через однорангову архітектуру блокчейну елементи в потоці можуть надходити до різних вузлів у різному порядку, а MultiChain дозволяє отримувати елементи до того, як вони будуть «підтверджені» в блоці. У результаті всі API пошуку пропонують вибір між глобальним (за замовчуванням) або локальним упорядкуванням. Глобальне впорядкування гарантує, що коли ланцюжок досягне консенсусу, усі вузли отримають однакові відповіді від однакових викликів API. Локальне впорядкування гарантує, що для будь-якого конкретного вузла порядок елементів потоку ніколи не змінюватиметься між викликами API. Кожна програма може зробити відповідний вибір для своїх потреб.

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

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

У довгостроковій перспективі, де потоки вписуються в дорожню карту MultiChain? Зробивши крок назад, MultiChain тепер пропонує три сфери високорівневої функціональності:

  • Дозволи контролювати, хто може підключатися, здійснювати транзакції, створювати активи/потоки, видобувати/перевіряти та адмініструвати.
  • Активи включаючи випуск, перевипуск, передачу, атомарний обмін, депонування та знищення.
  • струменеві з API для створення потоків, написання, підписки, індексування та отримання.

Після випуску MultiChain 1.0 (і преміум-версії), що буде наступним у цьому списку? Якщо подивитися на Команда API який використовується для створення потоків, ви помітите, очевидно, зайвий параметр із фіксованим значенням stream. Цей параметр дозволить MultiChain підтримувати інші типи об’єктів високого рівня в майбутньому.

Можливі майбутні значення для параметра включають evm (для ан Ethereum-сумісна віртуальна машина), sql (для бази даних у стилі SQL) або навіть wiki (для спільно редагованого тексту). Будь-яка спільна сутність, стан якої визначається впорядкованою серією змін, є потенційним кандидатом. Кожна така сутність потребуватиме: (a) API, які забезпечують правильну абстракцію для оновлення її стану, (b) відповідні механізми для підписаних вузлів для відстеження цього стану та (c) API для ефективного отримання частини або всього стану. Ми чекаємо, щоб дізнатися, які інші об’єкти високого рівня були б найбільш корисними, щоб їх реалізували ми чи треті сторони за допомогою архітектури плагінів.

А як щодо смарт-контрактів?

У загальному сенсі MultiChain використовує підхід, в якому дані незмінно вбудовано в блокчейн, але код для інтерпретації цих даних у вузлі або прикладному рівні. Це навмисно відрізняється від парадигми «розумних контрактів», прикладом якої є Ethereum, у якому код вбудовано в блокчейн і виконується у віртуальній машині. Теоретично, тому що розумні контракти є Тюрінг завершений, вони можуть відтворювати поведінку MultiChain або будь-якої іншої блокчейн-платформи. Однак на практиці смарт-контракти в стилі Ethereum мають багато болісних недоліків:

  • Кожний вузол повинен виконувати всі обчислення, незалежно від того, цікаво це чи ні. Навпаки, у MultiChain кожен вузол вирішує, на які потоки підписатися, і може ігнорувати дані, що містяться іншими.
  • Віртуальна машина, яка використовується для смарт-контрактів, має значно гіршу продуктивність, ніж код, який був власно скомпільований для даної архітектури комп’ютера.
  • Код смарт-контракту незмінно вбудовано в ланцюжок, запобігаючи додаванню функцій і виправленню помилок. Це було яскраво продемонстровано в загибель The DAO.
  • Транзакції, надіслані в смарт-контракт не вдається оновити через природу обчислень загального призначення, поки не буде відомий їхній остаточний порядок, стан блокчейна. Це призводить до затримок (поки транзакція не буде підтверджено в блоці), а також можливих розворотів (у разі розгалуження в ланцюжку). Навпаки, MultiChain може обробляти кожен тип непідтвердженої транзакції відповідним чином: (а) вхідні активи негайно оновлюють непідтверджений баланс вузла, (б) елементи вхідного потоку стають миттєво доступними, а їхнє глобальне впорядкування згодом завершується, (в) змінюються дозволи застосовуються негайно, а потім відтворюються у вхідних блоках.

Тим не менш, як і я сказано раніше, ми, звичайно, не виключаємо смарт-контракти як корисну парадигму для блокчейн-додатків, якщо і коли побачимо сильні випадки використання. Однак у MultiChain смарт-контракти будуть реалізовані на рівні потоку поверх блокчейну, а не на найнижчому рівні транзакцій. Це збереже чудову продуктивність MultiChain для більш простих об’єктів блокчейну, таких як активи та потоки, і водночас запропонує повільніші обчислення в ланцюзі там, де це дійсно необхідно. Але таких випадків менше, ніж можна подумати.

 

Будь ласка, залишайте будь-які коментарі на LinkedIn.

 

Технічний додаток

Усі команди, пов’язані з потоками, повністю задокументовані в Сторінка MultiChain API, але ось короткий підсумок:

  • Створіть потік за допомогою 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 параметр blockchain, а також менший з maximum-block-size та max-std-tx-size значення мінус кілька сотень байт.
  • Вузли, які використовують старий формат гаманця, не можуть підписуватися на потоки, і слід оновити.

 

Часова мітка:

Більше від Багатоканальний