A common discussion topic in our community is how to reduce counterparty risk when exchanging phonons. “Locked Phonons” is a simple mechanism that I believe can be leveraged to build a user flow that makes it economically expensive for a party to not uphold their part of an agreed phonon exchange. While this is the first specification I have seen that achieves this goal without involving third party escrow services, I am sure there are many improvements that can be made. I hope this post will lead to improvements on my design or spark discussion and ideas that lead to a better solution.
What is a locked phonon?
A locked phonon is a phonon that can not be redeemed and can only be transferred to an assigned recipient or not transferred at all. If a locked phonon is sent to its assigned recipient it keeps these properties on the recipient’s card. They can be unlocked by providing a signature from one of two parties; an attester or, if you received the locked phonon, the phonon card that sent it to you. An attester can be any entity that can provide a signed message. The Protocol is agnostic to who or what the attester is and it is up to the user locking the phonon to decide.
Locked phonons in action
Bob and Alice agree to trade a phonon each. Both have shared the public keys of the phonons they are trading and have validated the other’s phonon has the asset they wish to acquire.
Bob and Alice decide on the attester they wish to use. This might be a service built into their wallets or the service they found each other on (decentralized exchange book).
Bob and Alice generate a unique nonce for their trade. It is in both their best interests to generate a nonce that is unique. The attester might have a recommended format for the nonce. The nonce can also include parameters about the trade such as how long each user has to complete their part of the trade. In this case a nonce is created with each of their card’s public keys, the public keys of the phonons they are exchanging, the current time and agreement that each party has 5 minutes to complete each step.
Both Alice and Bob lock their respective phonon by passing in the agreed upon nonce, the attester’s public key and the other party’s card’s public key. Their cards return a “proof of lock”, a signed message proving their phonons are locked.
Each sends their “proof of lock” to the other and validates the proof they receive. They need to ensure the proof contains the nonce, recipient public key and phonon public key they expect and ensure the signature comes from a valid phonon card.
Each constructs a phonon transfer packet which the other party consumes. Both parties now have the phonons they want but they are still locked. Consuming the transfer packet returns an “unlock” signed message that can be used to unlock the phonon on the other party’s card.
Both Alice and Bob share their “unlock” signed messages completing the trade.
The above describes the happy path. At certain steps along the way either party can fail to complete their side of the trade.
At step 4, if either party fails to lock their phonon (or signal that their phonon was locked), the party that had completed the lock can contact the attester requesting a signed message to unlock their phonon. The attester will wait for the agreed amount of time before completing the request. No economic harm has come to Alice or Bob.
At step 6, if either party fails to send their phonon, the complaining party can send their transaction packet to the attester proving that they have completed their side of the trade and the attester shouldn’t process any requests from the other party for an unlock signature. In this situation both parties have lost access to their respective phonon. 100% economic harm.
At step 7, if a party has received their phonon but hasn’t received their “unlock” code from the recipient they can prove they have sent their packet by supplying it to the attester. It is safe for the attester to issue an unlock signature.
Closing thoughts
This design keeps phonon exchanges peer-to-peer by only involving a third party attestor if one party isn’t behaving as they should.
Both parties take on equal risk as either there is no economic loss or equal economic loss. Griefing attacks are possible but it will cost the attacker the same value they are causing the other party to lose (assuming phonons being exchanged are of equal value).
An attester service could be a decentralized network
An attester service could charge for its services
An attester service could ban misbehaving cards increasing the cost of griefing attacks.
I have a created a demo locked phonon in a high level mock phonon card here.
This is cool, I have some dumb questions, thought id put them here so everyone can learn.
Let’s say you and I decide to trade phonons, and we are both good actors. We agree to exchange my Phonon of a GOAT NFT and your Phonon of 1,000 BTC.
Im putting numbers in each step just so if/when im wrong about anything its easier to point out where Im fucking up. OK……
I share the public key of my phonon showing i have my Phonon God Goat NFT, and you show your public key of a Phonon loaded with 1,000 BTC.
Both the Public Key’s have the correct assets inside.
We want to use an attestor service, sort of like an escrow service, so that I can exchange this sick Goat NFT for your BTC.
We select the JT Kansas City Beef attestation service who charges a small fee in native phonons.
Assuming JT’s service works, it validates the public key with the private keys of both Phonons in both of our cars.
This part I’m a little confused, both cards need to generate a nonce to ensure the cards can pair? (So that nobody else can send a request for that Goat NFT, or your ETH? And that nonce gets generated from the PUF or does that get generated by the attestation service?
The Nonce is like agreeing to/signing an escrow contract, Mickey has this GOAT NFT and will send it only to Hinchy if and only if Hinchy agrees to send 1,000BTC only to Mickey. Both parties have the next 60 seconds to send the phonons to each other, and cant do anything else with the phonons for that agreed upon period of time in this nonce.
We’ve generated a nonce, we then share it with each other to prove I am still me and you are still you and we both have everything we have agreed to have to make the trade.
The phonon javacard applet receives and confirms the nonce and issues another nonce back to the attestation service, which is proof of the phonons being locked for this business purpose.
This part I don’t quite get, they send a phonon transfer packet, is this the NFT + BTC respectively, + a proof of receipt which allows you to access the phonon after both parties receive it?
Both parties send the proof of receipt, and now they can open and access the phonon, Mickey now has 1,000 BTC and Hinchy has the worlds most valuable Goat NFT.
Not quite. An attester service doesn’t need to verify the phonons because Phonon Protocol users are able to verify this themselves. A card is able to prove it holds a phonon and that it is a valid phonon card. With these two proofs there is no need for outside verification.
yeah, the nonce is confusing. I got myself a bit muddled a few times while working through the flow. Firstly, the users decide on the nonce, they are not generated on the cards or by the attester. The nonce is basically acting as a unique identifier for the trade. It could be generated on our card but that involves a lot of backwards and forwards (slow) and adds complexity to The Protocol. This is why I am suggesting it is done externally to The Protocol and it is up to the users (or their wallets) to ensure it is secure.
Imagine a situation where there wasn’t a nonce and you and I swapped the same two phonons back and forth a few times. Without a nonce I could use an unlock signature from a previous swap to unlock the phonon during an active swap. A user just need to make sure it is something unique to ensure their counterparty can’t use the same nonce in the future.
The phonons are locked indefinitely until either the attester service or the counterparty agrees to unlock. The nonce is also used as a proof that the phonon has been locked. If you were swapping the same phonon backwards and forwards, without a nonce you could show me a proof that the phonon is locked from a previous swap. I would say once both parties have locked their phonons and shown proofs to each other the swap is “locked in”.
Could you expand on this? I don’t quite understand.
So the attester only needs to get involved if one of the parties isn’t acting as they should. Each step (locking, sending the phonon, consuming the phonon, unlocking the phonon) is provable. If for some reason one user does not act as they should the other can provide proof of what stage the swap is at. If the counterparty doesn’t respond with a proof that they are acting in good faith then the attester can unlock the complainers phonon. Each attester can have its own rules and resolution processes. It is very flexible.
I feel safe sending you my phonon knowing you can only send the NFT phonon to me. I also have very high confidence you will send the NFT to me because if you don’t your BTC phonon is worthless to you as the attester (if it is a good actor) wont unlock it for you. So after we exchange phonons there is an extra step where we provide each other the “unlock code” for the phonon we sent.
Always wanted a goat NFT.
Let me know if this hasn’t explained any aspect of it because I’m sure other people will have similar questions. I’ll try and knock together a diagram explaining the steps as well.
i swear to god
y’all manage to pick on bits and pieces of the stuff i somehow dream up - 2-3weeks later :
“locked phonons”
(Full Disclosure: I’ve just skimmed thru this but im 98.65% certain this was me)
Question: Why are bob and alice transacting directly with the asset (which, by definition means we’ve loaded it with complexity, storage and memory) - wouldn’t it be easier if the design was implemented with a ‘destructive phonon’ (which is only destroyed after both parties manage to sign the Mirrored Asset)
When the mirrored asset is destroyed it then calls upon a split of the Desired Asset.
Also, i hate the name.
Can we call it
Doppleganger (Mirrored) or AlterEgo.
(You know…something fun - just for the sake of variety )
)