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.

[kianenigma]

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.

This trait is indeed the correct way to solve this issue; It is a way for a runtime to express across itself, and its metadata, what kind of hashing it uses.

https://github.com/polytope-labs/hyperbridge/blob/da97a78e0a6561b83dbfd2b9e9fee3a3e30bb3dd/parachain/runtimes/nexus/src/lib.rs#L343

This trait is bounded to be type_info, so it should be possible to express it in the metadata, though I do not know off the top of my head if it is present in it. It will become present in the metadata, if some other dispatchable/storage uses <T as frame_system::Config>::Hashing as its return type.

We can explore a more convenient way to make sure such a type is in the metadata.

[tomaka]

This trait is bounded to be type_info, so it should be possible to express it in the metadata,

You can't access the metadata without knowing the hash function(s) first.
(unless you rely on huge hacks such as trying to sync the chain multiple times, once per possible hash function)

EDIT: in the case of a chain spec that contains for example the full state of a block, we could indeed access the metadata without knowing the hash function, as we know for sure that the block is valid. However, smoldot can accept chain specs that contain just the finalized block hash (and a few more things) then downloads the block from the peer-to-peer network, in which case the hash algorithm has to be known in order to proceed.

[josepot]

However, smoldot can accept chain specs that contain just the finalized block hash (and a few more things) then downloads the block from the peer-to-peer network, in which case the hash algorithm has to be known in order to proceed.

In fact, in the case of parachains: smoldot only requires the "stateRootHash". So, even more of a reason for the chainspec to be standarized and to include a property that defines the hashing function.

[kianenigma]

This trait is bounded to be type_info, so it should be possible to express it in the metadata,

You can't access the metadata without knowing the hash function(s) first. (unless you rely on huge hacks such as trying to sync the chain multiple times, once per possible hash function)

EDIT: in the case of a chain spec that contains for example the full state of a block, we could indeed access the metadata without knowing the hash function, as we know for sure that the block is valid. However, smoldot can accept chain specs that contain just the finalized block hash (and a few more things) then downloads the block from the peer-to-peer network, in which case the hash algorithm has to be known in order to proceed.

Okay, so your EDIT clarified things for me. I was only considering a classic chain-spec, which contains the full block state, or better said, at least it contains the :code, from which you should be able to get the metadata.

Where can I see the format of this type of "partial" chain-spec?

[josepot]

Where can I see the format of this type of "partial" chain-spec?

RelayChain example.

ParaChain example.