diff --git a/packages/docs/pages/index.mdx b/packages/docs/pages/index.mdx index 99653ab7..aef49e30 100644 --- a/packages/docs/pages/index.mdx +++ b/packages/docs/pages/index.mdx @@ -11,13 +11,11 @@ Namada's cryptographical features give users asset-agnostic, multichain data pro - Zcash-like shielded transfers for any assets (fungible and non-fungible) - Rewards for keeping assets in the shielded set -- Interoperability with Ethereum via a custom bridge with trust-minimization ## Overview of features - [Proof-of-Stake](./introduction/protocol-intro.mdx) with [governance](./users/governance.mdx) to secure and evolve Namada - Fast-finality BFT with 4-second blocks -- Trust-minimized 2-way Ethereum bridge - IBC connections to chains that already speak IBC (all Cosmos chains) - [Multi-Asset Shielded Pool](./users/shielded-accounts/shielded-transfers.mdx) (MASP) - Convert Circuit ([shielded set rewards](./users/shielded-accounts/shielded-rewards.mdx)) diff --git a/packages/docs/pages/integrating-with-namada/light-sdk/usage/transactions.mdx b/packages/docs/pages/integrating-with-namada/light-sdk/usage/transactions.mdx index 0ecc2a81..88c2e0b6 100644 --- a/packages/docs/pages/integrating-with-namada/light-sdk/usage/transactions.mdx +++ b/packages/docs/pages/integrating-with-namada/light-sdk/usage/transactions.mdx @@ -3,7 +3,6 @@ The transaction module exposes various modules (objects) to construct transactio ```rust pub mod account; // contains functions to create transactions for account module -pub mod bridge; // contains functions to create transactions for bridge module pub mod governance; // contains functions to create transactions for governance module pub mod ibc; // contains functions to create transactions for ibc module pub mod pgf; // contains functions to create transactions for pgf module @@ -57,20 +56,6 @@ impl InitAccount { A public key can be constructed from a string using the `::from_str()` method. The `vp_code_hash` is a hash that is found under the `wasm` folder. -### Bridge - -```rust -pub use namada_sdk::eth_bridge_pool::{GasFee, TransferToEthereum}; -pub struct BridgeTransfer(Tx); -impl BridgeTransfer { - pub fn new( - transfer: TransferToEthereum, - gas_fee: GasFee, - args: GlobalArgs, - ) -> Self {...} -} -``` - ### Governance ```rust diff --git a/packages/docs/pages/introduction/install/binaries/overview-of-binaries.mdx b/packages/docs/pages/introduction/install/binaries/overview-of-binaries.mdx index 93b941b0..e2091514 100644 --- a/packages/docs/pages/introduction/install/binaries/overview-of-binaries.mdx +++ b/packages/docs/pages/introduction/install/binaries/overview-of-binaries.mdx @@ -10,7 +10,6 @@ Once installed, you should have the following binaries: | `namadan` | The ledger node | | `namadac` | The client | | `namadaw` | The wallet | -| `namadar` | The ethereum bridge relayer | The main binary `namada` has sub-commands for all of the other binaries. Therefore, the following commands are equivalent: @@ -19,7 +18,6 @@ The main binary `namada` has sub-commands for all of the other binaries. Therefo | `namada client` | `namadac` | | `namada node` | `namadan` | | `namada wallet` | `namadaw` | -| `namada relayer` | `namadar` | To explore the command-line interface, the `--help` argument can be added at any sub-command level to find out any possible sub-commands and/or arguments. diff --git a/packages/docs/pages/introduction/privacy.mdx b/packages/docs/pages/introduction/privacy.mdx index 06bdf60a..3ed6ea73 100644 --- a/packages/docs/pages/introduction/privacy.mdx +++ b/packages/docs/pages/introduction/privacy.mdx @@ -6,7 +6,7 @@ Namada provides the largest possible unified shielded set in the multichain, com * Namada can also seed data protection to users who want to use an asset originating from one base chain on another chain, without losing data protection * Namada retrofits data protection to assets that were created and already used in transparent chains -Users should be aware that they can still expose personal information when transferring funds into and out of Namada via the Ethereum bridge or IBC. For example, a user bridging WETH from Ethereum may be able to obfuscate their on-chain identities to *some* on-chain observers by interacting with Smart contract based shielding protocols or centralized exchanges. However, a user transferring a non-fungible token or a low liquidity token that relies on price discovery on-chain, will leak more information by the nature of their asset holdings. This is also true of tokens transferred into and out of Namada via IBC. Once inside the shielded set, a user can perform *shielded actions* such as triggering a cross chain swap. +Users should be aware that they can still expose personal information when transferring funds into and out of Namada via IBC. For example, a user bridging WETH from Ethereum may be able to obfuscate their on-chain identities to *some* on-chain observers by interacting with Smart contract based shielding protocols or centralized exchanges. However, a user transferring a non-fungible token or a low liquidity token that relies on price discovery on-chain, will leak more information by the nature of their asset holdings. This is also true of tokens transferred into and out of Namada via IBC. Once inside the shielded set, a user can perform *shielded actions* such as triggering a cross chain swap. Shielded actions are not limited to application chains that are IBC compatible, it works with any chain that is connected to Namada, e.g. Ethereum, and the actions can be generalized to interact with any dApp, such as trading NFTs or staking ETH. For the time being, the only shielded action available is cross chain transfers, but more will be added in the future. diff --git a/packages/docs/pages/networks/testnets/faq.mdx b/packages/docs/pages/networks/testnets/faq.mdx index 7cab9d10..b684b276 100644 --- a/packages/docs/pages/networks/testnets/faq.mdx +++ b/packages/docs/pages/networks/testnets/faq.mdx @@ -17,10 +17,6 @@ There are a few more, but we leave it to you as a challenge to find out which these are 🤔 HINT: `namadac balance` -### **Q: How do I use the Ethereum Bridge?** - -**A:** The Ethereum Bridge is not yet implemented. Keep an eye on the [Changelog](https://github.com/anoma/namada/tree/main/.changelog) 👀 to see when it will be officially released. - ### **Q: How can I make an IBC transfer?** **A:** As of `v0.23.1` you can now follow the docs [here!](../../users/ibc.mdx) diff --git a/packages/docs/pages/operators/eth-bridge.mdx b/packages/docs/pages/operators/eth-bridge.mdx deleted file mode 100644 index 1d0e92a8..00000000 --- a/packages/docs/pages/operators/eth-bridge.mdx +++ /dev/null @@ -1,27 +0,0 @@ -# Namada Ethereum Bridge - -The ethereum bridge on Namada is a trustless (in the sense that the only trust assumptions are that validators on Namada are collectively honest) bridge between Namada and Ethereum. - -The bridge is a combination of smart contracts on Ethereum as well as ledger protocol code that enables its functionality. The bridge is designed to be generic, and can be used to bridge any chain that has a BFT consensus mechanism. - - -## Design - -The full design specs can be found [here](https://specs.namada.net/modules/ethereum-bridge). - -A short outline of the design is outlined below. - -## The ethereum side - -Value transferred to the Namada is escrowed in a vault abstraction, which -enables other contracts to be upgraded without moving value around. When ERC20 -tokens are transferred back to Ethereum, value is released from escrow into the -destination accounts. - -## The Namada side - -When a transfer is initiated from Ethereum to Namada, the transfer is validated by the validators. Once this validation is complete, the transferred funds are minted on the Namada side and sent to the destination account. When tokens are sent back to Ethereum, they are burnt on the Namada end. - -This documentation is intended for relayers and validators on Namada and is structured as follows: - -- [Relaying transactions](./eth-bridge/relaying.mdx) \ No newline at end of file diff --git a/packages/docs/pages/operators/eth-bridge/relaying.mdx b/packages/docs/pages/operators/eth-bridge/relaying.mdx deleted file mode 100644 index 553a4142..00000000 --- a/packages/docs/pages/operators/eth-bridge/relaying.mdx +++ /dev/null @@ -1,48 +0,0 @@ -import { Callout } from 'nextra-theme-docs' - -# Relaying Ethereum Transactions - -Relayer commands are found in the `namadar` binary, which at the moment can only be installed from source. - -## Relaying validator set updates - -In order for any transactions to be relayed to the Ethereum smart contract, the validator sets need to be up to date on the Ethereum side. This is updated by a relayer which can be set up in the following manner: - -```bash copy -namadar validator-set relay --daemon --confirmations 1 --retry-sleep 0 --success-sleep 0 --safe-mode -``` - -The `--safe-mode` flag is optional, but recommended. It will stop the relayer from being shut down by `^C` and will instead wait for the current batch of transactions to be relayed before shutting down. - -More optional flags are available, which can be found by running `namadar validator-set relay --help`. Notably, `--eth-gas`and `--eth-gas-price` will allow you to set the maximum gas-limit and gas-price, respectively, that the relayer will use when relaying transactions to the Ethereum smart contract. - -## Relaying transactions - -Transactions are relayed in batches. The relayer will wait until it has a batch of transactions to relay before sending them to the Ethereum smart contract. This is done to reduce the number of transactions that need to be sent to the Ethereum smart contract, and thus reduce the gas costs. - -The relayer can get a "recommended-batch" of signed transactions to relay by running: - -```bash -namadar ethereum-bridge-pool recommend-batch -``` - -If this is favourable for the relayer, it can construct the proof and relay it to the Ethereum smart contract by running: - -```bash -namadar ethereum-bridge-pool relay-proof --hash-list $HASH_LIST -``` - - -As this involves an Ethereum transaction, the `--eth-gas` and `--eth-gas-price` flags are also available here. - - -Alternatively, the relayer can run the command: - -```bash -namadar ethereum-bridge-pool construct-proof --hash-list $HASH_LIST -``` - -To only construct the proof without relaying it. The proof could then be relayed manually by the relayer. - - - diff --git a/packages/docs/pages/users/governance/on-chain-governance.mdx b/packages/docs/pages/users/governance/on-chain-governance.mdx index c7b346ae..1cd6a283 100644 --- a/packages/docs/pages/users/governance/on-chain-governance.mdx +++ b/packages/docs/pages/users/governance/on-chain-governance.mdx @@ -173,17 +173,6 @@ 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):