Async AMA: Technical Questions About the Phonon Network, Interoperability, Scaling and Use Case Feasibility

Technical Discussion
1

This is a series of questions related to the technical underpinnings of the Phonon protocol, as they relate to standard use cases in Web3 and scaling of the network directed to the developers of the Phonon protocol.

Recently, I put together a graphic (see below) outlining some of the common use cases for the Phonon protocol, in preparation for discussion about initial areas of focus.

phonon_product_market_fit
phonon_product_market_fit1082Ă—763 164 KB

The graphic makes several assumptions about the Phonon protocol based on my current understanding of its capabilities and limitations. If possible, I’d like to see if the team could answer some key questions related to these assumptions to determine if they are accurate. Some of these questions cover basic topics, and are included for the benefit of individuals new to the protocol.

Accessing the Network and Trading Phonons

  1. At its core the Phonon network enables secure, private P2P transactions of crypto-assets. Are users required to use hardware (cards, devices, eSIM cards) to create and transfer Phonons P2P?

  2. Does the technical team consider the need for users to acquire hardware/cards to transact a significant barrier to entry? Why or why not?

Creating Phonons

  1. What would be the primary entry points for a user to create Phonons? For example, on the Ethereum network would a purpose-built smart contract be required?

  2. From a privacy perspective, would a smart contract utilized for individuals to create Phonons be easily identified and tracked, influencing the privacy of wallets interacting with it?

  3. While within the Phonon network, transactions are private by default. However, when phonons are converted back to assets on the BTC and ETH chains are these transactions easily identifiable as coming from the Phonon network? Why or why not?

  4. In your minds, what special benefits does transacting on the Phonon network provide that make it superior to existing solutions with a similar feature set?

    For example, individuals using the Incognito network can transact freely between assets cross-chain (as long as they are wrapped/deposited to the network), and these transactions are auditable, but not tied to individual users taking standard precautions (don’t withdraw/deposit large amounts in a short period of time, etc.).


    What additional privacy guarantees does transacting on the Phonon network provide beyond this? Specifically:

    - Entering the Phonon network (creating phonons) is very similar to what is required for other solutions such as Railgun, but “standard” deposit amounts are not required.

    -Transactions on other privacy-centric chains and applications are also invisible, or difficult to track by default. How is transacting on the phonon network superior to those other options from a privacy perspective?

    -Obscuring transaction behavior by making deposits/withdrawals in standard amounts is a core feature of privacy tools such as Tornado Cash. How is the Phonon network superior to options such as Tornado Cash if depositing/withdrawing in “standard” amounts is a common feature?

    -Individuals withdrawing deposits from Tornado Cash, Incognito, Secret Network, etc. must be careful to do so using standard amounts, and transactions exiting the network can be identified and tracked. Is it possible to identify phonon network withdrawals? Why or why not?

  5. Why must Phonons be created in standard increments (e.g., .1 ETH, .5 ETH)? Can phonons be created in arbitrary amounts, such as .12 ETH, etc.? What are the benefits/drawbacks of depositing/withdrawing phonons in non-standard amounts?

Phonon Pooling and “Interoperability”

  1. Is it possible for users to independently create Phonons and then have them aggregated together in a single pool that other users can access?


    Specifically:


    -Alice creates 100 ETH in phonons in 10 ETH batches
    -Bob creates 100 ETH in phonons in 20 ETH batches
    -John creates 8 BTC in phonons in 2 BTC batches
    -Sarah creates 8 BTC in phonons in 1 BTC batches


    Alice and Bobs phonons are aggregated into a pool worth 200 ETH and John and Sarah’s BTC are aggregated into a 16 BTC pool.


    Andrew creates a 10 ETH phonon amount and then trades these phonons for BTC utilizing the phonon network (from John and Sarah’s pool).


    Is this type of pooling and transaction possible utilizing the Phonon network? How would this be achieved technically?

  2. Would Phonons created using different hardware with different certificates not be able to “talk” to or “see” each other? How do we prevent the fragmentation of the phonon network if this is the case?

  3. If phonons cannot be pooled or aggregated would a centralized, highly capitalized “market maker” be required to facilitate transactions on the network? If so, would this be a point of centralization for the network, and a potential privacy risk?

    For example, if a centralized actor, such Circle created the vast majority of USDC Phonons used in a DEX , but required that all transactions using its phonons be tracked by default.

    However, other actors, who don’t have large amounts of capital available, could not pool together their Phonons to create large capital pools on the network that guaranteed private transactions by default. As a result, the majority of USDC transactions on the network are not private and permissioned (only accessible as long as Circle maintains its liquidity and the ability to monitor transactions).

Phonon Network: Building Applications

  1. Lending, borrowing and other financial applications are growing in popularity. How could the Phonon network be used to facilitate the following activities:
  • Borrowing of Phonons of a specific type (say a decentralized stablecoin)
  • Lending of Phonons
  • Generating yield on phonons deposited to the network (if lending and borrowing of phonons is possible
  1. What types of applications do you recommend be developed to that make it easy for individuals to transact using the network in a way that preserves privacy, maximizes security and maximizes accessibility?
2 Likes
2

@davoice321 Wonderful work.

I like how your visual offers a one page, at-a-glance vantage point of the landscape of possibilities. Would you mind making this document available for others to edit?

I’d like to add (or spin off another version/tab, if you’d prefer) a few more columns that connects some additional dots; I want to place other conversations/ideas from the blog and discord in the context of your one pager.

The longer I write - I don’t want to muddy your AMA with my chicken scratch, so I’d opt to create a second tab for you to review/see.

3

thanks. i don’t have a document that’s editable. but in the future i can create one on Google Docs based on the answers to the technical questions.

1 Like
4

Thanks for the graphic, I think this is a useful way to look at some of the capabilities of phonon as pertaining to some of the possible use cases, though I don’t necessarily agree with all of the conclusions in the estimation section. My main sticking point being the idea that pooling liquidity would necessarily be prohibitive with Phonon. Hopefully it becomes clear why that’s the case as I work through the individual questions posed. I’m going to take these a few at a time and come back to answer the rest as time allows me.

Accessing the Network and Trading Phonons

Yes, in general users are required to use secure hardware to use phonon, like the smartcards, eSIM cards, or other secure devices you mention. Since the software running on these devices is securely provisioned and immutable (unchangeable) it allows us to provide guarantees that the software it runs will behave correctly and in a secure fashion.

I say “in general” because I can envision certain ideas where phonon hardware could interact effectively with someone or something outside of the phonon system, utilizing some sort of hybrid between the hardware security guarantee and another form of security guarantee. But that is a nascent idea that is not well fleshed out. The primary uses we’re discussing here require participants to have secure hardware running the phonon applet.

I’d agree it’s a barrier to entry but I don’t think it’s too significant for the protocol to overcome. I believe the cost of a smartcard for instance is less than $10. Relative to the benefits gained by transacting within the system, likely in much greater quantities, this is a small fixed cost.

Of course it presents a bootstrapping problem, but the success of projects like Bitcoin and Helium in my mind show that crypto is uniquely suited to incentivizing early adoption to overcome this “cold start” problem. As well, ideas about making the protocol available on existing hardware like Lattices and phone eSims would be additional ways to obviate the hardware acquisition barrier to entry.

Creating Phonons

For the primary entry point for a phonon is the creation of a private key on phonon hardware, and the subsequent encumbrance of an asset to that private key. This maps most cleanly onto a UTXO based system like Bitcoin, where there is a one to one correspondence between an address, an amount, and a private key. In this case, you create any number of phonons, derive their BTC addresses from the public keys, and then send the desired amount of bitcoin to each address you derived. The phonon card’s keys now control access to these UTXO’s, and so this BTC now exists as phonons.

For the example of Ethereum, you can do the same thing with balances assigned to multiple “accounts,” each controlled by private keys, but it may be helpful to use a smart contract to do something a little more complex in order to reduce the cost of doing a send for each phonon creation, given how gas prices are now. This hasn’t been totally worked out, but I think it should be possible to write a smart contract to do some internal bookkeeping of existing phonons in order to track their creation and redemption through the smart contract, and reduce the overall costs of entry and exit to the system.

Of course, I think it’s also worth considering this topology relative to where costs are going in light of L2s and shifting usage as blockchain scaling is worked out across the industry. We may want to “skate to where the puck is going” so to speak.

I think there would be some privacy consequences to think through of using a smart contract as an entry/exit, but it would not inherently identify users. Since a phonon can be infinitely transferred from card to card once it’s entered the system, the redeemer of a phonon would not necessarily be the same as the creator, so that breaks any identifying link on the way out of the system. In fact there’s no reason withdrawals couldn’t be done to a completely fresh address. The privacy consequences here are in the scope of account creation on the redeeming blockchain.

For the BTC example I gave above, ETH in the UTXO style, or any other UTXO chain, phonon creations and redemptions would look identical on chain to any other type of transaction. Just normal addresses with normal transfers submitted on chain, the only difference being that the encumbering private keys for these assets may be transferred off chain through phonon during these asset’s lifetime as phonons.

This is why Karl is fond of saying Phonon sidechannels privacy onto existing blockchain. There is now a plausible chance that due to phonon, a UTXO does not have the same owner during the time it sits on the ledger.

Introducing a smart contract with phonon specific functionality would necessarily identify that assets going in and out of that contract are likely to be phonons, but perhaps there is a creative way around this.

I’m going to skip #4 for right now and come back to it as there are several questions wrapped up in there and it seems I’ll need to do some research on some of the other protocols to give a proper reply, though I am interested in seeing how these compare.

Phonons can be created in arbitrary amounts, yes. The important point is that each phonon must be a discrete amount, since it is a private key represented by a single address on the blockchain that is static throughout the life of the phonon. (although interestingly, due to the way UTXOs work, one could add to a phonon’s value after creation, but not reduce it. I haven’t thought of a good application for this fact yet, so thus far I consider it inconsequential.)

The theory is that standard amounts would likely be the best way to transact within the system, since they allow for parties to establish conventions for standard exchange amounts, or to build up whatever value they actually want to transact from several granular phonons, like adding up bills and coins to the amount of the price.

I think this is likely to be a convention that gets worked out as we get more practical experience with the system, and it is also an implementation detail that could be abstracted away within the phonon-client. Users could simply deal with account balances and the client could perform the calculation and estimation behind the scenes to accomplish user goals with combinations of discrete values.

Thanks for the questions, and I’ll come back to answer the rest of the sections.

3 Likes
5

Appreciate these answers! I’m looking forward ro the rest, including insights about pooling phonons.

6

Yes I believe so. The best way to accomplish this is an open question and a green field design space. Let me just point out up front that the best way to build a “DEX” with Phonon may not look like the way you’d build a DEX on a blockchain or the way an exchange is designed in traditional finance, since the base capabilities are quite different.

Here’s a couple ideas on how this could work, just to illustrate. A service could be developed or functionality could be added to the client to allow users to broadcast the list of phonons they are willing to exchange and what conditions they are willing to exchange them under. (The pair assets, price, etc.) This could be 100 1 ETH phonons or 10 100 ETH phonons or any other combination.

Another user who wants to take the other side of the trade can then offer the pair asset in an acceptable quantity, and the two clients will communicate to make the phonon exchange between the cards. Behind the scenes this may involve any combination of individual phonons in order to fulfill the proper trade amounts, the math can all be done in software.

A further elaboration on this idea would allow for the service to aggregate order listings between multiple user’s posted assets to form larger “pools” that other users can interact with. The service could then handle orchestrating exchanges between these multiple users, possibly including things like multi-asset hops, in order to fulfill the order for the initiating user.

This is just the first naive design that occurs to me. I wouldn’t be surprised at all if there are much more clever designs that deliver greater efficiency and decentralization.

Phonons created using different hardware would be interoperable, for example SIMs talking to cards talking to lattice’s. No problem there, as the trust between devices is maintained by the certificate system.

Phonon hardware using different certificates may be compatible or incompatible depending on how the certificates are issued. Compatibility between multiple issuers would work fine as long as those issuers have agreed to each trust each other’s certificate signing keys. However, if someone were to fork the applet and start signing it with a rogue key, those cards would not be trusted by the legitimate cards within the network. This is a feature that guarantees the security of the protocol’s operation and protects it from potential malicious card issuers.

I think I covered above that phonons could in fact be aggregated among individual users above, but it would also be possible to build centralized services involving a market maker if it was so desired. But yes, that would involve more privacy risks and I’m doubtful it would be the best way to implement exchanges on Phonon, though it might be the simplest to implement.

7

thanks for this clarification . this (developing this capability) is something that i’d like to explore via the working group as a priority – from a feasibility and speed to execution perspective.

1 Like
8

This is really fascinating, thank you for sharing! I can think of several used cases off the top of my head - automated rebalancing, tax loss harvesting, dollar cost averaging, resource allocation for treasury and token distribution.

I know in the early days of Helium, some developers were creating HNT miners off a raspberry pi. Is the Lattice truly unhackable or could this also occur in the early stages of the PhononDAO?

9

I’d like to see a new graphic similar to the first one but with updated info based on the AMAs. The first graphic, at least to me, seems to undersell and underestimate Phonon’s capabilities, and I don’t really want to be sending that message.

10

The graphic was meant to illustrate questions about