Merge pull request 0xPolygon#2688 from 0xPolygon/mardizzone/docs-update

update docs for hv2

Author: arash009

docs/cdk/how-to/deploy-t1-prover-devnet.md

@@ -72,7 +72,7 @@ The following steps create some test data.
 
 1. Start the devnet up with `docker compose up`. If you had previously run this command, you might want to wipe old data with a `make clean` to avoid running from a previous state.
 2. Wait for blocks to start being produced. This should only take a few seconds. You can use `polycli monitor` to quickly check that blocks are being created.
-3. Generate some load and test transactions, by using a tool like [polycli](https://github.com/maticnetwork/polygon-cli/blob/main/doc/polycli_loadtest.md) to create transactions.
+3. Generate some load and test transactions, by using a tool like [polycli](https://github.com/0xPolygon/polygon-cli/blob/main/doc/polycli_loadtest.md) to create transactions.
 4. Once the load is done, and if you ran docker in detached mode, you can stop the devnet with `docker compose stop`.
 5. Checkout and build [jerrigon](https://github.com/0xPolygonZero/erigon/tree/feat/zero) from the `feat/zero` branch. You can use `make all` to build everything.
 6. Create a copy of the erigon state directory to avoid corrupting things
@@ -155,4 +155,4 @@ We expect that the following transaction types or use-cases to prove without any
     polycli wallet inspect --mnemonic "code code code code code code code code code code code quality" | jq '.Addresses[] | {"key": .ETHAddress, "value": { "balance": "0x21e19e0c9bab2400000"}}' | jq -s 'from_entries'
     ```
 
-[^1]: See Line# 11 of the docker-compose.yml https://github.com/0xPolygonZero/eth-pos-devnet-provable/blob/959da56673c25c2094b1a23bc9e1fa9ae9a9db6e/docker-compose.yml#L11 
+[^1]: See Line# 11 of the docker-compose.yml https://github.com/0xPolygonZero/eth-pos-devnet-provable/blob/959da56673c25c2094b1a23bc9e1fa9ae9a9db6e/docker-compose.yml#L11 

docs/innovation-design/security/reports.md

@@ -24,7 +24,6 @@ The scope of the ISO/IEC 27001:2022 certification is limited to the information
 
 ## POS
 
- - Bor/Heimdal milestones audit by Least Authority: https://github.com/maticnetwork/bor/blob/develop/audit/audit-feature-milestones.pdf.
  - POS portal audits: https://github.com/maticnetwork/pos-portal/tree/master/audits.
  - POS contracts: https://github.com/0xPolygon/pos-contracts/tree/main/audit.
 

docs/pos/architecture/bor/introduction.md

@@ -11,7 +11,7 @@ The ratio of stake/staking power specifies the probability to be selected as a m
 1. Validators are given slots proportionally according to their stake.
 2. Using historical Ethereum block data as seed, we shuffle this array.
 3. Now depending on Producer count*(maintained by validator's governance)*, validators are taken from the top.
-4. Using this validator set and Tendermint's proposer selection algorithm, we choose a producer for every sprint on Bor.
+4. Using this validator set and CometBFT's proposer selection algorithm, we choose a producer for every sprint on Bor.
 
 ## Detailed mechanics of Bor consensus
 
@@ -21,7 +21,7 @@ In Polygon's Proof-of-Stake (PoS) framework, participants can stake MATIC tokens
 
 ### Span: Defining validator sets and voting power
 
-A span is a defined set of blocks, during which a specific subset of validators is selected from the broader validator pool. Heimdall provides intricate details of each span through its span-details APIs. Within a span, each validator is assigned a certain voting power. The probability of a validator being chosen as a block producer is directly proportional to their voting power. The selection algorithm for block producers is borrowed from Tendermint's consensus protocol.
+A span is a defined set of blocks, during which a specific subset of validators is selected from the broader validator pool. Heimdall provides intricate details of each span through its span-details APIs. Within a span, each validator is assigned a certain voting power. The probability of a validator being chosen as a block producer is directly proportional to their voting power. The selection algorithm for block producers is borrowed from CometBFT's consensus protocol.
 
 ### Sprint: Single block producer selection within a span
 

docs/pos/architecture/bor/state-sync.md

@@ -1,17 +1,17 @@
 `State sync` is the native mechanism for a user in the Polygon PoS chain to read the latest Ethereum data.
 
-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.
+Validators on the Heimdall layer pickup the [StateSynced](https://github.com/0xPolygon/pos-contracts/blob/a4c26d59ca6e842af2b8d2265be1da15189e29a4/contracts/root/stateSyncer/StateSender.sol#L24) event and pass it on to the Bor layer.
 
-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.
+The receiver contract inherits [IStateReceiver](https://github.com/0xPolygon/genesis-contracts/blob/master/contracts/IStateReceiver.sol), and custom logic sits inside [onStateReceive](https://github.com/0xPolygon/genesis-contracts/blob/05556cfd91a6879a8190a6828428f50e4912ee1a/contracts/IStateReceiver.sol#L5) function.
 
 This is the flow required from dapps / users to work with state-sync:
 
-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)
+1. Call the smart contract function present here: [https://github.com/0xPolygon/pos-contracts/blob/19163ddecf91db17333859ae72dd73c91bee6191/contracts/root/stateSyncer/StateSender.sol#L33](https://github.com/0xPolygon/pos-contracts/blob/19163ddecf91db17333859ae72dd73c91bee6191/contracts/root/stateSyncer/StateSender.sol#L33)
 2. Which emits an event called `StateSynced(uint256 indexed id, address indexed contractAddress, bytes data);`
 3. All the validators on the Heimdall chain receive this event and one of them, whoever wishes to get the transaction fees for state sync sends this transaction to Heimdall.
 4. Once `state-sync` transaction on Heimdall has been included in a block, it is added to pending state-sync list.
 5. After every sprint on `bor`, the Bor node fetches the pending state-sync events from Heimdall via an API call.
-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)
+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/0xPolygon/genesis-contracts/blob/master/contracts/IStateReceiver.sol](https://github.com/0xPolygon/genesis-contracts/blob/master/contracts/IStateReceiver.sol)
 
 ## How does state sync work?
 
@@ -21,7 +21,7 @@ State transfer from Ethereum to Bor happens through system call. Suppose, a user
 
 ## State sender
 
-Source: [https://github.com/maticnetwork/contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol](https://github.com/maticnetwork/contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol)
+Source: [https://github.com/0xPolygon/pos-contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol](https://github.com/0xPolygon/pos-contracts/blob/develop/contracts/root/stateSyncer/StateSender.sol)
 
 To sync state, the state sender contract calls the `syncState` method on Ethereum chain.
 
@@ -57,7 +57,7 @@ event StateSynced (
 
 Once the `StateSynced` event is emitted on the `stateSender` contract on Ethereum, Heimdall listens to those events and adds to the Heimdall state after $2/3+$ validators agree on the.
 
-After every sprint (currently 16 blocks on Bor), Bor fetches a new state-sync record and updates the state using a `system` call. Here is the code for the same: [https://github.com/maticnetwork/bor/blob/6f0f08daecaebbff44cf18bee558fc3796d41832/consensus/bor/genesis_contracts_client.go#L51](https://github.com/maticnetwork/bor/blob/6f0f08daecaebbff44cf18bee558fc3796d41832/consensus/bor/genesis_contracts_client.go#L51)
+After every sprint (currently 16 blocks on Bor), Bor fetches a new state-sync record and updates the state using a `system` call. Here is the code for the same: [https://github.com/0xPolygon/bor/blob/6f0f08daecaebbff44cf18bee558fc3796d41832/consensus/bor/genesis_contracts_client.go#L51](https://github.com/0xPolygon/bor/blob/6f0f08daecaebbff44cf18bee558fc3796d41832/consensus/bor/genesis_contracts_client.go#L51)
 
 During `commitState`, Bor executes `onStateReceive`, with `stateId` and `data` as args, on target contract.
 
@@ -83,7 +83,7 @@ System call is helpful to change state to contract without making any transactio
 
 ## State-sync logs and Bor block receipts
 
-Events emitted by system calls are handled in a different way than normal logs. Here is the code: [https://github.com/maticnetwork/bor/pull/90](https://github.com/maticnetwork/bor/pull/90).
+Events emitted by system calls are handled in a different way than normal logs. Here is the code: [https://github.com/0xPolygon/bor/pull/90](https://github.com/0xPolygon/bor/pull/90).
 
 Bor produces a new transaction/receipt just for the client which includes all the logs for state-sync. Transaction hash is derived from block number and block hash (last block at that sprint):