Binance Square
nhathoc24
251 投稿

nhathoc24

22 フォロー
15 フォロワー
194 いいね
投稿
·
--
翻訳参照
Một Order bán 700 USDT trên Binance P2P của tôi kết thúc bình thường, không lỗi, không tranh chấp nhưng sau đó tôi nhận ra mình biết khá rõ người gửi tiền, lại biết rất ít về chính cách mình nhận tiền. Trước Order, tôi xem hồ sơ buyer, tỷ lệ hoàn tất và đối chiếu tên thanh toán. Crypto nằm trong Escrow, trao đổi giữ trong Order. Buyer báo đã trả, tôi tự kiểm tra tiền thực nhận rồi mới Release. Order đóng xong, tôi đọc lại hướng dẫn an toàn của Binance và dừng ở chargeback fraud. Binance cảnh báo một số phương thức thanh toán có thể cho phép người gửi yêu cầu chargeback hoặc đảo ngược giao dịch. Tôi nhìn lại phương thức mình vừa nhận 700 USDT và tự hỏi: nếu có dispute hoặc yêu cầu đảo ngược, nó xử lý thế nào? Tôi không biết rõ. Buyer không làm gì sai. Tôi chọn phương thức đó vì quen, nhanh, tiện, nhưng chưa hiểu kỹ cách nó xử lý những tình huống như vậy. Từ Order sau, tôi thêm đúng một bước: hiểu phương thức thanh toán trước khi chọn nó. Trong giao dịch, tôi vẫn theo đúng quy trình Binance P2P và dùng Appeal/Support nếu gặp điều mình không thể xác minh. 700 USDT hôm đó đã về đủ. Bài học thì dành cho lần sau: Đừng đợi tiền gặp vấn đề rồi mới tìm hiểu cách mình đã chọn để nhận nó. @Binance_Vietnam #BinanceP2PAnToan $TUT $BEAT
Một Order bán 700 USDT trên Binance P2P của tôi kết thúc bình thường, không lỗi, không tranh chấp nhưng sau đó tôi nhận ra mình biết khá rõ người gửi tiền, lại biết rất ít về chính cách mình nhận tiền.

Trước Order, tôi xem hồ sơ buyer, tỷ lệ hoàn tất và đối chiếu tên thanh toán. Crypto nằm trong Escrow, trao đổi giữ trong Order. Buyer báo đã trả, tôi tự kiểm tra tiền thực nhận rồi mới Release.

Order đóng xong, tôi đọc lại hướng dẫn an toàn của Binance và dừng ở chargeback fraud. Binance cảnh báo một số phương thức thanh toán có thể cho phép người gửi yêu cầu chargeback hoặc đảo ngược giao dịch. Tôi nhìn lại phương thức mình vừa nhận 700 USDT và tự hỏi: nếu có dispute hoặc yêu cầu đảo ngược, nó xử lý thế nào?

Tôi không biết rõ. Buyer không làm gì sai. Tôi chọn phương thức đó vì quen, nhanh, tiện, nhưng chưa hiểu kỹ cách nó xử lý những tình huống như vậy. Từ Order sau, tôi thêm đúng một bước: hiểu phương thức thanh toán trước khi chọn nó. Trong giao dịch, tôi vẫn theo đúng quy trình Binance P2P và dùng Appeal/Support nếu gặp điều mình không thể xác minh.

700 USDT hôm đó đã về đủ. Bài học thì dành cho lần sau: Đừng đợi tiền gặp vấn đề rồi mới tìm hiểu cách mình đã chọn để nhận nó.

@Binance Vietnam #BinanceP2PAnToan $TUT $BEAT
私は「3分」をBinance P2Pでデッドラインのように見ていました。4分目になってようやく、平均的な数字を“約束”に変えてしまったのだと気づきました。 今朝、$CYSを利確したあと、700 USDTをBinance P2Pに移して売却しました。プロフィール、完了率、取引履歴、そして入金名義を照合します。平均の処理時間が約3分なので、かなり安心していました。 03:47。銀行アプリを2回目に開いてみても、残高はまだ変わっていません。取引が遅いのだと思い、そのあと自分が参照データをデッドラインに変えてしまっていたことに気づきました。3分はaverageであって、SLAではありません。 averageは過去の取引を表しています。つまり、700 USDTの注文が03:00までに必ず終わると約束するものではありません。Orderで「購入者が支払った」と表示されても、銀行側で入金がまだ記録されていない場合、それは“食い違っている2つの状態”です。私はUSDTをEscrowに入れ、やり取りはBinanceのOrder Chatで維持し、自分で資金の流れを確認できるまでReleaseしません。 2つの状態が食い違っているとき、次の手順を当てる必要はありません。入金名義が変わったり、ロック解除を急かされたり、Binanceの外に出て取引しようと提案されたりしても、Order ID、領収書、チャットを残して照合します。説明がつかない場合は、次のステップとしてAppeal/Binance Supportです。 今朝の注文 $CYS は、私にとって美しい利確になりました。でも4分目が、より価値のある習慣を残してくれました。そこから、処理時間は“参考”にすぎません。Releaseのボタンを押す前に、自分で確認したデータだけが最終的な説得力を持ちます。3分は、700 USDTをReleaseする権利ではなく、私にとっての参照です。 #BinanceP2PAnToan @Binance_Vietnam $MMT $BLUAI
私は「3分」をBinance P2Pでデッドラインのように見ていました。4分目になってようやく、平均的な数字を“約束”に変えてしまったのだと気づきました。

今朝、$CYS を利確したあと、700 USDTをBinance P2Pに移して売却しました。プロフィール、完了率、取引履歴、そして入金名義を照合します。平均の処理時間が約3分なので、かなり安心していました。

03:47。銀行アプリを2回目に開いてみても、残高はまだ変わっていません。取引が遅いのだと思い、そのあと自分が参照データをデッドラインに変えてしまっていたことに気づきました。3分はaverageであって、SLAではありません。

averageは過去の取引を表しています。つまり、700 USDTの注文が03:00までに必ず終わると約束するものではありません。Orderで「購入者が支払った」と表示されても、銀行側で入金がまだ記録されていない場合、それは“食い違っている2つの状態”です。私はUSDTをEscrowに入れ、やり取りはBinanceのOrder Chatで維持し、自分で資金の流れを確認できるまでReleaseしません。

2つの状態が食い違っているとき、次の手順を当てる必要はありません。入金名義が変わったり、ロック解除を急かされたり、Binanceの外に出て取引しようと提案されたりしても、Order ID、領収書、チャットを残して照合します。説明がつかない場合は、次のステップとしてAppeal/Binance Supportです。

今朝の注文 $CYS は、私にとって美しい利確になりました。でも4分目が、より価値のある習慣を残してくれました。そこから、処理時間は“参考”にすぎません。Releaseのボタンを押す前に、自分で確認したデータだけが最終的な説得力を持ちます。3分は、700 USDTをReleaseする権利ではなく、私にとっての参照です。

#BinanceP2PAnToan @Binance Vietnam $MMT $BLUAI
#BinanceP2PAnToan ベトナムにはこんな格言があります。「分け前が欲しければ、深いところまで負けろ(=しっぺ返しを食らう)」──でも、先週のBinance P2Pのある1件の指示(取引)を見て初めて、この4文字がとても明快な“計算式”として書けることに気づきました。 私が得たもの:少しだけ有利な価格。 私が失ったもの:稼働中の1つのオーダー。 それでもまだ得に見えますが、2つ目のほうをよく見ると話は別です。あのオーダーは暗号資産をエスクローで保持し、やり取りはオーダーチャット内で進めさせ、双方に問題があった場合はAppeal/Binance Supportにつながる導線まで用意しているのです。つまり買い手は、単に値段を変えるよう“提案”しているだけではありません。取引そのもののやり方を変える提案をしているのです。 それが起きたのは先週の土曜日。私は200 USDTを売りました。注文が成立すると、買い手がこうメッセージしてきたのです。「キャンセルして。こっちで直接やるよ。君はもっと良い価格になるから。」私は言い争いもしませんし、さらに条件交渉もしませんでした。オーダーはそのまま保持し、拒否しただけです。 取引後に一番印象に残ったのは200 USDTではありません。とても丁寧な形で現れる“レッドフラグ”が、どういうものかということです。それは「リスクを受け入れて」なんて言いません。「もっといい価格をあげる」「Telegramを早く使おう」「手間のためにオーダーを消そう」と言うんです。言い方は3つあるのに、向いている方向は同じ──取引をプラットフォームの外へ引き出すことです。 今ではP2Pがかなりシンプルに見えています。もし“メリット”と称して、私に稼働中のオーダーをキャンセルしろ、チャネルを変えろ、進行中の合意を置き換えろと言ってくるなら、そこで止めます。やり取りはオーダーチャットのまま、関連情報も保持したまま。問題があればAppealかSupportを使います。自分で別のルールを新たに作る必要はありません。 あの日は、数ドル分(小さな金額)も追加では稼げませんでした。でも最終的な“計算”はプラスでした。私は、この取引が走るように設計された正しいレール上に取引を保ったのです。 @Binance_Vietnam #BinanceP2PAnToan $SKYAI $HFT
#BinanceP2PAnToan
ベトナムにはこんな格言があります。「分け前が欲しければ、深いところまで負けろ(=しっぺ返しを食らう)」──でも、先週のBinance P2Pのある1件の指示(取引)を見て初めて、この4文字がとても明快な“計算式”として書けることに気づきました。

私が得たもの:少しだけ有利な価格。
私が失ったもの:稼働中の1つのオーダー。

それでもまだ得に見えますが、2つ目のほうをよく見ると話は別です。あのオーダーは暗号資産をエスクローで保持し、やり取りはオーダーチャット内で進めさせ、双方に問題があった場合はAppeal/Binance Supportにつながる導線まで用意しているのです。つまり買い手は、単に値段を変えるよう“提案”しているだけではありません。取引そのもののやり方を変える提案をしているのです。

それが起きたのは先週の土曜日。私は200 USDTを売りました。注文が成立すると、買い手がこうメッセージしてきたのです。「キャンセルして。こっちで直接やるよ。君はもっと良い価格になるから。」私は言い争いもしませんし、さらに条件交渉もしませんでした。オーダーはそのまま保持し、拒否しただけです。

取引後に一番印象に残ったのは200 USDTではありません。とても丁寧な形で現れる“レッドフラグ”が、どういうものかということです。それは「リスクを受け入れて」なんて言いません。「もっといい価格をあげる」「Telegramを早く使おう」「手間のためにオーダーを消そう」と言うんです。言い方は3つあるのに、向いている方向は同じ──取引をプラットフォームの外へ引き出すことです。

今ではP2Pがかなりシンプルに見えています。もし“メリット”と称して、私に稼働中のオーダーをキャンセルしろ、チャネルを変えろ、進行中の合意を置き換えろと言ってくるなら、そこで止めます。やり取りはオーダーチャットのまま、関連情報も保持したまま。問題があればAppealかSupportを使います。自分で別のルールを新たに作る必要はありません。

あの日は、数ドル分(小さな金額)も追加では稼げませんでした。でも最終的な“計算”はプラスでした。私は、この取引が走るように設計された正しいレール上に取引を保ったのです。

@Binance Vietnam #BinanceP2PAnToan $SKYAI $HFT
今日の$HEI のラリーで、1,000 USDT以上稼げた。おもしろいことに、私が一番覚えているのはそこじゃない。BinanceのP2Pが私のためには決して押さない、あの「ボタン」——リリースだ。 USDTを出品した直後、購入者が支払いのスクリーンショットを送ってきた。 「先にリリースしてください。銀行の反映が遅いんです。」 私はスクリーンショットを閉じ、銀行アプリを開いて待った。 何も来なかった。 そのとき、ようやく腑に落ちた。 Binanceは私の暗号資産をエスクローでロックできる。マーチャントステータスや完了率も表示できる。注文IDも保持できるし、取引のあらゆるメッセージも保存できる。だが、本当に重要な唯一のこと——お金が実際に私の銀行口座へ届いたかどうか——それは検証できない。 だから私は、口座名を必ず確認する。スクリーンショットではなく銀行の残高を信じる。そして、Appealやチャット履歴がいつでも参照できるように、会話はすべてBinanceの中に残す。 3分後、ようやく支払い通知が届いた。 そのとき初めて、私はリリースを押した。 $HEI の利益は記憶から薄れていく。あの3分は薄れない。Binance P2Pで一番安全なのはエスクローじゃない——最終決定が、本当に確かめられるのはただ一人、私にあるという点だと気づかせてくれた。 @Binance_Vietnam #BinanceP2PAnToan $HFT
今日の$HEI のラリーで、1,000 USDT以上稼げた。おもしろいことに、私が一番覚えているのはそこじゃない。BinanceのP2Pが私のためには決して押さない、あの「ボタン」——リリースだ。

USDTを出品した直後、購入者が支払いのスクリーンショットを送ってきた。

「先にリリースしてください。銀行の反映が遅いんです。」

私はスクリーンショットを閉じ、銀行アプリを開いて待った。

何も来なかった。

そのとき、ようやく腑に落ちた。

Binanceは私の暗号資産をエスクローでロックできる。マーチャントステータスや完了率も表示できる。注文IDも保持できるし、取引のあらゆるメッセージも保存できる。だが、本当に重要な唯一のこと——お金が実際に私の銀行口座へ届いたかどうか——それは検証できない。

だから私は、口座名を必ず確認する。スクリーンショットではなく銀行の残高を信じる。そして、Appealやチャット履歴がいつでも参照できるように、会話はすべてBinanceの中に残す。

3分後、ようやく支払い通知が届いた。

そのとき初めて、私はリリースを押した。

$HEI の利益は記憶から薄れていく。あの3分は薄れない。Binance P2Pで一番安全なのはエスクローじゃない——最終決定が、本当に確かめられるのはただ一人、私にあるという点だと気づかせてくれた。
@Binance Vietnam #BinanceP2PAnToan $HFT
私が興味を持つのは、IBCパケットが通常、アプリケーション・チェーンからBabylon Genesisへ移動するのに3〜12秒かかること、あるいは輻輳によってそれが300秒まで延びうることではありません。ブロックチェーンの基準で見れば、どちらの数字も特に目立つものではありません。難しい問いはこうです――情報は、いつ経済的現実を変える資格を得るのか? 多くの人はBabylonをクロスチェーン・メッセージング・プロトコルだと説明します。私の見解では、それがデータの動き方は説明しますが、セキュリティがどのように確立されるのかは説明しきれていません。現在では56,853 BTC以上が50を超えるBabylon Secured Networksを支えていますが、その価値は単にデータが到達したからといって保護されるわけではありません。バリデータが不正行為をした場合、アプリケーション・チェーンはSlashing Proofを生成しますが、スラッシングはすぐには起こりません。証明は、IBCまたはCross-chain Core Protocolを通じてBabylon Genesisへ届き、独立した検証を通過する必要があります。伝送は事実を運びます。検証が経済的な最終性を付与します。 このため、ACIDのAtomicityは部分的な類推にとどまります。Atomicityは、1つのデータベースと1つの実行境界を前提とします。Babylonは、共有されたGlobal State Lockを持たない独立したブロックチェーンにまたがるため、課題は実行を同期させることではなく、同じ検証済みの証拠から導かれる同一の強制可能な結果へ収束させることです。 したがって、3〜12秒の間隔、あるいは300秒ですら、これはネットワーク遅延以上のものです。それは、出来事が観測されてから、その出来事が強制可能になるまでのギャップです。クロスチェーン・セキュリティにおける真のボトルネックは、伝送ではなく検証です。 Trust Pending Layerは、Slashing Proofがまだ検証中の間に、一時的に経済的に敏感な状態へフラグを立てることで、このギャップを狭められます。それはスラッシングを置き換えるものではありませんが、証拠から強制へ移行する過程をより予測可能にするでしょう。 Babylonのより深い貢献は、単に50を超えるブロックチェーンをBitcoinのセキュリティに接続することではありません。それはマルチチェーン時代のための原則を確立することです――情報は数秒で移動しうるが、取り返しのつかない経済的な意思決定は、検証の後にのみ行われるべきだ。 @babylonlabs_io $AKE $BABY #baby
私が興味を持つのは、IBCパケットが通常、アプリケーション・チェーンからBabylon Genesisへ移動するのに3〜12秒かかること、あるいは輻輳によってそれが300秒まで延びうることではありません。ブロックチェーンの基準で見れば、どちらの数字も特に目立つものではありません。難しい問いはこうです――情報は、いつ経済的現実を変える資格を得るのか?

