Closed martyall closed 6 years ago
Note: we are now using a consistent (de)serialization of the BigNumber
type. Before it was possible to use either decimal or hexadecimal encodings, and sometimes there was padding added when there shouldn't be.
Other problems included certain rpc calls that don't exist on all nodes, those now have a Partial constraint
.
We are no longer trying to interpret different block structures because the changes here made that more difficult. Also, @XertroV s changes for supporting Kovan blocks were not quite correct -- there are actually many more discrepancies between the two block types and we were just jumbling things up. I think that it's sufficient for the moment to implement a eth_getBlockByHash
etc in whatever client library is using a non-standard block structures (in this case parity POA) library, it's easy to follow the pattern laid out in this library or file an issue.
@blinky3713 - I notice KovanBlock is just in the test module, do we have plans to add Kovan support back to main? Personally I'd like this to be included in the 1.0 milestone since I use Kovan pretty heavily. Happy to do implementation ofc.
On of the issues I foresee regarding custom eth_getBlockByHash
implementations is having lots of isKovan
type flags and needed to write wrappers around any getBlock
calls. Not sure how all that will pan out. That said, Kovan blocks are technically different blocks so it's probably worth keeping different types or implementing kludges (e.g. a KovanBlock -> Block
method) a per-project thing.
One idea might be to allow a function to be injected in the block processing thing? You could use an AVar within Web3
to store the function and allow it to be updated, though this might be bad design (e.g. if someone else is working on my code it might not be apparent that the behaviour of getBlock
now doesn't match the ps-web3 docs)
Hmm.
This pr upgrades the foreign generics package to be able to use
Maybe
types, which are available in version 6.0.