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

Оригінальний автор: Fu Shaoqing, SatoshiLab, Bihelix, All Things Island BTC Studio

Читайте коментарі:

(1) Ця стаття є трохи незрозумілою, оскільки вона включає деякі базові принципи системи, а автор має обмежений теоретичний і практичний досвід роботи з розподіленими системами. Звичайні читачі можуть безпосередньо прочитати висновок, який є архітектурою великомасштабних програм web3.0 у розділі 3.3.

(2) Для класифікації побудови другого рівня зверніться до статті «Стаття, яка підсумовує базову систему знань про побудову другого рівня біткойна (рівень 2)». Згідно з класифікацією структури системи в довідковій статті, другий рівень Bitcoin Layer 2 поділяється на три типи: структура блокчейну, структура розподіленої системи та структура централізованої системи.

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

(4) Три кути огляду: розподілена книга, кінцевий автомат, блокова + ланцюгова структура

Передмова Багаторівневі та багаторакурсні

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

(1) Кілька рівнів

Загалом багаторівневість можна спостерігати на макро-, мезо- та мікрорівнях, або з точки зору часових циклів для спостереження можна використовувати короткострокові, середньострокові та довгострокові рівні. Розвиваючи екосистему Bitcoin, ми можемо отримати більш повне, глибоке та точне розуміння екосистеми Bitcoin, спостерігаючи за нею з трьох рівнів: короткострокового, середньострокового та довгострокового.

Ось резюме вчителя Дашана: «Екосистема біткойн поділяється на три можливості: короткострокові, середньострокові та довгострокові: Короткострокова можливість для екосистеми біткойн — це трек Inscription, представлений BRC-20; Середньострокова можливість — трек Bitcoin Layer 2; довгостроковий трек — протокол RGB і BitVM 2 трек; трек Nostr плюс трек поза ланцюгом (представлений RGB і BitVM).

У Розділі 3.4 цієї статті рання стадія побудови другого рівня на основі ланцюжка також класифікується як короткострокова можливість у Розділі 3.4.

(2) Кілька кутів

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

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

1. Три кути огляду

У документі Ethereum «Ethereum EVM Illustrated» вказано, що існує три кути огляду для блокової структури Ethereum (розподілена книга, кінцевий автомат, блокчейн). Це спостереження також стосується біткойнів і більше підходить для спостереження за екологічною структурою біткойнів. У наступному вступі ми розуміємо з цих трьох точок зору, і будуть різні переваги.

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

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

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

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

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

1.1. Бізнес-перспектива — розподілена книга

З точки зору реєстру, блокчейн — це група транзакцій, як і сторінки даних, записані в реєстрі.

З точки зору бухгалтерських книг нам легше зрозуміти його бізнес-можливості та його грошові та фінансові функції. Це також роль бухгалтерської книги в загальній архітектурі програм Web3.0.

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

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

1.2. Абстрактна перспектива обчислень — кінцевий автомат

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

З точки зору стану, блокчейн — це кінцевий автомат на основі транзакцій. Транзакція — це умова тригера, яка змушує вихідний стан σt перетворюватися на наступний стан σt+ 1 під дією транзакції.

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

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

З точки зору стану, коли ми спостерігаємо за блокчейном + розподіленою системою, буде легше зрозуміти правила передачі стану та зміни в двох системах.

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

1.3 Технічна перспектива реалізації — блочна + ланцюгова структура

З точки зору технічної реалізації, такі системи, як Bitcoin та Ethereum, є блокчейном. Розрізнені дані пов’язані між собою за допомогою блоку даних і хеш-покажчика всередині.

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

Ми можемо легко зрозуміти характеристики цієї структури реалізації технології блок + ланцюг, а також можемо розрахувати показники ефективності. Наприклад, розмір блоку мережі Bitcoin становить 1 млн (теоретичний максимум становить 4 млн після підтримки Segregated Witness), і кількість підтримуваних транзакцій можна повністю розрахувати.

Формула розрахунку така: (розмір блоку/середній розмір транзакцій)/середній інтервал часу блоку. За звичайних обставин кожен блок біткойн може вмістити приблизно 2000-3000 транзакцій або 3-7 TPS.

1.4. Основні характеристики блокчейну та характеристики трьох будівельних структур рівня 2

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

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

(1) Структура блокчейна

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

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

