diff --git a/docs/conrefs/cementing-delay.md b/docs/conrefs/_cementing-delay.md similarity index 100% rename from docs/conrefs/cementing-delay.md rename to docs/conrefs/_cementing-delay.md diff --git a/docs/conrefs/gas-price-warning.md b/docs/conrefs/_gas-price-warning.md similarity index 100% rename from docs/conrefs/gas-price-warning.md rename to docs/conrefs/_gas-price-warning.md diff --git a/docs/conrefs/rate-limit.md b/docs/conrefs/_rate-limit.md similarity index 100% rename from docs/conrefs/rate-limit.md rename to docs/conrefs/_rate-limit.md diff --git a/docs/evm/bridging/bridging-evm.mdx b/docs/evm/bridging/bridging-evm.mdx index 423c144e..d1f096b7 100644 --- a/docs/evm/bridging/bridging-evm.mdx +++ b/docs/evm/bridging/bridging-evm.mdx @@ -8,9 +8,9 @@ import Video from '@site/src/components/Video'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -[The Etherlink EVM{/* TEVM */} bridge](https://bridge.etherlink.com/evm) is a web application that allows you to transfer wrapped tokens between Etherlink EVM{/* TEVM */} and several other EVM-compatible blockchain networks. +[The Etherlink EVM bridge](https://bridge.etherlink.com/evm) is a web application that allows you to transfer wrapped tokens between Etherlink EVM and several other EVM-compatible blockchain networks. -The EVM bridge supports connections from Etherlink EVM{/* TEVM */} to these networks: +The EVM bridge supports connections from Etherlink EVM to these networks: - Ethereum - Avalanche C-Chain @@ -29,15 +29,15 @@ It allows users to transfer several wrapped tokens, including: - WBNB - SHIB -For the Etherlink EVM{/* TEVM */} addresses of these tokens, see [Token addresses](#token-addresses). +For the Etherlink EVM addresses of these tokens, see [Token addresses](#token-addresses). -Etherlink EVM{/* TEVM */}'s LayerZero bridge infrastructure also supports a number of tokens that meet their [Omnichain Fungible Token (OFT)](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) standard. -The token addresses for OFTs that can be transferred between Etherlink EVM{/* TEVM */} and other networks (including WXTZ) can be retrieved from the [LayerZero API](https://docs.layerzero.network/v2/tools/api/oft), or are listed [here](#token-addresses). +Etherlink EVM's LayerZero bridge infrastructure also supports a number of tokens that meet their [Omnichain Fungible Token (OFT)](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) standard. +The token addresses for OFTs that can be transferred between Etherlink EVM and other networks (including WXTZ) can be retrieved from the [LayerZero API](https://docs.layerzero.network/v2/tools/api/oft), or are listed [here](#token-addresses). ## Bridge security The bridge uses the decentralized smart contracts of [LayerZero](https://layerzero.network/) that are deployed on the supported EVM networks without the intervention of a third party. -It also relies on the EVM node{/* TXN */} and sequencer operators that secure Etherlink{/* TX */} itself; these operators are listed in [Network operators](/network/operators). +It also relies on the EVM node and sequencer operators that secure Etherlink itself; these operators are listed in [Network operators](/network/operators). ## Using the EVM bridge @@ -45,11 +45,11 @@ For a video walkthrough of the bridge, see [this video](https://www.loom.com/sha ![Overview of the EVM bridge](/img/wab-details.png) -1. Go to the Etherlink EVM{/* TEVM */} bridge at https://bridge.etherlink.com/evm. +1. Go to the Etherlink EVM bridge at https://bridge.etherlink.com/evm. 1. Click the **Connect** button and connect your EVM wallet. -1. Select the source network from which to bridge tokens to Etherlink EVM{/* TEVM */}, or select Etherlink EVM{/* TEVM */} as the source network to bridge tokens out of Etherlink EVM{/* TEVM */}. +1. Select the source network from which to bridge tokens to Etherlink EVM, or select Etherlink EVM as the source network to bridge tokens out of Etherlink EVM. 1. Next to the source network, click the source token and select the token to transfer from the source network. The interface shows all bridgeable tokens across all available networks and your token balances. @@ -65,8 +65,8 @@ The interface shows all bridgeable tokens across all available networks and your 1. Set the other parameters for the transfer, including the **Gas on destination** and **Slippage tolerance** fields. :::note[Gas on destination] - Interacting with Etherlink EVM{/* TEVM */} requires XTZ (its native token) to pay for gas fees. - As part of your bridging transaction, you can choose to send up to 0.1 XTZ to your Etherlink EVM{/* TEVM */} wallet address to pay for fees for later transactions and interact with the Etherlink EVM{/* TEVM */} ecosystem. + Interacting with Etherlink EVM requires XTZ (its native token) to pay for gas fees. + As part of your bridging transaction, you can choose to send up to 0.1 XTZ to your Etherlink EVM wallet address to pay for fees for later transactions and interact with the Etherlink EVM ecosystem. The cost of this XTZ is added to the fees that you pay for the transfer. By default, the bridge adds 0.1 XTZ if the destination account has no XTZ. ::: @@ -98,7 +98,7 @@ The transfer button can show these errors: - **Select Different Chain** The source and destination chains are not compatible. - This bridge is for moving tokens in and out of Etherlink EVM{/* TEVM */}, not for moving tokens between other networks. + This bridge is for moving tokens in and out of Etherlink EVM, not for moving tokens between other networks. - **Transfer Cap Reached** @@ -106,24 +106,24 @@ The transfer button can show these errors: Select a smaller amount to transfer. This error can occur for bridgeable tokens that exist on multiple networks (ETH/WETH, USDT and USDC). - For example, if the bridge contract on Avalanche has 100 USDT, you can transfer no more than 100 USDT from Etherlink EVM{/* TEVM */} to Avalanche. + For example, if the bridge contract on Avalanche has 100 USDT, you can transfer no more than 100 USDT from Etherlink EVM to Avalanche. For further support, visit the [LayerZero Discord](https://discord.gg/ktbvm8Nkcr). -If you have general questions about Etherlink{/* TX */}, we welcome you to join the [Etherlink{/* TX */} Discord Community](https://discord.com/invite/etherlink). +If you have general questions about Etherlink, we welcome you to join the [Etherlink Discord Community](https://discord.com/invite/etherlink). ## Token addresses :::note -Not all Etherlink EVM{/* TEVM */} tokens can be bridged to and from other chains. +Not all Etherlink EVM tokens can be bridged to and from other chains. See the bridge UI for the tokens that the bridge supports for each chain. ::: -### Etherlink EVM{/* TEVM */} +### Etherlink EVM -This table shows the Etherlink EVM{/* TEVM */} address of some of the tokens you can bridge between Etherlink EVM{/* TEVM */} and certain other chains: +This table shows the Etherlink EVM address of some of the tokens you can bridge between Etherlink EVM and certain other chains: @@ -396,17 +396,79 @@ These tables show the addresses of the equivalent tokens on other networks: ## How bridging wrapped assets works -The Etherlink EVM{/* TEVM */} bridge uses a [wrapped asset bridge](https://github.com/LayerZero-Labs/wrapped-asset-bridge) created by [LayerZero](https://layerzero.network/). -It works by maintaining liquidity pools on other networks and minting equivalent tokens on Etherlink EVM{/* TEVM */}. +The Etherlink EVM bridge uses a [wrapped asset bridge](https://github.com/LayerZero-Labs/wrapped-asset-bridge) created by [LayerZero](https://layerzero.network/). +It works by maintaining liquidity pools on other networks and minting equivalent tokens on Etherlink EVM. -When you bridge tokens from other networks to Etherlink EVM{/* TEVM */}, the bridge contracts lock the tokens in a liquidity pool on the source network, send a message over LayerZero's software to Etherlink EVM{/* TEVM */}, and mint tokens on Etherlink EVM{/* TEVM */}. -When you bridge tokens out of Etherlink EVM{/* TEVM */}, the contracts burn the tokens on Etherlink EVM{/* TEVM */} and unlock them in the liquidity pool on the target network. -Therefore, bridging tokens out of Etherlink EVM{/* TEVM */} is dependent on the liquidity pool on the target chain. -LayerZero also maintains EVM nodes{/* TXN */} to verify that the transactions complete on Etherlink EVM{/* TEVM */}. +When you bridge tokens from other networks to Etherlink EVM, the bridge contracts lock the tokens in a liquidity pool on the source network, send a message over LayerZero's software to Etherlink EVM, and mint tokens on Etherlink EVM. +When you bridge tokens out of Etherlink EVM, the contracts burn the tokens on Etherlink EVM and unlock them in the liquidity pool on the target network. +Therefore, bridging tokens out of Etherlink EVM is dependent on the liquidity pool on the target chain. +LayerZero also maintains EVM nodes to verify that the transactions complete on Etherlink EVM. This diagram shows how the EVM bridge works: -![Overview of the EVM bridge, showing the interaction between contracts on other chains and Etherlink EVM{/* TEVM */}, moderated by LayerZero](/img/wrapped-asset-bridge.png) + + + + + + + + + + + + + + + CLIENTS + + User's EVM + wallet + + Wrapped asset + bridge web app + + OTHER EVM CHAINS + + Wrapped asset + bridge contracts + + LAYERZERO + + LayerZero + relayer + + HIGH-LATENCY NODE + + Etherlink EVM node + + Etherlink Smart + Rollup node + + ETHERLINK + + Wrapped asset + bridge contracts + + use app, + sign txs + + tokens + + transactions + + tokens + + transactions + + transactions + + transactions + + verify L1 + finality + trusts only layer-1-final state + {/* https://lucid.app/lucidchart/cac80916-85c8-455d-b50b-f265057dcc1b/edit */} For more information, see the repository for the bridge: https://github.com/LayerZero-Labs/wrapped-asset-bridge. @@ -425,7 +487,7 @@ Developers can integrate these contracts into their own cross-chain bridge if re - + @@ -457,7 +519,7 @@ Developers can integrate these contracts into their own cross-chain bridge if re ## LayerZero endpoints for OFTs -LayerZero uses these contracts to connect Etherlink EVM{/* TEVM */} to its network for tokens that meet their Omnichain Fungible Token (OFT) standard. +LayerZero uses these contracts to connect Etherlink EVM to its network for tokens that meet their Omnichain Fungible Token (OFT) standard. For more information, see [Deployed Endpoints, Message Libraries, and Executors](https://docs.layerzero.network/v2/deployments/deployed-contracts?chains=etherlink). @@ -538,7 +600,7 @@ For more information, see [Deployed Endpoints, Message Libraries, and Executors] ## Related tools and information - For information about pending transactions, see the [LayerZero Cross Chain Explorer](https://layerzeroscan.com/). -- For information about Etherlink EVM{/* TEVM */} transactions, see the [Etherlink EVM{/* TEVM */} block explorer](https://explorer.etherlink.com/). +- For information about Etherlink EVM transactions, see the [Etherlink EVM block explorer](https://explorer.etherlink.com/). - More Information about the LayerZero protocol is available in their [official documentation](https://docs.layerzero.network/). - The audit reports of the LayerZero protocol are available in this [LayerZero GitHub Repository](https://github.com/LayerZero-Labs/LayerZero/tree/main/audit). - To review the open source code of the EVM bridge, visit the [LayerZero Github Repository](https://github.com/LayerZero-Labs/wrapped-asset-bridge). diff --git a/docs/evm/bridging/bridging-fa-how.md b/docs/evm/bridging/bridging-fa-how.md index 896799fb..088bc5ef 100644 --- a/docs/evm/bridging/bridging-fa-how.md +++ b/docs/evm/bridging/bridging-fa-how.md @@ -59,7 +59,116 @@ For tokens supported by the bridge, an automated program calls the `claim` funct This diagram is an overview of the process of bridging tokens from layer 1 to Etherlink EVM: -Overview of the FA token bridging deposit process + + + + + + + + + + + + + + + CLIENTS + + User's Tezos + wallet + + Any user + + User's EVM + wallet + + TEZOS LAYER 1 + + FA token + contract + + Ticketer + contract + + Token bridge + helper contract + + Smart Rollup inbox + + Delayed inbox + forced inclusion + + ETHERLINK + + Sequencer + + Null precompile + 0x0000…0000 + + FA bridging + precompile + 0xff00…0002 + + ERC-20 proxy + contract + + + 1 + allow access + + + 2 + send transaction: + - amount to bridge + - user's Etherlink + address + - Smart Rollup + address + + + 3 + transfer tokens + + + 4 + send tokens + + + 5 + send ticket + + lock tokens, create ticket + + + 6 + ticket + + data + + + + 7 + receive information + + + + 8 + send info + + + 9 + claim tokens + + + 10 + send info + + mint + + + 11 + send tokens + ## Withdrawing tokens from Etherlink EVM to layer 1 @@ -73,7 +182,7 @@ The process of bridging FA-compatible tokens from Etherlink EVM to la - The address of the ticketer contract on layer 1 - The content of the ticket to remove from the proxy contract (not the ticket itself) -1. The precompiled contract generates calls the withdrawal endpoint of the ERC-20 proxy contract. +1. The precompiled contract calls the withdrawal endpoint of the ERC-20 proxy contract. 1. The proxy contract sends the information about the withdrawal to the helper contract by putting it in a transaction in the Smart Rollup outbox. This transaction includes the target layer 1 address. @@ -82,14 +191,90 @@ This transaction includes the target layer 1 address. 1. When the commitment that contains the transaction is cemented on layer 1, anyone can run the transaction by running the Octez client `execute outbox message` command. -1. The helper contract receives the ticket from the originally deposited tokens and target address and stores the address. +1. The helper contract receives the ticket and the target layer 1 address from the outbox message and forwards them, unchanged, to the ticketer contract's `withdraw` entrypoint. -1. The helper contract sends the ticket to the ticketer contract's `withdraw` entrypoint. - -1. The ticketer contract burns the ticket and sends the tokens to the helper contract. - -1. The helper contract sends the tokens to the target layer 1 address. +1. The ticketer contract verifies and burns the ticket and sends the tokens directly to the target layer 1 address. This diagram is an overview of the process of bridging tokens from Etherlink EVM to layer 1: -Overview of the FA token bridging withdrawal process + + + + + + + + + + + + + + + CLIENTS + + User's Tezos + wallet + + Any user + via an Octez client + + User's EVM + wallet + + TEZOS LAYER 1 + + Ticketer + contract + + Token bridge + helper contract + + Smart Rollup + outbox + + ETHERLINK + + FA bridging + precompile + 0xff00…0002 + + ERC-20 proxy + contract + + + 1 + send transaction: + - amount + - layer 1 address + - ticket & contract + info + + + 2 + burn tokens + + + 3 + queue outbox message + + + 4 + trigger outbox message + after the commitment is cemented (~2 weeks) + + + 5 + send ticket + + + 6 + forward ticket + + burn ticket, + unlock tokens + + + 7 + send tokens + diff --git a/docs/evm/bridging/bridging-fa-transactions.md b/docs/evm/bridging/bridging-fa-transactions.md index bb892bac..8e1db9d0 100644 --- a/docs/evm/bridging/bridging-fa-transactions.md +++ b/docs/evm/bridging/bridging-fa-transactions.md @@ -78,7 +78,7 @@ Because the Etherlink EVM tokens are compatible with the ERC-20 stand ## Withdrawing FA tokens from Etherlink EVM to layer 1 It takes two transactions to withdraw an FA token back to layer 1: one to initiate the withdrawal and another to run the outbox transaction on Tezos layer 1. -As described in [Bridging FA tokens](/evm/bridging/bridging-fa), you must wait two weeks to run the outbox transaction due to the Smart Rollup refutation period. +As described in [Bridging FA tokens](/evm/bridging/bridging-fa), you must wait for the two-week Smart Rollup refutation period before running the outbox transaction (withdrawals complete in about 15 days end to end). Normally, an automated system run by Optimistic Labs runs these outbox transactions as soon as the refutation period is over, which sends the withdrawn tez to the layer 1 account. However, pending outbox transactions expire after a period equal to the refutation period. diff --git a/docs/evm/bridging/bridging-fa.md b/docs/evm/bridging/bridging-fa.md index bd7338d7..f89fd25b 100644 --- a/docs/evm/bridging/bridging-fa.md +++ b/docs/evm/bridging/bridging-fa.md @@ -3,7 +3,7 @@ title: Bridging FA tokens between Tezos layer 1 and Etherlink EVM # tevm sidebar_label: Bridging FA tokens --- -import CementingDelayNote from '@site/docs/conrefs/cementing-delay.md'; +import CementingDelayNote from '@site/docs/conrefs/_cementing-delay.md'; You can bridge FA standards-compliant tokens in and out of Etherlink EVM by deploying contracts that move the tokens. Then you can create dApps that use these contracts to move tokens or send a request to the Etherlink team to add your tokens to the bridge at https://bridge.etherlink.com/tezos. diff --git a/docs/evm/bridging/bridging-tezos.md b/docs/evm/bridging/bridging-tezos.md index 4fef4626..137298b3 100644 --- a/docs/evm/bridging/bridging-tezos.md +++ b/docs/evm/bridging/bridging-tezos.md @@ -3,7 +3,7 @@ title: Bridging XTZ between Tezos layer 1 and Etherlink EVM # tevm sidebar_label: Bridging to Tezos --- -import CementingDelayNote from '@site/docs/conrefs/cementing-delay.md'; +import CementingDelayNote from '@site/docs/conrefs/_cementing-delay.md'; You can bridge XTZ tokens from Tezos layer 1 to Etherlink EVM and back. XTZ is the native token on Etherlink EVM and Tezos, which is called tez and shown on price tickers with the symbol [XTZ](https://coinmarketcap.com/currencies/tezos/). @@ -80,13 +80,77 @@ The request includes the tez to bridge, the address of the Etherlink Sm This diagram is an overview of the deposit process: -![Overview of the token bridging deposit process](/img/bridging-deposit.png) + + + + + + + + + + + + + + + CLIENTS + + User's Tezos + wallet + + User's EVM + wallet + + TEZOS LAYER 1 + + Bridge contract + + Exchanger + contract + + ETHERLINK + + Kernel + + + 1 + send transaction: + - amount of tez + - user's Etherlink + address + - Smart Rollup + address + + + 2 + send tez + + + 3 + lock tez, + create ticket + + + 4 + send ticket + + + 5 + send via the Smart Rollup inbox: + - ticket + - user's Etherlink address + + + 6 + send tez on Etherlink + ### Withdrawal process The withdrawal process (moving XTZ from Etherlink EVM to tez on Tezos layer 1) follows these general steps: -1. A Etherlink EVM user sends XTZ and their layer 1 address to the [withdrawal precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) in the Etherlink Smart Rollup via an EVM node. +1. An Etherlink EVM user sends XTZ and their layer 1 address to the [withdrawal precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) in the Etherlink Smart Rollup via an EVM node. 1. The contract locks the XTZ. 1. The contract creates a transaction to the exchanger contract's `burn` entrypoint and puts this transaction in the Smart Rollup outbox. This outbox message becomes part of Etherlink's commitment to its state. @@ -95,7 +159,81 @@ This outbox message becomes part of Etherlink's commitment to its state This diagram is an overview of the withdrawal process: -![Overview of the token bridging withdrawal process](/img/bridging-withdrawal.png) + + + + + + + + + + + + + + + CLIENTS + + User's Tezos + wallet + + Octez client + anyone can run it + + User's EVM + wallet + + TEZOS LAYER 1 + + Exchanger contract + + Smart Rollup + outbox + + ETHERLINK + + Withdrawal + precompile + 0xff00…0001 + + + 1 + send transaction: + - amount of tez + - user's layer 1 + address + + + 2 + store tez, + create ticket + + + 3 + include in + commitment: + (ticket, user's + layer 1 address) + + + 4 + trigger outbox message + after the commitment is cemented (~2 weeks) + + + 5 + call burn entrypoint: + (ticket, layer 1 address) + + + 6 + unlock tez, destroy ticket + + + 7 + send tez + ### Fast withdrawals @@ -115,7 +253,7 @@ They can use the bridge to verify that they will receive the withdrawn funds whe The process for fast withdrawals is different than for standard withdrawals: -1. A Etherlink EVM user submits a withdrawal transaction to the fast withdrawal precompiled contract instead of the standard withdrawal precompiled contract. +1. An Etherlink EVM user submits a withdrawal transaction to the fast withdrawal precompiled contract instead of the standard withdrawal precompiled contract. 1. As in the standard withdrawal process, the fast withdrawal precompiled contract locks the Etherlink EVM XTZ and puts a message in the Smart Rollup outbox that represents those tokens. However, instead of sending the withdrawn tokens directly to the user's Tezos layer 1 account, it sends them to a fast withdrawal contract on layer 1. 1. Liquidity providers monitor the Smart Rollup outbox and when they detect fast withdrawal requests with favorable rates, they call the layer 1 contract to claim the fast withdrawal. diff --git a/docs/evm/bridging/bridging.mdx b/docs/evm/bridging/bridging.mdx index ed954bc3..36ffd160 100644 --- a/docs/evm/bridging/bridging.mdx +++ b/docs/evm/bridging/bridging.mdx @@ -3,20 +3,20 @@ title: Bridging tokens id: bridging --- -You can move tokens in and out of Etherlink EVM{/* TEVM */} through a process called _bridging_. +You can move tokens in and out of Etherlink EVM through a process called _bridging_. See these related pages for more information: -- [Bridging XTZ between Tezos layer 1 and Etherlink EVM{/* TEVM */}](/evm/bridging/bridging-tezos) -- [Bridging FA tokens between Tezos layer 1 and Etherlink EVM{/* TEVM */}](/evm/bridging/bridging-fa) -- [Bridging tokens between Etherlink EVM{/* TEVM */} and other EVM networks](/evm/bridging/bridging-evm) +- [Bridging XTZ between Tezos layer 1 and Etherlink EVM](/evm/bridging/bridging-tezos) +- [Bridging FA tokens between Tezos layer 1 and Etherlink EVM](/evm/bridging/bridging-fa) +- [Bridging tokens between Etherlink EVM and other EVM networks](/evm/bridging/bridging-evm) ## Explorer -The explorer at https://bridge.explorer.etherlink.com shows bridging transactions between Tezos Mainnet and Etherlink{/* TX */} Mainnet. +The explorer at https://bridge.explorer.etherlink.com shows bridging transactions between Tezos Mainnet and Etherlink Mainnet. ## Native bridges -Etherlink{/* TX */} developers have created web-based bridges for different situations. +Etherlink developers have created web-based bridges for different situations. These bridges are permissionless; anyone can use them without restrictions or the intervention of a third party.
@@ -32,13 +32,13 @@ These bridges are permissionless; anyone can use them without restrictions or th
- + - + diff --git a/docs/evm/developing/deploying-contracts.md b/docs/evm/developing/deploying-contracts.md index 2d17ebe7..40e9400a 100644 --- a/docs/evm/developing/deploying-contracts.md +++ b/docs/evm/developing/deploying-contracts.md @@ -4,7 +4,7 @@ dependencies: ethers: 6.13.5 --- -import PublicRpcRateLimitNote from '@site/docs/conrefs/rate-limit.md'; +import PublicRpcRateLimitNote from '@site/docs/conrefs/_rate-limit.md'; As an EVM-compatible chain, Etherlink EVM runs Solidity contracts. You can deploy Solidity smart contracts in any way that you would deploy them to an EVM-compatible chain. diff --git a/docs/evm/developing/estimating-fees.md b/docs/evm/developing/estimating-fees.md index dfc4f2cf..090b52d7 100644 --- a/docs/evm/developing/estimating-fees.md +++ b/docs/evm/developing/estimating-fees.md @@ -2,7 +2,7 @@ title: Estimating fees --- -import GasPriceWarning from '@site/docs/conrefs/gas-price-warning.md'; +import GasPriceWarning from '@site/docs/conrefs/_gas-price-warning.md'; The Etherlink EVM gas price (and therefore the fee for a given transaction) varies based on the activity on the chain. As activity increases, fees increase, and vice versa. @@ -44,7 +44,7 @@ This gas price is the cost per unit of computation required by a transaction. -To calculate the fee estimate for a given transaction, you can send the transaction to the `eth_estimateGas` endpoint to obtain the estimated gas usage for the the transaction (as in this example), and then calculate the total expected gas fee: +To calculate the fee estimate for a given transaction, you can send the transaction to the `eth_estimateGas` endpoint to obtain the estimated gas usage for the transaction (as in this example), and then calculate the total expected gas fee: ```bash curl --request POST \ diff --git a/docs/evm/developing/indexing-graph.mdx b/docs/evm/developing/indexing-graph.mdx index 45c1b94e..b438f99f 100644 --- a/docs/evm/developing/indexing-graph.mdx +++ b/docs/evm/developing/indexing-graph.mdx @@ -6,7 +6,7 @@ sidebar_label: Indexing contracts Getting historical data on a smart contract can be frustrating when building a dApp. [The Graph](https://thegraph.com/) provides an easy way to query smart contract data through APIs known as subgraphs. The Graph's infrastructure relies on a decentralized network of indexers, enabling your dApp to become truly decentralized. -Both Etherlink{/* TX */} Mainnet and Shadownet Testnet are supported by The Graph. +Both Etherlink Mainnet and Shadownet Testnet are supported by The Graph. ## Quick start @@ -90,7 +90,7 @@ Here's a step by step walk through: ![Publish screen](/img/thegraph-studio-publish-modal.png) - > **Note:** The Graph's smart contracts are all on Arbitrum One, even though your subgraph is indexing data from Etherlink EVM{/* TEVM */}, Ethereum or any other [supported chain](https://thegraph.com/docs/en/developing/supported-networks/). + > **Note:** The Graph's smart contracts are all on Arbitrum One, even though your subgraph is indexing data from Etherlink EVM, Ethereum or any other [supported chain](https://thegraph.com/docs/en/developing/supported-networks/). ## Query your subgraph diff --git a/docs/evm/developing/information.md b/docs/evm/developing/information.md index 63c60bf4..8eb89c13 100644 --- a/docs/evm/developing/information.md +++ b/docs/evm/developing/information.md @@ -4,7 +4,7 @@ dependencies: ethers: 6.13.5 --- -import PublicRpcRateLimitNote from '@site/docs/conrefs/rate-limit.md'; +import PublicRpcRateLimitNote from '@site/docs/conrefs/_rate-limit.md'; The EVM interface supports standard EVM endpoints that allow you to get information about the Etherlink network and its accounts, including user accounts and smart contract accounts. @@ -15,7 +15,7 @@ The EVM interface supports standard EVM endpoints that allow you to get informat ## Getting the balance of accounts -To get the balance of a user account or smart contract, pass the account address to the [`eth_getBalance`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getbalance) endpoint, as in this example: +To get the balance of a user account or smart contract, pass the account address to the [`eth_getBalance`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-getbalance) endpoint, as in this example: ```bash curl --request POST \ @@ -36,7 +36,7 @@ The response includes the balance in XTZ in hexadecimal: ## Getting the chain ID -Etherlink EVM supports the standard EVM [`eth_chainId`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_chainid) and [`net_version`](https://ethereum.org/en/developers/docs/apis/json-rpc/#net_version) endpoints to get the ID of the current network. +Etherlink EVM supports the standard EVM [`eth_chainId`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-chainid) and [`net_version`](https://ethereum.org/en/developers/docs/apis/json-rpc/#net-version) endpoints to get the ID of the current network. The `eth_chainId` endpoint returns the chain ID in hexadecimal and the `net_version` endpoint returns it in decimal, as in this example: ```bash @@ -49,7 +49,7 @@ curl --request POST \ ## Getting information about smart contracts -Etherlink EVM supports the standard EVM [`eth_getCode`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getcode) and [`eth_getStorageAt`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getstorageat) endpoints to get the code of a contract and its storage in hexadecimal, as in this example: +Etherlink EVM supports the standard EVM [`eth_getCode`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-getcode) and [`eth_getStorageAt`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-getstorageat) endpoints to get the code of a contract and its storage in hexadecimal, as in this example: ```bash curl --request POST \ @@ -63,12 +63,12 @@ curl --request POST \ Etherlink EVM supports several standard Ethereum endpoints to get information about transactions: -- [`eth_getTransactionByBlockNumberAndIndex`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyblocknumberandindex) -- [`eth_getTransactionByBlockHashAndIndex`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyblockhashandindex) -- [`eth_getTransactionByHash`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyhash) -- [`eth_getTransactionReceipt`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionreceipt) -- [`eth_getTransactionCount`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactioncount) -- [`eth_getTransactionByHash`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyhash) +- [`eth_getTransactionByBlockNumberAndIndex`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-gettransactionbyblocknumberandindex) +- [`eth_getTransactionByBlockHashAndIndex`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-gettransactionbyblockhashandindex) +- [`eth_getTransactionByHash`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-gettransactionbyhash) +- [`eth_getTransactionReceipt`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-gettransactionreceipt) +- [`eth_getTransactionCount`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-gettransactioncount) +- [`eth_getTransactionByHash`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-gettransactionbyhash) For example, you can get information about a transaction by passing its hash to the `eth_getTransactionByHash` or `eth_getTransactionReceipt` endpoints, as in this example: diff --git a/docs/evm/developing/tokens.mdx b/docs/evm/developing/tokens.mdx index 85e7c32d..11731c7d 100644 --- a/docs/evm/developing/tokens.mdx +++ b/docs/evm/developing/tokens.mdx @@ -4,15 +4,15 @@ title: Tokens import InlineCopy from '@site/src/components/InlineCopy'; -The native coin on Etherlink EVM{/* TEVM */} has the symbol XTZ, like the [tez tokens on Tezos layer 1](https://docs.tezos.com/architecture/tokens). +The native coin on Etherlink EVM has the symbol XTZ, like the [tez tokens on Tezos layer 1](https://docs.tezos.com/architecture/tokens). You can get XTZ from many [exchanges](/evm/tools/exchanges) and [on-ramps](/evm/tools/onramps). -Etherlink EVM{/* TEVM */} provides a wrapped version of XTZ named WXTZ that is an [ERC-20-compliant](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) token for ease of interacting with decentralized applications. +Etherlink EVM provides a wrapped version of XTZ named WXTZ that is an [ERC-20-compliant](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) token for ease of interacting with decentralized applications. For more information about WXTZ, see [WXTZ](#wxtz). ## Token addresses -These are some of the other tokens that are available on Etherlink EVM{/* TEVM */}. +These are some of the other tokens that are available on Etherlink EVM. Click the address to go to the block explorer page for the token:
Etherlink EVM{/* TEVM */}Etherlink EVM
Tezos bridgeBridges XTZ and approved FA tokens from Tezos layer 1 to Etherlink EVM{/* TEVM */} and backBridges XTZ and approved FA tokens from Tezos layer 1 to Etherlink EVM and back Mainnet Shadownet Testnet
EVM bridgeBridges assets from EVM chains to wrapped assets on Etherlink EVM{/* TEVM */} and backBridges assets from EVM chains to wrapped assets on Etherlink EVM and back Mainnet Shadownet Testnet
@@ -84,7 +84,7 @@ Click the address to go to the block explorer page for the token: ## WXTZ -WXTZ is a token created to replicate the functionality of Wrapped Ether (WETH), but specifically for the XTZ native token on Etherlink EVM{/* TEVM */}. +WXTZ is a token created to replicate the functionality of Wrapped Ether (WETH), but specifically for the XTZ native token on Etherlink EVM. The goal of WXTZ is to facilitate the use of XTZ in decentralized applications (dApps) and protocols that require ERC-20-like tokens. For more information and the code of the token, see the [etherlinkcom/token-deployments repository](https://github.com/etherlinkcom/token-deployments/tree/main). @@ -119,7 +119,7 @@ Here are the chains the token is deployed on: - + @@ -154,20 +154,20 @@ The WXTZ contract was audited by [Omniscia.io](https://omniscia.io/). The final report is here: https://omniscia.io/reports/etherlink-cross-chain-token-665c8ac479e20900180f383b WXTZ supports OFT to simplify cross-chain compatibility. -However, if the OFT bridge gets compromised, all the XTZ in the contract on Etherlink EVM{/* TEVM */} could be stolen by a malicious attacker with these steps: +However, if the OFT bridge gets compromised, all the XTZ in the contract on Etherlink EVM could be stolen by a malicious attacker with these steps: 1. Create and deploy a fake WXTZ contract on another EVM chain 2. Mint a maximum amount of WXTZ on the other chain -3. Connect to the contract on Etherlink EVM{/* TEVM */} using `setPeer()` -4. Transfer the WXTZ to Etherlink EVM{/* TEVM */} -5. Withdraw the XTZ locked in the WXTZ contract on Etherlink EVM{/* TEVM */} +3. Connect to the contract on Etherlink EVM using `setPeer()` +4. Transfer the WXTZ to Etherlink EVM +5. Withdraw the XTZ locked in the WXTZ contract on Etherlink EVM -The Etherlink{/* TX */} team has taken measures to protect users native to Etherlink EVM{/* TEVM */} and bridged across EVM chains. +The Etherlink team has taken measures to protect users native to Etherlink EVM and bridged across EVM chains. -These are the measures to protect Etherlink EVM{/* TEVM */} users: +These are the measures to protect Etherlink EVM users: -- We overrode the `_credit` method used by LayerZero to bridge tokens between chains. We added a condition checking that the receiving amount of WXTZ can't exceed the amount of XTZ stored in the contract. The result is that **only the WXTZ supply bridged** using the LayerZero protocol should be at risk, and not the local WXTZ on Etherlink EVM{/* TEVM */}. If an attacker succeeds in hacking the bridge, they will only be able to transfer the difference between the amount of XTZ stored in the contract and the local total supply of WXTZ on Etherlink EVM{/* TEVM */}. In this way, all Etherlink EVM{/* TEVM */} users who own their WXTZ locally will still have their WXTZ backed 1:1 by XTZ in the contract. +- We overrode the `_credit` method used by LayerZero to bridge tokens between chains. We added a condition checking that the receiving amount of WXTZ can't exceed the amount of XTZ stored in the contract. The result is that **only the WXTZ supply bridged** using the LayerZero protocol should be at risk, and not the local WXTZ on Etherlink EVM. If an attacker succeeds in hacking the bridge, they will only be able to transfer the difference between the amount of XTZ stored in the contract and the local total supply of WXTZ on Etherlink EVM. In this way, all Etherlink EVM users who own their WXTZ locally will still have their WXTZ backed 1:1 by XTZ in the contract. -- To protect bridged users, the Etherlink{/* TX */} team overrode the `setPeer()` method that connects and disconnects WXTZ contracts on different chains. +- To protect bridged users, the Etherlink team overrode the `setPeer()` method that connects and disconnects WXTZ contracts on different chains. By adding a 2 day timelock to the `setPeer()` method, there is a 2 day delay between initially creating a connection and the connection being executed. -If a hacker takes ownership of the contracts and starts connecting or disconnecting, **bridged users will have 2 days to bridge back all their funds on Etherlink EVM{/* TEVM */} and withdraw their XTZ**. +If a hacker takes ownership of the contracts and starts connecting or disconnecting, **bridged users will have 2 days to bridge back all their funds on Etherlink EVM and withdraw their XTZ**. diff --git a/docs/evm/developing/transactions.md b/docs/evm/developing/transactions.md index 725616af..72884758 100644 --- a/docs/evm/developing/transactions.md +++ b/docs/evm/developing/transactions.md @@ -6,9 +6,9 @@ dependencies: viem: 0 --- -import PublicRpcRateLimitNote from '@site/docs/conrefs/rate-limit.md'; +import PublicRpcRateLimitNote from '@site/docs/conrefs/_rate-limit.md'; -import GasPriceWarning from '@site/docs/conrefs/gas-price-warning.md'; +import GasPriceWarning from '@site/docs/conrefs/_gas-price-warning.md'; Etherlink EVM supports the standard Ethereum `eth_call` and `eth_sendRawTransaction` RPC endpoints for calling smart contracts and sending transactions. @@ -329,7 +329,7 @@ If you pass `latest` instead of `pending`, the node waits until the transaction Etherlink EVM supports this `pending` value only on the `eth_sendRawTransactionSync` method, not on any other methods. When the sequencer enqueues the transaction for the next block, it notifies the nodes of the transaction and the nodes return a receipt for the transaction that includes information such as its gas price and gas cost. -This receipt matches the specification for the [`eth_getTransactionReceipt`](https://ethereum.org/developers/docs/apis/json-rpc/#eth_gettransactionreceipt) endpoint except that the `blockHash` field is always `0x000...` because the block has not been created yet. +This receipt matches the specification for the [`eth_getTransactionReceipt`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-gettransactionreceipt) endpoint except that the `blockHash` field is always `0x000...` because the block has not been created yet. You can take this response as a confirmation that the sequencer will put the transaction in the next block. If the sequencer does not intend to put the transaction in the next block (such as if the block is nearly complete or the transaction volume is high), the nodes wait to provide the receipt until the transaction will be in the next block. @@ -624,7 +624,7 @@ The response includes information about the matching events: } ``` -For other filters, see [`eth_getLogs`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getstorageat) in the Ethereum JSON-RPC API reference. +For other filters, see [`eth_getLogs`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth-getstorageat) in the Ethereum JSON-RPC API reference. ## Tracing transactions diff --git a/docs/evm/developing/verifying-contracts.mdx b/docs/evm/developing/verifying-contracts.mdx index 770667b7..c398b3db 100644 --- a/docs/evm/developing/verifying-contracts.mdx +++ b/docs/evm/developing/verifying-contracts.mdx @@ -4,7 +4,7 @@ title: Verifying contracts Verifying a smart contract provides a link to its source code and attests that the source code matches the deployed bytecode. -Follow these steps to verify a contract on the Etherlink EVM{/* TEVM */} block explorer: +Follow these steps to verify a contract on the Etherlink EVM block explorer: 1. Find the deployed contract on https://explorer.etherlink.com/, https://testnet.explorer.etherlink.com/, or https://shadownet.explorer.etherlink.com/. diff --git a/docs/evm/developing/websockets.md b/docs/evm/developing/websockets.md index a4d5858f..5a830cb4 100644 --- a/docs/evm/developing/websockets.md +++ b/docs/evm/developing/websockets.md @@ -180,7 +180,7 @@ As such, it has to be enabled by adding to the node configuration file: ::: You can subscribe to WebSockets to receive Instant Confirmations, which are notices that a transaction will appear in the next block. -Using WebSockets for Instant Confirmations requires at least version 0.49 of the `octez-evm-node` binary. +Using WebSockets for Instant Confirmations requires at least version 0.52 of the `octez-evm-node` binary. :::note @@ -247,7 +247,7 @@ The response to the `tez_newIncludedTransactions` event (a transaction object) i "params": { "result": { "type": "0x2", - "chainId": "0x1f308", + "chainId": "0x1f34f", "hash": "0xfbb0025e811b8bf37034e508da4740c68164c33947089b1c22119be55258a3e1", "nonce": "0x7", "blockHash": null, diff --git a/docs/evm/get-started/getting-testnet-tokens.mdx b/docs/evm/get-started/getting-testnet-tokens.mdx index e03175ef..5405f253 100644 --- a/docs/evm/get-started/getting-testnet-tokens.mdx +++ b/docs/evm/get-started/getting-testnet-tokens.mdx @@ -2,12 +2,12 @@ title: Getting Testnet tokens --- -The native coin on Etherlink{/* TX */} has the symbol XTZ, like the [tez tokens on Tezos layer 1](https://docs.tezos.com/architecture/tokens). -For more information about that token and the tokens that are available on Etherlink EVM{/* TEVM */}, see [Tokens](/evm/developing/tokens). +The native coin on Etherlink has the symbol XTZ, like the [tez tokens on Tezos layer 1](https://docs.tezos.com/architecture/tokens). +For more information about that token and the tokens that are available on Etherlink EVM, see [Tokens](/evm/developing/tokens). -The Etherlink{/* TX */} test network has a faucet that provides free XTZ tokens that you can use to pay transaction fees and test applications on Etherlink EVM{/* TEVM */}. +The Etherlink test network has a faucet that provides free XTZ tokens that you can use to pay transaction fees and test applications on Etherlink EVM. -To get tokens on Etherlink{/* TX */} Shadownet Testnet, follow these steps: +To get tokens on Etherlink Shadownet Testnet, follow these steps: 1. Go to [shadownet.faucet.etherlink.com](https://shadownet.faucet.etherlink.com). 2. Connect your Ethereum wallet. @@ -22,6 +22,6 @@ If you don't see them, you may need to click **Add to Wallet** next to the **Sen The faucet provides a fixed amount of tokens once every 24 hours. If you need more tokens, the [Tezos Shadownet faucet](https://faucet.shadownet.teztnets.com/) provides tez on Tezos layer 1. -Then you can bridge those tez to Etherlink EVM{/* TEVM */} XTZ with the bridge, as described in [Bridging tokens](/evm/bridging/). +Then you can bridge those tez to Etherlink EVM XTZ with the bridge, as described in [Bridging tokens](/evm/bridging/). ::: diff --git a/docs/evm/get-started/network-information.mdx b/docs/evm/get-started/network-information.mdx index 2c0ee93a..4a0a0883 100644 --- a/docs/evm/get-started/network-information.mdx +++ b/docs/evm/get-started/network-information.mdx @@ -5,17 +5,17 @@ title: Network information (EVM) import InlineCopy from '@site/src/components/InlineCopy'; import Link from '@docusaurus/Link'; -This page contains information for connecting to the public Etherlink{/* TX */} networks via the EVM interface. +This page contains information for connecting to the public Etherlink networks via the EVM interface. For using the networks via the Michelson interface, see [Michelson network information](/michelson/network-information). -For current and historical status information for Etherlink{/* TX */}, see https://status.etherlink.com. +For current and historical status information for Etherlink, see https://status.etherlink.com. For every network, we provide two public EVM endpoints: a full RPC endpoint and a -relay endpoint. The full RPC endpoint can be consumed by Etherlink EVM{/* TEVM */} users and +relay endpoint. The full RPC endpoint can be consumed by Etherlink EVM users and decentralized applications to interact with the chain. The relay endpoint exposes a restricted RPC API with only `eth_sendRawTransaction` and `eth_blockNumber` available. Use the relay endpoint when setting up a -[EVM node{/* TXN */}](/network/evm-nodes). +[EVM node](/network/evm-nodes). :::warning @@ -28,7 +28,7 @@ or subscribe to a commercial [RPC provider](/evm/tools/node-providers) plan whic ::: -## Etherlink{/* TX */} Mainnet +## Etherlink Mainnet
Etherlink EVM{/* TEVM */}Etherlink EVM
@@ -40,7 +40,7 @@ or subscribe to a commercial [RPC provider](/evm/tools/node-providers) plan whic - + @@ -83,11 +83,11 @@ or subscribe to a commercial [RPC provider](/evm/tools/node-providers) plan whic - + - + @@ -105,10 +105,10 @@ or subscribe to a commercial [RPC provider](/evm/tools/node-providers) plan whic
Network NameEtherlink{/* TX */} MainnetEtherlink Mainnet
EVM version{"https://governance.etherlink.com"}
Etherlink{/* TX */} smart rollup snapshotsEtherlink smart rollup snapshots {"https://snapshots.tzinit.org/etherlink-mainnet/"}
EVM node{/* TXN */} snapshotsEVM node snapshots {"https://snapshotter-sandbox.nomadic-labs.eu/etherlink-mainnet/"}
-## Etherlink{/* TX */} Shadownet Testnet +## Etherlink Shadownet Testnet This test network (sometimes abbreviated as "Shadownet Testnet" or just "Shadownet") runs on the [Shadownet](https://teztnets.com/shadownet-about) Tezos test network. -Shadownet Testnet is the primary test network for Etherlink{/* TX */}. +Shadownet Testnet is the primary test network for Etherlink. @@ -120,7 +120,7 @@ Shadownet Testnet is the primary test network for Etherlink{/* TX */}. - + @@ -163,11 +163,11 @@ Shadownet Testnet is the primary test network for Etherlink{/* TX */}. - + - + @@ -195,13 +195,13 @@ Block speed | Variable; see [Architecture](/network/architecture) Docker image | https://hub.docker.com/r/tezos/tezos-bare images that start with `octez-evm-node` Debugging | Supported via standard [Ethereum endpoints](/evm/developing/endpoint-support) Tracing | Supported via standard [Ethereum endpoints](/evm/developing/endpoint-support) -Monitoring | Supported; see [Monitoring EVM nodes{/* TXN */}](/network/monitoring) +Monitoring | Supported; see [Monitoring EVM nodes](/network/monitoring) WebSockets | Supported; see [Getting updates with WebSockets](/evm/developing/websockets) Fee structure | Variable, including an execution fee and a fee for data inclusion on layer 1 but not a voluntary tip; see [Fee structure](/evm/developing/fees) ## Precompiled contracts -These precompiled contracts are specific to Etherlink EVM{/* TEVM */}: +These precompiled contracts are specific to Etherlink EVM:
Network NameEtherlink{/* TX */} Shadownet TestnetEtherlink Shadownet Testnet
EVM version18
Etherlink{/* TX */} smart rollup snapshotsEtherlink smart rollup snapshots {"https://snapshots.tzinit.org/etherlink-shadownet"}
EVM node{/* TXN */} snapshotsEVM node snapshots {"https://snapshotter-sandbox.nomadic-labs.eu"}
@@ -235,7 +235,7 @@ These precompiled contracts are specific to Etherlink EVM{/* TEVM */}:
-Etherlink EVM{/* TEVM */} also includes these [Ethereum precompiled contracts](https://www.evm.codes/precompiled): +Etherlink EVM also includes these [Ethereum precompiled contracts](https://www.evm.codes/precompiled): diff --git a/docs/evm/get-started/using-your-wallet.mdx b/docs/evm/get-started/using-your-wallet.mdx index 36469d52..57f8e329 100644 --- a/docs/evm/get-started/using-your-wallet.mdx +++ b/docs/evm/get-started/using-your-wallet.mdx @@ -16,7 +16,7 @@ You can connect any wallet that supports custom EVM networks, including: - [Temple wallet](https://www.templewallet.com) - [Trust Wallet](https://trustwallet.com/) -You can use these buttons to connect your wallet to Etherlink EVM{/* TEVM */}: +You can use these buttons to connect your wallet to Etherlink EVM:
@@ -33,13 +33,13 @@ You can use these buttons to connect your wallet to Etherlink EVM{/* TEVM */}:
-Your wallet may show warnings about connecting to this documentation site because it is not a popular source of Etherlink EVM{/* TEVM */} transactions and is not listed on community platforms. +Your wallet may show warnings about connecting to this documentation site because it is not a popular source of Etherlink EVM transactions and is not listed on community platforms. These warnings appear because this documentation site does not handle any transactions, only these wallet connection buttons. -If you want to be sure that you are connecting to the correct network, you can connect to Etherlink EVM{/* TEVM */} on another site such as these: +If you want to be sure that you are connecting to the correct network, you can connect to Etherlink EVM on another site such as these: -- To connect to Etherlink{/* TX */} Mainnet, use the [Mainnet block explorer](https://explorer.etherlink.com/) or the [bridge](https://www.etherlinkbridge.com). +- To connect to Etherlink Mainnet, use the [Mainnet block explorer](https://explorer.etherlink.com/) or the [bridge](https://www.etherlinkbridge.com). -- To connect to Etherlink{/* TX */} Shadownet Testnet, use the [Shadownet Testnet block explorer](https://shadownet.explorer.etherlink.com/) or the [faucet](https://shadownet.faucet.etherlink.com/). +- To connect to Etherlink Shadownet Testnet, use the [Shadownet Testnet block explorer](https://shadownet.explorer.etherlink.com/) or the [faucet](https://shadownet.faucet.etherlink.com/). ## Connecting wallets manually diff --git a/docs/evm/getting-started.md b/docs/evm/getting-started.md index f905f002..0f0fc5fc 100644 --- a/docs/evm/getting-started.md +++ b/docs/evm/getting-started.md @@ -33,4 +33,4 @@ For detailed guidance, refer to [Deploying smart contracts](/evm/developing/depl To call a Michelson contract from a Solidity contract, use the NAC gateway. See [NAC Usage](./nac-usage.md) for the gateway address and call conventions. -For a more hands-on presentation, check the [Cross-interface counter tutorial](/tutorials/nac-counter) (note however that the NAC tutorial, as presented, runs on Previewnet, not on Etherlink Shadownet). +For a more hands-on presentation, check the [Cross-interface counter tutorial](/tutorials/nac-counter) (note however that the NAC tutorial, as presented, runs on the Tezos X Previewnet, not on Etherlink Shadownet). diff --git a/docs/evm/index.md b/docs/evm/index.md index 36c6d228..fc13adf5 100644 --- a/docs/evm/index.md +++ b/docs/evm/index.md @@ -4,7 +4,7 @@ title: EVM Interface Overview # EVM Interface -The **EVM Interface** (formerly the only developer experience in Etherlink) is implemented by an EVM runtime that is designed to be a drop-in replacement for Ethereum-compatible chains: existing Solidity contracts, wallets, SDKs, and tooling work without modification. +The **EVM Interface** is implemented by an EVM runtime that is designed to be a drop-in replacement for Ethereum-compatible chains: existing Solidity contracts, wallets, SDKs, and tooling work without modification. The EVM Interface targets full compatibility with the Ethereum ecosystem, but there are a few differences from Ethereum, detailed at [Compatibility with Ethereum](/evm/developing/compatibility). diff --git a/docs/examples/potluck-game.md b/docs/examples/potluck-game.md index 1343491d..7f0416eb 100644 --- a/docs/examples/potluck-game.md +++ b/docs/examples/potluck-game.md @@ -40,7 +40,7 @@ The four components live in separate subdirectories of the repository: | Directory | Language | Role | |---|---|---| | `contracts/evm/` | Solidity | xUSDC token, xEscrow escrow contract | -| `contracts/tezlink/` | LIGO | Game contract (pot, players, address mapping) | +| `contracts/tezlink/` | LIGO | Michelson-interface game contract (pot, players, address mapping) | | `xbutton-relayer/` | TypeScript | Off-chain service: watches escrow events, calls NAC gateway | | `xbutton-frontend/` | React + Vite | UI: wallet connect, deposit button, live game state | diff --git a/docs/governance/overview.mdx b/docs/governance/overview.mdx index 614dffad..da15dabb 100644 --- a/docs/governance/overview.mdx +++ b/docs/governance/overview.mdx @@ -4,18 +4,18 @@ title: Governance overview import InlineCopy from '@site/src/components/InlineCopy'; -The Etherlink{/* TX */} governance process manages updates to Etherlink{/* TX */}'s kernel and the account that operates the sequencer. +The Etherlink governance process manages updates to Etherlink's kernel and the account that operates the sequencer. -Tezos bakers can participate in the [Etherlink{/* TX */} governance process](/governance/how-is-etherlink-governed) by submitting proposals to change the kernel and sequencer operator and voting for or against them. +Tezos bakers can participate in the [Etherlink governance process](/governance/how-is-etherlink-governed) by submitting proposals to change the kernel and sequencer operator and voting for or against them. The voting power of a baker is the amount of tez that it has staked plus the tez that delegators have delegated to it, also called its _staking balance_. Separate contracts manage the slow kernel updates, the fast kernel updates, and the sequencer operator, so to interact with them, bakers send transactions to those contracts, such as with the Octez client. -The addresses of the governance contracts are specified in Etherlink{/* TX */}'s kernel. +The addresses of the governance contracts are specified in Etherlink's kernel. For information about the Octez client, see [Command Line Interface](https://octez.tezos.com/docs/active/cli-commands.html) in the Octez documentation. ## Governance web site -For information about Etherlink{/* TX */} governance and to vote on governance proposals, see https://governance.etherlink.com. +For information about Etherlink governance and to vote on governance proposals, see https://governance.etherlink.com. This site: - Shows information about each governance process @@ -25,7 +25,7 @@ This site: ## Governance contract addresses -You need the address of the correct governance contract (and sometimes the address of the Etherlink{/* TX */} Smart Rollup) to propose changes, vote on changes, and trigger approved changes. +You need the address of the correct governance contract (and sometimes the address of the Etherlink Smart Rollup) to propose changes, vote on changes, and trigger approved changes. @@ -52,7 +52,7 @@ You need the address of the correct governance contract (and sometimes the addre - + diff --git a/docs/michelson/bridging.md b/docs/michelson/bridging.md index 34fe12e9..b9a6672d 100644 --- a/docs/michelson/bridging.md +++ b/docs/michelson/bridging.md @@ -5,16 +5,25 @@ title: Bridging # Bridging :::caution[In progress] -This page is under construction, the bridging website is being worked out. -Come back soon! +The bridging web UI does not support the Michelson interface yet. +The mechanisms below work today but require scripts or manual transactions. ::: -In the meantime, you can [bridge tokens to the EVM interface](/evm/bridging/) and control them via [Native Atomic Composability (NAC)](/michelson/nac-usage). +## Depositing tez from Tezos layer 1 -## What the Michelson interface bridges +Native tez can be bridged from Tezos layer 1 directly to a Michelson-interface account. +The flow is the same as [depositing to the EVM interface](/evm/bridging/bridging-tezos): the layer 1 bridge contract wraps the tez in a ticket and forwards it to the Etherlink Smart Rollup, together with routing data that designates the receiver. +To target a Michelson-interface account, the routing data designates an implicit account (`tz1`, `tz2`, or `tz3`) instead of an EVM address; the kernel rejects deposits that target originated (`KT1`) accounts. -**Native tez** can be moved between Tezos layer 1 and the Michelson interface; the bridging UI for this path is under construction. +Until the bridging web UI supports this path, you can use the deposit scripts in the [Etherlink bridge repository](https://github.com/baking-bad/etherlink-bridge) (see `scripts/tezos/xtz_deposit_michelson.py`), or deposit to the [EVM interface](/evm/bridging/bridging-tezos) and transfer the tez to your Michelson-interface account. -**FA tokens** are deliberately not bridged to the Michelson interface directly. +## Withdrawing tez to Tezos layer 1 + +Withdrawing directly from a Michelson-interface account is not available yet. +In the meantime, transfer the tez to an EVM-interface account that you control — any transfer to the account's Michelson alias credits it, as described in [Accounts and aliases](/overview/accounts-and-aliases) — and use the standard [EVM withdrawal](/evm/bridging/bridging-tezos#withdrawal-process). + +## FA tokens + +FA tokens are deliberately not bridged to the Michelson interface directly. Bridging the same token to both interfaces would create two wrapped versions of it on the same chain. -Instead, tokens bridged to the [EVM interface](/evm/bridging/) remain the single canonical representation, and Michelson contracts use them directly via [NAC](/michelson/nac-usage). +Instead, tokens bridged to the [EVM interface](/evm/bridging/) remain the single canonical representation, and Michelson contracts use them directly via [Native Atomic Composability (NAC)](/michelson/nac-usage). diff --git a/docs/michelson/developing/accounts.md b/docs/michelson/developing/accounts.md index fff06c87..e41f45fa 100644 --- a/docs/michelson/developing/accounts.md +++ b/docs/michelson/developing/accounts.md @@ -4,7 +4,7 @@ title: Accounts # Accounts -Among the [types of accounts](https://docs.tezos.com/architecture/accounts) desscribed in the Tezos L1 documentation, the following are available in the Michelson interface: +Among the [types of accounts](https://docs.tezos.com/architecture/accounts) described in the Tezos L1 documentation, the following are available in the Michelson interface: | Address type | Status | |---|---| diff --git a/docs/michelson/developing/compatibility.md b/docs/michelson/developing/compatibility.md index 0e6a77b8..4caa34ba 100644 --- a/docs/michelson/developing/compatibility.md +++ b/docs/michelson/developing/compatibility.md @@ -8,7 +8,7 @@ The Michelson Interface is designed to behave as closely as possible to Tezos La ## Compatible features -Most of the features, including the following ones work identically to Tezos Layer 1. Therefore, users may safely refer to the corresponding page in the [Tezos documentation](https://docs.tezos.com/) for all these aspects. +Most features work identically to Tezos Layer 1. Therefore, users may safely refer to the corresponding page in the [Tezos documentation](https://docs.tezos.com/) for all these aspects. ## Known differences @@ -38,7 +38,7 @@ When a transaction is initiated via a cross-interface call (i.e., from the EVM i Michelson aliases (KT1 contracts created for EVM accounts) automatically forward any tez they receive to the originating EVM account via the gateway. You cannot send tez directly to an alias address and retain it there. -One consequence of this is that `SENDER == SELF_ADDRESS` is not a safe test in Etherlink, see [Self-address test](../self-address). +One consequence of this is that `SENDER == SELF_ADDRESS` is not a safe test in Etherlink, see [Aliases and caller-equals-self](../self-address). ### Blocks diff --git a/docs/michelson/developing/rpc-reference.md b/docs/michelson/developing/rpc-reference.md index d4b38245..128967c3 100644 --- a/docs/michelson/developing/rpc-reference.md +++ b/docs/michelson/developing/rpc-reference.md @@ -5,7 +5,7 @@ title: RPC reference # RPC reference EVM nodes provide the same RPCs as Tezos L1 nodes on their Michelson endpoint. -The Michelson endpoint is served at the `/tezlink` sub-path of the node's base RPC URL. +The Michelson endpoint is served at the `/tezlink` sub-path of the node's base RPC URL (a legacy path name that may be renamed to `/michelson` in a future version). For example, a node running on the default port exposes the Michelson interface at `http://localhost:8545/tezlink`. For public endpoint URLs, see [Michelson network information](/michelson/network-information). @@ -46,4 +46,4 @@ The following L1 RPCs exhibit different behavior in Etherlink, either t | `GET /version` | Returns a stub value with an empty commit hash and date. | | `GET /context/issuance/expected_issuance` | Returns dummy zero rewards; Etherlink has no token issuance. | | `POST /helpers/scripts/pack_data` | Uses a throwaway dummy context instead of the live chain state; results may differ for gas-sensitive encodings. | -| `GET /context/constants` | Several constants differ from mainnet: `minimal_block_delay` = 1 s; `hard_gas_limit_per_operation` = 660,000 gas (≈ 30 M EVM gas ÷ 22); `cost_per_byte` = 1 mutez. | +| `GET /context/constants` | Several constants differ from mainnet: `minimal_block_delay` = 1 s (the protocol encoding cannot express sub-second periods; actual block cadence follows Etherlink blocks, down to 500 ms under load); `hard_gas_limit_per_operation` = 660,000 gas (the 30M EVM per-transaction gas cap converted at 22 milligas per EVM gas unit); `cost_per_byte` = 1 mutez. | diff --git a/docs/michelson/developing/smart-contracts.md b/docs/michelson/developing/smart-contracts.md index c8fe6020..342b4e0b 100644 --- a/docs/michelson/developing/smart-contracts.md +++ b/docs/michelson/developing/smart-contracts.md @@ -8,3 +8,9 @@ Smart contracts can be developed using the same languages as in Tezos L1 (e.g., Refer to section [Smart contracts](https://docs.tezos.com/smart-contracts) in the Tezos documentation. +:::note Differences from Tezos layer 1 +The Michelson interface is not byte-for-byte layer 1: `simulate_operation` is only partially implemented (which affects fee estimation in tools such as Taquito), the `async` injection mode is not honored yet, and storage costs 1 mutez per byte. +See [Compatibility with Tezos L1](/michelson/developing/compatibility) and the [RPC reference](/michelson/developing/rpc-reference) before porting a workflow. +::: + + diff --git a/docs/michelson/developing/tokens.md b/docs/michelson/developing/tokens.md index 8276741b..f286a6eb 100644 --- a/docs/michelson/developing/tokens.md +++ b/docs/michelson/developing/tokens.md @@ -6,5 +6,11 @@ title: Tokens Tokens defined and used in the Michelson interface generally adhere to different standards such as FA1.2, FA2, or FA2.1. -Refer to section [Tokens](https://docs.tezos.com/architecture/tokens) in the Tezos documentation for instructions on developing you own tokens. +Refer to section [Tokens](https://docs.tezos.com/architecture/tokens) in the Tezos documentation for instructions on developing your own tokens. + +:::note Differences from Tezos layer 1 +The Michelson interface is not byte-for-byte layer 1: `simulate_operation` is only partially implemented (which affects fee estimation in tools such as Taquito), the `async` injection mode is not honored yet, and storage costs 1 mutez per byte. +See [Compatibility with Tezos L1](/michelson/developing/compatibility) and the [RPC reference](/michelson/developing/rpc-reference) before porting a workflow. +::: + diff --git a/docs/michelson/getting-started.md b/docs/michelson/getting-started.md index fbcac1d0..720518c7 100644 --- a/docs/michelson/getting-started.md +++ b/docs/michelson/getting-started.md @@ -13,7 +13,9 @@ For network parameters and connection instructions, see [Michelson network infor ## 2. Get tez -For information on faucets and obtaining testnet tez, see [Michelson network information](/michelson/network-information). +For testing, the fastest path is [Previewnet](/testing/previewnet), whose faucet funds Michelson-interface accounts directly. +On Mainnet, [bridge tez from Tezos layer 1](/michelson/bridging). +For the current status of the Shadownet faucet, see [Michelson network information](/michelson/network-information). ## 3. Interact with a smart contract @@ -21,7 +23,7 @@ Once your wallet is funded, you can interact with any Michelson smart contract d - Use the Tezos RPC or a higher-level SDK such as **Taquito** to originate contracts and send transactions. - Use LIGO, SmartPy, or any other Michelson-targeting language to write contracts. Deploy them the same way you would on Tezos L1. -- Block explorers such as TzKT display operations and contract state. +- Indexer and block explorer support for the Michelson interface is in progress; see [Michelson network information](/michelson/network-information) for current status. ## 4. Try native atomic composability diff --git a/docs/michelson/network-information.md b/docs/michelson/network-information.md index 59599957..de1e2a10 100644 --- a/docs/michelson/network-information.md +++ b/docs/michelson/network-information.md @@ -24,7 +24,7 @@ In that case, the URL of your endpoint is `/tezlink` (the pat | Network parameter | Value | |---|---| | Network identifier | `NetXohUVN5QWR4f` | -| Endpoint | michelson.etherlink.mainnet.octez.io | +| Endpoint | https://michelson.etherlink.mainnet.octez.io | | Indexer | Not yet available | | Bridge | Native tez only (see [Bridging](/michelson/bridging)); for FA tokens, [bridge to the EVM interface](/evm/bridging) and use them via [NAC](/michelson/nac-usage) | @@ -33,16 +33,16 @@ In that case, the URL of your endpoint is `/tezlink` (the pat | Network parameter | Value | |---|---| | Network identifier | `NetXtLrzvQDobza` | -| Endpoint | michelson.etherlink.shadownet.octez.io | +| Endpoint | https://michelson.etherlink.shadownet.octez.io | | Indexer | Not yet available | | Faucet | Not yet available; in the meantime, [get EVM test tokens](/evm/get-started/getting-testnet-tokens) | | Bridge | Native tez only (see [Bridging](/michelson/bridging)); for FA tokens, [bridge to the EVM interface](/evm/bridging) and use them via [NAC](/michelson/nac-usage) | -## Etherlink Previewnet Testnet +## Tezos X Previewnet Testnet See [Previewnet](/testing/previewnet) page. -## Quick connectivity check: +## Quick connectivity check ``` bash curl -s /chains/main/chain_id diff --git a/docs/michelson/self-address.md b/docs/michelson/self-address.md index 70fa20a5..445ea358 100644 --- a/docs/michelson/self-address.md +++ b/docs/michelson/self-address.md @@ -1,5 +1,5 @@ --- -title: Self-address test +title: Aliases and caller-equals-self --- # `SENDER == SELF_ADDRESS` is externally inducible diff --git a/docs/michelson/tools/dapps.md b/docs/michelson/tools/dapps.md index 6f0f2211..2584f3c7 100644 --- a/docs/michelson/tools/dapps.md +++ b/docs/michelson/tools/dapps.md @@ -4,5 +4,11 @@ title: Dapps # Dapps -For developping distributed applications (dApps) on the Michelson interface, refer to section [Dapps](https://docs.tezos.com/dApps) in the Tezos documentation. +For developing distributed applications (dApps) on the Michelson interface, refer to section [Dapps](https://docs.tezos.com/dApps) in the Tezos documentation. + +:::note Differences from Tezos layer 1 +The Michelson interface is not byte-for-byte layer 1: `simulate_operation` is only partially implemented (which affects fee estimation in tools such as Taquito), the `async` injection mode is not honored yet, and storage costs 1 mutez per byte. +See [Compatibility with Tezos L1](/michelson/developing/compatibility) and the [RPC reference](/michelson/developing/rpc-reference) before porting a workflow. +::: + diff --git a/docs/michelson/wallet-support.md b/docs/michelson/wallet-support.md index f1a311fd..d923f1c3 100644 --- a/docs/michelson/wallet-support.md +++ b/docs/michelson/wallet-support.md @@ -16,7 +16,7 @@ Any Tezos-compatible wallet that supports custom RPC endpoints can be used with ## Connecting to Etherlink 1. Open your wallet's network settings. -2. Add a custom network using the Etherlink Michelson RPC endpoint from the [previewnet repository](https://github.com/trilitech/tezos-x-previewnet). +2. Add a custom network using a Michelson RPC endpoint from [Michelson network information](/michelson/network-information) (or the [Previewnet](/testing/previewnet) endpoint for testing). 3. Switch to the custom network. Your tz address and balance will be shown as usual. Transactions are signed and submitted the same way as on Tezos Layer 1. diff --git a/docs/network/architecture.md b/docs/network/architecture.md index 03e8e692..bd8a43fe 100644 --- a/docs/network/architecture.md +++ b/docs/network/architecture.md @@ -10,7 +10,66 @@ These components are instances of binaries in the [Octez software suite](https:/ ## High-level diagram -![A high-level diagram of the Etherlink architecture, showing the interaction between the nodes and the sequencer](/img/architecture-high-level.png) + + + + + + + + + + + + + + + CLIENTS + + Web app + + Wallet + + ETHERLINK + + + + EVM nodes + Ethereum JSON-RPC + Tezos RPC + + Sequencer + + + + Smart Rollup + nodes + + Smart Rollup node + operator / batcher + + TEZOS LAYER 1 + + + + Layer 1 nodes + + + transactions + + txs + + blocks + + verify L1 finality + + send blocks + + track + + publish blocks + and commitments + ## Sequencer @@ -47,6 +106,7 @@ Only one account can run the sequencer; see [Sequencer governance](/governance/h Etherlink relies on three types of nodes, with instances of each type running in different modes: - EVM nodes (`octez-evm-node`): The EVM nodes running in sequencer observer mode maintain a local copy of the Etherlink context and expose a [JSON RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/)-compliant endpoint for clients to submit transactions to. +Since Etherlink 7.0, they also expose the [Tezos RPC](/michelson/developing/rpc-reference) endpoint of the Michelson interface. They forward these transactions to the sequencer and receive transactions from the sequencer, which they use to update their state. They also check Smart Rollup nodes to verify that these transactions make it to Tezos layer 1. @@ -96,8 +156,82 @@ If users submit multiple transactions that depend on each other (that is, they h This diagram summarizes the transaction process: -![A more detailed diagram of Etherlink architecture, showing the flow of transactions and blocks](/img/architecture-full.png) -{/* https://lucid.app/lucidchart/b363063d-f1fe-4081-a717-f7ae9dae4242/edit */} + + + + + + + + + + + + + + + CLIENTS + + Web app + + Wallet + + ETHERLINK + + + + EVM nodes + sequencer observer mode + + SEQUENCER + + EVM node + sequencer mode + + + + Smart Rollup + nodes + track layer 1 + + Smart Rollup node + operator / batcher + + TEZOS LAYER 1 + + + + Layer 1 nodes + + BLOCK + - metadata, hash of the previous block + - layer 1 transactions and operations + - Smart Rollup inbox messages + (including Etherlink blocks) + - hashes of Smart Rollup states + (including Etherlink), posted as + commitments + + + send transactions + + txs + + blocks + + verify blocks are + published on layer 1 + + send blocks + + track layer 1 and + receive Etherlink blocks + + publish Etherlink blocks + in the Smart Rollup inbox + + create + ### Delayed inbox transaction processing diff --git a/docs/network/building-kernel.mdx b/docs/network/building-kernel.mdx index 2e559a52..49698d42 100644 --- a/docs/network/building-kernel.mdx +++ b/docs/network/building-kernel.mdx @@ -7,8 +7,8 @@ dependencies: import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -It's not necessary to build the Etherlink{/* TX */} kernel. -You can set the `pre-images-endpoint` field in the Smart Rollup node's configuration file as described in [Running an Etherlink{/* TX */} Smart Rollup node](/network/smart-rollup-nodes). +It's not necessary to build the Etherlink kernel. +You can set the `pre-images-endpoint` field in the Smart Rollup node's configuration file as described in [Running an Etherlink Smart Rollup node](/network/smart-rollup-nodes). You can also download the installer kernel here: [installer.hex](pathname:///files/installer.hex). However, if you want to build the kernel yourself, you can use these instructions. @@ -21,7 +21,7 @@ For more information about installer kernels and preimages, see the tutorial [De Before you begin, make sure that you have these prerequisites installed: -- Docker, because the Etherlink{/* TX */} build process relies on a Docker image to ensure reproducible builds +- Docker, because the Etherlink build process relies on a Docker image to ensure reproducible builds - Rust, because of its support for WebAssembly (WASM), the language that Smart Rollups use to communicate. @@ -152,7 +152,7 @@ Before you begin, make sure that you have these prerequisites installed: make -f kernels.mk build-deps kernel_sdk ``` - 1. Set the parameters for the Etherlink{/* TX */} kernel by running this command, which sets the chain ID, governance and bridge contracts, and other values: + 1. Set the parameters for the Etherlink kernel by running this command, which sets the chain ID, governance and bridge contracts, and other values: ```bash octez-evm-node make kernel installer config setup_file.yml --chain-id 42793 \ @@ -198,7 +198,7 @@ Before you begin, make sure that you have these prerequisites installed: make -f kernels.mk build-deps kernel_sdk ``` - 1. Set the parameters for the Etherlink{/* TX */} kernel by running this command, which sets the chain ID, governance and bridge contracts, and other values: + 1. Set the parameters for the Etherlink kernel by running this command, which sets the chain ID, governance and bridge contracts, and other values: ```bash octez-evm-node make kernel installer config setup_file.yml \ diff --git a/docs/network/evm-nodes.mdx b/docs/network/evm-nodes.mdx index 6334a327..e7b74cad 100644 --- a/docs/network/evm-nodes.mdx +++ b/docs/network/evm-nodes.mdx @@ -7,13 +7,13 @@ dependencies: import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -The EVM nodes{/* TXN */} are responsible for maintaining a copy of the Etherlink{/* TX */} context and applying new blocks that process Etherlink{/* TX */} transactions. +The EVM nodes are responsible for maintaining a copy of the Etherlink context and applying new blocks that process Etherlink transactions. ## Prerequisites -- Make sure you understand the interaction between different nodes as described in [Etherlink{/* TX */} architecture](/network/architecture). -- If you want to verify the blocks that come from the sequencer, run an Etherlink{/* TX */} Smart Rollup node as described in [Running an Etherlink{/* TX */} Smart Rollup node](/network/smart-rollup-nodes). -Public Smart Rollup nodes for Etherlink{/* TX */} are not yet available, so you must run your own if you want to participate in the Etherlink{/* TX */} network. +- Make sure you understand the interaction between different nodes as described in [Etherlink architecture](/network/architecture). +- If you want to verify the blocks that come from the sequencer, run an Etherlink Smart Rollup node as described in [Running an Etherlink Smart Rollup node](/network/smart-rollup-nodes). +Public Smart Rollup nodes for Etherlink are not yet available, so you must run your own if you want to participate in the Etherlink network. ## System requirements @@ -34,7 +34,7 @@ If you don't want to see all of the options and settings for the EVM node, you c 1. Download the latest release of the `octez-evm-node` binary from https://gitlab.com/tezos/tezos/-/releases. :::note - Version 0.64 or later of the `octez-evm-node` binary is required to support the Etherlink{/* TX */} kernel 7.0. + Version 0.64 or later of the `octez-evm-node` binary is required to support the Etherlink kernel 7.0. ::: 1. Run the `octez-evm-node run observer` command to start the node as an observer: @@ -42,7 +42,7 @@ If you don't want to see all of the options and settings for the EVM node, you c - Use this command for Etherlink{/* TX */} Mainnet: + Use this command for Etherlink Mainnet: ```bash octez-evm-node run observer \ @@ -55,7 +55,7 @@ If you don't want to see all of the options and settings for the EVM node, you c - Use this command for Etherlink{/* TX */} Shadownet Testnet: + Use this command for Etherlink Shadownet Testnet: ```bash octez-evm-node run observer \ @@ -78,9 +78,9 @@ See [Verifying that the node is running](#verifying-that-the-node-is-running). The EVM node supports these history modes: -- `archive` (the default): The node stores a copy of all available Etherlink{/* TX */} information. +- `archive` (the default): The node stores a copy of all available Etherlink information. -- `full`: The node stores all of the necessary information to construct the current Etherlink{/* TX */} state plus the states for a certain number of previous days, known as the _retention period_. +- `full`: The node stores all of the necessary information to construct the current Etherlink state plus the states for a certain number of previous days, known as the _retention period_. - `rolling`: The node stores the current context plus the complete transaction data for a certain number of previous days, known as the _retention period_. @@ -126,7 +126,7 @@ For example, this command runs the EVM node in the Docker container on port 8545 :::note The EVM node exposes the Michelson (Tezos-compatible) RPCs at the -`/tezlink` sub-path of the node's base endpoint. +`/tezlink` sub-path of the node's base endpoint (a legacy path name that may be renamed to `/michelson` in a future version). For example, if your local node listens on the default port, the Michelson endpoint is `http://localhost:8545/tezlink`. @@ -145,8 +145,8 @@ The following instructions use the placeholder `` to represent thi You can set a different location for the file if you want to separate the data directory from the node configuration, such as often happens in Kubernetes. The default location is the file `config.json` in the data directory. - The network to use, which you specify in the `--network` argument or the `EVM_NODE_NETWORK` environment variable. - - `--network mainnet` for Etherlink{/* TX */} Mainnet - - `--network shadownet` for Etherlink{/* TX */} Shadownet + - `--network mainnet` for Etherlink Mainnet + - `--network shadownet` for Etherlink Shadownet Choosing a network sets the node to use preimages that the Tezos Foundation hosts on a file server on a so-called "preimages endpoint". It also sets the relay endpoint that the node uses to connect to other nodes on the network. @@ -172,18 +172,18 @@ The default location is the file `config.json` in the data directory. It's safe to use these preimages because the node verifies them. - If you don't want to use third-party preimages, you can build the kernel yourself and move the contents of the `wasm_2_0_0/` directory to the local data directory; see [Building the Etherlink{/* TX */} kernel](/network/building-kernel). - However, in this case, you must manually update this directory with the preimages of every kernel voted by the community and deployed on Etherlink{/* TX */} after that. + If you don't want to use third-party preimages, you can build the kernel yourself and move the contents of the `wasm_2_0_0/` directory to the local data directory; see [Building the Etherlink kernel](/network/building-kernel). + However, in this case, you must manually update this directory with the preimages of every kernel voted by the community and deployed on Etherlink after that. When you have the information for these parameters, follow these steps to generate the configuration file: -1. If you want your EVM node to check the correctness of the blocks it receives via a Smart Rollup node, get the RPC URL of that Etherlink{/* TX */} Smart Rollup node, such as `http://localhost:8932`. +1. If you want your EVM node to check the correctness of the blocks it receives via a Smart Rollup node, get the RPC URL of that Etherlink Smart Rollup node, such as `http://localhost:8932`. The following instructions use the placeholder `` to represent this URL. -You can use a Smart Rollup node that is running in any mode and history mode as long as it is up to date with the current state of Etherlink{/* TX */}. +You can use a Smart Rollup node that is running in any mode and history mode as long as it is up to date with the current state of Etherlink. 1. Create a directory for the node to store its data in. 1. Create the configuration file by setting the parameters in the environment variables or passing the arguments to the `octez-evm-node init config` command. - If you are not running an Etherlink{/* TX */} Smart Rollup node and are trusting incoming blocks, use the `--dont-track-rollup-node` flag, as in this `mainnet` example: + If you are not running an Etherlink Smart Rollup node and are trusting incoming blocks, use the `--dont-track-rollup-node` flag, as in this `mainnet` example: ```bash octez-evm-node init config \ @@ -217,7 +217,7 @@ You can initialize and start the node in several ways: - [From a snapshot that the node downloads automatically](#from-an-automatic-snapshot) - [From a snapshot that you download manually](#from-a-manual-snapshot) -- [From an existing Etherlink{/* TX */} Smart Rollup node](#from-an-existing-etherlink-smart-rollup-node) +- [From an existing Etherlink Smart Rollup node](#from-an-existing-etherlink-smart-rollup-node) - [From genesis](#from-genesis) For a faster way of running a node locally for a short time, see [Running a local sandbox](/testing/sandbox). @@ -350,17 +350,17 @@ The node throws an error if you try to run it in a mode that it is not configure ### From an existing Etherlink Smart Rollup node -You can use the Etherlink{/* TX */} Smart Rollup node to initialize a data directory for the EVM node without having to actually start the Smart Rollup node. +You can use the Etherlink Smart Rollup node to initialize a data directory for the EVM node without having to actually start the Smart Rollup node. The `octez-smart-rollup-node` binary sets up a data directory that the EVM node can use as a starting point. -You can use a Smart Rollup node that is running in any mode and history mode as long as it is up to date with the current state of Etherlink{/* TX */}. +You can use a Smart Rollup node that is running in any mode and history mode as long as it is up to date with the current state of Etherlink. 1. Get a built version of the Smart Rollup node binary, named `octez-smart-rollup-node`. -The best place to get the most recent binary files to use with Etherlink{/* TX */} is https://gitlab.com/tezos/tezos/-/releases. +The best place to get the most recent binary files to use with Etherlink is https://gitlab.com/tezos/tezos/-/releases. -1. Get the URL of the Etherlink{/* TX */} Smart Rollup node snapshot for the appropriate Etherlink{/* TX */} network or download the file manually: +1. Get the URL of the Etherlink Smart Rollup node snapshot for the appropriate Etherlink network or download the file manually: - - Etherlink{/* TX */} Mainnet: https://snapshots.tzinit.org/etherlink-mainnet - - Etherlink{/* TX */} Shadownet Testnet: https://snapshots.tzinit.org/etherlink-shadownet + - Etherlink Mainnet: https://snapshots.tzinit.org/etherlink-mainnet + - Etherlink Shadownet Testnet: https://snapshots.tzinit.org/etherlink-shadownet The full history snapshot is appropriate for most use cases. The EVM node can run in any history mode starting from a Smart Rollup node that starts from these snapshots. @@ -395,8 +395,8 @@ The following `mainnet` examples use `` as the location of ### From genesis -1. Get the Etherlink{/* TX */} installer kernel (`installer.hex` file), which you can build yourself as described in [Building the Etherlink{/* TX */} kernel](/network/building-kernel) or download here: [installer.hex](pathname:///files/installer.hex). -1. Run this command to start the node with the Etherlink{/* TX */} installer kernel that you built or downloaded; change the name of the `installer.hex` file in the command accordingly: +1. Get the Etherlink installer kernel (`installer.hex` file), which you can build yourself as described in [Building the Etherlink kernel](/network/building-kernel) or download here: [installer.hex](pathname:///files/installer.hex). +1. Run this command to start the node with the Etherlink installer kernel that you built or downloaded; change the name of the `installer.hex` file in the command accordingly: ```bash octez-evm-node run observer --data-dir --initial-kernel installer.hex diff --git a/docs/network/smart-rollup-nodes.mdx b/docs/network/smart-rollup-nodes.mdx index 8209f811..72f3e4fe 100644 --- a/docs/network/smart-rollup-nodes.mdx +++ b/docs/network/smart-rollup-nodes.mdx @@ -7,30 +7,30 @@ dependencies: import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -Etherlink{/* TX */} uses Smart Rollup nodes as a bridge between the Etherlink{/* TX */} transactions on the EVM nodes and Tezos layer 1. -Public Smart Rollup nodes for Etherlink{/* TX */} are not yet available, so you must run your own if you want to participate in the Etherlink{/* TX */} network. +Etherlink uses Smart Rollup nodes as a bridge between the Etherlink transactions on the EVM nodes and Tezos layer 1. +Public Smart Rollup nodes for Etherlink are not yet available, so you must run your own if you want to participate in the Etherlink network. :::note -In this context, an _Etherlink{/* TX */} Smart Rollup node_ is an [Octez Smart Rollup node](https://octez.tezos.com/docs/shell/smart_rollup_node.html) that runs the Etherlink{/* TX */} kernel. -This kernel is a Rust program compiled in WASM implementing the semantics of Etherlink{/* TX */} blocks and transactions. +In this context, an _Etherlink Smart Rollup node_ is an [Octez Smart Rollup node](https://octez.tezos.com/docs/shell/smart_rollup_node.html) that runs the Etherlink kernel. +This kernel is a Rust program compiled in WASM implementing the semantics of Etherlink blocks and transactions. ::: To start, the node uses the _installer kernel_, which is a compressed version of the kernel that provides only enough information to install the original kernel. The data for the original kernel is stored in separate files called _preimages_. -You can run the Smart Rollup node starting from Etherlink{/* TX */} genesis or from a snapshot of a recent Etherlink{/* TX */} state. +You can run the Smart Rollup node starting from Etherlink genesis or from a snapshot of a recent Etherlink state. ## System requirements -Running an Etherlink{/* TX */} Smart Rollup node on Etherlink{/* TX */} Mainnet requires a computer with 500GB of disk space and at least 16GB RAM. +Running an Etherlink Smart Rollup node on Etherlink Mainnet requires a computer with 500GB of disk space and at least 16GB RAM. ## Modes -Running the Smart Rollup node in operator or maintenance mode is the best way to participate in Etherlink{/* TX */} because in these modes the node posts commitments about Etherlink{/* TX */}'s state to layer 1. -These commitments validate Etherlink{/* TX */}'s state and ensure that Etherlink{/* TX */} is processing blocks and transactions honestly according to its kernel. -As described in [Smart Rollups](https://docs.tezos.com/architecture/smart-rollups) on docs.tezos.com, one honest node is enough to ensure that Etherlink{/* TX */} is running correctly, but adding more nodes strengthens its security and allows users to verify for themselves that Etherlink{/* TX */} is running as intended. +Running the Smart Rollup node in operator or maintenance mode is the best way to participate in Etherlink because in these modes the node posts commitments about Etherlink's state to layer 1. +These commitments validate Etherlink's state and ensure that Etherlink is processing blocks and transactions honestly according to its kernel. +As described in [Smart Rollups](https://docs.tezos.com/architecture/smart-rollups) on docs.tezos.com, one honest node is enough to ensure that Etherlink is running correctly, but adding more nodes strengthens its security and allows users to verify for themselves that Etherlink is running as intended. The best way to run a node that can post commitments is to start with a node in observer mode, verify that it works, and convert it to maintenance mode. Maintenance mode is similar to operator mode but it does not require settings for batching operations, which are required only for sequencer nodes. @@ -39,7 +39,7 @@ For more information on modes, see [Smart Rollup node](https://octez.tezos.com/d ## References -Make sure that you understand the interaction between different nodes as described in [Etherlink{/* TX */} architecture](/network/architecture). +Make sure that you understand the interaction between different nodes as described in [Etherlink architecture](/network/architecture). For more information about Smart Rollup nodes in general, see [Smart Rollups](https://docs.tezos.com/architecture/smart-rollups) on docs.tezos.com and [Smart Rollup Node](https://octez.tezos.com/docs/shell/smart_rollup_node.html) in the Octez documentation. @@ -54,7 +54,7 @@ After the node has started, you can switch to a rolling node. Follow these steps to start the node in observer mode: 1. Get a built version of the Smart Rollup node binary, named `octez-smart-rollup-node`. -The best place to get the most recent binary files to use with Etherlink{/* TX */} is https://gitlab.com/tezos/tezos/-/releases. +The best place to get the most recent binary files to use with Etherlink is https://gitlab.com/tezos/tezos/-/releases. 1. Initialize the local context of the node, which is where it stores local data: @@ -62,14 +62,14 @@ The best place to get the most recent binary files to use with Etherlink{/* TX * The default directory is `$HOME/.tezos-smart-rollup-node`. The following instructions use the placeholder `` to represent this directory. - 1. Initialize the local context by running this command and passing the address of the Etherlink{/* TX */} Smart Rollup and the preimages endpoint. + 1. Initialize the local context by running this command and passing the address of the Etherlink Smart Rollup and the preimages endpoint. You can get this information on the [Network information](/evm/get-started/network-information) page. - This command initializes the context for Etherlink{/* TX */} Mainnet: + This command initializes the context for Etherlink Mainnet: ```bash octez-smart-rollup-node init observer config for sr1Ghq66tYK9y3r8CC1Tf8i8m5nxh8nTvZEf \ @@ -89,7 +89,7 @@ The best place to get the most recent binary files to use with Etherlink{/* TX * - For Etherlink{/* TX */} Shadownet Testnet, use this command: + For Etherlink Shadownet Testnet, use this command: ```bash octez-smart-rollup-node init observer config for sr19fMYrr5C4qqvQqQrDSjtP31GcrWjodzvg \ @@ -112,15 +112,15 @@ The best place to get the most recent binary files to use with Etherlink{/* TX * This configuration uses the preimages that the Tezos Foundation hosts on a file server on a so-called "preimages endpoint". It's safe to use these preimages because the node verifies them. - If you don't want to use third-party preimages, you can build the kernel yourself and move the contents of the `wasm_2_0_0/` directory to the local data directory; see [Building the Etherlink{/* TX */} kernel](/network/building-kernel). - However, in this case, you must manually update this directory with the preimages of every kernel voted by the community and deployed on Etherlink{/* TX */} after that. + If you don't want to use third-party preimages, you can build the kernel yourself and move the contents of the `wasm_2_0_0/` directory to the local data directory; see [Building the Etherlink kernel](/network/building-kernel). + However, in this case, you must manually update this directory with the preimages of every kernel voted by the community and deployed on Etherlink after that. 1. To speed up the setup process by loading a snapshot, follow these steps: - 1. Get the URL of the Etherlink{/* TX */} Smart Rollup node full history snapshot for the appropriate Etherlink{/* TX */} network or download the file manually: + 1. Get the URL of the Etherlink Smart Rollup node full history snapshot for the appropriate Etherlink network or download the file manually: - - Etherlink{/* TX */} Mainnet: https://snapshots.tzinit.org/etherlink-mainnet - - Etherlink{/* TX */} Shadownet Testnet: https://snapshots.tzinit.org/etherlink-shadownet + - Etherlink Mainnet: https://snapshots.tzinit.org/etherlink-mainnet + - Etherlink Shadownet Testnet: https://snapshots.tzinit.org/etherlink-shadownet The full history snapshot is appropriate for most use cases. If you want to run an EVM node with the Smart Rollup node, they do not need to run in the same history mode. @@ -184,7 +184,7 @@ For example, this query gets the health of the node: curl -s http://localhost:8932/health ``` - If the response includes the fields `healthy: false` and the `blocks_late` field is more than 0, the node is catching up to the current state of Etherlink{/* TX */}. + If the response includes the fields `healthy: false` and the `blocks_late` field is more than 0, the node is catching up to the current state of Etherlink. ```json { @@ -205,7 +205,7 @@ For example, this query gets the health of the node: 1. Wait until the response includes the field `healthy: true` and the `blocks_late` field is 0. -Now the Smart Rollup node is running and tracking the state of Etherlink{/* TX */} by receiving information from layer 1. +Now the Smart Rollup node is running and tracking the state of Etherlink by receiving information from layer 1. ## Converting the Smart Rollup node to maintenance mode @@ -357,7 +357,7 @@ For example, this query gets the health of the node: By default, the Smart Rollup node exposes its JSON RPC API endpoint to `localhost:8932`. To set the host name or port that the node listens on, use the `--rpc-addr` or `--rpc-port` arguments of the `octez-smart-rollup-node run` command. -Now that you have a Smart Rollup node configured for Etherlink{/* TX */}, you can run an EVM node{/* TXN */}, as described in [Running an EVM node{/* TXN */}](/network/evm-nodes). +Now that you have a Smart Rollup node configured for Etherlink, you can run an EVM node, as described in [Running an EVM node](/network/evm-nodes). ## Stopping the Smart Rollup node @@ -374,7 +374,7 @@ The Smart Rollup node respects SIGTERM and exits cleanly when stopped. ::: -Follow these steps to stop an Etherlink{/* TX */} Smart Rollup node: +Follow these steps to stop an Etherlink Smart Rollup node: 1. Stop the node temporarily. @@ -405,5 +405,5 @@ octez-client recover bond of for smart rollup `: The account that you used to run the Smart Rollup in operator mode -- ``: The address of the Etherlink{/* TX */} Smart Rollup +- ``: The address of the Etherlink Smart Rollup - ``: The account to use to send this `recover bond` operation diff --git a/docs/overview/architecture.md b/docs/overview/architecture.md index c0fcdcdd..b0b6177f 100644 --- a/docs/overview/architecture.md +++ b/docs/overview/architecture.md @@ -20,7 +20,7 @@ The goal for each interface is to stay as compatible as possible with the origin ### Bridging vs. NAC -When an EVM contract calls a Michelson contract on Etherlink, both execution steps happen inside the same rollup kernel, within a single block: +When an EVM contract calls a Michelson contract on Etherlink, both execution steps happen inside the same rollup kernel, within a single block. @@ -102,25 +102,57 @@ In both bridging cases, the two sides are separate ledgers that must be reconcil The diagram below shows what happens inside a single block when an EVM contract calls a Michelson contract through the gateway precompile. -```mermaid -sequenceDiagram - actor U as EVM user - participant EVM as EVM runtime - participant GW as Gateway precompile - participant M as Michelson runtime - participant KT as KT1… contract - - U->>EVM: send transaction - EVM->>GW: callMichelson("KT1…", "entrypoint", data) - GW->>M: cross-runtime dispatch - M->>KT: execute entrypoint - KT-->>M: storage updated - M-->>GW: success / revert - GW-->>EVM: outcome - EVM-->>U: transaction receipt - - Note over EVM,M: One atomic transaction — all or nothing -``` + + + + + + + + + + + + + + + EVM user + + + EVM runtime + + + Gateway precompile + + + Michelson runtime + + + KT1… contract + + + + + + + send transaction + + callMichelson("KT1…", "entrypoint", data) + + cross-runtime dispatch + + execute entrypoint + + storage updated + + success / revert + + outcome + + transaction receipt + + One atomic transaction — all or nothing + Because the two runtimes share the same ledger, there are no wrapped tokens to mint or burn, no bridge relayer to trust, and no risk of one side completing while the other fails. @@ -132,7 +164,7 @@ Etherlink is powered by a [Tezos Smart Rollup](https://docs.tezos.com/a - **Sequencer** — elected by Tezos Layer 1 bakers, the sequencer orders and batches operations from all interfaces into _blueprints_, which it publishes to the L1 rollup inbox. It targets a block time of around 500 ms, and offers pre-confirmations in about 50ms. - **Rollup nodes** — apply blueprints (including operations from all interfaces) to produce Etherlink blocks and maintain the chain state. Each rollup node derives a per-interface block from each Etherlink block. - **EVM nodes** — expose the two JSON-RPC APIs, backed respectively by the EVM runtime state and Michelson runtime state. - Thus, they could be called "Etherlink nodes" by now, but we keep calling them "EVM nodes" because the corresponding executable is still called `octez-evm-node`. + The name is historical: these nodes now serve both interfaces, but the corresponding executable is still called `octez-evm-node`. - **Tezos nodes** — expose the Tezos Layer 1 RPC API. Operations submitted via either interface to the corresponding runtime are collected by the sequencer, interleaved in first-in-first-out order, and included in the next blueprint. diff --git a/docs/overview/glossary.md b/docs/overview/glossary.md index 7e253f87..99e53676 100644 --- a/docs/overview/glossary.md +++ b/docs/overview/glossary.md @@ -6,7 +6,6 @@ title: Glossary This glossary defines the most essential terms used in Etherlink. For a wider set of terms used in the Tezos ecosystem, see the [Glossary](https://docs.tezos.com/overview/glossary) in the Tezos documentation. -These glossaries are planned to be fused in the near term. **ABI encoding** — The binary format used to encode function arguments and return values when calling EVM smart contracts. Each argument occupies a 32-byte slot: integers and addresses are left-padded with zeros; dynamic types such as `bytes` use an offset-length-data layout. ABI-encoded data is what `%call_evm` expects in its `abi_params` field and what `staticcall_evm` and `callMichelsonView` return. diff --git a/docs/overview/index.md b/docs/overview/index.md index f9182aa6..3393acc9 100644 --- a/docs/overview/index.md +++ b/docs/overview/index.md @@ -16,7 +16,7 @@ Built upon the secure foundation of Tezos layer 1, Etherlink delivers ## It's fast Experience a developer-friendly environment that minimizes wait times. -Etherlink provides low latency with sub-second (< 500ms) confirmation times, delivered by the sequencer. +Etherlink provides low latency with confirmation times of around 500 ms, delivered by the sequencer. And it's getting even faster with [Instant Confirmations](/evm/developing/transactions#getting-instant-confirmations), currently an experimental feature, that provide pre-confirmations within 50ms. diff --git a/docs/progress/upgrades.md b/docs/progress/upgrades.md index c9f3e1a0..3b902bf8 100644 --- a/docs/progress/upgrades.md +++ b/docs/progress/upgrades.md @@ -107,7 +107,7 @@ Instant Confirmations enable these features: - Users can call the `eth_sendRawTransactionSync` endpoint that is available in the EVM node version 0.52 and later to submit a transaction and wait for an instant confirmation from the node when the transaction will be in the next block. For more information, see [Getting Instant Confirmations](/evm/developing/transactions#getting-instant-confirmations). - - Uses can subscribe to notifications via WebSockets to get information about transactions that the sequencer will put in the next block. + - Users can subscribe to notifications via WebSockets to get information about transactions that the sequencer will put in the next block. For more information, see [Subscribing to Instant Confirmations](/evm/developing/websockets#subscribing-to-instant-confirmations). - The speed limit (also known as the target) is increased to 13.5 million gas units per second. @@ -173,7 +173,13 @@ For more information, see [Announcing Etherlink 6.6: a security hardening kernel ## Etherlink 7.0 (Ganesha) -The Etherlink 7.0 upgrade went live on 20 August 2026 through the fast kernel governance process and brought the largest expansion of Etherlink's scope since launch. +:::note + +Etherlink 7.0 requires version 0.64 or later of the `octez-evm-node` binary. + +::: + +The Etherlink 7.0 upgrade went live on 21 August 2026 through the fast kernel governance process and brought the largest expansion of Etherlink's scope since launch. In particular, it added the new Michelson interface, which runs Michelson smart contracts and brings the Tezos account model to Etherlink, and Native Atomic Composability (NAC) for seamlessly combining EVM and Michelson contracts. Etherlink 7.0 was initially proposed through the slow kernel governance process on 2 August 2026. diff --git a/docs/testing/previewnet.md b/docs/testing/previewnet.md index e2178a2e..79af41fd 100644 --- a/docs/testing/previewnet.md +++ b/docs/testing/previewnet.md @@ -1,8 +1,8 @@ --- -title: Previewnet test network +title: Tezos X Previewnet test network --- -Previewnet is a public test network running the upgrade-7 feature set ahead of the other networks. +Tezos X Previewnet is a public test network running the upgrade-7 feature set ahead of the other networks. It has allowed builders and integrators to experiment with both the EVM and Michelson interfaces and with cross-interface interactions ahead of the upgrade 7 on Mainnet. ## Resources diff --git a/docs/testing/testnet.mdx b/docs/testing/testnet.mdx index 1be71763..4ffaaace 100644 --- a/docs/testing/testnet.mdx +++ b/docs/testing/testnet.mdx @@ -2,7 +2,7 @@ title: Developing on test networks --- -Etherlink{/* TX */} has an active test network named Etherlink{/* TX */} Shadownet Testnet, or Shadownet for short. +Etherlink has an active test network named Etherlink Shadownet Testnet, or Shadownet for short. It runs on the Tezos Shadownet test network. For technical details about Shadownet, see [EVM network information](/evm/get-started/network-information) and [Michelson network information](/michelson/network-information). @@ -15,12 +15,12 @@ The old testnet, Ghostnet Testnet, has been decommissioned, and is no longer usa ::: -For more information about the Tezos test networks that Etherlink{/* TX */} test networks run on, see [Testing on testnets](https://docs.tezos.com/developing/testnets) on docs.tezos.com. +For more information about the Tezos test networks that Etherlink test networks run on, see [Testing on testnets](https://docs.tezos.com/developing/testnets) on docs.tezos.com. ## Using test networks In most cases, you can use a test network in place of Mainnet by using the RPC URL of an EVM node that is running on that test network. -You can use the public RPC node for the network for a small number of transactions (because it has a rate limit), or you can run your own EVM node on the test network by following the instructions in [Running an EVM node{/* TXN */}](/network/evm-nodes). +You can use the public RPC node for the network for a small number of transactions (because it has a rate limit), or you can run your own EVM node on the test network by following the instructions in [Running an EVM node](/network/evm-nodes). Then, use the RPC URL in transactions, as in this example, which uses the public RPC node for the Shadownet Testnet: @@ -40,7 +40,7 @@ curl --request POST \ Examples of using test networks are on other pages in this documentation. -## Etherlink{/* TX */} Previewnet +## Tezos X Previewnet -The [Previewnet test network](/testing/previewnet) is a long-running test network that runs the upgrade-7 feature set (the Michelson interface and Native Atomic Composability) ahead of the other Etherlink{/* TX */} networks. +The [Tezos X Previewnet test network](/testing/previewnet) is a long-running test network that runs the upgrade-7 feature set (the Michelson interface and Native Atomic Composability) ahead of the other Etherlink networks. Previewnet is still available for some time. \ No newline at end of file diff --git a/docs/tutorials/nac-counter.md b/docs/tutorials/nac-counter.md index c2b7494c..3d92ad39 100644 --- a/docs/tutorials/nac-counter.md +++ b/docs/tutorials/nac-counter.md @@ -20,7 +20,7 @@ By the end you will have: 3. seen a successful cross-interface call (EVM transaction succeeds, Michelson storage changes), 4. seen an *atomic revert* (Michelson rejects the call, the EVM transaction reverts as a whole). -The whole walkthrough runs on the **Etherlink Previewnet**. +The whole walkthrough runs on the **Tezos X Previewnet**. --- @@ -205,7 +205,7 @@ The three entrypoints we'll use through NAC are: - `decrement` — subtracts 1; fails with `"at zero"` when storage is already 0. We'll use this to demonstrate atomic reverts. - `reset` — sets storage back to 0 (handy for re-running the demo). -### A.3 Connect Temple to the Previewnet +### A.3 Connect Temple to the Tezos X Previewnet 1. In Temple → **Settings → Networks → Add network**. 2. Set the RPC URL to `https://michelson.previewnet.tezosx.nomadic-labs.com` and use the values from the [network table](#network-values-read-this-first) above. @@ -258,7 +258,7 @@ Keep that terminal (or explorer tab) open — you'll come back to it after the E ## Part B — EVM contract and wallet interaction -### B.1 Connect MetaMask to the Previewnet +### B.1 Connect MetaMask to the Tezos X Previewnet The fastest path is the [Previewnet dashboard](https://previewnet.tezosx.nomadic-labs.com/) — click **Add to MetaMask** and approve. @@ -281,7 +281,7 @@ interface INativeAtomicGateway { } contract EvmToMichelsonCounter { - /// @dev Etherlink Previewnet NAC / EVM/Michelson gateway precompile. + /// @dev Tezos X Previewnet NAC / EVM/Michelson gateway precompile. address internal constant NAC_GATEWAY = 0xfF00000000000000000000000000000000000007; INativeAtomicGateway public immutable gateway; @@ -343,7 +343,7 @@ contract EvmToMichelsonCounter { Open [Remix](https://remix.ethereum.org), paste the contract above, and deploy as you would on any other EVM testnet: -- **Environment**: "Injected Provider — MetaMask", with MetaMask switched to the Etherlink Previewnet. +- **Environment**: "Injected Provider — MetaMask", with MetaMask switched to the Tezos X Previewnet. - **Constructor argument**: the Michelson counter `KT1…` string from Part A (e.g. `"KT1abc…"`). You can also deploy locally with Hardhat or Foundry — same network, same constructor argument. diff --git a/sidebars.js b/sidebars.js index dc225174..f62472a4 100644 --- a/sidebars.js +++ b/sidebars.js @@ -143,7 +143,6 @@ const sidebars = { 'michelson/developing/accounts', 'michelson/developing/tokens', 'michelson/developing/smart-contracts', - 'michelson/tools/dapps', 'michelson/developing/rpc-reference', ], }, @@ -151,6 +150,7 @@ const sidebars = { type: 'category', label: 'Tools', items: [ + 'michelson/tools/dapps', 'michelson/tools/tezos-unity-sdk', ], }, diff --git a/static/img/architecture-full.png b/static/img/architecture-full.png deleted file mode 100644 index ce24855c..00000000 Binary files a/static/img/architecture-full.png and /dev/null differ diff --git a/static/img/architecture-high-level.png b/static/img/architecture-high-level.png deleted file mode 100644 index b0c18afe..00000000 Binary files a/static/img/architecture-high-level.png and /dev/null differ diff --git a/static/img/bridging-deposit-fa.png b/static/img/bridging-deposit-fa.png deleted file mode 100644 index a362908f..00000000 Binary files a/static/img/bridging-deposit-fa.png and /dev/null differ diff --git a/static/img/bridging-deposit.png b/static/img/bridging-deposit.png deleted file mode 100644 index a2a0e8ae..00000000 Binary files a/static/img/bridging-deposit.png and /dev/null differ diff --git a/static/img/bridging-withdrawal-fa.png b/static/img/bridging-withdrawal-fa.png deleted file mode 100644 index cbd043d0..00000000 Binary files a/static/img/bridging-withdrawal-fa.png and /dev/null differ diff --git a/static/img/bridging-withdrawal.png b/static/img/bridging-withdrawal.png deleted file mode 100644 index 968d67e1..00000000 Binary files a/static/img/bridging-withdrawal.png and /dev/null differ diff --git a/static/img/wrapped-asset-bridge.png b/static/img/wrapped-asset-bridge.png deleted file mode 100644 index 99be42be..00000000 Binary files a/static/img/wrapped-asset-bridge.png and /dev/null differ
Etherlink{/* TX */} Smart RollupEtherlink Smart Rollup