support other seal-engines

[simon-jentzsch]

Currently this encode and decodes only blocks as specified in the yellow paper.
it does not work with POA-Chains, since they are using different sealed_fields.
How about we use the seal_fields insted.

[holgerd77]

Hi Simon, not sure if you have followed the latest developments at ethereumjs/ethereumjs-block#44 introducing support for different networks and were inspired for this issue from there.

I'm very open for an extension in this direction, actually through the new ethereumjs-common library there will also now be the possibility to request the consensus type (e.g. pow or poa) when a network and a hardfork are set.

I am no POA expert, do you want to prepare a PR for this? Or do you have someone in mind who could do? It would be also good if you could have a look at the common library if/where/what kind of POA data should be added there.

[holgerd77]

Hi @simon-jentzsch, any comment on this (see my note above)?

[simon-jentzsch]

Hi, yes this is implementation I coded, which serializes blockheaders from both (pow and poa):

https://github.com/slockit/in3/blob/master/src/util/serialize.ts#L146

I tested this on all testchains.

[vpulim]

@simon-jentzsch Would you be able to incorporate your code into ethereumjs-block and submit a PR?

In addition to supporting additional seal fields for PoA, we also need to fix the validation code. Until more robust validation code is written, the following changes should be enough to loosely validate PoA blocks for now:

1. In BlockHeader.prototype.canonicalDifficulty, the minimumDifficulty check should be skipped for non-PoW chains:

  if (dif.cmp(minimumDifficulty) === -1 && this._common.consensus(hardfork) === 'pow') {
    dif = minimumDifficulty
  }

2. In BlockHeader.prototype.validate, the extraData.length check should be skipping for non-PoA chains:

    if (self.extraData.length > self._common.param('vm', 'maxExtraDataSize', hardfork) 
      && self._common.consensus(hardfork) === 'pow') {
      return cb('invalid amount of extra data')
    }

[holgerd77]

//cc @simon-jentzsch What's the status of this?

[vpulim]

To clarify, @simon-jentzsch's PR implements changes needed for Parity's Aura PoA protocol. However, Goerli (and Geth) use the Clique PoA protocol which does not require changes to the Block header fields.

[holgerd77]

Will close, we will likely not support the Parity Aura PoA protocol and there is another more generalized PoA issue open with #689