Scaling Blockchains With Off-chain Data

Перевидано Платоном

читають: 0

Коли хеш вартий мільйона слів

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

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

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

Конфіденційність і масштабованість

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

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

З іншого боку, масштабованість є більш серйозною проблемою. Скажімо, будь-яка пристойна блокчейн-платформа повинна підтримувати пропускну здатність мережі 500 транзакцій на секунду. Якщо метою ланцюжка є зберігання інформації, то розмір кожної транзакції залежатиме в першу чергу від того, скільки даних вона містить. Для кожної транзакції знадобиться (принаймні) 100 байт накладних витрат для зберігання адреси відправника, цифрового підпису та кількох інших частинок.

Якщо ми візьмемо простий випадок, де кожен елемент є невеликою структурою JSON із 100 байтів, загальна пропускна здатність даних становитиме 100 кілобайт на секунду, обчислену за формулою 500 × (100+100). Це означає менше 1 мегабіт/секунду пропускної здатності, що цілком відповідає можливостям будь-якого сучасного підключення до Інтернету. Дані будуть накопичуватися зі швидкістю близько 3 терабайт на рік, що не мало. Але зараз з жорсткими дисками на 12 терабайт широко доступні та RAID Контролери, які об’єднують кілька фізичних дисків в один логічний, ми могли б легко зберігати 10-20 років даних на кожному вузлі без зайвих клопотів чи витрат.

Однак усе виглядає зовсім інакше, якщо ми зберігаємо більші частини інформації, наприклад скановану документацію. Розмір аркуша паперу формату А4 у форматі JPEG прийнятної якості може мати розмір 500 кілобайт. Помножте це на 500 транзакцій за секунду, і ми отримаємо пропускну здатність 250 мегабайт в секунду. Це означає 2 гігабіт/секунду пропускної здатності, що швидше, ніж у більшості локальних мереж, не кажучи вже про з’єднання з Інтернетом. У Amazon Web Services найдешевше опублікована ціна 0.05 дол. США за гігабайт, це означає річний рахунок за пропускну здатність 400,000 8000 дол. США за вузол. І де кожен вузол зберігатиме XNUMX терабайт нових даних, що генеруються щорічно?

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

Розчин хешування

Тож як вирішити проблему масштабованості даних? Як ми можемо скористатися перевагами децентралізованого нотаріального завірення даних у блокчейні, не копіюючи ці дані на кожен вузол ланцюга?

Відповідь полягає в розумній технології під назвою «хеш». Хеш — це довге число (приміром, 256 біт або близько 80 десяткових цифр), яке однозначно ідентифікує частину даних. Хеш обчислюється з даних за допомогою a одностороння функція який має важливу криптографічну властивість: за будь-якої частини даних легко й швидко обчислити її хеш. Але враховуючи певний хеш, обчислювально неможливо знайти фрагмент даних, який би генерував цей хеш. І коли ми говоримо «обчислювально неможливо», ми маємо на увазі більше обчислень, ніж атомів у відомому Всесвіті.

Хеші відіграють вирішальну роль у всіх блокчейнах завдяки унікальній ідентифікації транзакцій і блоків. Вони також лежать в основі обчислювальної проблеми в системах підтвердження роботи, таких як біткойн. Було розроблено багато різноманітних хеш-функцій, які мають такі мовчазні назви, як BLAKE2, MD5 і RIPEMD160. Але для того, щоб будь-яка хеш-функція заслужила довіру, вона має пройти ретельний академічний огляд і тестування. Ці тести відбуваються у вигляді спроб атак, таких як «прообраз» (пошук вхідних даних із заданим хешем), «другий прообраз» (пошук другого вхідних даних із тим самим хешем, що й заданий вхід) і «зіткнення» (пошук будь-яких два різні входи з однаковим хешем). Вижити в цьому випробуванні непросто, оскільки довга і трагічна історія несправних хеш-функцій підтверджує знамените правило: «Не крутіть свою власну криптовалюту».

Повертаючись до нашої початкової проблеми, ми можемо вирішити проблему масштабованості даних у блокчейнах, вставляючи хеші великих фрагментів даних у транзакції замість самих даних. Кожен хеш діє як «зобов’язання» щодо своїх вхідних даних, причому самі дані зберігаються поза блокчейном або «поза ланцюгом». Наприклад, використовуючи популярну хеш-функцію SHA256, 500-кілобайтне зображення у форматі JPEG може бути представлено 32-байтовим числом, що становить понад 15,000 500 разів. Навіть зі швидкістю XNUMX зображень на секунду це комфортно повертає нас на територію реальних вимог до пропускної здатності та зберігання з точки зору даних, що зберігаються в самому ланцюжку.

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

Питання доставки

Все йде нормально. Вбудовуючи хеші в блокчейн замість вихідних даних, ми маємо просте вирішення проблеми масштабованості. Тим не менш, залишається одне важливе питання:

Як ми доставляємо оригінальний вміст поза ланцюгом до тих вузлів, які його потребують, якщо не через сам ланцюг?

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

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

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

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

Для тих, хто має досвід одноранговий обмін файлами протоколи, такі як Napster, Gnutella або BitTorrent, все це буде здаватися дуже знайомим. Дійсно, багато основних принципів однакові, але є дві ключові відмінності. По-перше, якщо припустити, що ми використовуємо наш блокчейн у корпоративному контексті, система працює в закритій групі учасників, а не в Інтернеті в цілому. По-друге, блокчейн додає децентралізоване впорядкування, штампування часу та нотаріальне засвідчення, що дозволяє всім користувачам підтримувати послідовне та захищене від втручання уявлення про те, що саме сталося, коли та ким.

Яким чином розробник блокчейн-додатків може досягти такої децентралізованої доставки вмісту поза мережею? Одним із поширених варіантів є використання існуючої однорангової платформи обміну файлами, такої як кумедна назва Міжпланетна файлова система (IPFS), і використовувати його разом з блокчейном. Кожен учасник запускає як вузол блокчейну, так і вузол IPFS, з деяким проміжним програмним забезпеченням, яке координує їх роботу. Під час публікації даних поза мережею це проміжне програмне забезпечення зберігає вихідні дані в IPFS, а потім створює транзакцію блокчейну, що містить хеш цих даних. Щоб отримати деякі дані поза мережею, проміжне програмне забезпечення витягує хеш із блокчейну, а потім використовує цей хеш для отримання вмісту з IPFS. Локальний вузол IPFS автоматично перевіряє отриманий вміст на відповідність хешу, щоб переконатися, що його не було змінено.

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

Дані поза мережею в MultiChain 2.0

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

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

Публікуючий вузол MultiChain записує нові дані у своє локальне сховище, розрізаючи великі елементи на частини для легкого перетравлення та доставки.
Транзакція для публікації елементів потоку поза ланцюгом створюється автоматично, що містить хеш(и) фрагмента та розмір(и) у байтах.
Ця транзакція підписується та транслюється в мережу, поширюючись між вузлами та входячи в блокчейн звичайним способом.
Коли вузол, підписаний на потік, бачить посилання на деякі дані поза ланцюгом, він додає хеші фрагментів для цих даних до своєї черги отримання. (Підписуючись на старий потік, вузол також ставить у чергу будь-які раніше опубліковані елементи поза ланцюгом для отримання.)
У фоновому режимі, якщо в черзі отримання вузла є фрагменти, запити надсилаються в мережу, щоб знайти ці блоки, ідентифіковані за їх хешами.
Ці запити на фрагменти поширюються на інші вузли в мережі одноранговим способом (наразі обмежено двома переходами – див. технічні деталі нижче).
Будь-який вузол, який має дані для блоку, може відповісти, і ця відповідь передається абоненту назад по тому ж шляху, що й запит.
Якщо жоден вузол не відповідає на запит блоку, фрагмент повертається назад до черги для подальшої повторної спроби.
В іншому випадку абонент вибирає найбільш перспективне джерело для блоку (на основі стрибків і часу відповіді) і надсилає йому запит на дані цього блоку, знову ж таки за тим же одноранговим шляхом, що й у попередній відповіді.
Вихідний вузол доставляє запитувані дані, знову використовуючи той самий шлях.
Абонент звіряє розмір даних і хеш із вихідним запитом.
Якщо все перевірено, абонент записує дані у своє локальне сховище, роблячи їх негайно доступними для отримання через потокові API.
Якщо запитаний вміст не надійшов або не відповідає бажаному хешу чи розміру, фрагмент повертається назад до черги для майбутнього отримання з іншого джерела.

Найголовніше, що все це відбувається надзвичайно швидко. У мережах із низькою затримкою невеликі фрагменти даних поза мережею надходять до передплатників протягом частки секунди після транзакції, яка на них посилається. А для додатків із високим навантаженням наше тестування показує, що MultiChain 2.0 alpha 3 може підтримувати швидкість понад 1000 елементів поза ланцюгом або 25 МБ даних, отриманих за секунду, на сервері середнього класу (Core i7) із пристойною продуктивністю. Підключення до інтернету. Усе працює нормально з об’єктами поза ланцюгом розміром до 1 ГБ, що значно перевищує ліміт у 64 МБ для даних у ланцюзі. Звичайно, ми сподіваємося покращити ці цифри й далі, витрачаючи час на оптимізацію MultiChain 2.0 під час його бета-фази.

Використовуючи в потоках дані поза ланцюгом, а не в ланцюжку, розробники додатків MultiChain повинні робити саме дві речі:

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

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

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

Якщо ви хочете спробувати елементи потоку поза ланцюгом, просто дотримуйтеся регулярних правил MultiChain Приступаючи до роботи і не пропускайте розділ 5.

То що далі?

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

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

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

Тим часом ми вже розпочали роботу над «Розумними фільтрами», останньою важливою функцією, запланованою для спільноти MultiChain 2.0. Розумний фільтр — це фрагмент коду, вбудований у блокчейн, який реалізує власні правила для перевірки даних або транзакцій. Розумні фільтри мають певну схожість із «розумними контрактами» та можуть виконувати багато подібних завдань, але мають ключові відмінності щодо безпеки та продуктивності. Ми з нетерпінням чекаємо розповісти вам більше згодом.

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

Технічні деталі

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

Потокові політики. Коли створюється потік MultiChain, його можна додатково обмежити, щоб дозволити лише дані в ланцюжку або поза ним. Існує кілька можливих причин для цього, замість того, щоб кожен видавець вирішував сам. Наприклад, елементи мережі пропонують залізну гарантію доступності, тоді як старі елементи поза мережею можуть стати безповоротними, якщо їх видавець та інші передплатники вийдуть з мережі. З іншого боку, елементи в ланцюжку неможливо «забути», не модифікувавши блокчейн, тоді як елементи поза ланцюгом є більш гнучкими. Це може бути важливо з точки зору правил конфіденційності даних, таких як нові європейські правила GDPR.
Метадані в мережі. Для елементів поза ланцюгом трансакція в ланцюзі все ще містить видавця(ів), ключ(и), формат (JSON, текстовий або двійковий) і загальний розмір. Все це займає дуже мало місця та допомагає розробникам додатків визначити, чи є недоступність елемента поза ланцюгом проблемою для певного потокового запиту.
Ліміт двох стрибків. Під час ретрансляції запитів на фрагменти через однорангову мережу існує компроміс між доступністю та продуктивністю. Хоча було б добре, щоб кожен запит поширювався по кожному окремому шляху, це може засмітити мережу непотрібними «балаканинами». Тож наразі запити фрагментів обмежені двома переходами, що означає, що вузол може отримувати дані поза ланцюгом від будь-якого однорангового вузла. У невеликих мережах до 1000 вузлів, які, як правило, характеризують корпоративні блокчейни, ми вважаємо, що це добре працюватиме, але нам легко відкоригувати це обмеження (або запропонувати його як параметр), якщо виявиться, що ми помиляємося.
Локальне сховище. Кожен вузол MultiChain зберігає дані поза ланцюгом у каталозі «chunks» свого звичайного каталогу blockchain, використовуючи ефективний двійковий формат та індекс LevelDB. Окремий підкаталог використовується для елементів у кожному з передплачених потоків, а також для тих, що публікуються самим вузлом. У кожному з цих підкаталогів повторювані фрагменти (з однаковим хешем) зберігаються лише один раз. Коли вузол скасовує підписку на потік, він може вирішити, видаляти чи ні дані поза ланцюгом, отримані для цього потоку.
Двійковий кеш. Під час публікації великих фрагментів двійкових даних, у ланцюжку чи поза ланцюгом, розробникам додатків може бути непрактично надсилати ці дані в API MultiChain в одному запиті JSON-RPC. Таким чином, MultiChain 2.0 реалізує двійковий кеш, який дозволяє створювати великі фрагменти даних за допомогою кількох викликів API, а потім публікувати їх на короткому заключному етапі. Кожен елемент у двійковому кеші зберігається як простий файл у підкаталозі «cache» каталогу blockchain, що дозволяє також надсилати гігабайти даних безпосередньо через файлову систему.
API моніторингу. MultiChain 2.0 alpha 3 додає два нових API для моніторингу асинхронного отримання даних поза мережею. Перший API описує поточний стан черги, показуючи, скільки фрагментів (і скільки даних) очікують, запитуються або витягуються. Другий API надає сукупну статистику для всіх запитів і запитів фрагментів, надісланих після запуску вузла, включаючи кількість різних типів помилок.
Очистити при публікації. Під час публікації елемента поза ланцюгом MultiChain гарантує, що його локальна копія даних повністю записана (або «скинута») на фізичний диск перед тим, як транзакція, яка посилається на ці дані, буде передана в мережу. В іншому випадку, якщо вузлу не пощастило втрачати живлення відразу після трансляції транзакції, дані поза ланцюгом можуть бути остаточно втрачені. Це не є проблемою для самого MultiChain, оскільки затримки між спробами отримання блоку з часом автоматично зростають. Але це може спричинити проблеми на прикладному рівні, коли всі знають про існування деяких даних, але ніхто не може їх знайти.
Видавнича діяльність. Скидаючи дані поза ланцюгом на диск таким чином, MultiChain може призвести до зниження продуктивності, оскільки фізичні диски повільні. Наприклад, жорсткий диск середнього діапазону 7200 об/хв може виконувати лише близько 100 випадкових записів даних на секунду, що, у свою чергу, обмежує швидкість, з якою окремий вузол може публікувати елементи поза мережею. Є три можливі способи вирішення цієї проблеми. По-перше, і найпростіше, вузли можуть використовувати твердотільний накопичувач (SSD) замість звичайного жорсткого диска, який підтримує 10,000 XNUMX операцій випадкового запису в секунду. По-друге, за допомогою API «createrawsendfrom» в одній транзакції можна опублікувати кілька елементів поза мережею. У цьому випадку MultiChain записує всі позаланцюгові дані, на які посилається транзакція, в одній дисковій операції. Нарешті, MultiChain можна налаштувати так, щоб не скидати дані поза ланцюга на диск перед трансляцією транзакції, яка на них посилається. Використовуйте цю опцію обережно.
Інтеграція рідної валюти. Для випадків використання, які цього вимагають, MultiChain завжди пропонував можливість використання рідної валюти в блокчейні, щоб запобігти спаму транзакцій та/або стимулювати валідатори блоків («майнери»). У цих випадках транзакції повинні пропонувати майнерам мінімальну комісію, пропорційну їхньому розміру в байтах, для того, щоб їх ретранслювати та підтверджувати в ланцюжку. Цей механізм було розширено, щоб дозволити запобігати спаму поза мережею, вимагаючи мінімальної додаткової плати за кілобайт даних поза мережею, на які посилається в транзакції.
Архівні вузли. Якщо вузол бажає підписатися на кожен потік і, отже, отримувати та зберігати кожен опублікований елемент поза ланцюгом, його можна налаштувати для цього за допомогою параметра часу виконання «autosubscribe». Будь-який такий вузол діятиме як резервний для всієї мережі, гарантуючи, що елементи поза мережею не будуть втрачені або недоступні, незалежно від того, які інші вузли зникнуть. Можна уявити сторонні компанії, які пропонують це як комерційну послугу.