ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-18 20:47:57 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Rename 'playground' to 'R3 Prototyping'

Browse Source
This commit is contained in:
Mike Hearn 2015-11-30 17:00:25 +00:00
parent 50c3956988
commit 8ea4ac8b15
17 changed files with 82 additions and 103 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
build.gradle
View File

@ -1,4 +1,4 @@
group 'com.r3cev.experimental'
group 'com.r3cev.prototyping'
version '1.0-SNAPSHOT'
apply plugin: 'java'

2
docs/build/html/.buildinfo vendored
View File

@ -1,4 +1,4 @@
# Sphinx build info version 1
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
config: 4b8a393be639c6ef9d56da5e90338bb6
config: b79bc8e267991c90208eba2e06b900db
tags: 645f666f9bcd5a90fca523b33c5a78b7

6
docs/build/html/_sources/index.txt vendored
View File

@ -1,7 +1,7 @@
Welcome to the Playground's documentation!
==========================================
Welcome to the R3 prototyping repository!
=========================================
This documentation describes the first prototype of the R3 shared ledger platform.
This documentation describes the first prototype of a possible future R3 shared ledger platform.
The goal of this prototype is to explore fundamentally better designs for transactions, states and smart contract APIs
than what presently exists on the market, tailor made for the needs of the financial industry. It does not at this

21
docs/build/html/_sources/tutorial.txt vendored
View File

@ -169,7 +169,7 @@ We have four fields in our state:
States are immutable, and thus the class is defined as immutable as well. The ``data`` modifier in the Kotlin version
causes the compiler to generate the equals/hashCode/toString methods automatically, along with a copy method that can
be used to create variants of the original object. Data classes are similar to case classes in Scala, if you are
familiar with that language. The ``withoutOwner```` method uses the auto-generated copy method to return a version of
familiar with that language. The ``withoutOwner`` method uses the auto-generated copy method to return a version of
the state with the owner public key blanked out: this will prove useful later.
The Java code compiles to the same bytecode as the Kotlin version, but as you can see, is much more verbose.
@ -407,7 +407,7 @@ may be missing here. We check for it being null later.
.. note:: In the Kotlin version, as long as we write a comparison with the transaction time first, the compiler will
verify we didn't forget to check if it's missing. Unfortunately due to the need for smooth Java interop, this
check won't happen if we write e.g. `someDate > time`, it has to be `time < someDate`. So it's good practice to
check won't happen if we write e.g. ``someDate > time``, it has to be ``time < someDate``. So it's good practice to
always write the transaction timestamp first.
The first line (first three lines in Java) impose a requirement that there be a single piece of commercial paper in
@ -671,13 +671,14 @@ multiple contracts.
.. note:: Crafting methods should ideally be written to compose with each other, that is, they should take a
``PartialTransaction`` as an argument instead of returning one, unless you are sure it doesn't make sense to
combine this type of transaction with others. In this case, issuing CP at the same time as doing other things
would just introduce complexity that isn't likely to be worth it, so we return a fresh object each time.
would just introduce complexity that isn't likely to be worth it, so we return a fresh object each time: instead,
an issuer should issue the CP (starting out owned by themselves), and then sell it in a separate transaction.
The function we define creates a ``CommercialPaper.State`` object that mostly just uses the arguments we were given,
but it fills out the owner field of the state to be the same public key as the issuing institution. If the caller wants
to issue CP onto the ledger that's immediately owned by someone else, they'll have to create the state themselves.
The returned partial transaction has a ``WireCommand`` object as a parameter. This is just a container for any object
The returned partial transaction has a ``WireCommand`` object as a parameter. This is a container for any object
that implements the ``Command`` interface, along with a key that is expected to sign this transaction. In this case,
issuance requires that the issuing institution sign, so we put the key of the institution there.
@ -723,6 +724,10 @@ Finally, we can do redemption.
Here we can see an example of composing contracts together. When an owner wishes to redeem the commercial paper, the
issuer (i.e. the caller) must gather cash from its wallet and send the face value to the owner of the paper.
.. note:: **Exercise for the reader**: In this early, simplified model of CP there is no built in support
for rollover. Extend the contract code to support rollover as well as redemption (reissuance of the paper with a
higher face value without any transfer of cash)
The *wallet* is a concept that may be familiar from Bitcoin and Ethereum. It is simply a set of cash states that are
owned by the caller. Here, we use the wallet to update the partial transaction we are handed with a movement of cash
from the issuer of the commercial paper to the current owner. If we don't have enough quantity of cash in our wallet,
@ -754,9 +759,11 @@ Although this tutorial covers how to implement an owned asset, there is no requi
world, and (code) contracts as imposing logical relations on how facts combine to produce new facts.
For example, in the case that the transfer of an asset cannot be performed entirely on-ledger, one possible usage of
the model is to implement a delivery-vs-payment lifecycle in which there is a state representing an intention to trade,
another state representing an in-progress delivery, and a final state in which the delivery is marked as complete and
payment is being awaited.
the model is to implement a delivery-vs-payment lifecycle in which there is a state representing an intention to trade
and two other states that can be interpreted by off-ledger platforms as firm instructions to move the respective asset
or cash - and a final state in which the exchange is marked as complete. The key point here is that the two off-platform
instructions form pa rt of the same Transaction and so either both are signed (and can be processed by the off-ledger
systems) or neither are.
As another example, consider multi-signature transactions, a feature which is commonly used in Bitcoin to implement
various kinds of useful protocols. This technique allows you to lock an asset to ownership of a group, in which a

8
docs/build/html/genindex.html vendored
View File

@ -9,7 +9,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Index &mdash; Playground 0.1 documentation</title>
<title>Index &mdash; R3 Prototyping 0.1 documentation</title>
@ -31,7 +31,7 @@
<link rel="top" title="Playground 0.1 documentation" href="index.html"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="index.html"/>
<script src="_static/js/modernizr.min.js"></script>
@ -49,7 +49,7 @@
<a href="index.html" class="icon icon-home"> Playground
<a href="index.html" class="icon icon-home"> R3 Prototyping
@ -99,7 +99,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">Playground</a>
<a href="index.html">R3 Prototyping</a>
</nav>

8
docs/build/html/getting-set-up.html vendored
View File

@ -8,7 +8,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Getting set up &mdash; Playground 0.1 documentation</title>
<title>Getting set up &mdash; R3 Prototyping 0.1 documentation</title>
@ -30,7 +30,7 @@
<link rel="top" title="Playground 0.1 documentation" href="index.html"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="index.html"/>
<link rel="next" title="Tutorial" href="tutorial.html"/>
<link rel="prev" title="Overview" href="overview.html"/>
@ -50,7 +50,7 @@
<a href="index.html" class="icon icon-home"> Playground
<a href="index.html" class="icon icon-home"> R3 Prototyping
@ -103,7 +103,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">Playground</a>
<a href="index.html">R3 Prototyping</a>
</nav>

16
docs/build/html/index.html vendored
View File

@ -8,7 +8,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Welcome to the Playground’s documentation! &mdash; Playground 0.1 documentation</title>
<title>Welcome to the R3 prototyping repository! &mdash; R3 Prototyping 0.1 documentation</title>
@ -30,7 +30,7 @@
<link rel="top" title="Playground 0.1 documentation" href="#"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="#"/>
<link rel="next" title="What’s included?" href="inthebox.html"/>
@ -49,7 +49,7 @@
<a href="#" class="icon icon-home"> Playground
<a href="#" class="icon icon-home"> R3 Prototyping
@ -99,7 +99,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="#">Playground</a>
<a href="#">R3 Prototyping</a>
</nav>
@ -116,7 +116,7 @@
<ul class="wy-breadcrumbs">
<li><a href="#">Docs</a> &raquo;</li>
<li>Welcome to the Playground&#8217;s documentation!</li>
<li>Welcome to the R3 prototyping repository!</li>
<li class="wy-breadcrumbs-aside">
@ -130,9 +130,9 @@
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="welcome-to-the-playground-s-documentation">
<h1>Welcome to the Playground&#8217;s documentation!<a class="headerlink" href="#welcome-to-the-playground-s-documentation" title="Permalink to this headline"></a></h1>
<p>This documentation describes the first prototype of the R3 shared ledger platform.</p>
<div class="section" id="welcome-to-the-r3-prototyping-repository">
<h1>Welcome to the R3 prototyping repository!<a class="headerlink" href="#welcome-to-the-r3-prototyping-repository" title="Permalink to this headline"></a></h1>
<p>This documentation describes the first prototype of a possible future R3 shared ledger platform.</p>
<p>The goal of this prototype is to explore fundamentally better designs for transactions, states and smart contract APIs
than what presently exists on the market, tailor made for the needs of the financial industry. It does not at this
time include networking, database or user interface code.</p>

