Introducing Lodestar Prover
We're excited to introduce the latest addition to our suite—Lodestar Prover, a tool for connecting consensus and execution clients, facilitating seamless and secure blockchain integrations.
A disconnect for dApps?
Within the Ethereum ecosystem, dApps have historically faced a challenge in establishing smooth interactions with execution clients. They depended heavily on service providers, usually called RPC providers, putting all their trust in these external sources.
While dApps can communicate with consensus clients effectively through light clients, the connection between execution clients and dApps has been disjointed. This fragmentation not only stifled the potential for seamless integration but also raised concerns about maintaining trust.
What's the solution?
The Lodestar Prover functions by theoretically building two light clients, one for consensus and one for execution, connecting both to provide a unified trustless communication interface to the Ethereum network. This enhances the integration, communication, and security of dApps.
Think of the Lodestar Prover as an extra safe and secure layer of protection, wrapping snuggly around your existing web3 provider.
What it is:
- It makes network interactions more secure.
- It trustlessly establishes trust with RPC providers.
- It provides offline execution of the RPC calls.
- It acts as a security wrapper for your favorite web3 providers.
What it is not:
- It is not a standalone web3 provider.
- It does not remove dependency on RPC providers (e.g., Infura, Alchemy).
- It is not a full Execution Layer (EL) node.
- It is not an EVM replacement.
How to use it?
In the most straightforward setup, users add a web3 library (like web3.js or ethers.js), then set up an HTTP Provider with a URL pointing to a remote service, like the Lodestar Sepoila RPC, which allows you to connect to an Ethereum network online.
Using this setup, you create a web3 instance that can now handle transactions, look up information on the blockchain, and do more tasks related to Ethereum.
Verified web3 provider
Developers can then integrate Lodestar Prover's verification capabilities into their web3 setup. Users can achieve this configuration by incorporating a few additional lines of code from the Prover library. This step effectively wraps the standard web3 connection with a protective layer that verifies each transaction.
The enhancement doesn't alter the fundamental operation of the web3 setup. Instead, it enriches it by adding a robust verification process. As a result, developers can continue to use their web3 or ethers instances as before, now with the added assurance that their blockchain transactions are being checked and confirmed for authenticity and integrity.
Remember, since transactions are executed in the local EVM (so as not to reflect the impact on the network), users will have to transmit the transactions to the network themselves after verifying the local execution results.
Designed to work with a wide range of tools, Lodestar Prover handles most providers. Whether a developer uses the web3.js library, the ethers library, or any other system for sending and receiving blockchain data—even older ones—they can count on Prover for support.
Run as a proxy server
Beyond direct integration, Lodestar Prover offers the flexibility to run as a proxy server. This setup streamlines dApps' blockchain interactions by channeling them through the proxy server, which then communicates with the Ethereum network.
Developers can easily set this up with a few command-line instructions, defining the network and specifying the service URLs and port numbers. Once operational, the proxy server efficiently handles all RPC communications, ensuring that dApps can interact with the blockchain securely and reliably without needing to connect directly.
Supported methods
As it currently stands, Lodestar Prover offers support for a suite of crucial Ethereum RPC methods integral to blockchain development. For clarity, we can arrange these supported methods into three primary categories: Block, Call & Estimate, and State.
For a complete list of supported methods, check out the Prover ReadMe.
Block
For obtaining block data, it supports methods such as eth_getBlockByHash and eth_getBlockByNumber, enabling developers to retrieve specific block details.
Call & estimate
In the realm of smart contracts, the Lodestar Prover accommodates eth_call for simulatinnovativemart contract executions and eth_estimateGas to forecast the gas costs of transactions.
State
Additionally, for account information queries, it includes eth_getBalance for checking an account's ether balance and eth_getCode for extracting a contract's code.
This range of methods represents Prover's current functionality. We intend to extend this list as the tool evolves.
How does it work?
The process begins within Lodestar Prover's framework as it connects with a provider. Lodestar Prover then recognizes the type of provider and establishes a ProofProvider, embeds and extracts the request handler method, and wraps it with a custom method.
Each time a request is made, the ProofProvider intercepts it, ensuring it gets routed through Lodestar Prover's internal request processor before proceeding. This processor acts as the gatekeeper, scrutinizing every interaction to confirm its validity, thereby fortifying the trustworthiness of every transaction.
Proof-provider/state management
Lodestar Prover manages its state by regularly syncing with a consensus client. It runs a light client, which waits until it gets fully synced up. Execution payloads from the block headers are then fetched and stored to help Lodestar Prover check that transactions are correct.
Sometimes, if the light client lacks all the necessary information, Prover will get more data straight from the execution node. After gathering all the required information, Prover is ready to proceed and process the requests.
Request processing
When Prover receives a JSON-RPC request, it begins by breaking down the request into segments. Each segment gets categorized as either 'blocked', 'unverifiable', or 'verifiable'. Blocked requests are those the provider gets instructed not to process, resulting in a JSON-RPC error response. Unverifiable requests are those that Lodestar Prover cannot confirm alone. These are sent directly to the execution node, where they will fetch the necessary response.
Finally, verifiable requests are those that Lodestar Prover can validate internally, such as 'eth_call"'' or 'eth_getBalance"''. After processing, the responses from each category are combined and sent back to the dApp that made the request.
EVM processing
When Lodestar Prover receives a request for an operation that requires EVM interaction, like an 'eth_call', it starts by generating an access list. This list contains all the storage addresses that the call will interact with. Prover then pulls the data from these addresses and thoroughly verifies it for accuracy. Once verified, this data gets used to update Loadstar Prover's in-memory version of the EVM, ensuring that it reflects the most recent state of the blockchain.
The transaction is executed within this sandboxed environment, allowing Prover to simulate the result without impacting the actual blockchain. This process is crucial for developers who need to test smart contract interactions safely before they get made live, offering a reliable preview of how the transaction would unfold on the blockchain.
Comparing light clients
Lodestar Prover is not the only tool of its kind. Indeed, the community has developed other similar solutions. Tools like Helios offer a Rust-based light client, Kevlar provides a JavaScript-based light client proxy, and Patronum stands out as a JavaScript-based verification provider.
Each of these tools caters to specific needs within the dApp development process. However, Lodestar Prover sets itself apart by combining the capabilities of these varied tools into one seamless package.
Whether developers need to run a proxy, act as a verification provider, or function as a web3 provider, Lodestar Prover can adapt to each role, offering a versatile solution for diverse dApp development scenarios. With Lodestar, developers can choose how they want to integrate these functionalities into their projects, depending on their unique requirements.
What's next?
The team is committed to enhancing Lodestar Prover's capabilities and user experience. Presently supporting a handful of RPC methods, there's an ongoing effort to expand this repertoire, aiming to cover a broader range of blockchain interactions.
A key focus is on performance improvement, explicitly accelerating the in-memory processing of the EVM, which is crucial for developers seeking a more efficient development process. A significant upcoming milestone for Lodestar Prover is its planned integration with MetaMask as an add-on feature. This integration will allow users to test Lodestar Prover easily through MetaMask's snaps feature without any intricate setup.
Further, the team is developing functionality to execute transactions in memory with the option to send them to the network, providing developers more flexibility and control over their transactions. This feature is handy for testing transaction outcomes before committing them to the live network.
Lodestar Prover presented at Light Client Summit
Try Lodestar Prover out yourself! Here.
Contribute to Lodestar! 🌟
At ChainSafe, we constantly seek exceptional talent to join our teams and welcome contributors to the Lodestar consensus client. To any TypeScript developers looking to take on challenges and push the boundaries of the JavaScript ecosystem, get in touch! To get involved, visit our GitHub repository.
If you wish to contact the team, join Chainsafe's Discord in the #lodestar-general channel or explore our job openings page. Alternatively, you can email us at info@chainsafe.io.
Lodestar is built and maintained by ChainSafe.