What’s included?¶

The current prototype consists of a small amount of code that defines:

Key data structures.
Algorithms that work with them, such as serialising, hashing, signing, and verification of the signatures.
Two smart contracts that implement a notion of a cash claim and basic commercial paper (implemented twice, in two different programming languages). These are simplified versions of the real things.
Unit tests that check the algorithms do what is expected, and which verify the behaviour of the smart contracts.
API documentation and tutorials (what you’re reading)
A simple standalone node that uses an embedded message queue broker as its P2P messaging layer.
A trading demo that runs the node in either a listening/buying mode, or a connecting/selling mode, and swaps some fake commercial paper assets for some self-issued IOU cash, using a generic protocol framework.
It also includes two oracles: one for precise timestamping and another for interest rate swaps.

Some things it does not currently include but should gain later are:

Sandboxing, distribution or publication of smart contract code
A peer to peer network
Database persistence
An API for integrating external software
A user interface for administration
Many other things

The prototype’s goal is rapid exploration of ideas. Therefore in places it takes shortcuts that a production system would not in order to boost productivity:

It uses an object graph serialization framework instead of a well specified, vendor neutral protocol.
It uses secp256r1, an obsolete elliptic curve.
It uses the default, out of the box Apache Artemis MQ protocol instead of AMQP/1.0 (although switching should be easy)

Contracts¶

The primary goal of this prototype is to implement various kinds of contracts and verify that useful business logic can be expressed with the data model, developing and refining an API along the way. To that end there are currently two contracts in the repository:

Cash
Commercial paper

Cash implements the idea of a claim on some quantity of deposits at some institutional party, denominated in some currency, identified by some deposit reference. A deposit reference is an opaque byte array which is usable by the issuing party for internal bookkeeping purposes.

Cash states are fungible with each other (can be merged and split arbitrarily) if they use the same currency, party and deposit reference.

CommercialPaper implements an asset with a face value denominated in a certain currency, which may be redeemed at the issuing party after a certain time. Commercial paper states define the face value (e.g. $1000) and the time at which they may be redeemed. The contract allows the paper to be issued, traded and redeemed. The commercial paper contract is implemented twice, once in Java and once in a language called Kotlin.

Each contract comes with unit tests.

Kotlin¶

The prototype is written in a language called Kotlin. Kotlin is a language that targets the JVM and can be thought of as a simpler Scala, with much better Java interop. It is developed by and has commercial support from JetBrains, the makers of the IntelliJ IDE and other popular developer tools.

As Kotlin is very new, without a doubt you have not encountered it before. Don’t worry: it is designed as a better Java for industrial use and as such, the syntax was carefully designed to be readable even to people who don’t know the language, after only a few minutes of introduction.

Due to the seamless Java interop the use of Kotlin to extend the platform is not required and the tutorial shows how to write contracts in both Kotlin and Java. You can read more about why Kotlin is a potentially strong successor to Java here.

Kotlin programs use the regular Java standard library and ordinary Java frameworks. Frameworks used at this time are:

JUnit for unit testing
Kryo for serialisation (this is not intended to be permanent)
Gradle for the build
Guava for a few utility functions