У цьому матеріалі
2 жовтня кросчейн-протокол THORChain запустив власний пул ліквідності Zcash (ZEC) після завершення оновлення вузлів мережі, які тепер відстежують Zcash. Наступним кроком стане запуск торгівлі.
THORChain заявив, що процес оновлення завершено, і кожен вузол стежить за мережею Zcash, а торгівля розпочнеться після запуску пулу. Протокол охарактеризував майданчик як децентралізований і попередив користувачів, що ліквідність залишається низькою на етапі відкриття.
Пул THORChain ZEC запущено до початку основної торгівлі
Новий пул ZEC надає мережі THORChain діючий майданчик для ліквідності Zcash до активації свопів. У своїй заяві від 2 жовтня THORChain зазначив:
«Торгівля — це наступний крок».
Ліквідність досі обмежена. THORChain попередив:
«Ліквідність поки невелика і зростатиме з часом, тому торгуйте з обережністю на початковому етапі».
У повідомленні від 2 жовтня не були вказані дані про глибину пулу або точний час початку торгів.
На сторінці активних вузлів у мережевому оглядачі THORChain наразі ZEC вказано як «OK» у розділі інформації про блокчейн, поряд з Bitcoin, Ethereum та кількома іншими мережами, які відстежуються показаним вузлом.
Підтримка Zcash з'явилася після кількох місяців роботи над кодом
У своєму оновленні протоколу від 4 березня THORChain повідомив, що інтеграція Zcash додала обробку UTXO, специфічну для цієї мережі, та логіку RPC. Окреме зміни включило ZEC до основного оракула протоколу, забезпечивши відстеження цін безпосередньо в логіці протоколу THORChain.
У березні до GitLab було внесено зміни, що виправляють звітність щодо мережевих комісій ZEC та розрахунки платоспроможності. Розробники заявили, що попередня реалізація могла завищувати допустимий рівень газу, оскільки повна комісія ZIP-317 розглядалася як ставка за байт під час одного з розрахунків платоспроможності. В результаті виправлення було змінено спосіб обробки вхідних даних про розмір транзакції для ZEC.
Розробка тривала і у вересні. У запиті на злиття THORNode були задокументовані невідповідності у підписі, що виникають через те, що термін дії транзакцій ZEC розраховувався на основі даних з різних локальних точок ланцюга, що призводило до отримання різних дайджестів підпису між вузлами.
У результаті об'єднання змін термін дії транзакцій був прив'язаний до узгодженої висоти ZEC на фіксованій висоті THORChain і зберігав значення при повторних спробах та перезапусках. Було введено періодичні оновлення узгодженої висоти ZEC за допомогою звітів про мережеві комісії, а також змінено обробку прострочених спроб підписання.
17 вересня в офіційному блозі THORChain було оголошено, що Zcash стане наступним у черзі на запуск в основній мережі, оскільки запуск блокчейна відновився після періоду, присвяченого забезпеченню стабільності мережі. Тоді проєкт уточнив терміни, вказавши, що запуск відбудеться до того, як вузли почнуть відстежувати Zcash, а пул ліквідності буде запущено.
Торги на біржі ZEC розпочнуться на початковому етапі за низької ліквідності
Попередження THORChain від 2 жовтня було безпосередньо пов'язане з доступною ліквідністю на етапі відкриття. Протокол закликав користувачів виявляти обережність, поки пул залишається невеликим, а торгівля все ще очікує наступного етапу активації.
У документації THORChain модель обміну описується як набір безперервних пулів ліквідності, які обробляють власні активи без необхідності використання обгорнутих версій. RUNE служить розрахунковим активом мережі та перебуває в її пулах ліквідності, забезпечуючи маршрутизуючий актив для обмінів між підтримуваними ланцюгами.
Для підтримки Zcash було потрібно кілька налаштувань, пов'язаних з його архітектурою UTXO. У більш ранньому внесенні THORNode ZEC було класифіковано як блокчейн на основі UTXO, і були додані конфігурації для перевірки адрес, одиниць газу, порогових значень пилу, часу створення блоків, параметрів coinbase та вимог до вхідних транзакцій.
Подальша робота тривала незадовго до запуску. У вересні було внесено виправлення, що стосується підпису транзакцій, яке вимагало від вузлів використання узгодженої висоти ZEC для терміну дії транзакцій, а також збереження тієї самої інформації про непідписані транзакції при повторних спробах замість перерахунку терміну дії на основі новішої локальної точки.
Читайте також:
