Как перейти с Ethereum на Solana: руководство для разработчиков

О чём эта статья?

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

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

Фундаментальные различия

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

Механизмы консенсуса

Механизмы консенсуса лежат в основе каждой блокчейн-сети. Они определяют, как проверяются транзакции и как блоки безопасно, эффективно и децентрализованно добавляются в блокчейн. Ethereum и Solana — это сети Proof of Stake (PoS). Хотя обе сети основаны на PoS, их подходы к достижению консенсуса различаются из-за разных правил подтверждения.

Ethereum использует Gasper — сочетание Casper the Friendly Finality Gadget (Casper-FFG) и алгоритма выбора форка LMD-GHOST. Вместе они образуют механизм консенсуса, обеспечивающий безопасность Ethereum.

Casper — это основанная на PoS система финализации, которая повышает статус подтверждения блока до «финализированного». Блок в Ethereum считается финализированным, когда две трети совокупного стейка голосуют за включение этого блока и поверх него создаётся ещё один блок. Поскольку для финализации требуется согласие двух третей совокупного стейка с тем, что блок является каноническим, злоумышленник не сможет создать альтернативную финализированную цепочку, не владея двумя третями совокупного стейка или не контролируя их и не уничтожив как минимум одну треть через слэшинг. Casper позволяет новым участникам уверенно синхронизироваться с канонической цепочкой. 

LMD-GHOST — аббревиатура от «Latest Message-Driven Greedy Heaviest Observed Sub-Tree». Этот алгоритм определяет, какому форку Ethereum следовать. Он выбирает форк, получивший наибольшую поддержку, то есть «вес», от валидаторов сети — отсюда выражение «жадное самое тяжёлое наблюдаемое поддерево». Затем алгоритм учитывает только самое последнее сообщение от каждого валидатора. При каждом предложении нового блока в Ethereum валидаторы применяют это правило, чтобы решить, должен ли блок стать частью канонической цепочки.

Для сравнения: Solana использует хеши Proof of History (PoH) для достижения консенсуса. Несмотря на неоднозначное название, PoH — не алгоритм консенсуса. Это способ доказать ход времени во враждебной сети. Точнее, это криптографическая функция временных меток, которая позволяет нодам согласовать порядок событий, не обмениваясь данными друг с другом. Лидер, то есть валидатор, добавляющий записи в реестр, присваивает блокам временные метки, чтобы доказать, что с момента предыдущего блока прошло определённое время. 

Добавление временных меток формирует историческую запись, поскольку они доказывают, что данные существовали в определённый момент времени. Историческая запись создаётся с помощью последовательной устойчивой к нахождению прообраза хеш-функции, где каждый хеш зависит от предыдущего. Функции верифицируемой задержки (VDF) играют ключевую роль в создании этих хешей. Они гарантируют, что каждый хеш основывается на предыдущем и учитывает прошедшее с того момента время. Интеграция VDF добавляет временное измерение в процесс хеширования и позволяет создать в Solana проверяемую последовательность событий с временными метками.

Разобравшись, как механизм Proof of History в Solana создаёт надёжную последовательность событий с помощью криптографических временных меток, важно понять его интеграцию с механизмом консенсуса Solana — Tower BFT. Tower Byzantine Fault Tolerance (BFT) — это оптимизированный для PoH вариант традиционной модели консенсуса Byzantine Fault Tolerance в Solana. Tower BFT использует созданную PoH историческую запись как систему координат. Она позволяет валидаторам эффективно и точно голосовать за состояние реестра. В Tower BFT валидаторы отдают голоса, которые блокируются на длительный срок, а с добавлением новых голосов обязательства усиливаются. Благодаря PoH валидаторы могут быстрее принимать более обоснованные решения о состоянии реестра без обмена данными друг с другом. Сочетание PoH и Tower BFT ускоряет достижение консенсуса и повышает безопасность и надёжность сети. В результате возникает масштабируемая блокчейн-среда с высокой пропускной способностью, где транзакции подтверждаются быстро.

Обработка транзакций и среды выполнения

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

Среда выполнения Ethereum работает как детерминированная однопоточная стековая машина под названием Ethereum Virtual Machine (EVM). Она ведёт себя как математическая функция. Иными словами, при заданных входных данных EVM выдаёт детерминированный результат. Полезно представить Ethereum как функцию перехода состояния: f(S, T) = S’. Получив прежнее состояние (S) и новый набор допустимых транзакций (T), EVM создаёт новое допустимое выходное состояние (S’). При одинаковом наборе транзакций EVM всегда достигает одного и того же конечного состояния. Это критически важно для согласованности между нодами сети.

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

Ethereum упрощает среду выполнения смарт-контрактов за счёт однопоточной модели. Разработчики получают предсказуемые изменения состояния, поскольку транзакции обрабатываются последовательно. Благодаря этому среда разработки Ethereum, вероятно, доступнее для начинающих: они могут сосредоточиться на логике смарт-контракта, а не на сложностях выполнения. Однако такая простота затрудняет масштабирование. Последовательная обработка ограничивает пропускную способность сети. Это может приводить к перегрузкам, более долгому ожиданию транзакций и повышению комиссий за газ в периоды высокого спроса. Поскольку каждая транзакция расходует газ, разработчикам приходится оптимизировать его использование. Такая оптимизация улучшает общий пользовательский опыт и помогает бороться с перегрузками, при которых неэффективный код способен сделать приложения непригодными для обычного пользователя.

Разработчикам Solana не нужно оптимизировать расход газа, как разработчикам Ethereum. Solana спроектирована как машина состояния с высокой пропускной способностью и низкой задержкой, известная как Solana Virtual Machine (SVM). Важный компонент SVM — Sealevel. Это движок среды выполнения, который обрабатывает транзакции параллельно. В Solana каждая транзакция сообщает среде выполнения, какие части состояния она прочитает или изменит. Среда выполнения параллельно обрабатывает неконфликтующие транзакции и транзакции, читающие одно и то же состояние. Sealevel оптимизирует выполнение смарт-контрактов, распределяя транзакционную нагрузку между несколькими потоками на оборудовании валидатора. Пока валидатор обрабатывает одну транзакцию на одном ядре, другая может одновременно обрабатываться на другом.

Встроенный параллелизм Solana значительно снижает стоимость транзакций. У транзакций Solana есть две комиссии: базовая и приоритетная. Базовая комиссия фиксирована и составляет 5000 лампортов за подпись; у большинства транзакций только одна подпись. Приоритетная комиссия необязательна и позволяет повысить приоритет транзакции относительно других транзакций. Планировщик недетерминированно отдаёт приоритет транзакциям с более высокой приоритетной комиссией. Комиссии за транзакции часто составляют менее $0,001 USD, а средняя комиссия за транзакции, не связанные с голосованием, находится в диапазоне от 0,000005 до 0,00007 SOL. Верхняя граница выше обычной из-за недавнего роста использования приоритетных комиссий. При текущей цене SOL около ~$98,96 такая комиссия составляет приблизительно от $0,000494 до $0,006968 USD. 

