Binance Square
#shareyouropinion

shareyouropinion

閲覧回数 9,040
35人が討論中
Mirza_X_Mustafa
·
--
確認済み
昨夜、以前の透明性レポートを見つけたのですが、私はそれを読んだことがなく、その内容がニュートン(Newton)が実際に何なのかという理解を変えてしまいました。ニュートンはそもそも、最初からコンプライアンス目的のポリシーエンジンとして設計されたものではありません。 2025年10月の開示では、元々の設計は、鍵管理に向けた「キーストア・ロールアップ」であり、AIエージェントのための検証可能な自動化と、委任された認可(delegated authorization)に特化していたと説明されています。 中核となる考え方は、鍵管理インフラに結びついた、暗号学的に検証された権限を通じて、エージェントがオンチェーン上のアクションを実行できるようにすることでした。 転機は、チームが、同じ基盤となるプリミティブ(検証可能な自動化、委任された認可)が、エージェントの鍵管理の枠を大きく超えて、ステーブルコイン、RWA、そしてより広い資産市場にまたがる一般的なポリシー執行のための枠組みへと拡張できることに気づいたときに訪れました。 キーストア・ロールアップは、より大きなものの基盤となりました。つまり、「どのような条件のもとで、どのようなアテステーション(証明)を伴って、どんなアクションが起こり得るのか」を統治するポリシーエンジンです。 これは、私が最初に読んだホワイトペーパーが示唆していたものとは、意味のある点で出発点がまったく異なります。 私は、この歴史はニュートンのアーキテクチャ上の選択――BLSアテステーションのモデル、オペレーター・クォーラムの設計、ユースケースとしてのエージェントのコマースへの重視――を理解するうえで重要だと思っています。これらは、コンプライアンス最優先の設計判断ではありません。鍵管理とエージェントの認可の設計判断が、その後にコンプライアンスのユースケースへと一般化されたのです。 まだ整理できていないのは、現在のアーキテクチャのうち、どれほどが、コンプライアンス最優先のポリシーエンジンにとって最適とは限らない、元のキーストア・ロールアップ設計の前提を引き継いでいるのか、という点です。転機がきれいな再設計だったのか、それとも元の技術的基盤の拡張だったのか――それも含めて、どこまで分かっていない状況です。 #ShareYourOpinion $EVAA $LAB ニュートンのアーキテクチャはどのように進化していったと思いますか? @NewtonProtocol $NEWT #Newt
昨夜、以前の透明性レポートを見つけたのですが、私はそれを読んだことがなく、その内容がニュートン(Newton)が実際に何なのかという理解を変えてしまいました。ニュートンはそもそも、最初からコンプライアンス目的のポリシーエンジンとして設計されたものではありません。

2025年10月の開示では、元々の設計は、鍵管理に向けた「キーストア・ロールアップ」であり、AIエージェントのための検証可能な自動化と、委任された認可(delegated authorization)に特化していたと説明されています。

中核となる考え方は、鍵管理インフラに結びついた、暗号学的に検証された権限を通じて、エージェントがオンチェーン上のアクションを実行できるようにすることでした。

転機は、チームが、同じ基盤となるプリミティブ(検証可能な自動化、委任された認可)が、エージェントの鍵管理の枠を大きく超えて、ステーブルコイン、RWA、そしてより広い資産市場にまたがる一般的なポリシー執行のための枠組みへと拡張できることに気づいたときに訪れました。

キーストア・ロールアップは、より大きなものの基盤となりました。つまり、「どのような条件のもとで、どのようなアテステーション(証明)を伴って、どんなアクションが起こり得るのか」を統治するポリシーエンジンです。

これは、私が最初に読んだホワイトペーパーが示唆していたものとは、意味のある点で出発点がまったく異なります。

私は、この歴史はニュートンのアーキテクチャ上の選択――BLSアテステーションのモデル、オペレーター・クォーラムの設計、ユースケースとしてのエージェントのコマースへの重視――を理解するうえで重要だと思っています。これらは、コンプライアンス最優先の設計判断ではありません。鍵管理とエージェントの認可の設計判断が、その後にコンプライアンスのユースケースへと一般化されたのです。

