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