catalyst-network / protocol Goto Github PK

It is more appropriate and will also allow cleaning all the usage of the class from
Protocol.Delta.Delta to Delta

this will allow for voting for the most popular candidate
a candidate delta contains

• a hash of the content of the delta
• the producer's PeerIdentifier
• the hash of the delta preceding the candidate

Currently we are using an int64, but as seen in Deltas or IPPN, protobuf has dedicated message structure for that

For use with catalyst-ffi and wasm-ed25519ph

We eventually want some type of unit testing for protobuffs. Protobuffs doesnt have native UT functionality so we would need to generate them to a language like c#/js and write UT in for them in there.

This allows messages to be transmitted as an "Any" type on which the TypeUrl field points to the unambiguously to the proto being described in the Value field

Needed for catalyst-network/Catalyst#216

This needs to include

• a type_url as in Google Common Types Any
• a bytestream content
• a peerId to identifier the sender
• a signature to allow verifying the content of the message

Mainnet is not spelled Mainet.

Needed for catalyst-network/Catalyst#216

Rangeproof doesn't need to be split into multiple fields as it can be serialised and deserialised to a single byte array in rust. Maintaining this separation into multiple fields would provide no benefits and make the object that crosses the ffi boundary much more complicated than it needs to be.

This is needed in the "election" phase or the phase during which all participants broadcast what they think is the best Candidate they saw during that cycle.

the current return type pushes people to transmit strings on the wire

we should really transmit proto objects

For use in #809

This is a first validation that at least the files are in a valid format, these files can then be used for unit testing done in C#

this peerId is used to send Challenge messages which are defined in proto as well

This is to allow matching a given response to the original request it corresponds to
The correlation Id could be a 16 bytes GUID, or the request message signature, or anything that allows disambiguation.
For now we can add a field to the proto definitions and decide on how to fill it when implementing in C#.

So that other nodes get updated when this new Delta is appearing on the DFS and start trying to retrieve it

After chatting with research, it seems that there could be forks in the consensus, and that means that there could be double-spending attempts, so we need to use a nonce to prevent that from happening.

We need clear field names as well as the length of fields for protobuff definitions.

https://app.zenhub.com/workspaces/catalyst-network-development-5c69b98076215728ef1061ef/issues/catalyst-network/catalyst-js/56
https://app.zenhub.com/workspaces/catalyst-network-development-5c69b98076215728ef1061ef/issues/catalyst-network/protocol/123