Верхня межа блокчейн-системи — це максимальна кількість транзакцій, яку може вмістити одна ємність блоку. Наприклад, рівень біткойна має 7 TPS на секунду, а ланцюжок рівня 2 має продуктивність 100 TPS. Тоді дві структури разом складають 700 TPS.

Щоб розширити продуктивність структур, що містять блокчейн, необхідна багатошарова конструкція, і її потрібно використовувати в поєднанні з гетерогенними системами. Для роботи, яка має бути виконана в системі блокчейн, потрібно записати лише дані, які потрібно глобально зберегти та обчислити. Інші неглобальні дані можуть бути призначені іншим рівням для обробки, щоб оброблені дані та код були лише пов’язані. відповідним сторонам.

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

(2) Розподілена система

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

Таким чином, якщо ми можемо використовувати розподілену систему в конструкції другого рівня на основі функції реєстру першого рівня біткойна, ми теоретично зможемо досягти необмеженого розширення продуктивності, зберігаючи основні характеристики блокчейну. Випадок у цій галузі представлений мережею Bitcoin + Lightning. Продуктивність цієї комбінації становить 7 TPS * ∞.

Причина досягнення повноти Тьюринга в розподіленій системі полягає в тому, що вартість запису та виконання смарт-контрактів у системі блокчейн дуже висока, оскільки це глобальні дані та глобальний код. Тому смарт-контракти також підходять для багаторівневої теорії, яка обмежує зберігання коду та виконання смарт-контрактів учасниками. Це також сценарій, коли перевірка на стороні клієнта відбувається в розподілених системах, щоб брати участь у обчисленні лише надійні дані (стан, одноразова печатка) між відповідними сторонами, а повні обчислення Тьюринга виконуються лише локально. Це те, що часто говорять про загальномережевий консенсус і консенсус учасників у розподілених системах. Найбільша складність у створенні другого рівня з розподіленою структурою системи полягає в тому, що технічна реалізація є відносно складною. Такі мережі, як Lightning Network, які просто вирішують проблеми з оплатою, розвиваються повільно та мають багато недоліків. Ще складніше реалізувати повні обчислення за Тьюрингом у розподіленій системі. Повільний розвиток і повільне оновлення версій RGB є зразком.

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

(3) Централізована система

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

Будівництво другого поверху централізованої системи може використовуватися як додаткове або перехідне рішення до двох інших способів.

(4) Комплексний аналіз

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

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

Як правило, невеликі програми потрібно завершувати лише в одному блокчейні. Трохи більші системи підходять для завершення на другому рівні конструкції блокчейн + блокчейн. Але для великомасштабних додатків кращим рішенням є використання системи блокчейн + розподілена система. З точки зору продуктивності, верхня межа розподіленої системи теоретично необмежена, тому такою комбінацією є 7 TPS біткойна * ∞. Інженерна реалізація також буде обмежена деякими конкретними факторами, як правило, верхня межа такої системи обмежена можливостями маршрутизації розподіленої системи, можливостями обробки спрямованих ациклічних графів змін стану та іншими конкретними зв’язками технічної реалізації. Пізніше, у типовій прикладній архітектурі Web3.0, ви також можете побачити схему комбінування різних систем.

Через поєднання багатьох системних структур можна подолати обмеження базової теорії однієї системи. Наприклад, система блокчейн обмежена обмеженнями неможливого трикутника DSS, але якщо використовується система блокчейн + розподілена система, можна вирішити неможливий трикутник децентралізації D, безпеки S і масштабованості S. Інші комбінації, блокчейн + централізована система, також можуть певною мірою вирішити проблему масштабованості. Розподілена система + централізована система може вирішити обмеження трикутника CAP у розподілених системах.

В історії розвитку техніки в минулому також були випадки комбінованого використання. Наприклад, коли централізована база даних має обмежені можливості, вона приймає структуру «головний-підлеглий», потім переходить до підбаз даних і підтаблиць, до розподілених баз даних, які є прикладами використання централізованих систем і розподілених систем.

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

2. Перегляньте дизайн і розробку другого рівня Bitcoin з точки зору кінцевої машини

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

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

З точки зору кінцевої машини, архітектура додатків екосистеми Bitcoin або Web3.0 використовує ці комбінації систем для завершення обробки перетворень стану, завершуючи тим самим обробку бізнес-логіки.

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

2.1. Базові знання про стани та кінцеві автомати в теорії графів