Эти комиссии также предсказуемы. Для управления спросом Solana использует локальные рынки комиссий. Пространство блока устроено так, чтобы отдельная точка высокой активности, например популярный минт NFT, не могла занять всё пространство и повысить комиссии во всей сети. Комиссии растут только для транзакций, которые пытаются получить доступ к конкретной точке высокого спроса. Локальные рынки комиссий позволяют использовать приоритетные комиссии, не провоцируя полномасштабные войны газа. Такая локализация отличается от сетей на основе газа, таких как Ethereum, где транзакции обрабатываются последовательно, а общая перегрузка приводит к нестабильным комиссиям.

Ethereum — однопоточная среда выполнения, которая обрабатывает только один контракт за раз. Сейчас она не использует преимущества современного многоядерного оборудования, поэтому аппаратные ресурсы валидаторов задействованы не полностью. Стремление сохранить низкие требования к оборудованию нод дополнительно ограничивает обработку транзакций в Ethereum. Для сравнения: благодаря параллельной обработке Solana может выполнять больше транзакций, используя все доступные ядра валидатора. В сочетании с локальными рынками комиссий это делает Solana гораздо более производительной машиной глобального состояния. 

Языки смарт-контрактов

Основной язык разработки смарт-контрактов в Ethereum — Solidity. Это статически типизированный язык с фигурными скобками, предназначенный для создания смарт-контрактов, работающих в EVM. На него значительно повлияли JavaScript, C++ и Python, поэтому разработчики, знакомые с этими языками, легко его осваивают.

Yul — промежуточный низкоуровневый язык, оптимизированный для совместимых с EVM блокчейнов. Yul даёт разработчикам больше контроля над выполнением байт-кода и особенно эффективен для точной настройки расхода газа и управления другими низкоуровневыми операциями. Разработчики могут создавать более эффективные контракты, программируя непосредственно на Yul или используя его как целевой язык компиляции.

Vyper — популярный Python-подобный язык, ориентированный на простоту и безопасность. В нём намеренно меньше возможностей, чем в Solidity, поскольку его цель — снизить сложность и количество потенциальных уязвимостей. Философия Vyper превыше всего ставит удобочитаемость и проверяемость кода. Этот подход вдохновил разработку похожих языков, например Fe, а также языков, компилируемых в Vyper, таких как Dasy.

Rust — лингва франка для разработки смарт-контрактов, которые в Solana обычно называют программами. Это быстрый и эффективный с точки зрения памяти язык, производительность которого сопоставима с C++. Благодаря этим характеристикам он подходит для разработки приложений в сети с высокой пропускной способностью и низкой задержкой. Развитая система типов и модель владения Rust обеспечивают безопасность памяти и потоков, заставляя разработчиков создавать надёжные и безопасные приложения. 

Хотя Rust непросто освоить тем, кто ещё не знаком с системным программированием, взамен он позволяет создавать надёжный и эффективный код. Большая часть разработки на Rust ведётся с помощью Anchor. Anchor — это фреймворк с заданными соглашениями, который упрощает разработку программ: сокращает шаблонный код, выполняет различные стандартные проверки безопасности и оптимизирует процесс (де)сериализации. Поэтому для начала работы не нужны глубокие знания Rust. Для ориентира: документация Anchor рекомендует пользователям ознакомиться с первыми девятью главами книги о Rust, то есть знать основы Rust. В Solana Playground есть несколько руководств по Anchor, которые помогут начать работу.

Хотя Rust предпочтителен, разработчики им не ограничены. Можно использовать C, C++ и любой язык, ориентированный на BPF-бэкенд LLVM, то есть любой язык, который компилируется в байт-код BPF. Тем, кто знаком с Python-подобными языками, такими как Vyper, Seahorse Lang позволяет писать программы на Python. Разработчики получают простоту Python, сохраняя те же гарантии безопасности, что и при разработке на Rust. Начать программировать на Solana уже сегодня помогут полезные руководства по Seahorse, например Seahorse University и Seahorse Cookbook.

Разработчики, переходящие с Ethereum, не ограничены Rust. Рекомендуется изучить и использовать такие популярные фреймворки, как Anchor и Seahorse, благодаря предоставляемым ими гарантиям безопасности, но это не всегда возможно. Благодаря недавним разработкам Solang и Neon Labs, включая их компилятор и совместимую с EVM среду разработки, разработчики могут использовать Solidity для создания программ. У Solidity есть своё место в Solana. Чтобы приступить к разработке программ на Solidity, необходимо глубже разобраться в особенностях программной модели Solana. Понимание модели аккаунтов Solana критически важно для разработчиков, совершающих этот переход, поскольку она лежит в основе разработки программ и взаимодействия с сетью.

Модель аккаунтов

Ethereum делит аккаунты на две основные категории: аккаунты с внешним владельцем (EOA) и контрактные аккаунты. EOA — стандартный тип аккаунта для пользователей. Они управляются закрытыми ключами, могут хранить баланс Ether, отправлять транзакции и взаимодействовать с контрактными аккаунтами. Операциями контрактных аккаунтов, напротив, управляет встроенный в них код смарт-контракта. Они не могут самостоятельно инициировать транзакции и действуют только в ответ на транзакции от EOA или других контрактных аккаунтов.

Solana использует более унифицированную модель аккаунтов и рассматривает их как многофункциональные контейнеры для постоянного хранения данных. В этой модели любой аккаунт может быть программой, что стирает традиционную границу между аккаунтом и смарт-контрактом. В отличие от Ethereum, где код и состояние объединены в одном аккаунте, программы Solana не имеют состояния. Это означает, что они не хранят состояние внутри себя. Все необходимые им данные хранятся в отдельном аккаунте и передаются транзакцией по ссылке. Передача аккаунтов по ссылке позволяет развернуть одну универсальную программу, способную взаимодействовать с разными аккаунтами. Модель аккаунтов Solana разделяет код и данные, создавая более эффективную и модульную среду разработки. Это удобно для пользователей, которым нужно взаимодействовать с несколькими протоколами, не перемещая активы между разными программами. В Solana всё является аккаунтом. 

Аккаунты Solana можно разделить на исполняемые и неисполняемые. Проще говоря, исполняемые аккаунты могут запускать код. Неисполняемые аккаунты служат для хранения данных и не могут выполнять код, поскольку не содержат его.

