eth2 0.0.5

Getting started

import trio
from eth2.models import lighthouse
from eth2.core import ContentType
from eth2.providers.http import Eth2HttpClient, Eth2HttpOptions

async def start():
    # Customize this to use your Beacon endpoint
    address = 'http://localhost:4000'
    # Optionally bring in your own HTTP client
    # async with httpx.AsyncClient() as client:
    #     prov = Eth2HttpProvider(client, options=Eth2HttpOptions(api_base_url=address))
    async with Eth2HttpClient(options=Eth2HttpOptions(
            api_base_url=address,
            default_req_type=ContentType.json,
            default_resp_type=ContentType.ssz)) as prov:
        # The provider can be extended with any API model.
        await fun(prov.extended_api(lighthouse.Eth2API))
    print("done!")

trio.run(start)

Using the API model

from eth2.models.lighthouse import Eth2API

async def fun(api: Eth2API):
    print("fetching state!")
    data = await api.beacon.state(slot=spec.Slot(1))
    print(data.beacon_state.eth1_data)

    # Much faster than retrieving full state!
    head = await api.beacon.head()
    print(f"finalized: {head.finalized_block_root.hex()} {head.finalized_slot}")

    enr = await api.network.enr()
    print(enr)

    # Will error, the slashing is invalid, two equal headers (and no signatures ofc)
    await api.beacon.post_proposer_slashing(spec.ProposerSlashing())

Advanced API calls

When you need to tweak individual API call settings

from eth2.core import ContentType, APIEndpointFn
from eth2.models.lighthouse import Eth2API, APIState

async def advanced(api: Eth2API):
    # Make a copy of the callable function, to then change its settings
    fn = APIEndpointFn(api.beacon.state)
    fn.resp_type = ContentType.json  # Instead of default ssz, because why not

    # The most inefficient way to retrieve finalized checkpoint.
    # Full state, as json.
    # But hey, access any data, and process with the spec as you like.
    data: APIState = await fn(slot=spec.Slot(300))
    print(data.beacon_state.finalized_checkpoint)

Defining custom models

The HTTP provider can “learn” how to use a model of routes, on the fly! No need to hardcode any API calls. Just define the model as a Pytho 3.8 Protocol. The Eth2 API provider will shadow this model with an implementation.

• Any Protocol class with annotations can be interpreted as route model. Fields are sub-routes.

• api() decorator to make function calls usable endpoints. Customize endpoint options if you need.

• var_path() decorator to make function calls construct dynamic paths

Currently the Lighthouse API model is well supported, and the new standard-API is being experimented with, but incomplete.