Reverting to Architecture Document 0.8.1

Author: desaperados

README.rst

@@ -1,5 +1,3 @@
-UNPUBLISHED DRAFT. NOT FOR RELEASE
-
 *****************************
 RChain-Architecture
 *****************************
@@ -29,7 +27,7 @@ For Windows users:
 
 Get source code
 --------------------------------------------------------------------------------
-* git clone: https://github.com/ethereum/homestead-guide.git
+* git clone: https://github.com/rchain/architecture-docs.git
 
 Build and view html
 --------------------------------------------------------------------------------

applications.rst

@@ -0,0 +1,26 @@
+.. _applications:
+
+################################################################################
+Applications
+################################################################################
+
+Any number and variety of applications can be built on top of the RChain Platform
+that provide a decentralized public compute utility. These include, for example:
+
+* Wallets
+* Exchanges
+* Oracles & External Adapters
+* Custom Protocols
+* Smart Contracts
+* Smart Properties
+* DAOs
+* Social Networks
+* Marketplaces
+
+Several application providers are already committed to this platform, including
+RChain for its social product, `LivelyGig`_ for its marketplaces,  `weWOWwe`_ for
+its sports-based social network, and `Nobex Radio`_ for a to-be-announced product.
+
+.. _LivelyGig: http://www.livelygig.com
+.. _weWOWwe: http://wewowwe.com
+.. _Nobex Radio: http://www.nobexpartners.com

introduction/approach.rst renamed to architecture-approach.rst

@@ -1,4 +1,4 @@
-.. _approach:
+.. _architecture-approach:
 
 ################################################################################
 Architectural Approach

architecture-overview.rst

@@ -0,0 +1,31 @@
+.. _architecture-overview:
+
+################################################################################
+Architecture Overview
+################################################################################
+
+The primary components of the architecture are depicted below:
+
+.. image:: img/architecture-overview.png
+    :width: 600px
+    :align: center
+
+Like all "layer cake" views of architecture, this diagram is a simplification of the actual architecture. At first glance, you’ll notice there are components expected in blockchain architectures, but also components that might not be as expected All data managed by the platform requires some associated payment. Of course, an application could also manage its own data, and that data could be referenced via a pointer stored on the blockchain.
+
+In addition to the datastore at the base of the architecture, a consensus protocol and peer-to-peer gossip network form the foundation.
+
+Above that, the SpecialK Data & Continuation Access and Cache layer is  an evolution of the existing SpecialK technology (including its decentralized content delivery, key-value database, inter-node messaging, data access patterns, and privacy protecting agent model).
+
+The Casper consensus protocols assure that nodes reach agreement about the contracts, contract state, and transactions for which each node is interested.
+
+Blockchain contracts (aka smart contracts, protocols, or programs) will be written in a new domain-specific language for contracts called Rholang (or in contract languages that compile to Rholang) and then executed on the Rho Virtual Machine on a number of native platforms.
+
+Smart Contracts include some essential system contracts as well as those providing capabilities for tokens and application-supplied contracts.
+
+A metered and monetized content delivery network (CDN) is enabled through token and micro-payment contracts, accessing a mix of blockchain and off-chain data.
+
+The Attention & Reputation Economy provides a model and set of interactions for motivating respectful and economic creation and dissemination of information within social networks.
+
+In the architecture, there will be several APIs, especially at the top layers. Typed APIs will provide access to the RhoVM, Contract Services, and individual contracts. In addition other APIs (including RESTful APIs) will be provided for accessing the CDN, and the Attention & Reputation Economy.
+
+We'll detail these components in the sections below, from the bottom-up. But first, let’s discuss the requirements and software architecture approach motivating this platform solution.

attention-and-reputation-economy.rst

