
Celestiaスクリプト作成後の感想:Cosmosの多くの作業がうまく行われていない
TechFlow厳選深潮セレクト

Celestiaスクリプト作成後の感想:Cosmosの多くの作業がうまく行われていない
Celestiaは当時、大規模なトラフィックへの対策を確実に講じていなかったし、RPCノードの設定も適当だった。
執筆:霧月、Geek Web3
12月17日、Celestia上でインスクリプション「CIAS」が発生すると知り、急いでインスクリプションを刷るためのスクリプトを作成しようと考えた。現在、Celestiaおよびその属するCosmosエコシステム、そしてCIASイベント自体について、多くの不満がある。
実際、インスクリプションを刷るスクリプトを作るのは難しくない。主に3つのモジュールに分けられる:ウォレット構築、ノード接続、トランザクションのフラッディング。最初の2ステップは、対象ブロックチェーンの開発者ドキュメントを見れば、すぐに実装方法が見つかる。
まずCelestiaの公式サイトとGitHubを調べたが、開発者がユーザー向けのユースケースを構築するための資料はほとんどなく、主にノード運営に関するドキュメントばかりだった。もちろんこれは理解できる。CelestiaはToC向けのブロックチェーンではないからだ。Celestiaは目立たない場所で、自分はCosmosベースであり、CosmJSを使ってメインネットとやり取りできるとだけ言及している。
そこで私はすぐさまCosmJSに向かった。しかしCosmosはどうだろうか、ドキュメントすらまともに作れていない。普通ならGitHubにJSライブラリがあれば使用例があるはずだが、そのチュートリアルは二次ページの奥深くに隠されており、設定に従ってやっても最後にエラーが出る。
このエラーは環境の問題ではなく、チュートリアルがバージョンアップに追随していないためだ。クラス名が変わったり、呼び出せなくなったりすることが頻繁にある。古いチュートリアルに基づいてnpmライブラリのバージョンを切り替えても、一部のサンプルコードは依然として動作せず、しばらく試行錯誤した後、諦めた。
そこでグーグル検索してみたところ、正しいドキュメントはGitHubではなく公式サイトにあった。これは常識的ではない。それにしても、GitHubのreadmeに公式サイトへのリンクを追加するのはそんなに難しいことではないだろうか?
正しいチュートリアルを得て、ウォレット構築とノード接続の2ステップを素早く完了し、次にフラッディング用トランザクションモジュールの構築に移った。このモジュールは単純に言えば、トランザクション署理+ネットワークリクエストのforループである。しかし、ここでもいくつかの問題に直面した:
CosmJSライブラリ内のすべてのトランザクションメソッドは、トランザクション自体のパラメータしか公開していない。sequence(シークエンス)が公開されていないのだ。(sequenceはイーサリアムのnonceに類似しており、リプレイ攻撃を防ぐためのトランザクションカウンターで、各トランザクション送信後にnonceやsequenceは自動的に+1される)。

Sequenceはsign署名時にネットワークに接続して取得する方式(chainIdなども同様)であり、sendTokens() → signAndBroadCast → sign()という流れになる。毎回トランザクション送信時にネットワークリクエストをして応答を待つのは、刷りスピードに悪影響を与え、無駄なネットワークリクエストも増える。フラッディングには不利だし、トランザクションの加速/キャンセルも困難になる。

イーサリアムのWeb3JSにおけるトランザクション送信メソッドを振り返ると、nonceを自分で指定できる。しかしCosmJSではできない。やはりイーサリアムの設計の方が合理的だと思う。nonceを直接指定することで、トランザクションのキャンセル/加速が可能になる。あるトランザクションが詰まった場合、同じnonceを持つ別のトランザクションで置き換えることができる。もちろん、フラッディング攻撃にも利用できる。

時間があまりなかったため、修正が必要な他の関数もある中、Proxyを使ってhookして書き換えるのはやめ、CosmJSライブラリを直接改変することにした。
スクリプトによるフラッディングの仕組みは、forループで繰り返しトランザクションを発行し署名を生成してRPCノードに送信する。1回トランザクションを発行するごとにsequence/nonceが+1され、20回発行した後、再びループを繰り返す。
Sequenceは各フラッディングサイクル開始前に一度だけローカルに取得すればよく、CosmJSライブラリのデフォルトのように、毎回トランザクション後にノードに再度リクエストする必要はない。またchainIdは固定値として記述し、繰り返しノードにリクエストしない。(編集注:ここで設定されたループ回数は比較的低い。明らかに作者はまだそれほど過激ではない。ある人物がConfluxのインスクリプションを打つ際、1サイクルあたりのループ回数を1000に変更し、1分間に約200件の異なるトランザクションを送信していた)

最終的に、簡素なCelestia用スクリプトが完成した。12月17日夜、CIASがネット切断された後、このスクリプトで数百件のトランザクションをテスト送信した。12月19日未明、CIASが再開された際、実際にいくつかのCIAS(約1800個)を獲得できた。しかし、それでも不満は残る:
-
12月17日、CelestiaのRPCノードはデータの同期が深刻に乱れる問題が発生した。異なるRPCノード間のブロック高さに大きな差があり、自分のアカウントのSequenceをリクエストしても返ってくる値がほぼ一致しなかった。非常に苦痛だった。Celestiaのブロックエクスプローラーも使用不能になり、ほぼ手探り状態だった。つまり、Celestiaネットワークは停止こそしていなかったが、ブロックは生成できても、すでに限界に近づいていたと言える。
-
当日、CIASインスクリプションの運営側はCelestiaが持ちそうになくなるのを見て、48460番目のブロック高さ以降に登録されたインスクリプション取引をすべて無効とする臨時発表を行った。まるで「取引所がネット切断」するような雰囲気だ。さらにCIAS自身のウェブサイトもダウンした。

-
ある人々は、Cosmosチェーンのネイティブコンセンサスプロトコルがブロックのコンセンサス処理において非常に劣っていると指摘しているが、これについては評価しない。ただ、昨夜のCIASによるネット切断の目的は興味深いものがある。
-
12月17日、同期データが最も速いノードを選ぶのは極めて困難だった。なぜならほぼすべてのRPCノードがパンク状態になり、頻繁に応答不能になったからだ。その後、自動的にノードを切り替えるコードをいくつか書いてみた。
-
CIAS自体のインスクリプション形式は他のインスクリプションとは少し異なり、例えばbrc-20のjsonではすべての数字が文字列だが、cia-20では数字そのものになっている。

-
CIASインスクリプションのコストは昨夜ピーク時に1枚あたり1.5~2Uまで暴騰し、中には80U払って1枚のインスクリプションを打った人もいる。この高い手数料はTPSが限定されていることを示している。Celestiaの創業者は1秒間に1万件のトランザクションを処理できると自称しているが、明らかに誇張だ。

総合的に見ると、12月17日の夜の体験を一言で言えば、「Celestiaは大規模トラフィックへの備えがまったくできていなかった。RPCノードの設定もいい加減だった」(数十台のRPCノードが1時間でパンクするなど、到底想像しにくい)。
19日深夜には状況はかなり改善され、ガス代の高騰以外は大きな問題はなかった。Celestiaが軽ノード向けにデータ配信を行うDAネットワークとしては、一時的に試練を乗り越えたと言えるが、今後また別の落とし穴があるかどうかは分からない。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News









