Binance Square
NVD Insights
15.1k 投稿

NVD Insights

Crypto analyst with 7 years in the crypto space and 3.7 years of hands-on experience with Binance.
取引を発注
超高頻度トレーダー
4.7年
769 フォロー
26.7K+ フォロワー
33.2K+ いいね
投稿
ポートフォリオ
·
--
翻訳参照
Been going through @Dusk_Foundation transaction and gas model the past couple days, and honestly I think most people hear "gas fee" and picture some arbitrary tax bolted onto a transfer. That's not really what's going on here. the thing is, in Dusk transfer contract, gas isn't sitting off to the side of execution it's baked into it. The contract validates the transaction against the relevant rules, handles the contract deployment or call itself, and deducts gas specifically to cover the computational cost of doing all that. Three pieces working together in one flow: rule checking, execution, and resource accounting. honestly, that is the part that actually makes sense once you sit with it if computation genuinely costs something, building that cost directly int0 transaction processing means the network is accounting for real resource usage instead of pretending execution is free. here is the catch though: the more expressive transactions get, the harder it gets to keep those costs predictable without turning the pricing model into something users can't easily reason about. still, I'd rather have costs made explicit than have them hide somewhere and show up later as network strain. does accounting for computation this way make execution more sustainable, or does pricing complexity just become its own usability headache? #dusk $DUSK
Been going through @Dusk transaction and gas model the past couple days, and honestly I think most people hear "gas fee" and picture some arbitrary tax bolted onto a transfer. That's not really what's going on here.

the thing is, in Dusk transfer contract, gas isn't sitting off to the side of execution it's baked into it. The contract validates the transaction against the relevant rules, handles the contract deployment or call itself, and deducts gas specifically to cover the computational cost of doing all that. Three pieces working together in one flow: rule checking, execution, and resource accounting.

honestly, that is the part that actually makes sense once you sit with it if computation genuinely costs something, building that cost directly int0 transaction processing means the network is accounting for real resource usage instead of pretending execution is free.

here is the catch though: the more expressive transactions get, the harder it gets to keep those costs predictable without turning the pricing model into something users can't easily reason about.

still, I'd rather have costs made explicit than have them hide somewhere and show up later as network strain.

does accounting for computation this way make execution more sustainable, or does pricing complexity just become its own usability headache?
#dusk $DUSK
@Dusk_Foundation が合意(コンセンサス)をどのように扱っているかを、より注意深く見てきました。見落としがちだと感じる点の1つは、このプロセスが「1つの単一の決定」として扱われていないことです。 まず、Amaブロックが準備され提案されます。その後、投票参加者がそれを評価し、ネットワークが結果としての状態に合意する前に確認します。 この切り分けが重要だと私は思います。候補ブロックを作ることと、そのブロックを受け入れることは同じではないからです。提案が間違っていれば、投票段階は、ブロック生成そのものを受け入れとみなすのではなく、参加者がそれを拒否できる明確な拒否ポイントを提供します。 私はシステムの観点から、この設計が気に入っています。ロジックを切り分けやすくなります。つまり「まず提案し、次に合意する」です。 ただ、もう1つ考え続けている面があります。より明確な段階は、各コンポーネント間の調整(コーディネーション)も増やすことになります。これらの段階がお互いに依存しているなら、追加の構造は、調整が正しく機能する必要がある追加の箇所を生み出し得ます。 私の見立てでは、興味深い問いは「この設計が洗練されて見えるかどうか」ではありません。「その切り分けが、不要な複雑さを生むことなく耐障害性(レジリエンス)を実際に高めるのかどうか」です。 段階化された合意はDuskを悪い提案に対してより頑健にしますか? それとも、追加された調整が新たなトレードオフを生み出しますか? #dusk $DUSK
@Dusk が合意(コンセンサス)をどのように扱っているかを、より注意深く見てきました。見落としがちだと感じる点の1つは、このプロセスが「1つの単一の決定」として扱われていないことです。

まず、Amaブロックが準備され提案されます。その後、投票参加者がそれを評価し、ネットワークが結果としての状態に合意する前に確認します。

この切り分けが重要だと私は思います。候補ブロックを作ることと、そのブロックを受け入れることは同じではないからです。提案が間違っていれば、投票段階は、ブロック生成そのものを受け入れとみなすのではなく、参加者がそれを拒否できる明確な拒否ポイントを提供します。

私はシステムの観点から、この設計が気に入っています。ロジックを切り分けやすくなります。つまり「まず提案し、次に合意する」です。

ただ、もう1つ考え続けている面があります。より明確な段階は、各コンポーネント間の調整(コーディネーション)も増やすことになります。これらの段階がお互いに依存しているなら、追加の構造は、調整が正しく機能する必要がある追加の箇所を生み出し得ます。

私の見立てでは、興味深い問いは「この設計が洗練されて見えるかどうか」ではありません。「その切り分けが、不要な複雑さを生むことなく耐障害性(レジリエンス)を実際に高めるのかどうか」です。

段階化された合意はDuskを悪い提案に対してより頑健にしますか? それとも、追加された調整が新たなトレードオフを生み出しますか?
#dusk $DUSK
翻訳参照
Spent a chunk of the weekend trying to understand how @Dusk_Foundation actually sequences investor onboarding for regulated assets, and honestly my first take was way off. I figured it was basically a token with some rules bolted on and the market just handles the rest like normal. that's not it, though. The thing is, wallets have to be bound to verified participants before the asset even gets issued, so eligibility lives at the identity layer, not inside the token contract itself. The contract can enforce transfer restrictions, sure, but only against wallets already recognized in the system. Someone unverified does not get rejected when they try t0 buy they just never show up in the addressable buyer pool to begin with. honestly, that is the part that actually changes how you should be reading liquidity here. On a normal token, thin order book depth usually means weak demand anyone can hold it, so depth is a decent proxy for interest. On a regulated Dusk asset, that logic breaks. Thin liquidity might just mean the eligible pool hasn't caught up to real demand yet. what I can not tell from the outside is whether slow liquidity growth is actually a demand issue, or just a verification bottleneck nobody's solved. still, that's a distinction worth sitting with before writing off a quiet market as weak. what happens to price discovery the day that eligible pool suddenly doubles? #dusk $DUSK
Spent a chunk of the weekend trying to understand how @Dusk actually sequences investor onboarding for regulated assets, and honestly my first take was way off. I figured it was basically a token with some rules bolted on and the market just handles the rest like normal.

