[idea] Flexible Phonons

About a month ago, @AndrewB , @rake, @hinchy and I considered the requirements for ECASH. Among them, change without access to the internet stood out as core need for ECASH. Something we cannot do today.

@hinchy and I would like to present to you Flexible Phonons:

The purpose of Flexible Phonons is to make it possible for two parties to settle transactions without the internet, using assets both parties trust, and not relying on a 3rd party to issue change.

Though the inspiration for this construct was ECASH, we believe Flexible Phonons can open up a world of possibilities for the protocol:

  • Gaming: Debiting hit points, armor damage, mana or experience for characters/equipment/stuff in games.
  • Punch Cards: debit coffees, train or bus rides, anything today that has a “loadable card” mechanic
  • Cash: Enabling offline exchange for any currency/medium perceived as backed by a trusted party (governments, banks, credit unions)

Flexible Phonons are designed to use most existing applet functionality. We want them to behave much like any other standard phonon when possible.

How are they different from a standard phonon?

  • They are attested by the issuer/authority on creation. I call this feature “branding” (like branding a cow) because they are marked by their creators upon creation with a stamp that cannot be faked or changed. Read more about Branded Phonons here.
  • Their value is not fixed (like a backed phonon whose asset immutably awaits on chain) but can increment and decrement
  • After being instantiated at creation by the issuer, the value cannot be edited by a user. Instead, the phonon’s value can only be updated by the card itself when making payments.

We have prototyped the design, and have workable code for the ‘repl’. You can play with the code yourself with this PR.

See the Technical Change Summaries in the links above to see what may need to be adjusted in the client and applet to support this implementation.

Also, I’ve submitted this for @deviator and @nate to review, but they’ve been super duper busy getting testnet going (yay) so let’s not bombard them with questions now for a few more weeks :slight_smile:

Excited for the discussion!

3 Likes

The requirement
A requirement from the ECash Bill reads

(7) capable of instantaneous, final, direct, peer-to-peer, offline transactions using secured hardware devices that do not involve or require subsequent or final settlement on or via a common or distributed ledger, or any other additional approval or validation by the United States Government or any other third party payments processing intermediary.

The situation
A shopper has a single phonon representing $5 and wants to buy a $2 item from the store. The store after a busy day only has a single $5 phonon.

With Current Phonon Protocol Features
The store is unable to meet the change requirements. In this situation, the shopper or store would need to use a change making service which breaks the requirement of “direct, peer-to-peer, offline”. One solution to this would be to only issue phonons in the lowest denomination but then we run into card memory limitations when carrying any meaningful value.

With Flexible Phonons
The shopper’s card creates a new phonon, assigns $2 value to it and reduces the value of their $5 phonon to $3. The shopper then sends the new $2 phonon to the store’s card. The store’s card increases their $5 phonon to $7 and deletes the received phonon.

I think of Flexible Phonons as balances on cards that are updated by sending and receiving phonons. It is basically the ERC20 of the Phonon Protocol. I am very excited for this.

1 Like

Below is a condensed/edited version of a discussion I had with Cloak in the discord.

Where is the attesting happening exactly?
A flexible phonon is an extension of a branded phonon. A branded phonon is created by supplying a private key to the applet. The applet derives the public key from the private key and adds it to the phonon’s metadata. Only the applet is able to set this this property so it is guaranteed that only the holder of the private key is able to create phonons with that “brand”. Very similar to how only the owner of the USDC ERC20 contract is able to mint USDC. Phonons with the same brand can be thought of as fungible. Flexible phonons take this a step further and allow phonons with the same brand to be combined and divided. You receive a flexible phonon as you do any other. The only difference is, if you already have a flexible phonon with the same brand on your card, when you receive another the two phonons will be “combined”.

1 Like

This is super cool. I don’t quite get the increment/decrement aspect. Is this trust based from a centralized party?

Hey @mickey , I’m confused by your question.

Short answer: No.

Long answer: see below


First, let’s revisit how Standard Phonons work today:

  • Value and CurrencyType are attributes of a phonon (example: 5 Ethereum)
  • These attributes can be set/updated/changed by anyone who has the phonon in their possession (can change from 5 to 3, or Ethereum to Bitcoin). It’s not common for someone to want/need to change these descriptor attributes, but they can.
  • For a phonon whose Value is 5 and CurrencyType is Ethereum, does it actually have 5 ETH in it? Maybe, maybe not. Depends if the person has loaded it with 5 ETH (on the blockchain). But because it is described as having 5 Ethereum, you expect it to contain 5 ETH, and would validate accordingly (if you had access to the internet)

Flexible Phonons are similar, but with a few adjustments:

  • Value and CurrencyType are also attributes of a flexible phonon. However:
    • CurrencyType will always be equal to Flexible.
    • Value and CurrencyType can only be set when the phonon is created (very unlike a standard phonon). The applet disables the setDescriptor method to work for Flexible phonons. Nobody can adjust these meta data directly after it is created.
  • How does increment/decrement work?
    • Because the applet disables the setDescriptor method on the card for CurrencyTypes = Flexible, It is impossible for Value to be changed directly for flexible phonons.
    • Instead, a new method in the applet handles the transfer of value between Flexible Phonons (you can see how this works in the code we’ve whipped up).
      • Let’s say you have a Flexible Phonon with value 4. And you want to send me 2 value. Here’s what happens:
      • The card will 1) create a new phonon on the fly (with Value 0, CurrencyType Flexible), 2) subtract 2 from your phonon 3) add 2 to the one it created 4) send the other person the newly created phonon.
      • It is impossible for the double spend to happen (i.e. subtract 0, add 2) because this math is accomplished for both phonons inside the same method at the same time. The applet cannot add to a flexible phonon what it has not yet taken away from another.

Trust

Because all of the above is controlled by the card, there is only 1 thing you need to know/trust for Flexible Phonons. And that is the meaning of the public key which is tagged to the Flexible Phonon when it is created. (Reminder, this public key is deduced by the card from the private key the creator gives when creating the phonon.

  • Example: the United States government may use 5 different private keys when creating Flexible Phonons that contain “pennies”. And they may create a million Flexible Phonons with those keys that each contain $5 worth (5000 pennies). This means, anytime you encounter one of those Flexible Phonons (which you identify since they are tagged with the public key for 1 of those 5 private keys used by the US Gov to mint pennies), you can be certain it contains pennies.
  • All you need to “know” to check/verify the authenticity of a Flexible Phonon is the public key used by the guarantor. This can be stored easily in your client. We could explore storing an array of some on the card, but probably not necessary.
1 Like