Standardize Relay Structure

Build Research
1

BACKGROUND:

Pocket Network has the potential to support every blockchain. Countless networks and innumerable versions of messaging systems are a great challenge for the programmers as they continue to develop the architecture. In order to build a fully scalable and future-proof client, Pocket Network must lay a flexible groundwork for relay structures that will account for both mass adoption and network support.

IDEA:

Pocket Network seeks to implement a system that efficiently standardizes the relay structure for all networks and their corresponding versions.

TOPIC:

This is a brainstorming discussion. Post ideas about how to standardize the Pocket Network relay structure to support future networks.

TERMINOLOGY:

“Relay” refers to a data structure within the Pocket Network that contains a non-native blockchain request or corresponding response.

“Relay Structure” refers to a data structure within the Pocket Network that interprets incoming data to a Pocket Network relay and formats outbound data to fit the non-native blockchain specification.

2

You will need some kind of serialization scheme for this, as well as an extensible data structure that allows for forward and backwards compatibility, e.g. with Protobuf you can add fields but not delete them.

Here are some options: https://notes.ethereum.org/15_FcGc0Rq-GuxaBV5SP2Q#.

3

There are two types of relays, as constructed via our SDK’s - Queries and Transactions. Someone is either reading or writing from a blockchain, so I think starting with this distinction is important.

We may want to have a base Relay structure that then divides into these two as well.

Initial thoughts on shared properties between reads and writes for this base Relay structure:

  • From - a Pocket address will always be signing to request information or write information to a blockchain even if it’s not the Pocket protocol
  • Metadata - Generic set of information that is being requested or sent. This can vary from sending crypto, writing to a smart contract, reading from a smart contract, reading extraneous data such as balances
4

For me, the way to handle this, is to create a separate repo with 1 directory file for each network (ETH, BTC, RCHAIN, etc…), and store all the versions of the “standard” so we make it community driven. I understand networks could have multiple clients (e.g. geth and parity), however they will usually follow the same communications protocol.