You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, all Ethereum Solidity types either Signer or Unsigned of any size are serialized to substreams::scalar::BigInt. This hinder a performance hit because arithmetic on pure native types would be much faster.
The goal of this task is to change the type generated in Rust for solidity Signed/Unsigned integers so they are aligned to the closest native type that support it.
For example:
int8 -> i8
int16 -> i16
int24 -> i32
...
(same with unsigned).
If bit size > 64, then we would render BigInt as before.
This will be a major breaking change as anyone with such ABI will generate new code using primitive types so it will drastically change their usage.
Maybe we should think about providing a backward compatibility option to the macro and codegen tool always_bigint=true (something like that) so that an easier update path is available.
The text was updated successfully, but these errors were encountered:
Right now, all Ethereum Solidity types either Signer or Unsigned of any size are serialized to
substreams::scalar::BigInt
. This hinder a performance hit because arithmetic on pure native types would be much faster.The goal of this task is to change the type generated in Rust for solidity Signed/Unsigned integers so they are aligned to the closest native type that support it.
For example:
If bit size > 64, then we would render BigInt as before.
This will be a major breaking change as anyone with such ABI will generate new code using primitive types so it will drastically change their usage.
Maybe we should think about providing a backward compatibility option to the macro and codegen tool
always_bigint=true
(something like that) so that an easier update path is available.The text was updated successfully, but these errors were encountered: