mirror of
https://github.com/0glabs/0g-chain.git
synced 2024-12-23 23:05:18 +00:00
fixed capitilization and typos
This commit is contained in:
parent
0839466ec2
commit
610a269e31
@ -6,12 +6,12 @@ In order for developers to start building modules, they must install the followi
|
||||
2. [Docker](https://docs.docker.com/get-docker/)
|
||||
|
||||
### Go Programming Language
|
||||
Go is used to develop modules and gives much needed performance and flexibility to blockchain developers being a language developed and used by some of the largest companies in the world, in their server/networking applications.
|
||||
Go is a language developed and used by some of the largest companies in the world for server/networking applications. Go is used to develop modules and provides optimum performance and flexibility to blockchain developers.
|
||||
|
||||
[A Tour Of Go](https://tour.golang.org/welcome/1)
|
||||
|
||||
### Docker
|
||||
Docker is a software containerization tool used to spin up Kava nodes and shut them down quickly and allow software portability between different operating systems & environments. It is also used to spin up multiple Kava nodes locally and handles basic networking between them with Docker Compose.
|
||||
Docker is a software containerization tool used to spin up and shut down Kava nodes and allows software portability between different operating systems & environments. It is also used to spin up multiple Kava nodes locally and handles basic networking between them with `docker compose`.
|
||||
|
||||
[Docker Overview](https://docs.docker.com/get-started/overview/)
|
||||
|
||||
|
@ -20,7 +20,10 @@ Proper vetting of a parameter change proposal should prevent this from happening
|
||||
regardless.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
$ kvcli tx gov submit-proposal param-change <path/to/proposal.json> --from=<key_or_address>
|
||||
```
|
||||
|
||||
Where proposal.json contains:
|
||||
```
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Borrow
|
||||
|
||||
borrow tokens from the hard protocol
|
||||
Borrow tokens from the hard protocol
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx hard borrow <amount> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```borrow``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```borrow``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Deposit
|
||||
|
||||
deposit coins to hard
|
||||
Deposit coins to hard
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx hard deposit <amount> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Repay
|
||||
|
||||
repay tokens to the hard protocol
|
||||
Repay tokens to the hard protocol
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx hard repay <amount> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```repay``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```repay``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Withdraw
|
||||
|
||||
withdraw coins from hard
|
||||
Withdraw coins from hard
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx hard withdraw <amount> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -7,7 +7,7 @@ Create a new cdp, depositing some collateral and drawing some debt.
|
||||
kvcli tx cdp create <collateral> <debt> <collateral-type> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```create``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```create``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -7,7 +7,7 @@ Add collateral to an existing cdp.
|
||||
kvcli tx cdp deposit <owner-addr> <collateral> <collateral-type> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -7,7 +7,7 @@ Create debt in an existing cdp and send the newly minted asset to your account.
|
||||
kvcli tx cdp draw <collateral-type> <debt> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```draw``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```draw``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Repay Debt
|
||||
|
||||
repay debt to an existing cdp
|
||||
Repay debt to an existing cdp
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx cdp repay <collateral-name> <debt> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```repay``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```repay``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Remove Collateral
|
||||
|
||||
withdraw collateral from an existing cdp
|
||||
Withdraw collateral from an existing cdp
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx cdp withdraw <owner-addr> <collateral> <collateral-type> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Deposit
|
||||
|
||||
deposit coins to a swap liquidity pool
|
||||
Deposit coins to a swap liquidity pool
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx swap deposit <tokenA> <tokenB> <slippage> <deadline> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Swap Tokens
|
||||
|
||||
swap an exact amount of token a for token b
|
||||
Swap an exact amount of token a for token b
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx swap swap-exact-for-tokens <exactCoinA> <coinB> <slippage> <deadline> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```swap-exact-for-tokens``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```swap-exact-for-tokens``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Withdraw
|
||||
|
||||
withdraw coins from a swap liquidity pool
|
||||
Withdraw coins from a swap liquidity pool
|
||||
|
||||
## Command
|
||||
```
|
||||
kvcli tx swap withdraw <shares> <minCoinA> <minCoinB> <deadline> <flags>
|
||||
```
|
||||
|
||||
using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
|
||||
Using ```kvcli``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
|
||||
|
||||
### Arguments
|
||||
position|name|expects
|
||||
|
@ -1,61 +0,0 @@
|
||||
<!--
|
||||
order: 2
|
||||
-->
|
||||
|
||||
# Transaction Creation
|
||||
|
||||
One of the fundamental ways to interact with a Kava Node is through the use of ```kvcli```. It can be used to create new transactions from the user, which will later be broadcasted to other nodes in the network after going through validations and signing. the ```kvcli``` commands for transaction creation will all follow a very similar pattern across modules and it will follow the structure below:
|
||||
|
||||
```
|
||||
kvcli tx [module_name] [command_name] [arguments] [flags]
|
||||
```
|
||||
|
||||
| key | explanation |
|
||||
|-----------|---|
|
||||
| kvcli | calls the cli by its name |
|
||||
| tx | creates a transaction |
|
||||
| module_name | specifies the module which a transaction will be created |
|
||||
| command_name | specifies the type of transaction for the given module |
|
||||
| arguments | provide arguments for the transaction |
|
||||
| flags | provide flags for the transaction some of which can be required |
|
||||
|
||||
the flags are the last part of the command and depending on the module they can be required in order for the transaction command to be accepted. Flags are reserved to modify commands, all flags will have a default value. Some of these default values will be empty strings and as stated above they will need to be filled in in order for the command to be processed. a user can override any flag's default value by ```--flag_name [flag_value]```.
|
||||
|
||||
Users creating transactions will usually interact with the most common flags below:
|
||||
|
||||
|
||||
| Identifier | Purpose |
|
||||
|------------------|---------|
|
||||
| --from | transaction origin account |
|
||||
| --gas | how much gas a transaction consumes usually left as auto for estimation |
|
||||
| --gas-adjustment | optional flag for scaling up the gas flag to avoid underestimating |
|
||||
| --gas-prices | will set how much the user is willing to pay per gas unit |
|
||||
| --fees | will set the total fees the user is willing to pay |
|
||||
|
||||
the fees/gas prices that are calculated will decide if any given validator will decide to include the transaction in a new block by checking the value against their Node's minimum gas price. For that reason users are encouraged to pay more fees such that their transactions get added to a new block.
|
||||
|
||||
### Transaction example
|
||||
|
||||
given two accounts ```A``` & ```B``` the owner of account ```A``` would like to send some funds over to another account ```B``` , using the ```kvcli``` the user with account ```A``` would create a transaction that will follow this structure below:
|
||||
```
|
||||
kvcli tx send <B_Addr> 1000ukava --from <A_Addr> --gas-prices 0.50ukava
|
||||
```
|
||||
|
||||
## Transaction Journey
|
||||
|
||||
In the Cosmos SDK a transaction is defined as any user created object that must trigger state changes in the application. As such a transaction must be processed carefully and go through strict validation to ensure that it:
|
||||
|
||||
1. Provides all the required fields.
|
||||
2. The transaction is Valid.
|
||||
3. The user is authorized and has the fees to pay for the transaction.
|
||||
4. The transaction is not repeated or malicious in any way.
|
||||
|
||||
### Mempool
|
||||
the first step for a transaction is for it to end up in the Mempool such that it can be processed by Validators and added to a new Block. In order for the transaction to be added into the Mempool it must pass a couple validation steps.
|
||||
|
||||
1. Pass basic stateless checks that are quick in nature and act as a quick way to disqualify a transaction immediately, if it is failing to provide basic fields such as address, etc.
|
||||
2. Pass stateful checks which will required more thorough testing such as the address are valid, have enough funds, and are authorized to create the transaction. The reason this is stateful is because the node will create the state copy and run the transaction in it to validate it.
|
||||
|
||||
### Proposal
|
||||
|
||||
Once a transaction is in the Mempool and a Proposer is chosen from the set of validators, the Proposer includes it in the new block. And a series of checks are ran by other validators to run the transactions and if everything is valid a new block will be created.
|
Loading…
Reference in New Issue
Block a user