[WIP] ETH2.0 Wire protocol #195
Conversation
…estar into mikerah/eth2-wire-protocol Rebased mikerah/eth2-wire-protocol
…estar into mikerah/eth2-wire-protocol Divergence between local and remote branch
…th2-wire-protocol Get latest p2p changes
…th2-wire-protocol Merge newest changes
|
Looks like the linter failed |
src/p2p/index.ts
Outdated
| } catch (err) { | ||
| this.log.error(err); | ||
| } | ||
| }); | ||
|
|
||
| this.node.on('peer:disconnect', (peerInfo) => { | ||
| try { | ||
| try { | ||
|
|
There was a problem hiding this comment.
white space, also not sure if this needs a try/catch theres no async functionality happening
There was a problem hiding this comment.
The pull-stream is there because that's what used in the example I was given. I will be changing this to an async iterator. Also, you can still use try/catch whether or not there's async functionality. Is there a preferred way for catching errors that would be better in this case?
There was a problem hiding this comment.
The way I look at It, those functions should return a promise or callback if they have an error.
I'm on mobile but I'll check the api later
src/p2p/index.ts
Outdated
| @@ -89,18 +95,45 @@ export class P2PNetwork extends EventEmitter implements Service { | |||
|
|
|||
| }); | |||
|
|
|||
| // 2-way handshake | |||
| const protocol: string = "/eth/serenity/beacon/rpc/1"; | |||
There was a problem hiding this comment.
probably put this into constants file
…, along with other changes
…l have lint issues
| slot: Slot; | ||
| } | ||
|
|
||
| export interface HashTreeRoot { |
There was a problem hiding this comment.
I think we could make a Root type in src/types/primitive.ts that would be useful across the codebase, used in the wire messages.
It would look like:
export type Root = bytes32;and since we would be using it in ssz-ed types, we'd need a export const Root = bytes32; too.
|
@mpetrunic I'm not done yet. I'm still trying to setup the code to make it easier to refactor so that implementing the |
|
@wemeetagain we can easily interface between the two. The main issue with ssz is that it's not fit to for messages sent over the wire like something like RLP or Protobufs are. That's why other clients are adopting the dual Protobuf-ssz scheme I'm attempting to go with |
|
Could you elaborate on ssz not being fit for messages over the wire? The networking rpc spec mentions that data is serialized using ssz, which makes it seem it is fit for messages over the wire. I/m under the impression that the reason other clients use protobuf is because they rely on gRPC which requires the use of protobufs. |
|
I think that spec is going to be changed soon. The reason for using ssz on the wire is simplicity. There were some discussions a while back about using RLP instead. This issue from a while ago sums it up. There's also a google doc floating around somewhere that goes into details. I think that doc is probably just the current discv5 spec, though. |
|
So why are we implementing a protobuf wire protocol? |
|
I'm going to have to agree with @wemeetagain I don't see a compelling argument for including protobuf. Minimalistic is always better imo. |
|
Closing in favor of waiting until ETH2.0 Wire Protocol is more certain. |
I have started an initial implementation of the ETH2.0 Wire protocol.