Исполняемые аккаунты содержат программы. Программы могут владеть дополнительными аккаунтами, читать данные других аккаунтов или пополнять их баланс, изменять данные и списывать средства с принадлежащих им аккаунтов. Исполняемые аккаунты можно дополнительно разделить на ончейн-программы и нативные программы. Ончейн-программы — это написанный пользователями код, развёрнутый в сети. Их может обновлять уполномоченный на это аккаунт, обычно тот, который их развернул. Нативные программы — особая разновидность исполняемых аккаунтов. Они похожи на предварительно скомпилированные контракты Ethereum, но обладают более широкой функциональностью. Эти программы встроены в ядро Solana и предоставляют функции, необходимые для работы валидаторов. Пример нативной программы — System Program. Она отвечает за создание новых аккаунтов, выделение памяти под данные аккаунтов, назначение аккаунтов программам, перевод лампортов из принадлежащих ей аккаунтов и оплату комиссий за транзакции. Полный список нативных программ доступен здесь.

У всех аккаунтов, независимо от того, являются они исполняемыми или неисполняемыми, одинаковый набор полей: 

• Поле lamports для отслеживания нативного баланса аккаунта в SOL
• Поле данных, содержащее необработанный массив байтов, который хранится в аккаунте
• Поле владельца, указывающее программу, которая может изменять этот аккаунт
• Поле подписанта, которое используется в транзакциях и указывает, может ли аккаунт подтверждать транзакции
• Поле доступности для записи, определяющее, можно ли изменять данные аккаунта. Оно упрощает параллельную обработку, помечая включённые в транзакции аккаунты как доступные только для чтения или для записи
• Поле исполняемости, указывающее, хранит ли аккаунт программу
• Поле эпохи ренты, указывающее следующую эпоху, в которой аккаунт должен заплатить ренту

Рента — это стоимость хранения, которая позволяет поддерживать аккаунты Solana активными и хранить их в памяти валидаторов. Чтобы оставаться активными, аккаунты должны поддерживать минимальный баланс. Рента сокращает разрастание состояния, позволяя сети со временем освобождать неиспользуемые аккаунты и аккаунты с недостаточным балансом. После недавних обновлений в основной сети не осталось аккаунтов, которые платят ренту. Вместо этого все аккаунты при создании должны быть освобождены от ренты. Аккаунт освобождается от ренты, если поддерживает минимальный баланс, эквивалентный платежам за два года. Оценить объём SOL, необходимый для освобождения аккаунта от ренты, можно с помощью таких инструментов, как Test Drive и подкоманда rent в Solana CLI. Это отличается от системы распределения ресурсов Ethereum, где хранилище сохраняется, пока его явно не очистят. Подход Solana предлагает более предсказуемую структуру затрат на хранение состояния и одновременно сокращает его разрастание.

Адреса и адреса, производные от программы (PDA)

Каждый аккаунт идентифицируется адресом — уникальным 32-байтовым открытым ключом. Это отличается от модели данных Ethereum, где длина адресов составляет 20 байт. Для создания адресов Solana использует ed25519, то есть схему подписи EdDSA на основе SHA-512 и эллиптической кривой Curve22519. Чтобы иметь допустимую пару ключей, аккаунт должен быть точкой на кривой ed25519. 

Адреса, производные от программы (PDA), — это аккаунты, созданные вне кривой с помощью bump, то есть значения, смещающего результат за пределы кривой. Для PDA необходимы три основных компонента: адрес родительской программы, набор сидов и bump. Сиды представляют собой массив строк с произвольными значениями. Однако большинство разработчиков создают определённые сиды, связанные с переменными состояния родительской программы, чтобы формировать структуры данных, похожие на хеш-таблицы. Таким образом, PDA создаётся путём хеширования ID программы, сидов и bump с помощью хеш-функции SHA-512.

PDA находятся вне кривой, чтобы только породившая PDA программа могла подписывать данные от его имени. Это упрощает поток транзакций благодаря программному созданию подписей, позволяя dApp без доверия работать без вмешательства.

Взаимодействие с аккаунтом

Транзакция Ethereum — это изменяющее состояние действие, инициированное EOA. Смарт-контракты не могут самостоятельно инициировать транзакции, а способны только реагировать на них. Эти реакции определяются кодом контракта, а стоимость выполнения транзакции измеряется в газе. Пользователи должны предоставить достаточно Ether для оплаты комиссии за газ.

Транзакции Ethereum обычно выполняют одну операцию, например вызывают определённую функцию смарт-контракта. Хотя одна транзакция может привести к нескольким изменениям состояния внутри контракта, все изменения ограничены рамками одного вызова контракта.

В Solana транзакция включает массив аккаунтов для чтения или записи, одну или несколько подписей и одну или несколько инструкций. Инструкция — это директива для одного вызова программы. Она представляет собой наименьшую единицу логики выполнения и основную операционную единицу. Инструкции указывают исполняющую программу, все задействованные аккаунты и операционные данные. Программы интерпретируют данные инструкции и выполняют операции с указанными аккаунтами. Такая структура позволяет одной транзакции атомарно выполнять последовательность действий в нескольких программах. Это означает, что все инструкции либо успешно выполняются, либо завершаются с ошибкой вместе. Поток транзакций Solana отличается от модели Ethereum, где транзакция обычно связана с одним смарт-контрактом или действием EOA.

Межпрограммные вызовы (CPI) позволяют одной программе вызвать другую в рамках той же транзакции. Количество байтов данных аккаунта на единицу вычислений, взимаемых при CPI, составляет 250. Это примерно 50 МБ при 200 000 единиц. CPI позволяют использовать программно созданные подписи при вызовах между программами. Это похоже на эффективный и атомарный вызов одним смарт-контрактом Ethereum другого контракта. Однако вызывающая программа приостанавливается до тех пор, пока вызванная программа не завершит обработку инструкции. Повторный вход ограничен прямой рекурсией программы в саму себя с фиксированной максимальной глубиной 4. Это предотвращает ситуации, когда программа вызывает другую из промежуточного состояния, не зная, что позднее может получить обратный вызов.

Для эффективности размер транзакций Solana ограничен, подобно лимиту газа в Ethereum. Однако основное внимание уделяется объёму данных. Для надёжной передачи данных транзакции Solana соответствуют стандартам максимального размера передаваемого блока IPv6 (MTU). После резервирования необходимого пространства под заголовок для данных пакета остаётся 1232 байта. Чтобы преодолеть ограничения размера и поддерживать несколько форматов транзакций, Solana представила версионированные транзакции. Помимо устаревшего формата, то есть исходного формата транзакций, была выпущена версия 0 с поддержкой таблиц поиска адресов (ALT). ALT хранят адреса ончейн в табличной структуре данных, где каждый адрес индексируется однобайтовым индексом u8. Это значительно уменьшает размер транзакций, поскольку для каждого аккаунта требуется только 1 байт вместо 32 байт.

Solang

