You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

90 lines
2.7 KiB

  1. # ADR 2: Event Subscription
  2. ## Context
  3. In the light client (or any other client), the user may want to **subscribe to
  4. a subset of transactions** (rather than all of them) using `/subscribe?event=X`. For
  5. example, I want to subscribe for all transactions associated with a particular
  6. account. Same for fetching. The user may want to **fetch transactions based on
  7. some filter** (rather than fetching all the blocks). For example, I want to get
  8. all transactions for a particular account in the last two weeks (`tx's block
  9. time >= '2017-06-05'`).
  10. Now you can't even subscribe to "all txs" in Tendermint.
  11. The goal is a simple and easy to use API for doing that.
  12. ![Tx Send Flow Diagram](img/tags1.png)
  13. ## Decision
  14. ABCI app return tags with a `DeliverTx` response inside the `data` field (_for
  15. now, later we may create a separate field_). Tags is a list of key-value pairs,
  16. protobuf encoded.
  17. Example data:
  18. ```json
  19. {
  20. "abci.account.name": "Igor",
  21. "abci.account.address": "0xdeadbeef",
  22. "tx.gas": 7
  23. }
  24. ```
  25. ### Subscribing for transactions events
  26. If the user wants to receive only a subset of transactions, ABCI-app must
  27. return a list of tags with a `DeliverTx` response. These tags will be parsed and
  28. matched with the current queries (subscribers). If the query matches the tags,
  29. subscriber will get the transaction event.
  30. ```
  31. /subscribe?query="tm.event = Tx AND tx.hash = AB0023433CF0334223212243BDD AND abci.account.invoice.number = 22"
  32. ```
  33. A new package must be developed to replace the current `events` package. It
  34. will allow clients to subscribe to a different types of events in the future:
  35. ```
  36. /subscribe?query="abci.account.invoice.number = 22"
  37. /subscribe?query="abci.account.invoice.owner CONTAINS Igor"
  38. ```
  39. ### Fetching transactions
  40. This is a bit tricky because a) we want to support a number of indexers, all of
  41. which have a different API b) we don't know whenever tags will be sufficient
  42. for the most apps (I guess we'll see).
  43. ```
  44. /txs/search?query="tx.hash = AB0023433CF0334223212243BDD AND abci.account.owner CONTAINS Igor"
  45. /txs/search?query="abci.account.owner = Igor"
  46. ```
  47. For historic queries we will need a indexing storage (Postgres, SQLite, ...).
  48. ### Issues
  49. - https://github.com/tendermint/basecoin/issues/91
  50. - https://github.com/tendermint/tendermint/issues/376
  51. - https://github.com/tendermint/tendermint/issues/287
  52. - https://github.com/tendermint/tendermint/issues/525 (related)
  53. ## Status
  54. proposed
  55. ## Consequences
  56. ### Positive
  57. - same format for event notifications and search APIs
  58. - powerful enough query
  59. ### Negative
  60. - performance of the `match` function (where we have too many queries / subscribers)
  61. - there is an issue where there are too many txs in the DB
  62. ### Neutral