More Extensible Multiaddress Format

[shawntabrizi]

This PR introduces a more extensible MultiAddress format for Substrate that can be used to wrap multiple different address identifiers for an underlying AccountId:

• Index
• Raw Bytes (like an encoded string)
• 20 bytes (ETH)
• 32 bytes (like a 256 bit hash)

Ultimately this replaces and deprecates the less extensible and custom encoding format provided by the Indices pallet.

This now allows for a chain to have multiple different address formats for a single AccountId, specifically in conjunction with the StaticLookup trait that can be used to convert from one address format to the underlying AccountId.

This is relevant for things like a name service pallet, or even could make runtime integration with the EVM pallet more simple.

This also updated the Substrate Node Template to use the MultiAddress format by default, allowing it to easily upgrade to alternative lookups in the future if it wants and to keep the types the same between the Node Template and the Node!

This is a breaking change for any front-end to runtime communication using the old indices format since the encoding format of these multiaddresses have now changed.

cc @jacogr @gavofyork

[xlc]

This is super useful for evm integration.

Should have a way to provide multiple lookup sources. So we can do

impl frame_system::Trait for Runtime {
	type Lookup = (Indices, Evm, NameService);

[shawntabrizi]

@xlc do you know if there is a better way to do this?

20d1a70

/// Perform a StaticLookup where there are two lookup sources of the same type.
pub struct TwoStaticLookup<A, B>(PhantomData<(A, B)>);
impl<A, B> StaticLookup for TwoStaticLookup<A, B>
where
	A: StaticLookup,
	B: StaticLookup<Source = A::Source, Target = A::Target>,
{
	type Source = A::Source;
	type Target = A::Target;

	fn lookup(x: Self::Source) -> Result<Self::Target, LookupError> {
		let a = A::lookup(x.clone());
		if a.is_ok() {
			return a
		} else {
			B::lookup(x)
		}
	}
	fn unlookup(x: Self::Target) -> Self::Source {
		A::unlookup(x)
	}
}

I have things compiling and seemingly working on my name service PR.

Unfortunatley I dont think the impl_for_tuples! macro will work here...

[xlc]

Can't figure out how to get impl_for_tuples working but this is my take

impl<A, B> StaticLookup for (A, B)
where
	A: StaticLookup,
	B: StaticLookup<Source = A::Source, Target = A::Target>,
{
	type Source = A::Source;
	type Target = A::Target;

	fn lookup(x: Self::Source) -> Result<Self::Target, LookupError> {
		A::lookup(x.clone()).or_else(|_| B::lookup(x))
	}
	fn unlookup(x: Self::Target) -> Self::Source {
		A::unlookup(x)
	}
}

and type Lookup = (Indices, (NameService, NameService));

I think this is good enough.

[athei]

Why is this change? The old code has less duplication. Or did it stop working for some reason?

[shawntabrizi]

I think it was just me being explicit. If there is no different, i would personally prefer explicitness. Else, if there is good reason to keep it the same, i dont really care about this change.

[athei]

Personally, I would always prefer writing things as generic as possible and thus reducing code churn when a refactoring is made. Ultimately it is your decision. I just pointed it out here because I thought you made this change by mistake.

[shawntabrizi]

bot merge

[ghost]

Trying merge.

[Felix0301]

Hi all,
Is this a backwards breaking change in relation to transaction serialization?

[Felix0301]

Hi all,
Is this a backwards breaking change in relation to transaction serialization?

=> Yes it is . Clearer communication around breaking changes is super important for developers working on wallet implementations - there should be a preceeding documentation specifying serialization and a change description, not just a code change that introduces breaking changes. Crucial to support and incentivice independent development.