Deon Runtime

The Deon Runtime is a JVM library that implements the core functionality needed to work with CSL contracts and events. The runtime is used as a subcomponent in tools and services that need to process CSL contracts.

Data types are provided for representing the abstract syntax trees of CSL contracts, which are tree-structured representations of CSL source code that can easily be processed and manipulated by software because the job of parsing the code and decomposing it into its parts has been done. Contracts are represented as abstract syntax because this has a number of advantages over translating them into general-purpose executable code such as JVM bytecode. Since abstract syntax retains the structure of the CSL code it represents, all contracts, and in particular residual contracts, can easily be rendered as CSL code that can be inspected by a human. Furthermore, it is considerably easier to analyze abstract syntax for a language that is constrained to a particular domain than it is to analyze general purpose programs. Finally, the representation allows other tooling to inspect the CSL, opening the system up for future expansions not anticipated at the time of its creation.

CSL source code cannot be parsed by the runtime; this job is performed by the Deon sic tool which parses the CSL source code and checks that it is meaningful, saving the resulting abstract syntax tree in a serialized format that can be loaded by the runtime library. The serialization format for the abstract syntax is also used for storing residual contracts on the ledgers supported by Deon Digital.

The runtime library also provides an implementation of the apply function which given a contract and an event computes the residual contract. This is used by the systems that consume the Deon runtime to maintain the correspondence between the obligations that derive from a contract and the events that have occurred so far.

The following diagram shows the components that are involved when a CSL file is parsed and used to instantiate a new CSL contract:

In the top, the sic tool parses and type checks the source code in a CSL file that specifies one or more contract templates. If the file contains no errors, a parsed and type checked abstract syntax representation is serialized to a format that can be consumed by the Deon Runtime.

Given a processed CSL file and the data necessary to instantiate a contract template in it (such as specific prices or the identities of the agents involved), the contract interpreter creates a contract, essentially by substituting the given arguments into the contract template as it is defined in the file, analogous to filling out the blanks in a traditional paper template. The resulting contract is an immutable object that represents a specific set of events that are expected now and in the future - for instance, it might represent the fact that payment has been recorded but a knockout has not yet occurred, and the conditions under which it would occur. This immutable object can be serialized for storage in a database system, saved to a distributed ledger, or transferred over a network. It is also possible to recover a CSL specification of the contract’s remaining obligations from this run-time representation, allowing them to be audited, inspected, and understood by manual or automatic processes.

Lifecycle Management

Contracts have a lifecycle: they are instantiated from templates, they determine obligations between their parties at each point in time, and at some point they are satisfied and can be archived. Lifecycle management is the process of keeping track of contracts’ lifecycles and ensuring that the current contractual obligations are clear. Lifecycle management is done by performing operations on the immutable run-time representations of contracts. A central operation is to apply an event to a contract, which either results in a rejection (if the event is not actually expected by the contract) or a new contract object that represents the point in the contract lifecycle after the given event has occurred. For instance, a contract might obligate Alice to pay Bob a sum of €500, after which Bob must transfer a share of a company back to Alice. Applying the payment event results in a new contract that requires only the transfer of stock. Events are first-class values within the CSL language, and all CSL values are represented as structured data in the runtime, similar to the abstract syntax used for representing contracts.

Event values are typically created and applied to the relevant contract by a contract lifecycle manager, which is a software system that provides the integration between the Deon runtime, a ledger and the surrounding environment. It keeps track of a set of contract instances which are contracts that are identified by a unique identifier known by the relevant parties. The contract manager performs concrete observations and matches them to the relevant contract instances, updating the contracts via the apply function and recording the event in the ledger to ensure that a tamper-proof and verifiable record of the contract’s lifecycle is always available. The contract manager also exposes operations for instantiating new contract instances and managing the general aspects of their life cycles, such as contract upgrades/replacements and early termination due to external factors.

An important distinction should be made between the concrete event evidence observed by the contract manager and the event values applied to the contract instances. Concrete event evidence is usually in a format specific to the system that generated it, and may include details that are not relevant to determine the next point in the life cycle of a given contract instance. For example, a payment confirmation event may include multiple reference numbers that are important for tracking the payment, but which are not relevant for determining if the right party paid the correct amount within a given deadline. Similarly, different systems may generate concrete events that refer to the same legal entities using different credentials, but from the point of view of a contract, only the identities of the participants are relevant, not how they are identified. The contract manager will therefore translate all concrete evidence into high-level CSL events that are actually observed by the contracts.

CSL contracts are thus written in terms of a set of abstract events from a well-defined ontology that models the business domain and which serves as the interface between CSL contracts and the surrounding systems. For instance, for contracts modeling financial instruments on an exchange, the ontology will consist of events such as market price observations and confirmations of payments and deliveries. Because of this architecture, CSL contracts are independent of the technical details of the systems in which they are deployed, which enables their use in other contexts such as stochastic simulation or analysis.

The following diagram shows how the components described above interact with each other:

The ledger stores tamper-proof histories of all contract instances. Apart from just storing the history of the contract states, the ledger also records the observations that resulted in the events being applied to the contract instances. Since the Deon runtime is entirely deterministic (instantiating the same contract twice or applying the same event to the same contract instance twice always results in identical results) such a history of observations can always be verified to be correct according to the relevant contract by recomputing the history of contract states and verifying that they match with what is actually recorded on the ledger.

We have existing solutions for two ledger technologies, both of which provide secure, tamper-proof histories for all contract instances, but with different tradeoffs:

DbLedger

Integrates with an industry-standard relational database system to store contract data, with a publish/subscribe model where a single node manages contract instances and publishes changes via a secure messaging protocol to subscriber nodes deployed at the premises of the relevant parties.

Deon Digital Smart Financial Instruments DLT

Stores contract instances on a custom built DLT.