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

Consensus: frontend get method should show accepted and finalized contract state #788

Open
kstroobants opened this issue Jan 3, 2025 · 3 comments · May be fixed by #801
Open

Consensus: frontend get method should show accepted and finalized contract state #788

kstroobants opened this issue Jan 3, 2025 · 3 comments · May be fixed by #801
Assignees

Comments

@kstroobants
Copy link
Contributor

-> 1. might be the easiest. Both require a change in GenlayerJS (https://github.com/yeagerai/genlayer-js/blob/d941a8d6342c62916c50246269cf1cc1db471357/src/contracts/actions.ts#L25)

Two options:

  1. Get method does two eth_calls, one for accepted and one for finalized.
    • Frontend does two calls and shows both return values.
    • eth_call contains a flag to choose accepted or finalized state. Put default on accepted so that the write method does not need a flag.
    • _SnapshotView class read method need to select the correct state key based on the given flag.
  2. Get method does one eth_call getting the whole state dictionary.
    • Parsing/decoding needs to be updated in GenlayerJS.
    • Doubt: _SnapshotView class read method will give the whole dictionary but the write method call of the frontend uses the _SnapshotView class read method. So somehow the accepted state from the dictionary needs to be given to the genvm processing and not the whole dictionary.
@kstroobants kstroobants changed the title Consensus: frontend get method shows accepted and finalized contract state Consensus: frontend get method should show accepted and finalized contract state Jan 3, 2025
@kstroobants kstroobants self-assigned this Jan 8, 2025
@cristiam86
Copy link
Collaborator

@kstroobants, we must not change eth_ methods since they need to be compatible with any Ethereum-like node. If this has a different signature, we should create the gen_ specific method

@kstroobants
Copy link
Contributor Author

we must not change eth_ methods since they need to be compatible with any Ethereum-like node. If this has a different signature, we should create the gen_ specific method

The new flag parameter (stateStatus) is part of the params: dict of the def call() of the eth_call RPC method. How is this different than the leaderOnly parameter given to eth_sendRawTransaction?

See PR #801

@cristiam86
Copy link
Collaborator

how we send the transactions is going to change so the leaderOnly feature needs a workaround. We probably need something specific for the Studio here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants