Що буде з валідаторами Solana, які пропустять оновлення Agave 4.4.1?

Anza надала операторам вузлів Solana час до епохи 1079, щоб встановити патч, який змінює спосіб, у який мережа обліковує дані облікового запису, що завантажуються транзакцією. Машина, яка працює на старішій збірці, може залишатися онлайн і все одно випасти з узгодженого ланцюга, з різними наслідками для валідаторів, які отримують винагороди за стейкінг, і сервісів, на які покладаються гаманці для отримання актуальних даних.

Anza попередила валідаторів перед епохою 1079, що оператори, які працюють на старішому програмному забезпеченні, ризикують залишитися позаду, коли мережа ввімкне нове правило. Названі сумісні версії — Agave 4.4.1 і Firedancer v26.10.6.

Трекер feature gate Agave визначає відповідну зміну як мінімальний розмір завантажених даних для облікових записів ProgramData loader-v3. Його таблиця мінімальних версій відокремлює випуски, що використовуються тестовими мережами, від тих, що заплановані для mainnet. Читання розкладу вимагає одночасної перевірки кластера, функції та епохи.

Кінцевий термін також охоплював вузли, які не голосують. Ці машини можуть надавати гаманцям і біржам баланси, хеші блоків і дані підтвердження. Проблема на одній із них може дістатися користувачів, які ніколи не делегували SOL і не обирали валідатора.

Що робить зміна

Програма Solana може використовувати обліковий запис для зберігання своїх виконуваних даних. Коли транзакції потрібно завантажити програму, мережа обліковує дані, пов'язані з цією операцією. Мінімум, застосований до облікового запису даних програми, змінює те, як сумісне програмне забезпечення обробляє відповідну транзакцію за новим правилом.

Мета feature gate — скоординувати, коли учасники почнуть використовувати нове правило. Оператори можуть встановити випуск заздалегідь, тоді як фактична зміна правила набуває чинності в узгодженій точці. Тому версія може підтримувати функцію до того, як ця функція стане активною в mainnet.

Після активації gate старіший випуск може розійтися з оновленим програмним забезпеченням щодо транзакції або стану, створеного блоком. Валідатор тоді може перестати слідувати ланцюгу, визнаному рештою мережі, навіть якщо сам сервер залишається онлайн. Це практичне значення попередження Anza про відгалуження.

Чому стейк за вузлами має значення

Сто маленьких валідаторів і кілька великих операторів не обов'язково повинні представляти порівнянні обсяги голосуючого стейку. Для роботи мережі відповідне питання полягає в тому, скільки стейку дотримується сумісних правил. Трекер зазначає, що зміни мінімальної версії mainnet зазвичай слідують за порогом прийняття стейку та періодом очікування. Це загальне правило слід відрізняти від конкретного попередження, виданого перед епохою 1079.

Перевірка прийняття повинна поєднувати інформацію про версію з активним стейком, а потім порівнювати ці показники з участю в голосуванні після межі. Вузол, який повідомляє правильний випуск, все ще може наздоганяти або зазнавати окремої несправності. І навпаки, стабільний агрегат може маскувати проблеми в меншого оператора, якщо більшість стейку залишається онлайн і голосує нормально.

Ця різниця важлива для делегаторів. Їхній досвід залежить від валідатора, якому було призначено їхній стейк, а не від того, чи встановила більшість машин випуск. Якщо валідатор перестає ефективно голосувати, пропущена участь може зменшити винагороди, що приписуються цьому стейку. Відповідним доказом були б кредити голосів і записи винагород за відповідні епохи.

Що помітили б користувачі та біржі

Користувач, який надсилає SOL, дбає про те, чи прийнято переказ і чи досяг він потрібного рівня підтвердження. Це можна перевірити за допомогою даних транзакції та мережі. Твердження, що кілька операторів пропустили оновлення, саме по собі не встановлює повільніших підтверджень, зупинки чи масштабного збою.

Біржа також може призупинити депозити або виведення коштів, спостерігаючи за оновленням, навіть коли перекази тривають у ланцюжку. Баланси її клієнтів залежать від її власної інфраструктури та політики зарахування. Тому транзакція, яка з'являється в ланцюжку, може залишатися в очікуванні на біржовому рахунку клієнта, доки цей майданчик не відновить нормальну обробку.

Корисне порівняння після оновлення перевірило б три речі окремо. По-перше, чи продовжували створюватися та підтверджуватися блоки? По-друге, чи ефективно змінилася кількість стейку, що голосує? По-третє, чи призупиняла або відновлювала якась названа біржа перекази навколо цієї межі? Кожна відповідь потребує окремого запису.

Чому дедлайн оновлення стосувався також інфраструктури

У примітках до випуску Agave від Anza зміну обліку ProgramData визначено як бекпорт. Випуск Firedancer включає підтримку тієї самої функції. Коли два клієнти обробляють ту саму транзакцію після активації, вони повинні дійти згоди щодо того, скільки даних облікового запису вона завантажує. Спільне правило є тим, що має значення на цій межі.

RPC-вузол без стейку може обслуговувати застосунок, не вносячи стейк у голосування. Це робить імовірним те, що користувач гаманця зіткнеться з локальною проблемою, навіть якщо валідатори, що голосують, продовжують створювати блоки. Застосунок, який читає з відстаючої кінцевої точки, може відображати застарілий стан або повертати помилку. Порівняння його відповіді з тим самим запитом через іншу кінцеву точку допомагає визначити, де сталася перерва.

Жовтнева міграція Solana на Alpenglow дає контекст для того, як оператори готуються до скоординованої зміни. Та міграція стосувалася протоколу консенсусу. Листопадовий патч стосувався завантаження облікових записів. Обидва дають операторам версію для перевірки, але наслідки потрібно оцінювати щодо конкретного правила, яке змінилося.

Чим дедлайн відрізнявся від дати випуску

Anza опублікувала Agave 4.4.1 5 листопада. Її подальше попередження операторам повідомляло, що зміну заплановано на епоху 1079, початок якої оцінювався приблизно о 13:30 UTC 6 листопада. Версія визначала програмне забезпечення, потрібне операторам, тоді як епоха визначала, коли мережа планувала почати застосовувати правило.

Межа епохи залежить від прогресу ланцюжка. Час у попередженні давав операторам практичну оцінку, але важливою подією був перехід ланцюжка до нової епохи. Оператори не могли розглядати пізніший місцевий час або звичайне вікно технічного обслуговування як продовження графіка.

Випуск може містити код, який ще не змінює того, як мережа обробляє транзакції. Оператори спершу встановлюють програмне забезпечення, а потім мережа активує функцію в запланований момент. Така послідовність дозволяє операторам підготуватися, не застосовуючи вузлами одразу різних правил до того самого блоку.

Вікно було коротким навіть для операторів, які вже перейшли на Agave 4.4.0. Номер патчу змінився на одиницю, але попередній випуск не мав підтримки, потрібної для нового правила. Тому нещодавнє встановлення не було заміною перевірці точної збірки.

Випуск Firedancer 26.10.6 підтримував ту саму функцію. Оператори могли використовувати різні реалізації клієнтів, але обидва мали враховувати ті самі дані облікового запису під час виконання транзакції за активними правилами.

Різниця між програмним забезпеченням і активацією вже з'являлася в матеріалах crypto.news про розгортання Alpenglow у тестовій мережі. Alpenglow змінив консенсус, тоді як листопадовий патч стосувався обробки транзакцій. В обох випадках доступність збірки була окремою віхою від вимоги мережі щодо її поведінки.

Де ProgramData входить у транзакцію

Транзакція перелічує облікові записи, потрібні її інструкціям. Валідатор завантажує дані, пов'язані з цими обліковими записами, щоб виконати інструкції. Мережа обмежує обсяг даних облікових записів, який може завантажити транзакція, що дає валідаторам межу для категорії роботи, яку вони виконують до або під час виконання.

Оновлюваний завантажувач Solana використовує обліковий запис програми та окремий обліковий запис ProgramData. Останній зберігає дані виконуваної програми та пов'язану інформацію для завантажувача. Користувач викликає програму, не враховуючи вручну розмір цих виконуваних даних. Цю частину обробляє середовище виконання валідатора.

Патч встановлює мінімальну межу для обсягу, що приписується обліковому запису ProgramData завантажувача v3, коли його завантажують. Якщо старий облік приписував менше за цю межу, нове правило зараховує щонайменше мінімум проти ліміту завантажених даних транзакції. Транзакція, що значно нижче ліміту, може дати той самий результат після зміни.

Різниця має значення на межі. Транзакція, яка поєднує кілька інструкцій або використовує кілька програм, може вже завантажувати значний обсяг даних облікових записів. Якщо новий мінімум піднімає сукупний обсяг вище ліміту, старі та нові правила можуть дати різні результати навіть за тих самих інструкцій і того самого підписувача.

Ліміт завантажених даних відрізняється від бюджету обчислень. Обчислення вимірюють роботу з виконання. Транзакція може мати достатньо обчислень для виконання інструкцій і все одно не пройти ліміт, який регулює, які облікові записи вона може завантажити. Підвищення дозволу на обчислення саме по собі не змінює обсяг, що зараховується проти ліміту завантажених даних.

Правило також залишає розгорнуті інструкції застосунку на місці. Програма може залишатися за тією самою адресою і мати той самий код, поки валідатор стягує за її обліковий запис ProgramData інакше. Команди застосунків мають причину перевірити транзакції поблизу ліміту, навіть якщо вони не робили власного розгортання.

Як два вузли можуть розійтися щодо одного й того самого блоку

Валідатори виконують транзакції, щоб перевірити стан, створений блоком. Якщо два вузли починають з одного стану і застосовують різні правила до однієї з цих транзакцій, вони можуть дійти різних результатів. Вони не можуть обидва вважати той самий результуючий стан дійсним, якщо різницю не усунуто.

Це пояснює попередження Anza про те, що старіші вузли випадають із синхронізації. Старий вузол може залишатися онлайн і продовжувати відповідати на запити, не відстежуючи ланцюг, прийнятий сумісними валідаторами. Те, що його процес працює, є слабшим тестом, ніж те, чи він актуальний і чи погоджується з кластером.

Оператор може порівняти слот, який повідомляє вузол, із незалежним джерелом. Валідатор, що голосує, також має перевірити, що його голоси зараховані на прийнятому ланцюзі. Журнали помилок можуть виявити проблему під час повторного відтворення блоків, яка була б невидимою під час перевірки безперервності роботи.

Попередження описувало наслідок несумісності. Оцінка після граничного терміну все ще потребує показати, які оператори запускали застарілі збірки і що сталося з їхніми вузлами. Знімок версій, зібраний після відновлення оператора, міг би пропустити короткий період, коли той валідатор випадав із синхронізації.

Дата активації та момент, коли спостерігач помічає проблему, також можуть відрізнятися. Вузьке правило впливає лише на транзакції, які його задіюють. Період без видимої розбіжності одразу після межі не показав би, чи може вузол обробити транзакцію поблизу ураженого ліміту.

Чому підрахунок валідаторів розповідає лише частину історії

Важливість валідатора, що голосує, частково залежить від того, яку частку стейку він представляє. Кілька великих операторів можуть представляти більшу вагу голосів, ніж багато менших. Тому підрахунок уражених машин відповідає на інше питання, ніж відсоток активного стейку, який продовжував брати участь.

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

Відповідні показники можуть змінюватися незалежно. Виробництво блоків може продовжуватися, поки конкретний постачальник RPC надає застарілі дані. Валідатор може пропускати голоси, поки його публічний вебсайт залишається доступним. Біржа може призупинити депозити Solana, поки ланцюг продовжує підтверджувати перекази.

Раніше висвітлення граничного терміну Alpenglow у Solana описувало передачу, що вимагає скоординованої підготовки валідаторів і застосунків. Метою там була швидша фінальність. Обмеження ProgramData має вужчий технічний ефект, але оператори все одно мають оцінювати готовність відповідно до свого місця в мережі.

Що делегатори можуть встановити з записів голосування та винагород

Делегатори мають економічне питання, навіть коли мережа залишається доступною. Вони хочуть знати, чи валідатор, який заробляє винагороди від їхнього імені, продовжував брати участь. Пропущений патч сам по собі не переміщує делегований SOL зі стейк-акаунта, але переривання голосування може зменшити винагороди, зароблені протягом відповідного періоду.

