I started using serde for #25 and discovered that the combination of serde, pwasm-abi-derive and no_std does not work. serde can be compiled with no_std support but pwasm-abi-derive uses serde with std. Altough pwasm-abi-derive is a proc macro it uses the same serde configuration as the library, i.e. the no_std configuration. This results in an error when compiling pwasm-abi-derive. (This issue is a known cargo bug.)
To solve this issue we can drop either of the three.
Dropping serde
As outlined in #25 we need a serialization mechanism to store structured data in the key value store that the protocol (currently parity ethereum) provides. I’m not aware of any alternative to serde that has a comparable feature set and no_std support.
Dropping pwasm-abi-derive
The pwasm-abi-derive crate provides a macro to create Ethereum ABI compatible glue code from a Rust trait. This eliminates the need to write this glue code or similar dispatching logic ourselves and provides interoperability with the Web3 client.
If we drop pwasm-abi-derive we need to implement this glue code for the the ledger as well as the client.
Dropping no_std
Compiling the ledger without no_std to the wasm32 target works in theory as long as we don’t use OS features.
However a trial revealed that the size of the generated Wasm deployment code exceeded the initial memory of 2 pages. This results in a failure when the contract is deployed. To address this issue we need to patch wasm-utils so that pack_instance makes sure that enough memory is provided.
Another problem is that serde withtout no_std generates code that involves floating point computations. These are rejected by Parity Ethereum when inject_gas_counter is called. (This is not intuitive and results in a “bytecode invalid” error.) This can be changed by removing .with_forbidden_floats() from the rule set
I started using
serde
for #25 and discovered that the combination ofserde
,pwasm-abi-derive
andno_std
does not work.serde
can be compiled withno_std
support butpwasm-abi-derive
usesserde
withstd
. Altoughpwasm-abi-derive
is a proc macro it uses the sameserde
configuration as the library, i.e. theno_std
configuration. This results in an error when compilingpwasm-abi-derive
. (This issue is a knowncargo
bug.)To solve this issue we can drop either of the three.
Dropping
serde
As outlined in #25 we need a serialization mechanism to store structured data in the key value store that the protocol (currently parity ethereum) provides. I’m not aware of any alternative to serde that has a comparable feature set and
no_std
support.Dropping
pwasm-abi-derive
The
pwasm-abi-derive
crate provides a macro to create Ethereum ABI compatible glue code from a Rust trait. This eliminates the need to write this glue code or similar dispatching logic ourselves and provides interoperability with the Web3 client.If we drop
pwasm-abi-derive
we need to implement this glue code for the the ledger as well as the client.Dropping
no_std
Compiling the ledger without
no_std
to the wasm32 target works in theory as long as we don’t use OS features.However a trial revealed that the size of the generated Wasm deployment code exceeded the initial memory of 2 pages. This results in a failure when the contract is deployed. To address this issue we need to patch
wasm-utils
so thatpack_instance
makes sure that enough memory is provided.Another problem is that
serde
withtoutno_std
generates code that involves floating point computations. These are rejected by Parity Ethereum wheninject_gas_counter
is called. (This is not intuitive and results in a “bytecode invalid” error.) This can be changed by removing.with_forbidden_floats()
from the rule set