Merge PR #1463: docs: Fix dependencies, from monorepo merge
Closes #1456
This commit is contained in:
Dev Ojha
Christopher Goes
parent
24a68d3bdf
commit
0d28eda146
|
|
@ -1,7 +1,7 @@
|
|||
# The Basics
|
||||
|
||||
Here we introduce the basic components of an SDK by building `App1`, a simple bank.
|
||||
Users have an account address and an account, and they can send coins around.
|
||||
Users have an account address and an account, and they can send coins around.
|
||||
It has no authentication, and just uses JSON for serialization.
|
||||
|
||||
The complete code can be found in [app1.go](examples/app1.go).
|
||||
|
|
@ -22,11 +22,11 @@ type Msg interface {
|
|||
// ValidateBasic does a simple validation check that
|
||||
// doesn't require access to any other information.
|
||||
ValidateBasic() error
|
||||
|
||||
|
||||
// Get the canonical byte representation of the Msg.
|
||||
// This is what is signed.
|
||||
GetSignBytes() []byte
|
||||
|
||||
|
||||
// Signers returns the addrs of signers that must sign.
|
||||
// CONTRACT: All signatures must be present to be valid.
|
||||
// CONTRACT: Returns addrs in some deterministic order.
|
||||
|
|
@ -38,7 +38,7 @@ type Msg interface {
|
|||
The `Msg` interface allows messages to define basic validity checks, as well as
|
||||
what needs to be signed and who needs to sign it.
|
||||
|
||||
For instance, take the simple token sending message type from app1.go:
|
||||
For instance, take the simple token sending message type from app1.go:
|
||||
|
||||
```go
|
||||
// MsgSend to send coins from Input to Output
|
||||
|
|
@ -134,7 +134,7 @@ type KVStore interface {
|
|||
|
||||
Note it is unforgiving - it panics on nil keys!
|
||||
|
||||
The primary implementation of the KVStore is currently the IAVL store. In the future, we plan to support other Merkle KVStores,
|
||||
The primary implementation of the KVStore is currently the IAVL store. In the future, we plan to support other Merkle KVStores,
|
||||
like Ethereum's radix trie.
|
||||
|
||||
As we'll soon see, apps have many distinct KVStores, each with a different name and for a different concern.
|
||||
|
|
@ -157,7 +157,7 @@ Only handlers which were given explict access to a store's key will be able to a
|
|||
|
||||
### Context
|
||||
|
||||
The SDK uses a `Context` to propogate common information across functions.
|
||||
The SDK uses a `Context` to propogate common information across functions.
|
||||
Most importantly, the `Context` restricts access to KVStores based on object-capability keys.
|
||||
Only handlers which have been given explicit access to a key will be able to access the corresponding store.
|
||||
|
||||
|
|
@ -177,10 +177,10 @@ func newFooHandler(key sdk.StoreKey) sdk.Handler {
|
|||
[context.Context](https://golang.org/pkg/context/), which has
|
||||
become ubiquitous in networking middleware and routing applications as a means
|
||||
to easily propogate request context through handler functions.
|
||||
Many methods on SDK objects receive a context as the first argument.
|
||||
Many methods on SDK objects receive a context as the first argument.
|
||||
|
||||
The Context also contains the
|
||||
[block header](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md#header),
|
||||
The Context also contains the
|
||||
[block header](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md#header),
|
||||
which includes the latest timestamp from the blockchain and other information about the latest block.
|
||||
|
||||
See the [Context API
|
||||
|
|
@ -189,7 +189,7 @@ docs](https://godoc.org/github.com/cosmos/cosmos-sdk/types#Context) for more det
|
|||
### Result
|
||||
|
||||
Handler takes a Context and Msg and returns a Result.
|
||||
Result is motivated by the corresponding [ABCI result](https://github.com/tendermint/abci/blob/master/types/types.proto#L165).
|
||||
Result is motivated by the corresponding [ABCI result](https://github.com/tendermint/tendermint/abci/blob/master/types/types.proto#L165).
|
||||
It contains return values, error information, logs, and meta data about the transaction:
|
||||
|
||||
```go
|
||||
|
|
@ -268,7 +268,7 @@ type appAccount struct {
|
|||
}
|
||||
```
|
||||
|
||||
Coins is a useful type provided by the SDK for multi-asset accounts.
|
||||
Coins is a useful type provided by the SDK for multi-asset accounts.
|
||||
We could just use an integer here for a single coin type, but
|
||||
it's worth [getting to know
|
||||
Coins](https://godoc.org/github.com/cosmos/cosmos-sdk/types#Coins).
|
||||
|
|
@ -349,7 +349,7 @@ func handleTo(store sdk.KVStore, to sdk.Address, amt sdk.Coins) sdk.Result {
|
|||
```
|
||||
|
||||
The handler is straight forward. We first load the KVStore from the context using the granted capability key.
|
||||
Then we make two state transitions: one for the sender, one for the receiver.
|
||||
Then we make two state transitions: one for the sender, one for the receiver.
|
||||
Each one involves JSON unmarshalling the account bytes from the store, mutating
|
||||
the `Coins`, and JSON marshalling back into the store.
|
||||
|
||||
|
|
@ -359,7 +359,7 @@ And that's that!
|
|||
|
||||
The final piece before putting it all together is the `Tx`.
|
||||
While `Msg` contains the content for particular functionality in the application, the actual input
|
||||
provided by the user is a serialized `Tx`. Applications may have many implementations of the `Msg` interface,
|
||||
provided by the user is a serialized `Tx`. Applications may have many implementations of the `Msg` interface,
|
||||
but they should have only a single implementation of `Tx`:
|
||||
|
||||
|
||||
|
|
@ -371,7 +371,7 @@ type Tx interface {
|
|||
}
|
||||
```
|
||||
|
||||
The `Tx` just wraps a `[]Msg`, and may include additional authentication data, like signatures and account nonces.
|
||||
The `Tx` just wraps a `[]Msg`, and may include additional authentication data, like signatures and account nonces.
|
||||
Applications must specify how their `Tx` is decoded, as this is the ultimate input into the application.
|
||||
We'll talk more about `Tx` types later, specifically when we introduce the `StdTx`.
|
||||
|
||||
|
|
@ -409,11 +409,11 @@ func txDecoder(txBytes []byte) (sdk.Tx, sdk.Error) {
|
|||
Finally, we stitch it all together using the `BaseApp`.
|
||||
|
||||
The BaseApp is an abstraction over the [Tendermint
|
||||
ABCI](https://github.com/tendermint/abci) that
|
||||
ABCI](https://github.com/tendermint/tendermint/abci) that
|
||||
simplifies application development by handling common low-level concerns.
|
||||
It serves as the mediator between the two key components of an SDK app: the store
|
||||
and the message handlers. The BaseApp implements the
|
||||
[`abci.Application`](https://godoc.org/github.com/tendermint/abci/types#Application) interface.
|
||||
[`abci.Application`](https://godoc.org/github.com/tendermint/tendermint/abci/types#Application) interface.
|
||||
See the [BaseApp API
|
||||
documentation](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp) for more details.
|
||||
|
||||
|
|
@ -422,22 +422,22 @@ Here is the complete setup for App1:
|
|||
```go
|
||||
func NewApp1(logger log.Logger, db dbm.DB) *bapp.BaseApp {
|
||||
cdc := wire.NewCodec()
|
||||
|
||||
|
||||
// Create the base application object.
|
||||
app := bapp.NewBaseApp(app1Name, cdc, logger, db)
|
||||
|
||||
|
||||
// Create a capability key for accessing the account store.
|
||||
keyAccount := sdk.NewKVStoreKey("acc")
|
||||
|
||||
|
||||
// Determine how transactions are decoded.
|
||||
app.SetTxDecoder(txDecoder)
|
||||
|
||||
|
||||
// Register message routes.
|
||||
// Note the handler receives the keyAccount and thus
|
||||
// gets access to the account store.
|
||||
app.Router().
|
||||
AddRoute("bank", NewApp1Handler(keyAccount))
|
||||
|
||||
|
||||
// Mount stores and load the latest state.
|
||||
app.MountStoresIAVL(keyAccount)
|
||||
err := app.LoadLatestVersion(keyAccount)
|
||||
|
|
@ -450,8 +450,8 @@ func NewApp1(logger log.Logger, db dbm.DB) *bapp.BaseApp {
|
|||
|
||||
Every app will have such a function that defines the setup of the app.
|
||||
It will typically be contained in an `app.go` file.
|
||||
We'll talk about how to connect this app object with the CLI, a REST API,
|
||||
the logger, and the filesystem later in the tutorial. For now, note that this is where we
|
||||
We'll talk about how to connect this app object with the CLI, a REST API,
|
||||
the logger, and the filesystem later in the tutorial. For now, note that this is where we
|
||||
register handlers for messages and grant them access to stores.
|
||||
|
||||
Here, we have only a single Msg type, `bank`, a single store for accounts, and a single handler.
|
||||
|
|
@ -465,30 +465,30 @@ Since we only have one store, we only mount one.
|
|||
## Execution
|
||||
|
||||
We're now done the core logic of the app! From here, we can write tests in Go
|
||||
that initialize the store with accounts and execute transactions by calling
|
||||
that initialize the store with accounts and execute transactions by calling
|
||||
the `app.DeliverTx` method.
|
||||
|
||||
In a real setup, the app would run as an ABCI application on top of the
|
||||
Tendermint consensus engine. It would be initialized by a Genesis file, and it
|
||||
would be driven by blocks of transactions committed by the underlying Tendermint
|
||||
would be driven by blocks of transactions committed by the underlying Tendermint
|
||||
consensus. We'll talk more about ABCI and how this all works a bit later, but
|
||||
feel free to check the
|
||||
[specification](https://github.com/tendermint/abci/blob/master/specification.md).
|
||||
feel free to check the
|
||||
[specification](https://github.com/tendermint/tendermint/abci/blob/master/specification.md).
|
||||
We'll also see how to connect our app to a complete suite of components
|
||||
for running and using a live blockchain application.
|
||||
for running and using a live blockchain application.
|
||||
|
||||
For now, we note the follow sequence of events occurs when a transaction is
|
||||
received (through `app.DeliverTx`):
|
||||
|
||||
- serialized transaction is received by `app.DeliverTx`
|
||||
- transaction is deserialized using `TxDecoder`
|
||||
- for each message in the transaction, run `msg.ValidateBasic()`
|
||||
- for each message in the transaction, run `msg.ValidateBasic()`
|
||||
- for each message in the transaction, load the appropriate handler and execute
|
||||
it with the message
|
||||
|
||||
## Conclusion
|
||||
|
||||
We now have a complete implementation of a simple app!
|
||||
We now have a complete implementation of a simple app!
|
||||
|
||||
In the next section, we'll add another Msg type and another store. Once we have multiple message types
|
||||
we'll need a better way of decoding transactions, since we'll need to decode
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ delineated boundary between the Cosmos-SDK and Tendermint.
|
|||
It separates the logical state transition machine of your application from
|
||||
its secure replication across many physical machines.
|
||||
|
||||
By providing a clear, language agnostic boundary between applications and consensus,
|
||||
By providing a clear, language agnostic boundary between applications and consensus,
|
||||
ABCI provides tremendous developer flexibility and [support in many
|
||||
languages](https://tendermint.com/ecosystem). That said, it is still quite a low-level protocol, and
|
||||
requires frameworks to be built to abstract over that low-level componentry.
|
||||
|
|
@ -14,9 +14,9 @@ The Cosmos-SDK is one such framework.
|
|||
While we've already seen `DeliverTx`, the workhorse of any ABCI application,
|
||||
here we will introduce the other ABCI requests sent by Tendermint, and
|
||||
how we can use them to build more advanced applications. For a more complete
|
||||
depiction of the ABCI and how its used, see
|
||||
depiction of the ABCI and how its used, see
|
||||
[the
|
||||
specification](https://github.com/tendermint/abci/blob/master/specification.md)
|
||||
specification](https://github.com/tendermint/tendermint/abci/blob/master/specification.md)
|
||||
|
||||
## InitChain
|
||||
|
||||
|
|
@ -26,8 +26,8 @@ which is called once by Tendermint the very first time the application boots up.
|
|||
|
||||
The InitChain request contains a variety of Tendermint information, like the consensus
|
||||
parameters and an initial validator set, but it also contains an opaque blob of
|
||||
application specific bytes - typically JSON encoded.
|
||||
Apps can decide what to do with all of this information by calling the
|
||||
application specific bytes - typically JSON encoded.
|
||||
Apps can decide what to do with all of this information by calling the
|
||||
`app.SetInitChainer` method.
|
||||
|
||||
For instance, let's introduce a `GenesisAccount` struct that can be JSON encoded
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ import (
|
|||
"encoding/json"
|
||||
"fmt"
|
||||
|
||||
"github.com/tendermint/go-crypto"
|
||||
"github.com/tendermint/tendermint/crypto"
|
||||
cmn "github.com/tendermint/tmlibs/common"
|
||||
dbm "github.com/tendermint/tmlibs/db"
|
||||
"github.com/tendermint/tmlibs/log"
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# End-Block
|
||||
# End-Block
|
||||
|
||||
## Slashing
|
||||
|
||||
|
|
@ -6,16 +6,16 @@ Tendermint blocks can include
|
|||
[Evidence](https://github.com/tendermint/tendermint/blob/develop/docs/spec/blockchain/blockchain.md#evidence), which indicates that a validator
|
||||
committed malicious behaviour. The relevant information is forwarded to the
|
||||
application as [ABCI
|
||||
Evidence](https://github.com/tendermint/abci/blob/develop/types/types.proto#L259), so the validator an be accordingly punished.
|
||||
Evidence](https://github.com/tendermint/tendermint/abci/blob/develop/types/types.proto#L259), so the validator an be accordingly punished.
|
||||
|
||||
For some `evidence` to be valid, it must satisfy:
|
||||
For some `evidence` to be valid, it must satisfy:
|
||||
|
||||
`evidence.Timestamp >= block.Timestamp - MAX_EVIDENCE_AGE`
|
||||
|
||||
where `evidence.Timestamp` is the timestamp in the block at height
|
||||
`evidence.Height` and `block.Timestamp` is the current block timestamp.
|
||||
|
||||
If valid evidence is included in a block, the validator's stake is reduced by `SLASH_PROPORTION` of
|
||||
If valid evidence is included in a block, the validator's stake is reduced by `SLASH_PROPORTION` of
|
||||
what their stake was when the equivocation occurred (rather than when the evidence was discovered):
|
||||
|
||||
```
|
||||
|
|
@ -89,7 +89,7 @@ for val in block.Validators:
|
|||
// else previous == val not in block.AbsentValidators, no change
|
||||
|
||||
// validator must be active for at least SIGNED_BLOCKS_WINDOW
|
||||
// before they can be automatically unbonded for failing to be
|
||||
// before they can be automatically unbonded for failing to be
|
||||
// included in 50% of the recent LastCommits
|
||||
minHeight = signInfo.StartHeight + SIGNED_BLOCKS_WINDOW
|
||||
minSigned = SIGNED_BLOCKS_WINDOW / 2
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ what is happening under the hood.
|
|||
|
||||
## Setup and Install
|
||||
|
||||
You will need to have go installed on your computer. Please refer to the [cosmos testnet tutorial](https://cosmos.network/validators/tutorial), which will always have the most updated instructions on how to get setup with go and the cosmos repository.
|
||||
You will need to have go installed on your computer. Please refer to the [cosmos testnet tutorial](https://cosmos.network/validators/tutorial), which will always have the most updated instructions on how to get setup with go and the cosmos repository.
|
||||
|
||||
Once you have go installed, run the command:
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ make get_tools // run make update_tools if you already had it installed
|
|||
make get_vendor_deps
|
||||
make install_examples
|
||||
```
|
||||
Then run `make install_examples`, which creates binaries for `basecli` and `basecoind`. You can look at the Makefile if you want to see the details on what these make commands are doing.
|
||||
Then run `make install_examples`, which creates binaries for `basecli` and `basecoind`. You can look at the Makefile if you want to see the details on what these make commands are doing.
|
||||
|
||||
## Using basecli and basecoind
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ basecoind version
|
|||
|
||||
They should read something like `0.17.1-5d18d5f`, but the versions will be constantly updating so don't worry if your version is higher that 0.17.1. That's a good thing.
|
||||
|
||||
Note that you can always check help in the terminal by running `basecli -h` or `basecoind -h`. It is good to check these out if you are stuck, because updates to the code base might slightly change the commands, and you might find the correct command in there.
|
||||
Note that you can always check help in the terminal by running `basecli -h` or `basecoind -h`. It is good to check these out if you are stuck, because updates to the code base might slightly change the commands, and you might find the correct command in there.
|
||||
|
||||
Let's start by initializing the basecoind daemon. Run the command
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ And you should see something like this:
|
|||
}
|
||||
```
|
||||
|
||||
This creates the `~/.basecoind folder`, which has config.toml, genesis.json, node_key.json, priv_validator.json. Take some time to review what is contained in these files if you want to understand what is going on at a deeper level.
|
||||
This creates the `~/.basecoind folder`, which has config.toml, genesis.json, node_key.json, priv_validator.json. Take some time to review what is contained in these files if you want to understand what is going on at a deeper level.
|
||||
|
||||
|
||||
## Generating keys
|
||||
|
|
@ -79,7 +79,7 @@ Repeat the passphrase:
|
|||
Enter your recovery seed phrase:
|
||||
```
|
||||
|
||||
You just created your first locally stored key, under the name alice, and this account is linked to the private key that is running the basecoind validator node. Once you do this, the ~/.basecli folder is created, which will hold the alice key and any other keys you make. Now that you have the key for alice, you can start up the blockchain by running
|
||||
You just created your first locally stored key, under the name alice, and this account is linked to the private key that is running the basecoind validator node. Once you do this, the ~/.basecli folder is created, which will hold the alice key and any other keys you make. Now that you have the key for alice, you can start up the blockchain by running
|
||||
|
||||
```
|
||||
basecoind start
|
||||
|
|
@ -100,7 +100,7 @@ You can see your keys with the command:
|
|||
basecli keys list
|
||||
```
|
||||
|
||||
You should now see alice, bob and charlie's account all show up.
|
||||
You should now see alice, bob and charlie's account all show up.
|
||||
|
||||
```
|
||||
NAME: ADDRESS: PUBKEY:
|
||||
|
|
@ -123,11 +123,11 @@ Where `90B0B9BE0914ECEE0B6DB74E67B07A00056B9BBD` is alice's address we got from
|
|||
The following command will send coins from alice, to bob:
|
||||
|
||||
```
|
||||
basecli send --name=alice --amount=10000mycoin --to=29D721F054537C91F618A0FDBF770DA51EF8C48D
|
||||
basecli send --name=alice --amount=10000mycoin --to=29D721F054537C91F618A0FDBF770DA51EF8C48D
|
||||
--sequence=0 --chain-id=test-chain-AE4XQo
|
||||
```
|
||||
|
||||
Flag Descriptions:
|
||||
Flag Descriptions:
|
||||
- `name` is the name you gave your key
|
||||
- `mycoin` is the name of the token for this basecoin demo, initialized in the genesis.json file
|
||||
- `sequence` is a tally of how many transactions have been made by this account. Since this is the first tx on this account, it is 0
|
||||
|
|
@ -142,7 +142,7 @@ basecli account 29D721F054537C91F618A0FDBF770DA51EF8C48D
|
|||
Now lets send some from bob to charlie. Make sure you send less than bob has, otherwise the transaction will fail:
|
||||
|
||||
```
|
||||
basecli send --name=bob --amount=5000mycoin --to=2E8E13EEB8E3F0411ACCBC9BE0384732C24FBD5E
|
||||
basecli send --name=bob --amount=5000mycoin --to=2E8E13EEB8E3F0411ACCBC9BE0384732C24FBD5E
|
||||
--sequence=0 --chain-id=test-chain-AE4XQo
|
||||
```
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ Note how we use the ``--name`` flag to select a different account to send from.
|
|||
Lets now try to send from bob back to alice:
|
||||
|
||||
```
|
||||
basecli send --name=bob --amount=3000mycoin --to=90B0B9BE0914ECEE0B6DB74E67B07A00056B9BBD
|
||||
basecli send --name=bob --amount=3000mycoin --to=90B0B9BE0914ECEE0B6DB74E67B07A00056B9BBD
|
||||
--sequence=1 --chain-id=test-chain-AE4XQo
|
||||
```
|
||||
|
||||
|
|
@ -171,8 +171,8 @@ That is the basic implementation of basecoin!
|
|||
**WARNING:** Running these commands will wipe out any existing
|
||||
information in both the ``~/.basecli`` and ``~/.basecoind`` directories,
|
||||
including private keys. This should be no problem considering that basecoin
|
||||
is just an example, but it is always good to pay extra attention when
|
||||
you are removing private keys, in any scenario involving a blockchain.
|
||||
is just an example, but it is always good to pay extra attention when
|
||||
you are removing private keys, in any scenario involving a blockchain.
|
||||
|
||||
To remove all the files created and refresh your environment (e.g., if
|
||||
starting this tutorial again or trying something new), the following
|
||||
|
|
@ -212,7 +212,7 @@ The Basecoin state consists entirely of a set of accounts. Each account
|
|||
contains an address, a public key, a balance in many different coin denominations,
|
||||
and a strictly increasing sequence number for replay protection. This
|
||||
type of account was directly inspired by accounts in Ethereum, and is
|
||||
unlike Bitcoin's use of Unspent Transaction Outputs (UTXOs).
|
||||
unlike Bitcoin's use of Unspent Transaction Outputs (UTXOs).
|
||||
|
||||
```
|
||||
type BaseAccount struct {
|
||||
|
|
@ -225,7 +225,7 @@ type BaseAccount struct {
|
|||
|
||||
You can also add more fields to accounts, and basecoin actually does so. Basecoin
|
||||
adds a Name field in order to show how easily the base account structure can be
|
||||
modified to suit any applications needs. It takes the `auth.BaseAccount` we see above,
|
||||
modified to suit any applications needs. It takes the `auth.BaseAccount` we see above,
|
||||
and extends it with `Name`.
|
||||
|
||||
```
|
||||
|
|
@ -256,7 +256,7 @@ Accounts are serialized and stored in a Merkle tree under the key
|
|||
Typically, the address of the account is the 20-byte ``RIPEMD160`` hash
|
||||
of the public key, but other formats are acceptable as well, as defined
|
||||
in the `Tendermint crypto
|
||||
library <https://github.com/tendermint/go-crypto>`__. The Merkle tree
|
||||
library <https://github.com/tendermint/tendermint/crypto>`__. The Merkle tree
|
||||
used in Basecoin is a balanced, binary search tree, which we call an
|
||||
`IAVL tree <https://github.com/tendermint/iavl>`__.
|
||||
|
||||
|
|
@ -293,15 +293,15 @@ Note the `SendTx` includes a field for `Gas` and `Fee`. The
|
|||
transaction, while the `Fee` refers to the total amount paid in fees.
|
||||
This is slightly different from Ethereum's concept of `Gas` and
|
||||
`GasPrice`, where `Fee = Gas x GasPrice`. In Basecoin, the `Gas`
|
||||
and `Fee` are independent, and the `GasPrice` is implicit.
|
||||
and `Fee` are independent, and the `GasPrice` is implicit.
|
||||
|
||||
In Basecoin, the `Fee` is meant to be used by the validators to inform
|
||||
the ordering of transactions, like in Bitcoin. And the `Gas` is meant
|
||||
to be used by the application plugin to control its execution. There is
|
||||
currently no means to pass `Fee` information to the Tendermint
|
||||
validators, but it will come soon... so this version of Basecoin does
|
||||
not actually fully implement fees and gas, but it still allows us
|
||||
to send transactions between accounts.
|
||||
validators, but it will come soon... so this version of Basecoin does
|
||||
not actually fully implement fees and gas, but it still allows us
|
||||
to send transactions between accounts.
|
||||
|
||||
Note also that the `PubKey` only needs to be sent for
|
||||
`Sequence == 0`. After that, it is stored under the account in the
|
||||
|
|
@ -318,4 +318,3 @@ serve as a basic unit of decentralized exchange. When using multiple
|
|||
inputs and outputs, you must make sure that the sum of coins of the
|
||||
inputs equals the sum of coins of the outputs (no creating money), and
|
||||
that all accounts that provide inputs have signed the transaction.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue