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

Fetch and instrument block timestamp #83

Merged
merged 10 commits into from
May 29, 2024
Merged

Fetch and instrument block timestamp #83

merged 10 commits into from
May 29, 2024

Conversation

thpani
Copy link
Collaborator

@thpani thpani commented May 29, 2024

Fetch and instrument the block timestamp, which is available in Soroban as env.ledger().timestamp().

Also modifies and moves around some e2e test assets, to match the repository after running npm run e2e. This is the result of (a) including time stamps and (b) writing back the verification result in verify.

Finally I'm moving an rmSync() call to keep the JSON TLA+ for debugging purposes, in case Apalache fails.

thpani added 9 commits May 29, 2024 14:31
Now that `verify` writes back the verification result,
this would duplicate the entry. Thus, we have to store it
under its contract address from the beginning.
It's formatted this way by e2e `verify` writing back
the verification result.
@thpani thpani requested review from konnov and Kukovec May 29, 2024 15:13
@thpani thpani self-assigned this May 29, 2024
Copy link
Collaborator

@Kukovec Kukovec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

// https://docs.rs/soroban-sdk/latest/soroban_sdk/ledger/struct.Ledger.html#method.timestamp
// according to [this](https://stellar.stackexchange.com/questions/1852/transaction-created-at-and-ledger-close-time),
// the transaction object's `created_at` equals the ledger's `closed_at`.
const timestamp = new Date(op.created_at).getTime() / 1000
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the /1000 here? I understand that it says here that the time is given in seconds, but in a degenerate case it could happen that Date(t1).getTime() and Date(t2).getTime() are different in ms units but same in s units due to truncation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Horizon only gives us seconds precision, it's just that Date (which we use for parsing) internally represents milliseconds.

We could leave it as milliseconds here, but I think it's preferable to have parity between the spec and the contract code (in case there are any constants).

I agree though that this looks confusing. I'll add a comment for clarification.

@thpani thpani merged commit 0b65de4 into main May 29, 2024
3 checks passed
@thpani thpani deleted the th/timestamp branch May 29, 2024 18:53
@konnov konnov added this to the M1: Transaction extractor milestone Jun 19, 2024
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 this pull request may close these issues.

3 participants