Cosmos concepts
Concepts before accessing LikeCoin chain
Last updated
Concepts before accessing LikeCoin chain
Last updated
A private key is a 32 bytes (256 bits) binary.
The public key is derived from the private key according to secp256k1, in 33-bytes compressed format.
The Cosmos address is derived by the follows: address = ripemd160(sha256(pubKey)), encoded by bech32 with cosmos as prefix.
See for an example in JavaScript.
To use the RPC APIs, we need a a lite client endpoint, which communicates with full nodes and verify the data from full nodes cryptographically (e.g. verifying Merkle proof).
For the FoTan mainnet:
Users can also run a full node and a lite client.
To setup a full node, please follow the instruction from this document:
(TODO: genesis URL and seed node)
Since the FoTan upgraed, the RESTful API is built into the liked command. You may modify .liked/config/app.toml for enabling the RESTful API if needed.
is an example Docker Compose config file for running the Taipei network full node and lite client. This hosts an RPC API endpoint on port 1317.\
Chain ID defines which chain / network you are operating on, to prevent replaying transactions on other networks.
Each address corresponds to an account, which will have an account number and a sequence number.
Account number is the account's number.
It is required in transactions, and could be queried from the /auth/accounts/{address} API.
Sequence is the number of transactions the account has sent.
It is required in transactions to prevent transaction replays, similar to the concept of nonce in Ethereum.
It could be queried from the /auth/accounts/{address} API.
In Cosmos SDK, coins are represented as an object with 2 fields: amount and denom.
amount is the number of coins, while denom is the identifier of the coins.
In LikeCoin Chain, we only have one denom, which is nanolike. 1 LikeCoin = 1000000000nanolike.
When used in short forms (e.g. CLI parameters), the format of coins is ${amount}${denom}, e.g. 1000000000nanolike.
In Cosmos SDK, there is a concept called gas, which is similar to the concept of gas in Ethereum.
Each transaction must specify the maximum amount of gas it may consume.
If the transaction consumed more gas than provided during execution, it will fail.
Different from Ethereum, transactions specify their transaction fee directly, instead of specifying the gas price.
Nodes calculates the gas price by gas_price = fee / gas, and may reject transactions with gas price lower than their expectation.
We currently recommend validators to set the gas price to 10000.0nanolike as per proposal 74. For a typical coin sending transaction, it consumes about 44000 gas, which means the transaction fee is 0.044 LikeCoin.
Since the fee is specified in the transaction, it will not be refunded even if the actual gas consumption is less than the provided one.
The signing process is the standard secp256k1 signing.
The output bytes are organized in 64 bytes, which are the r and s values, 256 bites each, concatenated.
The signature is represented as object in transactions, which includes the public key and the signature bytes.
Example:
The sign bytes are the input to the secp256k1 signing algorithm.
Sign bytes are obtained by the following process:
construct a standard transaction as follows:
Where msgs are the msg objects of the transactions. For a typical Send transaction, it will look like this:
Note that all numbers (e.g. amount, sequence, account_number) are encoded as string in the sign bytes.
remove all fields with null value.
reorganize the JSON message to remove all indents and newline formattings, and sort the fields by alphanumeric order.
The sign bytes of the example above after processing will look like this: