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
Version conflicts with primitive-types and Dependencies on ethereum/evm
Polkadot SDK now depends on [email protected], but the latest published versions of ethereum and evm crates still depend on [email protected]. This results in incompatibilities for types like H256, U256, and others between Polkadot SDK and Frontier.
Currently, the only person with publishing rights for the ethereum crate is @sorpaas, but it seems that he is not actively engaged in its maintenance. IMHO, if @sorpaas consents, one of the Frontier maintainers should be added as a co-maintainer for the ethereum/evm crates. Alternatively, forking those crates could be considered as a viable option.
Given the long-term maintenance requirements of tracking changes to Ethereum hard forks, another approach to consider might be supporting revm together.
Extrinsic V5 and the future of SelfContainedCall
In Extrinsic V5, verifying signatures has be separated into a TransactionExtension (superseding SignedExtension), allowing the functionality previously handled by SelfContainedCall to be implemented as a TransactionExtension.
I investigated supporting backward compatibility regardless of removing wrapping types of (Checked|Unchecked)Extrinsic, but I couldn't find a straightforward way to invoke call.apply_self_contained() instead of call.dispatch(). As a result, separate extrinsic types would still be required.
However, for chains launching from scratch without the need to support existing extrinsics, adopting the V5 format from the beginning could allow TransactionExtension to handle functionality previously implemented via SelfContainedCall. While supporting SelfContainedCall may still be necessary, it should be considered for deprecation.
The text was updated successfully, but these errors were encountered:
Version conflicts with
primitive-types
and Dependencies onethereum
/evm
Polkadot SDK now depends on
[email protected]
, but the latest published versions ofethereum
andevm
crates still depend on[email protected]
. This results in incompatibilities for types likeH256
,U256
, and others between Polkadot SDK and Frontier.Currently, the only person with publishing rights for the
ethereum
crate is @sorpaas, but it seems that he is not actively engaged in its maintenance. IMHO, if @sorpaas consents, one of the Frontier maintainers should be added as a co-maintainer for theethereum
/evm
crates. Alternatively, forking those crates could be considered as a viable option.Given the long-term maintenance requirements of tracking changes to Ethereum hard forks, another approach to consider might be supporting
revm
together.Extrinsic V5 and the future of
SelfContainedCall
In Extrinsic V5, verifying signatures has be separated into a
TransactionExtension
(supersedingSignedExtension
), allowing the functionality previously handled bySelfContainedCall
to be implemented as aTransactionExtension
.I investigated supporting backward compatibility regardless of removing wrapping types of
(Checked|Unchecked)Extrinsic
, but I couldn't find a straightforward way to invokecall.apply_self_contained()
instead ofcall.dispatch()
. As a result, separate extrinsic types would still be required.However, for chains launching from scratch without the need to support existing extrinsics, adopting the V5 format from the beginning could allow
TransactionExtension
to handle functionality previously implemented viaSelfContainedCall
. While supportingSelfContainedCall
may still be necessary, it should be considered for deprecation.The text was updated successfully, but these errors were encountered: