lidofinance / alerting-forta Goto Github PK

tl;dr

When the alert logic requires to query something from the previous block, it's better to use the block.parentHash instead of blockNumber - 1 to avoid issues with the Ethereum chain reorganizations.

How to fix

See the following reference code:
https://github.com/lidofinance/alerting-forta/blob/main/ethereum-steth/src/clients/eth_provider.ts#L181-L196

  public async getBalanceByBlockHash(address: string, blockHash: string): Promise<E.Either<Error, BigNumber>> {
    try {
      const out = await retryAsync<EtherBigNumber>(
        async (): Promise<EtherBigNumber> => {
          return await this.jsonRpcProvider.getBalance(address, {
            blockHash: blockHash,
          } as never)
        },
        { delay: DELAY_IN_500MS, maxTry: ATTEMPTS_5 },
      )

      return E.right(new BigNumber(String(out)))
    } catch (e) {
      return E.left(new NetworkError(e, `Could not fetch balance by address ${address} and blockHash ${blockHash}`))
    }
  }

https://github.com/lidofinance/alerting-forta/blob/main/ethereum-steth/src/services/vault/Vault.srv.ts#L60-L63

const prevBlockWithdrawalVaultBalance = await this.ethProvider.getBalanceByBlockHash(
  this.withdrawalsVaultAddress,
  blockEvent.block.parentHash,
)

Affected scope

List of the files that affected by the issue:

grep --include=\*.ts -rnw '.' -e ".*umber - 1" --exclude-dir=node_modules

./ethereum-validators-set/src/subagents/lido-report/agent-lido-report.ts:841:    blockTag: txEvent.blockNumber - 1,
./ethereum-validators-set/src/subagents/exitbus-oracle/agent-exitbus-oracle.ts:283:      blockEvent.blockNumber - 1,
./ethereum-validators-set/src/subagents/accounting-oracle/agent-accounting-oracle.ts:140:      blockEvent.blockNumber - 1,
./ethereum-validators-set/src/subagents/accounting-oracle/agent-accounting-oracle.ts:148:        blockEvent.blockNumber - 1,
./l2-bridge-linea/src/clients/linea_block_client.ts:72:      const blocks = await this.provider.fetchBlocks(this.cachedBlockDto.number, latestBlock.right.number - 1)
./l2-bridge-mantle/src/clients/mantle_block_client.ts:72:      const blocks = await this.mantleProvider.fetchBlocks(this.cachedBlockDto.number, latestBlock.right.number - 1)
./voting-watcher/src/agent-voting-watcher.ts:156:  const prevBlock = await ethersProvider.getBlock(blockEvent.blockNumber - 1);
./ethereum-steth/src/services/steth_operation/StethOperation.srv.ts:230:      this.ethProvider.getBufferedEther(shiftedBlockNumber - 1),
./l2-bridge-base/src/services/monitor_withdrawals.ts:54:    const withdrawalEvents = await this.withdrawalsClient.getWithdrawalEvents(pastl2Block, l2BlockNumber - 1)
./l2-bridge-base/src/clients/base_block_client.ts:72:      const blocks = await this.provider.fetchL2Blocks(this.cachedBlockDto.number, latestBlock.right.number - 1)
./ethereum-financial/src/services/aave/Aave.srv.ts:63:        this.ethProvider.getStethBalance(this.aaveAstethAddress, blockEvent.number - 1),
./ethereum-financial/src/services/aave/Aave.srv.ts:64:        await this.ethProvider.getTotalSupply(blockEvent.number - 1),
./ethereum-financial/src/services/aave/Aave.srv.ts:101:              `${blockEvent.number - 1}`,
./l2-bridge-zksync/src/clients/zksync_block_client.ts:72:      const blocks = await this.provider.fetchBlocks(this.cachedBlockDto.number, latestBlock.right.number - 1)

Explanations and references

References

• https://figment.io/insights/ethereum-reorg-what-you-need-to-know/
• https://www.alchemy.com/overviews/what-is-a-reorg

Helpful picture

Error in AgentPoolsRewards.handleBlock
TypeError: Cannot read property 'periodFinish' of undefined

https://explorer.forta.network/alert/0x85fbc5f6b3e9842c89fa1d3d92572009a66cc9d7d8cfe53c37eefc1ace22e897

tl;dr

