Skip to content

Latest commit

 

History

History
100 lines (68 loc) · 3.21 KB

light-client.md

File metadata and controls

100 lines (68 loc) · 3.21 KB
section sortOrder label pageName
Get Started
3
Consumable Light Client
light-client

Consumable Light Client

Overview

Traditionally, light clients have been inaccessible to consumers. While EIP-1186 allows end users to receive Merkle Proofs from an Ethereum node, it requires reliance on a trusted state root hash. Stateless APIs, however, provide a method to deliver a verified state root hash to the end user, eliminating the need for trust.

By combining a verified state root hash with an independent proof provider, developers can continue using their existing frameworks to consume data from the Ethereum blockchain without the current trust assumptions.


This combination of a verified state root hash and an independent proof provider allows for developers wishing to consume data from the Ethereum blockchain to continue doing so via their existing frameworks, while eliminating the trust assumptions that currently come with it.

Usage

Regardless if you want to bring your own proofs or use the Stateless network you'll need to create a verified API bucket.


Using the light client approach is nearly identical to consuming the current verified APIs via a bucket as described in the Quickstart section. The same initial steps of creating a bucket still apply.


What needs to be considered when consuming proofs directly through the Stateless API, is that the providers in the bucket should be different from the provider acting as your proof provider.


If you haven't created a bucket, the first step is following the Quickstart to create your initial bucket, which can have between 1 and 3 providers, take note of which ones.


If you already have created a bucket, simply run stateless-cli buckets list to take note of which providers are already in your bucket.

Using Stateless as your Proof Provider

Once you've done that, you'll want to create a second bucket with a single provider that isn't in already in your existing bucket, this is your Proof Provider.


This bucket URL is your proverUrl.

Bring your Own Proof Provider

Otherwise, you're free to bring any RPC resource that offers eth_getProof. Some examples of this include:


  1. A node from another commercial node provider, Infura, Alchemy, etc.
  2. An RPC resource from an indexer layer, Laconic's ipld-eth-server, Subsquid's RPC Proxy, etc.

This RPC URL is your proverUrl

Connecting it to Ethers

Once you have this proverUrl either from Stateless or your own source, using Ethers works identical to the proof source, just with this additional proverUrl parameter in the initialization:


const { ethers } = require("ethers-stateless");

const provider = new ethers.StatelessProvider(
    "your_bucket_url",
    ['https://api.stateless.solutions'],
    1,
    "your_proverUrl"']);

See the Ethers guide for more information about the other parameters.