diff --git a/tmdemoapp/docs/README.md b/tmdemoapp/docs/README.md index 3f70a46..507f1ea 100644 --- a/tmdemoapp/docs/README.md +++ b/tmdemoapp/docs/README.md @@ -105,7 +105,7 @@ To compensate, a **Judge** can penalize malicious nodes by forfeiting their secu To execute domain-specific logic the application state machine implements Tendermint's [ABCI interface](http://tendermint.readthedocs.io/projects/tools/en/master/abci-spec.html). It is written in `Scala 2.12`, compatible with `Tendermint v0.19.x` and uses the [`jabci`](https://mvnrepository.com/artifact/com.github.jtendermint/jabci) library providing ABCI definitions for JVM languages. -Tendermint Core orders incoming transactions, passes them to the application and stores them persistently. It also combines transactions into ordered lists – _blocks_. Besides the transaction list, a block also has some [metadata](http://tendermint.readthedocs.io/en/master/specification/block-structure.html) that helps to provide integrity and verifiability guarantees. Basically this metadata consists of two major parts: +Tendermint orders incoming transactions, passes them to the application and stores them persistently. It also combines transactions into ordered lists – _blocks_. Besides the transaction list, a block also has some [metadata](http://tendermint.readthedocs.io/en/master/specification/block-structure.html) that helps to provide integrity and verifiability guarantees. Basically this metadata consists of two major parts: * metadata related to the current block * `height` – an index of this block in the blockchain * block creation time @@ -140,7 +140,7 @@ There are few different operations that can be invoked using the bundled command * `get` operations which read the value associated with a specified key: `get a/b` * `run` operations which await for the cluster to respond with the function result: `run factorial(a/b)` -`put` operations are _effectful_ and are explicitly changing the application state. To process such operation, **TM Core** sends a transaction to the state machine which applies this transaction to its state, typically changing the associated value of the specified key. If requested operation is a computational `put`, state machine finds the corresponding function from a set of previously hardcoded ones, executes it and then assigns the result to the target key. +`put` operations are _effectful_ and are explicitly changing the application state. To process such operation, Tendermint sends a transaction to the state machine which applies this transaction to its state, typically changing the associated value of the specified key. If requested operation is a computational `put`, state machine finds the corresponding function from a set of previously hardcoded ones, executes it and then assigns the result to the target key. Correctness of `put` operations can be verified by the presence of a corresponding transaction in a correctly formed block and an undisputed `app_hash` in the next block. Basically, this would mean that a cluster has reached quorum regarding this transaction processing. @@ -149,24 +149,11 @@ Correctness of `put` operations can be verified by the presence of a correspondi `run` operations are just a shortcut to the combination of `put` and `get` requests. To perform such operation, the client first requests to assign the result of the specified function to a certain key and then queries the value associated with this key. ## Installation and run -To run the application, the node machine needs Scala 2.12 with `sbt`, [Tendermint](http://tendermint.readthedocs.io/en/master/install.html) and GNU `screen`. +To run the application, the node machine needs Scala 2.12 with `sbt`, [Tendermint](http://tendermint.readthedocs.io/en/master/install.html) and GNU `screen`. To execute operations the client machine needs Python 2.7 with `sha3` package installed. -To execute operations a client machine needs Python 2.7 with `sha3` package installed. +This demo contains scripts that automate running a cluster of 4 nodes (the smallest BFT ensemble possible) on the local machine. To prepare configuration files, run `source local-cluster-init.sh`. To start the cluster, run `local-cluster-start.sh` which starts 9 screen instances: `app[1-4]` – application backends, `tm[1-4]` – corresponding Tendermint instances and `judge` – Judge stub. Cluster initialization might take few seconds, after which the client can query Tendermint RPC endpoints using any of `46158`, `46258`, `46358` or `46458` ports. -There are also scripts that automate deployment and running 4 application nodes (the smallest BFT ensemble possible) on the local machine. - -```bash -source local-cluster-init.sh -``` -To prepare configuration files, run `source local-cluster-init.sh`. To start the -`local-cluster-init.sh` prepares all required configuration files to launch 4-node cluster locally. - -```bash -./local-cluster-start.sh -``` -`local-cluster-start.sh` starts 9 screen instances (`app[1-4]` instances for the Apps, `tm[1-4]` – for corresponding TM Cores, and `judge` for the Judge). Cluster initialization may take some seconds, after that the client can query TM Cores' RPC endpoints on any of `46158`, `46258`, `46358` or `46458` ports. - -Other scripts allow to temporarily stop (`local-cluster-stop.sh`), delete (`local-cluster-delete.sh`) and reinitialize/rerun (`local-cluster-reset.sh`) the cluster. +Other scripts allow to temporarily stop (`local-cluster-stop.sh`), delete (`local-cluster-delete.sh`) and reinitialize (`local-cluster-reset.sh`) the cluster. ## Sending queries Examples below use `localhost:46157` to query TM Core on 1st local "node", to access other nodes one needs to use other endpoints (`46257`, `46357`, `46457`). In normal conditions, all endpoints behave the same way.