Message implementation

[ChihChengLiang]

What is wrong?

A beacon chain client sends and receives multiple types of messages, such as blocks and attestationRecords. It would be tedious if implementing a new type of message requires modifications in several places in both Python and Go codebase.

For example, if a message foo is introduced, it is likely that we need to:

• define foo message in message.proto in Python codebase.
• add rpc send_foo in rpc.proto in Python codebase.
• add rpc notify_foo in event.proto in Python codebase.
• add a handler in rpc server in Python codebase.
• add a validator for foo in Python codebase.
• add a handler in event rpc server in Go codebase.
• add a validator for foo in Go codebase.
• add register[topic, validator] in Go codebase.

How can it be fixed?

Make Go codebase agnostic to message type, whenever it receives a new message, pass the raw byte to the Python host. The Python host deserializes the raw byte and determine it's validity and return to the Go.

The proposed solution requires only adding a generic message, rpc server, and event notifier in both Go and Python codebase. When introducing a new message foo, the extra modification is reduced to:

• add message type foo in Python codebase
• add handler for it in Python codebase.

This also comes a downside that the invalid messages can't be pre-filtered in Go side by the content but by the size. This could be an attacking vector but might be tolerable in the prototyping stage.

[mhchia]

Totally agree with you. It makes a lot of sense. When we simplify the RPC call to notfiy(topic, bytes) and send(topic, bytes), it will be a lot easier to replace it with PIPE. Just for fun, I drew a flowchart for notify from Go to Python. Hope it will be useful.

[ChihChengLiang]

Addressed