msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
Subscribe to msfew
Subscribe to msfew
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Blockchains have two sources of data: on-chain data (e.g. the amount of ETH held by an address), and off-chain data (e.g. the current price of ETH on the exchange). To get the latter, the oracle needs to tell this data to the smart contract.
Why does the Internet also need to have “offline” data, but doesn’t have the oracle problem? Because data on the blockchain needs to be secured, so the data uploaded to the oracle needs to be trusted, whereas data on the Internet (Web2) is inherently centralized.
The oracle needs to solve the trust problem from data source to processing and feeding, not usually the problem of the data itself.
The trust problem of the oracle consists of data source and data processing and feeding, and the following solutions are available for each of them:
I think the most important point of the oracle’s trust issue is the trustworthiness of the data source, but a lot of this data is off-chain, and there is no way to prove that the off-chain data is completely trustworthy, just like you can’t prove that the price of ETH on certain exchange must be a certain value. Neither a trusted party nor a decentralized network of oracle can generate a price with no arbitrage or OEV at all.
The only way to solve the problem of trustworthy data sources is to go full on-chain prophecy (Uniswap TWAP) in the future when most of the liquidity and economic activity is happening on the chain, not on the exchange, so that the data sources are “crypto-native” and fully trustworthy and verifiable. .
Town Crier uses SGX to ensure that the data processing is credible; Empiric uses contracts on StarkNet to ensure that the data processing and calculation is credible, and the data source sends price data directly to the oracle contract on StarkNet to make it first-hand data, to ensure the credibility of the data source; Redstone’s SmartWeave contracts allow anyone to be a data processor and use Arweave to store price data so that it is trusted and can be verified later; Chainlink uses the Chainlink network’s on-chain aggregation contracts to calculate data results and send them to the blockchain.
Any application that is supposed to be on the chain will eventually be on the chain, thus satisfying the transparent, verifiable, permissionless, decentralized nature of the blockchain.
A fully on-chain oracle will completely solve the problem of data sources and data processing and feeding, allowing DeFi applications to bring freedom of economic activity to all.
TWAP is an oracle from Uniswap. Its data source comes entirely from the Uniswap protocol’s own trading data. The data is obtained and processed entirely on chain. Developers can use Uniswap TWAP directly on chain for token price calculations.
The principle of TWAP is based on the token price at the last tx of each block, combined with the block time, to calculate the sum of the price of a token over the entire history of the protocol, so that an average price can be calculated when the oracle is used.
The reason for using the price at the last tx is to make the attacker’s cost of attack unpredictable, thus increasing the oracle’s security. This is because even if an attacker controls the price at the last transaction of a block, he cannot predict the information such as the ordering of the related activities in the next block. According to on-chain analysis, this kind of multi-block attack has not happened yet. (Spoiler alert, in PoS, it doesn’t seem to be the same).
The time variable is added to further increase the cost of the attack, and to maintain the overall stability and security of the price by sacrificing the reflection of the immediate price on the TWAP price.
V2 TWAP can be used by directly getting the total price change over a time period and dividing it by a set time period t to get an average price as the token price. At regular intervals (not necessarily t, you can use the sliding window algorithm, which has a smaller delay on price change), the price is retrieved for the latest time period.
For TWAP, the longer the time parameter, the slower the updates, but the higher the security, since the cost of price manipulation is essentially the overhead of arbitrage and the gas of sending transactions on each block during the time interval.
V2 uses the total price (price * time) in the time period, V3 uses the total tick (tick * time) in the time period.
In V2 we mentioned the need to re-fetch prices every so often, which may require the involvement of a Keeper, Uniswap V3 solves this problem.
V3 stores block timestamps and total ticks directly in an array of definable length (depending on demand and network timestamp behavior), which is updated when swapping and other interactions happen to the contract, without the need for active trigger from the Keeper.
In addition, you need to convert the tick to a price when using it, which is a little harder to use than V2.
If TWAP works so well, is so trustworthy and verifiable, and is completely decentralized, then why is Chainlink so widely adopted?
The motivation for writing this article was actually seeing someone on Twitter say that Euler Finance’s switching from TWAP to Chainlink is an upgrade (note the person’s ID… ==).
He claims that TWAP is very insecure because in PoS attacker can perform multi-block oracle manipulation, which is actually completely solvable.
In contrast, I think the advantages of TWAP being fully decentralized and fully on-chain are much better than Chainlink, and in the long run, if there are no significant differences in application demand (e.g. you want to move weather data to the chain), then TWAP is the best choice.
A comparison of TWAP and Chainlink:
TWAP is being crushed across the board, but I personally believe that decentralization and security are the leading 1, and the other factors are the trailing 0. Completely on-chain is a trend. Anyone can make a smart contract platform that is very much faster, cheaper, and supports more programming languages than Ethereum, but it can’t kill Ethereum.
The problem of attacks on TWAP oracle in PoS networks, as described by ChainLinkGod, has also been considered by Uniswap engineers and Euler Finance’s engineers.
In PoS, since the block producer is more predictable, it is easier to perform multi-block attacks in the following ways combined:
Validators with large stakes may be assigned blocks consecutively
Private tx sent via Flashbot
Multi-block bundle
In the case of PoW and PoS, TWAP for a 30 minute time window (144 blocks) for the V3 ETH/USDC pair, the following costs are required to manipulate the price to cause 30% volatility:
PoW: $23.7 trillion
PoS (with 2 blocks in a continuous control window): $23.7 trillion
PoS (with 3 blocks in a continuous control window): $9.5 billion
PoS (with 5 blocks in a continuous control window): $103 million
The more blocks under control, the significantly lower the cost of manipulation, so what’s the solution?
A temporary solution to the risk of manipulation of TWAP after PoS would be:
choose a larger time window
choose a pool with better liquidity.
A complete solution to the manipulation risk of TWAP after PoS is:
This would require the manipulator to control more than half of the blocks in order to manipulate the price, compared to the case above, which would require controlling 73 blocks, a number that should be too large to type.
I think in the future, a perfect “oracle” is needed:
Fully verifiable data sources from the blockchain (then it should be based on TWAP), and support for multi-chain.
Data processing and processing via ZK or full on-chain trusted computing.
But these may require dealing with the following existing or emerging glitches:
On-chain data for variety, precision, and timeliness (of course, Chainlink and others have the same problem of price delays)
Complete solution to TWAP data source price manipulation (deeper pools, larger windows, use median instead of average)
Elimination of trust shortcomings across the oracle (multi-sig? Nakamoto coefficient? Unreliable Fisherman mechanism?)
Cross-chain access and feeding of data, and trusted transmission of data on the chain in multi-chain scenarios
Data source diversity (e.g., using only Uniswap V2 or V3 is not good)
Keeper execution in trusted environment (if keepers needed)
I believe that in the future, more and more economic activities will take place on the chain, more and more price data and transaction pairs will exist on DEX, Uniswap will be able to provide a better TWAP, and there will be other solutions to achieve my vision of a perfect oracle based on TWAP, and eventually a 100% decentralized financial system.
0:
1b:
2:
https://docs.uniswap.org/protocol/V2/concepts/core-concepts/oracles
Incentive mechanisms are central to the functionality of permissionless blockchains: they incentivize participants to run and secure the underlying consensus protocol. Designing incentive-compatible incentive mechanisms is notoriously challenging, however. As a result, most public blockchains today use incentive mechanisms whose security properties are poorly understood and largely untested.
3:
本文主要介绍被广泛使用的一种链上预言机 TWAP（时间加权平均价格）
4:
UniswapV3的预言机解决了UniswapV2预言机需要额外维护TWAP更新的缺陷问题。
5:
Euler v2 is the credit layer of onchain finance. Modular by design, it empowers builders to create vaults that collateralise almost any kind of digital asset. This launch represents a pivotal moment in DeFi. With Euler v2, the possibilities for lending, borrowing, and building are endless.
The announcement of Uniswap V3 has given rise to various questions regarding how Uniswap's Time Weighted Average Price (TWAP) oracles...
6:
Recently there have been concerns raised about the long-term security of Time-Weighted Average Price (TWAP) oracles as implemented by Uniswap, especially related to the Proof of Stake transition and more sophisticated MEV capabilities. I've been working on a new price oracle implementation that computes the median price during a specified window of time.
7:
Why Chainlink's "Explicit Staking" is One of the Most Half-Baked Ideas in the History of Cryptoeconomic Design
Blockchains have two sources of data: on-chain data (e.g. the amount of ETH held by an address), and off-chain data (e.g. the current price of ETH on the exchange). To get the latter, the oracle needs to tell this data to the smart contract.
Why does the Internet also need to have “offline” data, but doesn’t have the oracle problem? Because data on the blockchain needs to be secured, so the data uploaded to the oracle needs to be trusted, whereas data on the Internet (Web2) is inherently centralized.
The oracle needs to solve the trust problem from data source to processing and feeding, not usually the problem of the data itself.
The trust problem of the oracle consists of data source and data processing and feeding, and the following solutions are available for each of them:
I think the most important point of the oracle’s trust issue is the trustworthiness of the data source, but a lot of this data is off-chain, and there is no way to prove that the off-chain data is completely trustworthy, just like you can’t prove that the price of ETH on certain exchange must be a certain value. Neither a trusted party nor a decentralized network of oracle can generate a price with no arbitrage or OEV at all.
The only way to solve the problem of trustworthy data sources is to go full on-chain prophecy (Uniswap TWAP) in the future when most of the liquidity and economic activity is happening on the chain, not on the exchange, so that the data sources are “crypto-native” and fully trustworthy and verifiable. .
Town Crier uses SGX to ensure that the data processing is credible; Empiric uses contracts on StarkNet to ensure that the data processing and calculation is credible, and the data source sends price data directly to the oracle contract on StarkNet to make it first-hand data, to ensure the credibility of the data source; Redstone’s SmartWeave contracts allow anyone to be a data processor and use Arweave to store price data so that it is trusted and can be verified later; Chainlink uses the Chainlink network’s on-chain aggregation contracts to calculate data results and send them to the blockchain.
Any application that is supposed to be on the chain will eventually be on the chain, thus satisfying the transparent, verifiable, permissionless, decentralized nature of the blockchain.
A fully on-chain oracle will completely solve the problem of data sources and data processing and feeding, allowing DeFi applications to bring freedom of economic activity to all.
TWAP is an oracle from Uniswap. Its data source comes entirely from the Uniswap protocol’s own trading data. The data is obtained and processed entirely on chain. Developers can use Uniswap TWAP directly on chain for token price calculations.
The principle of TWAP is based on the token price at the last tx of each block, combined with the block time, to calculate the sum of the price of a token over the entire history of the protocol, so that an average price can be calculated when the oracle is used.
The reason for using the price at the last tx is to make the attacker’s cost of attack unpredictable, thus increasing the oracle’s security. This is because even if an attacker controls the price at the last transaction of a block, he cannot predict the information such as the ordering of the related activities in the next block. According to on-chain analysis, this kind of multi-block attack has not happened yet. (Spoiler alert, in PoS, it doesn’t seem to be the same).
The time variable is added to further increase the cost of the attack, and to maintain the overall stability and security of the price by sacrificing the reflection of the immediate price on the TWAP price.
V2 TWAP can be used by directly getting the total price change over a time period and dividing it by a set time period t to get an average price as the token price. At regular intervals (not necessarily t, you can use the sliding window algorithm, which has a smaller delay on price change), the price is retrieved for the latest time period.
For TWAP, the longer the time parameter, the slower the updates, but the higher the security, since the cost of price manipulation is essentially the overhead of arbitrage and the gas of sending transactions on each block during the time interval.
V2 uses the total price (price * time) in the time period, V3 uses the total tick (tick * time) in the time period.
In V2 we mentioned the need to re-fetch prices every so often, which may require the involvement of a Keeper, Uniswap V3 solves this problem.
V3 stores block timestamps and total ticks directly in an array of definable length (depending on demand and network timestamp behavior), which is updated when swapping and other interactions happen to the contract, without the need for active trigger from the Keeper.
In addition, you need to convert the tick to a price when using it, which is a little harder to use than V2.
If TWAP works so well, is so trustworthy and verifiable, and is completely decentralized, then why is Chainlink so widely adopted?
The motivation for writing this article was actually seeing someone on Twitter say that Euler Finance’s switching from TWAP to Chainlink is an upgrade (note the person’s ID… ==).
He claims that TWAP is very insecure because in PoS attacker can perform multi-block oracle manipulation, which is actually completely solvable.
In contrast, I think the advantages of TWAP being fully decentralized and fully on-chain are much better than Chainlink, and in the long run, if there are no significant differences in application demand (e.g. you want to move weather data to the chain), then TWAP is the best choice.
A comparison of TWAP and Chainlink:
TWAP is being crushed across the board, but I personally believe that decentralization and security are the leading 1, and the other factors are the trailing 0. Completely on-chain is a trend. Anyone can make a smart contract platform that is very much faster, cheaper, and supports more programming languages than Ethereum, but it can’t kill Ethereum.
The problem of attacks on TWAP oracle in PoS networks, as described by ChainLinkGod, has also been considered by Uniswap engineers and Euler Finance’s engineers.
In PoS, since the block producer is more predictable, it is easier to perform multi-block attacks in the following ways combined:
Validators with large stakes may be assigned blocks consecutively
Private tx sent via Flashbot
Multi-block bundle
In the case of PoW and PoS, TWAP for a 30 minute time window (144 blocks) for the V3 ETH/USDC pair, the following costs are required to manipulate the price to cause 30% volatility:
PoW: $23.7 trillion
PoS (with 2 blocks in a continuous control window): $23.7 trillion
PoS (with 3 blocks in a continuous control window): $9.5 billion
PoS (with 5 blocks in a continuous control window): $103 million
The more blocks under control, the significantly lower the cost of manipulation, so what’s the solution?
A temporary solution to the risk of manipulation of TWAP after PoS would be:
choose a larger time window
choose a pool with better liquidity.
A complete solution to the manipulation risk of TWAP after PoS is:
This would require the manipulator to control more than half of the blocks in order to manipulate the price, compared to the case above, which would require controlling 73 blocks, a number that should be too large to type.
I think in the future, a perfect “oracle” is needed:
Fully verifiable data sources from the blockchain (then it should be based on TWAP), and support for multi-chain.
Data processing and processing via ZK or full on-chain trusted computing.
But these may require dealing with the following existing or emerging glitches:
On-chain data for variety, precision, and timeliness (of course, Chainlink and others have the same problem of price delays)
Complete solution to TWAP data source price manipulation (deeper pools, larger windows, use median instead of average)
Elimination of trust shortcomings across the oracle (multi-sig? Nakamoto coefficient? Unreliable Fisherman mechanism?)
Cross-chain access and feeding of data, and trusted transmission of data on the chain in multi-chain scenarios
Data source diversity (e.g., using only Uniswap V2 or V3 is not good)
Keeper execution in trusted environment (if keepers needed)
I believe that in the future, more and more economic activities will take place on the chain, more and more price data and transaction pairs will exist on DEX, Uniswap will be able to provide a better TWAP, and there will be other solutions to achieve my vision of a perfect oracle based on TWAP, and eventually a 100% decentralized financial system.
0:
1b:
2:
https://docs.uniswap.org/protocol/V2/concepts/core-concepts/oracles
Incentive mechanisms are central to the functionality of permissionless blockchains: they incentivize participants to run and secure the underlying consensus protocol. Designing incentive-compatible incentive mechanisms is notoriously challenging, however. As a result, most public blockchains today use incentive mechanisms whose security properties are poorly understood and largely untested.
3:
本文主要介绍被广泛使用的一种链上预言机 TWAP（时间加权平均价格）
4:
UniswapV3的预言机解决了UniswapV2预言机需要额外维护TWAP更新的缺陷问题。
5:
Euler v2 is the credit layer of onchain finance. Modular by design, it empowers builders to create vaults that collateralise almost any kind of digital asset. This launch represents a pivotal moment in DeFi. With Euler v2, the possibilities for lending, borrowing, and building are endless.
The announcement of Uniswap V3 has given rise to various questions regarding how Uniswap's Time Weighted Average Price (TWAP) oracles...
6:
Recently there have been concerns raised about the long-term security of Time-Weighted Average Price (TWAP) oracles as implemented by Uniswap, especially related to the Proof of Stake transition and more sophisticated MEV capabilities. I've been working on a new price oracle implementation that computes the median price during a specified window of time.
7:
Why Chainlink's "Explicit Staking" is One of the Most Half-Baked Ideas in the History of Cryptoeconomic Design
No activity yet