Sattar Chaqer

あなたが考えること：$QNT は史上最高値の428ドルを更新できるのか、それとも史上最高値を更新できないのか

48500人以上のフォロワー、これは私のバイナンスの仲間たちです。

これまでの私の歩みに関わってくれたすべての方へ。最初からいてくれた方も、最近参加してくれた方も、あなたの支えは私にとってとても大きなものです。

ただいま戻ってきました。そして皆さんが一緒にいてくれて嬉しいです。これからも一緒に成長していきましょう。

バイナンスの仲間たちに大きな愛を。❤️

特別な感謝を @MrStar @BTC_Fahmi @Aesthetic_Meow @GM_Crypto01 @Ridhi Sharma @Alizeh Ali _Angel @Coin--King @Hazel Rose @J U N I A @Dr Nohawn @Nadyisom @Mohsin_Trader_King @RUBYISHAH_LODHI2001 @Fox夕 @Crypto_Alchemy @DrSaleG @BINANSERS @KOKIM 4758 @NAPOL @AmnaJen @RazdannN

Join here my amazing friend @Fox夕

行って取りに行こう

2

急げ！請求を取りに行こう

チャンスを逃さないで

$BTC が先陣を切って動いており、$ETH は力強く追随しています。両方のチャートは、市場全体で勢いが急速に高まっていることを示しています。

すべてのTPヒット

TP 1 HITS

以前は、コンセンサスとは主に次のブロックを選ぶことだと思っていました。

しかしDuskは、私にそれを別の見方をさせました。

Succinct Attestationでは、有力候補となるブロックは新しいチップになる前に、複数の段階を経る必要があります。

まずProposalです。ランダムに選ばれたプロビジョナーが、候補ブロックを生成してブロードキャストします。

次にValidation。委員会が、候補ブロックを現在のチェーンと照合し、有効かどうかを投票します。

ですがDuskはそれで終わりではありません。

別の委員会がRatificationを担当し、Validation段階の結果に対して投票します。

この分離が、私の目を引きました。

ネットワークは単に、「ブロックはあるか？」と尋ねているわけではありません。

そのブロックが有効なのか、有効性の検証が定足数に達したのか、そして別の委員会がその結果に同意しているのか――それを尋ねています。

そして、ratificationが成功した後にのみ、その候補は新しいチップとして受け入れられます。

これは、コンセンサスの考え方として非常に異なるものです。

@Dusk $DUSK #dusk

ステーキング・コントラクトが実際に設定できる報酬分配ルールとは
‎
‎午後ずっと、Dusk上のステーキング・コントラクトが実際に何を設定できるのかを追いかけていて、選択肢はかなり限られているはずだと思っていました。ところが、限られていません。
‎
‎Dusk自身の「Stake Abstraction」に関するドキュメントでは、コントラクトが任意の報酬分配ルールを実装でき、報酬の一部を紹介者（リファラー）のアフィリエイトやオペレーターにルーティングすることも含めて、すべてコントラクト側の裁量で行えると確認できます。これは固定のプロトコル・レベルの割合ではありません。つまり、実際に設定可能な余地が非常にオープンです。$BTR
‎
‎その点が引っかかりました。
‎
‎プロトコルが強制する単純さを捨て、その代わりに、コントラクトをデプロイする人が、実際に報酬がそれを利用する人々の間でどう分けられるかを決められるようにする。上からは標準の分配が押し付けられません。$TAC
‎
‎ただ、ここで自分が実際に分かっていることを正確にしたいです。Duskは、このパターンの実例として、実用上のSozuを挙げています。自動化されたステーキング・プールです。私がどこを探しても見つからないのは、Sozuの現時点でのデプロイ状況が、メインネット稼働なのか、テストネットのみなのか、あるいはその中間なのかといった点です。そこは推測しません。@Dusk
‎
‎Sozuの具体的な状態に関係なく、これによって何が可能になるのかという点に立ち返り続けました。紹介（リファラル）駆動型のステーキング・サービス、オペレーターの手数料モデル、アフィリエイト・プログラムなどはすべて、Dusk自体がそれらのいずれかを作り込む必要なしに、技術的には実現できます。#dusk
‎
‎では、オープンな報酬分配は本当に役に立つステーキング商品を生み出すのでしょうか。それとも、信頼の問いが「Duskのプロトコルが自分に対してフェアに扱ってくれるか」から「この特定のコントラクトのオペレーターが自分に対してフェアに扱ってくれるか」へと移るだけなのでしょうか？$DUSK

プライバシーは、金額を隠すことだけではありません。

私がフェニックスで興味深いと思ったのは、取引同士が結び付けられにくくなるようにも工夫している点です。

フェニックスでは、メルクルツリーに保存されたノート（支払い単位）を使用します。各ノートにはそれぞれ固有のノート公開鍵があります。

同じ公開鍵を何度も使い回すのではなく、フェニックスは各ノートごとに使い捨てのノート公開鍵を作成します。

それが印象的だったのは、同じ識別子を再利用すると、異なる取引を同じユーザーに結び付けるのが簡単になり得るからです。$GRASS

ホワイトペーパーでは、この使い捨て鍵は取引間の非リンク性（アンリンクアビリティ）を提供するために設計されていると述べています。$UAI

もう一つ、興味深い点があります。

受信者はビューキーを使って、そのノートが自分のものかどうかを確認できます。一方で、そのノートを消費するために必要な秘密鍵は、受信者の完全な秘密鍵からのみ導出できるようになっています。

つまり、ここでのプライバシーの考え方は、単にすべてを隠すことではありません。

公開的に「つながることができる範囲」をコントロールすることです。

それによって、私はフェニックスを別の視点で見つめるようになりました。

プライベートな取引であることは一つのこと。

さらに、誰かが複数の取引を見て、それらを結び付けることを難しくすることも別の意味があります。

正直に言うと、後者のほうが同じくらい重要かもしれません。

@Dusk $DUSK #dusk

プライバシーにとって最も重要なのは何でしょう？

すべてのブロックチェーンのメッセージを全員に送るのは安全そうです。ですが、信じられないほど無駄でもあります。

私がDuskのホワイトペーパーを読んだときに、Kadcastが興味深いと感じたのはまさにそこです。

DuskはKadcastを使って、ブロック、トランザクション、コンセンサス投票をブロードキャストします。同じメッセージを単に隣接するすべてのノードに無差別に流すのではなく、KadcastはKademliaの考え方を用いてノードを整理します。

各ノードは、ノードID間のXOR距離に基づいてバケットに分類されたルーティング情報を保持します。

そして、伝播の仕方がより選択的になります。

あるノードは、増加するXOR距離に応じて選ばれたピアにメッセージを転送します。そうしたピアがプロセスを続けることで、ネットワーク全体にわたって構造化されたカスケードが形成されます。

Kadcastはマルチキャストツリーも使用します。メッセージは近いピアから始まり、そこからネットワークのより遠いノードへと引き継がれます。これにより、不要な経路を通じて同じ情報を繰り返し送るのではなく、より少ないリレーでネットワークのノードをカバーできます。$TUT

この違いに惹かれたのは、ブロックチェーンのネットワークでは、すべてのノードがすべての隣接ノードへ何もかも転送し続けるとコストが高くなり得るからです。

重要なのは、メッセージを素早く動かすことだけではありません。

信頼性の高い、かつタイムリーな伝播を維持しながら、冗長な送信を減らすことです。

私はこの点が好きです。なぜなら、ブロックチェーンの性能は、コンセンサスやブロック生成だけの話ではないことを示しているからです。$PUMP

ネットワークもまた、情報を効率的に運ばなければなりません。

ときには、より賢い設計とは、より多くのメッセージを送ることではありません。

本当にそれらを受け取る必要があるノードを知ることです。

@Dusk $DUSK #dusk

Kadcastを効率的にしているのは何でしょうか？

市場はまた、いくつか興味深い名前を持ち込んでいます。$TRUMP $BEAT どちらもチャート上で大きな注目を集めています。現時点では、私が気づく前にみんながこうした値動きをどうやって見つけているのかを理解しようとしているところです。

以前は、失敗したスマートコントラクト呼び出しは基本的にただのエラーだと思っていました。

しかし DuskVM をよりよく調べるほど、失敗のパスがいっそう面白くなってきました。

実行が始まる前に Dusk は、送信者の残高、署名、nonce などを確認します。これらの基本条件が満たされない場合、トランザクションは通常どおり実行されません。

では、実行中に何かがうまくいかなかったらどうなるのでしょう？

そこが、私がより重要だと感じている部分です。

スマートコントラクトは実行中に状態変更を行うことができますが、失敗した呼び出しがその状態変更をそのまま残すわけではありません。失敗した実行による状態変更はコミットされません。

そのため、コントラクトが古い状態と不完全な新しい状態の間で途中のまま固まることはありません。

ガスもここで重要です。コントラクトの実行はガスを消費するため、失敗は「最終結果が成功だったかどうか」だけの問題ではありません。その途中でも実行リソースは消費されます。

それによって、私の考えは「安全な実行とは何か」を見直す方向に変わりました。

それは、成功するトランザクションを機能させることだけではありません。

実行が失敗したときに、予測可能な挙動があることでもあります。

金融アプリケーションにおいて、その違いは重要です。価値ある資産を扱うシステムは、想定していた経路が崩れたときに何が起きるのかを知る必要があります。

スマートコントラクトで最も重要な部分が、「すべてがうまくいったときに何が起きるか」ではないことがあります。

問題は、ネットワークがそうならないときに何をするか、です。

@Dusk $DUSK #dusk

呼び出しが失敗したときに最も重要なのは何ですか？

市場は本当に“もう一度見たくなる”見せ方を知っている。$PEOPLE $ENA

チャート上では、かなり強い動きを見せている。

本当のスキルは“動く銘柄を見つけること”ではなく、“動き出す前に見つけること”なのではと思い始めた。

以前は、ブロックチェーンのネイティブ環境に直接構築することが自動的に最適だと考えていた。

しかし、DuskVMを詳しく見てみた。

DuskVMは、開発者にDuskのレイヤー1環境への直接アクセスを提供する。スマートコントラクトはDusk固有のプリミティブを使い、ネットワークのネイティブ機能と密に連携できる。

それは一見、明らかな利点に聞こえる。だが反対側を見てみると別だ。

Dusk上に直接構築するということは、DuskVM専用に設計されたツール群とも付き合う必要があるということだ。既に確立されたエコシステムから来た開発者は、慣れ親しんだ言語・フレームワーク・開発ワークフローにすでに安心感を持っているかもしれない。

つまり、現実にはトレードオフがある。

L1へのアクセスはより近くなるが、すでに知っているツールからはさらに遠ざかる。

そのことが、私にDuskVMについて別の見方をさせた。

問いは単に、Duskのネイティブ実行環境が強力かどうかではない。

Dusk固有のプリミティブにアクセスできることが、より専門化された開発体験を受け入れるに足るほど価値があるかどうかだ。

Duskのアーキテクチャに密接に結びついた機能が必要なアプリケーションでは、そのトレードオフが成立する可能性がある。

しかし、慣れ親しんだツールやワークフローを主に求める開発者にとっては、学習曲線が技術そのものと同じくらい重要になるかもしれない。

インフラは、開発者が何を作れるかだけではない。

それは、彼らがそれを作るために何を学ぶつもりがあるかでもある。

@Dusk $DUSK #dusk

開発者にとって、より重要なのは何だろう？

市場は、私を驚かせるために新しい名前を次々と見つけてきます。$BOME $RE

どちらもチャート上で十分な注目を集めています。

この時点では、次にどちらが動くかを聞くことすらしていません。みんなの前にそれを見つけたいだけです。

以前は、ブロックチェーンにEVMを追加するのは、主に開発を簡単にするためだと思っていました。

しかし、Duskを深く見ていくと、捉え方が変わってきました。

Duskには2つの実行環境があります。DuskVMとDuskEVMです。そしてそれらは、2種類の異なる開発者の課題を解決しているようです。

DuskVMはネイティブの環境です。スマートコントラクトはRustで書いてWebAssemblyにコンパイルでき、開発者がDuskのL1アーキテクチャの中で直接構築する手段を提供します。

一方でDuskEVMは別のアプローチです。

Ethereumから来た開発者にとって馴染みのある環境を提供し、SolidityやVyper、そして確立されたEVMツールングのサポートもあります。

この違いは、私が最初に考えていた以上に重要です。

Duskのネイティブなアーキテクチャに密接に取り組みたい開発者は、DuskVMを使えます。

しかし、すでにSolidityを知っていて、何年もEthereumの開発ツールを使ってきた人は、Duskで試し始めるためだけに、まったく別の環境を学びたいわけではありません。

だから私は、DuskVMとDuskEVMを互いに競合するものだとは見ていません。

同じネットワークへの2つの入口のようなものです。

1つはDuskにネイティブ。

もう1つは、EVMの世界から来る開発者にとってエコシステムをより利用しやすくします。

今は、より難しい問いのほうに興味が湧いてきました。

Duskは、実行アーキテクチャが断片化して感じられることなく、両方の開発者グループを惹きつけることができるのでしょうか？

@Dusk $DUSK #dusk

Duskのどの環境に、より関心がありますか？