Balancer V3はアーキテクチャ設計に大きな調整を加えました——複雑なロジックを流動性プールから金庫層に移動させました。現在、プールはシンプルなままで、3つのコア関数を実装するだけです:onSwapは取引計算を担当し、computeInvariantはプールの一定関数を処理し、computeBalanceは操作後の残高を管理します。このように変更することで、カスタムAMM戦略の開発ハードルが直接下がり、以前は数ヶ月かけてさまざまな細部と格闘していたのが、開発者にとってはずっと友好的になりました。アーキテクチャの最適化により、DeFiのイノベーションのスピードも追いつくことができるようになっています。

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • 8
  • リポスト
  • 共有
コメント
0/400
GasOptimizervip
· 7時間前
バランサーがこの一連のロジックを金庫層に落とし込むのは賢明に見えるが、実際の問題は——こうして分割した場合、単一の呼び出しのgas消費が逆に増えるのではないか?三つのコア関数はシンプルに聞こえるが、実際には層をまたぐインタラクションのオーバーヘッドを計算しなければならない。
原文表示返信0
Liquidated_Larryvip
· 01-14 21:09
くそっ、これが本来あるべき姿だ。以前のあのロジックはクソみたいに積み重ねられていたのに、今や3つの関数に簡素化された?開発者はやっと一息つけるな
原文表示返信0
SignatureVerifiervip
· 01-14 21:08
いや、3つの機能は紙の上では良さそうだけど…実際に誰もまだボールト層の影響をストレステストしていないのかな?正直なところ、ただ複雑さを移動させているだけで、実際にはそれを排除していない気がする
原文表示返信0
SlowLearnerWangvip
· 01-14 21:08
えっと...今になってBalancerがもうこんな風にやっていたことに気づいた。私はまだ古いバージョンについて考えていたのに
原文表示返信0
RetailTherapistvip
· 01-14 21:08
ああ、これで開発者は手を抜くことができる。細かい部分に悩まされて崩壊する必要がなくなる。V3のこのアーキテクチャの簡素化は本当に賢明だ。
原文表示返信0
ZenZKPlayervip
· 01-14 21:04
本当ですか?3つの関数だけで解決できるのですか?もし本当なら、誰もがAMMを改造できることになりませんか?ちょっと簡略化しすぎている気がします。
原文表示返信0
GateUser-5854de8bvip
· 01-14 21:01
くそ、やっとこの塊を整理できた。以前のアーキテクチャは本当に頭が痛くなるほどだった
原文表示返信0
SwapWhisperervip
· 01-14 20:59
ああ、ついに誰かがプールをシンプルにしてくれたね。以前のやつは本当に複雑すぎた。
原文表示返信0
  • ピン