#dusk $DUSK @Dusk
Ich ging gerade durch die Transaktionsdokumente von Dusk, als mir ein kleiner Punkt auffiel.
Boreas führte explizite Grenzen ein zwischen einer von einem Client akzeptierten Transaktion, ihrer kanonischen Darstellung und der Version, die im Ledger festgeschrieben wird. Der Grund ist ziemlich einfach: Verschiedene Teile des Netzwerks sollten dieselbe Transaktion nicht unterschiedlich interpretieren.
Dann bemerkte ich etwas Praktischeres in den Austausch-Integrationsdokumenten von Dusk.
Ein Exchange wird explizit angewiesen, eine Einzahlung nicht einfach gutzuschreiben, nur weil sie im Mempool auftauchte, enthalten war oder in einem nicht finalisierten Block akzeptiert wurde. Er muss auf den finalisierten Zustand warten.
Das machte die Änderung von Boreas für mich noch nachvollziehbarer.
Für die finanzielle Infrastruktur bedeutet Konsistenz nicht nur, dass Knoten sich untereinander einig sind. Irgendwann wird daraus ein buchhalterisches Problem: Wann darf ein anderes System ein On-Chain-Ereignis sicher als echt behandeln?
Ich hatte die Transaktions-Lifecycle von dieser Seite her vorher nicht wirklich bedacht. Vielleicht ist der schwierige Teil, finanzielle Aktivitäten on-chain zu bringen, nicht das Aufzeichnen der Transaktion. Es ist zu wissen, genau wann jedes System ihr vertrauen darf.
#Dusk $BTC $DUSK
Ich ging gerade durch die Transaktionsdokumente von Dusk, als mir ein kleiner Punkt auffiel.
Boreas führte explizite Grenzen ein zwischen einer von einem Client akzeptierten Transaktion, ihrer kanonischen Darstellung und der Version, die im Ledger festgeschrieben wird. Der Grund ist ziemlich einfach: Verschiedene Teile des Netzwerks sollten dieselbe Transaktion nicht unterschiedlich interpretieren.
Dann bemerkte ich etwas Praktischeres in den Austausch-Integrationsdokumenten von Dusk.
Ein Exchange wird explizit angewiesen, eine Einzahlung nicht einfach gutzuschreiben, nur weil sie im Mempool auftauchte, enthalten war oder in einem nicht finalisierten Block akzeptiert wurde. Er muss auf den finalisierten Zustand warten.
Das machte die Änderung von Boreas für mich noch nachvollziehbarer.
Für die finanzielle Infrastruktur bedeutet Konsistenz nicht nur, dass Knoten sich untereinander einig sind. Irgendwann wird daraus ein buchhalterisches Problem: Wann darf ein anderes System ein On-Chain-Ereignis sicher als echt behandeln?
Ich hatte die Transaktions-Lifecycle von dieser Seite her vorher nicht wirklich bedacht. Vielleicht ist der schwierige Teil, finanzielle Aktivitäten on-chain zu bringen, nicht das Aufzeichnen der Transaktion. Es ist zu wissen, genau wann jedes System ihr vertrauen darf.
#Dusk $BTC $DUSK
