Consider non-zero default nonce

[ggwpez]

New or resurrected accounts use Nonce::default() that returns 0 in the Polkadot runtime.
We could change this to return the current block number, to avoid replay of immortal transactions.

Any downsides? Yea, its slower but nothing else i think.

[bkchr]

Yeah sounds good. We can include it in 1.3.0.

[kianenigma]

and once paritytech/polkadot-sdk#1557 is merged and release I suppose?

[ggwpez]

and once paritytech/polkadot-sdk#1557 is merged and release I suppose?

We can do it without that actually.

[kianenigma]

New or resurrected accounts use Nonce::default() that returns 0 in the Polkadot runtime.
We could change this to return the current block number, to avoid replay of immortal transactions.

Ah so you are suggesting a newtype for nonce with custom Default impl? yes, makes sense.

[xlc]

This will confuse block explorer and indexer

[bkchr]

This will confuse block explorer and indexer

Why? I think the problem is bigger for wallets.

[bkchr]

@ggwpez do you still want to tackle this?

[athei]

This will confuse block explorer and indexer

Why? I think the problem is bigger for wallets.

If it is a problem at all.

Having this functionality will become more important when adding Ethereum compatibility: Eth transactions are immortal.

[kianenigma]

We should do this. the Type added in https://github.com/paritytech/polkadot-sdk/pull/4034/files#r1829220430 has an issue that it derives the default TypeInfo, which as said will confuse the explorers. We need a similar custom type, but with a manual TypeInfo impl that would keep it identical in the metadata. Then no explorer or wallet would have any issues.

[bkchr]

Having this functionality will become more important when adding Ethereum compatibility: Eth transactions are immortal.

What? We are going to inherit the ETH transaction format? Why? Please don't say "metamask".

[athei]

In order to support Ethereum wallets you need to accept their transactions. This what they sign. Of course we can build our own transaction format but that won't make existing Dapps compatible. See, I didn't even say the M word.

[bkchr]

But I thought for this snaps exists? So you can extend the big M?

So, we will only support their tx? But will not have a ETH compatible state root etc or?

[athei]

But I thought for this snaps exists?

Requirement is that it works without having the user to install anything. Also, it would be another thing to maintain. We might as well just support it as-is. Both frontier and Acala are doing that, too. We try to be as compatible as possible.

So, we will only support their tx?

No. You can still call pallet_revive via normal extrinsic. Both is supported. However, Dapps written against any Ethereum javascript library will submit Ethereum style transactions. There is nothing we can do about it.

Theoretically, we could require a custom transaction format and have that signed by Metamask using https://eips.ethereum.org/EIPS/eip-712. However, supporting the legacy transaction formats makes sure that it works everywhere. Without that it would mean that existing javascript libraries work as is. A whole lot more work for us to provide wrappers for all of them. Apart from the missing mortality I don't see a big reason why not to. Especially if we can initialize the nonce to the block number as proposed here.

So, we will only support their tx? But will not have a ETH compatible state root etc or?

Yeah seems to be working for frontier and Acala. We just return our state root when somebody requests a block. Dapps just seem to be using this as identifiers if at all.

https://docs.metamask.io/wallet/reference/json-rpc-methods/eth_getblockbyhash/
https://github.com/paritytech/polkadot-sdk/blob/a4791617241732f4fecafe21e12c16b7fe42f73e/substrate/frame/revive/rpc/src/client.rs?plain=1#L747-L773

Its not like there are any EVM light clients in production that would try to use them to verify a proof.

[kianenigma]

@ggwpez do you still want to tackle this?

Proposed this ticket to @re-gius. My suggestion to him, as noted above, is to not use the TypeWithDefault and instead use a custom new type with a manual implementation of TypeInfo. This should avoid any issues while decoding the nonce; from the outer world, the nonce is still u64.

[re-gius]

paritytech/polkadot-sdk#6562 should have fixed the Type Info. Now we need to wait for the next release, and then update the fellowship repo.