# Differences between Ethereum and GIWA
The GIWA chain is built on the OP Stack. Because the OP Stack is EVM-equivalent, it provides an environment almost identical to Ethereum.
However, there are a few small differences between layer 2 GIWA and layer 1 Ethereum. Being aware of these differences when developing apps on the GIWA chain can reduce unexpected issues.
### Block
Item
Ethereum
GIWA
Block time
12 seconds
1 second
Block gas limit
45,000,000
60,000,000
Block production mechanism
Proposer + validator structure
Sequencer
### Bridging
Because GIWA is a layer 2 built on Ethereum, assets can be moved bidirectionally (Ethereum <-> GIWA) via bridges.
#### Deposit Transactions
A deposit transaction means changing GIWA's state by submitting a transaction on layer 1 Ethereum. This lets you move ETH and tokens from layer 1 to GIWA. Layer 1 transactions can also trigger contract calls on GIWA.
#### Withdrawal Transactions
A withdrawal transaction moves assets from layer 2 to layer 1 via a layer 2 transaction. For withdrawals, a proof of the layer 2 state must be submitted to layer 1. Because the proof might be incorrect, a fault-proof challenge period is added to validate the proof.
### Address Aliasing
When a deposit transaction is triggered by a smart contract, the sender address recorded on layer 2 for that transaction is `layer 1 smart contract address + 0x1111000000000000000000000000000000001111` as an aliased address. If you’re building cross-chain apps, you must account for this.
{% hint style="info" %}
Why Is Address Aliasing Needed?
According to the behavior of the `CREATE` opcode, contracts deployed on layer 1 and layer 2 can end up with the same address even if their code is different. This can create conflicts, especially when bridging or handling cross-chain interactions. To prevent these issues, transactions sent from an layer 1 contract are recorded on layer 2 with an aliased sender address instead of the original layer 1 contract address.
{% endhint %}
### Mempool
On Ethereum, when a transaction is sent, it propagates across the network nodes. These transactions remain in the mempool until they are included in a block. Ethereum maintains a public mempool, so anyone can inspect pending transactions.
On L2 GIWA, however, there is no public mempool. Only the sequencer — the entity responsible for producing blocks — can access it. The GIWA sequencer currently executes transactions in order of the highest fees first.
### Finality
Unlike Ethereum, blocks on GIWA can exist in three states:
* unsafe: The block has been produced by the GIWA sequencer but has not yet been published to Ethereum
* safe: The block has been published to Ethereum
* finalized: The block has been published to Ethereum, and the corresponding L1 block has reached finalized status
When developing on GIWA, you may need to consider the state of layer 2 blocks.
## Learn more
* [Bridging](https://docs.optimism.io/stack/differences#bridging)
* [Opcodes](https://docs.optimism.io/stack/differences#opcodes)
* [Transactions](https://docs.optimism.io/stack/differences#transactions)
* [Chain Finality](https://docs.optimism.io/stack/differences#chain-finality)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.giwa.io/giwa-chain/en/network-information/diffs-ethereum-giwa.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.