Embark Framework

Что такое Embark Framework?

Embark Framework — это фреймворк с открытым исходным кодом, созданный для помощи разработчикам в создании, тестировании, развертывании и управлении децентрализованными приложениями.

Он предназначен главным образом для приложений, использующих смарт-контракты для Ethereum Virtual Machine, браузерные интерфейсы, децентрализованные хранилища и технологии однорангового взаимодействия.

В официальном репозитории Embark Framework он описан как фреймворк для разработки и развертывания децентрализованных приложений.

Embark автоматизировал многие задачи, которые разработчикам иначе пришлось бы выполнять вручную.

К ним относились компиляция смарт-контрактов, определение порядка развертывания, развертывание контрактов, отслеживание адресов развернутых контрактов, повторная генерация артефактов фронтенда, запуск тестов, запуск локальных блокчейн-сервисов и публикация файлов приложения.

Embark был примечателен тем, что пытался управлять всем стеком децентрализованного приложения, а не только компиляцией смарт-контрактов.

Проект на Embark мог объединять блокчейн-контракты, JavaScript-код приложения, децентрализованное файловое хранилище, сервисы именования и децентрализованный обмен сообщениями в рамках одного рабочего процесса, управляемого конфигурацией.

Embark был важным инструментом для разработки приложений на Ethereum в период раннего роста децентрализованных приложений.

Однако последний стабильный релиз вышел в апреле 2020 года, поэтому сейчас разработчикам следует считать Embark устаревшим ПО, для работы с которым может потребоваться масштабная проверка совместимости и безопасности.

Для чего был создан Embark?

Embark был создан, чтобы сократить объем работ по настройке и координации компонентов при разработке децентрализованных приложений.

Децентрализованное приложение часто состоит из нескольких компонентов, которые должны корректно взаимодействовать друг с другом.

В него могут входить контракты Solidity, узел блокчейна, скрипты развертывания контрактов, сгенерированные ABI, JavaScript-библиотеки, веб-интерфейс, децентрализованное хранилище, тесты и конфигурация для конкретной сети.

Без фреймворка разработчикам приходится настраивать и связывать каждый компонент самостоятельно.

Embark стремился предоставить единую среду, которая учитывала бы эти компоненты и обновляла их по мере изменения проекта.

Например, после изменения контракта Solidity Embark мог заново скомпилировать его, определить, требуется ли повторное развертывание, обновить адрес контракта, повторно сгенерировать артефакты фронтенда и пересобрать приложение.

Этот автоматизированный процесс был призван ускорить циклы разработки и сократить количество ошибок при ручной настройке.

Поддерживается ли Embark Framework сейчас?

Embark следует считать устаревшим фреймворком для разработки криптовалютных приложений, а не активно поддерживаемым решением для новых производственных проектов.

В официальном репозитории версия 6.0.0, выпущенная 27 апреля 2020 года, указана как последний стабильный релиз.

В официальном журнале изменений также указаны две последующие ночные сборки от 8 августа 2020 года и 8 октября 2020 года.

В общедоступной карточке пакета Embark также видно, что основной пакет давно не получал стабильных обновлений.

В актуальном руководстве Ethereum по фреймворкам для разработки объясняется роль полнофункциональных фреймворков, однако Embark больше не входит в список рекомендуемых решений.

Отсутствие новых релизов означает, что старые зависимости, системы сборки, клиенты блокчейна, JavaScript API и сетевые параметры могут работать некорректно или небезопасно на современном компьютере для разработки.

В существующих проектах на Embark по-прежнему могут быть полезные фрагменты кода, контракты, тесты и история развертывания.

Однако командам, которые поддерживают такие проекты, следует провести аудит всех зависимостей и рассмотреть возможность переноса критически важных процессов на активно поддерживаемые компоненты.

Кто создал Embark?

Первоначально Embark создал разработчик Иури Матиас, а позднее проект развивала более широкая команда участников с открытым исходным кодом.

По мере изменения состава сопровождающих и организационной поддержки проект переходил между организациями GitHub.

Сейчас основной общедоступный исходный код находится в организации Embark Labs на GitHub.

В репозитории — тысячи исторических коммитов и множество модульных пакетов для взаимодействия с блокчейном, развертывания, тестирования, хранения данных, коммуникации, генерации кода и разработки пользовательских интерфейсов.

Embark распространялся по лицензии MIT, которая разрешает разработчикам изучать, изменять и распространять код с соблюдением условий лицензии.

Что такое фреймворк для разработки dApp?

Фреймворк для разработки децентрализованных приложений — это набор инструментов, координирующих типовые задачи разработки в блокчейне.

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

Фреймворк не заменяет знания о смарт-контрактах и безопасности блокчейна.

Он автоматизирует отдельные этапы разработки.

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

Использование фреймворка может повысить производительность, но также добавляет зависимости и предположения, связанные с конкретным фреймворком.

Что означал термин serverless в Embark?

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

В данном контексте serverless не обязательно означал, что серверов или компьютеров вообще нет.

Узлы блокчейна, участники сети хранения данных, шлюзы, сервисы кошельков и инфраструктура доставки веб-контента все равно должны где-то работать.

Этот термин означал, что приложение могло меньше зависеть от одного традиционного сервера, контролируемого единственным оператором.

Смарт-контракты могли содержать общую логику приложения и его состояние.

Децентрализованное хранилище могло распределять файлы между участвующими узлами.

Статический фронтенд мог напрямую взаимодействовать с блокчейном или сервисами хранения через браузер пользователя.

Во многих реальных приложениях по-прежнему использовались централизованные сервисы для индексации, аналитики, уведомлений, поддержки пользователей, кэширования, аутентификации или ускоренной доставки данных.

Управление смарт-контрактами в Embark

Управление смарт-контрактами было одной из ключевых функций Embark.

Фреймворк мог находить исходные файлы контрактов, компилировать их, определять зависимости и развертывать контракты в настроенной сети EVM.

Он отслеживал уже развернутые контракты и старался избегать ненужного повторного развертывания.

Если одному контракту был нужен адрес другого, Embark мог установить порядок развертывания и передать требуемый адрес зависимому контракту.

Это было полезно для приложений с токен-контрактами, реестрами, контрактами контроля доступа, фабриками, библиотеками и другими связанными компонентами.

Система также создавала артефакты контрактов, которые JavaScript-код мог использовать для вызова развернутых контрактов.

Автоматизация развертывания сокращала объем повторяющейся работы, но разработчикам все равно нужно было проверять аргументы конструктора, привилегированные адреса, идентификаторы сетей, настройки газа и аккаунты для развертывания.

Автоматическое повторное развертывание контрактов

Embark мог отслеживать изменения файлов смарт-контрактов во время работы среды разработки.

При изменении контракта фреймворк мог повторно скомпилировать его и определить, требуется ли новое развертывание.

Затем он мог обновить артефакты приложения и пересобрать фронтенд.

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

Автоматическое повторное развертывание было удобно преимущественно в локальных или временных сетях разработки.

Повторное развертывание производственного контракта создает новый адрес и не переносит автоматически состояние или активы исходного контракта.

Разработчикам нельзя считать повторное развертывание производственного контракта простым обновлением веб-приложения.

Для неизменяемых контрактов и обновляемых систем требуются разные процедуры миграции, управления и обеспечения безопасности.

Конфигурация контрактов

В проектах Embark использовались конфигурационные файлы, описывавшие контракты и параметры развертывания.

В конфигурации можно было указать, следует ли развертывать контракт, какие аргументы конструктора ему нужны, какой аккаунт должен его развернуть и от каких других контрактов он зависит.

Для локальной разработки, приватных сетей, общедоступных тестовых сред и производственных сетей можно было использовать отдельные конфигурации окружений.

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

Однако конфигурационные файлы могли представлять угрозу, если содержали приватные ключи, фразы восстановления, пароли или неограниченно доступные удаленные конечные точки.

Конфиденциальные учетные данные нельзя добавлять в общедоступный репозиторий исходного кода.

EmbarkJS

EmbarkJS — это слой интеграции с JavaScript, использовавшийся во фронтенд-приложениях, созданных с помощью Embark.

Он предоставлял браузерному коду доступ к развернутым смарт-контрактам и другим настроенным децентрализованным сервисам.

Embark генерировал объекты контрактов на основе скомпилированных ABI и адресов развернутых контрактов.

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

