Introducing Fossil
We are excited to announce Fossil (previously known as the Starknet L2 Storage Verifier) as the latest additions to Oiler Network’s suite of products!
What is Fossil?
Fossil is a set of smart contracts on both Starknet and Ethereum L1 that allow Starknet smart contracts to read anything ever committed to Ethereum L1 and any of it’s EVM based L2s. Yes you read that right! Fossil is able to read data from Optimism, Polygon and other L2s on Starknet.
The key advantage of using Fossil over other solutions like oracles is that its security is equal to the security of the L2 (Starknet) itself. This is a game-changer!
Another advantage of Fossil is that it minimises the amount of required L1 messages, making it possible to read larger amounts of data for much cheaper.
What data can be read using Fossil?
Using Fossil, you can read Ethereum historical data such as:
State
State this broad term includes:
- Smart contracts storage, like ERC20 balances
- Accounts nonces
- Accounts ETH balances
- Smart contracts code hashes
Logs
The ability to access logs allows contracts on Starknet to check whether a transaction on Ethereum emitted an event, for example an ERC20 transfer.
Receipts
Since Fossil is able to retrieve logs which are part of transaction receipts, we are also able to access other information found in these receipts (how much gas a specific tx used, it’s index in the block, etc…)
Transactions
Fossil is able to read transactions in any block including all their properties such as:
- GasLimit
- GasPrice
- BaseFee
- PriorityFee
- Calldata
- To
Block headers
Another set of data which is particularly easy to access on Starknet using fossil is the block header, from the block header we can read the block parameters like:
- BaseFee
- Difficulty
- Miner
- Timestamp
- Block number
- GasUsed
- Uncles hash
And many other parameters.
EVM accessible data
When building anything on top of an EVM chain you are limited to the current state. This is a problem because you cannot directly access historical state, consequently, you cannot directly retrieve information about past transactions found in a specific block, as well as past receipts or even past ERC20 balances.
Reading anything from the block header, which is not the hash of the block itself, is limited only to the current (latest) block. Given these limitations, any developer willing to access any of that data is limited to the last 256 blocks. Accessing data in this manner is not optimal as it requires verifying Merkle Patricia proofs, which is expensive to run on ethereum.
Due to this, developers must rely on keepers or oracles if they want to access historical data or computed historical data such as volatility.
Keepers are external actors who are incentivesed to perform a certain action required by a DeFi protocol, an example of such action can be taking a snapshot of the price of the protocol token.
The concept of keepers is secure however keepers are not the best solution for computing TWAPs and taking snapshots of data as the amount of samples is limited by the gas feasibility of such action, making the protocol that uses keepers in such way less secure.
Oracles on the other hand are meant provide data that is not accessible on the chain itself like CEX prices and volumes. However due to the limitations of the EVM, oracles are also commonly used to provide data about the chain itself.
Oracles are oftentimes the most vulnerable part of any protocol. Due to this, we deeply believe that data that was ever present onchain should not be accessed using oracles as it introduces unnecessary risk.
Fortunately, verifying Merkle Patricia proofs is uncomperably cheaper on Starknet and Fossil takes advantage of this! By leveraging the capabilities of STARKs and StarkNet, it is now possible to access historical onchain data without the use of keepers or oracles.
How does Fossil work?
StarkNet allows sending messages from L1 to its L2, the Fossil L1 contracts builds a payload which is the hash of the latest re-org safe block and sends it to L2.
Given this hash on L2, Fossil is able to re-create the entire block header by providing the RLP serialised header, then hash it, and compare it to the original hash. If the hashes match, then the header is valid.
Now, this RLP header contains some crucial elements:
- parent hash -> Allows you to repeat the procedure above and recreate the parent block all the way up to genesis.
- state root -> The root of the Ethereum mainnet Merkle Patricia tree, which means we can access data about accounts and their storage.
- Transactions Root ->Allows us to prove that some transactions were included in the block.
- Receipts root -> Allows us to prove that the execution of a specific transaction, resulted in a specific receipt.
- Basefee
- Difficulty
- GasUsed
- Block number
- Block timestamp
Now, combining all these things together, we optimised Fossil in a way which also allows to compute TWAPs of:
- Base fee
- Gas used
- Difficulty
What can be built with Fossil?
As mentioned many times Fossil allows to recreate historical and recent data from ethereum L1.
Before we describe usecases let’s categorise them by which Fossil feature they use.
State access
Using this feature a dApp can access it’s users L1 token balances in order to allow them to perform certain action. For example, voting.
Another great usecase of Fossil state access is calculating Uniswap V2 TWAPs. A great innovation of Uniswap V3 was the introduction of TWAPs which made the price manipulation cost much much higher because of averaging. However using Fossil we can simply access Uniswap V2 prices across many blocks and compute the TWAP!
Block header parameters
The ability to access parameters from the block header allows developers to compute things like basefee, difficulty TWAPs, volatility and much more!
For this reason, Fossil can be used to settle derivatives, provide volatility information for pricing models etc…
Receipts
As mentioned before, transactions receipts include logs. This is valuable because we could use the log data to build an Ethereum<>Starknet bridge for ERC20 tokens which does not require approving the tokens first. This is because the L2 side of the bridge will only need to check that the tokens have been transferred to a correct address.
Transactions receipts are also a valuable source of information about who interacted with which protocol. This means Fossil could be used to airdrop early protocol adopters.
Currently most airdrop eligibility data is extracted by querying the chain and later generating a csv file with all the addresses and rewards to later generate a merkle tree out of it. With Fossil this process can be completely decentralised and transparent. This offloads a huge amount of responsibly from the airdrop organizer and may be an appealing option for DAOs who value transparancy.
API
Using Fossil requires syncing L2 with L1, process blocks by proving their headers and finally generate/verify Merkle Patricia proofs. This is quite complicated and introduces a lot of work for whoever wants to integrate Fossil. We developed the Fossil API to do all of this for you.
The API allows it’s users to specify what kind of data they want to access on starknet ,such data will be made available by the Fossil API service. Once the work is done, a notifying webhook will be sent back with the appropriate L2 calldata.
Please note that the Fossil API is not suited for all use cases, such as governance. This is because it is a centralised service, which will be decentralised in the future.
Using the Fossil API is that it is cheaper than running Fossil on your own because the API,
- Coordinates actions of multiple actors
Leverages Coincidence of Wills situations when multiple users want to fetch same data.
- Supports Request Batching
Bunches different requests from users and asks for the most optimised sync from L1, preforming the minimum amount of necessary computation.
- Supports Job Scheduling
Queues jobs for some time, and then runs a cron job to mutualise cost for all these jobs. Without the API, users would all have to preform the required computation individually.
At this time, the API supports the following actions:
- Proving storage slots and accounts used to process an
eth_call. - Proving past transactions.
- Proving past receipts.
- Computing a TWAP of the following block parameters:
[difficulty, basefee, gasUsed]
Try Fossil Today!
Although we have listed several sample use cases, the reality is that Fossils use cases are endless. Please reach out to us by sending an email to fossil@oiler.network if you are interested in trying the Fossil API, or require assistance with integration.
