Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typo mistake at bridge between Morph and Ethereum #19

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

typo mistake at bridge between Morph and Ethereum #19

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 17 additions & 19 deletions docs/build-on-morph/build-on-morph/3-bridge-between-morph-and-ethereum.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
---
title: Bridge between Morph and Ethereum
lang: en-US
keywords: [morph,ethereum,rollup,layer2,validity proof,optimstic zk-rollup]
keywords: [morph, ethereum, rollup, layer2, validity proof, optimstic zk-rollup]
description: Upgrade your blockchain experience with Morph - the secure decentralized, cost0efficient, and high-performing optimstic zk-rollup solution. Try it now!
---

## Bridging basics

Although Morph is an Ethereum Layer 2 (and therefore fundamentally connected to Ethereum), it's also a separate blockchain system.
Although Morph is an Ethereum Layer 2 (and therefore fundamentally connected to Ethereum), it's also a separate blockchain system.

App developers often have a need to move data and assets between Morph and Ethereum, a process we call "bridging".

Expand All @@ -17,10 +17,9 @@ For the most common usecase, moving tokens around, we've created the Standard To

### Sending data

If the Standard Token Bridge doesn't fully cover your usecase, you can also [send arbitrary data between L1 and L2](#send-messages-between-morph-and-ethereum). You can use this functionality to have a contract on Ethereum trigger a contract function on Morph, and vice versa.

We've made this process as easy as possible by giving developers a simple API for triggering a cross-chain function call.
If the Standard Token Bridge doesn't fully cover your usecase, you can also [send arbitrary data between L1 and L2](#send-messages-between-morph-and-ethereum). You can use this functionality to have a contract on Ethereum trigger a contract function on Morph, and vice versa.

We've made this process as easy as possible by giving developers a simple API for triggering a cross-chain function call.

## Utilize Standard Bridge Contract

Expand All @@ -33,7 +32,8 @@ The Standard Bridge is composed of two main contracts the [`L1StandardBridge`](h
Here we'll go over the basics of using this bridge to move tokens between Layer 1 and Layer 2.

## Deposits
<!--

<!--
::: warning NOTICE
We're working hard to get more smart contract wallet software deployed and tested on Morph.
However, as a safety measure, **we currently block smart contract wallets from calling the `depositETH` and `depositERC20` functions**.
Expand All @@ -47,7 +47,6 @@ ERC20 deposits into L2 can be triggered via the `depositERC20` and `depositERC20

Ensure the Standard Token Bridge is **approved** to use the tokens you wish to deposit.


### Depositing ETH

ETH deposits into L2 can be triggered via the `depositETH` and `depositETHTo` functions on the [`L1StandardBridge`](https://github.com/morph-l2/contracts/tree/main/contracts/L1/L1StandardBridge.sol#L119C20-L119C20).
Expand All @@ -65,7 +64,6 @@ ERC20 withdrawals can be triggered via the `withdraw` or `withdrawTo` functions
Unlike on L1, we do not have a separate function on L2 for withdrawing ETH.
Instead, you can use the `withdraw` or `withdrawTo` functions on the [`L2StandardBridge`](https://github.com/morph-l2/contracts/tree/main/contracts/L2/L2StandardBridge.sol#L121) and use the address `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` as the L2 token address.


## Send messages between Morph and Ethereum

Apps on Morph can be made to interact with apps on Ethereum via a process called "bridging".
Expand All @@ -76,7 +74,7 @@ With just a little bit of elbow grease, you also can create contracts that bridg

<summary><b>Understanding contract calls</b></summary>

To understand the process of creating bridges between contracts on Layer 1 and Layer 2, you should first have a basic understanding of the way contracts on *Ethereum* communicate with one another.
To understand the process of creating bridges between contracts on Layer 1 and Layer 2, you should first have a basic understanding of the way contracts on _Ethereum_ communicate with one another.
If you're a smart contract developer, you might be familiar with stuff like this:

```solidity
Expand Down Expand Up @@ -134,7 +132,7 @@ At a high level, this process is pretty similar to the same process for two cont

Each layer has its own messenger contract which serves to abstract away some lower-level communication details, a lot like how HTTP libraries abstract away physical network connections.

We won't get into *too* much detail about these contracts here — the only thing you really need to know about is the `sendMessage` function attached to each messenger:
We won't get into _too_ much detail about these contracts here — the only thing you really need to know about is the `sendMessage` function attached to each messenger:

```solidity
function sendMessage(
Expand Down Expand Up @@ -182,7 +180,7 @@ contract MyOtherContract {
}
```

:::tip
:::tip

Using the messenger contracts
Our messenger contracts, the [`L1CrossDomainMessenger`](https://github.com/morph-l2/contracts/tree/main/contracts/L1/L1CrossDomainMessenger.sol) and [`L2CrossDomainMessenger`](https://github.com/morph-l2/contracts/tree/main/contracts/L2/L2CrossDomainMessenger.sol), always come pre-deployed to each of our networks.
Expand All @@ -193,14 +191,14 @@ Our messenger contracts, the [`L1CrossDomainMessenger`](https://github.com/morph

Each message from L2 to L1 requires three transactions:

1. An L2 transaction that *initiates* the transaction, which is priced the same as any other transaction made on Morph.
1. An L2 transaction that _initiates_ the transaction, which is priced the same as any other transaction made on Morph.

2. An L1 transaction that *proves* the transaction.
2. An L1 transaction that _proves_ the transaction.
This transaction can only be submitted after the state root is submitted to L1.
This transaction is expensive because it includes verifying a [Merkle trie](https://eth.wiki/fundamentals/patricia-tree) inclusion proof.
This transaction is expensive because it includes verifying a [Merkle tree](https://eth.wiki/fundamentals/patricia-tree) inclusion proof.

3. An L1 transaction that *finalizes* the transaction.
This transaction can only be submitted after the transaction challenge period has passed.
3. An L1 transaction that _finalizes_ the transaction.
This transaction can only be submitted after the transaction challenge period has passed.

The total cost of an L2 to L1 transaction is therefore the combined cost of the L2 initialization transaction and the two L1 transactions.

Expand All @@ -212,7 +210,6 @@ ne of the most important things to understand about L1 ⇔ L2 interactions is th
.
This means that any messages you send from Layer 2 will only be received on Layer 1 after this period has elapsed.


:::tip

Read about Morph's unique challenge design based on [Responsive validity proof](../../how-morph-works/responsive-validity-proof/1-overview.md)
Expand All @@ -222,16 +219,17 @@ Read about Morph's unique challenge design based on [Responsive validity proof](
We call this period of time the "challenge period" because it is the time during which a transaction can be challenged.This period is critical for ensuring the integrity of transactions between Layer 2 and Layer 1.

Comparing Rollup Approaches:

- In a basic Optimistic Rollup, identifying and correcting incorrect transactions or states (like a fraudulent withdrawal transaction aiming to redirect your ETH to a hacker's address) requires significant time and effort. This involves interactions with the sequencer to prove the transaction is incorrect.
- Morph’s approach differs. With Responsive Validity Proof, the sequencer is required to prove their correctness by submitting a zk (zero-knowledge) validity proof. This system necessitates a specific period for challengers to detect issues and initiate a challenge.

Implications for Smart Contracts:

- It’s crucial not to make decisions about Layer 2 transaction results from within a smart contract on Layer 1 until the challenge period has elapsed. Doing so prematurely might lead to decisions based on invalid transaction results.
- Consequently, messages sent from Layer 2 to Layer 1, using the standard messenger contracts, cannot be relayed until they have completed the full challenge period.


<!--
::: tip On the length of the challenge period
The challenge period on Morph testnet is currently for test purposes.
:::
-->
-->