@@ -0,0 +1,17 @@
+.. _attention-and-reputation-economy:
+
+################################################################################
+Attention & Reputation Economy
+################################################################################
+
+From a user-centric perspective, this economy aims to directly but unobstructedly allow value to be placed on the content’s creation, consumption, and promotion. This applies to many types of content.  For example, a short textual post is created, sent to an initial distribution list, read, promoted (liked), and made available to even more readers. Or, a short movie can go through the same workflow. Along these paths, attention is given, and rewards can flow back to the content originator and to promoters. Based on one’s own engagement with the content exchanged to/from one’s connections, each connection’s reputation is computed. The reputation rank can be used subsequently to present content in a manner consistent with how the user has demonstrated attention in the recent past.
+
+For more information, see the original whitepaper, `RChain - The Decentralized and
+Distributed Social Network`_. The latest thinking about Attention & Reputation Economy
+will be described in Slack discussions and blog posts.
+
+.. image:: img/attention-economy.png
+  :width: 400px
+  :align: center
+
+.. _RChain - The Decentralized and Distributed Social Network: http://www.synereo.com/whitepapers/synereo.pdf

blockchain-data.rst

@@ -0,0 +1,100 @@
+.. _blockchain-data:
+
+################################################################################
+Blockchain Data
+################################################################################
+
+Data Semantics
+================================================================================
+
+Like Ethereum, the RChain blockchain will store contracts and their serialized state. UTXO-style transactions will be implemented with simpler system-level contracts. Like Bitcoin and Ethereum, tamper-proof blockchain semantics will be used to create a history of blocks. The blockchain’s main purpose is to efficiently store essential state, any necessary sequencing, and timestamping.
+
+Note that the math underlying this blockchain semantic structure is known as a
+Traced Monoidal Category. For more detail see Masahito Hasegawa's paper on this
+topic, `Recursion from Cyclic Sharing - Traced Monoidal Categories and Models of
+Cyclic Lambda Calculi`_.
+
+The RChain design considers all storage “conserved”, although not all data will be conserved forever. Instead, data storage will be leased and will cost producers of that data in proportion to its size, contract complexity, and lease duration. Unlike Bitcoin and Ethereum, immutable data is not promised to be truly forever; however, a very long lease duration is equivalent.
+
+The simple economic reason justifying leasing is that storage must be paid by someone or it cannot be maintained. We’ve chosen to make the economic mechanism direct. It is really an environmentally unfriendly idea that storage is made "free" only to subsidize it by an unrelated process. A small part of the real cost is measurable in the heat signatures of the data centers that are growing to staggering size. This charging for data as it is accessed also helps reduce "attack" storage, the storage of illegal content to discredit the technology.
+
+A variety of data is supported, including public unencrypted json, encrypted blobs, or a mix. This data can also reference off-platform data stored in private, consortium, public, or obscure locations and formats.
+
+.. _Recursion from Cyclic Sharing - Traced Monoidal Categories and Models of Cyclic Lambda Calculi: http://www.kurims.kyoto-u.ac.jp/~hassei/papers/tlca97.pdf
+
+Data Storage
+===============================================================================
+
+Data will be accessed using the SpecialK semantics and physically stored in a key-value database. A given node can choose which address namespaces it cares about, so not all data needs to be replicated in every node.
+
+Addresses and Sharding/Compositionality
+===============================================================================
+
+In contrast to other blockchains, where addresses are public keys (or hashes
+thereof), RChain’s address space will be structured. This is similar to how both
+the Internet and the web works, with IP addresses and URLs, respectively. A
+structured addressing approach allows programs to talk about “location” in a
+much more nuanced and fine-grained way. This design choice enables fast datalog
+queries based on those namespaces and better system performance by analyzing
+communication patterns to optimize the sharding solution.
+
+This sharding solution allows:
+
+* Dynamic composable sharding based on namespace interaction
+* Concurrent betting on and committing of blocks that don’t conflict.
+* Clients to subscribe to select address spaces without downloading the entire blockchain. Able to impose different policies such as maximum transaction size on different address ranges.
+* Arbitrary number of levels of address namespace.
+
+For additional information, see Linear Types Can Change The Blockchain
+(`pdf`_, `lex`_, `hangout video`_), which describes the inspirational math
+and thinking in this area. Linear Types provide a nice way to decompose the
+blockchain in a scalable fashion. It already has sharding semantics in it,
+that is in the type system.
+
+.. _pdf: https://github.com/leithaus/pi4u/blob/master/ltcctbc/ltcctbc.pdf
+.. _lex: https://github.com/leithaus/pi4u/tree/master/ltcctbc
+.. _hangout video: https://plus.google.com/u/0/events/cmqejp6d43n5cqkdl3iu0582f4k
+
+Namespace Definition and Policy
+===============================================================================
+
+In order to support many of the use cases that users of Bitcoin find valuable as well as broader use cases, namespace definitions will have a corresponding policy set that constrains its use, for example by setting:
+
+* maximum contract code size,
+* maximum data size,
+* minimum lease time,
+* maximum lease time, and
+* other parameters
+
+With policies such as these, a namespace can be defined to provide better guarantees of fast transaction speed and immutability, for example.
+
+Contract Ownership, Transactions, and Messages
+===============================================================================
+
+RChain’s contract accounts, transactions, and messages are analogous to `those in Ethereum`_.
+
+.. _those in Ethereum: http://ethdocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html
+
+Rate-limiting Mechanism
+===============================================================================
+
+RChain’s VM will implement a rate-limiting mechanism that is related to some
+calculation of processing, memory, storage, and bandwidth resources. This mechanism
+is needed in order to recover costs for the hardware and related operations.
+Although Bitcoin and Ethereum (gas) have similar needs, the mechanisms are different.
+Specifically, the metering will not be done at the VM level, but will be injected
+in the contract code (via source-to-source translation that is part of the compilation
+process [#f1]_).
+
+Tokens
+===============================================================================
+
+Somewhat similar to Omni Layer, multiple types of tokens will be supported. These tokens will have different properties depending on their type, including parameters such as:
+
+* supply (initial supply, supply growth function, and final supply),
+* fungibility, and
+* other properties
+
+For each type of token, there will be a link between its class (i.e., its set of distinguishing properties) and the rate-limiting mechanism.
+
+.. [#f1] Ethereum 2.0 is intending on following the same technique.

call-for-participation.rst

@@ -0,0 +1,17 @@
+.. _call-for-participation:
+
+################################################################################
+Call for Participation
+################################################################################
+
+We invite you to participate in RChain's Slack channels, joining via http://slack.rchain.coop.
+
+We need a variety of talent, but most urgently programmers with solid computer
+science, formal methods, and ideally experience with mobile process calculi and
+functional programming. Or, individuals who can demonstrate their ability to
+quickly learn these disciplines.
+
+We need investors to help fund the building out this architecture. Note that there
+are many forward-looking statements in this document, and are subject to many risks.
+
+Contact Lucius Gregory Meredith and / or Ed Eykholt for more information.

introduction/comparison-of-blockchains.rst renamed to comparison-of-blockchains.rst

@@ -35,12 +35,6 @@ Bitcoin, Ethereum, and RChain as currently planned.
 |               | *Runtime architecture*    | Script runs on Bitcoin Core, Libbitcoin, and other native implementations                                                                | Ethereum Virtual Machine implemented on multiple platforms                                                                                       | RhoVM implemented on multiple platforms                                                                                                                                                              |
 +               +---------------------------+------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 |               | *Programming language*    | Script                                                                                                                                   | Solidity, Serpent, LLL and any other languages that get implemented on the EVM.                                                                  | Rholang and any other languages that get implemented on the RhoVM.                                                                                                                                   |
-+               +---------------------------+------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|               | *Name*                    | A smart contract (concept) is not named, but,implemented at an address with a transaction’s locking and unlocking scripts.               | Has one address                                                                                                                                  | Instance may have multiple names; may exist in multiple namespaces.                                                                                                                                  |
-+---------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| **Latency**   | *Block confirmation time* | 10 minutes for 1 block, 30 minutes for de-facto finality.                                                                                | Current: 14 seconds for 1 block, 3 min for de-facto finality.                                                                                    | Variable. Target is sub-second for 1 block. TBD for de-facto finality.                                                                                                                               |
-+               +---------------------------+------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|               | *Block confirmation time* | Affected by large blocks and need for global consensus                                                                                   | Affected by large blocks and need for global consensus                                                                                           | Improved by sharding, bet-by-proposition (versus block), nodes listen to only portion of blockchain                                                                                                  |
 +---------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 | **Block Size**                            | 1MB                                                                                                                                      | Dynamic                                                                                                                                          | Dynamic                                                                                                                                                                                              |
 +-------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

conf.py

@@ -55,9 +55,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = u'0.8'
+version = u'0.8.1'
 # The full version, including alpha/beta/rc tags.
-release = u'0.8'
+release = u'0.8.1'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.