寫完塞拉斯蒂亞文字，打出銘文后，他抱怨說：宇宙的基本功不紮實

作者：吳越，極客Web3

12月17日，我得知銘文CIAS即將在Celestia上發表，我打算臨時寫一個腳本來刷銘文。 現在，我對Celestia及其Cosmos生態系統以及CIAS事件本身有很多抱怨。

其實刷銘文的腳本編寫起來並不難，主要分為錢包構建、連接節點、泛洪交易三個模組。 **前兩個步驟只需要在目標公鏈的開發者文檔中找到，即可找到快速實現。

我先去Celestia官網和Github看了一下，沒有開發者搭建用戶場景的用例，主要是節點操作等相關文檔。 當然，這是可以理解的，因為Celestia不是ToC區塊鏈。 Celestia只是在一個不起眼的地方提到它基於Cosmos，並且可以通過CosmJS與其主網進行交互。

所以我直接去了CosmJS。 但是宇宙呢，它甚至不擅長文檔。 **我直接去了 Github，按照常識，一般這種 JS 會在 Github 上有一個用例。 但是它的教程隱藏在輔助頁面中，並且點擊后，按照它的配置做一個通過，最後報錯。

這個錯誤不是環境問題，是因為它的教程沒有用教程版本更新經常這個類的名字被更改而無法調優等等。 我在舊的教程版本上切換到了 npm 庫的版本，仍然有一些用例不起作用，所以我折騰了一段時間后放棄了。

所以我又用谷歌搜索了一下，結果發現正確的文檔在官方網站上，而不是 Github，這有點違反直覺。 **再說一遍，將 Github 自述檔教程更新到官方網站不是很好嗎？

拿到正確的教程后，我很快就完成了搭建錢包和連接節點兩步，開始搭建泛洪交易模組。 簡單來說，這個模組是一個處理交易簽名+網路請求的for迴圈。 但這裡有一些問題：

CosmJS 庫中的所有事務方法都只公開事務本身的參數，但不會公開其序列（序列類似於ETH車間中的隨機數，是為防止重放攻擊而設置的事務計數器，每次事務發出后，隨機數和序列自動 +1）。

序列實際上是它在簽名時連接到網路獲取它（chainId 等），並且它必須通過 sendTokens（） -> signAndBroadCast -> sign（）。 **每次提交交易都去網路請求並等待返回，會影響刷子的速度，也會增加無用的網路請求，這對泛洪不利，當然也不利於加速/取消交易。 **

讓我們回顧一下 ETH Web3JS 發送事務的方法，您可以在其中自己指定隨機數。 但不是在CosmJS中。 我還是覺得ETH方的設計要合理得多，可以直接指定隨機數來取消/加速事務，如果一個事務卡住了，你可以自定義一個具有相同事務的隨機數來替換卡住的事務，當然也可以用於我們的洪水攻擊。

由於時間限制，庫中還有其他幾個函數需要修改，** 我決定不使用 Proxy 來取消重寫，而是直接在 CosmJS 庫中修改它。 **

腳本觸發泛洪交易的思路是通過 for 迴圈不斷發起交易並生成簽名，發送到 RPC 節點，發起交易后，序列/隨機數為 +1，發起 20 個交易后，迴圈迴圈。

序列僅在每個洪水周期開始之前在本地拉取，並且無需在每個事務之後從節點重新請求序列，這是 CosmJS 庫中的預設值。 另一方面，chainId 被寫成一個固定值，不必從節點重複請求。 （編者注：這裡的循環次數設置得比較少，很明顯作者沒有那麼暴力。 有人在輸入 Conflux 銘文時，將每個週期的週期數更改為 1000，每分鐘發送大約 200 個不同的交易）

最終，我得到了一個基本的Celestia腳本，在12月17日晚上CIAS拔掉插頭后，我對其進行了簡短的測試，併發送了數百筆交易。 在12月19日淩晨CIAS恢復后，我確實擊中了一些CIAS（約1,800）。 但還有其他事情要抱怨：**

• 12 月 17 日，Celestia 的 RPC 節點出現了嚴重的數據不同步問題，不同 RPC 節點的區塊高度差異很大，當你請求節點到你帳戶的序列時，返回結果基本不一致，非常痛苦。 Celestia區塊瀏覽器也不可用，基本上是盲目的。 可以說，此時的Celestia網路雖然沒有宕機，依舊可以出區塊，但估計已經快到了極限。
• 當天，CIAS銘文官方看到Celestia快要忍無可忍了，臨時宣佈48460區塊高度后鏈上所有銘文鑄幣交易無效，頗有“拔掉交易所網線”的趨勢。 CIAS自己的網站崩潰了。

• 對於 Cosmos 鏈的原生共識協定在區塊共識方面做得很差的看法沒有評論，但很明顯，CIAS 昨晚拔出網線的目的很有趣。
• 在 12 月 17 日，很難選擇同步數據最快的節點，因為幾乎所有的 RPC 節點都過度擁擠並且經常無回應。 後來我嘗試編寫一些自動切換節點的代碼。
• CIAS本身的銘文格式與其他銘文不太一致，例如，在brc-20的json中，所有數位都是字串，而在CIA-20中則是一個數位。

*昨晚最高時，CIAS銘文的成本飆升至每枚銘文1.5~2U，甚至有人為一個銘文支付了80U。 如此高的費用反映了有限的TPS，Celestia的創始人聲稱他每秒可以處理10k筆交易，這顯然是無稽之談。

總體來說，12 月 17 日晚的經歷是一句話：Celestia 絕對沒有準備好應對大規模流量，在 RPC 節點配置方面非常敷衍（很難想像 1 小時內可以炸毀數十個 RPC 節點）。 **

19日晚，情況好多了，除了油費飆升之外，其他方面也沒什麼大問題，只能說Celestia作為專門向輕節點分發數據的DA網路，暫時經受住了考驗，但不知道以後還會不會有其他陷阱。