У теорії графів базові знання про стани та кінцеві автомати включають наступне:

Стан: стан відноситься до вузла або вершини в теорії графів. У орієнтованому графі стан може бути представлений у вигляді вузла, а в неорієнтованому графі стан може бути представлений у вигляді вершини.

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

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

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

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

Топологічне сортування: топологічне сортування відноситься до лінійного сортування вершин орієнтованого ациклічного графа (DAG), так що для будь-яких двох вершин u і v, якщо є ребро (u, v), тоді u з’являється перед v в сортуванні.

Спрямований ациклічний граф (DAG): орієнтований ациклічний граф — це орієнтований граф, у якому немає циклу, який починається з вершини та повертається до вершини після проходження кількох ребер.

Найкоротший шлях: найкоротший шлях відноситься до шляху з найменшою сумою ваг ребер серед шляхів, що з’єднують дві вершини в графі.

Мінімальне остовне дерево: Мінімальне остовне дерево означає пошук дерева, яке містить усі вершини зв’язаного графа, щоб сума ваг ребер дерева була мінімальною.

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

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

2.2. Конечний автомат і розподілена система

Тут ми використовуємо кілька розподілених мереж, щоб представити:

(1) У мережі Lightning

У мережі Lightning Network точки знань, пов’язані зі станами та кінцевими автоматами:

Lightning Network — це рішення другого рівня для біткойнів, засноване на платіжному каналі в мережі Lightning Network -витратні операції.

Транзакції (тобто стани) у мережі Lightning Network реалізуються через контракти з блокуванням часу (HTLC) на основі хешування, за допомогою яких учасники можуть блокувати кошти (стан передається між системами Bitcoin і Lightning Network) і проводити безпечні транзакції в межах каналів. (проста обробка стану).

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

Ретрансляційні вузли в Lightning Network: ретрансляційні вузли — це вузли, які можуть пересилати платіжні запити та допомагати здійснювати міжканальні платежі.

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

Конфіденційність платежів у мережі Lightning: оскільки транзакції в мережі Lightning Network здійснюються в межах каналу, усі транзакції не потрібно записувати в блокчейн, тому конфіденційність платежів можна покращити.

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

(2) У RGB точки знань, пов’язані зі станом, кінцевою машиною та каналом стану:

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

RGB базується на технології державного каналу в Bitcoin або Lightning Network. Канал статусу в RGB відноситься до каналу зв’язку між двома або більше сторонами, створеного на основі LNP і BP. У каналі можна виконувати кілька транзакцій і оновлення статусу, що зменшує кількість транзакцій і комісій у блокчейні.

Канали стану в RGB використовують скрипти з кількома підписами на основі біткойнів для блокування коштів і використовують спеціальні типи транзакцій для оновлення стану каналу.

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

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

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

Канали стану в RGB можна поєднувати з іншими технологіями та протоколами, такими як Lightning Network, LNURL тощо, щоб забезпечити більш багату функціональність і кращий досвід користувача.

Для забезпечення надійності та доступності системи при розробці та реалізації каналів стану в RGB необхідно враховувати такі фактори, як безпека, конфіденційність, масштабованість тощо.

(3) У Nostr — поняття, пов’язані зі станами, кінцевими автоматами та державними каналами.

У Nostr, оскільки інформація передається, поняття стану (довірені дані, цифрова валюта) і кінцевої машини ще не знайшли відображення. Однак я вважаю, що якщо розподілену структуру Nostr трохи змінити і обробку статусу збільшити, буде сформована система, подібна до Lightning Network, яка зможе як передавати інформацію, так і доставляти цінності. Можливість поступового перетворення цієї розподіленої системи на основі інформації в розподілену систему, що включає обробку значень, також описана в діаграмі архітектури програми Web3.0 у Розділі 3.3.

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

(4) У розподілених системах точки знань, пов’язані з кінцевими автоматами, включають:

Модель кінцевого автомата: кінцевий автомат — це математична модель, яка описує переходи та поведінку системи між різними станами. У розподілених системах моделі кінцевих автоматів часто використовуються для опису поведінки та змін стану системи.

Скінченний автомат (FSM): Скінченний автомат — це найпростіша модель кінцевого автомата, яка містить скінченний набір станів і набір правил переходу між станами. У розподілених системах кінцеві автомати можуть описувати різні стани системи та переходи між станами.

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

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

Узгодженість стану: у розподіленій системі кілька вузлів можуть мати різні стани. Узгодженість станів означає підтримання станів різних вузлів у системі узгодженими та узгодженими один з одним.

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

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

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

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

Масштабованість: розподілені кінцеві автомати повинні бути масштабованими, тобто вони повинні мати можливість підтримувати ефективні переходи між станами та узгодженість у міру збільшення масштабу системи.

2.3. Конечний автомат і система блокчейн

Згідно з документом Ethereum «Ethereum EVM illustrated», кожен блок — це набір тригерних станів, а вся система Ethereum — це процесор стану. У 1.2 ми представили вміст кінцевого автомата в системі блокчейн. Також є багато описів кінцевих автоматів у офіційному документі Ethereum.

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

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

2.4. Державна машина та централізована система

Приклади використання блокчейну + централізованих систем включають Ordinals і централізовану біржу CEX.

Такі системи є відносно простими, а деякі взагалі не мають передачі стану, як-от порядкові системи, які використовують лише централізовані індекси для завершення статистичної роботи.

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

У майбутніх додатках Web3.0 повинно бути більше випадків використання блокчейну + централізованих систем.

3. Як має виглядати структура програми Web3?

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

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

3.1. Класифікація загальних програм

Ми використовуємо статистику додатків у 48-му «Статистичному звіті про розвиток Інтернету в Китаї» як довідку, надалі – статистичний звіт. Оскільки Web2.0 зрілий і не впливає на аналіз класифікації додатків і результати масштабування користувачів, довідкові дані додатків, які ми використовуємо, є старими даними з 2020 і 2021 років. Слід зазначити, що це лише статистика китайського Інтернету. На етапі Web3.0 багато програм є глобальними, і користувачі мають вищі вимоги до масштабу та продуктивності.

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

Якщо всі програми Web2.0 перейти на Web3.0, більшість із них матиме дуже високі вимоги до продуктивності. Якщо взяти для прикладу оплату Visa, вимога до максимальної продуктивності становить: 65 000 TPS. Такі показники продуктивності можуть підтримуватися лише розподіленими системами. Наприклад, поточна продуктивність Lightning Network становить 40 мільйонів транзакцій за секунду Мережі теоретично недостатньо.

Крім того, ми беремо звичайні ігри як приклад. На даний момент повноцінна гра з найвищим TPS на блокчейні може досягти піку приблизно в кілька тисяч TPS, що є величезним відривом від традиційних ігор Web2 3A із сотнями тисяч. TPS. Якщо ви хочете перенести всі ігри на Web3.0, необхідна продуктивність інфраструктури стане великою проблемою.

Більше того, ігри є лише однією програмою в загальних категоріях програм, а інші програми мають більшу продуктивність і особливі вимоги.

3.2. Вимоги до програм Web3.0

Щоб зрозуміти потреби програми, буде простіше використовувати структуру доходу як показник. Ми посилаємося на звіт «Термінал токенів, куратор FutureMoney Research 2022 Q2». Хоча цей звіт є більш раннім, платіжні та інші програми знаходяться на початковій стадії і не вплинуть на основні результати аналізу. Тож автор був ледачий і використовував дані, коли я писав книги Web3.0. Якщо є дані за 4 квартал 2023 року, вони будуть більш точними.

(1) Потрібен аналіз через звітність про доходи

Класифікація доходів у звіті краще відображає поточний склад основного продукту Web3.0. як показано на малюнку.

1. Дохід Рівня 1 (основного основного ланцюга в блокчейні) становить 48%, що становить майже половину загального доходу, можна розуміти як «продаж блокового простору»;

2. Дохід торгової платформи NFT становить 22%, а її бізнес-модель можна розуміти як роялті або маркетингову діяльність;

3. Дохід від DeX у DeFi становить 15%, а його бізнес-модель — це комісія за транзакції та дохід від ліквідності на ринку;

4. Дохід від ставки в DeFi становить 8%, а його бізнес-модель полягає в розподілі комісій або відсотків від управління активами;

5. Gamefi становить 5%, а його бізнес-модель полягає в роялті, комісії за передачу, продажі NFT тощо;

6. Прибуток від кредитування в DeFi становить близько 1%, а його бізнес-модель – це процентний спред;

