reusable `spec` generation crate for non-ink smart contract
Created by: extraymond
description
As a substrate developer using solang
, while solang have the ability to compile solidity as pallet-contract compatible bytecode, the abi for interacting with the front-end might not be parsed correctly, due to mismatch of schema of spec . https://github.com/hyperledger-labs/solang/issues/666
Therefore, it would be nice to have the same build procedure on spec generation. It could benefit solang or alternative compiler to conform to ink_metadata
instead of having to build their own type conversion schema. This could also allow tooling's around pallet-contract
to have more downstream users, since now there's less unexpected behavior interacting with contract tab and contract-ui.
required modification on ink side
assume ink_metadata as the standard:
- public several internal structs of
ink_metadata
, so other compiler can reuseConstructor
,Message
etc in their spec building process. - currently
MetadataVersioned
tookInkProject
as it's child property, if it's more loosely coupled, such asMetadataVersioned(T: Into<InkProject>)
, other tools could potentially just implementInto<InkProject>
for it's internal representation and allowink_metadata
to took over after that. - potentially move some of
ink_metadata
structs undercargo-contract
so it's less depending onink
, per the comment on solang's developer
solang's usage after this change
- if internal types of
ink_metadata
are public then solang could manually follow the generation steps and do type conversion from its side. - if
ink_metadata
can be decoupled without usingInkProject
directly, solang can just satisfied the trait and allowink_metadata
to do the generation for it's types.
Thanks for providing feeback for this use case on solang's side, hope I'm not missing anything @seanyoung @athei