Added support for renew and index host function

[x3c41a]

Added no-op implementation for both.

Relates to #2182

[bkontur]

@x3c41a please also at the end

[x3c41a]

done

[bkontur]

@x3c41a By the time this gets merged, can we just build/install it locally (somehow) from this branch and use it in our JS/PAPI examples?

[x3c41a]

@x3c41a By the time this gets merged, can we just build/install it locally (somehow) from this branch and use it in our JS/PAPI examples?

Installing

Yes, so I've built local JS package and linked it:

cd smoldot
cd wasm-node/javascript
npm install
npm run build
npm link

Then I went to bulletin repo and linked newly build (and linked) local smoldot repo with:

cd bulletin-chain
cd examples
npm link smoldot

To make sure you did everything right, just run the following in bulletin repo and the result should be similar to:

ndk@PAR03612 examples % npm list smoldot
examples@ /Users/ndk/parity/polkadot-bulletin-chain/examples
├─┬ @polkadot-api/[email protected]
│ └─┬ @polkadot-api/[email protected]
│   └── [email protected]
├─┬ @polkadot/[email protected]
│ └─┬ @polkadot/[email protected]
│   └─┬ @substrate/[email protected]
│     ├─┬ @substrate/[email protected]
│     │ └── [email protected] deduped -> ./../../smoldot/wasm-node/javascript
│     └── [email protected]
├─┬ [email protected]
│ └─┬ @polkadot-api/[email protected]
│   └── [email protected] deduped -> ./../../smoldot/wasm-node/javascript
└── [email protected] -> ./../../smoldot/wasm-node/javascript

Testing

Once I made sure smoldot is linked to the build from my new branch, I started testing.
So I prepared this script that connects to Bob's chain (Alice does not work too) and reads storage and sends transaction. As well as added TRACE level logging to smoldot where I saw plenty of:

[smoldot:DEBUG] network: warp-sync-request-error; chain=local_testnet, target=12D3KooWQCkBm1BYtkHpocxCwMgR8yjitEeHGx8spzcDLGt2gkBm, error=Request(Substream(ProtocolNotAvailable))

and my transaction were timing out on chain_getHead calls so I think the issue persists.

That's my findings for now, I'll update the thread if I find anything interesting.

cc: @bkontur @tomaka

[bkontur]

@x3c41a very nice, so it looks like that this HostFunctions fix is working and we are one step further, so we need to solve other error ProtocolNotAvailable, right?

---

When I grep ProtocolNotAvailable in smoldot repo, there are just three references:
https://github.com/search?q=repo%3Asmol-dot%2Fsmoldot%20ProtocolNotAvailable&type=code, related to the Kademlia/litep2p/networking handling.

@x3c41a At least, what we could do, is to add some logs to the smoldot, to see what protocol is missing.

I am not that expert here, but maybe @dmitry-markin or @lexnv could know?

When I was debugging Bulletin logs with sub-libp2p=trace there were lots of protocols mentioned. Also please check the chain spec, there is "protocolId": "dot-bulletin", probably for local testnet it is "protocolId": null.

And also, we are at least adding some grandpa protocol for solochain:

       let grandpa_protocol_name = sc_consensus_grandpa::protocol_standard_name(
		&client.block_hash(0).ok().flatten().expect("Genesis block exists; qed"),
		&config.chain_spec,
	);

Most probably, the smoldot does not support Bitswap (yet?), because our Bulletin nodes start also Bitswap protocol streams, not sure if this could be an issue:

const PROTOCOL_NAME: &'static str = "/ipfs/bitswap/1.2.0";

---

• try to log missing protocol in smoldot
• try the smoldot example with
  • solochain (I think you used it here, right? - we are using custom node binary, maybe we are missing here anything, idk)
  • bulletin-westend parachain setup (I think this could possibly work, because it is regular parachain)

[x3c41a]

so it looks like that this HostFunctions fix is working and we are one step further

wow, good to hear 🚀
I thought we've hit a completely different and unrelated error

[x3c41a]

check the chain spec, there is "protocolId": "dot-bulletin", probably for local testnet it is "protocolId": null

Looks like it helped! Smoldot started sending responses back:
[smoldot:DEBUG] json-rpc-local_testnet: json-rpc-response-yielded; response={"jsonrpc":"2.0","id":4,"result":{"parentHash":"0x8999afae1f2a997c4e9113786ed1a69ce5b9034174b67556212bbbef1314000f","extrinsicsRoot":"0x4a10bb2bb15b70c51aafecd09cca72cfafb2b4ca9d1b239c950c5033ac33562b","stateRoot":"0xa27f6365ef94247cd2e03717b1e0f33a8…
🥳🎉

[x3c41a]

Writes work too ✅

[smoldot:DEBUG] json-rpc-local_testnet: json-rpc-response-yielded; response={"jsonrpc":"2.0","method":"author_extrinsicUpdate","params":{"subscription":"BbPKZPrNd1jzHXMyVXHA7HNkN1MocL3rXT2cC49vE1zQ","result":{"broadcast":["12D3KooWQCkBm1BYtkHpocxCwMgR8yjitEeHGx8spzcDLGt2gkBm"]}}}

...

[smoldot:DEBUG] json-rpc-local_testnet: json-rpc-response-yielded; response={"jsonrpc":"2.0","method":"author_extrinsicUpdate","params":{"subscription":"BbPKZPrNd1jzHXMyVXHA7HNkN1MocL3rXT2cC49vE1zQ","result":{"inBlock":"0x96f985ecdfd86f9b5e30e0a1742f99deb52c5d19252d1e383d4ab91c09ad0f09"}}}

I think we're good to go now!

[x3c41a]

mhm, I found another issue while implementing authorise and store with IPFS and PAPI - paritytech/polkadot-bulletin-chain#118

TL;DR: the content that we store with Smoldot + Bulletin can't be fetched back via IPFS
cc: @bkontur

[bkontur]

mhm, I found another issue while implementing authorise and store with IPFS and PAPI - paritytech/polkadot-bulletin-chain#118

TL;DR: the content that we store with Smoldot + Bulletin can't be fetched back via IPFS cc: @bkontur

That is the most probably not smoldot issue, let's focus here on merging these host functions and continue with other stuff in Bulletin PR/issue

[x3c41a]

most probably not smoldot issue

I am also unsure if it's smoldot issue or not thus decided to raise awareness before the PR is merged

[tomaka]

The no-op implementation is unfortunately problematic, because a Polkadot node might refuse a block when one of the two new functions is called with an invalid extrinsic index. However for the sake of pragmatism I think it's fine to merge anyway.

[x3c41a]

@tomaka how does release process look like from smol-dot side? what's the ETA for this change to go live? Thank you!

[tomaka]

New versions have already been published.