@Dusk
送金は実行主体（発行者）主導です。Zedgerのコントラクト仕様の中に、そこに属しているかのように座っています。
その条項については、たぶん本来より長く立ち止まりました。
Zedgerは証券と現実世界の資産のために作られており、保有者は通常、自分の鍵を通じてそれらの資産を管理します。ですが、そのコントラクトには発行者のための強制送金（force-transfer）機能も用意されています。
見落とされたバグではありません。
鋳造（minting）、焼却（burning）、配当（dividends）と並ぶように設計された機能です。
ここが、私がまだ追跡できていなかった部分です。
そのオーバーライドが発動するとき、それはプライバシーの仕組みを迂回（バイパス）しません。むしろそれを使います。
保有者のノートは、通常のPhoenixノートが消費されるときと同じメカニズムで無効化されます。その後、発行者が指定した宛先へ、資産を再発行でき、送金自体はプロトコルの「証明ベースの仕組み」によって処理されます。
つまり、保有者が余計な情報を公開せずに支配（コントロール）を証明できるようにする仕組みが、保有者自身が開始していない送金を実行する際にも関与している、ということです。
それが私にとって面白い部分です。
トークン化された債券は、単にウォレット内にある残高ではありません。法的な請求権（リーガルクレーム）です。そしてZedgerのコントラクトは、配当、コーポレートアクション、チェーンの外で引き起こされる出来事といった事柄を、すでに織り込んでいます。資産がトークン化されても、そうした義務は消えません。
Zedgerの答えは、完全に別の送金システムをくっつけることではありません。
そこにすでにある仕組みを再利用します。
ホワイトペーパーだけでは分からないのは、そのオーバーライドが、実際の発行者がそれを使い始めたときにどれくらい“狭い”ままなのかという点です。誰がそれを発動できるのか。どのような条件のときか。さらに多くの資産タイプが追加されても、その境界（境目）は狭いままなのか。
$DUSK は、少なくともその境界が、それを説明しているコントラクト以外の何かに対して試された後で、私にとってさらに興味深くなっていきます。
#dusk
送金は実行主体（発行者）主導です。Zedgerのコントラクト仕様の中に、そこに属しているかのように座っています。
その条項については、たぶん本来より長く立ち止まりました。
Zedgerは証券と現実世界の資産のために作られており、保有者は通常、自分の鍵を通じてそれらの資産を管理します。ですが、そのコントラクトには発行者のための強制送金（force-transfer）機能も用意されています。
見落とされたバグではありません。
鋳造（minting）、焼却（burning）、配当（dividends）と並ぶように設計された機能です。
ここが、私がまだ追跡できていなかった部分です。
そのオーバーライドが発動するとき、それはプライバシーの仕組みを迂回（バイパス）しません。むしろそれを使います。
保有者のノートは、通常のPhoenixノートが消費されるときと同じメカニズムで無効化されます。その後、発行者が指定した宛先へ、資産を再発行でき、送金自体はプロトコルの「証明ベースの仕組み」によって処理されます。
つまり、保有者が余計な情報を公開せずに支配（コントロール）を証明できるようにする仕組みが、保有者自身が開始していない送金を実行する際にも関与している、ということです。
それが私にとって面白い部分です。
トークン化された債券は、単にウォレット内にある残高ではありません。法的な請求権（リーガルクレーム）です。そしてZedgerのコントラクトは、配当、コーポレートアクション、チェーンの外で引き起こされる出来事といった事柄を、すでに織り込んでいます。資産がトークン化されても、そうした義務は消えません。
Zedgerの答えは、完全に別の送金システムをくっつけることではありません。
そこにすでにある仕組みを再利用します。
ホワイトペーパーだけでは分からないのは、そのオーバーライドが、実際の発行者がそれを使い始めたときにどれくらい“狭い”ままなのかという点です。誰がそれを発動できるのか。どのような条件のときか。さらに多くの資産タイプが追加されても、その境界（境目）は狭いままなのか。
$DUSK は、少なくともその境界が、それを説明しているコントラクト以外の何かに対して試された後で、私にとってさらに興味深くなっていきます。
#dusk
