During the transition from contract mode to block header mode, when creating the extra data for a new block, we need to look ahead to the next block's voteProvider to obtain the nonEmpty one associated with the BlockValidatorProvider.
This only applies to ForkingValidatorProvider which is currently only used for QBFT. However, we don't want QBFT to know it's using a ForkingValidatorProvider. Therefore we need to implement getVoteProviderAfterBlock on the ValidatorProvider interface even though it's implementation is equivalent to getVoteProvider.
Signed-off-by: Simon Dudley <simon.dudley@consensys.net>
This is a re-implementation of the initial POC done in https://github.com/PegaSysEng/pantheon/pull/1909/ by Danno Ferrin <danno.ferrin@gmail.com>
* Only enable plugin rpc api when enabled on --rpc-http-api or --rpc-ws-apis
* Only allow new rpc endpoints to be defined
Signed-off-by: Antony Denyer <git@antonydenyer.co.uk>
Broad reaching optimizations to speed up EVM calculations
* Generally speaking, use int and long where it is more appropriate than UInt256 (memory indexes mostly)
* Move the internal stack to Bytes from UInt256
* Re-work the flow of many operations to account for the above
Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>
Move EVM to a standalone module
Move the EVM classes to a standalone module. This is mostly moves but
some API re-resign to peel out some features not essential to the EVM,
such as privacy support and ties to the data storage subsystem.
Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>
* Create new datatypes module
Create a new `datatypes` module to hold datatypes that are broadly used.
This will aid modularization by making sure the base types in the module
minimize the amount of unrelated support classes needed.
Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>
* Add Address, Hash, and Wei to datatypes
Move the Address, Hash, and Wei to datatypes in as they are needed for
EVM modularization.
Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>
* Add unstable CLI option for max ommers depth
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Move to a builder pattern for mining parameters
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Upgrade to Apache Tuweni 2.0
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Remove intermediate repository
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Remove all occurrences of toBytes
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Migrate to tuweni-bytes
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* add changelog
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* correct reference tests
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Initial API changes
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* more changes
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Change APIs for VM ops
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Use constant UInt256.ONE
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* Optimize a bit address <> word transformation
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
* spotless
Signed-off-by: Antoine Toulme <antoine@lunar-ocean.com>
The Hash of a qbft payload is calculated by hashing the RLP'd bytes of the message-id, followed by the payload's encoded bytes.
RLP(msgCode, RLP(payload.encodedBytes()))
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
We were creating new in-memory storage segments each time we were
supposed to be retrieving it which prevented me from being able to test
what keys ended up being stored in that segment.
Signed-off-by: Ratan Rai Sur <ratan.r.sur@gmail.com>
QBFT no longer validates all fields of the block header (eg nonce mixhash), as these have no bearing on the
safety model of the protocol.
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
The code required to deserialise signed payloads for QBFT is verbose and can be reduced by templating.
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
Move the messageFactory out of IbftFinalState such that the IbftFinalState can be reused between IBFT and QBFT.
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
Aspects of the consensus mechanism associated with block creation, and validation have been moved
from the IBFT package, into into consensus/common, such that they can be reused for the QBFT
implementation.
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
When validating a RoundChange message, its important that not only
are there sufficient Prepare msgs in the PreparedCertificate, but
also that each are from a different validator (i.e. cannot simply
count the number msgs, but must count distinct authors).
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
Move the block header validation errors logging levels from trace and
debug to info. Also, include a standard prefix "Invalid block header: "
in each of the log lines.
Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>
Since the EIP-1559 transition is going away, simply use a set of
accepted transactions for transaction validator that we'll check
against.
Don't assume that there are two transaction types and instead check
what type the transactions are.
Use guessType when we're deserializing from json.
Signed-off-by: Ratan Rai Sur <ratan.r.sur@gmail.com>
Moves IBFT events to the common package for reuse with the QBFT implementation.
This necessitated the creation of BftEventHandler interface, such that a generic IbftController can be passed around, rather than the literal IbftController.
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
Moving the IbftMessage (and rename to BftMessage) to the common package such that it can be reused as part of the QBFT implementation.
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
SignedData is to be used as part of QBFT, and as such the IBFT specific aspects of this class are to be moved into a separate class (allowed SignedData to be moved into the common package)
Signed-off-by: Trent Mohay trent.mohay@consensys.net
This is the first step in making aspects of the IBFT2 code base common, such that it can be reused as part of the QBFT implementation which is coming shortly.
Signed-off-by: Trent Mohay trent.mohay@consensys.net
This is a stronger check than in the past, which potentially allowed for a the IBFT system to handle messages for the current round, even if a block had already been imported (but had not yet received the new-block event) - which in turn, could lead to a network fork in a adversarial environment.
Signed-off-by: Trent Mohay <trent.mohay@consensys.net>
For every block produced and imported directly log the same information
we would get from other import paths.
* If this node produced the block, note that with "Produced" instead of
"Imported"
* Log the size of the pending transaction pool
* Only log IBFT rounds at INFO if they go past round 0, DEBUG otherwise.
Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>