All,
I stumbled upon the very first write-up I put together recently on Phonon (previously referred to as Dcash). This document was original used for internal communications and discussions. This was last modified 09/04/2018. I am putting it here as an interesting piece of the Phonon history, but also as a reference for people to read that may spur understanding of my thinking (although some is out of date) as well as inspire new ideas. I am providing the text as well as the link in case people don’t like word docs 
.
Introduction
Cryptocurrencies which are based on distributed peer-to-peer systems for transacting value are becoming more and more ubiquitous. Unfortunately, there are severe limitations in the ability to increase the number of transactions per second that a blockchain system is able to process. This has to due to limitations in the ability of a truly distributed system being able to come to consensus on a consistent set of transactions in a short period of time without a central authority. Unfortunately, the introduction of any sort of central authority leaves the blockchain prone to attack and corruption. Although, there are some examples of centralized blockchains, such as ripple, it is emergently apparent that centralization is not the market preferred mechanism of scaling. Here we propose a new system that will allow transactions to happen without a central authority off the blockchain. By allowing transactions to happen off the blockchain, the number of transactions that can be processed will be able to scale with the number of users. This creates a scalable system which will allow current blockchain systems to realize several orders of magnitude increases in the effective number of transactions which they are able to process. The disclosed method of making transactions off chain is referred to as dcash.
Summary
Dcash uses a series of smart cards which have unique keys provisioned to each of the cards. Ideally these keys will take the form of a physically stored secret such as a physically unclonable function (PUF). The cards at the time of manufacture will be issued a unique cryptographically signed certificate for the cards specific private key by the manufacturer of the smart card. This signed certificate can be used by the smart card in a challenge response way to prove who manufactured it. This will also allow other smart cards to verify counter-party smart cards origin. The smart cards will be loaded with firmware which is cryptographically signed by the manufacturer, verifiable by counterparty cards, and will enforce the double spend rules common in blockchains. The enforcement of the double spend rules by the smart cards allows the users to move the trust of settlement from the consensus mechanism of the blockchain to the hardware/firmware loaded on the smart cards. Once there is a high degree of confidence that the smart cards will behave in such a way to enforce blockchain transaction rules, different forms of blockchain assets can be passed from card to card atomically without interacting with the blockchain. Users will be able to load assets from the blockchain, as well as send assets back to the blockchain which have accumulated on a smart card. The assets that are loaded on the card will become bearer assets in the fact that they will not be able to be backed up, and possession of the singular card will be possession of the asset.
Detailed description
Key Model
Scarce tradable assets know as tokens or cryptocurrencies exist on blockchains. The ability to move these assets from one account to another denotes the ability of a user to spend funds and therefore is possession of those funds. Typically, a transaction is initiated by signing a message which indicates the movement of funds from one account to another account with the private key of the originating account. If the account has sufficient funds, and the signature and of a validly constructed message is made, the nodes of the blockchain will process the transaction and funds will be transferred in the ledger to the receiving account. In this context, the private key that is used to sign transactions represents the assets on the blockchain. Hypothetically, the smart cards could pass individual private keys from one card to another card. The recipient card would be willing to accept the private key as payment because they will be able to check the corresponding account balance on the chain and will be able to verify the origin and function of the counter party smart card. The recipient smart card trusts that the counterpart card will permanently delete the key they are passing and that no other copy of that key exists. The key itself is the bearer asset. One downside of passing keys is that permanently deleting keys is not compatible with PUFs. Therefore, in this context, the key would have to be stored as a string in memory on the smart card. Storing a key in memory is less secure than storing a key using a PUF. This could be addressed somewhat by using a hierarchical deterministic (HD) wallet. A HD wallet creates many address from a seed address using a deterministic process. An example of this is outlined in Bitcoin improvement proposal (BIP) 39? The PUF could be used as the seed and children addresses could be created using the HD process. However, proving that an address comes from the seed key to which the manufacturer certificate is issued would be difficult. Therefore, although many addresses and passable keys could be created, the ability of a counter-party to verify that they are accepting funds from a “good” card would be difficult if not impossible.
UTXO (Bill) Model
In another scenario, the originating smart card could create a UTXO which encumbers founds by a hash. The UTXO could be created on the card on the fly without interacting with the blockchain. The recipient card would then receive the UTXO as well as the hash-preimage which can be used to unencumber the funds locked by the UTXO. The recipient card will be able to validate that the paying card is creating the UTXO from an account which has sufficient funds to cover the payment. When the receiving card wants to redeem the UTXO, they can first broadcast the UTXO to chain and then create a transaction redeeming that UTXO to an account of their choosing by presenting the hash pre-image. If the receiving card wants to further spend the UTXO as dcash prior to spending on chain, they can present the UTXO as a bearer asset to the next card in the chain. The receiving card can verify that the UTXO is redeemable onchain and accept it as a method of settlement with the redeeming hash pre-image. In the context of dcash, the UTXOs can be thought of as analogous to a paper bill. They will typically have a non-trivial value, and each one will be redeemed in an individually processed and verified transaction when redeeming them on the blockchain. The advantage of UTXO based asset trading over private key trading is that a card can hypothecate UTXOs as needed when needed. Also, the recipient of a UTXO can verify that the UTXO is able to be redeemed by making a simple read query to the blockchain. The risk of double spend of a UTXO if the smart card system is hacked is localized to the value of any singular UTXO. The drawbacks of this system is that each UTXO will have to pay a non-trivial fee when getting redeemed on the blockchain. This sets a lower limit on the value of a UTXO which will be practical. For example, if current processing fees for a transaction are $0.05 and a UTXO is worth a dollar, that may make sense for some users, but if say the UTXO was worth $0.10 the transaction fee becomes a significant portion of the UTXO value making them less practical.
Transaction ID Model
In yet another scenario, the card could be loaded with an initial balance corresponding to a transaction into the cards address on the blockchain. The card could verify the balance by being given a copy of the loading transaction including the transaction ID and transaction hash. The loading transaction would be to the account on the smart card via a smart contract which services loading of a specific manufacturers smart cards or general group of smart cards. The card will then know that it has a certain amount of a certain asset that came from a specific transaction ID. It is very difficult to verify what that specific asset is because of the nature of blockchains. For example, Bitcoin is defined as the blockchain which has the most work on top of the genesis block created by Satoshi Nakomoto in 2009. However, there have been many forks in the bitcoin blockchain and there a different assets that look very similar such as Bitcoin Cash unless the card or user can holistically verify the asset by be informed of which chain they consider Bitcoin. Therefore, instead of attempting to create a proof of what the asset is, the transaction ID is passed to the receiving counter-party card and they can verify that the transaction ID that funded the balance on the paying card is indeed present on the blockchain which they think it is. Once that is verified by the receiving card, they could take payment from the paying card by incrementing a balance against the transaction ID (and asset) and the paying card would simultaneously decrement its balance the corresponding amount. To redeem funds back to the blockchain, the card could sign a transaction with its private key, present the certificate showing the validity of the card, as well as a request to redeem an amount to an on-chain account via the smart contract. The smart contract would check the certificate, the signature of the request, as well as verify the existence of the underlying transaction IDs, and that the total request is smaller than the balance of the corresponding IDs. In some ways this is similar to the UTXO, but rather than having to process each transaction individually, amounts that correspond to a single asset type can be aggregated together when they are redeemed which will allow the redemption process to be cheaper. The lowering of cost and the fact that there is less specific identification of each individual asset in that they are treated as account balances rather than specific assets makes this method more like change rather than bills. The attack surface of the change is higher because a double spend could affect more than one specific transaction, but rather could negatively influence the balance of the gateway smart contract account. The downside of this process is although balances can be added, each contributing transaction ID will need to be checked which will make on chain redemption more expensive. Additionally, there is limited storage space on the smart cards so they will only be able to hold a finite number of transaction IDs before having to be settled to chain.
Authority Model
Another alternate implementation of the above would be to require the loading transaction to be signed by the card issuing authority or be made from a specific account. This would prove to subsequent cards which assets are loaded on the card to the point that they trust the loading authority. This means that the counter-party cards would no longer need to verify the existence of a UTXO or transaction ID. Rather when a card is loaded, the payee card knows that the balance comes from the asset that the loading authority says it is. When a counterparty is taking payment, they can request they are only paid in assets which have been loaded by authorities that they trust. The payee card can verify that the payer card respects the request by inspecting the signed certificate issued with the card. Cards could be configured to accept attestations by multiple authorities by adding the public key of those authorities to the card. If an authority becomes nefarious, the user can remove the key from their card for future transactions. This will create an incentive for loading authorities to do a “good” job as a single infraction or misuse of the loading private key will decimate an authorities business. In this manifestation, a payer card would simply present the signature from the loading authority that was used to initialize the card balance to the payee card to prove appropriate asset type. When a user wants to redeem assets on chain, they can present the loading authorities signature to the corresponding smart contract, a valid card certificate, as well as a signed request to move funds corresponding to the certificate. Unlike, the system that uses transaction IDs to determine asset types, there will likely be far fewer prevalent loading authorities so the number of transactions that need to be verified should be limited to the number of authorities used which could be low as 1 even with thousands of transactions with thousands of counter parties.
Proof and Stochastic Model
If users do not want to trust an authority, they cannot create fungible assets because each Transaction ID or UTXO is unique and specific. It is always up to the payee to verify the payer is settle in an asset that they are comfortable with by making a read of on-chain data. An alternate approach is to use a proof as well as a set of rules or models that are descriptive of specific assets such that a card can verify the asset generally without having to make an on-chain read of data. A proof would be a set of hashes that demonstrate that a transaction was included in a block that had a certain amount of work performed on that transaction after it was made as well as enough information about the past that the underlying asset is verifiable by its correspondence with the model. If a proof is made in a completely uncompressed way, the proof of the transaction would be an up to date copy of the underlying blockchain. Proofs can be made using interlinking hashes which allow the compression of the required proof. The model describes characteristics of the blockchain in concise form which may including rate of work, block time, number of transactions per block, as well as historic checkpoints. Based on the character of the transaction and associated proof, the underlying asset for the funding transaction can be ascertained with a high degree of confidence by comparing the proof to the model. The payer card can have a list of acceptable proofs that are used to ascertain a funding transactions underlying asset. During payment, the payer card would provide information about the model that was used to verify the proof, and the payee card could decide to accept payment or not based on the confidence that it has in the proving model. In the context of a single smart contract which gateways the funding transactions for all cards, only models that are acceptable to the smart contract would be acceptable by another card. The models which are acceptable to the smart contract would be deployed in the smart contract and may also be signed by the card issuing entity.
Transaction Steps
- Establish a secure communication channel between cards.
a. Card (a) sends its public key to card (b)
b. Card (b) encrypts its public key and salt with card (a) public key
c. Card (a) receives and decrypts card (b) public key and salt
d. Card (a) encrypts the salt with cards (b) public key
e. Card (b) decrypts and verifies the salt is correct
Assume all communications are encrypted before transmission following this step
- Both cards establish trusted provenance of counter-party card
a. Card (a) sends a message indicating the manufacturer, and its public key/account, which is signed by the card manufacturer to card (b)
b. Card (b) uses the manufacturers public key to verify that the public key of card (b) was indeed signed by the manufacturer
c. Card (b) acknowledges to card (a) it has acceptable provenance and also sends card (a) a message indicating the manufacturer, and its public key/account, which is signed by the card manufacturer to card (a)
d. Card (a) acknowledges card (b) provenance - Card (b) makes a request for payment from card (a) including requested asset type and amount
Assume one of the above models is used
- Card (a) provides the appropriate information to card (b) to allow card (b) to verify the asset being used for settlement
- Card (a) requests salt from card (b)
- Card (b) provides salt to card (a) to use in the transaction
- Card (a) constructs a message containing the settlement information, salts and encrypts
- Card (a) adjusts the internal balances and/or deletes the assets being sent for settlement
- Card (a) sends the settlement information to card (b)
- Card (b) verifies the salt and then stores the settlement and adjusts balances accordingly
If a transaction is interrupted after the formation of the settlement, the funds that are being sent between cards will be lost. This is important to ensure that the transaction transiting between the two cards can’t be replayed.
Loading Transactions
In the UTXO model the process of loading a transaction onto a card is quite simple.
- User makes an on-chain transaction to the public key of a card.
- The card is connected to a device which sends it the transaction ID as well as the transaction details.
- The card will then have a usable UTXO that it can used which is associated with the transaction ID. To spend the money from the loaded UTXO, the card creates a transaction from this UTXO encumbered by a hash lock. (e.g. <OP_DUP><OP_SHA256><OP_EQUAL> )
- The card would then pass this signed transaction and pre-image to the payee card.
- The payee card could then subsequently spend this “bill” with the next card or redeem it back to the blockchain at some time in the future.
In the authority model, the loading of a transaction onto a card would be as follows:
- The user would make a transaction to the authority run account.
- The authority would make an outgoing transaction from the authority account to the user indicated valid smart card account.
- The card is connected to a device which transmits the signed transaction to the card.
- The card checks that the loading transaction originated from an authority it trusts based on a public key that is already on the card corresponding to the authority.
- The card then initializes the balance for the asset type indicated by the authority to the amount of the loaded transaction.
- When subsequent transactions are made, only the signed transaction initializing the balance needs to be shared to verify asset type with a counter-party card.
- Balances are incremented and decremented as assets are exchanged between cards.
- Balances are redeemed by making signed requests to the authority or to an authority created smart contract.