Interesting idea, reminds me of the design for fractionalized phonons we discussed a while back.
I see a couple ideas combined here actually, there’s a phonon transfer design that uses an account model instead of the current UTXO model. This has the great benefit of not requiring fixed denominations, and saves on storage, since an entire asset can be represented within a single Phonon. The cost of course is a good deal more complexity in the card implementation for Phonon transfers.
The other idea is the “branded” phonons thing, which is an interesting way to validate provenance of an asset I guess.
The branded idea is interesting but I’m not sure how secure the proposed implementation is. My main objection is storing a user generated private key inside a phonon, whereas all phonon private keys within “normal” phonons are generated on card.
It scares me to allow the user to add a private key that was not generated on card, as it opens up new attack vectors whereby a private key that has been duplicated outside of phonon is then inserted into a phonon card and passed off as a genuine phonon key.
I realize the applet logic is supposed to prevent this by locking the descriptor for these assets, but in practice the risks of adding this complexity will bleed over into the existing implementation. Any mistake in this implementation could also blow a hole in the normal Phonon security model.
Also, I don’t think that implementation of branding is optimal for the attestor or the attestee. If the attestor copies their private key into a phonon to prove the origin of an asset, any subsequent leak of that private key invalidates every asset that has ever been “branded” by that key.
Actually I think the card already has an implementation of this that can be adapted for this purpose, and that’s the signature scheme used in Native Phonons. Essentially, the mining card issues a signature using it’s identity private key, which is then trusted by recipients by checking the certificate chain for the CA which the card already trusts.
I propose then, for a “branded” Phonon, the data that should be passed from the issuer is the following:
- A Certificate Authority Public Key (This Certificate represents the trusted identity of the issuer)
- A unique identifier for the account (likely a hash)
- The value of the account at initial creation
- A signature from the CA private key over the unique identifier and value
Now, when two users with assets from this issuer want to transfer them, the counterparties can check each other’s asset’s signatures against the public key they each have in their own certificate. This will also allow them to match up the asset type and increment/decrement the correct balance during their transfers.
The advantage of using hash + signature + cert instead of directly using the private key is that you never have to copy a private key from outside of the Phonon Protocol into the applet, preserving that fundamental property of the security model. I think it also solves some issues in how cards trust each other’s transfers and establish an initial balance but I haven’t thought that all the way through.
Anyway, overall I like the idea, I think it’s super powerful and we should keep it in mind for the future. At the moment I think it requires a lot of additional complexity in the card applet logic especially. Not only is there a new flow for deposit and redeem on this assets, they would require large changes to core card commands like SEND_PHONONS and RECV_PHONONS to handle the account model increment/decrement logic and alternate asset validation. For now I’d prefer to keep the implementation focused on normal Phonons for Beta, as there is already a long way to go on the roadmap to get blockchain backed phonon transfers working securely and smoothly, but I think this is worth revisiting as the basic implementation stabilizes.