diff --git a/docs/bridging/bridging-fa-how.md b/docs/bridging/bridging-fa-how.md index b15e90d2..b2ddb371 100644 --- a/docs/bridging/bridging-fa-how.md +++ b/docs/bridging/bridging-fa-how.md @@ -50,9 +50,9 @@ The request includes the amount of tokens to bridge, the address of the Etherlin 1. The sequencer reads the ticket and information about it from the delayed inbox, leaves the ticket in control of the Smart Rollup itself, and calls the null address precompiled contract (`0x000...000`) with the information. -1. The null address precompile sends the information about the deposit to the FA bridging precompiled contract (`0xff0...0002`), which then emits a `QueuedDeposit` event which contains the `depositId` information needed to complete the transfer. +1. The null address precompile sends the information about the deposit to the Tezos bridge precompiled contract (`0xff0...0002`), which then emits a `QueuedDeposit` event which contains the `depositId` information needed to complete the transfer. -1. Any user can call the FA bridging precompiled contract's `claim` function, which causes the contract to call the ERC-20 proxy contract. +1. Any user can call the Tezos bridge precompiled contract's `claim` function, which causes the contract to call the ERC-20 proxy contract. For tokens supported by the bridge, an automated program calls the `claim` function for you. 1. The ERC-20 proxy contract mints the equivalent tokens and sends them to the user's Etherlink account. @@ -65,7 +65,7 @@ This diagram is an overview of the process of bridging tokens from layer 1 to Et The process of bridging FA-compatible tokens from Etherlink to layer 1 (also known as withdrawing tokens) follows these general steps: -1. The user calls the FA bridging precompiled contract on Etherlink and includes this information: +1. The user calls the Tezos bridge precompiled contract on Etherlink and includes this information: - The address of the ERC-20 proxy contract that manages the tokens - The user's layer 1 address or the address of a contract to send the tokens to diff --git a/docs/bridging/bridging-fa-transactions.md b/docs/bridging/bridging-fa-transactions.md index 1bbac265..cfbe64d1 100644 --- a/docs/bridging/bridging-fa-transactions.md +++ b/docs/bridging/bridging-fa-transactions.md @@ -14,6 +14,8 @@ It takes a few transactions to bridge a token from layer 1 to Etherlink: - A transaction to initiate the deposit - A transaction to claim the tokens on Etherlink +This process is similar to the process of depositing XTZ tokens, as described in [Bridging to Tezos](/bridging/bridging-tezos). + Follow these steps to deposit FA-compliant tokens from layer 1 to Etherlink: 1. Give the token bridge helper contract access to the tokens, depending on the type of token: @@ -57,13 +59,13 @@ Follow these steps to deposit FA-compliant tokens from layer 1 to Etherlink: The token bridge helper contract sends the tokens to the ticketer contract, which issues a ticket that represents the tokens. The token bridge helper contract sends that ticket to Etherlink. -1. When the deposit is in an Etherlink block, call the FA bridging precompiled contract contract's `claim` function to cause the ERC-20 proxy contract to mint the tokens. +1. When the deposit is in an Etherlink block, call the Tezos bridge precompiled contract contract's `claim` function to cause the ERC-20 proxy contract to mint the tokens. - The address of the precompiled contract is `0xff00000000000000000000000000000000000002` and to call the function you can use the ABI `claim(uint256 depositId)`, where `depositId` matches the `depositId` that was emitted in a previous event for this transfer by the precompile (`QueuedDeposit(uint256 depositId, address recipient, uint256 amount, uint256 timelock, uint256 depositCount)`). + The address of the bridge contract is `0xff00000000000000000000000000000000000002` and to call the function you can use the ABI `claim(uint256 depositId)`, where `depositId` matches the `depositId` that was emitted in a previous event for this transfer by the precompile (`QueuedDeposit(uint256 depositId, address recipient, uint256 amount, uint256 timelock, uint256 depositCount)`). As a reference, here is an [example of the sequencer injecting a deposit](https://explorer.etherlink.com/tx/0x5a06fe64e880d6d1f53c243477cd5656204712f1543b607340996ad246158669) and here is an [example of the corresponding claim transaction](https://explorer.etherlink.com/tx/0xe017665cd7bfdef375a863114ac9f7ed2538da4d8584b0f1e0aa71ce96342aee). - The precompiled contract sends information about the deposit to the ERC-20 proxy contract, which mints the tokens and sends them to the Etherlink account. + The bridge contract sends information about the deposit to the ERC-20 proxy contract, which mints the tokens and sends them to the Etherlink account. :::note @@ -85,7 +87,7 @@ However, pending outbox transactions expire after a period equal to the refutati Therefore, if the system that runs these outbox transactions is down for two weeks after the refutation period ends, the transactions may be lost. Neither of these transactions are easy to do by yourself. -Initiating the withdrawal requires sending complex information about the ticket and contracts to the FA2 withdrawal precompile on Etherlink. +Initiating the withdrawal requires sending complex information about the ticket and contracts to the bridge contract on Etherlink. Running the outbox transaction requires you to know the level of the Etherlink commitment that contains it in order to get its proof and commitment, and there is no easy way to get that information without using an indexer to check each level for the transaction. The command-line tool at https://github.com/baking-bad/etherlink-bridge provides commands that can help with the withdrawal transactions. diff --git a/docs/bridging/bridging-tezos.md b/docs/bridging/bridging-tezos.md index 8629382a..28398798 100644 --- a/docs/bridging/bridging-tezos.md +++ b/docs/bridging/bridging-tezos.md @@ -74,19 +74,22 @@ The request includes the tez to bridge, the address of the Etherlink Smart Rollu 1. Etherlink Smart Rollup nodes receive the deposit transaction from the Smart Rollup inbox. 1. The Smart Rollup nodes put the deposit transaction in the delayed inbox. 1. The sequencer requests the state of Etherlink from a Smart Rollup node and receives the delayed inbox. -1. The sequencer creates a corresponding transaction on Etherlink to transfer XTZ from the [null address](https://explorer.etherlink.com/address/0x0000000000000000000000000000000000000000) to the user's address. -1. The sequencer adds this transaction to an Etherlink block as in the usual transaction lifecycle described in [Architecture](/network/architecture). +1. Depending on the target account, the sequencer handles the deposit in different ways: + + - If the target account is a user account (also known as an externally owned account), the sequencer creates a transaction that calls the [Tezos bridge precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) (`0xff0...0001`) that transfers the XTZ to the user account. + - If the target account is a smart contract or EIP-7702 smart account, the sequencer calls the Tezos bridge precompiled contract to queue but not execute a transaction to transfer the XTZ. + Then, any user can call the `claim` function to execute the transaction and send the XTZ to the smart contract or smart account and call its code. + An automated system run by Optimistic Labs monitors the calls the `claim` function on behalf of depositors, so the process is transparent to bridge users. This diagram is an overview of the deposit process: -![Overview of the token bridging deposit process](/img/bridging-deposit.png) - +![Overview of the token bridging deposit process](/img/bridging-deposit-xtz.png) ### Withdrawal process The withdrawal process (moving XTZ from Etherlink to tez on Tezos layer 1) follows these general steps: -1. An Etherlink 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 Etherlink EVM node. +1. An Etherlink user sends XTZ and their layer 1 address to the [Tezos bridge precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) in the Etherlink Smart Rollup via an Etherlink 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. diff --git a/docs/get-started/network-information.mdx b/docs/get-started/network-information.mdx index fe34b52c..ac8f26a7 100644 --- a/docs/get-started/network-information.mdx +++ b/docs/get-started/network-information.mdx @@ -227,12 +227,12 @@ These precompiled contracts are specific to Etherlink: - XTZ bridging + Tezos bridge - FA bridging + FA bridge diff --git a/docs/governance/how-is-etherlink-governed.md b/docs/governance/how-is-etherlink-governed.md index 8a47bd70..dd63cfbb 100644 --- a/docs/governance/how-is-etherlink-governed.md +++ b/docs/governance/how-is-etherlink-governed.md @@ -44,16 +44,16 @@ The Etherlink slow kernel governance process is a streamlined version of the [Te It consists of three periods: a Proposal period and a Promotion period, which are supervised by Etherlink's kernel governance contract, and a Cooldown period, which is enforced by the Etherlink kernel itself. The lengths of these periods are stored in the [kernel governance contract](https://better-call.dev/mainnet/KT1XdSAYGXrUDE1U5GNqUKKscLWrMhzyjNeh). -This table shows the period lengths as of the Ebisu Etherlink update and the Tezos Seoul protocol: +This table shows the period lengths as of Etherlink 6.2 and the Tezos Tallinn protocol: Period | Length | Approximate time --- | --- | --- -Proposal | 50400 layer 1 blocks | About 4.5 days -Promotion | 50400 layer 1 blocks | About 4.5 days +Proposal | 67200 layer 1 blocks | About 4.5 days +Promotion | 67200 layer 1 blocks | About 4.5 days Cooldown | 86400 seconds | About 1 day Note that these periods can vary. -For example, 8 seconds is the minimal block time on layer 1, which means that blocks can take longer than 8 seconds and therefore periods that are based on blocks can last longer than this minimal time. +For example, 6 seconds is the minimal block time on layer 1, which means that blocks can take longer than 6 seconds and therefore periods that are based on blocks can last longer than this minimal time. Also, an Etherlink user must trigger the protocol upgrade after the Cooldown period is over, so the exact time of the upgrade can vary. ### 1. Proposal period @@ -63,7 +63,7 @@ Any baker can submit kernel upgrade proposals and upvote proposals, with the wei Bakers can submit and upvote up to 20 proposals in a single Proposal period. At the end of the period, if a proposal has enough voting power to meet a certain percentage of the total voting power, it moves to the next phase. -As of the Ebisu update, the leading proposal must gather support from at least 1% of the total voting power to move to the next phase. +As of Etherlink 6.2, the leading proposal must gather support from at least 1% of the total voting power to move to the next phase. If no proposal gathers adequate support, a new Proposal period begins. ### 2. Promotion period @@ -77,7 +77,7 @@ To pass, the proposal must meet both of these requirements: - Supermajority: The total voting power of the Yea votes must reach a supermajority. The thresholds for these requirements are stored in the governance contract. -This table shows the requirements as of the Ebisu Etherlink update: +This table shows the requirements as of Etherlink 6.2: Requirement | Threshold --- | --- @@ -116,13 +116,13 @@ The fast kernel governance process is like the slow kernel governance process, w ### Periods The fast governance process has the same Proposal, Promotion, and Cooldown periods as the slow governance process, but the lengths of these periods are different. -The lengths are stored in the [fast governance contract](https://better-call.dev/mainnet/KT1D1fRgZVdjTj5sUZKcSTPPnuR7LRxVYnDL). -This table shows the period lengths as of the Ebisu Etherlink update and the Tezos Seoul protocol: +The lengths are stored in the [fast governance contract](https://better-call.dev/mainnet/KT1JGCdHEyvE3RkmzR7hRYK7vC42QF6zK34H). +This table shows the period lengths as of Etherlink 6.2 and the Tezos Tallinn protocol: Period | Length | Approximate time --- | --- | --- -Proposal | 3600 layer 1 blocks | About 8 hours -Promotion | 3600 layer 1 blocks | About 8 hours +Proposal | 4800 layer 1 blocks | About 8 hours +Promotion | 4800 layer 1 blocks | About 8 hours Cooldown | 86400 seconds | About 1 day Like the slow governance periods, these periods can vary based on the timing of layer 1 blocks and when users activate the new kernel at the end of the Cooldown period. @@ -132,7 +132,7 @@ Like the slow governance periods, these periods can vary based on the timing of The differences in thresholds in the security governance process ensure expedited resolution of urgent issues while upholding integrity by demanding higher quorum to prevent potential nefarious actions. The thresholds for the quorum and supermajority requirements are stored in the governance contract. -This table shows the requirements as of the Ebisu Etherlink update: +This table shows the requirements as of Etherlink 6.2: Period | Requirement | Threshold --- | --- | --- @@ -150,18 +150,18 @@ Similar to the kernel governance processes, the sequencer voting process has Pro In this process, bakers propose and vote on the account that operates the sequencer. The lengths of the periods are stored in the [sequencer governance contract](https://better-call.dev/mainnet/KT1NnH9DCAoY1pfPNvb9cw9XPKQnHAFYFHXa). -This table shows the period lengths as of the Ebisu Etherlink update and the Tezos Seoul protocol: +This table shows the period lengths as of Etherlink 6.2 and the Tezos Tallinn protocol: Period | Length | Approximate time --- | --- | --- -Proposal | 50400 layer 1 blocks | About 4.5 days -Promotion | 50400 layer 1 blocks | About 4.5 days +Proposal | 67200 layer 1 blocks | About 4.5 days +Promotion | 67200 layer 1 blocks | About 4.5 days Cooldown | 86400 seconds | About 1 day ### Thresholds The thresholds for the quorum and supermajority requirements are stored in the governance contract. -This table shows the requirements as of the Ebisu Etherlink update: +This table shows the requirements as of Etherlink 6.2: Period | Requirement | Threshold --- | --- | --- diff --git a/docs/governance/kernel-governance.md b/docs/governance/kernel-governance.md index 9a589ae6..e3ef7f2e 100644 --- a/docs/governance/kernel-governance.md +++ b/docs/governance/kernel-governance.md @@ -22,7 +22,7 @@ For example, this Octez client command calls this view for the slow governance c ```bash octez-client -E https://mainnet.ecadinfra.com \ - run view get_voting_state on contract KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r + run view get_voting_state on contract KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH ``` The view returns information about the current governance period in this order: @@ -49,7 +49,7 @@ To upvote a proposed kernel update during a Proposal period, go to the [governan As an alternative, call the `upvote_proposal` entrypoint with the same parameters as the `new_proposal` entrypoint: ```bash -octez-client call KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r from my_wallet \ +octez-client call KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH from my_wallet \ --entrypoint "upvote_proposal" \ --arg "0x" ``` @@ -61,7 +61,7 @@ When a proposal is in the Promotion period, you can vote for or against it by go As an alternative, you can vote for it by calling the `vote` entrypoint of the appropriate governance contract: ```bash -octez-client call KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r from my_wallet \ +octez-client call KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH from my_wallet \ --entrypoint "vote" --arg '"yea"' ``` diff --git a/docs/governance/overview.mdx b/docs/governance/overview.mdx index 7ad91392..e61b5790 100644 --- a/docs/governance/overview.mdx +++ b/docs/governance/overview.mdx @@ -37,15 +37,15 @@ You need the address of the correct governance contract (and sometimes the addre Kernel governance (slow) - + Kernel governance (fast) - + Sequencer operator - + Voting keys diff --git a/docs/governance/proposing-upgrades.md b/docs/governance/proposing-upgrades.md index 8fe6e1d5..ff2f3cd8 100644 --- a/docs/governance/proposing-upgrades.md +++ b/docs/governance/proposing-upgrades.md @@ -14,7 +14,7 @@ Other bakers use different commands to vote for or against it, as described in [ During a Proposal period, bakers can propose updates by calling the `new_proposal` entrypoint of the appropriate governance contract and passing the hash of their proposed kernel, as in this example, which uses `` as the kernel hash: ```bash -octez-client call KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r from my_wallet \ +octez-client call KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH from my_wallet \ --entrypoint "new_proposal" \ --arg "0x" ``` @@ -22,7 +22,7 @@ octez-client call KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r from my_wallet \ The command takes these parameters: - The address or Octez client alias of your baker account or [voting key](/governance/voting-key) -- The address of the Etherlink kernel governance contract, either `KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r` for the slow governance process or `KT1DxndcFitAbxLdJCN3C1pPivqbC3RJxD1R` for the fast governance process; see [Governance contract addresses](/governance/overview#governance-contract-addresses) +- The address of the Etherlink kernel governance contract, either `KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH` for the slow governance process or `KT1JGCdHEyvE3RkmzR7hRYK7vC42QF6zK34H` for the fast governance process; see [Governance contract addresses](/governance/overview#governance-contract-addresses) - The hash of the upgraded kernel, which the proposer must generate from the code of the new kernel The proposer must make the code and hash of the new kernel available for people to evaluate. diff --git a/docs/governance/quickstart.md b/docs/governance/quickstart.md index 353d047b..a66dc917 100644 --- a/docs/governance/quickstart.md +++ b/docs/governance/quickstart.md @@ -30,7 +30,7 @@ octez-client call from \ Parameters: -- ``: The governance contract to call, either `KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r` for the slow governance process or `KT1DxndcFitAbxLdJCN3C1pPivqbC3RJxD1R` for the fast governance process; see [Governance contract addresses](/governance/overview#governance-contract-addresses) +- ``: The governance contract to call, either `KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH` for the slow governance process or `KT1JGCdHEyvE3RkmzR7hRYK7vC42QF6zK34H` for the fast governance process; see [Governance contract addresses](/governance/overview#governance-contract-addresses) - ``: Your baker key or Etherlink [voting key](/governance/voting-key) - ``: The hash of the kernel to upvote, starting with `0x` @@ -45,7 +45,7 @@ octez-client call from \ Parameters: -- ``: The governance contract to call, either `KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r` for the slow governance process or `KT1DxndcFitAbxLdJCN3C1pPivqbC3RJxD1R` for the fast governance process; see [Governance contract addresses](/governance/overview#governance-contract-addresses) +- ``: The governance contract to call, either `KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH` for the slow governance process or `KT1JGCdHEyvE3RkmzR7hRYK7vC42QF6zK34H` for the fast governance process; see [Governance contract addresses](/governance/overview#governance-contract-addresses) - ``: Your baker key or Etherlink [voting key](/governance/voting-key) The command does not need the hash of the kernel because only one kernel can be in the Promotion period at a time, so the options are to vote for or against that kernel or to abstain by voting "pass." diff --git a/docs/governance/sequencer-upgrades.md b/docs/governance/sequencer-upgrades.md index c780d2b4..690f903c 100644 --- a/docs/governance/sequencer-upgrades.md +++ b/docs/governance/sequencer-upgrades.md @@ -15,7 +15,7 @@ For example, this Octez client command calls this view for the kernel governance ```bash octez-client -E https://mainnet.ecadinfra.com \ - run view get_voting_state on contract KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf + run view get_voting_state on contract KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn ``` The view returns information about the current governance period. @@ -28,7 +28,7 @@ You can also subscribe to the `voting_finished` event to be notified when the Pr To propose an account to be the sequencer operator, bakers can call the `new_proposal` entrypoint of the governance contract during the Proposal period: ```bash -octez-client transfer 0 from my_wallet to KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf \ +octez-client transfer 0 from my_wallet to KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn \ --entrypoint new_proposal \ --arg 'Pair "" ' ``` @@ -43,7 +43,7 @@ The command takes these parameters: For example: ```bash -octez-client call KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf from my_wallet \ +octez-client call KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn from my_wallet \ --entrypoint new_proposal \ --arg 'Pair "" ' ``` @@ -53,7 +53,7 @@ To upvote a proposed sequencer operator during a Proposal period, go to the [gov As an alternative, call the `upvote_proposal` entrypoint with the same parameters as the `new_proposal` entrypoint: ```bash -octez-client call KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf from my_wallet \ +octez-client call KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn from my_wallet \ --entrypoint upvote_proposal \ --arg 'Pair "" ' ``` @@ -67,7 +67,7 @@ When a proposal is in the Promotion period, you can vote for or against it by go As an alternative, you can vote for or against it or pass on voting by calling the `vote` entrypoint of the governance contract: ```bash -octez-client call KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf from my_wallet \ +octez-client call KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn from my_wallet \ --entrypoint "vote" --arg '"yea"' ``` @@ -80,7 +80,7 @@ The command takes these parameters: For example: ```bash -octez-client call KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf from tz1RLPEeMxbJYQBFbXYw8WHdXjeUjnG5ZXNq \ +octez-client call KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn from tz1RLPEeMxbJYQBFbXYw8WHdXjeUjnG5ZXNq \ --entrypoint "vote" --arg '"yea"' ``` @@ -89,7 +89,7 @@ octez-client call KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf from tz1RLPEeMxbJYQBFbXYw After a proposed account wins a vote, any account can trigger the change and enable that account to run the sequencer by calling the governance contract's `trigger_committee_upgrade` entrypoint: ```bash -octez-client call KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf from my_wallet \ +octez-client call KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn from my_wallet \ --entrypoint "trigger_committee_upgrade" \ --arg '"sr1Ghq66tYK9y3r8CC1Tf8i8m5nxh8nTvZEf"' ``` diff --git a/docs/governance/triggering-upgrades.md b/docs/governance/triggering-upgrades.md index bc67e2b9..6d93f8b9 100644 --- a/docs/governance/triggering-upgrades.md +++ b/docs/governance/triggering-upgrades.md @@ -7,7 +7,7 @@ dependencies: After a proposal wins a vote, any account can trigger the kernel upgrade by calling the appropriate governance contract's `trigger_kernel_upgrade` entrypoint: ```bash -octez-client call KT1DxndcFitAbxLdJCN3C1pPivqbC3RJxD1R from my_wallet \ +octez-client call KT1JGCdHEyvE3RkmzR7hRYK7vC42QF6zK34H from my_wallet \ --entrypoint "trigger_kernel_upgrade" \ --arg '"sr1Ghq66tYK9y3r8CC1Tf8i8m5nxh8nTvZEf"' ``` diff --git a/docs/governance/voting-key.md b/docs/governance/voting-key.md index 6585b369..aee5d218 100644 --- a/docs/governance/voting-key.md +++ b/docs/governance/voting-key.md @@ -79,7 +79,7 @@ As a result, the voting key can vote on those contracts but not on the kernel fa ```bash octez-client call KT1Ut6kfrTV9tK967tDYgQPMvy9t578iN7iH from \ --entrypoint propose_voting_key \ - --arg '(Pair "" True (Some { "KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf" ; "KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r" }))' + --arg '(Pair "" True (Some { "KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn" ; "KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH" }))' ``` Then, to claim voting rights, go to the [governance web site](https://governance.etherlink.com), connect your voting key with the **Connect** button at the top right of the page, and use the connection dialog to claim rights. @@ -111,7 +111,7 @@ For example, from the code of the contract you can see that the parameter to pas This command compiles an expression of this CameLIGO type to Michelson to propose rights for two contracts: ```bash -ligo compile expression cameligo '("" : address), True, (Some (Set.literal [("KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf" : address); ("KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r" : address)]) : (address set) option)' +ligo compile expression cameligo '("" : address), True, (Some (Set.literal [("KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn" : address); ("KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH" : address)]) : (address set) option)' ``` You can use the result as the parameter to pass to the `propose_voting_key` entrypoint. @@ -120,8 +120,8 @@ Here is the result of the command: ```michelson (Pair "" True - (Some { "KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf" ; - "KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r" })) + (Some { "KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn" ; + "KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH" })) ``` Here is the resulting `octez-client` command: @@ -129,7 +129,7 @@ Here is the resulting `octez-client` command: ```bash octez-client call KT1Ut6kfrTV9tK967tDYgQPMvy9t578iN7iH from \ --entrypoint propose_voting_key \ - --arg '(Pair "" True (Some { "KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r" ; "KT1WckZ2uiLfHCfQyNp1mtqeRcC1X6Jg2Qzf" }))' + --arg '(Pair "" True (Some { "KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH" ; "KT1CSqkafD5ZCHFvmsozrCBeSy2XJQzutJRn" }))' ``` ::: @@ -149,7 +149,7 @@ For example, this command verifies rights for the slow kernel governance contrac ```bash octez-client run view is_voting_key_of on contract KT1Ut6kfrTV9tK967tDYgQPMvy9t578iN7iH \ - with input 'Pair "" "" (Some "KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r")' + with input 'Pair "" "" (Some "KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH")' ``` :::tip @@ -160,7 +160,7 @@ The view accepts a tuple that includes the address of the voting key, the addres For example, to compile the parameter from the previous example, install LIGO and run this command: ```bash -ligo compile expression cameligo '("" : address), ("" : address), (Some ("KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r" : address): address option)' +ligo compile expression cameligo '("" : address), ("" : address), (Some ("KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH" : address): address option)' ``` You can use the result as the parameter to pass to the view. @@ -169,7 +169,7 @@ Here is the result of the command: ```michelson (Pair "tz1fsVnw7VQD73kUDB8ZWc67GWvCjTEibi9A" "tz1QCVQinE8iVj1H2fckqx6oiM85CNJSK9Sx" - (Some "KT1VZVNCNnhUp7s15d9RsdycP7C1iwYhAQ8r")) + (Some "KT1NM6cpM5BPTmYPszjv6LRDAMRZXPET9DmH")) ``` ::: diff --git a/docs/index.mdx b/docs/index.mdx index 0197805e..d85855f7 100644 --- a/docs/index.mdx +++ b/docs/index.mdx @@ -30,7 +30,7 @@ Leveraging the Tezos 2-block finality guarantee and the high-speed execution of Etherlink ~ 500 ms - ~ 8 seconds + ~ 6 seconds Optimism Bedrock diff --git a/docs/network/architecture.md b/docs/network/architecture.md index a55905ed..416585fd 100644 --- a/docs/network/architecture.md +++ b/docs/network/architecture.md @@ -157,10 +157,10 @@ As described in [Sequencer](#sequencer), the sequencer puts transactions in bloc When the EVM nodes get another block that builds on the previous block, they can trust that the transactions in the previous block are final as long as they trust the that the sequencer will publish them to layer 1. At this point, the previous block is considered _confirmed_ and it would take a significant bug in the sequencer for it to generate blocks that do not use the confirmed block and thus reorganize the blocks in such a way as to make the confirmed block invalid. -- **Transactions are confirmed on layer 1 in 8 seconds.** +- **Transactions are confirmed on layer 1 in 6 seconds.** The sequencer also posts blocks to Tezos layer 1. As with Etherlink blocks, Tezos blocks are confirmed when another block builds on them, as described in [The consensus algorithm](https://octez.tezos.com/docs/active/consensus.html) in the Octez documentation. -Tezos blocks are generated every 8 seconds, so Etherlink transactions are posted and confirmed on Tezos after 8 seconds, when another block is posted. +Tezos blocks are generated every 6 seconds, so Etherlink transactions are posted and confirmed on Tezos after 6 seconds, when another block is posted. Etherlink Smart Rollup nodes also pick up these blocks and their instance of the kernel decides immediately whether these blocks are valid and if they should become the next Etherlink block. When the Etherlink block has been posted and confirmed on Tezos layer 1, Etherlink treats the block (and the transactions in it) as finalized. diff --git a/docs/progress/upgrades.md b/docs/progress/upgrades.md index bd80c943..903604f7 100644 --- a/docs/progress/upgrades.md +++ b/docs/progress/upgrades.md @@ -115,12 +115,12 @@ The speed limit decides when the gas price raises. For more information, see [Execution fee](/network/fees#execution-fee). - A breaking change to the `QueuedDeposit` event that the FA bridge emits. -This event is now emitted by the FA bridging precompiled contract (`0xff0...0002`) and the first topic of the event is changed to match its ABI signature. +This event is now emitted by the Tezos bridge precompiled contract (`0xff0...0002`) and the first topic of the event is changed to match its ABI signature. For more information about bridging events, see [How bridging FA tokens works](/bridging/bridging-fa-how). For more information, see [Announcing Farfadet: A 6th Upgrade Proposal for Etherlink Mainnet](https://medium.com/@etherlink/announcing-farfadet-a-6th-upgrade-proposal-for-etherlink-mainnet-6bc59793962d). -## Etherlink 6.1 +### Etherlink 6.1 :::note @@ -131,6 +131,25 @@ Version 0.53 or later of the `octez-evm-node` binary is strongly recommended for The Etherlink 6.1 upgrade went through the fast kernel governance process and fixed an issue with the FA bridge introduced in 6.0. For more information, see [Announcing Etherlink 6.1: a bugfix proposal for FA token deposits](https://medium.com/@etherlink/announcing-etherlink-6-1-a-bugfix-proposal-for-fa-token-deposits-2cc08ffd6fad). +### Etherlink 6.2 + +The Etherlink 6.2 upgrade includes: + +- Fixes to stabilize Instant Confirmations and make them more efficient. +These changes have no effect on how Instant Conformations work from the user perspective. + +- Updated governance contracts to align Etherlink governance periods with the 6-second block time introduced by the Tallinn upgrade. + +- A change to how the Tezos-Etherlink bridge works. +The bridge now deposits XTZ tokens to Etherlink user and smart contract accounts in a way similar to how the FA bridge handles deposits of FA tokens. +This update gets Etherlink in sync with how sending tokens to smart contracts works on EVM; now, depositing XTZ to a smart contract automatically calls its code. +For more information, see [Deposit process](/bridging/bridging-tezos#deposit-process). + + This change to the bridge introduces a breaking change in the events that are emitted as part of the bridging process. + The `deposit` event is now emitted by the [Tezos bridge precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) (`0xff0...0001`), not the null/system address. + +For more information, see TODO BLOG POST. + ## Changelog For full details about changes to Etherlink, see [Changelogs](/progress/changelogs). diff --git a/static/img/bridging-deposit-fa.png b/static/img/bridging-deposit-fa.png index a362908f..b53e8e00 100644 Binary files a/static/img/bridging-deposit-fa.png and b/static/img/bridging-deposit-fa.png differ diff --git a/static/img/bridging-deposit-fa.visualdesigner.umdx b/static/img/bridging-deposit-fa.visualdesigner.umdx index ab2ccf81..0de59a8d 100644 Binary files a/static/img/bridging-deposit-fa.visualdesigner.umdx and b/static/img/bridging-deposit-fa.visualdesigner.umdx differ diff --git a/static/img/bridging-deposit-xtz.png b/static/img/bridging-deposit-xtz.png new file mode 100644 index 00000000..c4e9d556 Binary files /dev/null and b/static/img/bridging-deposit-xtz.png differ diff --git a/static/img/bridging-deposit-xtz.visualdesigner.umdx b/static/img/bridging-deposit-xtz.visualdesigner.umdx new file mode 100644 index 00000000..a6004f33 Binary files /dev/null and b/static/img/bridging-deposit-xtz.visualdesigner.umdx 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