LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

Ran through the docs, more cleanup, everything except ibc ready

Browse Source
This commit is contained in:
Ethan Frey
2017-06-19 15:13:46 +02:00
parent 1e76d92d85
commit 9bb3493f78
4 changed files with 58 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/guide/basecoin-plugins.md
+30 -15
View File
@@ -14,24 +14,28 @@ functionality. The Counter plugin is bundled with basecoin, so if you have
already [installed basecoin](install.md) then you should be able to run a full
node with `counter` and the a light-client `countercli` from terminal. The
Counter plugin is just like the `basecoin` tool. They both use the same
library of commands, including one for signing and broadcasting `SendTx`.
library of commands, including one for signing and broadcasting `SendTx`.
Counter transactions take two custom inputs, a boolean argument named `valid`,
and a coin amount named `countfee`. The transaction is only accepted if both
`valid` is set to true and the transaction input coins is greater than
`countfee` that the user provides.
`countfee` that the user provides.
A new blockchain can be initialized and started just like with in the [previous
guide](basecoin-basics.md):
```
# WARNING: this wipes out data - but counter is only for demos...
rm -rf ~/.counter
countercli reset_all
counter init
countercli keys new cool
countercli keys new friend
GENKEY=`countercli keys get cool -o json | jq .pubkey.data`
GENJSON=`cat ~/.counter/genesis.json`
echo $GENJSON | jq '.app_options.accounts[0].pub_key.data='$GENKEY > ~/.counter/genesis.json
echo $GENJSON | jq '.app_options.accounts[0].pub_key.data='$GENKEY > ~/.counter/genesis.json
counter start
@@ -58,7 +62,7 @@ countercli tx counter --name cool --amount=1mycoin --sequence=3 --valid
The first transaction is rejected by the plugin because it was not marked as
valid, while the second transaction passes. We can build plugins that take
many arguments of different types, and easily extend the tool to accomodate
them. Of course, we can also expose queries on our plugin:
them. Of course, we can also expose queries on our plugin:
```
countercli query counter
@@ -70,15 +74,25 @@ If we send another transaction, and then query again, we will see the value
increment:
```
countercli tx counter --name cool --amount=1mycoin --sequence=4 --valid
countercli tx counter --name cool --amount=2mycoin --sequence=4 --valid --countfee=2mycoin
countercli query counter
```
The value Counter value should be 2, because we sent a second valid transaction.
Notice how the result of the query comes with a proof. This is a Merkle proof
that the state is what we say it is. In a latter [guide on InterBlockchain
Communication](ibc.md), we'll put this proof to work!
And this time, since we sent a countfee (which must be less than or equal to the
total amount sent with the tx), it stores the `TotalFees` on the counter as well.
Even if you don't see it in the UI, the result of the query comes with a proof.
This is a Merkle proof that the state is what we say it is, and ties that query
to a particular header. Behind the scenes, `countercli` will not only verify that
this state matches the header, but also that the header is properly signed by
the known validator set. It will even update the validator set as needed, so long
as there have not been major changes and it is secure to do so. So, if you wonder
why the query may take a second... there is a lot of work going on in the
background to make sure even a lying full node can't trick your client.
In a latter [guide on InterBlockchainCommunication](ibc.md), we'll use these
proofs to post transactions to other chains.
Now, before we implement our own plugin and tooling, it helps to understand the
`AppTx` and the design of the plugin system.
@@ -91,8 +105,8 @@ some data.
```golang
type AppTx struct {
Gas int64 `json:"gas"`
Fee Coin `json:"fee"`
Gas int64 `json:"gas"`
Fee Coin `json:"fee"`
Input TxInput `json:"input"`
Name string `json:"type"` // Name of the plugin
Data []byte `json:"data"` // Data for the plugin to process
@@ -161,18 +175,19 @@ more details.
First is the `cmd/counter/main.go`, which drives the program. It can be left
alone, but you should change any occurrences of `counter` to whatever your
plugin tool is going to be called.
plugin tool is going to be called. You must also register your plugin(s) with
the basecoin app with `RegisterStartPlugin`.
The light-client which is located in `cmd/countercli/main.go` allows for is
where transaction and query commands are designated. Similarity this command
can be mostly left alone besides replacing the application name and adding
references to new plugin commands
references to new plugin commands
Next is the custom commands in `cmd/countercli/commands/`. These files is
where we extend the tool with any new commands and flags we need to send
transactions or queries to our plugin. Note the `init()` function, where we
register a new transaction subcommand with `RegisterTxSubcommand`, and where we
load the plugin into the Basecoin app with `RegisterStartPlugin`.
transactions or queries to our plugin. You define custom `tx` and `query`
subcommands, which are registered in `main.go` (avoiding `init()`
auto-registration, for less magic and more control in the main executable).
Finally is `plugins/counter/counter.go`, where we provide an implementation of
the `Plugin` interface. The most important part of the implementation is the