まだ整理できていないのは、現在のアーキテクチャのうち、どれほどが、コンプライアンス最優先のポリシーエンジンにとって最適とは限らない、元のキーストア・ロールアップ設計の前提を引き継いでいるのか、という点です。転機がきれいな再設計だったのか、それとも元の技術的基盤の拡張だったのか――それも含めて、どこまで分かっていない状況です。
#ShareYourOpinion
$EVAA $LAB
ニュートンのアーキテクチャはどのように進化していったと思いますか?
@NewtonProtocol $NEWT #Newt
Original design mostly remaine
0%
Major redesign after the pivot
0%
A blend of both approaches
33%
Not enough information yet
67%
3 投票 • 投票は終了しました
ニュートンのクレデンシャル・モデルにおける責任ギャップと、従来のKYC/AML運用の現実 先週、規制を受けた企業でKYCプログラムを運営しているコンプライアンス担当の友人と、ニュートンの本人確認(アイデンティティ)モデルを一緒に検証したところ、ニュートンが説明していることと、コンプライアンスチームが実務として行っていることの間のギャップは、想像していた以上に大きかった。 従来のKYC/AMLでは、新規顧客のオンボーディング時に、制裁データベースに照合して書類を収集・スクリーニングし、リスクをスコアリングして記録する。取引が事後的にフラグ付けされると、ファイルを引き出してレビュー履歴を書き、レポートを提出してSAR(疑わしい取引報告)につながる。 手作業で書類が多い紙のトレイルは、監査人が受け入れる。責任は銀行にある。チェックは銀行が行い、その結果を銀行が引き受ける。 ニュートンのモデルでは、第三者のKYCプロバイダが発行したクレデンシャルが、ユーザーによって保持される。運用者がTEE(Trusted Execution Environment:信頼実行環境)内で数秒でポリシーに照らして評価する。コンプライアンスの受領(レシート)が監査証跡となる。 スピードと自動化は本当にある。私のコンプライアンス担当の友人が最初に聞いたのは、ニュートンが「クレデンシャルは有効だ」と言う一方で発行者のデータが誤っていた場合に、誰が責任を負うのか、という点だった。ニュートンのモデルでは、発行者が発行し、運用者が評価し、スマートコントラクトが執行する。責任の連鎖はより長く、かつ不明確になりがちだ。 私は、技術的な能力ではなく、制度導入を現実的に考えたときの最も重要な設計上の問いは、ニュートンが担保(アテステーション)した取引が非コンプライアンスだった場合に、誰がその責任(負債)を負うのか、だと思っている。 まだ解けていないのは、ニュートンのコンプライアンス・レシートが、規制上の責任要件を満たすのか、それとも「チェックを実行した」ということを示すだけなのか、そしてそれらが同じなのかどうかという点だ。 $LAB $HMSTR #shareyouropinion @NewtonProtocol $NEWT #Newt
ニュートンのクレデンシャル・モデルにおける責任ギャップと、従来のKYC/AML運用の現実

先週、規制を受けた企業でKYCプログラムを運営しているコンプライアンス担当の友人と、ニュートンの本人確認(アイデンティティ)モデルを一緒に検証したところ、ニュートンが説明していることと、コンプライアンスチームが実務として行っていることの間のギャップは、想像していた以上に大きかった。

従来のKYC/AMLでは、新規顧客のオンボーディング時に、制裁データベースに照合して書類を収集・スクリーニングし、リスクをスコアリングして記録する。取引が事後的にフラグ付けされると、ファイルを引き出してレビュー履歴を書き、レポートを提出してSAR(疑わしい取引報告)につながる。

手作業で書類が多い紙のトレイルは、監査人が受け入れる。責任は銀行にある。チェックは銀行が行い、その結果を銀行が引き受ける。

ニュートンのモデルでは、第三者のKYCプロバイダが発行したクレデンシャルが、ユーザーによって保持される。運用者がTEE(Trusted Execution Environment:信頼実行環境)内で数秒でポリシーに照らして評価する。コンプライアンスの受領(レシート)が監査証跡となる。

スピードと自動化は本当にある。私のコンプライアンス担当の友人が最初に聞いたのは、ニュートンが「クレデンシャルは有効だ」と言う一方で発行者のデータが誤っていた場合に、誰が責任を負うのか、という点だった。ニュートンのモデルでは、発行者が発行し、運用者が評価し、スマートコントラクトが執行する。責任の連鎖はより長く、かつ不明確になりがちだ。

私は、技術的な能力ではなく、制度導入を現実的に考えたときの最も重要な設計上の問いは、ニュートンが担保(アテステーション)した取引が非コンプライアンスだった場合に、誰がその責任(負債)を負うのか、だと思っている。

まだ解けていないのは、ニュートンのコンプライアンス・レシートが、規制上の責任要件を満たすのか、それとも「チェックを実行した」ということを示すだけなのか、そしてそれらが同じなのかどうかという点だ。
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt
DeFiにおけるポイント/リワードプログラムはコンプライアンスのイネーブルメントとしての優位性を生みます。新トンのアイデンティティとコンプライアンスドメインは、対処すべきエッジケースを明確に設計していません。 ポイントプログラムでは、プロトコルのアクティビティに基づいて、ウォレットへクレジットまたはトークンが配布されます。いずれの場合も、コンプライアンス上の論点は、配布される価値を受け取る資格が、その受領ウォレットにあるかどうかです。 サンクション(制裁)コンプライアンスは、リワードの分配に対しても、他の価値移転と同じように適用されます。 新トンのコンプライアンスドメインが、リワード分配トランザクションに対してサンクションチェックを強制できるか、特にプロトコルからウォレットへ向けて行われるリワードのアウトバウンド転送について、ドキュメント上で明確に説明されていません。 方向性が重要です。 新トンの使用例の多くは、ウォレットがトランザクションをプロトコルへ送信する前にチェックを行うことを含みます。リワードのエアドロップは、その逆方向に働きます。 強制モデルが、プロトコル主導のアウトバウンド転送に適用されるかどうかは、ポリシーチェックがどのようにトリガーされるかという構造上の問題です。 現在のドキュメントではこれに対する回答がありません。このエッジケースは現実的であり、アクティブなリワードプログラムを運用するあらゆるDeFiプロトコルにとって重要です。 @NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion {future}(HMSTRUSDT) {future}(LABUSDT) {spot}(NEWTUSDT) #Newt #NEWT リワードにはチェックが必要ですか?
DeFiにおけるポイント/リワードプログラムはコンプライアンスのイネーブルメントとしての優位性を生みます。新トンのアイデンティティとコンプライアンスドメインは、対処すべきエッジケースを明確に設計していません。

ポイントプログラムでは、プロトコルのアクティビティに基づいて、ウォレットへクレジットまたはトークンが配布されます。いずれの場合も、コンプライアンス上の論点は、配布される価値を受け取る資格が、その受領ウォレットにあるかどうかです。

サンクション(制裁)コンプライアンスは、リワードの分配に対しても、他の価値移転と同じように適用されます。

新トンのコンプライアンスドメインが、リワード分配トランザクションに対してサンクションチェックを強制できるか、特にプロトコルからウォレットへ向けて行われるリワードのアウトバウンド転送について、ドキュメント上で明確に説明されていません。

方向性が重要です。
新トンの使用例の多くは、ウォレットがトランザクションをプロトコルへ送信する前にチェックを行うことを含みます。リワードのエアドロップは、その逆方向に働きます。

強制モデルが、プロトコル主導のアウトバウンド転送に適用されるかどうかは、ポリシーチェックがどのようにトリガーされるかという構造上の問題です。

現在のドキュメントではこれに対する回答がありません。このエッジケースは現実的であり、アクティブなリワードプログラムを運用するあらゆるDeFiプロトコルにとって重要です。
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
リワードにはチェックが必要ですか?
🔘 Always
67%
🔘 High-value only
33%
🔘 Never
0%
🔘 Depends on rules
0%
6 投票 • 投票は終了しました
記事
エンタープライズのクラウド認可における Rego と、Newton のコンプライアンス活用事例#newt 今週、Rego のポリシー作成(authoring)セクションを読み進めて、Newton が開発者やコンプライアンス チームに実際に何を学ぶよう求めているのかを理解しました。なぜなら、Kubernetes の admission control に使われるのと同じ言語の枠組み(フレーミング)には、検討する価値のある前提が含まれているからです。 Rego は Open Policy Agent プロジェクトによって作成された宣言的なポリシー言語です。エンタープライズのインフラストラクチャでは、Kubernetes の Admission Control API ゲートウェイの認可や、CI/CD パイプラインのポリシーに使われます。Rego には、意思決定を導くために構造化データ上の一連のルールを評価する、特定の評価モデルと、命令型プログラミングのバックグラウンドから来た人にとっての明白ではない学習曲線があります。

エンタープライズのクラウド認可における Rego と、Newton のコンプライアンス活用事例

#newt
今週、Rego のポリシー作成(authoring)セクションを読み進めて、Newton が開発者やコンプライアンス チームに実際に何を学ぶよう求めているのかを理解しました。なぜなら、Kubernetes の admission control に使われるのと同じ言語の枠組み(フレーミング)には、検討する価値のある前提が含まれているからです。
Rego は Open Policy Agent プロジェクトによって作成された宣言的なポリシー言語です。エンタープライズのインフラストラクチャでは、Kubernetes の Admission Control API ゲートウェイの認可や、CI/CD パイプラインのポリシーに使われます。Rego には、意思決定を導くために構造化データ上の一連のルールを評価する、特定の評価モデルと、命令型プログラミングのバックグラウンドから来た人にとっての明白ではない学習曲線があります。
小さく始めよう。DeFiにおいて取引を生成するAIエージェントは、従来の金融におけるアルゴリズム取引とは決して同じものではなく、それらを取り巻くコンプライアンス基盤も大幅に発達していません。 ズームアウトすると、ニュートンのポリシーレイヤーは、取引レベルのコンプライアンスという課題に答えます。つまり、この特定の取引は定義されたルールをクリアしているか——という問いです。これは、従来のアルゴリズム取引のコンプライアンスが求める要素のうちの1つのレイヤーにすぎません。 #NEWT その上のレイヤーは別物です。従来のアルゴリズム取引のコンプライアンスでは、モデルの文書化、監査証跡、実行された取引を特定のモデルの意思決定に結び付けること、そしてモデルが予期せぬ挙動を示した際に人が介入できるキルスイッチ機能が求められます。 #newt これらは、個々の取引に対する事前の執行(プリセトルメント)による強制では、いずれもカバーされません。 さらにズームアウトすると、DeFiにおけるAIエージェント取引が拡大すれば、規制当局は、従来の市場におけるアルゴリズム取引と同様の要件を適用するでしょう。ニュートンのインフラは、そのコンプライアンス・スタックに必要なコンポーネントです。これをそれ自体で十分だとみなすのは、DeFiでAIエージェントを用いる規制対象の事業体にとって、重大なギャップになり得ます。 #ShareYourOpinion $LAB $HMSTR @NewtonProtocol $NEWT #Newt
小さく始めよう。DeFiにおいて取引を生成するAIエージェントは、従来の金融におけるアルゴリズム取引とは決して同じものではなく、それらを取り巻くコンプライアンス基盤も大幅に発達していません。

ズームアウトすると、ニュートンのポリシーレイヤーは、取引レベルのコンプライアンスという課題に答えます。つまり、この特定の取引は定義されたルールをクリアしているか——という問いです。これは、従来のアルゴリズム取引のコンプライアンスが求める要素のうちの1つのレイヤーにすぎません。
#NEWT

その上のレイヤーは別物です。従来のアルゴリズム取引のコンプライアンスでは、モデルの文書化、監査証跡、実行された取引を特定のモデルの意思決定に結び付けること、そしてモデルが予期せぬ挙動を示した際に人が介入できるキルスイッチ機能が求められます。
#newt

これらは、個々の取引に対する事前の執行(プリセトルメント)による強制では、いずれもカバーされません。

さらにズームアウトすると、DeFiにおけるAIエージェント取引が拡大すれば、規制当局は、従来の市場におけるアルゴリズム取引と同様の要件を適用するでしょう。ニュートンのインフラは、そのコンプライアンス・スタックに必要なコンポーネントです。これをそれ自体で十分だとみなすのは、DeFiでAIエージェントを用いる規制対象の事業体にとって、重大なギャップになり得ます。

#ShareYourOpinion $LAB $HMSTR

@NewtonProtocol $NEWT #Newt
昨夜、ガバナンス文書をもう一度読み返しました。というのも、「すでに運用されているガバナンス」という前提が何かを意味しているようだったからです。つまり、「設計されている何か」を意味します。 ニュートンが説明する提案ライフサイクルには5つの段階があります。アイデア—非公式な議論で、正式なプロセスはありません。RFC—Request for Comments。変更を提案するための、構造化された文書です。NIP—Newton Improvement Proposal。RFCを正式化したもので、検討に付される準備ができた版です。 コミュニティ討議—投票の前に、フィードバックを受け付けるオープンな期間。トークン・ハウスの投票—Snapshotを通じてオフチェーンで実施され、NEWTのステーカーがNIPに投票します。 以上が、設計された完全なパイプラインです。 最初の読みで見落としていたのは、このパイプラインが文書内には存在している一方で、トークン・ハウス自体、つまり実際に投票する当事者の組織は、まだ運用上の構造としては存在していない、という点です。現時点では、文書が「フェーズ0」と呼ぶ段階で、Foundation Boardが意思決定を行っています。提案ライフサイクルは、目標状態であって現在の状態ではありません。 この細部が、ニュートンの資料におけるすべてのガバナンス主張の読み方を変えます。 私は、この文書がその区別を明確にしていることを実際に好んでいます。フェーズ0の言い回し—曖昧な「コミュニティ主導のマーケティング」ではない、ということです。プロジェクト名が、その現在の中央集権のステージをここまでストレートに自らのものとして示しているのは珍しいです。 まだ解けていないのは、フェーズ0からフェーズ1への移行を具体的に何がトリガーするのかです。固定されたタイムラインなのか、分散化の指標なのか、それともFoundation Boardの裁量に完全に委ねられているのか。 $TAC $LAB #ShareYourOpinion @NewtonProtocol $NEWT #Newt
昨夜、ガバナンス文書をもう一度読み返しました。というのも、「すでに運用されているガバナンス」という前提が何かを意味しているようだったからです。つまり、「設計されている何か」を意味します。

ニュートンが説明する提案ライフサイクルには5つの段階があります。アイデア—非公式な議論で、正式なプロセスはありません。RFC—Request for Comments。変更を提案するための、構造化された文書です。NIP—Newton Improvement Proposal。RFCを正式化したもので、検討に付される準備ができた版です。

コミュニティ討議—投票の前に、フィードバックを受け付けるオープンな期間。トークン・ハウスの投票—Snapshotを通じてオフチェーンで実施され、NEWTのステーカーがNIPに投票します。

以上が、設計された完全なパイプラインです。

最初の読みで見落としていたのは、このパイプラインが文書内には存在している一方で、トークン・ハウス自体、つまり実際に投票する当事者の組織は、まだ運用上の構造としては存在していない、という点です。現時点では、文書が「フェーズ0」と呼ぶ段階で、Foundation Boardが意思決定を行っています。提案ライフサイクルは、目標状態であって現在の状態ではありません。

この細部が、ニュートンの資料におけるすべてのガバナンス主張の読み方を変えます。

私は、この文書がその区別を明確にしていることを実際に好んでいます。フェーズ0の言い回し—曖昧な「コミュニティ主導のマーケティング」ではない、ということです。プロジェクト名が、その現在の中央集権のステージをここまでストレートに自らのものとして示しているのは珍しいです。

まだ解けていないのは、フェーズ0からフェーズ1への移行を具体的に何がトリガーするのかです。固定されたタイムラインなのか、分散化の指標なのか、それともFoundation Boardの裁量に完全に委ねられているのか。
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt
·
--
ブリッシュ
確認済み
「信託不要のビットコイン・ボールト(TBV)」ホワイトペーパーは、第5章で呼び出す価値のあることを行っています。同章では、オープン・パーティシペーションを明確なベネフィットとして挙げつつ、同じ章で実際の仕組みとしてホワイトリスト化されたリクイデーターを指定しています。@babylonlabs_io ベネフィットの箇条書きでは、オープン・パーティシペーションがカバーする対象が明示的で、リクイデーター、借り手、開発者まで含まれ、すべてが最小限のオンボーディングでプロトコルに接続できるはずだとされています。しかし、少し前の段落で説明される清算フローも同様に明確で、清算はホワイトリスト化されたリクイデーターによって実行される、としています。これは定義された許可制の集合であり、アンダーコラテラルなポジションをクローズしたい人なら誰でもよいわけではありません。$BABY リクイデーターのホワイトリスト化が不合理だと言っているわけではありません。清算とは、実際の資本を迅速に保有・移動することであり、その役割に対して参加者を審査することは、オンチェーンでもオフチェーンでも、貸付プロトコル全般で標準的な実務です。 また、2つの主張が同時にうまく噛み合っていないとも言っています。ベネフィットではオープンな参加者としてリクイデーターを名指ししますが、仕組みは彼らをゲートします。両立しているとは言い切れません。オープンという表現が、その箇条書きでは、ホワイトリストが裏付ける範囲よりも重みを持っています。#baby ホワイトリスト自体が簡単に参加できる(たとえば、k-of-nの共同署名セットで誰でも入れる)のであれば、最小限のオンボーディングとホワイトリスト化された参加者が同じものになり得て、2つの観点から見た結果として整合する可能性があります。しかし、ホワイトペーパーは、リクイデーターが実際にどのようにホワイトリスト入りするのかを一度も説明していません。 では、誰でもリクイデーターになれるのでしょうか。それともオープン・パーティシペーションはホワイトリストのところで終わってしまうのでしょうか。第5章では、ベネフィットとゲートが同じページに書かれているのに、両者が結び付けられていません。 $UAI $BANK #ShareYourOpinion #ShareYourVote
「信託不要のビットコイン・ボールト(TBV)」ホワイトペーパーは、第5章で呼び出す価値のあることを行っています。同章では、オープン・パーティシペーションを明確なベネフィットとして挙げつつ、同じ章で実際の仕組みとしてホワイトリスト化されたリクイデーターを指定しています。@BabylonLabs_io

ベネフィットの箇条書きでは、オープン・パーティシペーションがカバーする対象が明示的で、リクイデーター、借り手、開発者まで含まれ、すべてが最小限のオンボーディングでプロトコルに接続できるはずだとされています。しかし、少し前の段落で説明される清算フローも同様に明確で、清算はホワイトリスト化されたリクイデーターによって実行される、としています。これは定義された許可制の集合であり、アンダーコラテラルなポジションをクローズしたい人なら誰でもよいわけではありません。$BABY

リクイデーターのホワイトリスト化が不合理だと言っているわけではありません。清算とは、実際の資本を迅速に保有・移動することであり、その役割に対して参加者を審査することは、オンチェーンでもオフチェーンでも、貸付プロトコル全般で標準的な実務です。

また、2つの主張が同時にうまく噛み合っていないとも言っています。ベネフィットではオープンな参加者としてリクイデーターを名指ししますが、仕組みは彼らをゲートします。両立しているとは言い切れません。オープンという表現が、その箇条書きでは、ホワイトリストが裏付ける範囲よりも重みを持っています。#baby

ホワイトリスト自体が簡単に参加できる(たとえば、k-of-nの共同署名セットで誰でも入れる)のであれば、最小限のオンボーディングとホワイトリスト化された参加者が同じものになり得て、2つの観点から見た結果として整合する可能性があります。しかし、ホワイトペーパーは、リクイデーターが実際にどのようにホワイトリスト入りするのかを一度も説明していません。

では、誰でもリクイデーターになれるのでしょうか。それともオープン・パーティシペーションはホワイトリストのところで終わってしまうのでしょうか。第5章では、ベネフィットとゲートが同じページに書かれているのに、両者が結び付けられていません。

$UAI $BANK
#ShareYourOpinion
#ShareYourVote
Anyone can liquidate
60%
Whitelist is required
20%
Needs clarification
20%
5 投票 • 投票は終了しました
週末にテストネットの流れを「読んだだけ」じゃなくて実際に歩いて(手順として)確認してみました。動画ガイドを前提で見ていれば仕組みは理解できるはずだと思っていましたが、それは違いました。 Trustless Bitcoin Vaults(TBV)によるネイティブBitcoin担保の借入をAave v4で実現するパブリック・テストネットでは、テストBTCをバルトに入れて、オンチェーン上で検証されるのを見た上で、ホワイトペーパーにある collBTC のミントと融資の流れと同じようにそれを担保に借りられます。ファセットからテストトークンを先に受け取り、その後エクスプローラーで入金を追跡していくと、ドキュメントに書かれている「抽象的なバルトが検証されて collBTC がミントされる」という説明が、図解ではなく実際の手順の連なりとして頭に入ってきます。 私の理解がつながったのは、ライトクライアントの検証ステップが、ふつうのトークン送金で感じるような「即時」さではないからでした。入金と、使える状態として collBTC が表示されるまでには実際に待ち時間があるのです。 自分でこの手順を一度通してみることで、後でホワイトペーパーの後半を読むときの見え方が変わると思います。決済や清算のフローは、1つの入金が同じステップで進むのを見た後なら、抽象的な図にはなりません。 ただ、分かっていないのはテストネットのタイミングがメインネットで実際に体感するものと一致するのか、それともテストネットのインフラがライブのデプロイより速いのか遅いのか、という点です。 testnetアプリの横にリンクされたフィードバックフォームがあり、自分でフローを通すなら使う価値があります。ドキュメントと一致しない点に気づいたら特に。 $EUL $ON #shareyouropinion @babylonlabs_io $BABY #baby
週末にテストネットの流れを「読んだだけ」じゃなくて実際に歩いて(手順として)確認してみました。動画ガイドを前提で見ていれば仕組みは理解できるはずだと思っていましたが、それは違いました。

Trustless Bitcoin Vaults(TBV)によるネイティブBitcoin担保の借入をAave v4で実現するパブリック・テストネットでは、テストBTCをバルトに入れて、オンチェーン上で検証されるのを見た上で、ホワイトペーパーにある collBTC のミントと融資の流れと同じようにそれを担保に借りられます。ファセットからテストトークンを先に受け取り、その後エクスプローラーで入金を追跡していくと、ドキュメントに書かれている「抽象的なバルトが検証されて collBTC がミントされる」という説明が、図解ではなく実際の手順の連なりとして頭に入ってきます。

私の理解がつながったのは、ライトクライアントの検証ステップが、ふつうのトークン送金で感じるような「即時」さではないからでした。入金と、使える状態として collBTC が表示されるまでには実際に待ち時間があるのです。

自分でこの手順を一度通してみることで、後でホワイトペーパーの後半を読むときの見え方が変わると思います。決済や清算のフローは、1つの入金が同じステップで進むのを見た後なら、抽象的な図にはなりません。

ただ、分かっていないのはテストネットのタイミングがメインネットで実際に体感するものと一致するのか、それともテストネットのインフラがライブのデプロイより速いのか遅いのか、という点です。

testnetアプリの横にリンクされたフィードバックフォームがあり、自分でフローを通すなら使う価値があります。ドキュメントと一致しない点に気づいたら特に。
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby
記事
Halborn監査:重大な脆弱性はない。監査スコープの開示が示すこと2025年Q4のレポートにあるHalbornの監査開示に戻って、何が監査対象だったのか、そして結果について何が述べられているのかを注意深く確認しました。「致命的な脆弱性はない」というフレーズは、それが意味を成す前に、そのスコープ(範囲)を理解する必要があるためです。 監査は、レポートが明示的に挙げている「証明者(プローバー)基盤」を具体的に対象としています。これにより、プロトコル全体の監査とは切り分けられています。 ポリシー検証ワークフローで使用される、証明者実装の正しさ(correctness)に関するセキュリティ上の前提と堅牢性が、明確に焦点として挙げられていました。これはスコープ付きのコンポーネントレベル監査であり、エンドツーエンドのプロトコル・セキュリティのレビューではありません。

Halborn監査:重大な脆弱性はない。監査スコープの開示が示すこと

