Если рассматривать второй уровень Биткойна с точки зрения конечного автомата, как выглядит архитектура крупномасштабных приложений Web3?

Автор оригинала: Фу Шаоцин, SatoshiLab, Bihelix, All Things Island BTC Studio

Прочитайте комментарии:

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

(2) Классификацию конструкции второго уровня см. в статье «Статья, обобщающая базовую систему знаний конструкции второго уровня (Уровня 2) Биткойна». В соответствии с классификацией структуры системы, приведенной в справочной статье, второй уровень Биткойн-уровня 2 разделен на три типа: структура блокчейна, структура распределенной системы и структура централизованной системы.

(3) Наблюдая за конструкцией второго уровня Биткойна с точки зрения конечного автомата, вы обнаружите, что принцип конечного автомата применим ко всем трем системным структурам (система блокчейн, распределенная система, централизованная система), но реализация Метод ограничен структурой системы.

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

Предисловие Многоуровневые и многоракурсные

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

(1)Несколько уровней

Многоуровневые процессы обычно можно наблюдать на макро-, мезо- и микроуровнях, а с точки зрения временных циклов для наблюдения можно использовать краткосрочные, среднесрочные и долгосрочные уровни. При развитии экосистемы Биткойн мы можем получить более полные, глубокие и точные знания и понимание экосистемы Биткойн, наблюдая за ней на трех уровнях: краткосрочном, среднесрочном и долгосрочном.

Вот краткое изложение Учителя Дашана: «Экосистема Биткойн разделена на три возможности: краткосрочную, среднесрочную и долгосрочную: Краткосрочная возможность для экосистемы Биткойн — это трек Inscription, представленный BRC-20; среднесрочная возможность — это путь Bitcoin Layer 2 и Nostr Plus.Lightning Network трек; долгосрочная возможность — это путь решения вне цепочки, представленный протоколом RGB и BitVM. Он включает в себя четыре трека: трек Inscription и уровень. 2; трек Nostr plus Lightning Network; трек вне сети (представленный RGB и BitVM)».

В разделе 3.4 этой статьи ранняя стадия цепного построения второго уровня в Layer также классифицируется как краткосрочная возможность. Причины представлены в разделе 3.4.

(2) Несколько углов

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

Учитывая это множество точек зрения, мы начинаем с бизнес-перспективы — распределенный реестр (способствует пониманию бизнеса), абстрактной вычислительной точки зрения — конечный автомат (способствует пониманию реализации блокчейна + распределенных систем) и перспективы технической реализации — блок + структура цепочки (способствует пониманию блокчейн-части экосистемы).

1. Три угла обзора

В документе Ethereum «Ethereum EVM Illustrated» указано, что существует три угла обзора структуры блоков Ethereum (распределенный реестр, конечный автомат, блокчейн). Это наблюдение также применимо к Биткойну и больше подходит для наблюдения за экологической структурой Биткойна. В следующем введении мы понимаем эти три точки зрения, и будут разные выгоды.

С точки зрения конечного автомата не только легко понять статус и его обработку в блокчейне, но также легче понять статус, каналы состояния и переходы состояний в распределенной системе. структуру распределенной системы, будет легче понять маршрутизацию.Проблема состоит в том, чтобы понять требования направленного ациклического графа переходов состояний. Конечные автоматы основаны на базовых принципах абстрактных вычислений теории графов.Основываясь на этих принципах и конкретных структурах реализации (блокчейн, распределенная, централизованная), вы поймете конкретные проблемы, которые необходимо решить, и идеи решений.

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

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

Что касается структуры экосистемы Биткойн, с точки зрения реестров и конечных автоматов мы можем лучше понять преимущества и недостатки каждой структуры, а также то, как использовать три альтернативные структуры для создания второго уровня Биткойна, даже если мы построим Web3. 0 Вся архитектура приложения.

Когда я читал документацию Ethereum «Иллюстрация Ethereum EVM», у меня возникло такое ощущение. Наблюдение за вещами, которые можно сравнить с Эфириумом, с трех разных точек зрения дает нам некоторые идеи для размышления и ссылки на опыт обработки для решения Эфириума. Например, когда Ethereum рассматривается как автомат, основанный на состояниях, теории и алгоритмы конечных автоматов в компьютерной области могут быть адаптированы к Ethereum. Рассматривая Ethereum как базу данных на основе реестра, некоторые теории базы данных можно применить к Ethereum, например, идею сегментирования базы данных. Это ощущение также применимо к экосистеме Биткойн, и она будет смешана и использована в трех крупных системных структурах, что сделает гибкость еще большей.

1.1. Бизнес-перспектива: распределенный реестр

С точки зрения реестра, блокчейн — это группа транзакций, точно так же, как страницы данных, записанные в реестре.

С точки зрения реестров нам легче понять его бизнес-возможности, а также его денежно-кредитные и финансовые функции. Это также роль реестра в общей архитектуре приложений Web3.0.

С точки зрения реестров мы можем легко понять структуру второго уровня цепочки: счета разных предприятий могут регистрироваться в разных реестрах, а эти подрегистры могут быть объединены в общий реестр.

С точки зрения реестра + распределения мы можем понять, что если участнику предоставляется цифровая валюта, как с ней поступить и как разделить счета, участники могут вести переговоры и разобраться с ней сами и, наконец, записать ее в реестр. .

1.2. Абстрактная компьютерная перспектива — конечный автомат

Здесь мы сосредоточимся на конечных автоматах, поскольку эта перспектива может обеспечить хорошее понимание систем блокчейна и распределенных систем. И вы можете понять разницу между тем, как данные (или состояние) обрабатываются в системе блокчейна и как они обрабатываются в распределенной системе.

С точки зрения государства, блокчейн представляет собой конечный автомат, основанный на транзакциях. Транзакция — это условие триггера, которое приводит к преобразованию исходного состояния σt в следующее состояние σt+1 под действием транзакции.

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

Итак, с этой точки зрения блокчейн — это цепочка состояний (в распределенной системе это канал состояний). С точки зрения состояния, систему блокчейна можно рассматривать как автомат, основанный на состоянии.

С точки зрения состояния, когда мы наблюдаем блокчейн + распределенную систему, будет легче понять правила передачи и изменения состояния в двух системах.Обе системы на самом деле представляют собой автоматы, основанные на состоянии.

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

1.3 Техническая перспектива реализации — блочно-цепочная структура

С точки зрения технической реализации такие системы, как Биткойн и Эфириум, представляют собой блокчейн. Разбросанные данные связаны между собой блоком данных и хеш-указателем внутри.

Это всего лишь техническая структура реализации, предназначенная для работы такой системы, как блокчейн. Данные и вычисления в блокчейне используют глобальный подход, и только эта структура может выполнять функцию реестра. Детали реализации и применимость этой структуры необходимо учитывать при взаимодействии с внешними системами.

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

Формула расчета: (размер блока/средний размер транзакций)/средний интервал времени блока. При нормальных обстоятельствах каждый блок Биткойна может вместить примерно 2000–3000 транзакций или 3–7 TPS.

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

Обратитесь к трем классификациям конструкции второго уровня Биткойна: структура блокчейна, структура распределенной системы и структура централизованной системы. Сравнивая некоторые основные характеристики конструкции первого и второго слоев Биткойна, мы можем ясно увидеть различия между ними. Как показано в таблице ниже. Позже мы сравним требования приложений в разделе 3.2, чтобы помочь нам выбрать подходящую комбинацию архитектурных построений из этих базовых системных структур.

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

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

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

Самая большая проблема структуры блокчейна — низкая производительность. Для этого есть две причины: во-первых, структура блокчейна не может исключить сценарии частичных вычислений, и все запросы обрабатываются в режиме полного расчета. Например, частичный расчет и глобальный расчет, локальные данные и глобальные данные, временные данные и постоянные данные. Во-вторых, структура блокчейна имеет очевидный верхний предел производительности. Если расширение уровня 2 выполняется через цепочку, количество поддерживаемых транзакций также очень ограничено. Простой расчет выглядит следующим образом:

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

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

Судя по приведенной выше таблице, только структура блокчейна может реализовать функцию не требующего доверия реестра. Поэтому, если система хочет реализовать функцию не требующего доверия реестра, она должна включать в себя систему блокчейна. Однако из-за требований к производительности крупномасштабных приложений систему блокчейна необходимо комбинировать с другими системами для удовлетворения потребностей.

(2) Распределенная система

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

Следовательно, если мы сможем использовать распределенную систему в конструкции второго уровня, основанную на функции реестра первого уровня Биткойна, мы теоретически сможем достичь неограниченного расширения производительности, сохраняя при этом основные характеристики блокчейна. Примером в этой области является Биткойн + Lightning Network.Производительность этой комбинации составляет 7 TPS Биткойна * ∞.

