...

Daml abstracts the event sourcing model employed by blockchains and distributed ledgers. Event sourcing means that the current state of the system can be computed from the log of past events. Instead of keeping a global event log, Daml provides each stakeholder a consistent view on a virtual shared event log, called the virtual shared ledger, while distributing data on a strict need-to-know basis under the hood. This creates a system in which each participant has a consistent view of the (virtual) global system state, consisting of exactly the data they are entitled to. The virtual shared ledger is described in Daml’s Ledger Model and implemented in the Daml smart contract language and associated Ledger API.

The Ledger API is the primary API to interact with Daml smart contracts and the virtual shared ledger. It is a high-performance reactive gRPC-based streaming API. It allows applications to subscribe to events that they are permissioned to view, get their current state, or submit commands to write new events. As such, the Ledger API and smart contracts are the primary mechanisms for abstracting away concrete blockchains or databases to instead develop against a virtual shared ledger. Any node in a network that exposes Daml’s Ledger API—and thus gives access to the shared ledgers—is called a participant node as it allows participation in the network.

To enable an infrastructure like a blockchain or database to run Daml applications, it needs a Daml Driver that allows a matching participant node to connect into the network. Daml Drivers do not store any data and are typically deployed per node of the underlying blockchain or database. There are already numerous drivers, both open source and commercial, available in the Daml ecosystem, with more under development. See https://daml.com for an overview.

...

ASX-daml-project-cancelled-Chairman Apologizes After Writing Off 165 Million Blockchain Project.pdf file

the project was facing a number of obstacles, including resistance from companies on the platform to use the shared ledger.

<< Lesson learned:  engage key partners at through out the start of a solution life cycle, not at the test phasephase  ( see Food Trust, TradeLens, TYS )

<< Lesson learned: let the partner council define the economic. governance, compliance, trust models that work, not just the applications and technologies for the use cases in scope

the Accenture report commissioned by ASX that noted “the absence of appropriate design artefacts, rigour, or inconsistent design discipline to model the expected behaviour within the constraints of the technology.”

<< Lesson learned: don't try to be revolutionary. Be evolutionary in the solution design - takes longer but has lower risks, more network buy in for success

Potential Challenges

Candidate Solutions

...