Add isEthereum to ChainProperties

[fgamundi]

Giving the growing number of Ethereum based substrate chains, the Tanssi team is proposing to add isEthereum to the chain properties so apps (such as polkadotjs-apps) can easily distinguish if the chain they're connecting to is Ethereum-based or not without having to maintain and update a manual list.

[jacogr]

This gets us half-way and is a great start.

With the chain properties, we have to ensure it is correctly decorated on the registry as well (so users can just use registry.chainProperties() instead of via RPC, you no doubt saw that apps doesn't replicate all the logic again).

This part is done in the registry (where it also combines existing on-chain constants - always taking precedence, hence not applying that in eg. apps), you can find it here -

api/packages/types/src/create/registry.ts

Lines 154 to 167 in 47df39e

	// extract additional properties from the metadata
	function extractProperties (registry: TypeRegistry, metadata: Metadata): ChainProperties | undefined {
	const original = registry.getChainProperties();
	const constants = decorateConstants(registry, metadata.asLatest, metadata.version);
	const ss58Format = constants['system'] && (constants['system']['sS58Prefix'] || constants['system']['ss58Prefix']);
	if (!ss58Format) {
	return original;
	}
	const { tokenDecimals, tokenSymbol } = original || {};
	return registry.createTypeUnsafe<ChainProperties>('ChainProperties', [{ ss58Format, tokenDecimals, tokenSymbol }]);
	}

And here is where it is called/used -

api/packages/types/src/create/registry.ts

Lines 611 to 614 in 47df39e

	// setup the chain properties with format overrides
	this.setChainProperties(
	extractProperties(this, metadata)
	);

[fgamundi]

Hi @jacogr. Thanks for the review and explanation! I've updated the registry to set isEthereum

[girazoki]

@jacogr any news on this side? it would be important for us as we will start having chains that need addresses being represented in ethereum format

[jacogr]

Why are we using Option<Bool> instead of just Bool?

I looked through and cannot see specific benefit.

With Option<Bool>:

• if not specified it is isNone (which is equivalent to false)
• if specified, it returns isTrue or isFalse

With Bool:

• If not specified, it is isFalse
• if specified, it is either isTrue or isFalse

The benefit of using Bool is that we don't need to go through unwrapping magic on use, i.e. it is a straight flag check.

EDIT: It would also be useful to add a getter (like the other chain* retrievals) to the registry for chainIsEthereum(): boolean (This makes downstream usage aq walk in the park)

[jacogr]

Thank you.

[polkadot-js-bot]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.