Embark Framework

Embark Frameworkとは？

Embark Frameworkは、分散型アプリケーションの構築、テスト、デプロイ、管理を支援するために開発されたオープンソースの開発フレームワークです。

主に、Ethereum Virtual Machine（EVM）のスマートコントラクト、ブラウザベースのフロントエンド、分散型ストレージ、ピアツーピア通信技術を利用するアプリケーション向けに設計されました。

公式のEmbark Frameworkリポジトリでは、分散型アプリケーションを開発・デプロイするためのフレームワークと説明されています。

Embarkは、開発者が手作業で行う必要のあった多くの作業を自動化しました。

具体的には、スマートコントラクトのコンパイル、デプロイ順序の決定、コントラクトのデプロイ、デプロイ済みアドレスの追跡、フロントエンド成果物の再生成、テストの実行、ローカルブロックチェーンサービスの起動、アプリケーションファイルの公開などです。

スマートコントラクトのコンパイルだけに焦点を当てず、分散型アプリケーションのスタック全体を管理しようとした点が、Embarkの大きな特徴でした。

Embarkプロジェクトでは、ブロックチェーン上のコントラクト、JavaScriptアプリケーションコード、分散型ファイルストレージ、ネーミングサービス、分散型メッセージングを、設定ファイルに基づく1つのワークフローに統合できました。

Embarkは、分散型アプリケーションが発展し始めた初期の時期に、Ethereum開発ツールとして重要な役割を果たしました。

ただし、最新の安定版は2020年4月にリリースされています。現在はレガシーソフトウェアとして扱い、利用には大規模な互換性確認やセキュリティ対応が必要になる可能性があります。

Embarkの設計目的

Embarkは、分散型アプリケーションの開発で必要となるセットアップや各要素の調整作業を減らすために設計されました。

分散型アプリケーションは、正しく連携しなければならない複数の要素で構成されることがあります。

Solidityコントラクト、ブロックチェーンノード、コントラクトのデプロイスクリプト、生成されたアプリケーション・バイナリ・インターフェース（ABI）、JavaScriptライブラリ、ウェブインターフェース、分散型ストレージ、テスト、ネットワーク固有の設定などが含まれる場合があります。

フレームワークを使わない場合、開発者は各要素を自ら設定し、接続しなければなりません。

Embarkは、これらの要素をまとめて扱い、プロジェクトの変更に合わせて更新する環境の提供を目指しました。

たとえばSolidityコントラクトを変更すると、Embarkがコントラクトを再コンパイルし、再デプロイが必要かどうかを判断したうえで、コントラクトアドレスを更新し、フロントエンド成果物を再生成して、アプリケーションを再ビルドする場合があります。

この自動化されたワークフローは、開発サイクルを短縮し、手動設定によるミスを減らすことを目的としていました。

Embark Frameworkは現在も保守されていますか？

Embarkは、新しい本番プロジェクト向けに積極的に保守されているフレームワークではなく、レガシーな暗号資産開発フレームワークとみなすべきです。

公式リポジトリによると、最新の安定版は2020年4月27日リリースのバージョン6.0.0です。

プロジェクトの公式変更履歴には、その後のナイトリービルドが2020年8月8日と10月8日の日付で2件記録されています。

公開されているEmbarkパッケージの記録にも、メインパッケージが最近安定版として公開されていないことが示されています。

Ethereumの現在の開発フレームワークガイドでは、フルスタック開発フレームワークの役割が説明されていますが、掲載されているフレームワークにEmbarkは含まれていません。

最近のリリースがないため、古い依存関係、ビルドシステム、ブロックチェーンクライアント、JavaScript API、ネットワークに関する前提が、現在の開発環境で安全に動作しない可能性があります。

既存のEmbarkプロジェクトには、現在も有用なコード、コントラクト、テスト、デプロイ履歴が含まれている場合があります。

ただし、保守を続けるチームはすべての依存関係を監査し、重要なワークフローを現在も保守されているコンポーネントに移行することを検討すべきです。

Embarkの開発者

Embarkは、開発者のIuri Matiasが最初に作成し、その後、より広範なオープンソースチームによって開発されました。

保守担当者や組織的な支援体制の変化に伴い、プロジェクトはGitHub上の組織間を移動しました。

現在、主要な公開ソースコードはEmbark LabsのGitHub組織にあります。

リポジトリには数千件の過去のコミットと、ブロックチェーン連携、デプロイ、テスト、ストレージ、通信、コード生成、ユーザーインターフェース用ツールを扱う多数のモジュール式パッケージが含まれています。

EmbarkはMIT Licenseで公開されており、ライセンス条件に従ってコードの調査、改変、再配布が認められています。

DApp開発フレームワークとは？

