#dusk $DUSK @Dusk Ich bemerkte das Problem, als eine Überweisung einen Standort passierte und dann einfach am nächsten stehen blieb. Nichts Dramatisches war fehlgeschlagen. Die Wallet war gültig, das Asset legitim, und beide Seiten schienen ihre eigenen Regeln zu befolgen. Der empfangende Standort prüfte lediglich eine neuere Eignungsrichtlinie, als der Absender verwendet hatte. Diese kleine Unstimmigkeit machte die Ausführungs-/Settlement-Geschwindigkeit fast unerheblich. Es musste trotzdem ermittelt werden, welche Regel gilt, ob die bestehende Berechtigung/der Nachweis als vertrauenswürdig angesehen werden kann, und wie viele Anlegerinformationen offengelegt werden sollten, um das aufzuklären. Genau hier wird Dusk schwerer zu bewerten. Selektive Offenlegung kann die Beweismittel eng halten, und deterministisches Settlement kann das Eigentum klarer machen, aber beides sorgt nicht automatisch dafür, dass mehrere Standorte synchron bleiben, wenn Berechtigungen zu unterschiedlichen Zeiten geändert werden. Teilnehmende könnten anfangen, Überweisungen zu verzögern, breitere Offenlegungen anzufordern oder private Ausnahmelisten zu pflegen, nur um sich selbst zu schützen. Das wäre verständlich, könnte aber still und leise die Reconciliation-Ebene wieder aufbauen, die das System eigentlich reduzieren sollte. Mich interessiert weniger, zuzusehen, wie eine weitere saubere Überweisung abgeschlossen wird, als vielmehr zu sehen, was bei einer chaotischen Richtlinienaktualisierung passiert: mehrere Standorte, ausstehende Orders, abgelaufene Anmeldedaten/Zertifikate, vielleicht eine eingefrorene Wallet. Wenn die nicht betroffenen Überweisungen weiterlaufen, während die umstrittene in sich bleibt und nachvollziehbar/auditiert werden kann, würde mir das mehr über Dusk’s Fähigkeit zur Skalierung sagen als irgendeine perfekte Durchsatz-Zahl je könnte.