firefly
firefly copied to clipboard
FF23023: EVM return data invalid: FF22047: Insufficient bytes to read string value
I suspect there is a bug in the FireFly signer ABI encoding. This contract demonstrates the issue: https://mumbai.polygonscan.com/address/0xc0bc785b2c5494820B63c7108547b4652b9742aD#code
Steps to reproduce:
- Create a new FireFly stack (using default settings with a local blockchain node is fine)
- Create a contract interface / API with the contract listed above
- Call the
POST
/invoke/createCoupon
endpoint with the following payload:
{
"input": {
"_end": "1234",
"_id": "2345",
"_ipfsUrl": "3456",
"_start": "4567"
}
}
- Call the
POST
/query/viewAllCreatedTokens
endpoint with an empty JSON object as the request body
Response:
{
"error": "FF10111: Error from ethereum connector: FF23023: EVM return data invalid: FF22047: Insufficient bytes to read string value [tup,i:0,b:0][dyn,i:0,b:64][tup,i:1,b:128]"
}
On Polygonscan I see a valid response from this method should look like:
[[1,QmdbaSQbGU6Wo9i5LyWWVLuU8g6WrYpWh2K4Li4QuuE8Fr,1683555160,1683554160]]
evmconnect.log Here's a full evmconnect log with the error
So the query to get the tokens which return a tuple of type (uint256, string, uint256, uint256) is encoded as such
Blocks Index. Value
0000000000000000000000000000000000000000000000000000000000000020 0 32 // offset for the list of tuples
0000000000000000000000000000000000000000000000000000000000000001 32 1 // Number of tuples in the list (length)
0000000000000000000000000000000000000000000000000000000000000020 64 32 // Start position for the respective tuples
000000000000000000000000000000000000000000000000000000000000007b 96 123 // ID I gave the coupon
0000000000000000000000000000000000000000000000000000000000000080 128 128 // Offset to where the UTF8 string starts (the length of it first)
000000000000000000000000000000000000000000000000000000000031079d 160 3213213 // _start of coupon I gave
0000000000000000000000000000000000000000000000000000000000005e4d 192 24141 // _end of coupon I gave
000000000000000000000000000000000000000000000000000000000000000b 224 11 // Length in bytes of the string that comes next
7468697369736d7975726c000000000000000000000000000000000000000000 256 // String starts here 128 + 128
The bug is that when we add up the offset of the string to the current position we are passed there wrong parameters in. We want to add the Head Start (in the case the start of the tuple) to the data offset for the string. Unfortunately, we weren't passing the right head start parameter to the function where we traverse the bytes. So the error that occurs we try to decode a int as an string!
This is fixed as part of https://github.com/hyperledger/firefly-signer/pull/42
There is an additional fix that @peterbroadhurst when he noticed that we were returning the full length of the walkDynamicChildArrayABIBytes to the headBytesRead of decodeABIElement - but actually, only the 32bytes of the headOffset were from the header.
. This meant that we were moving the head position by too much when decoding the element of a dynamic array which causes loads of issues.
I have also encountered a similar issue where when I have created FFI & API for a simple straight forward contract contract - https://github.com/joshtharakan/solidity-template/blob/main/contracts/greeter/Greeter.sol Steps to reproduce
- Create a new FireFly stack. (I used besu node)
- Create a contract interface & API with the
Greeter
contract listed above - Call the
POST
/invoke/setGreeting endpoint with the following payload:
{
"input": {
"_greeting": "bonjour"
}
}
- Call the
POST
/query/greet
endpoint with an empty JSON object as the request body
{
"input": {}
}
Response:
{
"output": null
}
Apparently, the call towards the API generated against the solidity created getter functions for the public variable greeting
works fine
POST
/query/greeting
input
{
"input": {}
}
Response:
{
"output": "bonjour"
}
I am able to get the proper response when I tried interacting with the node directly with an eth_call
and also with ethers.js
providing the ABI. I tried with a couple of other contracts as well and all have the same problem.
I am also unable to get any errors reported in evmconnect
service.
docker logs scip-local-besu_evmconnect_0 2>&1 | egrep eth_call
[2023-05-18T11:56:42.760Z] DEBUG evmconnect: RPC[000012690] --> eth_call httpreq=iFkO1c7K req=_tVwslnH
[2023-05-18T11:56:42.768Z] INFO evmconnect: RPC[000012690] <-- eth_call [200] OK (8.06ms) httpreq=iFkO1c7K req=_tVwslnH
[2023-05-18T12:00:51.034Z] DEBUG evmconnect: RPC[000013479] --> eth_call httpreq=xWwHFfg3 req=mF9p5IQk
[2023-05-18T12:00:51.043Z] INFO evmconnect: RPC[000013479] <-- eth_call [200] OK (8.59ms) httpreq=xWwHFfg3 req=mF9p5IQk
[2023-05-18T12:01:02.588Z] DEBUG evmconnect: RPC[000013516] --> eth_call httpreq=REb2E9Yp req=gtizpjTN
[2023-05-18T12:01:02.596Z] INFO evmconnect: RPC[000013516] <-- eth_call [200] OK (8.46ms) httpreq=REb2E9Yp req=gtizpjTN
[2023-05-18T12:01:07.424Z] DEBUG evmconnect: RPC[000013533] --> eth_call httpreq=BzXxI3Ce req=DyVGEOuE
[2023-05-18T12:01:07.432Z] INFO evmconnect: RPC[000013533] <-- eth_call [200] OK (7.88ms) httpreq=BzXxI3Ce req=DyVGEOuE
[2023-05-18T12:02:48.192Z] DEBUG evmconnect: RPC[000013851] --> eth_call httpreq=98pbrWWM req=JLSlyc0B
[2023-05-18T12:02:48.204Z] INFO evmconnect: RPC[000013851] <-- eth_call [200] OK (11.98ms) httpreq=98pbrWWM req=JLSlyc0B
[2023-05-18T12:07:40.997Z] DEBUG evmconnect: RPC[000014780] --> eth_call httpreq=sriA_acw req=8h1l77Ud
[2023-05-18T12:07:41.005Z] INFO evmconnect: RPC[000014780] <-- eth_call [200] OK (7.40ms) httpreq=sriA_acw req=8h1l77Ud
@joshtharakan Merged a PR recently that fixed the above problem https://github.com/hyperledger/firefly/pull/1333 - let me know if you are still hitting the issue