From the above abi, we can see that `currency` contract accepts an action called `transfer` that accepts message with fields `from`, `to`, and `amount`.
1589302ms thread-0 main.cpp:271 operator() ] Converting argument to binary...
...
...
@@ -540,18 +602,6 @@
}
}
```
We can check the balance of `tester` inside its scope, and see it has balance of 50
```
./eosc get table tester currency account
{
"rows": [{
"account": "account",
"balance": 50
}
],
"more": true
}
```
Now we can transfer it from `tester` to `inita` and require the permission of `tester`. This should drain the balance of `tester` to 0.
...
...
@@ -626,6 +676,30 @@
[...snipped...]
```
@section querycontract Querying Contract
After doing the transfer action on `currency` contract, we can verify the amount of token held by each account by looking at `currency`'s `account` table.
This table is stored on the scope of each account instead of on `currency` scope.
```
$./eosc get table tester currency account
{
"rows": [],
"more": false
}
$./eosc get table inita currency account
{
"rows": [{
"account": "account",
"balance": 50
}
],
"more": true
}
```
@section particularnode Connecting to Particular Node
By default, `eosc` will connect to `eosd` running on localhost port 8888. You can connect to another `eosd` node by specifying its host and port.
("enable-stale-production",boost::program_options::bool_switch()->notifier([this](boole){my->_production_enabled=e;}),"Enable block production, even if the chain is stale.")
("required-participation",boost::program_options::bool_switch()->notifier([this](inte){my->_required_producer_participation=uint32_t(e*config::Percent1);}),"Percent of producers (0-99) that must be participating in order to produce blocks")
To date, all work done to experiment with the EOS blockchain has been performed using a single instance of eosd hosting all 21 block producers. While this is a perfectly valid solution for validating features of the blockchain, developing new contracts, or whatever, it does not scale. Nor does it expose the sort of issues raised when contract and block data must be shared across multiple instances. Providing the ability to scale involves deploying multiple eosd nodes across many hosts and lining then into a peer-to-peer (p2p) network. Composing this network involves tailoring and distributing configuration files, coordinating starts and stops and other tasks.
Doing this manually is a tedious task and easily error prone. Fortunately a solution is provided, in the form of the Launcher application, described below.
...
...
@@ -33,26 +33,26 @@ Network topology or "shape" describes how the nodes are connected in order to sh
The Launcher has definitions of three different network "shapes" based on inter-nodal connections, which can be selected by a command line option, or you can supply your own network topology by editing the Launcher generated configuration file.
####Ring network
####Ring network
![](ring.png"Ring Diagram")
This is the simplest network, where each node identifies just the node next to it as it's only peer.
####Star network
####Star network
![](star.png"Star Diagram")
A "star" is intended to support the use larger number nodes in the testnet. In this case the number of peers connected to a node and the distribution of those nodes varies based on the number of nodes in the network.
A "star" is intended to support a larger number of nodes in the testnet. In this case the number of peers connected to a node and the distribution of those nodes varies based on the number of nodes in the network.
####Mesh network
####Mesh network
![](mesh.png"Mesh Diagram")
In a "mesh" network, each node is connected to as many peer nodes as possible.
#The Launcher Application
#The Launcher Application
To address the complexity implied by distributing multiple eosd nodes across a LAN or a wider network, the launcher application was created.
Based on a handful of command line arguments the Launcher is able to compose per-node configuration files, distribute these files securely amongst the peer hosts, then start up the multiple instances of eosd.
Eosd instances started this way have their output logged in individual text files. Finally the launcher application is also able to shut down some or all of the test network.
##Running the Launcher application
##Running the Launcher application
The launcher program is used to configure and deploy producing and non-producing eosd nodes that talk to each other using configured routes. The configuration for each node is stored in separate directories, permitting multiple nodes to be active on the same host, assuming the machine has sufficient memory and disk space for multiple eosd instances. The launcher makes use of multiple configuration sources in order to deploy a testnet. A handful of command line arguments can be used to set up simple local networks.
...
...
@@ -145,7 +145,7 @@ The ssh helper fields are paths to ssh and scp, an identity if necessary, and an
The rest of the testnet.json file is the collection of node descriptors. The fragment shown above was created with the command line `programs/launcher/launcher -p6 -s mesh -o testnet.json` and then edited to refer to a remote host named "remoteserv."
###Elements Of The JSON File
###Elements Of The JSON File
This table describes all of the key/value pairs used in the testnet.json file.
|Value | Description
...
...
@@ -177,7 +177,7 @@ keys | specify the authentication tokens for this node.
peers | this list indicates the other nodes in the network to which this one actively connects. Since this file may be edited to alter the hostname, public name, or p2p port values, the peers list here holds aliases for the actual endpoints eventually written to the individual config.ini files.
producers | this list identifies which of the producers from the genesis.json file are held by this node. Note that the launcher uses a round-robin algorithm to spread the producer instances across the producing nodes.
###Provisioning Distributed Servers
###Provisioning Distributed Servers
The ssh_helper section of the testnet.json file contains the ssh elements necessary to connect and issue commands to other servers. In addition to the ssh_helper section which provides access to global configuration settings, the per-node configuration may provide overriding identity and connection arguments.
It is also necessary to provision the server by at least copying the eosd executable, and the genesis.json files to their appropriate locations relative to some named EOS root directory. For example, I defined the EOS root to be `/home/phil/blockchain/eos`. When run, the launcher will run through a variety of shell commands using ssh and finally using scp to copy a config.ini file to the appropriate data directory on the remote.
...
...
@@ -196,7 +196,7 @@ The launcher app creates a separate date and configuration directory for each no
A file called "last_run.json" contains hints for a later instance of the launcher to be able to kill local and remote nodes when run with -k.
#What Remains To Be Done
#What Remains To Be Done
Functionality that remains to be implemented: caching signed transactions then purging them on a schedule. Sending summaries of blocks rather than whole blocks. Optimizing the routing between nodes. Failover during new node synchronization if a peer fails to respond timely enough
