<p>A transaction may also be <strong>timestamped</strong>. A timestamp is a (hash, datetime, signature) triple from a
<em>timestamping authority</em> (TSA). The notion of a TSA is not ledger specific and is defined by
<aclass="reference external"href="https://www.ietf.org/rfc/rfc3161.txt">IETF RFC 3161</a> which defines the internet standard Timestamping Protocol (TSP).
The purpose of the TSA is to attach a single, globally agreed upon time which a contract may use to enforce certain
types of time-based logic. The TSA’s do not need to know about the contents of the transaction in order to provide a
timestamp, and they are therefore never exposed to private data.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">In the current code, use of TSAs is not implemented.</p>
</div>
<p>As the same terminology often crops up in different distributed ledger designs, let’s compare this to other
<h3>Comparison with Bitcoin<aclass="headerlink"href="#comparison-with-bitcoin"title="Permalink to this headline">¶</a></h3>
<p>Similarities:</p>
<ulclass="simple">
<li>The basic notion of immutable states that are consumed and created by transactions is the same.</li>
<li>The notion of transactions having multiple inputs and outputs is the same. Bitcoin sometimes refers to the ledger
as the unspent transaction output set (UTXO set) as a result.</li>
<li>Like in Bitcoin, a contract is pure function. Contracts do not have storage or the ability to interact with anything.
Given the same transaction, a contract’s accept function always yields exactly the same result.</li>
<li>Bitcoin output scripts are parameterised by the input scripts in the spending transaction. This is somewhat similar
to our notion of a <em>command</em>.</li>
<li>Bitcoin transactions, like ours, refer to the states they consume by using a (txhash, index) pair. The Bitcoin
protocol calls these “outpoints”. In our prototype code they are known as <codeclass="docutils literal"><spanclass="pre">StateRefs</span></code> but the concept is identical.</li>
<li>Bitcoin transactions have an associated timestamp (the time at which they are mined).</li>
</ul>
<p>Differences:</p>
<ulclass="simple">
<li>A Bitcoin transaction has a single, rigid data format. A “state” in Bitcoin is always a (quantity of bitcoin, script)
pair and cannot hold any other data. Some people have been known to try and hack around this limitation by embedding
data in semi-standardised places in the contract code so the data can be extracted through pattern matching, but this
is a poor approach. Our states can include arbitrary typed data.</li>
<li>A Bitcoin transaction’s acceptance is controlled only by the contract code in the consumed input states. In practice
this has proved limiting. Our transactions invoke not only input contracts but also the contracts of the outputs.</li>
<li>A Bitcoin script can only be given a fixed set of byte arrays as the input. This means there’s no way for a contract
to examine the structure of the entire transaction, which severely limits what contracts can do.</li>
<li>Our contracts are Turing-complete and can be written in any ordinary programming language that targets the JVM.</li>
<p><codeclass="docutils literal"><spanclass="pre">Cash</span></code> implements the idea of a claim on some quantity of deposits at some institutional party, denominated in some currency,
<p><codeclass="docutils literal"><spanclass="pre">CommercialPaper</span></code> implements an asset with a <em>face value</em> denominated in a certain currency, which may be redeemed at
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.</p>
<p>Each contract comes with unit tests.</p>
</div>
<divclass="section"id="kotlin">
<h2>Kotlin<aclass="headerlink"href="#kotlin"title="Permalink to this headline">¶</a></h2>
<p>The prototype is written in a language called <aclass="reference external"href="https://kotlinlang.org/">Kotlin</a>. 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.</p>
<p>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.</p>
<p>Due to the seamless Java interop the use of Kotlin to extend the platform is <em>not</em> required and the tutorial shows how
to write contracts in both Kotlin and Java. You can <aclass="reference external"href="https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3">read more about why Kotlin is a potentially strong successor to Java here</a>.</p>
<p>Kotlin programs use the regular Java standard library and ordinary Java frameworks. Frameworks used at this time are:</p>
<ulclass="simple">
<li>JUnit for unit testing</li>
<li>Kryo for serialisation (this is not intended to be permanent)</li>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
