app, docs: update Bech32 HRP to ethm (#476)

* changelog

* app, docs: update Bech32 HRP

* changelog
This commit is contained in:
Federico Kunze Küllmer
2021-08-23 07:21:27 +00:00
committed by GitHub
parent 83f5ab671b
commit 9dcbebafb8
8 changed files with 47 additions and 41 deletions
+12 -12
View File
@@ -24,8 +24,8 @@ The root HD path for Ethermint-based accounts is `m/44'/60'/0'/0`.
[BIP-0173](https://github.com/satoshilabs/slips/blob/master/slip-0173.md) defines a new format for segregated witness output addresses that contains a human-readable part that identifies the Bech32 usage. Ethermint uses the following HRP (human readable prefix) as the base HRP:
| Network | Mainnet | Testnet | Regtest |
| --------- | ------- | ------- | ------- |
| Ethermint | `eth` | `eth` | |
|-----------|---------|---------|---------|
| Ethermint | `ethm` | `ethm` | |
There are 3 main types of HRP for the `Addresses`/`PubKeys` available by default on Ethermint:
@@ -35,19 +35,19 @@ There are 3 main types of HRP for the `Addresses`/`PubKeys` available by default
| | Address bech32 Prefix | Pubkey bech32 Prefix | Curve | Address byte length | Pubkey byte length |
|--------------------|-----------------------|----------------------|-----------------|---------------------|--------------------|
| Accounts | `eth` | `ethpub` | `eth_secp256k1` | `20` | `33` (compressed) |
| Validator Operator | `ethvaloper` | `ethvaloperpub` | `eth_secp256k1` | `20` | `33` (compressed) |
| Consensus Nodes | `ethvalcons` | `ethvalconspub` | `ed25519` | `20` | `32` |
| Accounts | `ethm` | `ethpub` | `eth_secp256k1` | `20` | `33` (compressed) |
| Validator Operator | `ethmvaloper` | `ethmvaloperpub` | `eth_secp256k1` | `20` | `33` (compressed) |
| Consensus Nodes | `ethmvalcons` | `ethmvalconspub` | `ed25519` | `20` | `32` |
## Address formats for clients
`EthAccount` can be represented in both [Bech32](https://en.bitcoin.it/wiki/Bech32) (`eth1...`) and hex (`0x...`) formats for Ethereum's Web3 tooling compatibility.
`EthAccount` can be represented in both [Bech32](https://en.bitcoin.it/wiki/Bech32) (`ethm1...`) and hex (`0x...`) formats for Ethereum's Web3 tooling compatibility.
The Bech32 format is the default format for Cosmos-SDK queries and transactions through CLI and REST
clients. The hex format on the other hand, is the Ethereum `common.Address` representation of a
Cosmos `sdk.AccAddress`.
- **Address (Bech32)**: `eth14au322k9munkmx5wrchz9q30juf5wjgz2cfqku`
- **Address (Bech32)**: `ethm14au322k9munkmx5wrchz9q30juf5wjgz2cfqku`
- **Address ([EIP55](https://eips.ethereum.org/EIPS/eip-55) Hex)**: `0xAF79152AC5dF276D9A8e1E2E22822f9713474902`
- **Compressed Public Key**: `{"@type":"/ethermint.crypto.v1beta1.ethsecp256k1.PubKey","key":"ApNNebT58zlZxO2yjHiRTJ7a7ufjIzeq5HhLrbmtg9Y/"}`
@@ -56,18 +56,18 @@ Cosmos `sdk.AccAddress`.
The `ethermintd debug addr <address>` can be used to convert an address between hex and bech32 formats. For example:
```bash
ethermintd debug addr eth10jmp6sgh4cc6zt3e8gw05wavvejgr5pw2unfju
ethermintd debug addr ethm10jmp6sgh4cc6zt3e8gw05wavvejgr5pw2unfju
Address bytes: [124 182 29 65 23 174 49 161 46 57 58 28 250 59 172 102 100 129 208 46]
Address (hex): 7CB61D4117AE31A12E393A1CFA3BAC666481D02E
Address (EIP-55): 0x7cB61D4117AE31a12E393a1Cfa3BaC666481D02E
Bech32 Acc: eth10jmp6sgh4cc6zt3e8gw05wavvejgr5pw2unfju
Bech32 Acc: ethm10jmp6sgh4cc6zt3e8gw05wavvejgr5pw2unfju
Bech32 Val: ethvaloper10jmp6sgh4cc6zt3e8gw05wavvejgr5pw5wdauz
ethermintd debug addr 0x7cB61D4117AE31a12E393a1Cfa3BaC666481D02E
Address bytes: [124 182 29 65 23 174 49 161 46 57 58 28 250 59 172 102 100 129 208 46]
Address (hex): 7CB61D4117AE31A12E393A1CFA3BAC666481D02E
Address (EIP-55): 0x7cB61D4117AE31a12E393a1Cfa3BaC666481D02E
Bech32 Acc: eth10jmp6sgh4cc6zt3e8gw05wavvejgr5pw2unfju
Bech32 Acc: ethm10jmp6sgh4cc6zt3e8gw05wavvejgr5pw2unfju
Bech32 Val: ethvaloper10jmp6sgh4cc6zt3e8gw05wavvejgr5pw5wdauz
```
@@ -84,7 +84,7 @@ obtain the addresses and keys as mentioned above,
ethermintd keys show mykey --bech acc
- name: mykey
type: local
address: eth1qsklxwt77qrxur494uvw07zjynu03dq9alwh37
address: ethm1qsklxwt77qrxur494uvw07zjynu03dq9alwh37
pubkey: '{"@type":"/ethermint.crypto.v1.ethsecp256k1.PubKey","key":"A8nbJ3eW9oAb2RNZoS8L71jFMfjk6zVa1UISYgKK9HPm"}'
mnemonic: ""
@@ -126,7 +126,7 @@ ethermintd q auth account $(ethermintd keys show <MYKEY> -a) -o text
``` bash
# GET /cosmos/auth/v1beta1/accounts/{address}
curl -X GET "http://localhost:10337/cosmos/auth/v1beta1/accounts/eth14au322k9munkmx5wrchz9q30juf5wjgz2cfqku" -H "accept: application/json"
curl -X GET "http://localhost:10337/cosmos/auth/v1beta1/accounts/ethm14au322k9munkmx5wrchz9q30juf5wjgz2cfqku" -H "accept: application/json"
```
### JSON-RPC
+3 -3
View File
@@ -65,12 +65,12 @@ We view testnet participation as a great way to signal to the community that you
In short, there are two types of keys:
- **Tendermint Key**: This is a unique key used to sign consensus votes.
- It is associated with a public key `ethvalconspub` (Get this value with `ethermintd tendermint show-validator`)
- It is associated with a public key `ethmvalconspub` (Get this value with `ethermintd tendermint show-validator`)
- It is generated when the node is created with `ethermintd init`.
- **Application key**: This key is created from `ethermintd` and used to sign transactions. Application keys are associated with a public key prefixed by `ethpub` and an address prefixed by `eth`. Both are derived from account keys generated by `ethermintd keys add`.
- **Application key**: This key is created from `ethermintd` and used to sign transactions. Application keys are associated with a public key prefixed by `ethpub` and an address prefixed by `ethm`. Both are derived from account keys generated by `ethermintd keys add`.
Note: A validator's operator key is directly tied to an application key, but
uses reserved prefixes solely for this purpose: `ethvaloper` and `ethvaloperpub`
uses reserved prefixes solely for this purpose: `ethmvaloper` and `ethmvaloperpub`
### What are the different states a validator can be in?
+2 -2
View File
@@ -38,7 +38,7 @@ To run testnet nodes, you will need a machine with the following minimum require
## Create Your Validator
Your `ethvalconspub` can be used to create a new validator by staking tokens. You can find your validator pubkey by running:
Your `ethmvalconspub` can be used to create a new validator by staking tokens. You can find your validator pubkey by running:
```bash
ethermintd tendermint show-validator
@@ -80,7 +80,7 @@ You can confirm that you are in the validator set by using a third party explore
If you want to participate in genesis as a validator, you need to justify that
you have some stake at genesis, create one (or multiple) transactions to bond this stake to your validator address, and include this transaction in the genesis file.
Your `ethvalconspub` can be used to create a new validator by staking tokens. You can find your validator pubkey by running:
Your `ethmvalconspub` can be used to create a new validator by staking tokens. You can find your validator pubkey by running:
```bash
ethermintd tendermint show-validator
+6 -6
View File
@@ -11,10 +11,10 @@ There are multiple ways to interact with a node: using the CLI, using gRPC or us
Now that your very own node is running, it is time to try sending tokens from the first account you created to a second account. In a new terminal window, start by running the following query command:
```bash
ethermintd query bank balances $MY_VALIDATOR_ADDRESS --chain-id=ethermintd-1
ethermintd query bank balances $MY_VALIDATOR_ADDRESS --chain-id=ethermint_9000-1
```
You should see the current balance of the account you created, equal to the original balance of `eth` you granted it minus the amount you delegated via the `gentx`. Now, create a second account:
You should see the current balance of the account you created, equal to the original balance of tokens you granted it minus the amount you delegated via the `gentx`. Now, create a second account:
```bash
ethermintd keys add recipient --keyring-backend=file
@@ -26,19 +26,19 @@ RECIPIENT=$(ethermintd keys show recipient -a --keyring-backend=file)
The command above creates a local key-pair that is not yet registered on the chain. An account is created the first time it receives tokens from another account. Now, run the following command to send tokens to the `recipient` account:
```bash
ethermintd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000000aphoton --chain-id=ethermintd-1 --keyring-backend=file
ethermintd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000000aphoton --chain-id=ethermint_9000-1 --keyring-backend=file
# Check that the recipient account did receive the tokens.
ethermintd query bank balances $RECIPIENT --chain-id=ethermintd-1
ethermintd query bank balances $RECIPIENT --chain-id=ethermint_9000-1
```
Finally, delegate some of the stake tokens sent to the `recipient` account to the validator:
```bash
ethermintd tx staking delegate $(ethermintd keys show my_validator --bech val -a --keyring-backend=file) 500aphoton --from=recipient --chain-id=ethermintd-1 --keyring-backend=file
ethermintd tx staking delegate $(ethermintd keys show my_validator --bech val -a --keyring-backend=file) 500aphoton --from=recipient --chain-id=ethermint_9000-1 --keyring-backend=file
# Query the total delegations to `validator`.
ethermintd query staking delegations-to $(ethermintd keys show my_validator --bech val -a --keyring-backend=file) --chain-id=ethermintd-1
ethermintd query staking delegations-to $(ethermintd keys show my_validator --bech val -a --keyring-backend=file) --chain-id=ethermint_9000-1
```
You should see two delegations, the first one made from the `gentx`, and the second one you just performed from the `recipient` account.