分散型アプリケーション開発フレームワークとは、ブロックチェーン開発で一般的に必要となる作業を調整するツール群です。

Ethereumの開発ドキュメントでは、フレームワークには一般に、ローカルブロックチェーンツール、コントラクトのコンパイルとテスト、フロントエンド連携、ネットワーク設定、デプロイ、分散型配信のサポートなどが含まれると説明されています。

フレームワークは、スマートコントラクトやブロックチェーンのセキュリティに関する知識の代わりにはなりません。

開発プロセスの一部を自動化するものです。

フレームワークが設定を生成しても、生成されたコードやトランザクションの動作を理解する責任は開発者にあります。

開発フレームワークを使うと生産性が向上する場合がある一方、依存関係やフレームワーク固有の前提が加わります。

Embarkにおける「サーバーレス」の意味

Embarkは、分散型アプリケーションを、1つ以上の分散型技術を使ったサーバーレスのHTML5アプリケーションと説明することがよくありました。

ここでいうサーバーレスは、サーバーやコンピューターが一切存在しないという意味とは限りません。

ブロックチェーンノード、ストレージのピア、ゲートウェイ、ウォレットサービス、ウェブ配信インフラは、引き続きどこかで稼働する必要があります。

この用語は、単一の運営者が管理する従来型のアプリケーションサーバーへの依存を減らせることを意味していました。

スマートコントラクトは、アプリケーションの共有ロジックや状態を保持できます。

分散型ストレージは、参加ノード間でファイルを分散できます。

静的なフロントエンドは、ユーザーのブラウザからブロックチェーンやストレージサービスに直接接続できます。

実際のアプリケーションの多くは、インデックス作成、分析、通知、ユーザーサポート、キャッシュ、認証、高速なデータ配信などに、依然として中央集権型サービスを利用していました。

Embarkのスマートコントラクト管理

スマートコントラクト管理は、Embarkの主要機能の1つでした。

フレームワークはコントラクトのソースファイルを特定してコンパイルし、依存関係を判断して、設定済みのEVMネットワークにデプロイできました。

すでにデプロイされたコントラクトを追跡し、不必要な再デプロイを避けようとしました。

あるコントラクトが別のコントラクトのアドレスに依存する場合、Embarkはデプロイ順序を調整し、必要なアドレスを依存先のコントラクトに渡すことができました。

これは、トークンコントラクト、レジストリ、アクセス制御コントラクト、ファクトリー、ライブラリなど、相互に連携する要素を含むアプリケーションに役立ちました。

システムは、JavaScriptコードからデプロイ済みコントラクトを呼び出すためのコントラクト成果物も生成しました。

自動デプロイで反復作業は減りましたが、開発者はコンストラクターの引数、権限を持つアドレス、ネットワークID、ガス設定、デプロイに使うアカウントを引き続き確認する必要がありました。

コントラクトの自動再デプロイ

Embarkは、開発環境の稼働中にスマートコントラクトのファイル変更を監視できました。

コントラクトが変更されると、フレームワークは再コンパイルし、新たなデプロイが必要かどうかを判断できました。

その後、アプリケーション成果物を更新し、フロントエンドを再ビルドできました。

各コマンドを手動で繰り返す必要がなくなり、開発サイクルが速くなりました。

自動再デプロイは、主にローカル環境や使い捨ての開発ネットワークで便利な機能でした。

本番コントラクトを再デプロイすると新しいアドレスが作成され、元のコントラクトの状態や資産が自動的に移行するわけではありません。

本番環境への再デプロイを、単純なウェブアプリケーションの更新と同じように扱ってはなりません。

不変のコントラクトとアップグレード可能なシステムでは、必要な移行、ガバナンス、セキュリティ手順が異なります。

コントラクト設定

Embarkプロジェクトでは、コントラクトやデプロイ動作を設定ファイルに記述していました。

設定では、コントラクトをデプロイするかどうか、必要なコンストラクター引数、デプロイに使用するアカウント、他のコントラクトへの依存関係などを指定できました。

ローカル開発、プライベートネットワーク、公開テスト環境、本番ネットワークに、それぞれ異なる環境設定を使用できました。

環境を分けることで、どの環境でも同じアドレス、認証情報、デプロイルールを使用する事態を避けやすくなります。

一方、秘密鍵、リカバリーフレーズ、パスワード、制限のないリモートエンドポイントが設定ファイルに含まれると、危険な状態になり得ます。

機密性の高い認証情報を公開ソースリポジトリにコミットしてはなりません。

EmbarkJS

EmbarkJSは、Embarkで構築されたフロントエンドアプリケーションで使われるJavaScript連携レイヤーでした。

ブラウザ上のコードから、デプロイ済みスマートコントラクトや設定済みの他の分散型サービスを利用できました。

