XRP LedgerはついにfixDirectoryLimit改正案を実装し、台帳上の特定リストに保存できるアイテム数に関する古い「ハードキャップ」を撤廃しました。
これまで、1つのリストが長くなりすぎると、ネットワークは新しいアイテムの追加をブロックしていました。これは、ユーザーが十分なXRPを持っていても発生していました。
今では、その恣意的な制限はなくなり、ネットワークはスパム防止のためにReserves（オブジェクトを作成するためにロックするXRP）に依存するようになりました。
なぜこれは重要なのか
ディレクトリをファイリングキャビネットの特定のフォルダーと考えてみてください。XRPLはディレクトリを使って類似のものをまとめています。最も一般的な例はオーダーブックです。
もし500人が全員、ちょうど$2.50でXRPを買いたい場合、台帳はその500件のオファーをすべて、その価格帯の「ディレクトリ」にまとめます。
以前は、このフォルダーが持てる「ページ」数にハードリミットがありました。
もし特定の価格帯（$2.50）が非常に人気となり、何千ものオファーが殺到した場合、ディレクトリは事実上「満杯」になる可能性がありました。
ユーザーはtecDIR_FULLのようなエラーコードを受け取ることがありました。これは、その特定の「フォルダー」が技術的に満杯であるために、有効な取引が失敗することを意味していました。
この改正案により、この制限は削除されました。ネットワークはスパムを防ぐためにハードコードされた制限を必要としません。なぜなら、すでに「Owner Reserves」があるからです。オファーやオブジェクトを作成するにはXRPをロックする必要があります。この経済的コストが、無限にオブジェクトをスパムすることを防ぎます。
バリデーターは、ディレクトリページが「満杯」かどうかを確認するためにリソースを無駄にする必要がなくなりました。
一方、トレーダーやアプリは、トラフィックが多い時に予期せぬtecDIR_FULLエラーに遭遇することがなくなります。
忙しい一年
今年はXRPLにとって忙しい一年でした。これは今年最初の大きな改正案でした。Automated Market Maker（AMM）プール向けに特化した「clawback」機能が追加されました。ネットワークはDynamicNFT機能も導入し、ノンファンジブルトークンが破棄や再発行を必要とせず、時間とともにメタデータを更新できるようになりました。
