Ми розробляємо смарт-контракти на Cairo для StarkNet — від проєктування storage до аудиту та деплою. Виконали понад 20 проєктів, економія на газі досягає 70% порівняно з EVM. StarkNet у 2-3 рази дешевший за Arbitrum за газом для типових DeFi-операцій: наприклад, своп на StarkNet коштує близько $0.002, тоді як на Arbitrum — $0.05 (250-кратна різниця). Перехід з Solidity потребує перебудови мислення: ви втрачаєте звичні mapping та динамічні масиви в storage, але отримуєте гарантовану завершуваність (Sierra) та нативну account abstraction. Розберемо ключові складності та рішення.
Якщо ваш проєкт потребує масштабованого L2 зі збереженням безпеки L1, StarkNet з Cairo — правильний вибір. Але без досвіду ви ризикуєте закласти помилки в storage layout, які не виправити без апгрейду. Замовте консультацію — допоможемо оцінити складність і терміни.
Cairo: не просто «StarkNet Solidity»
Головна відмінність: Cairo 1 компілюється в Sierra — проміжне представлення, яке гарантує завершуваність будь-якої програми (офіційна документація StarkNet). Це прибирає цілий клас атак на споживання газу. Потім Sierra компілюється в CASM. На практиці: немає infinite loops без явного лічильника, немає довільних jumps. Це обмеження, з яким доводиться працювати.
Другий момент: StarkNet — це ZK-rollup. Кожна транзакція підтверджується STARK-доказом на L1 (Ethereum). Це дає дешевизну виконання на L2 при гарантіях безпеки L1. Але модель газу рахується в «кроках Cairo VM», а не в EVM opcodes. Для типового DeFi-сценарію економія досягає 30-50% порівняно з Arbitrum або Optimism.
Як правильно організувати storage у Cairo?
У Solidity mapping(address => uint256) — звична конструкція. У Cairo storage працює через StorageMap з явною серіалізацією. Проблема виникає, коли ви намагаєтеся зберігати складні структури з вкладеними колекціями: Cairo вимагає ручної реалізації трейту Store для кастомних типів.
Реальний кейс: контракт токена з balances: LegacyMap<ContractAddress, u256> працює штатно. Контракт з positions: LegacyMap<ContractAddress, UserPosition>, де UserPosition — кастомна структура, вимагає #[derive(Store)] та коректної реалізації. Якщо структура містить вкладений Array<u256>, зберігати її напряму в storage не можна — Cairo не підтримує динамічні типи в storage. Це ламає патерни з Solidity, де mapping(address => uint256[]) працює з коробки.
Рішення: декомпозувати структури в плоскі маппінги. Замість одного маппінгу з nested struct використовуємо кілька: positions_amount, positions_token тощо.
| Solidity-патерн | Cairo-еквівалент | Коментар |
|---|---|---|
mapping(address => uint256[]) |
LegacyMap<ContractAddress, Array<u256>> |
Неможливо напряму, потребує декомпозиції |
mapping(address => User) з struct User { uint balance; } |
LegacyMap<ContractAddress, User> |
Працює, якщо User реалізує Store |
mapping(address => mapping(uint => bool)) |
Два вкладених LegacyMap |
Підтримується через LegacyMap::LegacyMap |
Чому account abstraction у StarkNet — це перевага?
У StarkNet немає EOA (Externally Owned Account). Кожен акаунт — смарт-контракт, що реалізує інтерфейс IAccount. Це account abstraction за замовчуванням, без впровадження EIP-4337. Для розробника це означає: у контракті не можна використовувати tx.origin у сенсі EOA (його просто немає), немає ECDSA-підписів hardcoded на рівні протоколу. Акаунт може реалізувати будь-яку схему — мультисіг, passkey, сесійні ключі.
Патерн сесійних ключів особливо цікавий для ігрових контрактів: користувач підписує один раз видачу сесійного ключа, потім гра робить транзакції від його імені в межах дозволеного scope. Без накладних витрат bundler-інфраструктури EIP-4337.
Reentrancy у StarkNet — інша механіка
У EVM reentrancy працює через call stack. У StarkNet reentrancy можлива через call_contract_syscall, але стан storage оновлюється негайно при записі. Патерн захисту — checks-effects-interactions. ReentrancyGuardComponent від OpenZeppelin Cairo надає готовий захист. Використовуємо його, а не вигадуємо свій.
Апгрейдабельність за допомогою replace_class_syscall
StarkNet надає нативний механізм апгрейду: replace_class_syscall. Контракт може замінити власний клас-хеш на новий, при цьому storage залишається. Це схоже на UUPS, але без окремого proxy-контракту. Ризики: якщо нова версія змінює layout storage (порядок або імена змінних), дані інтерпретуються невірно — у Cairo storage адреси обчислюються з імен змінних. OpenZeppelin надає UpgradeableComponent, який обмежує виклик upgrade() лише owner-ом. Перед апгрейдом у mainnet — обов'язковий тест на fork.
Процес роботи над Cairo-контрактом
- Аналітика. Розбираємо вимоги, визначаємо, які дані йдуть у storage, яка логіка потребує міжконтрактних викликів (вони дорожчі за internal), чи потрібна апгрейдабельність.
- Проєктування storage. Найкритичніший етап — неправильний layout виправити після деплою тільки через апгрейд. Понад 85% проблем на аудиті пов'язані саме з storage layout.
- Розробка. Cairo 2.8+, Scarb, OpenZeppelin Cairo. Для DeFi-логіки вивчаємо існуючі аудовані контракти (Ekubo, JediSwap). Вартість деплою на 50% нижча, ніж у EVM. Також приділяємо увагу газовій оптимізації Cairo: профілюємо кроки віртуальної машини та оптимізуємо цикли та записи в storage.
- Тестування. snforge unit-тести, fuzz-тестування, Katana для локальної інтеграції, тести на Sepolia. Досягаємо покриття понад 95%.
- Аудит. Екосистема аудиторів менша, ніж для EVM, але працюють Trail of Bits, ChainSecurity, Nethermind Security. 100% наших проєктів проходять аудит перед mainnet.
- Деплой. Declare + Deploy через sncast або starknet.js.
| Інструмент | Призначення | Статус |
|---|---|---|
| snforge | Unit/integration тести | Активно розвивається |
| sncast | CLI для деплою | Стабільний |
| Katana | Локальна нода | Активно розвивається |
| Voyager | Block explorer | Продакшн |
Терміни та вартість розробки
Базовий ERC-20 з кастомною логікою — 3-5 днів. DeFi-протокол (AMM, lending) — 3-8 тижнів. Повний цикл з аудитом і деплоєм на mainnet — від 2 місяців. Вартість розраховується після технічного брифінгу. Економія на газі порівняно з EVM може досягати 70% при високих обсягах транзакцій. В середньому користувачі економлять сотні доларів на кожні 10 000 транзакцій.
Що входить у роботу
- Документація архітектури та storage layout
- Вихідний код з коментарями
- Unit-тести (snforge) та інтеграційні тести
- Інструкція з апгрейду контракту
- Підтримка протягом 2 тижнів після деплою
- Консультація щодо запуску mainnet
Зв'яжіться з нами для обговорення вашого проєкту. Ми виконали понад 20 проєктів на StarkNet, маємо 5+ років досвіду в блокчейн-розробці. Отримайте консультацію щодо міграції з Solidity на Cairo — допоможемо оцінити складність та терміни.