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

Support for smart contracts and big maps #21

Closed
amzid opened this issue Nov 12, 2020 · 4 comments
Closed

Support for smart contracts and big maps #21

amzid opened this issue Nov 12, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@amzid
Copy link

amzid commented Nov 12, 2020

I am working on Tezos Reward Distributor and we are using tzkt as a possible backend api for fetching blockchain data. We are now working on adding support for delegations in the form of dexter contracts and we would like to extend the current tzkt provider implementation with the needed endpoints to extract data from big maps at any given block, i.e. given a block level and a big map id, I would like to get the list of values stored in this big map at that specific block.
That would be great if this feature can be added to tzkt for us to enable support for the dexter delegations using tzkt.

@argonau7
Copy link

argonau7 commented Feb 4, 2021

Yes this would be great to have ASAP!

@Groxan
Copy link
Member

Groxan commented Feb 4, 2021

Thank you for your interest! We're already working on contract storage and lazy storage (aka big_maps) indexing.

@Groxan
Copy link
Member

Groxan commented Apr 15, 2021

Hey! We have implemented bigmaps indexing. For now, it is available on staging and will be in prod in a few weeks, after more tests. The API is more or less stable and likely won't be changed, so you can already play with it.

There are two ways to access bigmaps:

  1. By ptr: /bigmaps/543 (see docs)
  2. By name: /contracts/{dexter}/bigmaps/accounts (see docs)

And there are two endpoints to access keys:

  1. Current keys: /keys (see docs)
  2. At specific block: /historical_keys/{level} (see docs)

As far as I understand, you need historical keys, so the second endpoint is your choice. In all other cases I strongly recommend avoid accessing historical keys, because this endpoint is much slower than current keys due to data aggregation.

You can also use filters, pagination and selection, for example: /historical_keys/1400000?active=true&value.balance.ne=0&select=key,value

Feel free to leave any feedback or ask any questions.

@Groxan
Copy link
Member

Groxan commented Apr 29, 2021

Done in v1.5

@Groxan Groxan closed this as completed Apr 29, 2021
ajinkyaraj-23 pushed a commit to ajinkyaraj-23/tzkt that referenced this issue Oct 7, 2024
* [data] create a DalAttestationStatus table

In order to keep track of DAL attestations evolution

* [cache] create a cache for DalCommitmentStatus

To be able to retrieve them faster

* [dal-attestation] index DAL attestation status

Each time an endorsement contains dal-attestation, index a
DalAttestationStatus for each slot associated to a DAL commitment

* [api] add an endpoint to count DAL attestations

Authorize to filter by:
 - commitment
 - publishLevel
 - slot-index
 - attester
 - attested

* [api] add an endpoint to get DAL attestation information

Authorize to select fields:
 - commitment
 - publishLevel
 - slotIndex
 - attester
 - attested

Authorize to filter by:
 - commitment
 - publishLevel
 - slotIndex
 - attester
 - attested

Authorize to sort by:
 - publishLevel
 - slotIndex
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants