Freshened up docs with --genesis and Makefile
This commit is contained in:
Ethan Frey
parent
64b434a375
commit
44e9ecce43
|
|
@ -19,7 +19,7 @@ The former is the running node. The latter is a command-line light-client.
|
|||
|
||||
## Generate some keys
|
||||
|
||||
Let's generate two keys, one to receive an initial allocation of coins,
|
||||
Let's generate two keys, one to receive an initial allocation of coins,
|
||||
and one to send some coins to later:
|
||||
|
||||
```
|
||||
|
|
@ -74,12 +74,17 @@ Basecli is used for sending transactions and querying the state.
|
|||
Leave Basecoin running and open a new terminal window. Here run:
|
||||
|
||||
```
|
||||
basecli init --chain-id=test_chain_id --node=tcp://localhost:46657
|
||||
basecli init --node=tcp://localhost:46657 --genesis=$HOME/.basecoin/genesis.json
|
||||
```
|
||||
|
||||
Note it will ask you to verify the validator hash. For a blockchain on your local computer, don't worry about it.
|
||||
If you're connecting to a blockchain over the internet, you should verify that the validator hash is correct.
|
||||
This is so that all queries done with `basecli` can be cryptographically proven to be correct according to a known validator set.
|
||||
If you provide the genesis file to basecli, it can calculate the proper chainID
|
||||
and validator hash. Basecli needs to get this information from some trusted
|
||||
source, so all queries done with `basecli` can be cryptographically proven to
|
||||
be correct according to a known validator set.
|
||||
|
||||
Note: that --genesis only works if there have been no validator set changes
|
||||
since genesis. If there are validator set changes, you need to find the current
|
||||
set through some other method.
|
||||
|
||||
## Send transactions
|
||||
|
||||
|
|
@ -97,7 +102,7 @@ The first account is flush with cash, while the second account doesn't exist.
|
|||
Let's send funds from the first account to the second:
|
||||
|
||||
```
|
||||
basecli tx send --name=cool --amount=1000mycoin --to=0x$YOU --sequence=1
|
||||
basecli tx send --name=cool --amount=1000mycoin --to=$YOU --sequence=1
|
||||
```
|
||||
|
||||
Now if we check the second account, it should have `1000` 'mycoin' coins!
|
||||
|
|
@ -140,8 +145,8 @@ See `basecli tx send --help` for additional details.
|
|||
Even if you don't see it in the UI, the result of every query comes with a proof.
|
||||
This is a Merkle proof that the result of the query is actually contained in the state.
|
||||
and the state's Merkle root is contained in a recent block 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.
|
||||
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
|
||||
|
|
@ -249,9 +254,9 @@ transaction.
|
|||
|
||||
## Conclusion
|
||||
|
||||
In this guide, we introduced the `basecoin` and `basecli` tools,
|
||||
demonstrated how to start a new basecoin blockchain and how to send tokens between accounts,
|
||||
and discussed the underlying data types for accounts and transactions, specifically the `Account` and the `SendTx`.
|
||||
In this guide, we introduced the `basecoin` and `basecli` tools,
|
||||
demonstrated how to start a new basecoin blockchain and how to send tokens between accounts,
|
||||
and discussed the underlying data types for accounts and transactions, specifically the `Account` and the `SendTx`.
|
||||
In the [next guide](basecoin-plugins.md), we introduce the Basecoin plugin system,
|
||||
which uses a new transaction type, the `AppTx`, to extend the functionality of
|
||||
the Basecoin system with arbitrary logic.
|
||||
|
|
|
|||
|
|
@ -42,10 +42,10 @@ The default files are stored in `~/.counter`. In another window we can
|
|||
initialize the light-client and send a transaction:
|
||||
|
||||
```
|
||||
countercli init --chain-id=test_chain_id --node=tcp://localhost:46657
|
||||
countercli init --node=tcp://localhost:46657 --genesis=$HOME/.counter/genesis.json
|
||||
|
||||
YOU=$(countercli keys get friend | awk '{print $2}')
|
||||
countercli tx send --name=cool --amount=1000mycoin --to=0x$YOU --sequence=1
|
||||
countercli tx send --name=cool --amount=1000mycoin --to=$YOU --sequence=1
|
||||
```
|
||||
|
||||
But the Counter has an additional command, `countercli tx counter`, which
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ The results of a query can thus be used as proof in an `IBCPacketPostTx`.
|
|||
## Relay
|
||||
|
||||
While we need all these packet types internally to keep track of all the
|
||||
proofs on both chains in a secure manner, for the normal work-flow,
|
||||
proofs on both chains in a secure manner, for the normal work-flow,
|
||||
we can run a relay node that handles the cross-chain interaction.
|
||||
|
||||
In this case, there are only two steps. First `basecoin relay init`,
|
||||
|
|
@ -271,11 +271,11 @@ basecoin1 start &> basecoin1.log &
|
|||
Note the `sed` command to replace the ports in the config file.
|
||||
You can follow the logs with `tail -f basecoin1.log`
|
||||
|
||||
Now we can attach the client to the chain and verify the state.
|
||||
Now we can attach the client to the chain and verify the state.
|
||||
The first account should have money, the second none:
|
||||
|
||||
```
|
||||
basecli1 init --chain-id=$CHAINID1 --node=tcp://localhost:${RPC_PORT1}
|
||||
basecli1 init --node=tcp://localhost:${RPC_PORT1} --genesis=${BCHOME1_SERVER}/genesis.json
|
||||
basecli1 query account $MONEY
|
||||
basecli1 query account $GOTNONE
|
||||
```
|
||||
|
|
@ -304,11 +304,11 @@ sed -ie "s/4665/$PORT_PREFIX2/" $BCHOME2_SERVER/config.toml
|
|||
basecoin2 start &> basecoin2.log &
|
||||
```
|
||||
|
||||
Now attach the client to the chain and verify the state.
|
||||
Now attach the client to the chain and verify the state.
|
||||
The first account should have money, the second none:
|
||||
|
||||
```
|
||||
basecli2 init --chain-id=$CHAINID2 --node=tcp://localhost:${RPC_PORT2}
|
||||
basecli2 init --node=tcp://localhost:${RPC_PORT2} --genesis=${BCHOME2_SERVER}/genesis.json
|
||||
basecli2 query account $MOREMONEY
|
||||
basecli2 query account $BROKE
|
||||
```
|
||||
|
|
@ -316,7 +316,7 @@ basecli2 query account $BROKE
|
|||
### Connect these chains
|
||||
|
||||
OK! So we have two chains running on your local machine, with different
|
||||
keys on each. Let's hook them up together by starting a relay process to
|
||||
keys on each. Let's hook them up together by starting a relay process to
|
||||
forward messages from one chain to the other.
|
||||
|
||||
The relay account needs some money in it to pay for the ibc messages, so
|
||||
|
|
@ -336,7 +336,7 @@ basecli2 tx send --amount=100000mycoin --sequence=1 --to=$RELAY_ADDR --name=more
|
|||
basecli2 query account $RELAY_ADDR
|
||||
```
|
||||
|
||||
Now we can start the relay process.
|
||||
Now we can start the relay process.
|
||||
|
||||
```
|
||||
basecoin relay init --chain1-id=$CHAINID1 --chain2-id=$CHAINID2 \
|
||||
|
|
@ -359,7 +359,7 @@ The hard part is over, we set up two blockchains, a few private keys, and
|
|||
a secure relay between them. Now we can enjoy the fruits of our labor...
|
||||
|
||||
```
|
||||
# Here's an emptt account on test-chain-2
|
||||
# Here's an empty account on test-chain-2
|
||||
basecli2 query account $BROKE
|
||||
```
|
||||
|
||||
|
|
@ -375,8 +375,8 @@ sleep 2
|
|||
basecli2 query account $BROKE
|
||||
```
|
||||
|
||||
You're no longer broke! Cool, huh?
|
||||
Now have fun exploring and sending coins across the chains.
|
||||
You're no longer broke! Cool, huh?
|
||||
Now have fun exploring and sending coins across the chains.
|
||||
And making more accounts as you want to.
|
||||
|
||||
## Conclusion
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
# Install
|
||||
|
||||
If you aren't used to compile go programs and just want the released
|
||||
version of the code, please head to our [downloads](https://tendermint.com/download)
|
||||
page to get a pre-compiled binary for your platform.
|
||||
|
||||
On a good day, basecoin can be installed like a normal Go program:
|
||||
|
||||
```
|
||||
|
|
@ -18,7 +22,12 @@ make all
|
|||
```
|
||||
|
||||
This will create the `basecoin` binary in `$GOPATH/bin`.
|
||||
Note the `make get_vendor_deps` command will install `glide` and the correct version of all dependencies.
|
||||
`make all` implies `make get_vendor_deps` and uses `glide` to install the
|
||||
correct version of all dependencies. It also tests the code, including
|
||||
some cli tests to make sure your binary behaves properly.
|
||||
|
||||
If you need another branch, make sure to run `git checkout <branch>` before the `make` commands.
|
||||
If you need another branch, make sure to run `git checkout <branch>`
|
||||
before `make all`. And if you switch branches a lot, especially
|
||||
touching other tendermint repos, you may need to `make fresh` sometimes
|
||||
so glide doesn't get confused with all the branches and versions lying around.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue