web3.py: ABIv2 tuple encoding is not supported
- Version: 4.7.1
- Python: 3.6
- OS: osx/linux/win
What was wrong?
ABIv2 tuple encoding is not supported, even though the currently used version of eth_abi does support these sort of encodings if invoked correctly. For this reason it is impossible to call the getOrderInfo() method (https://github.com/0xProject/0x-monorepo/blob/development/packages/migrations/artifacts/2.0.0/Exchange.json#L1370) from the 0x V2 Exchange contract. And many other methods as well.
The exception thrown is ValueError: No matching entries for 'tuple' in encoder registry.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 24 (11 by maintainers)
Thanks for investing so much time.
Actually, my problem is not about the actual encoding/decoding, but software doing hashing/digital signatures (as it is verified by the Perun smart contracts). So, what I actually want to achieve: Encode the input data and create a signature, which can be read from the contract. This can only work, if the input for the signature (or hash) is exactly the same on both sides, means, the encoding on both sides has to be exactly the same.
When reading the eth-abi documentation and function signatures, I would expect eth-abi encoding functions to behave
exactlylike the Solidity functions may do. Maybe encoding/decoding still works somehow, but creating signatures/hashes and verifying it can only work if the bytes representation is exactly the same. Since the whole blockchain thing heavily (or better: exclusively) relies on hashes and signatures, I would not classify this issue as “nice to be fixed” but “absolutely mandatory” that available off-chain/off-node/offline encoding functions return the exact same results as solidity would/will do when running on-chain.Thx for digging deeper into that!
No, it’s not solved. As described above, there is a difference in python-based encoding and in-EVM encoding of empty arrays.
It’s not up to me to decide about the application logic of the code excerpts showed above. I’m using a given Smart Contract framework (Perun) which has a semantical difference between
[]and[0]. And even if I could change the application logic: It still remains a bug in the ABIv2 tuple encoding when it comes to nested elements with empty arrays. So, for me it’s not even a different issue, since it’s a bug in ABIv2 encoding, therefore this issue here is not fully and correctly implemented, therefore (in my opinion) it should not be closed.My workaround: I’m not doing any encoding anymore using web3py - I created Solidity methods for all these encodings and call
contract.functions.encodeWhatever(tuple(structure_to_be_encoded)).call(). Still: This is a workaroung for an existing bug. Not a solution.