NómadaCripto

#dusk $DUSK @Dusk
Cuando una operación muestra un resultado, normalmente tiendo a pensar que el proceso ya terminó. Pero como trader empecé a preguntarme algo que antes simplificaba demasiado: ¿qué significa realmente que una transacción haya sido aceptada por un nodo?
Esa pregunta me llevó a revisar cómo Dusk describe el recorrido de una transacción. Encontré que el proceso pasa por diferentes etapas: primero puede enviarse y ser admitida para su procesamiento; después puede entrar al mempool, ser incluida en un bloque y ejecutarse. Pero ahí apareció una nueva duda: si una transacción ya fue aceptada, incluida y ejecutada, ¿eso significa necesariamente que el proceso terminó?
Al profundizar en la documentación de Dusk encontré una diferencia que antes no tenía presente: la inclusión y ejecución de una transacción no son lo mismo que su finalización. Un bloque puede avanzar por diferentes estados antes de alcanzar la condición que hace final a ese bloque y a las transacciones que contiene.
Ahí cambió mi forma de mirar una operación. Antes tendía a observar principalmente si una acción había sido enviada y cuál había sido su resultado. Ahora considero más importante identificar exactamente en qué estado se encuentra antes de asumir que el proceso terminó.
Como trader, esta diferencia me parece relevante porque una acción visible no necesariamente representa el final de todo el proceso que existe detrás. En adelante, cuando analice una transacción, no quiero preguntarme solamente si fue aceptada o ejecutada; también quiero saber si realmente alcanzó el estado de finalización.
A veces, entender un resultado exige dejar de mirar solamente dónde terminó la operación y empezar a observar qué tuvo que ocurrir antes para poder considerarla realmente terminada.
@Dusk #dusk $DUSK

#dusk $DUSK @Dusk
トレーダーとして、通常は注文が執行されたときに取引が終わり、その結果を目にすることで完結したと考えています。ところが最近、あまり見えない別の何かについて考え始めました。つまり、その執行の後、市場のさまざまな部分が、何が起きたのかを記録し、認識する必要があるということです。
この疑問から、規制された市場でいくつかのプロセスがどのように組織されているのかを調べました。すると、異なる段階が、記録や振替から決済、レポーティング、そして当該アセットに関連するその他のプロセスに至るまで、さまざまな参加者やシステムに依存し得ることが分かりました。
そこで以前はしなかった問いが浮かびます。同じサイクルに全員が参加しているのなら、「同一の出来事」に関する情報が、それぞれの場所で同じ形で表現されていない場合、何が起きるのでしょうか？
Duskを深く調べる中で、その提案するインフラは、従来は分断されがちだったプロセスを共通のインフラの周りで調整し、切り離された記録を減らし、異なるシステム間での情報照合（リコンサイル）の必要性を抑えることを目指していると分かりました。
しかし、そこでまた、最初の問いを変えさせる出来事がありました。
問題が、取引を正しく執行することだけでなく、すべての参加者が何が起きたのかを一貫した形で認識できるようにすることにもあるのなら、金融取引には、通常は私の画面上では見えてこない側面があります。執行後に、その「履歴（ストーリー）」が一貫性を保てるかどうか、という点です。
トレーダーとして、取引を分析する方法が変わります。これまでは主に、エントリーが執行されたか、価格がどう推移したか、そして結果がどうだったかを問うていました。いまはさらに、その取引を支えるインフラが、異なるプロセスをまたいでいく間に、その状態と結果が首尾一貫して維持されることを可能にしているかどうかを、自分に問えるようになりました。
取引は、最終結果だけでは完全に理解できないのかもしれません。最終結果の背後に残る履歴が、ある段階から次の段階へ移る際にも、一貫した状態で保たれることが重要なのです。
#dusk

#dusk $DUSK @Dusk
取引を文書化するとき、通常は「それを証明する」とは、できるだけ多くの情報を示すことだと思っています。つまり、入力、移動、結果、そして、それが本当に起きたことを確認できるあらゆる要素です。しかし最近になって、何かを証明するのに、必ず取引の全手順を見せる必要があるのだろうか、と考え始めました。
その疑問から、Duskが取引の可視性にどう取り組んでいるかを調べました。すると、異なるモデルを想定したアーキテクチャだと分かります。Moonlightでは送金のデータを可視のままにし、Phoenixではゼロ知識証明によって保護された取引を用います。この後者の場合、取引に含まれる特定の機密データを公開せずに、取引の妥当性を証明できます。@Dusk
そこで浮かんだのは、もうひとつの問いです。もしある取引が、そのすべての詳細を誰もが知っていなくても検証可能なら、具体的な主張を裏づけるために第三者には実際どんな情報が必要なのでしょうか？
さらに深掘りすると、Duskには、規制や監査で特定の情報へのアクセスが求められる際に、viewing keysによる選択的開示の仕組みも用意されていることを見つけました。これにより、以前は同一のものとして扱っていた二つの考えをつなげることができました。つまり、「あることが本当だと確認すること」と「その背後に存在するすべての詳細を知ること」は、必ずしも同じではないということです。
トレーダーとして、取引を文書化する際の考え方が変わりました。以前は、「信頼を得るためにどれだけ見せるべきか」を問うていました。ですが、今私にとってより有用に思える問いは別です。つまり、「どんな主張を証明する必要があり、そのために最小限どんな情報が必要なのか？」です。
もしかすると、最も効率的な透明性とは、すべてを公開するものではなく、「検証が必要とされる部分を正確に確認できる」ようにすることで、残りの情報を不必要な露出に変えないものなのかもしれません。この違いは小さく見えるかもしれませんが、「何かを検証可能な状態にすること」が意味するものの捉え方をかなり変えてくれます。
@Dusk #dusk $DUSK

#dusk $DUSK @Dusk
私が運用していて学んだことの一つは、オペレーションが「すべてが予定どおりに進んだ回数」だけで定義されるわけではないということです。つまり、注文が実行されるべきではないとき、送金がルールを満たさないとき、あるいは起きたことを振り返って見直しを迫られる状況が生じたときの、それらの瞬間も重要です。
それが私を、Duskを調査する中で別の問いへと導きました。すなわち、「通常の経路をたどれないオペレーションを適切に扱うために、金融インフラには何が必要なのか？」という問いです。
Duskのドキュメントでは、規制対象の資産には、送金に関する制御を組み込み、定められたルールを満たさない場合に特定の取引を失敗させることができると分かりました。ですが、それによってさらに別の疑問が生まれました。誤った取引を止めることは一つのことですが、その後に問題が発生し、例外的な状況を解決しなければならないときはどうなるのか？
そこで、Duskが鍵の喪失、詐欺、または資産のルールで求められる特定のアクションなどのケースに対して、回復および是正（remediation）のプロセスも想定していることを見つけました。
そしてそこで、私の市場インフラに対する見方が変わりました。私は当初、「良いインフラとは、取引が正しく実行されることを実現するものだ」と考えていました。でも今では、それに加えて「期待されるフローが機能しなくなったとき、何が起きるのか？」と問いを立てることのほうが、より包括的だと感じています。
トレーダーとしては、それが私の分析の一部を変えます。取引がどのように実行されるかを理解したいだけではなく、「そもそも実行されるべきでないときにどのようなルールが存在するのか」、そして「例外が現れたときにどのようなメカニズムがあるのか」も知りたいのです。
@Dusk #dusk $DUSK

画像の中央に表示されている緑色のグラフを見てください。このラインは、直近3日間の小さなトレーディングの物語を物語っています。8月13日はほぼ0%から始まります。翌日には約0.8%まで進みますが、8月15日には「取引が常に一直線に進むわけではない」という最初のリマインダーが現れます。収益は約0.1%まで後退します。
そこで、私にとってこの物語の面白い部分が始まります。結果が後退するとき、目的は損失を追いかけたり、衝動的に判断したりすることではありません。ポジションを管理し続け、市場が次の動きを明らかにするのを待つことです。そして、まさにそれがグラフから観察できます。あの下落の後、ラインは再び上向きに反転し、期間は約1.55%のところで終わります。
さらに、このスクリーンショットでは、現在11の未決済ポジションが存在することも分かります。一方で、そのうちの1つであるONUSDTは、一時的にマイナスになっています。これにより重要なことが理解できます。個別のポジションは損失を出している一方で、口座全体の推移は前進し続けることがある、という点です。
これは、Evolución del Trader（トレーダーの進化）で記録したいことです。最終結果だけでなく、グラフが描く道のりを残したいのです。なぜなら、各上昇の裏側には、判断・忍耐・学びというプロセスがあるからです。
「絶対に負けない」と言っても信頼は築けません。プロセスを見せることで信頼は築かれます。
#NomadaCripto #Trading #BinanceSquare #Futuros #EvolucionDelTrader

#dusk $DUSK @Dusk
今日、トレーダーとして普段あまりにも単純化しがちなことを考えていました。すなわち、ある資産を買うときに本当に重要なのは、エントリーした価格と、いつ売って降りられるかというタイミングです。しかし、そもそもその資産を「所有する」とは、実際にはどういう意味なのでしょうか？
この問いがきっかけで、私はまだ探索したことのない領域からDuskを調べ始めました。Duskの「デジタル・アセット・サービシング（Digital Asset Servicing）」という提案は、単に「誰がその資産を保有しているか」を記録しておくこと以上のものを含んでいます。そこには、取引の後に発生しうる手続き――例えば、コーポレート・アクション、投資家とのコミュニケーション、そして投票など――も含まれます。
そこでまた別の疑問が浮かびました。取引されたあとに、資産が新たなイベントを生み出す可能性があるとしたら、それらに参加する権利が誰にあるのかは、どのように決まるのでしょうか？
Duskのインフラをさらに深掘りしていくと、所有権の記録は、単に「誰が資産を持っているか」を知るための手段ではないことが分かりました。それはまた、その所有に紐づく権利――たとえば、特定のコーポレート・イベントへの参加権――を認識するための土台にもなり得ます。
そこで、私はポジションの見方を変えました。これまで私は、ポジションを主に「買う」「保有する」「売る」ものとして捉えていました。しかし今は、それを生み出した取引がすでに終わったあとでさえ、そのポジションが権利を生み出しうる「所有の関係」だとも考え始めています。
金融市場において、資産を保有することの本当の意味は、単にそれを売ることにあるのではなく、その資産の保有が、再びイベントを生んだときに可能にするすべてのことにあるのかもしれません。
@Dusk #dusk $DUSK

#dusk $DUSK @Dusk
操作が終わると、通常は結果を見ます。しかし最近、その操作が「完了した」と見なされるために、実際には何がその背後で起きているのかを考え始めました。入力は実行、進化（evolution）、支払い、そして結果へと変わり得ますが、それらの段階のいずれか単体では、すべてのプロセスが最終的にきちんと確定したのはいつなのかを説明できません。

その問いは私を再びDuskへと導きましたが、今回は別の角度からです。Dusk Tradeを調べる中で、ある金融資産は単に「買い」から「売り」へ移るだけではないことが分かりました。そこには、取り込み（incorporation）、適格性（eligibility）、トレーディング、支払いの調整、そして決済（settlement）といったプロセスがあります。そこで次の疑問が生まれました。これほど多くの段階があるなら、最終的に最終状態が本当に確立されることを決めるのは、どの構成要素なのでしょうか？

そこで登場したのがDuskDSです。Duskのアーキテクチャ内におけるその役割を理解したことで、「操作を実行すること」と「その状態を完了させること」が、必ずしも同じではないのだと分かりました。ですがさらに別の疑問も出てきます。アーキテクチャの一部が実行し、別の部分が状態の確立を助けるのだとしたら、どうすれば一連のものはすべて協調して保たれるのでしょうか？

調べを進める中で、異なるレイヤーがそれぞれ異なる機能を担うアーキテクチャにたどり着きました。そしてそこで、私は操作を見る考え方を変えました。これまで私は、主に入力から出力までの「流れ」を考えていました。しかし今は、実行、状態、決済がきちんと噛み合ってこそ、最終的な結果に意味が出るのだと捉え始めています。

この調査を終えた時、Duskがトレーディング操作を何か別のものへ変えるとは思いませんでした。変わったのは、私自身がそれを観察する方法です。見える結果は、はるかに大きなプロセスの最後の一片に過ぎないのかもしれません。
@Dusk #dusk $DUSK

#dusk $DUSK @Dusk
今日のある取引（オペレーション）によって、普段見落としがちなことを考えるようになりました。価格はプロセスの一部にすぎません。取引（オペレーション）には、アクセス、ルール、情報、実行、そして決済（settlement）も関わってきます。Duskを調べたところ、規制された市場向けのインフラは、ある資産を単なるトークンとして扱っていないことが分かりました。Dusk Tradeは、オンボーディング、適格性（eligibility）、トレーディング、支払い、決済を調整しています。すると別の疑問が浮かびました。なぜこれほど多くの機能を分けているのでしょうか。アーキテクチャを学ぶことで、その答えが見えてきました。Duskは実行、決済、そしてアイデンティティを分離しつつ、フローに応じてプライバシーと選択的な開示を組み込んでいます。さらに三つ目の疑問が出てきました。市場が、その情報をすべて公開せずに検証可能である必要がある場合、何が起きるのでしょうか。そこで私は、トレーディングの見方を変えるようなことを理解しました。透明性は必ずしも全面的な露出を意味しません。今、私は取引（オペレーション）を記録するとき、「証明する必要があること」と、「単に利用可能であるために、ただ明かしてしまっているだけのこと」を分けて考えたいと思っています。
@Dusk #dusk $DUSK