За словами технічного директора Paradigm Георгіоса Константопулоса, Solidity зараз перебуває в «неприємному стані», що спонукає до дискусій про те, чи варто його покращувати, чи розглядати альтернативи.
Як нам програмувати Ethereum?
Solidity зараз у проблемному стані, IMO. Чи робимо ми Solidity хорошим? Ми скидаємо Solidity? Якщо ми відмовимося від Solidity, ми зробимо Vyper чи ми створимо нову мову?
Якщо ми створюємо нову мову, чи варто замість цього використовувати середовище виконання RISCV, яке працює в Rust?
— Георгіос Константопулос (@gakonst) 3 квітня 2025 р
“Як ми маємо програмувати Ethereum? […] Ми покращимо Solidity? Ми відкинемо його? […] Чи ми перейдемо на Vyper чи нову мову програмування? Якщо ми виберемо останню, ми повинні створити середовище виконання RISCV, сумісне з Rust?” – зауважив експерт.
Solidity є основною мовою програмування, яка використовується для розробки смарт-контрактів на Ethereum.
У відповідь деякі члени спільноти стверджували, що новіша, простіша мова може допомогти розробникам уникнути дорогих помилок, що має вирішальне значення для екосистеми DeFi з TVL, що становить десятки мільярдів доларів.
Нова мова, яка є *простішою* за solidity, з хорошою взаємодією з/вихідним люком до solidity, можливо, завдяки першочерговому переходу до неї. Під простішим я маю на увазі: дати розробнику менше контролю, але ускладнити йому дорогі помилки. Приклад: змінні зберігання читаються…
— Бен ДіФранческо (@BenDiFrancesco) 3 квітня 2025 р
0xngmi, засновник DeFiLllama, запропонував створити нову альтернативу, яка заохочуватиме переоцінку процесу написання смарт-контракту, наголошуючи на станах і переходах, а не на простих інструкціях. Цей підхід може мінімізувати кількість помилок і підвищити безпеку коду.
Моя нетрадиційна думка полягає в тому, що було б добре створити нові мови, які замість того, щоб бути імперативними, працювали, коли б розробник описував кінцевий автомат, а потім генерував код, який би відповідав цьому
принципово багато розумних контрактів реалізують державну машину, і що…
— 0xngmi (@0xngmi) 3 квітня 2025 р
“Якщо вартість збереження поточного статус-кво перевищує витрати на перехід на нову мову, ми повинні розпочати загальноіндустріальний рух за відмову від Solidity. Ми можемо почати з двох наступних найбільш популярних варіантів — Rust і Move”, — запропонував Ніл Харунян, колишній керівник екосистеми Aptos Labs.
Під час розмови багато людей пропонували перейти на Rust, який використовується в екосистемі Solana. Однак деякі висловили скептицизм щодо його придатності для Ethereum.
Значна частина коментаторів виступала за «відремонтування» Solidity замість того, щоб відмовитися від нього, пропонуючи додати більш потужні інструменти та покращити досвід розробника, наголошуючи на важливості вирішення «найнагальніших проблем».
якщо теперішня вартість триваючого проблемного стану дорожча, ніж витрати на перехід на нову мову, ми повинні провести загальноіндустріальну кампанію, щоб знайти мову, яка має сенс. починаючи з двох наступних найбільш поширених мов SC – Rust і Move
— Ніл (@neilhar_) 3 квітня 2025 р
Решта пропонує використовувати Vyper, який пов’язаний із співзасновником Ethereum Віталіком Бутеріним і має активну підтримку від Curve Finance.
“Компілятор Solidity знаходиться в поганому стані (я підозрюю, що він обтяжений технічною заборгованістю), і для роботи з Ethereum потрібен інший компілятор або інша мова. Що ще більш інтригує, це те, що Paradigm значно сприяла популярності Solidity, розробивши спеціальні інструменти для Solidity”, – зазначив засновник Curve Михайло Єгоров.
Підприємець закликав розробників досліджувати використання Vyper, зазначивши, що його компілятор у порівняно кращому стані.
Просто перевірте, чи Vyper достатньо близько. Ви заощадите купу роботи!
— Curve Finance (@CurveFinance) 3 квітня 2025 р
“Просто перевірте, чи достатньо близько Vyper. Ви заощадите купу роботи!” відповів офіційний акаунт Curve Finance.
Варто зазначити, що в листопаді 2024 року ForkLog повідомив про наміри команди Vlayer розширити функціональність Ethereum шляхом створення Solidity 2.0.
Раніше Бутерін пропонував різні методи посилення децентралізації та спрощення аудиту коду.
Arabic
Chinese (Simplified)
Dutch
English
French
German
Italian
Portuguese
Spanish
Ukrainian