...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.
The version of the reflect2 library we were pulling in (transitively,
via json-iterator) segfaults on go 1.18, due to some use of the unsafe
package that is not portable accross version; I was seeing this manifest
not long after running `make debug`.
The problem is fixed in the latest version, and similarly the latest
version of json-iterator depends on the fixed version. So, this patch
updates to the latest version to get he fix.
...and set suggested gas percentile to 40 instead of 60.
Recently, the recommended gas price requested via `eth_gasPrice`,
`hmy_gasPrice` or `hmyv2_gasPrice` has been fairly high (think 100k
gwei). This patch changes the maximum suggested gas price via these APIs
to be capped at 500 gwei. Users are still allowed to change the gas
price manually to be higher than this, for faster execution.
The occurence of these extremely high gas prices can be attributed to
the self reinforcing mechanism of this implementation. If some 20 blocks
are produced with extremely high gas prices for all transactions, the
API queries the transactions and returns the (erstwhile) 60th percentile
from them. This then results in a feedback loop for the following
blocks. This loop continues until transactions which do not use the
suggested gas price become part of the following blocks - which in
itself is unlikely, since transactions are sorted by gas price for
inclusion.
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.
* rpc metric identifier for getBlockReceipts
* made rpc response types compatible with ethereum
* implement hmyv2_getBlockReceipts RPC API
* Revert "made rpc response types compatible with ethereum"
This reverts commit 6182c62f45.
* encode rpc/v1 receipt type field ethereum compatible
MaxMustermann2
Jacky Wang
Konstantin
Ian Denhardt
peekpi
Leo Chen
Konstantin
Soph
Rongjian Lan
bbist
harjas
Dimitris Lamprinos