Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ETCM-355] Send fork id to peers #1030

Merged
merged 13 commits into from
Jul 9, 2021
Merged

Conversation

lukasz-golebiewski
Copy link
Contributor

Description

First part of https://eips.ethereum.org/EIPS/eip-2364. Extends the ETH64 protocol Status by a fork id field and broadcasts it to peers during handshake

Does not yet contain peer fork id validation

@@ -27,13 +27,15 @@ case class EtcHelloExchangeState(handshakerConfiguration: EtcHandshakerConfigura
override def applyResponseMessage: PartialFunction[Message, HandshakerState[PeerInfo]] = { case hello: Hello =>
log.debug("Protocol handshake finished with peer ({})", hello)
// FIXME in principle this should be already negotiated
Capability.negotiate(hello.capabilities.toList, handshakerConfiguration.capabilities) match {
Capability.negotiate(hello.capabilities.toList, handshakerConfiguration.blockchainConfig.capabilities) match {
case Some(ProtocolVersions.ETC64) => EtcNodeStatus64ExchangeState(handshakerConfiguration)
case Some(ProtocolVersions.ETH63) => EtcNodeStatus63ExchangeState(handshakerConfiguration)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

request: do you mind changing this to Eth? I missed it and it's confusing this way.

@dzajkowski
Copy link
Contributor

overall looks good to me. question: would you be able to deploy to staging to see how it behaves? I guess running it locally against ETC mainnet would also be a good idea.

Copy link
Contributor

@leo-bogastry leo-bogastry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thinks it's looking good

@lukasz-golebiewski
Copy link
Contributor Author

Waiting before merging for #1029

@lukasz-golebiewski lukasz-golebiewski force-pushed the feature/etcm-355/eth64 branch 6 times, most recently from f877897 to 9f6194a Compare July 6, 2021 14:02
@lukasz-golebiewski lukasz-golebiewski force-pushed the feature/etcm-355/eth64 branch 3 times, most recently from 199ece7 to 43c8eef Compare July 8, 2021 14:45
This also fixes a bug in NewBlock message creation, where only
protocol version was taken into account
val remoteStatus = peers(peer.id).peerInfo.remoteStatus

val message: MessageSerializable = remoteStatus.protocolFamily match {
case ETH => blockToBroadcast.as63
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be so cool to have this fail if a new block type is introduced. just a thought, no great ideas.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thinking out loud:

  private def broadcastNewBlock(blockToBroadcast: BlockToBroadcast, peers: Map[PeerId, PeerWithInfo]): Unit =
    obtainRandomPeerSubset(peers.values.map(_.peer).toSet).foreach { peer =>
      val remoteStatus = peers(peer.id).peerInfo.remoteStatus

      val message: MessageSerializable = {
        val capOpt = Capabilities.of(remoteStatus.protocolFamily, remoteStatus.protocolVersion)
        capOpt match {
          case Capabilities.Eth63Capability => blockToBroadcast.as63
          case Capabilities.Eth64Capability => blockToBroadcast.as63
          case Capabilities.Etc64Capability => blockToBroadcast.as64
          case None                         => throw new RuntimeException("Unknown capability, cannot broadcast block")
        }
      }

...

    def of(pf: ProtocolFamily, v: Int): Option[Capability] =
      (pf, v) match {
        case (ProtocolFamily.ETH, 63) => Some(Eth63Capability)
        case (ProtocolFamily.ETH, 64) => Some(Eth64Capability)
        case (ProtocolFamily.ETC, 64) => Some(Etc64Capability)
        case _                        => None
      }

and an ADT out of the capabilities?

log.debug("Negotiated protocol version with client {} is eth/63", hello.clientId)
EthNodeStatus63ExchangeState(handshakerConfiguration)
}
case Some(ProtocolVersions.ETH64) => {
case Some(ProtocolVersions.ETH64) =>
log.debug("Negotiated protocol version with client {} is eth/64", hello.clientId)
EthNodeStatus64ExchangeState(handshakerConfiguration)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you also fix the 'orElse' clause that I introduced (orElse(WireDecoder))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to do this in a follow up PR, this one has become quite old and heavy

@lukasz-golebiewski lukasz-golebiewski merged commit 0bc2292 into develop Jul 9, 2021
@lukasz-golebiewski lukasz-golebiewski deleted the feature/etcm-355/eth64 branch July 9, 2021 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants