Модульні блокчейни: відстеження виконання, дані та розрахунки
Модульний блокчейн розподіляє відповідальність між компонентами, а не вимагає від однієї системи виконання кожного завдання. Це може зробити опис мережі простим: виконання відбувається тут, дані надходять туди, а розрахунок відбувається в іншому місці. Важливе питання полягає в тому, що насправді гарантує кожен компонент.
У цій статті порівнюються архітектурні ролі, а не символічні ціни чи рейтинг проектів. Модульна конструкція автоматично не означає менший ризик, вищу віддачу від інвестицій або однакову безпеку в усіх реалізаціях.
Розділіть завдання перед порівнянням систем
Виконання застосовує правила транзакцій і обчислює запропоновану зміну стану. Доступність даних стосується того, чи була доступна інформація, необхідна для перевірки системи. Врегулювання стосується того, як криптографічні зобов’язання щодо стану ланцюга (state commitments), докази чи суперечки приймаються відповідно до певного протоколу. Консенсус визначає погоджений порядок або прийняту історію в системі.
Ці ролі можуть збігатися або розподілятися різними способами. Міток проекту недостатньо: мережа може називати себе модульною, зберігаючи значний контроль у секвенсорі, ключі оновлення або комітеті даних. Намалюйте фактичну карту залежностей, а не припускайте, що всі модульні мережі мають одну модель довіри.
Документація Ethereum щодо доступності даних пояснює, чому перевірка залежить від доступу до даних транзакцій і чому легкі клієнти та зведені пакети потребують відповідних гарантій. Питання доступу до даних відрізняється від того, чи правильно виконане обчислення.
Слідкуйте за гіпотетичною транзакцією
Уявіть, що користувач надсилає транзакцію до мережі виконання. Секвенсор включає його в пакет. Система робить необхідні дані доступними, використовуючи вибраний рівень даних, і передає криптографічне зобов’язання щодо стану ланцюга (state commitment) з механізмом перевірки, якого вимагає її дизайн, на рівень розрахунків.
Користувач може побачити раннє підтвердження до того, як кожен етап досягне остаточного статусу. Запишіть значення кожного статусу: отримано, впорядковано, виконано, дані опубліковано, підтвердження прийнято або вікно оскарження завершено. Не позначайте найбільш раннє підтвердження як остаточний розрахунок, якщо протокол не підтримує таке тлумачення.
Цей приклад описує ролі, а не приписує одну універсальну послідовність. Різні зведені та модульні системи можуть поєднувати етапи або використовувати різні механізми перевірки та остаточності.
Запитайте, що відбувається, коли компонент виходить з ладу
Якщо секвенсор зупиняється, чи можуть користувачі надсилати транзакції іншим способом і за яких умов? Якщо служба даних приховує інформацію, хто це виявляє та що користувачі можуть перевірити? Якщо рівень розрахунків перевантажений, як це вплине на зобов’язання або зняття?
Дайте відповіді на ці запитання з поточної документації, включаючи процедури надзвичайних ситуацій та адміністративний контроль. Запасний варіант, описаний у дорожній карті, не обов’язково працює. Мережа, яка продовжує відображати баланси, може все ще мати обмежену здатність приймати транзакції або завершувати зняття.
Перегляньте залежності міст окремо. Маркер, що з’являється у двох мережах, не означає, що маршрут передачі успадковує всі властивості безпеки обох ланцюгів.
Порівняйте повну вартість і досвід користувача
Низька комісія за виконання є лише частиною вартості транзакції. Публікація даних, врегулювання, перекриття та операції зняття можуть призвести до додаткових витрат або затримок. Порівняйте еквівалентні дії за той самий період і поясніть, хто яку вартість оплачує.
Виміряйте повний маршрут, що стосується користувача: вхід, виконання, підтвердження, виведення та повернення до потрібного активу чи мережі. Порівняльний показник, що охоплює лише один етап, не повинен представлятися як ціна всієї подорожі туди й назад. Економія коштів також може залежати від попиту та умов рівня даних.
Використовуйте контрольний список залежностей
Для кожної системи запишіть правила виконання, повноваження щодо замовлення, розташування даних, механізм перевірки, пункт призначення розрахунків, засоби керування оновленням і процедуру виходу. Позначте, які претензії активні, а які заплановані. Включіть джерела та перевірену дату, оскільки архітектурні параметри можуть змінюватися.
Щодо пов’язаної, але окремої проблеми, прочитайте порівняння міжланцюжкових повідомлень: воно відповідає інструкціям між ланцюжками, тоді як цей посібник відповідає розподілу роботи всередині архітектури.
Інженерний дизайн протоколу та економічні права його токена є окремими дослідницькими питаннями. Перевірте корисність токенів і фактичну ринкову доступність самостійно за допомогою офіційної документації та сторінки ринків OrangeX, а не розглядайте претензію щодо масштабування як торговельний висновок.
