Support runtimes that use keccak-256

[josepot]

I wasn't able to use smoldot for connecting to Hyperbridge (here is their chainspec). I assume that's because it uses keccak_256 (instead of blake2_256) as its hashing function.

Would it be possible to support chains that use keccak as their hashing function?

An idea would be to have a custom field on the chainspec with the name of the hashing function, and then if smoldot doesn't support it it would print an error.

[tomaka]

Saying that a chain "uses keccak as its hashing function" is a bit like saying that a video game console is 32 bits or 64 bits, it's really imprecise. Hashing functions are used for headers, but also trie nodes, seed phrases, SS58, and Babe slot determination.

Technically, yes, smoldot can support hash functions other than blake2 and we can technically make the hash function customizable. However, it's out of scope for smoldot to have primary support for anything else but the Polkadot/Kusama relay chains. If a parachain works similarly to the relay chain, then smoldot supports it, but if a parachain decides to randomly modify the way it works then smoldot won't support it.

[tomaka]

An idea would be to have a custom field on the chainspec with the name of the hashing function

I'm also against turning chain specs into the Polkadot equivalent of package.json where everyone randomly adds undocumented custom fields that only one implementation supports.

[josepot]

Sorry, I didn't explain myself correctly.

If a parachain works similarly to the relay chain, then smoldot supports it, but if a parachain decides to randomly modify the way it works then smoldot won't support it

What I meant to ask is wether it would be possible for smoldot to support chains that have been created with FRAME but that are using keccak-256 as the FRAME Hashing trait.

I understand that smoldot has to draw the line somewhere and it can't reasonably support every possible FRAME configuration. However, this strikes to me as a reasonable addition. In the sense that the parachain still works fairly similarly to the way that polkadot/kusama work, but it has customized this trait in FRAME.

I'm also against turning chain specs into the Polkadot equivalent of package.json where everyone randomly adds undocumented custom fields that only one implementation supports.

I completely agree with this. What about passing it as an optional property on the addChain config object? Eg:

const smoldot = start();
const relay = await smoldot.addChain({ chainSpec: relayChainSpec, disableJsonRpc: true });
const hyperbridge = smoldot.addChain({
  chainSpec,
  potentialRelayChains: [relay],
  hashing: "keccak_256", // it defaults to `blake2_256`
})

[tomaka]

What I meant to ask is wether it would be possible for smoldot to support chains that have been created with FRAME but that are using keccak-256 as the FRAME Hashing trait.

I have no idea what that trait does exactly. I care about how parachains work on a conceptual level, whereas this trait is some kind of high-level API for parachain developers.

[josepot]

I have no idea what that trait does exactly. I care about how parachains work on a conceptual level, whereas this trait is some kind of high-level API for parachain developers.

Thank you for the clarification. Let me rephrase my question: Would it be possible for smoldot to support a customizable hashing function in any context where blake2_256 is currently being used? Specifically, I believe the relevant areas are:

• Storage root
• Header hash
• Extrinsic hash
• Trie node hash

Do you think it would be feasible to provide this level of configurability? 🙏

[tomaka]

I completely agree with this. What about passing it as an optional property on the addChain config object? Eg:

This would just be a hack. The chain spec JSON is not just a parameter of addChain, it is the parameter of addChain. In other words, you should imagine addChain as a function that accepts 20 or so parameters, but since this would be cumbersome and difficult to use, it instead accepts a JSON version of these 20 parameters. The only exception of course being potentialRelayChains since they are JavaScript objects.