Embarkは、コンパイル済みのアプリケーション・バイナリ・インターフェース（ABI）とデプロイ済みコントラクトアドレスに基づいて、コントラクトオブジェクトを生成しました。

フロントエンド開発者は、これらのオブジェクトを使って読み取り専用のコントラクト関数を呼び出し、トランザクションを送信し、ブロックチェーンイベントを監視できました。

機能が有効な場合、EmbarkJSはストレージ、通信、ネーミング連携用のモジュールも提供しました。

生成されたオブジェクトにより、アドレスやABIを手作業で管理する負担が減りました。

ただし、フロントエンドでは、アカウントへのアクセス、ネットワーク選択、トランザクションの確認、署名の拒否、トランザクションのリバート、変化するブロックチェーンの状態などに対応する必要がありました。

JavaScriptのPromiseと非同期処理

Embarkでは、多くのコントラクト操作がJavaScriptのPromiseを通じて提供されていました。

これは、ブロックチェーンアプリケーション開発の非同期性に適した仕組みです。

コントラクト呼び出しでは、リモートノードへのRPCリクエストが必要になる場合があります。

状態を変更するトランザクションでは、ユーザーの承認、ブロードキャスト、ブロックへの取り込み、複数回の承認が必要になる場合があります。

開発者は、送信されたトランザクションと、正常に実行され十分な承認を得たトランザクションを区別する必要がありました。

送信のPromiseが解決しても、意図したコントラクト操作が成功したとは限りません。

アプリケーションでは、レシート、実行状況、発行イベント、エラー情報を確認する必要がありました。

EmbarkとEVMネットワーク

Embarkは主にEthereumと、Ethereum Virtual Machineに対応する他のブロックチェーン向けに設計されました。

EVMはスマートコントラクトのバイトコードを実行し、アカウント、ストレージ、メッセージ、ガス、コントラクト呼び出しの共通モデルを提供します。

Embarkは設定済みプロバイダーを通じて、ローカルノード、プライベートネットワーク、テスト環境、公開ネットワークに接続できました。

ブロックチェーンノードとの通信には、Ethereum互換のJSON-RPCメソッドを使用しました。

Ethereum JSON-RPCドキュメントでは、アプリケーションがノードへの問い合わせやトランザクション送信に利用する標準リクエストインターフェースが説明されています。

フレームワークがRPCインターフェースに対応していても、新しいトランザクション形式、手数料市場、コンパイラバージョン、クライアントのフラグ、ネットワークの動作に対応できるとは限りません。

ローカルブロックチェーン開発

Embarkは、開発やテスト用のローカルブロックチェーン環境を起動したり、既存環境に接続したりできました。

ローカルネットワークでは、公開ネットワーク上の資産を使わずにコントラクトを素早くデプロイできます。

シミュレーション残高を持つテストアカウントを利用でき、ブロック生成も高速化できました。

ローカル開発は、コントラクトのロジック、フロントエンド連携、デプロイ順序、トランザクションの流れを確認するのに役立ちました。

ただし、ローカルブロックチェーンですべての公開ネットワーク上の状況を再現できるわけではありません。

実際のネットワークでは、手数料の変動、トランザクションの遅延、悪意あるユーザー、外部プロトコル、価格変動、ネットワーク混雑、より複雑な再編成やファイナリティの挙動が生じます。

本番システムには、現実的な環境や前提に基づく追加テストが必要です。

Embarkのテスト

EmbarkはJavaScriptを使ったスマートコントラクトのテスト駆動開発に対応していました。

開発者は、コントラクトのデプロイ、関数の呼び出し、トランザクションの送信、結果の状態確認を行うテストを作成できました。

フレームワークはテストアカウントを管理し、テスト実行時に開発用ブロックチェーンをリセットまたは初期化できました。

コントラクトテストでは、デプロイ動作、アクセス制御、トークン残高、イベント、リバート、コントラクト間の連携を検証できました。

スマートコントラクトの不具合はデプロイ後に永続化する可能性があるため、自動テストはEmbarkの最も価値ある機能の1つでした。

テストに合格しても、コントラクトの安全性が証明されるわけではありません。

テストで検証されるのは、開発者が含めたシナリオと前提だけです。

スマートコントラクトのテスト対象

優れたテストスイートには、想定されるユーザー操作と、意図的に敵対的な操作の両方を含める必要があります。

権限のある呼び出し元と、権限のない呼び出し元をテストします。

ゼロ値、最大値、連続呼び出し、想定外の順序、不正なアドレス、失敗する外部呼び出し、境界条件も確認します。

トランザクションがリバートした際に、状態の変更が正しく維持されるかも検証します。

コントラクトが資産を送信したり、信頼できないコントラクトを呼び出したりする場合は、リエントランシーもテストします。