Причина достижения полноты по Тьюрингу в распределенной системе заключается в том, что стоимость записи и выполнения смарт-контрактов в системе блокчейна очень высока, поскольку это глобальные данные и глобальный код. Следовательно, смарт-контракты также подходят для многоуровневой теории, которая ограничивает хранение кода и выполнение смарт-контрактов участниками. В этом сценарии также происходит проверка на стороне клиента в распределенных системах. Для участия в расчетах требуются только проверенные данные (состояние, одноразовая печать) между соответствующими сторонами, а расчеты по Тьюрингу выполняются только локально. Именно это часто говорят о общесетевом консенсусе и консенсусе участников в распределенных системах.Самая большая трудность в построении второго уровня со структурой распределенной системы заключается в том, что техническая реализация относительно сложна. Сети, подобные Lightning Network, которые просто решают проблемы с платежами, развиваются медленно и имеют множество недостатков. Еще сложнее реализовать Тьюринг-полные вычисления в распределенной системе. Медленная разработка и медленные обновления версий RGB являются эталонным примером.

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

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

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

Строительство второго этажа централизованной системы может использоваться как дополнительное или переходное решение к двум другим методам.

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

В эпоху ценностей из приведенного выше содержания мы видим, что трудно добиться эффекта удовлетворения потребностей, полагаясь только на одну систему. Это также практическая необходимость для второго уровня экологического развития Биткойна. Но то, как объединить эти три системы, требует большого изучения. Давайте сначала проанализируем это теоретически. Столкнувшись с разными потребностями, будут разные структуры объединения.

Прежде всего, с точки зрения концепции многоуровневого протоколирования, сеть Биткойн не требует полноты по Тьюрингу. Основываясь на этом самом базовом требовании, набор инструкций Биткойна можно свести к минимуму. Остальные функции оставлены на усмотрение расширений верхнего уровня. Помимо удовлетворения функциональных требований этого уровня, технология соединения между первым уровнем Биткойна и сетью верхнего уровня также нуждается в дальнейшем развитии и совершенствовании. как можно меньше места для данных Биткойна.

Как правило, небольшие приложения необходимо выполнять только на одном блокчейне. Чуть более крупные системы подходят для доработки на конструкции второго уровня блокчейн + блокчейн. Но для крупномасштабных приложений предпочтительным решением является использование системы блокчейн + распределенная система. С точки зрения производительности верхний предел распределенной системы теоретически неограничен, поэтому такой комбинацией является биткойнская 7 TPS * ∞. Инженерная реализация также будет ограничена некоторыми специфическими факторами.Обычно верхний предел такой системы ограничивается возможностями маршрутизации распределенной системы, возможностями обработки направленных ациклических графов изменения состояний и другими конкретными звеньями технической реализации. Позже в типичной архитектуре приложений Web3.0 также можно увидеть схему объединения различных систем.

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

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

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

2. Пересмотрите проектирование и разработку второго уровня Биткойна с точки зрения конечного автомата.

В трёх двухэтажных зданиях существуют состояния и государственные машины, но названия немного разные, из-за чего большинство людей не обращают внимания на этот ракурс наблюдения.

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

С точки зрения конечного автомата архитектура приложений экосистемы Биткойн или Web3.0 использует эти комбинации систем для завершения обработки преобразований состояния, тем самым завершая обработку бизнес-логики.

Используя идею конечных автоматов, мы рассмотрим двухуровневую структуру сети Биткойн и увидим, что каждый уровень архитектуры имеет разделение труда, подходящее для его характеристик.

2.1.Базовые знания о состояниях и конечных автоматах в теории графов

В теории графов базовые знания о состояниях и конечных автоматах включают следующее:

Состояние. В теории графов состояние относится к узлу или вершине. В ориентированном графе состояние можно представить в виде узла; в неориентированном графе состояние можно представить в виде вершины.

Переход состояний. Переход между состояниями означает процесс перехода из одного состояния в другое. В ориентированном графе переход состояний можно представить как направленное ребро; в неориентированном графе переход состояний можно представить как неориентированное ребро.

Машина состояний. Машина состояний – это абстрактная вычислительная модель, используемая для описания серии состояний и правил перехода между состояниями. Конечный автомат состоит из набора состояний, начального состояния, функции перехода и состояния завершения.

Направленный граф. Ориентированный граф – это структура графа, состоящая из вершин и ориентированных ребер. Направленные ребра указывают от одной вершины к другой, представляя отношения перехода между состояниями.

