Binance Square
0xMinh
1.7k 投稿

0xMinh

Researcher / Airdrop Hunter $BTC $ETH Web 3 Airdrop | X : @M91inktats
取引を発注
低高頻度トレーダー
5年
149 フォロー
450 フォロワー
1.9K+ いいね
投稿
ポートフォリオ
·
--
本人確認中
以前は、コンプライアンスはブロックチェーンの外側にあるものだと思っていました。プロトコルは許可不要(permissionless)であればよく、規制への対応はアプリケーションや仲介者が処理すればよい、という考えです。 Dusk Networkについてさらに深く調べるうちに、立ち止まらざるを得ないアプローチに出会いました。コンプライアンスは単に上から被せる「検査レイヤー」のように見なされるのではなく、資産、アイデンティティ、アクセス権、そしてデータをシステムがモデル化する方法そのものの中に現れてくるのです。 最初は、DuskがRWAのためにいくつかのツールを追加しているだけなのだと思いましたが、もっと広い問題だと気づきました。規制対象の資産であれば、適格性(eligibility)、移転制限(transfer restriction)、開示(disclosure)、そして決済(settlement)は、すでに資産のライフサイクルの一部になっています。 現時点での私の見方は、Dusk Networkがそれらの制約を同じ運用環境に取り込もうとしているというものです。Citadelはidentityとselective disclosureを扱い、MoonlightとPhoenixは、透明性とプライバシーのバランスを可能にします。 これは別のtrust modelを反映しています。ブロックチェーンは規制に対して完全に中立であるべきだと仮定するのではなく、Duskは、市場の運用が規制されるのであれば、その「規制された市場」もまたプログラマブルである必要があるのだと仮定しているように見えるのです。 私はそれが自動的にDuskを他のあらゆるLayer 1よりも適していると結論づけるものだとは、いまだに思っていません。より面白い問いはこうです。Regulationがシステム設計の一部としてプロトコル、アプリケーション、そして金融インフラの境界に組み込まれたとき、その役割は一体どこに置かれるのだろうか? #dusk $DUSK @Dusk_Foundation $BTC
以前は、コンプライアンスはブロックチェーンの外側にあるものだと思っていました。プロトコルは許可不要(permissionless)であればよく、規制への対応はアプリケーションや仲介者が処理すればよい、という考えです。

Dusk Networkについてさらに深く調べるうちに、立ち止まらざるを得ないアプローチに出会いました。コンプライアンスは単に上から被せる「検査レイヤー」のように見なされるのではなく、資産、アイデンティティ、アクセス権、そしてデータをシステムがモデル化する方法そのものの中に現れてくるのです。
最初は、DuskがRWAのためにいくつかのツールを追加しているだけなのだと思いましたが、もっと広い問題だと気づきました。規制対象の資産であれば、適格性(eligibility)、移転制限(transfer restriction)、開示(disclosure)、そして決済(settlement)は、すでに資産のライフサイクルの一部になっています。
現時点での私の見方は、Dusk Networkがそれらの制約を同じ運用環境に取り込もうとしているというものです。Citadelはidentityとselective disclosureを扱い、MoonlightとPhoenixは、透明性とプライバシーのバランスを可能にします。

これは別のtrust modelを反映しています。ブロックチェーンは規制に対して完全に中立であるべきだと仮定するのではなく、Duskは、市場の運用が規制されるのであれば、その「規制された市場」もまたプログラマブルである必要があるのだと仮定しているように見えるのです。

私はそれが自動的にDuskを他のあらゆるLayer 1よりも適していると結論づけるものだとは、いまだに思っていません。より面白い問いはこうです。Regulationがシステム設計の一部としてプロトコル、アプリケーション、そして金融インフラの境界に組み込まれたとき、その役割は一体どこに置かれるのだろうか?
#dusk $DUSK @Dusk $BTC
·
--
以前私は、プライバシーとコンプライアンスはほぼ相反する二つの方向だと思っていました。一方はデータを隠したいのに対し、もう一方は必要に応じて検査・検証・追跡(トレーサビリティ)できる能力を求める。私はその見方にかなり長く慣れていたので、Dusk Network について読むときも最初は、何らかのトレードオフがあるはずだと待ち構えていました。 しかし資料を読み進めるほど、別の考えに行き着かざるを得なくなりました。それは、プライバシーは必ずしも「すべてを見えないものにしなければならない」という意味ではない、ということです。 最初私は、Dusk Network はゼロ知識証明によって取引をより秘匿にしようとしているだけだと考えました。その後、問題は「誰がデータを見ることを許可されるか」という権限の設計にあるのだと気づきました。 Phoenix は取引情報を隠せますが、selective disclosure(選択的開示)によって、許可された当事者には具体的なデータを開示できます。Moonlight は、公開が必要なときにはフローを透明に保ちます。 そのとき初めて、自分が間違った問いを立てていたことを理解しました。 「プライバシーかコンプライアンスか?」ではなく、「誰が、何を、どのような状況で知る必要があるのか?」です。 少なくとも私の現在の視点では、Dusk Network はその方向で trust model(信頼の前提のあり方)を変えようとしています。システムは、すべての人が同じ“真実”を同時に見ることを求めるのではなく、検証に十分な証拠を作りつつ、知る権限を制限しようとしています。 私はまだ、これがコンプライアンスのための完全な解決策だとは考えていません。法律は依然としてブロックチェーンの外にあります。 そしておそらく、さらに考えるべきなのは、Dusk Network は矛盾を消し去ろうとしているのではなく、私たちが“矛盾”をどう定義するかを変えようとしている点です。 #dusk $DUSK @Dusk_Foundation $BTC
以前私は、プライバシーとコンプライアンスはほぼ相反する二つの方向だと思っていました。一方はデータを隠したいのに対し、もう一方は必要に応じて検査・検証・追跡(トレーサビリティ)できる能力を求める。私はその見方にかなり長く慣れていたので、Dusk Network について読むときも最初は、何らかのトレードオフがあるはずだと待ち構えていました。
しかし資料を読み進めるほど、別の考えに行き着かざるを得なくなりました。それは、プライバシーは必ずしも「すべてを見えないものにしなければならない」という意味ではない、ということです。
最初私は、Dusk Network はゼロ知識証明によって取引をより秘匿にしようとしているだけだと考えました。その後、問題は「誰がデータを見ることを許可されるか」という権限の設計にあるのだと気づきました。
Phoenix は取引情報を隠せますが、selective disclosure(選択的開示)によって、許可された当事者には具体的なデータを開示できます。Moonlight は、公開が必要なときにはフローを透明に保ちます。
そのとき初めて、自分が間違った問いを立てていたことを理解しました。
「プライバシーかコンプライアンスか?」ではなく、「誰が、何を、どのような状況で知る必要があるのか?」です。
少なくとも私の現在の視点では、Dusk Network はその方向で trust model(信頼の前提のあり方)を変えようとしています。システムは、すべての人が同じ“真実”を同時に見ることを求めるのではなく、検証に十分な証拠を作りつつ、知る権限を制限しようとしています。
私はまだ、これがコンプライアンスのための完全な解決策だとは考えていません。法律は依然としてブロックチェーンの外にあります。
そしておそらく、さらに考えるべきなのは、Dusk Network は矛盾を消し去ろうとしているのではなく、私たちが“矛盾”をどう定義するかを変えようとしている点です。
#dusk $DUSK @Dusk $BTC
·
--
以前私は、トークン化はほぼ流動性と同義だと思っていました。ある資産をブロックチェーンに載せ、所有権を細分化して、多くの人が参加できるようにする――それはかなり筋が通っているように聞こえます。しかし、Dusk Network と、彼らが RWA に取り組む方法を深く読み進めるうちに、その前提には問題があると感じ始めました。「トークン化できる」ことと「効率的に取引できる」ことの間にはギャップがあります。 最初は、ブロックチェーンこそが最も難しい部分だと思っていました。ですが、トークンを作ることは問題の解決のうちの一層にすぎないと気づきました。流動性は、法的側面、所有権、譲渡可能性、そして当事者間の信頼にも依存します。 現在の私の見方は、それまでのものとはかなり違います。トークン化は自動的に流動性を生み出すわけではなく、デジタル・システム内で資産を表現し、より容易に移転できるようにするだけです。 Dusk Network で私が注目したのは、彼らがブロックチェーンを現実の資産に対する制約から切り離していないことです。RWA が証券に関わる場合、投資家や規制といった要素が絡みます。「オープンにする」ことが、単純に「誰でも参加できる」という意味にはなりません。 そのとき初めて、より深い問題はトークンそのものにあるのではなく、その背後にある信頼のモデルにあるのだと理解しました。 それでも一つ疑問が残ります。もしブロックチェーンが取引の摩擦を減らしてくれるとしても、法的な制約がなお残っているなら、私たちは本当に新しい流動性を生み出したのでしょうか。それとも、古い流動性を別の形に移し替えているだけなのでしょうか? #dusk $DUSK @Dusk_Foundation $BTC
以前私は、トークン化はほぼ流動性と同義だと思っていました。ある資産をブロックチェーンに載せ、所有権を細分化して、多くの人が参加できるようにする――それはかなり筋が通っているように聞こえます。しかし、Dusk Network と、彼らが RWA に取り組む方法を深く読み進めるうちに、その前提には問題があると感じ始めました。「トークン化できる」ことと「効率的に取引できる」ことの間にはギャップがあります。

最初は、ブロックチェーンこそが最も難しい部分だと思っていました。ですが、トークンを作ることは問題の解決のうちの一層にすぎないと気づきました。流動性は、法的側面、所有権、譲渡可能性、そして当事者間の信頼にも依存します。
現在の私の見方は、それまでのものとはかなり違います。トークン化は自動的に流動性を生み出すわけではなく、デジタル・システム内で資産を表現し、より容易に移転できるようにするだけです。

Dusk Network で私が注目したのは、彼らがブロックチェーンを現実の資産に対する制約から切り離していないことです。RWA が証券に関わる場合、投資家や規制といった要素が絡みます。「オープンにする」ことが、単純に「誰でも参加できる」という意味にはなりません。
そのとき初めて、より深い問題はトークンそのものにあるのではなく、その背後にある信頼のモデルにあるのだと理解しました。
それでも一つ疑問が残ります。もしブロックチェーンが取引の摩擦を減らしてくれるとしても、法的な制約がなお残っているなら、私たちは本当に新しい流動性を生み出したのでしょうか。それとも、古い流動性を別の形に移し替えているだけなのでしょうか?
#dusk $DUSK @Dusk $BTC
·
--
以前私は、ブロックチェーン上のプライバシーとは取引をすべて隠すことと同義だと思っていました。公開されるデータが少なければ少ないほど、それは良い設計だと考えていました。 しかしDusk Networkについてさらに深く読むと、その前提は変わり始めます。Phoenixには、私が何度も読み返さずにはいられなかった細部があります。それは「ネットワークは取引を検証する必要があるが、内部の全ての価値を見せる必要はない」という点です。 最初はConfidential Transactionを単に金額を暗号化する仕組みだと思っていましたが、それでは不十分だと気づきました。Phoenixはshielded notesとnullifiersを使用しています。ゼロ知識証明により、取引の支払い権限、妥当性、そしてダブルスペンドの防止を、取引の機微なデータを公開せずに証明できます。 私の捉え方では、違いは「検証される」ことと「見られる」ことの境界にあります。ブロックチェーンは取引が有効であることを知る必要はありますが、金額や参加者を必ずしも知る必要はありません。 Phoenix 2.0は、この考えをさらに一歩進めます。受取人は送信者を特定できますが、その情報が全ネットワークに対する公開データになるわけではありません。 私が特に注目したのは、もはやプライバシー機能そのものではありません。この設計が信頼のモデルをどう変えるのかです。人々にデータを見せてそれを信じさせるのではなく、システムは、ある程度の観測を暗号学的な証明で置き換えます。 そしておそらく、さらに難しい問いはこれです。管理された金融向けのブロックチェーンにおいて、私たちは本当に何を隠したいのか、そして何を証明したいのか? #dusk $DUSK @Dusk_Foundation $BTC
以前私は、ブロックチェーン上のプライバシーとは取引をすべて隠すことと同義だと思っていました。公開されるデータが少なければ少ないほど、それは良い設計だと考えていました。
しかしDusk Networkについてさらに深く読むと、その前提は変わり始めます。Phoenixには、私が何度も読み返さずにはいられなかった細部があります。それは「ネットワークは取引を検証する必要があるが、内部の全ての価値を見せる必要はない」という点です。
最初はConfidential Transactionを単に金額を暗号化する仕組みだと思っていましたが、それでは不十分だと気づきました。Phoenixはshielded notesとnullifiersを使用しています。ゼロ知識証明により、取引の支払い権限、妥当性、そしてダブルスペンドの防止を、取引の機微なデータを公開せずに証明できます。
私の捉え方では、違いは「検証される」ことと「見られる」ことの境界にあります。ブロックチェーンは取引が有効であることを知る必要はありますが、金額や参加者を必ずしも知る必要はありません。
Phoenix 2.0は、この考えをさらに一歩進めます。受取人は送信者を特定できますが、その情報が全ネットワークに対する公開データになるわけではありません。
私が特に注目したのは、もはやプライバシー機能そのものではありません。この設計が信頼のモデルをどう変えるのかです。人々にデータを見せてそれを信じさせるのではなく、システムは、ある程度の観測を暗号学的な証明で置き換えます。
そしておそらく、さらに難しい問いはこれです。管理された金融向けのブロックチェーンにおいて、私たちは本当に何を隠したいのか、そして何を証明したいのか?
#dusk $DUSK @Dusk $BTC
·
--
以前私は、ブロックチェーンの採用(adoption)は開発者、アプリケーション、そしてユーザーから始まるのだと思っていました。ユーザーが増えれば、エコシステムは自然に拡大していくはずだ、と。 私はそれをほぼ法則のように見ていましたが、Dusk Networkについてより深く読んでみると、この前提に疑いを持ち始めました。 私が立ち止まったのはNPEXとの関係です。Duskは2020年からNPEXの株主になっている一方で、NPEXはオランダでライセンスを受けたMTFです。 当初はNPEXが主にRWAのためのユースケースを提供しているのだと思っていましたが、その後、もっと広い問題だと気づきました。採用には、単にブロックチェーンが優れているだけでは足りません。発行体、投資家のアクセス、取引の場、そして市場に受け入れられてきたプロセスが必要です。 NPEXはすでにその市場の一部分を備えています。Duskは、発行、取引、決済といったワークフローをオンチェーンに載せるためのインフラを提供しています。 そのため、私の見方は以前とは変わりました。NPEXは、採用がすでに起きたことを証明するものではありませんが、採用が始まるためのより現実的な道筋を作り得ます。 ここで考えさせられるのは、こうです。従来の市場を“追いかけて”ブロックチェーンのDuskを探すのではなく、Duskは“すでに存在する市場”にブロックチェーンを持ち込もうとしているのだ、ということ。 このモデルがどこまで広がるかはまだ分かりませんが、重要な問いは、おそらくDuskにどれだけユーザーがいるかではなく、NPEXが実際の金融ニーズをオンチェーンのインフラ利用ニーズへと変えられるかどうかです。#dusk $DUSK @Dusk_Foundation $BTC
以前私は、ブロックチェーンの採用(adoption)は開発者、アプリケーション、そしてユーザーから始まるのだと思っていました。ユーザーが増えれば、エコシステムは自然に拡大していくはずだ、と。
私はそれをほぼ法則のように見ていましたが、Dusk Networkについてより深く読んでみると、この前提に疑いを持ち始めました。
私が立ち止まったのはNPEXとの関係です。Duskは2020年からNPEXの株主になっている一方で、NPEXはオランダでライセンスを受けたMTFです。
当初はNPEXが主にRWAのためのユースケースを提供しているのだと思っていましたが、その後、もっと広い問題だと気づきました。採用には、単にブロックチェーンが優れているだけでは足りません。発行体、投資家のアクセス、取引の場、そして市場に受け入れられてきたプロセスが必要です。

NPEXはすでにその市場の一部分を備えています。Duskは、発行、取引、決済といったワークフローをオンチェーンに載せるためのインフラを提供しています。
そのため、私の見方は以前とは変わりました。NPEXは、採用がすでに起きたことを証明するものではありませんが、採用が始まるためのより現実的な道筋を作り得ます。

ここで考えさせられるのは、こうです。従来の市場を“追いかけて”ブロックチェーンのDuskを探すのではなく、Duskは“すでに存在する市場”にブロックチェーンを持ち込もうとしているのだ、ということ。

このモデルがどこまで広がるかはまだ分かりませんが、重要な問いは、おそらくDuskにどれだけユーザーがいるかではなく、NPEXが実際の金融ニーズをオンチェーンのインフラ利用ニーズへと変えられるかどうかです。#dusk $DUSK @Dusk $BTC
·
--
以前私はレンディングプロトコルをかなり単純なものだと思っていました。つまり、ある人が資金を預け、別の人が借りる。そして金利は、市場によって変動調整されるだけだと。私は重要なのは、主に流動性の配分と、借入に関するリスクの管理だとほぼ決めつけていました。 TermMaxをさらに深く読んでみると、私が立ち止まらざるを得ない点がひとつありました。それは、このプロトコルが単に固定金利を設定するだけでなく、借入を具体的な満期時点と結びつけていることです。 最初は、これはfixed rate lendingの一種のバリエーションにすぎないのだろうと思いました。しかしその後、この見方はまだ従来型のレンディングモデルにあまりに近いと気づきました。TermMaxは、金利だけでなく、期間と将来価値を受け取る権利までを、取引可能な構造として組み込んでいます。 その時、なぜドキュメントがFT、XT、そして価格付けカーブについてこれほど詳しく語っているのかが初めて理解できました。それらは単なる補助的なトークンではなく、借り手と貸し手の権利を分離し、交換できるようにすることで、仕組みそのものを変えるからです。 いまの観点では、私はTermMaxを単に「資産を預ける場所」または「資産を借りる場所」とは見なせなくなりました。 私はそれを、時間と金利がそれぞれ個別に価格付けされる、オンチェーンのfixed income市場を構築しようとする試みとして捉え始めました。 ただ、それでも気になっています。このモデルで期間を市場の一部に変えることで、DeFiにおける流動性の定義がどの程度まで変わってしまうのか、という点です。 #termmax @termmax $BTC
以前私はレンディングプロトコルをかなり単純なものだと思っていました。つまり、ある人が資金を預け、別の人が借りる。そして金利は、市場によって変動調整されるだけだと。私は重要なのは、主に流動性の配分と、借入に関するリスクの管理だとほぼ決めつけていました。

TermMaxをさらに深く読んでみると、私が立ち止まらざるを得ない点がひとつありました。それは、このプロトコルが単に固定金利を設定するだけでなく、借入を具体的な満期時点と結びつけていることです。
最初は、これはfixed rate lendingの一種のバリエーションにすぎないのだろうと思いました。しかしその後、この見方はまだ従来型のレンディングモデルにあまりに近いと気づきました。TermMaxは、金利だけでなく、期間と将来価値を受け取る権利までを、取引可能な構造として組み込んでいます。
その時、なぜドキュメントがFT、XT、そして価格付けカーブについてこれほど詳しく語っているのかが初めて理解できました。それらは単なる補助的なトークンではなく、借り手と貸し手の権利を分離し、交換できるようにすることで、仕組みそのものを変えるからです。

いまの観点では、私はTermMaxを単に「資産を預ける場所」または「資産を借りる場所」とは見なせなくなりました。
私はそれを、時間と金利がそれぞれ個別に価格付けされる、オンチェーンのfixed income市場を構築しようとする試みとして捉え始めました。

ただ、それでも気になっています。このモデルで期間を市場の一部に変えることで、DeFiにおける流動性の定義がどの程度まで変わってしまうのか、という点です。
#termmax @TermMax $BTC
·
--
かつて私は、強い流動性はプロトコル内に置かれている資金量を見るだけで分かると思っていました。しかしTermMaxについて読み進めるほど、その測り方では物語の全てを捉えきれていないことに気づきました。 資金は、複数の異なる市場に分配することができます。問題は、ある市場で大きな需要が発生したとき、別の市場に置かれている資金がすぐにスムーズに移せるわけではないことです。 その点が、私がAtomic Ordersについて読む際に特に注目した詳細でした。 TermMaxの設計では、同じ流動性の元手を複数の市場に同時に配置することはできますが、それを複数回利用することはできません。ある注文が流動性の一部を取り出すと、その対応分は同時に他の市場からも消えます。 最初は、これは単に「より深く見える」流動性の作り方に過ぎないのだと思いました。しかしその後、実際の問題は資金配分能力にあるのだと理解しました。 最初から資金をある市場にがっちり固定する必要はありません。資金は複数の異なる需要の背後に待機しておき、実際に取引が発生した場所で初めて消費されるのです。 そのため、私の見方として現在のAtomic Ordersは、流動性をさらに“増やす”仕組みではなく、需要が出現する前に配置されていた流動性の位置づけを変える方法に近いと感じています。 とはいえ、私は引き続き実データも見てみたいです。たとえば、板の深さ(約定の深さ)、ローンのサイズ、そして資金の稼働(使用)状況が時間とともにどう変化するかです。 おそらく私にとって関心のある問いは、TermMaxにどれだけTVLがあるかということではなく、各ユニットの流動性が実際にどれだけ効率よく市場を支えられるのか、という点です。 #termmax @termmax $BTC
かつて私は、強い流動性はプロトコル内に置かれている資金量を見るだけで分かると思っていました。しかしTermMaxについて読み進めるほど、その測り方では物語の全てを捉えきれていないことに気づきました。

資金は、複数の異なる市場に分配することができます。問題は、ある市場で大きな需要が発生したとき、別の市場に置かれている資金がすぐにスムーズに移せるわけではないことです。

その点が、私がAtomic Ordersについて読む際に特に注目した詳細でした。
TermMaxの設計では、同じ流動性の元手を複数の市場に同時に配置することはできますが、それを複数回利用することはできません。ある注文が流動性の一部を取り出すと、その対応分は同時に他の市場からも消えます。

最初は、これは単に「より深く見える」流動性の作り方に過ぎないのだと思いました。しかしその後、実際の問題は資金配分能力にあるのだと理解しました。
最初から資金をある市場にがっちり固定する必要はありません。資金は複数の異なる需要の背後に待機しておき、実際に取引が発生した場所で初めて消費されるのです。

そのため、私の見方として現在のAtomic Ordersは、流動性をさらに“増やす”仕組みではなく、需要が出現する前に配置されていた流動性の位置づけを変える方法に近いと感じています。
とはいえ、私は引き続き実データも見てみたいです。たとえば、板の深さ(約定の深さ)、ローンのサイズ、そして資金の稼働(使用)状況が時間とともにどう変化するかです。

おそらく私にとって関心のある問いは、TermMaxにどれだけTVLがあるかということではなく、各ユニットの流動性が実際にどれだけ効率よく市場を支えられるのか、という点です。
#termmax @TermMax $BTC
·
--
私は、サポートに連絡することについての考え方を変えなければならない状況に遭遇したことがあります。ちょうど2026年の旧正月が近い頃、私は家の備品を買うためにBinance P2Pで500 USDTを売っていました。購入者は「13,000,000 VND(約1300万ドン)」を送金したうえで、チャットの枠内に領収書の画像を送ったと言っていましたが、銀行口座を確認すると実際に入金が確認できませんでした。 そのときの私の最初の反応はとてもシンプルで、購入者が支払ったのに、私はまだお金を受け取っていないのだとサポートに連絡し、問題を処理し始めればよいと思ったのです。 しかし、ふと考えを少し止めてBinance P2Pについて詳しく読み直すと、私が見落としていた手順があることに気づきました。Binanceは、トラブル(紛争)が発生した場合、両者が appeal(異議申立て)を開くことができ、サポートチームは関連する証拠を確認すると説明しています。そうなると、考え直さなければなりません。 ただ状況を説明するのではなく、私は注文ID、取引のステータス、受け取るべき金額、そして銀行口座の入出金履歴を確認し始めました。また、必要になったときのために、確認画像や関連する証拠も保存しておきました。 最初はサポートを「問題を解決してくれる場所」として捉えていましたが、その後、自分にも介入を求める前に十分に明確なデータを準備する責任があることに気づきました。違いは、私が「照合できる話」や「照合できる事実」を提示できているかどうかにあるのです。 必要な証拠情報をきちんと準備していたおかげで、その後はすべて非常にスムーズに進みました。 それ以来、私はサポートを探す前に、検証できるものがすべて確認するようにしています。新しいデータの紛争ではこそ、信頼できる根拠が重要です。#binancep2pantoan @Binance_Vietnam $BTC
私は、サポートに連絡することについての考え方を変えなければならない状況に遭遇したことがあります。ちょうど2026年の旧正月が近い頃、私は家の備品を買うためにBinance P2Pで500 USDTを売っていました。購入者は「13,000,000 VND(約1300万ドン)」を送金したうえで、チャットの枠内に領収書の画像を送ったと言っていましたが、銀行口座を確認すると実際に入金が確認できませんでした。

そのときの私の最初の反応はとてもシンプルで、購入者が支払ったのに、私はまだお金を受け取っていないのだとサポートに連絡し、問題を処理し始めればよいと思ったのです。

しかし、ふと考えを少し止めてBinance P2Pについて詳しく読み直すと、私が見落としていた手順があることに気づきました。Binanceは、トラブル(紛争)が発生した場合、両者が appeal(異議申立て)を開くことができ、サポートチームは関連する証拠を確認すると説明しています。そうなると、考え直さなければなりません。

ただ状況を説明するのではなく、私は注文ID、取引のステータス、受け取るべき金額、そして銀行口座の入出金履歴を確認し始めました。また、必要になったときのために、確認画像や関連する証拠も保存しておきました。

最初はサポートを「問題を解決してくれる場所」として捉えていましたが、その後、自分にも介入を求める前に十分に明確なデータを準備する責任があることに気づきました。違いは、私が「照合できる話」や「照合できる事実」を提示できているかどうかにあるのです。

必要な証拠情報をきちんと準備していたおかげで、その後はすべて非常にスムーズに進みました。

それ以来、私はサポートを探す前に、検証できるものがすべて確認するようにしています。新しいデータの紛争ではこそ、信頼できる根拠が重要です。#binancep2pantoan @Binance Vietnam $BTC
·
--
今日は、ダスクがプライベート取引をどのように処理するのかについて、かなり時間をかけて読んでいました。そこで、以前は見落としていたある細部に気づき始めました。 ここでいうプライバシーは、単に後付けの“層”を加えることではありません。ダスクはゼロ知識証明を使って、その裏にあるデータのすべてを公開することなく、ある条件が正しいことを証明します。それは支払い能力であったり、参加条件、あるいは取引の状態である場合もあります。 最初は、暗号資産はたいてい二者択一を迫られるものだと思っていました。検証しやすいように透明性を選ぶか、データを隠すためにプライバシーを選ぶか。ですが、選択的開示について読み進めるほど、この問題の立て方自体が、あまりにも単純すぎるのではないかと感じてきました。 私の今の見方では、プライバシーは必ずしも監査不可能を意味しません。権限を持つ一方は、必要な情報を見ることを許可され、他の人々は取引が条件を満たしたことだけを知っていればよい、という形も成り立ちます。 Zedger と、ダスクが進める資産トークン化は、まさにこの点に私の関心を向けさせました。Solidity の開発者が、最初からやり直すことなくエコシステムに入ってこられるよう道を開くという意味で、DuskEVM も注目に値します。 ただ、私はまだ結論を急ぎたくありません。 「プライベートだが監査可能」という設計上の考え方は、確かに筋が通っています。難しいのは、それが規制当局、実際の紛争、そして大規模さといった現実に直面したときに、どこまで耐えられるかという点です。 NPEX は、このモデルが現実の市場へより近づけられていることを示していますが、実地での検証と、大規模な形での実証・証明は別問題です。 おそらく、それが私がダスクで引き続き観察したい部分なのです。 #dusk $DUSK @Dusk_Foundation $BTC
今日は、ダスクがプライベート取引をどのように処理するのかについて、かなり時間をかけて読んでいました。そこで、以前は見落としていたある細部に気づき始めました。
ここでいうプライバシーは、単に後付けの“層”を加えることではありません。ダスクはゼロ知識証明を使って、その裏にあるデータのすべてを公開することなく、ある条件が正しいことを証明します。それは支払い能力であったり、参加条件、あるいは取引の状態である場合もあります。

最初は、暗号資産はたいてい二者択一を迫られるものだと思っていました。検証しやすいように透明性を選ぶか、データを隠すためにプライバシーを選ぶか。ですが、選択的開示について読み進めるほど、この問題の立て方自体が、あまりにも単純すぎるのではないかと感じてきました。

私の今の見方では、プライバシーは必ずしも監査不可能を意味しません。権限を持つ一方は、必要な情報を見ることを許可され、他の人々は取引が条件を満たしたことだけを知っていればよい、という形も成り立ちます。
Zedger と、ダスクが進める資産トークン化は、まさにこの点に私の関心を向けさせました。Solidity の開発者が、最初からやり直すことなくエコシステムに入ってこられるよう道を開くという意味で、DuskEVM も注目に値します。
ただ、私はまだ結論を急ぎたくありません。
「プライベートだが監査可能」という設計上の考え方は、確かに筋が通っています。難しいのは、それが規制当局、実際の紛争、そして大規模さといった現実に直面したときに、どこまで耐えられるかという点です。
NPEX は、このモデルが現実の市場へより近づけられていることを示していますが、実地での検証と、大規模な形での実証・証明は別問題です。
おそらく、それが私がダスクで引き続き観察したい部分なのです。
#dusk $DUSK @Dusk $BTC
·
--
以前自分は、余剰資金ができたら最も重要なのは最高の利回りを探すことだと思っていました。でもTermMaxについて調べるほど、見方が変わってきました。固定金利がもたらすのは、DeFiでも必ずしも常に手に入るわけではないもの――予測可能性です。 自分は利回り水準と期間を把握でき、それらの数字にもとづいて計画を立てられますが、その確実性には必ず何らかの代償が伴います。ポジションを確定した後も、市場は変化し続けます。利回りがさらに高くなる可能性もありますし、別の機会が現れるかもしれません。または単に、途中で自分の戦略が変わることもあります。そのとき、かつて安全だと感じていたものが、制約になってしまうのです。 だから私は、固定金利が良いのか変動金利が良いのか、もう二択で考えなくなりました。いまの視点では、どちらも別々の2つのニーズに対応しているだけです。固定金利は確実性を優先し、変動金利は柔軟性を優先します。 仮に6か月間、15,000 USDを貸し出すとします。私は「どちらが利回りが高いか」を聞くだけではありません。「利益を固定して安定と引き換えるのか、それとも市場の変動に応じてポジションを変更する権利を保持するのか?」を問い直します。もしかすると、資金を両方に分けるのも選択肢でしょう。結局のところ、考えるべき問いは、どちらが良いかではなく、自分が何をもってどんな代償を払い得るのか――その点にあります。#termmax @termmax
以前自分は、余剰資金ができたら最も重要なのは最高の利回りを探すことだと思っていました。でもTermMaxについて調べるほど、見方が変わってきました。固定金利がもたらすのは、DeFiでも必ずしも常に手に入るわけではないもの――予測可能性です。

自分は利回り水準と期間を把握でき、それらの数字にもとづいて計画を立てられますが、その確実性には必ず何らかの代償が伴います。ポジションを確定した後も、市場は変化し続けます。利回りがさらに高くなる可能性もありますし、別の機会が現れるかもしれません。または単に、途中で自分の戦略が変わることもあります。そのとき、かつて安全だと感じていたものが、制約になってしまうのです。

だから私は、固定金利が良いのか変動金利が良いのか、もう二択で考えなくなりました。いまの視点では、どちらも別々の2つのニーズに対応しているだけです。固定金利は確実性を優先し、変動金利は柔軟性を優先します。

仮に6か月間、15,000 USDを貸し出すとします。私は「どちらが利回りが高いか」を聞くだけではありません。「利益を固定して安定と引き換えるのか、それとも市場の変動に応じてポジションを変更する権利を保持するのか?」を問い直します。もしかすると、資金を両方に分けるのも選択肢でしょう。結局のところ、考えるべき問いは、どちらが良いかではなく、自分が何をもってどんな代償を払い得るのか――その点にあります。#termmax @TermMax
·
--
以前、私は金融市場が、いくつもの連続したシステムをつなぎ合わせるように運用されているのだと思っていました。ある場所で発行し、別の場所で取引し、その後に決済や照合作業を行う。 Dusk Network と NPEX を深く読み込むにつれ、その前提を見直し始めました。私が立ち止まる理由になったのは、資産をブロックチェーンに載せるという概念そのものではなく、Dusk が資産の全ワークフローをどのように連結して描いているかという点です。 最初は、これは依然として主にトークン化だと考えていました。資産を表すトークンを作成し、それを市場に投入する、というものです。しかし Dusk の資料は、トークン化とネイティブ・イシュアンス(native issuance)をかなり明確に区別しています。ネイティブ・イシュアンスでは、資産のライフサイクルを、単にトークンを表現レイヤーとして使うのではなく、台帳そのものの周りに設計できます。 その後、より重要な部分を見落としていたことに気づきました。Dusk Trade は売買の話だけではありません。適格性(eligibility)、開示(disclosure)、payment leg と asset leg の連携、そして settlement を含みます。 NPEX は、管理された市場インフラの層も提供しています。現在の Dusk では、イシュアンス、取引、開示、決済を、統一された onchain ワークフローに入れ込もうとしている両者を描写しています。 私の現在の見方では、最大の変化は trust model にあります。問題はもはや「トークンがブロックチェーン上にあるかどうか」ではなく、「アクセス権、譲渡、情報、そして決済に関するルールが、どれだけ一貫して同時に実行できるか」です。 私はまだ、ブロックチェーンが実行する領域と、NPEX の法的枠組みが引き続き担う領域の境界について疑問があります。たぶん、それこそが最も追うべき部分なのです。 #dusk $DUSK @Dusk_Foundation $BTC
以前、私は金融市場が、いくつもの連続したシステムをつなぎ合わせるように運用されているのだと思っていました。ある場所で発行し、別の場所で取引し、その後に決済や照合作業を行う。

Dusk Network と NPEX を深く読み込むにつれ、その前提を見直し始めました。私が立ち止まる理由になったのは、資産をブロックチェーンに載せるという概念そのものではなく、Dusk が資産の全ワークフローをどのように連結して描いているかという点です。

最初は、これは依然として主にトークン化だと考えていました。資産を表すトークンを作成し、それを市場に投入する、というものです。しかし Dusk の資料は、トークン化とネイティブ・イシュアンス(native issuance)をかなり明確に区別しています。ネイティブ・イシュアンスでは、資産のライフサイクルを、単にトークンを表現レイヤーとして使うのではなく、台帳そのものの周りに設計できます。

その後、より重要な部分を見落としていたことに気づきました。Dusk Trade は売買の話だけではありません。適格性(eligibility)、開示(disclosure)、payment leg と asset leg の連携、そして settlement を含みます。
NPEX は、管理された市場インフラの層も提供しています。現在の Dusk では、イシュアンス、取引、開示、決済を、統一された onchain ワークフローに入れ込もうとしている両者を描写しています。

私の現在の見方では、最大の変化は trust model にあります。問題はもはや「トークンがブロックチェーン上にあるかどうか」ではなく、「アクセス権、譲渡、情報、そして決済に関するルールが、どれだけ一貫して同時に実行できるか」です。

私はまだ、ブロックチェーンが実行する領域と、NPEX の法的枠組みが引き続き担う領域の境界について疑問があります。たぶん、それこそが最も追うべき部分なのです。
#dusk $DUSK @Dusk $BTC
·
--
以前、Binance P2Pでのクレーム(異議申し立て)は最後の手段であり、取引が本当に破綻したときにのみ使うべきだと思っていました。 私は以前、自分でなんとかして解決しようとする傾向がありました。相手に何度か追加でメッセージを送り、返事を待ち、第三者を介さずに問題が解決できることを願っていました。 しかし、改めてBinance P2Pが紛争(ディスピュート)をどう扱うのかを見てみると、考え方が変わり始めました。私が見落としていた点があります。双方が取引の状態について一致できなくなったとき、話し合いを続けても問題がよりはっきりするとは限らない、ということです。 最初は、クレームを開くことは事態をより深刻にすることだと思っていました。 その後、私はその目的を誤解していたことに気づきました。クレームは必ずしも対立のための行動ではありません。それは、紛争をプロセスに乗せ、Binanceが関連する情報と証拠にもとづいて検討できるようにするための手段です。 今の私の視点では、クレームを検討すべきタイミングは、私が苛立つときではありません。取引に問題が生じ、かつ双方がお互いに明確に解決できないときです。 これにより、責任の捉え方も変わりました。紛争があったらすぐにクレームを出すべき、というわけでもありませんが、状況がややこしくなるのを恐れて先延ばしにするべきでもないのです。 おそらく、もっと重要な問いは「いつクレームすべきか?」ではなく、「いつまで自分同士の話し合いだけで十分だと信じていていいのか?」です。 #binancep2pantoan @Binance_Vietnam $BTC
以前、Binance P2Pでのクレーム(異議申し立て)は最後の手段であり、取引が本当に破綻したときにのみ使うべきだと思っていました。

私は以前、自分でなんとかして解決しようとする傾向がありました。相手に何度か追加でメッセージを送り、返事を待ち、第三者を介さずに問題が解決できることを願っていました。
しかし、改めてBinance P2Pが紛争(ディスピュート)をどう扱うのかを見てみると、考え方が変わり始めました。私が見落としていた点があります。双方が取引の状態について一致できなくなったとき、話し合いを続けても問題がよりはっきりするとは限らない、ということです。

最初は、クレームを開くことは事態をより深刻にすることだと思っていました。
その後、私はその目的を誤解していたことに気づきました。クレームは必ずしも対立のための行動ではありません。それは、紛争をプロセスに乗せ、Binanceが関連する情報と証拠にもとづいて検討できるようにするための手段です。

今の私の視点では、クレームを検討すべきタイミングは、私が苛立つときではありません。取引に問題が生じ、かつ双方がお互いに明確に解決できないときです。
これにより、責任の捉え方も変わりました。紛争があったらすぐにクレームを出すべき、というわけでもありませんが、状況がややこしくなるのを恐れて先延ばしにするべきでもないのです。
おそらく、もっと重要な問いは「いつクレームすべきか?」ではなく、「いつまで自分同士の話し合いだけで十分だと信じていていいのか?」です。
#binancep2pantoan @Binance Vietnam $BTC
·
--
本人確認中
以前はTGE後の価格で新しいトークンを見ることが多かったです。価格が上がるか下がるかは、市場が何を考えているかを最も素早く示すシグナルのように思えましたが、TMXの資料を読み込むうちに、その見方だけでは足りないことに気づき始めました。 TermMaxは2026年8月25日にTGEを予定しています。ですので、私が関心を持つのは、その日以降に市場が形成するTMXの価格水準だけではなく、その後に何が起きるのかです。 私が立ち止まったのは、TermMaxがTMXの役割をどう設計しているかという点です。ホワイトペーパーでは、TMXはガバナンス、ステーキング、そしてエコシステムのインセンティブのためのものとして説明されています。総供給量は10億トークンで、そのうち20%が初期の流通(initial circulation)に割り当てられます。 最初は、TGEは主に市場が価格を確定するタイミングだと思っていました。しかし、その後、それは経済設計を検証し始めるための起点でもあるのだと理解しました。 いまの私は、そうした前提でTMXを見ています。ステーキングは本当に保有を促す動機を生むのか、ガバナンスは実際に使われるのか、インセンティブは持続可能な活動を生み出すのか、それとも短期的な需要を押し上げるだけなのか――それを観察したいのです。 また、配分グループごとにベスティング(権利確定)スケジュールが異なることにも注目しています。特にエコシステム部分は、2億9000万TMXが48か月のベスティング期間で割り当てられています。 それにより、価格はほんのごく短い一断面を反映しているだけではないか、と考えました。 たぶん25/8以降は、TMXがいくらであるかよりも、その周辺の仕組みが本当に設計どおりに機能しているのかが、より重要な問いになるでしょう。 #termmax @termmax $BTC
以前はTGE後の価格で新しいトークンを見ることが多かったです。価格が上がるか下がるかは、市場が何を考えているかを最も素早く示すシグナルのように思えましたが、TMXの資料を読み込むうちに、その見方だけでは足りないことに気づき始めました。

TermMaxは2026年8月25日にTGEを予定しています。ですので、私が関心を持つのは、その日以降に市場が形成するTMXの価格水準だけではなく、その後に何が起きるのかです。

私が立ち止まったのは、TermMaxがTMXの役割をどう設計しているかという点です。ホワイトペーパーでは、TMXはガバナンス、ステーキング、そしてエコシステムのインセンティブのためのものとして説明されています。総供給量は10億トークンで、そのうち20%が初期の流通(initial circulation)に割り当てられます。
最初は、TGEは主に市場が価格を確定するタイミングだと思っていました。しかし、その後、それは経済設計を検証し始めるための起点でもあるのだと理解しました。

いまの私は、そうした前提でTMXを見ています。ステーキングは本当に保有を促す動機を生むのか、ガバナンスは実際に使われるのか、インセンティブは持続可能な活動を生み出すのか、それとも短期的な需要を押し上げるだけなのか――それを観察したいのです。
また、配分グループごとにベスティング(権利確定)スケジュールが異なることにも注目しています。特にエコシステム部分は、2億9000万TMXが48か月のベスティング期間で割り当てられています。
それにより、価格はほんのごく短い一断面を反映しているだけではないか、と考えました。
たぶん25/8以降は、TMXがいくらであるかよりも、その周辺の仕組みが本当に設計どおりに機能しているのかが、より重要な問いになるでしょう。
#termmax @TermMax $BTC
·
--
以前は、EVMの互換性をわりと単純に捉えていました。あるブロックチェーンがSolidityとEthereumのツール群に対応していれば、それだけで開発者を新しいエコシステムへ連れていく方法だと、私は当然のように思い込んでいました。 しかしDuskのドキュメントをより深く読み進めると、その前提が十分ではないことに気づきました。私が立ち止まらざるを得なかったのは、Duskがexecution(実行)をsettlement(決済)から切り離すやり方です。 最初は、DuskEVMは主にEthereumのアプリをDusk上で動かすためのものだと考えていましたが、その役割はそれより広いものの、私が思っていたよりも具体的だということが分かりました。 DuskEVMはEVMの実行環境であり、DuskDSはコンセンサス、決済、データ可用性を担います。さらに、regulated financeの領域は、access control(アクセス制御)、selective disclosure(選択的開示)、そしてDuskのtransaction model(トランザクションモデル)など、複数の要素に依存しています。 現時点の見方としては、私はもはやDuskEVMを技術的な意味でのEthereum bridge(ブリッジ)とは見ていません。SolidityやEthereumのツール群を使うアプリが、Duskのインフラに到達できるようにする“互換性レイヤー”だと捉えています。 この責務の分割が面白いところです。EVMは馴染みのある開発モデルを保持し、一方で決済やregulated financeが求める要件は、別のレイヤーで処理されます。 たぶん、ここでの「ブリッジ」は2つのブロックチェーン間ではなく、2つのシステム構築の考え方の間に架けられているのです。 それでも疑問があります。互換性と、新しいregulated infrastructureとの分離こそが、Duskの設計で最も注目すべきポイントなのではないでしょうか? #dusk $DUSK @Dusk_Foundation
以前は、EVMの互換性をわりと単純に捉えていました。あるブロックチェーンがSolidityとEthereumのツール群に対応していれば、それだけで開発者を新しいエコシステムへ連れていく方法だと、私は当然のように思い込んでいました。

しかしDuskのドキュメントをより深く読み進めると、その前提が十分ではないことに気づきました。私が立ち止まらざるを得なかったのは、Duskがexecution(実行)をsettlement(決済)から切り離すやり方です。

最初は、DuskEVMは主にEthereumのアプリをDusk上で動かすためのものだと考えていましたが、その役割はそれより広いものの、私が思っていたよりも具体的だということが分かりました。

DuskEVMはEVMの実行環境であり、DuskDSはコンセンサス、決済、データ可用性を担います。さらに、regulated financeの領域は、access control(アクセス制御)、selective disclosure(選択的開示)、そしてDuskのtransaction model(トランザクションモデル)など、複数の要素に依存しています。

現時点の見方としては、私はもはやDuskEVMを技術的な意味でのEthereum bridge(ブリッジ)とは見ていません。SolidityやEthereumのツール群を使うアプリが、Duskのインフラに到達できるようにする“互換性レイヤー”だと捉えています。

この責務の分割が面白いところです。EVMは馴染みのある開発モデルを保持し、一方で決済やregulated financeが求める要件は、別のレイヤーで処理されます。

たぶん、ここでの「ブリッジ」は2つのブロックチェーン間ではなく、2つのシステム構築の考え方の間に架けられているのです。

それでも疑問があります。互換性と、新しいregulated infrastructureとの分離こそが、Duskの設計で最も注目すべきポイントなのではないでしょうか?
#dusk $DUSK @Dusk
·
--
私は、入金されたお金が口座に入金されれば取引はそのまま続けられると思っていましたが、Binance P2Pをさらに観察するほど、「止まる価値のある」小さな要素があると感じるようになりました。それは支払人の名前が一致していないことです。 Binanceは、パートナーの支払い口座の名義が、プラットフォーム上で確認された名前と一致しない場合、販売者は暗号資産をリリースすべきではないと明確に記載しています。Binanceでは返金(refund)を認めており、注文(Order)をBinanceチャット経由で報告することを推奨しています。 以前は、これは形式的なチェックにすぎないのだと思っていましたが、実際に私の考えを変えたケースがあります。 ある販売者が、彼はMomo経由で入金を受け取ったものの、送金者の名前がBinance上の名前と一致していなかったと共有していました。彼はその後も暗号資産をリリースしましたが、支払いが異議申し立てられ、その資金が凍結されてしまいました。 すべての名義のズレが詐欺だと断言できるわけではありませんが、このケースは「お金が入った」ことだけでは、検証を終えてよいとは限らないことを示しています。 私の現在の見方はシンプルです。リリースする前に、注文の情報と実際の入金情報を照合する必要があります。不審な点があれば、急いで進めるよりも、あえて余計な手間(friction)を作るほうがマシだと考えています。 おそらくBinance P2Pはtrustを消しているわけではなく、検証可能な手順の中で取引を進めることで、相手に預けるtrustの量を減らそうとしているだけなのだと思います。 そして、私は今でも疑問に思っています:一致しない名前は、裏でどんなリスクを警告しているのでしょうか? #binancep2pantoan @Binance_Vietnam $BTC
私は、入金されたお金が口座に入金されれば取引はそのまま続けられると思っていましたが、Binance P2Pをさらに観察するほど、「止まる価値のある」小さな要素があると感じるようになりました。それは支払人の名前が一致していないことです。

Binanceは、パートナーの支払い口座の名義が、プラットフォーム上で確認された名前と一致しない場合、販売者は暗号資産をリリースすべきではないと明確に記載しています。Binanceでは返金(refund)を認めており、注文(Order)をBinanceチャット経由で報告することを推奨しています。

以前は、これは形式的なチェックにすぎないのだと思っていましたが、実際に私の考えを変えたケースがあります。
ある販売者が、彼はMomo経由で入金を受け取ったものの、送金者の名前がBinance上の名前と一致していなかったと共有していました。彼はその後も暗号資産をリリースしましたが、支払いが異議申し立てられ、その資金が凍結されてしまいました。

すべての名義のズレが詐欺だと断言できるわけではありませんが、このケースは「お金が入った」ことだけでは、検証を終えてよいとは限らないことを示しています。
私の現在の見方はシンプルです。リリースする前に、注文の情報と実際の入金情報を照合する必要があります。不審な点があれば、急いで進めるよりも、あえて余計な手間(friction)を作るほうがマシだと考えています。

おそらくBinance P2Pはtrustを消しているわけではなく、検証可能な手順の中で取引を進めることで、相手に預けるtrustの量を減らそうとしているだけなのだと思います。
そして、私は今でも疑問に思っています:一致しない名前は、裏でどんなリスクを警告しているのでしょうか?
#binancep2pantoan @Binance Vietnam $BTC
·
--
以前、私は良い金融システムはどちらか一方を選ばなければならないのだと思っていました。検証しやすいように透明性を持つか、参加者を守るために秘匿性を持つか。 Dusk Networkの資料をより深く読むうちに、思わず立ち止まるようなアプローチに出会いました。Duskは、プライバシーと透明性を互いに排他的な二つの状態だとは見ていません。このシステムは、必要に応じて公開フロー、shielded、そしてselective disclosureを可能にします。 最初は、プライバシーとは主に取引データを隠すことだと考えていましたが、その見方は少し単純すぎると気づきました。規制された市場では、問題は「誰が、どの情報を、どのような状況で知ることを許されるか」にもあります。 そのため、私の中でのDuskの捉え方も変わりました。プライバシーは必ずしもコンプライアンスと対立するわけではありません。Phoenixは取引情報を秘匿しつつ、viewing keysとselective disclosureによって、ワークフローが求めるときにデータを開示できるのです。 これによって、私はより信頼モデルについて考えるようになりました。おそらく、金融システムはすべてを公開に変えて検証可能性を作る必要はなく、より重要なのは、プライバシー、透明性、そしてアクセス権の境界を制御できることです。 ただ、これらの原則がアプリケーションごとにどう異なる形で実装されるのかについて、私はまだ疑問が残っています。考えるべき問いは、Duskがプライバシーか透明性を選ぶかどうかではなく、それがどの情報を「信頼されるべきもの」として、証明し、開示するのかを決めることだ、という点かもしれません。#dusk $DUSK @Dusk_Foundation $BTC
以前、私は良い金融システムはどちらか一方を選ばなければならないのだと思っていました。検証しやすいように透明性を持つか、参加者を守るために秘匿性を持つか。

Dusk Networkの資料をより深く読むうちに、思わず立ち止まるようなアプローチに出会いました。Duskは、プライバシーと透明性を互いに排他的な二つの状態だとは見ていません。このシステムは、必要に応じて公開フロー、shielded、そしてselective disclosureを可能にします。

最初は、プライバシーとは主に取引データを隠すことだと考えていましたが、その見方は少し単純すぎると気づきました。規制された市場では、問題は「誰が、どの情報を、どのような状況で知ることを許されるか」にもあります。

そのため、私の中でのDuskの捉え方も変わりました。プライバシーは必ずしもコンプライアンスと対立するわけではありません。Phoenixは取引情報を秘匿しつつ、viewing keysとselective disclosureによって、ワークフローが求めるときにデータを開示できるのです。

これによって、私はより信頼モデルについて考えるようになりました。おそらく、金融システムはすべてを公開に変えて検証可能性を作る必要はなく、より重要なのは、プライバシー、透明性、そしてアクセス権の境界を制御できることです。

ただ、これらの原則がアプリケーションごとにどう異なる形で実装されるのかについて、私はまだ疑問が残っています。考えるべき問いは、Duskがプライバシーか透明性を選ぶかどうかではなく、それがどの情報を「信頼されるべきもの」として、証明し、開示するのかを決めることだ、という点かもしれません。#dusk $DUSK @Dusk $BTC
Privacy
50%
Transparency
0%
Compliance
0%
Cân bằng cả 3
50%
2 投票 • 投票は終了しました
·
--
以前私は、取引がスムーズに進むこと自体が、相手の信頼性をある程度示しているのだと思っていました。購入者がきちんと支払えば、取引が完了するので、その後ろにあるものも特に心配はないはずだと、ほぼ当然のように考えていました。でも、最近のBinance P2Pの取引によって、その考えを見直さざるを得なくなりました。 そのとき私は500 USDTを売り、購入者は普通に支払いました。銀行で入金を確認している最中、彼らは「あなたはよく暗号資産を取引していますか?」と聞いてきたのです。するとその後、彼らは新しいプロジェクトを紹介し、個別に話したいから電話番号やtelegramを教えてほしいと言ってきました。 最初は、これはそれほど大きな問題ではないように感じました。でも、やがて気づいたのは、その誘いが進行中の取引の範囲を完全に逸脱していたということです。 私は、彼らが紹介したいプロジェクトが良いものなのか悪いものなのか分からなかったので、判断もできませんでしたし、電話番号やtelegramも渡しませんでした。私は必要な確認をきちんと行い、実際に受け取った金額、送信者の情報をチェックして、それから取引完了を確認しました。それまでは500 USDTは、私が確認するまでシステムによってEscrowに保持されていました。 私が得た教訓は、「購入者を疑うべきだ」ということではなく、有効な取引を別のことにまで拡大解釈してはいけない、ということです。 購入者が必要な支払額を正しく送金したことは、この取引が正しい手順どおりに行われたことを確認するだけで、彼らが紹介してきたプロジェクトを評価する材料にはなりません。 そのため、万一問題があって異議申し立てをする必要がある場合や、Binance P2Pのサポートに連絡する必要がある場合に備えて、チャット内容、取引コード、証憑(あれば)を残しています。 この経験を通して私は、取引の外側のことについては、むしろ少し懐疑心を持ち、自分で検証してから信じるほうがよいのだと、自分に言い聞かせました。 #binancep2pantoan @Binance_Vietnam $BTC
以前私は、取引がスムーズに進むこと自体が、相手の信頼性をある程度示しているのだと思っていました。購入者がきちんと支払えば、取引が完了するので、その後ろにあるものも特に心配はないはずだと、ほぼ当然のように考えていました。でも、最近のBinance P2Pの取引によって、その考えを見直さざるを得なくなりました。

そのとき私は500 USDTを売り、購入者は普通に支払いました。銀行で入金を確認している最中、彼らは「あなたはよく暗号資産を取引していますか?」と聞いてきたのです。するとその後、彼らは新しいプロジェクトを紹介し、個別に話したいから電話番号やtelegramを教えてほしいと言ってきました。
最初は、これはそれほど大きな問題ではないように感じました。でも、やがて気づいたのは、その誘いが進行中の取引の範囲を完全に逸脱していたということです。

私は、彼らが紹介したいプロジェクトが良いものなのか悪いものなのか分からなかったので、判断もできませんでしたし、電話番号やtelegramも渡しませんでした。私は必要な確認をきちんと行い、実際に受け取った金額、送信者の情報をチェックして、それから取引完了を確認しました。それまでは500 USDTは、私が確認するまでシステムによってEscrowに保持されていました。

私が得た教訓は、「購入者を疑うべきだ」ということではなく、有効な取引を別のことにまで拡大解釈してはいけない、ということです。
購入者が必要な支払額を正しく送金したことは、この取引が正しい手順どおりに行われたことを確認するだけで、彼らが紹介してきたプロジェクトを評価する材料にはなりません。

そのため、万一問題があって異議申し立てをする必要がある場合や、Binance P2Pのサポートに連絡する必要がある場合に備えて、チャット内容、取引コード、証憑(あれば)を残しています。
この経験を通して私は、取引の外側のことについては、むしろ少し懐疑心を持ち、自分で検証してから信じるほうがよいのだと、自分に言い聞かせました。
#binancep2pantoan @Binance Vietnam $BTC
·
--
以前私は、コンセンサスとは複数のバリデーターが同じブロックを共同で確認するという“多数決の話”だと思っていました。ネットワークに参加するノードが多いほど、より信頼できるものだと決めつけていました。 Dusk Networkについて深く調べていくと、Succinct Attestationのある一つのディテールが私の考えを止めさせました。Duskは、すべてのプロビジョナーがすべての判断を処理するような方向でコンセンサスを設計していません。 最初は、SA(Succinct Attestation)はかなり単純だと理解していました。つまり、DUSKをステークしている人々が協力して提案し投票する、という理解です。しかし、それは重要な部分を見落としていました。SAは、コミッティ(委員会)に基づくProof-of-Stakeの仕組みであり、プロビジョナーにはさまざまな役割が割り当てられます。 さらに読み進めると、各ラウンドは3つのステップを経ることが分かります。Proposal、Validation、Ratificationです。あるプロビジョナーがブロックを提案し、次にあるコミッティがそれを検証し、その後別のコミッティが結果を確定してブロックを完了させます。 現在の視点では、私はもはやSAを単なる投票の方法とは見ていません。コンセンサスにおける責任の分担の仕組みとして捉えています。システムは、すべてのプロビジョナーがすべてを確認することを要求しません。タスクごとにグループを選び、ブロックがfinality(最終確定)に到達するための条件を設定します。 これによって、trust model(信頼モデル)の見方が変わりました。信頼は単にノード数にあるのではなく、コミッティの選び方やステークにあるのです。 それでも気になります。コンセンサスが選ばれたグループに依存するのであれば、信頼の実際の限界はどこにあるのでしょうか? #dusk $DUSK @Dusk_Foundation
以前私は、コンセンサスとは複数のバリデーターが同じブロックを共同で確認するという“多数決の話”だと思っていました。ネットワークに参加するノードが多いほど、より信頼できるものだと決めつけていました。

Dusk Networkについて深く調べていくと、Succinct Attestationのある一つのディテールが私の考えを止めさせました。Duskは、すべてのプロビジョナーがすべての判断を処理するような方向でコンセンサスを設計していません。

最初は、SA(Succinct Attestation)はかなり単純だと理解していました。つまり、DUSKをステークしている人々が協力して提案し投票する、という理解です。しかし、それは重要な部分を見落としていました。SAは、コミッティ(委員会)に基づくProof-of-Stakeの仕組みであり、プロビジョナーにはさまざまな役割が割り当てられます。

さらに読み進めると、各ラウンドは3つのステップを経ることが分かります。Proposal、Validation、Ratificationです。あるプロビジョナーがブロックを提案し、次にあるコミッティがそれを検証し、その後別のコミッティが結果を確定してブロックを完了させます。

現在の視点では、私はもはやSAを単なる投票の方法とは見ていません。コンセンサスにおける責任の分担の仕組みとして捉えています。システムは、すべてのプロビジョナーがすべてを確認することを要求しません。タスクごとにグループを選び、ブロックがfinality(最終確定)に到達するための条件を設定します。

これによって、trust model(信頼モデル)の見方が変わりました。信頼は単にノード数にあるのではなく、コミッティの選び方やステークにあるのです。

それでも気になります。コンセンサスが選ばれたグループに依存するのであれば、信頼の実際の限界はどこにあるのでしょうか?
#dusk $DUSK @Dusk
·
--
あるメモ一行が、私にUSDTを出金(release)するのをためらわせる……! 2025年のクリスマスの頃、私は年末の出費に備えるために1,000 USDTを売りました。銀行アプリを確認したところ、口座に入金されていて、メモ欄に「chuyen tien mua usdt binance」(USDTをBinanceで買うための送金)と書かれていました。 金額は正しく、入金もちゃんと届いていました。しばらく待ってからUSDTを出金するのは、そのときはほぼ自然な反射のように見えました。 でも私は立ち止まりました。細かい点ですが、注文では支払いメモに暗号資産やBinanceに関連する語が含まれてはいけない、という条件があったからです。 最初はこのメモが支払いに問題があることを直接は証明しないと思いました。しかしそれは、取引の一部が当初の条件と一致していないことを示していました。私の暗号資産の取引のやり方では、このズレだけでも再確認するには十分でした。 私はBinance P2Pのチャットに戻り、購入者に追加で本人確認を求めました。支払いをした相手が、その注文の正しい相手であることを確実にしたかったのです。 条件がこれ以上進められない場合は、取引を無理に完了させようとせず、手順に従って返金を選びました。 その時になって、私はEscrow(エスクロー)の役割をよりはっきり理解しました。Binance P2Pは注文の中で暗号資産を保管しますが、それでも私は、CryptoをReleaseする前に、実際に受け取った入金を自分で確認しなければなりません。「paid」というステータスは、銀行口座の確認を代替できません。 だから私は、常にBinance P2P上のやり取りをすべて保持しています。チャット、Order ID、そして入金の詳細は、Appeal(異議申し立て)やサポートに連絡が必要になったときの、ひとつのつながる記録(証跡)になります。 最後に一番覚えているのは、問題のある支払いメモそのものではなく、小さな一つのディテールが取引全体を不確実にし得るということ、そしてまだ確認されていない「つながり」が一つでも残っているなら、急いで進めるより立ち止まるほうが良い、という点です。 #binancep2pantoan @Binance_Vietnam $BTC
あるメモ一行が、私にUSDTを出金(release)するのをためらわせる……!

2025年のクリスマスの頃、私は年末の出費に備えるために1,000 USDTを売りました。銀行アプリを確認したところ、口座に入金されていて、メモ欄に「chuyen tien mua usdt binance」(USDTをBinanceで買うための送金)と書かれていました。

金額は正しく、入金もちゃんと届いていました。しばらく待ってからUSDTを出金するのは、そのときはほぼ自然な反射のように見えました。

でも私は立ち止まりました。細かい点ですが、注文では支払いメモに暗号資産やBinanceに関連する語が含まれてはいけない、という条件があったからです。
最初はこのメモが支払いに問題があることを直接は証明しないと思いました。しかしそれは、取引の一部が当初の条件と一致していないことを示していました。私の暗号資産の取引のやり方では、このズレだけでも再確認するには十分でした。

私はBinance P2Pのチャットに戻り、購入者に追加で本人確認を求めました。支払いをした相手が、その注文の正しい相手であることを確実にしたかったのです。

条件がこれ以上進められない場合は、取引を無理に完了させようとせず、手順に従って返金を選びました。

その時になって、私はEscrow(エスクロー)の役割をよりはっきり理解しました。Binance P2Pは注文の中で暗号資産を保管しますが、それでも私は、CryptoをReleaseする前に、実際に受け取った入金を自分で確認しなければなりません。「paid」というステータスは、銀行口座の確認を代替できません。

だから私は、常にBinance P2P上のやり取りをすべて保持しています。チャット、Order ID、そして入金の詳細は、Appeal(異議申し立て)やサポートに連絡が必要になったときの、ひとつのつながる記録(証跡)になります。

最後に一番覚えているのは、問題のある支払いメモそのものではなく、小さな一つのディテールが取引全体を不確実にし得るということ、そしてまだ確認されていない「つながり」が一つでも残っているなら、急いで進めるより立ち止まるほうが良い、という点です。
#binancep2pantoan @Binance Vietnam $BTC
·
--
私は以前、ブロックチェーンが拡張するには、まずグローバルな視点を見据える必要があると決めつけていました。当時の法規制は、最初から設計の一部になるものというより、あとから適応すべき「障壁」のように扱われるものだと思っていたのです。 Dusk Networkについてさらに深く調べるうちに、思わず立ち止まらざるを得ない細部に出会いました。プロジェクトは何度も、EUやMiCAのような要件を金融インフラの物語の中に組み込んでいます。実際、Dusk自身が明確に、MiCAの影響を受ける重要なターゲット市場として欧州に焦点を当てていると述べています。 最初は、これは単にRWAプロジェクトが発展のために市場を選んでいるだけだろうと思いました。しかし読み進めるほど、自分の見方が少し狭かったのではないかと感じるようになりました。 Duskの現行資料には「Assets & Regulations」のセクションがあり、そこではMiCAに直接言及するとともに、管理される資産に対する実務上の要件にも触れています。 そこで初めて、なぜEUが重要なのかが理解できました。MiCAは、2024年12月30日から本格適用されており、さらに一部の規定は2024年6月30日から早期適用されています。 私の現在の見方では、注目すべきはDuskがどれだけ「EUに適合しているか」ではありません。より重要なのは、コンプライアンスが設計上の前提になり得るという点です。 このモデルが本当に欧州以外でもうまく拡大できるのかどうか、私は今なお疑問に思っています。より重要な問いは、おそらく次のようなものです。Duskは特定の市場のために構築しているのか、それともブロックチェーンが管理された金融に入り込むための新しい方法を試しているのか? #dusk $DUSK @Dusk_Foundation
私は以前、ブロックチェーンが拡張するには、まずグローバルな視点を見据える必要があると決めつけていました。当時の法規制は、最初から設計の一部になるものというより、あとから適応すべき「障壁」のように扱われるものだと思っていたのです。

Dusk Networkについてさらに深く調べるうちに、思わず立ち止まらざるを得ない細部に出会いました。プロジェクトは何度も、EUやMiCAのような要件を金融インフラの物語の中に組み込んでいます。実際、Dusk自身が明確に、MiCAの影響を受ける重要なターゲット市場として欧州に焦点を当てていると述べています。

最初は、これは単にRWAプロジェクトが発展のために市場を選んでいるだけだろうと思いました。しかし読み進めるほど、自分の見方が少し狭かったのではないかと感じるようになりました。
Duskの現行資料には「Assets & Regulations」のセクションがあり、そこではMiCAに直接言及するとともに、管理される資産に対する実務上の要件にも触れています。
そこで初めて、なぜEUが重要なのかが理解できました。MiCAは、2024年12月30日から本格適用されており、さらに一部の規定は2024年6月30日から早期適用されています。
私の現在の見方では、注目すべきはDuskがどれだけ「EUに適合しているか」ではありません。より重要なのは、コンプライアンスが設計上の前提になり得るという点です。

このモデルが本当に欧州以外でもうまく拡大できるのかどうか、私は今なお疑問に思っています。より重要な問いは、おそらく次のようなものです。Duskは特定の市場のために構築しているのか、それともブロックチェーンが管理された金融に入り込むための新しい方法を試しているのか?
#dusk $DUSK @Dusk
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約