Интерпретация SCP: парадигма инфраструктуры, не требующей доверия, за пределами формулы свертки

Автор: Wuyue, Geek Web3

Введение:В этой статье в перспективе будет представлена парадигма проектирования инфраструктуры Web3, которая выглядит немного необычно - Storage Consensus Paradigm SCP (Storage-based Consensus Paradigm), хотя эта модель проектирования продукта теоретически сильно отличается от основных модульных блокчейн-решений, таких как Ethereum Rollup, но ** в простоте посадки и сложности подключения к платформе Web2 осуществимость очень высока Поскольку он не собирался с самого начала ограничивать себя узким путем внедрения, таким как Rollup, он хотел использовать более широкий и открытый фреймворк для слияния платформы Web2 с инфраструктурой Web3, что, можно сказать, является интеллектуальным и творческим подходом. Введение: В этой статье в перспективе будет представлена несколько необычная парадигма проектирования инфраструктуры Web3 - парадигма консенсуса хранилищ (SCP) Хотя эта модель дизайна продукта теоретически сильно отличается от основных модульных блокчейн-решений, таких как Ethereum Rollup, она очень осуществима с точки зрения простоты реализации и сложности подключения к платформам Web2, потому что он не намерен с самого начала ограничивать себя узким путем реализации, таким как Rollup, и хочет интегрировать платформу Web2 и средства Web3 с более широкой и открытой структурой, что, можно сказать, является интеллектуальным и творческим подходом.

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

• Он имеет скорость, сравнимую с традиционными приложениями или биржами Web2, намного превышающую любую публичную цепочку, L2, роллап, сайдчейн и т. д.
• Плата за газ отсутствует, а стоимость использования практически равна нулю.
• Высокая безопасность средств, намного превышающая централизованные средства, такие как биржи, уступающая Rollup, но больше или равная Sidechain.
• Тот же пользовательский опыт, что и в Web2, без каких-либо знаний об открытых и закрытых ключах, кошельках, инфраструктуре и т. д. блокчейна.

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

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

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

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

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

Уровень доступности данных: Осуществляется широко признанной и проверенной публичной сетью или хранилищами в качестве уровня доступности данных, такими как Ethereum, Arweave, Celestia и т. д. Execution Layer (Уровень выполнения): Сервер, который получает и выполняет пользовательские транзакции и отправляет данные транзакций, подписанные пользователями, на уровень DA пакетами, аналогично секвенсору Rollup. Тем не менее, уровень исполнения не обязательно должен иметь структуру связанного списка в стиле блокчейна, это может быть полностью база данных Web2 + вычислительная система, но вся вычислительная система должна быть с открытым исходным кодом и прозрачной. Уровень консенсуса: состоит из группы узлов, которые извлекают данные, отправленные на уровень DA уровнем выполнения, и используют тот же алгоритм, что и уровень выполнения, для вычисления данных, чтобы подтвердить, что выходные данные уровня выполнения верны, и могут использоваться в качестве избыточности уровня выполнения для предотвращения аварий. Пользователи также могут считывать данные, возвращаемые каждым узлом на уровне консенсуса, чтобы убедиться в отсутствии мошенничества на уровне выполнения. Расчетный уровень: состоит из группы узлов и других контрактов или адресов в цепочке, которая используется для обработки поведения пользователей, вносящих депозит в SCP или выходящих из SCP, чем-то похожий на режим работы мостов межцепочечного взаимодействия. Узел расчетного уровня управляет функцией вывода средств с депозитного адреса через контракт с мультиподписью или адрес на основе TSS. При пополнении пользователь вносит активы на указанный Адрес цепочки, отправляет запрос при выводе, а Узел Расчетного уровня считывает данные и высвобождает активы через мультиподпись или TSS. Степень защищенности расчетного уровня зависит от принятого механизма кроссчейн-взаимодействия.

Система SCP

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

• В слое DA проекта используется постоянное хранилище Arweave, которое представляет собой большой круг на схеме. Координатор, т.е. уровень исполнения. **Пользователь отправляет транзакцию координатору, который выполняет расчет и представляет результат, а затем пакетно отправляет исходные входные данные пользователя на уровень DA. Detector, который извлекает необработанные данные о транзакциях, отправленные координатором из Arweave, и проверяет данные и результаты с помощью алгоритма, согласованного с координатором. Клиент детектора также имеет открытый исходный код и может быть запущен кем угодно.
• **Watchmen — группа детекторов, отвечающих за мультиподпись системы вывода средств. **Запросы на вывод средств проверяются и публикуются на основе данных о транзакциях. Кроме того, сторож также несет ответственность за подписание предложения.

Мы можем видеть всю систему, и консенсус, которого они достигают, является оффчейном, что является ядром парадигмы консенсуса хранилища - он отказывается от системы NodeConsensus в стиле блокчейна и позволяет исполнительному уровню избавиться от тяжелого процесса общения и подтверждения консенсуса, и ему нужно только выполнять работу сервера, чтобы достичь почти неограниченного TPS и экономичности. Это очень похоже на Rollup, но SCP пошел по пути, отличному от Rollup, пытаясь перейти от варианта использования для конкретного масштаба к новой модели перехода от Web2 к Web3. **

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

В этой архитектуре централизованный сервер или база данных не представляют принципиальной проблемы. Это еще один пункт парадигмы SCP, который связывает и разделяет два понятия “централизация” и “единое целое” - ** в системе, не требующей доверия, могут быть централизованные компоненты, ** даже основной компонент, но это не влияет на общее отсутствие доверия.

Мы можем выкрикнуть такой лозунг - “Следующее поколение инфраструктуры, не требующей доверия, не должно полагаться на протоколы консенсуса, а должно быть системами с открытым исходным кодом и сетями узлов P2P”.

Первоначальное намерение людей изобрести и использовать блокчейн заключается в том, чтобы не доверять, реестр является последовательным, неподдельным, отслеживаемым и другими клишированными основами, которые четко изложены в BitcoinWhite Paper. Но после Ethereum, будь то схема масштабирования старой публичной цепочки, или Rollup, или модульный блокчейн, у всех сформировалось мышление: то, что мы делаем, должно быть Блокчейном (состоящим из Протокола Консенсуса Ноды), или Роллапом, который кажется цепочечным решением (только структура данных Блокчейн есть, но у Ноды нет прямого обмена сообщениями Консенсуса).

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

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

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

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

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

*Exchange. На основе SCP может быть построена открытая, прозрачная биржа с высоким TPS, которая может иметь характеристики скорости CEX и нулевой стоимости, сохраняя при этом децентрализацию DEX. Здесь различие между CEX и DEX становится размытым.

• Платежная сеть. Аналогично Alipay, PayPal и т.д.
• Поддержка виртуальных машин/загрузчиков блокчейна/контрактов. Любой разработчик может развернуть на нем любое приложение, поделиться всеми пользовательскими данными с другими программами и работать по инструкции пользователя.

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

В архитектуре SCP отсутствует концепция абстракции аккаунта — вы можете свободно перенимать стандартные учетные записи Web2 и учетные записи Blockchain. С этой точки зрения, многие зрелые сценарии использования Web2 не нуждаются в переосмыслении и создании для работы непосредственно на SCP. В этом может заключаться преимущество SCP-объектов перед свертками. **

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

Система учетных записей, упомянутая выше, и чувствительные читатели должны были заметить, что, хотя SCP может воспользоваться системой учетных записей Web2, использовать ее в том виде, в котором она есть, кажется проблематичным.

Поскольку вся система полностью прозрачна, прямое использование модели взаимодействия «пользователь-сервер» приведет к серьезным проблемам, что приведет к отсутствию безопасности. Давайте рассмотрим, как работает традиционная модель сервер-пользователь:**

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

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

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

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

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

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

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

Разница между двумя модами обусловлена симметрией и асимметрией. В архитектуре «сервер-пользователь» обе стороны хранят одни и те же секреты. В архитектуре Blockchain-User секреты хранятся только у пользователя.

Несмотря на то, что уровень исполнения SCP не может быть блокчейном, все данные должны быть синхронизированы с общедоступным уровнем DA, поэтому метод аутентификации входа и работы, используемый SCP, должен быть асимметричным. Однако, поскольку мы не хотим иметь громоздкие действия и плохой опыт, которые влияют на массовое внедрение, такие как предоставление пользователям возможности хранить закрытые ключи и использовать кошельки, приложения, построенные на SCP, также имеют острую потребность в использовании традиционных идентификационных паролей или входов в систему с трехсторонней аутентификацией OAuth, так как же объединить их?

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

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

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

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

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

Конфиденциальность

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

Заряд

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

Уровень выполнения может настраивать различные стратегии зарядки, такие как полностью бесплатная или частичная зарядка, а также может монетизировать другое поведение, такое как MEV (которое очень зрело в секвенсоре), маркетинговая деятельность и т. д.

Сопротивление цензуре

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

** В настоящее время не существует четкого решения проблемы сопротивления цензуре, которая является проблемой парадигмы SCP. **

Уровень консенсуса

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

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

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

Уровень выполнения предоставляет пользователю результат предварительного подтверждения и мягкого завершения, поскольку он еще не был отправлен на уровень DA;

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

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

Слой поселений

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

Децентрализация моста-свидетеля, насколько это возможно, является предметом многих исследований межсетевого взаимодействия. Из-за ограниченного объема я не буду подробно останавливаться на этом здесь. Хорошо спроектированная SCP-платформа также должна иметь авторитетных партнеров по мультиподписи Decentralization Bridge на практике.

Кто-то может спросить, почему SCP не использует цепочки со смарт-контрактами в качестве уровня DA? Это может сделать расчетный уровень, который дает контракты и полностью не доверяет.

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

Но на практике это не всегда оптимально:**

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

2. Докажите, что система очень сложна в разработке, т.к. SCP может не только имитировать EVM, но и реализовывать любую логику. ** Глядя на тот факт, что такие команды, как Optimism, до сих пор не находятся в сети для доказательств мошенничества, и сложность разработки zkEVM, мы можем представить, что реализовать доказательства различных систем на Ethereum крайне сложно.

Таким образом, решение Rollup лучше подходит только в определенных ситуациях, и если вы планируете реализовать более широкий и открытый подход, который уходит от системы EVM и переходит к большему количеству функций Web2, идея Ethereum Rollup не подходит.

**SCP — это не публичная схема масштабирования цепочки, а более крупная архитектура вычислительной платформы Web3, поэтому очевидно, что нет необходимости следовать идее Ethereum Layer 2. **

Диаграмма, сравнивающая SCP с другими парадигмами