Введение:

Эта статья представляет собой прогностическое введение в несколько нестандартную парадигму проектирования инфраструктуры Web3: Парадигму консенсуса на основе хранилищ (SCP). Эта модель проектирования значительно отличается от основных модульных решений блокчейна, таких как Ethereum Rollups, в теории. Однако она демонстрирует высокую осуществимость в плане простоты внедрения и интеграции с платформами Web2. SCP не намерен ограничивать себя узкой тропой реализации, как Rollups. Вместо этого он стремится принять более широкую и открытую структуру для слияния платформ Web2 с инфраструктурой Web3. Этот подход можно рассматривать как чрезвычайно фантазийный и инновационный.

Давайте представим общественное решение масштабирования блокчейна с следующими характеристиками:

• У него есть скорость, сравнимая с традиционными веб-приложениями или биржами Web2, значительно превосходящими любую публичную блокчейн, Layer 2 (L2), роллапы, сайдчейны и т.д.

• Нет комиссий за газ, и стоимость использования почти нулевая.

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

• Пользовательский опыт, идентичный Web2, не требующий никаких знаний о открытых и закрытых ключах блокчейна, кошельках, инфраструктуре и т. д.

Такое решение действительно очень захватывающее: с одной стороны, оно фактически достигло пика в масштабировании; с другой стороны, оно заложило прочный фундамент для массового принятия Web3, фактически сокращая разрыв между пользовательскими интерфейсами Web2 и Web3. Однако, кажется, у нас есть лишь немного таких всеобъемлющих решений, так как основные обсуждения и практики действительно слишком немногочисленны.

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

Основные компоненты и принципы работы SCP

В общем, SC, как и «модульный блокчейн», упомянутый сообществами Ethereum и Celestia, имеет различные модули, такие как слой доступности данных, слой исполнения, слой консенсуса и слой расчетов.

• Уровень доступности данных: Обрабатываемый широко признанным и хорошо протестированным публичным блокчейном или службами хранения, выступающими в качестве уровня доступности данных, такими как Ethereum, Arweave, Celestia и т. д.

• Уровень выполнения: Сервер, используемый для приема транзакций пользователей и их выполнения, а также для пакетной отправки подписанных данных транзакций на уровень DA, аналогично последователям в Rollups. Однако уровень выполнения не обязательно должен иметь структуру цепочки в стиле блокчейна; он может быть полностью базой данных Web2 + системой вычислений, но вся система вычислений должна быть открытым исходным кодом с прозрачностью.

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

• Уровень расчетов: Состоит из группы узлов и контрактов или адресов на других цепочках, ответственных за обработку депозитов пользователей в SCP или вывод из SCP, в некоторой степени аналогичный работе межцепочечных мостов. Узлы уровня расчетов контролируют функцию вывода депозитного адреса через мультисиг контракты или адреса на основе TSS. Для депозитов пользователи переводят активы на указанный адрес на своей цепочке; для вывода они отправляют запрос, и после того, как узлы уровня расчетов считают данные, они освобождают активы через мультисиг или TSS. Уровень безопасности уровня расчетов зависит от используемого механизма межцепочечного взаимодействия.

Фреймворк практики SCP

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

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

Мы видим, что консенсус, достигнутый всей системой, полностью находится вне блокчейна, что является ядром парадигмы консенсуса в отношении хранилища. Он отказывается от системы консенсуса узлов, типичной для блокчейнов, освобождая уровень исполнения от обременительного процесса коммуникации и подтверждения консенсуса. Это позволяет ему эффективно функционировать как единый сервер, тем самым достигая практически неограниченного TPS и экономичности. Этот аспект очень похож на накопительные пакеты, но SCP (парадигма консенсуса хранилища) идет по другому пути, чем накопительные пакеты. SCP пытается перейти от варианта использования, специфичного для масштабирования, к новому переходному режиму от Web2 к Web3. Вышеупомянутый Координатор является сервером, но это не значит, что Координатор может действовать произвольно. Как и в случае с секвенсором в Rollups, после пакетной отправки исходных данных от пользователей на Arweave, любой желающий может запустить программу Detector, чтобы проверить их и сравнить с состоянием, возвращаемым Координатором. В некотором смысле это сродни подходу приложений типа надписей. В этой архитектуре централизованный сервер или база данных не представляют принципиальной проблемы. Это еще один пункт парадигмы SCP: она разделяет понятия «централизация» и «единое целое» — в системе, не требующей доверия, могут быть централизованные компоненты, даже основной компонент, не влияющие на общую ненадежность системы.

Мы можем выкрикнуть следующий лозунг: «Следующее поколение инфраструктуры, не требующей доверия, не обязательно должно полагаться на протоколы консенсуса, но это должна быть система с открытым исходным кодом и сетью одноранговых узлов (P2P)». Первоначальная цель изобретения и использования блокчейна заключалась в том, чтобы достичь децентрализации, согласованности реестра, неизменности и отслеживаемости, как прямо указано в белой книге Биткойна. Тем не менее, после Ethereum, будь то решения для расширения старой публичной цепочки, роллапы или модульные блокчейны, существовало фиксированное мышление: то, что мы создаем, должно быть либо блокчейном (состоящим из протоколов консенсуса узлов), либо чем-то вроде Rollup (который, по-видимому, представляет собой цепочку со структурами данных блокчейна, но без прямого обмена сообщениями консенсуса между узлами). Теперь, в рамках фреймворка, основанного на SCP (Stellar Consensus Protocol), очевидно, что даже не будучи блокчейном, можно достичь децентрализации, согласованности реестра, неизменности и отслеживаемости, при условии более явных деталей реализации.

Уровень исполнения

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

Бесконечные возможности в среде выполнения

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

1. Обмены. Используя SCP, можно создать публичный, прозрачный обмен с высокой скоростью транзакций в секунду (TPS), объединяя быстрые и бесплатные функции Централизованной биржи (CEX) и децентрализации Децентрализованной биржи (DEX). Здесь различие между CEX и DEX становится размытым.

2. Платежные сети. Похоже на Alipay, PayPal и т. д.

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

Дизайн-паттерн SCP, который поддерживает любую среду выполнения, имеет свои уникальные преимущества: нет необходимости полагаться на компоненты с историческим багажом, особенно на такие концепции, как «абстракция учетной записи», уникальные для сообщества Ethereum. Для SCP концепция абстракции учетной записи сама по себе излишня. В архитектуре SCP нет концепции абстракции учетной записи — можно свободно использовать стандартные учетные записи Web2 и учетные записи блокчейна и т. д. С этой точки зрения многие зрелые случаи использования Web2 не нужно пересматривать и перестраивать, чтобы применить их напрямую к SCP. В этом аспекте SCP может иметь преимущество перед Rollups.

Прозрачность и Асимметрия

Система учетных записей была упомянута выше, и внимательные читатели могли заметить, что в то время как SCP (Протокол согласия Stellar) может использовать систему учетных записей Web2, использование ее в текущем виде представляется проблематичным. Это связано с тем, что вся система полностью прозрачна! Прямое использование модели взаимодействия пользователь-сервер из Web2 приводит к серьезным проблемам безопасности, делая систему абсолютно ненадежной. Давайте рассмотрим, как работает традиционная модель сервер-пользователь:

1. Регистрация учетной записи: Пользователи вводят имя пользователя и пароль на странице регистрации приложения. Чтобы защитить пароль пользователя, сервер обрабатывает его с помощью хэш-функции при получении. Чтобы увеличить сложность хэша и защититься от атак с использованием радужных таблиц, к каждому паролю пользователя обычно добавляется случайно сгенерированная строка (известная как "соль"). Имя пользователя, соль и хэш хранятся в открытом виде в базе данных поставщика услуг и не являются общедоступными. Тем не менее, соль и безопасная обработка необходимы для предотвращения внутренних угроз и атак.

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

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

Давайте рассмотрим типичную систему взаимодействия пользователя с блокчейном Web3:

1. Регистрация учетной записи: На самом деле нет процесса регистрации учетной записи, а также системы имени пользователя и пароля. Учетные записи (адреса) не требуется регистрировать; они существуют по своей природе, и тот, кто контролирует закрытый ключ, контролирует учетную запись. Закрытый ключ генерируется случайным образом локально кошельком и не включает в себя онлайн-процесс.

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

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

Разница между этими двумя режимами вызвана симметричными и асимметричными факторами. В архитектуре сервер-пользователь обе стороны имеют одинаковый секрет. В архитектуре блокчейна-пользователя только пользователь обладает секретом. Хотя уровень выполнения SCP (платформа смарт-контрактов) может не быть блокчейном, все данные должны синхронизироваться с общедоступным уровнем DA (доступность данных). Поэтому методы проверки входа и операций SCP должны быть асимметричными. Однако, чтобы избежать громоздких действий, таких как управление частными ключами и использование кошельков, что может затруднить широкое принятие из-за плохого пользовательского опыта, существует сильный спрос на традиционные методы входа с помощью ID-пароля или аутентификации через сторонние службы типа OAuth в приложениях, построенных на SCP. Итак, как мы можем объединить эти два подхода? В связи с асимметричным характером криптографии и доказательствами в нулевом знании я предвижу два возможных решения:

• Если требуется система идентификации по паролю, модуль сохранения пароля может быть исключен из SCP, сделав его невидимым для других. Внутренне уровень выполнения SCP по-прежнему использует открытые и закрытые учетные записи блокчейна и операционную логику, без регистрации или входа в систему. Фактический идентификатор пользователя должен соответствовать закрытому ключу. Этот закрытый ключ, конечно, не должен храниться на стороне проекта. Возможным решением является использование 2-3 MPC (многопартийных вычислений) для решения проблемы централизованного хранения, не обременяя пользователя использованием закрытого ключа.
• При использовании входа через OAuth JWT (JSON Web Token) можно использовать в качестве средства аутентификации личности. Этот метод немного более централизован, чем предыдущий, поскольку в основном он зависит от услуг сторонних служб входа, предоставляемых гигантами Web2 для верификации личности.
• При первом использовании входа третьей стороны поля JWT, представляющие идентификаторы пользователя и поставщика услуг, регистрируются в системе. В последующих операциях пользователя команда операции рассматривается как общедоступный ввод, в то время как JWT в целом является секретным свидетелем, используя ZKP (Доказательство нулевого знания) для проверки каждой транзакции пользователя.
• У каждого JWT есть ограничение срока действия, и пользователи будут запрашивать новый JWT в следующий раз, когда они войдут в систему, поэтому нет необходимости в постоянном хранении. Кроме того, эта система полагается на JWK (JSON Web Key), который можно понимать как публичный ключ, предоставленный гигантами для проверки JWK. Как JWK децентрализованно вводится в систему, и методы для будущего вращения закрытого ключа также стоит исследовать.

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

Проблемы конфиденциальности

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

Сборы

Как взимаются комиссии на уровне исполнения, является еще одним интересным аспектом. Передача данных на уровень доступности данных (DA) также несет издержки, включая обслуживание собственных серверов. Основная цель взимания комиссий за газ в традиционных блокчейнах - предотвращение спама сети многочисленными избыточными транзакциями, при этом упорядочение транзакций на основе комиссий за газ является вторичным. В Web2 подобных проблем не существует, существуют только базовые концепции, такие как затопление и DDoS-атаки. Уровень исполнения может настраивать различные стратегии взимания платы, такие как полное отсутствие оплаты или частичная оплата, или получение прибыли от других действий, таких как Максимально Извлекаемая Стоимость (MEV), которая уже очень зрела в последователях и рыночных операциях.

Устойчивость к цензуре

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

Слой консенсуса

Этот уровень состоит из слабо связанных узлов, которые активно не образуют сеть, поэтому он не является строго консенсусным уровнем, а просто подтверждает текущее состояние уровня выполнения внешнему миру (например, пользователям). Например, если вы сомневаетесь в рабочем состоянии этих узлов, вы можете скачать их клиент детектора, который запускает тот же программный код, что и координатор. Однако, как и в случае со свертками, поскольку данные передаются пакетами, состояние, возвращаемое уровнем выполнения пользователям, всегда более актуально, чем на уровне DA. Это связано с проблемой предварительного подтверждения: уровень выполнения предоставляет пользователям результаты предварительного подтверждения, мягкой окончательности, поскольку они еще не были отправлены на уровень DA; в то время как уровень консенсуса обеспечивает жесткую завершенность. Пользователи могут не особенно беспокоиться по этому поводу, но для таких приложений, как кроссчейн-мосты, необходимо придерживаться жесткой завершенности. Например, система ввода и вывода средств бирж не доверяет данным, транслируемым вне блокчейна секвенсорами Rollup; они ждут, пока эти данные будут на Ethereum, прежде чем принять. Помимо подтверждения результатов, уровень консенсуса также играет решающую роль в качестве аварийной избыточности для уровня выполнения. Если уровень исполнения навсегда перестает работать или действует злонамеренно, теоретически любой уровень консенсуса может взять на себя работу уровня исполнения и принимать запросы пользователей. Если такая серьезная ситуация возникает, сообществу следует выбирать стабильные и надежные узлы в качестве серверов уровня исполнения.

Слой расчетов

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

Сделать мост свидетеля как можно более децентрализованным - это тема исследований для многих кросс-цепных мостов. Из-за ограничений пространства здесь это не будет разъясняться. Хорошо спроектированная платформа SCP в практике также должна иметь уважаемых децентрализованных партнеров мультиподписи моста. Некоторые могут спросить, почему SCP не использует цепь со смарт-контрактами в качестве слоя DA? Это позволило бы создать слои доверительного расчета на основе контрактов. В долгосрочной перспективе, преодолев некоторые технические трудности, если слой DA размещен на Ethereum или других слоях DA с разрешением контрактов, и могут быть построены соответствующие контракты проверки, SCP также может достичь той же безопасности расчета, что и Rollup, без необходимости мультиподписей.

На практике это может быть не лучший выбор:

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

2. Разработка систем доказательств крайне сложна, потому что в SCP можно симулировать не только EVM (Ethereum Virtual Machine), но и реализовывать любую логику. Учитывая текущее состояние проектов, таких как Optimism, где их доказательства мошенничества еще не запущены, и сложность разработки zkEVM (нулевой знаний Ethereum Virtual Machine), можно представить огромные трудности при реализации различных систем доказательств на Ethereum.

Поэтому решение Rollup более практично в конкретных обстоятельствах. Если вы планируете реализовать более широкую, более открытую систему, отходя от EVM-фреймворка для интеграции большего количества функций Web2, то подход Ethereum Rollup не подходит. SCP - это не просто план расширения для определенной публичной блокчейн, а более крупная архитектура платформы вычислений Web3. Следовательно, ему clearly не нужно придерживаться подхода Ethereum Layer2.

Иллюстрация сравнивает SC с другими парадигмами

Отказ от ответственности:

1. Эта статья перепечатана с [Geek Web3]. Все авторские права принадлежат оригинальному автору [Mist, Geek Web3]. Если есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
2. Ответственность за отказ: мнения и взгляды, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.