#termmax @TermMax ...私はTermMaxの最新V2の修正点を見ていて、あることがずっと気になっていました。
以前は、多くのDeFiのバグは不適切な数学に行き着くものだと思っていました。
でも今回は、数学は概ね大丈夫でした。
より大きな問題は、現実の捉え方が違っていたことです。
たとえばapr()です。
旧ロジックは注文の生のXT残高を見ていました。
それは一見もっともに聞こえますよね?
しかしV2は価格状態として生のXT残高を使いません。
virtualXtReserveを使います。
この違いは重要です...
たとえば、値札の価格が店の内部台帳で管理されている店を想像してください。でも、あなたは誰かがたまたまカウンターに置いた現金の量から値段を計算し始めます。
現金は変わります。
でも価格モデルは変わりません。
それが、直接のXT送金が旧APR計算にできてしまうことの正体です。
残高は動くのにカーブは動かず、それでもapr()はその残高を新しい価格状態として扱うことがあり得ます。
今回の修正は、会計モデルが経済モデルに一致するようにしています。
そして、私はこのほうがより面白い教訓だと思います。
金融のスマートコントラクトでは、危険な問いがいつも:
「式は正しいか?」
とは限りません。
場合によっては:
「式に与えているのは、正しい状態か?」
です。
同じテーマは清算の修正にも現れます。
18桁の負債オラクルが、16進のような小数変換で担保の比較を崩してしまえば、本来50%の清算で済むはずのポジションが、満額清算になってしまう可能性があります。
繰り返しますが、これは本当に複雑な式の問題ではありません。
単位(ユニット)の問題でした。
だから私は、見た目は退屈そうな変更にもっと注意を払い始めています。
1行の会計修正は、派手な新機能よりも重要になり得ます。
それは、そのプロトコルが市場を正しく解釈しているかどうかを左右するからです。
TermMaxについて、ここから注意して見ていくなら次の1点です:
システムが持つ流動性の量だけでなく、価格設定、担保評価、そして清算ロジックがすべて同じ経済的現実を読み取っているかどうか.....
そこから「コードが動く」が「金融インフラが動く」へと変わっていきます。
あなたなら、まず式を監査しますか? まず会計状態を監査しますか? それともまずオラクル/単位の前提を監査しますか?....
以前は、多くのDeFiのバグは不適切な数学に行き着くものだと思っていました。
でも今回は、数学は概ね大丈夫でした。
より大きな問題は、現実の捉え方が違っていたことです。
たとえばapr()です。
旧ロジックは注文の生のXT残高を見ていました。
それは一見もっともに聞こえますよね?
しかしV2は価格状態として生のXT残高を使いません。
virtualXtReserveを使います。
この違いは重要です...
たとえば、値札の価格が店の内部台帳で管理されている店を想像してください。でも、あなたは誰かがたまたまカウンターに置いた現金の量から値段を計算し始めます。
現金は変わります。
でも価格モデルは変わりません。
それが、直接のXT送金が旧APR計算にできてしまうことの正体です。
残高は動くのにカーブは動かず、それでもapr()はその残高を新しい価格状態として扱うことがあり得ます。
今回の修正は、会計モデルが経済モデルに一致するようにしています。
そして、私はこのほうがより面白い教訓だと思います。
金融のスマートコントラクトでは、危険な問いがいつも:
「式は正しいか?」
とは限りません。
場合によっては:
「式に与えているのは、正しい状態か?」
です。
同じテーマは清算の修正にも現れます。
18桁の負債オラクルが、16進のような小数変換で担保の比較を崩してしまえば、本来50%の清算で済むはずのポジションが、満額清算になってしまう可能性があります。
繰り返しますが、これは本当に複雑な式の問題ではありません。
単位(ユニット)の問題でした。
だから私は、見た目は退屈そうな変更にもっと注意を払い始めています。
1行の会計修正は、派手な新機能よりも重要になり得ます。
それは、そのプロトコルが市場を正しく解釈しているかどうかを左右するからです。
TermMaxについて、ここから注意して見ていくなら次の1点です:
システムが持つ流動性の量だけでなく、価格設定、担保評価、そして清算ロジックがすべて同じ経済的現実を読み取っているかどうか.....
そこから「コードが動く」が「金融インフラが動く」へと変わっていきます。
あなたなら、まず式を監査しますか? まず会計状態を監査しますか? それともまずオラクル/単位の前提を監査しますか?....
