私は普段から各大区分のブロックチェーンネットワークのインフラとシステム容量の制限をずっと精査していて、「集中期日」みたいな業務シナリオをスマートコントラクトが処理するときの並行処理(コンカレンシー)圧力がどれほど凄まじいかをよく知っています。TermMax公式は、数十万ユーザーに対して定められた時間内にロールオーバー(展期)とクローズ(決済・手仕舞い)を完了させることを、さも簡単そうに軽く扱っていますが、EVM(イーサリアム仮想マシン)という基盤のレイヤーではフロントエンドのボタンをクリックするのとはわけが違います。
借入プロトコルの展期では、裏側で古い債務の返済、利息の精算、担保率の再計算、さらに別のコントラクトをまたいで流動性プールを呼び出し直すこと、最後に新しい債務の証憑(証明書)を再ミントすることなど、極めて複雑な一連のスマートコントラクト呼び出しが関与します。公式は「登録ウォレット150万」「日次アクティブ9万」をもって、8月25日のTGEの熱を証明したいようですが、私の見立てでは、この種の高い稼働率は、集中期日にはむしろシステム災害になり得ます。
例えばこの数日、ちょうどマクロが激しく揺れている最中に、大量のユーザーが同時に展期またはクローズの要求を出したとしたら、この連鎖的なトランザクションは一瞬で当該ネットワークのGasコストを爆発させます。しかも、それだけではありません。オラクルの価格提示(喂価)にたとえ数秒の遅延が生じたり、オンチェーンの状態がタイムリーに同期されなかったりするだけで、ユーザーの清算または展期のリクエストはスリッページ保護(許容誤差)によって広範囲にRevert(ロールバック)されます。画面では操作が成功したように見えても、実際のオンチェーンでは失敗している。さらに天文学的な手数料まであなたから取られるのです。
私の判断: 借入プロトコルは追い風の局面だけでインタラクション体験を競うべきではありません。TGEの直前、私が最も気にしているのは、極限の混雑状態で清算エンジンがどれほどリバート率(回転率)を抑えられるかです。もしネットワークのGasコストが10倍に跳ね上がっても、大口のクローズ注文を100%成功させられないなら、このいわゆる「ワンタップ操作」は時限爆弾にほかなりません。実行品質が担保できないなら、いくら華麗なデータを並べても素人を騙せるだけです。#termmax @TermMax $ETH
借入プロトコルの展期では、裏側で古い債務の返済、利息の精算、担保率の再計算、さらに別のコントラクトをまたいで流動性プールを呼び出し直すこと、最後に新しい債務の証憑(証明書)を再ミントすることなど、極めて複雑な一連のスマートコントラクト呼び出しが関与します。公式は「登録ウォレット150万」「日次アクティブ9万」をもって、8月25日のTGEの熱を証明したいようですが、私の見立てでは、この種の高い稼働率は、集中期日にはむしろシステム災害になり得ます。
例えばこの数日、ちょうどマクロが激しく揺れている最中に、大量のユーザーが同時に展期またはクローズの要求を出したとしたら、この連鎖的なトランザクションは一瞬で当該ネットワークのGasコストを爆発させます。しかも、それだけではありません。オラクルの価格提示(喂価)にたとえ数秒の遅延が生じたり、オンチェーンの状態がタイムリーに同期されなかったりするだけで、ユーザーの清算または展期のリクエストはスリッページ保護(許容誤差)によって広範囲にRevert(ロールバック)されます。画面では操作が成功したように見えても、実際のオンチェーンでは失敗している。さらに天文学的な手数料まであなたから取られるのです。
私の判断: 借入プロトコルは追い風の局面だけでインタラクション体験を競うべきではありません。TGEの直前、私が最も気にしているのは、極限の混雑状態で清算エンジンがどれほどリバート率(回転率)を抑えられるかです。もしネットワークのGasコストが10倍に跳ね上がっても、大口のクローズ注文を100%成功させられないなら、このいわゆる「ワンタップ操作」は時限爆弾にほかなりません。実行品質が担保できないなら、いくら華麗なデータを並べても素人を騙せるだけです。#termmax @TermMax $ETH