---
# System prepended metadata

title: 'Bridge:'

---

# Bridge:
This document give a different explanations about the bridge.

## How to do a resync in the bridge?
To do a resync in the bridge first we need to know until which point of the synchronization we want to delete.
The bridge sync is similar to the node sync. Thus, all the blocks are store in table sync.block. It is important to mention that L1 and L2 synchronization uses the same tables and can only be differenciated by the network_id field. So if we want to check the L1 nodes we should do the next query.
```
select * from sync.block where network_id = 0
```
Fow L2 would be:
```
select * from sync.block where network_id = 1
```
Most of the tables are linked with the block table by the block_id. To get this block_id from table block just do the next query.
```
select id from sync.block
```
If we want to resync from a certain block, first we need to identify the block. After that we can use the next query to clean the tables.
The next example cleans the l2 synchronization from a certain id. The same query could be done using block_num instead of id.
```
-------------------------------------------------------------
delete from sync.block where id >= 227241 and network_id = 1
-------------------------------------------------------------
```


#### Hackmd with API changes to be implemented by polygon UI:
https://hackmd.io/@whdiZCYoSvCkHAcEx3dnWA/SkhNRMHtp


# DataBase structure:

Ther are two schemas. One schema is used to store data received from smart contract. This schema is called sync.
In the mt schema the information of the all the mts is stored.
There is another schema called public that contains a table to control the migrations.

## Sync schema contains the next tables:
```
- block
- claim
- deposit
- exit_root
- monitored_txs
- token_wrapped
```

Except table monitored_txs, all tables are referenciate to table block in order to allo deletes on cascade if a reorg happens.

**NOTE:** It is important to mention that tables mix L1 sync and L2 sync using the fiel network_id.
network_id 0 is mainnet and rollups could have network_id 1,2,3 and so on and so forth.

MT schema have the next tables:

```
- rht
- root
- rollup_exit
```


## Merkle tree explanation by kevin:
https://drive.google.com/file/d/15_SdR1SG_mP5HZ4UAL-rE8O4NulENW7N/view











