Canton Network

Building distributed applications from scratch offers numerous advantages, including improved workflow automation, reduced errors, enhanced security, and effective auditing in regulated industries.

To build an application that automates a cross-organization workflow, one must devise and correctly implement a set of rules for exchanging data (i.e., a communication protocol).

Today’s standards help with transporting data (e.g., REST, gRPC) and describing its shape (e.g., XML schemas, session types), as well as handling authentication (e.g., X.509, TLS). But implementing the protocol logic remains a non-trivial task. For example, an estimated 10% of the trade volume in stock markets is subject to manual intervention (reconciliation), due to mismatches and mistakes in interpreting the exchanged data.

A smart contract platform solves the problem of diverging implementations by providing a shared data encoding and execution logic for the protocol. Of course, this shared logic still has to be correct. In particular, the security of cross-organization distributed applications critically depends on proper authorization. Inadequate authorization features in languages used in existing smart contract platforms resulted in several high-profile incidents, such as the first Parity Wallet attack.

Business workflows often need to be composed into higher-level workflows, but their software implementations typically do not easily achieve the desired properties. For instance, in a travel agency workflow that combines booking a flight and a hotel, it is crucial to ensure atomicity of distributed transactions. This means that the flight and hotel should be booked together or not at all, to avoid the risk of partially successful bookings and increased costs for the end customer.

This atomicity is only possible if both the airline and the hotel systems build in specific and compatible support for it. Standards such as X/Open XA exist, but they have to be correctly implemented by all of the involved subsystems, including their off-the-shelf components. This is a significant technical complexity that is not essential to the individual operation, and thus often never gets implemented

Platforms relying on proof-of-work blockchains focus on bringing trust in third parties to an absolute minimum.

In particular, such a blockchain can yield the digital equivalent of golden nuggets: a bearer token that is neither controlled nor backed by any single real-world party. The platform’s contracts can then manipulate the balances in this currency jointly with arbitrary other information. In exchange, the platforms sacrifice scalability: their throughput is typically limited to tens of transactions per second, and the historic data required to use the platform securely often grows unboundedly with time.

The throughput can be increased for value transactions by moving them off the blockchain, but this destroys the ability to integrate them with other applications, and introduces problems such as routing and collateralization. But not only blockchains inhibit scaling: most platforms replicate a global shared state at all their participants. This necessarily puts a cap on scaling, as any state change must be processed by all participants.

A global shared state is also a privacy leak that is unacceptable for use cases such as handling trade secrets, financial data, or healthcare. It also clashes with the data minimization requirements of the European Union’s General Data Protection Regulation (GDPR). Pseudonymization helps, but is not a solution. Furthermore, resting the security on a shared global state stored in a blockchain data structure clashes with the GDPR’s “right to be forgotten” requirement. Some blockchain-based services have already shut down due to their inability to comply with the GDPR. Advanced cryptography can restore privacy to various degrees, up to full-blown private multi-party computation, but these methods are computationally intensive and present a significant obstacle to scaling. Platforms that are willing to make stronger trust assumptions can limit data visibility without resorting to expensive cryptography. However, limiting visibility can also limit transparency: either through error or malice, data might not be distributed to everyone that should see it. This can cause disputes. Finally, the privacy requirements often surpass these platforms’ abilities. For example, a stock market trade must happen 3 atomically, but the buyer’s bank should only see the outgoing money transfer, and not what this money bought. All practical platforms promising both such subtransaction-level privacy and transparency rely on trusted execution environments, such as SGX, for protecting privacy. These protections suffice for some use cases, but recent research makes them inadequate for many others.

For more info, please check daml official documentation.