"RCP" is a typo in architecture-docs/img/architecture-overview.png

It should be "RPC". And json is usually capitalized, so it should be "JSON RPC".

But the core RPC mechanism is actually GRPC.

Kent - Today at 12:08 PM Just popped in here to say that http://rchain-architecture.readthedocs.io/en/latest/execution_model/consensus_protocol.html is fairly outdated. Michael Birch and I plan to write up a "cbc-casper in practice" to replace it.
dckc - Today at 12:09 PM replace as in pull request? or separate document?
Kent - Today at 12:10 PM I was thinking a separate document but I'm sure copy/pasting it over and making it into a PR isn't too much effort

Last (SUCCESSFUL) Latest build Completed Jan. 18, 2018. 5:32 a.m.

Since then, Latest builds on https://readthedocs.org have failed:

• Completed March 2, 2018. 12:47 a.m.(FAILED)

• Completed March 25, 2018. 5:57 a.m. (FAILED)

Live version at http://rchain-architecture.readthedocs.io/en/latest/ is outdated (Jan 18).

@JoshyOrndorff writes October 27 12:16 AM:

Last sentence in the abstract "The platform includes a modular, end-to-end design that commits to correct-by-construction software and industrial extensibility." <- What is industrial extensibility?

Good question.

I wonder if some sort of footnote is appropriate for the Mercury time-frame:

Since the contract language and its VM are build [sic] from the formal specifications of provable mathematics, and since the compiler pipeline and engineering approach is correct by construction, we expect the platform will be regarded as trustworthy.

I see some K framework stuff for Rholang has been started, but for the VM, we have thousands of lines of code before anyone even attempted to state the correctness theorem, yes?

Neither @JoshOrndorff quite understand what "Data separation to reduce unnecessary data replication" means in this bullet:

• Data separation to reduce unnecessary data replication of otherwise independent tokens and smart contracts.

@edeykholt @pyrocto @leithaus clues?

Derived from the rho-calculus computational formalism, ...

sample code dosn't compile against the RHolang specs 0.2
Below is execution script and generated errors:

➜ src git:(master) ✗ docker run -it --mount type=bind,source="$(pwd)",target=/tmp rchain/rnode --eval /tmp/cell.rho
Syntax Error, trying to recover and continue parse... for input symbol "" spanning from unknown:3/10(57) to unknown:3/13(60)
Exception in thread "main" java.lang.Exception: Unrecoverable Syntax Error
at coop.rchain.rholang.syntax.rholang_mercury.parser.unrecovered_syntax_error(parser.java:744)
at java_cup.runtime.lr_parser.parse(lr_parser.java:731)
at coop.rchain.rholang.syntax.rholang_mercury.parser.pProc(parser.java:731)
at coop.rchain.node.Main$.buildAST(main.scala:213)
at coop.rchain.node.Main$.buildNormalizedTerm(main.scala:203)
at coop.rchain.node.Main$.main(main.scala:122)
at coop.rchain.node.Main.main(main.scala)

I just saw this question in #rholang. The good news is: the published docs have reasonable answers.

You know where you can get a high level overview over how things are connected here, like how is Rho calc and Rholang connected, and if I go through the Rholang tutorial do I learn much about Rho calc, and how far is this implemented in RChain etc.?

The information about how Rho calc and Rholang are connected belongs in RChain Architecture document... ah... good news: there is a section on The Formalism: Rho-Calculus. Some of the material there is somewhat aspirational; for example, rnode doesn't have any static behavioral type checking yet.

There are two Rholang tutorials cited from developer.rchain.coop; both of them cover all the basics of rho calculus: Nil, input, output, parallel composition, and dereference (reflection). If you're interested in the theory, look at the citations from the arch doc.

To learn more, see the RChain Community Calendar for events such as the weekly Rholang office hours on Thursdays.

RE: https://github.com/rchain/architecture-docs/blob/master/introduction/comparison-of-blockchains.rst

In the "Scalability/Transaction Throughput" row, I think a better distinction should be made between what a "COMM" event is and what a "transaction" is. At RCon3 there was a clarification over the network throughput for test net. It was stated that the aim of RChain was 40K+ COMM events/second - not transactions. I think it's important to distinguish between these two things, as COMM events are atomic. It's important to note that [Single COMM Event != Single Token Transaction].

Are we betting on propositions in Mercury? Here's hoping for time to pore over the code and find relevant specs:

Unlike Ethereum’s betting on a whole blocks, RChain’s betting is on logical propositions. A proposition is a set of statements about the blockchain, for example: which transactions (i.e. proposed state transitions) must be included, in which order, which transactions should not be included, or other properties. A concrete example of a proposition is: “transaction t should occur before transaction s” and “transaction r should not be included”. For more information, see the draft specification Logic for Betting – On Betting on Propositions.

https://rchain-architecture.readthedocs.io/en/latest/execution_model/consensus_protocol.html

In the last sentence of this page.

For more details join the #rhovm channel on the RChain Slack here. Compiler work can be seen on GitHub.

The provided link in the word GitHub is broken

IOU better issue description.

@pyrocto ping? does this reach you?

context: RChain Architecture document revision

The high-level architecture diagram seems more up-to-date than the text around it:

The RChain Network implements direct node-to-node communication, where each node runs the RChain platform and a set of dApps on the top of it.

A node runs a set of dApps? I wonder what that means, exactly.

The diagram shows:

1. Each node runs a set of "Node-local Contracts" (is that terminology preferred over "system contracts"? I suppose it's more clear.)
2. On-chain contracts on top of the Casper consensus protocol.

The heart of an RChain is the Rho Virtual Machine (RhoVM) Execution Environment, which runs multiple RhoVMs that are each executing a smart contract. These execute concurrently and are multi-threaded.

Each RhoVM executes one smart contract? That would be a strange way to define "smart contract". I suppose each shard / namespace has an independent distributed RhoVM, but each of those RhoVMs runs many contracts in parallel, no?

This concurrency, which is designed around on the formal models of mobile process calculi, along with an application of compositional namespaces, allows for what are in effect multiple blockchains per node.

A node can participate in multiple shards or regions, but "multiple blockchains per node" seems passe.

This multi-chain, independently executing virtual machine instances is in sharp contrast to a “global compute” design which constrains transactions to be executed sequentially, on a single virtual machine.

There's still a "global compute" design to RChain, yes? i.e. the distributed RhoVM that results from the Casper protocol. It's just that the RhoVM isn't sequential.

In addition, each node can be configured to subscribe to and process the namespaces (blockchains) in which it is interested.

Wait... that's in addition? Now I'm really lost.