I noticed something noteworthy when thinking about splitting Phoenix and Zedger on @Dusk : this is essentially how to resolve an inherent conflict that most other blockchains avoid by choosing only one side—either absolute privacy or absolute transparency—rather than trying to do both at once for two different types of assets within a single transaction.
For most blockchains, a transaction can only have one display mode—either fully public or fully hidden. But a transaction that purchases securities with money is inherently twofold: payment is an arrangement between the buyer and the seller, while ownership of the securities is constrained by a third party—regulators, and limits imposed by the shareholder base.
These two constraints are different even before blockchain technology, so forcing them into a single new privacy model is unreasonable. That’s why Phoenix hides the flow of funds between the two parties, while Zedger maintains the validity of securities ownership under its own independent compliance rule set. DuskDS doesn’t force these two problems into one; instead, it lets each mechanism solve the problem it’s designed for, then synchronizes both payments within the same block.
Self-refutation: even though this architectural complexity is logical, it also means that interaction errors between Phoenix and Zedger are harder to detect than in a system with only one security model— the more interacting components there are, the larger the surface area for logical bugs.
I’m waiting to see whether $DUSK will publish additional audit results on the intersection between Phoenix and Zedger, because this seems to be the most complex and most important area to verify across the entire architecture.
#dusk $BTC $ETH
For most blockchains, a transaction can only have one display mode—either fully public or fully hidden. But a transaction that purchases securities with money is inherently twofold: payment is an arrangement between the buyer and the seller, while ownership of the securities is constrained by a third party—regulators, and limits imposed by the shareholder base.
These two constraints are different even before blockchain technology, so forcing them into a single new privacy model is unreasonable. That’s why Phoenix hides the flow of funds between the two parties, while Zedger maintains the validity of securities ownership under its own independent compliance rule set. DuskDS doesn’t force these two problems into one; instead, it lets each mechanism solve the problem it’s designed for, then synchronizes both payments within the same block.
Self-refutation: even though this architectural complexity is logical, it also means that interaction errors between Phoenix and Zedger are harder to detect than in a system with only one security model— the more interacting components there are, the larger the surface area for logical bugs.
I’m waiting to see whether $DUSK will publish additional audit results on the intersection between Phoenix and Zedger, because this seems to be the most complex and most important area to verify across the entire architecture.
#dusk $BTC $ETH
