Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We need a way to query Era Summaries #144

Open
scarmuega opened this issue Feb 27, 2025 · 3 comments · May be fixed by #147
Open

We need a way to query Era Summaries #144

scarmuega opened this issue Feb 27, 2025 · 3 comments · May be fixed by #147

Comments

@scarmuega
Copy link
Member

We need an endpoint that allows a user to query the history of eras and param changes (maybe just a subset) across the history of time. Similar to what BF has here: https://docs.blockfrost.io/#tag/cardano--network/GET/network/eras

@Mercurial
Copy link
Contributor

Mercurial commented Feb 27, 2025

So we might need a query aswell to get protocol params by epoch / era not only the summary because tx validate for older @scarmuega

@SebastienGllmt
Copy link

SebastienGllmt commented Mar 17, 2025

I agree with this because timestamps aren't available in any of the tx/block information in utxorpc, and you can't infer the timestamp based on the slot information along using just utxorpc without being able to get the era summaries

You can't even get the timestamp from the genesis blocks because the genesis blocks only give you the following fields

byron

{
    "startTime": 1506203091,
    "blockVersionData": {
        "slotDuration": "20000",
    }
}

shelley

{
  "activeSlotsCoeff": 0.05,
  "epochLength": 432000,
  "slotLength": 1,
  "systemStart": "2017-09-23T21:44:51Z",
}

which doesn't give you a way to know when the Shelley hardfork happened (which we need to know so that we can change the timestamp calculation logic at the right time)

@SebastienGllmt
Copy link

SebastienGllmt commented Mar 24, 2025

It would be nice if the era summary also contains the starting slot & hash of the first block of that era, that way it can be used as a ChainPoint

it might not be possible to support that though depending on the goal of this endpoint:

  1. If the era summary endpoint should let you know about eras before they even happen (ex: when the hardfork is scheduled to happen in the next epoch)
  2. If the era summary endpoint should only let you know about eras that have already started

If (1), then we can't know the ChainPoint (since it hasn't happened yet). They could be optional fields only returned if the era change has gone through

Note: some time travel is already required for the end field that specifies the end of an era

@SebastienGllmt SebastienGllmt linked a pull request Mar 24, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants