Розробка смарт-контрактів на Vyper
Vyper з'являється в ТЗ зазвичай з однієї з двох причин: або клієнт пройшов аудит, де аудитори вказали на складність аналізу Solidity-коду, або проект працює з DeFi-протоколами, де ціна помилки вимірюється мільйонами. Curve Finance, Lido, Yearn — все вони використовують Vyper тому що мова не дозволяє писати неоднозначний код. Це не рекламний тезис, це архітектурне рішення.
Чому Solidity іноді виявляється не тим інструментом
Головна проблема Solidity не у уязвімостях як таких — а у тому, скільки способів їх створити непомітно. Modifier-ланцюги, які виконуються у неочікуваному порядку. Implicit type conversion між uint256 і int256. Reentrancy через transfer() у receive(), тому що 2300 gas stipend уже не константа після Istanbul hardfork (EIP-1884). Dynamic dispatch через interface, який у runtime виявляється іншим контрактом.
Vyper намірено видаляє більшість цих конструкцій. Немає наслідування. Немає модифікаторів. Немає перегрузки функцій. Немає inline assembly (за винятком явно позначених блоків). Це означає, що аудитор читає контракт лінійно згори вниз — і бачить ровно те, що виконується.
Конкретний приклад з практики: контракт стейкингу на Solidity з трьома рівнями наслідування та п'ятьма modifier-ами на одній функції withdraw(). Reentrancy guard стоїть на першому modifier-е, але третій modifier змінює state перед викликом — і паттерн checks-effects-interactions виявляється порушеним. Rewrite на Vyper — 180 рядків замість 420, і вся логіка читається за одне прохідження.
Що Vyper обмежує принципово
Немає рекурсії. Глибина call stack завжди обмежена. Gas griefing через рекурсивні виклики фізично неможливий.
Немає нескінченних циклів. Всі цикли мають фіксовану границю, задану на рівні типу. for i: uint256 in range(100) — компілятор знає максимальну кількість ітерацій і може точно оцінити gas consumption.
Немає перегрузки операторів. Арифметика у Vyper завжди explicit: integer overflow перевіряється за замовчуванням з версії 0.3.x без SafeMath-обгорток. У Solidity до 0.8.0 це був джерело більшості дефляційних атак на токени.
Явні декоратори видимості. @external, @internal, @view, @pure — кожна функція отримує явний декоратор. Немає ситуації, коли функція стає публічною за замовчуванням через пропущений private.
| Характеристика | Solidity 0.8.x | Vyper 0.4.x |
|---|---|---|
| Наслідування | Підтримується | Відсутнє |
| Reentrancy guard | Через modifier | @nonreentrant вбудований у мову |
| Overflow protection | Default з 0.8.0 | Default завжди |
| Inline assembly | Широко доступний | Тільки @deploy, обмежено |
| Аудованість | Залежить від архітектури | Висока за замовчуванням |
| Розмір bytecode | Оптимізується через ir | Зазвичай менше для простої логіки |
Як ми розробляємо на Vyper
Інструментарій: Vyper 0.4.x, Titanoboa (фреймворк для тестування, працює прямо у Python без вузла), Hardhat з vyper-плагіном для інтеграції у існуючі EVM-проекти, Foundry для fuzz-тестування через FFI.
Titanoboa — окрема історія. Це інтерпретатор Vyper, написаний на Python, який дозволяє тестувати контракти у Jupyter Notebook або pytest без запуску локального вузла. Час на ітерацію при написанні тестів скорочується у 3-4 рази порівняно з Hardhat. Ми використовуємо його для unit-тестів і property-based тестування через hypothesis.
Для fuzz-тестування — Foundry через FFI: Vyper-контракт компілюється у bytecode, який потім запускається у Foundry-тестах. Не ідеально, але дозволяє використовувати Echidna для пошуку нарушень інваріантів.
Розвертання — через скрипти на Python з web3.py або через Hardhat-задачі. На Polygon та Arbitrum gas estimation ідентичний Ethereum mainnet (ті ж EVM opcodes), тому контракти портуються без змін.
Коли Vyper не підходить
Vyper — поганий вибір для складної системи з кількома взаємозв'язаними контрактами, які повинні переиспользовувати логіку через наслідування. Паттерн Diamond (EIP-2535) на Vyper реалізується через окремі модулі-контракти з явними викликами, що збільшує складність маршрутизації. Для таких систем Solidity з OpenZeppelin та жорстким style guide дає кращий результат.
Також Vyper не підходить, якщо у команді клієнта немає Python-розробників і всі тулинг завязаний на JavaScript/TypeScript екосистему — крива адаптації буде помітною.
Процес роботи
Аналіз вимог. Дивимось на складність бізнес-логіки, кількість взаємодіючих контрактів, вимоги до апгрейдованості. Якщо контракт передбачає proxy-паттерн з частими оновленнями — обговорюємо, тому що upgradeable Vyper вимагає окремого підходу (немає стандартного Transparent Proxy з OpenZeppelin).
Розробка і тестування. Пишемо на Vyper, тестуємо через Titanoboa + pytest. Покриття рядків коду — мінімум 95%. Окремий набір тестів на граничні умови: максимальні значення uint256, нульові адреси, виклики з контрактів vs EOA.
Статичний аналіз. Slither підтримує Vyper з версії 0.9.x. Запускаємо повний набір детекторів. Додатково — ручний review з фокусом на reentrancy через cross-function виклики.
Деплой. Верифікація контракту на Etherscan / Polygonscan. Vyper-контракты верифікуються через compiler metadata, який включає версію компілятора і settings.
Терміни на контракт середної складності: 3-5 робочих днів включаючи тесты. Вартість розраховується після аналізу ТЗ.