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

See more eras at any period of time #180

Open
Renegatto opened this issue May 11, 2023 · 2 comments
Open

See more eras at any period of time #180

Renegatto opened this issue May 11, 2023 · 2 comments

Comments

@Renegatto
Copy link

Currently when used for CTL testing, plutip tests are very unstable for time-related dApp domains because observable future is too small.
Epoch and Eras are short, but also there are too few of them.
Txs that should have several minutes of validity range often cannot be constructed because there are no info about the time range end slot in era summaries.

@zmrocze
Copy link
Contributor

zmrocze commented May 13, 2023

Could you please expand on

Txs that should have several minutes of validity range often cannot be constructed because there are no info about the time range end slot in era summaries

for example what are era summaries here?

@Renegatto
Copy link
Author

Renegatto commented May 14, 2023

Could you please expand on

Txs that should have several minutes of validity range often cannot be constructed because there are no info about the time range end slot in era summaries

for example what are era summaries here?

EraSummaries is a CTL datatype.

CTL requesting it from Ogmios via eraSummaries query.

If I understand correctly, it is basically an array of information about known eras, including information about lowest and highest slots and slot length.

An example of a problems I am talking about:

We are doing plutip testing and creating the Tx that need time t0 to get validated. This time from the moment at which we submit Tx ends at slot sB.
However, era summaries knows only about eras 1,2,3, and the highest slot it knows about is s, which is too early. So really we have only t1 time to validate Tx which is not enough.
If we try to submit this Tx which validity interval is [sA;timeToSlot B] we will get an error that Tx cannot be even constructed because it's validity range upper bound is not in any known era.

                    sA                      s
                    |<-----------t1-------->|   sB
                    |<-----------t0---------|-->|
t 0------|---era-1--A-|---era-2--|--era--3--|---B----->

The problem is acute because the known time interval for Plutip is small in absolute units (I didn't measure, but I think it's several minutes), however the time Tx needs to get validated is not that small in comparison to a testnet one.

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

No branches or pull requests

2 participants