Нижче розібрано реальний кейс Audius — децентралізованої музичної платформи, яка у 2021 році перенесла основну логіку роботи з контентом з Ethereum на Solana, зберігши токен AUDIO на Ethereum L1. Це один із найбільш задокументованих прикладів міграції, і саме він дозволяє розглянути процес без прикрашання: з конкретними технічними компромісами, втратами та здобутками.

Причини міграції: вартість, швидкість, UX

Audius на етапі росту зіткнувся з трьома взаємопов'язаними обмеженнями Ethereum Mainnet.

Вартість транзакцій. Кожна дія користувача — завантаження треку, створення плейлиста, підписка на артиста — вимагала напису в блокчейн. За умови активного використання платформи витрати на gas для одного користувача могли сягати десятків доларів на місяць. Для продукту масового призначення це було неприйнятно.

Швидкість фіналізації. Час підтвердження блоку в Ethereum (12–15 секунд у той період, фактично — хвилини з урахуванням фіналізації) робив інтерактивні дії повільними. Користувач не міг миттєво побачити результат своєї дії — це суперечило очікуванням, сформованим централізованими сервісами на кшталт SoundCloud.

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

Solana пропонувала іншу модель: транзакції за частки цента, час блоку ~400 мілісекунд, можливість пакетної обробки транзакцій. Для Audius це не було ідеальним рішенням, але структурно відповідало їхнім проблемам.

Технічні виклики перепису смарт-контрактів

Міграція не була простим портуванням коду. Між Ethereum (Solidity, EVM) та Solana (Rust, Anchor, BPF-віртуальна машина) існує фундаментальна різниця в архітектурі.

Модель стану та обліку

У Ethereum стан зберігається в сховищі контракту (storage slots), а доступ до нього координується через msg.sender. У Solana кожен акаунт має власну область пам'яті, а доступ контролюється через систему PDA (Program Derived Address) та перевірку підписів. Команді Audius довелося перепроєктувати модель даних: замість єдиного контракту-моноліта з мапами користувачів і треків — набір програм із чітким розподілом власності даних.

Переписання бізнес-логіки з Solidity на Rust

Direct-трансляція неможлива. Solidity має гарбічний збір, динамічні масиви в storage, вбудовані модифікатори доступу. Rust вимагає явного управління пам'яттю, суворої типізації та роботи з серіалізацією (Borsh у випадку Anchor). Команда витратила значний час на переписування не лише логіки, а й тестів: інструментарій тестування в екосистемі Solana на той момент був значно менш зрілим, ніж Hardhat/Foundry у Ethereum.

CPI та композиційність

У Solana програми взаємодіють через Cross-Program Invocation (CPI) — механізм виклику однією програмою іншої з передачею контексту підписів. Це потужний інструмент, але він вимагає продуманого дизайну: кожен виклик змінює стек, обмежує глибину рекурсії та створює нові вектори помилок. Audius мав спроєктувати ланцюжок викликів так, щоб уникнути перевищення лімітів обчислень (compute units).

Збереження токена на Ethereum

Важливе архітектурне рішення: AUDIO залишився як ERC-20 на Ethereum. Solana-сторона працювала з "віддзеркаленими" балансами через мост (Wormhole). Це означало, що міграція була частковою — не повний переїзд, а розподіл логіки між двома мережами.

Міграція користувачів та ліквідності

Це був найменш технічний, але найскладніший етап.

Користувачі. Більшість аудиторії Audius взагалі не знала, що платформа працює на блокчейні. Міграція на Solana для них означала зміну внутрішнього рушія, а не перехід на новий продукт. Проте для тієї частини користувачів, яка взаємодіяла з токеном (стейкінг, управління), з'явилася необхідність навчитися користуватися мостом Wormhole, створювати Solana-гаманці (Phantom, Solflare). Це спричинило відтік частини токен-орієнтованої аудиторії.

Ліквідність. Розподіл токена між двома мережами фрагментував ліквідність. Деякі DEX на Solana додали пари з віддзеркаленим AUDIO, але глибина ринку суттєво поступалася Ethereum-парам на Uniswap. Команда не могла примусово перенести ліквідність — це залежало від рішень маркетмейкерів та LP-провайдерів.

Вузли та валідатори. Audius має власну мережу контент-вузлів (content nodes) та вузлів відкриття (discovery nodes). Міграція вимагала оновлення софту на всіх вузлах, що працювали з блокчейн-шаром. Частина операторів не оновилася оперативно, що створило тимчасову деградацію мережі.

Вимірювані результати після міграції

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

  • Зниження вартості транзакцій. Вартість типової дії на платформі (завантаження контенту, оновлення метаданих) знизилася на порядки — з доларового діапазону до часток цента за транзакцію в Solana.
  • Час підтвердження. Зменшився з секунд/хвилин до менш ніж секунди, що дозволило зробити UX наближеним до веб2.
  • Активність мережі. Кількість транзакцій, пов'язаних з Audius на Solana, суттєво перевищила показники на Ethereum. Проте це частково пояснюється архітектурною різницею: на Solana більше дій вимагають ончейн-письму.
  • Фрагментація ліквідності токена. Баланси AUDIO розділилися між Ethereum та Solana. Глибина ринку віддзеркаленого токена на Solana-DEX залишалася нижчою, ніж оригінального на Ethereum-DEX.
  • Залежність від мосту. З'явився новий вектор ризику — безпека мосту Wormhole. У лютому 2022 року Wormhole зазнав експлойту на ~120 тис. ETH, що прямо вплинуло на віддзеркалені активи, включно з AUDIO.

Уроки для команд, що розглядають міграцію

  1. Міграція рідко буває повною. У більшості реальних кейсів частина логіки або токеноміки залишається на початковому ланцюжку. Готуйтеся до підтримки двох мереж одночасно — це подвоює інфраструктурну складність.
  2. Різниця мов — це різниця парадигм. Перепис з Solidity на Rust не є рефакторингом. Це перепроєктування. Виділіть час на навчання команди та перебудову архітектури, а не лише на "переклад" коду.
  3. Мости — новий клас ризику. Перенісши активи через міст, ви додаєте атакувальну поверхню, яка не існувала в одномережевій архітектурі. Оцініть, чи компенсує вигід від нової мережі ризик втрати активів через вразливість мосту.
  4. Ліквідність не мігрує автоматично. Навіть якщо технічна міграція успішна, маркетмейкери та LP-провайдери приймають власні рішення. Фрагментація ліквідності — майже гарантований наслідок.
  5. UX-виграш не завжди очевидний кінцевому користувачу. Якщо ваша аудиторія не взаємодіє з блокчейном безпосередньо (як у випадку Audius), користувач не відчує різниці між Ethereum та Solana. Міграція виправдана лише якщо вона вирішує внутрішні проблеми масштабування, які інакше блокували б розвиток продукту.
  6. Тестування в новому середовищі починається з нуля. Інструменти, покриття тестами, edge-кейси — усе це треба вибудовувати заново. Не розраховуйте на автоматичну міграцію тестової бази.

Межі кейсу: не рекомендація мігрувати

Цей матеріал описує конкретний досвід конкретного проєкту в конкретний період. Audius мав унікальний профіль: масова не-крипто аудиторія, висока частота ончейн-записів, наявність власної інфраструктури вузлів. Ці фактори разом створили ситуацію, де Ethereum Mainnet був структурним вузьким місцем.

Для іншого проєкту — наприклад, DeFi-протоколу з низькою частотою транзакцій але високою вартістю замків — розрахунок може бути прямо протилежним. Ethereum L1 або L2-рішення можуть бути кращим вибором залежно від типу продукту, моделі безпеки, яку ви обираєте, та того, де знаходиться ваша ліквідність.

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

Джерела