7. Дохід Tooling становить близько 1%, а його бізнес-модель — це комісія за послуги, яка в майбутньому також включатиме комісію за монетизацію трафіку;

Інші галузі, пов’язані з Web3.0, не є програмами Web3.0, не вважаються основними галузями Web3.0 і не будуть включені. Наприклад: ЗМІ Web3.0, дослідницькі організації, навчальні організації тощо.

Зі структури доходу ми бачимо, що поточні потреби додатків екосистеми BTC можна в основному вирішити за допомогою блокчейну та його системи другого рівня без потреби у складній архітектурі системи. Проте Gamefi та SocialFi розвиваються відносно швидко. Використовуючи приклади ігор у довідковій літературі, ми бачимо, що масштабні ігри вже мають більш високі та чіткі вимоги до структури системи.

Зі структури доходу ми бачимо потреби поточної екосистеми BTC. Варто переробити всі продукти в Ethereum та інших екосистемах. Дещо змінивши ланцюгову технологію побудови другого рівня в екосистемі Ethereum і створивши новий другий рівень на біткойнах, можна краще задовольнити ці основні потреби, але лише в міру децентралізації, безпеки, конфіденційності та стійкості до цензури був зроблений. У «Статті, що підсумовує базову систему знань про конструкцію другого рівня (рівень 2) біткойна», усі ці нові конструкції другого рівня, засновані на типі EVM, є випадками цієї ситуації.

(2) Аналіз прикладних випадків використання ігор з високими вимогами до продуктивності

У статті «The Impossible Becomes Possible: Making Full-Chain Game Development a Reality on the Lightning Network» є більший попит як на функціональність, так і на продуктивність. Справжня архітектура додатків Web3.0 поступово з’являється.

Опис проблеми в статті: На основі забезпечення безпеки, конфіденційності та децентралізації повноланцюгові ігри ніколи не знаходили оптимального рішення для масштабованості. Наприклад, найпопулярніші повноланцюгові ігрові движки Mud і Dojo прагнуть допомогти повноланцюжковим іграм досягти вищого TPS, але гравцям все одно потрібно більше 2 секунд буферизації для кожної операції. Фактично, поточна повноланцюгова гра з найвищим TPS у блокчейні може досягти піку приблизно в кілька тисяч TPS, що є величезним відривом від традиційних ігор Web2 3A із сотнями тисяч TPS. Переслідуючи передумову не втратити переваги блокчейну, повноланцюгові ігри можуть подолати масштабованість.

У рішенні, яке обговорюється далі в технічному обговоренні, Lightning Network і RGB використовуються для розширення продуктивності, а також пропонуються концепції тимчасових і виділених ланцюжків.

Ефемерний ланцюжок

Ефемерні блокчейни можна визначити як блокчейни, які не існують вічно та знищуються, коли виконується мета блокчейну (наприклад, запис транзакцій) або коли його стан постійно зберігається в іншому місці. Статус завершення, який зберігається в тимчасовому ланцюжку, — це просто дані про факти завершення, пов’язані з тимчасовим ланцюжком, таким чином стискаючи все на значний порядок величини. Тимчасові ланцюжки в основному обмежені затримкою транзакцій і пропускною здатністю блокчейну.

Тимчасовий ланцюг VS канал стану

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

Блокчейни для окремих програм

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

На прикладі цієї гри в поєднанні з нашим попереднім аналізом кількох архітектур ми можемо приблизно судити про архітектуру майбутніх великомасштабних програм.

3.3 Як має виглядати архітектура, яка відповідає широкомасштабним програмам Web3.0?

У попередньому матеріалі ми дізналися про типові категорії програм у Web2.0. Усі ці програми було оновлено до Web3.0, що є ознакою повного вступу в еру Web3.0. Яка архітектура може задовольнити багато програм, наведених вище?

(1) Прості архітектурні відмінності між Web2.0 і Web3.0

Ось зміст статті «Архітектура програми Web 3.0», написаної богинею блокчейну Пріті Касиредді. Структурний опис додатків Web3.0 тут є дуже простою структурою, яка покладається лише на систему блокчейн. Однак ця структура є надто простою, не відображає конструкцію другого рівня та непридатна для великомасштабних застосувань.

Порівнюючи випадки технічної реалізації традиційних централізованих продуктів і продуктів Web3.0, буде легше зрозуміти відмінності в технічній реалізації. У поєднанні з описом Ґевіна Вуда бачення технологічного стеку Web3.0 ми бачимо, що найбільша різниця в технічній реалізації Web3.0 знаходиться на задньому плані, а різниця в рівні взаємодії з користувачем є відносно невеликою.

(2) Системна архітектура для великомасштабних програм в епоху Web3.0

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

Завдяки системі блокчейн ми вступили в епоху Web3.0, це складна архітектура, побудована на системі блокчейн, розподіленій системі та централізованій системі. Серед них система блокчейн та її розширення другого рівня завершують передачу та обробку цінності, а розподілена система та централізована система завершують передачу та обробку інформації.

Як показано нижче,

Конкретний вміст описано таким чином:

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

(2) Система, подібна до RGB, також потребуватиме деяких тимчасових ланцюжків або проміжних ланцюжків для виконання функції розрахунків у реєстрі, як показано синьою лінією на малюнку. Ігровий випадок у Посиланні 1 описує цей сценарій. Він не з’явився у великих масштабах, тому що побудова RGB-подібних систем складна і ще не досягла зрілості.

(3) Окрім екосистеми біткойн, існують також інші екосистеми системи блокчейн, які відповідають потребам різних бізнес-сценаріїв. Як ми описали в статті про інфраструктуру другого рівня, буде багато проектів на другому рівні, заснованих на ланцюжку, і те саме стосується ланцюжків в екосистемі, яка не є біткойнами. Інші системи блокчейну та другі рівні також можуть входити в Lightning Network і RGB, і це відбуватиметься поступово в міру розвитку технології.

(4) В екосистемі Web3.0 централізовані системи також матимуть місце, але їх частка вже не буде такою великою, як у Web2.0. Централізовані системи мають багато переваг.

(5) У реальних програмах внутрішня проводка на малюнку вище стане складнішою. Деяким не потрібно використовувати другий рівень, але безпосередньо керувати мережею першого рівня, наприклад, коли RGB використовує протокол BP. Інші блокчейни також можуть використовувати розподілені системи, такі як мережа Raiden на Ethereum. Хоча вона незріла, якщо існують сценарії попиту, будуть сценарії використання шляхом трансформації деяких основних функцій. Наведений вище малюнок є спрощеним описом архітектури програми Web3.0.

3.4 Можливі шляхи будівництва

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

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

(1) Перша фаза є ранньою стадією двошарової конструкції на основі написів і ланцюжків

Двошарова конструкція на основі написів і ланцюжків відносно проста і в даний час має багато застосувань. Незалежно від того, чи це brc 20, src 20, arc 20, написи та інші додатки, або ті ланцюгові сторони проекту будівництва другого рівня, усіх їх багато.

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

(2) Друга стадія — це середня та пізня стадії побудови другого рівня на основі ланцюга та побудови другого рівня на основі розподіленої системи.

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

(3) Масштабне будівництво на основі екології Bitcoin

Останнім етапом є етап зрілості. На цьому етапі Web3.0 починає створюватися у великих кількостях і поступово розвивається. Звичайні програми, описані в 3.1, почали входити в епоху Web3.0.

Можливо, цей етап займе більше часу, можливо, буде подія точки перегину, яка може сприяти входженню великої кількості програм Web2.0, і час може бути не таким довгим.

Незважаючи ні на що, коли настане справжня ера Web3.0, його функції та продуктивність будуть більшими та блискучими, ніж поточний Інтернет для ПК + мобільний Інтернет загалом. Можливо, це схоже на появу Сори в області штучного інтелекту, що дуже дивно і шокуюче, але процес не такий раптовий.

Довідковий опис

(1) Зверніться до статей і змісту курсу пана Дашана про короткострокові, середньострокові та довгострокові аспекти екології біткойнів.

(2) «Неможливе стає можливим: створення повної ланцюжкової розробки ігор у реальність у мережі Lightning» (Натхнення та перевірка цієї статті ще більше)

(3) Три кути спостереження в основному стосуються «ілюстрованого Ethereum EVM», Такенобу Т., 2018.3

(4) Для вмісту, пов’язаного з класифікацією додатків, здебільшого зверніться до «Web3.0: Building the Digital Future of the Metaverse», написаного автором у 2022 році.

(5) Зверніться до знань теорії графів в університетській цифровій логіці.

(6) Зроблено посилання на деякі статті про розподілені системи.