(fix) Pass strings to scilla as strings, rather than arrays of their bytes

[rrw-zilliqa]

Fixes #2163

[rrw-zilliqa]

(note that I don't allege that this is the right fix - just that it works for my use case!)

[github-actions]

Bencher Report

Branch	users/richard/2163-passing-strings-to-scilla
Testbed	self-hosted

Click to view all benchmark results

Benchmark	Latency	Benchmark Result milliseconds (ms) (Result Δ%)	Upper Boundary milliseconds (ms) (Limit %)
full-blocks-erc20-transfers/full-blocks-erc20-transfers	📈 view plot 🚷 view threshold	970.60 ms (-9.31%) Baseline: 1,070.19 ms	1,362.22 ms (71.25%)
full-blocks-evm-transfers/full-blocks-evm-transfers	📈 view plot 🚷 view threshold	366.72 ms (-10.77%) Baseline: 410.97 ms	502.04 ms (73.05%)
full-blocks-zil-transfers/full-blocks-zil-transfers	📈 view plot 🚷 view threshold	3,295.80 ms (-16.48%) Baseline: 3,946.18 ms	5,341.31 ms (61.70%)
process-empty/process-empty	📈 view plot 🚷 view threshold	10.62 ms (+5.28%) Baseline: 10.09 ms	11.08 ms (95.90%)

🐰 View full continuous benchmarking report in Bencher

[JamesHinshelwood]

Would a transaction have been able to be mined with the previous behaviour? If so, we need to conditionalise this with fork configuration.

[rrw-zilliqa]

Would a transaction have been able to be mined with the previous behaviour? If so, we need to conditionalise this with fork configuration.

I don't believe so - the old code returned an array of bytes; if you could find an array of bytes which was valid JSON, then potentially yes, but I can't think of one. Happy either way, though - let me know if you want to add it?

[JamesHinshelwood]

I would ideally like to test this with the block replay support that I've recently implemented to verify it doesn't break existing transactions before we merge it.