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

docs: minor edits throughout

Browse Source
This commit is contained in:
Zach Ramsay
2017-08-28 19:45:19 -04:00
parent 5fa668a94d
commit 71283673de
3 changed files with 135 additions and 157 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/quark/glossary.md
+77 -81
View File
@@ -1,28 +1,29 @@
# Glossary
This glossary defines many terms used throughout documentation of Quark. If
This glossary defines many terms used throughout documentation of Quark. If
there is every a concept that seems unclear, check here. This is mainly to
provide a background and general understanding of the different words and
concepts that are used. Other documents will explain in more detail how to
concepts that are used. Other documents will explain in more detail how to
combine these concepts to build a particular application.
## Transaction (tx)
## Transaction
A transaction is a packet of binary data that contains all information to
validate and perform an action on the blockchain. The only other data that it
interacts with is the current state of the chain (key-value store), and
it must have a deterministic action. The tx is the main piece of one request.
it must have a deterministic action. The transaction is the main piece of one
request.
We currently make heavy use of [go-wire](https://github.com/tendermint/go-wire)
and [data](https://github.com/tendermint/go-wire/tree/master/data) to provide
binary and json encodings and decodings for `struct` or interface` objects.
Here, encoding and decoding operations are designed to operate with interfaces
nested any amount times (like an onion!). There is one public `TxMapper`
in the basecoin root package, and all modules can register their own transaction types there. This allows us to deserialize the entire tx in
one location (even with types defined in other repos), to easily embed
an arbitrary tx inside another without specifying the type, and provide
an automatic json representation to provide to users (or apps) to
inspect the chain.
in the basecoin root package, and all modules can register their own transaction
types there. This allows us to deserialize the entire tx in one location (even
with types defined in other repos), to easily embed an arbitrary tx inside another
without specifying the type, and provide an automatic json representation to
provide to users (or apps) to inspect the chain.
Note how we can wrap any other transaction, add a fee level, and not worry
about the encoding in our module any more?
@@ -39,54 +40,54 @@ type Fee struct {
As a request passes through the system, it may pick up information such as the
authorization it has received from another middleware, or the block height the
request runs at. In order to carry this information between modules it is
saved to the context. further, it all information must be deterministic from
the context in which the request runs (based on the tx and the block it was
included in) and can be used to validate the tx.
request runs at. In order to carry this information between modules it is
saved to the context. Further, all information must be deterministic from
the context in which the request runs (based on the transaction and the block
it was included in) and can be used to validate the transaction.
## Data Store
To be able to provide proofs to Tendermint, we keep all data in one key-value
(kv) store which is indexed with a merkle tree. This allows for the easy
In order to provide proofs to Tendermint, we keep all data in one key-value
(kv) store which is indexed with a merkle tree. This allows for the easy
generation of a root hash and proofs for queries without requiring complex
logic inside each module. Standardization of this process also allows powerful
light-client tooling as any store data may be verified on the fly.
The largest limitation of the current implemenation of the kv-store is that
interface that the application must use can only `Get` and `Set` single data
points. This said, there are some data structures like queues and range
points. That said, there are some data structures like queues and range
queries that are available in `state` package. These provide higher-level
functionality in a standard format, but have not yet been integrated into the
kv-store interface.
## Isolation
One of the main arguments for blockchain is security. So while we encourage
One of the main arguments for blockchain is security. So while we encourage
the use of third-party modules, all developers must be vigilant against
security holes. If you use the
[stack](https://github.com/tendermint/basecoin/tree/unstable/stack)
security holes. If you use the
[stack](https://github.com/cosmos/cosmos-sdk/tree/master/stack)
package, it will provide two different types of compartmentalization security.
The first is to limit the working kv-store space of each module. When
`DeliverTx` is called for a module, it is never given the entire data store,
but rather only its own prefixed subset of the store. This is achieved by
prefixing all keys transparently with `<module name> + 0x0`, using the null
byte as a separator. Since the module name must be a string, no malicious
byte as a separator. Since the module name must be a string, no malicious
naming scheme can ever lead to a collision. Inside a module, we can
write using any key value we desire without the possibility that we
have modified data belonging to separate module.
The second is to add permissions to the transaction context. The tx context
can specify that the tx has been signed by one or multiple specific
The second is to add permissions to the transaction context. The transaction
context can specify that the tx has been signed by one or multiple specific
[actors](https://github.com/tendermint/basecoin/blob/unstable/context.go#L18).
A tx will only be executed if the permission requirements have been fulfilled.
For example the sender of funds must have signed, or 2 out of 3
multi-signature actors must have signed a joint account. To prevent the
A transactions will only be executed if the permission requirements have been
fulfilled. For example the sender of funds must have signed, or 2 out of 3
multi-signature actors must have signed a joint account. To prevent the
forgery of account signatures from unintended modules each permission
is associated with the module that granted it (in this case
[auth](https://github.com/tendermint/basecoin/tree/unstable/modules/auth)),
[auth](https://github.com/cosmos/cosmos-sdk/tree/master/modules/auth)),
and if a module tries to add a permission for another module, it will
panic. There is also protection if a module creates a brand new fake
panic. There is also protection if a module creates a brand new fake
context to trick the downstream modules. Each context enforces
the rules on how to make child contexts, and the stack middleware builder
enforces that the context passed from one level to the next is a valid
@@ -94,7 +95,7 @@ child of the original one.
These security measures ensure that modules can confidently write to their
local section of the database and trust the permissions associated with the
context, without concern of interference from other modules. (Okay,
context, without concern of interference from other modules. (Okay,
if you see a bunch of C-code in the module traversing through all the
memory space of the application, then get worried....)
@@ -102,7 +103,7 @@ memory space of the application, then get worried....)
The ABCI interface is handled by `app`, which translates these data structures
into an internal format that is more convenient, but unable to travel over the
wire. The basic interface for any code that modifies state is the `Handler`
wire. The basic interface for any code that modifies state is the `Handler`
interface, which provides four methods:
```golang
@@ -123,11 +124,11 @@ interoperability, much like `http.Handler` does in golang web development.
## Middleware
Middleware is a series of processing steps that any request must travel through
before (and after) executing the registered `Handler`. Some examples are a
logger (that records the time before executing the tx, then outputs info -
including duration - after the execution), of a signature checker (which
unwraps the tx by one layer, verifies signatures, and adds the permissions to
the Context before passing the request along).
before (and after) executing the registered `Handler`. Some examples are a
logger (that records the time before executing the transaction, then outputs
info - including duration - after the execution), of a signature checker (which
unwraps the transaction by one layer, verifies signatures, and adds the
permissions to the Context before passing the request along).
In keeping with the standardization of `http.Handler` and inspired by the
super minimal [negroni](https://github.com/urfave/negroni/blob/master/README.md)
@@ -154,31 +155,31 @@ self-sufficient. Common elements of a module are:
* middleware (to handler any wrapper transactions)
To enable a module, you must add the appropriate middleware (if any) to the
stack in `main.go` for the client application (Quark default:
stack in `main.go` for the client application (default:
`basecli/main.go`), as well as adding the handler (if any) to the dispatcher
(Quark default: `app/app.go`). Once the stack is compiled into a `Handler`,
then each tx is handled by the appropriate module.
(default: `app/app.go`). Once the stack is compiled into a `Handler`,
then each transaction is handled by the appropriate module.
## Dispatcher
We usually will want to have multiple modules working together, and need to
make sure the correct transactions get to the correct module. So we have have
`coin` sending money, `roles` creating multi-sig accounts, and `ibc` following
other chains all working together without interference.
make sure the correct transactions get to the correct module. So we have the
`coin` sending money, `roles` to create multi-sig accounts, and `ibc` for
following other chains all working together without interference.
After the chain of middleware, we can register a `Dispatcher`, which also
implements the `Handler` interface. We then register a list of modules with
implements the `Handler` interface. We then register a list of modules with
the dispatcher. Every module has a unique `Name()`, which is used for
isolating its state space. We use this same name for routing tx. Each tx
implementation must be registed with go-wire via `TxMapper`, so we just look
at the registered name of this tx, which should be of the form
isolating its state space. We use this same name for routing transactions.
Each transaction implementation must be registed with go-wire via `TxMapper`,
so we just look at the registered name of this tx, which should be of the form
`<module name>/xxx`. The dispatcher grabs the appropriate module name from
the tx name and routes it if the module is present.
This all seems a bit of magic, but really just making use of the other magic
(go-wire) that we are already using, rather than add another layer. The only
thing you need to remember is to use the following pattern, then all the tx
will be properly routed:
This all seems like a bit of magic, but really we're just making use of go-wire
magic that we are already using, rather than add another layer. For all the
transactions to be properly routed, the only thing you need to remember is to
use the following pattern:
```golang
const (
@@ -192,34 +193,31 @@ const (
But wait, there's more... since we have isolated all the modules from each
other, we need to allow some way for them to interact in a controlled fashion.
One example is the `fee` middleware, which wants to deduct coins from the
calling account and can accomplished most easilty with the `coin` module.
calling account and can be accomplished most easily with the `coin` module.
If we want to make a call from the middleware, this is relatively simple. The
middleware already has a handle to the `next` Handler, which will execute the
rest of the stack. It can simple create a new SendTx and pass it down the
stack. If it returns success, then do the rest of the processing (and send the
original tx down the stack), otherwise abort.
To make a call from the middleware, we the `next` Handler, which will execute
the rest of the stack. It can create a new SendTx and pass it down the
stack. If it returns success, do the rest of the processing (and send the
original transaction down the stack), otherwise abort.
However, if one `Handler` inside the `Dispatcher` wants to do this, it becomes
more complex. The solution is that the `Dispatcher` accepts not a `Handler`,
more complex. The solution is that the `Dispatcher` accepts not a `Handler`,
but a `Dispatchable`, which looks like a middleware, except that the `next`
argument is a callback to the dispatcher to execute a sub-transaction. If a
argument is a callback to the dispatcher to execute a sub-transaction. If a
module doesn't want to use this functionality, it can just implement `Handler`
and call `stack.WrapHandler(h)` to convert it to a `Dispatchable` that never
uses the callback.
One example of this is the counter app, which can optionally accept a payment.
If the tx contains a payment, it must create a SendTx and pass this to the
dispatcher to deduct the amount from the proper account. Take a look at
[counter
plugin](https://github.com/tendermint/basecoin/blob/unstable/docs/guide/counter/plugins/counter/counter.go)
for a better idea.
If the transaction contains a payment, it must create a SendTx and pass this
to the dispatcher to deduct the amount from the proper account. Take a look at
[counter plugin](https://github.com/cosmos/cosmos-sdk/blob/master/docs/guide/counter/plugins/counter/counter.go)for a better idea.
## Permissions
IPC requires a more complex permissioning system to allow the modules to have
limited access to each other. Also to allow more types of permissions than
simple public key signatures. So, rather than just use an address to identify
limited access to each other and also to allow more types of permissions than
simple public key signatures. Rather than just use an address to identify
who is performing an action, we can use a more complex structure:
```golang
@@ -235,28 +233,26 @@ or initiate any sort of transaction. It doesn't just have to be a pubkey on
this chain, it could stem from another app (such as multi-sig account), or even
another chain (via IBC)
`ChainID` is to be used for IBC, which is discussed below, but right now focus
on `App` and `Address`. For a signature, the App is `auth`, and any modules
can check to see if a specific public key address signed like this
`ctx.HasPermission(auth.SigPerm(addr))`. However, we can also authorize a tx
with `roles`, which handles multi-sig accounts, it checks if there were enough
signatures by checking as above, then it can add the role permission like `ctx
= ctx.WithPermissions(NewPerm(assume.Role))`
`ChainID` is for IBC, discussed below. Let's focus on `App` and `Address`.
For a signature, the App is `auth`, and any modules can check to see if a
specific public key address signed like this `ctx.HasPermission(auth.SigPerm(addr))`.
However, we can also authorize a tx with `roles`, which handles multi-sig accounts,
it checks if there were enough signatures by checking as above, then it can add
the role permission like `ctx= ctx.WithPermissions(NewPerm(assume.Role))`
In addition to permissioning, the Actors are addresses just like public key
In addition to the permissions schema, the Actors are addresses just like public key
addresses. So one can create a mulit-sig role, then send coin there, which can
only be moved upon meeting the authorization requirements from that module.
`coin` doesn't even know the existence of `roles` and one could build any other
sort of module to provide permissions (like bind the outcome of an election to
move coins or to modify the accounts on a role).
One idea (not implemented) is to provide scopes on the permissions. Right now,
if I sign a tx to one module, it can pass it on to any other module over IPC
with the same permissions. It could move coins, vote in an election, or
anything else. Ideally, when signing, one could also specify the scope(s) that
this signature authorizes. The [oauth
protocol](https://api.slack.com/docs/oauth-scopes) also has to deal with a
similar problem, and maybe could provide some inspiration.
One idea - not yet implemented - is to provide scopes on the permissions.
Currently, if I sign a transaction to one module, it can pass it on to any other
module over IPC with the same permissions. It could move coins, vote in an election,
or anything else. Ideally, when signing, one could also specify the scope(s) that
this signature authorizes. The [oauth protocol](https://api.slack.com/docs/oauth-scopes)
also has to deal with a similar problem, and maybe could provide some inspiration.
## Replay Protection
@@ -264,7 +260,7 @@ similar problem, and maybe could provide some inspiration.
In order to prevent [replay
attacks](https://en.wikipedia.org/wiki/Replay_attack) a multi account nonce system
has been constructed as a module, which can be found in
`modules/nonce`. By adding the nonce module to the stack, each
`modules/nonce`. By adding the nonce module to the stack, each
transaction is verified for authenticity against replay attacks. This is
achieved by requiring that a new signed copy of the sequence number which must
be exactly 1 greater than the sequence number of the previous transaction. A
@@ -290,11 +286,11 @@ with other sequence numbers.
By abstracting out the nonce module in the stack, entire series of transactions
can occur without needing to verify the nonce for each member of the series. An
common example is a stack which will send coins and charge a fee. Within Quark
common example is a stack which will send coins and charge a fee. Within the SDK
this can be achieved using separate modules in a stack, one to send the coins
and the other to charge the fee, however both modules do not need to check the
nonce. This can occur as a separate module earlier in the stack.
## IBC (Inter-Blockchain Communication)
Wow, this is a big topic. Also a WIP. Add more here...
Stay tuned!
docs/quark/overview.md
+27 -30
View File
@@ -6,35 +6,34 @@ and match modular elements as desired. Along side, all modules are permissioned
and sandboxed to isolate modules for greater application security.
For more explanation please see the [standard
library](https://github.com/tendermint/basecoin/blob/unstable/docs/quark/stdlib.md)
library](stdlib.md)
and
[glossary](https://github.com/tendermint/basecoin/blob/unstable/docs/quark/glossary.md)
[glossary](glossary.md)
documentation.
For a more interconnected schematics see these
[framework](https://github.com/tendermint/basecoin/blob/unstable/docs/graphics/overview-framework.png)
[framework](../graphics/overview-framework.png)
and
[security](https://github.com/tendermint/basecoin/blob/unstable/docs/graphics/overview-security.png)
[security](../graphics/overview-security.png)
overviews.
## Framework Overview
### Transaction (tx)
### Transactions
Each tx passes through the middleware stack which can be defined uniquely by
each application. From the multiple layers of tx, each middleware may strip
off one level, like an onion. As so, the transaction must be constructed to
mirror the execution stack, and each middleware should allow embedding an
arbitrary tx for the next layer in the stack.
Each transaction passes through the middleware stack which can be defined
uniquely by each application. From the multiple layers of tx, each middleware
may strip off one level, like an onion. As such, the transaction must be
constructed to mirror the execution stack, and each middleware module should
allow embedding an arbitrary tx for the next layer in the stack.
<img src="https://github.com/tendermint/basecoin/blob/unstable/docs/graphics/tx.png" width=250>
<img src="..//graphics/tx.png" width=250>
### Execution Stack
Middleware components allow for code reusability and integrability. A standard
set of middleware are provided and can be mix-and-matched with custom
middleware. Some of the [standard
library](https://github.com/tendermint/basecoin/blob/unstable/docs/quark/stdlib.md)
middleware. Some of the [standardlibrary](stdlib.md)
middlewares provided in this package include:
- Logging
- Recovery
@@ -45,37 +44,37 @@ middlewares provided in this package include:
- Roles
- Inter-Blockchain-Communication (IBC)
As a part of stack execution the state space provided to each middleware is
As a part of stack execution the state space provided to each middleware is
isolated (see [Data Store](overview.md#data-store)). When executing the stack,
state-recovery points (checkpoints) can be assigned for stack execution of
`CheckTx` or `DeliverTx`. This means, that all state changes will be reverted
to the checkpoint state on failure when either being run as a part of `CheckTx`
state-recovery check-points can be assigned for stack execution of `CheckTx`
or `DeliverTx`. This means, that all state changes will be reverted to the
checkpoint state on failure when either being run as a part of `CheckTx`
or `DeliverTx`. Example usage of the checkpoints is when we may want to deduct
a fee even if the end business logic fails, under this situation we would add
the DeliverTx Checkpoint to after the fee middleware but before the business
a fee even if the end business logic fails; under this situation we would add
the `DeliverTx` checkpoint after the fee middleware but before the business
logic. This diagram displays a typical process flow through an execution stack.
<img src="https://github.com/tendermint/basecoin/blob/unstable/docs/graphics/middleware.png" width=500>
<img src="../graphics/middleware.png" width=500>
### Dispatcher
The dispatcher handler aims to allow for reusable business logic. As a
The dispatcher handler aims to allow for reusable business logic. As a
transaction is passed to the end handler, the dispatcher routes the logic to
the correct module. To use the dispatcher tool all transaction types must
the correct module. To use the dispatcher tool, all transaction types must
first be registered with the dispatcher. Once registered the middleware stack
or any other handler can call the dispatcher to execute a transaction.
Similarity to the execution stack, when executing a transaction the dispatcher
Similarly to the execution stack, when executing a transaction the dispatcher
isolates the state space available to the designated module (see [Data
Store](overview.md#data-store)).
<img src="https://github.com/tendermint/basecoin/blob/unstable/docs/graphics/dispatcher.png" width=600>
<img src="../graphics/dispatcher.png" width=600>
## Security Overview
### Permission
Each application is run in a sandbox to isolate security risks. When
interfacing between applications, if a one of those application is compromised
interfacing between applications, if a one of those applications is compromised
the entire network should still be secure. This is achieved through actor
permissioning whereby each chain, account, or application can provided a
designated permission for the transaction context to perform a specific action.
@@ -83,7 +82,7 @@ designated permission for the transaction context to perform a specific action.
Context is passed through the middleware and dispatcher, allowing one to add
permissions on this app-space, and check current permissions.
<img src="https://github.com/tendermint/basecoin/blob/unstable/docs/graphics/permission.png" width=500>
<img src="../graphics/permission.png" width=500>
### Data Store
@@ -93,13 +92,11 @@ is achieved through the use of unique prefix assigned to each module. From the
module's perspective it is no different, the module need-not have regard for
the prefix as it is assigned outside of the modules scope. For example, if a
module named `foo` wanted to write to the store it could save records under the
key `bar` however the dispatcher would register that record in the persistent
key `bar`, however, the dispatcher would register that record in the persistent
state under `foo/bar`. Next time the `foo` app was called that record would be
accessible to it under the assigned key `bar`. This effectively makes app
prefixing invisible to each module while preventing each module from affecting
each other module. Under this model no two registered modules are permitted to
have the same namespace.
<img src="https://github.com/tendermint/basecoin/blob/unstable/docs/graphics/datastore.png" width=500>
<img src="../graphics/datastore.png" width=500>
docs/quark/stdlib.md
+31 -46
View File
@@ -1,9 +1,9 @@
# Standard Library
The Quark framework comes bundled with a number of standard modules that
The Cosmos-SDK comes bundled with a number of standard modules that
provide common functionality useful across a wide variety of applications.
Example usage of the modules is also provided. It is recommended to investigate
if desired functionality is already provided before developing new modules.
See examples below. It is recommended to investigate if desired
functionality is already provided before developing new modules.
## Basic Middleware
@@ -22,18 +22,18 @@ them as errors, so they can be handled normally.
### Signatures
The first layer of the tx contains the signatures to authorize it. This is
then verified by `modules.auth.Signatures`. All tx may have one or multiple
signatures which are then processed and verified by this middleware and then
passed down the stack.
The first layer of the transaction contains the signatures to authorize it.
This is then verified by `modules.auth.Signatures`. All transactions may
have one or multiple signatures which are then processed and verified by this
middleware and then passed down the stack.
### Chain
The next layer of a tx (in the standard stack) binds the tx to a specific chain
with an optional expiration height. This keeps the tx from being replayed on
a fork or other such chain, as well as a partially signed multi-sig being delayed
months before being committed to the chain. This functionality is provided in
`modules.base.Chain`
The next layer of a transaction (in the standard stack) binds the transaction
to a specific chain with a block height that has an optional expiration. This
keeps the transactions from being replayed on a fork or other such chain, as
well as a partially signed multi-sig being delayed months before being
committed to the chain. This functionality is provided in `modules.base.Chain`
### Nonce
@@ -44,22 +44,22 @@ protection cross-IBC and cross-plugins and also allows signing parties to not
be bound to waiting for a particular transaction to be completed before being
able to sign a separate transaction.
Rather than force each module to implement its own replay protection, a tx
stack may contain a nonce wrap and the account it belongs to. The nonce must
contain a signed sequence number which is incremented one higher than the last
request or the request is rejected. This is implemented in
`modules.nonce.ReplayCheck`
Rather than force each module to implement its own replay protection, a
transaction stack may contain a nonce wrap and the account it belongs to. The
nonce must contain a signed sequence number which is incremented one higher
than the last request or the request is rejected. This is implemented in
`modules.nonce.ReplayCheck`.
If you're interested checkout this [design
discussion](https://github.com/tendermint/basecoin/issues/160).
discussion](https://github.com/cosmos/cosmos-sdk/issues/160).
### Fees
An optional feature, but useful on many chains, is charging transaction fees. A
simple implementation of this is provided in `modules.fee.SimpleFeeMiddleware`.
An optional - but useful - feature on many chains, is charging transaction fees.
A simple implementation of this is provided in `modules.fee.SimpleFeeMiddleware`.
A fee currency and minimum amount are defined in the constructor (eg. in code).
If the minimum amount is 0, then the fee is optional. If it is above 0, then
every tx with insufficient fee is rejected. This fee is deducted from the
every transaction with insufficient fee is rejected. This fee is deducted from the
payers account before executing any other transaction.
This module is dependent on the `coin` module.
@@ -82,7 +82,7 @@ requires some payment solution, like fees or trader.
### Roles
Roles encapsulates what are typically called N-of-M multi-signatures accounts
Roles encapsulate what are typically called N-of-M multi-signatures accounts
in the crypto world. However, I view this as a type of role or group, which can
be the basis for building a permission system. For example, a set of people
could be called registrars, which can authorize a new IBC chain, and need eg. 2
@@ -95,7 +95,7 @@ a role is planned in the near future.
### Inter-Blockchain Communication (IBC)
IBC, is the cornerstone of The Cosmos Network, and is built into the quark
IBC, is the cornerstone of The Cosmos Network, and is built into the Cosmos-SDK
framework as a basic primitive. To fully grasp these concepts requires
a much longer explanation, but in short, the chain works as a light-client to
another chain and maintains input and output queue to send packets with that
@@ -105,39 +105,24 @@ blockchains to each other ultimately invoke inter-blockchain transactions.
Most functionality is implemented in `modules.ibc.Handler`. Registering a chain
is a seed of trust that requires verification of the proper seed (or genesis
block), and this generally requires approval of an authorized registrar (which
may be a multi-sig role). Updating a registered chain can be done by anyone,
may be a multi-sig role). Updating a registered chain can be done by anyone,
as the new header can be completely verified by the existing knowledge of the
chain. Also, modules can initiate an outgoing IBC message to another chain
chain. Also, modules can initiate an outgoing IBC message to another chain
by calling `CreatePacketTx` over IPC (inter-plugin communication) with a tx
that belongs to their module. (This must be explicitly authorized by the
same module, so only the eg. coin module can authorize a `SendTx` to another
chain).
`PostPacketTx` can post a tx that was created on another chain along with the
merkle proof, which must match an already registered header. If this chain
can verify the authenticity, it will accept the packet, along with all the
permissions from the other chain, and execute it on this stack. This is the
`PostPacketTx` can post a transaction that was created on another chain along
with the merkle proof, which must match an already registered header. If this
chain can verify the authenticity, it will accept the packet, along with all
the permissions from the other chain, and execute it on this stack. This is the
only way to get permissions that belong to another chain.
These various pieces can be combined in a relay, which polls for new packets
on one chain, and then posts the packets along with the new headers on the
other chain.
## Planned Apps
### Staking
Straight-forward PoS as used for cosmos.
Based on [basecoin-stake](https://github.com/tendermint/basecoin-stake)
### Voting
Simple elections that can authorize other tx, like roles. A building block for
governance.
### Trader
Escrow, OTC option, Order book. Based on
[basecoin-examples](https://github.com/tendermint/basecoin-examples/tree/develop/trader).
This may be more appropriate for an external repo.
## Example Apps
See the [Cosmos Academy](https://github.com/cosmos/cosmos-academy) for example applications.