Open hrls opened 1 month ago
After looking into how pallet macros work, this is what I got:
We have metainfo about the type of pallet call in form of scale_info::Type. This is type-erased tree-like form of the call itself and nested types metas. Some type names are plain text caption similar to those we see in code e.g. Balance<T>
, T::AccountId
. We need to recover the full path of type in order to use it. From this perspective I assume that the implementation will involve proc_macro
things. Not so much there, but it looks like it's doable.
Other things we need to form a usable precompile:
How to calculate gas and provide access to pallet state for these precompiles in derivable form are big open questions anyway.
As my conclusion: looks like we can build EVM ABI and call the pallet from proxy precompile. But to complete this solution we still need additionals like gas math, state access, some utils and stuff. Implementation of fully derivable proxy pallet is tricky if even possible.
@ales-tsurko @yarsawyer
Can we generate a normal precompile (like, for example, when we write one) using macro? I mean, could we take the runtime, when we configure it and extend it? Or make this inside a fork of pallet_evm
, as pallet_evm
already handles fees and precompiles.
Can we generate a normal precompile using macro?
Yes, but we limited only by call option to generate some info.
.. make this inside a fork of
pallet_evm
, aspallet_evm
already handles fees and precompiles.
TBD
Q: Is it possible to create/generate EVM precompile for an existing Substrate pallet?
Substrate runtime has introspection (both type-based and runtime metadata). We can try to build proxy precompile per pallet using its metadata (or some kind rust macro magic).
ABI for existing pallet probably is good start for proof-of-concept implementation.