From be7d2751e416df7bb3057c29ea629ebec5202ade Mon Sep 17 00:00:00 2001 From: dave | d1onys1us <13951458+d1onys1us@users.noreply.github.com> Date: Wed, 7 Jun 2023 23:25:19 +0900 Subject: [PATCH 1/4] feat(website): update proving docs (#13915) --- .../website/pages/docs/concepts/_meta.json | 2 +- .../concepts/proving-taiko-blocks/_meta.json | 11 --- .../concepts/proving-taiko-blocks/provers.mdx | 1 - .../the-oracle-prover.mdx | 1 - .../verified-blocks-and-parallel-proving.mdx | 20 ------ .../website/pages/docs/concepts/proving.mdx | 71 +++++++++++++++++++ .../pages/docs/guides/enable-a-prover.mdx | 4 +- 7 files changed, 75 insertions(+), 35 deletions(-) delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx create mode 100644 packages/website/pages/docs/concepts/proving.mdx diff --git a/packages/website/pages/docs/concepts/_meta.json b/packages/website/pages/docs/concepts/_meta.json index 25998bbb2d5..3a7076a2e7e 100644 --- a/packages/website/pages/docs/concepts/_meta.json +++ b/packages/website/pages/docs/concepts/_meta.json @@ -5,7 +5,7 @@ "creating-taiko-blocks": { "title": "Creating Taiko blocks" }, - "proving-taiko-blocks": { + "proving": { "title": "Proving Taiko blocks" }, "bridging": { diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json b/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json deleted file mode 100644 index c74e1bd3c27..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "provers": { - "title": "Provers" - }, - "the-oracle-prover": { - "title": "The oracle prover" - }, - "verified-blocks-and-parallel-proving": { - "title": "Verified blocks & parallel proving" - } -} diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx deleted file mode 100644 index 6e0d3773759..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx +++ /dev/null @@ -1 +0,0 @@ -The purpose of proving blocks is to allow bridges to withdraw state out of the rollup. To rely on some state that happened inside of the rollup, a bridge will want a proof that everything was done correctly. On Taiko you can [run a node as a prover](/docs/guides/run-a-node) and prove blocks, permissionlessly. This means that you can examine the proposed blocks on the TaikoL1 contract, and generate proofs for them. Currently, any prover can create proofs for proposed blocks. This means that the number of "fork choices" has no upper bound, because we don't know what is the correct state transition yet. Only first prover with a valid proof of the correct fork choice (state transition) will receive the reward of TTKO. diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx deleted file mode 100644 index 7c75790b407..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx +++ /dev/null @@ -1 +0,0 @@ -There is a concept of an oracle prover on Taiko, which will be removed when the circuits are complete and some rollup training wheels have been removed (such as DAO governance and multi-proofs). The oracle prover is a prover that is trusted to provide the correct state transition. If oracle proving is enabled, then the oracle prover will be forced as the first prover for a block and the second will be from a prover. The actual prover (one of you) however will receive the reward of course, this is just a safety mechanism we have in place while the ZK-EVM is still in development. diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx deleted file mode 100644 index bcf9416167c..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx +++ /dev/null @@ -1,20 +0,0 @@ -There are three states that a block can be in on Taiko: -- Proposed -- Proved -- Verified - -We already know what a proposed block is (must pass at least the block-level intrinsic validity tests to be accepted by the TaikoL1 contract). Next, a proposed block can be valid or invalid, depending on whether it passes the transaction list intrinsic validity test. A block is invalid if it fails the transaction list intrinsic validity test, and this block is not created on Taiko. - -Now, a block can be proved, but also further "verified". What's the difference? A block is proved if it has a valid proof which proves a state transition from one state (parent block) to another (current block). However, blocks are proven in parallel by the decentralized provers. So while a block can prove a parent block transitions to the current block, we don't know if the parent block itself has been proven. As you can see, for a block to be "verified", it needs to prove the valid state transition to the current block, but the parent also need to be verified. We assume that the genesis block (which has no parent), is verified. So all the children blocks from genesis to the current block need to have proofs of their state transition for the current block to be "verified". - -For the visual learners here is a visualization of the three stages (proposed -> proved -> verified) - -**Proposed:** -![Proposed](/images/diagrams/concepts/proving-taiko-blocks/proposed.png) - -**Proved:** -![Proved](/images/diagrams/concepts/proving-taiko-blocks/proved.png) - -**Verified:** -![Verified](/images/diagrams/concepts/proving-taiko-blocks/verified.png) - diff --git a/packages/website/pages/docs/concepts/proving.mdx b/packages/website/pages/docs/concepts/proving.mdx new file mode 100644 index 00000000000..9687f6bcc08 --- /dev/null +++ b/packages/website/pages/docs/concepts/proving.mdx @@ -0,0 +1,71 @@ +import Image from "next/image"; + +# Proving Taiko blocks + +## Overview +The purpose of proving blocks is to give certainty to bridges about the execution that happened in the rollup. To rely on some state that happened inside of the rollup, a bridge will want a proof that everything was done correctly. On Taiko you can run a node as a prover and prove blocks, permissionlessly. This means that you can examine the proposed blocks on the TaikoL1 contract, and generate proofs for them. Currently, any prover can create proofs for proposed blocks. This means that the number of "fork choices" has no upper bound, because we don't know what is the correct state transition yet. Only first prover with a valid proof of the correct fork choice (state transition) will receive the reward of TTKO. + +## Verified blocks and parallel proving +There are three states that a block can be in on Taiko: +- Proposed +- Proved +- Verified + +We already know what a proposed block is (must pass at least the block-level intrinsic validity tests to be accepted by the TaikoL1 contract). Next, a proposed block can be valid or invalid, depending on whether it passes the transaction list intrinsic validity test. A block is invalid if it fails the transaction list intrinsic validity test, and this block is not created on Taiko. + +Now, a block can be proved, but also further "verified". What's the difference? A block is proved if it has a valid proof which proves a state transition from one state (parent block) to another (current block). However, blocks are proven in parallel by the decentralized provers. So while a block can prove a parent block transitions to the current block, we don't know if the parent block itself has been proven. As you can see, for a block to be "verified", it needs to prove the valid state transition to the current block, but the parent also need to be verified. We assume that the genesis block (which has no parent), is verified. So all the children blocks from genesis to the current block need to have proofs of their state transition for the current block to be "verified". + +For the visual learners here is a visualization of the three stages (proposed -> proved -> verified) + +**Proposed:** +
+ proposed +
+**Proved:** +
+ proved +
+**Verified:** +
+ verified +
+ +## Types of provers +### Community prover + +Currently, you only need a single proof from the any prover to verify a block. + +### Oracle prover + +The oracle prover is a prover from a unique address (our own address) that is able to override the community prover. This is a safety mechanism we have in place while the ZK-EVM is still in development and in case an invalid block was marked as verified from a community proof. + +### System proof + +A system proof is a fake proof that is generated by the system to mark a block as verified. We only require a real proof to be generated every N blocks. Otherwise, we accept a fake, system proof, and mark the block as verified. This is a temporary testnet feature to reduce the cost for community provers. + +### The proof cooldown period + +We have a proof cooldown period which is an interval of time we set after fully verifying a block. The reason we do that is to allow for a fault proof to come in, once we have a multi-prover system set in place. + + +## Prover dynamics + +### How the proof reward is determined + +A proof reward in TTKO is rewarded for successfully proving a block. This reward is dependent on the `proofTimeTarget`. You can see the current proof reward by calling `getProofReward` on the TaikoL1 contract. + +So that we don't grow a long list of unverified blocks for too long, we want to target proofs coming in at a certain rate. So we set a target proof time. If it has taken a long time since the last verified block, the proof reward increases to incentivize provers to generate a proof. + +Conversely, if everyone is submitting proofs quickly, then the proof reward decreases towards zero. This means that as a prover, you should query `getProofReward` on the TaikoL1 contract to determine if it is profitable to generate a proof. If you submit proofs as quickly as possible, then the proof reward will trend towards zero. + +### Default in simple-taiko-node + +The [simple-taiko-node](https://github.com/taikoxyz/simple-taiko-node) will come pre-configured to not submit proofs as quickly as possible, by querying `getProofReward`. This hopefully means that most nodes in the network are acting in the group interest, by responsibly not submitting the proof as quickly as possible. However, because the first prover will win the reward, and because the project is open source, anybody can modify the [taiko-client](https://github.com/taikoxyz/taiko-client) and act rationally to submit a proof slightly earlier than the default set in `simple-taiko-node`. As you can see, it causes somewhat of a prisoner's dilemma. + +### Proof skip + +We have a `realProofSkipSize` set [here](https://github.com/taikoxyz/taiko-mono/blob/main/packages/protocol/contracts/L1/TaikoConfig.sol#LL40C13-L40C30) so that a real proof is only needed every N blocks for the testnet. + +### Your role as a prover + +We are describing this dynamic so you can be informed when you run a prover. It's very possible that without the correct strategy, you will not be profitable as a prover. You are naturally competing in an open space where others could have more efficient hardware and generate a proof in a short amount of time that you cannot compete against. \ No newline at end of file diff --git a/packages/website/pages/docs/guides/enable-a-prover.mdx b/packages/website/pages/docs/guides/enable-a-prover.mdx index b56d5203464..d3988c7c47c 100644 --- a/packages/website/pages/docs/guides/enable-a-prover.mdx +++ b/packages/website/pages/docs/guides/enable-a-prover.mdx @@ -3,9 +3,11 @@ import { Callout, Steps } from "nextra-theme-docs"; # Enable a prover - Only the first prover can get the reward, and others will be rejected by the protocol smart contract. This means the fastest prover will be able to prove the block and earn the reward, **if you have just the minimum hardware outlined in the prerequisited below, running a single prover, it's unlikely you will be able to prove any blocks (because you will be competing against other high-performance provers)**. +Only the first prover can earn the TTKO reward, and others will be rejected by the protocol smart contract. This means the fastest prover will be able to prove the block and earn the reward, **if you have just the minimum hardware outlined in the prerequisited below, running a single prover, it's unlikely you will be able to prove any blocks (because you will be competing against other high-performance provers)**. Meaning, if you do not have a powerful prover, the primary purpose of running a prover is to help test out and provide community feedback on running the node software. Keep in mind this will have a cost in electricity on your computer, and if you are not proving blocks, it's unlikely you will receive a reward to offset that electricity cost. + +Please see [How the proof reward is determined](/docs/concepts/proving#how-the-proof-reward-is-determined) for more details. ## Overview From cf47afe4f2233e44fcd74e80b3ee93a389cf8efa Mon Sep 17 00:00:00 2001 From: dave | d1onys1us <13951458+d1onys1us@users.noreply.github.com> Date: Thu, 8 Jun 2023 01:11:30 +0900 Subject: [PATCH 2/4] chore(website): update bridging docs (#13916) --- .../website/pages/docs/concepts/bridging.mdx | 110 ++++++++++++++++++ .../pages/docs/concepts/bridging/_meta.json | 14 --- .../bridging/cross-chain-messaging.mdx | 31 ----- .../bridging/how-the-bridge-works.mdx | 37 ------ .../concepts/bridging/the-signal-service.mdx | 30 ----- .../bridging/the-taiko-bridge-dapp.mdx | 1 - 6 files changed, 110 insertions(+), 113 deletions(-) create mode 100644 packages/website/pages/docs/concepts/bridging.mdx delete mode 100644 packages/website/pages/docs/concepts/bridging/_meta.json delete mode 100644 packages/website/pages/docs/concepts/bridging/cross-chain-messaging.mdx delete mode 100644 packages/website/pages/docs/concepts/bridging/how-the-bridge-works.mdx delete mode 100644 packages/website/pages/docs/concepts/bridging/the-signal-service.mdx delete mode 100644 packages/website/pages/docs/concepts/bridging/the-taiko-bridge-dapp.mdx diff --git a/packages/website/pages/docs/concepts/bridging.mdx b/packages/website/pages/docs/concepts/bridging.mdx new file mode 100644 index 00000000000..262b47ed0e3 --- /dev/null +++ b/packages/website/pages/docs/concepts/bridging.mdx @@ -0,0 +1,110 @@ +# Bridging + +Bridges are foundational for cross-chain users and applications. Users might come to another chain, such as Taiko (a ZK-rollup). To do this, they need to bridge over funds. Notoriously, bridging has been a dangerous operation. How do you make sure that this bridge is secure? + +Let's explain bridging on Taiko. We will answer the following questions: + +- [How does the Taiko protocol enable secure cross-chain messaging?](#cross-chain-messaging) +- [What is the Taiko signal service?](#the-signal-service) +- [How does Taiko's bridge implementation work?](#how-the-bridge-works) + +## Cross-chain messaging + +The Taiko protocol's design, specifically its Ethereum-equivalence enables secure cross-chain messaging. Let's see how it works by simply using merkle proofs. + +### Taiko stores block hashes of each chain + +Taiko deploys two smart contracts which store the hashes of the other chain: + +- TaikoL1 stores a blockNumber->blockHash mapping `l2Hashes` (deployed on Ethereum) +- TaikoL2 stores a blockNumber->blockHash mapping `l1Hashes` (deployed on Taiko) + +Every time an L2 block is created on Taiko, the hash of the enclosing block on L1 is stored in the TaikoL2 contract. And every time an L1 block is verified, the L2 hash is stored in the TaikoL1 contract (only the latest one, if multiple ones are verified at once). + +### Merkle trees enable verifying values exist on the other chain + +Merkle trees are a data storage structure that allows a lot of data to be fingerprinted with a single hash, called the merkle root. The way that they are structured enables one to verify that some value exists within this large data structure, without actually needing to have access to the entire merkle tree. To do this, the verifier would need: + +- The merkle root, this is the single "fingerprint" hash of the merkle tree +- The value, this is the value we are checking is inside the merkle root +- A list of intermediate sibling hashes, these are the hashes that enable the verifier to re-calculate the merkle root + +You can get the latest known merkle root stored on the destination chain by calling `getCrossChainBlockHash(0)` on the TaikoL1/TaikoL2 contract. You can get the value / message to verify and the sibling hashes for that latest known merkle root by asking for it with the standard RPC call `eth_getProof` on the "source chain". Then you just need to send them to be verified against that latest known block hash that is stored in a list on the "destination chain". + +A verifier will take the value (a leaf in the merkle tree) and the sibling hashes to re-calculate the merkle root. If the calculated merkle root matches the one that is stored in the destination chain's list of block hashes (the block hashes of the source chain), then we have proved that the message was sent on the source chain, assuming the source chain block hashes stored on the destination chain were correct. + +## The signal service + +Taiko's signal service is a smart contract available on both L1 and L2, available for any dapp developer to use. It exposes a [simple interface](/docs/reference/contract-documentation/signal/ISignalService). And it's what uses the previously mentioned merkle proofs to provide a service for secure cross-chain messaging. + +You can store signals and check if a signal was sent from an address. It also exposes one more important function: `isSignalReceived`. + +What does this function do? The first thing to understand is that the Taiko protocol maintains two important contracts: + +- [TaikoL1](/docs/reference/contract-documentation/L1/TaikoL1) +- [TaikoL2](/docs/reference/contract-documentation/L2/TaikoL2) + +These contracts both keep track of the block hashes on the **other chain**. So TaikoL1, which is deployed on Ethereum, has access to the latest block hashes on Taiko. And TaikoL2, which is deployed on Taiko, has access to the latest block hashes on Ethereum. + +So, `isSignalReceived` can prove on either chain that you sent a signal to the Signal Service on the other chain. A user or dapp can call `eth_getProof`(https://eips.ethereum.org/EIPS/eip-1186) which generates a merkle proof. + +You need to provide `eth_getProof` with: + +1. The signal (the data you want to prove exists within the storage root of some block on the chain) +2. The address of the signal service (the contract address which stores the provided signal) +3. The block number you are asserting the signal was sent on (optional—if you don't provide this, it will default to the latest block number) + +And, `eth_getProof` will generate a merkle proof (it will give the necessary sibling hashes and the height of the block, that along with the signal, can rebuild the merkle storage root of the block you are asserting the signal exists in). + +This means, assuming that the hashes which TaikoL1 and TaikoL2 maintain are correct, we can reliably send **cross-chain messages**. + +Let's walk through an example: + +1. First, we can send a message on some source chain, and store it on the signal service. +2. Next, we call `eth_getProof`, which will give us a proof that we did indeed send a message on the source chain. +3. Finally, we call `isSignalReceived` on the destination chain's SignalService which essentially just verifies the merkle proof. `isSignalReceived` will look up the block hash you are asserting you had stored a message on the source chain (where you originally sent the message), and with the sibling hashes inside the merkle proof it will rebuild the merkle root, which verifies the signal was included in that merkle root—meaning it was sent. + +And boom! We have sent a cross-chain message. Confusing? Well leave some feedback please if it is, so we can clear it up. + +## How the bridge works + +The bridge is a set of smart contracts and a frontend web app that allow you to send testnet ETH and ERC-20 tokens between Sepolia and Taiko. This bridge is just one possible implementation built on top of Taiko's core protocol, specifically the signal service which anybody can use to build bridges. You can try the bridge [here](https://bridge.test.taiko.xyz). + +First, here is a flowchart of how our bridge dapp implementation works, which uses the signal service: + +![bridging send message flowchart](/images/diagrams/concepts/bridging/bridging-send-message.png) \ +![bridging process message flowchart](/images/diagrams/concepts/bridging/bridging-process-message.png) + +### How does Ether bridging work? + +Taiko's bridge utilizes the Signal Service we described. Here is the general user flow for Taiko's bridge: + +1. The user sends their funds to the Bridge contract +2. The Bridge locks the Ether, and stores a message by calling `sendSignal(message)` on the SignalService contract +3. The user receives Ether on the destination chain, if they (or another) provide a valid merkle proof that the message was received on the source chain + +### How does ERC-20 bridging work? + +ERC-20 tokens originate from a canonical chain. To send a token and bridge it to the other chain, a new BridgedERC20 contract needs to be deployed on the destination chain. + +#### Bridge from canonical chain to destination chain + +Here are the overall steps for transferring canonical ERC-20 from a source chain to the destination chain: + +1. A contract for the ERC-20 must first be deployed on the destination chain (will be done automatically by the TokenVault if not already deployed) + +2. Call sendERC20 on the source chain TokenVault, this will **transfer** the amount by using the `safeTransferFrom` function on the canonical ERC-20 contract, on the source chain, to the TokenVault. + +3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method. + +4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in the message. This will **mint** ERC-20 on the BridgedERC20 contract to the `to` address on the destination chain! + +#### Bridge from destination chain back to the canonical chain + +Okay now let's do the reverse, how do we transfer a bridged token from a source chain to the destination chain? + +1. A contract for the ERC-20 already exists on the canonical chain, so no need to deploy a new one. +2. Call sendERC20 on the source chain TokenVault, this will **burn** the ERC-20 on the BridgedERC20 contract. +3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method. +4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in this message. This will **transfer** the amount from the destination chain TokenVault to the `to` address on the destination chain. + diff --git a/packages/website/pages/docs/concepts/bridging/_meta.json b/packages/website/pages/docs/concepts/bridging/_meta.json deleted file mode 100644 index d8ced8fb987..00000000000 --- a/packages/website/pages/docs/concepts/bridging/_meta.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "cross-chain-messaging": { - "title": "Cross-chain messaging" - }, - "the-signal-service": { - "title": "The signal service" - }, - "the-taiko-bridge-dapp": { - "title": "The bridge dapp" - }, - "how-the-bridge-works": { - "title": "How the bridge dapp works" - } -} diff --git a/packages/website/pages/docs/concepts/bridging/cross-chain-messaging.mdx b/packages/website/pages/docs/concepts/bridging/cross-chain-messaging.mdx deleted file mode 100644 index dd748242a1c..00000000000 --- a/packages/website/pages/docs/concepts/bridging/cross-chain-messaging.mdx +++ /dev/null @@ -1,31 +0,0 @@ -Bridges are foundational for cross-chain users and applications. Users might come to another chain, such as Taiko (a ZK-rollup). To do this, they need to bridge over funds. Notoriously, bridging has been a dangerous operation. How do you make sure that this bridge is secure? - -Let's explain bridging on Taiko. We will answer the following questions: - -- How does the Taiko protocol enable secure cross-chain messaging? -- What is the Taiko signal service? -- What is the Taiko bridge dapp? -- How does the bridge dapp work? - -The Taiko protocol's design, specifically its Ethereum-equivalency enables secure cross-chain messaging. Let's see how it works by simply using merkle proofs. - -### Taiko stores block hashes of each chain - -Taiko deploys two smart contracts which store the hashes of the other chain: - -- TaikoL1 stores a blockNumber->blockHash mapping `l2Hashes` (deployed on Ethereum) -- TaikoL2 stores a blockNumber->blockHash mapping `l1Hashes` (deployed on Taiko) - -Every time an L2 block is created on Taiko, the hash of the enclosing block on L1 is stored in the TaikoL2 contract. And every time an L1 block is verified, the L2 hash is stored in the TaikoL1 contract (only the latest one, if multiple ones are verified at once). - -### Merkle trees enable verifying values exist on the other chain - -Merkle trees are a data storage structure that allows a lot of data to be fingerprinted with a single hash, called the merkle root. The way that they are structured enables one to verify that some value exists within this large data structure, without actually needing to have access to the entire merkle tree. To do this, the verifier would need: - -- The merkle root, this is the single "fingerprint" hash of the merkle tree -- The value, this is the value we are checking is inside the merkle root -- A list of intermediate sibling hashes, these are the hashes that enable the verifier to re-calculate the merkle root - -You can get the latest known merkle root stored on the destination chain by calling `getLatestSyncedHeader()` on the TaikoL1/TaikoL2 contract. You can get the value / message to verify and the sibling hashes for that latest known merkle root by asking for it with the standard RPC call `eth_getProof` on the "source chain". Then you just need to send them to be verified against that latest known block hash that is stored in a list on the "destination chain". - -A verifier will take the value (a leaf in the merkle tree) and the sibling hashes to re-calculate the merkle root. If the calculated merkle root matches the one that is stored in the destination chain's list of block hashes (the block hashes of the source chain), then we have proved that the message was sent on the source chain, assuming the source chain block hashes stored on the destination chain were correct. diff --git a/packages/website/pages/docs/concepts/bridging/how-the-bridge-works.mdx b/packages/website/pages/docs/concepts/bridging/how-the-bridge-works.mdx deleted file mode 100644 index cdeead1fa18..00000000000 --- a/packages/website/pages/docs/concepts/bridging/how-the-bridge-works.mdx +++ /dev/null @@ -1,37 +0,0 @@ -First, here is a flowchart of how our bridge dapp implementation works, which uses the signal service: - -![bridging send message flowchart](/images/diagrams/concepts/bridging/bridging-send-message.png) \ -![bridging process message flowchart](/images/diagrams/concepts/bridging/bridging-process-message.png) - -## How does Ether bridging work? - -Taiko's bridge utilizes the Signal Service we described. Here is the general user flow for Taiko's bridge: - -1. The user sends their funds to the Bridge contract -2. The Bridge locks the Ether, and stores a message by calling `sendSignal(message)` on the SignalService contract -3. The user receives Ether on the destination chain, if they (or another) provide a valid merkle proof that the message was received on the source chain - -## How does ERC-20 bridging work? - -ERC-20 tokens originate from a canonical chain. To send a token and bridge it to the other chain, a new BridgedERC20 contract needs to be deployed on the destination chain. - -### Bridge from canonical chain to destination chain - -Here are the overall steps for transferring canonical ERC-20 from a source chain to the destination chain: - -1. A contract for the ERC-20 must first be deployed on the destination chain (will be done automatically by the TokenVault if not already deployed) - -2. Call sendERC20 on the source chain TokenVault, this will **transfer** the amount by using the `safeTransferFrom` function on the canonical ERC-20 contract, on the source chain, to the TokenVault. - -3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method. - -4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in the message. This will **mint** ERC-20 on the BridgedERC20 contract to the `to` address on the destination chain! - -### Bridge from destination chain back to the canonical chain - -Okay now let's do the reverse, how do we transfer a bridged token from a source chain to the destination chain? - -1. A contract for the ERC-20 already exists on the canonical chain, so no need to deploy a new one. -2. Call sendERC20 on the source chain TokenVault, this will **burn** the ERC-20 on the BridgedERC20 contract. -3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method. -4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in this message. This will **transfer** the amount from the destination chain TokenVault to the `to` address on the destination chain. diff --git a/packages/website/pages/docs/concepts/bridging/the-signal-service.mdx b/packages/website/pages/docs/concepts/bridging/the-signal-service.mdx deleted file mode 100644 index e89b65121b3..00000000000 --- a/packages/website/pages/docs/concepts/bridging/the-signal-service.mdx +++ /dev/null @@ -1,30 +0,0 @@ -Taiko's signal service is a smart contract available on both L1 and L2, available for any dapp developer to use. It exposes a [really simple interface](/docs/reference/contract-documentation/signal/ISignalService). And it's what uses the previously mentioned merkle proofs to provide a service for secure cross-chain messaging. - -You can store signals and check if a signal was sent from an address. It also exposes one more important function: `isSignalReceived`. - -What does this function do? The first thing to understand is that the Taiko protocol maintains two important contracts: - -- [TaikoL1](/docs/reference/contract-documentation/L1/TaikoL1) -- [TaikoL2](/docs/reference/contract-documentation/L2/TaikoL2) - -These contracts both keep track of the block hashes on the **other chain**. So TaikoL1, which is deployed on Ethereum, has access to the latest block hashes on Taiko. And TaikoL2, which is deployed on Taiko, has access to the latest block hashes on Ethereum. - -So, `isSignalReceived` can prove on either chain that you sent a signal to the Signal Service on the other chain. A user or dapp can call `eth_getProof`(https://eips.ethereum.org/EIPS/eip-1186) which generates a merkle proof. - -You need to provide `eth_getProof` with: - -1. The signal (the data you want to prove exists within the storage root of some block on the chain) -2. The address of the signal service (the contract address which stores the provided signal) -3. The block number you are asserting the signal was sent on (optional—if you don't provide this, it will default to the latest block number) - -And, `eth_getProof` will generate a merkle proof (it will give the necessary sibling hashes and the height of the block, that along with the signal, can rebuild the merkle storage root of the block you are asserting the signal exists in). - -This means, assuming that the hashes which TaikoL1 and TaikoL2 maintain are correct, we can reliably send **cross-chain messages**. - -Let's walk through an example: - -1. First, we can send a message on some source chain, and store it on the signal service. -2. Next, we call `eth_getProof`, which will give us a proof that we did indeed send a message on the source chain. -3. Finally, we call `isSignalReceived` on the destination chain's SignalService which essentially just verifies the merkle proof. `isSignalReceived` will look up the block hash you are asserting you had stored a message on the source chain (where you originally sent the message), and with the sibling hashes inside the merkle proof it will rebuild the merkle root, which verifies the signal was included in that merkle root—meaning it was sent. - -And boom! We have sent a cross-chain message. Confusing? Well leave some feedback please if it is, so we can clear it up. diff --git a/packages/website/pages/docs/concepts/bridging/the-taiko-bridge-dapp.mdx b/packages/website/pages/docs/concepts/bridging/the-taiko-bridge-dapp.mdx deleted file mode 100644 index d7d18b08067..00000000000 --- a/packages/website/pages/docs/concepts/bridging/the-taiko-bridge-dapp.mdx +++ /dev/null @@ -1 +0,0 @@ -The bridge is a set of smart contracts and a frontend web app that allow you to send testnet ETH and ERC-20 tokens between Sepolia and Taiko. This bridge is just one possible implementation built on top of Taiko's core protocol, specifically the signal service which anybody can use to build bridges. You can try the bridge [here](https://bridge.test.taiko.xyz). From 8e1a16bc7775e93c783da88c5fd4f9b43a298279 Mon Sep 17 00:00:00 2001 From: mfinestone <36642873+mfinestone@users.noreply.github.com> Date: Wed, 7 Jun 2023 23:42:08 -0400 Subject: [PATCH 3/4] chore(website): update homepage with blog post (#13921) Co-authored-by: dave | d1onys1us <13951458+d1onys1us@users.noreply.github.com> --- packages/website/components/BlogSection.tsx | 30 ++++++++++----------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/packages/website/components/BlogSection.tsx b/packages/website/components/BlogSection.tsx index 35bc5380063..f4245b6edaa 100644 --- a/packages/website/components/BlogSection.tsx +++ b/packages/website/components/BlogSection.tsx @@ -1,4 +1,19 @@ const posts = [ + { + title: "Taiko Alpha-3 Testnet is Live", + href: "https://taiko.mirror.xyz/wD7yN8Y5RttbP7kzdtX22GbMg6i18a-Xwet2sshpt48", + description: + "Today we’re excited to share that the Taiko alpha-3 testnet, Grímsvötn, is live! This is the next step on the road to a decentralized, Ethereum-equivalent ZK-EVM.", + date: "Jun 07, 2023", + datetime: "2023-06-07", + imageUrl: + "https://mirror-media.imgix.net/publication-images/LtyEm5huf-mf9854QWh3o.jpeg?height=800&width=1600&h=800&w=1600&auto=compress", + readingTime: "9 min", + author: { + name: "finestone", + imageUrl: "https://avatars.githubusercontent.com/u/36642873?s=96&v=4", + }, + }, { title: "ZK-Roller-Coaster #6", href: "https://taiko.mirror.xyz/7BwxX8eR_dW2jihpAk6V10X4qKG0X7NKs_l3Me1pLNs", @@ -29,21 +44,6 @@ const posts = [ imageUrl: "https://avatars.githubusercontent.com/u/106527861?v=4", }, }, - { - title: "ZK-Roller-Coaster #5", - href: "https://taiko.mirror.xyz/D9hurhYWGpVbFosu8KYsr0FeYcbi4wB0rt67hbXD_zk", - description: - "This is the 5th edition of ZK-Roller-Coaster where we track and investigate the most exciting, meaningful, and crazy ZK-stuff of the prior two weeks.", - date: "May 22, 2023", - datetime: "2023-05-22", - imageUrl: - "https://mirror-media.imgix.net/publication-images/aqZ6LByfP5NL675mThlf-.png?height=512&width=1024&h=512&w=1024&auto=compress", - readingTime: "3 min", - author: { - name: "Lisa A.", - imageUrl: "https://avatars.githubusercontent.com/u/106527861?v=4", - }, - }, ]; export default function BlogSection() { From 125ecff4301c053bd5fdf24c3d7fa2fafcd3c397 Mon Sep 17 00:00:00 2001 From: dave | d1onys1us <13951458+d1onys1us@users.noreply.github.com> Date: Thu, 8 Jun 2023 12:43:20 +0900 Subject: [PATCH 4/4] fix(website): update contract addresses (#13918) --- packages/website/pages/docs/reference/contract-addresses.md | 1 - 1 file changed, 1 deletion(-) diff --git a/packages/website/pages/docs/reference/contract-addresses.md b/packages/website/pages/docs/reference/contract-addresses.md index e2c8fd6f76d..cb6884e4b7a 100644 --- a/packages/website/pages/docs/reference/contract-addresses.md +++ b/packages/website/pages/docs/reference/contract-addresses.md @@ -45,7 +45,6 @@ | Name | Address | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Taiko's personal proposer | [0xE09e4fF4353fbf984F99fa824524277F704e7475](https://sepolia.etherscan.io/address/0xE09e4fF4353fbf984F99fa824524277F704e7475) | -| Taiko's personal prover | [0x6798639591530FbBAfd12c2826422B58bD2c5219](https://sepolia.etherscan.io/address/0x6798639591530FbBAfd12c2826422B58bD2c5219) | | Taiko's relayer | [0xe07b3455f382E6912558f613e072c1a46964eDBb](https://sepolia.etherscan.io/address/0xe07b3455f382E6912558f613e072c1a46964eDBb) | | Oracle prover | [0x6798639591530FbBAfd12c2826422B58bD2c5219](https://sepolia.etherscan.io/address/0x6798639591530FbBAfd12c2826422B58bD2c5219) | | System prover 1 | [0x89697A45BA1FEFbc575BdcA6e0C50D5112A5a766](https://sepolia.etherscan.io/address/0x89697A45BA1FEFbc575BdcA6e0C50D5112A5a766) |