私はいつも金庫ツールに対して抱くのと同じ疑問を持ちながら、ニュートンを読んでいました。

何ができるのかではありません。

彼らは古いワークフローのどれくらいを維持しているのか。

そこから、VaultKitが私にとって別物のように感じ始めました。

ドキュメントではTypeScriptのSDKと、それに伴うSolidityのコントラクトが説明されていますが、印象に残ったのはもっと小さな部分でした。キュレーターは、すでに知っている金庫のフローを使い続けられます。一方で、それぞれのアクションはShieldクローンに包まれ、金庫が呼び出しを受ける前にNewtonのポリシー・アテステーションを通過します。

とても特定の種類の設計です。

金庫の管理を、見た目上新しくするために「新しくしよう」とはしていません。チームが自分たちの全スタックを作り直さないまま、間違えにくくすることを狙っています。

ここにあるのは、まさにその緊張関係だと思います。

DeFiの金庫では、特に機関投資家の資金が絡む場合、紙の上のルールだけが問題になることは、ほとんどありません。難しいのは、そのルールが金庫が動くたびに確実に実行されるようにすることです。Newtonは、その約束をキュレーターから実行パスそのものへ移そうとしています。

だからこそ、ワークフローが非常に重要です。

システムはShieldFactoryによって、キュレーターごとの決定論的なクローンを使い、Newtonはポリシーレイヤーがmainnet betaで稼働していると述べています。つまり、これはブログ記事の中で語られる「良いアイデア」ではなく、金庫が動く前に立ちはだかるゲートを中心に組み立てられたワークフローです。

ただ、それでもトレードオフはあります。

摩擦が少ないことは、マネージャーがそのアテステーション経路を十分信頼できる場合にだけ良い。ワークフローが重く感じたり、ゲートが余計なオーバーヘッドに感じられたりすると、人々は結局、すでに知っているやり方に留まります。

私はそこを見ていきたい。

金庫のコンプライアンスが良さそうに聞こえるかどうかではありません。

VaultKitがコンプライアンスを「ワークフローのアップグレード」として感じさせるのか、それとも「ワークフローの税金」として感じさせるのか。

ここで私がニュートンを読み解くうえで一番すっきりしているのは、この捉え方です。金庫のマネージャーがルールを持つべきかどうかが問題なのではありません。問題は、そのルールが、すでに使っているのと同じフローの中に置けるのか、それとも、すべての動きを突破するための新しいプロセスに変えてしまうのか、ということです。
@NewtonProtocol #newt $NEWT