12
docs/build/html/inthebox.html vendored
View File

@ -8,7 +8,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>What’s included? &mdash; Playground 0.1 documentation</title>
<title>What’s included? &mdash; R3 Prototyping 0.1 documentation</title>
@ -30,9 +30,9 @@
<link rel="top" title="Playground 0.1 documentation" href="index.html"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="index.html"/>
<link rel="next" title="Overview" href="overview.html"/>
<link rel="prev" title="Welcome to the Playground’s documentation!" href="index.html"/>
<link rel="prev" title="Welcome to the R3 prototyping repository!" href="index.html"/>
<script src="_static/js/modernizr.min.js"></script>
@ -50,7 +50,7 @@
<a href="index.html" class="icon icon-home"> Playground
<a href="index.html" class="icon icon-home"> R3 Prototyping
@ -100,7 +100,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">Playground</a>
<a href="index.html">R3 Prototyping</a>
</nav>
@ -170,7 +170,7 @@ would not in order to boost productivity:</p>
<a href="overview.html" class="btn btn-neutral float-right" title="Overview" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="index.html" class="btn btn-neutral" title="Welcome to the Playground’s documentation!" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
<a href="index.html" class="btn btn-neutral" title="Welcome to the R3 prototyping repository!" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
</div>

BIN
docs/build/html/objects.inv vendored
View File

Binary file not shown.

8
docs/build/html/overview.html vendored
View File

@ -8,7 +8,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Overview &mdash; Playground 0.1 documentation</title>
<title>Overview &mdash; R3 Prototyping 0.1 documentation</title>
@ -30,7 +30,7 @@
<link rel="top" title="Playground 0.1 documentation" href="index.html"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="index.html"/>
<link rel="next" title="Getting set up" href="getting-set-up.html"/>
<link rel="prev" title="What’s included?" href="inthebox.html"/>
@ -50,7 +50,7 @@
<a href="index.html" class="icon icon-home"> Playground
<a href="index.html" class="icon icon-home"> R3 Prototyping
@ -109,7 +109,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">Playground</a>
<a href="index.html">R3 Prototyping</a>
</nav>

8
docs/build/html/roadmap.html vendored
View File

@ -8,7 +8,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Roadmap &mdash; Playground 0.1 documentation</title>
<title>Roadmap &mdash; R3 Prototyping 0.1 documentation</title>
@ -30,7 +30,7 @@
<link rel="top" title="Playground 0.1 documentation" href="index.html"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="index.html"/>
<link rel="prev" title="Tutorial" href="tutorial.html"/>
@ -49,7 +49,7 @@
<a href="index.html" class="icon icon-home"> Playground
<a href="index.html" class="icon icon-home"> R3 Prototyping
@ -102,7 +102,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">Playground</a>
<a href="index.html">R3 Prototyping</a>
</nav>

8
docs/build/html/search.html vendored
View File

@ -8,7 +8,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Search &mdash; Playground 0.1 documentation</title>
<title>Search &mdash; R3 Prototyping 0.1 documentation</title>
@ -30,7 +30,7 @@
<link rel="top" title="Playground 0.1 documentation" href="index.html"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="index.html"/>
<script src="_static/js/modernizr.min.js"></script>
@ -48,7 +48,7 @@
<a href="index.html" class="icon icon-home"> Playground
<a href="index.html" class="icon icon-home"> R3 Prototyping
@ -98,7 +98,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">Playground</a>
<a href="index.html">R3 Prototyping</a>
</nav>

2
docs/build/html/searchindex.js vendored
View File

File diff suppressed because one or more lines are too long

31
docs/build/html/tutorial.html vendored
View File

@ -8,7 +8,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Tutorial &mdash; Playground 0.1 documentation</title>
<title>Tutorial &mdash; R3 Prototyping 0.1 documentation</title>
@ -30,7 +30,7 @@
<link rel="top" title="Playground 0.1 documentation" href="index.html"/>
<link rel="top" title="R3 Prototyping 0.1 documentation" href="index.html"/>
<link rel="next" title="Roadmap" href="roadmap.html"/>
<link rel="prev" title="Getting set up" href="getting-set-up.html"/>
@ -50,7 +50,7 @@
<a href="index.html" class="icon icon-home"> Playground
<a href="index.html" class="icon icon-home"> R3 Prototyping
@ -111,7 +111,7 @@
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">Playground</a>
<a href="index.html">R3 Prototyping</a>
</nav>
@ -292,7 +292,7 @@ from the Java 8 standard time library. It defines a point on the timeline.</li>
<p>States are immutable, and thus the class is defined as immutable as well. The <code class="docutils literal"><span class="pre">data</span></code> modifier in the Kotlin version
causes the compiler to generate the equals/hashCode/toString methods automatically, along with a copy method that can
be used to create variants of the original object. Data classes are similar to case classes in Scala, if you are
familiar with that language. The <code class="docutils literal"><span class="pre">withoutOwner``</span></code> method uses the auto-generated copy method to return a version of
familiar with that language. The <code class="docutils literal"><span class="pre">withoutOwner</span></code> method uses the auto-generated copy method to return a version of
the state with the owner public key blanked out: this will prove useful later.</p>
<p>The Java code compiles to the same bytecode as the Kotlin version, but as you can see, is much more verbose.</p>
</div>
@ -506,7 +506,7 @@ may be missing here. We check for it being null later.</p>
<p class="first admonition-title">Note</p>
<p class="last">In the Kotlin version, as long as we write a comparison with the transaction time first, the compiler will
verify we didn&#8217;t forget to check if it&#8217;s missing. Unfortunately due to the need for smooth Java interop, this
check won&#8217;t happen if we write e.g. <cite>someDate &gt; time</cite>, it has to be <cite>time &lt; someDate</cite>. So it&#8217;s good practice to
check won&#8217;t happen if we write e.g. <code class="docutils literal"><span class="pre">someDate</span> <span class="pre">&gt;</span> <span class="pre">time</span></code>, it has to be <code class="docutils literal"><span class="pre">time</span> <span class="pre">&lt;</span> <span class="pre">someDate</span></code>. So it&#8217;s good practice to
always write the transaction timestamp first.</p>
</div>
<p>The first line (first three lines in Java) impose a requirement that there be a single piece of commercial paper in
@ -742,12 +742,13 @@ multiple contracts.</p>
<p class="last">Crafting methods should ideally be written to compose with each other, that is, they should take a
<code class="docutils literal"><span class="pre">PartialTransaction</span></code> as an argument instead of returning one, unless you are sure it doesn&#8217;t make sense to
combine this type of transaction with others. In this case, issuing CP at the same time as doing other things
would just introduce complexity that isn&#8217;t likely to be worth it, so we return a fresh object each time.</p>
would just introduce complexity that isn&#8217;t likely to be worth it, so we return a fresh object each time: instead,
an issuer should issue the CP (starting out owned by themselves), and then sell it in a separate transaction.</p>
</div>
<p>The function we define creates a <code class="docutils literal"><span class="pre">CommercialPaper.State</span></code> object that mostly just uses the arguments we were given,
but it fills out the owner field of the state to be the same public key as the issuing institution. If the caller wants
to issue CP onto the ledger that&#8217;s immediately owned by someone else, they&#8217;ll have to create the state themselves.</p>
<p>The returned partial transaction has a <code class="docutils literal"><span class="pre">WireCommand</span></code> object as a parameter. This is just a container for any object
<p>The returned partial transaction has a <code class="docutils literal"><span class="pre">WireCommand</span></code> object as a parameter. This is a container for any object
that implements the <code class="docutils literal"><span class="pre">Command</span></code> interface, along with a key that is expected to sign this transaction. In this case,
issuance requires that the issuing institution sign, so we put the key of the institution there.</p>
<p>The <code class="docutils literal"><span class="pre">PartialTransaction</span></code> constructor we used above takes a variable argument list for convenience. You can pass in
@ -784,6 +785,12 @@ state on the ledger.</p>
</div>
<p>Here we can see an example of composing contracts together. When an owner wishes to redeem the commercial paper, the
issuer (i.e. the caller) must gather cash from its wallet and send the face value to the owner of the paper.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last"><strong>Exercise for the reader</strong>: In this early, simplified model of CP there is no built in support
for rollover. Extend the contract code to support rollover as well as redemption (reissuance of the paper with a
higher face value without any transfer of cash)</p>
</div>
<p>The <em>wallet</em> is a concept that may be familiar from Bitcoin and Ethereum. It is simply a set of cash states that are
owned by the caller. Here, we use the wallet to update the partial transaction we are handed with a movement of cash
from the issuer of the commercial paper to the current owner. If we don&#8217;t have enough quantity of cash in our wallet,
@ -812,9 +819,11 @@ logic that uses standardised APIs and runs in a sandbox.</p>
<em>must</em> be concerned with ownership of an asset. It is better to think of states as representing useful facts about the
world, and (code) contracts as imposing logical relations on how facts combine to produce new facts.</p>
<p>For example, in the case that the transfer of an asset cannot be performed entirely on-ledger, one possible usage of
the model is to implement a delivery-vs-payment lifecycle in which there is a state representing an intention to trade,
another state representing an in-progress delivery, and a final state in which the delivery is marked as complete and
payment is being awaited.</p>
the model is to implement a delivery-vs-payment lifecycle in which there is a state representing an intention to trade
and two other states that can be interpreted by off-ledger platforms as firm instructions to move the respective asset
or cash - and a final state in which the exchange is marked as complete. The key point here is that the two off-platform
instructions form pa rt of the same Transaction and so either both are signed (and can be processed by the off-ledger
systems) or neither are.</p>
<p>As another example, consider multi-signature transactions, a feature which is commonly used in Bitcoin to implement
various kinds of useful protocols. This technique allows you to lock an asset to ownership of a group, in which a
threshold of signers (e.g. 3 out of 4) must all sign simultaneously to enable the asset to move. It is initially

45
docs/source/conf.py
View File

@ -1,6 +1,6 @@
# -*- coding: utf-8 -*-
#
# Playground documentation build configuration file, created by
# R3 prototyping documentation build configuration file, created by
# sphinx-quickstart on Mon Nov 23 21:19:35 2015.
#
# This file is execfile()d with the current directory set to its
@ -45,7 +45,7 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
project = u'Playground'
project = u'R3 Prototyping'
copyright = u'2015, R3 CEV'
author = u'R3 CEV'
@ -207,7 +207,7 @@ html_style = 'css/custom.css'
#html_search_scorer = 'scorer.js'
# Output file base name for HTML help builder.
htmlhelp_basename = 'Playgrounddoc'
htmlhelp_basename = 'R3doc'
# -- Options for LaTeX output ---------------------------------------------
@ -229,7 +229,7 @@ latex_elements = {
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'Playground.tex', u'Playground Documentation',
(master_doc, 'R3Prototyping.tex', u'R3 Prototyping Documentation',
u'R3 CEV', 'manual'),
]
@ -252,40 +252,3 @@ latex_documents = [
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'playground', u'Playground Documentation',
[author], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'Playground', u'Playground Documentation',
author, 'Playground', 'One line description of project.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# If true, do not generate a @detailmenu in the "Top" node's menu.
#texinfo_no_detailmenu = False

6
docs/source/index.rst
View File

@ -1,7 +1,7 @@
Welcome to the Playground's documentation!
==========================================
Welcome to the R3 prototyping repository!
=========================================
This documentation describes the first prototype of the R3 shared ledger platform.
This documentation describes the first prototype of a possible future R3 shared ledger platform.
The goal of this prototype is to explore fundamentally better designs for transactions, states and smart contract APIs
than what presently exists on the market, tailor made for the needs of the financial industry. It does not at this

2
settings.gradle
View File

@ -1,2 +1,2 @@
rootProject.name = 'playground'
rootProject.name = 'r3prototyping'