Кратко опишите техническую архитектуру dYdX V4

dYdX V4 будет независимым блокчейном L1 с полностью децентрализованной книгой заказов вне сети и механизмом сопоставления.

**Автор:**dYdX

Скомпилировать: IBCL

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

v4 будет независимым блокчейном L1 с полностью децентрализованной книгой заказов вне сети и механизмом сопоставления. Цепочка dYdX будет основана на Cosmos SDK и протоколе консенсуса CometBFT PoS.

Поскольку мы приближаемся к запуску основной сети v4, мы хотели дать вам представление о том, что строит команда dYdX. В этой статье представлен общий обзор архитектуры v4. Учитывая, что v4 все еще находится в разработке, возможны изменения.

архитектура системы v4

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

Соглашение

Протокол представляет собой блокчейн L1, построенный на CometBFT и использующий CosmosSDK. Программное обеспечение узла написано на Go и скомпилировано в один двоичный файл. Как и все блокчейны CosmosSDK, v4 использует механизм консенсуса Proof-of-Stake.

Протокол будет поддерживаться сетью узлов. Существует два типа узлов:

• Валидаторы: Валидаторы несут ответственность за хранение заказов в книге заказов в памяти (т. е. вне сети и без достижения консенсуса), передачу транзакций другим валидаторам и создание новых блоков для цепочки dYdX посредством процесса консенсуса. В процессе консенсуса валидаторы будут по очереди предлагать новые блоки в циклическом взвешенном режиме (взвешенном по количеству токенов, размещенных на их узлах). Предлагающие несут ответственность за предложение содержания следующего блока. Когда заказ соответствует, предлагающие добавляют его в свой предложенный блок и начинают раунд консенсуса. Блок считается зафиксированным и добавленным в блокчейн, если его одобряют ⅔ или более валидаторов (по весу ставки). Пользователи будут отправлять транзакции непосредственно валидаторам.
• Полный узел: полный узел представляет собой процесс, выполняющий приложение версии 4, которое не участвует в консенсусе. Это узел с весом ставки 0, который не подает предложения и не голосует за них. Однако полные узлы подключаются к сети валидаторов, участвуют в сплетнях транзакций и обрабатывают каждый вновь отправленный блок. Полные узлы имеют полное представление о цепочке dYdX и ее истории и предназначены для поддержки индексаторов. Некоторые стороны могут решить (по соображениям производительности или стоимости) запустить свои собственные полные узлы и/или индексаторы.

индексатор

Indexer — это набор сервисов только для чтения, цель которых — индексировать и обслуживать данные блокчейна для пользователей более эффективным и удобным для Web2 образом. Это делается путем использования данных в режиме реального времени с полных узлов v4, их сохранения в базе данных и предоставления доступа к этим данным конечным пользователям через веб-сокеты и запросы REST.

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

Индексаторы будут использовать базу данных Postgres для хранения данных в сети, Redis для хранения данных вне сети и Kafka для потребления данных в сети/вне сети и потоковой передачи в различные службы индексаторов.

внешний интерфейс

Чтобы создать сквозной децентрализованный опыт, dYdX создает три интерфейса с открытым исходным кодом: веб-приложение, приложение для iOS и приложение для Android.

• Веб-приложение: веб-сайт будет создан с использованием Java и React. Веб-сайт будет взаимодействовать с Indexer через API, чтобы получать информацию о книге заказов вне сети и отправлять сделки непосредственно в сеть. dYdX откроет кодовую базу внешнего интерфейса и соответствующие сценарии развертывания. Это позволит любому легко развернуть и получить доступ к внешнему интерфейсу dYdX в / из своего собственного домена / размещенного решения через шлюз IPFS / Cloudflare.
• Мобильные устройства: приложения для iOS и Android созданы с использованием родных языков Swift и Kotlin соответственно. Мобильное приложение будет взаимодействовать с индексатором так же, как и веб-приложение, и отправлять транзакции напрямую в цепочку. Мобильное приложение также будет с открытым исходным кодом, что позволит любому развернуть мобильное приложение в App Store или Play Store. В частности, для магазинов приложений развертывателям необходимо иметь учетную запись разработчика и учетную запись Bitrise, чтобы завершить процесс отправки приложения.

Жизненный цикл заказа

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

1. Пользователи совершают транзакции в децентрализованном интерфейсе (например, на веб-сайте) или через API.
2. Заказ направляется валидатору. Этот валидатор сплетничает о транзакции другим валидаторам и полным узлам, чтобы обновить свои книги заказов новым заказом.
3. Процесс консенсуса выбирает валидатора в качестве предлагающего. Выбранные валидаторы соответствуют порядку и добавляют его в следующий предложенный блок.
4. Предлагаемый блок продолжается через процесс консенсуса. А. Если ⅔ валидаторов проголосуют за подтверждение блока, блок будет зафиксирован и сохранен в сетевой базе данных всех валидаторов и полных узлов. б) Если предложенный блок не достигает порога ⅔, блок будет отклонен.
5. После фиксации блока обновленные данные в цепочке (и вне цепочки) передаются от полных узлов к индексаторам. Затем индексатор предоставляет эти данные через API и веб-сокеты внешнему интерфейсу и/или любой другой внешней службе, которая запрашивает эти данные.

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