Неориентированный граф. Неориентированный граф – это структура графа, состоящая из вершин и неориентированных ребер. Неориентированные ребра соединяют две вершины и представляют собой связь между состояниями.

Топологическая сортировка. Топологическая сортировка — это линейная сортировка вершин ориентированного ациклического графа (DAG), так что для любых двух вершин u и v, если есть ребро (u, v), то u появляется перед v. в сортировке.

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

Кратчайший путь. К кратчайшему пути относится путь с наименьшей суммой весов ребер среди путей, соединяющих две вершины графа.

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

Эти базовые знания являются основными понятиями теории графов и используются для описания и анализа отношений и правил перехода между состояниями. Соответствующие знания и графики можно подробно изучить в профессиональных книгах.

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

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

Здесь мы используем несколько распределенных сетей, чтобы представить:

(1) В сети Lightning

В сети Lightning точки знаний, связанные с состояниями и конечными автоматами:

Сеть Lightning — это решение второго уровня для Биткойна, основанное на технологии канала состояния. Канал платежей в сети Lightning — это двусторонний канал состояния. Участники могут проводить в канале несколько транзакций и обновлять статус канала для достижения быстрого и низкого уровня. -стоимостные операции.Оплата затрат.

Транзакции (т. е. состояния) в сети Lightning реализуются посредством контрактов с временной блокировкой на основе хэша (HTLC), с помощью которых участники могут блокировать средства (состояние передается между системами Биткойн и сети Lightning Network) и проводить безопасные транзакции внутри каналов. (простая обработка состояния).

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

Узлы ретрансляции в сети Lightning. Узлы ретрансляции — это узлы, которые могут пересылать платежные запросы и помогать осуществлять межканальные платежи.

Двусторонний платеж в сети Lightning: Сеть Lightning позволяет участникам осуществлять двусторонние платежи в платежном канале, то есть они могут не только платить другой стороне, но и принимать платеж другой стороны.

Конфиденциальность платежей в сети Lightning: поскольку транзакции в сети Lightning проводятся внутри канала, все транзакции не нужно записывать в блокчейн, что позволяет повысить конфиденциальность платежей.

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

(2) В RGB точками знаний, связанными с состоянием, конечным автоматом и каналом состояния, являются:

RGB основан на протоколах LNP и BP. Существует дискуссия о том, является ли RGB вторым или третьим слоем. Если RGB напрямую рассчитывается на основе BP, он напрямую расширяет полную функцию Тьюринга Биткойна и принадлежит второму уровню. Этот метод имеет ограниченное расширение производительности. Если расчет RGB основан на LNP, он принадлежит к третьему уровню (потому что LNP — это второй уровень Биткойна).Этот метод может повысить как производительность, так и полную по Тьюрингу вычислительную мощность, но существует определенная сложность в технической реализации. . Обычно комбинированный метод позволяет не только расширить вычислительную мощность, но и повысить производительность и снизить сложность реализации.

RGB основан на технологии канала состояния в Биткойне или сети Lightning. Канал статуса в 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», каждый блок представляет собой набор триггерных состояний, а вся система Ethereum представляет собой процессор состояний. В версии 1.2 мы представили содержимое конечного автомата в системе блокчейна. В официальном документе Ethereum также есть много описаний конечных автоматов.

Хотя конечный автомат обладает мощными вычислительными возможностями, его верхний предел — это потолок структуры блокчейна.

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

2.4 Государственный аппарат и централизованная система

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

Такие системы относительно просты, а некоторые вообще не имеют передачи состояния, например, Ordinals, которые используют только централизованные индексы для выполнения статистической работы.

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

В будущих приложениях 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 составляет 40 миллионов транзакций в секунду, а производительность Lightning Network составляет 40 миллионов транзакций в секунду, а производительность Lightning Network - Сети теоретически недостаточно. Верхний предел.

Кроме того, в качестве примера мы возьмем обычные игры.В настоящее время полноцепная игра с самым высоким TPS в блокчейне может достигать пика около нескольких тысяч TPS, что является огромным разрывом с традиционными играми Web2 3A с сотнями тысяч ТПС. Если вы хотите перенести все игры на 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) Анализ сценариев использования приложений с высокими требованиями к производительности

В статье «Невозможное становится возможным: как сделать полноценную разработку игр реальностью в сети Lightning» отмечается повышенный спрос как на функциональность, так и на производительность. Реальная архитектура приложений Web3.0 постепенно формируется.

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

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

Эфемерная цепочка

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

