本記事では、Ethereumのテストネットである「Sepolia」のノードを構築する手順を解説します。
こんにちは。大和総研リテール基幹システム第二部の内山です。普段は、大和証券が提供するファンドラップに関連するシステム開発に携わっています。
DXシステム部の高木です。普段は経費申請や資金管理・決済業務などバックオフィス業務を行う証券会社向けシステムの設計・開発を行っています。
大和総研ではEthereumなどのパブリックブロックチェーンを活用したWeb3の広がりを見据え、Web3分野の研究開発を行う専門のプロジェクト「Web3 Lab」を発足しました。社内のさまざまな部署から公募で選ばれたメンバーがWeb3 Labに参加しており、私たちもその一員として日々の業務と兼務しながら研究開発に取り組んでいます。
今回はAmazon Web Services（以降、AWS）上で、 Ethereumのノードを構築し、Ethereumのテストネットである「Sepolia」のネットワークに接続する手順について解説します。本記事が、ノード構築を検討している皆さまの参考になれば幸いです。
- 1 Ethereumとは
- 2 Sepoliaとは
- 3 ノードとは
- 4 ノードの種類
- 5 クライアントソフトウェア
- 6 Sepoliaテストネットを用いたノード構築
- 7 まとめ
- お問い合わせ先
- 参考文献
1 Ethereumとは
Ethereum（イーサリアム）は、2013年に当時カナダの学生であったヴィタリック・ブテリン氏（Vitalik Buterin）が発表した構想に基づいて開発されたブロックチェーンの名称です。EthereumはBitcoinと同様パブリックブロックチェーンに分類されるブロックチェーンであり、後述する「ノード」を構築すれば誰でもそのネットワークにアクセスできます。Ethereumで発行されている暗号資産（ネイティブトークン）は「イーサ」（Ether、略称：ETH）と呼ばれており、2026年4月20日時点でBitcoin（BTC）に次いで第2位の時価総額となっています。
Ethereumの登場以前に開発されたブロックチェーンは暗号資産の取引を目的として開発されていたのに対し、Ethereumは24時間自律的に稼働する汎用コンピュータを実現することを目的として開発されました。Ethereumはオープンソース化され、非営利組織のEthereum Foundation（Ethereum財団）と開発者のコミュニティにより、開発とアップデートが継続的に行われています。
2 Sepoliaとは
SepoliaはEthereumのテスト用のネットワークの一つです。本番のネットワークがメインネットと呼ばれるのに対して、テスト用のネットワークはテストネットと呼ばれています。メインネットに似せた環境となっており、開発者がスマートコントラクトやブロックチェーンを利用したアプリケーションの動作確認をするために利用されます。
Sepoliaはメインネット同様、トランザクションを送信する際にトランザクション手数料を支払う必要があります。Sepoliaではその支払いにSepolia ETHというSepolia用のネイティブトークンを利用します。Sepolia ETH はFaucetと呼ばれる配布サイトから無料で取得できます。
3 ノードとは
ブロックチェーンのネットワークは「ノード」と呼ばれる複数のコンピュータが相互に接続することで形成されており、ブロックチェーン上に記録されたデータは「ノード」に分散して保持されています。そのためブロックチェーンは「分散台帳」とも呼ばれています。
ノードには、ブロックとステートの２種類のデータが格納されます。
| データ種類 | データの内容 |
|---|---|
| ブロック | ブロックチェーン上で実行された複数のトランザクション情報をまとめたかたまりを指します。 ブロックは、トランザクションや、ブロックの前後関係を表すハッシュ値、ブロックチェーン全体で何番目のブロックなのかを示すブロックナンバーなどさまざまな情報を持っています。 |
| ステート（状態） | ブロックチェーン上の、ある時点におけるアカウントの状態を示した情報です。 とある時点におけるアカウント内のETHの残高などの情報が格納されています。 |
出所：大和総研作成
ブロックとステートについて、図解すると以下の通りです。
① ある時点（s）で、Aさんが100 ETH、Bさんが50 ETH持っている「状態」
② 「AさんからBさんへ25 ETH送るトランザクション（Tx1）」が「実行」
③ 次の時点（s+1）で、Aさんが75 ETH、Ｂさんが75 ETH持っている「状態」
以上のように、その時点の資産状況や取引履歴が、それぞれデータとして存在しています。
4 ノードの種類
Ethereumではすべてのノードが同じデータを保持しているわけではなく、保持するデータの種類に応じてノードは大きく３種類に分けられます。ノードを構築する際にどの種類のノードを構築するかを選択する必要があり、ノードの種類ごとに構築時のデータの同期方法も異なります。
| ノード名 |
同期するデータの種類と同期方法 | メリット | デメリット | ユースケース |
|---|---|---|---|---|
| フルノード | いくつかの同期方法があり、代表的なものは以下の通り。 ・フル同期 ジェネシスブロック（ブロックチェーンの最初のブロック）から順に全てのブロックを取得し、ブロック内のトランザクションを実行してステートを構築する。 ・スナップ同期 定期的に作成されるステートのスナップショットのうち最新のものを他のノードから取得した後、そのスナップショットが作成された時以降のブロックを順に取得してブロック内のトランザクションを実行し、ステートを構築する。 ※フル同期もスナップ同期も定期的に直近のステートのみを残して過去のステートは削除する。 |
定期的に過去のステートに関するデータが削除されるため、データ容量の増加がアーカイブノードに比べ緩やかになる。 | 削除された過去のステートに含まれる情報を参照する際は、その都度計算処理が必要となり時間がかかる。 | ウォレットサービス、ブロックチェーンゲームなどブロックチェーンを利用した一般的なサービスを提供する場合。 |
| アーカイブノード | ジェネシスブロックから順に全てのブロックを取得し、ブロック内のトランザクションを実行してステートを構築する。過去のステートは削除せず、すべてのステートの履歴を保持する。 | ブロックとステートを全て保持するため、どのデータに対しても、素早くアクセスすることが可能。 | 過去のステートも含めすべてのデータを保存するため、ストレージの消費量が多い。 | ブロックチェーン上の詳細なデータ分析やブロックチェーン技術そのものの研究開発・検証を行う場合。 |
| ライトノード | 全てのブロックのヘッダー情報のみを同期する。 ※ヘッダー情報にはブロックのサマリ情報のみが記載されている |
ブロックのヘッダーのみしか保持しないため、ストレージの消費量が少ない。 | データの一部分しか保持していないため、その詳細に関する情報を参照する場合は他のフルノードから取得する必要があり、データを素早く参照できない。 | 携帯電話や組み込み機器上でノードを稼働させ、ブロックチェーンネットワークに直接アクセスする場合。 |
出所：大和総研作成
5 クライアントソフトウェア
ノードは、「クライアント」とも呼ばれます。Ethereumの場合、クライアントは「実行クライアント（Execution clients）」と「コンセンサスクライアント（Consensus clients）」という2つのソフトウェアで構成され、それぞれ以下の役割を担っています。
| クライアントの種類 |
役割 |
|---|---|
| 実行クライアント | ブロックチェーンネットワーク上に送信されたトランザクションを受け取り、EVM（Ethereum Virtual Machine：イーサリアム仮想マシン）と呼ばれる、Ethereum上でスマートコントラクトを実行できる環境でトランザクションを検証・実行し、データを更新する役割を担います。 |
| コンセンサスクライアント | PoSと呼ばれるコンセンサスアルゴリズムに従ってブロックの提案や提案に対する承認を行い、ネットワークの合意形成を図る役割を担います。 |
出所：大和総研作成
さまざまな実行クライアントとコンセンサスクライアントがオープンソースで開発されています。詳しくは下記のサイトを参照してください。
6 Sepoliaテストネットを用いたノード構築
ここからは実際にノードを構築し、Sepoliaへの接続を行います。クライアントソフトウェアは、ブロックチェーンネットワークの安全性や可用性を高めるために、その多様性を高めることが推奨されています。今回は2026年4月1日時点でメインネット（本番のネットワーク）の実行クライアントの中で最も利用者が多いGeth（注1）と、コンセンサスクライアントの中で2番目に利用者が多いPrysm（注2）を使います。クライアントソフトウェアのシェアについては下記のサイトから確認できます。
Ethernodes（Ethereumネットワーク上で稼働するクライアントの統計情報を提供するサイト）
ノード構築は下図の流れで進めます。Geth、Prysmはそれぞれdockerコンテナとして構築するため、③の「設定ファイルの編集」で作成するdockerコンテナの起動設定ファイル（docker-compose.yaml）内に記載する内容がGeth、Prysmの設定に相当するものになります。
① 環境（サーバ・ストレージ）の用意
ノードはブロックのデータを蓄積し続けるため一般的に大容量のストレージが必要となります。今回は環境構築を効率化するため、AWSを用いてサーバとストレージを用意します。
Gethの公式ドキュメント（注3）のハードウェア要件には、CPUが4コア、メモリは16GB、スナップ同期の場合のディスク容量は650GB程度が必要であると記載されています。そのため下記のEC2とEBSを用意します。（AWSのリソースの構築手順は省略）
- EC2のインスタンスタイプ：m7g.xlarge（CPU：4コア、メモリ：16GB）
- OS：Ubuntu 24.04
- EBS（ルートボリュームとして）：8GB
- EBS（ノードのデータを保存するためのデータボリュームとして）：1000GB（Gethの公式ドキュメントが書かれたときよりもデータが増大しているため、多めにストレージを確保します。）
データボリュームのEBSは「/cmn/data」にマウントします。
$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 3.1G 548K 3.1G 1% /run /dev/nvme0n1p1 8.0G 5.1G 3.0G 64% / tmpfs 7.7G 0 7.7G 0% /tmp /dev/nvme1n1 1000G 0G 1000G 0% /cmn/data ・・・データボリューム /dev/nvme0n1p128 10M 1.4M 8.7M 14% /boot/efi tmpfs 1.6G 0 1.6G 0% /run/user/1000
②Dockerのインストール
上述した通り、Geth、Prysmはそれぞれdockerコンテナとして構築するため、Docker Engineをインストールし、docker composeコマンドを使用できます。
インストール方法はOSごとに異なるため、公式サイトを参考にしてください。
Install Docker Engine | Docker Docs
③ 起動の準備
GethとPrysmを起動する前に、下記の作業を行います。
- jwt.hexの作成
- Genesisファイルの取得
- docker-compose.yamlの作成
jwt.hexの作成
GethとPrysmは互いに通信を行い、協調して動作します。その際、通信の認証に用いるJWT（JSON Web Token）を事前に作成する必要があります。今回は、Prysmが提供するスクリプトのJWT生成機能を用いて作成したjwt.hexというファイルを使用します。作成作業はデータボリュームである「/cmn/data」直下で行います。スクリプトの入手方法については以下の公式サイトも参考にしてください。
Install with script | Prysm
$ cd /cmn/data $ curl https://raw.githubusercontent.com/OffchainLabs/prysm/master/prysm.sh --output ./prysm.sh && chmod +x ./prysm.sh $ ./prysm.sh beacon-chain generate-auth-secret
スクリプトを実行すると「/cmn/data」直下にjwt.hexファイルが作成されます。下記のディレクトリ構成を参考に、gethディレクトリとprysmディレクトリを作成し、それぞれconfigディレクトリとdataディレクトリを作成します。jwt.hexファイルをgethディレクトリとprysmディレクトリの両方のconfigディレクトリにコピーしておきます。
/cmn/data
├── geth
│ ├── config
│ │ └── jwt.hex
│ └── data
│ └── (このディレクトリはGethが起動後に使用します)
│
└── prysm
├── config
│ └── jwt.hex
└── data
└── (このディレクトリはPrysmが起動後に使用します)
Genesisファイルの取得
コンセンサスクライアントを起動する際に必要なGenesisファイルを取得します。このファイルには、イーサリアムのネットワークが開始された時点の、全バリデータの状態やネットワークの設定情報が格納されています。コンセンサスクライアントを構築する際にはあらかじめ取得しておく必要があります。
SepoliaテストネットのGenesisファイルは下記から取得可能です。
sepolia/metadata/genesis.ssz at main · eth-clients/sepolia · GitHub
$ cd /cmn/data/prysm/config $ wget https://github.com/eth-clients/sepolia/raw/refs/heads/main/metadata/genesis.ssz
docker-compose.yamlの作成
最後に、docker-compose.yamlファイルを使ってGeth および Prysm をどのような dockerコンテナの構成で起動するかを定義します。/cmn/data直下にdocker-compose.yamlファイルを作成します。
$ cd /cmn/data $ vi docker-compose.yaml
今回作成したdocker-compose.yamlファイルは以下の通りです。GethとPrysmそれぞれについてポイントとなる点を説明します。
services:
geth:
image: "ethereum/client-go"
restart: "always"
container_name: "geth"
hostname: "geth"
ports:
- "8545:8545"
volumes:
- ./geth/config:/config
- ./geth/data:/geth
command:
- --sepolia ・・・Ⓐ
- --datadir=/geth
- --authrpc.addr=0.0.0.0
- --authrpc.port=8551 ・・・Ⓑ
- --authrpc.vhosts=*
- --authrpc.jwtsecret=/config/jwt.hex ・・・🄫
- --http
- --http.api=eth,net
- --http.addr=0.0.0.0
- --http.vhosts=*
- --syncmode=snap ・・・Ⓓ
- --verbosity=3
user: "1000:1000"
prysm:
image: "gcr.io/prysmaticlabs/prysm/beacon-chain"
restart: "always"
container_name: "prysm"
hostname: "prysm"
ports:
- "8551:8551"
depends_on:
geth:
condition: service_started
volumes:
- ./prysm/config:/config
- ./prysm/data:/prysm
command:
- --accept-terms-of-use
- --sepolia ・・・Ⓔ
- --jwt-secret=/config/jwt.hex ・・・Ⓕ
- --genesis-beacon-api-url=https://sepolia.beaconstate.info ・・・Ⓖ
- --checkpoint-sync-url=https://sepolia.beaconstate.info ・・・Ⓖ
- --datadir=/prysm
- --execution-endpoint=http://geth:8551 ・・・Ⓗ
- --rpc-host=0.0.0.0
- --http-host=0.0.0.0
- --genesis-state=/config/genesis.ssz ・・・Ⓘ
user: "1000:1000"
Gethの設定ポイント
Ⓐ Ethereumのテストネットである“sepolia”を指定します。
Ⓑ コンセンサスクライアントであるPrysmと接続するためにGethが使用するポートを指定します。
Ⓒ GethとPrysmが通信を行う際の認証に用いるJWTが記載されたファイルを指定します。
Ⓓ 同期方法を指定します。今回は“snap”を指定しスナップ同期を行います。
Ⓔ Ethereumのテストネットである“sepolia”を指定します。
Ⓕ GethとPrysmが通信を行う際の認証に用いるJWTが記載されたファイルを指定します。
Configure JWT authentication | Prysm
Ⓘ あらかじめダウンロードしたGenesisファイルの場所を指定します。
④ ノードの起動と同期状況の確認
docker-compose.yamlファイルの準備ができましたので、docker composeコマンドを使ってノードを起動します。
$ cd /cmn/data $ docker compose up -d
dockerコンテナのログからGethとPrysmのログを確認できます。
$ docker compose logs -f
GethとPrysmの起動後しばらくすると、同期処理が始まります。同期完了までしばらく時間がかかります。ログから同期の状況を確認できます。例えば、下記はGethの同期状況のログです。Syncedの後に続く数値が、同期の進捗率を示しています。以下の例は、ステートが5.00％まで同期済、チェーン（ブロック）が34.82％まで同期済という状況を示しています。
geth | INFO [04-06|10:25:38.117] Syncing: state download in progress synced=5.00% state=11.17GiB accounts=7,887,684@1.64GiB slots=34,629,613@7.39GiB codes=974,439@2.13GiB eta=1h27m19.835s geth | INFO [04-06|10:25:43.966] Syncing: chain download in progress synced=34.82% chain=16.12GiB headers=3,691,181@1.20GiB bodies=3,691,181@12.72GiB receipts=3,691,181@2.21GiB eta=1h10m40.067s
synced=100.00%というメッセージが表示されるまで待ちます。
⑤ 同期ステータスの確認
synced=100.00%になった後も、内部ではデータの整理（インデックス化）などが継続されており、完了までしばらく時間がかかる場合があります。同期ステータスはノードに用意されているブロックチェーンのデータを取得するためのさまざまなAPIを利用して確認できます。今回は、Geth が提供している JavaScript Console（注4）を使用して同期ステータスを確認できるAPIを呼び出します。
なお、今回はdockerコンテナでGethを起動しているため、gethコマンドを使用するために、Geth のdockerコンテナにアクセス後、Javascript Consoleを起動します。
$ docker exec -it geth /bin/sh // Gethのdockerコンテナにアクセス / $ geth attach --datadir /tmp/.ethereum http://localhost:8545 Welcome to the Geth JavaScript console! modules: eth:1.0 net:1.0 rpc:1.0 To exit, press ctrl-d or type exit >
JavaScript Consoleを起動後、eth.syncingというAPIを呼び出します。false と返ってきた場合は同期が完了しています。下記のようなメッセージが返ってきた場合は同期処理中です。
> eth.syncing
{
currentBlock: 10648501,
healedBytecodeBytes: 0,
healedBytecodes: 0,
healedTrienodeBytes: 0,
healedTrienodes: 0,
healingBytecode: 0,
healingTrienodes: 0,
highestBlock: 0,
startingBlock: 0,
stateIndexRemaining: 0,
syncedAccountBytes: 0,
syncedAccounts: 0,
syncedBytecodeBytes: 0,
syncedBytecodes: 0,
syncedStorage: 0,
syncedStorageBytes: 0,
txIndexFinishedBlocks: 1121601,
txIndexRemainingBlocks: 1228399
}
⑥ 動作確認
同期の完了後、ブロックチェーンのデータを実際に参照してみます。同期ステータスの確認時と同様、JavaScript ConsoleからAPIを呼び出すことで、データを参照できます。
- ノードのブロック番号取得API（eth.blockNumber） APIを実行した時点での同期済のブロック番号を参照できるAPIです。その出力結果にあるブロック番号をEthereum 上で実行されたトランザクションを確認できるサイトである「Etherscan」（注5）で検索することで、ブロックチェーンのデータとして実在するブロックであることが確認できます。
> eth.blockNumber 10648511
- トランザクションレシート取得API（eth.getTransactionReceipt（引数：トランザクションハッシュ））
Ethereumのトランザクションにはトランザクションハッシュと呼ばれる、トランザクションを一意に識別するための識別子が付与されます。このAPIではトランザクションハッシュを使用して、トランザクションの内容や実行結果などの詳細な情報が記載されたトランザクションレシートという情報を取得することができます。
今回は「Etherscan」で適当なトランザクションを選択し、そのトランザクションレシートをAPIから取得してみます。対象のトランザクションのURLは下記になります。Transaction Hashの欄に書かれているトランザクションハッシュを用いてAPIを呼び出します。
https://sepolia.etherscan.io/tx/0xf5d3fa7634bf6be7b2b1d68acd1482d8a89d491c49c4ebcfbe70fd3ae6550c74
> eth.getTransactionReceipt('0xf5d3fa7634bf6be7b2b1d68acd1482d8a89d491c49c4ebcfbe70fd3ae6550c74')
{
blockHash: "0x072c1912d14c39d0c78822b8862aa2365df1fffcd24db68f1f08331edb761665",
blockNumber: 7112590,
contractAddress: "0x85c7e1961daf80c0ee5edcdd87117d46eff8e6aa",
cumulativeGasUsed: 8939968,
effectiveGasPrice: 28537384964,
from: "0x26853dd2eb7c7a89edbe9977cc0ac95abd70ee39",
gasUsed: 1060691,
logs: [{
address: "0x85c7e1961daf80c0ee5edcdd87117d46eff8e6aa",
blockHash: "0x072c1912d14c39d0c78822b8862aa2365df1fffcd24db68f1f08331edb761665",
blockNumber: 7112590,
data: "0x00000000000000000000000000000000000000000000000000000000000f4240",
logIndex: 28,
removed: false,
topics: ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", "0x0000000000000000000000000000000000000000000000000000000000000000", "0x00000000000000000000000026853dd2eb7c7a89edbe9977cc0ac95abd70ee39"],
transactionHash: "0xf5d3fa7634bf6be7b2b1d68acd1482d8a89d491c49c4ebcfbe70fd3ae6550c74",
transactionIndex: 40
}],
logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000008000
000000000000000000000000000000000000000000000020000000000000000000800000000000000008
000000010000000000000000000000000000000000000000000000000000000000000000000000000000
000020000000020000000000000000000000000000000000000000000000000000002000000000000000
000000000000000004000000000000000000021000000000000000000000000000000000000000000000
000800000000000000000",
status: "0x1",
to: null,
transactionHash: "0xf5d3fa7634bf6be7b2b1d68acd1482d8a89d491c49c4ebcfbe70fd3ae6550c74",
transactionIndex: 40,
type: "0x2"
}
7 まとめ
本記事では、Gethを使ってEthereumのノードを構築し、テストネット「Sepolia」に接続しました。
GethとPrysmのdockerイメージを利用すれば比較的容易にノードを構築することができます。今回紹介したGethとPrysmのほかにも様々なクライアントソフトウェアが存在しますので、構築手順やその特徴を比較してみるのも面白いかもしれません。興味のある方はぜひチャレンジしてみてください。
お問い合わせ先
大和総研では、ブロックチェーン・Web3分野の研究開発を行う専門のプロジェクトを発足し、ウォレットに関する特許を取得するなど、ブロックチェーン・Web3に関する取り組みを行っています。長年にわたるブロックチェーン・Web3関連の取り組みの実績を活かし、お客様のブロックチェーン・Web3ビジネスの検討やシステムの構築をサポートします。ご要望・ご不明点などがありましたら、ITソリューションサービスサイトよりお問い合わせください。
参考文献
（注1）go-ethereum
https://geth.ethereum.org/
（注2）Offchain Labs 「Prysm」
https://www.offchainlabs.com/prysm
（注3）go-ethereum 「Hardware requirements」
https://geth.ethereum.org/docs/getting-started/hardware-requirements
（注4）go-ethereum 「JavaScript Console」
https://geth.ethereum.org/docs/interacting-with-geth/javascript-console
（注5）Etherscan 「Sepolia Testnet Explorer」
https://sepolia.etherscan.io/
