--helpflag to get more information about.
send. Through this
sendcommand, see how to use tx commands.
broadcaststeps. So the command above works internally generate unsigned transaction first, and ask password of
from_key_or_addressto sign, sign the generated transaction with key, and finally broadcast the signed transaction.
--dry-runflag to the command line.
--generate-onlyflag. This allows you to separate the creation and signing of a transaction without broadcasting.
from_keyis not supported in generate-only mode. You need to use
--generate-onlyflag. It will read a transaction from
[file], sign it, and print its JSON encoding.
--signature-onlyflag is set, it will output the signature parts only.
--offlineflag makes sure that the client will not reach out to full node. As a result, the account and sequence number queries will not be performed and it is required to set such parameters manually. Note, invalid values will cause the transaction to fail.
--offlineflag is also set, signature validation over the transaction will be not be performed as that will require RPC communication with a full node.
--generate-onlyflag and signed with the
signcommand. This command reads the transaction from
[file]and broadcast it to a node.
create-validatorcommand needs some mandatory flags.
gasis a special unit that is used to track the consumption of resources during execution.
gasis typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes:
messageexecution is typically priced, resulting in a
fees = gas * gas-prices).
feesgenerally have to be paid by the sender of the
message. Note that the Cosmos platform does not enforce
gaspricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications will implement
feemechanisms to prevent spam. This is done via the
gasis dependent on the transaction. Different transaction require different amount of
gas-pricesis the price of each unit of
gas. Each validator sets a
minimum-gas-pricesvalue, and will only include transactions that have a
gas-pricesgreater than their
feesare the product of
fees. The validators specify a
app.tomlfile that they use to determine whether to include a transaction, where
gas-prices >= min-gas-prices. The higher
fees, the higher chance that your transaction will get included in a block.
--gasflag every time, the
gasamount for a transaction is calculated as it is being processed automatically as default. Of course, this only gives an estimate, so it returns failures. So you can adjust this estimate with the flag
--gas-adjustmentif you want to be sure you provide enough
gasfor the transaction.
min-gas-pricesby dividing your fee with the estimated
gasconsumption, to properly assign the right priority to your transaction.