rchain / rchain

Blockchain (smart contract) platform using CBC-Casper proof of stake + Rholang for concurrent execution.
Other
693 stars 217 forks source link

[DRAFT] Improve RNode event system #3585

Open zsluedem opened 2 years ago

zsluedem commented 2 years ago

Overview

Currently, rnode got an event system but provides a very limited function on it and it is not a well-tested feature. Ideally, the event system would provide easy function to websocket, grpc streaming endpoint.

Currently, it only provides 3 kinds of events in the system.

  1. BlockCreated
  2. BlockAdded
  3. BlockIsFinalized

The goal here is to improve the event system to help developers catch events and data in RChain.

Impact

Might require some of the core codes to handle additional effects.

Dependencies

No

Design

Besides the events above, we should add more events to the node. Currently, I can come up with 3 kinds events we should consider.

  1. Consensus events(finalized infos, merging infos, slashing infos, etc)
  2. Rholang Vm events(channel produce info, channel consume info, etc. Epic task)
  3. Other events(like p2p events, etc.)

We can consider completing this issue into smaller issues one by one.

tgrospic commented 2 years ago

@zsluedem Definition of events should not be connected to any specific protocol (WS, HTTP, gRPC, ...).

zsluedem commented 2 years ago

@zsluedem Definition of events should not be connected to any specific protocol (WS, HTTP, gRPC, ...).

Feel free to modify anything in the issue. :)

dckc commented 2 years ago

I think Rholang Vm events is what I am most interested in. I want to be able to do listenForDataAtName without polling. Being able to do deploy on the same connection would be nice but is probably not essential.

I suppose gRPC streaming is pretty close to what I want, but websockets is a little easier to deal with.

tgrospic commented 2 years ago

@dckc For the purpose of getting data after deploy there is no need to have specialized push for data at name. The data is available when next block is created and with block created event user can be triggered on this event and create a request to get the data.

Although we already have WS with block created event is useless because user doesn't have a way to be sure if he missed an event if WS connection is interrupted.


In the next major release of API we are planning to unify API interface for all protocols. As you mentioned for gRPC streaming we can do the same with HTTP streaming. Of course with some identifier to safely reconnect and receive all events.

Web Sockets can be tricky to work with e.g. browsers can prevent new connections if too many attempts are created (when connection is not stable), request/response correlation must be implemented on the user level, requires reconnection logic, ... So I'm more for the solution which allows users to use the same protocol for push messages also.

dckc commented 2 years ago

Ah. Block created does seem to address my needs. If you have an example using it from JS, that would be particularly helpful.