TL;DR
-
The recent release of shadow event and ERC-7571 triggers controversy.
-
Some people think shadow event is nice because its advantages in saving costs, and offering better developer experience by dropping onchain events on mainnet.
-
Some people consider shadow event as “a dangerous experiment”, mainly due to its verifiability and decentralization issues compared to its alternatives and the existing way developers deal with onchain event.
0. Solidity event
Solidity events give an abstraction on top of the EVM’s logging functionality.
event facilitates communication between smart contracts and their user interfaces (eg. website of a decentralized application).
It is commonly used in smart contract development as:
-
A way to return values for the user interface from smart contracts
-
A way to asynchronous trigger with data
-
A cheaper form of storage (on Ethereum)
They are indexer-friendly (including indexing protocols, dashboards, and aggregators) and useful for applications for these reasons.
Read more about Ethereum event and log here: 1, 2, 3, 4.
1. Recent Debate on event
a) Shadow Event
A gasless event, logged on an offchain execution environment that mirrors mainnet state in real time.
Back in Dec 26, 2022, Dan Robinson tweeted about the phantom events concept and pleaded “Somebody please build an indexer that lets a user insert “phantom events” into any contract on-chain, written in Solidity”. Shadow.xyz (previously called trymetro.xyz/shadow) commented in the chat, then further built Shadow.xyz as Paradigm EIR.
Shadow event works like this: you have a mirror of mainnet, but custom event logic that only triggers the events and data pipelines on the mirrored chain (shadow network) instead of having to pay for calldata and execution on the mainnet EVM. Simply put, you save money by not having event on mainnet production for indexing and gas, but have them with a mirrored mainnet.
b) ERC-7571
Besides releasing shadow event, Shadow proposed ERC-7571, a specification for shadow events – extra event logs in contract code that should only be generated in an offchain execution environment.
ERC-7571 further spreads the concept and use case of shadow event.
c) Controversy
On the surface, shadow events help developers and users save money on mainnet event data, and also help events exist in a more flexible form. However, there are opposite views.
For ERC-7571, some people believes it is more like a compiler change, “there's no reason to create an ERC for a language feature, that discussion belongs in whatever venue the language has for discussing changes”, and prefer “propose something more general purpose like config flags”. As a record, high_byte also proposed something similar (offchain keyword) to Solidity 2 years ago.
We'll cover the arguments for and against shadow events in more detail later in this article.
2. "Stop Using Onchain event"
Stop using onchain event, use shadow event.
a) event on Ethereum Mainnet is expensive.
Austin Adams from Uniswap Labs expresses that “computation done on the logs, which makes them somewhat costly” and “Uniswap v3 users have spent over $20m on events” which is “5-6% of total gas fees”. These additional costs of event are essentially left to the user. Hasu from Flashbots described this approach as a “10x savings on cost”. And Joseph from Astaria said this will be definitely used for the product for saving user gas.
Doug Colkitt from Ambient Finance shares the same opinion “Event logging has cumulatively cost Ethereum users tens of millions in unnecessary gas costs”.
David Mihal takes “on-chain Twitter from PeepEth” as an example, showed that “it (event) 'll eventually get pushed off-chain”.
b) event may not be “truth” for applications.
According to a clear definition given by bartek from L2Beat, event is not really a truth as the data source for onchain applications, but rather a dev-defined interpretation of smart contract behavior. The “real truth data” is tx traces and storage diffs.
Other claims support that event data is not truth data:
To summarize, event is developer-friendly, but not 100% trustless data, so we should reduce our reliance on it onchain.
c) Shadow event enables better developer experience.
Shadow event related platform, shadow.xyz, serves as a developer infrastructure that enables a better development experience for not only smart contract developers, but also data analysts:
-
Smart Contract Developers: Save gas as mentioned before, and attract more usage based on this.
-
Data Analysts: Allow for third-party edit-mode that is flexible and can be changed after deploy as new data requirements emerge.
-
Funds: Quickly write logs to measure traction on chain across sectors.
Overall, the shadow event design pattern fulfills a long-standing need to make development and data analysis easier.
3. "Keep Using Onchain event"
Keep the existing way of using event, use shadow event but not shadow’s way.
In response to these arguments, I have also observed a great deal of opposition to shadow events, arguing that the cost savings are not enough to cover the sacrifices in verifiability and decentralization. Some alternatives to shadow events have been proposed by developers, who have also expressed their support for event-driven development.
a) Cost is not an real issue.
Although "not including onchain events in production saves gas", this is only valuable enough in L1. For each Uniswap v3 transaction in L1 (based on my napkin math), not using an event saves about a dollar. In L2, these costs are almost negligible (~0.002 USD). Not nearly as much as the potential benefits of including them (cross-chain, data analytics).
Beyond that, a 5% cost savings is not really that big of a savings for each transaction. Only for protocols with a huge number of interactions, such as Uniswap, will the overhead be measured in the millions or tens of millions.
In addition, LefterisJP believes that these savings (in the form of hosting costs) will always be pushed to the user.
b) Verifiability and decentralization are sacrificed.
One of the strongest reactions from the community has been the potential impact on verifiability and decentralization of using shadow events instead of onchain events, as well as the trend of sacrificing these characteristics of blockchain.
Infrastructure needs to be decentralized and open-sourced.
-
Opinion says infrastructure such as Shadow.xyz costs too much and is hosted by Shadow themselves only, and there’s no open-source code to self-host and is not fully ready to be standardized as ERC.
-
The introduction of shadow event adds up even more required infrastructure.
-
A closed source provider making the underdeveloped indexing landscape even more of an atrocity.
Moving event offchain makes verifying harder.
-
For Defillama, It'll be impossible for users to run their adapters and verify the numbers.
-
The users pay gas in a decentralized manner so that they can later see their data in any dapp they want to use and “move everything off chain” which only makes user’s life harder.
The trend of moving everything offchain may be a huge step backwards.
-
Shadow event’s aim is to push the ecosystem towards completely moving all log data offchain.
-
Shadow event sets a bad precedent for optimising on-chain code with compromising immutability and censorship resistance for the optimisation of computing and analytics.
c) We have existing ways to enable similar effect to shadow event.
Using shadow.xyz based shadow event may have the above problems. Developers actually have alternatives to achieve the same effect without having to worry about centralization and verifiability issues, but can achieve the key features of saving gas and facilitating debugging.
Achieve Shadow Event with Indexer
The use of event and better event related toolings is all about the indexer.
GhostLogs is an alternative to Shadow.xyz. MakerDAO implemented a similar indexing solution to achieve shadow event effect in 2017. Mudit Gupta from Polygon proposed a better indexing approach in 2022. brock from nascent also built something similar called soldexer.
Debug with Shadow Event with Language Level Tricks
Shadow event / block can be implemented at the language level by adding a few statements when testing the contract.
These features are requested for Solidity and Vyper compiler (1, 2), and can be extended to other languages.
Debug with Shadow Event with Features in Toolkit
Shadow events can be implemented in the Forge with some extra code. Only 4 lines of code (if contract is not a proxy use vm.etch() instead of vm.store()).
d) We love using onchain event.
Last but not least, developers love using onchain event.
“not onchain, not consensus, not truth”.
4. What may happen next?
At HyperOracle, we decided early on to focus on making event data trustless. Our initial version of zkOracle implemented trustless historical access and compute for event data. The main reason for this decision was that we knew that event is a data that developers rely heavily on, and that there was a lack of a source of truth to verifiably put event back into the onchain smart contract.
The Shadow event discussion not only covers dev experience and verifiability, but also user experience (gas cost). It is even highly relevant to the design of Ethereum and EVM itself. This is a discussion on whether to optimize first or decentralize first.
Overall, innovation has been good, and shadow events are a new feature that developers have been waiting for. We hope to see more open source efforts in this. It will be interesting to see if ERC-7571 and shadow event get adopted widely on language-level, and client-level.
About HyperOracle
HyperOracle is a programmable zkOracle protocol that powers smart contracts with arbitrary compute and richer data sources. HyperOracle offers full security and decentralization for trustless automation and onchain AI/ML so builders can easily create next-gen dApps.