IBFT requires various aspects of the mining infrastructure in order
to create a proposed block.
This includes specifically the BlockCreator and MiningCoordinating,
the mining executor is not required at this stage, nor is the miner.
* EthGetTransactionReceipt Acceptance test added
* GetTransactionReceipt Acceptance Test updated to conform to new dsl
* Update to new dsl
* Update to new dsl
* Update to new dsl - spotless applied
* Naming convention corrected
* Naming convention corrected
Deleted obsolete test cases
added assertion for status code
* Naming convention corrected
Deleted obsolete test cases
added assertion for status code
* Naming convention corrected
* Removed sender field to make test more efficient
* Removed sender field to make test more efficient
* IoC for deploying the smart contract
* Smart contract deploy as a Transaction
* Consistent transaction naming
* Avoiding a resource leak with lazy creation of Web3j connections
* Remove release/retain requirement from MessageData.
MessageData now wraps a BytesValue rather than a Netty ByteBuf so we no longer need to call release/retain and pass that through to the underlying ByteBuf.
Entirely removed support for a BytesValue wrapping a Netty ByteBuf as it does not provide any way to release the underlying ByteBuf.
* Add BytesValue.copyTo(byte[]) to avoid the need to call getArrayUnsafe() to copy the data.
Removing dependency upon using map.entry to define a vote that has
been proposed via JSON RPC.
This is part of the general clean up of the voting infrastructure
used for IBFT, Clique and legacy IBFT.
The consensus-mechanism specific block values have been separated
from the VoteTallyUpdater such that there is a single updater rather
than one per consensus mechanism.
This has necessitated the creation of a custom serialiser/
deserialiser for each mechanism instead.
This change will ultimatley bleed through to the proposed votes and
their insertion to mined blocks.
Some more logging level downgrades.
* At steady state we should get only one info level log per new block
* We don't need to know about peer stuff at info
* Caught up to best peer fires for every block
Update value returned by web3_clientVersion to be ethstats friendly
* Version part starts with a v
* SNAPSHOT builds report 32 bits of the git hash
* OS and architecture are sniffed out and reported
* JVM version and branding are sniffed out and reported
Example values (not all real):
pantheon/v0.9.0-dev-f800a0b1/osx-x86_64/oracle-java-1.8
pantheon/v0.9.0-dev-27960b57/osx-x86_64/zulu-java-11
pantheon/v0.9.0/linux-arm64/openjdk-java-12
fixes#233 Allow nodekey to be specified separately to --datadir
Add a `--node-private-key <FILE>` option on CLI to enable the use of a custom key file.
if not set, uses the default "key" file in the data dir
if set but doesn't exist, creates a new key file
if set and exists, uses the specified key file
Add tests that hit the retry failure case
Move "complete what we just got" semantic into the
DownloadHeaderSequenceTask. Previously it was completing everything
in the chunk it was assigned.
* Ban Peers via CLI
As part of working on #251 I needed to be able to ban certain nodes from my
connection pool and let others connect. This is a general solution to add
a --banned-nodeids CLI flag where the nodeIds of banned nodes are listed.
* Introduce ProtocolScheduleBuilder and use it for Clique, MainNet, IBFT and dev.
* Remove default milestone blocks and simplify MainnetProtocolSchedule. All milestone blocks must now be defined in the genesis file (previously ethash chains would get Mainnet milestone blocks by default).
* Make GenesisConfigFile responsible for handling all the content in the genesis config file and rename GenesisConfig to GenesisState as it is now just responsible for creating the initial state at genesis.
* In CliqueProtocolController, pass the network ID to EthProtocolManager instead of the chain ID and use downloader parallelism setting instead of network ID for the number of threads.
Gradle 4.10.2 issues deprecation warnings. Based on the Gradle
documentation, enable the STABLE_PUBLISHING feature preview to
fix this. This is essentially a no-op as no Maven publications
are published.
As recommended in #231 alter the API so that the
subclasses always return their list from executePeerTask in the
`CompletableFuture` and reset the retry in `#executeTask()` when any
non-empty list is returned.
* Fix corner case where Memory did not clear target destination if the new bytes to set was empty.
* Use BytesValue.EMPTY instead of Bytes32.EMPTY to make it clear that it's a 0 length BytesValues rather than 32 bytes of zeross.
* Treat outputLength for call operations as a maximum length - when the actual data to output is shorter than outputLength, do not zero out the tail end of the memory range.
A more robust fix: be tolerant of partial success. Instead of counting
every call as a limited retry change the semantics of
AbstractRetryingPeerTask such that it's retryCounter may be reset on a
partial success. Hence the limit is on consecutive zero progress
retries and large blocks dribbled in one at a time are not penalized.
Undo temp fix. Restore retries to 3 in a row.
* Don't rely on sun.security.krb5.Confounder.bytes.
It's not reflected as part of the JDK platform and makes IDEs cranky.
* Use a better SecureRandom factory.
* spotless
Adrian Sutton
tmohay
mbaxter
Michael Connor
CJ Hare
Danno Ferrin
Nicolas MASSART
PegaSys Admin
MadelineMurray
Lucas Saldanha
Jussi Virtanen
Matt Gucci