Дорожня карта MultiChain 1.0 beta 2 і 2.0

Де ми сьогодні і куди підемо завтра

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

У цьому місяці також виповнюється два роки з моменту першого альфа-випуску MultiChain у червні 2015 року. Як і з будь-яким новим продуктом, ми не були впевнені, як відреагує ринок, і знали, що є лише один спосіб дізнатися – випустити мінімально життєздатний продукт, що означає початкову версію, яка має значну цінність, але є попередньою за проектом. На щастя, на відміну від нашого першого продукту CoinSpark, MultiChain отримав сильну та негайну позитивну відповідь. Це супроводжувалося цунамі запитів розумних функцій, багато з яких ми зараз запровадили. Паралельно з розвитком продукту використання також помітно зросло. Наприклад, у липні 3,000 року веб-сайт MultiChain отримав менше 2015 відвідувачів, а тепер щомісяця його кількість у десять разів більше.

Продуктивність MultiChain

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

.throughput td,.throughput th {text-align:right;}

Всього транзакцій	1.0 альфа 3	1.0 альфа 21	1.0 альфа 22	1.0 1 бета	1.0 2 бета
100	6.5 ст.л	7.8	541.7	830.6	1465.7
1,000	7.0	7.6	583.9	889.4	1199.6
10,000	4.1	6.4	566.9	746.6	1071.2
100,000	-	6.6	558.0	771.9	1034.2
1,000,000	-	-	548.6	773.6	1055.4

Середня кількість транзакцій за секунду, включаючи накладні витрати API та створення, підписання, видобуток та перевірку транзакцій і блоків.
Тести, проведені за допомогою ab Інструмент порівняльного аналізу сервера HTTP, що надсилає два одночасних запити до sendtoaddress API.
Технічні характеристики сервера: Intel Core i7-4770, 4 ядра @ 3.4 МГц, 32 ГБ ОЗУ, Seagate 2 ТБ 7200 RPM SATA, CentOS 6.4.

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

Звичайно, оптимізація продуктивності - це нескінченне завдання, і немає причин, чому MultiChain не може досягти 10,000 XNUMX tx/sec на 16-ядерний процесор з відповідними архітектурними змінами. Однак, виходячи з розмов з нашими користувачами та партнерами, здається, що мало хто очікує, що протягом наступних кількох років знадобиться більше 1,000 tx/sec. Тож ми перефокусуємо наші зусилля з розробки на нові функції, що наближає нас до теми MultiChain 2.0.

Огляд MultiChain 2.0

Версія 2.0 MultiChain буде першою в двох версіях – Community (з відкритим кодом) і Enterprise (комерційна). Я зосереджуся тут на безкоштовному виданні Community, оскільки ми лише обговорюємо деталі MultiChain Enterprise з наших партнерів. У будь-якому випадку, видання Community та Enterprise будуть дуже сумісні, оскільки: (a) програми, створені на версії Community, працюватимуть без змін на MultiChain Enterprise, і (b) обидві версії зможуть підключатися та здійснювати транзакції один з одним. на тому ж ланцюжку.

Трьома ключовими областями розширеної функціональності в обох версіях MultiChain 2.0 будуть:

• Розширена модель даних для потоків, включаючи документи JSON.
• Настроювані програмовані фільтри транзакцій для перевірки в мережі.
• Безперебійне оновлення протоколу та параметрів блокчейну.

Звернемося до кожного з них докладно.

Більш багата модель даних для потоків

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

У MultiChain 1.0 кожен елемент потоку має одного або кількох видавців (які його підписують), додатковий ключ, корисне навантаження двійкових даних розміром до 64 МБ і позначку часу (отриману з блоку, в який він вбудований). Кожен вузол може вільно вирішувати, на які потоки підписатися, або може підписатися на всі потоки автоматично. Якщо вузол підписаний на потік, він індексує вміст цього потоку в режимі реального часу, що дозволяє ефективно отримувати дані за видавцем, ключем, блоком, міткою часу або позицією.

MultiChain 2.0 збагатить функціональність цих потоків кількома способами:

• Елементи JSON. Крім двійкових даних, елементи потоку підтримуватимуть структуровані об’єкти JSON, що зберігаються в блокчейні в ефективному форматі серіалізації, наприклад UBJSON. Оскільки API MultiChain вже використовує JSON, ці об’єкти JSON будуть доступними для запису та читання природним і очевидним способом.
• Кілька ключів. Елементи потоку підтримуватимуть декілька ключів, що дозволить індексувати один фрагмент даних кількома способами для отримання за допомогою liststreamkeyitems. Ми постійно оцінюємо, скільки функціональних можливостей бази даних включити в MultiChain, і не очікуємо підтримки індексування піделементів у елементах потоку JSON у версії 2.0. Дозвіл кількох ключів для кожного елемента потоку забезпечує розумний обхідний шлях.
• Atomic записує декілька елементів. MultiChain 1.0 дозволяє одній транзакції записувати в кілька потоків, але не записувати кілька елементів в один потік. MultiChain 2.0 зніме це обмеження.
• Об’єднання JSON. Будь-який впорядкований список об’єктів JSON можна природним чином зрівняти або узагальнити, щоб створити «об’єднаний» об’єкт. Об'єднаний об'єкт містить усі ключі, які з'являються в окремих об'єктах, де значення, що відповідає кожному ключу, береться з останнього об'єкта, в якому цей ключ з'являється. Якщо хочете, об’єднаний об’єкт є кінцевим станом рядка бази даних, стовпці якого визначаються першим об’єктом і розширюються або оновлюються пізнішими об’єктами. MultiChain 2.0 додасть API для легкого та швидкого отримання об’єднаного об’єкта для елементів JSON у потоці з певним ключем або видавцем.

Ці функції є похідними від поширених способів, якими розробники зараз використовують потоки. Іншими словами, ми спостерігаємо, що багато людей будують поверх MultiChain на рівні додатків і переносять цю функціональність у сам MultiChain – шаблон, який ми маємо намір застосовувати й надалі. Тепер, коли елементи потоку включатимуть інформацію про тип, їх можна легко розширити в майбутньому для підтримки інших форматів даних, таких як XML, HDF5 та MIME-ідентифікований вміст. Не кажучи вже про можливості прозорого ланцюгового стиснення та шифрування.

MultiChain 2.0 також підтримуватиме об’єкти JSON для необроблених метаданих транзакцій (тобто не елементів потоку), а також метаданих для подій видачі активів та створення потоку, замість пар ключ/значення лише для тексту, реалізованих у MultiChain 1.0. The listassets API запропонує об’єднання JSON для всіх подій видачі активу, щоб метадані кожного випуску могли ефективно оновлювати остаточний опис об’єкта.

Користувацькі фільтри транзакцій

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

MultiChain 2.0 представить іншу парадигму, яка називається фільтрами транзакцій, які перевіряють окремі транзакції без посилання на будь-який глобальний стан. Ми очікуємо, що фільтри будуть написані на Javascript і виконані у вбудованому механізмі виконання, наприклад v8, який використовується в Google Chrome браузер і Node.js платформа. Звичайно, нам потрібно переконатися, що код фільтра виконується однаково на кожному вузлі в блокчейні, блокуючи будь-які джерела недетермінізму наприклад, зчитування часу, використання випадкових чисел, доступ до мережі чи диска або виконання математичних операцій, які залежать від архітектури хост-сервера. Створення детермінованого середовища виконання Javascript є складним завданням, але (не віддаючи зайвого) ми вважаємо, що воно буде корисним для кількох інших функцій MultiChain у майбутньому.

Фільтрам буде переданий об’єкт JSON, що описує окрему транзакцію, структурований як результат decoderawtransaction але з додатковими полями. Наприклад, кожна введена транзакція в JSON міститиме структуру, що описує попередній вихід транзакції, яку вона витрачає, і кожна адреса супроводжуватиметься списком дозволів, які на даний момент має ця адреса. Завдання фільтра полягає в тому, щоб повернути логічне значення, яке вказує, чи є транзакція прийнятною, і якщо ні, надати текстову помилку, пояснюючи причину. API MultiChain включатиме команди для створення фільтрів, їх тестування на попередніх або нових транзакціях та їх активації за умови згоди адміністратора.

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

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

Ми очікуємо, що одна популярна програма для фільтрів буде перевіряти елементи потоку. Наприклад, фільтр може гарантувати, що певні поля в елементах JSON потоку містять числа в певному діапазоні. У MultiChain 1.0 цей тип перевірки має виконуватися на рівні програми або під час запису елементів потоку (якщо джерело є надійним), або під час їх читання. На відміну від цього, MultiChain 2.0 дозволить вбудовувати ці правила в сам блокчейн, скоріше, як перевірити обмеження у реляційній базі даних.

MultiChain 2.0 включатиме дві додаткові функції, щоб зробити фільтри ще більш потужними. По-перше, він представить визначені користувачем дозволи, які існують поряд із вісьмома дозволами, визначеними MultiChain. Як і у випадку зі звичайними дозволами, вони надаватимуть певним адресам адміністратори (а в деяких випадках користувачі з activate привілеї) і включені поряд з адресами в об’єкт JSON, переданий фільтру. Наприклад, фільтр може гарантувати, що лише адреси з певним дозволом, визначеним користувачем, можуть записувати певні типи даних у потік або здійснювати трансакції з певним активом понад певний поріг.

По-друге, MultiChain 2.0 підтримуватиме користувацькі (двійкові або JSON) метадані в звичайних виводах транзакцій. Це дозволить будь-якому виводу діяти як загальний рядок бази даних, який «належить» адресі всередині. Фільтри бачитимуть будь-які метадані в рамках витрачених і створених результатів транзакції як частину опису JSON. В результаті MultiChain стане універсальним механізмом спільної бази даних, де дійсність транзакції визначається настроюваною функцією рядків, які вона створює та видаляє. (Якщо це звучить трохи абстрактно, ми обов’язково наведемо кілька конкретних прикладів.)

Оновлення блокчейну

Оскільки блокчейни розраховані на багато років, їх характеристики, можливо, доведеться змінювати з часом. Поточна версія MultiChain вже забезпечує достатню ступінь гнучкості, дозволяючи змінювати дозволи (включаючи адміністраторів і майнерів за консенсусом), створювати нові активи та потоки, а також плавно додавати або видаляти вузли з мережі. Тим не менш, в MultiChain 1.0 є основний блокчейн параметри, такі як максимальний розмір блоку та час підтвердження цілі, фіксуються під час створення ланцюга і не можуть бути змінені згодом.

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

Параметри блокчейну, які можна оновити, включатимуть:

• Версія протоколу. Це дозволить оновити блокчейн, створений з однією версією MultiChain, щоб підтримувати функції в новій версії, наприклад елементи потоку JSON або фільтри транзакцій. Дійсно, протокольна версія 10008 представлений у MultiChain 1.0 alpha 29 (і використовуваний у бета-версії), уже перевірений на майбутнє з недокументованою підтримкою такого типу оновлення. Як тільки блокчейн MultiChain 1.0 буде оновлено до протоколу 2.0, він також отримає доступ до інших змін параметрів, описаних тут.
• Масштабування блокчейну. Блокчейни, які стають популярними, можуть перерости початкові значення, встановлені для їх цільового часу підтвердження або максимальних розмірів транзакцій і блоків. MultiChain 2.0 дозволить збільшувати або зменшувати ці значення за потреби.
• Модель дозволів. MultiChain 2.0 дозволить оновлювати багато параметрів, що стосуються дозволів та керування, зокрема: (a) anyone-can-* параметри, які керують тим, як блокчейн відкритий або закритий, (b) admin-consensus-* параметри, які визначають рівні консенсусу адміністратора, необхідні для певних операцій, і (c) mining-diversity параметр, який контролює суворість циклового алгоритму консенсусу.

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

Забігаючи вперед

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

На завершення я хотів би подякувати нашій команді розробників на чолі з д-ром Михайлом Розанцевим за їхню безперервну досконалість та наполегливу роботу. Ми розглядаємо MultiChain як простий проект розробки програмного забезпечення, в якому якість коду та тестування мають головне значення. Я маю честь працювати з людьми, які можуть перетворити складне бачення продукту в стабільно працююче програмне забезпечення з такою чудовою ефективністю та швидкістю.

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