管理機能、アップグレード経路、一時停止機能、緊急出金、所有権移転もテスト対象です。

Solidityのセキュリティガイダンスでは、リエントランシー、ガス制限付きループ、認証済みプロキシ、非公開情報、外部呼び出しなどの一般的なリスクが説明されています。

Embarkのコントラクト成果物

コントラクト成果物とは、スマートコントラクトのデプロイや操作に必要な情報を含む生成ファイルです。

コントラクトのABI、バイトコード、デプロイ済みアドレス、ネットワーク情報、コンパイラ出力、ソース参照などが含まれる場合があります。

Embarkは、フロントエンドやテストコードから、アドレスやインターフェースを手作業でコピーせずにコントラクトを利用できるよう、成果物を生成しました。

成果物は、対象とするデプロイネットワークに一致している必要があります。

誤ったネットワークのアドレスを使うと、無関係なコントラクトやコードのないアドレスをアプリケーションが呼び出す可能性があります。

本番アプリケーションでは、ローカルの成果物ファイルだけに頼らず、ブロックチェーンのチェーンIDとコントラクトのバイトコードを検証すべきです。

Embarkのビルドパイプライン

Embarkには、分散型アプリケーションのフロントエンド資産を準備するためのビルドパイプラインが含まれていました。

JavaScript、HTML、スタイルシート、画像、生成されたブロックチェーン成果物などをコピー、変換、バンドルできました。

特定のユーザーインターフェース技術に固定するのではなく、一般的なウェブ開発ツールやフロントエンドライブラリと連携できました。

これにより、開発者は慣れたブラウザ開発の手法を維持しながら、ブロックチェーン連携を追加できました。

ビルドパイプラインは、インストールやコンパイル時にパッケージやスクリプトを実行するため、ソフトウェアサプライチェーンのリスクを生みます。

古いプロジェクトでは、脆弱性を含む、正常にインストールできない、元の配布元から削除されているといった古いパッケージに依存している場合があります。

Embark Cockpit

Embarkには、一般にCockpitと呼ばれるグラフィカルな開発インターフェースが含まれていました。

Cockpitは、稼働中の分散型アプリケーション環境を視覚的に確認できるように設計されていました。

コントラクト、トランザクション、ログ、プロセス、サービス、開発状況などを表示できました。

開発中の操作や動作を確認するためのツールも備えていました。

視覚的なダッシュボードにより、複数のコマンドライン画面を使うよりフレームワークを扱いやすくできました。

ただし、ダッシュボードでは重要な詳細が簡略化されたり省略されたりする場合があるため、開発者は基盤となるトランザクションを理解する必要があります。

最終リリース以降にフロントエンド依存関係やブラウザの動作が変わっているため、過去のCockpitコンポーネントは現在、特に実行が難しい可能性があります。

Embark Console

Embark Consoleは、設定済みのプロジェクトとブロックチェーンネットワークに接続する対話型のコマンド環境でした。

開発者は、アカウントの確認、生成済みコントラクトオブジェクトへのアクセス、読み取り関数の呼び出し、トランザクションの送信に利用できました。

対話型コンソールは、デバッグや手動テストに便利でした。

一方、価値のある資産を保有する本番アカウントに接続すると危険です。

コマンドによって、コントラクトのデプロイ、状態変更、資産移転、権限付与が実行される場合があります。

秘密鍵やロック解除済みアカウントを、保護されていないコンソールや一般公開されたRPCエンドポイント経由で公開してはなりません。

Embarkと分散型ストレージ

Embarkは、アプリケーションがブロックチェーン外でファイルをアップロード、取得、公開できるよう、分散型ストレージシステムと連携しました。

大きなアプリケーションファイルをEVMコントラクトのストレージに直接保存するのは、通常コストがかかります。

分散型ストレージネットワークには、フロントエンドファイル、画像、メタデータ、文書などを保存し、ブロックチェーンには参照情報やコンテンツ識別子を記録できます。

EmbarkJSは、対応するストレージサービス向けに共通のアプリケーションインターフェースを提供しました。

Embarkでは、アプリケーションの静的なフロントエンドを分散型ストレージ経由でデプロイすることもできました。

これにより従来型のウェブサーバーへの依存を減らせますが、コンテンツが永久に利用できるとは限りません。

EmbarkとIPFS

IPFSは、Embarkの主要な分散型ストレージ連携の1つでした。

IPFSはコンテンツアドレス方式を採用しており、ファイルをサーバー上の場所だけでなく、コンテンツの暗号学的な記述によって特定できます。

IPFS公式ドキュメントでは、コンテンツ識別子を使って、内容に基づきデータを要求する仕組みが説明されています。

ファイルを変更すると、通常は別のコンテンツ識別子が生成されます。

これにより、ユーザーはコンテンツの変更を検出しやすくなります。

ただし、少なくとも1つの到達可能な参加者がデータを保存・配信し続けなければならないため、可用性が自動的に保証されるわけではありません。

重要なアプリケーションファイルについては、ピン留め、複製、永続化の計画が必要です。

EmbarkとSwarm

Embarkは、Swarmを利用したストレージやアプリケーションデプロイの過去のサポートも提供していました。

対応するストレージ連携を通じて、フロントエンドファイルを公開し、コントラクトのソースやアプリケーションコンテンツを取得できました。

Embarkの最終安定版リリース以降、ストレージAPIやネットワークの動作は変化しています。

そのため、古い設定は現在のノード、ゲートウェイ、パッケージバージョン、アドレス指定ルールと互換性がない可能性があります。

過去のプロジェクトを保守する開発者は、本番で利用する前に、各ストレージ操作を個別にテストすべきです。

分散型通信

Embarkには、分散型またはピアツーピア通信システムとの連携機能が含まれていました。

プロジェクトのドキュメントでは、対応する通信技術としてWhisperとOrbitが挙げられていました。

これらの連携は、従来型の単一メッセージングサーバーに全面的に依存せず、分散型アプリケーションがチャネルを通じてメッセージを送受信できるようにすることを目的としていました。

通信レイヤーは、通知、チャット、連携、アプリケーション固有のデータ交換を支援できます。

メッセージ配信、スパム対策、本人確認、暗号化、オフラインアクセス、長期保存は、それぞれ別途設計する必要がありました。

過去の通信連携機能は、現在のネットワークソフトウェアでは動作しない可能性があります。

Embarkプラグイン

Embarkは、コア機能を拡張するモジュール式プラグインアーキテクチャを採用していました。

プラグインによって、ブロックチェーンクライアント、ストレージシステム、通信サービス、コンパイラ、テストツール、デプロイ動作、コンソールコマンド、アプリケーション連携を追加できました。

新しいサービスのたびにコアプロジェクトを変更する必要がなく、フレームワークの柔軟性が高まりました。

一方で、プラグインはサプライチェーンと互換性のリスクも高めました。

プラグインはローカルコードを実行し、設定を読み取り、アカウントにアクセスし、生成ファイルを変更し、デプロイ動作に影響を与える可能性があります。

インストール前に、プラグインのソース、保守担当者、リリース履歴、依存関係、権限を確認すべきです。

Embarkのコマンド

Embarkは、プロジェクトの作成、実行、テスト、ビルド、操作を行うコマンドラインコマンドを提供していました。

過去のインストールコマンドは

でした。

コマンドで、分散型アプリケーションのサンプルを作成できました。

コマンドは、設定済みの開発サービスを起動し、プロジェクトの変更を監視しました。

コマンドは、スマートコントラクトのテストを実行しました。

コマンドは、デプロイ用のアプリケーションファイルを準備しました。

コマンドは、選択した設定に接続する対話型環境を開きました。

ソフトウェアと依存関係が古いため、これらの過去のコマンドは現在のOSやパッケージ実行環境で失敗する場合があります。

Embarkの環境設定

Embarkプロジェクトでは、対象とするブロックチェーンごとに異なる環境を定義できました。

ローカル環境では、自動生成アカウントとシミュレーション用ブロックチェーンを使う場合があります。

公開テスト環境では、リモートノードに接続し、テスト資金を持つアカウントからデプロイする場合があります。

本番環境では、より厳格な署名管理、固定されたコントラクトアドレス、慎重に確認したガス設定を使う場合があります。

環境を分離すると、本番環境でテスト設定を誤用するリスクを減らせます。

ただし、環境名だけでセキュリティが確保されるわけではありません。

デプロイスクリプトには、明示的なチェーンIDの確認と安全な鍵管理手順が必要です。

Embarkとコントラクトの依存関係

大規模な分散型アプリケーションには、他のコントラクトに依存するコントラクトが含まれることがよくあります。

コンストラクターで、トークン、レジストリ、ライブラリ、管理者、オラクルの各アドレスが必要となる場合があります。

Embarkでは、デプロイ設定から他のコントラクトを参照し、デプロイ済みアドレスを解決できました。

依存関係の情報に基づき、正しいデプロイ順序を決定できました。

依存関係の自動化によって手作業でのコピーは減りましたが、重要な信頼関係が見えにくくなる可能性があります。

参照先コントラクトが意図したバージョンであること、権限がアプリケーションのセキュリティ設計に合致することを、開発者は引き続き確認する必要があります。

Embarkとアプリケーションのネーミング

Embarkには、分散型ネーミングシステムとの過去の連携機能が含まれていました。

ネーミングシステムは、人間が読める名前をアカウント、コントラクト、コンテンツ識別子、その他のブロックチェーン上のリソースに対応付けます。

長い16進数アドレスを入力せずに済むため、使いやすさが向上する場合があります。

名前には有効期限があり、譲渡されたり、新しい宛先に解決されたり、侵害されたアカウントに管理されたりする可能性があります。

読みやすい名前だけを、コントラクトの同一性を恒久的に証明するものとして扱ってはなりません。

高額な操作では、解決されたアドレスとネットワークを確認すべきです。

Embark Frameworkの利点

Embarkは、コントラクト、フロントエンドコード、テスト、デプロイ、ストレージ、通信にまたがる統一されたワークフローを提供しました。

JavaScriptのコントラクトオブジェクトとデプロイ成果物を自動生成しました。

ソースファイルを監視し、必要に応じてコンポーネントを再ビルドまたは再デプロイしました。

複数コントラクト間の依存関係管理に対応しました。

ローカル開発ネットワークとJavaScriptテストを提供しました。

複数のブロックチェーン環境に異なる設定を使用できました。

視覚的なダッシュボードと対話型コンソールも備えていました。

また、分散型アプリケーションはブロックチェーンだけで構成されるとは限らないという考え方を、開発者に広めるのに役立ちました。

Embark Frameworkの制約

Embarkは多様な技術をまとめて管理しようとしたため、規模が大きく複雑なフレームワークになりました。

多数のNode.jsパッケージ、ブロックチェーンクライアント、コンパイラ、ストレージツール、フロントエンドライブラリ、プラグインに依存していました。

主要な依存関係のいずれかに破壊的変更があると、開発環境全体に影響する可能性があります。

自動デプロイやコード生成により、実行されているコマンドやトランザクションの詳細を初心者が理解しにくくなる場合があります。

幅広い機能は、インストール時間やトラブルシューティングの複雑さも増やしました。

現在は安定版の最近のリリースがないため、互換性やソフトウェアサプライチェーンに深刻な懸念があります。

古い開発フレームワークがセキュリティリスクを生む理由

古いフレームワークには、脆弱性が公表済みの古い依存関係が含まれる可能性があります。

依存関係ツリーに、すでに保守されていないパッケージが含まれていることもあります。

インストールスクリプトが、廃止されたレジストリ、バイナリのダウンロード、システムコマンドに依存している場合があります。

現在のSolidityコンパイラの動作や最新のEVM機能に対応していない可能性があります。

安全でないガスの前提を生成したり、廃止されたノードのフラグを使用したりする場合もあります。

古いフロントエンドライブラリには、ブラウザの脆弱性や、互換性のないウォレット連携動作が含まれる可能性があります。

インストールに成功しても、開発環境全体の安全性が証明されるわけではありません。

ソフトウェアサプライチェーンのリスク

JavaScript開発フレームワークのインストールでは、直接・間接の多数のパッケージのコードが実行される場合があります。

侵害されたパッケージは、環境変数を読み取り、ソースファイルを変更し、署名認証情報を盗み、ビルド成果物に悪意あるコードを挿入する可能性があります。

古いロックファイルでは、過去のパッケージバージョンが入手できない場合、依存関係が以前とは異なる形で解決されることがあります。

古いプロジェクトは、価値のある秘密鍵を置かない隔離環境にインストールすべきです。

ロックファイル、パッケージのチェックサム、インストールスクリプト、依存関係グラフも確認してください。

本番用の署名は、信頼できない、または再構築したばかりのレガシービルド環境から分離すべきです。

秘密鍵の安全な管理

Embarkでコントラクトをデプロイしたり開発用トランザクションを送信したりするには、アカウントへのアクセスが必要でした。

暗号化されていない秘密鍵やリカバリーフレーズをプロジェクト設定に保存すると、重大なセキュリティリスクが生じます。

ソース管理から情報が漏えいすると、その鍵で管理されているすべての資産が危険にさらされる可能性があります。

悪意ある依存パッケージが、ローカルの設定ファイルや環境変数を読み取る可能性もあります。

本番デプロイでは、資金を限定し、トランザクションを明確に確認できる管理された署名手順を使うべきです。

開発用アカウントを、長期保有資産の管理や管理者用アカウントに再利用してはなりません。

スマートコントラクトの検証

Embarkでコントラクトをデプロイしても、公開ソースがデプロイ済みバイトコードと一致することが自動的に証明されるわけではありません。

コントラクト検証では、公開されたソースコードとコンパイラ設定をオンチェーンのコードと照合できます。

デプロイに使った正確なコンパイラバージョン、最適化設定、コンストラクター引数、ライブラリ、ソースファイルを保存すべきです。

古いコンパイラのバイナリや依存関係が失われると、レガシープロジェクトの成果物を再現することが難しくなる可能性があります。

そのため、Embarkプロジェクトを保守する際は、再現可能なビルドとデプロイ記録の保存が重要です。

Embarkからの移行

Embarkから移行する際、すべてのスマートコントラクトを再デプロイする必要があるとは限りません。

デプロイ済みコントラクトを維持したまま、ローカルでのコンパイル、テスト、デプロイ、フロントエンドのビルド手順を置き換えられます。

まず、コントラクトアドレス、ソースファイル、ABI、コンパイラ設定、コンストラクター引数、ライブラリ、管理者アカウントを一覧にします。

次に、隔離された最新のビルド環境でコントラクトを再現します。

可能であれば、テストを使って新しい成果物と過去のデプロイ済みバイトコードを比較します。

その後、フロントエンドコードを更新し、Embarkの生成成果物に依存せず、検証済みのABIとアドレスを読み込めるようにします。

コントラクト自体の変更が必要で、移行リスクを理解している場合に限り、再デプロイを行うべきです。

既存のEmbarkプロジェクトの保存

古いEmbarkアプリケーションを保守するチームは、ソースリポジトリ全体とロックファイルを保存すべきです。

必要なNode.jsバージョン、OS、コンパイラバージョン、ブロックチェーンクライアント、環境変数、パッケージマネージャーの動作を記録します。

コンテナイメージや仮想マシンイメージは、再現可能な過去の環境の保存に役立ちます。

ただし、環境の保存は脆弱性も保存するため、イメージをスキャンし、隔離しておくべきです。

Embarkが動作しなくなってもコントラクトを操作できるよう、重要なコントラクトはフレームワークとは別に文書化します。

デプロイアドレスと管理者権限は、オンチェーンで直接確認してください。

新しいプロジェクトにEmbarkを使うべきですか？

2026年に新しい本番用暗号資産アプリケーションを開発する場合、一般にEmbarkを基盤として選ぶべきではありません。

フレームワークの安定版は、2020年4月以降リリースされていません。

ドキュメントに記載された連携機能や依存関係は、古いEthereum開発環境を前提に設計されています。

新しいプロジェクトには、現在のコンパイラリリース、トランザクション形式、ネットワークの動作、テスト手法、セキュリティ慣行に対応する、積極的に保守されたツールが必要です。

Embarkは、過去の研究、レガシーアプリケーションの保守、初期のDAppツールの研究、再利用可能なコントラクトやテストケースの抽出には、現在も役立つ場合があります。

継続利用する場合は、依存関係全体を確認するまで、価値のある鍵を置かない管理された環境で実施すべきです。

Embarkの歴史的な重要性

Embarkは、フルスタックの分散型アプリケーションフレームワークという考え方を形作るのに貢献しました。

スマートコントラクト、フロントエンドコード、ストレージ、通信、テスト、デプロイ、開発者向けインターフェースを、1つのアプリケーションの要素として扱いました。

これは、ブロックチェーン開発ツールが分断され、設定も難しかった時期に重要でした。

また、コントラクト成果物の自動生成や依存関係を考慮したデプロイを、より多くのJavaScript開発者が利用できるようにしました。

分散型ストレージとの連携により、あらゆる種類のデータをブロックチェーンの状態として扱う以外の方法を、開発者が検討するきっかけにもなりました。

アーキテクチャやツールは異なりますが、現代の開発ワークフローでも同じ課題に取り組んでいます。

Embarkの開発ワークフロー例

開発者が、トークンを使った簡単な投票アプリケーションを作る場合を考えてみましょう。

トークンと投票ルールを定めるSolidityコントラクトを作成できます。

Embarkの設定では、トークンコントラクトを記述し、デプロイ済みアドレスを投票コントラクトに渡すよう指定できます。

Embarkはローカルブロックチェーンを起動し、両コントラクトをコンパイルし、必要な順序でデプロイして、フロントエンド成果物を生成できます。

ブラウザアプリケーションはEmbarkJSを使ってトークン残高を表示し、投票トランザクションを送信できます。

JavaScriptテストでは、対象となるトークン保有者だけが投票できることや、1つのアカウントが複数回投票できないことを検証できます。

完成したフロントエンドは、ビルド後、設定済みの分散型ストレージ連携を通じてアップロードできます。

このワークフローのすべての要素について、公開ネットワークにデプロイする前にセキュリティレビューが必要です。

Embark Frameworkでよくある誤り

よくある誤りの1つは、リポジトリが公開されていることを理由に、Embarkが現在も積極的に保守されていると思い込むことです。

2つ目は、価値のある暗号資産の鍵を保管しているマシンに、古いグローバルパッケージを直接インストールすることです。

3つ目は、コンストラクター引数や権限を持つアカウントを確認せず、自動コントラクトデプロイを安全だとみなすことです。

4つ目は、ローカルテストで公開ネットワークのあらゆる状況を再現できると思い込むことです。

5つ目は、デプロイ用秘密鍵を設定ファイルやソース管理に保存することです。

6つ目は、分散型ストレージならファイルが永久に利用可能になると思い込むことです。

7つ目は、トランザクションの送信成功とスマートコントラクトの実行成功を混同することです。

8つ目は、誤ったブロックチェーンネットワーク向けの生成済み成果物を使うことです。

9つ目は、新しくコンパイルしたバイトコードが過去のコントラクトと一致するか確認せずに、ビルドツールを移行することです。

10個目は、ユーザー、資産、権限、アプリケーションの状態の移行計画を立てずに、本番コントラクトを再デプロイすることです。

FAQ

Embark Frameworkとは何ですか？

Embark Frameworkは、Ethereum互換の分散型アプリケーションの開発、テスト、デプロイ、管理に使われたオープンソースのレガシーツールです。

Embarkではどのプログラミング言語が使われていましたか？

主にSolidityのスマートコントラクトと、JavaScriptまたはTypeScriptのアプリケーションコードに対応していました。

Embarkはどのブロックチェーンに対応していましたか？

主にEthereumと、Ethereum Virtual MachineおよびEthereum形式のJSON-RPCインターフェースに対応する他のネットワーク向けに設計されていました。

Embark Frameworkは現在も稼働していますか？

2020年4月27日のバージョン6.0.0以降、安定版はリリースされていないため、レガシーソフトウェアとして扱うべきです。

Embarkの最新安定版は何ですか？

公式リポジトリに記載されている最新安定版はバージョン6.0.0です。

バージョン6.0.0以降にリリースはありましたか？

公式変更履歴には、2020年8月と10月に6.0.1のナイトリービルドが2件記録されていますが、それ以降に安定版はリリースされていません。

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コントラクトを動かすにはEmbarkが必要ですか？

いいえ。デプロイ済みのEVMコントラクトはブロックチェーンによって実行されます。正しいアドレスとABIを使えば、互換性のある任意のインターフェースからアクセスできます。

コントラクトを移行せずにEmbarkから移行できますか？

はい。既存のコントラクトを引き続き操作しながら、ローカルのビルドやデプロイのワークフローを置き換えられます。

現在Embarkをインストールしても安全ですか？

古い依存関係を確認したうえで、価値のある秘密鍵を公開しない隔離環境に限ってインストールすべきです。

新しい暗号資産プロジェクトでEmbarkを使うべきですか？

新しい本番プロジェクトでは、古い依存関係スタックを持つEmbarkに頼るのではなく、現在も保守されている開発コンポーネントを使うべきです。

Embarkが歴史的に重要なのはなぜですか？

スマートコントラクト、フロントエンド開発、自動デプロイ、テスト、ストレージ、通信、視覚的なツールを、1つのDAppワークフローに統合した初期のフレームワークの1つだからです。

まとめ

Embark Frameworkは、フルスタックの分散型アプリケーション開発を簡素化するために作られた、レガシーなオープンソース開発環境です。

Solidityのコンパイル、コントラクトのデプロイ、依存関係の管理、成果物の生成、フロントエンドのビルド、テスト、ブロックチェーン連携を自動化しました。

EmbarkJSとプラグインベースのアーキテクチャを通じて、分散型ストレージや通信技術とも連携しました。

自動再デプロイ、ローカルブロックチェーン管理、JavaScriptテスト、対話型コンソール、Cockpitダッシュボードなどの機能により、Ethereumアプリケーションが初期に拡大した時期に大きな影響を与えました。

最新の安定版は2020年4月27日リリースのバージョン6.0.0で、その年の後半にナイトリービルドが2件公開されました。

最近のリリースがないため、依存関係、ノード連携、ストレージモジュール、ビルドツール、ウォレットに関する前提が現在のシステムと互換性を持たない可能性があります。

Embarkでデプロイ済みの既存コントラクトは、オンチェーンで動作し続けるためにフレームワークを必要としません。

レガシープロジェクトのチームは、コントラクトアドレスとブロックチェーン上の状態を維持しながら、コンパイル、テスト、デプロイ、フロントエンドのワークフローを保守されているツールに移行できます。

Embarkを調査する開発者は、環境を隔離し、依存関係を監査し、秘密鍵を保護し、コントラクトのバイトコードを検証し、過去の連携機能をすべてテストすべきです。

Embarkは暗号資産開発の歴史の一部として価値がありますが、現在も保守されている本番用フレームワークと混同してはなりません。