単一アカウントの制限と送金の上限は、アカウント形式のライブ位置確認が明確に必要です——特定の保有者はすでに閾値を超えている、ということですか。今この時点で。
投稿
--
Daniyaa
·
--
ブリッシュ#dusk $DUSK @Dusk
私の伯母は、賃貸不動産事業のために2種類の台帳を別々に管理しています――1つは、どの特定ユニットがどのテナントに属しているかを追跡するもの、もう1つは、今月回収した総家賃を追跡するものです。なぜ1冊にまとめないのか聞いたところ、個別の所有と、累計の集計はまったく別の質問に答えるもので、1冊に両方をやらせると両方の答えが信頼できなくなる、と言いました。
私はZedgerがどちらか一方のモデルを選ぶだろうと考えました。しかし、どのようにして両方を組み合わせているのかを関数ごとに追跡すると、その前提は崩れました。
Dusk自身の資料では、Zedgerが具体的にサポートする5つのことが挙げられています。適合する決済と償還、事前承認されたユーザーが1アカウント以上を保有するのを防ぐこと、配当の配布、投票、上限付きの譲渡です。私は、各要求がどのカテゴリに実際に当てはまるのかを整理しました。ソースが十分に具体的で、何を指しているかを特定できたためです。単一アカウントの制限と上限付き譲渡は、アカウント形式のライブなポジション確認――つまり、この特定の保有者は今、しきい値を超えていないか――を明確に必要とします。一方で、配当の配布と投票は、ポジションごとの離散的で監査可能な記録が必要で、UTXOのような個別ノートのトラッキングに近いです。
正直に言うと、Duskの資料には、決済と償還を機械的にどの具体的モデルが扱うのかが明確には書かれていません。リストを完全に見せるためだけに、その仕組みを推測はしません。
どちらのモデル単独でも、私が確認できた機能はすべてカバーできません。アカウントのみのシステムでは、配当の監査のために特定の過去ポジションを証明するのが難しいです。UTXOのみのシステムでは、すべてのノートを同時に確認せずに、ライブな上限を強制するのが難しくなります。
DUSKにとっての本当の試金石は、このハイブリッドが、さらに多くの発行体がその上に独自のしきい値を設定しても、維持可能なままでいられるかどうかです。
2つの会計モデルを組み合わせれば本当に「二重のニーズ」を解決できるのか、それとも、1つの代わりに2セット分のエッジケースを持ち込むだけなのか？
私の伯母は、賃貸不動産事業のために2種類の台帳を別々に管理しています――1つは、どの特定ユニットがどのテナントに属しているかを追跡するもの、もう1つは、今月回収した総家賃を追跡するものです。なぜ1冊にまとめないのか聞いたところ、個別の所有と、累計の集計はまったく別の質問に答えるもので、1冊に両方をやらせると両方の答えが信頼できなくなる、と言いました。
私はZedgerがどちらか一方のモデルを選ぶだろうと考えました。しかし、どのようにして両方を組み合わせているのかを関数ごとに追跡すると、その前提は崩れました。
Dusk自身の資料では、Zedgerが具体的にサポートする5つのことが挙げられています。適合する決済と償還、事前承認されたユーザーが1アカウント以上を保有するのを防ぐこと、配当の配布、投票、上限付きの譲渡です。私は、各要求がどのカテゴリに実際に当てはまるのかを整理しました。ソースが十分に具体的で、何を指しているかを特定できたためです。単一アカウントの制限と上限付き譲渡は、アカウント形式のライブなポジション確認――つまり、この特定の保有者は今、しきい値を超えていないか――を明確に必要とします。一方で、配当の配布と投票は、ポジションごとの離散的で監査可能な記録が必要で、UTXOのような個別ノートのトラッキングに近いです。
正直に言うと、Duskの資料には、決済と償還を機械的にどの具体的モデルが扱うのかが明確には書かれていません。リストを完全に見せるためだけに、その仕組みを推測はしません。
どちらのモデル単独でも、私が確認できた機能はすべてカバーできません。アカウントのみのシステムでは、配当の監査のために特定の過去ポジションを証明するのが難しいです。UTXOのみのシステムでは、すべてのノートを同時に確認せずに、ライブな上限を強制するのが難しくなります。
DUSKにとっての本当の試金石は、このハイブリッドが、さらに多くの発行体がその上に独自のしきい値を設定しても、維持可能なままでいられるかどうかです。
2つの会計モデルを組み合わせれば本当に「二重のニーズ」を解決できるのか、それとも、1つの代わりに2セット分のエッジケースを持ち込むだけなのか？
