Why Tokens Don't Work Using Private Transactions

A token economy with privacy is a popular use case in the enterprise space. For CBDCs (Central Bank based Digital Currency), carbon trading, and many other scenarios involving payments or settlements, token is a very useful construct. Most of these use cases involve participants that represent organizations and commercial entities that compete with each other in their industries. As a result, not disclosing each other’s balances and trading patterns is a fundamental requirement.

Properly addressing privacy in a token implementation is a topic that requires in-depth discussions, which is beyond the scope of this blog. What we’d like to focus on is how NOT to implement a token contract.

Private transaction is a concept that has been implemented by multiple blockchain protocols. Quorum and Hyperledger Besu are able to work with a private transaction manager called Tessera. Hyperledger Fabric supports the same private transaction pattern with chaincode private collections.

Private Transaction in a Token Economy

Private transaction allows a subset of participants in a blockchain network to maintain a separate world state from the world state that is globally shared among all the participants of the blockchain. Only the participants privy to the transaction are able to execute the transaction and update the state, while those not privy to the transaction do not update the state.

This approach has usage in many scenarios, mainly when transactions are by and large independent of each other. For instance, in a global trade network, one trade is independent from another. One private transaction can be carried out between party A and party B, while another private transaction can be carried out between party A and party C. The result is that at the end of the two trades, party B and party C will have different views to the current state that party A is in.

Because there are no interdependencies between these trades, the fact that party B and party C will have different views to the state of party A is not an issue. Using private transactions in such scenarios is a great approach to achieve privacy.

On the other hand, private transactions do not work in a token economy.

All token implementations require a shared global view. For fungible tokens, such as ERC20 tokens, this means all parties must be able to verify that mass conservation is always achieved with every transaction. For non-fungible tokens, such as ERC721 tokens, a shared global view is required so that all parties are able to verify that each token is globally unique.

This runs contrary to the fact that private transactions result in different parties having different views of the global state.

Let's look at an example

The following example will illustrate the problem with using private transactions to implement a token economy.

Imagine a blockchain network of 3 parties: A, B and C. A fungible token has been implemented with a standard ERC20 contract. The illustration is based on Ethereum. Hyperledger Fabric will be slightly different in the exact mechanism with chaincode private collections but the concept is identical.

v0[A,B,C]: A=1000, B=0, C=0

v1[A,B]: A=900, B=100, C=0

v1[A,B]: A=900, B=100, C=0
          |
          | B transfers 50 to C
          |
v2[B,C]: A=900, B=50, C=50

v0[A,B,C]: A=1000, B=0, C=0
          |
          | B transfers 50 to C
          |
Failed with error: transfer amount exceeds balance

This transaction failed on party C’s node because B had a starting balance of 0, and attempted to transfer 50.

The entire flow is illustrated in the following diagram:

‍

‍

‍

INFO [06-16|03:41:33.497] VM returned with error                   err="execution reverted"
DEBUG[06-16|03:41:33.497] Executing EVM call finished              runtime="268.317 µs"
WARN [06-16|03:41:33.497] Served eth_call                          conn=127.0.0.1:60506    reqid=9         t="403.363 µs" err="execution reverted: ERC20: transfer amount exceeds balance" errdata=0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002645524332303a207472616e7366657220616d6f756e7420657863656564732062616c616e63650000000000000000000000000000000000000000000000000000

The above error message confirms that the reason the same transaction succeeded on party B node but failed on party C was because party C’s starting state has balance 0, as illustrated above.

Protection Against Private State Divergence

Private state divergence as demonstrated above can cause many types of issues. To protect against this, the developer can make use of these features:

• privacy groups, which ensures that private transactions targeting a group are always sent to all the members of the group. Both Quorum and Hyperledger Besu support privacy groups.
• private state protection, which requires all private transactions targeting a private contract to always include all the original members that the contract deployment specifies

Note that in both cases, while the private state integrity is maintained within the subset of the participants, the end result is that all the members of the private contract share the same private state (as in, everybody knows everybody’s balances and transactions). In the case of a token implementation that requires privacy, the privacy requirement is not fulfilled.

Summary

In summary, while private transactions work well for use cases that involve “one-off” transactions, or transactions that do not modify any globally shared states, they can not be used to implement tokens.

Tokens that need privacy must utilize advanced technologies such as zero knowledge proof. This is still an actively advancing technology, with promising implementations including EY’s Nightfall 3 confidential tokens. As with any technologies involving advanced cryptography, it takes time and effort to prove the correctness of the algorithm and security of the implementation.

On the other hand, if your blockchain project requires privacy, check out Hyperledger FireFly. It takes inspiration from the private transactions pattern to provide privacy while giving a whole lot more flexibility to developers in terms of how to implement the transaction processing logic.