---
title: "Polygonアーカイブノードの制限に備える方法"
description: "Polygonアーカイブノードは16TBのストレージ上限に近づいています。アーカイブリクエストが失敗し始める前に準備しておくべき4つの方法を紹介します。"
---

# Polygonアーカイブノードの制限に備える方法

[Polygonエコシステム](https://www.alchemy.com/dapps/ecosystem/polygon)の最近の成長により、[GETH](https://www.alchemy.com/overviews/what-is-a-geth-node-and-how-to-run-one)クライアントで動作するPolygonアーカイブノードは16TBのストレージ閾値を超えることが見込まれています。

まだストレージサイズをアップグレードしていない場合、このPolygonアーカイブノードの制限により、アーカイブノードが機能しなくなる可能性があります。

本記事では、なぜこの問題が発生するのか、そして迫りくるPolygonアーカイブノードの制限にどう備えるべきかを説明します。

## Polygonアーカイブノードの制限にはいつ達するのか？

###### Polygonアーカイブノードの制限には5/23の週に達する見込みです。

16TBの閾値を超える正確な日時は、次の2つの要因によって決まります。

1. アーカイブノードがどれだけ稼働してきたか
1. 16TBがどのように計算されるか

re-orgが多く発生するノードほどディスク容量を多く消費し、16TBは16,000GBまたは16,384GBのいずれかとして計算されるため、この差はおおよそ1週間で埋まります。

###### なぜストレージ制限を引き上げるのか？

Polygonチェーンは2020年6月の初期ローンチ以来、[著しい成長](https://www.alchemy.com/case-study/polygon)を遂げてきました。その結果、Polygonのブロックチェーン全体の履歴のコピーを保持する必要があるアーカイブノード運用者は、そのすべてのデータをアーカイブノードに保存しなければなりません。

Polygonは16TBを超える最初のチェーンの一つですが、他のチェーンエコシステムも成長を続けるにつれ、間もなく同様の課題に直面することになります。そのため、現在Polygonを利用していない場合でも、備え方を知るために読み進めることをお勧めします。

## 16TBのストレージ制限はPolygonアーカイブノードにとって何を意味するのか？

多くのクラウドホスティングプロバイダーにとって、16TBのストレージ制限は一般的なものです。Polygonアーカイブノード向けに大規模なディスク容量とインフラを準備していない限り、この制限に達した後はデータの提供ができなくなる可能性が高いです。

###### つまり、すべてのアーカイブリクエストが失敗し始めるということです。

### なぜアーカイブデータが必要なのか？

アーカイブデータにより、単に[Polygonの過去のトランザクションを取得する](https://alchemy.com/blog/how-to-get-historical-transactions-on-polygon)だけでなく、ブロックチェーン全体の履歴にアクセスできるようになります。これは以下のようなデータを表示する上で非常に重要です。

1. ウォレットのトランザクション履歴
1. トレンドと分析
1. インデックス化されたデータ
1. その他、過去のデータを参照するあらゆる用途

## Polygonアーカイブノードの制限に備える4つの方法

短期・中期・長期のどれを最適化したいかに応じて、いくつかの選択肢があります。それぞれ順番に説明します。

### 1. ノードを削除して再同期する（短期）

ノードを削除して再同期することで、uncleブロックなど、正規チェーンの一部ではなくなったデータを一掃できます。

Polygonノードの削除と再同期は比較的簡単ですが、新しいデータが解放されたストレージ領域を再び埋めていくため、あくまで一時的なつなぎの解決策にすぎません。

### 2. Logical Volume Management（LVM）またはRAID0を使ってより多くのストレージ容量を管理する（中期）

[LVM](https://www.digitalocean.com/community/tutorials/an-introduction-to-lvm-concepts-terminology-and-operations)（およびRAID0）を使うと、複数のディスクからのストレージを1つのファイルシステムに割り当て、単一ディスクの最大容量の制限を回避できます。

これは簡単な作業ではありませんが、ノード運用者は既存のEC2インスタンスタイプやEBSボリュームタイプを使い続けながら、必要に応じてディスクパーティションをスケールアップできるようになります。

代替案として、AWSは最大64TBのディスク容量をサポートする新しいEBSボリュームタイプ、[io2 block express](https://aws.amazon.com/about-aws/whats-new/2021/07/aws-announces-general-availability-amazon-ebs-block-express-volumes/)をリリースしました。ただし、これは新しい_r5b_ EC2インスタンスタイプに限定されており、この種のディスク容量問題を解決するには一般的に「オーバースペック」だと考えられています。

### 3. PolygonノードクライアントをErigonに切り替える（長期）

ErigonはBorコンセンサスをネイティブにサポートするノードクライアントの選択肢であり、Polygon/MATICブロックチェーンと互換性があります。比較として、Erigonを使用した場合のPolygon Proof of Stakeメインネットのステートデータは、わずか4.5TBほどに収まります。

Polygon向けに[Erigonクライアントをセットアップする](https://github.com/ledgerwatch/erigon)ことは長期的な解決策ですが、より管理しやすいステートデータを実現できます。

### 4. PolygonのノードインフラプロバイダーとしてAlchemyを使う

Alchemyチームは、[Polygon APIを使った開発](https://www.alchemy.com/docs/reference/polygon-pos-api-quickstart)をはじめ、Alchemyがサポートするあらゆるチェーンにおいて、ユーザーがスムーズで信頼性の高い体験を得られるよう日夜取り組んでいます。

すべてのアップグレードや破壊的変更への対応はAlchemyが行うため、ユーザー側で対応する必要はありません。しかも無料です。[こちらからサインアップ](https://alchemy.com/?a=830b94adba)すれば、数分でAlchemyの利用を開始できます。

最新情報やヒント、新機能のリリースについては、Twitterの[@Alchemy](https://x.com/Alchemy)をフォローしてください。