Перше місце, куди варто подивитися, — це акаунт голосування валідатора. Порівняння кредитів голосування за епохи навколо межі може встановити, чи змінилася його участь. Записи винагород дають окрему перевірку впливу на конкретні стейк-акаунти.

Нижча винагорода сама по собі не ідентифікує оновлення як причину. Комісія, попередня продуктивність валідатора та статус стейк-акаунта — усе це може впливати на зафіксовану суму. Докази того, що голосування зупинилися на межі та відновилися після зміни клієнта, дали б сильніше пояснення, ніж одна нижча винагорода.

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

Стейкінг через біржу додає сервісні відносини. Біржа може керувати власними валідаторами або використовувати іншого провайдера, а потім зараховувати клієнтам згідно зі своїми умовами. Користувачеві знадобилися б записи біржі, щоб пов'язати ончейн-зміну голосувань із винагородою, зарахованою на індивідуальний акаунт.

Що застаріла кінцева точка RPC може зробити з гаманцем

Багато гаманців отримують баланси, блокхеші та результати транзакцій через кінцеву точку RPC. Вузол, який відстає, може повідомляти попередній баланс або не повертати нещодавню транзакцію. Користувачі можуть зіткнутися з цими симптомами, навіть якщо інші вузли обробляють мережу нормально.

Блокхеш може вплинути на транзакцію до того, як мережа її виконає. Гаманець, який отримує застарілий блокхеш, може побудувати транзакцію, яка вже недійсна на момент, коли вона досягає справного вузла. Симптом — невдала відправка, але причина може бути в застарілій інформації, а не в зміні балансу чи інструкцій.

Симуляція залежить від тих самих відносин. Вузол, що працює за старими правилами, може повідомити, що транзакція відповідає ліміту завантажених даних, навіть якщо вузли, які застосовують нове правило, отримують інший результат. Симуляція на сумісному вузлі все ще може відрізнятися від остаточного виконання, якщо стан змінюється між симуляцією та включенням.

Застосунки з кількома вузлами за однією кінцевою точкою стикаються з іншою можливістю. Запити можуть вдаватися або не вдаватися залежно від того, яка машина їх отримує. Провайдер повинен перевірити, що весь пул актуальний, перш ніж відносити періодичну проблему до ланцюга.

Порівняння між незалежними кінцевими точками допомагає відокремити ці проблеми. Якщо кілька актуальних кінцевих точок збігаються, а один сервіс відрізняється, розбіжність може бути локальною для цього сервісу. Якщо незалежні спостерігачі також повідомляють про зміну у виробництві блоків або підтвердженнях, є сильніші докази мережевої проблеми.

Жовтневий перехід консенсусу мав власні інфраструктурні зміни. Crypto.news повідомив, що Alpenglow видалив попередні ончейн-транзакції голосування. Командам застосунків довелося відрізняти зміну в тому, що вони спостерігали, від того, чи могли валідатори слідувати новій системі. Листопадове правило завантаження акаунтів знову робить відповідь залежною від ролі спостерігача.

Чому зарахування на біржі може відставати від ланцюга

Біржа може зарахувати депозит лише після того, як її системи розпізнають переказ і застосують свою політику підтвердження. Тому успішна ончейн-транзакція не визначає, коли зміниться внутрішній біржовий баланс клієнта.

Платформа може призупинити депозити або виведення коштів під час оновлення інфраструктури. Вона також може продовжувати отримувати перекази в мережі, поки її черга депозитів очікує підтвердження від справного вузла. Повідомлення платформи та оглядач блоків можуть обидва бути точними, навіть якщо один показує переривання обслуговування, а інший — успішний переказ.

Щодо виведення коштів, затримка може виникнути до того, як біржа підпише або транслює транзакцію. Відсутність запису в мережі протягом цього часу мало що говорить про те, чи прийме мережа транзакцію після її подання. Статус обробки платформи стосується саме цієї частини часової шкали.

Повідомлення про те, що кілька бірж призупинили операції, все одно потребувало б визначення, які саме послуги були порушені та яку причину навела кожна з них. Повідомлення про планове технічне обслуговування або черга, спричинена іншою проблемою, можуть потрапити в те саме вікно, що й оновлення. Збіг є приводом порівняти записи, а не мірилом участі мережі.

Що показало б, чи пропустили оператори патч

Трекер фіча-гейтів Anza відокремлює мінімальну межу випуску від окремих активацій. Попередні матеріали crypto.news про розгортання Alpenglow та межу mainnet описували ту саму відмінність. Збірка може відповідати межі в один момент і не мати зміни, запланованої на пізнішу епоху.

Найкорисніший запис після активації порівнював би активну функцію, розповсюдження програмного забезпечення та участь операторів у тому самому вікні. Запис функції визначає, коли правило почало застосовуватися. Запис програмного забезпечення визначає, які збірки були в експлуатації. Голоси та блоки показують, чи поводилися мережа та окремі оператори по-різному.

Пропущені слоти є одним із можливих спостережень. Вони також можуть зростати з причин, не пов'язаних із патчем, зокрема через звичайну продуктивність валідаторів, призначених лідирувати. Порівняння кількох вікон і зіставлення пропусків із їхніми лідерами надає спостереженню контекст.

Прострочена частка стейку дає інший погляд. Сума може змінюватися, коли один великий валідатор припиняє участь, навіть якщо загальна кількість прострочених вузлів майже не змінюється. Порівняння має враховувати операторів, які вже були простроченими до оновлення.

Вплив на RPC та біржі потрібно документувати окремо. Ці провайдери можуть обслуговувати велику кількість користувачів, не з'являючись у порівнянні частки стейку. Їхні повідомлення, метрики обслуговування та записи про те, коли вузли повернулися до поточних слотів, описували б збої, які дані голосування не можуть зафіксувати.

Чому поетапне розгортання все одно потребує тесту активації

Стабільний випуск клієнта можна розгортати поступово до активації нової функції. Це дозволяє операторам побачити, чи програмне забезпечення запускається правильно, наздоганяє та обробляє транзакції за поточними правилами. Це також допомагає виявити проблеми розгортання до того, як його використовуватиме більше вузлів.

Успішне розгортання до активації не може перевірити всі наслідки активної функції. Транзакцію поблизу ліміту завантажених даних облікового запису потрібно тестувати за обома наборами правил, щоб показати, де саме змінюється результат. Це інший тест, ніж спостереження за тим, чи залишається бінарний файл онлайн.

Crypto.news раніше повідомляв, що Alpenglow орієнтувався на інший підхід до фінальності. Його критерії успіху включали те, що сталося зі швидкістю підтвердження. Патч ProgramData краще оцінювати за тим, чи клієнти погоджуються щодо транзакцій, які стикаються з новим лімітом, і чи залишається інфраструктура доступною після ввімкнення гейта.

Відкат також змінює значення під час активації. До межі старіший підтримуваний випуск все ще може обробляти правила, що вже діють. Після неї повернення до збірки, якій бракує функції, може відновити саме ту несумісність, яку оператор намагався вирішити. Резервний варіант повинен зберігати підтримку активного гейта.

Оператор із запасом потужності може підняти пропатчений вузол і перевірити його перед призначенням трафіку. Менший оператор може бути змушений перезапустити свій єдиний вузол і чекати, поки він наздожене. Дедлайн є спільним, але час, який користувачі проводять в очікуванні, може залежати від надлишковості провайдера.

Чому ціна SOL не може виміряти ефект оновлення

SOL може падати або зростати в ті самі години, коли оператори встановлюють патч. Він торгується проти багатьох тих самих валют і пулів капіталу, що й інші криптоактиви. Ставки, рухи Bitcoin і зміни в кредитному плечі можуть впливати на ціну в тому самому вікні.

Технічна проблема може мати значення для торгівлі, якщо вона перериває перекази або робить застосунок недоступним. Доказами такого пояснення були б повідомлення від торгових майданчиків, зміни в депозитах або виведеннях коштів, або дані про виконання в ончейні, пов'язані з відповідними акаунтами. Лише ціна токена не ідентифікує цей канал.

Невдача окремої транзакції також відрізняється від втрати контролю над акаунтом. Гаманець міг сформувати транзакцію зі старою інформацією або надіслати її через застарілий вузол. Користувач все ще може контролювати акаунт, тоді як застосунок має проблеми з доступом до поточної мережі.

