This commit is contained in:
Alexander Demidko 2018-06-24 19:25:51 +03:00 committed by GitHub
parent 015fdbfae4
commit e78dd4ce10
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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.