Временная цепочка против канала состояния

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

Блокчейны для конкретных приложений

Блокчейны, ориентированные на конкретные приложения, — это блокчейны, созданные для запуска одного децентрализованного приложения (dapp). Вместо того, чтобы создавать существующую цепочку блоков, разработчики создают новую цепочку блоков с нуля, используя специальную виртуальную машину (ВМ), которая выполняет транзакции для взаимодействия пользователей с приложением. Разработчики также могут настраивать различные элементы сетевого стека блокчейна — консенсус, сеть и исполнение — в соответствии с конкретными требованиями к проектированию. Повышение скорости выполнения смарт-контрактов и решение ограничений вычислительных ресурсов могут помочь в реализации блокчейна для конкретных приложений. Разрешение разработчикам настраивать инфраструктуру для различных вариантов использования упрощает разработку. В то же время это позволяет разработчикам 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 Network на Ethereum. Рисунок выше представляет собой упрощенное описание архитектуры приложения Web3.0.

3.4. Возможные пути строительства

Из структуры доходов мы можем увидеть текущие потребности экосистемы BTC в приложениях, а из классификации часто используемых приложений мы можем увидеть будущие потребности для полного перехода на Web3.0. Это будет долгий путь. Поэтому дела с относительно длительным сроком строительства нужно решать поэтапно.

Три этапа здесь очень похожи на краткосрочный, среднесрочный и долгосрочный, упомянутые Учителем Дашаном. Он просто суммирует простой этап цепного построения второго слоя в первый этап строительства.

(1) Первая фаза представляет собой раннюю стадию двухслойной конструкции на основе надписей и цепочек.

Двухслойные конструкции на основе надписей и цепочек относительно просты и в настоящее время имеют множество применений. Будь то brc 20, src 20, arc 20, надпись и другие приложения или эти цепочки строительных проектов второго уровня, все они в изобилии.

Построение на этом этапе относительно простое, большинство из них — финансовые приложения, а при поддержке опыта трансформации и имитации второго слоя Эфириума оно происходит проще и быстрее. Хотя этот процесс относительно прост, он важен и важен. Этот этап в основном предназначен для завершения различных проверок функциональной осуществимости.

(2) Второй этап — это средние и поздние этапы построения второго уровня на основе цепочки и построения второго уровня на основе распределенной системы.

На этом этапе также задействовано построение второго слоя на основе цепочки, которое является продвинутым этапом построения на основе цепочки.Кроме того, второй этап фокусируется на тестировании и совершенствовании различных распределенных построек второго уровня. Сеть Lightning станет более зрелой, ее функции RGB и стабильность будут значительно улучшены, а сценарии ее применения станут богаче. Постепенно появятся и созреют конкуренты, подобные RGB, такие как BitVM. В то же время распределенные системы, такие как Nostr, также будут включать в себя функции стоимости. Этот этап в основном предназначен для завершения различных проверок функциональной осуществимости и производительности.

(3) Масштабное строительство на основе экологии Биткойн.

Последний этап — этап зрелости.На этом этапе Web3.0 начинает создаваться в больших количествах и постепенно созревает. Распространенные приложения, описанные в 3.1, начали вступать в эпоху Web3.0.

Возможно, наступление этого этапа займет больше времени. Возможно, наступит переломный момент, который сможет способствовать появлению большого количества приложений Web2.0, и время может быть не таким долгим.

Несмотря ни на что, когда наступит настоящая эра Web3.0, она определенно будет совсем другой: функции и производственная ценность будут больше и ярче, чем нынешний ПК-Интернет + мобильный Интернет в целом. Возможно, это похоже на появление Соры в сфере ИИ, что очень удивительно и шокирует, но процесс не такой внезапный.

Справочное описание

(1) Обратитесь к статьям и содержанию курса г-на Дашана о краткосрочных, среднесрочных и долгосрочных аспектах экологии Биткойна.

(2) «Невозможное становится возможным: создание полноцепной разработки игр в сети Lightning» (вдохновение и подтверждение этой статьи еще больше)

(3) Три угла наблюдения в основном относятся к «иллюстрированной EVM Ethereum», Takenobu T., 2018.3

(4) Содержимое, связанное с классификацией приложений, в основном относится к книге «Web3.0: построение цифрового будущего метавселенной», написанной автором в 2022 году.

(5) Обратитесь к знаниям теории графов в университетской цифровой логике.

(6) Ссылки сделаны на некоторые статьи о распределенных системах.