Solang — компилятор Solidity для Solana и Polkadot. Он стремится обеспечить совместимость исходных файлов с версией 0.8 компилятора Solidity для EVM, хотя и с некоторыми изменениями для соответствия архитектурам Solana и Polkadot. Важная особенность Solang — использование LLVM, мощной инфраструктуры для компиляторов. Гибкость LLVM позволит Solang в будущем поддерживать другие языки программирования и упростит их реализацию и компиляцию. Это соответствует цели Solang: облегчить разработчикам переход на Solana или Polkadot и расширить сферу применения Solidity. Solang непрерывно развивается с упором на совместимость, эффективность и удобство использования. Разработчикам Ethereum, которые хотят применять свои навыки в разных блокчейнах, важно понимать особенности и ограничения Solang.

Установка

Установить Solang можно несколькими способами. На Mac пользователи могут загрузить Solang через Brew с помощью частного tap-репозитория:

brew install hyperledger/solang/solang

Другой способ установить Solang — использовать контейнеры Solang. Он отлично подходит тем, кто предпочитает Docker, поскольку новые образы автоматически публикуются в этих контейнерах. Доступны теги v.0.3.3 и latest:

docker pull ghcr.io/hyperledger/solang:latest

Один из самых простых способов установить и использовать Solang — через Ancor. Сначала убедитесь, что в системе установлены Rust и Node.js. Пользователям Windows также потребуется настроить Подсистему Windows для Linux. Теперь необходимо установить набор инструментов Solana. На Mac и Linux это можно сделать следующей командой:

 sh -c "$(curl -sSfL https://release.solana.com/v1.17.13/install)"

Если вам нужна другая версия ПО, замените «v1.17.13» соответствующим тегом выпуска. Также можно использовать одно из следующих символических названий каналов: stable, beta или edge. В зависимости от системы вам может потребоваться обновить переменную среды PATH. Если вы увидите соответствующее сообщение, скопируйте и выполните рекомендованную ниже команду, чтобы обновить PATH. Проверить нужную версию solana можно командой solana --version.

В Windows откройте командную строку от имени администратора. Скопируйте и выполните следующую команду, чтобы загрузить установщик Solana во временный каталог:

cmd /c "curl https://release.solana.com/v1.17.13/solana-install-init-x86_64-pc-windows-msvc.exe --output C:\solana-install-tmp\solana-install-init.exe --create-dirs"

Затем скопируйте и выполните следующую команду, чтобы установить последнюю версию Solana: C:\solana-install-tmp\solana-install-init.exe v1.17.13. После завершения установки нажмите Enter.

Закройте окно командной строки и откройте новое от имени обычного пользователя. Убедитесь, что нужная версия solana установлена, выполнив команду solana –-version.

Затем установите Anchor.

Рекомендуется устанавливать Anchor с помощью менеджера версий Anchor (avm). Это можно сделать через cargo следующей командой:

cargo install -git https://github.com/coral-xyz/anchor avm --locked --force.

Затем установите и активируйте последнюю версию:

avm install latest
avm use latest

# Verify the installation
avm –version

Anchor версии 0.28 позволяет разработчикам выполнять сборку непосредственно с помощью Solang. Создать новый проект Solang можно командой anchor init project_name —solidity. Она создает новую программу Solang и тестовый файл, демонстрирующий взаимодействие с программой через клиент.

Если вы используете Visual Studio Code, установите расширение Solang для подсветки синтаксиса. Отключите все другие активные расширения Solidity, чтобы расширение Solang работало корректно.

Создание нового проекта

Создайте новый проект командой anchor-init project_name –solidity. Она создаст новый каталог с именем вашего проекта. Флаг Solidity указывает Anchor, что мы хотим использовать Solang. В каталоге ./solidity проекта будет находиться стартовая программа. Контракт будет выглядеть так:

@program_id("F1ipperKF9EfD821ZbbYjS319LXYiBmjhzkkf5a26rC")
contract test {
    bool private value = true;

    @payer(payer)
    constructor() {
        print("Hello, World!");
    }

    /// A message that can be called on instantiated contracts.
    /// This one flips the value of the stored `bool` from `true`
    /// to `false` and vice versa.
    function flip() public {
            value = !value;
    }

    /// Simply returns the current value of our `bool`.
    function get() public view returns (bool) {
            return value;
    }
}

В этой программе есть constructor для создания программы, инициализации переменной состояния value значением true и записи «Hello, World!» в логи программы. Функция flip при вызове обновляет переменную состояния. Функция get возвращает текущее значение переменной состояния. Это похоже на обычный смарт-контракт Solidity, но есть несколько особенностей. Самое существенное отличие — использование аннотаций.

Аннотации

Аннотации используются для управления аккаунтами. Обратите внимание на аннотацию @program_id(“...”). Она задает ончейн-адрес программы, если тот известен заранее. Чтобы вызвать контракт через внешний вызов, программа должна иметь обозначение @program_id либо вызываться с аргументом {program_id: … }:

@program_id(“...”);

contract Foo {
	function hello() public pure {
		print(“Hello”);
	}
}

contract Foo2 {
	function bye() public pure {
		print(“Bye”);
	}
}

contract Bar {
	function new_foo() external {
		Foo.new();
	}
}

contract Bar2 {
	function new_foo(address new_foo_id) external {
		Foo2.new{program_id: new_foo_id}();
	}
}

Когда мы создавали новый проект, над конструктором в примере контракта находилась аннотация @payer. Она определяет аккаунт, который оплатит инициализацию аккаунта данных программы. Синтаксис @payer(payer) объявляет аккаунт с именем payer, который будет необходим при каждом вызове конструктора.

При создании экземпляра контракта требуется аккаунт программы для хранения исполняемого кода и аккаунт данных для хранения переменных состояния. Аккаунт данных можно создать в клиентском коде, а затем передать в транзакцию, вызывающую конструктор. Также аккаунт данных может создать сам конструктор. Как минимум необходимо указать аннотацию @payer. Если аккаунт данных будет PDA, нужно указать seed и bump. Аннотация @seed задает seed для получения PDA. Это может быть строковый литерал или шестнадцатеричная строка в формате hex”1234”. Если аннотация seed находится перед аргументом, она должна ссылаться на аргумент типа bytes, address или на байтовый массив фиксированной длины. Аннотация @bump задает значение для получения адреса вне кривой. Это должен быть один байт типа bytes1. Необязательная аннотация @space позволяет задать размер аккаунта данных. Это выражение uint64, которое может быть константой или использовать один из аргументов конструктора. Согласно документации Solang, значение @space должно быть как минимум равно размеру, указанному при выполнении команды solang -v:

$ solang compile --target solana -v examples/solana/flipper.sol
...
info: contract flipper uses at least 17 bytes account data
…

Если у программы нет конструктора, эти аннотации можно использовать с пустым конструктором. В документации Solang приведен следующий пример:

@program_id("Foo5mMfYo5RhRcWa4NZ2bwFn4Kdhe8rNK5jchxsKrivA")
contract Foo {

    @space(500 + 12)
    @seed("Foo")
    @payer(payer)
    constructor(@seed bytes seed_val, @bump bytes1 bump_val) {
        // ...
    }
}

Аннотации функций используются для объявления аккаунтов, необходимых внешним функциям:

• @account(foo) объявляет аккаунт foo доступным только для чтения
• @mutableAccount(bar) объявляет аккаунт bar изменяемым
• @signer(fizz) объявляет аккаунт fizz подписантом с доступом только для чтения
• @mutableSigner(buzz) объявляет аккаунт buzz изменяемым подписантом

Аккаунты, объявленные в конструкторе с аннотацией @payer, доступны внутри него. Аккаунты, объявленные аннотациями функций, доступны в векторе tx.accounts. Например, для доступа к аккаунту, объявленному как @account(ichigo), используется tx.accounts.ichigo. Это вернет встроенную структуру AccountInfo. Она соответствует структуре, описанной в разделе «Понимание модели аккаунтов». Названия немного отличаются:

• key: адрес или публичный ключ аккаунта. Имеет тип address
• lamports: баланс аккаунта в лампортах. Имеет тип uint64
• data: данные аккаунта. Имеют тип bytes
• owner: владелец аккаунта. Имеет тип address
• rent_epoch: следующая эпоха, в которой наступит срок оплаты ренты аккаунта. Имеет тип uint64
• is_signer: указывает, подписал ли аккаунт транзакцию. Имеет тип bool
• is_writable: указывает, доступен ли аккаунт для записи в этой транзакции. Имеет тип bool
• executable: указывает, является ли аккаунт программой. Имеет тип bool

Ограничения

Основные несовместимости Solang с традиционной разработкой для Ethereum:

• msg.sender недоступен в Solana. При модели аккаунтов контракт на Rust может обращаться к различным аккаунтам данных, но какой из них считать вызывающей стороной? Во многих случаях невозможно определить один аккаунт как вызывающий. Кроме того, среда выполнения не предоставляет механизма для получения аккаунтов вызывающей стороны
• Функции ecrecover() нет, но существует функция signatureVerify() для проверки подписей ed25519.
• Конструкции try-catch не работают. Если внешний вызов или создание контракта завершится ошибкой, среда выполнения остановит исполнение и откатит всю транзакцию.
• Определения ошибок и откаты с сообщениями об ошибках пока не работают
• Передача нативной валюты при вызове функции не работает.
• Многие встроенные функции Yul недоступны. Solang поддерживает большинство встроенных функций, однако операции с памятью и блокчейном не реализованы.
• Формат ERC-20 пока не поддерживается. SPL-токены определяются в соответствии с Token Program. Token Program — нативный для Solana способ создания, выпуска, передачи и сжигания токенов. Файл spl_token.sol необходимо скопировать в дерево исходного кода и импортировать там, где требуется библиотека SplToken

Кроме того, регистры SVM имеют разрядность 64 бита, поэтому 64-битные целые числа (например, uint64 и int64) предпочтительнее 256-битных. Операция с типами разрядностью более 64 бит, такими как uint256 или int256, разбивается на несколько операций. Поэтому она выполняется медленнее и расходует больше вычислительных единиц.

Литерал адреса необходимо задавать с помощью синтаксиса address"36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D". Шестнадцатеричный синтаксис Ethereum (например, 0xE0f5206BBD039e7b0592d8918820024e2a7437b9) не поддерживается. Все балансы и значения в Solana имеют разрядность 64 бита. Поэтому встроенные функции для адресов (то есть .balance(), .transfer() и .send()) используют 64-битные целые числа.

Solang открывает разработчикам EVM перспективный путь в экосистему Solana, но у него есть несколько ограничений, которые необходимо тщательно учитывать. Переход к модели Solana на основе аккаунтов — не просто синтаксическое изменение, а фундаментальная смена логики смарт-контрактов. Некоторые функции, шаблоны кода и специфические возможности EVM недоступны в Solang. Разработчики не могут перенести смарт-контракт Ethereum в Solang и ожидать, что он заработает без существенных изменений. Отсутствие некоторых возможностей, например полноценных определений ошибок и откатов с сообщениями об ошибках, может стать серьезной проблемой. Однако важно учитывать, что Solang постоянно развивается и каждое обновление призвано улучшить опыт разработки на Solidity для Solana. Solang также дает несколько явных преимуществ.

Преимущества

Несмотря на эти ограничения, ряд встроенных функций и архитектурных решений улучшает опыт разработчиков. Например, созданные в Solang контракты могут взаимодействовать с программами Anchor. Для этого можно сгенерировать интерфейс Solidity из IDL программы Anchor. IDL означает «язык описания интерфейсов». По сути, это JSON-файл со всеми спецификациями программы. Он содержит всю информацию, необходимую для взаимодействия с программой Anchor. При разработке программы с помощью фреймворка Anchor автоматически создает IDL. Это очень похоже на ABI в Ethereum. Чтобы сгенерировать интерфейс Solidity из IDL, выполните команду solang idl [-output directory] [IDL file]. Затем файл можно импортировать с помощью синтаксиса import “...”;.

Solang предоставляет библиотеку Solana — набор библиотек, с помощью которых контракты Solidity взаимодействуют со специфическими инструкциями Solana. Для выпуска, сжигания и передачи токенов Solang предоставляет библиотеку SPL Token. Ее можно считать аналогом ERC-20 и ERC-721. Solang также предоставляет библиотеку системных инструкций, чтобы разработчики могли взаимодействовать с System Program в Solana.

Solang также включает встроенные возможности, которые можно импортировать с помощью solana. В их число входят структуры AccountMeta и AccountInfo. Структура AccountMeta задает аккаунты, которые нужно передать вызываемой стороне при внешнем вызове (то есть CPI). Структура AccountMeta имеет следующий вид:

• pubkey: адрес или публичный ключ аккаунта. Имеет тип address
• is_writable: указывает, может ли вызываемая сторона записывать данные в этот аккаунт. Имеет тип bool
• is_signer: указывает, может ли вызываемая сторона считать, что этот аккаунт подписал транзакцию. Имеет тип bool

Если при внешнем вызове опустить аргумент accounts, компилятор Solang автоматически создаст массив AccountMeta. Это работает только для функций, объявленных как external. В противном случае массив AccountMeta нужно создать вручную в соответствии с порядком аккаунтов в IDL. Если для определенного вызова аккаунты не нужны, передайте пустой вектор: {accounts: []}. В документации Solang приведен хороший пример создания массива AccountMetas:

function build_this() external {
	// When calling a constructor from an external function, the data account for the contract
	// 'BeingBuilt' should be passed as the 'BeingBuilt_dataAccount' in the client code.
	BeingBuilt.new("my_seed");
}

