アーカイブ ノード: ノード セットアップの頂点

Running an archive node for a blockchain like Ethereum or Polygon is an undertaking that’s both labor-intensive and costly. It’s more or less the pinnacle of node setups. The node will require good hardware, maintenance (i.e., good monitoring), and also time—at least whenever monitoring kicks in or a new release is due. Typically, one will only take this on for a specific reason.

Ethereum や Polygon などのブロックチェーンのアーカイブ ノードを実行するのは、労力もコストもかかる作業です。これは、多かれ少なかれ、ノード設定の頂点です。ノードには、少なくとも監視が開始されるとき、または新しいリリースが予定されているときは常に、適切なハードウェア、メンテナンス (つまり、適切な監視)、および時間も必要になります。通常、これを引き受けるのは特定の理由がある場合のみです。

An archive node is more than a full node. A full node “only” stores the entire blockchain, whereas an archive node additionally stores every state that each smart contract and transaction ever had (i.e., at every block height). However, the additional data of an archive node can be reconstructed from the data of a full node.

アーカイブ ノードは完全なノード以上のものです。フル ノードはブロックチェーン全体を「のみ」保存しますが、アーカイブ ノードは、各スマート コントラクトとトランザクションがこれまでに持っていたすべての状態 (つまり、すべてのブロックの高さ) をさらに保存します。ただし、アーカイブ ノードの追加データは、フル ノードのデータから再構築できます。

Since this often leads to discussions on Twitter or online forums, I like to bring an analogy to Bitcoin: An archive node for Ethereum is akin to a Bitcoin node that stores the UTXO (Unspent Transaction Output) set valid at every block height. This isn’t particularly interesting for Bitcoin because (a) these data can be reconstructed much faster and (b) they don’t hold any special informational value. It’s different with Ethereum because there are smart contracts whose intermediate states are stored, making it possible to directly query, for example, how much USDT an account had at any given time (block height).

これはしばしば Twitter やオンライン フォーラムでの議論につながるため、私はビットコインに例えたいと思います。イーサリアムのアーカイブ ノードは、すべてのブロックの高さで有効な UTXO (未使用トランザクション出力) セットを保存するビットコイン ノードに似ています。 (a) これらのデータははるかに高速に再構築でき、(b) 特別な情報価値を保持しないため、これはビットコインにとって特に興味深いものではありません。イーサリアムの場合は、中間状態が保存されているスマート コントラクトがあり、たとえば、特定の時点でアカウントにどれだけの USDT があったのか (ブロックの高さ) を直接クエリできるため、異なります。

I synchronized my first archive node for the Ethereum ecosystem in 2019. It was out of pure curiosity: I had purchased a lot of server hardware for a project (96 cores, 768 GiB RAM, over 40 TiB SSD storage) and wanted to push it to the limit. So, I synchronized an archive node for Ethereum using geth, which took exactly 7 days and 22 hours. I still remember it so precisely because I discussed the topic on coinforum.de and documented my progress.

私は 2019 年にイーサリアム エコシステムの最初のアーカイブ ノードを同期しました。それは純粋な好奇心からでした。プロジェクト用に大量のサーバー ハードウェア (96 コア、768 GiB RAM、40 TiB 以上の SSD ストレージ) を購入しており、それをプッシュしたかったのです。限界まで。そこで、geth を使用して Ethereum のアーカイブ ノードを同期しました。これにはちょうど 7 日と 22 時間かかりました。今でもそのことをはっきりと覚えているのは、coinforum.de でこのトピックについて議論し、自分の進捗状況を記録したからです。

Long-term, better reasons are needed. That’s a significant difference between Ethereum and Bitcoin. Bitcoiners synchronize the entire blockchain out of idealism. In Ethereum, most users utilize node providers like Infura or Alchemy. These providers allow roughly 100,000 free API calls, sufficient for smaller projects and wallets.

長期的な、より良い理由が必要です。それがイーサリアムとビットコインの大きな違いです。ビットコイナーは理想主義からブロックチェーン全体を同期させます。 Ethereum では、ほとんどのユーザーが Infura や Alchemy などのノード プロバイダーを利用します。これらのプロバイダーでは、約 100,000 回の無料 API 呼び出しが許可されており、小規模なプロジェクトやウォレットには十分です。

When and for whom is an archive node useful?

アーカイブ ノードはいつ、誰にとって役立つのでしょうか?

It becomes critical when one wants or needs to conduct blockchain analyses. If, for instance, you want to know which accounts held what amounts of a token on Ethereum at any time, you need to scan the blockchain block by block to find all addresses and then query the historical balances for each ERC20 transaction. This quickly exceeds the free API calls provided by Alchemy and Infura and can become expensive fast. In such cases, an archive node is worthwhile because scanning all blocks leads to as many API calls as there are blocks in the blockchain. Ethereum currently has over 20 million blocks.

ブロックチェーン分析を実行したい場合、または実行する必要がある場合、これは重要になります。たとえば、イーサリアム上でどのアカウントがどのくらいの量のトークンを保持していたかを常に知りたい場合は、ブロックチェーンをブロックごとにスキャンしてすべてのアドレスを見つけ、各 ERC20 トランザクションの履歴残高をクエリする必要があります。これは、Alchemy や Infura が提供する無料の API 呼び出しをすぐに超え、すぐに高価になる可能性があります。このような場合、すべてのブロックをスキャンすると、ブロックチェーン内のブロックと同じ数の API 呼び出しが行われるため、アーカイブ ノードは価値があります。イーサリアムには現在 2,000 万以上のブロックがあります。

I now operate such nodes for clients. The reasons can sometimes be absurd. For instance, a company offers assistance in complying with EU regulations, which require demonstrating the CO2 consumption for each crypto asset. If you have a token on Ethereum, you must trace back all past transactions and swaps to calculate the gas used by the token. The gas corresponds to the required computational power and thus serves as an indicator of CO2 consumption.

私は現在、クライアントのためにそのようなノードを運用しています。その理由は時には不合理である場合もあります。たとえば、ある企業は、各暗号資産の CO2 消費量の実証を義務付ける EU の規制に準拠するための支援を提供しています。イーサリアムにトークンをお持ちの場合は、過去のトランザクションとスワップをすべて遡って、トークンで使用されるガスを計算する必要があります。このガスは必要な計算能力に相当するため、CO2 消費量の指標として機能します。

This is, of course, ludicrous. As a Proof-of-Stake blockchain, Ethereum consumes very little energy, and synchronizing an archive node likely generates far more CO2 than you could ever save through the regulation (if at all). But it’s not my job to ask such questions, but rather to set up nodes.

もちろん、これはばかげています。 Proof-of-Stake ブロックチェーンとして、イーサリアムはほとんどエネルギーを消費せず、アーカイブ ノードの同期により、規制によって節約できるよりもはるかに多くの CO2 が生成される可能性があります (もしあったとしても)。しかし、そのような質問をするのは私の仕事ではなく、ノードを設定するのが仕事です。

What resources are needed to operate an Ethereum archive node?

Ethereum アーカイブ ノードを運用するにはどのようなリソースが必要ですか?

The differences between nodes and clients can be substantial. I have experience with Ethereum, Polygon, and Solana.

ノードとクライアントの違いは大きくなる可能性があります。私はイーサリアム、ポリゴン、ソラナの経験があります。

Using the Nethermind client, Ethereum requires about 15 terabytes of storage for the execution layer data, 8 CPU cores (preferably 16 for synchronization), and 128 gigabytes of RAM. An alternative client is Erigon, which requires only three terabytes of data. Erigon stores data differently than Nethermind, using a flat architecture that only saves deltas between some blocks. This may result in slightly longer query times for historical data but saves a lot of space.

Nethermind クライアントを使用する場合、イーサリアムは実行層データ用に約 15 テラバイトのストレージ、8 個の CPU コア (同期用に 16 個が望ましい)、および 128 ギガバイトの RAM を必要とします。代替クライアントは Erigon で、必要なデータは 3 テラバイトのみです。 Erigon は Nethermind とは異なる方法でデータを保存し、一部のブロック間のデルタのみを保存するフラット アーキテクチャを使用します。これにより、履歴データのクエリ時間が若干長くなる可能性がありますが、多くのスペースが節約されます。

For a server, the demand is moderate. Once synchronized, less is needed. The biggest challenge is the hard drives, or rather the SSDs. To understand why, you must know how smart contracts work with the Ethereum Virtual Machine (EVM). I’ll keep it brief: Each smart contract has its own virtual memory space, which may load different parts depending on the account. This leads to numerous read and write operations (I/O) with each new block and during synchronization.

サーバーの場合、需要は中程度です。一度同期すると、必要なものは少なくなります。最大の課題はハードドライブ、あるいは SSD です。その理由を理解するには、スマート コントラクトがイーサリアム仮想マシン (EVM) とどのように連携するかを知る必要があります。簡単に説明します。各スマート コントラクトには独自の仮想メモリ空​​間があり、アカウントに応じて異なる部分をロードする可能性があります。これにより、新しいブロックごとおよび同期中に多数の読み取りおよび書き込み操作 (I/O) が発生します。

Therefore, traditional hard drives (HDDs) are outdated; SSDs are needed. Users of Nethermind must chain several SSDs together to store at least 15 terabytes. This can quickly cost a four-figure amount if

したがって、従来のハード ドライブ (HDD) は時代遅れです。 SSDが必要です。 Nethermind のユーザーは、少なくとも 15 テラバイトを保存するには、複数の SSD をチェーン接続する必要があります。これには、すぐに 4 桁の金額がかかる可能性があります。