Как отказаться от мышления Rollup и интегрировать платформу Web2 с Web3 с помощью более широкой и открытой структуры?
Написано Wuyue, Geek Web3
**Введение: **В этой статье будет представлена парадигма проектирования инфраструктуры Web3, которая кажется немного уникальной — Парадигма консенсуса на основе хранилища (SCP). Хотя эта модель проектирования продукта теоретически сильно отличается от основной модульной модели. блокчейн-решения, такие как Ethereum Rollup, но это очень осуществимо с точки зрения простоты реализации и простоты соединения с платформой Web2, поскольку с самого начала я не намеревался ограничивать себя узким путем реализации, таким как Rollup. хотел использовать более широкую и открытую структуру для интеграции платформы Web2 и средств Web3, которую можно назвать мозгом. Широко открытый, творческий подход.
Текст: Представим себе решение для расширения публичной сети со следующими характеристиками:
- Он имеет скорость, сравнимую с традиционными приложениями или биржами Web2, намного превосходя любую публичную цепь, L2, объединение, сайдчейн и т. д.
- Плата за газ отсутствует, а стоимость использования практически равна 0.
- Безопасность средств высока, намного превосходит безопасность централизованных средств, таких как биржи, уступает Rollup, но выше или равна сайдчейнам.
- Тот же пользовательский опыт, что и в Web2, без каких-либо знаний об открытых и закрытых ключах, кошельках, инфраструктуре и т. д. блокчейна.
Такое решение действительно очень интересное: с одной стороны, оно фактически позволило максимально расширить возможности; с другой стороны, оно также заложило очень прочную основу для массового внедрения Web3, практически устранив разрыв между Web2 и Web3. опыт использования.
Однако мы, похоже, не можем себе представить, сколько решений может быть настолько полным, потому что на самом деле слишком мало основных дискуссий и практики.
В качестве введения выше мы использовали расширение, очень знакомую тему. На самом деле, SCP не ограничивается расширением. Его дизайн вдохновлен планами расширения и обсуждениями сообщества публичных сетей, таких как Биткойн и Эфириум. Его концепция и практическое применение заключаются в создании нового поколения не требующей доверия инфраструктуры, даже вычислительной платформы без блокчейна. **
Основные компоненты и принципы работы SCP
Вообще говоря, **SCP также похож на то, что сообщества Ethereum и Celestia называют «модульным блокчейном».**Он имеет такие модульные подразделения, как уровень доступности данных, уровень исполнения, уровень консенсуса и уровень расчетов.
- Уровень доступности данных: в качестве уровня доступности данных предполагается широко признанная и проверенная публичная сеть или средства хранения, такие как Ethereum, Arweave, Celestia и т. д.
- Уровень выполнения: Сервер, используемый для приема пользовательских транзакций и их выполнения, а также для пакетной передачи данных транзакций, подписанных пользователем, на уровень DA, аналогично секвенсору Rollup. Но уровень исполнения не обязательно должен иметь структуру связанного списка в стиле блокчейна.Это может быть полностью база данных Web2 + вычислительная система, но вся вычислительная система должна быть с открытым исходным кодом и прозрачной.
- Консенсусный уровень: состоит из группы узлов. Они передают данные, отправленные исполнительным уровнем, на уровень DA и используют тот же алгоритм, что и исполнительный уровень, для работы с этими данными, чтобы подтвердить, является ли результат выходные данные уровня выполнения являются правильными и могут использоваться в качестве резерва предотвращения аварий для уровня выполнения. Пользователи также могут читать данные, возвращаемые каждым узлом на уровне консенсуса, чтобы гарантировать отсутствие мошенничества на уровне исполнения.
- Уровень расчетов: Состоит из группы узлов и контрактов или адресов в других цепочках. Он используется для управления поведением пользователей, пополняющих счет SCP или выводящих деньги из SCP. Он чем-то похож на режим работы. перекрестного цепного моста. Узел расчетного уровня управляет функцией вывода адреса пополнения через контракты с несколькими знаками или адреса на основе TSS. При пополнении счета пользователь вносит активы на указанный адрес в цепочке, а при выводе средств отправляется запрос.После того, как узел расчетного уровня считывает данные, он освобождает активы посредством мультиподписи или TSS. Уровень безопасности расчетного уровня зависит от принятого кросс-чейнового механизма.
Рамки практики SCP
Мы можем понять парадигму SCP через следующую структуру. Продукт, соответствующий структуре SCP, может иметь основные функции, такие как пополнение счета, перевод, снятие средств, обмен и т. д., и может быть дополнительно расширен на этой основе. На рисунке ниже представлена принципиальная схема такого продукта:
- Уровень DA проекта использует постоянное хранилище Arweave, большой кружок на рисунке.
- **Координатор, исполнительный уровень. **Пользователь отправляет транзакцию координатору, координатор выполняет операцию и отображает результаты операции, а затем пакетно отправляет исходные входные данные пользователя на уровень DA.
- Детектор извлекает исходные данные о транзакциях, отправленные координатором из Arweave, и использует согласованный с координатором алгоритм для проверки данных и результатов. Клиент детектора также имеет открытый исходный код и может быть запущен кем угодно.
- **Хранители — группа тестировщиков, отвечающих за мультиподпись системы вывода. **Запросы на снятие средств будут проверены и выпущены на основе данных о транзакции. Кроме того, сторож также несет ответственность за подписание предложения.
Мы можем видеть всю систему, и весь консенсус, которого они достигли, находится вне цепочки. Это ядро парадигмы консенсуса хранилища — она отказывается от системы консенсуса узлов в стиле блокчейна и освобождает уровень исполнения от тяжелого консенсуса. Процесс подтверждения требует работы только одного сервера, что обеспечивает практически неограниченное количество TPS и экономию. Это очень похоже на Rollup, но SCP пошел по другому пути, чем Rollup, превратив его из специального варианта использования для расширения емкости в новую модель перехода от Web2 к Web3. **
Упомянутый выше координатор является сервером, но это не значит, что координатор может делать все, что захочет. Как и в случае с сортировщиком Rollup, после того как исходные данные, отправленные пользователями, были отправлены в пакетах на Arweave, любой может запустить программу-детектор, чтобы проверить их и сравнить со статусом, возвращенным координатором. **В какой-то степени это то же самое, что и идея надписных приложений. **
В этой архитектуре централизованный сервер и база данных не представляют собой фундаментальной проблемы. Это еще один момент парадигмы SCP, которая связывает и разделяет две концепции «централизации» и «единого объекта» - **В системе, не требующей доверия, могут быть централизованные компоненты, **это могут быть даже основные компоненты, но это не влияет на общую недоверчивость.
Мы можем выкрикнуть такой лозунг — «Следующее поколение недоверенной инфраструктуры не обязательно должно опираться на консенсусные протоколы, а должно представлять собой системы с открытым исходным кодом и сети P2P-узлов».
Первоначальное намерение людей, изобретающих и использующих блокчейн, состоит в том, чтобы не доверять последовательным реестрам, неподдельным, отслеживаемым и другим банальным основам, которые четко изложены в официальном документе Биткойна. **Но после Ethereum, **будь то план расширения старой публичной цепочки, или Rollup, или модульный блокчейн, у всех сформировалось мышление: то, что мы делаем, должно быть блокчейном (Он состоит из протокола консенсуса узлов) или такое решение, как Rollup, которое выглядит как цепочка (оно просто имеет структуру данных блокчейна, но узлы не обмениваются напрямую консенсусными сообщениями).
Но теперь, в рамках структуры, основанной на SCP, даже если это не блокчейн, может быть достигнут ряд требований, таких как надежность, согласованность реестра, отсутствие подделки, отслеживаемость и т. д. Конечно, предполагается, что существуют более четкие детали реализации.
Уровень выполнения
Уровень исполнения имеет решающее значение для всей системы: он берет на себя вычислительный процесс всей системы и определяет, какие приложения можно запускать в системе.
Бесконечные возможные среды выполнения
Теоретически среда исполнения на уровне выполнения может иметь любую форму, и возможности безграничны, в зависимости от того, как позиционирует свой проект участник проекта:
*Обмен. На основе SCP можно построить открытую, прозрачную биржу с высоким TPS. Эта биржа может не только обладать характеристиками скорости CEX и нулевой стоимости, но также поддерживать децентрализацию DEX. Здесь различие между CEX и DEX становится размытым.
- Платежная сеть. Аналогично Alipay, PayPal и т. д.
- Поддержка виртуальной машины/блокчейна для загрузки программ/контрактов. Любой разработчик может развернуть на нем любое приложение, поделиться всеми пользовательскими данными с другими программами и действовать по инструкциям пользователя.
**SCP, модель проектирования, поддерживающая произвольные среды выполнения, имеет свои уникальные преимущества: **Вам больше не нужно полагаться на определенные компоненты с историческим багажом, особенно на концепцию «абстракции учетной записи», уникальную для сообщества Ethereum, что очень важно. к SCP. Говорят, что это не обязательно по своей природе.
В архитектуре SCP не существует концепции абстракции учетных записей — вы можете использовать стандартные учетные записи Web2 и учетные записи блокчейна по своему желанию. С этой точки зрения многие зрелые варианты использования Web2 могут быть напрямую использованы в SCP без переосмысления и доработки. Это может быть преимуществом SCP по сравнению с Rollup. **
Прозрачность и асимметрия
Система учетных записей была упомянута выше. Чуткие читатели должны были заметить, что, хотя SCP может использовать систему учетных записей Web2, похоже, существуют проблемы с ее использованием в неизмененном виде.
Потому что вся эта система абсолютно прозрачна! Непосредственное использование модели взаимодействия пользователя с сервером вызовет серьезные проблемы, в результате чего не будет обеспечена безопасность всей системы. Давайте сначала рассмотрим, как работает традиционная модель сервер-пользователь:
1. Регистрация аккаунта: Пользователь вводит логин и пароль на странице регистрации приложения. Чтобы защитить пароль пользователя, сервер обрабатывает пароль с помощью хэш-функции после его получения. Чтобы увеличить сложность хеша и защитить от атак радужных таблиц, пароль каждого пользователя часто объединяется со случайно сгенерированной строкой (называемой «солью») и хэшируется вместе. **Имя пользователя, соль и хэш хранятся в открытом виде в базе данных поставщика услуг и не разглашаются публике. **Но даже в этом случае соль и меры безопасности по-прежнему необходимы для предотвращения инсайдерских атак и атак.
2. Вход пользователя: Пользователи вводят свое имя пользователя и пароль в форме входа. Система сравнивает обработанное хеш-значение пароля с хеш-значением, хранящимся в базе данных. Если два хэша совпадают, значит, пользователь ввел правильный пароль, и процесс входа продолжается.
3. Аутентификация операции: После прохождения аутентификации для входа в систему система создаст сеанс для пользователя. Обычно информация о сеансе хранится на сервере, и сервер отправляет идентификатор (например, токен) в браузер или приложение пользователя. Пользователям больше не нужно повторно вводить свое имя пользователя и пароль при последующих операциях: браузер или приложение сохранят идентификатор и будут включать его в каждый запрос, чтобы указать, что у них есть разрешение от соответствующего сервера.
Давайте рассмотрим типичную систему взаимодействия блокчейна и пользователя Web3:
1. Регистрация учетной записи: На самом деле не существует процесса регистрации учетной записи и системы имени пользователя и пароля. Аккаунты (адреса) регистрировать не нужно, они существуют естественным образом, и тот, у кого есть приватный ключ, контролирует аккаунт. Закрытый ключ генерируется кошельком случайным образом локально и не требует сетевого процесса.
2. Вход пользователя: Использование блокчейна не требует входа в систему. Большинство dApps не имеют процесса входа в систему, но подключаются к кошельку. Некоторые децентрализованные приложения потребуют от пользователей выполнить проверку подписи после подключения к кошельку, чтобы убедиться, что пользователь действительно владеет закрытым ключом, а не просто передает адрес кошелька во внешний интерфейс.
**3. Аутентификация операции: ** Пользователь напрямую отправляет подписанные данные узлу. После проверки узел будет транслировать транзакцию на всю сеть блокчейна. После достижения консенсуса сети блокчейна операция пользователя будет подтверждена. .
Разница между двумя режимами вызвана симметрией и асимметрией. В серверно-пользовательской архитектуре обе стороны владеют одними и теми же секретами. В архитектуре блокчейн-пользователя только пользователь владеет секретом.
Хотя исполнительный уровень 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, в то время как сайдчейн или публичная цепь представляет собой полную распределенную сеть блокчейнов и ее трудно подвергнуть цензуре.
**В настоящее время не существует четкого решения проблемы сопротивления цензуре, которая является проблемой парадигмы SCP. **
Уровень консенсуса
Этот уровень состоит из отдельных узлов. Эти узлы не образуют сеть активно, поэтому в строгом смысле этого слова он не является уровнем консенсуса, а используется только для подтверждения текущего статуса уровня исполнения для внешнего мира (например, пользователей).
Например, если у вас есть сомнения в исправности этих узлов, вы можете скачать их клиент-детектор, который будет запускать тот же программный код, что и координатор. **
Однако это похоже на объединение: поскольку данные передаются пакетами, статус, возвращаемый пользователю на уровне выполнения, всегда новее, чем на уровне DA. Это включает в себя проблему предварительного подтверждения:
**Уровень выполнения предоставляет пользователям предварительно подтвержденные, программно окончательные результаты, **поскольку они еще не были отправлены на уровень DA;
**Уровень консенсуса обеспечивает пользователям жесткую окончательность. **Пользователей это может не особенно волновать, но для таких приложений, как перекрестные мосты, необходимо соблюдать жесткую окончательность. Например, система депозита и вывода средств биржи не будет доверять данным, передаваемым вне цепочки секвенсором Rollup.Она должна дождаться загрузки данных в Ethereum, прежде чем они будут распознаны.
Помимо использования для подтверждения результатов, уровень консенсуса также играет очень важную роль, поскольку он обеспечивает избыточность предотвращения катастроф для уровня выполнения. **Если исполнительный уровень постоянно объявляет забастовку и совершает серьёзные преступления, теоретически любой уровень консенсуса может взять на себя работу исполнительного уровня и принимать запросы пользователей. Если возникает такая серьезная ситуация, сообщество должно выбрать стабильный и надежный узел в качестве сервера исполнительного уровня.
Уровень поселений
Поскольку SCP не является накопительным пакетом, он не может обеспечить безопасный вывод средств, который не требует ручного вмешательства и полностью основан на криптографии и коде смарт-контракта, таком как уровень расчета вывода средств в Rollup. **Уровень безопасности кросс-чейн моста SCP такой же, как у сайдчейна или стороннего свидетеля кроссчейн моста. **Для освобождения активов необходимо полагаться на авторизованных менеджеров с несколькими подписями. Мы называем это режимом свидетеля. .
Сделать свидетельствующий мост максимально децентрализованным — тема многих исследований перекрестных мостов. Из-за ограниченности места мы не будем здесь вдаваться в подробности. Хорошо спроектированная платформа SCP также должна иметь на практике надежного партнера с мультиподписями в виде децентрализованного моста.
**Кто-то может спросить, почему SCP не использует цепочку со смарт-контрактами в качестве уровня DA? **Это обеспечивает уровень расчетов на основе контрактов, полностью не требующий доверия.
В долгосрочной перспективе, если будут преодолены некоторые технические трудности, если уровень DA будет помещен на уровень DA с контрактами, такими как Ethereum, и могут быть созданы соответствующие контракты для проверки, SCP также может получить ту же безопасность расчетов, что и Rollup. Нет необходимости использовать несколько подписей.
Но на практике это может быть не лучший выбор:
- Ethereum специально не используется для хранения данных, и его цена слишком высока по сравнению с публичной цепочкой чистого хранения данных. **Для парадигмы SCP решающее значение имеют достаточно низкие или фиксированные затраты на хранение. **Только таким образом можно будет поддерживать пропускную способность уровня Web2.
2.** Это доказывает, что систему очень сложно разрабатывать, поскольку SCP может не только моделировать EVM, но и реализовывать любую логику. **И когда мы смотрим на такие команды, как Optimism, чьих доказательств мошенничества до сих пор нет в сети, и на то, насколько сложно разработать zkEVM, мы можем представить, что реализовать доказательство различных систем на Ethereum чрезвычайно сложно.
Таким образом, **Rollup — это решение, которое имеет лучшую практическую осуществимость только при определенных обстоятельствах.**Если вы планируете реализовать более широкое и более открытое решение, избавьтесь от системы EVM и интегрируйте больше функций Web2, тогда Ethernet Идея Fang Rollup не подходит.
**SCP — это не некий план расширения общедоступной сети, а более крупная архитектура вычислительной платформы Web3, поэтому очевидно, что нет необходимости следовать идее Ethereum Layer 2. **
Картинка, сравнивающая SCP и другие парадигмы