function build_that(address data_account, address payer_account) public {
	AccountMeta[3] metas = [
		AccountMeta({
			pubkey: data_account,
      is_signer: true,
      is_writable: true
		}),
    AccountMeta({
    	pubkey: payer_account,
      is_signer: true,
      is_writable: true
    }),
    AccountMeta({
      pubkey: address"11111111111111111111111111111111",
      is_writable: false,
      is_signer: false
    })
  ];
  BeingBuilt.new{accounts: metas}("my_seed");

	// No accounts are needed in this call, so we pass an empty vector.
	BeingBuilt.say_this{accounts: []}("It's summertime!");
}

Solang также предоставляет встроенные функции для следующих задач:

• Расчет минимального баланса, необходимого для создания определенного аккаунта
• Создание PDA для адреса программы на основе указанных seed и bump
• Поиск PDA для адреса программы на основе указанных seed и bump

Solang объединяет Solana и Ethereum, предоставляя компилятор с богатым набором инструментов, который упрощает переход для разработчиков EVM. Несмотря на ограничения, Solang предлагает несколько возможностей для улучшения опыта разработки: взаимодействие с программами Anchor, доступ к специфическим библиотекам Solana и встроенные функции. Интеграция знакомых концепций, таких как IDL и стандарты токенов, дополнительно упрощает обучение. Возможность не беспокоиться о газе и его оптимизации также стала приятным дополнением. Solang — важный шаг к совместимости между Solana и Ethereum. Для разработчиков EVM, которые хотят выйти в высокопроизводительный мир Solana, Solang может стать подходящим инструментом.

Neon EVM

Solang — не единственный вариант для разработчиков Solidity, желающих создавать приложения в Solana. Neon EVM позиционирует себя как первая в мире распараллеливаемая EVM. Это полностью совместимая среда Ethereum в Solana. Она предлагает синергетическое и удобное для разработчиков решение по масштабированию dApp Ethereum в Solana. Разработчики могут развертывать dApp без перенастройки смарт-контрактов, используя любимые языки и инструменты.

Архитектура

Neon EVM состоит из трех основных компонентов: программы Neon EVM, Neon Proxy и Neon DAO.

Neon EVM — программа Solana, которая принимает транзакции, подобные Ethereum, и обрабатывает их в Solana по правилам EVM. Такие направленные в Neon EVM транзакции называются Neon Transactions. Они представляют собой подмножество методов JSON RPC из Ethereum JSON-RPC API.

Neon Proxy позволяет разработчикам Ethereum переносить dApp в Neon с минимальными изменениями. Он упаковывает транзакции EVM в транзакции Solana и служит контейнерным решением для операторов Neon. Эти операторы запускают серверы Neon Proxy, принимают платежи в NEON и совершают платежи в экосистеме Solana в SOL. NEON одновременно служит утилитарным токеном и токеном управления: операторы Neon получают его для оплаты комиссий за газ, необходимых для выполнения транзакций, а владельцы могут участвовать в Neon DAO.

Neon DAO — управляемая сообществом модель управления, которая дает владельцам токенов NEON возможность участвовать в принятии решений по Neon EVM. В нее входят пользователи, операторы, контрибьюторы, разработчики ядра и приложений, которые совместно обсуждают правила управления и развитие протокола. DAO работает через различные децентрализованные ассамблеи, отвечающие за экосистему, разработку и безопасность. Каждая ассамблея обеспечивает совместное принятие решений и рассмотрение предложений в своей области. Ассамблея по экосистеме контролирует ее устойчивый рост и управляет средствами для грантов и инициатив. Ассамблея по разработке отвечает за технические обновления программы Neon и экстренные вмешательства. Ассамблея по безопасности защищает казначейство Neon и программу Neon от потенциальных угроз.

Совместимость с EVM

Neon EVM обеспечивает взаимодействие с EVM в Solana следующим образом:

• Реализует большинство методов Ethereum JSON-RPC API
• Использует специальный прокси-сервер для обработки вызовов Ethereum
• Учитывает различия и ограничения архитектуры Solana

Взаимодействие с Neon EVM аналогично работе с любой другой EVM. Разработчики могут направлять знакомые методы RPC API в Neon Proxy, что обеспечивает удобный и непрерывный процесс разработки. Ключевые возможности:

• Совместимость со смарт-контрактами на Solidity и Vyper, а также со стандартными инструментами разработки Ethereum, такими как Metamask, Foundry и Remix
• Полная поддержка большинства опкодов Ethereum
• Поддержка запросов транзакций Ethereum типа 0 / legacy. Транзакции EIP-1559 пока не поддерживаются

Разумеется, для корректной работы Neon EVM в Solana необходимы определенные адаптации. Основные различия:

• Neon EVM поддерживает все прекомпилированные контракты, определенные на evm.code. Однако контракты Solidity со следующими вызовами выполняться не будут: bigModExp, bn256Add, bn256ScalarMult и bn256Pairing. Для поддержки этих контрактов в будущем в Neon EVM необходимо реализовать системные вызовы Solana
• Хотя большинство опкодов поддерживается без изменений, опкоды COINBASE, PREVRANDAO (FKA DIFFICULTY), GASLIMIT, BASEFEE и GAS не поддерживаются. Они известны как вариативные опкоды и адаптированы для Neon EVM.
• Расход газа и расчет комиссий отличаются от Ethereum. Как правило, благодаря использованию Solana в качестве расчетного слоя затраты ниже
• Методы Solidity transfer() и send() в Neon EVM небезопасны с точки зрения повторного входа из-за различий в расчете газа
• Модель аккаунтов Solana влияет на хранение данных смарт-контрактов: исполняемые и неисполняемые аккаунты имеют разные возможности хранения и права доступа
• Neon EVM использует версионированные транзакции, поэтому максимальное количество аккаунтов в одной транзакции ограничено 64
• Neon EVM использует фильтр пакетов Беркли (BPF) из Solana с ограничением heap-памяти в 256 КБ. Это ограничивает размер вызовов контрактов и требует применять стратегии оптимизации для эффективного управления памятью
• Функции, связанные со временем, например block.number и block.timestamp, ведут себя иначе. Разработчикам настоятельно не рекомендуется использовать их при разработке для Neon EVM

Хотя Neon EVM предоставляет знакомую и совместимую среду, для успешной миграции и разработки в Solana разработчики EVM должны знать основные различия и учитывать их.

Подключение к Neon RPC

Разработчики могут легко подключиться к Neon RPC с помощью Chainlist. Здесь можно подключиться к Neon EVM Mainnet или Devnet. Нажмите Подключить кошелек в модальном окне Mainnet или Devnet, а затем Подтвердить, когда откроется ваш кошелек.

Перед отправкой транзакций в Neon EVM пользователям следует выбрать оптимального оператора. Разверните сведения на карточке, чтобы увидеть доступные конечные точки RPC для каждой сети:

Если вы выберете оператора, отличного от предложенного по умолчанию при подключении кошелька, потребуется подключиться вручную. В документации Neon EVM есть подробные руководства по подключению к Proxy с помощью Foundry, Hardhat, Remix и Truffle. В разделе о развертывании мы рассмотрим подключение через Foundry.

После подключения разработчики могут получить NEON или другие тестовые токены ERC-20 через Neon Faucet. Также токены можно запросить программно через конечную точку request_neon:

curl -i -X POST \
	-d '{"wallet": "Your wallet", "amount": 1}' \
	'http://localhost:3333/request_neon'

Эта команда отправляет POST-запрос на получение токенов по указанному адресу кошелька.

Жизненный цикл транзакции и комиссии за газ

Выполнение транзакции из dApp Ethereum в Solana через Neon EVM включает три основных этапа:

• Пользователь инициирует подписанную транзакцию, подобную Ethereum, и направляет ее в конечную точку Neon RPC
• Транзакция передается в Neon Proxy через Ethereum API. Proxy оценивает объем газа, необходимый для выполнения транзакции, инициирует рассылку, упаковывая подобную Ethereum транзакцию в транзакцию Solana, и отправляет упакованную транзакцию в Neon EVM. В результате формируются квитанция Solana и соответствующая квитанция транзакции Neon EVM. Смарт-контракт Neon распаковывает транзакцию, проверяет подпись пользователя и загружает состояние EVM из хранилища Solana. Транзакция выполняется внутри BPF Solana
• Solana и Neon EVM обновляют свои состояния и завершают обработку запроса транзакции

Это полный жизненный цикл транзакции в Neon EVM — от инициации до выполнения. Разработчики могут посетить NeonScan, чтобы просмотреть последние транзакции и блоки, а также найти аккаунты, токены, блоки или хеши транзакций.

Разработчики также могут отправлять транзакции без газа. Эта возможность создана для пользователей, у которых недостаточно токенов NEON для оплаты комиссий за первые транзакции. Разработчики могут получить стартовый пакет транзакций без газа, обратившись по адресу info@neonevm.org. Выбранный разработчиком оператор Proxy по-прежнему обрабатывает эти транзакции, однако их стоимость оплачивает Neon. Обычно каждому новому аккаунту Neon предоставляется минимум три транзакции без газа.

Процесс выполнения транзакций без газа выглядит так:

• Конечный пользователь инициирует транзакцию через dApp
• dApp запрашивает текущую цену газа у выбранного оператора Proxy. Если аккаунт соответствует требованиям, оператор Proxy помечает аккаунт Neon для выполнения указанного количества транзакций без газа
• Для этих транзакций dApp покажет нулевую стоимость газа
• Конечный пользователь подписывает транзакцию без комиссии за газ
• Оператор Proxy выполняет транзакцию, а комиссию за газ в SOL оплачивает Neon Foundation

В документации Neon EVM приведен следующий фрагмент, демонстрирующий запрос транзакции без газа:

try {
	// Get gasless transaction if user account is eligible
  const rawGasPrice = await axios.post(rpcApiUrl, {
  	method: 'neon_gasPrice',
    params: [{ from: address }],
    jsonrpc: "2.0",
    id: new Date().getTime()
   })

   tx.gasPrice = rawGasPrice.data?.result;
	} catch (e) {
  	//Else, get standard GAS price
   	setError('Can\'t retrieve gas price for transaction')

    const rawGasPrice = await web3.eth.getGasPrice();

    tx.gasPrice = web3.utils.toHex(rawGasPrice);
} finally {
    setTx(tx)
}

NeonPass

NeonPass — инструмент для передачи токенов между Solana и Neon EVM. Он обеспечивает беспрепятственную передачу активов между ассоциированными аккаунтами токенов Solana и аккаунтами токенов ERC-20 в Neon EVM. NeonPass использует интерфейсный контракт Neon EVM и специализированное хранилище аккаунтов. Токены Solana Program Library (SPL) упаковываются в интерфейс ERC-20 внутри фабричного контракта Neon EVM. Это позволяет хранить SPL-токены в аккаунтах токенов ERC-20, совместимых с dApp на Solidity. NeonPass обеспечивает двустороннюю передачу токенов между аккаунтами Solana и Neon EVM. В отличие от традиционных мостов, которые блокируют активы и выпускают новые, он напрямую перемещает токены между двумя типами аккаунтов. Это обеспечивает беспрепятственное перемещение токенов Solana и Neon EVM.

Развертывание

Разработчики могут развертывать проекты в Neon EVM с помощью Hardhat, Foundry, Truffle и Remix. Поскольку проще всего использовать Solang через Anchor, все тесты написаны на TypeScript. Однако теперь все преданные поклонники Solidity наконец могут тестировать и развертывать dApp на Solidity в Solana через Foundry.

Сначала убедитесь, что у вас есть совместимый с EVM кошелек, подключенный к Neon EVM Devnet. Затем клонируйте пример проекта Neon для Foundry и перейдите в его каталог:

git clone https://github.com/neonlabsorg/neon-tutorials
cd neon-tutorials/foundry

Затем установите Foundryup, установщик набора инструментов Foundry, и выполните foundryup, чтобы установить последние ночные предварительно скомпилированные бинарные файлы (то есть force, cast, anvil и chisel):

curl -L https://foundry.paradigm.xyz | bash
foundryup

Установите необходимые библиотеки:

forge install foundry-rs/forge-std --no-commit
forge install openzeppelin/openzeppelin-contracts --no-commit

Теперь получите приватный ключ аккаунта кошелька. Например, в Metamask можно просмотреть приватный ключ, нажав меню-гамбургер и перейдя в Account Details > Show Private Key. Вам будет предложено ввести пароль. Нажмите Подтвердить, чтобы получить доступ к приватному ключу аккаунта. Никому не сообщайте этот ключ и примите необходимые меры для его защиты.

Затем создайте файл .env со следующими переменными:

RPC_URL_DEVNET=https://devnet.neonevm.org
CHAIN_ID_DEVNET=245022926
RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
CHAIN_ID_MAINNET=245022934
PRIVATE_KEY=
VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api

Замените <YOUR_PRIVATE_KEY> своим приватным ключом и выполните source .env.

Чтобы скомпилировать контракты проекта, перейдите в каталог src и выполните forge build. В консоли должно появиться сообщение об успешной работе компилятора. Контракты также можно протестировать командой forge test. Чтобы развернуть контракт проекта, выполните следующую команду:

forge create --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY src/TestERC20/TestERC20.sol:TestERC20 --constructor-args "Test ERC20 Token" "TERC20" --legacy

Вы должны увидеть примерно такой вывод:

[⠰] Compiling...
No files changed, compilation skipped
Deployer: 0x4455E84Eaa56a01676365D4f86348B311969a4f4
Deployed to: 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9
Transaction hash: 0x6de9dab8a526cbac33008056d185b93dff725605efb791bf116b6bece4f0c486

Чтобы проверить контракт, выполните следующую команду:

forge verify-contract --chain-id $CHAIN_ID_DEVNET  src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout

Замените <contract_address> адресом своего смарт-контракта. Вы должны получить ответ OK с URL, ведущим на адрес контракта в BlockScout — обозревателе Devnet от Neon. Также можно настроить файл .env для использования NeonScan вместо BlockScout. NeonScan тоже поддерживает devnet.

Преимущества и ограничения

Разработчикам, которым нужен процесс разработки, похожий на Ethereum, стоит выбрать Neon EVM. Это совместимая с EVM среда, которая отправляет подобные Ethereum транзакции и позволяет использовать знакомые инструменты. Такие возможности, как NeonPass, поддержка большинства опкодов EVM и транзакции без газа, значительно упрощают переход на Solana. Однако Neon EVM не идеальна. У нее есть определенные ограничения: необходимость менять логику смарт-контрактов для адаптации к инфраструктуре Solana, работа в рамках ограничений фильтра пакетов Беркли (BFP) и моделей аккаунтов Solana, а также ограничения некоторых опкодов и прекомпилированных контрактов. Понимание и учет этих нюансов необходимы для успешного развертывания в Solana из совместимой с EVM среды.

Предыдущие миграции

Чтобы крупный протокол Ethereum можно было развернуть в сети, отличной от EVM, необходимо решить несколько сложных задач. В частности, найти инженеров, не работающих с Solidity, чтобы переписать кодовую базу с нуля, привлечь надежных партнеров для аудита, повторно проверить новую кодовую базу и адаптировать контракты управления для исполнения решений DAO. Это может стоить миллионы долларов и потребовать нескольких месяцев напряженной работы. Для большинства проектов такой вариант нереалистичен. Однако подобные миграции уже происходили.

Helium — это сеть LoRaWAN, цель которой — создать децентрализованную беспроводную инфраструктуру для поддержки устройств интернета вещей (IoT). Для этого используются хот-споты — небольшие энергоэффективные устройства, похожие на миниатюрные вышки сотовой связи, которые подключаются к другим хот-спотам на больших расстояниях. Изначально Helium работал в собственном блокчейне уровня 1 (L1), но команда разработчиков предложила перейти на Solana в рамках HIP 70. Переход позволил бы Helium повысить доступность, улучшить компонуемость и ускорить работу для пользователей, сохранив высокий уровень безопасности и низкую стоимость использования. Сообщество подавляющим большинством поддержало предложение, и в апреле 2023 года Helium перешел на Solana. Операционный директор Helium Скотт Сигел назвал миграцию скучным событием — ни в сети, ни в инфраструктуре Helium не возникло никаких проблем. Это была мечта инженера. Команда также подробно описала весь процесс миграции в серии руководств в своей документации. Миграция Helium прошла чрезвычайно успешно и принесла сообществу значительную пользу.

Эта миграция — не единичный случай. The Render Network, первая в мире децентрализованная платформа рендеринга на GPU, в ноябре 2023 года успешно перенесла свою основную инфраструктуру с Ethereum на Solana. Сообщество проголосовало за RNP-002, одобрив миграцию на Solana. Основатель Render Джулс Урбах назвал миграцию переломным моментом. Он заявил: «Невероятная скорость транзакций Solana, низкие издержки и ориентация на архитектуру веб-масштаба делают ее идеальным выбором для Render Network, пока мы продолжаем создавать масштабируемую и децентрализованную инфраструктуру метавселенной».

Миграция Render не оказала существенного негативного влияния на пользователей. Они могут перевести средства из Ethereum в Solana с помощью помощника по обновлению Render. Пользователь подключает свой кошелек Ethereum, указывает количество RNDR для миграции и ждет, пока токены поступят на указанный кошелек Solana. 

Maker — один из наиболее характерных проектов Ethereum. Его цель — раскрыть потенциал децентрализованных финансов с помощью Maker Platform, инклюзивной платформы, призванной расширить экономические возможности и обеспечить равный доступ к мировому финансовому рынку. Платформа состоит из MakerDAO, который управляет проектом Maker, и протокола Maker для DAI — «первой в мире непредвзятой валюты и ведущего децентрализованного стейблкоина». Основатель Maker Руне Кристенсен опубликовал пост об использовании форка кодовой базы Solana для разработки аппчейна Maker: 

Миграции по своей природе сложны. Несмотря на финансовые, репутационные и временные издержки переноса всей инфраструктуры проекта с Ethereum на Solana, проекты выбирают Solana. Благодаря таким инструментам, как Solang и Neon EVM, миграции не обязательно должны быть сложными. Как показали Helium и Render Network, миграция может пройти без происшествий и практически не повлиять на средства пользователей. Solana — самый производительный блокчейн на рынке, созданный для веб-масштаба. Именно здесь стоит создавать проекты, и это понимает все больше команд.

Заключение

Solidity — это lingua franca разработки смарт-контрактов. С момента своего появления EVM остается доминирующей средой для смарт-контрактов. Однако у нее есть недостатки. Пользовательским приложениям веб-масштаба нужна сеть с высокой пропускной способностью и низкой задержкой. Однопоточная среда Ethereum с нестабильной стоимостью газа не способна поддерживать проекты децентрализованных сетей физической инфраструктуры (DePIN) с высокой пропускной способностью, такие как Helium. 

На фоне этих проблем Solana становится мощной альтернативой. Лучший способ воспользоваться реальными преимуществами Solana — создавать непосредственно на Solana. Благодаря последним разработкам такие инструменты, как Solang и Neon EVM, позволяют заинтересованным EVM-разработчикам выполнить миграцию с помощью знакомых инструментов и языков. Эта статья подробно рассказывает об архитектуре Solana, сравнивает ее с Ethereum и объясняет, как EVM-разработчик может начать разработку на Solana. Solana — самый производительный блокчейн на рынке. Он набирает популярность и привлекает внимание, а в его экосистеме появляется все больше надежных пользовательских приложений. Зачем ждать масштабирования Ethereum, если преимуществами быстрого и масштабируемого блокчейна можно пользоваться уже сегодня?

Если вы дочитали до этого места, спасибо, анон! Укажите свой адрес электронной почты ниже, чтобы не пропускать новости Solana. Готовы погрузиться глубже? Присоединяйтесь к нашему Discord и начните уже сегодня создавать будущее на самом производительном блокчейне.

Дополнительные ресурсы

• Оценка Solana для корпоративного использования: подробное руководство
• Neon EVM
• Документация Solang для Solana
• Книга по Rust
• Модель программирования Solana: введение в разработку на Solana
• Tower BFT: высокопроизводительная реализация PBFT в Solana
• Что такое SVM — виртуальная машина Solana