pigmej
commented
3 weeks ago builtin per-ip rate limiting
That's something that IMO is better to do on LB level.
Open dshulyak opened 7 months ago
pigmej
commented
3 weeks ago builtin per-ip rate limiting
That's something that IMO is better to do on LB level.
this is placeholder issue to hold API improvements
v2alpha1 api specification based on Lane and Kirill requirements:
API services
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:
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 https://github.com/spacemeshos/pm/issues/269
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.