Closed RiccardoM closed 4 years ago
I'm referring to the state of the consensus being made,
which can be monitored from the Tendermint
RPC /dump_consensus_state
or they can be subscribed by these events.
We can discuss how this can be done. I prefer getting this in the backend so that the node being monitored won't have large requests from the frontend. And the frontend can only query the data from GraphQL. It will be great if those events can be mapped as subscriptions on Hasura. We may don't have to store the data in PostreSQL if Hasura let us create custom logic which can get the data from the Tendermint
events.
Maybe put this on hold first. I will see if subscribing the events from frontend will have better UX. It may not really taking too much resources. If we have so many users subscribing the events simultaneously, it will be a happy problem.
[...] they can be subscribed by these events.
Are you referring to all these events?
EventCompleteProposal = "CompleteProposal"
EventLock = "Lock"
EventNewRound = "NewRound"
EventNewRoundStep = "NewRoundStep"
EventPolka = "Polka"
EventRelock = "Relock"
EventTimeoutPropose = "TimeoutPropose"
EventTimeoutWait = "TimeoutWait"
EventUnlock = "Unlock"
EventValidBlock = "ValidBlock"
EventVote = "Vote"
Yes these are the consensus state of a certain block height, which refer to the 6 steps of the Tendermint consensus.
@kwunyeung Between all of those 11 event types, what are the real important ones?
I think these
EventCompleteProposal = "CompleteProposal"
EventNewRound = "NewRound"
EventNewRoundStep = "NewRoundStep"
EventPolka = "Polka"
EventValidBlock = "ValidBlock"
EventVote = "Vote"
Inside the requirements, there's the following:
@kwunyeung can we more details on what you mean by "consensus state"?