多くの人はBabylonをクロスチェーン・メッセージング・プロトコルだと説明します。私の見解では、それがデータの動き方は説明しますが、セキュリティがどのように確立されるのかは説明しきれていません。現在では56,853 BTC以上が50を超えるBabylon Secured Networksを支えていますが、その価値は単にデータが到達したからといって保護されるわけではありません。バリデータが不正行為をした場合、アプリケーション・チェーンはSlashing Proofを生成しますが、スラッシングはすぐには起こりません。証明は、IBCまたはCross-chain Core Protocolを通じてBabylon Genesisへ届き、独立した検証を通過する必要があります。伝送は事実を運びます。検証が経済的な最終性を付与します。

このため、ACIDのAtomicityは部分的な類推にとどまります。Atomicityは、1つのデータベースと1つの実行境界を前提とします。Babylonは、共有されたGlobal State Lockを持たない独立したブロックチェーンにまたがるため、課題は実行を同期させることではなく、同じ検証済みの証拠から導かれる同一の強制可能な結果へ収束させることです。

したがって、3〜12秒の間隔、あるいは300秒ですら、これはネットワーク遅延以上のものです。それは、出来事が観測されてから、その出来事が強制可能になるまでのギャップです。クロスチェーン・セキュリティにおける真のボトルネックは、伝送ではなく検証です。

Trust Pending Layerは、Slashing Proofがまだ検証中の間に、一時的に経済的に敏感な状態へフラグを立てることで、このギャップを狭められます。それはスラッシングを置き換えるものではありませんが、証拠から強制へ移行する過程をより予測可能にするでしょう。

Babylonのより深い貢献は、単に50を超えるブロックチェーンをBitcoinのセキュリティに接続することではありません。それはマルチチェーン時代のための原則を確立することです――情報は数秒で移動しうるが、取り返しのつかない経済的な意思決定は、検証の後にのみ行われるべきだ。
@BabylonLabs_io $AKE $BABY #baby
「200を超えるファイナリティ・プロバイダー」が、@babylonlabs_io がますます分散化している証拠だとよく引用されます。しかし、その結論は早すぎると思います。その数字が示す重要なことは確かですが、ほとんどの人が想定する通りとは限りません。 バビロンは最初の課題を驚くほどうまく解決しました。プロフェッショナルな幅広いオペレーターがファイナリティ・プロバイダーになり、ビットコイン建ての経済的セキュリティによって裏付けられたバビロンのセキュアド・ネットワークを確実にするための、ファイナリティ層を構築したのです。言い換えれば、バビロンはネットワーク・セキュリティへの参加をうまく分散化できています。しかし、そこでプロトコルの直接的な影響は終わります。 次に何が起きるかは市場によって決まります。BTC保有者は自然に、より強い評判、より長い運用履歴、より一貫したパフォーマンスを持つファイナリティ・プロバイダーへ委任します。個々の意思決定は合理的です。それでも、何千もの合理的な判断が積み重なることで、委任されたBTCが比較的小さな一部のオペレーターに徐々に集中してしまうことがあります。プロトコルはオープンですが、経済的な影響力が自動的に広く分散されたままになるとは限りません。 だからこそ、私はバビロンの次の課題は、ファイナリティ・プロバイダーの数を増やすことではなくなっていると考えています。工学的な課題は概ね解決されています。より難しいのは、市場のインセンティブが、自然に集中を強める方向ではなく、広い委任を支え続けるようにすることです。プロトコルのアーキテクチャは参加の分散化を可能にできますが、分散された経済的な結果を維持できるのはインセンティブだけです。 私にとって、200のファイナリティ・プロバイダーが持つ本当の意味はそこにあります。このマイルストーンは、分散化が完了したことを証明するものではありません。バビロンが、プロトコル・アーキテクチャによって分散化できるものを分散化したことを示しているのです――参加する権利です。では、その参加が広く分散された経済的影響に結びつくかどうかは、最終的には市場のインセンティブによって決まります。アーキテクチャだけではありません。 @babylonlabs_io $AKE $B2 $BABY #baby
「200を超えるファイナリティ・プロバイダー」が、@BabylonLabs_io がますます分散化している証拠だとよく引用されます。しかし、その結論は早すぎると思います。その数字が示す重要なことは確かですが、ほとんどの人が想定する通りとは限りません。

バビロンは最初の課題を驚くほどうまく解決しました。プロフェッショナルな幅広いオペレーターがファイナリティ・プロバイダーになり、ビットコイン建ての経済的セキュリティによって裏付けられたバビロンのセキュアド・ネットワークを確実にするための、ファイナリティ層を構築したのです。言い換えれば、バビロンはネットワーク・セキュリティへの参加をうまく分散化できています。しかし、そこでプロトコルの直接的な影響は終わります。

次に何が起きるかは市場によって決まります。BTC保有者は自然に、より強い評判、より長い運用履歴、より一貫したパフォーマンスを持つファイナリティ・プロバイダーへ委任します。個々の意思決定は合理的です。それでも、何千もの合理的な判断が積み重なることで、委任されたBTCが比較的小さな一部のオペレーターに徐々に集中してしまうことがあります。プロトコルはオープンですが、経済的な影響力が自動的に広く分散されたままになるとは限りません。

だからこそ、私はバビロンの次の課題は、ファイナリティ・プロバイダーの数を増やすことではなくなっていると考えています。工学的な課題は概ね解決されています。より難しいのは、市場のインセンティブが、自然に集中を強める方向ではなく、広い委任を支え続けるようにすることです。プロトコルのアーキテクチャは参加の分散化を可能にできますが、分散された経済的な結果を維持できるのはインセンティブだけです。

私にとって、200のファイナリティ・プロバイダーが持つ本当の意味はそこにあります。このマイルストーンは、分散化が完了したことを証明するものではありません。バビロンが、プロトコル・アーキテクチャによって分散化できるものを分散化したことを示しているのです――参加する権利です。では、その参加が広く分散された経済的影響に結びつくかどうかは、最終的には市場のインセンティブによって決まります。アーキテクチャだけではありません。
@BabylonLabs_io $AKE $B2 $BABY #baby
多くの人が、誤った指標でバビロンを評価していると思います。議論の大半は、ステークされたBTC量、接続されたAVS、またはTVLに集中しています。これらの問いは、バビロンが単に別のインフラ・プロトコルであるかのように前提しています。しかし、私はそれが正しい見方ではなくなりました。 私の見解では、バビロンはビットコインの「信頼の前提」をBitcoinFiのための設計標準へと変換しようとしています。最も影響力のあるプロトコルは、最も多機能だったからといって記憶されることは稀です。彼らは、他のビルダーが従うことを選択する制約を設けることで、エコシステムを形作ります。 バビロンは、次の原則から始まります。ビットコインは、新しい金融経済に参加するために、その信頼の前提を妥協してはならない。これは単なる技術上の判断ではありません。製品がまだ作られていない時点で、許容される解決策の範囲を狭める設計上の制約です。 そのレンズで見ると、ブリッジはデフォルトの答えではなくなり、ラップ資産は明白な選択でもなくなります。あらゆるBitcoinFiプロトコルは、流動性や資本効率で競う前に、まずその設計がビットコインの信頼の前提を損なわないことを示さなければなりません。信頼を要さないビットコイン・ボルト(Vault)は、その哲学を実際に体現しており、製品が原則に従うのであって、その逆ではありません。 だからこそ、私はバビロンがステーキング・プロトコルよりも大きなものを目指していると考えています。ビルダーがその期待をデフォルトとして扱い始めれば、バビロンの影響は、バビロンが確保するBTCの量をはるかに超えて及ぶでしょう。 そのため、私はバビロンがTVLで他のプロトコルと競争しているとは思いません。BitcoinFiがまだ形作られつつある今、信頼を最優先する設計標準を確立しにいっているのです。もし成功すれば、その最大の貢献はTVLでは測れません。むしろ、将来のすべてのビルダーが必ず答えることになる、次のようなシンプルな問いによって測られるはずです: 「この設計は、ビットコインの信頼の前提を保持しているか?」 @babylonlabs_io $ON $BANK $BABY #baby
多くの人が、誤った指標でバビロンを評価していると思います。議論の大半は、ステークされたBTC量、接続されたAVS、またはTVLに集中しています。これらの問いは、バビロンが単に別のインフラ・プロトコルであるかのように前提しています。しかし、私はそれが正しい見方ではなくなりました。

私の見解では、バビロンはビットコインの「信頼の前提」をBitcoinFiのための設計標準へと変換しようとしています。最も影響力のあるプロトコルは、最も多機能だったからといって記憶されることは稀です。彼らは、他のビルダーが従うことを選択する制約を設けることで、エコシステムを形作ります。

バビロンは、次の原則から始まります。ビットコインは、新しい金融経済に参加するために、その信頼の前提を妥協してはならない。これは単なる技術上の判断ではありません。製品がまだ作られていない時点で、許容される解決策の範囲を狭める設計上の制約です。

そのレンズで見ると、ブリッジはデフォルトの答えではなくなり、ラップ資産は明白な選択でもなくなります。あらゆるBitcoinFiプロトコルは、流動性や資本効率で競う前に、まずその設計がビットコインの信頼の前提を損なわないことを示さなければなりません。信頼を要さないビットコイン・ボルト(Vault)は、その哲学を実際に体現しており、製品が原則に従うのであって、その逆ではありません。

だからこそ、私はバビロンがステーキング・プロトコルよりも大きなものを目指していると考えています。ビルダーがその期待をデフォルトとして扱い始めれば、バビロンの影響は、バビロンが確保するBTCの量をはるかに超えて及ぶでしょう。

そのため、私はバビロンがTVLで他のプロトコルと競争しているとは思いません。BitcoinFiがまだ形作られつつある今、信頼を最優先する設計標準を確立しにいっているのです。もし成功すれば、その最大の貢献はTVLでは測れません。むしろ、将来のすべてのビルダーが必ず答えることになる、次のようなシンプルな問いによって測られるはずです:

「この設計は、ビットコインの信頼の前提を保持しているか?」
@BabylonLabs_io $ON $BANK $BABY #baby
Sao mình k làm booster RealGo được nhỉ。Mình k có liên kết với tài khoản nào khác cả。Mà muốn huỷ liên kết thì giờ phải làm sao nhỉ?? $ESPORTS $LAB
Sao mình k làm booster RealGo được nhỉ。Mình k có liên kết với tài khoản nào khác cả。Mà muốn huỷ liên kết thì giờ phải làm sao nhỉ??
$ESPORTS $LAB
F1ドライバーは、300km/hで走行している最中に決してダッシュボードを下に見たりしません。 反応はすでに最適化されています。取引も同じです。値動きの激しい市場では、ポジションサイズを手動で入力したりスライダーをドラッグしたりするのは、時間を浪費するだけでなく、感情が介入する余地を作ってしまいます。ためらう1ミリ秒ごとに、あなたの取引計画を実行する相手にとって脅威となる瞬間が増えていきます。 GRVTは、不必要な操作をなくすためにQuick-Fraction Orderを導入しました。注文サイズを総資本の1%、2%、または5%にあらかじめ設定しておくことで、パニックの中で簡単に変えられてしまう「ポジションサイズの判断」を、デフォルトのワークフローへと変えます。 運用への影響: ・より速い執行:1注文あたり1.2秒を節約できるため、市場が急に動いたときのスリッページを抑えるのに役立ちます。この差は、単なる統計ではなく、実際の取引優位性です。 ・ミスの減少:手入力の代わりに固定ボタンを使うことで、ファットフィンガー(誤入力)のエラーを63%削減します。意志の力だけでは解決できない、人為的ミスの形を取り除きます。 公平な反論: 自動化は、ポジションサイズを素早く変更する必要がある場合に柔軟性を下げる、と考える人もいるかもしれません。ですが、相場の勢いの中でサイズを調整し、あとで後悔したことはどれほどの頻度でしょうか? こうした柔軟性は、多くの場合、戦略的な優位というよりは、規律が弱いことの症状になっています。Quick-Fraction Orderはサイズ変更を止めるわけではありません。選択を、衝動的ではなく「意識したもの」にするだけです。 規律は気持ち(態度)の問題ではありません。計画を破るのが、従うより難しくなるようなツールを設計するところから生まれます。あらかじめ決めた割合をワークフローに組み込むことで、GRVTはプレッシャー下でポジションサイズを計算する必要をなくします。 リスク管理は、毎日自分に実践を強いるものであるべきではありません。システムのデフォルトの状態であるべきです。取引プラットフォームは単なるツールです。どう設定するかが、市場で生き残れる時間を左右します。 @grvt_io #grvt $LAB $VELVET
F1ドライバーは、300km/hで走行している最中に決してダッシュボードを下に見たりしません。

反応はすでに最適化されています。取引も同じです。値動きの激しい市場では、ポジションサイズを手動で入力したりスライダーをドラッグしたりするのは、時間を浪費するだけでなく、感情が介入する余地を作ってしまいます。ためらう1ミリ秒ごとに、あなたの取引計画を実行する相手にとって脅威となる瞬間が増えていきます。

GRVTは、不必要な操作をなくすためにQuick-Fraction Orderを導入しました。注文サイズを総資本の1%、2%、または5%にあらかじめ設定しておくことで、パニックの中で簡単に変えられてしまう「ポジションサイズの判断」を、デフォルトのワークフローへと変えます。

運用への影響:

・より速い執行:1注文あたり1.2秒を節約できるため、市場が急に動いたときのスリッページを抑えるのに役立ちます。この差は、単なる統計ではなく、実際の取引優位性です。
・ミスの減少:手入力の代わりに固定ボタンを使うことで、ファットフィンガー(誤入力)のエラーを63%削減します。意志の力だけでは解決できない、人為的ミスの形を取り除きます。

公平な反論:

自動化は、ポジションサイズを素早く変更する必要がある場合に柔軟性を下げる、と考える人もいるかもしれません。ですが、相場の勢いの中でサイズを調整し、あとで後悔したことはどれほどの頻度でしょうか? こうした柔軟性は、多くの場合、戦略的な優位というよりは、規律が弱いことの症状になっています。Quick-Fraction Orderはサイズ変更を止めるわけではありません。選択を、衝動的ではなく「意識したもの」にするだけです。

規律は気持ち(態度)の問題ではありません。計画を破るのが、従うより難しくなるようなツールを設計するところから生まれます。あらかじめ決めた割合をワークフローに組み込むことで、GRVTはプレッシャー下でポジションサイズを計算する必要をなくします。

リスク管理は、毎日自分に実践を強いるものであるべきではありません。システムのデフォルトの状態であるべきです。取引プラットフォームは単なるツールです。どう設定するかが、市場で生き残れる時間を左右します。

@grvt_io #grvt $LAB $VELVET
Newton Protocolで最も興味深い点は、ポリシーをスマートコントラクトから分離することではありません。 重要なのは、初めてブロックチェーンが「真実」と「許可(パーミッション)」は根本的に別の問題であることを認めたのを見たことです。 何年もの間、ブロックチェーンは事実について合意できればよかったのです。すべてのノードが同じ状態を見ていれば、ネットワークは合意できます。スマートコントラクトはアプリケーションロジックの置き場となり、技術的負債はコードの中に蓄積されていきました。 Newtonは、その前提を変えます。 AIエージェントの世界では、取引は技術的には有効でも、許可されていない可能性があります。命令はすべてのプロトコル規則を満たしていても、支出上限を超えている、DAOのポリシーに違反している、内部統制と矛盾している、あるいは規制要件を満たしていないといった理由で拒否され得ます。ブロックチェーンはもはや「何が起きたか」だけに関して合意するのではなく、「その行為がなぜ許されるのか」についても合意しなければならないのです。 その瞬間から、Contract Debtは最大の制約ではなくなります。 最も成長している課題はPolicy Debtです。 しかしPolicy Debtは、単にポリシーが増えることの話ではありません。実際に蓄積されるのはセマンティクス(意味)です。同じポリシーでも、2つの組織が解釈を異なるものにしてしまうことがあります。同じデータが、2つのAIエージェントに異なる結論を導くこともあります。ノードがポリシーを同じ方法で解釈しなくなれば、ネットワークはデータをめぐって合意を失うのではなく、その意味をめぐって合意を失います。 それが、Newton Protocolが本当に取り組んでいる課題です。 Ethereumは、何千ものノードが共有された状態に合意できることを証明しました。Newtonは、より難しいことに挑戦しています。つまり、取引になる前に「意思決定がどう解釈されるべきか」について、何千ものノードが合意できることを証明しようとしているのです。 もし成功すれば、Newtonは単に別のPolicy Layerを導入するだけではありません。それは、「最も難しい合意問題がデータそのものではなく、その意味である」新しい世代のブロックチェーンを定義し得ます。これはAI時代を象徴する技術的負債になるかもしれず、しかもそれを解決しようと試みているブロックチェーンプロトコルはごくわずかです。@NewtonProtocol $NEWT #Newt $LAB
Newton Protocolで最も興味深い点は、ポリシーをスマートコントラクトから分離することではありません。

重要なのは、初めてブロックチェーンが「真実」と「許可(パーミッション)」は根本的に別の問題であることを認めたのを見たことです。

何年もの間、ブロックチェーンは事実について合意できればよかったのです。すべてのノードが同じ状態を見ていれば、ネットワークは合意できます。スマートコントラクトはアプリケーションロジックの置き場となり、技術的負債はコードの中に蓄積されていきました。

Newtonは、その前提を変えます。

AIエージェントの世界では、取引は技術的には有効でも、許可されていない可能性があります。命令はすべてのプロトコル規則を満たしていても、支出上限を超えている、DAOのポリシーに違反している、内部統制と矛盾している、あるいは規制要件を満たしていないといった理由で拒否され得ます。ブロックチェーンはもはや「何が起きたか」だけに関して合意するのではなく、「その行為がなぜ許されるのか」についても合意しなければならないのです。

その瞬間から、Contract Debtは最大の制約ではなくなります。

最も成長している課題はPolicy Debtです。

しかしPolicy Debtは、単にポリシーが増えることの話ではありません。実際に蓄積されるのはセマンティクス(意味)です。同じポリシーでも、2つの組織が解釈を異なるものにしてしまうことがあります。同じデータが、2つのAIエージェントに異なる結論を導くこともあります。ノードがポリシーを同じ方法で解釈しなくなれば、ネットワークはデータをめぐって合意を失うのではなく、その意味をめぐって合意を失います。

それが、Newton Protocolが本当に取り組んでいる課題です。

Ethereumは、何千ものノードが共有された状態に合意できることを証明しました。Newtonは、より難しいことに挑戦しています。つまり、取引になる前に「意思決定がどう解釈されるべきか」について、何千ものノードが合意できることを証明しようとしているのです。

もし成功すれば、Newtonは単に別のPolicy Layerを導入するだけではありません。それは、「最も難しい合意問題がデータそのものではなく、その意味である」新しい世代のブロックチェーンを定義し得ます。これはAI時代を象徴する技術的負債になるかもしれず、しかもそれを解決しようと試みているブロックチェーンプロトコルはごくわずかです。@NewtonProtocol $NEWT #Newt $LAB
記事
ニュートン・プロトコルのPolicy Engineが最初に過負荷になるのは、どのプロトコルでしょうか?自分が「どのプロトコルが最初にニュートン・プロトコルに統合されるか」という問いよりも、はるかに面白いと思った質問があります。 どのプロトコルが最もニュートンにとって苦しいものになるでしょうか? 最初は、すべてが数ミリ秒のうちに進むので、答えはPerpetual DEXではないかと予想していました。しかしニュートンのドキュメントを読み進めるほど、速度は単なる表面にすぎないと感じるようになりました。各プロトコルが実際に生み出すのは、ニュートンのAuthorizationアーキテクチャに対する、まったく別種の負荷だからです。

ニュートン・プロトコルのPolicy Engineが最初に過負荷になるのは、どのプロトコルでしょうか?

自分が「どのプロトコルが最初にニュートン・プロトコルに統合されるか」という問いよりも、はるかに面白いと思った質問があります。
どのプロトコルが最もニュートンにとって苦しいものになるでしょうか?
最初は、すべてが数ミリ秒のうちに進むので、答えはPerpetual DEXではないかと予想していました。しかしニュートンのドキュメントを読み進めるほど、速度は単なる表面にすぎないと感じるようになりました。各プロトコルが実際に生み出すのは、ニュートンのAuthorizationアーキテクチャに対する、まったく別種の負荷だからです。
記事
ニュートンはAIの意思決定の検証を、市場価値のある一種の資源へと変えているニュートン・プロトコルのトークノミクスを読んでいるときに、ずっと考え続けた疑問があります。イーサリアムはブロックスペースを販売しています。ではニュートンは何を売っているのでしょうか? 最初は自分も多くの人と同じで、総供給が10億$NEWTであること、解放(アンロック)のスケジュール、そしてAIエージェントがより多く使われればトークンには追加の需要が生まれるだろうという期待を見ていました。しかし、システムドキュメントを読み込み、KuCoinやBinance Academyの分析をさらに深く理解するほど、そこに見えているのは氷山の一角にすぎないと感じました。本当にニュートンが構築しているのは、減衰(ディスインフレ)メカニズムではありません。彼らは、AIの意思決定を検証する能力を、市場で価格付けできるようにする市場を作っているのです。

ニュートンはAIの意思決定の検証を、市場価値のある一種の資源へと変えている

ニュートン・プロトコルのトークノミクスを読んでいるときに、ずっと考え続けた疑問があります。イーサリアムはブロックスペースを販売しています。ではニュートンは何を売っているのでしょうか?
最初は自分も多くの人と同じで、総供給が10億$NEWT であること、解放(アンロック)のスケジュール、そしてAIエージェントがより多く使われればトークンには追加の需要が生まれるだろうという期待を見ていました。しかし、システムドキュメントを読み込み、KuCoinやBinance Academyの分析をさらに深く理解するほど、そこに見えているのは氷山の一角にすぎないと感じました。本当にニュートンが構築しているのは、減衰(ディスインフレ)メカニズムではありません。彼らは、AIの意思決定を検証する能力を、市場で価格付けできるようにする市場を作っているのです。
私がこれまで一度も疑ったことがない、ブロックチェーンに関する前提がひとつありました。所有権は、有効な署名を誰かが生成できる限り存在する、ということです。それは当たり前のように聞こえましたが、ニュートン・プロトコルの「デッドマンズ・スイッチ」に出会ってから考えが変わりました。 自己管理(セルフカストディ)は、所有権の最も純粋な形として扱われることがよくあります。秘密鍵を自分で管理していれば、誰もあなたの資産を奪うことはできません。しかし考えれば考えるほど、ブロックチェーンは本当の意味で所有権を守っているわけではない、と気づきました。守っているのは、有効な署名を生成できる能力です。 ウォレットが数か月、あるいは数年アクティブでなかった場合、ブロックチェーンには何が起きたのか分かりません。長期で保持しているのか、締め出されているのか、単に操作できない状態なのか。そのような状況は、ブロックチェーンからはすべて同じに見えます。ブロックチェーンは不在を理解できないのです。停止して署名を出さなくなったアドレスしか見ていません。 そこで私は逆説に行き当たりました。セルフカストディは、あなたの資産から他の誰も排除しますが、所有者がもはや観測できなくなったときに何が起こるかは決めてくれないのです。 ニュートン・プロトコルはここが違うように感じられます。秘密鍵を保管したり、シードフレーズを共有したりする代わりに、ニュートンは「不在」を解釈・実行できるポリシーとして扱います。ユーザーはRegoルールを書いて、ウォレットに180日間のアクティビティがない場合、AI Agentはその条件が満たされたことの証拠だけを収集する、と定められます。そしてポリシー層がルールを検証すると、あらかじめ設定されたタイムロック付きキーが、あらかじめ決められたアドレスへ資産を転送します。 重要なのは、AIが資産を受け取る相手を決めないことです。もし決めてしまうなら、ニュートンはセルフカストディを損なうことになります。AIは条件が満たされたことを証明するだけで、実行の権限は、所有者が作成したポリシーにあります。 私にとって、これこそがデッドマンズ・スイッチの本当の意味です。ニュートンは単に継承(インヘリタンス)を追加しているだけではありません。「この署名は有効か?」という問いから、「所有は、所有者が事前に定めた意図に従って継続されるべきか?」という問いへと、ブロックチェーンが認識できる範囲を広げているのです。@NewtonProtocol $NEWT #Newt $LAB $VELVET
私がこれまで一度も疑ったことがない、ブロックチェーンに関する前提がひとつありました。所有権は、有効な署名を誰かが生成できる限り存在する、ということです。それは当たり前のように聞こえましたが、ニュートン・プロトコルの「デッドマンズ・スイッチ」に出会ってから考えが変わりました。

自己管理(セルフカストディ)は、所有権の最も純粋な形として扱われることがよくあります。秘密鍵を自分で管理していれば、誰もあなたの資産を奪うことはできません。しかし考えれば考えるほど、ブロックチェーンは本当の意味で所有権を守っているわけではない、と気づきました。守っているのは、有効な署名を生成できる能力です。

ウォレットが数か月、あるいは数年アクティブでなかった場合、ブロックチェーンには何が起きたのか分かりません。長期で保持しているのか、締め出されているのか、単に操作できない状態なのか。そのような状況は、ブロックチェーンからはすべて同じに見えます。ブロックチェーンは不在を理解できないのです。停止して署名を出さなくなったアドレスしか見ていません。

そこで私は逆説に行き当たりました。セルフカストディは、あなたの資産から他の誰も排除しますが、所有者がもはや観測できなくなったときに何が起こるかは決めてくれないのです。

ニュートン・プロトコルはここが違うように感じられます。秘密鍵を保管したり、シードフレーズを共有したりする代わりに、ニュートンは「不在」を解釈・実行できるポリシーとして扱います。ユーザーはRegoルールを書いて、ウォレットに180日間のアクティビティがない場合、AI Agentはその条件が満たされたことの証拠だけを収集する、と定められます。そしてポリシー層がルールを検証すると、あらかじめ設定されたタイムロック付きキーが、あらかじめ決められたアドレスへ資産を転送します。

重要なのは、AIが資産を受け取る相手を決めないことです。もし決めてしまうなら、ニュートンはセルフカストディを損なうことになります。AIは条件が満たされたことを証明するだけで、実行の権限は、所有者が作成したポリシーにあります。

私にとって、これこそがデッドマンズ・スイッチの本当の意味です。ニュートンは単に継承(インヘリタンス)を追加しているだけではありません。「この署名は有効か?」という問いから、「所有は、所有者が事前に定めた意図に従って継続されるべきか?」という問いへと、ブロックチェーンが認識できる範囲を広げているのです。@NewtonProtocol $NEWT #Newt $LAB $VELVET
Newton Protocolのアーキテクチャには、私を何度も図を見返させた一点のディテールがありました。私の直感では、AIシステムは意思決定を行い、その後に実行が起こり、そして初めて検証が関与するものだと思っていました。しかしNewtonでは、AVSは実行の前に配置されています。最初は、それは単に追加の検証ステップなのだろうと考えました。調べれば調べるほど、その説明の筋が通らなくなっていきました。 目的が単にセキュリティの層をもう一つ足すことにあるなら、NewtonはAVSをワークフローの最後に置いて結果を検証できたはずです。ところがAVSは、意思決定がまだ拒否可能な位置に置かれています。仕組みそのもの以上に、その配置が私の注意を引きました。 そのとき、私は問題を間違った見方をしていたのだと気づきました。Newtonは取引そのものを守ろうとしているのではありません。意思決定が取引へと変わる権利を守ろうとしているのです。介入ポイントを前倒しにしたことで、セキュリティはもはや結果に対して反応しません。つまり、それを生み出す意思決定を、フィルタリングし始めるのです。 AIとなると、この考えはいっそう面白くなります。人間は「Confirm」をクリックする前にためらうことができます。しかしAIにはそれができません。十分なデータが揃った時点で、意思決定と実行までの距離はほとんどありません。AIをより賢くするというより、NewtonはAIに対し、その意思決定が実行に値することを証明することを求めます。 もちろん、その代償はあります。実行の前に配置されるポリシーが増えるほど、AIは即座に反応する自由を失います。良い機会を逃してしまう可能性もあります。Newtonの設計を見る限り、それは意図的に感じられます。機会を逃すことは、誤った意思決定が行動にまで至ることを許すよりも小さなコストだと見なされているのです。 Newton Protocolを学んだ後も私の中に残ったのは、AVSがどう動くかではありませんでした。AVSが私の「セキュリティ」の定義をどう変えたかです。セキュリティの価値は、悪い意思決定が起きた後に対処することだけにあるわけではありません。時には、その最大の価値は、それらの意思決定が行動になるチャンスすら与えないことにあります。 @NewtonProtocol $NEWT #Newt $LAB $T
Newton Protocolのアーキテクチャには、私を何度も図を見返させた一点のディテールがありました。私の直感では、AIシステムは意思決定を行い、その後に実行が起こり、そして初めて検証が関与するものだと思っていました。しかしNewtonでは、AVSは実行の前に配置されています。最初は、それは単に追加の検証ステップなのだろうと考えました。調べれば調べるほど、その説明の筋が通らなくなっていきました。

目的が単にセキュリティの層をもう一つ足すことにあるなら、NewtonはAVSをワークフローの最後に置いて結果を検証できたはずです。ところがAVSは、意思決定がまだ拒否可能な位置に置かれています。仕組みそのもの以上に、その配置が私の注意を引きました。

そのとき、私は問題を間違った見方をしていたのだと気づきました。Newtonは取引そのものを守ろうとしているのではありません。意思決定が取引へと変わる権利を守ろうとしているのです。介入ポイントを前倒しにしたことで、セキュリティはもはや結果に対して反応しません。つまり、それを生み出す意思決定を、フィルタリングし始めるのです。

AIとなると、この考えはいっそう面白くなります。人間は「Confirm」をクリックする前にためらうことができます。しかしAIにはそれができません。十分なデータが揃った時点で、意思決定と実行までの距離はほとんどありません。AIをより賢くするというより、NewtonはAIに対し、その意思決定が実行に値することを証明することを求めます。

もちろん、その代償はあります。実行の前に配置されるポリシーが増えるほど、AIは即座に反応する自由を失います。良い機会を逃してしまう可能性もあります。Newtonの設計を見る限り、それは意図的に感じられます。機会を逃すことは、誤った意思決定が行動にまで至ることを許すよりも小さなコストだと見なされているのです。

Newton Protocolを学んだ後も私の中に残ったのは、AVSがどう動くかではありませんでした。AVSが私の「セキュリティ」の定義をどう変えたかです。セキュリティの価値は、悪い意思決定が起きた後に対処することだけにあるわけではありません。時には、その最大の価値は、それらの意思決定が行動になるチャンスすら与えないことにあります。
@NewtonProtocol $NEWT #Newt $LAB $T
一部該当
記事
TEEは信頼を移すだけではない。権限を移すのだ。ニュートン・プロトコルのアーキテクチャを読んでいて、いちばん自分の頭を悩ませたのは、ゼロ知識やポリシー・エンジンではありませんでした。 Trusted Execution Environment(TEE)。 オペレーターになりたいなら、ソフトウェアを正しく動かすだけでは不十分です。ポリシーはTEEの中で実行されなければならず、そのうえで、ネットワークが結果を受け入れる前に、アテステーションや各種の暗号証明も作成する必要があります。最初は、これは単なるハードウェアによるセキュリティ層だと思っていました。でも読み進めるほど、ニュートンは、まったく別の場所に対してシステム全体が信頼を置くことを求めているのだと感じました。

TEEは信頼を移すだけではない。権限を移すのだ。

ニュートン・プロトコルのアーキテクチャを読んでいて、いちばん自分の頭を悩ませたのは、ゼロ知識やポリシー・エンジンではありませんでした。
Trusted Execution Environment(TEE)。
オペレーターになりたいなら、ソフトウェアを正しく動かすだけでは不十分です。ポリシーはTEEの中で実行されなければならず、そのうえで、ネットワークが結果を受け入れる前に、アテステーションや各種の暗号証明も作成する必要があります。最初は、これは単なるハードウェアによるセキュリティ層だと思っていました。でも読み進めるほど、ニュートンは、まったく別の場所に対してシステム全体が信頼を置くことを求めているのだと感じました。
ニュートン・プロトコルは、既存のポリシー結果を変えずにWASMランタイムをアップグレードするにはどうすればよいのでしょうか? ニュートン・プロトコルにおけるWASMランタイムのアップグレードは、見た目以上に危険かもしれません。 ニュートンはポリシーの1行もそのままにしておきながら、それが許可する内容を変えることができます。 必要なのは新しいランタイムだけです。 新しいランタイムがリソースやエラーを別の方法で扱うなら、同じポリシーと入力でも、あるオペレーターでは許可が返り、別のオペレーターでは評価エラーになります。 ポリシーは変わっていません。 しかし、認可の境界が変わったのです。 それで気づきました。WASMランタイムは、見えない実行レイヤーとして扱ってはならない。WASMランタイムは、ポリシーがどれくらいの時間走れるか、どれくらいのメモリを使えるか、そして失敗がどう解釈されるかを決めることで、ポリシーの意味論を定義する助けになります。 後方互換性とは、単に古いポリシーが引き続き動くことではありません。同じ条件のもとで、ポリシーが同じ判断を出し続けることを意味しなければなりません。 ニュートンにはセマンティックな固定(pinning)が必要でしょう。 各ポリシー成果物は、そのコードハッシュに加えて、ランタイムプロファイルにも結びつけるべきです。エンジンのバージョン、メモリ上限、実行バジェット、ホスト関数、そしてエラーの意味論です。 結果は「ポリシー成果物+ランタイムプロファイル」に依存することになります。 既存のポリシーは、テスト済みのランタイムのまま維持できます。新しいランタイムは、新しいポリシー、または再検証を通過したポリシーにのみ適用します。移行期間中は、ネットワークに一度にセマンティクスを変えさせるのではなく、複数バージョンを併存させられます。 差分テストでは、両方のランタイム間で、判断、エラー、リソース使用量、そして実行トレースを比較できます。 しかし、テストだけでは不十分です。 あらゆる入力をカバーできるテストスイートはありません。ニュートンにはさらに、安定したランタイム仕様、決定論的な適合性テストスイート、そしてバージョン別の有効化ルールが必要です。 WASMランタイムのアップグレードは通常のメンテナンスではありません。 それは、認可判断を生み出す環境を変えるのです。 ニュートンは、ポリシーを書き換える必要はありません。権威を書き換えるために必要なのは、ポリシーの下のランタイムを変えるだけで十分かもしれません。 @NewtonProtocol $NEWT #Newt $LAB $BEAT
ニュートン・プロトコルは、既存のポリシー結果を変えずにWASMランタイムをアップグレードするにはどうすればよいのでしょうか?

ニュートン・プロトコルにおけるWASMランタイムのアップグレードは、見た目以上に危険かもしれません。

ニュートンはポリシーの1行もそのままにしておきながら、それが許可する内容を変えることができます。

必要なのは新しいランタイムだけです。

新しいランタイムがリソースやエラーを別の方法で扱うなら、同じポリシーと入力でも、あるオペレーターでは許可が返り、別のオペレーターでは評価エラーになります。

ポリシーは変わっていません。

しかし、認可の境界が変わったのです。

それで気づきました。WASMランタイムは、見えない実行レイヤーとして扱ってはならない。WASMランタイムは、ポリシーがどれくらいの時間走れるか、どれくらいのメモリを使えるか、そして失敗がどう解釈されるかを決めることで、ポリシーの意味論を定義する助けになります。

後方互換性とは、単に古いポリシーが引き続き動くことではありません。同じ条件のもとで、ポリシーが同じ判断を出し続けることを意味しなければなりません。

ニュートンにはセマンティックな固定(pinning)が必要でしょう。

各ポリシー成果物は、そのコードハッシュに加えて、ランタイムプロファイルにも結びつけるべきです。エンジンのバージョン、メモリ上限、実行バジェット、ホスト関数、そしてエラーの意味論です。

結果は「ポリシー成果物+ランタイムプロファイル」に依存することになります。

既存のポリシーは、テスト済みのランタイムのまま維持できます。新しいランタイムは、新しいポリシー、または再検証を通過したポリシーにのみ適用します。移行期間中は、ネットワークに一度にセマンティクスを変えさせるのではなく、複数バージョンを併存させられます。

差分テストでは、両方のランタイム間で、判断、エラー、リソース使用量、そして実行トレースを比較できます。

しかし、テストだけでは不十分です。

あらゆる入力をカバーできるテストスイートはありません。ニュートンにはさらに、安定したランタイム仕様、決定論的な適合性テストスイート、そしてバージョン別の有効化ルールが必要です。

WASMランタイムのアップグレードは通常のメンテナンスではありません。

それは、認可判断を生み出す環境を変えるのです。

ニュートンは、ポリシーを書き換える必要はありません。権威を書き換えるために必要なのは、ポリシーの下のランタイムを変えるだけで十分かもしれません。
@NewtonProtocol $NEWT #Newt $LAB $BEAT
記事
WASM のメモリ安全性を超えて、Newton は Policy の CPU 使用量をどのように制限するのか?ニュートンには、同じポリシーを評価する2人のオペレーターがいると想像してください。 両者は同じ意図、同じ policyData、同じ Policy アーティファクトを受け取ります。オペレーターAは評価を90msで完了します。オペレーターBはわずかに遅く、100msのタイムアウトに達して、評価エラーを返します。 ロジックは変わっていません。入力も変わっていません。ポリシーも変わっていません。しかし、認可結果は以前とは同じではなくなりました。 そのため、Newton Protocol における CPU 制限は単なるパフォーマンス上の懸念ではありません。 Rego が WASM にコンパイルされると、ポリシーは隔離されたサンドボックス内で実行できます。ホストのメモリを任意に読み取ったり、システムAPIを呼び出したり、外部プロセスに直接干渉したりすることはできません。しかし、メモリ安全性が答えるのは1つの問いだけです:

WASM のメモリ安全性を超えて、Newton は Policy の CPU 使用量をどのように制限するのか?

ニュートンには、同じポリシーを評価する2人のオペレーターがいると想像してください。
両者は同じ意図、同じ policyData、同じ Policy アーティファクトを受け取ります。オペレーターAは評価を90msで完了します。オペレーターBはわずかに遅く、100msのタイムアウトに達して、評価エラーを返します。
ロジックは変わっていません。入力も変わっていません。ポリシーも変わっていません。しかし、認可結果は以前とは同じではなくなりました。
そのため、Newton Protocol における CPU 制限は単なるパフォーマンス上の懸念ではありません。
Rego が WASM にコンパイルされると、ポリシーは隔離されたサンドボックス内で実行できます。ホストのメモリを任意に読み取ったり、システムAPIを呼び出したり、外部プロセスに直接干渉したりすることはできません。しかし、メモリ安全性が答えるのは1つの問いだけです:
バイナンスがウォレットを中心に設計されていたとしたら、GRVTは組織を中心に設計されているのでしょうか? 問題が単に資産の共同管理であるなら、マルチシグですでに多くは解決できていました。組織なら、トレジャリーを共有し、承認のしきい値を設定し、Funding AccountsやTrading Accounts、または多層的な権限なしに引き出しを制限できます。それらが存在するということは、GRVTが「保管の外側」にある別の課題を解いていることを示唆しています。すなわち、1つのウォレットにあらゆる権限を集中させずに、組織はどのように資本を運用できるのか、という問題です。 ウォレットは所有を表現するのに非常に優れています。鍵を制御する者が資産を制御します。しかし、組織は「誰が金を所有しているのか?」以上の答えを出さなければなりません。資本を配分するのは誰か、誰が取引するのか、誰が口座を管理するのか、そして決して引き出しを許可してはならないのは誰か――それを定める必要があります。 だからこそ、GRVTにおけるOrganizationは、単なるエンタープライズ機能よりも大きく感じられるのです。Funding Accountsは、資本が管理される場所と、資本が投入される場所を分離します。Trading Accountsは、トレジャリーの完全な支配権を渡さずに戦略が動作できるようにします。さらに、Permissionsが各役割の制限を定義します。 1つのウォレットで組織を十分に表せるなら、こうした境界は不要でしょう。これらが存在することは、HExが複数の役割を、同じ資本を用いながらも、いずれの役割も自動的にそのすべてを支配してしまわない形で設計されていることを示しています。 これは複雑さを増します。しかし、機関投資家の資本では、単純さが「1か所に権限が集中しすぎる」ことを意味してしまう場合があります。GRVTは、所有・運用・内部リスクを分けるために、より多くの構造を受け入れています。 ですので、GRVTがウォレットを組織に置き換えるとは思いません。ウォレットはいまも問いに答えます。「資産を所有するのは誰か?」組織は、その所有だけでは言えないこと――「その資本を誰が、どのように、どの範囲で使えるのか?」に答えます。 バイナンスが1つの作動アカウントを前提に最適化されているとするなら、GRVTは連携する役割を前提に最適化されているように見えます。違いはアカウント種別の数ではなく、それらの背後にある前提です。つまり、1つの取引の背後には、まるごと1つの組織が立っている、という前提です。@grvt_io #grvt $LAB $VELVET
バイナンスがウォレットを中心に設計されていたとしたら、GRVTは組織を中心に設計されているのでしょうか?

問題が単に資産の共同管理であるなら、マルチシグですでに多くは解決できていました。組織なら、トレジャリーを共有し、承認のしきい値を設定し、Funding AccountsやTrading Accounts、または多層的な権限なしに引き出しを制限できます。それらが存在するということは、GRVTが「保管の外側」にある別の課題を解いていることを示唆しています。すなわち、1つのウォレットにあらゆる権限を集中させずに、組織はどのように資本を運用できるのか、という問題です。

ウォレットは所有を表現するのに非常に優れています。鍵を制御する者が資産を制御します。しかし、組織は「誰が金を所有しているのか?」以上の答えを出さなければなりません。資本を配分するのは誰か、誰が取引するのか、誰が口座を管理するのか、そして決して引き出しを許可してはならないのは誰か――それを定める必要があります。

だからこそ、GRVTにおけるOrganizationは、単なるエンタープライズ機能よりも大きく感じられるのです。Funding Accountsは、資本が管理される場所と、資本が投入される場所を分離します。Trading Accountsは、トレジャリーの完全な支配権を渡さずに戦略が動作できるようにします。さらに、Permissionsが各役割の制限を定義します。

1つのウォレットで組織を十分に表せるなら、こうした境界は不要でしょう。これらが存在することは、HExが複数の役割を、同じ資本を用いながらも、いずれの役割も自動的にそのすべてを支配してしまわない形で設計されていることを示しています。

これは複雑さを増します。しかし、機関投資家の資本では、単純さが「1か所に権限が集中しすぎる」ことを意味してしまう場合があります。GRVTは、所有・運用・内部リスクを分けるために、より多くの構造を受け入れています。

ですので、GRVTがウォレットを組織に置き換えるとは思いません。ウォレットはいまも問いに答えます。「資産を所有するのは誰か?」組織は、その所有だけでは言えないこと――「その資本を誰が、どのように、どの範囲で使えるのか?」に答えます。

バイナンスが1つの作動アカウントを前提に最適化されているとするなら、GRVTは連携する役割を前提に最適化されているように見えます。違いはアカウント種別の数ではなく、それらの背後にある前提です。つまり、1つの取引の背後には、まるごと1つの組織が立っている、という前提です。@grvt_io #grvt $LAB $VELVET
記事
自分は、ニュートン・プロトコルが意図せずAIのための「学習用インターフェース」を作っているのではと思うニュートン・プロトコルのドキュメントを読んだあと、しばらく頭を占めたアイデアがある。最初はポリシーを、みんなと同じように捉えていた。つまり意図と実行の間にある検証のための層だ。 ブロックチェーンがアクションを実行する前に、AIエージェントに何を許可するのかを決めるものではない。そういうふうに、最初の読みで自分は理解した。けれども二度目の読みでは、別の何かが見えてきた。 たぶん、将来いちばん「ポリシー」を読む存在は、人間ではないかもしれない。AIだ。なんだか変に聞こえる。でも考えれば考えるほど、納得できる気がしてくる。

自分は、ニュートン・プロトコルが意図せずAIのための「学習用インターフェース」を作っているのではと思う

ニュートン・プロトコルのドキュメントを読んだあと、しばらく頭を占めたアイデアがある。最初はポリシーを、みんなと同じように捉えていた。つまり意図と実行の間にある検証のための層だ。
ブロックチェーンがアクションを実行する前に、AIエージェントに何を許可するのかを決めるものではない。そういうふうに、最初の読みで自分は理解した。けれども二度目の読みでは、別の何かが見えてきた。
たぶん、将来いちばん「ポリシー」を読む存在は、人間ではないかもしれない。AIだ。なんだか変に聞こえる。でも考えれば考えるほど、納得できる気がしてくる。
Newtonプロトコルについての一つの疑問が、そのアーキテクチャよりも長く私の中に残っています。 バリデータはネットワークを保全することで報酬を得ます。 オラクルは信頼できるデータを提供することで報酬を得ます。 しかしNewtonが新しいインフラ層としてPolicy Authors(ポリシー作成者)を導入したとき、私は自分に問い続けています。 人々は、ポリシーを作り続け、維持し続けるために何に動機づけられるのだろうか? ポリシーは決して静的なものではありません。 規制は進化します。組織は変わります。AIエージェントはより能力を高めます。新しいリスクは絶えず生まれます。 インセンティブがなければ、すべてのアプリケーションが依存するインフラ層を、誰が継続的に更新するのでしょうか? 私にとって、これはNewtonが抱える最大級の経済的な問いの一つです。 初期のインセンティブは、最初の世代のポリシーを促すためにプロトコルから提供されるかもしれません。 エコシステムが成熟するにつれて、ユーザーは自分で作って監査するのではなく、信頼するポリシーに対して支払うようになるでしょう。 しかし最も価値の高い報酬は、ずっと後のことです。 ポリシーは単なる再利用可能なコードにとどまらず、エコシステム全体で採用されるデフォルトの意思決定フレームワークになります。 その時点では、Policy Authorは「何本のポリシーを書いたか」で評価されなくなります。 評価されるのは、「市場がどれだけの意思決定を彼らのポリシーに委ねたか」です。 それは収益以上のもの。 それは信頼性です。 Bitcoinはセキュリティを生み出すインセンティブを作りました。 Oraclesはデータを生み出すインセンティブを作りました。 もしNewtonが成功すれば、継続的に信頼できる意思決定フレームワークを作り出すためのインセンティブを生み出す、最初のブロックチェーンになるかもしれません。 おそらく、それこそがNewtonが築こうとしている本当の経済圏なのです。 @NewtonProtocol $NEWT #Newt $LAB $TAC
Newtonプロトコルについての一つの疑問が、そのアーキテクチャよりも長く私の中に残っています。

バリデータはネットワークを保全することで報酬を得ます。
オラクルは信頼できるデータを提供することで報酬を得ます。
しかしNewtonが新しいインフラ層としてPolicy Authors(ポリシー作成者)を導入したとき、私は自分に問い続けています。
人々は、ポリシーを作り続け、維持し続けるために何に動機づけられるのだろうか?

ポリシーは決して静的なものではありません。
規制は進化します。組織は変わります。AIエージェントはより能力を高めます。新しいリスクは絶えず生まれます。
インセンティブがなければ、すべてのアプリケーションが依存するインフラ層を、誰が継続的に更新するのでしょうか?

私にとって、これはNewtonが抱える最大級の経済的な問いの一つです。
初期のインセンティブは、最初の世代のポリシーを促すためにプロトコルから提供されるかもしれません。
エコシステムが成熟するにつれて、ユーザーは自分で作って監査するのではなく、信頼するポリシーに対して支払うようになるでしょう。
しかし最も価値の高い報酬は、ずっと後のことです。
ポリシーは単なる再利用可能なコードにとどまらず、エコシステム全体で採用されるデフォルトの意思決定フレームワークになります。
その時点では、Policy Authorは「何本のポリシーを書いたか」で評価されなくなります。
評価されるのは、「市場がどれだけの意思決定を彼らのポリシーに委ねたか」です。
それは収益以上のもの。
それは信頼性です。

Bitcoinはセキュリティを生み出すインセンティブを作りました。
Oraclesはデータを生み出すインセンティブを作りました。

もしNewtonが成功すれば、継続的に信頼できる意思決定フレームワークを作り出すためのインセンティブを生み出す、最初のブロックチェーンになるかもしれません。
おそらく、それこそがNewtonが築こうとしている本当の経済圏なのです。
@NewtonProtocol $NEWT #Newt $LAB $TAC
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約