-
Notifications
You must be signed in to change notification settings - Fork 78
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
update masp and ibc user sections (#353)
update masp and ibc user sections
- Loading branch information
Showing
15 changed files
with
430 additions
and
314 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,11 @@ | ||
{ | ||
"wallet": "Using the Namada wallet", | ||
"transparent-accounts": "Transparent accounts", | ||
"shielded-accounts": "The MASP", | ||
"transparent-accounts": "Transparent Accounts", | ||
"shielded-accounts": "MASP & Shielded Transfers", | ||
"fees": "Fees on Namada", | ||
"delegators": "Bonding and Proof-of-stake", | ||
"governance": "Governance and Public Goods Funding", | ||
"public-goods-stewards": "PGF", | ||
"ibc": "IBC transfers", | ||
"query": "Querying the chain" | ||
"query": "Querying the Chain" | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,120 +1,18 @@ | ||
import { Callout } from 'nextra-theme-docs' | ||
|
||
# Transferring assets over IBC | ||
# Transferring Assets over IBC | ||
|
||
It is possible to make ibc transfers using the Namada cli with the command `namadac ibc-transfer`. The assumed pre-requisites are that a channel has been created and Hermes is running with the proper config on two nodes. | ||
Namada features full IBC protocol support, which means non-native assets can be brought over from any IBC compatible | ||
chain (such as Cosmos SDK chains). As a result, users can enjoy the combined benefits of another chain's ecosystem, assets | ||
and features with Namada's [MASP](./shielded-accounts/). | ||
|
||
In order to conduct an IBC transfer using Namada's `ibc-transfer` command, we will need to know the `base-dir` and `node` of each instance (and other transfer parameters). | ||
`base-dir` is the base directory of each node, see [base-dir](../operators/ledger/base-directory.mdx) for more information. | ||
`node` is the `rpc_addr` of the relayer. | ||
You can run | ||
```shell | ||
grep "rpc_addr" ${HERMES_CONFIG} | ||
``` | ||
to find the address. | ||
The assumed prerequisites are that an active IBC connection has been created and maintained between the two chains by | ||
operators running relayer software such as [Hermes](https://github.com/heliaxdev/hermes). | ||
|
||
<Callout> | ||
**For the local node ONLY** | ||
This section will be focused on IBC transfers from a user perspective. For info on operating an IBC relayer, see | ||
[this](../operators/ibc.mdx) page in the Operators section. | ||
|
||
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)" | ||
``` | ||
</Callout> | ||
|
||
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" | ||
``` | ||
|
||
The inter-blockchain transfers from Chain A can be achieved by | ||
```bash copy | ||
namadac --base-dir ${BASE_DIR_A} | ||
ibc-transfer \ | ||
--amount ${AMOUNT} \ | ||
--source ${SOURCE_ALIAS} \ | ||
--receiver ${RECEIVER_RAW_ADDRESS} \ | ||
--token ${TOKEN_ALIAS} \ | ||
--channel-id ${CHANNEL_ID} \ | ||
--node ${LEDGER_ADDRESS_A} | ||
``` | ||
Where the above variables in `${VARIABLE}` must be substituted with appropriate values. The raw address of the receiver can be found by `namadaw --base-dir ${BASE_DIR_B} address find --alias ${RECEIVER}`. | ||
|
||
E.g. | ||
```bash copy | ||
namadac --base-dir ${BASE_DIR_A} | ||
ibc-transfer \ | ||
--amount 100 \ | ||
--source albert \ | ||
--receiver atest1d9khqw36g56nqwpkgezrvvejg3p5xv2z8y6nydehxprygvp5g4znj3phxfpyv3pcgcunws2x0wwa76 \ | ||
--token nam \ | ||
--channel-id channel-0 \ | ||
--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). | ||
|
||
## Transferring assets back from Cosmos-SDK based chains | ||
|
||
When a transfer has been made to a Cosmos-SDK based chain, the ibc transfer is conducted as above. However, when transferring back from the cosmos-based chain, clearly the `namadac ibc-transfer` command will not work. Instead, you want to use [`gaiad`](https://github.com/cosmos/gaia). | ||
|
||
```bash | ||
gaiad tx ibc-transfer transfer transfer ${CHANNEL_ID} ${RECEIVER_RAW_ADDRESS} ${AMOUNT}${IBC_TOKEN_ADDRESS} --from ${COSMOS_ALIAS} --node ${COSMOS_RPC_ENDPOINT} --fees 5000uatom | ||
``` | ||
|
||
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 | ||
``` | ||
|
||
## 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} | ||
``` | ||
### Resources | ||
- [How IBC Works](https://www.ibcprotocol.dev/how-ibc-works): A brief, beginner-friendly overview of IBC | ||
- [What is IBC?](https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html): A detailed, developer-focused look | ||
at the design and functionality of the protocol |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
{ | ||
"shielded-ibc": "Shielded IBC", | ||
"transparent-ibc": "Transparent IBC" | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,70 @@ | ||
import { Callout } from 'nextra-theme-docs' | ||
|
||
# Shielded IBC | ||
|
||
You can send assets to another IBC compliant chain, such as a Cosmos SDK chain or another Namada chain, using the | ||
`ibc-transfer` command in `namadac`. | ||
|
||
This section covers sending assets to and from a shielded ( `znam` ) address. | ||
|
||
## Prerequisites | ||
|
||
- An active IBC connection has been created and maintained between the two chains by operators running relayer | ||
software such as [Hermes](https://github.com/heliaxdev/hermes). | ||
- You will need to know the corresponding channel id | ||
|
||
## IBC transfer to a shielded address | ||
{/* TODO: instructions are out of date? */} | ||
|
||
Before sending your IBC transfer, you will need to generate a MASP | ||
|
||
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} | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
import { Callout } from 'nextra-theme-docs' | ||
|
||
# Transparent IBC | ||
|
||
You can send assets to another IBC compliant chain, such as a Cosmos SDK chain or another Namada chain, using the | ||
`ibc-transfer` command in `namadac`. | ||
|
||
This section covers sending assets to and from a transparent ( `tnam` ) address. | ||
|
||
## Prerequisites | ||
|
||
- An active IBC connection has been created and maintained between the two chains by operators running relayer | ||
software such as [Hermes](https://github.com/heliaxdev/hermes). | ||
- You will need to know the corresponding channel id | ||
|
||
## IBC transfers from Namada to another chain | ||
|
||
To make an outgoing IBC transfer from a Namada transparent address: | ||
```bash copy | ||
namadac ibc-transfer \ | ||
--source <your-transparent-address> \ | ||
--receiver <address-on-receiving-chain> \ | ||
--token <token-address> \ | ||
--amount <amount> | ||
--channel-id <channel-id> | ||
``` | ||
Note: | ||
- the `receiver` address is the address on the receiving chain -- if you are sending to another Namada chain, this would start with `tnam...`, | ||
while if you're sending to a Cosmos SDK chain it might start with `cosmos...` or some other prefix. | ||
- the `channel-id` parameter is a string, for example `channel-27`. | ||
|
||
#### Example: Sending NAM to the Cosmos Hub | ||
```bash copy | ||
namadac ibc-transfer \ | ||
--source my-namada-wallet \ | ||
--receiver cosmos1y3q368qj8d2ged5xcdz96wtt3n5f9zq6ql0p7k \ | ||
--token nam \ | ||
--amount 10 \ | ||
--channel-id channel-42 | ||
``` | ||
|
||
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 into Namada from Cosmos SDK chains | ||
|
||
To transfer assets back from a Cosmos SDK chain, you will post an IBC transaction on that chain using its corresponding | ||
client software. | ||
|
||
For the Cosmos Hub, you will use [`gaiad`](https://github.com/cosmos/gaia). Other chains will have their own corresponding client; | ||
however all Cosmos SDK based clients will share approximately the same commands and operation. Consult the documentation | ||
of the counterparty chain when in doubt. | ||
|
||
#### Example: Sending ATOM from the Cosmos Hub to Namada | ||
|
||
```bash | ||
gaiad tx ibc-transfer transfer \ | ||
transfer \ | ||
channel-64 \ | ||
tnam1qzgmrvz0zdjtgdu7yq6hl46wdg7za2t2hg5t85c7 \ | ||
10000000uatom \ | ||
--from my-cosmos-wallet \ | ||
--fees 5000uatom | ||
``` | ||
<Callout> | ||
The double use of 'transfer' in the above command is not a typo. The command takes an IBC port name as one of its parameters; | ||
and the name of the port happens to be 'transfer'. | ||
</Callout> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,51 +1,53 @@ | ||
# **Query** | ||
# Querying Overview | ||
|
||
This is the complete query related to Namada | ||
Querying a Namada chain is done using the client `namadac`. | ||
|
||
Including: account,pgf,proposal,proposal-result,proposal-votes | ||
This section details several common queries; see all available commands with `namadac --help`. | ||
|
||
## query-account | ||
#### query-account | ||
|
||
```txt | ||
namadac query-account --owner <WALLET> | ||
``` | ||
|
||
Return the results will return the `Threshold` and `Public` key of the address. | ||
Returns the `Threshold` and `Public` key(s) of an established account. | ||
|
||
## query-pgf | ||
#### query-pgf | ||
|
||
``` | ||
namadac query-pgf | ||
``` | ||
|
||
Return the results will return the `Pgf stewards , Reward distribution`, `Pgf fundings` key of the address. | ||
Returns the list of PGF Stewards, their reward distribution, and active PGF streaming payments. | ||
|
||
## query-proposal | ||
#### query-proposal | ||
|
||
``` | ||
namadac query-proposal --proposal-id <ID> | ||
``` | ||
|
||
Return the results will return the PGF type of the proposal, `author`, `content`, `StartEpoch`, `EndEpoch`, `GraceEpoch`, `Status` | ||
Returns info on a given proposal, including its type, author, content, StartEpoch, EndEpoch, GraceEpoch, and Status. | ||
|
||
## query-proposal-result | ||
#### query-proposal-result | ||
|
||
``` | ||
namadac query-proposal-result --proposal-id <ID> | ||
``` | ||
|
||
Return the results will return the outcome of the proposal, whether it's `Passed` or `Rejected`, including the total number of votes for `yay`, `nay`, `abstain`, and the threshold (fraction) of the total voting power needed to tally. | ||
Returns the outcome of a given proposal, including whether it's Passed/Rejected, the total number of votes for yay/nay/abstain, and the threshold (fraction) of the total voting power needed to tally. | ||
|
||
## query-proposal-votes | ||
#### query-proposal-votes | ||
|
||
``` | ||
namadac query-proposal-votes --proposal-id <ID> | ||
``` | ||
|
||
Return the results of all wallets that have voted `yay` or `nay` on the proposal | ||
Returns the results of all wallets that have voted `yay` or `nay` on the proposal | ||
|
||
``` | ||
namadac query-proposal-votes --proposal-id <ID> --voter <WALLET> | ||
``` | ||
|
||
Return the result of a specific wallet that has voted on a specific proposal | ||
Returns the result of a specific wallet that has voted on a specific proposal | ||
|
||
{/* TODO: add more queries*/} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,8 +1,26 @@ | ||
# The MASP | ||
|
||
The multi-asset shielded pool (MASP) is a zero knowledge circuit that allows users to make transfers in a way that does not reveal the sender, receiver, or amount. Each transfer is a zero knowledge proof itself, and is often referred to as a "note". From the users perspective, the construction of these zero knowledge proofs occur behind the scenes. | ||
Namada affords users data-protection through its multi-asset shielded pool (MASP), which supports shielded transfers with any native or non-native asset. | ||
The MASP is a zero-knowledge circuit ([zk-SNARK](https://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof)) that | ||
extends the [Zcash Sapling circuit](https://raw.githubusercontent.com/zcash/zips/master/protocol/sapling.pdf) to add support for sending arbitrary | ||
assets. All assets in the pool share the same anonymity set -- meaning that the more transactions are issued to MASP, the stronger the | ||
data protection guarantees for all users. | ||
|
||
The MASP is inspired by the work produced by the Electric Coin Company (ECC) who developed Zcash, and builds on the Sapling Circuit by implementing multi-asset functionality. In addition to the MASP, Namada has also implemented a zero knowledge circuit for rewarding shielded set contributions in a shielded manner. This circuit is called the Convert Circuit (CC for short). | ||
The MASP allows users to make transfers in a way that does not reveal the sender, receiver, or amount. Each transfer is a zero knowledge proof itself, and is often referred to as a "note". | ||
From the users perspective, the construction of these zero knowledge proofs occur behind the scenes. | ||
|
||
More technical details of these circuits can be found in the [specs](https://specs.namada.net) as well as [this blog post](https://namada.net/blog/understanding-the-masp-and-cc-circuits). | ||
Users of the MASP are [rewarded](./shielded-accounts/shielded-rewards.mdx) for their contributions to the shielded set in the form of native protocol tokens (NAM). | ||
|
||
### Inspiration | ||
|
||
The MASP is inspired by the work produced by the Electric Coin Company (ECC) who developed Zcash, and builds on the Sapling Circuit by implementing multi-asset functionality. | ||
In addition to the MASP, Namada has also implemented a zero knowledge circuit for rewarding shielded set contributions in a shielded manner. | ||
This circuit is called the Convert Circuit (CC for short). | ||
|
||
If you are familiar with Zcash, the set of interactions you can execute with Namada's MASP are similar: | ||
- [Shielding transfers](./shielded-accounts/shielding.mdx): transparent to shielded address | ||
- [Shielded transfers](./shielded-accounts/shielded-transfers.mdx): shielded to shielded address | ||
- [Unshielding transfers](./shielded-accounts/unshielding.mdx): shielded to transparent address | ||
|
||
More technical details of these circuits can be found in the [specs](https://specs.namada.net/modules/masp) as well as [this blog post](https://namada.net/blog/understanding-the-masp-and-cc-circuits). | ||
|
Oops, something went wrong.