EmbarkJS также предоставлял модули для интеграции с хранилищами, сервисами коммуникации и именования, если соответствующие функции были включены.

Сгенерированные объекты сокращали объем ручной работы по управлению адресами и ABI.

Однако фронтенд по-прежнему должен был обрабатывать доступ к аккаунту, выбор сети, подтверждение транзакций, отклоненные подписи, отмененные транзакции и изменения состояния блокчейна.

Промисы JavaScript и асинхронные операции

Многие операции с контрактами в Embark предоставлялись через промисы JavaScript.

Это соответствовало асинхронному характеру разработки блокчейн-приложений.

Для вызова контракта может потребоваться RPC-запрос к удаленному узлу.

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

Разработчикам нужно было различать отправленную транзакцию и успешно исполненную транзакцию с достаточным количеством подтверждений.

Успешное выполнение промиса отправки не всегда означало, что запрошенное действие контракта завершилось успешно.

Приложения должны были проверять квитанции, статус исполнения, сгенерированные события и сведения об ошибках.

Embark и сети EVM

Embark был предназначен главным образом для Ethereum и других блокчейнов, совместимых с Ethereum Virtual Machine.

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

Embark мог подключаться к локальным узлам, приватным сетям, тестовым средам или публичным сетям через настроенные провайдеры.

Для взаимодействия с узлами блокчейна использовались совместимые с Ethereum методы JSON-RPC.

В документации Ethereum по JSON-RPC описан стандартный интерфейс запросов, который приложения используют для получения данных от узлов и отправки транзакций.

Фреймворк может поддерживать интерфейс RPC, но при этом оставаться несовместимым с новыми типами транзакций, рынками комиссий, версиями компиляторов, параметрами клиентов или поведением сети.

Локальная разработка для блокчейна

Embark мог запускать локальную среду блокчейна для разработки и тестирования или подключаться к ней.

Локальная сеть позволяла быстро развертывать контракты без расходования активов в публичной сети.

В ней могли быть тестовые аккаунты с симулированными балансами и более быстрым созданием блоков.

Локальная разработка помогала проверять логику контрактов, интеграцию с фронтендом, порядок развертывания и последовательность транзакций.

Локальный блокчейн не воспроизводил все условия публичной сети.

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

Для производственных систем требовалось дополнительное тестирование в реалистичных средах и условиях.

Тестирование в Embark

Embark поддерживал разработку смарт-контрактов на основе тестирования с использованием JavaScript.

Разработчики могли создавать тесты, которые развертывали контракты, вызывали функции, отправляли транзакции и проверяли итоговое состояние.

Фреймворк управлял тестовыми аккаунтами и мог сбрасывать или инициализировать блокчейн разработки перед запуском тестов.

Тесты контрактов могли проверять поведение при развертывании, контроль доступа, балансы токенов, события, отмененные транзакции и взаимодействие между контрактами.

Автоматизированные тесты были одной из самых ценных функций Embark, поскольку ошибки смарт-контрактов после развертывания могут стать необратимыми.

Успешное прохождение тестов не доказывает безопасность контракта.

Тесты охватывают только те сценарии и предположения, которые учел разработчик.

Что следует проверять в тестах смарт-контрактов?

Надежный набор тестов должен охватывать ожидаемое поведение пользователей и намеренно враждебные сценарии.

Следует проверять вызовы от авторизованных и неавторизованных пользователей.

Нужно проверять нулевые и максимальные значения, повторные вызовы, неожиданный порядок действий, недопустимые адреса, неудачные внешние вызовы и граничные условия.

Следует убедиться, что изменения состояния остаются корректными, если транзакция отменяется.

Если контракт отправляет активы или вызывает ненадежные контракты, необходимо проверить возможность повторного входа.

Следует тестировать административные функции, способы обновления, механизмы приостановки, аварийный вывод средств и передачу права собственности.

В руководстве Solidity по безопасности описаны распространенные риски, в том числе повторный вход, циклы с ограниченным газом, авторизованные прокси, конфиденциальная информация и внешние вызовы.

Артефакты контрактов Embark

Артефакт контракта — это сгенерированный файл с информацией, необходимой для развертывания смарт-контракта или взаимодействия с ним.

Он может содержать ABI контракта, байт-код, развернутый адрес, сведения о сети, результаты компиляции и ссылки на исходный код.

Embark создавал артефакты, чтобы фронтенд и тестовый код могли обращаться к контрактам без ручного копирования их адресов и интерфейсов.

Артефакты должны были соответствовать целевой сети развертывания.

Если использовать адрес из другой сети, приложение может вызвать посторонний контракт или адрес, по которому нет кода.

Производственным приложениям следует проверять chain ID блокчейна и байт-код контракта, а не полагаться только на локальный файл артефакта.

Конвейер сборки Embark

В Embark был предусмотрен конвейер сборки для подготовки фронтенд-файлов децентрализованного приложения.

Он мог копировать, преобразовывать или объединять JavaScript-файлы, HTML, таблицы стилей, изображения и сгенерированные артефакты блокчейна.

Конвейер мог работать с распространенными инструментами веб-разработки и фронтенд-библиотеками, не требуя использования одной конкретной технологии пользовательского интерфейса.

Такая гибкость позволяла разработчикам продолжать применять привычные методы разработки для браузера и добавлять интеграции с блокчейном.

Конвейеры сборки создают риски для цепочки поставок программного обеспечения, поскольку во время установки или компиляции выполняют пакеты и скрипты.

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

Embark Cockpit

В Embark был графический интерфейс разработки, обычно называемый Cockpit.

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

В нем могли отображаться контракты, транзакции, журналы, процессы, сервисы и статус разработки.

Интерфейс также включал инструменты для взаимодействия с контрактами и изучения активности во время разработки.

Визуальная панель могла упростить работу с фреймворком по сравнению с использованием множества отдельных окон командной строки.

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

Исторические компоненты Cockpit сегодня может быть особенно трудно запустить из-за изменений фронтенд-зависимостей и поведения браузеров после выхода последних релизов.

Консоль Embark

Консоль Embark предоставляла интерактивную командную среду, подключенную к настроенному проекту и сети блокчейна.

Разработчики могли просматривать аккаунты, обращаться к сгенерированным объектам контрактов, вызывать функции чтения и отправлять транзакции.

Интерактивная консоль была полезна для отладки и ручного тестирования.

Но при подключении к производственному аккаунту со значительными активами она также представляла опасность.

Команды могли развертывать контракты, изменять состояние, переводить активы или выдавать разрешения.

Нельзя раскрывать приватные ключи и разблокированные аккаунты через незащищенную консоль или общедоступную конечную точку RPC.

Embark и децентрализованное хранилище

Embark интегрировался с децентрализованными системами хранения, чтобы приложения могли загружать, получать и публиковать файлы вне блокчейна.

Хранить большие файлы приложения непосредственно в хранилище контрактов EVM обычно дорого.

Децентрализованная сеть хранения может содержать файлы фронтенда, изображения, метаданные, документы и другой контент, а блокчейн — хранить ссылку или идентификатор контента.

EmbarkJS предоставлял общий интерфейс приложения для поддерживаемых сервисов хранения.

Embark также мог развернуть статический фронтенд приложения через децентрализованное хранилище.

Это уменьшало зависимость от одного традиционного веб-сервера, но не гарантировало, что контент останется доступным навсегда.

Embark и IPFS

IPFS был одной из основных интеграций Embark для децентрализованного хранения.

IPFS использует адресацию по содержимому: файл идентифицируется криптографическим описанием его содержимого, а не только расположением на сервере.

В официальной документации IPFS объясняется, как идентификаторы содержимого позволяют запрашивать данные на основе содержащейся в них информации.

При изменении файла обычно создается другой идентификатор содержимого.

Это помогает пользователям обнаруживать изменения в контенте.

Однако доступность данных не гарантируется автоматически: хотя бы один доступный участник сети должен продолжать хранить их и предоставлять к ним доступ.

Для важных файлов приложения проектам нужен план закрепления, репликации или длительного хранения.

Embark и Swarm

Embark также включал историческую поддержку хранения и развертывания приложений на базе Swarm.

Фреймворк мог публиковать файлы фронтенда и получать исходный код контрактов или содержимое приложений через поддерживаемые интеграции с хранилищами.

С момента последнего стабильного релиза Embark API хранилищ и поведение сетей изменились.

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

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

Децентрализованная коммуникация

В Embark были интеграции с децентрализованными системами коммуникации или однорангового взаимодействия.

В документации проекта упоминались Whisper и Orbit как поддерживаемые технологии коммуникации.

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

Слой коммуникации мог использоваться для уведомлений, чатов, координации или обмена данными приложения.

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

Исторические интеграции для коммуникации могут больше не работать с актуальным сетевым ПО.

Плагины Embark

В Embark использовалась модульная архитектура плагинов для расширения основных функций.

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

Система плагинов повышала гибкость фреймворка: разработчикам не приходилось изменять основной проект для подключения каждого нового сервиса.

Однако плагины также повышали риски для цепочки поставок и совместимости.

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

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

Команды Embark

Embark предоставлял команды командной строки для создания, запуска, тестирования и сборки проектов, а также взаимодействия с ними.

Историческая команда установки:

.

Команда

могла создать пример децентрализованного приложения.

Команда

запускала настроенные сервисы разработки и отслеживала изменения проекта.

Команда

запускала тесты смарт-контрактов.

Команда

подготавливала файлы приложения к развертыванию.

Команда

открывала интерактивную среду, подключенную к выбранной конфигурации.

Эти исторические команды могут не работать на современных операционных системах или в актуальных средах выполнения пакетов, поскольку ПО и его зависимости устарели.

Настройка окружений Embark

В проекте Embark можно было настроить разные окружения для разных блокчейн-сетей.

В локальном окружении могли использоваться автоматически созданные аккаунты и симулированный блокчейн.

Публичная тестовая среда могла подключаться к удаленному узлу и развертывать контракты через пополненный тестовый аккаунт.

В производственной среде могли применяться более строгие правила подписания, фиксированные адреса контрактов и тщательно проверенные настройки газа.

Разделение окружений снижало риск случайного использования тестовой конфигурации в производственной среде.

Однако одни лишь названия окружений не обеспечивали безопасность.

В скриптах развертывания по-прежнему требовались явные проверки chain ID и безопасные процедуры управления ключами.

Embark и зависимости контрактов

В крупных децентрализованных приложениях часто есть контракты, зависящие от других контрактов.

Конструктору могут потребоваться адрес токена, реестра, библиотеки, администратора или оракула.

В конфигурации развертывания Embark можно было указывать ссылки на другие контракты и получать адреса уже развернутых контрактов.

На основе этих сведений о зависимостях Embark мог определить правильный порядок развертывания.

Автоматизация работы с зависимостями избавляла от ручного копирования, но могла скрывать важные связи доверия.

Разработчикам все равно нужно было убедиться, что используется именно нужная версия контракта и что его разрешения соответствуют модели безопасности приложения.

Embark и именование приложений

В Embark были исторические интеграции с децентрализованными системами именования.

Система именования может сопоставлять удобочитаемое имя с аккаунтом, контрактом, идентификатором содержимого или другим ресурсом блокчейна.

Это повышает удобство: пользователям не нужно вводить длинные шестнадцатеричные адреса.

Срок действия имен может истечь, имя можно передать другому владельцу, направить на новый адрес или потерять из-за компрометации аккаунта.

Приложению не следует считать удобочитаемое имя постоянным подтверждением подлинности контракта.

Для операций с высокой стоимостью нужно проверять разрешенный адрес и сеть.

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

Embark предлагал единый рабочий процесс для контрактов, фронтенд-кода, тестирования, развертывания, хранения данных и коммуникации.

Он автоматически генерировал JavaScript-объекты контрактов и артефакты развертывания.

Фреймворк отслеживал исходные файлы и при необходимости пересобирал или повторно развертывал компоненты.

Он поддерживал управление зависимостями между несколькими контрактами.

В нем были локальные сети разработки и инструменты тестирования на JavaScript.

Для нескольких блокчейн-сред можно было использовать разные конфигурации.

Также были доступны визуальная панель и интерактивная консоль.

Кроме того, Embark помогал разработчикам понять, что децентрализованное приложение может использовать не только блокчейн.

Ограничения Embark Framework

Embark пытался координировать множество различных технологий, из-за чего фреймворк получился объемным и сложным.

Его работа зависела от многочисленных пакетов Node.js, клиентов блокчейна, компиляторов, инструментов хранения, фронтенд-библиотек и плагинов.

Изменение в любом крупном компоненте зависимости могло повлиять на всю среду разработки.

Автоматическое развертывание и генерация кода могли мешать начинающим разработчикам понимать, какие именно команды и транзакции выполняются.

Широкий набор функций также увеличивал время установки и усложнял устранение неполадок.

Отсутствие новых стабильных релизов теперь создает серьезные проблемы совместимости и риски для цепочки поставок программного обеспечения.

Почему устаревшие фреймворки для разработки создают риски безопасности

В старом фреймворке могут быть устаревшие зависимости с известными уязвимостями.

В его дереве зависимостей могут находиться пакеты, поддержка которых прекращена.

Скрипты установки могут использовать устаревшие реестры, загрузку исполняемых файлов или системные команды.

Фреймворк может не учитывать актуальное поведение компилятора Solidity или современные функции EVM.

Он может задавать небезопасные предположения о газе или использовать снятые с поддержки параметры узлов.

В старых фронтенд-библиотеках могут быть уязвимости браузера или проблемы совместимости с кошельками.

Успешная установка не доказывает безопасность получившейся среды разработки.

Риски для цепочки поставок программного обеспечения

При установке фреймворка разработки на JavaScript может выполняться код из множества прямых и транзитивных пакетов.

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

При отсутствии старых версий пакетов исторические lock-файлы могут разрешаться иначе.

Разработчикам следует устанавливать старые проекты в изолированной среде, не используя ценные приватные ключи.

Необходимо изучить lock-файл, контрольные суммы пакетов, скрипты установки и граф зависимостей.

Подписание для производственной среды должно быть отделено от ненадежной или недавно восстановленной среды сборки устаревшего проекта.

Безопасность приватных ключей

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

Хранение незашифрованного приватного ключа или фразы восстановления в конфигурации проекта создает серьезную угрозу безопасности.

Утечка данных из репозитория может раскрыть все активы, контролируемые этим ключом.

Вредоносная зависимость также может читать локальные конфигурационные файлы или переменные окружения.

Для производственного развертывания следует использовать контролируемый процесс подписания, ограничивать сумму активов и тщательно проверять транзакции.

Аккаунт для разработки нельзя повторно использовать в качестве долгосрочного казначейского или административного аккаунта.

Верификация смарт-контрактов

Развертывание контракта через Embark не доказывало автоматически, что опубликованный исходный код соответствует развернутому байт-коду.

Верификация контракта позволяет пользователям сравнить опубликованный исходный код и настройки компилятора с кодом в блокчейне.

Разработчикам следует сохранять точную версию компилятора, настройки оптимизатора, аргументы конструктора, библиотеки и исходные файлы, использованные при развертывании.

Воспроизвести сборки старого проекта может быть трудно, если старые двоичные файлы компилятора или зависимости исчезли.

Поэтому при поддержке проекта Embark важно обеспечивать воспроизводимость сборок и архивировать историю развертывания.

Переход с Embark

Для перехода с Embark необязательно повторно развертывать каждый смарт-контракт.

Команда может сохранить уже развернутые контракты, заменив локальные процессы компиляции, тестирования, развертывания и сборки фронтенда.

Сначала нужно составить перечень адресов контрактов, исходных файлов, ABI, настроек компилятора, аргументов конструкторов, библиотек и административных аккаунтов.

Затем нужно воспроизвести контракты в изолированной современной среде сборки.

По возможности тесты должны сравнивать новые артефакты с историческим байт-кодом развернутых контрактов.

После этого фронтенд-код можно обновить так, чтобы он загружал проверенные ABI и адреса без зависимости от сгенерированных артефактов Embark.

Повторное развертывание следует выполнять только при необходимости изменить сами контракты и после оценки рисков миграции.

Сохранение существующего проекта Embark

Команде, которая поддерживает старое приложение на Embark, следует архивировать полный репозиторий исходного кода и lock-файл.

Нужно зафиксировать необходимые версии Node.js и операционной системы, версию компилятора, клиент блокчейна, переменные окружения и поведение менеджера пакетов.

Образы контейнеров или виртуальных машин могут помочь сохранить воспроизводимую историческую среду.

Такие образы необходимо проверять и изолировать, поскольку вместе со средой сохраняются и ее уязвимости.

Критически важную информацию о контрактах следует документировать отдельно от фреймворка, чтобы разработчики могли взаимодействовать с ними, даже если Embark перестанет запускаться.

Адреса развертывания и роли администраторов следует проверять непосредственно в блокчейне.

Стоит ли начинать новый проект с Embark?

Как правило, в 2026 году разработчикам не следует выбирать Embark в качестве основы нового производственного приложения для работы с криптовалютами.

Стабильные версии фреймворка не выпускались с апреля 2020 года.

Документированные интеграции и зависимости Embark рассчитаны на более раннюю версию среды разработки Ethereum.

Для нового проекта нужны активно поддерживаемые инструменты, совместимые с актуальными версиями компиляторов, форматами транзакций, поведением сетей, методами тестирования и практиками безопасности.

Embark может по-прежнему быть полезен для исторических исследований, поддержки устаревших приложений, изучения ранних инструментов для dApp или извлечения повторно используемых контрактов и тестовых сценариев.

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

Историческое значение Embark

Embark помог сформировать концепцию полнофункционального фреймворка для децентрализованных приложений.

Он рассматривал смарт-контракты, фронтенд-код, хранилище, коммуникацию, тестирование, развертывание и инструменты разработчика как части одного приложения.

Это было важно в период, когда инструменты разработки для блокчейна были разрозненными и сложными в настройке.

Embark также сделал автоматическую генерацию артефактов контрактов и развертывание с учетом зависимостей доступными более широкому кругу JavaScript-разработчиков.

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

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

Пример рабочего процесса разработки в Embark

Предположим, разработчик хочет создать простое приложение для голосования на основе токенов.

Он может создать контракты Solidity для токена и правил голосования.

В конфигурации Embark можно описать токен-контракт и передать его развернутый адрес в контракт голосования.

Embark может запустить локальный блокчейн, скомпилировать оба контракта, развернуть их в нужном порядке и создать артефакты для фронтенда.

Браузерное приложение может использовать EmbarkJS для отображения балансов токенов и отправки транзакций голосования.

С помощью JavaScript-тестов можно проверить, что голосовать могут только подходящие держатели токенов и что один аккаунт не может проголосовать дважды.

Готовый фронтенд можно собрать и загрузить с помощью настроенной интеграции децентрализованного хранилища.

Перед развертыванием в публичной сети каждый этап этого процесса все равно требует проверки безопасности.

Распространенные ошибки при работе с Embark Framework

Одна из распространенных ошибок — считать Embark активно поддерживаемым проектом только потому, что его репозиторий доступен публично.

Другая ошибка — устанавливать старый глобальный пакет непосредственно на компьютер с ценными криптовалютными ключами.

Третья ошибка — считать автоматическое развертывание контрактов безопасным, не проверив аргументы конструктора и привилегированные аккаунты.

Четвертая ошибка — предполагать, что локальные тесты воспроизводят все условия публичной сети.

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

Шестая ошибка — считать, что децентрализованное хранилище гарантирует постоянную доступность файлов.

Седьмая ошибка — путать успешную отправку транзакции с успешным выполнением смарт-контракта.

Восьмая ошибка — использовать сгенерированные артефакты из другой сети блокчейна.

Девятая ошибка — переходить на другие инструменты сборки, не проверив, соответствует ли новый байт-код историческим контрактам.

Десятая ошибка — повторно развертывать производственный контракт без плана переноса пользователей, активов, разрешений и состояния приложения.

FAQ

Что такое Embark Framework?

Embark Framework — это устаревший инструмент с открытым исходным кодом для разработки, тестирования, развертывания и управления децентрализованными приложениями, совместимыми с Ethereum.

Какие языки программирования использовал Embark?

Embark работал главным образом со смарт-контрактами Solidity и кодом приложений на JavaScript или TypeScript.

Какие блокчейны поддерживал Embark?

Он был предназначен преимущественно для Ethereum и других сетей, совместимых с Ethereum Virtual Machine и интерфейсами JSON-RPC в стиле Ethereum.

Embark Framework все еще развивается?

Стабильных релизов фреймворка не было с выхода версии 6.0.0 от 27 апреля 2020 года, поэтому его следует считать устаревшим ПО.

Какая версия Embark была последней стабильной?

В официальном репозитории версия 6.0.0 указана как последний стабильный релиз.

Выходили ли версии после 6.0.0?

В официальном журнале изменений указаны две ночные сборки 6.0.1 за август и октябрь 2020 года, но более поздних стабильных релизов не было.

Какие задачи автоматизировал Embark?

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

Что такое EmbarkJS?

EmbarkJS — это слой интеграции с JavaScript, который предоставлял коду приложения доступ к настроенным смарт-контрактам, хранилищам, средствам коммуникации и связанным сервисам.

Что такое Embark Cockpit?

Cockpit — графическая панель разработки Embark для просмотра контрактов, транзакций, сервисов, журналов и активности проекта.

Мог ли Embark запускать локальный блокчейн?

Да. Он мог запускать локальную сеть разработки EVM или подключаться к ней для развертывания и тестирования контрактов.

Поддерживал ли Embark тестирование смарт-контрактов?

Да. Он поддерживал тесты контрактов на JavaScript и рабочие процессы разработки на основе тестирования.

Поддерживал ли Embark децентрализованное хранилище?

Да. В нем были исторические интеграции для хранения файлов на базе IPFS и Swarm и развертывания приложений.

Поддерживал ли Embark децентрализованный обмен сообщениями?

Да. В исторических версиях были интеграции с технологиями одноранговой коммуникации, такими как Whisper и Orbit.

Мог ли Embark развертывать несколько связанных контрактов?

Да. Он мог отслеживать зависимости между контрактами и развертывать их в порядке, позволяющем передавать необходимые адреса зависимым контрактам.

Поддерживал ли Embark фронтенд-фреймворки?

Да. Его веб-конвейер был рассчитан на работу с различными браузерными технологиями и процессами сборки.

Был ли Embark блокчейном?

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

Был ли Embark криптовалютой?

Нет. Это был фреймворк разработки с открытым исходным кодом, для работы которого не требовалась собственная криптовалюта.

Делал ли Embark смарт-контракты безопасными?

Нет. Он предоставлял инструменты для тестирования и разработки, но не мог гарантировать безопасность кода контрактов, разрешений или экономической логики.

Могут ли контракты Embark по-прежнему работать в блокчейне?

Да. Контракты, развернутые через Embark, могут продолжать работать независимо, если сеть и байт-код остаются доступными.

Нужен ли Embark для работы существующего контракта?

Нет. Развернутые контракты EVM выполняются блокчейном, и к ним можно обращаться через любой совместимый интерфейс, используя правильные адрес и ABI.

Может ли команда перейти с Embark, не перенося контракты?

Да. Команда может заменить локальный процесс сборки и развертывания, продолжая взаимодействовать с существующими контрактами.

Безопасно ли устанавливать Embark сегодня?

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

Стоит ли использовать Embark для нового криптопроекта?

Для нового производственного проекта, как правило, следует выбирать активно поддерживаемые компоненты разработки, а не полагаться на устаревший стек зависимостей Embark.

Почему Embark важен с исторической точки зрения?

Это был один из первых фреймворков, объединивших смарт-контракты, фронтенд-разработку, автоматизированное развертывание, тестирование, хранение, коммуникацию и визуальные инструменты в едином процессе разработки dApp.

Заключение

Embark Framework — это устаревшая среда разработки с открытым исходным кодом, созданная для упрощения полнофункциональной разработки децентрализованных приложений.

Она автоматизировала компиляцию Solidity, развертывание контрактов, управление зависимостями, генерацию артефактов, сборку фронтенда, тестирование и взаимодействие с блокчейном.

Embark также интегрировал децентрализованные технологии хранения и коммуникации через EmbarkJS и архитектуру на основе плагинов.

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

Последним стабильным релизом была версия 6.0.0 от 27 апреля 2020 года; позднее в том же году вышли две ночные сборки.

Из-за отсутствия новых релизов зависимости, интеграции с узлами, модули хранения, инструменты сборки и предположения о работе кошельков могут оказаться несовместимы с современными системами.

Для дальнейшей работы уже развернутых через Embark контрактов сам фреймворк не требуется.

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

Разработчикам, изучающим Embark, следует изолировать среду, провести аудит зависимостей, защитить приватные ключи, проверить байт-код контрактов и протестировать каждую историческую интеграцию.

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