From cfb95ce18230356d364bde3958234df9c281d680 Mon Sep 17 00:00:00 2001 From: NodeJom <128386488+NodeJom@users.noreply.github.com> Date: Fri, 8 Dec 2023 16:56:44 +0100 Subject: [PATCH 01/75] Update participants.mdx Fixed some typos and changed the command to generate the genesis key --- .../pages/operators/networks/genesis-flow/participants.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 47d8a8c6..ec08def2 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -21,7 +21,7 @@ This can be done through the namada cli: ```bash ALIAS="" -namadac gen key --alias $ALIAS --pre-genesis +namadaw --pre-genesis key gen --alias $ALIAS ``` After the user has entered their passwords and written down their mnemonic phrase, the namada cli will save the keys to the `pre-genesis` folder inside the [base directory](../../ledger/base-directory.mdx). @@ -89,7 +89,7 @@ Derived established account address: tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2d It is useful to save this address for later use. ```bash -ESTABLISHED_ACCOUNT_ADDRESS=tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpx +ESTABLISHED_ACCOUNT_ADDRESS=tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2dxk ``` This will generate a `transactions.toml` file that contains the pre-genesis transaction that will establish the account. The `transactions.toml` file should look something like this: @@ -201,4 +201,4 @@ Once all pre-genesis transactions have been generated and signed, the pre-genesi By convention, a directory for each pre-genesis network participant is created in the git repository. The `signed-transactions.toml` file is then submitted to the respective directory. - \ No newline at end of file + From d501d7a68c518a20bd601d00350eb6af86a8ef4c Mon Sep 17 00:00:00 2001 From: NodeJom <128386488+NodeJom@users.noreply.github.com> Date: Fri, 8 Dec 2023 17:01:18 +0100 Subject: [PATCH 02/75] Update participants.mdx Updated init-genesis-established-account command details --- .../operators/networks/genesis-flow/participants.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 47d8a8c6..ca834e0d 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -75,7 +75,7 @@ The `$ALIAS` variable is the alias of the pre-genesis keys that were generated i ```bash #Ensure $BASE_DIR is set to the base directory TX_FILE_PATH="$BASE_DIR/pre-genesis/transactions.toml" -namadac utils init-genesis-established-account --path $TX_FILE_PATH --alias $ALIAS +namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $ALIAS # You can change the `--path` argument to any file path, but the recommended is `$BASE_DIR/pre-genesis/transactions.toml` ``` @@ -103,13 +103,13 @@ public_keys = ["tpknam1qr872zwdvw4u4nkpl0ykmvhyvxw7j0u6g7ymz03d7he0jr3szkuwczddj #### Generate a pre-genesis multisignature account -In order to generate a pre-genesis multisignature account, simply add multiple `--alias` flags to the command: +In order to generate a pre-genesis multisignature account, just add --aliases. With the list of key aliases to use, separated by commas. ```bash # Ensure $BASE_DIR is set to the base directory # Assuming that the values of $ALIAS1, $ALIAS2, and $ALIAS3 are the aliases of the pre-genesis keys that were generated in the [Generating keys](#generating-keys) step. TX_FILE_PATH="$BASE_DIR/pre-genesis/transactions.toml" -namadac utils init-genesis-established-account --path $TX_FILE_PATH --alias $ALIAS1 --alias $ALIAS2 --alias $ALIAS3 +namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $ALIAS1,$ALIAS2,$ALIAS3 ``` The command will ouptut the generated address of the multisignature account. @@ -201,4 +201,4 @@ Once all pre-genesis transactions have been generated and signed, the pre-genesi By convention, a directory for each pre-genesis network participant is created in the git repository. The `signed-transactions.toml` file is then submitted to the respective directory. - \ No newline at end of file + From fdc80604a9f240bbf708ef5a473ad7aedb650866 Mon Sep 17 00:00:00 2001 From: aztbll <117690729+aztbll@users.noreply.github.com> Date: Fri, 8 Dec 2023 16:22:22 +0000 Subject: [PATCH 03/75] Update participants.mdx change the IP address field from default to users own IP --- .../pages/operators/networks/genesis-flow/participants.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 47d8a8c6..0a8e8213 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -144,10 +144,11 @@ Once the pre-genesis network participants have generated respective pre-genesis EMAIL="" SELF_BOND_AMOUNT=1000000 # Set this to the amount of NAM you want to self-bond VALIDATOR_ALIAS="" +IP_ADDRESS="" namadac utils init-genesis-validator \ --address $ESTABLISHED_ACCOUNT_ADDRESS \ --alias $VALIDATOR_ALIAS \ - --net-address "127.0.0.1:26656" \ + --net-address "$IP_ADDRESS:26656" \ --commission-rate 0.05 \ --max-commission-rate-change 0.01 \ --self-bond-amount $SELF_BOND_AMOUNT \ @@ -201,4 +202,4 @@ Once all pre-genesis transactions have been generated and signed, the pre-genesi By convention, a directory for each pre-genesis network participant is created in the git repository. The `signed-transactions.toml` file is then submitted to the respective directory. - \ No newline at end of file + From 5c65e43d765e9e0ec0ee8fb1aadf927d5c04b8f7 Mon Sep 17 00:00:00 2001 From: msobh13 <78115394+msobh13@users.noreply.github.com> Date: Sat, 9 Dec 2023 16:30:06 +0400 Subject: [PATCH 04/75] Create Remote_Signing.mdx Horcrux with Namada Blockchain for High Availability and Security --- .../docs/pages/operators/Remote_Signing.mdx | 218 ++++++++++++++++++ 1 file changed, 218 insertions(+) create mode 100644 packages/docs/pages/operators/Remote_Signing.mdx diff --git a/packages/docs/pages/operators/Remote_Signing.mdx b/packages/docs/pages/operators/Remote_Signing.mdx new file mode 100644 index 00000000..a85db33c --- /dev/null +++ b/packages/docs/pages/operators/Remote_Signing.mdx @@ -0,0 +1,218 @@ +import { Callout } from 'nextra-theme-docs' + + +# Horcrux with Namada Blockchain for High Availability and Security + +This guide is intended for operators of Namada Validators. +The guide assumes that you have already installed the node and are familiar with the basics of running a node. +This guide will assume you already using single Namada node and it is working as validator . +This guide will use horcrux as remote signing cluster with 3 Namada nodes to provide High Availability +and Security by eliminating the single point of Failure and to remove the validator signing key from the node for more security . + +### Design: + 3 horcrux servers as remote Signers cluster + 3 Namada Nodes. ( Best to host with different Hosting Providers Ex: AWS , Google , Contabo ) + +### Software Requirements: + OS : Ubuntu 22.04.3 + App : horcrux v3.2.2 + +### Hardware Requirements for Signers: + 3x VPS w/ 2 CPU, 2 GB RAM, 20 GB SSD + +### FW open ports : + 19901 for Nodes and 2222 for Signers - you can chose any port you want + +### DNS records : + 3 cname ( node1 , node2,node3 ) for nodes + 3 cname ( signer1,signer2,signer3 ) for signers + +## Run These steps on your all signers servers: + + * Create directory to organize your horcrux files + +```shell copy +mkdir horcruxNamada +``` +```shell copy +cd horcruxNamada +``` + +* Download horcrux binary v3.2.2 to all your signers + +```shell copy +wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.2/horcrux_linux-amd64 +``` + +* Rename horcrux_linux-amd64 to horcrux and copy it to /usr/bin/ and /usr/local/sbin/: + +```shell copy +mv horcrux_linux-amd64 horcrux +``` + +```shell copy +sudo cp horcrux /usr/bin/ +``` + +```shell copy +sudo cp horcrux /usr/local/sbin/horcrux +``` + +* Create a horcrux service: + +```shell copy +sudo nano /etc/systemd/system/hornamada.service +``` + +* Paste below content inside: + +[Unit] +Description= horcrux Signer For Namada +After=network.target + +[Service] +Type=simple +User=YOUR_LINUX_USER +WorkingDirectory=PATH_To_horcruxNamada +ExecStart=/usr/bin/horcrux start --home PATH_To_horcruxNamada +Restart=on-failure +RestartSec=3 +LimitNOFILE=4096 + +[Install] +WantedBy=multi-user.target + + +* Enable the service using: + +```shell copy +sudo systemctl enable hornamada.service +``` + + +### These steps are only for your first Signer ( Signer 1 ): + +* copy your Namada priv_validator_key.json from namada directory cometbft/config to horcruxNamada folder located in your first horcrux signing server ( Signer 1 ) + +we will use FQDN instead of IP for easy preferred way and we will use port 19901 for Nodes and port 2222 for signers + +```shell copy +horcrux config init --node "tcp://node1.YOURDOMAIN:19901" --node "tcp://node2.YOURDOMAIN:19901" --node "tcp://node3.YOURDOMAIN:19901" --cosigner "tcp://signer1.YOURDOMAIN.net:2222" --cosigner "tcp://signer2.YOURDOMAIN:2222" --cosigner "tcp://signer3.YOURDOMAIN:2222" --threshold 2 --grpc-timeout 1500ms --raft-timeout 1500ms --home PATH_To_horcruxNamada +``` +```shell copy +horcrux create-ecies-shards --shards 3 --home PATH_To_horcruxNamada +``` +```shell copy +horcrux create-ed25519-shards --chain-id NAMADA_CHAIN_ID --key-file PATH_To_horcruxNamada/priv_validator_key.json --threshold 2 --shards 3 --home PATH_To_horcruxNamada +``` + +The above steps will generate cosigner communication encryption keys + +and you should find new files and new folders inside your horcruxNamada that similar to below + + priv_validator_key.json + config.yaml + cosigner_1/ecies_keys.json + cosigner_2/ecies_keys.json + cosigner_3/ecies_keys.json + state + +* move your priv_validator_key.json to secure location as we don’t need it anymore + +* create a new file inside state folder named NAMADA-CHAIN-ID_priv_validator_state.json + +This file will hold the signing state for the cluster + +please change the NAMADA-CHAIN-ID with the Namada Chain ID + +* paste the blew content to it + +{ + "height": "0", + "round": "0", + " step": 3 +} + + +* Copy horcruxNamada folder to your both other signers using scp + +After copying your horcruxNamada folder to the second signer + +you will need to delete both folders named ( cosigner_1 , cosigner_3 ) and their content from horcruxNamada folder inside ( signer 2 ) + +This will lead to having Only two Folders cosigner_2 folder and state folder + +* Copy cosigner_2 content ( ecies_keys.json ) to horcruxNamada Folder + +So in the end in ( singer 2 ) , horcruxNamada folder content should be link this + +config.yaml +ecies_keys.json +cosigner_2 +state\NAMADA-CHAIN-ID_priv_validator_state.json +state + +* Repeat same steps with signer 3 . horcruxNamada folder content in signer 3 server should be link this + +config.yaml +ecies_keys.json +cosigner_3 +state\NAMADA-CHAIN-ID_priv_validator_state.json +state + +### These steps will be applied for First Namada Node + +* configure namada to start using the horcrux cluster for signing blocks by editing config.toml located in Namada config folder + +Search for + +priv_validator_laddr = "" + +* replace it with + +priv_validator_laddr = "0.0.0.0:19901" + + +* remove the priv_validator_key.json from the node and store it in secure location as we don’t need it anymore + +* stop NAMADA node and ONLY after it stopped open the file priv_validator_state.json inside the cometbft/data and check the “height” number + +* go to each signer and edit the NAMADA-CHAIN-ID_priv_validator_state.json inside the horcruxNamada/state with the “height” number you just got + +from your Namada Validator state should be like this + +{ + "height": "YOUR_NAMADA_height", + "round": "0", + " step": 3 +} + +* Start your first horcrux signer process inside signer one and check the logs + +```shell copy +sudo systemctl restart hornamada.service && sudo journalctl -u hornamada.service -f --output cat +``` + + +* start signer 2 and signer 3 horcrux signer process and watch the logs + +* start your Namada process on your First Node and check the logs + +If everything is working your node should start signing blocks + +* Install 2 Namada Nodes in different servers and edit their config file as we did with node 1 + +### WARNING : +FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING priv_validator_laddr = "0.0.0.0:19901" AND REMOVE THE ORIGNAL priv_validator_key.json FROM ALL NODES +PLEASE NOTE THAT USING REMOTE SIGNING COULD LEAD TO DOUBLE SIGNING AND SLASHING IF YOUR NODE SIGNED SAME BLOCK TWICE, +SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME . + + +### TROUBLESHOUTING : + * check FW ports + * check dns for signers and node cnames + * check files and folder paths for horcrux + * check same horcrux version on all signers + * PING RTT time between nodes and signers ( more delay more issues ) + + From b959e75f4fc07b6d0159c7f7a712575633fe6d20 Mon Sep 17 00:00:00 2001 From: msobh13 <78115394+msobh13@users.noreply.github.com> Date: Wed, 13 Dec 2023 21:33:19 +0400 Subject: [PATCH 05/75] Update Remote_Signing.mdx changed the Horcrus version to v3.2.3 --- packages/docs/pages/operators/Remote_Signing.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/operators/Remote_Signing.mdx b/packages/docs/pages/operators/Remote_Signing.mdx index a85db33c..0dacb3fa 100644 --- a/packages/docs/pages/operators/Remote_Signing.mdx +++ b/packages/docs/pages/operators/Remote_Signing.mdx @@ -38,10 +38,10 @@ mkdir horcruxNamada cd horcruxNamada ``` -* Download horcrux binary v3.2.2 to all your signers +* Download horcrux binary v3.2.3 to all your signers ```shell copy -wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.2/horcrux_linux-amd64 +wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.3/horcrux_linux-amd64 ``` * Rename horcrux_linux-amd64 to horcrux and copy it to /usr/bin/ and /usr/local/sbin/: From 18a986f8c0f422ee643bf14cca8a74d50ca57ffe Mon Sep 17 00:00:00 2001 From: msobh13 <78115394+msobh13@users.noreply.github.com> Date: Wed, 13 Dec 2023 21:34:55 +0400 Subject: [PATCH 06/75] Update Remote_Signing.mdx Changed Horcrux version to v3.2.3 --- packages/docs/pages/operators/Remote_Signing.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/operators/Remote_Signing.mdx b/packages/docs/pages/operators/Remote_Signing.mdx index 0dacb3fa..da020a64 100644 --- a/packages/docs/pages/operators/Remote_Signing.mdx +++ b/packages/docs/pages/operators/Remote_Signing.mdx @@ -15,7 +15,7 @@ and Security by eliminating the single point of Failure and to remove the valida ### Software Requirements: OS : Ubuntu 22.04.3 - App : horcrux v3.2.2 + App : horcrux v3.2.3 ### Hardware Requirements for Signers: 3x VPS w/ 2 CPU, 2 GB RAM, 20 GB SSD From c59e525b3ab85a36f3caa5b36512a84d3dc90902 Mon Sep 17 00:00:00 2001 From: aquariusluo <61925921+aquariusluo@users.noreply.github.com> Date: Thu, 14 Dec 2023 16:54:21 +0800 Subject: [PATCH 07/75] Update local-network.mdx Invalid type for pos_params.pipeline_len, which should be u64 not string. --- packages/docs/pages/operators/networks/local-network.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/operators/networks/local-network.mdx b/packages/docs/pages/operators/networks/local-network.mdx index 5c2a809d..181dfb62 100644 --- a/packages/docs/pages/operators/networks/local-network.mdx +++ b/packages/docs/pages/operators/networks/local-network.mdx @@ -55,7 +55,7 @@ For example, a MacOS user would run something along the lines of: python3 ./scripts/gen_localnet.py \ --localnet-dir genesis/localnet \ --mode release # Assuming the binaries were built using `make build-release` \ ---parameters '{"parameters": {"max_expected_time_per_block": 10}, "pos_params": {"pipeline_len": "5"}}' +--parameters '{"parameters": {"max_expected_time_per_block": 10}, "pos_params": {"pipeline_len": 5}}' # In order to change max_expected_time_per_block to 10 seconds from the default 30, and the pipeline length to 5 epochs from the default 2. ``` From 947699d62c3c6c9c9fda04d953fd58c03fdbae8f Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Thu, 14 Dec 2023 11:39:31 +0000 Subject: [PATCH 08/75] testnet docs updated for testnet 15 v0.28.1 --- packages/docs/pages/networks/testnets.mdx | 4 ++-- packages/docs/pages/networks/testnets/testnet-history.mdx | 4 ++-- .../pages/operators/networks/genesis-flow/participants.mdx | 4 ++++ 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 7bc3d9e4..4875036c 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -6,8 +6,8 @@ For more context read: ## Latest Testnet - Namada public testnet 15: - - From date: 14th of December 2023 17:00 UTC - - Namada protocol version: `v0.28.0` + - From date: 18th of December 2023 17:00 UTC + - Namada protocol version: `v0.28.1` - Cometbft version: `0.37.2` - CHAIN_ID: `tbd` diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index e49c3f9b..89229220 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -11,8 +11,8 @@ No upgrades are currently scheduled. ## Latest Testnet - Namada public testnet 15: - - From date: 14th of December 2023 17:00 UTC - - Namada protocol version: `v0.28.0` + - From date: 18th of December 2023 17:00 UTC + - Namada protocol version: `v0.28.1` - Cometbft version: `0.37.2` - CHAIN_ID: `tbd` diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 1780c203..e5e299b3 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -142,6 +142,7 @@ Once the pre-genesis network participants have generated respective pre-genesis # Ensure $TX_FILE_PATH is set EMAIL="" +DISCORD_HANDLE="" # This is optional SELF_BOND_AMOUNT=1000000 # Set this to the amount of NAM you want to self-bond VALIDATOR_ALIAS="" namadac utils init-genesis-validator \ @@ -152,6 +153,7 @@ namadac utils init-genesis-validator \ --max-commission-rate-change 0.01 \ --self-bond-amount $SELF_BOND_AMOUNT \ --email $EMAIL \ + --discord-handle $DISCORD_HANDLE \ --path $TX_FILE_PATH ``` @@ -167,6 +169,8 @@ The `--commission-rate` and `--max-commision-rate` flags are the commission rate The `--email` flag is the email address of the validator account. This is used for the validator account to receive notifications from the network coordinator and other participants. +The optional `--discord-handle` flag is the discord handle of the validator account. This is used for the validator account to receive notifications from the network coordinator and other participants. + The `--address` flag is the Namada address of the account. The `--path` flag is the path to the `transactions.toml` file that will be appended to, and requires the established account to already be initialised under. From 5e91ec51d4b12d091019988e101726dd17006ceb Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 15 Dec 2023 16:31:55 +0000 Subject: [PATCH 09/75] better docs for joining network --- .../networks/testnets/joining-the-testnet.mdx | 29 +++++++++++++++++-- .../operators/validators/validator-setup.mdx | 2 ++ 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx index 2e38dd00..566f5ff4 100644 --- a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx +++ b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx @@ -1,11 +1,36 @@ +import { Callout } from 'nextra-theme-docs' + # Joining the latest testnet Depending on whether you are a genesis validator, you can join the latest testnet either as a genesis validator or as a full node. ## Joining as a genesis validator -Joining the testnet validator is identical to that of a mainnet validator. -For this reason, please refer to [these docs](../../operators/validators/validator-setup.mdx#start-validating). +In order to join the network as a genesis validator, you will need to have been selected in the genesis ceremony. If you have not been selected, you can still join as a full node. +If you have been selected. You must run the following command: + +```bash +CHAIN_ID="" +VALIDATOR_ALIAS="" +namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS +``` + + +Note that if you use the above command, your pre-genesis wallet must be in the default base directory (`$BASE_DIR`). If the wallet is not in the default base directory, you must use the flag `--pre-genesis-path` instead. The value for this will be `$BASE_DIR/pre-genesis/$VALIDATOR_ALIAS`. + +E.g if your base directory is `.namada` and your validator alias is `my-validator`, then run the command + +```bash +CHAIN_ID="" +VALIDATOR_ALIAS="my-validator" +BASE_DIR=".namada" +namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS +``` + + +Running the node of a pre-genesis validator is identical to that of a mainnet validator. + +For this reason, please refer to [these docs](../../operators/validators/validator-setup.mdx#start-validating) for running the node. ## Joining as a full node If you are not a genesis validator, please follow the steps for [joining as a full node](../../operators/ledger/running-a-full-node.mdx). diff --git a/packages/docs/pages/operators/validators/validator-setup.mdx b/packages/docs/pages/operators/validators/validator-setup.mdx index dcb991d9..82e3f494 100644 --- a/packages/docs/pages/operators/validators/validator-setup.mdx +++ b/packages/docs/pages/operators/validators/validator-setup.mdx @@ -86,6 +86,8 @@ The local ledger node will also be setup to run this validator, you just have to ```shell copy namadan ledger run +# or for more verbose output: +# NAMADA_LOG=info CMT_LOG_LEVEL=p2p:none,pex:error NAMADA_CMT_STDOUT=true namadan ledger run ``` The ledger will then use the validator consensus key to sign blocks, should your validator account acquire enough voting power to be included in the active validator set. The size of the active validator set is limited to `128` (the limit is set by the PoS `max_validator_slots` parameter). From 3ea93ee8e10acc1cabff2c3669c99a9e512127d1 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Tue, 19 Dec 2023 18:04:27 +0100 Subject: [PATCH 10/75] first iteration of fixes --- .../docs/pages/operators/Remote_Signing.mdx | 218 ----------------- packages/docs/pages/operators/_meta.json | 1 + .../docs/pages/operators/remote-signing.mdx | 229 ++++++++++++++++++ 3 files changed, 230 insertions(+), 218 deletions(-) delete mode 100644 packages/docs/pages/operators/Remote_Signing.mdx create mode 100644 packages/docs/pages/operators/remote-signing.mdx diff --git a/packages/docs/pages/operators/Remote_Signing.mdx b/packages/docs/pages/operators/Remote_Signing.mdx deleted file mode 100644 index da020a64..00000000 --- a/packages/docs/pages/operators/Remote_Signing.mdx +++ /dev/null @@ -1,218 +0,0 @@ -import { Callout } from 'nextra-theme-docs' - - -# Horcrux with Namada Blockchain for High Availability and Security - -This guide is intended for operators of Namada Validators. -The guide assumes that you have already installed the node and are familiar with the basics of running a node. -This guide will assume you already using single Namada node and it is working as validator . -This guide will use horcrux as remote signing cluster with 3 Namada nodes to provide High Availability -and Security by eliminating the single point of Failure and to remove the validator signing key from the node for more security . - -### Design: - 3 horcrux servers as remote Signers cluster - 3 Namada Nodes. ( Best to host with different Hosting Providers Ex: AWS , Google , Contabo ) - -### Software Requirements: - OS : Ubuntu 22.04.3 - App : horcrux v3.2.3 - -### Hardware Requirements for Signers: - 3x VPS w/ 2 CPU, 2 GB RAM, 20 GB SSD - -### FW open ports : - 19901 for Nodes and 2222 for Signers - you can chose any port you want - -### DNS records : - 3 cname ( node1 , node2,node3 ) for nodes - 3 cname ( signer1,signer2,signer3 ) for signers - -## Run These steps on your all signers servers: - - * Create directory to organize your horcrux files - -```shell copy -mkdir horcruxNamada -``` -```shell copy -cd horcruxNamada -``` - -* Download horcrux binary v3.2.3 to all your signers - -```shell copy -wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.3/horcrux_linux-amd64 -``` - -* Rename horcrux_linux-amd64 to horcrux and copy it to /usr/bin/ and /usr/local/sbin/: - -```shell copy -mv horcrux_linux-amd64 horcrux -``` - -```shell copy -sudo cp horcrux /usr/bin/ -``` - -```shell copy -sudo cp horcrux /usr/local/sbin/horcrux -``` - -* Create a horcrux service: - -```shell copy -sudo nano /etc/systemd/system/hornamada.service -``` - -* Paste below content inside: - -[Unit] -Description= horcrux Signer For Namada -After=network.target - -[Service] -Type=simple -User=YOUR_LINUX_USER -WorkingDirectory=PATH_To_horcruxNamada -ExecStart=/usr/bin/horcrux start --home PATH_To_horcruxNamada -Restart=on-failure -RestartSec=3 -LimitNOFILE=4096 - -[Install] -WantedBy=multi-user.target - - -* Enable the service using: - -```shell copy -sudo systemctl enable hornamada.service -``` - - -### These steps are only for your first Signer ( Signer 1 ): - -* copy your Namada priv_validator_key.json from namada directory cometbft/config to horcruxNamada folder located in your first horcrux signing server ( Signer 1 ) - -we will use FQDN instead of IP for easy preferred way and we will use port 19901 for Nodes and port 2222 for signers - -```shell copy -horcrux config init --node "tcp://node1.YOURDOMAIN:19901" --node "tcp://node2.YOURDOMAIN:19901" --node "tcp://node3.YOURDOMAIN:19901" --cosigner "tcp://signer1.YOURDOMAIN.net:2222" --cosigner "tcp://signer2.YOURDOMAIN:2222" --cosigner "tcp://signer3.YOURDOMAIN:2222" --threshold 2 --grpc-timeout 1500ms --raft-timeout 1500ms --home PATH_To_horcruxNamada -``` -```shell copy -horcrux create-ecies-shards --shards 3 --home PATH_To_horcruxNamada -``` -```shell copy -horcrux create-ed25519-shards --chain-id NAMADA_CHAIN_ID --key-file PATH_To_horcruxNamada/priv_validator_key.json --threshold 2 --shards 3 --home PATH_To_horcruxNamada -``` - -The above steps will generate cosigner communication encryption keys - -and you should find new files and new folders inside your horcruxNamada that similar to below - - priv_validator_key.json - config.yaml - cosigner_1/ecies_keys.json - cosigner_2/ecies_keys.json - cosigner_3/ecies_keys.json - state - -* move your priv_validator_key.json to secure location as we don’t need it anymore - -* create a new file inside state folder named NAMADA-CHAIN-ID_priv_validator_state.json - -This file will hold the signing state for the cluster - -please change the NAMADA-CHAIN-ID with the Namada Chain ID - -* paste the blew content to it - -{ - "height": "0", - "round": "0", - " step": 3 -} - - -* Copy horcruxNamada folder to your both other signers using scp - -After copying your horcruxNamada folder to the second signer - -you will need to delete both folders named ( cosigner_1 , cosigner_3 ) and their content from horcruxNamada folder inside ( signer 2 ) - -This will lead to having Only two Folders cosigner_2 folder and state folder - -* Copy cosigner_2 content ( ecies_keys.json ) to horcruxNamada Folder - -So in the end in ( singer 2 ) , horcruxNamada folder content should be link this - -config.yaml -ecies_keys.json -cosigner_2 -state\NAMADA-CHAIN-ID_priv_validator_state.json -state - -* Repeat same steps with signer 3 . horcruxNamada folder content in signer 3 server should be link this - -config.yaml -ecies_keys.json -cosigner_3 -state\NAMADA-CHAIN-ID_priv_validator_state.json -state - -### These steps will be applied for First Namada Node - -* configure namada to start using the horcrux cluster for signing blocks by editing config.toml located in Namada config folder - -Search for - -priv_validator_laddr = "" - -* replace it with - -priv_validator_laddr = "0.0.0.0:19901" - - -* remove the priv_validator_key.json from the node and store it in secure location as we don’t need it anymore - -* stop NAMADA node and ONLY after it stopped open the file priv_validator_state.json inside the cometbft/data and check the “height” number - -* go to each signer and edit the NAMADA-CHAIN-ID_priv_validator_state.json inside the horcruxNamada/state with the “height” number you just got - -from your Namada Validator state should be like this - -{ - "height": "YOUR_NAMADA_height", - "round": "0", - " step": 3 -} - -* Start your first horcrux signer process inside signer one and check the logs - -```shell copy -sudo systemctl restart hornamada.service && sudo journalctl -u hornamada.service -f --output cat -``` - - -* start signer 2 and signer 3 horcrux signer process and watch the logs - -* start your Namada process on your First Node and check the logs - -If everything is working your node should start signing blocks - -* Install 2 Namada Nodes in different servers and edit their config file as we did with node 1 - -### WARNING : -FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING priv_validator_laddr = "0.0.0.0:19901" AND REMOVE THE ORIGNAL priv_validator_key.json FROM ALL NODES -PLEASE NOTE THAT USING REMOTE SIGNING COULD LEAD TO DOUBLE SIGNING AND SLASHING IF YOUR NODE SIGNED SAME BLOCK TWICE, -SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME . - - -### TROUBLESHOUTING : - * check FW ports - * check dns for signers and node cnames - * check files and folder paths for horcrux - * check same horcrux version on all signers - * PING RTT time between nodes and signers ( more delay more issues ) - - diff --git a/packages/docs/pages/operators/_meta.json b/packages/docs/pages/operators/_meta.json index 15b68b28..e1533fdc 100644 --- a/packages/docs/pages/operators/_meta.json +++ b/packages/docs/pages/operators/_meta.json @@ -1,6 +1,7 @@ { "hardware": "Hardware requirements", "ledger": "Running a full node", + "remote-signing": "Remote signing", "validators": "Validators", "networks": "Starting a network", "ibc": "IBC Relayers", diff --git a/packages/docs/pages/operators/remote-signing.mdx b/packages/docs/pages/operators/remote-signing.mdx new file mode 100644 index 00000000..3ce8a81a --- /dev/null +++ b/packages/docs/pages/operators/remote-signing.mdx @@ -0,0 +1,229 @@ +import { Callout } from 'nextra-theme-docs' + + +# Horcrux with Namada Blockchain for High Availability and Security + +This guide is intended for operators of Namada Validators. +This guide uses Horcrux as its remote signing cluster with 3 Namada nodes to provide high availability +and security. It does this by eliminating the single point of failure and to remove the validator signing key from the node for more security. + +### Design: + 3 horcrux servers as remote Signers cluster + 3 Namada Nodes. + +### Software Requirements: + OS : Ubuntu 22.04.3 + App : horcrux v3.2.3 + +### Hardware Requirements for Signers: + 3x VPS w/ 2 CPU, 2 GB RAM, 20 GB SSD + +### FW open ports : + 19901 for Nodes and 2222 for Signers - you can chose any port you want + +### DNS records : + 3 cname ( node1 , node2,node3 ) for nodes + 3 cname ( signer1,signer2,signer3 ) for signers + +## Run These steps on your all signers servers: + +1. Create the directory to organize your horcrux files + +```shell copy +mkdir HorcruxNamada +HORCRUX_PATH=$(pwd)/HorcruxNamada +``` +```shell copy +cd HorcruxNamada +``` + +2. Download the horcrux binary v3.2.3 + +```shell copy +wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.3/horcrux_linux-amd64 +``` + +3. Rename horcrux_linux-amd64 to horcrux and copy it to /usr/bin/ and /usr/local/sbin/: + +```shell copy +mv horcrux_linux-amd64 horcrux +``` + +```shell copy +sudo cp horcrux /usr/bin/ +``` + +```shell copy +sudo cp horcrux /usr/local/sbin/horcrux +``` + +4. Create a horcrux service: + +```shell copy +sudo nano /etc/systemd/system/hornamada.service +``` + +5. Paste below content inside: + +```shell +[Unit] +Description= horcrux Signer For Namada +After=network.target + +[Service] +Type=simple +User=YOUR_LINUX_USER +WorkingDirectory=$HORCRUX_PATH #but use the string value +ExecStart=/usr/bin/horcrux start --home $HORCRUX_PATH #but use the string value +Restart=on-failure +RestartSec=3 +LimitNOFILE=4096 + +[Install] +WantedBy=multi-user.target +``` + +6. Enable the service using: + +```shell copy +sudo systemctl enable hornamada.service +``` + + +### The below steps are only for your first signer ( Signer 1 ): + +1. Copy your Namada `priv_validator_key.json` from the `cometbft/config` directory (located in `$BASE_DIR`) to the newly created `HorcruxNamada` folder. + +(Optional) Use FQDN instead of IP, port 19901 for Nodes and port 2222 for signers + +2. Run the following commands to initialize the horcrux cluster: + +```shell copy +YOURDOMAIN="" +horcrux config init --node "tcp://node1.$YOURDOMAIN:19901" --node "tcp://node2.$YOURDOMAIN:19901" --node "tcp://node3.$YOURDOMAIN:19901" --cosigner "tcp://signer1.$YOURDOMAIN.net:2222" --cosigner "tcp://signer2.$YOURDOMAIN:2222" --cosigner "tcp://signer3.$YOURDOMAIN:2222" --threshold 2 --grpc-timeout 1500ms --raft-timeout 1500ms --home $HORCRUX_PATH +``` +```shell copy + +horcrux create-ecies-shards --shards 3 --home $HORCRUX_PATH +``` +```shell copy +NAMADA_CHAIN_ID="" +horcrux create-ed25519-shards --chain-id $NAMADA_CHAIN_ID --key-file $HORCRUX_PATH/priv_validator_key.json --threshold 2 --shards 3 --home $HORCRUX_PATH +``` + +The above steps will generate cosigner communication encryption keys. +Expect to find new files and new folders inside `HorcruxNamada`: + +```shell + priv_validator_key.json + config.yaml + cosigner_1/ecies_keys.json + cosigner_2/ecies_keys.json + cosigner_3/ecies_keys.json + state +``` + +3. Move your `priv_validator_key.json` to a secure location as we don’t need it anymore. + +4. Create a new file inside state folder named `${NAMADA_CHAIN_ID}_priv_validator_state.json` + +This file will hold the signing state for the cluster. + +5. Paste the belew content to it: + +```json +{ + "height": "0", + "round": "0", + " step": 3 +} +``` + +5. Copy the `HorcruxNamada` directory to the other signers using `scp`. + +After copying your HorcruxNamada folder to the second signer you will need to delete both folders named ( cosigner_1 , cosigner_3 ) and their content from HorcruxNamada folder inside ( signer 2 ) . + +This will lead to having Only two Folders cosigner_2 folder and a state folder. + +6. Copy cosigner_2 content ( ecies_keys.json ) to the `HorcruxNamada` Folder + +So in the end in ( singer 2 ) , `HorcruxNamada` folder content should be: + +```shell +config.yaml +ecies_keys.json +cosigner_2 +state\NAMADA-CHAIN-ID_priv_validator_state.json +state +``` +7. Repeat same steps with signer 3 . `HorcruxNamada` folder content in signer 3 server should be: + +```shell +config.yaml +ecies_keys.json +cosigner_3 +state\NAMADA-CHAIN-ID_priv_validator_state.json +state +``` + +### These steps will be applied to the first Namada node + +1. Configure Namada to start using the Horcrux cluster for signing blocks by editing the `config.toml` located in Namada config folder. + +Search for + +```toml +priv_validator_laddr = "" +``` + +Replace it with + +```toml +priv_validator_laddr = "0.0.0.0:19901" +``` + +2. remove the priv_validator_key.json from the node and store it in secure location as we don’t need it anymore + +3. stop NAMADA node and ONLY after it stopped open the file priv_validator_state.json inside the cometbft/data and check the “height” number + +4. go to each signer and edit the NAMADA-CHAIN-ID_priv_validator_state.json inside the horcruxNamada/state with the “height” number you just got + +from your Namada Validator state should be like this + +```json +{ + "height": "", + "round": "0", + " step": 3 +} +``` + +5. Start your first horcrux signer process inside signer one and check the logs + +```shell copy +sudo systemctl restart hornamada.service && sudo journalctl -u hornamada.service -f --output cat +``` + + +6. start signer 2 and signer 3 horcrux signer process and watch the logs + +7. start your Namada process on your First Node and check the logs + +If everything is working your node should start signing blocks + +8. Install 2 Namada Nodes in different servers and edit their config file as we did with node 1 + +### WARNING : +FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING priv_validator_laddr = "0.0.0.0:19901" AND REMOVE THE ORIGNAL priv_validator_key.json FROM ALL NODES +PLEASE NOTE THAT USING REMOTE SIGNING COULD LEAD TO DOUBLE SIGNING AND SLASHING IF YOUR NODE SIGNED SAME BLOCK TWICE, +SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME . + + +### TROUBLESHOUTING : + * check FW ports + * check dns for signers and node cnames + * check files and folder paths for horcrux + * check same horcrux version on all signers + * PING RTT time between nodes and signers ( more delay more issues ) + + From ea3496c59d8aff1ca1466b926ec47245f4f7525f Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Wed, 20 Dec 2023 14:11:35 +0100 Subject: [PATCH 11/75] improvements done --- .../docs/pages/operators/remote-signing.mdx | 91 ++++++++++--------- 1 file changed, 48 insertions(+), 43 deletions(-) diff --git a/packages/docs/pages/operators/remote-signing.mdx b/packages/docs/pages/operators/remote-signing.mdx index 3ce8a81a..a0dc8eff 100644 --- a/packages/docs/pages/operators/remote-signing.mdx +++ b/packages/docs/pages/operators/remote-signing.mdx @@ -1,38 +1,46 @@ import { Callout } from 'nextra-theme-docs' + +These docs were kindly created by community member [CryptoSJ](https://github.com/msobh13) and have been edited for readability purposes. If you have any suggestions, please open an [issue](https://github.com/anoma/namada-docs/issues) or a [pull request](https://github.com/anoma/namada-docs/pulls) at the github repository. + + # Horcrux with Namada Blockchain for High Availability and Security -This guide is intended for operators of Namada Validators. -This guide uses Horcrux as its remote signing cluster with 3 Namada nodes to provide high availability -and security. It does this by eliminating the single point of failure and to remove the validator signing key from the node for more security. +This guide is intended for Namada Validator operators. It outlines the use of Horcrux as a remote signing cluster with three Namada nodes to enhance high availability and security. This approach eliminates single points of failure and enhances validator signing key security. + +## Design: + +- Three Horcrux servers serve as the remote signers cluster. +- Three Namada Nodes are used as validators. + +## Software Requirements: + +- Operating System: Ubuntu 22.04.3 +- Application: Horcrux v3.2.3 + +## Hardware Requirements for Signers: -### Design: - 3 horcrux servers as remote Signers cluster - 3 Namada Nodes. +- Three Virtual Private Servers (VPS) with 2 CPUs, 2 GB RAM, and 20 GB SSD each. -### Software Requirements: - OS : Ubuntu 22.04.3 - App : horcrux v3.2.3 +## Firewall Open Ports: -### Hardware Requirements for Signers: - 3x VPS w/ 2 CPU, 2 GB RAM, 20 GB SSD +- Ports 19901 for Nodes and 2222 for Signers (You can choose different ports if desired). -### FW open ports : - 19901 for Nodes and 2222 for Signers - you can chose any port you want +## DNS Records: -### DNS records : - 3 cname ( node1 , node2,node3 ) for nodes - 3 cname ( signer1,signer2,signer3 ) for signers +- Create three CNAME records for nodes: node1, node2, and node3. +- Create three CNAME records for signers: signer1, signer2, and signer3. -## Run These steps on your all signers servers: +## Run These Steps on All Signer Servers: -1. Create the directory to organize your horcrux files +1. Create a directory to organize your Horcrux files: ```shell copy mkdir HorcruxNamada HORCRUX_PATH=$(pwd)/HorcruxNamada ``` + ```shell copy cd HorcruxNamada ``` @@ -43,7 +51,7 @@ cd HorcruxNamada wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.3/horcrux_linux-amd64 ``` -3. Rename horcrux_linux-amd64 to horcrux and copy it to /usr/bin/ and /usr/local/sbin/: +3. Rename horcrux_linux-amd64 to "horcrux" and copy it to /usr/bin/ and /usr/local/sbin/: ```shell copy mv horcrux_linux-amd64 horcrux @@ -63,7 +71,7 @@ sudo cp horcrux /usr/local/sbin/horcrux sudo nano /etc/systemd/system/hornamada.service ``` -5. Paste below content inside: +5. Paste the following content: ```shell [Unit] @@ -90,11 +98,11 @@ sudo systemctl enable hornamada.service ``` -### The below steps are only for your first signer ( Signer 1 ): +### Activating the first signer ( Signer 1 ): 1. Copy your Namada `priv_validator_key.json` from the `cometbft/config` directory (located in `$BASE_DIR`) to the newly created `HorcruxNamada` folder. -(Optional) Use FQDN instead of IP, port 19901 for Nodes and port 2222 for signers +(Optional) This guide will be using FQDN instead of IP, port 19901 for Nodes and port 2222 for signers. Feel free to adjust based on your preferences. 2. Run the following commands to initialize the horcrux cluster: @@ -102,10 +110,11 @@ sudo systemctl enable hornamada.service YOURDOMAIN="" horcrux config init --node "tcp://node1.$YOURDOMAIN:19901" --node "tcp://node2.$YOURDOMAIN:19901" --node "tcp://node3.$YOURDOMAIN:19901" --cosigner "tcp://signer1.$YOURDOMAIN.net:2222" --cosigner "tcp://signer2.$YOURDOMAIN:2222" --cosigner "tcp://signer3.$YOURDOMAIN:2222" --threshold 2 --grpc-timeout 1500ms --raft-timeout 1500ms --home $HORCRUX_PATH ``` -```shell copy +```shell copy horcrux create-ecies-shards --shards 3 --home $HORCRUX_PATH ``` + ```shell copy NAMADA_CHAIN_ID="" horcrux create-ed25519-shards --chain-id $NAMADA_CHAIN_ID --key-file $HORCRUX_PATH/priv_validator_key.json --threshold 2 --shards 3 --home $HORCRUX_PATH @@ -123,13 +132,13 @@ Expect to find new files and new folders inside `HorcruxNamada`: state ``` -3. Move your `priv_validator_key.json` to a secure location as we don’t need it anymore. +3. Move your `priv_validator_key.json` to a secure location, as it will not be needed any more. -4. Create a new file inside state folder named `${NAMADA_CHAIN_ID}_priv_validator_state.json` +4. Create a new file inside the state folder named `${NAMADA_CHAIN_ID}_priv_validator_state.json` This file will hold the signing state for the cluster. -5. Paste the belew content to it: +5. Paste the belew content into it: ```json { @@ -141,13 +150,9 @@ This file will hold the signing state for the cluster. 5. Copy the `HorcruxNamada` directory to the other signers using `scp`. -After copying your HorcruxNamada folder to the second signer you will need to delete both folders named ( cosigner_1 , cosigner_3 ) and their content from HorcruxNamada folder inside ( signer 2 ) . - -This will lead to having Only two Folders cosigner_2 folder and a state folder. - -6. Copy cosigner_2 content ( ecies_keys.json ) to the `HorcruxNamada` Folder +After copying your `HorcruxNamada` folder to the second signer, you will need to delete both folders named cosigner_1 and cosigner_3, along with their content from the HorcruxNamada folder inside signer 2. This will leave only two folders: `cosigner_2` and `state`. -So in the end in ( singer 2 ) , `HorcruxNamada` folder content should be: +6. Copy `cosigner_2` content ( `ecies_keys.json` ) to the `HorcruxNamada` Folder: ```shell config.yaml @@ -156,7 +161,7 @@ cosigner_2 state\NAMADA-CHAIN-ID_priv_validator_state.json state ``` -7. Repeat same steps with signer 3 . `HorcruxNamada` folder content in signer 3 server should be: +7. Repeat same steps for signer 3. Thus, the `HorcruxNamada` folder content in the third server should be: ```shell config.yaml @@ -166,7 +171,7 @@ state\NAMADA-CHAIN-ID_priv_validator_state.json state ``` -### These steps will be applied to the first Namada node +### Apply these steps to the first Namada node 1. Configure Namada to start using the Horcrux cluster for signing blocks by editing the `config.toml` located in Namada config folder. @@ -182,13 +187,13 @@ Replace it with priv_validator_laddr = "0.0.0.0:19901" ``` -2. remove the priv_validator_key.json from the node and store it in secure location as we don’t need it anymore +2. Remove the priv_validator_key.json from the node and store it in secure location as we don’t need it anymore -3. stop NAMADA node and ONLY after it stopped open the file priv_validator_state.json inside the cometbft/data and check the “height” number +3. Stop the Namada node. ONLY after it stopped, open the file `priv_validator_state.json` inside the `cometbft/data` directory and check the “height” number. -4. go to each signer and edit the NAMADA-CHAIN-ID_priv_validator_state.json inside the horcruxNamada/state with the “height” number you just got +4. Go to each signer and edit the `NAMADA-CHAIN-ID_priv_validator_state.json` file inside the `HorcruxNamada/state` directory with the “height” number from step 3. -from your Namada Validator state should be like this +It should now look like this: ```json { @@ -198,23 +203,23 @@ from your Namada Validator state should be like this } ``` -5. Start your first horcrux signer process inside signer one and check the logs +5. Start your first `horcrux` signer process inside `Signer_One` and check the logs: ```shell copy sudo systemctl restart hornamada.service && sudo journalctl -u hornamada.service -f --output cat ``` -6. start signer 2 and signer 3 horcrux signer process and watch the logs +6. Start the signer 2 and signer 3 `horcrux signer` processes and watch the logs -7. start your Namada process on your First Node and check the logs +7. Start your Namada process on your first node and check the logs. -If everything is working your node should start signing blocks +If everything is working fine, your node should start signing blocks. 8. Install 2 Namada Nodes in different servers and edit their config file as we did with node 1 ### WARNING : -FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING priv_validator_laddr = "0.0.0.0:19901" AND REMOVE THE ORIGNAL priv_validator_key.json FROM ALL NODES +FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING `priv_validator_laddr = "0.0.0.0:19901"` AND REMOVE THE ORIGNAL `priv_validator_key.json` FROM ALL NODES PLEASE NOTE THAT USING REMOTE SIGNING COULD LEAD TO DOUBLE SIGNING AND SLASHING IF YOUR NODE SIGNED SAME BLOCK TWICE, SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME . From 8d66512219b016d880f9b96f9f8bb65a096f5f48 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Tue, 2 Jan 2024 17:09:45 +0000 Subject: [PATCH 12/75] cleanup --- packages/docs/pages/introduction/install/docker.mdx | 2 +- .../docs/pages/users/governance/off-chain-governance.mdx | 2 +- .../docs/pages/users/governance/on-chain-governance.mdx | 1 + packages/docs/pages/users/wallet/web-wallet.mdx | 6 +++--- 4 files changed, 6 insertions(+), 5 deletions(-) diff --git a/packages/docs/pages/introduction/install/docker.mdx b/packages/docs/pages/introduction/install/docker.mdx index 29ddc682..a967f76c 100644 --- a/packages/docs/pages/introduction/install/docker.mdx +++ b/packages/docs/pages/introduction/install/docker.mdx @@ -53,7 +53,7 @@ For example if you wanted to build the docker image for Namada v0.16.0 and chain ```bash copy export CHAIN_ID=public-testnet-69.0.b20a1337aa1 -export BRANCH=v0.16.0 +export BRANCH=v0.28.2 #The latest branch of Namada ``` Then you can build the docker image by running: diff --git a/packages/docs/pages/users/governance/off-chain-governance.mdx b/packages/docs/pages/users/governance/off-chain-governance.mdx index d764104d..0fe96379 100644 --- a/packages/docs/pages/users/governance/off-chain-governance.mdx +++ b/packages/docs/pages/users/governance/off-chain-governance.mdx @@ -24,7 +24,7 @@ To vote on an offline proposal use the following command: namada client vote-proposal --data-path proposal \ --vote yay \ --signing-keys your-signing-keys-for-voter \ - --voter your-established-account \ + --address your-established-account \ --offline ``` diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 53bd701b..13360627 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -158,6 +158,7 @@ Only delegators and delegates can vote on proposals. Assuming you fall into one namada client vote-proposal \ --proposal-id 0 \ --vote yay \ + --address \ --signing-keys ``` diff --git a/packages/docs/pages/users/wallet/web-wallet.mdx b/packages/docs/pages/users/wallet/web-wallet.mdx index 0f8a4295..46b0aa88 100644 --- a/packages/docs/pages/users/wallet/web-wallet.mdx +++ b/packages/docs/pages/users/wallet/web-wallet.mdx @@ -1,14 +1,14 @@ # Web Wallet ## Install -When Namada is in `mainnet`, the web wallet will be available in most browser extension web stores. For now, you can install it from source by following the instructions below. +When Namada is in [`mainnet`](../../networks/mainnets.mdx), the web wallet will be available in most browser extension web stores. For now, the user can install it from source by following the instructions below. ### Installing from source (for development and experiment purposes) #### Connect to a testnet or run a local node -1. Follow the instructions for the [testnets](../../networks/testnets.mdx) to connect to a testnet or set up a local node using [docker](../../introduction/install/docker.mdx). +1. Follow the instructions for the [testnets](../../networks/testnets.mdx) to connect to a testnet or [set up a local node](../../operators/networks/local-network.mdx). 2. Figure out where the base directory is stored and save its location as a variable such as `export BASE_DIR=`. - You can follow [these docs](../../networks/testnets/migrating-testnets.mdx#after-v0153) to save this variable. Go ahead and save the chain id as a variable as well. You can find the chain id by running `cat $BASE_DIR/global-config.toml`. Save this chain-id to the variable `export CHAIN_ID=`. + You can follow [these docs](../../networks/testnets/migrating-testnets.mdx) to save this variable. Go ahead and save the chain id as a variable as well. You can find the chain id by running `cat $BASE_DIR/global-config.toml`. Save this chain-id to the variable `export CHAIN_ID=`. 3. You will need to edit the CometBFT config in order to allow the web wallet to connect to your node. The CometBFT config will be located in `$BASE_DIR/$CHAIN_ID/cometbft/config/config.toml`. You will need to change the `cors_allowed_origins` field to `["*"]`. You can do this by running ```shell copy From 9965d474342f26b273f113cabc38cfb7072eed07 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 5 Jan 2024 13:49:31 +0000 Subject: [PATCH 13/75] chain id corrected --- packages/docs/pages/networks/testnets.mdx | 2 +- packages/docs/pages/networks/testnets/testnet-history.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 4875036c..f69bb254 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -9,7 +9,7 @@ For more context read: - From date: 18th of December 2023 17:00 UTC - Namada protocol version: `v0.28.1` - Cometbft version: `0.37.2` - - CHAIN_ID: `tbd` + - CHAIN_ID: `public-testnet-15.0dacadb8d663` The history of all testnets can be found [here](./testnets/testnet-history.mdx). diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index 89229220..33cb70af 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -14,7 +14,7 @@ No upgrades are currently scheduled. - From date: 18th of December 2023 17:00 UTC - Namada protocol version: `v0.28.1` - Cometbft version: `0.37.2` - - CHAIN_ID: `tbd` + - CHAIN_ID: `public-testnet-15.0dacadb8d663` ## Testnet History Timeline From 6d44385164924606d55935b5bc08e203dd655fa2 Mon Sep 17 00:00:00 2001 From: Dimitris Apostolou Date: Fri, 5 Jan 2024 20:27:29 +0200 Subject: [PATCH 14/75] Fix typos --- packages/docs/pages/integrating-with-namada/sdk.mdx | 2 +- .../pages/operators/networks/genesis-flow/coordinator.mdx | 4 ++-- .../pages/operators/networks/genesis-flow/participants.mdx | 4 ++-- packages/docs/pages/operators/remote-signing.mdx | 2 +- packages/docs/pages/users/fees.mdx | 2 +- .../docs/pages/users/governance/on-chain-governance.mdx | 4 ++-- packages/docs/pages/users/ibc.mdx | 2 +- packages/docs/pages/users/wallet.mdx | 2 +- packages/specs/pages/base-ledger.mdx | 2 +- packages/specs/pages/base-ledger/replay-protection.mdx | 6 +++--- .../pages/base-ledger/replay-protection/optimizations.mdx | 6 +++--- .../pages/economics/proof-of-stake/objects-and-txs.mdx | 4 ++-- .../economics/public-goods-funding/becoming-a-steward.mdx | 2 +- .../specs/pages/economics/public-goods-funding/electing.mdx | 2 +- packages/specs/pages/governance/on-chain.mdx | 2 +- packages/specs/pages/index.mdx | 2 +- .../ethereum-bridge/transfers_to_namada.mdx | 2 +- packages/specs/pages/masp/ledger-integration.mdx | 2 +- packages/specs/pages/masp/trusted-setup.mdx | 6 +++--- 19 files changed, 29 insertions(+), 29 deletions(-) diff --git a/packages/docs/pages/integrating-with-namada/sdk.mdx b/packages/docs/pages/integrating-with-namada/sdk.mdx index 7e0c181c..c19a5f70 100644 --- a/packages/docs/pages/integrating-with-namada/sdk.mdx +++ b/packages/docs/pages/integrating-with-namada/sdk.mdx @@ -6,7 +6,7 @@ The Namada software development kit (SDK) can be found in the `namada` repo unde ## Quick Start -A good starting point to see the SDK in use is to check-out the [namada interface](https://github.com/anoma/namada-interface/tree/main/packages/shared/lib/src/sdk) repo. This repo contains a simple web application that uses the SDK to interact with the Namada blockchain. However, it is important to note the added complexity arising from the application integrating javascript using [wasm-bindgen](https://rustwasm.github.io/docs/wasm-bindgen/), which is not necesary. +A good starting point to see the SDK in use is to check-out the [namada interface](https://github.com/anoma/namada-interface/tree/main/packages/shared/lib/src/sdk) repo. This repo contains a simple web application that uses the SDK to interact with the Namada blockchain. However, it is important to note the added complexity arising from the application integrating javascript using [wasm-bindgen](https://rustwasm.github.io/docs/wasm-bindgen/), which is not necessary. ## Installation diff --git a/packages/docs/pages/operators/networks/genesis-flow/coordinator.mdx b/packages/docs/pages/operators/networks/genesis-flow/coordinator.mdx index 41de6a9e..d66ff767 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/coordinator.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/coordinator.mdx @@ -12,7 +12,7 @@ The network coordinator is responsible for: ### Setup -The genesis ceremony preperation includes creating a coordinated location for the pre-genesis network participants to submit their public keys. The network coordinator is responsible for setting up this location. Conventionally, the network coordinator will host a git repository that allows the pre-genesis network participants to submit their public keys. The network coordinator must ensure that the git repository is publicly accessible and that the pre-genesis network participants are able to submit their public keys in a secure manner. +The genesis ceremony preparation includes creating a coordinated location for the pre-genesis network participants to submit their public keys. The network coordinator is responsible for setting up this location. Conventionally, the network coordinator will host a git repository that allows the pre-genesis network participants to submit their public keys. The network coordinator must ensure that the git repository is publicly accessible and that the pre-genesis network participants are able to submit their public keys in a secure manner. Further, the network coordinator is responsible for making clear timelines for the various steps in the genesis ceremony. The network coordinator must ensure that the pre-genesis network participants are aware of the timelines and that they are able to submit their public keys, transactions, and be online in due time. @@ -26,7 +26,7 @@ Conventionally, the network coordinator hosts a git repository that allows the p ### Allocating pre-genesis NAM balances -Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must allocate balances to these addresses/public keys. The coordinator will often have prior identity information associated with desired balances, which they will then associate with the public keys and addresses in order to set the correct balances in `balances.toml`. The coordinaotor must also ensure that the total pre-genesis NAM balances allocated to the pre-genesis network participants is equal to the total NAM supply. +Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must allocate balances to these addresses/public keys. The coordinator will often have prior identity information associated with desired balances, which they will then associate with the public keys and addresses in order to set the correct balances in `balances.toml`. The coordinator must also ensure that the total pre-genesis NAM balances allocated to the pre-genesis network participants is equal to the total NAM supply. After this is completed, the network coordinator will publish the `balances.toml` file that contains the pre-genesis NAM balances allocated to the pre-genesis network participants. The `balances.toml` file should be published in the same location as the pre-genesis public keys were submitted. diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 2682b839..18afb71f 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -80,7 +80,7 @@ namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $A # You can change the `--path` argument to any file path, but the recommended is `$BASE_DIR/pre-genesis/transactions.toml` ``` -The command will ouptut the generated address of the established account. +The command will output the generated address of the established account. ```text Derived established account address: tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2dxk @@ -114,7 +114,7 @@ TX_FILE_PATH="$BASE_DIR/pre-genesis/transactions.toml" namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $ALIAS1,$ALIAS2,$ALIAS3 ``` -The command will ouptut the generated address of the multisignature account. +The command will output the generated address of the multisignature account. ```text diff --git a/packages/docs/pages/operators/remote-signing.mdx b/packages/docs/pages/operators/remote-signing.mdx index a0dc8eff..b6acac1b 100644 --- a/packages/docs/pages/operators/remote-signing.mdx +++ b/packages/docs/pages/operators/remote-signing.mdx @@ -219,7 +219,7 @@ If everything is working fine, your node should start signing blocks. 8. Install 2 Namada Nodes in different servers and edit their config file as we did with node 1 ### WARNING : -FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING `priv_validator_laddr = "0.0.0.0:19901"` AND REMOVE THE ORIGNAL `priv_validator_key.json` FROM ALL NODES +FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING `priv_validator_laddr = "0.0.0.0:19901"` AND REMOVE THE ORIGINAL `priv_validator_key.json` FROM ALL NODES PLEASE NOTE THAT USING REMOTE SIGNING COULD LEAD TO DOUBLE SIGNING AND SLASHING IF YOUR NODE SIGNED SAME BLOCK TWICE, SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME . diff --git a/packages/docs/pages/users/fees.mdx b/packages/docs/pages/users/fees.mdx index 0084e0bf..9fdb0329 100644 --- a/packages/docs/pages/users/fees.mdx +++ b/packages/docs/pages/users/fees.mdx @@ -62,7 +62,7 @@ namadac transfer \ --dry-run-wrapper ``` -Which will ouptut something along the lines of +Which will output something along the lines of ```md Dry-run result: Transaction is valid. Gas used: 1785; diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 13360627..d4e82725 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -25,7 +25,7 @@ Now, we need to create a json file `proposal.json` holding the content of our pr "discussions-to": "forum.namada.net/t/namada-proposal/1", "created": "2069-04-20T00:04:44Z", "license": "MIT", - "abstract": "We present a proposal that will send our community to the moon. This proposal outlines all training necessary to accomplish this goal. All memers are welcome to join.", + "abstract": "We present a proposal that will send our community to the moon. This proposal outlines all training necessary to accomplish this goal. All members are welcome to join.", "motivation": "When you think about it, the moon isn't actually that far away.The moon is only 384,400 km. We have not yet brought Namada to the moon, so it is only natural to use 101 as the prime number for our modular arithmetic operations. 384,400 (mod 101) = 95. 95 km is a distance that can be easily covered by a single person in a single day. Namada was produced by more than 100 people. So 95/100 = 0, rounded to the nearest integer. This means that Namada can reach the moon in no time.", "details": "Bringing Namada to the moon in no time is easily achievable. We just need to pass this governance proposal and set the plan in action", "requires": "" @@ -50,7 +50,7 @@ You should change the value of: - `voting_end_epoch` with an epoch greater than `voting_start_epoch`, a multiple of 3, and by which no further votes will be accepted; - `grace_epoch` with an epoch greater than `voting_end_epoch` + 6, in which the proposal, if passed, will come into effect. -The `data` field and its structure is dependant on the type of proposal being submitted. Below we outline the structure of the "data" field for each type of proposal. The one given in the example above is for a `Default Proposal`. +The `data` field and its structure is dependent on the type of proposal being submitted. Below we outline the structure of the "data" field for each type of proposal. The one given in the example above is for a `Default Proposal`. ### Default Proposal diff --git a/packages/docs/pages/users/ibc.mdx b/packages/docs/pages/users/ibc.mdx index 9a898497..de6c5397 100644 --- a/packages/docs/pages/users/ibc.mdx +++ b/packages/docs/pages/users/ibc.mdx @@ -55,7 +55,7 @@ namadac --base-dir ${BASE_DIR_A} --node 127.0.0.1:27657 ``` -Once the transaction has been submitted, a relayer will need to relay the packet to the other chain. This is done automatically by the relayer running Hermes. If the packet is never succsesfully relayed, the funds are returned to the sender after a timeout. See more infomation in the [specs](https://specs.namada.net/interoperability/ibc). +Once the transaction has been submitted, a relayer will need to relay the packet to the other chain. This is done automatically by the relayer running Hermes. If the packet is never successfully relayed, the funds are returned to the sender after a timeout. See more information in the [specs](https://specs.namada.net/interoperability/ibc). ## Transferring assets back from Cosmos-SDK based chains diff --git a/packages/docs/pages/users/wallet.mdx b/packages/docs/pages/users/wallet.mdx index 2c7b7ea8..2e443513 100644 --- a/packages/docs/pages/users/wallet.mdx +++ b/packages/docs/pages/users/wallet.mdx @@ -4,7 +4,7 @@ This document describes the different wallet concepts and options that are avail ## A brief introduction to the Namada wallet The purpose of the Namada wallet is to provide a user-interface to store and manage both keys and addresses. -[Technically speaking](https://vitalik.ca/general/2017/01/14/exploring_ecp.html), keys are just (potentially) very large integers that have some meaning on an eliptic curve. +[Technically speaking](https://vitalik.ca/general/2017/01/14/exploring_ecp.html), keys are just (potentially) very large integers that have some meaning on an elliptic curve. The wallet simply "remembers" these very large numbers on your behalf. Keys are the fundamental building blocks for accounts on Namada. Keys come in the form of *pairs* (of secret and public key), and can be used to derive the **account address** (first 40 chars of the SHA256 hash of the public key). diff --git a/packages/specs/pages/base-ledger.mdx b/packages/specs/pages/base-ledger.mdx index 13eebfb1..07deacd1 100644 --- a/packages/specs/pages/base-ledger.mdx +++ b/packages/specs/pages/base-ledger.mdx @@ -9,4 +9,4 @@ The consensus mechanism on Namada provides an algorithmic way for validators to The validity-predicate based execution mechanism is inherited from the architectural design philosophy of Anoma. The fundamental idea is that a "valid state" is defined as that which satisfies a set of boolean conditions. These boolean conditions are encoded by functional "validity predicates", which are invoked whenever a state is being proposed. If all validity predicates in the system return the boolean `true`, this defines a valid state which validators can vote on. The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps. These execution steps are defined within the smart contract, and verifying the validity of the new state requires *each* validator to run the series of execution steps. ## Replay protection & block space allocator -In addition to describing the execuction model and consensus, this section also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), and [block space allocator](./base-ledger/block-space-allocator.mdx). +In addition to describing the execution model and consensus, this section also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), and [block space allocator](./base-ledger/block-space-allocator.mdx). diff --git a/packages/specs/pages/base-ledger/replay-protection.mdx b/packages/specs/pages/base-ledger/replay-protection.mdx index e815ff43..ace8f53a 100644 --- a/packages/specs/pages/base-ledger/replay-protection.mdx +++ b/packages/specs/pages/base-ledger/replay-protection.mdx @@ -41,7 +41,7 @@ transaction is composed of two parts: a `WrapperTx` and an inner `Tx` {/* TODO: Check that this is up to date. I believe it is not */} ```rust pub struct WrapperTx { - /// The fee to be payed for including the tx + /// The fee to be paid for including the tx pub fee: Fee, /// Used to determine an implicit account of the fee payer pub pk: common::PublicKey, @@ -68,7 +68,7 @@ pub struct Tx { The wrapper transaction is composed of some metadata, an optional unshielding tx for fee payment (see [fee specs](../economics/fee-system.mdx)), the encrypted -inner transaction itself and the hash of the concatenation of these values. {/* TODO: Ensure that the hash of concatentation statement is as accurate as possible. It could be values, it could be the object (which consists of keys + values)*/} +inner transaction itself and the hash of the concatenation of these values. {/* TODO: Ensure that the hash of concatenation statement is as accurate as possible. It could be values, it could be the object (which consists of keys + values)*/} The inner `Tx` transaction carries the Wasm code to be executed and the associated data. A transaction is constructed as follows: @@ -153,7 +153,7 @@ has an internal replay protection mechanism. Still, since this field represents a valid, `Transaction`, there is a possible attack that can be run by leveraging this field: a malicious user could extract -this data before it makes it to a block, embedd it into a valid, masp signed +this data before it makes it to a block, embed it into a valid, masp signed `Tx` and apply it in advance. This attack is performed before the original tx is placed in a block and, diff --git a/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx b/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx index ddc0573b..fe97287f 100644 --- a/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx +++ b/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx @@ -1,6 +1,6 @@ import { Callout } from 'nextra-theme-docs' -{/* TODO: Maket this section more clear. At the moment I'm not sure what optmisation is what in the "possible optimisations" */} +{/* TODO: Maket this section more clear. At the moment I'm not sure what optimisation is what in the "possible optimisations" */} # Possible optimizations In this section we describe two alternative solutions that come with some optimizations. @@ -387,7 +387,7 @@ the following: ```rust pub struct WrapperTx { - /// The fee to be payed for including the tx + /// The fee to be paid for including the tx pub fee: Fee, /// Used to determine an implicit account of the fee payer pub pk: common::PublicKey, @@ -495,7 +495,7 @@ validate it. These will involve: These checks can all be done before executing the transactions themselves. If any of these fails, the transaction should be considered invalid and the action -to take will be one of the followings: +to take will be one of the following: 1. If the checks fail on the signature, chainId, expiration or transaction counter, then this transaction will be forever invalid, regardless of the diff --git a/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx b/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx index 6d4104a1..806fd80e 100644 --- a/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx +++ b/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx @@ -297,7 +297,7 @@ type Unbonds = HashMap>; struct BondId { validator: Address, - /// The delegator adddress for delegations, or the same as the `validator` + /// The delegator address for delegations, or the same as the `validator` /// address for self-bonds. source: Address, } @@ -310,7 +310,7 @@ struct Bond { struct Unbond { /// A key is a pair of the epoch of the bond from which a unbond was created - /// the epoch of unboding. This is needed for slash epoch range check. + /// the epoch of unbonding. This is needed for slash epoch range check. deltas: HashMap<(Epoch, Epoch), token::Amount> } ``` diff --git a/packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx b/packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx index 1b16fc15..b8622c90 100644 --- a/packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx +++ b/packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx @@ -52,7 +52,7 @@ There are 4 ways that a Steward may be removed from the steward set: 4. They reach the end of their term Resigning as a Steward is straight-forward. A simple interface is implemented to allow for the established account -representing the Steward to lose their priveleges as a PGF Steward. +representing the Steward to lose their privileges as a PGF Steward. If a steward's PGF proposal receives a significant number of `Nay` votes ($\frac{2}{3}$ as a fraction of voting-power voted and more than two-thirds of the votes are `Nay`), they will be removed from the steward set. diff --git a/packages/specs/pages/economics/public-goods-funding/electing.mdx b/packages/specs/pages/economics/public-goods-funding/electing.mdx index 582ef3fe..e6dfc385 100644 --- a/packages/specs/pages/economics/public-goods-funding/electing.mdx +++ b/packages/specs/pages/economics/public-goods-funding/electing.mdx @@ -24,7 +24,7 @@ The `id` will correspond to the `id` of the `StewardProposal` that is being vote #### Dealing with ties -In the rare occurence of a tie, the `StewardProposal` is rejected, i.e. the current steward-set remains the same. +In the rare occurrence of a tie, the `StewardProposal` is rejected, i.e. the current steward-set remains the same. ## Electing stewards diff --git a/packages/specs/pages/governance/on-chain.mdx b/packages/specs/pages/governance/on-chain.mdx index 7f0a5e84..39b796ce 100644 --- a/packages/specs/pages/governance/on-chain.mdx +++ b/packages/specs/pages/governance/on-chain.mdx @@ -100,7 +100,7 @@ Storage writes for a vote transaction are described [here](./storage.mdx#votes). If non-validating accounts are allowed to vote, delegates will be able to vote only for $\frac{2}{3}$ of the total voting period, while delegators can vote until the end of the voting period. If only validators are allowed to vote for the `ProposalType` in question, they are allowed to vote for the entire voting window. -If a delegator votes differently to its delegate, the delegate's vote will be *overriden* +If a delegator votes differently to its delegate, the delegate's vote will be *overridden* (e.g. if a delegator has a voting power of 200 and votes opposite to the delegate, then 200 will be subtracted from the voting power of the involved delegate). diff --git a/packages/specs/pages/index.mdx b/packages/specs/pages/index.mdx index bbb8071f..efcc742e 100644 --- a/packages/specs/pages/index.mdx +++ b/packages/specs/pages/index.mdx @@ -14,7 +14,7 @@ Users of the MASP are [rewarded](./economics/shielded-pool-incentives.mdx) for t Namada supports a variety of different wallets. One of these wallets is the native wallet, that exists in order to facilitate interacting with the protocol in a safe and private manner. -Furhter, Namada supports Shielded Actions, which allows users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains. +Further, Namada supports Shielded Actions, which allows users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains. You can learn more about Namada [here](https://blog.namada.net/introducing-namada-interchain-asset-agnostic-privacy/). diff --git a/packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx b/packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx index 2d1001e9..6effc2a2 100644 --- a/packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx +++ b/packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx @@ -8,7 +8,7 @@ will be two internal accounts with associated native validity predicates: ["multitoken"](../../base-ledger/fungible-token.html#multitoken) hierarchy. Also contains in escrow Namada tokens which have been sent to Ethereum, pertaining to pending wNAM transfers. -- `#EthBridgePool` - Holds gas fees to be payed to relayers of transfers to Ethereum, +- `#EthBridgePool` - Holds gas fees to be paid to relayers of transfers to Ethereum, as well assets (other than wNAM) in escrow, pertaining to pending transfers to Ethereum. diff --git a/packages/specs/pages/masp/ledger-integration.mdx b/packages/specs/pages/masp/ledger-integration.mdx index b284562d..46d74d9b 100644 --- a/packages/specs/pages/masp/ledger-integration.mdx +++ b/packages/specs/pages/masp/ledger-integration.mdx @@ -315,7 +315,7 @@ The [Multi-Asset Shielded Pool Specification](https://github.com/anoma/masp/blob * `HomomorphicPedersenCommit`, `ValueCommit`, and value base must be parameterized by asset type * [5.5 Encodings of Note Plaintexts and Memo Fields](https://zips.z.cash/protocol/protocol.pdf#notept) * The note plaintext tuple must include asset type - * The Sapling note plaintext encoding must use 32 bytes inbetween `d` and `v` to encode asset type + * The Sapling note plaintext encoding must use 32 bytes in between `d` and `v` to encode asset type * Hence the total size of a note plaintext encoding should be 596 bytes * [5.6 Encodings of Addresses and Keys](https://zips.z.cash/protocol/protocol.pdf#addressandkeyencoding) * Bech32m \[[BIP-0350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)\] is used instead of Bech32 \[[ZIP-173](https://zips.z.cash/zip-0173)\] to further encode the raw encodings diff --git a/packages/specs/pages/masp/trusted-setup.mdx b/packages/specs/pages/masp/trusted-setup.mdx index 0a4e726c..25f12682 100644 --- a/packages/specs/pages/masp/trusted-setup.mdx +++ b/packages/specs/pages/masp/trusted-setup.mdx @@ -70,7 +70,7 @@ Let's go through each subcomponents and describe them. ### Description -The CL handles the operation steps of the ceremony: adding a new contributor to the queue, authentificating a contributor, sending and receiving challenge files, removing inactive contributors, reattributing challenge file to a new contributor after a contributor dropped, verifying contributions, creating new files... +The CL handles the operation steps of the ceremony: adding a new contributor to the queue, authenticating a contributor, sending and receiving challenge files, removing inactive contributors, reattributing challenge file to a new contributor after a contributor dropped, verifying contributions, creating new files... ### "Historical" context @@ -79,7 +79,7 @@ The CL was originally implemented for the Powers of Tau (phase 1 of the MPC). In ### CL in the Namada context Splitting the parameters into multiple chunks is useful, if it takes hours to contribute. In our case, the contribution time is about some seconds and in the worst case about some minutes. So, we don't need to split the parameters into chunks. Though, since we forked from the Aleo Trusted Setup, we still have some references to "chunked" things like folder, variable or function names. In our implementation, this means that we have one contributor and one chunk per round. For example, the contribution file of a round `i` from a participant will always be located at `transcript/round_{i}/chunk_0/contribution_1.unverified`. -To be able to re-use the CL without heavy refactoring, we decided to keep most of the Aleo code as it is and only change the parts that needed to be changed, more precisely the crypto functions (`initialize`, `contribute` and `verify`) and the coordinator config `environment.rs`. +To be able to reuse the CL without heavy refactoring, we decided to keep most of the Aleo code as it is and only change the parts that needed to be changed, more precisely the crypto functions (`initialize`, `contribute` and `verify`) and the coordinator config `environment.rs`. ## 2. HTTP REST API @@ -103,7 +103,7 @@ The [HTTP REST API](https://github.com/anoma/namada-trusted-setup/blob/9c3e6c63c - `/contribution_info` Retrieve the contributions' info. This endpoint is accessible by anyone and does not require a signed request. - `/healthcheck` Retrieve healthcheck info. This endpoint is accessible by anyone and does not require a signed request. -![](/images/trusted-setup-assets/namda-ts-swimlane.png) +![](/images/trusted-setup-assets/namada-ts-swimlane.png) ### Saved files From 0e62742ef5d42b4d1f4ecc2eb3ea655aa9193a67 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Wed, 10 Jan 2024 16:28:45 +0000 Subject: [PATCH 15/75] changed most namadaw functions --- .../docs/pages/introduction/quick-start.mdx | 4 ++-- packages/docs/pages/operators/ibc.mdx | 2 +- .../networks/genesis-flow/participants.mdx | 2 +- .../operators/validators/validator-setup.mdx | 2 +- .../docs/pages/users/transparent-accounts.mdx | 22 ++++++++----------- .../transparent-accounts/multisignature.mdx | 10 ++------- 6 files changed, 16 insertions(+), 26 deletions(-) diff --git a/packages/docs/pages/introduction/quick-start.mdx b/packages/docs/pages/introduction/quick-start.mdx index c52b2ab8..8108c2f7 100644 --- a/packages/docs/pages/introduction/quick-start.mdx +++ b/packages/docs/pages/introduction/quick-start.mdx @@ -47,7 +47,7 @@ This should sync your node to the ledger and will take a while (depending on you First you will need an implicit account in order to receive tokens. You can generate one with: ```shell copy -namadaw address gen --alias +namadaw gen --alias ``` For the remainder of this introduction, let's assume your go-to alias is `stanley`. @@ -55,7 +55,7 @@ For the remainder of this introduction, let's assume your go-to alias is `stanle This will generate a new account and store it in the default keychain. You can see the account with: ```shell copy -namadaw address list +namadaw list --addr ``` {/* #TODO: ADD some output */} diff --git a/packages/docs/pages/operators/ibc.mdx b/packages/docs/pages/operators/ibc.mdx index 4282ff05..06eaf58f 100644 --- a/packages/docs/pages/operators/ibc.mdx +++ b/packages/docs/pages/operators/ibc.mdx @@ -166,7 +166,7 @@ cp ./target/release/hermes /usr/local/bin/ ### Create the relayer account On each chain, there must be a `relayer` account. The alias should be the same as `chains.key_name` in the config. On a namada chain, this can be done by running ```bash copy -namadaw key gen --alias relayer +namadaw gen key --alias relayer ``` This will generate a key for the relayer account. The key will be stored in the `wallet.toml` that is found in the [base directory](./ledger/base-directory.mdx) of the node, inside the `chain-id` folder. For example, if the `chain-id` is `namada-test.0a4c6786dbda39f786`, the `wallet.toml` will be found in `$HOME/.local/share/namada/namada-test.0a4c6786dbda39f786/wallet.toml` (on a ubuntu machine where `base-dir` has not been set up properly). diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 2682b839..0836d166 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -21,7 +21,7 @@ This can be done through the namada cli: ```bash ALIAS="" -namadaw --pre-genesis key gen --alias $ALIAS +namadaw --pre-genesis gen --alias $ALIAS ``` After the user has entered their passwords and written down their mnemonic phrase, the namada cli will save the keys to the `pre-genesis` folder inside the [base directory](../../ledger/base-directory.mdx). diff --git a/packages/docs/pages/operators/validators/validator-setup.mdx b/packages/docs/pages/operators/validators/validator-setup.mdx index 82e3f494..908fa632 100644 --- a/packages/docs/pages/operators/validators/validator-setup.mdx +++ b/packages/docs/pages/operators/validators/validator-setup.mdx @@ -30,7 +30,7 @@ The user must first generate a key pair for their validator account. ```bash copy KEY_ALIAS="aliace" -namada wallet key gen --alias $KEY_ALIAS +namada wallet gen --alias $KEY_ALIAS ``` Now choose a name for your validator: diff --git a/packages/docs/pages/users/transparent-accounts.mdx b/packages/docs/pages/users/transparent-accounts.mdx index 6021b831..f4eec0a3 100644 --- a/packages/docs/pages/users/transparent-accounts.mdx +++ b/packages/docs/pages/users/transparent-accounts.mdx @@ -29,11 +29,11 @@ Note the use of the placeholder `keysha` for the key parameter. This is a compl ```shell copy KEY_ALIAS="keysha" -namada wallet key gen --alias $KEY_ALIAS +namada wallet gen --alias $KEY_ALIAS ``` -The derived implicit address shares the same `keysha` alias. The previous command has the same effect as `namada wallet address gen --alias keysha`. +The derived implicit address shares the same `keysha` alias. The previous command has the same effect as `namada wallet gen --alias keysha`. By default, the keys are stored encrypted. @@ -43,7 +43,7 @@ Namada wallet supports keypair generation using a [mnemonic code](https://github To generate a keypair for a default path use ```shell copy KEY_ALIAS="keysha" -namada wallet key gen --alias $KEY_ALIAS --hd-path default +namada wallet gen --alias $KEY_ALIAS --hd-path default ``` @@ -67,7 +67,7 @@ namada wallet key restore --alias keysha --hd-path default ### List all known keys ```shell copy -namada wallet key list +namada wallet list --keys ``` ## Manage addresses @@ -76,32 +76,28 @@ namada wallet key list To manage addresses, similar to keys, various sub-commands are available: ```shell copy -namada wallet address +namada wallet --help ``` ### Generate an implicit address Let's call the implicit address `accountant`: ```shell copy -namada wallet address gen --alias accountant +namada wallet gen --alias accountant ``` - -Note that this will also generate and save a key from which the address was derived and save it under the same `accountant` alias. Thus, this command has the same effect as `namada wallet key gen --alias accountant`. - - ```shell copy -namada wallet address gen --alias keysha --hd-path default +namada wallet gen --alias keysha --hd-path default ``` generates an address using a [mnemonic code](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) and [HD derivation path](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki). ### Restore the address ```shell copy -namada wallet address restore --alias keysha --hd-path default +namada wallet derive --alias keysha --hd-path default ``` ### List all known addresses ```shell copy -namada wallet address list +namada wallet list --addr ``` \ No newline at end of file diff --git a/packages/docs/pages/users/transparent-accounts/multisignature.mdx b/packages/docs/pages/users/transparent-accounts/multisignature.mdx index d363f3be..43496e87 100644 --- a/packages/docs/pages/users/transparent-accounts/multisignature.mdx +++ b/packages/docs/pages/users/transparent-accounts/multisignature.mdx @@ -16,21 +16,15 @@ Before creating an account, a user must generate at least one cryptographic `key The following method will generate such a key: ```shell -namadaw key gen \ +namadaw gen \ --alias my-key1 ``` A second key can be generated as well (which will be useful for multisigs): ```shell -namadaw key gen \ +namadaw gen \ --alias my-key2 ``` -An implicit address can also be generated: -```shell -namadaw address gen \ ---alias my-address -``` - Accounts on Namada are initialised through the following method: **Non-multisig account (single signer)** From b3be9e553d334ab511831956074a0652ada1e8a9 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 12 Jan 2024 18:13:53 +0000 Subject: [PATCH 16/75] shielded expedition added --- packages/docs/pages/networks/testnets.mdx | 8 ++++++++ .../networks/testnets/environment-setup.mdx | 4 ++-- .../testnets/genesis-validator-apply.mdx | 6 ++++-- .../networks/testnets/joining-the-testnet.mdx | 11 +++++++++++ .../pages/networks/testnets/testnet-history.mdx | 8 ++++++++ .../networks/genesis-flow/participants.mdx | 17 ++++++++++++++++- 6 files changed, 49 insertions(+), 5 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index f69bb254..082e1783 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -4,6 +4,14 @@ For more context read: [Announcing Namada Public Testnets](https://blog.namada.net/announcing-namada-public-testnets/) +## Shielded expedition + +- Namada Shielded expedition 1: + - From date: `TBD` + - Namada protocol version: `TBD` + - Cometbft version: `0.37.2` + - CHAIN_ID: `TBD` + ## Latest Testnet - Namada public testnet 15: - From date: 18th of December 2023 17:00 UTC diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index 6a8128bc..edeaa9c9 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.23.1 +export NAMADA_TAG=v0.29.0 ``` @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.23.1` + - `namada --version` should output `Namada v0.29.0` diff --git a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx index f437ce7c..8f57113f 100644 --- a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx +++ b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx @@ -9,10 +9,12 @@ Before a testnet launches, you can apply to be a genesis validator. Follow [this guide](../../operators/validators/validator-setup.mdx#pre-genesis) on how to generate your "pre-genesis" validator files. -All pre-genesis validators are expected to bond `1000000` NAM tokens. At least that many tokens will be allocated to the pre-genesis validator key +For the shielded expedition, the `balances.toml` file has been published at the [namada-shieled-expedition repository](https://github.com/anoma/namada-shielded-expedition). +Amounts bonded in the bonding transactions must be less than or equal to the amounts specified in the `balances.toml` file. +It is recommended to leave at least 1000 `NAAN` unbonded for transaction fees. -After this, you'll have a signed `transactions.toml` file, the contents of which will look something like the following: +After this, you will have a signed `transactions.toml` file, the contents of which will look something like the following: ```toml [[established_account]] diff --git a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx index 566f5ff4..51a8ce4e 100644 --- a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx +++ b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx @@ -7,6 +7,11 @@ Depending on whether you are a genesis validator, you can join the latest testne ## Joining as a genesis validator In order to join the network as a genesis validator, you will need to have been selected in the genesis ceremony. If you have not been selected, you can still join as a full node. + + +For the shielded expedition, only the top 114 pilots have been selected as genesis validators. If you were not selected, you can still bond to one of the genesis validators or become a post-genesis validator. + + If you have been selected. You must run the following command: ```bash @@ -32,6 +37,12 @@ Running the node of a pre-genesis validator is identical to that of a mainnet va For this reason, please refer to [these docs](../../operators/validators/validator-setup.mdx#start-validating) for running the node. +## Submitting bonding transactions as a non-genesis validator +If your public key has been allocated `NAM` (`NAAN` for the shielded expedition), you can bond to a genesis validator as a pre-genesis transaction. +Please follw the steps [here](../../operators/networks/genesis-flow/participants.mdx#bond-to-a-pre-genesis-validator-account) in order to submit these transactions. + +Remember to sign these transactions as well. + ## Joining as a full node If you are not a genesis validator, please follow the steps for [joining as a full node](../../operators/ledger/running-a-full-node.mdx). diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index 33cb70af..6bd28ec9 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -8,6 +8,14 @@ This page covers all installation steps required by various upgrades to testnets No upgrades are currently scheduled. +## Shielded expedition + +- Namada Shielded expedition 1: + - From date: `TBD` + - Namada protocol version: `TBD` + - Cometbft version: `0.37.2` + - CHAIN_ID: `TBD` + ## Latest Testnet - Namada public testnet 15: diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 0836d166..2fce5903 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -145,7 +145,7 @@ Once the pre-genesis network participants have generated respective pre-genesis EMAIL="" DISCORD_HANDLE="" # This is optional -SELF_BOND_AMOUNT=1000000 # Set this to the amount of NAM you want to self-bond +SELF_BOND_AMOUNT=1000000 # Set this to the amount of NAM you want to self-bond. This must be less than or equal to the amount of NAM allocated to the pre-genesis keys in the `balances.toml` that was published by the network coordinator. VALIDATOR_ALIAS="" IP_ADDRESS="" namadac utils init-genesis-validator \ @@ -188,6 +188,21 @@ Successful execution will output the new validator address: Validator account address: tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2dxk ``` +#### Bond to a pre-genesis validator account +If your public key has been allocated `NAM` (`NAAN` for the shielded expedition), you can bond to a genesis validator as a pre-genesis transaction. +Please follow the below steps: + +```bash copy +namadac utils genesis-bond \ + --validator "" \ # Validator address. + --amount "" \ # Amount of tokens to stake in a bond. + --source "" \ # Source address for delegations. For self-bonds, the validator is also the source. + --path "" \ # Output toml file to write transactions to. +``` + +After this step is completed, sign the transaction + + ### Signing transactions Once the `transactions.toml` file has been generated, the pre-genesis network participants must sign the transactions. This can be done through the namada cli: From 9cd0f09b572329744216d001b18391da6693cfaa Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 12 Jan 2024 18:19:26 +0000 Subject: [PATCH 17/75] shielded expedition docs --- packages/docs/pages/networks/testnets.mdx | 2 ++ .../pages/networks/testnets/genesis-validator-apply.mdx | 8 +++++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 082e1783..00467974 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -6,6 +6,8 @@ For more context read: ## Shielded expedition +The `balances.toml` file is located at `https://github.com/anoma/namada-shielded-expedition`. + - Namada Shielded expedition 1: - From date: `TBD` - Namada protocol version: `TBD` diff --git a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx index 8f57113f..e7b56e77 100644 --- a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx +++ b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx @@ -1,3 +1,4 @@ +import { Http2ServerRequest } from 'http2' import { Callout } from 'nextra-theme-docs' # Applying to be a genesis validator @@ -68,7 +69,12 @@ This file contains only public information and is safe to share publicly. ### Submitting the config -If you want to be a genesis validator for the testnet, please make a pull request to https://github.com/anoma/namada-testnets adding your signed `transactions.toml` file to the relevant directory (e.g. `namada-public-testnet-2` for the second public testnet), renaming it to `$alias.toml`. + + +For the shielded expedition, use the repository `https://github.com/anoma/namada-shielded-expedition` instead of `https://github.com/anoma/namda-testnets`. + + +If you want to be a genesis validator for the testnet, please make a pull request to `https://github.com/anoma/namada-testnets` (`https://github.com/anoma/namada-shielded-expedition` for the Shielded expedition) adding your **signed** `transactions.toml` file to the relevant directory (e.g. `namada-public-testnet-2` for the second public testnet), renaming it to `""".toml`. E.g. if you chose your alias to be "bertha", submit the file with the name `bertha.toml`. You can see what an example PR looks like [here](https://github.com/anoma/namada-testnets/pull/2616). ### Wait for the `CHAIN_ID` From 199912c40e3e277250555ff1ccaac6e0c6df8bb3 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 12 Jan 2024 18:29:58 +0000 Subject: [PATCH 18/75] fixed broken import --- .../docs/pages/networks/testnets/genesis-validator-apply.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx index e7b56e77..0d6b1ac5 100644 --- a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx +++ b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx @@ -1,4 +1,3 @@ -import { Http2ServerRequest } from 'http2' import { Callout } from 'nextra-theme-docs' # Applying to be a genesis validator From c8740015f46a0a3a174eebfa36409a06e704f45e Mon Sep 17 00:00:00 2001 From: Jason Davies Date: Fri, 12 Jan 2024 22:14:17 +0000 Subject: [PATCH 19/75] Fix genesis-bond script. The `--validator` parameter should specify an address, not an alias. Additionally, backslash escapes don't work well with comments on the same line, so copy/pasting this into a shell won't work without removing the comments (and the final backslash). --- .../operators/networks/genesis-flow/participants.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index 2fce5903..264eacdb 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -194,10 +194,10 @@ Please follow the below steps: ```bash copy namadac utils genesis-bond \ - --validator "" \ # Validator address. - --amount "" \ # Amount of tokens to stake in a bond. - --source "" \ # Source address for delegations. For self-bonds, the validator is also the source. - --path "" \ # Output toml file to write transactions to. + --validator "" \ + --amount "" \ + --source "" \ + --path "" ``` After this step is completed, sign the transaction From 28df659881425ab0e083d4100e3453ec475da88b Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Mon, 15 Jan 2024 11:02:05 +0000 Subject: [PATCH 20/75] avatar field added --- .../pages/operators/networks/genesis-flow/participants.mdx | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index b0e809cd..e659dc31 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -145,6 +145,9 @@ Once the pre-genesis network participants have generated respective pre-genesis EMAIL="" DISCORD_HANDLE="" # This is optional +AVATAR_URL="" # This is optional, and expects a URL to an image the size of 128x128 pixels +WEBSITE="" # This is optional +DESCRIPTION="" # This is optional SELF_BOND_AMOUNT=1000000 # Set this to the amount of NAM you want to self-bond. This must be less than or equal to the amount of NAM allocated to the pre-genesis keys in the `balances.toml` that was published by the network coordinator. VALIDATOR_ALIAS="" IP_ADDRESS="" @@ -157,6 +160,9 @@ namadac utils init-genesis-validator \ --self-bond-amount $SELF_BOND_AMOUNT \ --email $EMAIL \ --discord-handle $DISCORD_HANDLE \ + --avatar $AVATAR_URL \ + --website $WEBSITE \ + --description $DESCRIPTION \ --path $TX_FILE_PATH ``` From e6c91a112a651cf0ad0479478d1097095ba950f0 Mon Sep 17 00:00:00 2001 From: Erick Calder Date: Mon, 15 Jan 2024 14:52:32 -0800 Subject: [PATCH 21/75] reference to older binaries --- packages/docs/pages/introduction/install/binaries.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/packages/docs/pages/introduction/install/binaries.mdx b/packages/docs/pages/introduction/install/binaries.mdx index 4dfca13b..8634f82e 100644 --- a/packages/docs/pages/introduction/install/binaries.mdx +++ b/packages/docs/pages/introduction/install/binaries.mdx @@ -18,6 +18,8 @@ latest_release_url=$(curl -s "https://api.github.com/repos/anoma/namada/releases wget "$latest_release_url" ``` +Older versions of the binaries are available from Github -- see the [releases page](https://github.com/anoma/namada/releases) + Unzip the `tar` using the following command: ```shell copy #Assuming the user only has one namada tar file in the current directory From 3a8da706521941c22976f73482190f4e286d8349 Mon Sep 17 00:00:00 2001 From: Johnson Date: Tue, 16 Jan 2024 09:29:24 +0800 Subject: [PATCH 22/75] fix: typo --- packages/docs/pages/operators/ledger/running-a-full-node.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/operators/ledger/running-a-full-node.mdx b/packages/docs/pages/operators/ledger/running-a-full-node.mdx index abc0c142..c8bb2b94 100644 --- a/packages/docs/pages/operators/ledger/running-a-full-node.mdx +++ b/packages/docs/pages/operators/ledger/running-a-full-node.mdx @@ -1,7 +1,7 @@ import { Callout } from 'nextra-theme-docs' # Full Node Setup -Before starting a full node, the unique identifier of the `chain-id` wll be needed, which will be released as soon as the genesis file is ready. +Before starting a full node, the unique identifier of the `chain-id` will be needed, which will be released as soon as the genesis file is ready. ### Join the network Once the `chain-id` has been distributed, it is possible to join the network with the `CHAIN_ID`: From 72109833544b2133f8fba7c56f5968f1968c4027 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Wed, 17 Jan 2024 17:20:00 +0000 Subject: [PATCH 23/75] now v0.30.0 --- packages/docs/pages/networks/testnets/environment-setup.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index edeaa9c9..a549818b 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.29.0 +export NAMADA_TAG=v0.30.0 ``` @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.29.0` + - `namada --version` should output `Namada v0.30.0` From e2e03be114bd9c3aafeda239ddd7bf32fcaa7504 Mon Sep 17 00:00:00 2001 From: Luigi Date: Sun, 21 Jan 2024 15:07:14 -0800 Subject: [PATCH 24/75] Fix typos --- packages/docs/pages/operators/remote-signing.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/packages/docs/pages/operators/remote-signing.mdx b/packages/docs/pages/operators/remote-signing.mdx index b6acac1b..aefaa000 100644 --- a/packages/docs/pages/operators/remote-signing.mdx +++ b/packages/docs/pages/operators/remote-signing.mdx @@ -138,13 +138,13 @@ Expect to find new files and new folders inside `HorcruxNamada`: This file will hold the signing state for the cluster. -5. Paste the belew content into it: +5. Paste the below content into it: ```json { "height": "0", "round": "0", - " step": 3 + "step": 3 } ``` @@ -199,7 +199,7 @@ It should now look like this: { "height": "", "round": "0", - " step": 3 + "step": 3 } ``` @@ -221,10 +221,10 @@ If everything is working fine, your node should start signing blocks. ### WARNING : FOR ALL RUNNING NODES IN THE CLUSTER BE SURE YOU ARE USING `priv_validator_laddr = "0.0.0.0:19901"` AND REMOVE THE ORIGINAL `priv_validator_key.json` FROM ALL NODES PLEASE NOTE THAT USING REMOTE SIGNING COULD LEAD TO DOUBLE SIGNING AND SLASHING IF YOUR NODE SIGNED SAME BLOCK TWICE, -SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME . +SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME. -### TROUBLESHOUTING : +### TROUBLESHOOTING : * check FW ports * check dns for signers and node cnames * check files and folder paths for horcrux From 017cd795916cdc57c68fb1d7a8b145628c863d2c Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Sun, 28 Jan 2024 23:55:25 +0000 Subject: [PATCH 25/75] fixed stuff --- packages/docs/pages/introduction.mdx | 4 ++-- packages/docs/pages/introduction/install/source.mdx | 6 +++--- .../pages/networks/testnets/genesis-validator-apply.mdx | 2 +- .../operators/networks/genesis-flow/participants.mdx | 8 ++++++-- packages/docs/pages/operators/networks/local-network.mdx | 2 +- .../docs/pages/users/public-goods-stewards/_meta.json | 2 +- .../docs/pages/users/public-goods-stewards/proposing.mdx | 4 ++-- 7 files changed, 16 insertions(+), 12 deletions(-) diff --git a/packages/docs/pages/introduction.mdx b/packages/docs/pages/introduction.mdx index c27293a7..d068b747 100644 --- a/packages/docs/pages/introduction.mdx +++ b/packages/docs/pages/introduction.mdx @@ -15,7 +15,7 @@ Here are some useful tips for reading this book: - Comments start with `#`: -`# this is a comment make sure you read them!` +`# this is a comment. Make sure you read them!` - Sample outputs start with an arrow: @@ -23,7 +23,7 @@ Here are some useful tips for reading this book: - User-defined inputs are in angle brackets: -`$ this is a command you should run ` +`this is a command you should run ""` ## About this documentation diff --git a/packages/docs/pages/introduction/install/source.mdx b/packages/docs/pages/introduction/install/source.mdx index d44b40a6..4f3d587e 100644 --- a/packages/docs/pages/introduction/install/source.mdx +++ b/packages/docs/pages/introduction/install/source.mdx @@ -3,15 +3,15 @@ import { Callout } from 'nextra-theme-docs' # Install from source -Please note that, although installing from source is the recommended route for installing namada, it can prove to be difficult, and is not recommended for beginners. For a first time installation, the installation process can take up to an hour. Building binaries from source can also take a long time, depending on your machine. +Please note that, although installing from source is the recommended route for installing namada, it can prove to be difficult, and is not recommended for beginners. For a first time installation, the installation process can take up to an hour. Building binaries from source can also take a long time, depending on the machine. ## Pre-requisites -Make sure you have the correct [pre-requisites](./source/pre-requisites.mdx) downloaded and installed. +Ensure the correct [pre-requisites](./source/pre-requisites.mdx) have been downloaded and installed. ## Installing Namada -Now that you have all the required dependencies installed, you can clone the source code from the [Namada repository](https://github.com/anoma/namada) and build it with: +Once all the required dependencies have been installed, the next step is to clone the source code from the [Namada repository](https://github.com/anoma/namada) and build it with: ```shell copy git clone https://github.com/anoma/namada.git diff --git a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx index 0d6b1ac5..e9a704ed 100644 --- a/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx +++ b/packages/docs/pages/networks/testnets/genesis-validator-apply.mdx @@ -6,7 +6,7 @@ Before a testnet launches, you can apply to be a genesis validator. ### Set up -Follow [this guide](../../operators/validators/validator-setup.mdx#pre-genesis) on how to generate your "pre-genesis" validator files. +Follow [this guide](../../operators/validators/validator-setup.mdx#pre-genesis) on how to generate "pre-genesis" validator files. For the shielded expedition, the `balances.toml` file has been published at the [namada-shieled-expedition repository](https://github.com/anoma/namada-shielded-expedition). diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index e659dc31..ecdde19b 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -196,7 +196,11 @@ Validator account address: tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2dxk #### Bond to a pre-genesis validator account If your public key has been allocated `NAM` (`NAAN` for the shielded expedition), you can bond to a genesis validator as a pre-genesis transaction. -Please follow the below steps: + +This step is intended for pre-genesis participants who have been allocated `NAM` (`NAAN` for the shielded expedition) and want to bond to a genesis validator that is not their own. If you want to bond to your own genesis validator, please follow the steps in [Generate a pre-genesis validator account](#generate-a-pre-genesis-validator-account) and use the `--self-bond` arguments. + + +The bond can be achieved by running: ```bash copy namadac utils genesis-bond \ @@ -206,7 +210,7 @@ namadac utils genesis-bond \ --path "" ``` -After this step is completed, sign the transaction +After this step is completed, it is required to sign the transaction. ### Signing transactions diff --git a/packages/docs/pages/operators/networks/local-network.mdx b/packages/docs/pages/operators/networks/local-network.mdx index 181dfb62..0b11d2eb 100644 --- a/packages/docs/pages/operators/networks/local-network.mdx +++ b/packages/docs/pages/operators/networks/local-network.mdx @@ -77,6 +77,6 @@ The ledger can be run through the familiar command: After the local network has fulfilled its purpose, it can be cleaned up by running the following commands found in the cleanup function of the script: ```shell copy - kilalll namadan + killall namadan # delete the base_dir/chain_id directory ``` diff --git a/packages/docs/pages/users/public-goods-stewards/_meta.json b/packages/docs/pages/users/public-goods-stewards/_meta.json index 3752b941..31af00dc 100644 --- a/packages/docs/pages/users/public-goods-stewards/_meta.json +++ b/packages/docs/pages/users/public-goods-stewards/_meta.json @@ -1,5 +1,5 @@ { "electing": "Becoming a Steward", "voting": "Voting for Stewards and PGF proposals", - "proposing": "PGF proposals (Stewards only)" + "proposing": "PGF proposals" } diff --git a/packages/docs/pages/users/public-goods-stewards/proposing.mdx b/packages/docs/pages/users/public-goods-stewards/proposing.mdx index 0f5120be..6ad8dee2 100644 --- a/packages/docs/pages/users/public-goods-stewards/proposing.mdx +++ b/packages/docs/pages/users/public-goods-stewards/proposing.mdx @@ -4,7 +4,7 @@ import { Callout } from 'nextra-theme-docs' ## Formatting the `proposal.json` -Below is an example of a `PGFProposal` that a steward could submit. Note that only stewards will be able to submit these proposals. +Below is an example of a `PGFProposal` that a governance participant could submit. ```json { "proposal" :{ @@ -51,7 +51,7 @@ Save this file as `PGF_proposal.json` to some memorable path on your machine. ## Submitting the proposal -In order to submit the proposal, the steward can use the following command: +In order to submit the proposal, the governance participant can use the following command: ```shell copy namada client init-proposal \ From c4182f3b67fc1675f3901b57181ba97527e2f55d Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Mon, 29 Jan 2024 00:59:25 +0000 Subject: [PATCH 26/75] governance had some issues --- .../docs/pages/users/governance/on-chain-governance.mdx | 7 ++++--- .../docs/pages/users/public-goods-stewards/electing.mdx | 1 + .../docs/pages/users/public-goods-stewards/proposing.mdx | 1 + 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index d4e82725..016a935a 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -19,6 +19,7 @@ Now, we need to create a json file `proposal.json` holding the content of our pr ```json { "proposal": { + "id": 1, "content": { "title": "One Small Step for Namada, One Giant Leap for Memekind", "authors": "bengt@heliax.dev", @@ -34,9 +35,9 @@ Now, we need to create a json file `proposal.json` holding the content of our pr "voting_start_epoch": 21, "voting_end_epoch": 24, "grace_epoch": 27, - "type": { - "Default": null - } + "data": { + // Depends on proposal type + } } } ``` diff --git a/packages/docs/pages/users/public-goods-stewards/electing.mdx b/packages/docs/pages/users/public-goods-stewards/electing.mdx index 09cb026f..d98a8301 100644 --- a/packages/docs/pages/users/public-goods-stewards/electing.mdx +++ b/packages/docs/pages/users/public-goods-stewards/electing.mdx @@ -20,6 +20,7 @@ The `steward_proposal.json` file contains the information about the proposal. It ```json { "proposal" :{ + "id": 1, "content": { "title": "Stewie for Steward 2024", "authors": "stewie@heliax.dev", diff --git a/packages/docs/pages/users/public-goods-stewards/proposing.mdx b/packages/docs/pages/users/public-goods-stewards/proposing.mdx index 6ad8dee2..2c32b123 100644 --- a/packages/docs/pages/users/public-goods-stewards/proposing.mdx +++ b/packages/docs/pages/users/public-goods-stewards/proposing.mdx @@ -8,6 +8,7 @@ Below is an example of a `PGFProposal` that a governance participant could submi ```json { "proposal" :{ + "id": 1, "content": { "title": "Stewie for Steward 2024", "authors": "stewie@heliax.dev", From 135b275fd81041a144294cd81654eab5dce195b0 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Tue, 30 Jan 2024 14:13:16 +0000 Subject: [PATCH 27/75] se docs --- packages/docs/pages/networks/testnets.mdx | 12 +++--------- .../pages/networks/testnets/environment-setup.mdx | 4 ++-- .../docs/pages/networks/testnets/testnet-history.mdx | 10 +++++----- .../docs/pages/operators/networks/local-network.mdx | 4 +++- .../pages/users/governance/on-chain-governance.mdx | 6 +++--- 5 files changed, 16 insertions(+), 20 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 00467974..da8934b9 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -9,17 +9,11 @@ For more context read: The `balances.toml` file is located at `https://github.com/anoma/namada-shielded-expedition`. - Namada Shielded expedition 1: - - From date: `TBD` - - Namada protocol version: `TBD` + - From date: 31st of January 2024 17:00 UTC + - Namada protocol version: `v0.30.3` - Cometbft version: `0.37.2` - - CHAIN_ID: `TBD` + - CHAIN_ID: `shielded-expedition.3d767ac5d5` -## Latest Testnet -- Namada public testnet 15: - - From date: 18th of December 2023 17:00 UTC - - Namada protocol version: `v0.28.1` - - Cometbft version: `0.37.2` - - CHAIN_ID: `public-testnet-15.0dacadb8d663` The history of all testnets can be found [here](./testnets/testnet-history.mdx). diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index a549818b..c954c0bb 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.30.0 +export NAMADA_TAG=v0.30.3 ``` @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.30.0` + - `namada --version` should output `Namada v0.30.3` diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index 6bd28ec9..b41e5388 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -11,14 +11,14 @@ No upgrades are currently scheduled. ## Shielded expedition - Namada Shielded expedition 1: - - From date: `TBD` - - Namada protocol version: `TBD` + - From date: 31st of January 2024 17:00 UTC + - Namada protocol version: `v0.30.3` - Cometbft version: `0.37.2` - - CHAIN_ID: `TBD` - + - CHAIN_ID: `shielded-expedition.3d767ac5d5` + ## Latest Testnet -- Namada public testnet 15: +- Namada public testnet 15 (offline): - From date: 18th of December 2023 17:00 UTC - Namada protocol version: `v0.28.1` - Cometbft version: `0.37.2` diff --git a/packages/docs/pages/operators/networks/local-network.mdx b/packages/docs/pages/operators/networks/local-network.mdx index 0b11d2eb..d300d80d 100644 --- a/packages/docs/pages/operators/networks/local-network.mdx +++ b/packages/docs/pages/operators/networks/local-network.mdx @@ -57,6 +57,8 @@ python3 ./scripts/gen_localnet.py \ --mode release # Assuming the binaries were built using `make build-release` \ --parameters '{"parameters": {"max_expected_time_per_block": 10}, "pos_params": {"pipeline_len": 5}}' # In order to change max_expected_time_per_block to 10 seconds from the default 30, and the pipeline length to 5 epochs from the default 2. +--num-nodes 2 # OPTIONAL: To run the localnet with 2 nodes +--num-vals 2 # OPTIONAL: To run the localnet with 2 validators ``` ### Modifying the genesis configuration file @@ -65,7 +67,7 @@ The genesis configuration can be modified in two ways. One is to change the cont ## Running the ledger -After the script has been run, a python process will have started in the background. +After the script has been run, all of the necessary folders will have been set up to run the chain. The ledger can be run through the familiar command: ```shell diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 016a935a..2fc2578e 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -47,9 +47,9 @@ In the content field, most of the fields are self-explanatory. The `requires` fi You should change the value of: - `Author` field with the address of `my-new-acc`; -- `voting_start_epoch` with a future epoch (must be a multiple of 3) for which you want the voting to begin; -- `voting_end_epoch` with an epoch greater than `voting_start_epoch`, a multiple of 3, and by which no further votes will be accepted; -- `grace_epoch` with an epoch greater than `voting_end_epoch` + 6, in which the proposal, if passed, will come into effect. +- `voting_start_epoch` with a future epoch (must be a multiple of the `min-voting-period` found in the `parameters.toml`) for which you want the voting to begin; +- `voting_end_epoch` with an epoch greater than `voting_start_epoch`, a multiple of `min-voting-period`, and by which no further votes will be accepted; +- `grace_epoch` with an epoch greater than `voting_end_epoch` + `, in which the proposal, if passed, will come into effect. The `data` field and its structure is dependent on the type of proposal being submitted. Below we outline the structure of the "data" field for each type of proposal. The one given in the example above is for a `Default Proposal`. From 3d05b493e64840bbd2ddb2b7db43ffd214d0328a Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Wed, 31 Jan 2024 16:20:17 +0000 Subject: [PATCH 28/75] docs updated for the newest se --- packages/docs/pages/networks/testnets.mdx | 6 +++--- .../docs/pages/networks/testnets/environment-setup.mdx | 4 ++-- packages/docs/pages/networks/testnets/testnet-history.mdx | 4 ++-- packages/docs/pages/users/transparent-accounts.mdx | 7 +++++-- 4 files changed, 12 insertions(+), 9 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index da8934b9..52b70126 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -9,10 +9,10 @@ For more context read: The `balances.toml` file is located at `https://github.com/anoma/namada-shielded-expedition`. - Namada Shielded expedition 1: - - From date: 31st of January 2024 17:00 UTC - - Namada protocol version: `v0.30.3` + - From date: 1st of February 2024 17:00 UTC + - Namada protocol version: `v0.31.0` - Cometbft version: `0.37.2` - - CHAIN_ID: `shielded-expedition.3d767ac5d5` + - CHAIN_ID: `shielded-expedition.b40d8e9055` The history of all testnets can be found [here](./testnets/testnet-history.mdx). diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index c954c0bb..fbfae19a 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.30.3 +export NAMADA_TAG=v0.31.0 ``` @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.30.3` + - `namada --version` should output `Namada v0.31.0` diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index b41e5388..cad21579 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -11,8 +11,8 @@ No upgrades are currently scheduled. ## Shielded expedition - Namada Shielded expedition 1: - - From date: 31st of January 2024 17:00 UTC - - Namada protocol version: `v0.30.3` + - From date: 1st of February 2024 17:00 UTC + - Namada protocol version: `v0.31.0` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.3d767ac5d5` diff --git a/packages/docs/pages/users/transparent-accounts.mdx b/packages/docs/pages/users/transparent-accounts.mdx index f4eec0a3..df723192 100644 --- a/packages/docs/pages/users/transparent-accounts.mdx +++ b/packages/docs/pages/users/transparent-accounts.mdx @@ -16,7 +16,7 @@ Namada uses [ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519) keypairs for To manage your keys, various sub-commands are available under: ```shell copy -namada wallet key +namada wallet --help ``` ### Generate a keypair @@ -61,9 +61,12 @@ Loss of any of them would inevitably lead to impossible account recovery. To recover the keypair from your mnemonic code and passphrase use ```shell copy -namada wallet key restore --alias keysha --hd-path default +namada wallet key derive --alias keysha --hd-path default ``` +This will ask you to then enter a passphrase (unless you add the `--unsafe-dont-encrypt` flag), +and then will ask you to enter your mnemonic code. + ### List all known keys ```shell copy From bce42619e0eadc783f5973a2b334b5d1ca4679d2 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Wed, 31 Jan 2024 17:06:27 +0000 Subject: [PATCH 29/75] memo field reminder --- packages/docs/pages/networks/testnets.mdx | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 52b70126..1634c78a 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -1,3 +1,5 @@ +import { Callout } from 'nextra-theme-docs' + # Namada Testnets For more context read: @@ -6,6 +8,11 @@ For more context read: ## Shielded expedition + +For the shielded expedition, it is important to remember to add the `--memo` flag to every transaction. The memo should be filled with the `tpknam` submitted at the shielded-expedition registration period. +For example `namadac transfer --source me --target you --amount 10 --token naan --signing-keys my-key --memo tpknamq1337mypubkey1964qqqqqq` + + The `balances.toml` file is located at `https://github.com/anoma/namada-shielded-expedition`. - Namada Shielded expedition 1: From a60cd394dd874e2e5f58dbabbadb29d0768429b2 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Wed, 31 Jan 2024 17:44:54 +0000 Subject: [PATCH 30/75] env variable added --- packages/docs/pages/introduction/quick-start.mdx | 1 - packages/docs/pages/networks/testnets/joining-the-testnet.mdx | 4 ++-- packages/docs/pages/operators/ledger/running-a-full-node.mdx | 2 +- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/packages/docs/pages/introduction/quick-start.mdx b/packages/docs/pages/introduction/quick-start.mdx index 8108c2f7..b0aa3d08 100644 --- a/packages/docs/pages/introduction/quick-start.mdx +++ b/packages/docs/pages/introduction/quick-start.mdx @@ -28,7 +28,6 @@ We recommend this step with [tmux](https://www.hamvocke.com/blog/a-quick-and-eas tmux # inside the tmux/or not - namadan ledger run # can detach the tmux (Ctrl-B then D) diff --git a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx index 51a8ce4e..8a1af7a6 100644 --- a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx +++ b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx @@ -17,7 +17,7 @@ If you have been selected. You must run the following command: ```bash CHAIN_ID="" VALIDATOR_ALIAS="" -namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS +NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download" namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS ``` @@ -29,7 +29,7 @@ E.g if your base directory is `.namada` and your validator alias is `my-validato CHAIN_ID="" VALIDATOR_ALIAS="my-validator" BASE_DIR=".namada" -namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS +NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download" namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS ``` diff --git a/packages/docs/pages/operators/ledger/running-a-full-node.mdx b/packages/docs/pages/operators/ledger/running-a-full-node.mdx index c8bb2b94..2af8b926 100644 --- a/packages/docs/pages/operators/ledger/running-a-full-node.mdx +++ b/packages/docs/pages/operators/ledger/running-a-full-node.mdx @@ -7,7 +7,7 @@ Before starting a full node, the unique identifier of the `chain-id` will be nee Once the `chain-id` has been distributed, it is possible to join the network with the `CHAIN_ID`: ```bash copy export CHAIN_ID="namada-mainnet" ## (replace with the actual chain-id) - namada client utils join-network --chain-id $CHAIN_ID + NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download" namada client utils join-network --chain-id $CHAIN_ID ``` ### Start your node and sync From 61d02cdda45e889102144c9df455837e786a1bf1 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Wed, 31 Jan 2024 17:56:26 +0000 Subject: [PATCH 31/75] env variable fixed --- packages/docs/pages/networks/testnets/joining-the-testnet.mdx | 4 ++-- packages/docs/pages/operators/ledger/running-a-full-node.mdx | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx index 8a1af7a6..d25e545d 100644 --- a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx +++ b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx @@ -17,7 +17,7 @@ If you have been selected. You must run the following command: ```bash CHAIN_ID="" VALIDATOR_ALIAS="" -NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download" namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS +NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.b40d8e9055" namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS ``` @@ -29,7 +29,7 @@ E.g if your base directory is `.namada` and your validator alias is `my-validato CHAIN_ID="" VALIDATOR_ALIAS="my-validator" BASE_DIR=".namada" -NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download" namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS +NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.b40d8e9055" namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS ``` diff --git a/packages/docs/pages/operators/ledger/running-a-full-node.mdx b/packages/docs/pages/operators/ledger/running-a-full-node.mdx index 2af8b926..3e4184bf 100644 --- a/packages/docs/pages/operators/ledger/running-a-full-node.mdx +++ b/packages/docs/pages/operators/ledger/running-a-full-node.mdx @@ -7,7 +7,7 @@ Before starting a full node, the unique identifier of the `chain-id` will be nee Once the `chain-id` has been distributed, it is possible to join the network with the `CHAIN_ID`: ```bash copy export CHAIN_ID="namada-mainnet" ## (replace with the actual chain-id) - NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download" namada client utils join-network --chain-id $CHAIN_ID + NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.b40d8e9055" namada client utils join-network --chain-id $CHAIN_ID ``` ### Start your node and sync From d79f93fb35db73860616f8190b4189403300da7c Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Thu, 1 Feb 2024 14:24:03 +0000 Subject: [PATCH 32/75] governance docs updated --- .../users/governance/on-chain-governance.mdx | 29 ++++++++++++++----- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 2fc2578e..f8b5f073 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -31,14 +31,16 @@ Now, we need to create a json file `proposal.json` holding the content of our pr "details": "Bringing Namada to the moon in no time is easily achievable. We just need to pass this governance proposal and set the plan in action", "requires": "" }, - "author": "atest1v4ehgw36g9zyydzpgycy23phxuunxdesgc6nydfsxge5x3zzgscny32pxccn2wfjg5urx3fhzxhmch", + "author": "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q", "voting_start_epoch": 21, "voting_end_epoch": 24, "grace_epoch": 27, - "data": { - // Depends on proposal type + }, + "data": + { + "add": "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q", + "remove": ["tnam1q9jpj9u5p6ugjylarkwmj9tsxr0pjlgpn5wa8ff0"] } - } } ``` @@ -82,7 +84,7 @@ The encoding will be submitted as a string "data" : [ { "action" : "add", - "address" : "atestatest1v4ehgw36g4pyg3j9x3qnjd3cxgmyz3fk8qcrys3hxdp5xwfnx3zyxsj9xgunxsfjg5u5xvzyzrrqtn" + "address" : "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q" } ] ``` @@ -103,7 +105,7 @@ stewards in a single proposal. { "target": { "amount": 420, - "address": "atestatest1v4ehgw36g4pyg3j9x3qnjd3cxgmyz3fk8qcrys3hxdp5xwfnx3zyxsj9xgunxsfjg5u5xvzyzrrqtn" + "address": "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q" }, "action" : "add", }, @@ -112,7 +114,7 @@ stewards in a single proposal. { "target": { "amount": 1337, - "address": "atestatest1v4ehgw36g4pyg3j9x3qnjd3cxgmyz3fk8qcrys3hxdp5xwfnx3zyxsj9xgunxsfjg5u5xvzyzrrqtn" + "address": "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q" } } ] @@ -133,11 +135,22 @@ the amount specified will be sent immediately. ## Submitting the proposal As soon as your `proposal.json` file is ready, you can submit the proposal with (make sure to be in the same directory as the `proposal.json` file): +**For a default proposal:** + ```shell copy namada client init-proposal --data-path proposal.json ``` -The transaction should have been accepted. You can query all the proposals with: +**For non-default proposals:** + +One of the flags `--pgf-stewards`, `--pgf-funding`, `--eth` must be specified. For example, for a PGF steward proposal: + +```shell copy +namada client init-proposal --pgf-stewards --data-path proposal.json +``` + +## Query the proposal +If the submitted transaction was accepted, the user can query all the proposals with: ```shell copy namada client query-proposal From bc35096844b91157f752971f51ea63954269535b Mon Sep 17 00:00:00 2001 From: Giancarlos Salas Date: Thu, 1 Feb 2024 11:17:58 -0500 Subject: [PATCH 33/75] Fix wallet derive command --- packages/docs/pages/users/transparent-accounts.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/users/transparent-accounts.mdx b/packages/docs/pages/users/transparent-accounts.mdx index df723192..69d62f5a 100644 --- a/packages/docs/pages/users/transparent-accounts.mdx +++ b/packages/docs/pages/users/transparent-accounts.mdx @@ -61,7 +61,7 @@ Loss of any of them would inevitably lead to impossible account recovery. To recover the keypair from your mnemonic code and passphrase use ```shell copy -namada wallet key derive --alias keysha --hd-path default +namada wallet derive --alias keysha --hd-path default ``` This will ask you to then enter a passphrase (unless you add the `--unsafe-dont-encrypt` flag), @@ -103,4 +103,4 @@ namada wallet derive --alias keysha --hd-path default ```shell copy namada wallet list --addr -``` \ No newline at end of file +``` From fec68ae8cf4c6f84f5d2ad116682821c1abf5376 Mon Sep 17 00:00:00 2001 From: amadison79 Date: Fri, 2 Feb 2024 15:15:42 +0100 Subject: [PATCH 34/75] Update shielded-transfers.mdx --- .../docs/pages/users/shielded-accounts/shielded-transfers.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx b/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx index fd6f6924..0f5040b8 100644 --- a/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx +++ b/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx @@ -27,7 +27,7 @@ transparent account with some token balance. One can randomly generate a new spending key with: ```shell copy -namadaw masp gen-key --alias +namadaw gen --shielded --alias ``` @@ -40,7 +40,7 @@ the same alias. To create a payment address from one's spending key, one can run: ```shell copy -namadaw masp gen-addr \ +namadaw gen-payment-addr \ --key \ --alias ``` From 65ef71b74483b8162c1f26529608b57777934393 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 2 Feb 2024 14:48:10 +0000 Subject: [PATCH 35/75] new gov fixes added --- packages/docs/pages/operators/ibc.mdx | 2 +- .../operators/validators/proof-of-stake.mdx | 2 +- .../users/governance/on-chain-governance.mdx | 63 ++++++++++++------- 3 files changed, 43 insertions(+), 24 deletions(-) diff --git a/packages/docs/pages/operators/ibc.mdx b/packages/docs/pages/operators/ibc.mdx index 06eaf58f..7a6464ce 100644 --- a/packages/docs/pages/operators/ibc.mdx +++ b/packages/docs/pages/operators/ibc.mdx @@ -166,7 +166,7 @@ cp ./target/release/hermes /usr/local/bin/ ### Create the relayer account On each chain, there must be a `relayer` account. The alias should be the same as `chains.key_name` in the config. On a namada chain, this can be done by running ```bash copy -namadaw gen key --alias relayer +namadaw gen --alias relayer ``` This will generate a key for the relayer account. The key will be stored in the `wallet.toml` that is found in the [base directory](./ledger/base-directory.mdx) of the node, inside the `chain-id` folder. For example, if the `chain-id` is `namada-test.0a4c6786dbda39f786`, the `wallet.toml` will be found in `$HOME/.local/share/namada/namada-test.0a4c6786dbda39f786/wallet.toml` (on a ubuntu machine where `base-dir` has not been set up properly). diff --git a/packages/docs/pages/operators/validators/proof-of-stake.mdx b/packages/docs/pages/operators/validators/proof-of-stake.mdx index 99fd8c78..20138add 100644 --- a/packages/docs/pages/operators/validators/proof-of-stake.mdx +++ b/packages/docs/pages/operators/validators/proof-of-stake.mdx @@ -7,7 +7,7 @@ The Namada Proof of Stake (PoS) system uses the NAM token as the staking token. The PoS system is implemented as an account with the [PoS Validity Predicate](https://github.com/anoma/namada/blob/main/shared/src/ledger/pos/vp.rs) that governs the rules of the system. You can find its address in your wallet: ```shell copy -namada wallet address find --alias PoS +namada wallet find --alias PoS ``` ## Epochs diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index f8b5f073..12134b37 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -11,7 +11,7 @@ All the different types of proposals are listed in [the specs](https://specs.nam Assuming you have an account with at least 500 NAM token (in this example we are going to use `my-new-acc`), lets get the corresponding address ```shell copy -namada wallet address find --alias `my-new-acc` +namada wallet find --alias `my-new-acc` ``` Now, we need to create a json file `proposal.json` holding the content of our proposal. Copy the below text into a json file. @@ -83,8 +83,7 @@ The encoding will be submitted as a string ```json "data" : [ { - "action" : "add", - "address" : "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q" + "add": "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q" } ] ``` @@ -100,25 +99,29 @@ stewards in a single proposal. ```json "data" : - { - "continuous" : [ - { - "target": { - "amount": 420, - "address": "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q" - }, - "action" : "add", - }, - ], - "retro" : [ - { - "target": { - "amount": 1337, - "address": "tnam1qql6qme020vw7pfw4ruavrwxujf9lf8z75v90c8q" + { + "continuous" : [ + { + "Internal": + { + + "amount": "1337", + "target": "tnam1q9rxk49a7y6fp8h5qwz47d6jhml0km2w2y7emqyz" + + } + } + ], + "retro" : [ + { + "Internal": + { + + "amount": "1337", + "target": "tnam1q9rxk49a7y6fp8h5qwz47d6jhml0km2w2y7emqyz" } - } - ] - }, + } + ] + }, ``` @@ -128,10 +131,26 @@ Within each payment, the target field contains the address of the recipient as w as the amount of NAM that they will receive. For continuous PGF funding, the amount specified will be sent at the end of each epoch. There is also the option to remove a recipient from the continuous PGF funding, by specifying an already existing continuous -funding payment, and then also including the "remove" action. For retroactive PGF funding, +funding payment, and then setting the amount to "0". For retroactive PGF funding, the amount specified will be sent immediately. +#### IBC PGF proposals + +For a pgf proposal that is to be executed on an IBC chain, the "Internal" data structure will be substituted with "IBC": + +```json +"IBC": + { + + "amount": "1337", + "target": "tnam1q9rxk49a7y6fp8h5qwz47d6jhml0km2w2y7emqyz", + "port_id": "", + "channel_id": "" + } +``` + + ## Submitting the proposal As soon as your `proposal.json` file is ready, you can submit the proposal with (make sure to be in the same directory as the `proposal.json` file): From 31e3c0c5fd7f9460d8bb7cef6d98e00e1d9f8e73 Mon Sep 17 00:00:00 2001 From: Mohammed Patla Date: Fri, 2 Feb 2024 11:29:37 -0500 Subject: [PATCH 36/75] Update pre-requisites.mdx Need libudev-dev installed or the make install command fails on ubuntu --- .../docs/pages/introduction/install/source/pre-requisites.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/introduction/install/source/pre-requisites.mdx b/packages/docs/pages/introduction/install/source/pre-requisites.mdx index 67a09a4a..4681f6fa 100644 --- a/packages/docs/pages/introduction/install/source/pre-requisites.mdx +++ b/packages/docs/pages/introduction/install/source/pre-requisites.mdx @@ -24,7 +24,7 @@ Then, install the remaining dependencies. **Ubuntu:** running the following command should install everything needed: ```shell copy -sudo apt-get install -y make git-core libssl-dev pkg-config libclang-12-dev build-essential protobuf-compiler +sudo apt-get install -y make git-core libssl-dev pkg-config libclang-12-dev build-essential protobuf-compiler libudev-dev ``` **Mac:** installing the Xcode command line tools should provide you with almost everything you need: From 84bda5a7a4b8acf74b9630a991bcce262adf9ea3 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Sun, 4 Feb 2024 13:26:36 +0000 Subject: [PATCH 37/75] small pr --- .../install/binaries/prerequisites.mdx | 2 +- .../users/governance/on-chain-governance.mdx | 54 +++++++++++++++---- 2 files changed, 45 insertions(+), 11 deletions(-) diff --git a/packages/docs/pages/introduction/install/binaries/prerequisites.mdx b/packages/docs/pages/introduction/install/binaries/prerequisites.mdx index 60a68bc9..1dab3677 100644 --- a/packages/docs/pages/introduction/install/binaries/prerequisites.mdx +++ b/packages/docs/pages/introduction/install/binaries/prerequisites.mdx @@ -9,4 +9,4 @@ Finally, you should have GLIBC `v2.33` or higher. **Ubuntu 22.04**: glibc is installed by default and you don't have to do anything more. -**Ubuntu 18.04 and Ubuntu 22.04**: glibc has `v2.27` and `v2.29` respectively, by default which is lower than the required version to run Namada. We recommend to directly [install from source](../source.mdx) or upgrade to Ubuntu 22.04, instead of updating glibc to the required version, since the latter way can be a messy and tedious task. In case updating glibc would interest you, this [website](http://www.linuxfromscratch.org/lfs/view/9.0-systemd/chapter05/glibc.html) gives you the steps to build the package from source. +**Ubuntu 18.04 and Ubuntu 20.04**: glibc has `v2.27` and `v2.29` respectively, by default which is lower than the required version to run Namada. We recommend to directly [install from source](../source.mdx) or upgrade to Ubuntu 22.04, instead of updating glibc to the required version, since the latter way can be a messy and tedious task. In case updating glibc would interest you, this [website](http://www.linuxfromscratch.org/lfs/view/9.0-systemd/chapter05/glibc.html) gives you the steps to build the package from source. diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 12134b37..c4ebd726 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -16,6 +16,31 @@ namada wallet find --alias `my-new-acc` Now, we need to create a json file `proposal.json` holding the content of our proposal. Copy the below text into a json file. +```json +{ + "proposal": { + "id": "Arbitrary", + "content": { + "title": "Text", + "authors": "Text", + "discussions-to": "URL", + "created": "YYYY--DDTHH:MM:SSZ", + "license": "", + "abstract": "Text", + "motivation": "Text", + "details": "Text", + "requires": "Number" + }, + "author": "author-address", + "voting_start_epoch": 420, + "voting_end_epoch": 426, + "grace_epoch": 432, + }, + "data": "TODO-ADD-DATA-IF-NEEDED" +} +``` + +A correct Steward proposal example is shown below: ```json { "proposal": { @@ -58,24 +83,22 @@ The `data` field and its structure is dependent on the type of proposal being su ### Default Proposal ```json -"data" : "" +"data" : [1,2,3,4,5,6,7,8,9,10] # This is a u8 vector ``` The data field for default proposals is optional. This is in line with the nature of default proposals. If the proposals have code attached to them in order to change governance parameters, then this code -will be represented as a wasm file and the path to this file will be given in the data field. +will be represented as a wasm file and byte encoded vector will be tehe value of the data field. -### ETH Bridge Proposal - -```json -"data" : "" + +In order to read the path to bytes, one can use a simple python script. +```python +with open(file_path, "rb") as f: + byte_vec = f.read() +print(byte_vec) ``` - - -**Note**: -The encoding will be submitted as a string ### Steward Proposal @@ -150,6 +173,17 @@ For a pgf proposal that is to be executed on an IBC chain, the "Internal" data s } ``` +### ETH Bridge Proposal + +```json +"data" : "" +``` + + +**Note**: +The encoding will be submitted as a string + + ## Submitting the proposal As soon as your `proposal.json` file is ready, you can submit the proposal with (make sure to be in the same directory as the `proposal.json` file): From 272f5f1f5e364d68938746c577ff3b86cfab422d Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Sun, 4 Feb 2024 14:28:28 +0000 Subject: [PATCH 38/75] masp-fixes --- .../shielded-accounts/shielded-transfers.mdx | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx b/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx index 0f5040b8..56096ed7 100644 --- a/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx +++ b/packages/docs/pages/users/shielded-accounts/shielded-transfers.mdx @@ -113,8 +113,8 @@ Payment addresses can be derived from both spending keys as well as viewing keys generated: ``` -namadaw masp gen-addr --alias my-pa1 --key my-sk -namadaw masp gen-addr --alias my-pa2 --key my-vk +namadaw gen-payment-addr --alias my-pa1 --key my-sk +namadaw gen-payment-addr --alias my-pa2 --key my-vk ``` #### Manual Key/Address Addition @@ -122,9 +122,9 @@ namadaw masp gen-addr --alias my-pa2 --key my-vk It is also possible to manually add spending keys, viewining keys, and payment addresses in their raw form. This is demonstrated by the commands below. ``` -namadaw masp add --alias my-sk --value xsktest1qqqqqqqqqqqqqq9v0sls5r5de7njx8ehu49pqgmqr9ygelg87l5x8y4s9r0pjlvu69au6gn3su5ewneas486hdccyayx32hxvt64p3d0hfuprpgcgv2q9gdx3jvxrn02f0nnp3jtdd6f5vwscfuyum083cvfv4jun75ak5sdgrm2pthzj3sflxc0jx0edrakx3vdcngrfjmru8ywkguru8mxss2uuqxdlglaz6undx5h8w7g70t2es850g48xzdkqay5qs0yw06rtxcvedhsv -namadaw masp add --alias my-vk --value xfvktest1qqqqqqqqqqqqqqpagte43rsza46v55dlz8cffahv0fnr6eqacvnrkyuf9lmndgal7erg38awgq60r259csg3lxeeyy5355f5nj3ywpeqgd2guqd73uxz46645d0ayt9em88wflka0vsrq29u47x55psw93ly80lvftzdr5ccrzuuedtf6fala4r4nnazm9y9hq5yu6pq24arjskmpv4mdgfn3spffxxv8ugvym36kmnj45jcvvmm227vqjm5fq8882yhjsq97p7xrwqt7n63v -namadaw masp add --alias my-pa --value patest10qy6fuwef9leccl6dfm7wwlyd336x4y32hz62cnrvlrl6r5yk0jnw80kus33x34a5peg2xc4csn +namadaw add --alias my-sk --value xsktest1qqqqqqqqqqqqqq9v0sls5r5de7njx8ehu49pqgmqr9ygelg87l5x8y4s9r0pjlvu69au6gn3su5ewneas486hdccyayx32hxvt64p3d0hfuprpgcgv2q9gdx3jvxrn02f0nnp3jtdd6f5vwscfuyum083cvfv4jun75ak5sdgrm2pthzj3sflxc0jx0edrakx3vdcngrfjmru8ywkguru8mxss2uuqxdlglaz6undx5h8w7g70t2es850g48xzdkqay5qs0yw06rtxcvedhsv +namadaw add --alias my-vk --value xfvktest1qqqqqqqqqqqqqqpagte43rsza46v55dlz8cffahv0fnr6eqacvnrkyuf9lmndgal7erg38awgq60r259csg3lxeeyy5355f5nj3ywpeqgd2guqd73uxz46645d0ayt9em88wflka0vsrq29u47x55psw93ly80lvftzdr5ccrzuuedtf6fala4r4nnazm9y9hq5yu6pq24arjskmpv4mdgfn3spffxxv8ugvym36kmnj45jcvvmm227vqjm5fq8882yhjsq97p7xrwqt7n63v +namadaw add --alias my-pa --value patest10qy6fuwef9leccl6dfm7wwlyd336x4y32hz62cnrvlrl6r5yk0jnw80kus33x34a5peg2xc4csn ``` ### Making Shielded Transactions @@ -175,10 +175,10 @@ and payment addresses that it stores. Below are examples of how the wallet's storage can be queried: ``` -namadaw masp list-keys -namadaw masp list-keys --unsafe-show-secret -namadaw masp list-keys --unsafe-show-secret --decrypt -namadaw masp list-addrs +namadaw list --keys +namadaw list --keys --unsafe-show-secret +namadaw list --keys --unsafe-show-secret --decrypt +namadaw list --addr ``` ### Finding Shielded Keys/Addresses @@ -188,6 +188,6 @@ payment address when given its alias. Below are examples of how the wallet's storage can be queried: ``` -namadaw masp find --alias my-alias -namadaw masp find --alias my-alias --unsafe-show-secret +namadaw find --alias my-alias +namadaw find --alias my-alias --unsafe-show-secret ``` From bb6ad9ad6169390e9e82980c847197c6209f45c4 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Mon, 5 Feb 2024 19:12:48 +0000 Subject: [PATCH 39/75] new se --- packages/docs/pages/networks/testnets.mdx | 8 ++++---- .../docs/pages/networks/testnets/environment-setup.mdx | 2 +- .../docs/pages/networks/testnets/testnet-history.mdx | 10 ++++++++-- 3 files changed, 13 insertions(+), 7 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 1634c78a..5c024177 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -15,11 +15,11 @@ For example `namadac transfer --source me --target you --amount 10 --token naan The `balances.toml` file is located at `https://github.com/anoma/namada-shielded-expedition`. -- Namada Shielded expedition 1: - - From date: 1st of February 2024 17:00 UTC - - Namada protocol version: `v0.31.0` +- Namada Shielded expedition 2: + - From date: 6th of February 2024 18:00 UTC + - Namada protocol version: `v0.31.1` - Cometbft version: `0.37.2` - - CHAIN_ID: `shielded-expedition.b40d8e9055` + - CHAIN_ID: `shielded-expedition.88f17d1d14` The history of all testnets can be found [here](./testnets/testnet-history.mdx). diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index fbfae19a..44e9c584 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.31.0` + - `namada --version` should output `Namada v0.31.1` diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index cad21579..1b3c15b8 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -10,8 +10,14 @@ No upgrades are currently scheduled. ## Shielded expedition -- Namada Shielded expedition 1: - - From date: 1st of February 2024 17:00 UTC +- Namada Shielded expedition 2: + - From date: 6th of February 2024 18:00 UTC + - Namada protocol version: `v0.31.1` + - Cometbft version: `0.37.2` + - CHAIN_ID: `shielded-expedition.88f17d1d14` + +- Namada Shielded expedition 1 (offline): + - From date: 1st of February 2024 18:00 UTC - Namada protocol version: `v0.31.0` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.3d767ac5d5` From 671fb6a2d0d5b5c192d42f0f216355e610613a82 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Tue, 6 Feb 2024 07:22:55 +0000 Subject: [PATCH 40/75] accounts --- packages/docs/pages/users/ibc.mdx | 14 +++++++------- packages/docs/pages/users/transparent-accounts.mdx | 4 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/packages/docs/pages/users/ibc.mdx b/packages/docs/pages/users/ibc.mdx index de6c5397..71a19dee 100644 --- a/packages/docs/pages/users/ibc.mdx +++ b/packages/docs/pages/users/ibc.mdx @@ -16,18 +16,18 @@ to find the address. **For the local node ONLY** - To find your ledger address for Chain A, you can run the following command - ```bash copy - export BASE_DIR_A = "${HERMES}/data/namada-a/.namada" - export LEDGER_ADDRESS_A = "$(grep "rpc_address" ${BASE_DIR_A}/${CHAIN_A_ID}/setup/validator-0/.namada/${CHAIN_A_ID}/config.toml)" - ``` +To find your ledger address for Chain A, you can run the following command +```bash copy +export BASE_DIR_A="${HERMES}/data/namada-a/.namada" +export LEDGER_ADDRESS_A="$(grep "rpc_address" ${BASE_DIR_A}/${CHAIN_A_ID}/setup/validator-0/.namada/${CHAIN_A_ID}/config.toml)" +``` -The channel ID for this chain will depend on the order in which one created the channel. Since we have only opened one channel, the `channel-id` is `channel-0`, but as more are created, these increase by index incremented by 1. The channel-id should be communicated by the relayer. +The [channel ID](../operators/ibc.mdx) for this chain will depend on the order in which one created the channel. Since we have only opened one channel, the `channel-id` is `channel-0`, but as more are created, these increase by index incremented by 1. The channel-id should be communicated by the relayer. Assuming that the open channel is `channel-0`, you can save it in an environment variable by running ```bash copy -export CHANNEL_ID = "channel-0" +export CHANNEL_ID="channel-0" ``` The inter-blockchain transfers from Chain A can be achieved by diff --git a/packages/docs/pages/users/transparent-accounts.mdx b/packages/docs/pages/users/transparent-accounts.mdx index 69d62f5a..39276a79 100644 --- a/packages/docs/pages/users/transparent-accounts.mdx +++ b/packages/docs/pages/users/transparent-accounts.mdx @@ -5,8 +5,8 @@ import { Callout } from 'nextra-theme-docs' All accounts in Namada have a unique address, exactly one Validity Predicate and optionally any additional data in its dynamic storage sub-space. There are currently 3 types of account addresses: -- **Implicit *(not fully supported yet)*:** An implicit account is derived from your keypair and can be used to authorize certain transactions from the account. They can be used as recipients of transactions even if the account has not been used on-chain before. -- **Established:** Used for accounts that allow the deployment of custom validation logic. These must be created on-chain via a transaction (e.g., [account initialization](./transparent-accounts/send-and-receive-nam-tokens.mdx#initialize-an-established-account)). The address is generated on-chain and is not known until the transaction is applied (the user provides randomness). +- **Implicit:** An implicit account is derived from your keypair and can be used to authorize certain transactions from the account. Implicit accounts have no code attached to them, and can only have one key controlling it. This differs it from established accounts, which can support multiple keys. +- **Established:** An established account is a associated with one or more cryptographic keys. Each account has the `vp_user` predicate which validate any associated transaction. The main purpose of this code is to ensure that the multisignature threshold is correctly met and stores the keys that verify transactions. All established accounts will be inititalised through on-chain transactions, unlike implicit accounts, which exist as soon as the keypair is generated. - **Internal:** Special internal accounts, such as protocol parameters account, PoS and IBC. ## Manage keypairs From 90c277e688ba71c75eeda007c059e0329361128f Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Tue, 6 Feb 2024 07:49:17 +0000 Subject: [PATCH 41/75] redelgate command added --- packages/docs/pages/users/delegators.mdx | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/packages/docs/pages/users/delegators.mdx b/packages/docs/pages/users/delegators.mdx index a16e575e..88631042 100644 --- a/packages/docs/pages/users/delegators.mdx +++ b/packages/docs/pages/users/delegators.mdx @@ -33,5 +33,11 @@ If you have the alias saved in your wallet, you can also pass ` ## Redelegating Redelegating is the process of changing the delegate you have bonded to. This process takes 4 epochs, after which your NAM will be redelegated. +To redelegate, you can use the following command: + +```bash copy +namadac redelegate --source-validator "" --destination-validator "" --owner "" --amount "" +``` + ## Unbonding Unbonding is the process of removing your bonded NAM from a delegate. This process is identical to [unbonding tokens from a validator](../operators/validators/staking.mdx#unbonding). From 4f160a08fd29a8660b5a0ccbd3ca3022e4b9859b Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Tue, 6 Feb 2024 18:38:58 +0000 Subject: [PATCH 42/75] corrected chain id --- packages/docs/pages/networks/testnets/joining-the-testnet.mdx | 4 ++-- packages/docs/pages/operators/ledger/running-a-full-node.mdx | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx index d25e545d..86046801 100644 --- a/packages/docs/pages/networks/testnets/joining-the-testnet.mdx +++ b/packages/docs/pages/networks/testnets/joining-the-testnet.mdx @@ -17,7 +17,7 @@ If you have been selected. You must run the following command: ```bash CHAIN_ID="" VALIDATOR_ALIAS="" -NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.b40d8e9055" namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS +NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.88f17d1d14" namadac utils join-network --chain-id $CHAIN_ID --genesis-validator $VALIDATOR_ALIAS ``` @@ -29,7 +29,7 @@ E.g if your base directory is `.namada` and your validator alias is `my-validato CHAIN_ID="" VALIDATOR_ALIAS="my-validator" BASE_DIR=".namada" -NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.b40d8e9055" namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS +NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.88f17d1d14" namadac utils join-network --chain-id $CHAIN_ID --pre-genesis-path $BASE_DIR/pre-genesis/$VALIDATOR_ALIAS ``` diff --git a/packages/docs/pages/operators/ledger/running-a-full-node.mdx b/packages/docs/pages/operators/ledger/running-a-full-node.mdx index 3e4184bf..c691d360 100644 --- a/packages/docs/pages/operators/ledger/running-a-full-node.mdx +++ b/packages/docs/pages/operators/ledger/running-a-full-node.mdx @@ -7,7 +7,7 @@ Before starting a full node, the unique identifier of the `chain-id` will be nee Once the `chain-id` has been distributed, it is possible to join the network with the `CHAIN_ID`: ```bash copy export CHAIN_ID="namada-mainnet" ## (replace with the actual chain-id) - NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.b40d8e9055" namada client utils join-network --chain-id $CHAIN_ID + NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.88f17d1d14" namada client utils join-network --chain-id $CHAIN_ID ``` ### Start your node and sync From 57120d881722ffa9500bea386985f2b959818bdf Mon Sep 17 00:00:00 2001 From: brentstone Date: Tue, 6 Feb 2024 16:30:17 -0500 Subject: [PATCH 43/75] fix namada version --- packages/docs/pages/networks/testnets/environment-setup.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index 44e9c584..3fcb1b54 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.31.0 +export NAMADA_TAG=v0.31.1 ``` From 479bb7173fea51e1cd3e7f71d4943ca4585998e8 Mon Sep 17 00:00:00 2001 From: brentstone Date: Tue, 6 Feb 2024 18:57:57 -0500 Subject: [PATCH 44/75] update pos for users --- packages/docs/pages/users/_meta.json | 4 +- packages/docs/pages/users/delegators.mdx | 88 +++++++++++++++++++----- 2 files changed, 72 insertions(+), 20 deletions(-) diff --git a/packages/docs/pages/users/_meta.json b/packages/docs/pages/users/_meta.json index 8fd9ed06..f2f6129e 100644 --- a/packages/docs/pages/users/_meta.json +++ b/packages/docs/pages/users/_meta.json @@ -3,8 +3,8 @@ "transparent-accounts": "Transparent accounts", "shielded-accounts": "The MASP", "fees": "Fees on Namada", - "delegators": "Delegating stake on Namada", + "delegators": "Bonding and Proof-of-stake", "governance": "Governance and Public Goods Funding", "public-goods-stewards": "PGF", "ibc": "IBC transfers" -} +} \ No newline at end of file diff --git a/packages/docs/pages/users/delegators.mdx b/packages/docs/pages/users/delegators.mdx index 88631042..d4875269 100644 --- a/packages/docs/pages/users/delegators.mdx +++ b/packages/docs/pages/users/delegators.mdx @@ -1,22 +1,18 @@ -# Delegators +# Bonding and proof-of-stake -## Delegators vs Delegates -All accounts on Namada with any amount of *bonded* NAM, is by definition, either a delegator or a delegate. +## Bonded tokens +Any account on Namada can *bond* or *stake* NAM tokens to any validator in the proof-of-stake system. When NAM tokens are bonded to a validator, that validator, if it is a member of the consensus set, may use those tokens as voting power to vote or sign newly proposed blocks. -#### What is a delegator? -> A delegator is an account that has bonded NAM to a delegate. +These validators earn some block rewards for doing so, and the original stakers of those tokens earn a proportional share of the validators' block rewards. -#### What is a delegate? -> A delegate is an account that has been bonded to by a delegator. +The non-validator accounts that bond NAM to a validator are known as *delegators*. Validators may also bond NAM tokens to themselves. ## Becoming a delegator In order to become a delegator, you must first have an account with positive NAM balance. If you do not have an account, you can follow the instructions [here](./transparent-accounts.mdx) to create one. -Once you have an account, you can bond your NAM to a delegate. At the time of writing, the only possible delegates are validators. In future Namada versions, there will be the option to delegate to other, non-validating accounts as well. +Once you have an account, you can bond your NAM to a validator. Bonding (or delegating) to a validator is the same as [staking with a validator](../operators/validators/staking.mdx). -Delegating to a validator is the same as [staking with a validator](../operators/validators/staking.mdx). - -First, you may want to list the available validators you can stake to: +First, you may want to list some available validators you can stake to: ```bash copy namadac bonded-stake @@ -25,19 +21,75 @@ namadac bonded-stake Once you've found the address of your favourite validator, you can bond to them with the following command: ```bash copy -namadac bond --validator --amount --signing-keys +namadac bond --source --validator --amount ``` -If you have the alias saved in your wallet, you can also pass `` instead of ``. +The `` is your account address from which you would like to stake NAM tokens. Validators who would like to self-bond do not need to provide the `--source` argument. -## Redelegating -Redelegating is the process of changing the delegate you have bonded to. This process takes 4 epochs, after which your NAM will be redelegated. +If you have the alias for an address saved in your wallet, you can also pass it as an argument. + +Once the transaction is submitted, the bond will become active at the *pipeline length* relative to the current epoch, which is some number of epochs in the future relative to the current one. Currently, this value is 2 epochs. -To redelegate, you can use the following command: +The pipeline length of the chain and other important proof-of-stake parameters can be queried from the chain with the following command: ```bash copy -namadac redelegate --source-validator "" --destination-validator "" --owner "" --amount "" +namadac query-protocol-parameters ``` ## Unbonding -Unbonding is the process of removing your bonded NAM from a delegate. This process is identical to [unbonding tokens from a validator](../operators/validators/staking.mdx#unbonding). +Unbonding is the process of removing your bonded NAM from a validator, and this must be done before attempting to withdraw your previously bonded tokens. + +This process is identical to [unbonding tokens from a validator](../operators/validators/staking.mdx#unbonding). + +The command to unbond is similar to the bonding command: + +```bash copy +namadac unbond --source --validator --amount +``` + +After a successful unbond transaction, the unbonded NAM tokens will be available for withdrawal after `pipeline_length + unbonding_length + cubic_slashing_window_length` epochs. Once again, the values of these three parameters can be queried from the chain. + +## Withdrawing +When the full unbonding period has passed, you can withdraw the unbonded NAM using the following command: + +```bash copy +namadac withdraw --source --validator +``` + +This transaction will immediately transfer all fully unbonded NAM tokens back to the `delegator-address` account, increasing your transferable balance. + +You may also query some information regarding how many NAM tokens are available for withdrawal with the following command: + +```bash copy +namadac bonds --owner +``` + +## Redelegating +In certain circumstances, you may want to switch the validator that holds your bonded tokens. This could be because your original validator has dropped out of the consensus set or has been deactivated or jailed and slashed for misbehaving. + +You can accomplish this with a redelegating the bonded tokens rather than unbonding, withdrawing, and then bonding again. Use the following command: + +```bash copy +namadac redelegate --owner --source-validator --destination-validator --amount +``` + +The `delegator-address` is your address, the `source-validator` is the validator that currently holds your bond, and the `destination-validator` is your desired new validator to hold your bond. + +Your new bond will be active and begin contributing to the `destination-validator`'s voting power after the pipeline length has passed. It will no longer be held by the `source-validator` at this epoch as well. + +## Claiming rewards +Inflationary rewards for proof-of-stake are computed and minted once per epoch, at the very beginning of a new epoch. + +In order to claim rewards that are owed to you for bonded NAM tokens, run the following command: + +```bash copy +namadac claim-rewards --source --validator +``` + +Successful execution of this transaction will immediately transfer the the reward tokens you are owed to your `delegator-address`, incrementing your transparent balance. + +Additionally, you can query the pending reward tokens without claiming by running: + +```bash copy +namadac rewards --source --validator +``` From b7a98201993ece155285068e40cf30718428c7f2 Mon Sep 17 00:00:00 2001 From: brentstone Date: Wed, 7 Feb 2024 16:34:08 -0500 Subject: [PATCH 45/75] change to Namada 0.31.2 --- packages/docs/pages/networks/testnets.mdx | 2 +- packages/docs/pages/networks/testnets/environment-setup.mdx | 4 ++-- packages/docs/pages/networks/testnets/testnet-history.mdx | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 5c024177..c7eae713 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -17,7 +17,7 @@ The `balances.toml` file is located at `https://github.com/anoma/namada-shielded - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.1` + - Namada protocol version: `v0.31.2` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14` diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index 3fcb1b54..65bbc746 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.31.1 +export NAMADA_TAG=v0.31.2 ``` @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.31.1` + - `namada --version` should output `Namada v0.31.2` diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index 1b3c15b8..37c684dd 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -12,7 +12,7 @@ No upgrades are currently scheduled. - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.1` + - Namada protocol version: `v0.31.2` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14` From 24d37d70c554457e2086800f37d0364ea8f3e873 Mon Sep 17 00:00:00 2001 From: brentstone Date: Thu, 8 Feb 2024 15:37:05 -0500 Subject: [PATCH 46/75] jailing for validators --- .../pages/operators/validators/_meta.json | 5 +- .../pages/operators/validators/jailing.mdx | 60 +++++++++++++++++++ 2 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 packages/docs/pages/operators/validators/jailing.mdx diff --git a/packages/docs/pages/operators/validators/_meta.json b/packages/docs/pages/operators/validators/_meta.json index c41995de..f521d169 100644 --- a/packages/docs/pages/operators/validators/_meta.json +++ b/packages/docs/pages/operators/validators/_meta.json @@ -1,5 +1,6 @@ { "validator-setup": "Validator setup", "staking": "Staking", - "proof-of-stake": "Proof of stake" -} + "proof-of-stake": "Proof of stake", + "jailing": "Jailing" +} \ No newline at end of file diff --git a/packages/docs/pages/operators/validators/jailing.mdx b/packages/docs/pages/operators/validators/jailing.mdx new file mode 100644 index 00000000..25034a42 --- /dev/null +++ b/packages/docs/pages/operators/validators/jailing.mdx @@ -0,0 +1,60 @@ +# Jailed validators + +Validators can be *jailed* for several reasons, such as double signing a block, signing an invalid block, or excessive downtime. Each of these reasons will have different ramifications for the validator. + +When a validator is jailed, it is removed from the validator sets and cannot participate in consensus. The validator node can still run and process the new blocks. A jailed validator can also still receive bonds. + +When the protocol determines that a validator will be jailed, the jailing and validator set removal will occur at the beginning of the next new epoch. + +You can check if a validator is jailed by querying its state with the following command: + +```bash copy +namadac validator-state --validator +``` + +## Unjailing a validator + +Once jailed, validators remain jailed indefinitely. They can only be unjailed by an `unjail-validator` transaction using the validator's signing keys. This can be done with the following command: + +```bash copy +namadac unjail-validator --validator +``` + +If the transaction is successful, then the validator will be reinstated into one of the validator sets at the pipeline length relative to the current epoch (typically 2 epochs in the future). + +There may be certain restrictions on unjailing your validator depending on the original reason for jailing. These will be described below. + +## Jailing for protocol misbehavior + +Protocol misbehaviors include the aforementioned double signing of a block and signing of an invalid block. + +In these cases, the validator will also be slashed - it and its delegates will lose stake and voting power. + +When a slash is detected and enqueued by the protocol, it is scheduled to be processed `unbonding_len + cubic_slashing_window_len + 1` epochs after the infraction epoch. This is to allow for sufficient time to detect all possible correlated infractions to be considered for cubic slashing. + +The validator will also be considered to be *frozen* until it no longer has any unprocessed, enqueued slashes. While *frozen*, unbonding from the validator is prohibited, and unjailing is forbidden. + +A validator's slash history, with previously processed slashes and enqueued slashes for future processing, can be queried with the following command: + +```bash copy +namadac slashes --validator +``` + +Additionally, all slashes in the network can be queried without the `--validator` flag. + +## Jailing for downtime (liveness) + +While a validator is in the consensus set, its uptime and voting history are tracked to ensure sufficient liveness. Two proof-of-stake parameters are used to determine if a validator will be jailed for liveness: + +- `liveness_window_check` +- `liveness_threshold` + +Namada liveness requires that a consensus validator vote on at least a `liveness_threshold` fraction of the last `liveness_window_check` blocks. If at any point this fraction dips below the `liveness_threshold`, then the validator will be jailed. + +The values of these parameters can be queried with the command: + +```bash copy +namadac query-protocol-parameters +``` + +Since jailing for downtime occurs without the presence of slashes (they are not *frozen*), the jailed validator can unjail themselves as soon as they become jailed. \ No newline at end of file From 6de0dcd62b77e1465980ebb4beb8482fdd061c79 Mon Sep 17 00:00:00 2001 From: brentstone Date: Thu, 8 Feb 2024 15:37:15 -0500 Subject: [PATCH 47/75] user interactions with jailed validators --- packages/docs/pages/users/delegators.mdx | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/packages/docs/pages/users/delegators.mdx b/packages/docs/pages/users/delegators.mdx index d4875269..1718c822 100644 --- a/packages/docs/pages/users/delegators.mdx +++ b/packages/docs/pages/users/delegators.mdx @@ -93,3 +93,11 @@ Additionally, you can query the pending reward tokens without claiming by runnin ```bash copy namadac rewards --source --validator ``` + +## Interacting with jailed validators + +When the validator that holds a bond is jailed, there are restrictions on what can be done with the bond. + +Bonding tokens is always permitted to any validator, even if it is jailed. + +Unbonding and redelegating from a jailed validator is not permitted if that validator is enqueued to be slashed (it is *frozen*), as described in [this section on jailing validators for protocol misbehaviors](../operators/validators/jailing.mdx#jailing-for-protocol-misbehavior). Otherwise, unbonding and redelegating is permitted. \ No newline at end of file From 42befa8da6b170fdf64994809850b1d692323c9d Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 9 Feb 2024 14:20:52 +0100 Subject: [PATCH 48/75] fixed parse error --- .../ethereum-bridge/ethereum_events_attestation.mdx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/packages/specs/pages/interoperability/ethereum-bridge/ethereum_events_attestation.mdx b/packages/specs/pages/interoperability/ethereum-bridge/ethereum_events_attestation.mdx index 7558ee63..bf5b3896 100644 --- a/packages/specs/pages/interoperability/ethereum-bridge/ethereum_events_attestation.mdx +++ b/packages/specs/pages/interoperability/ethereum-bridge/ethereum_events_attestation.mdx @@ -6,8 +6,7 @@ weighted average of more than $\frac{2}{3}$ of the voting power available across all epochs of the tally. Generically, Namada considers some tally $t$ `seen` if it satisfies the following inequality: -$$\sum_{E \in \xi} (\frac{\sigma(E)}{\sum_{E' \in \xi} \sigma(E')} \cdot F_E) > -\frac{2}{3}$$ +$$\sum_{E \in \xi} (\frac{\sigma(E)}{\sum_{E' \in \xi} \sigma(E')} \cdot F_E) > \frac{2}{3}$$ Where $\xi$ is the set of epochs when $t$ took place, $\sigma$ is a function mapping an epoch to its total voting power and $F_E$ is the From 104b65f4a6e78a95340ecf27d985ec1e2c18488e Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Fri, 9 Feb 2024 14:30:39 +0100 Subject: [PATCH 49/75] example for offline proposal added --- .../users/governance/off-chain-governance.mdx | 24 ++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/packages/docs/pages/users/governance/off-chain-governance.mdx b/packages/docs/pages/users/governance/off-chain-governance.mdx index 0fe96379..61420184 100644 --- a/packages/docs/pages/users/governance/off-chain-governance.mdx +++ b/packages/docs/pages/users/governance/off-chain-governance.mdx @@ -6,7 +6,29 @@ If for any reason issuing an on-chain proposal is not adequate to your needs, yo ## Create proposal -Create the same json file as in the on-chain proposal and use the following command: +### The proposal file + +For offline proposals, the structure of the `proposal.json` file is as follows: + +```json +"content": { + "title": "", + "authors": "<email>", + "discussions-to": "<forum-link>", + "created": "<Timestamp in format YYYY-MM-DDTHH:MM:SSZ>", + "license": "<Licences>", + "abstract": "<Abstract>", + "motivation": "<Motivation>", + "details": "<Details>", + "requires": "<preceding-proposal-id-that-must-pass>", + }, +"author": "<author-address>", +"tally_epoch": 1337, +``` + +<Callout> +The `tally_epoch` is the block height at which the tally will be computed. This is any integer after the current epoch. +</Callout> ```shell copy namada client init-proposal \ From 17846caef5456b0233a8b06c9321fcae6166e049 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Fri, 9 Feb 2024 15:04:38 +0100 Subject: [PATCH 50/75] tally_epoch is in past --- packages/docs/pages/users/governance/off-chain-governance.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/users/governance/off-chain-governance.mdx b/packages/docs/pages/users/governance/off-chain-governance.mdx index 61420184..7ef603c3 100644 --- a/packages/docs/pages/users/governance/off-chain-governance.mdx +++ b/packages/docs/pages/users/governance/off-chain-governance.mdx @@ -27,7 +27,7 @@ For offline proposals, the structure of the `proposal.json` file is as follows: ``` <Callout> -The `tally_epoch` is the block height at which the tally will be computed. This is any integer after the current epoch. +The `tally_epoch` is the block height at which the tally was computed. This is any integer before the current epoch. Since the tallying should occur before it is submitted. </Callout> ```shell copy From f9c220aaf1a9bd9a1bb22cf9256a69f2f011f927 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Fri, 9 Feb 2024 16:11:46 +0100 Subject: [PATCH 51/75] signing keys essential --- .../docs/pages/users/governance/off-chain-governance.mdx | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/packages/docs/pages/users/governance/off-chain-governance.mdx b/packages/docs/pages/users/governance/off-chain-governance.mdx index 7ef603c3..419400e3 100644 --- a/packages/docs/pages/users/governance/off-chain-governance.mdx +++ b/packages/docs/pages/users/governance/off-chain-governance.mdx @@ -26,18 +26,24 @@ For offline proposals, the structure of the `proposal.json` file is as follows: "tally_epoch": 1337, ``` -<Callout> +<Callout type="info"> The `tally_epoch` is the block height at which the tally was computed. This is any integer before the current epoch. Since the tallying should occur before it is submitted. </Callout> ```shell copy namada client init-proposal \ --data-path proposal.json \ + --signing-keys your-signing-keys-for-author \ --offline ``` This command will create a `proposal` file same directory where the command was launched. +<Callout type="info"> +If you would like the proposal to be created in a different directory, you can use the `--output-folder-path` flag to specify the directory. The directory must already exist, however. +It is also essential that you provide the `--signing-keys` argument to sign the proposal. As of `v0.31.2`, the `--signing-keys` is optional but it is not possible to sign the proposal after it has been created. +</Callout> + ## Vote on proposal To vote on an offline proposal use the following command: From 7c1df8d58bb0216cfd4696274e4a408126969235 Mon Sep 17 00:00:00 2001 From: phy-chain <108097051+phy-chain@users.noreply.github.com> Date: Mon, 12 Feb 2024 21:37:41 +0100 Subject: [PATCH 52/75] Add "abstain" option to on-chain-governance.mdx --- packages/docs/pages/users/governance/on-chain-governance.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index c4ebd726..89631350 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -229,7 +229,7 @@ namada client vote-proposal \ --signing-keys <your-alias> ``` -where `--vote` can be either `yay` or `nay`. +where `--vote` can be either `yay`, `nay` or `abstain`. ## Check the result From 9a6cc9895260278f37fda8b411be9695e1443470 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Tue, 13 Feb 2024 09:31:33 +0000 Subject: [PATCH 53/75] gov specs improved slightly --- packages/specs/pages/governance/proposal.mdx | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/packages/specs/pages/governance/proposal.mdx b/packages/specs/pages/governance/proposal.mdx index 7d49b267..7616fd12 100644 --- a/packages/specs/pages/governance/proposal.mdx +++ b/packages/specs/pages/governance/proposal.mdx @@ -3,7 +3,21 @@ import { Callout } from 'nextra-theme-docs' # Namada Proposals ## Proposal JSON -Field semantics are as follows: +For online proposals, the fields of the proposal JSON are as follows: + +```json +{ + "proposal": { + "id": 1, // The proposal id + "content": content, // (see below), + "author": "author", // The author's address + "voting_start_epoch": 420, // The epoch at which voting starts + "voting_end_epoch": 426, // The epoch at which voting ends + "grace_epoch": 432, // The epoch at which the proposal will be executed (if it passes) + }, + "data": data // The optional proposal data, depends on the type of proposal +} +``` - The `content` value should follow a standard format. We leverage a similar format to what is described in the [BIP2](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-format-and-structure) document: From 446ecf3d5767d1e24343c07639b644be924d6ca1 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Tue, 13 Feb 2024 10:40:15 +0000 Subject: [PATCH 54/75] small changes --- packages/specs/pages/base-ledger.mdx | 4 ++-- packages/specs/pages/economics.mdx | 2 +- packages/specs/pages/further-reading.mdx | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/specs/pages/base-ledger.mdx b/packages/specs/pages/base-ledger.mdx index 07deacd1..c3d26612 100644 --- a/packages/specs/pages/base-ledger.mdx +++ b/packages/specs/pages/base-ledger.mdx @@ -5,8 +5,8 @@ The base ledger of Namada includes a [consensus mechanism](./base-ledger/consens ## Consensus The consensus mechanism on Namada provides an algorithmic way for validators to communicate votes and collectively agree on a consistent state. The algorithm, coupled with a cryptoeconomic voting power allocation mechanism called "proof of stake", is designed so that that non-colluding validators acting in their (economic) self interest will follow the consensus algorithm in a predictable manner. -## Validity predicates -The validity-predicate based execution mechanism is inherited from the architectural design philosophy of Anoma. The fundamental idea is that a "valid state" is defined as that which satisfies a set of boolean conditions. These boolean conditions are encoded by functional "validity predicates", which are invoked whenever a state is being proposed. If all validity predicates in the system return the boolean `true`, this defines a valid state which validators can vote on. The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps. These execution steps are defined within the smart contract, and verifying the validity of the new state requires *each* validator to run the series of execution steps. +## Validity predicates (Resource Logics) +The validity-predicate (now known as resource logic) based execution mechanism is inherited from the architectural design philosophy of Anoma. The fundamental idea is that a "valid state" is defined as that which satisfies a set of boolean conditions. These boolean conditions are encoded by functional ([in the programtic sense](https://en.wikipedia.org/wiki/Functional_programming)) "validity predicates", which are invoked whenever a state is being proposed. If all validity predicates in the system return the boolean `true`, this defines a valid state which validators can vote on. The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps. These execution steps are defined within the smart contract, and verifying the validity of the new state requires *each* validator to run the series of execution steps. ## Replay protection & block space allocator In addition to describing the execution model and consensus, this section also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), and [block space allocator](./base-ledger/block-space-allocator.mdx). diff --git a/packages/specs/pages/economics.mdx b/packages/specs/pages/economics.mdx index e9586e58..747372a8 100644 --- a/packages/specs/pages/economics.mdx +++ b/packages/specs/pages/economics.mdx @@ -1,3 +1,3 @@ ## Economics -Namada users pay transaction fees in NAM and other tokens (see [fee system](./economics/fee-system.mdx) and [governance](./base-ledger/governance.mdx)), so demand for NAM can be expected to track demand for block space. On the supply side, the protocol mints NAM at a fixed maximum per-annum rate based on a fraction of the current supply (see [inflation system](./economics/inflation-system.mdx)), which is directed to three areas of protocol subsidy: [proof-of-stake](./economics/proof-of-stake.mdx), [shielded pool incentives](./economics/shielded-pool-incentives.mdx), and [public-goods funding](./economics/public-goods-funding.mdx). Inflation rates for these three areas are adjusted independently (the first two on PD controllers and the third based on funding decisions) and excess tokens are slowly burned. \ No newline at end of file +Namada users pay transaction fees in NAM and other tokens (see [fee system](./economics/fee-system.mdx) and [governance](./governance.mdx)), so demand for NAM can be expected to track demand for block space. On the supply side, the protocol mints NAM at a variable but capped per-annum rate based on a fraction of the current supply (see [inflation system](./economics/inflation-system.mdx)), which is directed to three areas of protocol subsidy: [proof-of-stake](./economics/proof-of-stake.mdx), [shielded pool incentives](./economics/shielded-pool-incentives.mdx), and [public-goods funding](./economics/public-goods-funding.mdx). Inflation rates for these three areas are adjusted independently (the first two on PD controllers and the third based on funding decisions) and excess tokens are slowly burned. \ No newline at end of file diff --git a/packages/specs/pages/further-reading.mdx b/packages/specs/pages/further-reading.mdx index 94890d64..b94a4df6 100644 --- a/packages/specs/pages/further-reading.mdx +++ b/packages/specs/pages/further-reading.mdx @@ -4,7 +4,7 @@ Thanks for reading! You can find further information about the project below: - [Namada website](https://namada.net) - [Namada source code](https://github.com/anoma/namada) -- [Namada community links](https://namada.net/#community) +- [Namada community links](https://namada.net/community/docs) - [Namada blog](https://blog.namada.net) - [Namada Docs](https://docs.namada.net/) - [Namada Twitter](https://twitter.com/namada) From ee49b0b76a693ea05b5845771fd9092729270ece Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Tue, 13 Feb 2024 12:39:43 +0000 Subject: [PATCH 55/75] upgrayydddd --- packages/docs/pages/networks/testnets/testnet-history.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index 37c684dd..6775ade5 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -6,7 +6,9 @@ This page covers all installation steps required by various upgrades to testnets ## Latest Upgrade -No upgrades are currently scheduled. +## Namada shielded expedition 2 `v0.31.4` upgrade + +In order to upgrade to the latest version of the Namada protocol, please follow the steps from [this hackmd](https://hackmd.io/EBTtfPiZT7yoRjxYRcbiPQ) ## Shielded expedition From d0c30d596d483c68da521177de9c58c90467b3a2 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Tue, 13 Feb 2024 15:43:21 +0000 Subject: [PATCH 56/75] updated for v0.31.4 --- packages/docs/pages/operators/ibc.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/docs/pages/operators/ibc.mdx b/packages/docs/pages/operators/ibc.mdx index 7a6464ce..879f1c6c 100644 --- a/packages/docs/pages/operators/ibc.mdx +++ b/packages/docs/pages/operators/ibc.mdx @@ -21,7 +21,7 @@ Below, we discuss first how to enable this connection between two pre-existing c ## Configure Hermes Hermes is an IBC relayer to relay IBC packets between chains. -Namada uses a [fork of Hermes supporting Namada chains](https://github.com/heliaxdev/hermes/tree/v1.7.1-namada-beta4). +Namada uses a [fork of Hermes supporting Namada chains](https://github.com/heliaxdev/hermes/tree/v1.7.4-namada-beta7). ### Make Hermes config file One essential piece of the puzzle is to create a `config.toml` file that describes what connections will be set up that the relayer will be responsible for. @@ -123,7 +123,7 @@ One can download the latest binary release from our [releases page](https://gith E.g. ```bash copy -export TAG="v1.7.1-namada-beta4" +export TAG="v1.7.4-namada-beta7" export ARCH="x86_64-unknown-linux-gnu" # or "aarch64-apple-darwin" curl -Lo /tmp/hermes.tar.gz https://github.com/heliaxdev/hermes/releases/download/${TAG}/hermes-${TAG}-${ARCH}.tar.gz tar -xvzf /tmp/hermes.tar.gz -C /usr/local/bin @@ -140,7 +140,7 @@ This is also true for the command `cp ./target/release/hermes /usr/local/bin/` b ### From source ```bash copy -export TAG="v1.7.1-namada-beta4" +export TAG="v1.7.4-namada-beta7" git clone https://github.com/heliaxdev/hermes.git git checkout $TAG @@ -293,7 +293,7 @@ First, you will need to export some environment variables: ```bash copy export NAMADA_DIR="<path-to-namada-source-directory>" -export TAG="v1.7.1-namada-beta4" +export TAG="v1.7.4-namada-beta7" ``` ```bash copy From bb207cf3ec2a50bca940715d2238ad72ee7137f4 Mon Sep 17 00:00:00 2001 From: Christopher Goes <cwgoes@pluranimity.org> Date: Tue, 13 Feb 2024 16:43:38 +0100 Subject: [PATCH 57/75] Minor editing --- packages/specs/pages/base-ledger.mdx | 10 ++++++---- .../specs/pages/base-ledger/consensus.mdx | 10 +++++----- .../specs/pages/base-ledger/execution.mdx | 11 ++++++----- packages/specs/pages/further-reading.mdx | 4 ++-- packages/specs/pages/index.mdx | 19 +++++++++---------- 5 files changed, 28 insertions(+), 26 deletions(-) diff --git a/packages/specs/pages/base-ledger.mdx b/packages/specs/pages/base-ledger.mdx index c3d26612..f576a7fb 100644 --- a/packages/specs/pages/base-ledger.mdx +++ b/packages/specs/pages/base-ledger.mdx @@ -3,10 +3,12 @@ The base ledger of Namada includes a [consensus mechanism](./base-ledger/consensus.mdx) and a validity-predicate based [execution system](./base-ledger/execution.mdx). ## Consensus -The consensus mechanism on Namada provides an algorithmic way for validators to communicate votes and collectively agree on a consistent state. The algorithm, coupled with a cryptoeconomic voting power allocation mechanism called "proof of stake", is designed so that that non-colluding validators acting in their (economic) self interest will follow the consensus algorithm in a predictable manner. -## Validity predicates (Resource Logics) -The validity-predicate (now known as resource logic) based execution mechanism is inherited from the architectural design philosophy of Anoma. The fundamental idea is that a "valid state" is defined as that which satisfies a set of boolean conditions. These boolean conditions are encoded by functional ([in the programtic sense](https://en.wikipedia.org/wiki/Functional_programming)) "validity predicates", which are invoked whenever a state is being proposed. If all validity predicates in the system return the boolean `true`, this defines a valid state which validators can vote on. The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps. These execution steps are defined within the smart contract, and verifying the validity of the new state requires *each* validator to run the series of execution steps. +The consensus mechanism on Namada provides an algorithmic way for validators to communicate votes and collectively agree on a single, consistent state in a Byzantine-fault-tolerant manner. The algorithm, coupled with a cryptoeconomic voting power allocation mechanism called "proof of stake", is designed so that that non-colluding validators acting in their (economic) self interest will follow the consensus algorithm in a predictable manner. + +## Validity predicates + +The validity predicate based execution mechanism is inherited from the architectural design philosophy of Anoma. The fundamental idea is that a "valid state" is defined as that which satisfies a set of boolean conditions. These boolean conditions are encoded by "validity predicates", represented as WASM or Rust-native functions, which are invoked whenever a state is being proposed. If all validity predicates in the system return the boolean `true`, this defines a valid state which validators can vote on. The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps. ## Replay protection & block space allocator -In addition to describing the execution model and consensus, this section also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), and [block space allocator](./base-ledger/block-space-allocator.mdx). +In addition to describing the execution model and consensus, this section also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), which prevents transactions from being executed multiple times, and [block space allocator](./base-ledger/block-space-allocator.mdx), which packs transactions into blocks. \ No newline at end of file diff --git a/packages/specs/pages/base-ledger/consensus.mdx b/packages/specs/pages/base-ledger/consensus.mdx index e459e5ea..5c977e50 100644 --- a/packages/specs/pages/base-ledger/consensus.mdx +++ b/packages/specs/pages/base-ledger/consensus.mdx @@ -5,13 +5,13 @@ Namada uses [CometBFT](https://github.com/cometbft/cometbft/) (nee Tendermint Go {/* Maybe we want to leave out the below section. I just felt we should give a brief summary of CometBFT */} ## The benefits of using CometBFT -Using the CometBFT consensus algorithm comes with a number of benefits including but not limited to: +Using the CometBFT consensus algorithm comes with a number of benefits including: - Fast finality - - CometBFT achieves fast and deterministic finality, meaning that once a block is committed to the blockchain, it is irreversible. This is crucial for applications rely on settled transactions that cannot be rolled back. + - CometBFT achieves fast and deterministic finality, meaning that once a block is committed to the blockchain, it is irreversible. This is crucial for applications which rely on settled transactions that cannot be rolled back, and enables efficient, low-latency interoperability. - Inter-blockchain communication system (IBC) - - Composability with all other CometBFT-based blockchains, such as Cosmos-ecosystem blockchains + - Interoperability with all other IBC-supporting chains, such as [Osmosis](https://osmosis.zone), the [Cosmos Hub](https://cosmos.network), and [Noble](https://nobleassets.xyz/). - Battle tested - - The entire Cosmos ecosystem has been using CometBFT (nee Tendermint) for years + - The entire Cosmos ecosystem has been using CometBFT (nee Tendermint) for years. - Customisable - - Allows the setting of various parameters, including the ability to implement a custom proof of stake algorithm \ No newline at end of file + - Allows the configuration of various parameters, including the ability to implement a custom proof of stake algorithm (as Namada does). \ No newline at end of file diff --git a/packages/specs/pages/base-ledger/execution.mdx b/packages/specs/pages/base-ledger/execution.mdx index 0a748ceb..c0c13fdd 100644 --- a/packages/specs/pages/base-ledger/execution.mdx +++ b/packages/specs/pages/base-ledger/execution.mdx @@ -5,16 +5,17 @@ The Namada ledger execution system is based on an initial version of the Anoma e ## Validity predicates Conceptually, a validity predicate (VP) is a boolean function which takes four inputs: -1. The transaction itself (certain parts of the transaction are sometimes analyzed in the VP logic) + +1. The transaction itself (certain parts of the transaction are sometimes analyzed in the VP logic, such as MASP proofs) 2. The addresses that are involved with that specific VP -3. The storage state prior to a transaction execution +3. The storage state prior to the transaction execution 4. The storage state after the transaction execution -A transaction may modify any data in the accounts' dynamic storage sub-space. Upon transaction execution, the VPs associated with the accounts whose storage has been modified are invoked to verify the transaction. If any of them reject the transaction, all of its storage modifications are discarded; if all accept, the storage modifications are written. +A transaction may modify any data in storage, which is partitioned into different areas ("accounts"), each associated with a VP. Upon transaction execution, the VPs associated with the accounts whose storage has been modified are invoked to verify the transaction. If any of them reject the transaction, all of its storage modifications are discarded; if all accept, the storage modifications are written. ## Namada ledger -The Namada ledger is built on top of [CometBFT](https://docs.cometbft.com/v0.37/spec/)'s [ABCI](https://docs.cometbft.com/v0.37/spec/abci/) interface with a slight deviation from the ABCI convention: in Namada, the transactions are currently *not* being executed in ABCI's [`DeliverTx` method](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#delivertx), but rather in the [`EndBlock` method](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). {/* TODO: I don't know what we want to say about the above. Maybe delete the below sentence entirely? */} +The Namada ledger is built on top of [CometBFT v0.37](https://docs.cometbft.com/v0.37/spec/)'s [ABCI](https://docs.cometbft.com/v0.37/spec/abci/) interface with a slight deviation from the ABCI convention: in Namada, the transactions are currently *not* being executed in ABCI's [`DeliverTx` method](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#delivertx), but rather in the [`EndBlock` method](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). {/* TODO: I don't know what we want to say about the above. Maybe delete the below sentence entirely? */} The reason for this is to prepare for future DKG and threshold decryption integration. The ledger features an account-based system (in which UTXO-based systems such as the MASP can be internally implemented as specific accounts), where each account has a unique address and a dynamic key-value storage sub-space. Every account in Namada is associated with exactly one validity predicate. Fungible tokens, for example, are accounts, whose rules are governed by their validity predicates. Many of the base ledger subsystems specified here are themselves just special Namada accounts too (e.g. PoS, IBC and MASP). This model is broadly similar to that of [Ethereum](https://ethereum.org/en), where each account is associated with contract code, but differs in the execution model. @@ -27,7 +28,7 @@ The ledger knows what addresses are involved in a WASM transaction because of ho While the execution model is fully programmable, for Namada only a selected subset of provided validity predicates and transactions will be permitted through pre-defined whitelists configured at network launch. -There are some native VPs for internal transparent addresses that are built into the ledger. All the other VPs are implemented as WASM programs. One can build a custom VP using the [VP template](https://github.com/anoma/namada/tree/master/wasm/vp_template) or use one of the pre-defined VPs. +There are some native VPs for internal transparent addresses that are built into the ledger. All the other VPs are implemented as WASM programs. One can build a custom VP using the [VP template](https://github.com/anoma/namada/tree/main/wasm/vp_template) or use one of the pre-defined VPs. {/* TODO: Make sure this is up to date with the ledger */} Supported validity predicates for Namada: diff --git a/packages/specs/pages/further-reading.mdx b/packages/specs/pages/further-reading.mdx index b94a4df6..98f22070 100644 --- a/packages/specs/pages/further-reading.mdx +++ b/packages/specs/pages/further-reading.mdx @@ -6,5 +6,5 @@ Thanks for reading! You can find further information about the project below: - [Namada source code](https://github.com/anoma/namada) - [Namada community links](https://namada.net/community/docs) - [Namada blog](https://blog.namada.net) -- [Namada Docs](https://docs.namada.net/) -- [Namada Twitter](https://twitter.com/namada) +- [Namada docs](https://docs.namada.net/) +- [Namada Twitter](https://twitter.com/namada) \ No newline at end of file diff --git a/packages/specs/pages/index.mdx b/packages/specs/pages/index.mdx index efcc742e..7e232e83 100644 --- a/packages/specs/pages/index.mdx +++ b/packages/specs/pages/index.mdx @@ -2,21 +2,20 @@ import { SpecsAscii } from '../components/SpecsAscii' # Namada +<br /> <SpecsAscii/> ## What is Namada? -Namada is a sovereign proof-of-stake blockchain, using the [CometBFT](https://cometbft.com/) (nee Tendermint) BFT consensus algorithm. Namada enables multi-asset private transfers for any native or non-native asset using a [multi-asset shielded pool](https://research.metastate.dev/multi-asset_shielded_pool/) derived from the [Sapling circuit](https://z.cash/upgrade/sapling/). +Namada is a sovereign proof-of-stake layer-one blockchain, using the [CometBFT](https://cometbft.com/) (nee Tendermint) BFT consensus algorithm. Namada enables multi-asset private transfers for any native or non-native asset using a [multi-asset shielded pool](https://research.metastate.dev/multi-asset_shielded_pool/) derived from the [Sapling circuit](https://z.cash/upgrade/sapling/). -Namada features full IBC protocol support, a natively integrated [Ethereum bridge](./interoperability.mdx), a modern [proof-of-stake system](./economics/proof-of-stake.mdx) with automatic reward compounding and cubic slashing, a [stake-weighted governance signalling mechanism](./governance.mdx), and a dual continuous/retroactive [public goods funding system](./economics/public-goods-funding.mdx). +Namada features full IBC protocol support, a natively integrated [Ethereum bridge](./interoperability.mdx), a modern [proof-of-stake system](./economics/proof-of-stake.mdx) with cubic slashing, a [stake-weighted governance signalling mechanism](./governance.mdx), and a dual continuous/retroactive [public goods funding system](./economics/public-goods-funding.mdx). Users of the MASP are [rewarded](./economics/shielded-pool-incentives.mdx) for their contributions to the privacy set in the form of native protocol tokens (NAM). -Namada supports a variety of different wallets. One of these wallets is the native wallet, that exists in order to facilitate interacting with the protocol in a safe and private manner. +Namada also supports shielded actions, which allow users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains. -Further, Namada supports Shielded Actions, which allows users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains. - -You can learn more about Namada [here](https://blog.namada.net/introducing-namada-interchain-asset-agnostic-privacy/). +You can find an introduction to Namada from a product perspective [here](https://blog.namada.net/introducing-namada-interchain-asset-agnostic-privacy/). ### What is Anoma? @@ -30,16 +29,16 @@ Anoma is a full-stack architecture designed with a long term perspective, while Privacy should be default and inherent in the systems we use for transacting, yet safe and user-friendly multi-asset privacy doesn't yet exist in the blockchain ecosystem. Up until now, users have had the choice of either a sovereign chain that reissues assets (e.g. [Zcash](https://z.cash/)) -or a privacy preserving solution built on an existing smart contract chain. Both have large trade-offs: in the former case, users don't have assets that they actually want to transact with, and in the latter case, the restrictions of existing platforms mean that users leak (non-trivial) metadata, and the protocols may be expensive and clunky to use. +or a privacy preserving solution built on an existing smart contract chain. Both have large trade-offs: in the former case, users don't have assets that they actually want to transact with, and in the latter case, the restrictions of existing platforms mean that users leak non-trivial metadata, and the protocols may be expensive and clunky to use. Namada supports any fungible or non-fungible asset on an IBC-compatible blockchain as well as fungible or non-fungible assets sent over a custom Ethereum bridge (such as ERC20 tokens and ERC721 tokens, respectively). Once assets are on Namada, shielded transfers are cheap and all assets contribute to the same anonymity set. -Users on Namada earn rewards, retain privacy of assets, and contribute to shared privacy. +Users of Namada earn rewards, retain privacy of assets, and contribute to shared privacy. ### Layout of this specification -The Namada specification documents are organised into four sub-sections: +These documents describe the behaviour of the Namada protocol. This description is organized into five sub-sections: - [Base ledger](./base-ledger.mdx) - [Governance](./governance.mdx) @@ -49,4 +48,4 @@ The Namada specification documents are organised into four sub-sections: This book is written using [NextraJS](https://nextra.site/). The source can be found in the [Namada Docs repository](https://github.com/anoma/namada-docs/tree/master/packages/specs). -Contributions to the contents and the structure of this book should be made via [pull requests](https://github.com/anoma/namada-docs/pulls). +Contributions to the contents and the structure of this book should be made via [pull requests](https://github.com/anoma/namada-docs/pulls). \ No newline at end of file From a9b4e08acf4c61aa8ec94adc8ba15dc8d8e6edd1 Mon Sep 17 00:00:00 2001 From: yito88 <yuji@phact-columba.com> Date: Tue, 13 Feb 2024 21:22:33 +0100 Subject: [PATCH 58/75] add shielding transfer over IBC --- packages/docs/pages/users/ibc.mdx | 50 ++++++++++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/packages/docs/pages/users/ibc.mdx b/packages/docs/pages/users/ibc.mdx index 71a19dee..104982dd 100644 --- a/packages/docs/pages/users/ibc.mdx +++ b/packages/docs/pages/users/ibc.mdx @@ -69,4 +69,52 @@ for example: ```bash copy gaiad tx ibc-transfer transfer transfer channel-0 atest1d9khqw368qcyx3jxxu6njs2yxs6y2sjyxdzy2d338pp5yd35g9zrv334gceng3z9gvmryv2pfdddt4 10ibc/281545A262215A2D7041CE1B518DD4754EC7097A1C937BE9D9AB6F1F11B452DD --from my-cosmos-address --node https://rpc.sentry-01.theta-testnet.polypore.xyz:443 --fees 5000uatom -``` \ No newline at end of file +``` + +## Shielding transfer +Before `namadac ibc-transfer`, you need to generate a proof of the following IBC transfer for the shielding transfer to the destination Namada. The command `namadac ibc-gen-shielded` generates the proof and outputs a file including required data. In this case, Chain B is the destination chain. +```bash copy +namadac --base-dir ${BASE_DIR_B} ibc-gen-shielded \ + --output-folder-path ${OUTPUT_PATH} \ + --target ${payment_addr_b} \ + --token apfel \ + --amount 100 \ + --port-id transfer \ + --channel-id channel-0 \ + --node ${LEDGER_ADDRESS_B} +``` +Then, you can send the token from the source chain by setting the proof in the ICS-20 packet's memo field. The following example is to send tokens from the source Namada (Chain A). The `${memo_path}` should be the file path created by `namadac ibc-gen-shielded` on the destination chain. +```bash copy +namadac --base-dir ${BASE_DIR_A} ibc-transfer \ + --source ${spending_key_a} \ + --receiver ${payment_addr_b} \ + --token apfel \ + --amount 100 \ + --channel-id channel-0 \ + --memo-path ${memo_path} \ + --node ${LEDGER_ADDRESS_A} +``` + +When the source chain is a Cosmos-SDK based chain, the memo should be set as string with `--memo` option. +```bash copy +memo=$(cat ${memo_path}) +gaiad tx ibc-transfer transfer \ + ${CHANNEL_ID} \ + ${RECEIVER_PAYMENT_ADDRESS} \ + ${AMOUNT}${IBC_TOKEN_ADDRESS} \ + --from ${COSMOS_ALIAS} \ + --memo ${memo} \ + --node ${COSMOS_RPC_ENDPOINT} \ + --fees 5000uatom +``` + +You can do unshielding transfers over IBC without generating a proof. +```bash copy +namadac --base-dir ${BASE_DIR_A} ibc-transfer \ + --source ${spending_key_a} \ + --receiver ${RECEIVER_RAW_ADDRESS} \ + --token nam \ + --amount 100 \ + --channel-id channel-0 \ + --node ${LEDGER_ADDRESS_A} +``` From 39399926378f7fc1720bbcfed04d3f5130583a6d Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Wed, 14 Feb 2024 09:46:04 +0000 Subject: [PATCH 59/75] jolly good old english -> America ain't got no US --- packages/specs/pages/base-ledger/multisignature.mdx | 2 +- packages/specs/pages/economics/proof-of-stake.mdx | 2 +- .../specs/pages/economics/proof-of-stake/objects-and-txs.mdx | 4 ++-- packages/specs/pages/index.mdx | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/packages/specs/pages/base-ledger/multisignature.mdx b/packages/specs/pages/base-ledger/multisignature.mdx index 4f4d906e..ebaedfa7 100644 --- a/packages/specs/pages/base-ledger/multisignature.mdx +++ b/packages/specs/pages/base-ledger/multisignature.mdx @@ -61,7 +61,7 @@ Once this transaction is executed, the following storage writes are made in asso - The threshold of the multisignature account - The list of public keys for the signers of the multisignature account -Multisignature accounts can also be initialised at genesis time - in this case, the requisite parameters are kept in the genesis file and written to storage during initialisation. +Multisignature accounts can also be initialized at genesis time - in this case, the requisite parameters are kept in the genesis file and written to storage during initialisation. ## Multisig account init validation diff --git a/packages/specs/pages/economics/proof-of-stake.mdx b/packages/specs/pages/economics/proof-of-stake.mdx index d103fb6d..ad7b9574 100644 --- a/packages/specs/pages/economics/proof-of-stake.mdx +++ b/packages/specs/pages/economics/proof-of-stake.mdx @@ -18,7 +18,7 @@ with the intent of carrying out attacks. Many PoS blockchains rely on the 1/3 By ## Goals of Rewards and Slashing: Liveness and Security * **Security: Delegation and Slashing**: we want to make sure validators are - backed by enough funds to make misbehaviour very expensive. Security is + backed by enough funds to make misbehavior very expensive. Security is achieved by punishing (slashing) if they do. *Slashing* locked funds (stake) intends to disincentivize diverging from correct execution of protocol, which in this case is voting to finalize valid blocks. diff --git a/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx b/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx index 806fd80e..2fe3fea2 100644 --- a/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx +++ b/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx @@ -13,7 +13,7 @@ The data relevant to the PoS system in the ledger's state are epoched. Each data Changes to the epoched data do not take effect immediately. Instead, changes in epoch `n` are queued to take effect in the epoch `n + pipeline_length` for most cases and `n + pipeline_length + unbonding_length + cubic_slash_window_width` for [unbonding](#unbond) actions. Should the same validator's data or same bonds (i.e. with the same identity) be updated more than once in the same epoch, the later update overrides the previously queued-up update. For bonds and unbonds, the token amounts are added up. Once the epoch `n` has ended, the queued-up updates for epoch `n + pipeline_length` are final and the values become immutable. -Additionally, any account may submit evidence for [a slashable misbehaviour](#slashing). +Additionally, any account may submit evidence for [a slashable misbehavior](#slashing). ### Validator @@ -117,7 +117,7 @@ Once an offense has been reported: Instead of absolute values, validators' total bonded token amounts and bonds' and unbonds' token amounts are stored as their deltas (i.e. the change of quantity from a previous epoch) to allow distinguishing changes for different epoch, which is essential for determining whether tokens should be slashed. Slashes for a fault that occurred in epoch `n` may only be applied before the beginning of epoch `n + unbonding_length`. For this reason, in epoch `m` we can sum all the deltas of total bonded token amounts and bonds and unbond with the same source and validator for epoch equal or less than `m - unbonding_length` into a single total bonded token amount, single bond and single unbond record. This is to keep the total number of total bonded token amounts for a unique validator and bonds and unbonds for a unique pair of source and validator bound to a maximum number (equal to `unbonding_length`). -To disincentivize validators misbehaviour in the PoS system a validator may be slashed for any fault that it has done. An evidence of misbehaviour may be submitted by any account for a fault that occurred in epoch `n` anytime before the beginning of epoch `n + unbonding_length`. +To disincentivize validators misbehavior in the PoS system a validator may be slashed for any fault that it has done. An evidence of misbehavior may be submitted by any account for a fault that occurred in epoch `n` anytime before the beginning of epoch `n + unbonding_length`. A valid evidence reduces the validator's total bonded token amount by the slash rate in and before the epoch in which the fault occurred. The validator's voting power must also be adjusted to the slashed total bonded token amount. Additionally, a slash is stored with the misbehaving validator's address and the relevant epoch in which the fault occurred. When an unbond is being withdrawn, we first look-up if any slash occurred within the range of epochs in which these were active and if so, reduce its token amount by the slash rate. Note that bonds and unbonds amounts are not slashed until their tokens are withdrawn. diff --git a/packages/specs/pages/index.mdx b/packages/specs/pages/index.mdx index 7e232e83..767cf15d 100644 --- a/packages/specs/pages/index.mdx +++ b/packages/specs/pages/index.mdx @@ -19,7 +19,7 @@ You can find an introduction to Namada from a product perspective [here](https:/ ### What is Anoma? -Anoma is an intent-centric, privacy-preserving architecture for decentralised counterparty discovery, solving, and settlement. You can find the Anoma specs [here](https://specs.anoma.net). +Anoma is an intent-centric, privacy-preserving architecture for decentralized counterparty discovery, solving, and settlement. You can find the Anoma specs [here](https://specs.anoma.net). ### How does Namada relate to Anoma? @@ -38,7 +38,7 @@ Users of Namada earn rewards, retain privacy of assets, and contribute to shared ### Layout of this specification -These documents describe the behaviour of the Namada protocol. This description is organized into five sub-sections: +These documents describe the behavior of the Namada protocol. This description is organized into five sub-sections: - [Base ledger](./base-ledger.mdx) - [Governance](./governance.mdx) From 30647ee53894b15bd4a01c9ac729e93e91d2ebe9 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Wed, 14 Feb 2024 09:47:47 +0000 Subject: [PATCH 60/75] How are we meant to play scrabble without the z in ize --- .../pages/integrating-with-namada/sdk/generating-accounts.mdx | 2 +- packages/docs/pages/networks/testnets.mdx | 2 +- packages/docs/pages/operators/networks.mdx | 2 +- packages/docs/pages/operators/networks/_meta.json | 2 +- packages/docs/pages/operators/networks/genesis-flow.mdx | 2 +- .../docs/pages/operators/networks/genesis-flow/participants.mdx | 2 +- packages/docs/pages/operators/validators/proof-of-stake.mdx | 2 +- packages/docs/pages/operators/validators/validator-setup.mdx | 2 +- packages/docs/pages/users/transparent-accounts.mdx | 2 +- .../docs/pages/users/transparent-accounts/multisignature.mdx | 2 +- 10 files changed, 10 insertions(+), 10 deletions(-) diff --git a/packages/docs/pages/integrating-with-namada/sdk/generating-accounts.mdx b/packages/docs/pages/integrating-with-namada/sdk/generating-accounts.mdx index 00fef4c8..d1e61be4 100644 --- a/packages/docs/pages/integrating-with-namada/sdk/generating-accounts.mdx +++ b/packages/docs/pages/integrating-with-namada/sdk/generating-accounts.mdx @@ -21,7 +21,7 @@ struct MultisigAccount { } ``` -Multisignature accounts, because they are initialised by an on-chain transaction, will always have their public key revealed to the ledger. However, when keypairs are generated in an offline fashion, the user must submit a transaction in order to reveal their public key. Because of this, it is helpful to add the field `revealed` to the account struct. +Multisignature accounts, because they are initialized by an on-chain transaction, will always have their public key revealed to the ledger. However, when keypairs are generated in an offline fashion, the user must submit a transaction in order to reveal their public key. Because of this, it is helpful to add the field `revealed` to the account struct. ```rust use namada_sdk::core::types::key::common::{PublicKey, SecretKey}; diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index c7eae713..8987630c 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -45,7 +45,7 @@ If you find a bug, please submit an issue with the `bug` [issue template](https: ## Testnet flowchart ![testnet_flowchart](/images/testnet_flowchart.png) -The Namada public testnet is permissionless, anyone can join without the authorisation of a centralised party. Expect frequent upgrades (every two weeks). +The Namada public testnet is permissionless, anyone can join without the authorisation of a centralized party. Expect frequent upgrades (every two weeks). ## Block explorer diff --git a/packages/docs/pages/operators/networks.mdx b/packages/docs/pages/operators/networks.mdx index 2b5710ef..f972c527 100644 --- a/packages/docs/pages/operators/networks.mdx +++ b/packages/docs/pages/operators/networks.mdx @@ -4,5 +4,5 @@ This guide will explore setting up Namada networks. It is broken into the following sections: -* [Decentralised network setup](./networks/genesis-flow.mdx) +* [Decentralized network setup](./networks/genesis-flow.mdx) * [Local network setup](./networks/local-network.mdx) \ No newline at end of file diff --git a/packages/docs/pages/operators/networks/_meta.json b/packages/docs/pages/operators/networks/_meta.json index fb0eb0e9..15295b1d 100644 --- a/packages/docs/pages/operators/networks/_meta.json +++ b/packages/docs/pages/operators/networks/_meta.json @@ -1,4 +1,4 @@ { - "genesis-flow": "Setting up a decentralised network", + "genesis-flow": "Setting up a decentralized network", "local-network": "Setting up a local network" } \ No newline at end of file diff --git a/packages/docs/pages/operators/networks/genesis-flow.mdx b/packages/docs/pages/operators/networks/genesis-flow.mdx index 23901d6b..9b2a9fc2 100644 --- a/packages/docs/pages/operators/networks/genesis-flow.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow.mdx @@ -1,6 +1,6 @@ # Setting up a decentarlised Namada network -Setting up a decentralised Namada network requires coordination between two distinct parties: +Setting up a decentralized Namada network requires coordination between two distinct parties: 1. [The network coordinator](./genesis-flow/coordinator.mdx#the-network-coordinator) 2. [The pre-genesis network participants](./genesis-flow/participants.mdx#pre-genesis-network-participants) diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx index ecdde19b..baf5501a 100644 --- a/packages/docs/pages/operators/networks/genesis-flow/participants.mdx +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.mdx @@ -182,7 +182,7 @@ The optional `--discord-handle` flag is the discord handle of the validator acco The `--address` flag is the Namada address of the account. -The `--path` flag is the path to the `transactions.toml` file that will be appended to, and requires the established account to already be initialised under. +The `--path` flag is the path to the `transactions.toml` file that will be appended to, and requires the established account to already be initialized under. </Callout> diff --git a/packages/docs/pages/operators/validators/proof-of-stake.mdx b/packages/docs/pages/operators/validators/proof-of-stake.mdx index 20138add..7a80656a 100644 --- a/packages/docs/pages/operators/validators/proof-of-stake.mdx +++ b/packages/docs/pages/operators/validators/proof-of-stake.mdx @@ -32,7 +32,7 @@ Validators on Namada are slashed for misbehavior. Automatic slashing conditions ## Jailing -Validators on Namada are jailed for either misbehaviour or for being offline for too long. If a number of blocks pass (also defined in the protocol parameters under `liveness_window_check`) in which none have been signed by the validator in question, the validator is jailed. +Validators on Namada are jailed for either misbehavior or for being offline for too long. If a number of blocks pass (also defined in the protocol parameters under `liveness_window_check`) in which none have been signed by the validator in question, the validator is jailed. When a validator is jailed, they are unable to participate in the consensus protocol. A validator is jailed for at least the pipeline amount of epochs, but must be unjailed manually by the validator. This is done by submitting an `unjail-validator` command. diff --git a/packages/docs/pages/operators/validators/validator-setup.mdx b/packages/docs/pages/operators/validators/validator-setup.mdx index 908fa632..169f0e7a 100644 --- a/packages/docs/pages/operators/validators/validator-setup.mdx +++ b/packages/docs/pages/operators/validators/validator-setup.mdx @@ -18,7 +18,7 @@ The method for setting up a genesis validator is described under the [pre-genesi ## Post-genesis validators -Post-genesis validators are validators that become initialised after the genesis block. This is the most common way of becoming a validator, and is the method described in this section. +Post-genesis validators are validators that become initialized after the genesis block. This is the most common way of becoming a validator, and is the method described in this section. <Callout type="info" emoji="🤡"> Note the use of the placeholder `aliace` for the alias parameter. This is a completely configurable parameter, and should just refer to the alias of the key/address generated. diff --git a/packages/docs/pages/users/transparent-accounts.mdx b/packages/docs/pages/users/transparent-accounts.mdx index 39276a79..b683ad88 100644 --- a/packages/docs/pages/users/transparent-accounts.mdx +++ b/packages/docs/pages/users/transparent-accounts.mdx @@ -6,7 +6,7 @@ All accounts in Namada have a unique address, exactly one Validity Predicate and There are currently 3 types of account addresses: - **Implicit:** An implicit account is derived from your keypair and can be used to authorize certain transactions from the account. Implicit accounts have no code attached to them, and can only have one key controlling it. This differs it from established accounts, which can support multiple keys. -- **Established:** An established account is a associated with one or more cryptographic keys. Each account has the `vp_user` predicate which validate any associated transaction. The main purpose of this code is to ensure that the multisignature threshold is correctly met and stores the keys that verify transactions. All established accounts will be inititalised through on-chain transactions, unlike implicit accounts, which exist as soon as the keypair is generated. +- **Established:** An established account is a associated with one or more cryptographic keys. Each account has the `vp_user` predicate which validate any associated transaction. The main purpose of this code is to ensure that the multisignature threshold is correctly met and stores the keys that verify transactions. All established accounts will be initialized through on-chain transactions, unlike implicit accounts, which exist as soon as the keypair is generated. - **Internal:** Special internal accounts, such as protocol parameters account, PoS and IBC. ## Manage keypairs diff --git a/packages/docs/pages/users/transparent-accounts/multisignature.mdx b/packages/docs/pages/users/transparent-accounts/multisignature.mdx index 43496e87..fc364719 100644 --- a/packages/docs/pages/users/transparent-accounts/multisignature.mdx +++ b/packages/docs/pages/users/transparent-accounts/multisignature.mdx @@ -25,7 +25,7 @@ namadaw gen \ --alias my-key2 ``` -Accounts on Namada are initialised through the following method: +Accounts on Namada are initialized through the following method: **Non-multisig account (single signer)** ```shell From b1714224a41264c3d5c563df770885dfab43a2d7 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Wed, 14 Feb 2024 12:06:46 +0000 Subject: [PATCH 61/75] reorg seaorg --- packages/specs/pages/_meta.json | 5 +---- packages/specs/pages/base-ledger/_meta.json | 4 +--- .../pages/base-ledger/block-space-allocator.mdx | 2 +- packages/specs/pages/base-ledger/execution.mdx | 14 +++++++------- .../{economics => base-ledger}/fee-system.mdx | 2 +- .../specs/pages/base-ledger/replay-protection.mdx | 8 ++++---- .../replay-protection/optimizations.mdx | 6 +++--- packages/specs/pages/economics.mdx | 3 --- packages/specs/pages/economics/_meta.json | 7 ------- packages/specs/pages/index.mdx | 11 ++++------- packages/specs/pages/interoperability.mdx | 5 ----- packages/specs/pages/interoperability/_meta.json | 4 ---- packages/specs/pages/modules.mdx | 11 +++++++++++ packages/specs/pages/modules/_meta.json | 9 +++++++++ .../ethereum-bridge.mdx | 0 .../ethereum-bridge/_meta.json | 0 .../ethereum-bridge/bootstrapping.mdx | 0 .../ethereum_events_attestation.mdx | 4 ++-- .../ethereum-bridge/ethereum_smart_contracts.mdx | 0 .../ethereum-bridge/proofs.mdx | 0 .../ethereum-bridge/security.mdx | 0 .../ethereum-bridge/transfers_to_ethereum.mdx | 0 .../ethereum-bridge/transfers_to_namada.mdx | 4 ++-- packages/specs/pages/{ => modules}/governance.mdx | 2 +- .../pages/{ => modules}/governance/_meta.json | 0 .../pages/{ => modules}/governance/off-chain.mdx | 0 .../pages/{ => modules}/governance/on-chain.mdx | 2 +- .../pages/{ => modules}/governance/proposal.mdx | 0 .../governance}/public-goods-funding.mdx | 2 ++ .../governance}/public-goods-funding/_meta.json | 0 .../public-goods-funding/becoming-a-steward.mdx | 2 +- .../governance}/public-goods-funding/electing.mdx | 0 .../governance}/public-goods-funding/funding.mdx | 0 .../public-goods-funding/incentives.mdx | 0 .../public-goods-stewards.mdx | 0 .../governance}/public-goods-funding/storage.mdx | 0 .../pages/{ => modules}/governance/storage.mdx | 2 +- .../pages/{interoperability => modules}/ibc.mdx | 0 .../{economics => modules}/images/cubic_slash.png | Bin .../{economics => modules}/images/inflation.png | Bin .../{economics => modules}/images/inflation.svg | 0 .../{economics => modules}/images/locking.png | Bin .../{economics => modules}/images/locking.svg | 0 packages/specs/pages/{ => modules}/masp.mdx | 2 +- .../specs/pages/{ => modules}/masp/_meta.json | 0 .../specs/pages/{ => modules}/masp/asset-type.mdx | 0 .../pages/{ => modules}/masp/burn-and-mint.mdx | 0 .../pages/{ => modules}/masp/convert-circuit.mdx | 2 +- .../{ => modules}/masp/ledger-integration.mdx | 0 .../masp}/shielded-pool-incentives.mdx | 4 +++- .../pages/{ => modules}/masp/trusted-setup.mdx | 0 .../{base-ledger => modules}/multisignature.mdx | 0 .../fungible-token.mdx => modules/multitoken.mdx} | 2 +- .../{economics => modules}/proof-of-stake.mdx | 0 .../proof-of-stake/_meta.json | 0 .../proof-of-stake/cubic-slashing.mdx | 0 .../proof-of-stake}/inflation-system.mdx | 8 ++------ .../proof-of-stake/objects-and-txs.mdx | 2 +- .../proof-of-stake/reward-distribution.mdx | 2 +- 59 files changed, 62 insertions(+), 69 deletions(-) rename packages/specs/pages/{economics => base-ledger}/fee-system.mdx (99%) delete mode 100644 packages/specs/pages/economics.mdx delete mode 100644 packages/specs/pages/economics/_meta.json delete mode 100644 packages/specs/pages/interoperability.mdx delete mode 100644 packages/specs/pages/interoperability/_meta.json create mode 100644 packages/specs/pages/modules.mdx create mode 100644 packages/specs/pages/modules/_meta.json rename packages/specs/pages/{interoperability => modules}/ethereum-bridge.mdx (100%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/_meta.json (100%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/bootstrapping.mdx (100%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/ethereum_events_attestation.mdx (98%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/ethereum_smart_contracts.mdx (100%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/proofs.mdx (100%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/security.mdx (100%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/transfers_to_ethereum.mdx (100%) rename packages/specs/pages/{interoperability => modules}/ethereum-bridge/transfers_to_namada.mdx (93%) rename packages/specs/pages/{ => modules}/governance.mdx (98%) rename packages/specs/pages/{ => modules}/governance/_meta.json (100%) rename packages/specs/pages/{ => modules}/governance/off-chain.mdx (100%) rename packages/specs/pages/{ => modules}/governance/on-chain.mdx (99%) rename packages/specs/pages/{ => modules}/governance/proposal.mdx (100%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding.mdx (98%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding/_meta.json (100%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding/becoming-a-steward.mdx (98%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding/electing.mdx (100%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding/funding.mdx (100%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding/incentives.mdx (100%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding/public-goods-stewards.mdx (100%) rename packages/specs/pages/{economics => modules/governance}/public-goods-funding/storage.mdx (100%) rename packages/specs/pages/{ => modules}/governance/storage.mdx (96%) rename packages/specs/pages/{interoperability => modules}/ibc.mdx (100%) rename packages/specs/pages/{economics => modules}/images/cubic_slash.png (100%) rename packages/specs/pages/{economics => modules}/images/inflation.png (100%) rename packages/specs/pages/{economics => modules}/images/inflation.svg (100%) rename packages/specs/pages/{economics => modules}/images/locking.png (100%) rename packages/specs/pages/{economics => modules}/images/locking.svg (100%) rename packages/specs/pages/{ => modules}/masp.mdx (87%) rename packages/specs/pages/{ => modules}/masp/_meta.json (100%) rename packages/specs/pages/{ => modules}/masp/asset-type.mdx (100%) rename packages/specs/pages/{ => modules}/masp/burn-and-mint.mdx (100%) rename packages/specs/pages/{ => modules}/masp/convert-circuit.mdx (99%) rename packages/specs/pages/{ => modules}/masp/ledger-integration.mdx (100%) rename packages/specs/pages/{economics => modules/masp}/shielded-pool-incentives.mdx (88%) rename packages/specs/pages/{ => modules}/masp/trusted-setup.mdx (100%) rename packages/specs/pages/{base-ledger => modules}/multisignature.mdx (100%) rename packages/specs/pages/{base-ledger/fungible-token.mdx => modules/multitoken.mdx} (96%) rename packages/specs/pages/{economics => modules}/proof-of-stake.mdx (100%) rename packages/specs/pages/{economics => modules}/proof-of-stake/_meta.json (100%) rename packages/specs/pages/{economics => modules}/proof-of-stake/cubic-slashing.mdx (100%) rename packages/specs/pages/{economics => modules/proof-of-stake}/inflation-system.mdx (94%) rename packages/specs/pages/{economics => modules}/proof-of-stake/objects-and-txs.mdx (98%) rename packages/specs/pages/{economics => modules}/proof-of-stake/reward-distribution.mdx (96%) diff --git a/packages/specs/pages/_meta.json b/packages/specs/pages/_meta.json index e38846c0..10c18567 100644 --- a/packages/specs/pages/_meta.json +++ b/packages/specs/pages/_meta.json @@ -1,9 +1,6 @@ { "index": "Introduction", "base-ledger": "Base ledger", - "governance": "Governance", - "masp": "Multi-asset shielded pool", - "interoperability": "Interoperability", - "economics": "Economics", + "mdoules": "Modules", "further-reading": "Further reading" } diff --git a/packages/specs/pages/base-ledger/_meta.json b/packages/specs/pages/base-ledger/_meta.json index b580de95..d419ed6a 100644 --- a/packages/specs/pages/base-ledger/_meta.json +++ b/packages/specs/pages/base-ledger/_meta.json @@ -1,8 +1,6 @@ { "consensus": "Consensus", - "execution": "Execution", - "multisignature": "Multisignature", - "fungible-token": "Fungible token", + "execution": "Execution model", "replay-protection": "Replay protection", "block-space-allocator": "Block space allocator" } diff --git a/packages/specs/pages/base-ledger/block-space-allocator.mdx b/packages/specs/pages/base-ledger/block-space-allocator.mdx index eaa8ce4d..2582148d 100644 --- a/packages/specs/pages/base-ledger/block-space-allocator.mdx +++ b/packages/specs/pages/base-ledger/block-space-allocator.mdx @@ -200,7 +200,7 @@ signatures on a single validator set update. "Chunks" of a proof (i.e. individual votes) are decided and batched together, until a complete proof is constructed. -Validator set updates are covered in more detail in [the Ethereum bridge section](../interoperability/ethereum-bridge.mdx). +Validator set updates are covered in more detail in [the Ethereum bridge section](../modules/ethereum-bridge.mdx). ## Governance diff --git a/packages/specs/pages/base-ledger/execution.mdx b/packages/specs/pages/base-ledger/execution.mdx index c0c13fdd..5f8c64fb 100644 --- a/packages/specs/pages/base-ledger/execution.mdx +++ b/packages/specs/pages/base-ledger/execution.mdx @@ -33,12 +33,12 @@ There are some native VPs for internal transparent addresses that are built into {/* TODO: Make sure this is up to date with the ledger */} Supported validity predicates for Namada: - Native - - Proof-of-stake (see [spec](../economics/proof-of-stake.mdx)) - - Ethereum bridge (see [spec](../interoperability/ethereum-bridge.mdx)) - - IBC & IbcToken (see [spec](../interoperability/ibc.mdx)) - - Governance (see [spec](../governance.mdx)) + - Proof-of-stake (see [spec](../modules/proof-of-stake.mdx)) + - Ethereum bridge (see [spec](../modules/ethereum-bridge.mdx)) + - IBC & IbcToken (see [spec](../modules/ibc.mdx)) + - Governance (see [spec](../modules/governance.mdx)) - Protocol parameters (part of governance) - - Multitoken (see [spec](./fungible-token.mdx)) + - Multitoken (see [spec](../modules/multitoken.mdx)) - WASM - - MASP (see [spec](../masp.mdx)) - - k-of-n multisignature (see [spec](./multisignature.mdx)) + - MASP (see [spec](../modules/masp.mdx)) + - k-of-n multisignature (see [spec](../modules/multisignature.mdx)) diff --git a/packages/specs/pages/economics/fee-system.mdx b/packages/specs/pages/base-ledger/fee-system.mdx similarity index 99% rename from packages/specs/pages/economics/fee-system.mdx rename to packages/specs/pages/base-ledger/fee-system.mdx index f06ec5e9..c2f757d8 100644 --- a/packages/specs/pages/economics/fee-system.mdx +++ b/packages/specs/pages/base-ledger/fee-system.mdx @@ -229,7 +229,7 @@ transactions involving the same addresses. ### Governance proposals -Governance [proposals](../base-ledger/governance.mdx) may carry some wasm code to +Governance [proposals](../modules/governance.mdx) may carry some wasm code to be executed in case the proposal passed. This code is embedded into a `DecryptedTx` directly by the validators at block processing time and is not inserted into the block itself. These transactions are exempt from fees and diff --git a/packages/specs/pages/base-ledger/replay-protection.mdx b/packages/specs/pages/base-ledger/replay-protection.mdx index ace8f53a..6e0ce2e9 100644 --- a/packages/specs/pages/base-ledger/replay-protection.mdx +++ b/packages/specs/pages/base-ledger/replay-protection.mdx @@ -67,7 +67,7 @@ pub struct Tx { ``` The wrapper transaction is composed of some metadata, an optional unshielding tx -for fee payment (see [fee specs](../economics/fee-system.mdx)), the encrypted +for fee payment (see [fee specs](./fee-system.mdx)), the encrypted inner transaction itself and the hash of the concatenation of these values. {/* TODO: Ensure that the hash of concatenation statement is as accurate as possible. It could be values, it could be the object (which consists of keys + values)*/} The inner `Tx` transaction carries the Wasm code to be executed and the associated data. @@ -123,7 +123,7 @@ semantics of the state transition. This inner transaction must be protected from `WrapperTx` is the only type of transaction currently accepted by the ledger. It must be protected from replay attacks; otherwise, a malicious user could replay the transaction as is. Even if the inner transaction implemented replay protection or was not accepted for any reason, the signer of the wrapper would still incur gas and fees, resulting in economic damage. To prevent the replay of both these transactions, reliance is placed on a set of digests from already processed transactions that are kept in storage. These digests are computed on the **unsigned** transactions, to support replay -protection even for [multisigned](multisignature.mdx) transactions. In this case, using hashes from the signed transactions would result in a different hash for a different set of signatures on the same transaction, allowing for a replay. To achieve this, the `WrapperTx` hash field contains the hash of the unsigned inner transaction, instead of the signed one. This change does not impact the overall safety of Namada, as the wrapper is still signed over all its bytes, including the inner signature. The modification also allows for early replay attack checks in the mempool and during wrapper block-inclusion. +protection even for [multisigned](../modules/multisignature.mdx) transactions. In this case, using hashes from the signed transactions would result in a different hash for a different set of signatures on the same transaction, allowing for a replay. To achieve this, the `WrapperTx` hash field contains the hash of the unsigned inner transaction, instead of the signed one. This change does not impact the overall safety of Namada, as the wrapper is still signed over all its bytes, including the inner signature. The modification also allows for early replay attack checks in the mempool and during wrapper block-inclusion. In addition, a subspace in storage is required, headed by a `ReplayProtection` internal address: ``` bash @@ -178,7 +178,7 @@ the attack explained in this section is performed: #### Governance proposals -Governance [proposals](../base-ledger/governance.mdx) may carry some wasm code to +Governance [proposals](../modules/governance.mdx) may carry some wasm code to be executed in case the proposal passed. This code is embedded into a `DecryptedTx` directly by the validators at block processing time and is not inserted into the block itself. @@ -264,7 +264,7 @@ In mempool_validation, several checks are performed on the wrapper transaction t - Unshielding transaction (if present) releases the minimum required tokens for fee payment - Successful execution of the unshielding transaction (if present) -More details about gas, fees, and the unshielding transaction can be found in the [fee specs](../economics/fee-system.mdx). +More details about gas, fees, and the unshielding transaction can be found in the [fee specs](./fee-system.mdx). These checks can all be conducted before executing the transactions themselves. If any of these checks fail, the transaction is considered invalid, and the appropriate action is taken: diff --git a/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx b/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx index fe97287f..c4f751a4 100644 --- a/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx +++ b/packages/specs/pages/base-ledger/replay-protection/optimizations.mdx @@ -69,7 +69,7 @@ these conditions doesn't hold the VP will discard the transactions and prevent the changes from being applied to the storage. In the specific case of a shielded transfer, since MASP already comes with -replay protection as part of the Zcash design (see the [MASP specs](../masp.mdx) +replay protection as part of the Zcash design (see the [MASP specs](../../modules/masp.mdx) and [Zcash protocol specs](https://zips.z.cash/protocol/protocol.pdf)), the counter in `SignedTxData` is not required and therefore should be optional. @@ -486,9 +486,9 @@ validate it. These will involve: - Valid signature - `GasLimit` is below the block gas limit (see the - [fee specs](../economics/fee-system.mdx) for more details) + [fee specs](../fee-system.mdx) for more details) - `Fees` are paid with an accepted token and match the minimum amount required - (see the [fee specs](../economics/fee-system.mdx) for more details) + (see the [fee specs](../fee-system.mdx) for more details) - Valid chainId - Valid transaction counter - Valid expiration diff --git a/packages/specs/pages/economics.mdx b/packages/specs/pages/economics.mdx deleted file mode 100644 index 747372a8..00000000 --- a/packages/specs/pages/economics.mdx +++ /dev/null @@ -1,3 +0,0 @@ -## Economics - -Namada users pay transaction fees in NAM and other tokens (see [fee system](./economics/fee-system.mdx) and [governance](./governance.mdx)), so demand for NAM can be expected to track demand for block space. On the supply side, the protocol mints NAM at a variable but capped per-annum rate based on a fraction of the current supply (see [inflation system](./economics/inflation-system.mdx)), which is directed to three areas of protocol subsidy: [proof-of-stake](./economics/proof-of-stake.mdx), [shielded pool incentives](./economics/shielded-pool-incentives.mdx), and [public-goods funding](./economics/public-goods-funding.mdx). Inflation rates for these three areas are adjusted independently (the first two on PD controllers and the third based on funding decisions) and excess tokens are slowly burned. \ No newline at end of file diff --git a/packages/specs/pages/economics/_meta.json b/packages/specs/pages/economics/_meta.json deleted file mode 100644 index c7231aad..00000000 --- a/packages/specs/pages/economics/_meta.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "fee-system": "Fee system", - "inflation-system": "Inflation system", - "proof-of-stake": "Proof-of-stake", - "shielded-pool-incentives": "Shielded pool incentives", - "public-goods-funding": "Public goods funding" -} diff --git a/packages/specs/pages/index.mdx b/packages/specs/pages/index.mdx index 767cf15d..6e35809b 100644 --- a/packages/specs/pages/index.mdx +++ b/packages/specs/pages/index.mdx @@ -9,9 +9,9 @@ import { SpecsAscii } from '../components/SpecsAscii' Namada is a sovereign proof-of-stake layer-one blockchain, using the [CometBFT](https://cometbft.com/) (nee Tendermint) BFT consensus algorithm. Namada enables multi-asset private transfers for any native or non-native asset using a [multi-asset shielded pool](https://research.metastate.dev/multi-asset_shielded_pool/) derived from the [Sapling circuit](https://z.cash/upgrade/sapling/). -Namada features full IBC protocol support, a natively integrated [Ethereum bridge](./interoperability.mdx), a modern [proof-of-stake system](./economics/proof-of-stake.mdx) with cubic slashing, a [stake-weighted governance signalling mechanism](./governance.mdx), and a dual continuous/retroactive [public goods funding system](./economics/public-goods-funding.mdx). +Namada features full IBC protocol support, a natively integrated [Ethereum bridge](./modules/ethereum-bridge.mdx), a modern [proof-of-stake system](./modules/proof-of-stake.mdx) with cubic slashing, a [stake-weighted governance signalling mechanism](./modules/governance.mdx), and a dual continuous/retroactive [public goods funding system](./modules/governance/public-goods-funding.mdx). -Users of the MASP are [rewarded](./economics/shielded-pool-incentives.mdx) for their contributions to the privacy set in the form of native protocol tokens (NAM). +Users of the MASP are [rewarded](./modules/masp/shielded-pool-incentives.mdx) for their contributions to the privacy set in the form of native protocol tokens (NAM). Namada also supports shielded actions, which allow users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains. @@ -40,11 +40,8 @@ Users of Namada earn rewards, retain privacy of assets, and contribute to shared These documents describe the behavior of the Namada protocol. This description is organized into five sub-sections: -- [Base ledger](./base-ledger.mdx) -- [Governance](./governance.mdx) -- [Multi-asset shielded pool](./masp.mdx) -- [Interoperability](./interoperability.mdx) -- [Economics](./economics.mdx) +1. [Base Ledger](./base-ledger.mdx): This section describes the core ledger functionality of the Namada protocol. This includes the basic data structures and state transitions that make up the Namada blockchain. +2. [Modules](./modules.mdx): This section describes the modules that make up the Namada protocol. Each module is a distinct part of the protocol that can be understood in isolation. This book is written using [NextraJS](https://nextra.site/). The source can be found in the [Namada Docs repository](https://github.com/anoma/namada-docs/tree/master/packages/specs). diff --git a/packages/specs/pages/interoperability.mdx b/packages/specs/pages/interoperability.mdx deleted file mode 100644 index 7f49d708..00000000 --- a/packages/specs/pages/interoperability.mdx +++ /dev/null @@ -1,5 +0,0 @@ -## Interoperability - -Namada is designed for trust-minimized interoperation with both the Ethereum and Cosmos ecosystems: -- To the Ethereum ecosystem (Ethereum main chain and any rollups bridged to it), Namada connects using a bespoke [Ethereum bridge](./interoperability/ethereum-bridge.mdx) operated by the Namada validator set. -- To the Cosmos ecosystem (any chain which supports IBC), Namada connects using an [integration of the IBC protocol](./interoperability/ibc.mdx). \ No newline at end of file diff --git a/packages/specs/pages/interoperability/_meta.json b/packages/specs/pages/interoperability/_meta.json deleted file mode 100644 index f4c9e53f..00000000 --- a/packages/specs/pages/interoperability/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "ethereum-bridge": "Ethereum Bridge", - "ibc": "IBC" -} diff --git a/packages/specs/pages/modules.mdx b/packages/specs/pages/modules.mdx new file mode 100644 index 00000000..f0e1d914 --- /dev/null +++ b/packages/specs/pages/modules.mdx @@ -0,0 +1,11 @@ +# Modules + +The validity predicates define the modules of Namada. These modules are: + +- Multitoken +- Multisignature +- Proof-of-stake +- Multi-asset-shielded-pool (MASP) +- Governance +- IBC +- Ethereum bridge \ No newline at end of file diff --git a/packages/specs/pages/modules/_meta.json b/packages/specs/pages/modules/_meta.json new file mode 100644 index 00000000..e092dee0 --- /dev/null +++ b/packages/specs/pages/modules/_meta.json @@ -0,0 +1,9 @@ +{ + "multitoken": "Multitoken", + "multisignature": "Multisignature", + "proof-of-stake": "Proof-of-stake", + "masp": "Multi-asset-shielded-pool (MASP)", + "governance": "Governance", + "ethereum-bridge": "Ethereum Bridge", + "ibc": "IBC" +} \ No newline at end of file diff --git a/packages/specs/pages/interoperability/ethereum-bridge.mdx b/packages/specs/pages/modules/ethereum-bridge.mdx similarity index 100% rename from packages/specs/pages/interoperability/ethereum-bridge.mdx rename to packages/specs/pages/modules/ethereum-bridge.mdx diff --git a/packages/specs/pages/interoperability/ethereum-bridge/_meta.json b/packages/specs/pages/modules/ethereum-bridge/_meta.json similarity index 100% rename from packages/specs/pages/interoperability/ethereum-bridge/_meta.json rename to packages/specs/pages/modules/ethereum-bridge/_meta.json diff --git a/packages/specs/pages/interoperability/ethereum-bridge/bootstrapping.mdx b/packages/specs/pages/modules/ethereum-bridge/bootstrapping.mdx similarity index 100% rename from packages/specs/pages/interoperability/ethereum-bridge/bootstrapping.mdx rename to packages/specs/pages/modules/ethereum-bridge/bootstrapping.mdx diff --git a/packages/specs/pages/interoperability/ethereum-bridge/ethereum_events_attestation.mdx b/packages/specs/pages/modules/ethereum-bridge/ethereum_events_attestation.mdx similarity index 98% rename from packages/specs/pages/interoperability/ethereum-bridge/ethereum_events_attestation.mdx rename to packages/specs/pages/modules/ethereum-bridge/ethereum_events_attestation.mdx index bf5b3896..97898e76 100644 --- a/packages/specs/pages/interoperability/ethereum-bridge/ethereum_events_attestation.mdx +++ b/packages/specs/pages/modules/ethereum-bridge/ethereum_events_attestation.mdx @@ -38,7 +38,7 @@ and events are timed out if they are not `seen` within the span of `unbonding_length` epochs, which corresponds to the period of time necessary for bonded tokens to be returned to an address (check the [relevant proof-of-stake -section](../../economics/proof-of-stake/reward-distribution.md) for more +section](../proof-of-stake/reward-distribution.mdx) for more details). Timing out an event consists of removing all its associated state from storage. Therefore, this mechanism serves another purpose: purging forged events from storage, voted on by Byzantine validators. @@ -80,7 +80,7 @@ Namada validators perform votes on other kinds of data, namely: contracts of the bridge. 2) Bridge pool root vote extensions. These vote extensions are used to reach a quorum decision on the most recent root and nonce of the - [Ethereum bridge pool](./transfers_to_ethereum.md). + [Ethereum bridge pool](./transfers_to_ethereum.mdx). These protocol transactions are only ever included on-chain if the Tendermint version that is being used to run the ledger does not include diff --git a/packages/specs/pages/interoperability/ethereum-bridge/ethereum_smart_contracts.mdx b/packages/specs/pages/modules/ethereum-bridge/ethereum_smart_contracts.mdx similarity index 100% rename from packages/specs/pages/interoperability/ethereum-bridge/ethereum_smart_contracts.mdx rename to packages/specs/pages/modules/ethereum-bridge/ethereum_smart_contracts.mdx diff --git a/packages/specs/pages/interoperability/ethereum-bridge/proofs.mdx b/packages/specs/pages/modules/ethereum-bridge/proofs.mdx similarity index 100% rename from packages/specs/pages/interoperability/ethereum-bridge/proofs.mdx rename to packages/specs/pages/modules/ethereum-bridge/proofs.mdx diff --git a/packages/specs/pages/interoperability/ethereum-bridge/security.mdx b/packages/specs/pages/modules/ethereum-bridge/security.mdx similarity index 100% rename from packages/specs/pages/interoperability/ethereum-bridge/security.mdx rename to packages/specs/pages/modules/ethereum-bridge/security.mdx diff --git a/packages/specs/pages/interoperability/ethereum-bridge/transfers_to_ethereum.mdx b/packages/specs/pages/modules/ethereum-bridge/transfers_to_ethereum.mdx similarity index 100% rename from packages/specs/pages/interoperability/ethereum-bridge/transfers_to_ethereum.mdx rename to packages/specs/pages/modules/ethereum-bridge/transfers_to_ethereum.mdx diff --git a/packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx b/packages/specs/pages/modules/ethereum-bridge/transfers_to_namada.mdx similarity index 93% rename from packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx rename to packages/specs/pages/modules/ethereum-bridge/transfers_to_namada.mdx index 6effc2a2..19bf4f88 100644 --- a/packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx +++ b/packages/specs/pages/modules/ethereum-bridge/transfers_to_namada.mdx @@ -3,9 +3,9 @@ In order to facilitate transferring assets from Ethereum to Namada, there will be two internal accounts with associated native validity predicates: -- `#EthBridge` - Controls the `/eth_msgs/` [storage](ethereum_events_attestation.md#storage) +- `#EthBridge` - Controls the `/eth_msgs/` [storage](./ethereum_events_attestation.mdx#storage) and ledger of balances of minted wrapped Ethereum assets (ERC20 tokens) structured in a - ["multitoken"](../../base-ledger/fungible-token.html#multitoken) hierarchy. + ["multitoken"](../multitoken.mdx#multitoken) hierarchy. Also contains in escrow Namada tokens which have been sent to Ethereum, pertaining to pending wNAM transfers. - `#EthBridgePool` - Holds gas fees to be paid to relayers of transfers to Ethereum, diff --git a/packages/specs/pages/governance.mdx b/packages/specs/pages/modules/governance.mdx similarity index 98% rename from packages/specs/pages/governance.mdx rename to packages/specs/pages/modules/governance.mdx index 592435fa..4d66c62c 100644 --- a/packages/specs/pages/governance.mdx +++ b/packages/specs/pages/modules/governance.mdx @@ -46,7 +46,7 @@ It is also possible to attach some payloads to proposals, in specific cases, to Governance on Namada supports both `signaling` and `voting` mechanisms. The signaling mechanism is used for changes which require a hard fork, while the voting mechanism is used for changes which merely alter state. In cases where the chain is not able to produce blocks anymore, Namada relies on [off-chain signaling](#off-chain-protocol) to agree on a common move. -Further information about delegators, validators, and NAM can be found in the [economics section](../economics.mdx). +Further information about delegators, validators, and NAM can be found in the [proof-of-stake section](./proof-of-stake.mdx). ## Outline diff --git a/packages/specs/pages/governance/_meta.json b/packages/specs/pages/modules/governance/_meta.json similarity index 100% rename from packages/specs/pages/governance/_meta.json rename to packages/specs/pages/modules/governance/_meta.json diff --git a/packages/specs/pages/governance/off-chain.mdx b/packages/specs/pages/modules/governance/off-chain.mdx similarity index 100% rename from packages/specs/pages/governance/off-chain.mdx rename to packages/specs/pages/modules/governance/off-chain.mdx diff --git a/packages/specs/pages/governance/on-chain.mdx b/packages/specs/pages/modules/governance/on-chain.mdx similarity index 99% rename from packages/specs/pages/governance/on-chain.mdx rename to packages/specs/pages/modules/governance/on-chain.mdx index 39b796ce..9e1af746 100644 --- a/packages/specs/pages/governance/on-chain.mdx +++ b/packages/specs/pages/modules/governance/on-chain.mdx @@ -131,7 +131,7 @@ Tallying is computed with the following rules: 9. Add voting power for any delegation that voted `Nay` (whose corresponding delegate didn't vote `Nay`) to `SumNay` 9. Add voting power for any delegation that voted `Abstain` (whose corresponding delegate didn't vote `Abstain`) to `SumAbstain` 10. Set `SumYeaOrNay` to `SumYay` + `SumNay` -11. Decide whether or not the proposal succeeds based on the proposal-type-specific tally instructions (see [Proposal](./proposal.md)) +11. Decide whether or not the proposal succeeds based on the proposal-type-specific tally instructions (see [Proposal](./proposal.mdx)) </Steps> diff --git a/packages/specs/pages/governance/proposal.mdx b/packages/specs/pages/modules/governance/proposal.mdx similarity index 100% rename from packages/specs/pages/governance/proposal.mdx rename to packages/specs/pages/modules/governance/proposal.mdx diff --git a/packages/specs/pages/economics/public-goods-funding.mdx b/packages/specs/pages/modules/governance/public-goods-funding.mdx similarity index 98% rename from packages/specs/pages/economics/public-goods-funding.mdx rename to packages/specs/pages/modules/governance/public-goods-funding.mdx index 62a75533..5422eb10 100644 --- a/packages/specs/pages/economics/public-goods-funding.mdx +++ b/packages/specs/pages/modules/governance/public-goods-funding.mdx @@ -2,6 +2,8 @@ import { Callout } from 'nextra-theme-docs' # Public Goods Funding +Namada provides 10% per annum inflation for other non-algorithmically-measurable public goods. + ## Motivation **Public goods** are non-excludable non-rivalrous items which provide benefits of some sort to their users. diff --git a/packages/specs/pages/economics/public-goods-funding/_meta.json b/packages/specs/pages/modules/governance/public-goods-funding/_meta.json similarity index 100% rename from packages/specs/pages/economics/public-goods-funding/_meta.json rename to packages/specs/pages/modules/governance/public-goods-funding/_meta.json diff --git a/packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx b/packages/specs/pages/modules/governance/public-goods-funding/becoming-a-steward.mdx similarity index 98% rename from packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx rename to packages/specs/pages/modules/governance/public-goods-funding/becoming-a-steward.mdx index b8622c90..35dab7d9 100644 --- a/packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx +++ b/packages/specs/pages/modules/governance/public-goods-funding/becoming-a-steward.mdx @@ -16,7 +16,7 @@ Nominating oneself as a PGF steward may be done at any time. Before a new PGF steward can either be elected or removed, a governance proposal that specifies this objective must pass. The voting on this proposal is handled by the governance proposal type `StewardProposal`, which is a custom proposal type. -The struct of `StewardProposal` is constructed as follows, and is explained in more detail in the [governance specs](../base-ledger/governance.mdx) +The struct of `StewardProposal` is constructed as follows, and is explained in more detail in the [governance specs](../../governance.mdx) ```rust struct StewardProposal{ diff --git a/packages/specs/pages/economics/public-goods-funding/electing.mdx b/packages/specs/pages/modules/governance/public-goods-funding/electing.mdx similarity index 100% rename from packages/specs/pages/economics/public-goods-funding/electing.mdx rename to packages/specs/pages/modules/governance/public-goods-funding/electing.mdx diff --git a/packages/specs/pages/economics/public-goods-funding/funding.mdx b/packages/specs/pages/modules/governance/public-goods-funding/funding.mdx similarity index 100% rename from packages/specs/pages/economics/public-goods-funding/funding.mdx rename to packages/specs/pages/modules/governance/public-goods-funding/funding.mdx diff --git a/packages/specs/pages/economics/public-goods-funding/incentives.mdx b/packages/specs/pages/modules/governance/public-goods-funding/incentives.mdx similarity index 100% rename from packages/specs/pages/economics/public-goods-funding/incentives.mdx rename to packages/specs/pages/modules/governance/public-goods-funding/incentives.mdx diff --git a/packages/specs/pages/economics/public-goods-funding/public-goods-stewards.mdx b/packages/specs/pages/modules/governance/public-goods-funding/public-goods-stewards.mdx similarity index 100% rename from packages/specs/pages/economics/public-goods-funding/public-goods-stewards.mdx rename to packages/specs/pages/modules/governance/public-goods-funding/public-goods-stewards.mdx diff --git a/packages/specs/pages/economics/public-goods-funding/storage.mdx b/packages/specs/pages/modules/governance/public-goods-funding/storage.mdx similarity index 100% rename from packages/specs/pages/economics/public-goods-funding/storage.mdx rename to packages/specs/pages/modules/governance/public-goods-funding/storage.mdx diff --git a/packages/specs/pages/governance/storage.mdx b/packages/specs/pages/modules/governance/storage.mdx similarity index 96% rename from packages/specs/pages/governance/storage.mdx rename to packages/specs/pages/modules/governance/storage.mdx index bbe24d37..726965a6 100644 --- a/packages/specs/pages/governance/storage.mdx +++ b/packages/specs/pages/modules/governance/storage.mdx @@ -26,7 +26,7 @@ Each proposal is stored in a sub-key under the internal proposal address. The st An **epoch** is a range of blocks or time that is defined by the base ledger and made available to the PoS system. This document assumes that epochs are identified by consecutive natural numbers. -All the data relevant to PoS are [associated with epochs](../economics/proof-of-stake/objects-and-txs.mdx#epoched-data). +All the data relevant to PoS are [associated with epochs](../proof-of-stake/objects-and-txs.mdx#epoched-data). </Callout> `/$GovernanceAddress/proposal/$epoch/$id` is used for efficient iteration over proposals by epoch. diff --git a/packages/specs/pages/interoperability/ibc.mdx b/packages/specs/pages/modules/ibc.mdx similarity index 100% rename from packages/specs/pages/interoperability/ibc.mdx rename to packages/specs/pages/modules/ibc.mdx diff --git a/packages/specs/pages/economics/images/cubic_slash.png b/packages/specs/pages/modules/images/cubic_slash.png similarity index 100% rename from packages/specs/pages/economics/images/cubic_slash.png rename to packages/specs/pages/modules/images/cubic_slash.png diff --git a/packages/specs/pages/economics/images/inflation.png b/packages/specs/pages/modules/images/inflation.png similarity index 100% rename from packages/specs/pages/economics/images/inflation.png rename to packages/specs/pages/modules/images/inflation.png diff --git a/packages/specs/pages/economics/images/inflation.svg b/packages/specs/pages/modules/images/inflation.svg similarity index 100% rename from packages/specs/pages/economics/images/inflation.svg rename to packages/specs/pages/modules/images/inflation.svg diff --git a/packages/specs/pages/economics/images/locking.png b/packages/specs/pages/modules/images/locking.png similarity index 100% rename from packages/specs/pages/economics/images/locking.png rename to packages/specs/pages/modules/images/locking.png diff --git a/packages/specs/pages/economics/images/locking.svg b/packages/specs/pages/modules/images/locking.svg similarity index 100% rename from packages/specs/pages/economics/images/locking.svg rename to packages/specs/pages/modules/images/locking.svg diff --git a/packages/specs/pages/masp.mdx b/packages/specs/pages/modules/masp.mdx similarity index 87% rename from packages/specs/pages/masp.mdx rename to packages/specs/pages/modules/masp.mdx index 289263f6..d62c1a52 100644 --- a/packages/specs/pages/masp.mdx +++ b/packages/specs/pages/modules/masp.mdx @@ -8,4 +8,4 @@ See the following documents: - [Asset type schema](./masp/asset-type.mdx) - [Burn and mint](./masp/burn-and-mint.mdx) - [Convert circuit](./masp/convert-circuit.mdx) -- [Shielded pool incentives](./economics/shielded-pool-incentives.mdx) \ No newline at end of file +- [Shielded pool incentives](./masp/shielded-pool-incentives.mdx) \ No newline at end of file diff --git a/packages/specs/pages/masp/_meta.json b/packages/specs/pages/modules/masp/_meta.json similarity index 100% rename from packages/specs/pages/masp/_meta.json rename to packages/specs/pages/modules/masp/_meta.json diff --git a/packages/specs/pages/masp/asset-type.mdx b/packages/specs/pages/modules/masp/asset-type.mdx similarity index 100% rename from packages/specs/pages/masp/asset-type.mdx rename to packages/specs/pages/modules/masp/asset-type.mdx diff --git a/packages/specs/pages/masp/burn-and-mint.mdx b/packages/specs/pages/modules/masp/burn-and-mint.mdx similarity index 100% rename from packages/specs/pages/masp/burn-and-mint.mdx rename to packages/specs/pages/modules/masp/burn-and-mint.mdx diff --git a/packages/specs/pages/masp/convert-circuit.mdx b/packages/specs/pages/modules/masp/convert-circuit.mdx similarity index 99% rename from packages/specs/pages/masp/convert-circuit.mdx rename to packages/specs/pages/modules/masp/convert-circuit.mdx index ee0469be..90ca05a1 100644 --- a/packages/specs/pages/masp/convert-circuit.mdx +++ b/packages/specs/pages/modules/masp/convert-circuit.mdx @@ -1,7 +1,7 @@ # Convert Circuit ## Convert Circuit Description -The high-level description of `Convert` can be found [Burn and mint](./burn-and-mint.html). +The high-level description of `Convert` can be found [Burn and mint](./burn-and-mint.mdx). The `Convert` provides a mechanism that burning and minting of assets can be enabled by adding `Convert Value Commitments` in transaction and ensuring the homomorphic sum of `Spend`, `Output` and `Convert` value commitments to be zero. diff --git a/packages/specs/pages/masp/ledger-integration.mdx b/packages/specs/pages/modules/masp/ledger-integration.mdx similarity index 100% rename from packages/specs/pages/masp/ledger-integration.mdx rename to packages/specs/pages/modules/masp/ledger-integration.mdx diff --git a/packages/specs/pages/economics/shielded-pool-incentives.mdx b/packages/specs/pages/modules/masp/shielded-pool-incentives.mdx similarity index 88% rename from packages/specs/pages/economics/shielded-pool-incentives.mdx rename to packages/specs/pages/modules/masp/shielded-pool-incentives.mdx index f02ecc20..3ba190c8 100644 --- a/packages/specs/pages/economics/shielded-pool-incentives.mdx +++ b/packages/specs/pages/modules/masp/shielded-pool-incentives.mdx @@ -1,4 +1,6 @@ -## Shielded pool incentives +## Shielded pool rewards + +Privacy provided by the MASP in practice depends on how many users use the shielded pool and what assets they use it with. To increase the likelihood of a sizeable privacy set, Namada pays a variable portion of inflation, up to 10% per annum, to shielded pool incentives, which are allocated on a per-asset basis by a PD-controller targeting specific amounts of each asset being locked in the shielded pool. ### Rationale diff --git a/packages/specs/pages/masp/trusted-setup.mdx b/packages/specs/pages/modules/masp/trusted-setup.mdx similarity index 100% rename from packages/specs/pages/masp/trusted-setup.mdx rename to packages/specs/pages/modules/masp/trusted-setup.mdx diff --git a/packages/specs/pages/base-ledger/multisignature.mdx b/packages/specs/pages/modules/multisignature.mdx similarity index 100% rename from packages/specs/pages/base-ledger/multisignature.mdx rename to packages/specs/pages/modules/multisignature.mdx diff --git a/packages/specs/pages/base-ledger/fungible-token.mdx b/packages/specs/pages/modules/multitoken.mdx similarity index 96% rename from packages/specs/pages/base-ledger/fungible-token.mdx rename to packages/specs/pages/modules/multitoken.mdx index 3dc31b69..8d011cef 100644 --- a/packages/specs/pages/base-ledger/fungible-token.mdx +++ b/packages/specs/pages/modules/multitoken.mdx @@ -6,7 +6,7 @@ The fungible token validity predicate authorises token balance changes on the ba A token balance is stored with a storage key. The token balance key should be `#Multitoken/{token_addr}/balance/{owner_addr}`. These keys can be made with [token functions](https://github.com/anoma/namada/blob/5da82f093f10c0381865accba99f60c557360c51/core/src/types/token.rs). -We can have multitoken balances for the same owner by `{token_addr}`, e.g. a token received over IBC is managed in `#Multitoken/{ibc_token}/balance/{receiver_addr}`. It is distinguished from the receiver's original balance in `#Multitoken/{token_addr}/balance/{receiver_addr}` to know which chain the token was transferred from. The `{ibc_token}` is explained in [IBC](../interoperability/ibc.mdx). +We can have multitoken balances for the same owner by `{token_addr}`, e.g. a token received over IBC is managed in `#Multitoken/{ibc_token}/balance/{receiver_addr}`. It is distinguished from the receiver's original balance in `#Multitoken/{token_addr}/balance/{receiver_addr}` to know which chain the token was transferred from. The `{ibc_token}` is explained in [IBC](../modules/ibc.mdx). Transfers between the balances with the same `{token_addr}` are allowed. Specifically, we can transfer a token from `#Multitoken/{token_addr}/balance/{sender_addr}` to `#Multitoken/{token_addr}/balance/{receiver_addr}`. diff --git a/packages/specs/pages/economics/proof-of-stake.mdx b/packages/specs/pages/modules/proof-of-stake.mdx similarity index 100% rename from packages/specs/pages/economics/proof-of-stake.mdx rename to packages/specs/pages/modules/proof-of-stake.mdx diff --git a/packages/specs/pages/economics/proof-of-stake/_meta.json b/packages/specs/pages/modules/proof-of-stake/_meta.json similarity index 100% rename from packages/specs/pages/economics/proof-of-stake/_meta.json rename to packages/specs/pages/modules/proof-of-stake/_meta.json diff --git a/packages/specs/pages/economics/proof-of-stake/cubic-slashing.mdx b/packages/specs/pages/modules/proof-of-stake/cubic-slashing.mdx similarity index 100% rename from packages/specs/pages/economics/proof-of-stake/cubic-slashing.mdx rename to packages/specs/pages/modules/proof-of-stake/cubic-slashing.mdx diff --git a/packages/specs/pages/economics/inflation-system.mdx b/packages/specs/pages/modules/proof-of-stake/inflation-system.mdx similarity index 94% rename from packages/specs/pages/economics/inflation-system.mdx rename to packages/specs/pages/modules/proof-of-stake/inflation-system.mdx index 012f782c..72d6ecb7 100644 --- a/packages/specs/pages/economics/inflation-system.mdx +++ b/packages/specs/pages/modules/proof-of-stake/inflation-system.mdx @@ -4,15 +4,11 @@ The Namada protocol controls the Namada token NAM (the native staking token), wh ### Proof-of-stake rewards -The security of the proof-of-stake voting power allocation mechanism used by Namada is dependent in part upon locking (bonding) tokens to validators, where these tokens can be slashed should the validators misbehave. Funds so locked are only able to be withdrawn after an unbonding period. In order to reward validators and delegators for locking their stake and participating in the consensus mechanism, Namada pays a variable amount of inflation to all delegators and validators. The amount of inflation paid is varied on a PD-controller in order to target a particular bonding ratio (fraction of the NAM token being locked in proof-of-stake). Namada targets a bonding ratio of 2/3, paying up to 10% inflation per annum to proof-of-stake rewards. See [reward distribution mechanism](./proof-of-stake/reward-distribution.mdx) for details. +The security of the proof-of-stake voting power allocation mechanism used by Namada is dependent in part upon locking (bonding) tokens to validators, where these tokens can be slashed should the validators misbehave. Funds so locked are only able to be withdrawn after an unbonding period. In order to reward validators and delegators for locking their stake and participating in the consensus mechanism, Namada pays a variable amount of inflation to all delegators and validators. The amount of inflation paid is varied on a PD-controller in order to target a particular bonding ratio (fraction of the NAM token being locked in proof-of-stake). Namada targets a bonding ratio of 2/3, paying up to 10% inflation per annum to proof-of-stake rewards. See [reward distribution mechanism](../proof-of-stake/reward-distribution.mdx) for details. ### Shielded pool rewards -Privacy provided by the MASP in practice depends on how many users use the shielded pool and what assets they use it with. To increase the likelihood of a sizeable privacy set, Namada pays a variable portion of inflation, up to 10% per annum, to shielded pool incentives, which are allocated on a per-asset basis by a PD-controller targeting specific amounts of each asset being locked in the shielded pool. See [shielded pool incentives](./shielded-pool-incentives.mdx) for details. - -### Public goods funding - -Namada provides 10% per annum inflation for other non-algorithmically-measurable public goods. See [public goods funding](./public-goods-funding.mdx) for details. +Privacy provided by the MASP in practice depends on how many users use the shielded pool and what assets they use it with. To increase the likelihood of a sizeable privacy set, Namada pays a variable portion of inflation, up to 10% per annum, to shielded pool incentives, which are allocated on a per-asset basis by a PD-controller targeting specific amounts of each asset being locked in the shielded pool. See [shielded pool incentives](../masp/shielded-pool-incentives.mdx) for details. ## Detailed inflation calculation model diff --git a/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx b/packages/specs/pages/modules/proof-of-stake/objects-and-txs.mdx similarity index 98% rename from packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx rename to packages/specs/pages/modules/proof-of-stake/objects-and-txs.mdx index 2fe3fea2..08f3b11f 100644 --- a/packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx +++ b/packages/specs/pages/modules/proof-of-stake/objects-and-txs.mdx @@ -134,7 +134,7 @@ This set is used to initialize the genesis state with epoched data active immedi The default values that are relative to epoch duration assume that an epoch last about 24 hours. - `max_validator_slots`: Maximum consensus validators, default `128` -- `min_validator_stake`: Minimum stake of a validator that allows the validator to enter the `consensus` or `below_capacity` [sets](#validator-sets), in number of native tokens. Because the [inflation system](../inflation-system.mdx#proof-of-stake-rewards) targets a bonding ratio of 2/3, the minimum should be somewhere around `total_supply * 2/3 / max_validator_slots`, but it can and should be much lower to lower the entry cost, as long as it's enough to prevent validation account creation spam that could slow down PoS system update on epoch change +- `min_validator_stake`: Minimum stake of a validator that allows the validator to enter the `consensus` or `below_capacity` [sets](#validator-sets), in number of native tokens. Because the [inflation system](./inflation-system.mdx#proof-of-stake-rewards) targets a bonding ratio of 2/3, the minimum should be somewhere around `total_supply * 2/3 / max_validator_slots`, but it can and should be much lower to lower the entry cost, as long as it's enough to prevent validation account creation spam that could slow down PoS system update on epoch change - `pipeline_len`: Pipeline length in number of epochs, default `2`, [see this link](https://github.com/cosmos/cosmos-sdk/blob/019444ae4328beaca32f2f8416ee5edbac2ef30b/docs/architecture/adr-039-epoched-staking.md#pipelining-the-epochs) - `unboding_len`: Unbonding duration in number of epochs, default `6` - `cubic_slash_window_width`: The number of epochs above and below the current one in which to collect misbehaviors for use in computing the cubic slash rate, default `1`. diff --git a/packages/specs/pages/economics/proof-of-stake/reward-distribution.mdx b/packages/specs/pages/modules/proof-of-stake/reward-distribution.mdx similarity index 96% rename from packages/specs/pages/economics/proof-of-stake/reward-distribution.mdx rename to packages/specs/pages/modules/proof-of-stake/reward-distribution.mdx index a24e58cf..5aa3734c 100644 --- a/packages/specs/pages/economics/proof-of-stake/reward-distribution.mdx +++ b/packages/specs/pages/modules/proof-of-stake/reward-distribution.mdx @@ -2,7 +2,7 @@ Namada uses the automatically-compounding variant of the [F1 fee distribution](https://drops.dagstuhl.de/opus/volltexte/2020/11974/pdf/OASIcs-Tokenomics-2019-10.pdf). -Rewards are given to validators for proposing blocks, for voting on finalizing blocks, and for being in the [consensus validator set](objects-and-txs.mdx#validator-sets). The funds for these rewards come from **minting** (creating new tokens). The amount that is minted depends on how many staking tokens are locked (staked) and some maximum annual inflation rate. The rewards mechanism is implemented as a [PD controller](../inflation-system.mdx#detailed-inflation-calculation-model) that dynamically adjusts the inflation rate to achieve a target staked token ratio. When the total fraction of tokens staked is very low, the return rate per validator needs to increase, but as the total fraction of stake rises, validators will receive fewer rewards. Once the desired staking fraction is achieved, the amount minted will just be the desired annual inflation. +Rewards are given to validators for proposing blocks, for voting on finalizing blocks, and for being in the [consensus validator set](objects-and-txs.mdx#validator-sets). The funds for these rewards come from **minting** (creating new tokens). The amount that is minted depends on how many staking tokens are locked (staked) and some maximum annual inflation rate. The rewards mechanism is implemented as a [PD controller](./inflation-system.mdx#detailed-inflation-calculation-model) that dynamically adjusts the inflation rate to achieve a target staked token ratio. When the total fraction of tokens staked is very low, the return rate per validator needs to increase, but as the total fraction of stake rises, validators will receive fewer rewards. Once the desired staking fraction is achieved, the amount minted will just be the desired annual inflation. Each delegation to a validator is initiated at an agreed-upon commission rate charged by the validator. Validators pay out rewards to delegators based on this mutually-determined commission rate. The minted rewards are auto-bonded and only transferred when the funds are unbonded. Once the protocol determines the total amount of tokens to mint at the end of the epoch, the minted tokens are effectively divided among the relevant validators and delegators according to their proportional stake. In practice, the reward products, which are the fractional increases in staked tokens claimed, are stored for the validators and delegators, and the reward tokens are only transferred to the validator’s or delegator’s account upon withdrawal. This is described in the following sections. The general system is similar to what Cosmos does. From 57adda08ae8baa1e7e56068c410dad3fd99ce05b Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Wed, 14 Feb 2024 12:12:29 +0000 Subject: [PATCH 62/75] meta jsons changed and also docs->specs references --- packages/docs/pages/operators/eth-bridge.mdx | 2 +- packages/docs/pages/users/ibc.mdx | 2 +- packages/docs/pages/users/public-goods-stewards.mdx | 2 +- packages/docs/pages/users/public-goods-stewards/electing.mdx | 4 ++-- .../docs/pages/users/shielded-accounts/shielded-rewards.mdx | 2 +- packages/specs/pages/_meta.json | 2 +- packages/specs/pages/base-ledger/_meta.json | 3 ++- packages/specs/pages/modules/governance/_meta.json | 3 ++- packages/specs/pages/modules/masp/_meta.json | 3 ++- packages/specs/pages/modules/proof-of-stake/_meta.json | 3 ++- 10 files changed, 15 insertions(+), 11 deletions(-) diff --git a/packages/docs/pages/operators/eth-bridge.mdx b/packages/docs/pages/operators/eth-bridge.mdx index 88e9e734..1d0e92a8 100644 --- a/packages/docs/pages/operators/eth-bridge.mdx +++ b/packages/docs/pages/operators/eth-bridge.mdx @@ -7,7 +7,7 @@ The bridge is a combination of smart contracts on Ethereum as well as ledger pro ## Design -The full design specs can be found [here](https://specs.namada.net/interoperability/ethereum-bridge). +The full design specs can be found [here](https://specs.namada.net/modules/ethereum-bridge). A short outline of the design is outlined below. diff --git a/packages/docs/pages/users/ibc.mdx b/packages/docs/pages/users/ibc.mdx index 71a19dee..4ec58b4e 100644 --- a/packages/docs/pages/users/ibc.mdx +++ b/packages/docs/pages/users/ibc.mdx @@ -55,7 +55,7 @@ namadac --base-dir ${BASE_DIR_A} --node 127.0.0.1:27657 ``` -Once the transaction has been submitted, a relayer will need to relay the packet to the other chain. This is done automatically by the relayer running Hermes. If the packet is never successfully relayed, the funds are returned to the sender after a timeout. See more information in the [specs](https://specs.namada.net/interoperability/ibc). +Once the transaction has been submitted, a relayer will need to relay the packet to the other chain. This is done automatically by the relayer running Hermes. If the packet is never successfully relayed, the funds are returned to the sender after a timeout. See more information in the [specs](https://specs.namada.net/modules/ibc). ## Transferring assets back from Cosmos-SDK based chains diff --git a/packages/docs/pages/users/public-goods-stewards.mdx b/packages/docs/pages/users/public-goods-stewards.mdx index 3481ca8d..faf55506 100644 --- a/packages/docs/pages/users/public-goods-stewards.mdx +++ b/packages/docs/pages/users/public-goods-stewards.mdx @@ -3,7 +3,7 @@ The funding of public goods on Namada is conducted through an entity called the Each steward is elected by governance through separate governance proposals. -See the specs about the public goods funding [here](https://specs.namada.net/economics/public-goods-funding.html) for more details. +See the specs about the public goods funding [here](https://specs.namada.net/modules/governance/public-goods-funding.html) for more details. This documentation will cover: diff --git a/packages/docs/pages/users/public-goods-stewards/electing.mdx b/packages/docs/pages/users/public-goods-stewards/electing.mdx index d98a8301..cdc1d681 100644 --- a/packages/docs/pages/users/public-goods-stewards/electing.mdx +++ b/packages/docs/pages/users/public-goods-stewards/electing.mdx @@ -53,7 +53,7 @@ that would be removed from the list of stewards. In the motivation and abstract field, it is important to make clear what type of public goods funding the steward will be focusing on. The *areas of public goods funding* can be found in the -[public goods funding specs](https://specs.namada.net/economics/public-goods-funding.html#funding-focuses). +[public goods funding specs](https://specs.namada.net/modules/governance/public-goods-funding.html#funding-focuses). </Callout> ### Submitting the proposal to the ledger @@ -89,4 +89,4 @@ Through the CLI it can be done with the command: namadac resign-steward --steward my-steward-address ``` -Read more about the other methods of losing stewardship in the [specs](https://specs.namada.net/economics/public-goods-funding/becoming-a-steward#losing-stewardship-status). +Read more about the other methods of losing stewardship in the [specs](https://specs.namada.net/modules/goverance/public-goods-funding/becoming-a-steward#losing-stewardship-status). diff --git a/packages/docs/pages/users/shielded-accounts/shielded-rewards.mdx b/packages/docs/pages/users/shielded-accounts/shielded-rewards.mdx index 73600601..d7d34bc6 100644 --- a/packages/docs/pages/users/shielded-accounts/shielded-rewards.mdx +++ b/packages/docs/pages/users/shielded-accounts/shielded-rewards.mdx @@ -2,4 +2,4 @@ Shielded rewards are distributed to all users in the shielded set. Users are rewared `NAM` tokens for each epoch their incentivised assets are in the shielded set. Informally, the amount of `NAM` rewarded for a specific asset is proportional to the amount of that asset in the shielded pool. Each asset has a "reward rate" specified by governance, which sets the constant of proportionality for that asset. -The interested reader should consult [the specs](https://specs.namada.net/economics/proof-of-stake) for a more precise explanation of how the reward is calculated. \ No newline at end of file +The interested reader should consult [the specs](https://specs.namada.net/modules/proof-of-stake) for a more precise explanation of how the reward is calculated. \ No newline at end of file diff --git a/packages/specs/pages/_meta.json b/packages/specs/pages/_meta.json index 10c18567..cbe2596b 100644 --- a/packages/specs/pages/_meta.json +++ b/packages/specs/pages/_meta.json @@ -1,6 +1,6 @@ { "index": "Introduction", "base-ledger": "Base ledger", - "mdoules": "Modules", + "modules": "Modules", "further-reading": "Further reading" } diff --git a/packages/specs/pages/base-ledger/_meta.json b/packages/specs/pages/base-ledger/_meta.json index d419ed6a..45f6354a 100644 --- a/packages/specs/pages/base-ledger/_meta.json +++ b/packages/specs/pages/base-ledger/_meta.json @@ -2,5 +2,6 @@ "consensus": "Consensus", "execution": "Execution model", "replay-protection": "Replay protection", - "block-space-allocator": "Block space allocator" + "block-space-allocator": "Block space allocator", + "fee-system": "Fee system" } diff --git a/packages/specs/pages/modules/governance/_meta.json b/packages/specs/pages/modules/governance/_meta.json index 342542d9..7cb41958 100644 --- a/packages/specs/pages/modules/governance/_meta.json +++ b/packages/specs/pages/modules/governance/_meta.json @@ -2,5 +2,6 @@ "on-chain" : "On chain governance", "off-chain" : "Off chain governance", "proposal" : "Proposals", - "storage" : "Storage" + "storage" : "Storage", + "public-goods-funding" : "Public goods funding" } \ No newline at end of file diff --git a/packages/specs/pages/modules/masp/_meta.json b/packages/specs/pages/modules/masp/_meta.json index d8a9601d..26cc34b2 100644 --- a/packages/specs/pages/modules/masp/_meta.json +++ b/packages/specs/pages/modules/masp/_meta.json @@ -3,5 +3,6 @@ "asset-type": "Asset type", "burn-and-mint": "Burn & mint", "convert-circuit": "Convert circuit", - "trusted-setup": "Trusted setup" + "trusted-setup": "Trusted setup", + "shielded-pool-incentives": "Shielded pool rewards" } diff --git a/packages/specs/pages/modules/proof-of-stake/_meta.json b/packages/specs/pages/modules/proof-of-stake/_meta.json index 4f1e4a7a..aaf43f4b 100644 --- a/packages/specs/pages/modules/proof-of-stake/_meta.json +++ b/packages/specs/pages/modules/proof-of-stake/_meta.json @@ -1,5 +1,6 @@ { "objects-and-txs": "Objects and Txs", "cubic-slashing": "Cubic slashing", - "reward-distribution": "Reward distribution" + "reward-distribution": "Reward distribution", + "inflation-system": "Inflation system" } From 1b1340fd03ca7a0a2c9de5fd72701e6175a41068 Mon Sep 17 00:00:00 2001 From: Christopher Goes <cwgoes@pluranimity.org> Date: Wed, 14 Feb 2024 16:51:48 +0100 Subject: [PATCH 63/75] Minor edits after structural rework --- packages/specs/pages/base-ledger.mdx | 18 +++++---------- .../specs/pages/base-ledger/consensus.mdx | 3 ++- packages/specs/pages/index.mdx | 4 ++-- packages/specs/pages/modules.mdx | 22 ++++++++++++------- 4 files changed, 24 insertions(+), 23 deletions(-) diff --git a/packages/specs/pages/base-ledger.mdx b/packages/specs/pages/base-ledger.mdx index f576a7fb..90fd38de 100644 --- a/packages/specs/pages/base-ledger.mdx +++ b/packages/specs/pages/base-ledger.mdx @@ -1,14 +1,8 @@ # Base ledger -The base ledger of Namada includes a [consensus mechanism](./base-ledger/consensus.mdx) and a validity-predicate based [execution system](./base-ledger/execution.mdx). - -## Consensus - -The consensus mechanism on Namada provides an algorithmic way for validators to communicate votes and collectively agree on a single, consistent state in a Byzantine-fault-tolerant manner. The algorithm, coupled with a cryptoeconomic voting power allocation mechanism called "proof of stake", is designed so that that non-colluding validators acting in their (economic) self interest will follow the consensus algorithm in a predictable manner. - -## Validity predicates - -The validity predicate based execution mechanism is inherited from the architectural design philosophy of Anoma. The fundamental idea is that a "valid state" is defined as that which satisfies a set of boolean conditions. These boolean conditions are encoded by "validity predicates", represented as WASM or Rust-native functions, which are invoked whenever a state is being proposed. If all validity predicates in the system return the boolean `true`, this defines a valid state which validators can vote on. The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps. - -## Replay protection & block space allocator -In addition to describing the execution model and consensus, this section also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), which prevents transactions from being executed multiple times, and [block space allocator](./base-ledger/block-space-allocator.mdx), which packs transactions into blocks. \ No newline at end of file +The base ledger of Namada includes: +- a [consensus mechanism](./base-ledger/consensus.mdx), which provides an algorithmic way for validators to communicate votes and collectively agree on a single, consistent state in a Byzantine-fault-tolerant manner; +- a validity-predicate-based [execution model](./base-ledger/execution.mdx) where a "valid state" is defined as that which satisfies a set of boolean conditions; +- a [replay protection system](./base-ledger/replay-protection.mdx) which prevents transactions from being executed multiple times; +- a [block space allocator](./base-ledger/block-space-allocator.mdx) which packs transactions into blocks; and +- a [fee system](./base-ledger/fee-system.mdx) which provides for efficient, DoS-resistant allocation of computational and storage resources within blocks \ No newline at end of file diff --git a/packages/specs/pages/base-ledger/consensus.mdx b/packages/specs/pages/base-ledger/consensus.mdx index 5c977e50..12059890 100644 --- a/packages/specs/pages/base-ledger/consensus.mdx +++ b/packages/specs/pages/base-ledger/consensus.mdx @@ -2,9 +2,10 @@ Namada uses [CometBFT](https://github.com/cometbft/cometbft/) (nee Tendermint Go) through the [cometbft-rs](https://github.com/heliaxdev/tendermint-rs) (nee tendermint-rs) bindings in order to provide peer-to-peer transaction gossip, Byzantine fault tolerant (BFT) consensus, and state machine replication for Namada's custom state machine. CometBFT implements the Tendermint consensus algorithm, which you can read more about [here](https://arxiv.org/abs/1807.04938). -{/* Maybe we want to leave out the below section. I just felt we should give a brief summary of CometBFT */} ## The benefits of using CometBFT +CometBFT, coupled with a cryptoeconomic voting power allocation mechanism called "proof of stake", is designed so that that non-colluding validators acting in their (economic) self interest will follow the consensus algorithm in a predictable manner. + Using the CometBFT consensus algorithm comes with a number of benefits including: - Fast finality diff --git a/packages/specs/pages/index.mdx b/packages/specs/pages/index.mdx index 6e35809b..4d7e0b6e 100644 --- a/packages/specs/pages/index.mdx +++ b/packages/specs/pages/index.mdx @@ -40,8 +40,8 @@ Users of Namada earn rewards, retain privacy of assets, and contribute to shared These documents describe the behavior of the Namada protocol. This description is organized into five sub-sections: -1. [Base Ledger](./base-ledger.mdx): This section describes the core ledger functionality of the Namada protocol. This includes the basic data structures and state transitions that make up the Namada blockchain. -2. [Modules](./modules.mdx): This section describes the modules that make up the Namada protocol. Each module is a distinct part of the protocol that can be understood in isolation. +1. [Base Ledger](./base-ledger.mdx): This section describes the core ledger functionality of the Namada protocol. This includes the consensus, execution model, fee system, and environment in which modules operate. +2. [Modules](./modules.mdx): This section describes the modules that make up the Namada protocol. Each module is a distinct part of the protocol grouping a related set of features that can be understood in isolation from other modules. This book is written using [NextraJS](https://nextra.site/). The source can be found in the [Namada Docs repository](https://github.com/anoma/namada-docs/tree/master/packages/specs). diff --git a/packages/specs/pages/modules.mdx b/packages/specs/pages/modules.mdx index f0e1d914..ff4a400e 100644 --- a/packages/specs/pages/modules.mdx +++ b/packages/specs/pages/modules.mdx @@ -1,11 +1,17 @@ # Modules -The validity predicates define the modules of Namada. These modules are: +Namada's features are grouped into _modules_. Each module defines: +- a validity predicate, which controls a storage sub-space in the ledger state; +- a set of data structures and a storage layout, which are used in this storage sub-space; +- a set of transactions, which allow users to take actions that change state in this storage sub-space; and, optionally +- handlers to be run on various block lifecycle events (e.g. during ABCI's `FinalizeBlock` or at the end of each epoch), which can be used to implement periodic, automated state changes (e.g. minting new tokens at the end of an epoch and distributing them to delegators) -- Multitoken -- Multisignature -- Proof-of-stake -- Multi-asset-shielded-pool (MASP) -- Governance -- IBC -- Ethereum bridge \ No newline at end of file +Namada includes the following modules: + +- [Multitoken](./modules/multitoken.mdx) +- [Multisignature](./modules/multisignature.mdx) +- [Proof-of-stake](./modules/proof-of-stake.mdx) +- [Multi-asset-shielded-pool (MASP)](./modules/masp.mdx) +- [Governance](./modules/governance.mdx) +- [IBC](./modules/ibc.mdx) +- [Ethereum bridge](./modules/ethereum-bridge.mdx) \ No newline at end of file From 8af4b17579d1ce69dfcaf4703858c1acdf43a027 Mon Sep 17 00:00:00 2001 From: nodiums <82638916+nodiums@users.noreply.github.com> Date: Thu, 15 Feb 2024 11:38:28 +0700 Subject: [PATCH 64/75] Update electing.mdx Fix Json structure commas --- packages/docs/pages/users/public-goods-stewards/electing.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/users/public-goods-stewards/electing.mdx b/packages/docs/pages/users/public-goods-stewards/electing.mdx index cdc1d681..6af83969 100644 --- a/packages/docs/pages/users/public-goods-stewards/electing.mdx +++ b/packages/docs/pages/users/public-goods-stewards/electing.mdx @@ -29,12 +29,12 @@ The `steward_proposal.json` file contains the information about the proposal. It "license": "MIT", "abstract": "Stewie is running for steward, with a focus on technical research. The technical research I will be focused on will definitely not be for weapons of mass destruction. There is some possibility however that I may be focusing somewhat on open source software for weapons of mass destruction.", "motivation": "Nobody knows technical research better than me. Trust me. I know it. I have the best technical research. I will be the best steward. Last night, Namada called me and said, Stewie, thank you. I will make public goods funding great again", - "details": "As a genius baby, I possess an unmatched level of intelligence and a visionary mindset. I will utilize these qualities to solve the most complex problems, and direct public goods funding towards weapons of mass destruction ... i mean open source software for weapons of mass destruction", + "details": "As a genius baby, I possess an unmatched level of intelligence and a visionary mindset. I will utilize these qualities to solve the most complex problems, and direct public goods funding towards weapons of mass destruction ... i mean open source software for weapons of mass destruction" }, "author": "stewie", "voting_start_epoch": 3, "voting_end_epoch": 6, - "grace_epoch": 12, + "grace_epoch": 12 }, "data" : { "add" : "atestatest1v4ehgw36g4pyg3j9x3qnjd3cxgmyz3fk8qcrys3hxdp5xwfnx3zyxsj9xgunxsfjg5u5xvzyzrrqtn", From dc817a0778e6b142374d1761700ccfdc1351b867 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Thu, 15 Feb 2024 14:18:08 +0000 Subject: [PATCH 65/75] voting periods and grace epoch added --- .../docs/pages/users/governance/on-chain-governance.mdx | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 89631350..d2740151 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -1,3 +1,4 @@ +import { info } from 'console' import { Callout } from 'nextra-theme-docs' # On-chain proposals @@ -245,3 +246,9 @@ or to just check the result: ```shell copy namada client query-proposal-result --proposal-id 0 ``` + +<Callout type="info"> +It is important to note that the proposal will only be executed at the end of the `grace_epoch` epoch if it has passed. If it has not passed, the proposal will be rejected and the code will not be executed. + +Another important note is that the voting period differs between `delegates` and `delegators`. The `delegates` have a shorter voting period than the `delegators`. This is to ensure that the `delegates` have enough time to vote on the proposals. See the specs for more information. +</Callout> \ No newline at end of file From c205997f06a34587593f8efbe5ccf6e41d29ad02 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Thu, 15 Feb 2024 15:05:59 +0000 Subject: [PATCH 66/75] delegates voting window added --- packages/docs/pages/users/governance/on-chain-governance.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index d2740151..76d2a586 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -250,5 +250,5 @@ namada client query-proposal-result --proposal-id 0 <Callout type="info"> It is important to note that the proposal will only be executed at the end of the `grace_epoch` epoch if it has passed. If it has not passed, the proposal will be rejected and the code will not be executed. -Another important note is that the voting period differs between `delegates` and `delegators`. The `delegates` have a shorter voting period than the `delegators`. This is to ensure that the `delegates` have enough time to vote on the proposals. See the specs for more information. +Another important note is that the voting period differs between `delegates` and `delegators`. The `delegates` have a shorter voting period than the `delegators`. This is defined in the `parameters.toml`. This is to ensure that the `delegates` have enough time to vote on the proposals. See the specs for more information. </Callout> \ No newline at end of file From 7d6489c251919cb35966c087e44d1d99236fd529 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Thu, 15 Feb 2024 17:43:50 +0000 Subject: [PATCH 67/75] corrected --- packages/docs/pages/users/governance/on-chain-governance.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 76d2a586..524215ab 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -248,7 +248,7 @@ namada client query-proposal-result --proposal-id 0 ``` <Callout type="info"> -It is important to note that the proposal will only be executed at the end of the `grace_epoch` epoch if it has passed. If it has not passed, the proposal will be rejected and the code will not be executed. +It is important to note that the proposal will only be executed at the start of the `grace_epoch` epoch if it has passed. If it has not passed, the proposal will be rejected and the code will not be executed. -Another important note is that the voting period differs between `delegates` and `delegators`. The `delegates` have a shorter voting period than the `delegators`. This is defined in the `parameters.toml`. This is to ensure that the `delegates` have enough time to vote on the proposals. See the specs for more information. +Another important note is that the voting period differs between validators and non-validators. The validators have a shorter voting period than the delegators. This is defined in the `parameters.toml`. This is to ensure that the non-validators have enough time to vote on the proposals (so that the validators cannot vote in the last block against the non-validators preference). See the specs for more information. </Callout> \ No newline at end of file From 524bb9ee8c82ba3122c10e2c57f99a3907f9dcf5 Mon Sep 17 00:00:00 2001 From: brentstone <brentstone01@gmail.com> Date: Thu, 15 Feb 2024 23:40:09 -0500 Subject: [PATCH 68/75] update protocol version to 0.31.4 --- packages/docs/pages/networks/testnets.mdx | 2 +- packages/docs/pages/networks/testnets/environment-setup.mdx | 4 ++-- packages/docs/pages/networks/testnets/testnet-history.mdx | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 8987630c..bdd2c12a 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -17,7 +17,7 @@ The `balances.toml` file is located at `https://github.com/anoma/namada-shielded - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.2` + - Namada protocol version: `v0.31.4` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14` diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index 65bbc746..dd24c77b 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.31.2 +export NAMADA_TAG=v0.31.4 ``` @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.31.2` + - `namada --version` should output `Namada v0.31.4` </Steps> diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index 6775ade5..4ec1df11 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -14,7 +14,7 @@ In order to upgrade to the latest version of the Namada protocol, please follow - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.2` + - Namada protocol version: `v0.31.4` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14` From 44069e0c73f70e929948817fb2ac54cda661d2dc Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Fri, 16 Feb 2024 13:44:34 +0000 Subject: [PATCH 69/75] proposal docs --- .../users/governance/on-chain-governance.mdx | 24 ++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 524215ab..6c048fbb 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -251,4 +251,26 @@ namada client query-proposal-result --proposal-id 0 It is important to note that the proposal will only be executed at the start of the `grace_epoch` epoch if it has passed. If it has not passed, the proposal will be rejected and the code will not be executed. Another important note is that the voting period differs between validators and non-validators. The validators have a shorter voting period than the delegators. This is defined in the `parameters.toml`. This is to ensure that the non-validators have enough time to vote on the proposals (so that the validators cannot vote in the last block against the non-validators preference). See the specs for more information. -</Callout> \ No newline at end of file +</Callout> + +## Submit a governance proposal with wasm code attached (advanced) + +First you will need a valid `.wasm` file. You then need to read this file into a vector of bytes. This can be done with the following python script: + +```python +with open(wasm_file_path, "rb") as f: + byte_vec = list(f.read()) +print(str(byte_vec)) +``` + +This needs to go into the `data` field of the proposal json. E.g `"data": [1,2,3,4,5,6,7,8,9,10]` + +When submitting this proposal, it is likely that the gas requirement will be large. Therefore, it is recommended to supply both the `--gas-limit` and `--gas-price` flags. + +```shell copy +namadac init-proposal --data-path proposal.json --gas-limit 500000 --gas-price 0.01 +``` + +<Callout type="info"> +Hint: use the `--dry-run` feature to figure out how much gas will be needed and use `namadac query-protocol-paramters` to see the current minimum gas price. +</Callout> From 2476dafc453d2869a16e65311abcac5d4fa0a4e2 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Fri, 16 Feb 2024 15:20:55 +0000 Subject: [PATCH 70/75] remove signing keys --- .../pages/users/governance/on-chain-governance.mdx | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 6c048fbb..40aff044 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -1,5 +1,8 @@ import { info } from 'console' +import { SocketAddress } from 'net' +import { addHookAliases } from 'next/dist/server/require-hook' import { Callout } from 'nextra-theme-docs' +import { f, t } from 'nextra/dist/types-fa5ec8b0' # On-chain proposals @@ -226,10 +229,13 @@ Only delegators and delegates can vote on proposals. Assuming you fall into one namada client vote-proposal \ --proposal-id 0 \ --vote yay \ - --address <your-address> \ - --signing-keys <your-alias> + --address <your-address> ``` +<Callout type="info"> +The `--address` flag needs to be the address of the delegator or delegate that is voting. For validators, it is better to use the raw address rather than the alias. The `--signing-keys` can be the alias, however it is recommended to leave out the `--signing-keys` flag and let the client figure out the signing keys. If the key does not have a balance, use the `--gas-payer` flag to specify the address of the account that will pay for the gas. +</Callout> + where `--vote` can be either `yay`, `nay` or `abstain`. ## Check the result From 1693a4681f66ed28ce1c10347cbafa3cb9058e28 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Fri, 16 Feb 2024 15:23:33 +0000 Subject: [PATCH 71/75] signatures flag corrected --- .../docs/pages/users/transparent-accounts/multisignature.mdx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/packages/docs/pages/users/transparent-accounts/multisignature.mdx b/packages/docs/pages/users/transparent-accounts/multisignature.mdx index fc364719..42f8cc0e 100644 --- a/packages/docs/pages/users/transparent-accounts/multisignature.mdx +++ b/packages/docs/pages/users/transparent-accounts/multisignature.mdx @@ -107,8 +107,7 @@ The final step is to submit the transaction. This can be done through the follow ```shell namadac tx \ --tx-path "tx_dumps/a45ef98a817290d6fc0efbd480bf66647ea8061aee1628ce09b4af4f4eeed1c2.tx" \ ---signatures $SIGNATURE_ONE \ ---signatures $SIGNATURE_TWO \ +--signatures $SIGNATURE_ONE $SIGNATURE_TWO \ --owner my-multisig-alias \ --gas-payer my-key1 ``` From 733b005222ec50a310988c54db0206603fa0663b Mon Sep 17 00:00:00 2001 From: brentstone <brentstone01@gmail.com> Date: Mon, 19 Feb 2024 11:48:20 -0700 Subject: [PATCH 72/75] update to v0.31.5 --- packages/docs/pages/networks/testnets.mdx | 2 +- packages/docs/pages/networks/testnets/environment-setup.mdx | 4 ++-- packages/docs/pages/networks/testnets/testnet-history.mdx | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index bdd2c12a..2b4b13b5 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -17,7 +17,7 @@ The `balances.toml` file is located at `https://github.com/anoma/namada-shielded - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.4` + - Namada protocol version: `v0.31.5` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14` diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index dd24c77b..e4c905e6 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -11,7 +11,7 @@ Note that building from source can be a difficult process and is not recommended Export the following variables: ```bash copy -export NAMADA_TAG=v0.31.4 +export NAMADA_TAG=v0.31.5 ``` @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.31.4` + - `namada --version` should output `Namada v0.31.5` </Steps> diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index 4ec1df11..b1833891 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -6,7 +6,7 @@ This page covers all installation steps required by various upgrades to testnets ## Latest Upgrade -## Namada shielded expedition 2 `v0.31.4` upgrade +## Namada shielded expedition 2 `v0.31.5` upgrade In order to upgrade to the latest version of the Namada protocol, please follow the steps from [this hackmd](https://hackmd.io/EBTtfPiZT7yoRjxYRcbiPQ) @@ -14,7 +14,7 @@ In order to upgrade to the latest version of the Namada protocol, please follow - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.4` + - Namada protocol version: `v0.31.5` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14` From 04b82c6191d28707db940351e34348175dbe5920 Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Tue, 20 Feb 2024 17:50:00 +0000 Subject: [PATCH 73/75] pos address stuff --- packages/docs/pages/operators/validators/jailing.mdx | 11 +++++++++++ packages/docs/pages/users/delegators.mdx | 11 +++++++++++ .../pages/users/governance/on-chain-governance.mdx | 9 +++++---- .../users/transparent-accounts/multisignature.mdx | 2 +- 4 files changed, 28 insertions(+), 5 deletions(-) diff --git a/packages/docs/pages/operators/validators/jailing.mdx b/packages/docs/pages/operators/validators/jailing.mdx index 25034a42..d49f0745 100644 --- a/packages/docs/pages/operators/validators/jailing.mdx +++ b/packages/docs/pages/operators/validators/jailing.mdx @@ -1,3 +1,5 @@ +import { Callout } from 'nextra-theme-docs' + # Jailed validators Validators can be *jailed* for several reasons, such as double signing a block, signing an invalid block, or excessive downtime. Each of these reasons will have different ramifications for the validator. @@ -20,6 +22,15 @@ Once jailed, validators remain jailed indefinitely. They can only be unjailed by namadac unjail-validator --validator <validator_address> ``` +<Callout type="info"> +Because the validator alias sometimes clashes with the alias for the implicit account and or established account in the wallet, it is recommended to use the validator address instead of the alias. +In order to find the validator address, you can use the following command: +```bash copy +namadaw list --addr | grep <validator-alias> +``` +then make sure it is the corresponding `tnam` address. +</Callout> + If the transaction is successful, then the validator will be reinstated into one of the validator sets at the pipeline length relative to the current epoch (typically 2 epochs in the future). There may be certain restrictions on unjailing your validator depending on the original reason for jailing. These will be described below. diff --git a/packages/docs/pages/users/delegators.mdx b/packages/docs/pages/users/delegators.mdx index 1718c822..09a30bc9 100644 --- a/packages/docs/pages/users/delegators.mdx +++ b/packages/docs/pages/users/delegators.mdx @@ -1,3 +1,5 @@ +import { Callout } from 'nextra-theme-docs' + # Bonding and proof-of-stake ## Bonded tokens @@ -24,6 +26,15 @@ Once you've found the address of your favourite validator, you can bond to them namadac bond --source <delegator-address> --validator <validator-address> --amount <amount> ``` +<Callout type="info"> +Because the validator alias sometimes clashes with the alias for the implicit account and or established account in the wallet, it is recommended to use the validator address instead of the alias. +In order to find the validator address, you can use the following command: +```bash copy +namadaw list --addr | grep <validator-alias> +``` +then make sure it is the corresponding `tnam` address. +</Callout> + The `<delegator-address>` is your account address from which you would like to stake NAM tokens. Validators who would like to self-bond do not need to provide the `--source` argument. If you have the alias for an address saved in your wallet, you can also pass it as an argument. diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index 40aff044..36e6a4de 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -1,8 +1,4 @@ -import { info } from 'console' -import { SocketAddress } from 'net' -import { addHookAliases } from 'next/dist/server/require-hook' import { Callout } from 'nextra-theme-docs' -import { f, t } from 'nextra/dist/types-fa5ec8b0' # On-chain proposals @@ -280,3 +276,8 @@ namadac init-proposal --data-path proposal.json --gas-limit 500000 --gas-price 0 <Callout type="info"> Hint: use the `--dry-run` feature to figure out how much gas will be needed and use `namadac query-protocol-paramters` to see the current minimum gas price. </Callout> + +## A video tutorial +Skip all the boring text and watch a video tutorial on how to submit a proposal: + +<iframe src="https://player.vimeo.com/video/914426953?badge=0&autopause=0&player_id=0&app_id=58479" width="640" height="416" frameBorder="0" allow="autoplay; fullscreen; picture-in-picture" allowFullScreen></iframe> diff --git a/packages/docs/pages/users/transparent-accounts/multisignature.mdx b/packages/docs/pages/users/transparent-accounts/multisignature.mdx index 42f8cc0e..d4dc5e3d 100644 --- a/packages/docs/pages/users/transparent-accounts/multisignature.mdx +++ b/packages/docs/pages/users/transparent-accounts/multisignature.mdx @@ -150,4 +150,4 @@ The public-keys provided to the argument `--public-keys` will become the new sig Skip all the boring reading and watch a video tutorial instead: -<iframe src="https://player.vimeo.com/video/873749851?h=ee68c142e2&title=0&byline=0&portrait=0" width="640" height="416" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen></iframe> +<iframe src="https://player.vimeo.com/video/873749851?h=ee68c142e2&title=0&byline=0&portrait=0" width="640" height="416" frameBorder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen></iframe> From 63d9c433717c7a782bf6dc5c4896ddc696ec2dcc Mon Sep 17 00:00:00 2001 From: bengtlofgren <bengtlofgren8@gmail.com> Date: Thu, 22 Feb 2024 12:50:49 +0000 Subject: [PATCH 74/75] --node changes --- packages/docs/pages/users/ibc.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/pages/users/ibc.mdx b/packages/docs/pages/users/ibc.mdx index 864f911d..8b4da35c 100644 --- a/packages/docs/pages/users/ibc.mdx +++ b/packages/docs/pages/users/ibc.mdx @@ -52,7 +52,7 @@ namadac --base-dir ${BASE_DIR_A} --receiver atest1d9khqw36g56nqwpkgezrvvejg3p5xv2z8y6nydehxprygvp5g4znj3phxfpyv3pcgcunws2x0wwa76 \ --token nam \ --channel-id channel-0 \ - --node 127.0.0.1:27657 + --node http://127.0.0.1:27657 ``` Once the transaction has been submitted, a relayer will need to relay the packet to the other chain. This is done automatically by the relayer running Hermes. If the packet is never successfully relayed, the funds are returned to the sender after a timeout. See more information in the [specs](https://specs.namada.net/modules/ibc). From 2988d0e8010ee761a99dcd0c80a82fd221014d64 Mon Sep 17 00:00:00 2001 From: brentstone <brentstone01@gmail.com> Date: Fri, 23 Feb 2024 20:07:37 -0600 Subject: [PATCH 75/75] update to 0.31.6 --- packages/docs/pages/networks/testnets.mdx | 6 ++--- .../networks/testnets/environment-setup.mdx | 22 +++++++++---------- .../networks/testnets/testnet-history.mdx | 4 ++-- 3 files changed, 16 insertions(+), 16 deletions(-) diff --git a/packages/docs/pages/networks/testnets.mdx b/packages/docs/pages/networks/testnets.mdx index 2b4b13b5..e88e32a4 100644 --- a/packages/docs/pages/networks/testnets.mdx +++ b/packages/docs/pages/networks/testnets.mdx @@ -8,16 +8,16 @@ For more context read: ## Shielded expedition -<Callout type="info" emoji="👷"> +< Callout type = "info" emoji = "👷" > For the shielded expedition, it is important to remember to add the `--memo` flag to every transaction. The memo should be filled with the `tpknam` submitted at the shielded-expedition registration period. For example `namadac transfer --source me --target you --amount 10 --token naan --signing-keys my-key --memo tpknamq1337mypubkey1964qqqqqq` -</Callout> +< /Callout> The `balances.toml` file is located at `https://github.com/anoma/namada-shielded-expedition`. - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.5` + - Namada protocol version: `v0.31.6` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14` diff --git a/packages/docs/pages/networks/testnets/environment-setup.mdx b/packages/docs/pages/networks/testnets/environment-setup.mdx index e4c905e6..e217013f 100644 --- a/packages/docs/pages/networks/testnets/environment-setup.mdx +++ b/packages/docs/pages/networks/testnets/environment-setup.mdx @@ -1,22 +1,22 @@ -import {Steps} from 'nextra-theme-docs' +import { Steps } from 'nextra-theme-docs' import { Callout } from 'nextra-theme-docs' # Environment setup -<Callout type="info"> +< Callout type = "info" > If you don't want to build Namada from source you can [install Namada from binaries](../../introduction/install/binaries.mdx). Note that building from source can be a difficult process and is not recommended for beginners. -</Callout> +< /Callout> Export the following variables: ```bash copy -export NAMADA_TAG=v0.31.5 +export NAMADA_TAG=v0.31.6 ``` ## Installing Namada -<Steps> +< Steps > ### Install all pre-requisites - [Rust](https://www.rust-lang.org/tools/install) - [CometBFT](../../introduction/installing-cometbft.mdx) @@ -37,17 +37,17 @@ sudo apt-get update -y sudo apt-get install build-essential make pkg-config libssl-dev libclang-dev -y curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` -</Steps> +< /Steps> ## Installing CometBFT -<Steps> +< Steps > ### See the installing CometBFT section [here](../../introduction/installing-cometbft.mdx) for instructions on how to install CometBFT. ### Copy both the namada and CometBFT binaries to somewhere on $PATH (or use the relative paths). This step may or may not be necessary. - namada binaries can be found in `/target/release` - CometBFT is likely in `$HOME/Downloads/cometbft` -</Steps> +< /Steps> ## Check ports -<Steps> +< Steps > ### Open ports on your machine: - 26656 - 26657 @@ -66,6 +66,6 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Make sure you are using the correct CometBFT version - `cometbft version` should output `0.37.2` - Make sure you are using the correct Namada version - - `namada --version` should output `Namada v0.31.5` + - `namada --version` should output `Namada v0.31.6` -</Steps> +< /Steps> diff --git a/packages/docs/pages/networks/testnets/testnet-history.mdx b/packages/docs/pages/networks/testnets/testnet-history.mdx index b1833891..ef0dc9eb 100644 --- a/packages/docs/pages/networks/testnets/testnet-history.mdx +++ b/packages/docs/pages/networks/testnets/testnet-history.mdx @@ -6,7 +6,7 @@ This page covers all installation steps required by various upgrades to testnets ## Latest Upgrade -## Namada shielded expedition 2 `v0.31.5` upgrade +## Namada shielded expedition 2 `v0.31.6` upgrade In order to upgrade to the latest version of the Namada protocol, please follow the steps from [this hackmd](https://hackmd.io/EBTtfPiZT7yoRjxYRcbiPQ) @@ -14,7 +14,7 @@ In order to upgrade to the latest version of the Namada protocol, please follow - Namada Shielded expedition 2: - From date: 6th of February 2024 18:00 UTC - - Namada protocol version: `v0.31.5` + - Namada protocol version: `v0.31.6` - Cometbft version: `0.37.2` - CHAIN_ID: `shielded-expedition.88f17d1d14`