Завьялов Илья Николаевич про сравнение Solana DeFi с Ethereum DeFi (Ч.2).

Поиск необеспеченного кредита в DeFi

Пожалуй, самая амбициозная и малоисследованная область в DeFi — это предоставление необеспеченных кредитов. Ограничения, связанные с избыточным залогом, ограничивают сферу применения кредитных протоколов, привязывая их к страховочной сетке ликвидаций. Переход к необеспеченному кредитованию требует надежных систем идентификации и репутации для снижения риска дефолта без гарантии залога. Такие инициативы, как интеграция телефонных номеров Celo с открытыми ключами и исследование децентрализованной системы Eigentrust для установления личности и репутации в сети, являются новаторскими попытками устранить этот пробел. Успешное внедрение необеспеченного кредита не только ознаменует важный этап в развитии DeFi, но и потенциально произведет революцию в том, как кредитование предоставляется в цифровую эпоху, предлагая бесшовную, основанную на доверии систему, которая вознаграждает позитивное финансовое поведение.

EVM доминирует в DeFi в настоящее время

Ethereum и его виртуальная машина Ethereum Virtual Machine (EVM) печально известны тем, что расширили функциональность Биткойна, создав полную по Тьюрингу среду, которая позволяет выполнять смарт-контракты. По своей сути смарт-контракты — это компьютерные программы, размещенные на блокчейн-платформах, которые автономно выполняют действия при соблюдении заранее определенных условий.

За последние ~7 лет Ethereum стал синонимом разработки смарт-контрактов, во многом благодаря поддержке таких языков, как Solidity и Vyper. Solidity, объектно-ориентированный язык программирования, черпает вдохновение в C++, JavaScript и Python и адаптирован для совместимости с виртуальной машиной Ethereum (EVM). Vyper, с другой стороны, предлагает экспериментальный подход к разработке контрактов, в дизайне которого использованы идеи Python, а также безопасность и простота.

Меня зовут Завьялов Илья Николаевич. Я предприниматель и увлекаюсь финансами. Добро пожаловать в мой блог.

Medium — medium.com/@IliaNicolaevichZavialov  

Substack — ilianicolaevichzavialov.substack.com/

Примерно 90%+ от общего объема DeFi TVL приходится на контракты, написанные на Solidity, предпочтительном языке программирования виртуальной машины Ethereum (EVM). Vyper, дополнительный язык смарт-контрактов, разработанный для EVM, занимает ~2% от общего объема TVL. Таким образом, ~96% стоимости DeFi хранится на EVM, построенных на Solidity или Vyper.

EVM играет ключевую роль в экосистеме Ethereum, выступая в качестве слоя абстракции, который легко преодолевает разрыв между кодом смарт-контракта и аппаратным обеспечением, выполняющим этот код. Язык программирования Solidity, используемый разработчиками, предназначен для конечной компиляции в байткод EVM — еще более простой набор инструкций, которые EVM может интерпретировать и затем выполнять. В ходе этого процесса EVM может взять текущее допустимое состояние и применить серию транзакций для создания нового допустимого состояния.

Одной из уникальных особенностей EVM является концепция газа (о ней речь пойдет в следующих разделах). В отличие от Биткойна, который просто взимает плату с пользователей за каждую финансовую транзакцию, модель Ethereum взимает плату с пользователей на основе выполненных вычислительных инструкций. Этот элемент «газ» добавляет новый уровень сложности в систему и во многом определяет, насколько сильно или слабо блокчейн может масштабироваться.

Проблемы с Solidity и EVM

Несмотря на то что EVM в настоящее время является бесспорным лидером в области виртуальных машин, общепризнанно, что у него есть существенные недостатки по сравнению с другими, более новыми виртуальными машинами. Масштабируемость и производительность представляют собой серьезные проблемы, которые необходимо решить для повышения эффективности и полезности EVM. Кроме того, сложности, присущие кодированию смарт-контрактов и взаимодействию между компонуемыми dApps, создают повышенный риск возникновения ошибок и уязвимостей в системе безопасности.

Среди распространенных рисков безопасности, наблюдаемых в EVM и коде Solidity, — атаки с повторным входом. Этот тип уязвимости позволяет злоумышленнику неоднократно вызывать функцию контракта в злонамеренном цикле, что может привести к утечке средств или дестабилизации протокола. Другая распространенная проблема заключается в простых кодовых или математических ошибках в смарт-контрактах, когда даже незначительные ошибки в формулах или логике вычислений могут привести к значительным финансовым потерям. Кроме того, критической уязвимостью является недосмотр в обеспечении правильных разрешений на вызовы. Контракты, в которых не обеспечивается адекватное ограничение вызовов функций авторизованными ролями, могут непреднамеренно предоставить злоумышленникам возможность выполнять несанкционированные транзакции или изменять состояния контрактов. 

Несмотря на привлекательность возможностей быстрого развертывания, реальность такова, что защита dApp от развивающихся угроз требует постоянного обучения, бдительного аудита кода и внедрения передовых мер безопасности. Такая среда не только ставит под постоянную угрозу средства пользователей, но и требует от разработчиков значительных затрат времени и ресурсов на защиту приложений от вредоносных эксплойтов.

Что касается масштабируемости EVM, то концепция газа является неотъемлемой частью сети. Газ служит метрикой вычислительных усилий, необходимых для выполнения транзакций и смарт-контрактов. Каждой транзакции выделяется определенное количество газа, что устанавливает предел вычислительных операций, которые могут быть выполнены. Эта система, разработанная для борьбы со спам-транзакциями и справедливого распределения сетевых ресурсов, вводит «самонавязанный» потолок масштабируемости для сети. Перед разработчиками, стремящимися оптимизировать выполнение контрактов в EVM, стоит задача минимизировать расход газа. Стратегии включают оптимизацию байткода — уменьшение количества опкодов (базовых операций EVM) — и использование таких техник, как разворачивание циклов и упрощение кода. Среди других улучшений масштабирования EVM за прошедшие годы — постепенное увеличение размера блока и сокращение времени выполнения блока (благодаря переходу на PoS). Несмотря на то, что эти усовершенствования с годами привели к ~3-5-кратному росту масштабируемости с момента создания Ethereum, EVM все еще намного менее производительна, чем другие проекты виртуальных машин блокчейна.

Язык программирования

В мире технологии блокчейн, где большинство цепочек alt-L1 решили использовать успех EVM, Solana выбрала другой путь. Отказавшись от совместимости с EVM, Solana использует фреймворк Low-Level Virtual Machine (LLVM) — краеугольный камень в современном программировании, который предлагает набор модульных и многократно используемых технологий компилятора и инструментария. LLVM выступает в качестве посредника, облегчающего перевод кода высокого уровня в машинный код, обеспечивая тем самым оптимальную производительность на различных аппаратных установках.

Наиболее распространенным языком программирования, используемым в экосистеме Solana, является Rust. Решение выбрать Rust в качестве основного языка для Solana обусловлено отличительными возможностями этого языка и стратегическими преимуществами, которые он дает инфраструктуре Solana. Репутация Rust как языка, обеспечивающего высокую производительность и параллелизм, прекрасно согласуется с архитектурными целями Solana, в частности с ее ориентацией на масштабируемость.

Подобно смарт-контрактам Ethereum, Solana вводит понятие «программы». Эти программы, написанные в основном на Rust, но также поддерживающие C и C++, являются основой для молниеносно быстрых экосистем DeFi и NFT в Solana. В основе подхода Rust к безопасности памяти лежит модель владения в сочетании с механизмом проверки заимствований, что в совокупности устраняет необходимость в сборщике мусора. Этот стратегический выбор дизайна позволяет Rust достичь высокой производительности, характерной для таких языков, как C и C++, при значительном повышении безопасности.

Локализованные рынки комиссионных сборов

Изначально в Solana была реализована система, в которой учетным записям присваивался фиксированный лимит вычислений, выраженный в «вычислительных единицах» (CU). Как только этот лимит достигался в пределах одного блока, никакие дополнительные транзакции не могли изменить состояние счета. Такая конструкция приводила к слишком предсказуемому результату — перегрузке цепи и скачкам комиссии, когда сеть испытывала высокий спрос. Для решения некоторых проблем и неоптимального пользовательского опыта, вызванного этими ограничениями на вычисления, в 2022 году была введена концепция локальных рынков сборов. Это нововведение позволяет пользователям платить приоритетные сборы валидаторам, чтобы сигнализировать о срочности изменения состояния учетной записи, которая уже достигла своего лимита вычислений в блоке. Этот механизм не только снижает уровень спама, позволяя важным транзакциям обгонять менее важные, но и повышает эффективность рынка блокчейн-пространства, обеспечивая гибкий, ориентированный на спрос подход к управлению и доступу к вычислительным ресурсам.

Теоретически локальные рынки сборов гарантируют, что скачки спроса в одной категории транзакций не будут оказывать непропорционально сильного влияния на сборы сети в целом. Несмотря на инновационный потенциал, практическая реализация локальных рынков комиссии в Solana столкнулась с проблемами: в сети преимущественно используется система «первой цены, жадной комиссии». Эта модель оказалась неэффективной, особенно в периоды пикового спроса, поскольку в ней отсутствует механизм, позволяющий пользователям точно прогнозировать и управлять комиссиями за транзакции. В настоящее время разрабатываются различные предложения, направленные на решение этих проблем, связанных со структурой рынка комиссионных сборов.