You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/pos/architecture/bor/consensus.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,11 +14,11 @@ Once validators are active on Heimdall they get selected as producers through `b
14
14
15
15
A logically defined set of blocks for which a set of validators is chosen from among all the available validators. Heimdall provides span details through span-details APIs.
16
16
17
-
Each validator in span contains voting power. Based on their power, they get selected as block producers. Higher power, a higher probability of becoming block producers. Bor uses Tendermint's algorithm for the same.
17
+
Each validator in span contains voting power. Based on their power, they get selected as block producers. Higher power, a higher probability of becoming block producers. Bor uses Tendermint's algorithm for the same.
18
18
19
19
## Sprint
20
20
21
-
A set of blocks within a span for which only a single block producer is chosen to produce blocks. The sprint size is a factor of span size.
21
+
A set of blocks within a span for which only a single block producer is chosen to produce blocks. The sprint size is a factor of span size.
22
22
23
23
Apart from the current proposer, Bor also selects back-up producers.
Bor provides a mechanism where some specific events on the main Ethereum chain are relayed to Bor.
93
93
94
-
1. Any contract on Ethereum may call [syncState](https://github.com/maticnetwork/contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol#L33) in `StateSender.sol`. This call emits `StateSynced` event: https://github.com/maticnetwork/contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol#L38
94
+
1. Any contract on Ethereum may call [syncState](https://github.com/maticnetwork/contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol#L33) in `StateSender.sol`. This call emits `StateSynced` event: <https://github.com/maticnetwork/contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol#L38>
2. Heimdall listens to these events and calls `function proposeState(uint256 stateId)` in `StateReceiver.sol` - thus acting as a store for the pending state change ids. Note that the `proposeState` transaction will be processed even with a 0 gas fee as long as it is made by one of the validators in the current validator set: https://github.com/maticnetwork/genesis-contracts/blob/master/contracts/StateReceiver.sol#L24
100
+
2. Heimdall listens to these events and calls `function proposeState(uint256 stateId)` in `StateReceiver.sol` - thus acting as a store for the pending state change ids. Note that the `proposeState` transaction will be processed even with a 0 gas fee as long as it is made by one of the validators in the current validator set: <https://github.com/maticnetwork/genesis-contracts/blob/master/contracts/StateReceiver.sol#L24>
101
101
102
-
3. At the start of every sprint, Bor pulls the details about the pending state changes using the states from Heimdall and commits them to the Bor state using a system call. See `commitState` here: https://github.com/maticnetwork/genesis-contracts/blob/f85d0409d2a99dff53617ad5429101d9937e3fc3/contracts/StateReceiver.sol#L41
102
+
3. At the start of every sprint, Bor pulls the details about the pending state changes using the states from Heimdall and commits them to the Bor state using a system call. See `commitState` here: <https://github.com/maticnetwork/genesis-contracts/blob/f85d0409d2a99dff53617ad5429101d9937e3fc3/contracts/StateReceiver.sol#L41>
Copy file name to clipboardExpand all lines: docs/pos/architecture/bor/index.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
Bor is our Block producer layer, which, in sync with the Heimdall validator, selects the producers and verifiers for each span and sprint.
4
4
5
-
The Bor node or the Block Producer implementation is basically the EVM-compatible blockchain operator. Currently, it is a Geth implementation with custom changes done to the consensus algorithm.
5
+
The Bor node or the Block Producer implementation is basically the EVM-compatible blockchain operator. Currently, it is a Geth implementation with custom changes done to the consensus algorithm.
6
6
7
7
Polygon PoS uses dual-consensus architecture on the Polygon Network to optimise for speed and decentralisation.
8
8
@@ -26,5 +26,5 @@ The ratio of Stake/Staking power specifies the probability to be selected as a m
26
26
27
27
1. Validators are given slots proportionally according to their stake.
28
28
2. Using historical Ethereum block data as seed, we shuffle this array.
29
-
3. Now depending on Producer count*(maintained by validator's governance)*, validators are taken from the top.
29
+
3. Now depending on Producer count*(maintained by validator's governance)*, validators are taken from the top.
30
30
4. Using this validator set and Tendermint's proposer selection algorithm, we choose a producer for every sprint on Bor.
Copy file name to clipboardExpand all lines: docs/pos/architecture/bor/snapshots.md
+7-9Lines changed: 7 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,8 @@
1
-
When setting up a new sentry, validator, or full node server, it is recommended that you use snapshots for faster syncing without having to sync over the network. Using snapshots will save you several days for both Heimdall and Bor. **Note: We no longer support bor archive snapshots due to unsustainable data growth.**
1
+
When setting up a new sentry, validator, or full node server, it is recommended that you use snapshots for faster syncing without having to sync over the network. Using snapshots will save you several days for both Heimdall and Bor. **Note: We no longer support bor archive snapshots due to unsustainable data growth.**
2
2
3
-
:::tip
3
+
!!! tip
4
4
5
-
For the latest snapshot, please visit [<ins>Polygon Chains Snapshots</ins>](https://snapshot.polygon.technology/).
6
-
7
-
:::
5
+
For the latest snapshot, please visit [<ins>Polygon Chains Snapshots</ins>](https://snapshot.polygon.technology/).
Once the extraction is complete, ensure that you update the datadir configuration of your client to point to the path where the extracted data is located. This ensures that the systemd services can correctly register the snapshot data when the client starts.
180
+
Once the extraction is complete, ensure that you update the datadir configuration of your client to point to the path where the extracted data is located. This ensures that the systemd services can correctly register the snapshot data when the client starts.
183
181
If you wish to preserve the default client configuration settings, you can use symbolic links (symlinks).
184
182
185
183
For example, let's say you have mounted your block device at `~/snapshots` and have downloaded and extracted the chaindata
Copy file name to clipboardExpand all lines: docs/pos/architecture/bor/state-sync.md
+18-20Lines changed: 18 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,9 @@
1
-
`State Sync` is the native mechanism to read Ethereum data from Matic EVM chain.
1
+
`State Sync` is the native mechanism to read Ethereum data from Matic EVM chain.
2
2
3
-
Validators on the Heimdall layer pickup the [StateSynced](https://github.com/maticnetwork/contracts/blob/a4c26d59ca6e842af2b8d2265be1da15189e29a4/contracts/root/stateSyncer/StateSender.sol#L24) event and pass it on to the Bor layer.
3
+
Validators on the Heimdall layer pickup the [StateSynced](https://github.com/maticnetwork/contracts/blob/a4c26d59ca6e842af2b8d2265be1da15189e29a4/contracts/root/stateSyncer/StateSender.sol#L24) event and pass it on to the Bor layer.
4
4
5
5
The receiver contract inherits [IStateReceiver](https://github.com/maticnetwork/genesis-contracts/blob/master/contracts/IStateReceiver.sol), and custom logic sits inside [onStateReceive](https://github.com/maticnetwork/genesis-contracts/blob/05556cfd91a6879a8190a6828428f50e4912ee1a/contracts/IStateReceiver.sol#L5) function.
6
6
7
-
8
7
This is the flow required from dapps / users to work with state-sync:
9
8
10
9
1. Call the smart contract function present here: [https://github.com/maticnetwork/contracts/blob/19163ddecf91db17333859ae72dd73c91bee6191/contracts/root/stateSyncer/StateSender.sol#L33](https://github.com/maticnetwork/contracts/blob/19163ddecf91db17333859ae72dd73c91bee6191/contracts/root/stateSyncer/StateSender.sol#L33)
@@ -14,30 +13,29 @@ This is the flow required from dapps / users to work with state-sync:
14
13
5. After every sprint on `bor`, the Bor node fetches the pending state-sync events from Heimdall via an API call.
15
14
6. The receiver contract inherits `IStateReceiver` interface, and custom logic of decoding the data bytes and performing any action sits inside `onStateReceive` function: [https://github.com/maticnetwork/genesis-contracts/blob/master/contracts/IStateReceiver.sol](https://github.com/maticnetwork/genesis-contracts/blob/master/contracts/IStateReceiver.sol)
16
15
17
-
18
-
# How does State Sync work?
16
+
## How does State Sync work?
19
17
20
18
State management sends the state from the Ethereum chain to the Bor chain. It is called **state-sync**.
21
19
22
-
State transfer from Ethereum to Bor happens through system call. Suppose, a user deposits USDC to the deposit manager on Ethereum. Validators listen to those events, validate, and store them in Heimdall state. Bor gets the latest state-sync records and updates the Bor state (mints equal amount of USDC on Bor) using a system call.
20
+
State transfer from Ethereum to Bor happens through system call. Suppose, a user deposits USDC to the deposit manager on Ethereum. Validators listen to those events, validate, and store them in Heimdall state. Bor gets the latest state-sync records and updates the Bor state (mints equal amount of USDC on Bor) using a system call.
To sync state, the contract calls following method **state sender contract** on Ethereum chain.
26
+
To sync state, the contract calls following method **state sender contract** on Ethereum chain.
29
27
30
28
```jsx
31
29
contract StateSender {
32
-
/**
33
-
* Emits `stateSynced` events to start sync process on Ethereum chain
34
-
* @paramreceiver Target contract on Bor chain
35
-
* @paramdata Data to send
36
-
*/
37
-
functionsyncState (
38
-
addressreceiver,
39
-
bytescalldatadata
40
-
) external;
30
+
/**
31
+
* Emits `stateSynced` events to start sync process on Ethereum chain
32
+
* @paramreceiver Target contract on Bor chain
33
+
* @paramdata Data to send
34
+
*/
35
+
functionsyncState (
36
+
addressreceiver,
37
+
bytescalldatadata
38
+
) external;
41
39
}
42
40
```
43
41
@@ -51,9 +49,9 @@ contract StateSender {
51
49
* @paramdata Data to send to Bor chain for Target contract address
52
50
*/
53
51
eventStateSynced (
54
-
uint256 indexed id,
55
-
address indexed contractAddress,
56
-
bytes data
52
+
uint256 indexed id,
53
+
address indexed contractAddress,
54
+
bytes data
57
55
);
58
56
```
59
57
@@ -92,4 +90,4 @@ Bor produces a new tx / receipt just for the client which includes all the logs
92
90
keccak256("matic-bor-receipt-"+ block number + block hash)
93
91
```
94
92
95
-
This doesn't change any consensus logic, only client changes. `eth_getBlockByNumber`, `eth_getTransactionReceipt`, and `eth_getLogs` include state-sync logs with derived. Note that the bloom filter on the block doesn't include inclusion for state-sync logs. It also doesn't include derived tx in `transactionRoot` or `receiptRoot`.
93
+
This doesn't change any consensus logic, only client changes. `eth_getBlockByNumber`, `eth_getTransactionReceipt`, and `eth_getLogs` include state-sync logs with derived. Note that the bloom filter on the block doesn't include inclusion for state-sync logs. It also doesn't include derived tx in `transactionRoot` or `receiptRoot`.
0 commit comments