Today we’re excited to introduce our third precompile that connects WeaveVM and Arweave: a way to access WeaveVM historical blocks from Arweave from inside WeaveVM smart contracts.
Before diving in: the state of accessing historical blocks in EVMs
Ethereum’s smart contracts, by design, depend on third-party data sources to access historical data due to the “BLOCKHASH” operation in the Ethereum Virtual Machine (EVM).
Ethereum’s contract API gives access only to the most recent 256 blocks (last 3072 seconds of chain history access equivalent to 51.2 minutes, based onEthereum’s 12-second block time). This makes it hard and expensive for contracts to verify data or an event from the chain’s history. Though it isn’t impossible, it forces reliance on oracles or other centralized third party proxy solutions(oracles, indexers, archive nodes).
WeaveVM’s approach for native historical block data access
WeaveVM has an advantage in this case because all of its block data is archived permanently on Arweave through its ExEx pipeline. Therefore, in our case, we have an open and permanent data lake of permanent WeaveVM block data.
However, this block data in Arweave exists in a serialized and compressed form (using Borsh and Brotli respectively).
So now as we have permanent records of our data on Arweave in a specific encoding pattern, we need WeaveVM to natively access this data and make it accessible in the contract API through a custom precompile with a compatible block structure interface.
Introducing Precompile 0x20 – access to historical block data
WeaveVM’s 0x20 precompile lets smart contract developers not access only the most recent 256 blocks, but any block data starting at genesis. To explain how to request block data using the 0x20 precompile, here is a code example:
As you can see, for the query variable we have three “parameters” separated by a semicolon ”;”
- An Arweave gateway (optional and fallback to arweave.net if not provided): https://ar-io.dev
- WeaveVM’s block number to fetch, target block: 141550
- The field of the block struct to access, in this case: hash
Only the gateway is an optional parameter, and regarding the field of the block struct to access, here is the Block struct that the 0x20 precompile uses:
Precompile 0x20 status
The precompile 0x20 is currently supported from Devnet 0.2.0 and further. Merging it into Alphanet won’t take place until further testing and as we are looking into a more elegant and friendlier developer experience for importing the Block struct as a solidity interface without needing to provide the field for every block request. Check out the 0x20 source code here
Usage example of 0x20 precompile
The 0x20 precompile enables dApp developers to build applications that don’t rely on oracles or archival nodes to access data stored off-chain. As a dApp developer, here’s how 0x20 can be used:
- Identity (onchain reputation services): Track user activity over extended periods, enabling more comprehensive scoring systems.
- Governance (enhanced governance platforms): Provide deeper historical context for proposals and voting mechanisms, fully onchain.
- Merkle-tree-less Airdrops (transparent token distributions): Enable direct on-chain verification of past interactions or holdings for airdrops.
- onchain data intensive dApps (on-chain Dune): embed data intensive analytics in smart contracts without relying on third parties to access historical data.
- Fully onchain gamefi (peristent onchain state): develop games with long-term player progression and historical elements, fully onchain.
Conclusion
With our set of custom precompiles so far, we are introducing new native ways for EVM to interface with Arweave and take advantage of its permanent data features. Today with our Vol.3 of WeaveVM Precompiles we unlocked for the first time, the solution to access historical blocks using Arweave as a data archive. If you find this solution useful and can make use of it, don’t hesitate to contact us and to start building on WeaveVM!