サーバーレスの Arbitrum フルノードを AWS で実行する

過去 2 年間で、レイヤー 2 テクノロジーが勢いを増し、Ethereum のスケーリングの制約を解決しつつあります。
L2beat は、さまざまなレイヤー 2 プロジェクトの統合ビューを提供しています。
記事作成時点で、Arbitrum はレイヤー 2 ソリューションの市場価値の約半分を占めています。

AWS は、node deployment blueprintsからAmazon Managed Blockchain のフルマネージド型のインフラストラクチャやデータサービスまで、ビルダーを支援するさまざまなサービスを提供しています。
Arbitrum はまだサポートされていませんが、AWS 上で独自のサーバーレス Arbitrum ノードを実行するのは簡単な作業です。

この記事では、AWS 上でサーバーレス方式で Arbitrum のフルノードをデプロイする方法を説明します。また、MetaMask を自分の Arbitrum ノードに接続して Arbitrum ネットワークとやり取りする方法も示します。この手順を実行するには、AWS アカウントを用意するだけで十分です。

ソリューションの概要

Arbitrum フルノードの運用には、トランザクション検証とセキュリティ、信頼性の低減など、さまざまな考慮事項があります。Arbitrum のドキュメントには、Arbitrum フルノードを実行するための前提条件とインストラクションがフルノードの実行方法 (Nitro)のセクションに記載されています。この記事では、これらの要件を満たすための AWS アーキテクチャを提案します。このアーキテクチャは単一の正解を表すものではなく、AWS Fargate などのサーバーレスサービスを優先して要件を実装する 1 つの方法です。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに基づく代替手段は、ここで紹介するアーキテクチャと同様に有効です。

次の図は、このソリューションの異なる構成要素を示しています。

arbitrum_node

次に考慮すべき重要な要素をいくつか示します。

Fargate で実行されるタスクは、Amazon Elastic Block Store (Amazon EBS) ボリュームとのネイティブな統合の恩恵を受けます。ボリュームのパフォーマンスベースラインについては、Fargate オンデマンドタスク用の Amazon EBS ボリュームのパフォーマンスベースラインを参照してください。
提案されているアーキテクチャは Sepolia テストネットでテストされており、開発環境またはテスト環境に導入することを目的としています。本番環境への展開では、Amazon Elastic Container Service (Amazon ECS) の Fargate クラスタは、より高いストレージパフォーマンスを提供できる Amazon EC2 起動タイプの ECS クラスタに置き換える必要があります。
執筆時点では、Arbitrum Nitro ノードの最新の安定版は 2.3.1 ですが、より新しいバージョンがリリースされているかどうかを確認することをお勧めします。
このアーキテクチャは最小構成であり、コストを意識して設計されていますが、特定の要件に合わせて拡張できます。
- 可用性を高めるには、複数のアベイラビリティーゾーン上でノードを実行することを検討してください。
- 別の Web3 アプリケーションバックエンドサービスから Arbitrum ノードに接続したい場合は、Amazon ECS Service Connect を利用できます。
- Arbitrum ノードへの接続に使用するサービスタスクのプライベート IP (変更される可能性あり) を回避したい場合は、AWS Fargate、AWS PrivateLink、ネットワークロードバランサーを使用して Amazon ECS 上のコンテナアプリケーションにプライベートにアクセスするのガイダンスに従ってこのアーキテクチャを拡張できます。
- IP トラフィックを監視するには、VPC フローログを使用できます。

次のセクションでは、このソリューションを実装する手順を一つ一つ追って説明します。さまざまなコンポーネントのデプロイを完全に理解するために、以下の手順に従うことをお勧めします。または代わりに、AWS CloudFormation テンプレートを使用することもできます。自動デプロイには約 15 分かかります。その後、このブログ記事の「ノードのテスト」のセクションに進んで、ノードがネットワークと正常に同期していることを確認できます。

VPC の作成

VPCを作成するには、以下の手順に従ってください。

Amazon VPC コンソールで、VPC を作成を選択します。
作成するリソースで、VPC などを選択します。
名前タグの自動生成の下で、自動生成に arbitrum と入力します。
IPv4 CIDR ブロックに 10.0.0.0/23 と入力します。
IPv6 CIDR ブロックでは、IPv6 CIDR ブロックなしを選択します。
アベイラビリティーゾーン数では、1 を選択します。
パブリックサブネット数では、1 を選択します。
プライベートサブネット数では、1 を選択します。
パブリックサブネットの CIDR ブロックに 10.0.0.0/24 と入力します。
プライベートサブネットの CIDR ブロックに 10.0.1.0/24 と入力します。
NAT ゲートウェイでは、AZ ごとに 1 を選択します。
VPC エンドポイントでは、なしを選択します。
DNS オプションでは、DNS ホスト名の有効化とDNS 解決の有効化を選択します。
VPC の作成を選択します。

IAM ロールの作成

AWS Identity and Access Management (IAM) の ecsTaskExecutionRole が存在することを確認してください。詳細については、Amazon ECS タスク実行 IAM ロールを参照してください。

AmazonECSInfrastructureRolePolicyForVolumes の管理ポリシーを使用して、ecsInfrastructureRole IAM ロールを作成します。
この IAM ロールは Amazon ECS のインフラを管理するためのロールです。
詳しい手順については、Amazon ECS インフラの IAM ロールを参照してください。

ロググループの作成

/ecs/arbitrum-node の Amazon CloudWatch ロググループを作成します。
詳細な手順については、ロググループとログストリームの操作を参照してください。

セキュリティグループの作成

このステップでは、2 つのセキュリティグループを作成します。詳しい手順については、セキュリティグループの作成をご覧ください。

VPN セキュリティグループの作成

まず、VPN 用のセキュリティグループを作成します:

Amazon EC2 コンソールで、ナビゲーションペインの セキュリティグループ を選択します。
セキュリティグループの作成 を選択します。
セキュリティグループ名 に arbitrum-vpn-sg と入力します。
説明に Arbitrum VPN security group と入力します。
VPC では arbitrum-vpc を選択します。
セキュリティグループの作成 を選択します。

Arbitrum ノードのセキュリティグループ作成

次に、Arbitrum ノードのセキュリティグループを作成します:

Amazon EC2 コンソールで、ナビゲーションペインから セキュリティグループ を選択します。
セキュリティグループの作成 を選択します。
セキュリティグループ名 には arbitrum-node-sg と入力します。
説明には Arbitrum node security group と入力します。
VPC では arbitrum-vpc を選択します。
次のインバウンドルールを作成します:
- 種類では カスタムTCP を選択します。
- ポート範囲 には 8547 と入力します。
- ソース では カスタム を選択し、arbitrum-vpn-sg セキュリティグループを選択します。
- 説明には Arbitrum RPC と入力します。
セキュリティグループの作成 を選択します。

ECS クラスターの作成

次の手順に従って、ECS クラスターを作成してください:

Amazon ECS コンソールで、ナビゲーションペインから クラスター を選択します。
クラスターの作成 を選びます。
クラスター名 には arbitrum-cluster と入力します。
インフラストラクチャ として AWS Fargate (サーバーレス) を選びます。
作成を選びます。

タスク定義の作成

次の手順に従ってタスク定義を作成してください。

次の手順で、Amazon ECS コンソールのナビゲーションペインから タスク定義 を選択します。
新しいタスク定義を作成 を選び、JSON を使用してタスク定義を作成 を選択します。

JSON コードを次のように編集してください。

{
    "family": "arbitrum-node",
    "containerDefinitions": [ 
        {
            "name": "arbitrum-container",
            "image": "offchainlabs/nitro-node:v2.3.1-26fad6f",
            "cpu": 4096,
            "memory": 16384,
            "memoryReservation": 16384,
            "portMappings": [ 
                {
                    "name": "arbitrum-8547-tcp",
                    "containerPort": 8547,
                    "hostPort": 8547,
                    "protocol": "tcp",
                    "appProtocol": "http"
                }
            ],
            "essential": true,
            "command": [ 
                "--parent-chain.blob-client.beacon-url=<SEPOLIA_BEACON_CHAIN_API_ENDPOINT>",
                "--parent-chain.connection.url=<SEPOLIA_ENDPOINT>",
                "--init.url=https://snapshot.arbitrum.foundation/sepolia/nitro-pruned.tar",
                "--chain.id=421614",
                "--http.api=net,web3,eth,arb",
                "--http.corsdomain=*",
                "--http.addr=0.0.0.0",
                "--http.vhosts=*",
                "--init.download-path=/root/.arbitrum/"
            ],
            "mountPoints": [ 
                {
                    "sourceVolume": "arbitrum-volume",
                    "containerPath": "/root/.arbitrum",
                    "readOnly": false 
                }
            ],
            "user": "root",
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-create-group": "true",
                    "awslogs-group": "/ecs/arbitrum-node",
                    "awslogs-region": "<AWS_REGION>",
                    "awslogs-stream-prefix": "ecs"
                }
            }
        }
    ],
    "executionRoleArn": "<ecsTaskExecutionRole_ARN>",
    "networkMode": "awsvpc",
    "volumes": [ 
        {
            "name": "arbitrum-volume",
            "configuredAtLaunch": true 
        }
    ],
    "requiresCompatibilities": [ 
        "FARGATE"
    ],
    "cpu": "4096",
    "memory": "16384",
    "ephemeralStorage": {
        "sizeInGiB": 21 
    },
    "runtimePlatform": {
        "cpuArchitecture": "ARM64",
        "operatingSystemFamily": "LINUX"
    }
}

プレースホルダーを更新します。
1. <SEPOLIA_BEACON_CHAIN_API_ENDPOINT> には、Sepolia ビーコンチェインエンドポイントの URL を入力します。このエンドポイントが必要な理由の詳細については、Arbitrum 2.3.0 リリースノートを参照してください。
  <SEPOLIA_ENDPOINT> には、Sepolia 実行クライアントエンドポイントの URL を入力します。
  <ecsTaskExecutionRole_ARN> には、ecsTaskExecutionRole IAM ロールの ARN を入力します。
  <AWS_REGION> には、AWS リージョン (例: us-east-1) を入力します。
作成を選んでタスク定義を作成します。

新しいサービスの作成

次のステップでは新しいサービスを作成しましょう。

Amazon ECS コンソールで、ナビゲーションペインの Clusters を選択します。
arbitrum-cluster クラスターを開きます。
コンピューティングオプション の下で、起動タイプ に次のパラメータを設定します:
- 起動タイプ は FARGATE を選択します。
- プラットフォームバージョン は LATEST を選択します。
デプロイ設定 の下で、次のパラメータを設定します:
- ファミリー では arbitrum-node を選択します。
- リビジョン では (LATEST) を選択します。
- サービス名 には arbitrum-node-service と入力します。
- 必要なタスク には 1 と入力します。
デプロイオプション の下で:
- ローリングアップデート を選択します。
- 最小実行タスク には 0 % と入力します。
- 最大実行タスク には 100 % と入力します。
Networking の下で:
- VPC では arbitrum-vpc を選択します。
- サブネット では arbitrum-vpc のプライベートサブネットを選択します。
- セキュリティグループ では arbitrum-node-sg を選択します。
- パブリックIP はオフを選択します。
Volume の下で:
- Size (GiB) には 1000 と入力します。
- IOPS には 5000 と入力します。
- File system type は EXT4 を選択します。
- Infrastructure role は ecsInfrastructureRole を選択します。
Create を選択します。

サービスは自動的に Arbitrum フルノードコンテナを持つ ECS タスクを開始します。コンテナのログを確認するには、arbitrum-グループ グループに移動し、タスクタブで新しく作成されたタスクを選択します。次にログタブでコンテナのログを確認できます。

コンテナがネットワークと同期を完了するのに数時間かかる可能性がありますが、その後は以下のスクリーンショットのように、作成された最後のブロックが Arbiscan のブロックと一致することを確認できるはずです。

logs

ノードのテスト

新しく作成したノードをテストするには、クライアント VPN を使って環境に接続し、その後、MetaMask (一般的なブラウザウォレット) を Arbitrum ノードのエンドポイントに接続します。

Arbitrum エンドポイントへの Client VPN によるアクセス

まず、相互認証の手順に従って証明書を生成します。AWS CloudShellウィンドウを開いて、次のコマンドを入力できます。

git clone https://github.com/OpenVPN/easy-rsa.git && \
cd easy-rsa/easyrsa3 && \
./easyrsa init-pki && \
echo "ca.mydomain.com" | ./easyrsa build-ca nopass && \
echo "yes" | ./easyrsa build-server-full arbitrum-vpn-server.mydomain.com nopass && \
echo "yes" | ./easyrsa build-client-full arbitrum-vpn-client.mydomain.com nopass && \
aws acm import-certificate --certificate fileb://pki/issued/arbitrum-vpn-server.crt --private-key fileb://pki/private/arbitrum-vpn-server.key --certificate-chain fileb://pki/ca.crt

これで Client VPN を作成できます。詳しい手順については、AWS Client VPN の開始方法をご覧ください。

まず、Amazon VPC コンソールでクライアント VPN エンドポイント を選択し、クライアント VPN エンドポイントの作成 を選びます。
次に、名前タグには arbitrum-vpn-endpoint と入力します。
次に、説明には Arbitrum ノードへのリモート VPN アクセス と入力します。
次に、クライアント IPv4 CIDR には 10.1.0.0/16 と入力します。
次に、サーバー証明書 ARN では、作成したサーバー証明書を選択します。
次に、認証オプション では、相互認証を使用する を選択します。
次に、クライアント証明書 ARN では、適切なクライアント証明書を選択します。
次に、スプリットトンネルを有効にする を選択します。
次に、VPC ID では arbitrum-vpc の ID を選択します。
次に、セキュリティグループ ID では arbitrum-vpn-sg の ID を選択します。
最後に、クライアント VPN エンドポイントを作成を実行します。

次に、ターゲットのネットワークを関連付けてください。

作成した Client VPN エンドポイントを選択し、ターゲットネットワークアソシエーションを選んだ後、ターゲットネットワークを関連付けるを選択してください。
VPC では、arbitrum-vpc を選択します。
関連付けるサブネットの選択では、arbitrum-vpc のプライベートサブネットを選択します。
クライアント VPN エンドポイントの状態が Available になるのを待ちます。

次に、認可ルールを作成します。

アクセスを許可するネットワーク先 に 10.0.1.0/24 (プライベートネットワークの arbitrum-vpc の CIDR 範囲) を入力してください。
アクセスを許可する対象 では、全てのユーザーにアクセスを許可 を選択してください。
承認ルールのステータスが アクティブ になるまで待ってください。

最後に、ローカルの OpenVPN クライアントを設定します:

AWS CloudShell から、Actions 、Download file を選択し、/home/cloudshell-user/easy-rsa/easyrsa3/pki/issued/arbitrum-vpn-client.mydomain.com.crt というファイル名を入力してください。
AWS CloudShell から、Actions 、Download file を選択し、/home/cloudshell-user/easy-rsa/easyrsa3/pki/private/arbitrum-vpn-client.mydomain.com.key というファイル名を入力してください。
クライアント VPN エンドポイントコンソールから、Download client configuration を選択し、ダウンロードしたファイルの末尾に、先に取得したファイルの内容をプレースホルダーに追加してください。

<cert>
-----BEGIN CERTIFICATE-----
Insert certificate from (.crt) file
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
Insert private key from (.key) file
-----END PRIVATE KEY-----
</key>

この構成ファイルを使って、AWS 提供のクライアントまたは他の OpenVPN ベースのクライアントアプリケーションで Client VPN エンドポイントに接続できます。詳しくは AWS Client VPN ユーザーガイド をご覧ください。

