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. Програмне забезпечення Node написано на Go та скомпільовано в єдиний двійковий файл. Як і всі блокчейни CosmosSDK, версія 4 використовує консенсусний механізм підтвердження частки.
Протокол підтримуватиметься мережею вузлів. Існує два види вузлів:
Валідатори: валідатори відповідають за зберігання замовлень у книзі замовлень у пам’яті (тобто поза ланцюгом і без зобов’язань щодо консенсусу), передачу транзакцій іншим валідаторам і створення нових блоків для ланцюга dYdX через процес консенсусу. У процесі консенсусу валідатори по черзі пропонуватимуть нові блоки за зваженим циклічним способом (зваженим за кількістю токенів, поставлених на їхні вузли). Автори несуть відповідальність за пропозицію змісту наступного блоку. Коли порядок збігається, пропоненти додають його до свого запропонованого блоку та починають раунд консенсусу. Блок вважається прийнятим і додається до блокчейну, якщо його схвалять ⅔ або більше валідаторів (за вагою ставки). Користувачі надсилатимуть транзакції безпосередньо валідаторам.
Повний вузол: повний вузол представляє процес, у якому виконується програма v4, яка не бере участі в консенсусі. Це вузол із вагою частки 0, який не подає пропозиції та не голосує за них. Однак повні вузли підключаються до мережі валідаторів, беруть участь у переговорах транзакцій і обробляють кожен щойно поданий блок. Повні вузли мають повне уявлення про ланцюг dYdX та його історію та призначені для підтримки індексаторів. Деякі сторони можуть вирішити (з міркувань продуктивності або вартості) запустити власні повні вузли та/або індексатори.
індексатор
Indexer — це набір доступних лише для читання служб, мета яких — індексувати та обслуговувати дані блокчейну для користувачів у більш ефективний і зручний для web2 спосіб. Для цього використовуються дані в реальному часі з повних вузлів версії 4, зберігаються в базі даних і робляться доступними для кінцевих користувачів через веб-сокет і запити 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, давайте подивимося, як це все поєднується під час розміщення замовлення. Під час розміщення замовлення у версії 4 відбувається наступний процес:
Користувачі здійснюють транзакції в децентралізованому інтерфейсі (наприклад, на веб-сайті) або через API
Замовлення направляється на валідатор. Цей валідатор розповідає про транзакцію іншим валідаторам і повним вузлам, щоб оновити їхні книги замовлень новим замовленням.
У процесі консенсусу вибирається валідатор як пропонент. Вибрані валідатори відповідають порядку та додають його до наступного запропонованого блоку.
Запропонований блок продовжує процес консенсусу. a. Якщо ⅔ валідаторів проголосують за підтвердження блоку, блок буде зафіксовано та збережено в базі даних у мережі всіх валідаторів і повних вузлів. б) Якщо запропонованому блоку не вдається досягти порогу ⅔, блок буде відхилено.
Після фіксації блоку оновлені дані в ланцюжку (і поза ланцюгом) передаються від повних вузлів до індексаторів. Потім індексатор надає ці дані через API та Websockets інтерфейсу та/або будь-якій іншій зовнішній службі, яка запитує ці дані.
Потік вище — це огляд високого рівня того, як замовлення/дані переміщуються через v4. Оскільки наближається запуск основної мережі v4, ми докладніше заглибимося в протокол, індексатори та різноманітну зовнішню інфраструктуру в наступних публікаціях блогу.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Коротко опишіть технічну архітектуру dYdX V4
**Автор:**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. Програмне забезпечення Node написано на Go та скомпільовано в єдиний двійковий файл. Як і всі блокчейни CosmosSDK, версія 4 використовує консенсусний механізм підтвердження частки.
Протокол підтримуватиметься мережею вузлів. Існує два види вузлів:
індексатор
Indexer — це набір доступних лише для читання служб, мета яких — індексувати та обслуговувати дані блокчейну для користувачів у більш ефективний і зручний для web2 спосіб. Для цього використовуються дані в реальному часі з повних вузлів версії 4, зберігаються в базі даних і робляться доступними для кінцевих користувачів через веб-сокет і запити REST.
Незважаючи на те, що сам протокол v4 здатний надавати кінцевим точкам запити щодо деяких базових даних у мережі, ці запити, як правило, повільні, оскільки валідатори та повні вузли не оптимізовані для їх ефективної обробки. Крім того, надмірні запити до валідаторів можуть погіршити їх здатність брати участь у консенсусі. З цієї причини багато валідаторів Cosmos вважають за краще вимикати ці API у виробництві. Ось чому важливо створювати та підтримувати індексатори та повні вузли окремо від валідаторів.
Індексатори використовуватимуть базу даних Postgres для зберігання даних у ланцюжку, Redis для зберігання даних поза ланцюгом і Kafka для споживання даних у ланцюзі/поза ланцюгом і потокової передачі до різних служб індексаторів.
передня частина
Щоб створити наскрізний децентралізований досвід, dYdX створює три інтерфейси з відкритим кодом: веб-додаток, додаток для iOS і додаток для Android.
Життєвий цикл замовлення
Тепер, коли ми краще розуміємо кожен компонент dYdX v4, давайте подивимося, як це все поєднується під час розміщення замовлення. Під час розміщення замовлення у версії 4 відбувається наступний процес:
Потік вище — це огляд високого рівня того, як замовлення/дані переміщуються через v4. Оскільки наближається запуск основної мережі v4, ми докладніше заглибимося в протокол, індексатори та різноманітну зовнішню інфраструктуру в наступних публікаціях блогу.