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

api v2 #270

Open
4 of 10 tasks
dshulyak opened this issue Oct 3, 2023 · 2 comments
Open
4 of 10 tasks

api v2 #270

dshulyak opened this issue Oct 3, 2023 · 2 comments

Comments

@dshulyak
Copy link

dshulyak commented Oct 3, 2023

this is placeholder issue to hold API improvements

v2alpha1 api specification based on Lane and Kirill requirements:

API services

  • account service
  • activation service
  • block service
  • layer service
  • network service
  • node service
  • reward service
  • tx service

Every service will contain Stream (private grpc) and List (public grpc - with pagination) endpoints to have minimal safe API.


the goal is to have efficient (in terms of cpu and disk usage) and correct (atleast once delivery semantics with reorg support) client to facilitate:

  • data indexing for explorer
  • full data observability

the implementation will consist of streams per every object (atxs, ballots, blocks, txs, tx results, reward, certificates, proposals). every object will be complete, in a sense that it should be possible to re-encode it in scale and verify signatures.

every stream will read history from database and switch to inmemory subscriptions in a "correct" way. the correct way will be elaborated in technical specification. good example of such API is stream for transaction results

the competing idea is #269

  • safe API to use in wallet-only mode

the goal is to have minimal safe API for interacting with vm. as such it should support:

  • submit transaction with strict validation (only 1 concurrent tx). this is different from sending to your own node

  • poll result of the transaction and state in mempool

  • query single account balance

  • builtin per-ip rate limiting

  • rosetta integration

https://www.rosetta-api.org/

as stated integration for rosetta API


from that list 1 and 2 items have a higher priority and can be completed with 1-2 month, rossetta can be completed later within 6 month.

@pigmej
Copy link
Member

pigmej commented Apr 9, 2024

builtin per-ip rate limiting

That's something that IMO is better to do on LB level.

@pigmej
Copy link
Member

pigmej commented May 20, 2024

The progress is reported: spacemeshos/api#295 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🏗 Doing
Development

No branches or pull requests

4 participants