Details

Advances in cryptography and decentralized trust are disrupting the world’s financial systems. Financial institutions and central banks are actively exploring Central Bank Digital Currencies (CBDC) and new forms of digital cash. The transformation from physical money to digital cash raises several challenges. One has to balance the needs of privacy with the needs of trust, security, accountability, and auditability. These solutions need to provide a scalable, interoperable, and inclusive infrastructure that can support the demanding requirements of 21st century democratic economies.

Digital cash should be better than physical cash. It should provide better trust, better trade-off between privacy and accountability, and better performance. Our VMware research technology preview is by no means a complete solution for digital cash. Our goal is to expose partners, technologists, policymakers, and the public to core ideas that we believe will be essential to future digital currency solutions. We hope this will help contribute to a global dialogue towards the future of digital cash and central bank digital currencies. Our system for Digital Cash is designed to highlight three properties: trust, accountable privacy, and performance.

1. Trust: Physical cash often contains physical protections that make it hard to double spend and counterfeit. We envision systems that are operated by licensed, supervised, established, and highly regulated parties. For digital cash, we use threshold cryptography and Byzantine Fault Tolerance to provide the highest possible guarantees for safety and liveness. Safety is the resilience against double spending and malicious use. Liveness is the availability and resilience of the system against malicious actors that aim to delay or deny service.
2. Accountable Privacy: For cash, small transactions are very much anonymous, but high-value payments typically go through more scrutiny and audit. Very high-value payments are often highly regulated, time delayed, and meticulously audited. We envision a digital cash solution that provides a similar experience: entities have a digital anonymity budget that can be replenished at a regular time interval (say monthly). All transactions that stay within this budget remain completely anonymous. Digital payments beyond the anonymity budget and any other high-value transactions retain a high degree of privacy but do require real-time auditor approval. Very-high value transactions require more meticulous audits that may incur a time delay.
3. Performance: Using highly efficient zero-knowledge proofs, commutativity, and modern multi-core servers (vertical scaling, parallelism) we aim for thousands of transactions (payments with accountable anonymity) per second. With multiple systems working in parallel (horizontal scaling, sharding) performance can be increased to tens of thousands of transactions per second. Adding privacy-preserving payment channels (hierarchical scaling, channels) we can scale to much higher loads. Better performance is also about enabling programmability, which we will support.

One of the most distinctive aspects of VMware’s digital cash is accountable privacy. Anonymity budgets are an example of what accountable privacy technology enables. We are exploring many other uses like guaranteeing tax compliance while maintaining privacy, integrating privacy preserving transactions with Automated Market Makers, and enabling exceptional access to deanonymize high-value transactions based on Anti-Money Laundering/Combating the Financing of Terrorism (AML/CFT) controls. Different jurisdictions and different institutions may require different privacy vs. auditability trade-offs. Accountable privacy technology provides considerable flexibility and future tuning. Our goal is to highlight the power of accountable privacy technology and the flexibility of its design.

UTT Demo

Try concord-bft with UTT on your laptop

https://github.com/vmware/concord-bft/tree/utt

Checkout the "utt" branch, go to the utt-demo folder and type ‘make start’ (optionally ‘make pull’ to be sure that you have the latest images). Docker compose will fetch the images and start the demo...

Annoucment from the Bank of Israel on technolgical experimentation on a disitributed platform

The BoI announcement here

The BoI full report here

Experts from Section 5 of the report:

In the current payments system, there are two contrary situations regarding the maintenance of privacy when making a payment. Cash is completely anonymous. A cash payment contains no information regarding the identity of the payer, the amount of the payment, the date and location of the payment, or the identity of the receiver. In contrast, when a payment is made using any digital means of payment — payment card, bank transfer, payment app, and so forth — the financial entities operating the means of payment gain full information regarding all these details. Each of these options has advantages and disadvantages. Individuals have a basic right to privacy, and as long as the payment and the transaction are legal, there is no reason to encroach on this privacy. However, the complete anonymity involved in cash payments has broad policy implications, since it enables tax avoidance, money laundering, and terrorism financing. The information held by the financial entities has value from the standpoint of the consumer, in that it enables the financial entities to tailor various value offers to the consumer, assess his ability to repay credit and offer credit accordingly, and so forth. However, the information may also be exploited to the consumer’s disadvantage.

Either way, the consumer is faced with two contrary options, and in practice, the ability to pay while maintaining privacy exists only when making a physical payment. Remote payments, which are becoming more common as the economy becomes more digital, can only be made using means of payment operated by the financial entities, which gather the information contained in each payment.

Maintaining the public’s ability to use digital means of payment with some level of privacy is one of the motivations identified by the Steering Committee on the Potential Issuance of a Digital Shekel. There is broad discussion around the world regarding the potential of a CBDC to enable payments with some degree of privacy. For instance, at a public consultation held by the European Central Bank regarding the potential issuance of a digital euro, privacy was identified as the most important characteristic of a digital euro in the view of the respondents (ECB, 2021).

The second stage of the technological experiment conducted by the Bank of Israel examined a model which was recently published by researchers from VMware that enables payment with limited privacy using a digital shekel. The idea behind the model is that each wallet can hold “ordinary” digital shekels, the transfer of which is recorded in the ledger as outlined in Figure 4, and “private” digital shekels, the transfer details of which are not recorded openly, and where both sides to the transaction enjoy complete privacy as with cash payments. The policy maker can set out a periodic “budget” for payment using private shekels. For instance, it can be determined that from each wallet it will be possible to pay up to 1000 shekels per month privately, and beyond that each payment transaction will be recorded in the ledger.

For the purpose of the second stage in the experiment, a VMware blockchain infrastructure was set up in an AWS cloud that supports zero knowledge proof technologies for limited privacy. Here too, the system was built using a two-tier model, with a Byzantine Agreement system based on VMware Blockchain and a VMware Decentralized Cash Infrastructure payment engine. Four nodes were established to manage the central bank’s blockchain in a distributed format, and three payment service providers were set up to communicate directly with the central bank’s blockchain and intermediate between users’ wallets and the bank’s blockchain. The digital wallets provided by the payment service providers to the end customers include “ordinary” digital shekels, “private” digital shekels, and a private budget.

The transaction approval mechanism (the consensus mechanism) in the experiment is a Permissioned Byzantine Agreement that enables the network to deal with the “Byzantine” behavior of one of the nodes — a failure of the node (electricity, faulty disc, or other kinds of usual failures), or a malicious take-over of the node that results in the node trying to write errors to the blockchain. In general, the number of intersections, n, must be in line with the formula: n=3f+1, where f is the number of intersection failures (or their Byzantine behavior) that the system can absorb. For instance, a blockchain system with 10 intersections can be protected from an enemy attack on three of them. The system ensures liveness, safety, and security as long as the enemy takes control of no more than f intersections. The limited privacy mechanism in the experiment was based on an expansion of eCash technology while using zero knowledge proof tools in order to ensure the limitation of privacy in a way that maintains full privacy for payments within the periodic privacy budget

The experiment simulated ten end customers. After establishing the system, the Bank of Israel “issued” ordinary digital shekels, private digital shekels, and a privacy budget. In order to test the system, the following actions were examined:

1. Privacy-protected payments using private digital shekels from the privacy budget, which maintain full privacy and are not openly recorded on the blockchain.
2. Payment using ordinary digital shekels that are recorded openly on the blockchain.
3. Conversion from ordinary digital shekels to private digital shekels and back (Such an action does not change the size of the privacy budget. It does, for instance, enable conversion of private shekels to ordinary shekels if the periodic privacy budget is exhausted).
4. The resilience of the system when one of the blockchain’s nodes fails and loses all of the information. The system continues to operate as usual, and when the node returns it is synchronized with the other parts of the system so that it returns in full.
5. The resilience of the system when a payment service provider failes and loses all of the information. When an alternative payment service provider comes online, it restores all the wallets (including the distribution between private and ordinary digital shekels and the periodic privacy budget).

Conclusion

The second stage of the experiment examined the ability to enable digital shekel payments while maintaining limited privacy in accordance with the rules that policy makers will set. The attempt to create a solution for this issue in the experimental environment showed that it is difficult to use encryption keys in a distributed architecture, and that it is therefore necessary to work with other mechanisms involving zero knowledge proof technologies. An examination of an innovative development of this technology showed that it is possible to implement a policy whereby a periodic budget of “private” digital shekels can be allocated to each customer on the digital shekel network, which the customer can use to pay without any documentation of the payment being kept. The experiment and the discussions held following it brought into sharper focus the fact that despite proof of the technological feasibility, there are many policy questions that still need to be examined and discussed. For instance, what is the “correct” private budget, and is it proper to allocate the same amount to each type of wallet (private, business, and so forth), could this create economic incentives for the misuse of “private” shekels, and so forth.