Найбільш прямим тестом після дедлайну є, отже, перевірка на рівні сервісу. Вузол голосування має бути актуальним і записувати голоси. Сервіс RPC має відповідати на запити з прийнятого ланцюга. Біржа має бути здатною відзвітувати про те, чи і коли вона обробила перекази, подані близько моменту перемикання.

Ці докази можуть підтримати оцінку, навіть якщо ціна рухається з не пов'язаних причин. Вони також дають делегаторам спосіб оцінити продуктивність їхнього власного валідатора, не сприймаючи загальномережеву вимогу до версії як твердження про результати кожного оператора.

Що відбувається, коли оператор повертається в мережу

Встановлення виправленого програмного забезпечення — це один крок до відновлення вузла. Потім оператору потрібно побачити, чи процес наздоганяє прийнятий ланцюг і чи слідує він йому за поточними правилами. Сервер може успішно перезапуститися, поки він все ще відтворює блоки або повертає дані, що відстають від вершини ланцюга.

Вузол голосування також має показати, що його участь відновилася. Його оператор може порівняти поточні голоси з часом, коли вузол відновився. Делегатор, який пізніше читає дані про винагороди, тоді може відрізнити точку відновлення від часу, коли було встановлено виправлення.

Постачальник послуг може вивести виправлений вузол з ротації, поки він не наздожене та не пройде перевірки. Оператор може порівняти слот, результат нещодавньої транзакції та результат симуляції з окремим еталоном. Постачальник, який повертає вузол у роботу до цих перевірок, може створити враження, що оновлення програмного забезпечення завершено, тоді як клієнти все ще стикаються зі старими даними.

Хронологія має значення при оцінці впливу. Вузол, який відхилився і повернувся в межах тієї самої епохи, може виглядати здоровим у пізнішому каталозі. Його пропущена участь все ще може мати значення для оператора або делегаторів. Публічна хронологія інциденту потребувала б достатньої деталізації, щоб показати, коли послуга зупинилася і коли нормальна діяльність відновилася.

Команди застосунків також можуть досліджувати транзакції, які зазнали невдачі лише через певний бекенд. Якщо повторне надсилання через поточний вузол вирішує проблему без зміни інструкцій, попередня кінцева точка стає ймовірним джерелом збою. Якщо та сама транзакція послідовно зазнає невдачі на поточних вузлах поблизу ліміту даних акаунта, саму транзакцію, можливо, потрібно перебудувати.

Така перебудова може включати зменшення даних, завантажених транзакцією, або розділення інструкцій, якщо застосунок може допустити кілька транзакцій. Розділення транзакції може змінити її гарантії, оскільки інструкції, які мали виконатися або зазнати невдачі разом, можуть більше не робити цього. Тому ця зміна належить до власного дизайну застосунку, поряд з його вимогами до завантаження акаунтів.

Наслідки для користувача залежать від того, де виникла несумісність. Оператор може пропустити участь, RPC може повертати застарілу інформацію, а застосунок може сформувати транзакцію, яка більше не вміщується. Перші два випадки можна вирішити шляхом відновлення сумісної інфраструктури, тоді як третій залежить від транзакції та чинного правила.

Перевірка відновлення Solana має зберігати ці спостереження окремо. Вона має порівнювати записи голосування для операторів, записи обслуговування для постачальників послуг і результати виконання для постраждалих застосунків. Це дає змогу виявити вузький ефект, навіть якщо мережа продовжувала виробляти блоки протягом усього часу.

Листопадовий дедлайн дав операторам названий реліз і межу епохи. Довготривалий запис його впливу походитиме з того, що робили вузли навколо цієї межі, і з послуги, яку вони змогли надати після неї.

На що звернути увагу

• Сумісні випуски: Графік Anza та примітки до випусків можуть встановити базовий рівень mainnet та його еквіваленти в різних клієнтах.
• Участь у голосуванні: Активний стейк і кредити голосів можуть показати, чи змінилася участь у голосуванні навколо цієї межі.
• Підтвердження мережі: Записи блоків і підтверджень можуть показати, чи продовжувала мережа обробляти транзакції навколо зміни.
• Операції бірж: Повідомлення торгових майданчиків можуть встановити, чи призупинила біржа власні депозити або виведення Solana.

Поширені запитання