MetaMask の設定

このセクションでは、あなたがすでに MetaMask をブラウザにインストールしており、Sepolia テストネットでトランザクションのガス料金を支払うのに ETH を十分に所持しているものとみなします。そうでなければ、まず MetaMask をブラウザにダウンロードしてインストールし、Sepolia テストネットの Faucet から ETH を取得する必要があります (完全なリストについては Networks を参照してください)。

ノードのプライベート IP を最初に収集するには、次の手順を完了してください。

Amazon ECS コンソールで arbitrum-cluster クラスターに移動します。
タスクタブで、実行中のタスクを選択し、プライベート IP を確認します。

MetaMask の設定を始められます。

MetaMask でネットワークを手動で追加するを選び、新しいネットワークを作成します。
ネットワーク名としてArbitrum-Sepolia-AWSを入力します。
RPC URLとしてhttp://ARBITRUM_NODE_IP:8547を入力します (ARBITRUM_NODE_IP は前のステップで書き留めた IP アドレスと一致する必要があります)。
Chain IDとして421614を入力します。
通貨シンボルとしてETHを選択します。
Block Explorer URLとしてhttps://sepolia.arbiscan.io/を入力します。

Arbitrum ブリッジを使用したテスト

Arbitrum ブリッジに https://bridge.arbitrum.io/?l2ChainId=421614 の URL で接続します。

MetaMask と接続した後は、送信元と送信先のネットワークを選択し、転送する ETH の量を入力することで、Sepolia テストネット (レイヤー 1) と Arbitrum Sepolia テストネット (レイヤー 2) の間で ETH を送受信できるはずです。

arbitrum_bridge

クリーンアップ

ソリューションを手動でデプロイした場合、作成した要素を以下の順序で削除してください。

Amazon ECS コンソールで、arbitrum-cluster ECS クラスターを削除する。
arbitrum-node タスク定義に移動し、すべてのリビジョンを登録解除する。
Amazon VPC コンソールで、arbitrum-vpc-endpoint クライアント VPN エンドポイントに移動し、ターゲットのネットワークアソシエーションタブでプライベートサブネットの関連付けを解除する。
arbitrum-vpn-endpoint VPN エンドポイントを削除する。
AWS Certificate Manager コンソールで、arbitrum-vpn-server ドメインに対応する証明書を削除する。
Amazon EC2 コンソールで、arbitrum-node-sg および arbitrum-vpn-sg セキュリティグループを削除する。
Amazon VPC コンソールで、NAT ゲートウェイを削除する。
arbitrum-vpc VPC を削除する。

代わりに CloudFormation テンプレートを使用した場合は、次の手順を実行してください:

Amazon VPC コンソールで、arbitrum-vpn-endpointというクライアント VPN エンドポイントを選択し、ターゲットネットワーク関連付け タブでプライベートサブネットの関連付けを解除してください。
arbitrum-vpn-endpoint VPN エンドポイントを削除します。
AWS Certificate Manager コンソールで、arbitrum-vpn-server ドメインに対応する証明書を削除します。
AWS CloudFormation コンソールでスタックを削除します。

まとめ

このポストでは、AWS のサーバーレスサービスを使用して Arbitrum のフルノードをデプロイする方法を紹介しました。これにより、Ethereum レイヤー 2 ソリューションを試せるようになったと思います。
提案したアーキテクチャを出発点として、より複雑な Web3 アプリケーションを構築し、そこから AWS ですでに稼働しているWeb3 エコシステムと統合できるでしょう。

本記事は、Run a serverless Arbitrum full node on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の深津颯騎が担当しました。

著者について

Guillaume Goutaudier は AWS のシニア・エンタープライズ・アーキテクトです。企業が AWS と戦略的技術パートナーシップを構築するのを支援しています。また、ブロックチェーン技術にも情熱を傾けており、ブロックチェーンの技術分野コミュニティのメンバーでもあります。

Amazon Web Services ブログ