From da11ef2787c2106decb0c85a76058a7e4ecd3e14 Mon Sep 17 00:00:00 2001 From: TucksonDev Date: Fri, 29 Sep 2023 14:10:38 +0100 Subject: [PATCH 1/2] Add Arbitrum to Oracles section --- docs/concepts/protocol/oracle.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/concepts/protocol/oracle.md b/docs/concepts/protocol/oracle.md index 47a97f889e..7e926a6d8c 100644 --- a/docs/concepts/protocol/oracle.md +++ b/docs/concepts/protocol/oracle.md @@ -91,3 +91,7 @@ Ticks are signed integers and can be expressed as a negative number, so for any ### Optimism On Optimism, every transaction is confirmed as an individual block. The `block.timestamp` of these blocks, however, reflect the `block.timestamp` of the last L1 block ingested by the Sequencer. For this reason, Uniswap pools on Optimism are not suitable for providing oracle prices, as this high-latency `block.timestamp` update process makes the oracle much less costly to manipulate. In the future, it's possible that the Optimism `block.timestamp` will have much higher granularity (with a small trust assumption in the Sequencer), or that forced inclusion transactions will improve oracle security. For more information on these potential upcoming changes, please see the [Optimistic Specs repo](https://github.com/ethereum-optimism/optimistic-specs/discussions/23). For the time being, usage of the oracle feature on Optimism should be avoided. + +### Arbitrum One + +On Arbitrum One, multiple transactions can be part of a block, and [multiple blocks](https://arbiscan.io/blocks) are usually created per second (up to a maximum of 4 blocks per second). Their `block.timestamp` reflect the time at which the block was produced based on the sequencer's clock (see [Arbitrum's sequencer documentation](https://docs.arbitrum.io/sequencer) to learn more about its trust assumptions), so observations have enough granularity to make the oracle more difficult to manipulate. Thus, Uniswap pools on Arbitrum One are suitable for providing oracle prices. For more information on how block numbers and time work on Arbitrum One, please see the [Arbitrum documentation portal](https://docs.arbitrum.io/time). \ No newline at end of file From b140c00559bbc833d742167786e8ad56cc189360 Mon Sep 17 00:00:00 2001 From: Tuckson <105675159+TucksonDev@users.noreply.github.com> Date: Tue, 26 Mar 2024 19:08:08 +0000 Subject: [PATCH 2/2] Update oracle.md --- docs/concepts/protocol/oracle.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/concepts/protocol/oracle.md b/docs/concepts/protocol/oracle.md index e2a742a909..58a86973cd 100644 --- a/docs/concepts/protocol/oracle.md +++ b/docs/concepts/protocol/oracle.md @@ -86,9 +86,7 @@ With a tick reading of `100_000`, we can find the value of `token1` (USDC) in te Ticks are signed integers and can be expressed as a negative number, so for any circumstances where `token0` is of a lower value than `token1`, a negative tick value will be returned by `tickCumulative` and a relative value of `< 0` will be returned by a calculation of `token0` in terms of `token1`. -### Optimism - -On Optimism, every transaction is confirmed as an individual block. The `block.timestamp` of these blocks, however, reflect the `block.timestamp` of the last L1 block ingested by the Sequencer. For this reason, Uniswap pools on Optimism are not suitable for providing oracle prices, as this high-latency `block.timestamp` update process makes the oracle much less costly to manipulate. In the future, it's possible that the Optimism `block.timestamp` will have much higher granularity (with a small trust assumption in the Sequencer), or that forced inclusion transactions will improve oracle security. For more information on these potential upcoming changes, please see the [Optimistic Specs repo](https://github.com/ethereum-optimism/optimistic-specs/discussions/23). For the time being, usage of the oracle feature on Optimism should be avoided. +## Oracles Integrations on Layer 2 Rollups ### Arbitrum One