that's not it, though. The thing is, wallets have to be bound to verified participants before the asset even gets issued, so eligibility lives at the identity layer, not inside the token contract itself. The contract can enforce transfer restrictions, sure, but only against wallets already recognized in the system. Someone unverified does not get rejected when they try t0 buy they just never show up in the addressable buyer pool to begin with.

honestly, that is the part that actually changes how you should be reading liquidity here. On a normal token, thin order book depth usually means weak demand anyone can hold it, so depth is a decent proxy for interest. On a regulated Dusk asset, that logic breaks. Thin liquidity might just mean the eligible pool hasn't caught up to real demand yet.

what I can not tell from the outside is whether slow liquidity growth is actually a demand issue, or just a verification bottleneck nobody's solved.

still, that's a distinction worth sitting with before writing off a quiet market as weak.

what happens to price discovery the day that eligible pool suddenly doubles?
#dusk $DUSK
確認済み
私は当初、DuskEVMは主に @Dusk_Foundation にEVM互換性をもたらすことが目的なのだと思っていました。さらに深く見ていくと、設計の捉え方が変わってきました。 私が惹かれるのは、馴染みのある開発者向けツールと、金融ユースケースを前提に構築されたインフラの組み合わせです。開発者はSolidityや既存のEVMツールを使えます。一方でHedgerは、プライベートでありながら検証可能な取引金額をサポートするよう設計されています。 さらに、応用レイヤーの可能性があります。トークン化された資産、DeFi、レンディング、そして規制された金融ワークフローです。Chainlink CCIPもまた、チェーンをまたいでトークン化資産をつなぐことで面白い要素を加えています。 私が繰り返し思い返してしまうのは、DuskEVMがすでにテストネットで利用可能だという点です。これにより、メインネット公開後にゼロから始めるのではなく、事前に開発者が試せる余地が生まれます。 私の見解では、EVM互換性はあくまで出発点にすぎません。より重要なのは、開発者が標準的なEVM環境以上のものを必要とするアプリケーションを構築するために、Duskのプライバシー、決済、データ可用性のインフラを実際に使えるのかどうかです。 私は発表そのものにはあまり関心がなく、それによって何が作られていくのかにより興味があります。 #dusk $DUSK
私は当初、DuskEVMは主に @Dusk にEVM互換性をもたらすことが目的なのだと思っていました。さらに深く見ていくと、設計の捉え方が変わってきました。

私が惹かれるのは、馴染みのある開発者向けツールと、金融ユースケースを前提に構築されたインフラの組み合わせです。開発者はSolidityや既存のEVMツールを使えます。一方でHedgerは、プライベートでありながら検証可能な取引金額をサポートするよう設計されています。

さらに、応用レイヤーの可能性があります。トークン化された資産、DeFi、レンディング、そして規制された金融ワークフローです。Chainlink CCIPもまた、チェーンをまたいでトークン化資産をつなぐことで面白い要素を加えています。

私が繰り返し思い返してしまうのは、DuskEVMがすでにテストネットで利用可能だという点です。これにより、メインネット公開後にゼロから始めるのではなく、事前に開発者が試せる余地が生まれます。

私の見解では、EVM互換性はあくまで出発点にすぎません。より重要なのは、開発者が標準的なEVM環境以上のものを必要とするアプリケーションを構築するために、Duskのプライバシー、決済、データ可用性のインフラを実際に使えるのかどうかです。

私は発表そのものにはあまり関心がなく、それによって何が作られていくのかにより興味があります。
#dusk $DUSK
翻訳参照
keep thinking about what happens to a @termmax pool right after a big batch of positions matures, not before. most people focus on maturity as an exit point for the individual lender, but I think the more interesting question is what it does to the pool itself in that window. when a large chunk of fixed rate debt matures around the same time, the pool's utilization can drop fast repaid capital sits there uncommitted until new borrowers show up t0 take the other side. it is a bit like a hotel with a bunch of checkouts on the same day and no guarantee the rooms fill back up that afternoon. that gap is fine, honestly, but it means the fixed rate on a fresh position right after a big maturity wave might look more attractive than it would in a steadier market, just because utilization temporarily dipped. a rate that looks generous right after a maturity spike might just be idle capital talking, not real demand. not sure how visible that pattern actually is unless you're watching utilization around specific maturity dates rather than just checking the rate on any given day... anyone tracking whether TermMax rates cluster differently right after big maturity clusters, or is that too small an effect to matter? #termmax
keep thinking about what happens to a @TermMax pool right after a big batch of positions matures, not before.

most people focus on maturity as an exit point for the individual lender, but I think the more interesting question is what it does to the pool itself in that window.

when a large chunk of fixed rate debt matures around the same time, the pool's utilization can drop fast repaid capital sits there uncommitted until new borrowers show up t0 take the other side. it is a bit like a hotel with a bunch of checkouts on the same day and no guarantee the rooms fill back up that afternoon.

that gap is fine, honestly, but it means the fixed rate on a fresh position right after a big maturity wave might look more attractive than it would in a steadier market, just because utilization temporarily dipped.

a rate that looks generous right after a maturity spike might just be idle capital talking, not real demand.

not sure how visible that pattern actually is unless you're watching utilization around specific maturity dates rather than just checking the rate on any given day...

anyone tracking whether TermMax rates cluster differently right after big maturity clusters, or is that too small an effect to matter?
#termmax
確認済み
翻訳参照
Been turning over one specific question about @Dusk_Foundation DvP settlement for a couple days now, and it is not the question most people are actually asking. Everyone wants t0 know if both legs of a trade move together. Almost nobody asks whether either leg can quietly unwind after the fact. honestly, that's the part that actually decides whether "atomic" means anything to an institution. the thing is, Dusk isn't relying on probabilistic confirmation here it uses Succinct Attestation for deterministic finality, so settled actually means settled, not "settled unless something changes." Layer shielded balances and selective disclosure on top of that, and a trade clears without broadcasting size or counterparty to the market, which public settlement chains basically can't touch. that's a real shift for anything institutional removing counterparty risk between two legs is genuinely hard to fake. what I still don't have a clean answer for: none of this manufactures the cash leg. Tokenized deposit, regulated stablecoin, something narrower built for purpose still open. And the CCIP extension adds reach but also a second atomicity boundary worth thinking through carefully. still, NPEX's volume looking organic rather than incentivized is the number I'd actually trust over sentiment. $DUSK #dusk
Been turning over one specific question about @Dusk DvP settlement for a couple days now, and it is not the question most people are actually asking. Everyone wants t0 know if both legs of a trade move together. Almost nobody asks whether either leg can quietly unwind after the fact.

honestly, that's the part that actually decides whether "atomic" means anything to an institution. the thing is, Dusk isn't relying on probabilistic confirmation here it uses Succinct Attestation for deterministic finality, so settled actually means settled, not "settled unless something changes." Layer shielded balances and selective disclosure on top of that, and a trade clears without broadcasting size or counterparty to the market, which public settlement chains basically can't touch.

that's a real shift for anything institutional removing counterparty risk between two legs is genuinely hard to fake.

what I still don't have a clean answer for: none of this manufactures the cash leg. Tokenized deposit, regulated stablecoin, something narrower built for purpose still open. And the CCIP extension adds reach but also a second atomicity boundary worth thinking through carefully.

still, NPEX's volume looking organic rather than incentivized is the number I'd actually trust over sentiment.
$DUSK #dusk
確認済み
翻訳参照
I've been reading into @Dusk_Foundation contract execution setup lately, and Piecrust is the piece most people gloss over when they talk about the project. Not gonna lie, I expected another heavy weight execution environment. It is not that. Piecrust is a lightweight WebAssembly based VM built for secure, modular contract execution, and the thing is, it separates contract logic from the cryptographic work underneath. Contracts just run application logic inside the VM. The expensive stuff ZK proof verification, signature validation gets pushed out into native host functions instead 0f living inside every contract. That's the part that actually works: cryptographic verification is expensive by nature, so forcing every contract to carry that weight itself would slow the whole system down for no real benefit. Splitting it out keeps execution lean while still handling the heavy privacy machinery Dusk depends on. The limitation nobody's fully tested yet: modularity looks clean on paper, but it has not been pressure tested against real financial applications running at volume, where complexity compounds fast. Still, building the separation in now beats trying to bolt it on after contracts get complicated. #dusk $DUSK
I've been reading into @Dusk contract execution setup lately, and Piecrust is the piece most people gloss over when they talk about the project.

Not gonna lie, I expected another heavy weight execution environment. It is not that. Piecrust is a lightweight WebAssembly based VM built for secure, modular contract execution, and the thing is, it separates contract logic from the cryptographic work underneath. Contracts just run application logic inside the VM. The expensive stuff ZK proof verification, signature validation gets pushed out into native host functions instead 0f living inside every contract.

That's the part that actually works: cryptographic verification is expensive by nature, so forcing every contract to carry that weight itself would slow the whole system down for no real benefit. Splitting it out keeps execution lean while still handling the heavy privacy machinery Dusk depends on.

The limitation nobody's fully tested yet: modularity looks clean on paper, but it has not been pressure tested against real financial applications running at volume, where complexity compounds fast.

Still, building the separation in now beats trying to bolt it on after contracts get complicated.
#dusk $DUSK
@termmax の金利について考えるよりも、ポジションが実際に満期を迎える当日に何が起きるのかについて考えていた。 多くの人は「固定金利=安全」と考えるけれど、私は本当の問いは満期に何が起きるかであって、その前ではないと思う。 技術的な話をすると:TermMaxのローンはオープンエンドではなく、固定された満期日を軸に作られている。ゼロクーポン債のように、金利と期日を最初から決めておくタイプで、途中で驚きがない。普通のローンというよりは、決済日前に住宅ローンの借り換え金利を固定で取りに行くようなものだ。紙の上ではきれいにまとまっている。 でもそれは、満期そのものが意思決定のポイントになるということでもある。ポジションをクローズするか、新しい期間にロールするか、決着(満期決済)させるか。そのどれもが、開けた日からコントロールできない市場状況に左右される。期間中の固定された確実性があっても、その端(満期周辺)の確実性までは買えない。 固定金利は不確実性を別の日付に移すだけで、それを消すわけではない。 正直、その不確実性は本当の制約なのか、それとも……固定期間型の商品が想定している動き方なのかで行ったり来たりしている。そして、開始時点に過剰なリスクを見込んでいるのだと思う。 このロールオーバーの戦略って、ポジションを開く前に実際に考える人はいるのだろうか?それとも、そういう意思決定は主にその場の判断で行われるものなのだろうか? #termmax
@TermMax の金利について考えるよりも、ポジションが実際に満期を迎える当日に何が起きるのかについて考えていた。

多くの人は「固定金利=安全」と考えるけれど、私は本当の問いは満期に何が起きるかであって、その前ではないと思う。

技術的な話をすると:TermMaxのローンはオープンエンドではなく、固定された満期日を軸に作られている。ゼロクーポン債のように、金利と期日を最初から決めておくタイプで、途中で驚きがない。普通のローンというよりは、決済日前に住宅ローンの借り換え金利を固定で取りに行くようなものだ。紙の上ではきれいにまとまっている。

でもそれは、満期そのものが意思決定のポイントになるということでもある。ポジションをクローズするか、新しい期間にロールするか、決着(満期決済)させるか。そのどれもが、開けた日からコントロールできない市場状況に左右される。期間中の固定された確実性があっても、その端(満期周辺)の確実性までは買えない。

固定金利は不確実性を別の日付に移すだけで、それを消すわけではない。

正直、その不確実性は本当の制約なのか、それとも……固定期間型の商品が想定している動き方なのかで行ったり来たりしている。そして、開始時点に過剰なリスクを見込んでいるのだと思う。

このロールオーバーの戦略って、ポジションを開く前に実際に考える人はいるのだろうか?それとも、そういう意思決定は主にその場の判断で行われるものなのだろうか?
#termmax
私は@Dusk_Foundation がプライバシーをどう描写しているかについて、特定の緊張関係のことをずっと考えています。最初に聞こえるよりも、ずっと分かりにくいのです。多くの人は、プライバシーと規制は互いに逆の方向へ引っ張り合うので、どちらか一方しか成り立たないと思いがちです。どちらかを選ぶだけ、両方は無理だと。 しかし、Duskのモデルはその選択を強制しません。ゼロ知識による検証があれば、ネットワークは取引がルールに従って行われたことを、実際にその具体的な中身をさらすことなく確認できます。従来の金融は、何かに署名される前に、データを銀行や取引相手、規制当局が直接見られる状態にして信頼を解決することでしかそれができません。Duskは、検証と開示を完全に切り離します。 率直に言えば、これが本当の転換点です。機微な詳細は封印されたままですが、必要になったときに限って、許可された関係者はきちんと機能する監査の導線を得られます。プライバシーは「オフ・ザ・グリッド(網の外)」という意味から、「保護されているが説明責任がある」という意味へと変わっていきます。これは、多くのプライバシー重視のチェーンがそもそも目指している設計目標とは別物です。 そして、どうしても頭を離れない未解決の問いがあります。実際の機関レベルの取引量が流れ始めたとき、つまり設計上すべてがきれいに整っている制御されたパイロットだけでなく、本番の運用ではこの考え方は成り立つのでしょうか。 それでも、最初からそのバランスに向けて構築することは、後からコンプライアンスを後付けするよりも、ずっと本気度の高い賭けです。 規制対象の資産が実際にスケールして動き始めたときのパフォーマンスを、誰かが実際に追跡しているのでしょうか? #dusk $DUSK
私は@Dusk がプライバシーをどう描写しているかについて、特定の緊張関係のことをずっと考えています。最初に聞こえるよりも、ずっと分かりにくいのです。多くの人は、プライバシーと規制は互いに逆の方向へ引っ張り合うので、どちらか一方しか成り立たないと思いがちです。どちらかを選ぶだけ、両方は無理だと。

しかし、Duskのモデルはその選択を強制しません。ゼロ知識による検証があれば、ネットワークは取引がルールに従って行われたことを、実際にその具体的な中身をさらすことなく確認できます。従来の金融は、何かに署名される前に、データを銀行や取引相手、規制当局が直接見られる状態にして信頼を解決することでしかそれができません。Duskは、検証と開示を完全に切り離します。

率直に言えば、これが本当の転換点です。機微な詳細は封印されたままですが、必要になったときに限って、許可された関係者はきちんと機能する監査の導線を得られます。プライバシーは「オフ・ザ・グリッド(網の外)」という意味から、「保護されているが説明責任がある」という意味へと変わっていきます。これは、多くのプライバシー重視のチェーンがそもそも目指している設計目標とは別物です。

そして、どうしても頭を離れない未解決の問いがあります。実際の機関レベルの取引量が流れ始めたとき、つまり設計上すべてがきれいに整っている制御されたパイロットだけでなく、本番の運用ではこの考え方は成り立つのでしょうか。

それでも、最初からそのバランスに向けて構築することは、後からコンプライアンスを後付けするよりも、ずっと本気度の高い賭けです。

規制対象の資産が実際にスケールして動き始めたときのパフォーマンスを、誰かが実際に追跡しているのでしょうか?
#dusk $DUSK
私は、レンディング市場を見るときに普段見落としがちなことについて考えていました。それは、ポジションを保有し続けることにかかるコストです。 それが、@termmax が私の興味を引いた理由です。重要なのは、単に金利が固定であることではありません。ポジションが始まる前に、借入コストと満期が分かっている点です。 変動金利での借入だと、ポジションを開いたままの間に負債が変動するのを見てきました。すると、資金調達コストという別の動く要素が加わるため、レバレッジの計画が難しくなります。TermMaxは、負債を固定金利・固定期間のポジションとして表現することで、この問題に取り組んでいます。 さらに興味深いのは、二次的な影響です。資金調達費用が定義されれば、金利がどこへ向かうかを絶えず推測する代わりに、既知のコストに対して資本の投入先を評価できます。 これをレバレッジ・リスクをなくすものだとは見ていません。なくすわけではありません。ただし、負債をより予測可能にすることで、意思決定がより慎重になり、説明責任がはっきりします。 私の見解では、TermMaxは問いを「このコストは後でいくらになるのか?」から「この既知のコストで、このポジションは理にかなっているか?」へと変えます。 それは本当にレバレッジ管理を改善するのか、それとも資金調達リスクを測りやすくするだけなのでしょうか? #termmax
私は、レンディング市場を見るときに普段見落としがちなことについて考えていました。それは、ポジションを保有し続けることにかかるコストです。

それが、@TermMax が私の興味を引いた理由です。重要なのは、単に金利が固定であることではありません。ポジションが始まる前に、借入コストと満期が分かっている点です。

変動金利での借入だと、ポジションを開いたままの間に負債が変動するのを見てきました。すると、資金調達コストという別の動く要素が加わるため、レバレッジの計画が難しくなります。TermMaxは、負債を固定金利・固定期間のポジションとして表現することで、この問題に取り組んでいます。

さらに興味深いのは、二次的な影響です。資金調達費用が定義されれば、金利がどこへ向かうかを絶えず推測する代わりに、既知のコストに対して資本の投入先を評価できます。

これをレバレッジ・リスクをなくすものだとは見ていません。なくすわけではありません。ただし、負債をより予測可能にすることで、意思決定がより慎重になり、説明責任がはっきりします。

私の見解では、TermMaxは問いを「このコストは後でいくらになるのか?」から「この既知のコストで、このポジションは理にかなっているか?」へと変えます。

それは本当にレバレッジ管理を改善するのか、それとも資金調達リスクを測りやすくするだけなのでしょうか?
#termmax
I've been digging into @Dusk_Foundation dual transaction model lately, and most people talking about it seem to think "privacy chain" means everything on it is private by default. That's not actually how it's built. The thing is, Dusk runs two separate models side by side. Moonlight is the transparent side account based, balances and activity publicly verifiable, basically the Ethereum style approach. Phoenix is the other half, UTXO based, using zero knowledge proofs and nullifiers to handle the double spend problem without exposing what is actually in the transaction. That's the part that actually works the network can confirm a transaction is valid without seeing the contents, and nullifiers solve the exact problem that usually breaks privacy focused designs. Instead of forcing every transaction into one model, it lets some activity stay publicly auditable while position sizes, counterparties, or strategy stay hidden, even on a public chain. The honest risk here: running two systems side by side is not free. Whatever complexity doesn't show up now tends t0 surface later as edge cases or weird interactions between the two models. Still, splitting privacy from transparency by design beats bolting privacy on as an afterthought. Anyone else watching how Moonlight and Phoenix actually interact in practice? #dusk $DUSK
I've been digging into @Dusk dual transaction model lately, and most people talking about it seem to think "privacy chain" means everything on it is private by default. That's not actually how it's built.

The thing is, Dusk runs two separate models side by side. Moonlight is the transparent side account based, balances and activity publicly verifiable, basically the Ethereum style approach. Phoenix is the other half, UTXO based, using zero knowledge proofs and nullifiers to handle the double spend problem without exposing what is actually in the transaction.

That's the part that actually works the network can confirm a transaction is valid without seeing the contents, and nullifiers solve the exact problem that usually breaks privacy focused designs. Instead of forcing every transaction into one model, it lets some activity stay publicly auditable while position sizes, counterparties, or strategy stay hidden, even on a public chain.

The honest risk here: running two systems side by side is not free. Whatever complexity doesn't show up now tends t0 surface later as edge cases or weird interactions between the two models.

Still, splitting privacy from transparency by design beats bolting privacy on as an afterthought.

Anyone else watching how Moonlight and Phoenix actually interact in practice?
#dusk $DUSK
私はここしばらく、フェニックスの取引が実際にどのように検証されるのか(@Dusk_Foundation )を考えてきたのですが、多くの人はいまだに「データを見て承認する」というおなじみの手順を思い浮かべます。 でも肝心なのは、検証者は送信者も受信者も金額も受け取らないということです。届くのはPLONKの証明(プローブ)です。その証明には、重要なルールがエンコードされています。つまり、支出者が実際に使用しているノートを所有していたこと、金額が正しくつり合っていること、そして再利用が行われていないこと。チェックは単に、数学が成り立つことを確認するだけです。隠された取引そのものを再構築したり、調べたりすることはありません。 これは、検証というものが何を意味するのかを大きく変えるものです。システムは、「それをそうだとするもの」を一度も見ないまま、数学的な命題が真であることを確認しているのです。 ただし制約もあります。何かがうまくいかないとき、プライバシーを守るのと同じ不可視性が、目視でのデバッグを難しくもします。 それでも、設計は意図的に感じられます。データを見ないことは、ここでのセキュリティモデルの一部です。 検証対象となるものを決して見ずに行う検証に、あなたは納得できますか? #dusk $DUSK
私はここしばらく、フェニックスの取引が実際にどのように検証されるのか(@Dusk )を考えてきたのですが、多くの人はいまだに「データを見て承認する」というおなじみの手順を思い浮かべます。

でも肝心なのは、検証者は送信者も受信者も金額も受け取らないということです。届くのはPLONKの証明(プローブ)です。その証明には、重要なルールがエンコードされています。つまり、支出者が実際に使用しているノートを所有していたこと、金額が正しくつり合っていること、そして再利用が行われていないこと。チェックは単に、数学が成り立つことを確認するだけです。隠された取引そのものを再構築したり、調べたりすることはありません。

これは、検証というものが何を意味するのかを大きく変えるものです。システムは、「それをそうだとするもの」を一度も見ないまま、数学的な命題が真であることを確認しているのです。

ただし制約もあります。何かがうまくいかないとき、プライバシーを守るのと同じ不可視性が、目視でのデバッグを難しくもします。

それでも、設計は意図的に感じられます。データを見ないことは、ここでのセキュリティモデルの一部です。

検証対象となるものを決して見ずに行う検証に、あなたは納得できますか?
#dusk $DUSK
@termmax は実際の金融コストとして時間を扱うから、私は何度もそこに戻ってきます。流動性が消えるまで変動金利が安く見えるのを何度も見てきましたが、その同じ借り入れが突然つらくなるんです。固定コストと既知の満期は退屈に聞こえるかもしれません。でも市場では、退屈さは役に立つことがあります。 私の注目点は、TermMaxがその考えをどう実装しているかです。固定された請求権をトークン化し、市場マーカーが金利を提示できるようにし、清算のタイムテーブルに頼るのではなく、最初のプレミアムでコールまたはプットのエクスポージャーを提供します。とはいえ、予測可能なコストは予測可能な結果と同じではありません。 より大きな疑問は、残りのリスクがどこに行くのかです。ローンは相変わらず担保、オラクル、スマートコントラクト、そして取引相手に依存しています。流動性は資産と満期ごとに分離されるため、早期に退出しようとするとスリッページが起きたり、実際には退出できなかったりすることがあります。現物決済もまた、望んでいなかった変動の大きい担保を貸し手に残してしまう可能性があります。一方で、キュレーターが管理するバルトでは、別の人間の判断というレイヤーが加わります。 私の結論はシンプルです。TermMaxはリスクを取り除きません。ある部分だけを予測可能にし、そのほかをより理解することが重要になります。 予測可能な資金調達は、より良い説明責任を生み出せるのでしょうか? #termmax
@TermMax は実際の金融コストとして時間を扱うから、私は何度もそこに戻ってきます。流動性が消えるまで変動金利が安く見えるのを何度も見てきましたが、その同じ借り入れが突然つらくなるんです。固定コストと既知の満期は退屈に聞こえるかもしれません。でも市場では、退屈さは役に立つことがあります。

私の注目点は、TermMaxがその考えをどう実装しているかです。固定された請求権をトークン化し、市場マーカーが金利を提示できるようにし、清算のタイムテーブルに頼るのではなく、最初のプレミアムでコールまたはプットのエクスポージャーを提供します。とはいえ、予測可能なコストは予測可能な結果と同じではありません。

より大きな疑問は、残りのリスクがどこに行くのかです。ローンは相変わらず担保、オラクル、スマートコントラクト、そして取引相手に依存しています。流動性は資産と満期ごとに分離されるため、早期に退出しようとするとスリッページが起きたり、実際には退出できなかったりすることがあります。現物決済もまた、望んでいなかった変動の大きい担保を貸し手に残してしまう可能性があります。一方で、キュレーターが管理するバルトでは、別の人間の判断というレイヤーが加わります。

私の結論はシンプルです。TermMaxはリスクを取り除きません。ある部分だけを予測可能にし、そのほかをより理解することが重要になります。

予測可能な資金調達は、より良い説明責任を生み出せるのでしょうか?
#termmax
何日かの間ずっとDuskVMとDuskEVMのどちらにするか行ったり来たりしていて、正直最初は「言語の違い」くらいの話だと思ってました。つまり、Rust/WASMかSolidityで、どちらも誰もが既に知っているツールチェーンの範囲内だろう、と。……でも違います。 ポイントは、DuskVMがネットワークの基盤のすぐ直下にあるので、Duskが実際にそのために作っているプライバシーやゼロ知識系の仕組みに直接アクセスできることです。DuskEVMはSolidityのコントラクトを標準のEVMツーリングで動かしますが、それでも同じDuskDSレイヤーを通じて決済され、ガスも同じDUSKトークンで支払います。違う実行ルートが、下の階層で同じ場所に着地する、という構図です。 でも、実は重要なのはそこではありません。DuskVMを選ぶのは「言語」を選ぶことではなく、「プライバシーのプリミティブそのものへの近さ」を選ぶことです。DuskEVMを選ぶなら、その距離の一部を、ほぼコード変更なしで連携できるウォレット、ブリッジ、取引所といった互換性の利便性と引き換えることになります。 ただし落とし穴があります。同じ決済レイヤーだからといって、同じ機能が手に入るわけではありません。DuskVMには近道がありません。必要なツール類はすべて最初から作り込みになります。 それでも、そのトレードオフが存在することをはっきり書き分けてほしいです。存在しないふりはしてほしくありません。 あなたはプライバシーのプリミティブに直接向けて作っていますか?それとも、まず互換性を重視していますか? @Dusk_Foundation #dusk $DUSK
何日かの間ずっとDuskVMとDuskEVMのどちらにするか行ったり来たりしていて、正直最初は「言語の違い」くらいの話だと思ってました。つまり、Rust/WASMかSolidityで、どちらも誰もが既に知っているツールチェーンの範囲内だろう、と。……でも違います。

ポイントは、DuskVMがネットワークの基盤のすぐ直下にあるので、Duskが実際にそのために作っているプライバシーやゼロ知識系の仕組みに直接アクセスできることです。DuskEVMはSolidityのコントラクトを標準のEVMツーリングで動かしますが、それでも同じDuskDSレイヤーを通じて決済され、ガスも同じDUSKトークンで支払います。違う実行ルートが、下の階層で同じ場所に着地する、という構図です。

でも、実は重要なのはそこではありません。DuskVMを選ぶのは「言語」を選ぶことではなく、「プライバシーのプリミティブそのものへの近さ」を選ぶことです。DuskEVMを選ぶなら、その距離の一部を、ほぼコード変更なしで連携できるウォレット、ブリッジ、取引所といった互換性の利便性と引き換えることになります。

ただし落とし穴があります。同じ決済レイヤーだからといって、同じ機能が手に入るわけではありません。DuskVMには近道がありません。必要なツール類はすべて最初から作り込みになります。

それでも、そのトレードオフが存在することをはっきり書き分けてほしいです。存在しないふりはしてほしくありません。

あなたはプライバシーのプリミティブに直接向けて作っていますか?それとも、まず互換性を重視していますか?
@Dusk #dusk $DUSK
確認済み
午前中、@Dusk_Foundation が実際にどのように機密取引を実装しているのかを一通り確認していたのですが、ひとつだけ引っかかりました。ここにはプライバシーが“チェーンの上に載る機能”として存在し、オプションのモードとして切り替えられるものだと想像していました。違います。ゼロ知識証明を使って、ベースレイヤーに組み込まれています。つまり、自分が支払い能力(ソルベンシー)を持ち、資格があること、取引が成立したことを“数字を見せずに”正しいと証明するのです。 その下にあるものは、プライバシーそのものよりも興味深いです。監査人は引き続き検証できますが、その他の人は有効なトランザクションだということ以上は見えません。多くのチェーンでは、秘匿のためのミキサーを使うか、機関投資家の信頼のために全面的な透明性を選ぶか、というトレードオフが強いられます。Duskは、その取引(トレードオフ)を選択的開示によって完全に無効化できると賭けている。その論理がZedgerやRWAトークン化の方向性であり、さらにDuskEVMが重要になる理由でもあります。つまり、Solidity開発者は新しいことを学ばずに、このモデルの上で構築できる。 率直に言うと、私が決着できていないのは、「“検証可能に準拠している(provably compliant)”」という考えが、「完全に見える(fully visible)」のと同じ強度で成り立つのか、規制当局が実際の争議で圧力テストしてきた場合のことです。NPEXは、機関がそれを試す用意があることを示唆しています。試してみる意思があることは、証明されていることとは同じではありません。 それでも、この件はまだ引っかかったままです。 #dusk $DUSK
午前中、@Dusk が実際にどのように機密取引を実装しているのかを一通り確認していたのですが、ひとつだけ引っかかりました。ここにはプライバシーが“チェーンの上に載る機能”として存在し、オプションのモードとして切り替えられるものだと想像していました。違います。ゼロ知識証明を使って、ベースレイヤーに組み込まれています。つまり、自分が支払い能力(ソルベンシー)を持ち、資格があること、取引が成立したことを“数字を見せずに”正しいと証明するのです。

その下にあるものは、プライバシーそのものよりも興味深いです。監査人は引き続き検証できますが、その他の人は有効なトランザクションだということ以上は見えません。多くのチェーンでは、秘匿のためのミキサーを使うか、機関投資家の信頼のために全面的な透明性を選ぶか、というトレードオフが強いられます。Duskは、その取引(トレードオフ)を選択的開示によって完全に無効化できると賭けている。その論理がZedgerやRWAトークン化の方向性であり、さらにDuskEVMが重要になる理由でもあります。つまり、Solidity開発者は新しいことを学ばずに、このモデルの上で構築できる。

率直に言うと、私が決着できていないのは、「“検証可能に準拠している(provably compliant)”」という考えが、「完全に見える(fully visible)」のと同じ強度で成り立つのか、規制当局が実際の争議で圧力テストしてきた場合のことです。NPEXは、機関がそれを試す用意があることを示唆しています。試してみる意思があることは、証明されていることとは同じではありません。

それでも、この件はまだ引っかかったままです。
#dusk $DUSK
最近、シタデルが実際に何をしているのかを理解しようと時間を使っていて、多くの人はまだそれを「アイデンティティ/KYCレイヤー」として扱い、読み飛ばしているように思います。ですが、その見方は違いの本質を外しています。 多くのアイデンティティシステムは金庫のようなもので、あなたのデータを集めて保持します。シタデルはそれよりも「フィルター」に近い。情報を渡すのではなく、主張を証明するのです。そして、その証明が済んだ後は、システムが元になっている具体的な情報を保持しません。検証済みの資格情報は、それ自体が永続的な資産というわけでもなく、背後にある主張がまだ成り立っていない限り、無関係になるまで期限切れになります。だから「一度きり」ではなく、再度の証明が必要です。 ここが実際に効いている部分です。開示の負担を、証明(アテステーション)へと移すことで、今のところオンチェーン上の多くのコンプライアンス・ツールとは根本的に異なる信頼モデルになるのです。 ただし、制約は現実にあります。何度も再証明するのは手間で、その手間こそが、多くのユーザーが避けたいものです。たとえトレードオフが自分に有利だとしても、それでもです。 それでも、その手間が人々をシステムから離れさせずに使い続けさせる理由になっているなら、それは利便性が生むどんな要求よりも、より粘着性の高い種類の需要です。 あなたはシタデルをインフラとして追っていますか? それとも、コンプライアンス芝居としてまだ切り捨てたままですか? #dusk $DUSK @Dusk_Foundation
最近、シタデルが実際に何をしているのかを理解しようと時間を使っていて、多くの人はまだそれを「アイデンティティ/KYCレイヤー」として扱い、読み飛ばしているように思います。ですが、その見方は違いの本質を外しています。

多くのアイデンティティシステムは金庫のようなもので、あなたのデータを集めて保持します。シタデルはそれよりも「フィルター」に近い。情報を渡すのではなく、主張を証明するのです。そして、その証明が済んだ後は、システムが元になっている具体的な情報を保持しません。検証済みの資格情報は、それ自体が永続的な資産というわけでもなく、背後にある主張がまだ成り立っていない限り、無関係になるまで期限切れになります。だから「一度きり」ではなく、再度の証明が必要です。

ここが実際に効いている部分です。開示の負担を、証明(アテステーション)へと移すことで、今のところオンチェーン上の多くのコンプライアンス・ツールとは根本的に異なる信頼モデルになるのです。

ただし、制約は現実にあります。何度も再証明するのは手間で、その手間こそが、多くのユーザーが避けたいものです。たとえトレードオフが自分に有利だとしても、それでもです。

それでも、その手間が人々をシステムから離れさせずに使い続けさせる理由になっているなら、それは利便性が生むどんな要求よりも、より粘着性の高い種類の需要です。

あなたはシタデルをインフラとして追っていますか? それとも、コンプライアンス芝居としてまだ切り捨てたままですか?
#dusk $DUSK @Dusk
·
--
ブリッシュ
$VELVET は本日+32%以上上昇していますが、その急騰のあとでは、ポンプを追いかけるよりも、現在の水準付近で価格がどう動くかにより注目しています。 価格: 0.9507 24h 高値: 1.1299 24h 安値: 0.4805 24h 出来高: 189.47M USDT $VELVET /USDT ロング エントリー: 0.94–0.96 TP1: 1.00 TP2: 1.08 TP3: 1.12 損切り: 0.89 15分足チャートでは、価格は1.1110まで押し上げられた後、強い拒否(リジェクト)によって0.8601付近まで下落しました。それ以来、買い手が価格を0.94–0.96付近で安定させることに成功しており、ここが今私が見ているエリアです。 このゾーンが維持され、かつ$VELVET が1.00を明確に上回る動きを見せるなら、1.08、そして直近高値付近の1.11–1.12に注目します。ここでは先ほどの上昇を追いかけません。私にとってより良いセットアップは、0.89が守られている間の確証を待つことです。 {future}(VELVETUSDT)
$VELVET は本日+32%以上上昇していますが、その急騰のあとでは、ポンプを追いかけるよりも、現在の水準付近で価格がどう動くかにより注目しています。

価格: 0.9507
24h 高値: 1.1299
24h 安値: 0.4805
24h 出来高: 189.47M USDT

$VELVET /USDT ロング
エントリー: 0.94–0.96
TP1: 1.00
TP2: 1.08
TP3: 1.12
損切り: 0.89

15分足チャートでは、価格は1.1110まで押し上げられた後、強い拒否(リジェクト)によって0.8601付近まで下落しました。それ以来、買い手が価格を0.94–0.96付近で安定させることに成功しており、ここが今私が見ているエリアです。

このゾーンが維持され、かつ$VELVET が1.00を明確に上回る動きを見せるなら、1.08、そして直近高値付近の1.11–1.12に注目します。ここでは先ほどの上昇を追いかけません。私にとってより良いセットアップは、0.89が守られている間の確証を待つことです。
確認済み
最近Dusk XSCの設計を読み返していて、まだ多くの人がそれを「プライバシートークン」として片付けて終わりにしている気がします。ですが、肝心の“プライバシー”の部分は、ここでは最も面白くない層かもしれません。 封印された残高の下では、どの送金もKYCおよびAMLのオンボーディングに紐づくホワイトリストを通過する必要があります。適格性を証明しなければならず、内容は隠されたままだとしても監査証跡は残ります。しかもこれは一度きりの関門ではなく、状況が変わるたびに取引相手側が再認定を続ける必要があるので、オンボーディングは単発の変換タイミングではなく、繰り返し行うチェックになります。 正直なところ、その部分こそが実際に機能しているところです。セキュリティトークンにおいては、適合(コンプライアンス)の再証明こそが、上にかぶっている機密性のラッパーではなく、実質的なプロダクトだと言えるかもしれません。 とはいえ、制約も明らかです。これだけ頻繁な検証は摩擦を生みます。そして摩擦こそが、ほとんどのトークン設計で採用を殺してしまうものです。機関投資家ならそれに耐えられるかもしれませんが、個人(リテール)ユーザーはたぶん無理でしょう。 それでも、規制された資本がここでの本当のターゲットなら、そのトレードオフは筋が通ります。目に見える活動よりも、静かでコンプライアンスに沿った持続性が優先されるわけです。 市場は実際にプライバシーを価格に織り込んでいるのでしょうか? それとも、“何も変わっていないこと”を目立たずに証明できることだけを織り込んでいるのでしょうか? @Dusk_Foundation #dusk $DUSK
最近Dusk XSCの設計を読み返していて、まだ多くの人がそれを「プライバシートークン」として片付けて終わりにしている気がします。ですが、肝心の“プライバシー”の部分は、ここでは最も面白くない層かもしれません。

封印された残高の下では、どの送金もKYCおよびAMLのオンボーディングに紐づくホワイトリストを通過する必要があります。適格性を証明しなければならず、内容は隠されたままだとしても監査証跡は残ります。しかもこれは一度きりの関門ではなく、状況が変わるたびに取引相手側が再認定を続ける必要があるので、オンボーディングは単発の変換タイミングではなく、繰り返し行うチェックになります。

正直なところ、その部分こそが実際に機能しているところです。セキュリティトークンにおいては、適合(コンプライアンス)の再証明こそが、上にかぶっている機密性のラッパーではなく、実質的なプロダクトだと言えるかもしれません。

とはいえ、制約も明らかです。これだけ頻繁な検証は摩擦を生みます。そして摩擦こそが、ほとんどのトークン設計で採用を殺してしまうものです。機関投資家ならそれに耐えられるかもしれませんが、個人(リテール)ユーザーはたぶん無理でしょう。

それでも、規制された資本がここでの本当のターゲットなら、そのトレードオフは筋が通ります。目に見える活動よりも、静かでコンプライアンスに沿った持続性が優先されるわけです。

市場は実際にプライバシーを価格に織り込んでいるのでしょうか? それとも、“何も変わっていないこと”を目立たずに証明できることだけを織り込んでいるのでしょうか?
@Dusk #dusk $DUSK
$XRP クジラの蓄積は回復力を示しています。 ウォレットの保有額が100万ドル超の $XRP は、XRPの時価総額が29%下落したにもかかわらず、過去3か月で32増加しました。 この乖離は、大口保有者が弱さを買い集めている可能性を示唆しており、次の流動性拡大に向けてポジションを取っているかもしれません。 $XRP
$XRP クジラの蓄積は回復力を示しています。

ウォレットの保有額が100万ドル超の $XRP は、XRPの時価総額が29%下落したにもかかわらず、過去3か月で32増加しました。

この乖離は、大口保有者が弱さを買い集めている可能性を示唆しており、次の流動性拡大に向けてポジションを取っているかもしれません。

$XRP
米国のスポット・ビットコインETFは先週、8億6530万ドルを受け入れた。4月中旬以来の最高水準だ。 これは、セルフカストディ(自己保管)のリスクに関する議論のさなかに、COLDCARDウォレットから約1億3000万ドル相当のBTCが流出したのが1週間前だったことに続く。
米国のスポット・ビットコインETFは先週、8億6530万ドルを受け入れた。4月中旬以来の最高水準だ。

これは、セルフカストディ(自己保管)のリスクに関する議論のさなかに、COLDCARDウォレットから約1億3000万ドル相当のBTCが流出したのが1週間前だったことに続く。
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約