2025年Q4のレポートにあるHalbornの監査開示に戻って、何が監査対象だったのか、そして結果について何が述べられているのかを注意深く確認しました。「致命的な脆弱性はない」というフレーズは、それが意味を成す前に、そのスコープ(範囲)を理解する必要があるためです。
監査は、レポートが明示的に挙げている「証明者(プローバー)基盤」を具体的に対象としています。これにより、プロトコル全体の監査とは切り分けられています。
ポリシー検証ワークフローで使用される、証明者実装の正しさ(correctness)に関するセキュリティ上の前提と堅牢性が、明確に焦点として挙げられていました。これはスコープ付きのコンポーネントレベル監査であり、エンドツーエンドのプロトコル・セキュリティのレビューではありません。
確認済み
ホワイトペーパーには、多くの人が読み飛ばすようなデータセットがある。166のブロックチェーンネットワークの調査だ。16件は資産凍結が組み込まれている。さらに19件は、最小限の変更でそれを有効化できる。許可なき(パーミッションレス)が条件付きであるネットワークは35。ニュートンはこれを使って、コアとなる問題をUIレベルの制御だけでは不十分だが、さらにブロックチェーンのレールが中立だという前提もまた不十分だ、という形で組み立てる。凍結能力を持つネットワークは、暗号学的な説明責任がなく、凍結権限を握る者によって、コンプライアンスを不透明かつ統制された方法で強制できる。ニュートンの回答は、プロトコル層ではなくポリシー層での執行。Regoで監査可能な認可ロジック。オペレーターの集合は分散化。オンチェーンでコンプライアンスの領収書を記録する。これによってネットワークが資産を凍結できなくなるわけではないが、チェーンが中立でないとしても、コンプライアンスの判断をプロトコルから分離し、監査可能にする。完全な解決策ではない。問題の上に別の説明責任のレイヤーを置くものだ。#NEWT 私は、凍結データがニュートンの解いていることを組み替えると本当に思う。パーミッションレスのレールにコンプライアンスを追加するというより、レール自体が中立でないかもしれないときに、コンプライアンスを透明にすることだ。#newt 問いは、ニュートンのポリシー層が、基盤となるチェーンが一方的な凍結権限を保持している場合に、意味のある説明責任を提供できるのかどうか、そして資産が結局いつでも凍結できるなら、コンプライアンスの領収書が無意味になってしまうのではないか、という点だ。#ShareYourOpinion @NewtonProtocol $NEWT #Newt $LAB $HMSTR
ホワイトペーパーには、多くの人が読み飛ばすようなデータセットがある。166のブロックチェーンネットワークの調査だ。16件は資産凍結が組み込まれている。さらに19件は、最小限の変更でそれを有効化できる。許可なき(パーミッションレス)が条件付きであるネットワークは35。ニュートンはこれを使って、コアとなる問題をUIレベルの制御だけでは不十分だが、さらにブロックチェーンのレールが中立だという前提もまた不十分だ、という形で組み立てる。凍結能力を持つネットワークは、暗号学的な説明責任がなく、凍結権限を握る者によって、コンプライアンスを不透明かつ統制された方法で強制できる。ニュートンの回答は、プロトコル層ではなくポリシー層での執行。Regoで監査可能な認可ロジック。オペレーターの集合は分散化。オンチェーンでコンプライアンスの領収書を記録する。これによってネットワークが資産を凍結できなくなるわけではないが、チェーンが中立でないとしても、コンプライアンスの判断をプロトコルから分離し、監査可能にする。完全な解決策ではない。問題の上に別の説明責任のレイヤーを置くものだ。#NEWT
私は、凍結データがニュートンの解いていることを組み替えると本当に思う。パーミッションレスのレールにコンプライアンスを追加するというより、レール自体が中立でないかもしれないときに、コンプライアンスを透明にすることだ。#newt
問いは、ニュートンのポリシー層が、基盤となるチェーンが一方的な凍結権限を保持している場合に、意味のある説明責任を提供できるのかどうか、そして資産が結局いつでも凍結できるなら、コンプライアンスの領収書が無意味になってしまうのではないか、という点だ。#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR
Yes — transparency matters
50%
No — freezing wins always
25%
Depends on jurisdiction
25%
Only with independent ops
0%
4 投票 • 投票は終了しました
ガバナンスの力学——誰が定足数の閾値、手数料の分配、オペレーターの参加を決めるのか ニュートンのガバナンスで誰も聞かない部分、それは最も重要なパラメータを実際に誰がコントロールしているのかです。 3つのガバナンスの軸——ポリシー基準、オペレーターの参加、プロトコルのアップグレード——そして議論で欠けているのは、それらの軸が実際に何を支配しているのかという点です。 定足数の閾値:タスクごとに設定可能で、ガバナンスによって決まり、ネットワーク上のあらゆるアテステーションの経済的なセキュリティを決定します。 手数料の分配:設定可能で、ガバナンスによって決まり、オペレーターの経済性を決定します。 オペレーターの参加:プロトコルのガバナンス・フレームワークによって統治され、そもそも誰が手数料を得るのかを決めます。 ここで、NEWTを誰が持っているかを見てください。 オペレーターはNEWTをステークする/オペレーターは手数料を得る/オペレーターは参加するためにNEWTを保有することが求められます。もしオペレーターが、他のトークン保有者に比べてNEWTを不釣り合いに多く保有しているなら、自分自身の定足数の閾値や手数料の分配を決めるガバナンス投票に対して、不釣り合いな影響力を持ち得ます。 それが珍しいとは言いません。ほとんどのプルーフ・オブ・ステークのガバナンスには、程度の差こそあれ、同種の問題が存在します。ほかのネットワークでは、バリデーターが、バリデーターの経済性に影響するパラメータに投票します。 #newt それが欠陥だとも言いません。NEWT保有によってゲームに皮を張っているオペレーターは、短期の搾取ではなく、ネットワークの長期的な健全性と利益を一致させる可能性があります。 #NEWT まだ解明できていないのは、ニュートンが、オペレーターが集団で投票して定足数の閾値を下げ、自分たちの運用負担を減らす一方で、静かにネットワークのセキュリティを損なうようなことを防ぐための、特定のメカニズムを設計しているかどうかです。 #shareyouropinion $HMSTR $LAB @NewtonProtocol $NEWT #Newt
ガバナンスの力学——誰が定足数の閾値、手数料の分配、オペレーターの参加を決めるのか

ニュートンのガバナンスで誰も聞かない部分、それは最も重要なパラメータを実際に誰がコントロールしているのかです。

3つのガバナンスの軸——ポリシー基準、オペレーターの参加、プロトコルのアップグレード——そして議論で欠けているのは、それらの軸が実際に何を支配しているのかという点です。

定足数の閾値:タスクごとに設定可能で、ガバナンスによって決まり、ネットワーク上のあらゆるアテステーションの経済的なセキュリティを決定します。

手数料の分配:設定可能で、ガバナンスによって決まり、オペレーターの経済性を決定します。

オペレーターの参加:プロトコルのガバナンス・フレームワークによって統治され、そもそも誰が手数料を得るのかを決めます。
ここで、NEWTを誰が持っているかを見てください。

オペレーターはNEWTをステークする/オペレーターは手数料を得る/オペレーターは参加するためにNEWTを保有することが求められます。もしオペレーターが、他のトークン保有者に比べてNEWTを不釣り合いに多く保有しているなら、自分自身の定足数の閾値や手数料の分配を決めるガバナンス投票に対して、不釣り合いな影響力を持ち得ます。

それが珍しいとは言いません。ほとんどのプルーフ・オブ・ステークのガバナンスには、程度の差こそあれ、同種の問題が存在します。ほかのネットワークでは、バリデーターが、バリデーターの経済性に影響するパラメータに投票します。
#newt
それが欠陥だとも言いません。NEWT保有によってゲームに皮を張っているオペレーターは、短期の搾取ではなく、ネットワークの長期的な健全性と利益を一致させる可能性があります。
#NEWT
まだ解明できていないのは、ニュートンが、オペレーターが集団で投票して定足数の閾値を下げ、自分たちの運用負担を減らす一方で、静かにネットワークのセキュリティを損なうようなことを防ぐための、特定のメカニズムを設計しているかどうかです。
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt
バビロンの手数料ルーティングセクションには、2度読み返す価値のある特定の1行があります オンチェーン上で自動化されたオークションで、BTC建ての手数料がBABYとしてオークションにかけられます。そして、落札者が費やしたBABYはプログラム的に燃やされます。 調整の裁量はありません。どれだけ燃やすか、いつ燃やすかを決める委員会もありません。必要なのは、プロトコル利用に直接結びついた機械的なオークションだけです。 これは、単なる一般的なデフレ型トークンノミクスの主張ではなく、明確な設計上の選択です。信頼不要のビットコイン・ボールト(TBV)の活動が成長し、より多くのボールトが作られ、より多くのBTC建てローンが発行され、より多くの償還が行われるほど、BTCで発生した手数料がこのオークションを通じてルーティングされ、BABYは固定の排出スケジュールではなく、実際の利用に応じて供給から取り除かれます。 トークン価値について何かが保証されるわけではありません。利用に連動した燃焼は、実際に有意な規模で利用が起きることに依存します。またホワイトペーパーでは、手数料体系やステーキングのルールが、引き続き設計の最中であり、ガバナンスの承認対象であることが明示されています。 それは些細な点でもありません。固定のスケジュールやマーケティングの約束ではなく、実証されたプロトコル利用に結びつけてトークンの燃焼メカニクスを設計していることは、この分野の多くのトークンノミクス主張よりも、追跡するうえで正直なシグナルになり得ます。 私がまだ把握できていないのは、このオークションメカニズムが、実際に稼働中のどこかのライブ展開で既に有効化されているのか、それとも、残りの手数料ルーティングの枠組みと同様に、設計段階の提案の1つとして議論され続けているのか、という点です。 @babylonlabs_io $BABY #baby #ShareYourOpinion $BANK $DEXE
バビロンの手数料ルーティングセクションには、2度読み返す価値のある特定の1行があります
オンチェーン上で自動化されたオークションで、BTC建ての手数料がBABYとしてオークションにかけられます。そして、落札者が費やしたBABYはプログラム的に燃やされます。

調整の裁量はありません。どれだけ燃やすか、いつ燃やすかを決める委員会もありません。必要なのは、プロトコル利用に直接結びついた機械的なオークションだけです。

これは、単なる一般的なデフレ型トークンノミクスの主張ではなく、明確な設計上の選択です。信頼不要のビットコイン・ボールト(TBV)の活動が成長し、より多くのボールトが作られ、より多くのBTC建てローンが発行され、より多くの償還が行われるほど、BTCで発生した手数料がこのオークションを通じてルーティングされ、BABYは固定の排出スケジュールではなく、実際の利用に応じて供給から取り除かれます。

トークン価値について何かが保証されるわけではありません。利用に連動した燃焼は、実際に有意な規模で利用が起きることに依存します。またホワイトペーパーでは、手数料体系やステーキングのルールが、引き続き設計の最中であり、ガバナンスの承認対象であることが明示されています。

それは些細な点でもありません。固定のスケジュールやマーケティングの約束ではなく、実証されたプロトコル利用に結びつけてトークンの燃焼メカニクスを設計していることは、この分野の多くのトークンノミクス主張よりも、追跡するうえで正直なシグナルになり得ます。

私がまだ把握できていないのは、このオークションメカニズムが、実際に稼働中のどこかのライブ展開で既に有効化されているのか、それとも、残りの手数料ルーティングの枠組みと同様に、設計段階の提案の1つとして議論され続けているのか、という点です。

@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号