GateSeal expiration alert should have been fired three days ago because the contract's expiration date is set to May, 1st and the expiration threshold for the alert is four weeks (28 days).

Description

The currently deployed GateSeal instance has an expiration timestamp set at 1714521600, i.e., 25 days away.

However, the following code should have fired an alert three days ago:

const GATE_SEAL_EXPIRY_THRESHOLD = ONE_MONTH
const GATE_SEAL_EXPIRY_TRIGGER_EVERY = ONE_WEEK
...
    } else if (
      currentBlockTimestamp - this.cache.getLastExpiryGateSealAlertTimestamp() >
      GATE_SEAL_EXPIRY_TRIGGER_EVERY
    ) {
      if (Number(expiryTimestamp) - currentBlockTimestamp <= GATE_SEAL_EXPIRY_THRESHOLD) {
        out.push(
          Finding.fromObject({
            name: '⚠️ GateSeal: is about to be expired',
            description: `GateSeal address: ${etherscanAddress(this.gateSealAddress)}\nExpiry date ${new Date(
              String(expiryTimestamp),
            )}`,
            alertId: 'GATE-SEAL-IS-ABOUT-TO-BE-EXPIRED',
            severity: FindingSeverity.Medium,
            type: FindingType.Degraded,
          }),
        )
        this.cache.setLastExpiryGateSealAlertTimestamp(currentBlockTimestamp)
      }
    }

Unluckily, it hadn't been fired due to the unknown reason (edited)

References

• https://docs.lido.fi/deployed-contracts/
• https://research.lido.fi/t/renew-gateseal-for-the-withdrawal-queue-and-validator-exit-bus-oracle/7081

How to reproduce

Given the expiration timestamp value is 1714521600, substracting GATE_SEAL_EXPIRY_THRESHOLD (which is 60 * 60 * 24 * 7 * 4 = 2419200 gives us 1714521600 - 2419200 = 1712102400, using the following API to fetch the block just after the threshold value:

https://api.findblock.xyz/v1/chain/1/block/after/1712102400
can conclude that the alert should have fired in the block 19571532

Wait time in the alert body and in the header are different

Currently, the l2-bridge-ethereum agent supports only:

• wstETH on Arbitrum bridge (L1 part)
• wstETH on Arbitrum bridge (L2 part)

Worth extending support for:

• wstETH on Base (L1 part, as the network in production atm)
• wstETH on zkSync (L1 part, as the network in the proposed state)

@sergeyWh1te, it would be great if you could take over the initiative here
cc: @arwer13 for future improvement (we missed this part for Base I guess)

Need to move alerts to relevant bots:

• - l2-bridge-linea
• - l2-bridge-base
• - l2-bridge-mantle
• - l2-bridge-zkSync
• - l2-bridge-Arbitrum
• - l2-bridge-Optimism

Proxy admin for L1 TokenBridge to Linea(0x051f1d88f0af5763fb888ec4378b4d8b29ea3319) was changed from 0x5B0bb17755FBa06028530682E2FD5bc373931768 to 0xF5058616517C068C7b8c7EbC69FF636Ade9066d6

Target bot: bsc-adi-governance

There are still things that needed to be done in order to achieve ✨ perfection ✨:

Alerts

• 🚨 BSC a.DI: Allowed Bridges quorum updated
• 🚨 BSC a.DI: Allowed bridges set updated

Context
Today we are starting the on-chain vote to change GateSeal address to pause wq and vebo contracts.
The vote will end on Fri, Apr, 26 at about 5 PM.

Proposal

• To change GateSeal's address in alerts https://github.com/lidofinance/alerting-forta/blob/main/ethereum-steth/src/utils/constants.ts#L41
  from 0x1ad5cb2955940f998081c1ef5f5f00875431aa90 to 0x79243345eDbe01A7E42EDfF5900156700d22611c
• to decrease the frequency of alerts about GateSeal expiration from weekly to bi-weekly.

Error in AgentBethRewards.handleBlock
Error: unexpected block hash
https://explorer.forta.network/alert/0xfbc3b530460058934d656db2066f1dc9f7bc8b93538c669654626a78cc087351

The error occurred ~ Jan 23 for the first time on single scan node.

It seems there is a problem in synchronisation of agent-beth-rewards and agent-lido-oracle.

Need to figure out the alert logic given the withdrawals logic in the post-Lido V2 world.

Filing this issue to be marked explicitly.