* reduce shard of testnet to 2
* remove harmony inner nodes in shard2 and shard3
* check shardID in VerifyCrossLink
* get NumShards by epoch instead of hardcodeed shards
* add Localnet in NewGenesisSpec
* do mayTestnetShardReduction in the block before the last block
* fix localnet epoch calculation
* not use old committee if shard reduction happens
* fix preLastBlock calculation
* do testnet shard reduction when propose new blocks
* enable 2s block period at epoch 0
* call IntermediateRoot once in the end
* skip inactive&baned validators when testnet shard reduction happens
* update ShardReductionEpoch to epoch 486
* fix: elastic rpc new filters fix
* fix: add a small delay to give readers time to catch up
* fix: run the subscribe in a go routine
* fix: generate the filter id before
* fix: rpl not able to marshal negative big int
* fix: use json to get the message
* Revert "Increase voting power of harmony nodes in testnet to 0.7 (#4200)"
This reverts commit 20edef740b.
* RESET TESTNET
* fix vrf testcase
* reduce number of nodes required for reseting testnet
* use only harmony nodes before staking epoch
* [txpool] fix#4215, support allowed transaction list.
* test: fix node tests for allowlist of txs
* add error checking of tx.data
* recover test scripts
* config migration
* add tx.data to error info
* [pool] refactor: log more if `from` in denylist
* reject tx if it does not pass the allowed whiltelist check
Co-authored-by: MaxMustermann2 <82761650+MaxMustermann2@users.noreply.github.com>
* lower gas limit to 30M
* increase suggested gas to 70 percentile and increase max suggested gas to 1000
* Fix race error.
* Increase price limit to 100e9.
* Set 95 percentile.
* Fix rpc response.
* [test] adjust funds for new higher gas price
* [rosetta] use new gas price
Co-authored-by: Rongjian Lan <rongjian.lan@gmail.com>
Co-authored-by: Konstantin <k.potapov@softpro.com>
Co-authored-by: MaxMustermann2 <82761650+MaxMustermann2@users.noreply.github.com>
The validator list is not per block, while the information being sought
is. Therefore, do not return error if validator address is not present
in state.
Fixes#4202
...and ensure transfers from the precompile address can be made before
executing them. Since we are now blocking multiple `CXReceipts` per
transaction explicitly, it doesn't make sense to be wary of contracts
subsidizing cross shard transfers for end users via `delegatecall`. It
is then safe to remove the gas charge for the precompile. Secondly,
ensure that there are enough funds on the precompile via `CanTransfer`
as part of the sanity check.
* fix unexpected chain id (https://github.com/harmony-one/harmony/issues/4129)
* update epoch numbers for ChainId fix
* updated ChainID Epoch for test net
* align comment with other comments
* fix the build using goimports
Co-authored-by: “GheisMohammadi” <“Gheis.Mohammadi@gmail.com”>
...for native tokens only, and not for smart contracts (which will be
added later). Resolves#4132 and requires a hard fork, currently
scheduled at EpochTBD on main and test nets, but epoch 1 (after
AcceptsCrossTx) on other nets.
The precompile is at address 249 and the method has the signature
`crossShardTransfer(uint256 amount, address to, uint32 toShardID)`. It
requires a transfer of the `amount` to the precompile address first, in
the form of `msg.value`, and cascades a cross shard receipt to the
network when executed. At this stage, it is blocked for use by smart
contracts by checking that there is no code at the address, and that the
address is not a validator. Documentation for Python integration tests
to follow.
Closesharmony-one/harmony#4113 by sorting transactions by time received
instead of using a hashmap based transaction ordering. This sorting is
on top of the gas price and nonce sorting already implemented.
Effectively, this allows the production of almost a deterministic order
of transaction ordering, as opposed to a heap-based hash map ordering
which is affected by Golang's internal operations. Consequently,
arbitrageurs, who spam the network with a view to exist around
arbitrag-able transactions, will have to focus on latency instead of
network spamming.
See also bnb-chain/bsc#269 and ethereum/go-ethereum#21358 for related
issues in other chains.