Full node in browser?

1

Hello,
I’m going to create a simple p2p application, and I would like to use blockchain as a secure, integral, transparent,…, storage—nothing fancy, just a consensus layer for common knowledge. On top of that I’m going to implement an MPC to compute some crypto protocol

I would like the app to be completely peer-to-peer and hence, to run in browsers on both laptops and smartphones.
I’m wondering if it’s possible using Substrate? Have anyone tried to do it?

Do you know some project that did it? Or can you suggest to me how to achieve it?

2

Not exactly a fullnode but you don’t need a fullnode anyway: GitHub - smol-dot/smoldot: Alternative client for Substrate-based chains.

This is light client in browser implements p2p, storage, consensus, wasm exectuion and all other components necessary to run a light node in browser.

3 Likes
3

@xlc Thank you. What do you mean by “but you don’t need a fullnode anyway”?
We need in-browser nodes to be able to receive/store transactions and achieve consensus, without any help from external node. Are light-nodes (especially the client you provided) capable of that?

4

It can send transaction. It can download blocks. It can perform header verification and perform wrap sync. It can execute block. What else do you need?

2 Likes
5

Ok, that would satisfy my needs :slight_smile:
One more question. In “normal” substrate I join a node via

./target/release/node-template \
  --base-path /tmp/node02 \
  --chain ./customSpecRaw.json \
  --port 30334 \
  --ws-port 9946 \
  --rpc-port 9934 \
  --telemetry-url 'wss://telemetry.polkadot.io/submit/ 0' \
  --validator \
  --rpc-methods Unsafe \
  --name MyNode02 \
  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWKUC4dqmQWcgFUYMh4SXDdhM3hZ8C32HhZTJaNB32SakG \
  --password-interactive

How to connect a browser node using smoldot? There is no such API allowing me to specify keystore/ports etc? How to create a private smoldot-to-smoldot network?

6

What exactly do you mean by “How to connect a browser node using smoldot?” ?

This could be useful for you https://docs.substrate.io/fundamentals/light-clients-in-substrate-connect/

You don’t need to specify port because that doesn’t make sense in the context of a browser application.

Smoldot is just a light client and therefore you don’t create network from it. It can’t produce block. You use Substrate to create network and smoldot client can join this network.

7

Ok, I understand, smoldot is just a light client—a passive node.

My original question was to create a blockchain network using only browser clients.
I need to host an ad-hoc blockchain that can last for a few hours and can work without external nodes. Pure browser-to-browser setting. That’s why I explicitly said that it should be a full node.

8

Creating a blockchain with only browser-based nodes is a very bad idea. Reasons include:

  • The only way for browser nodes to connect to each other is the WebRTC protocol. However, you need to bootstrap this using a non-browser-based server (a STUN server) that acts as a rendez-vous point. Every node that joins the network needs to first talk to this non-browser-based node. A network with only browser nodes can’t exist.
  • Full nodes need to store the state of the chain (the state of the chain doesn’t exist out of thin air, it needs to be stored somewhere). While the state of a demo chain is a few kilobytes, the state of for example Polkadot and Kusama are several Gigabytes.
  • When a browser tab is in the background, the browser slows down all the scripts (see this or this). While it is maybe not strictly impossible to create a full node that exists despite this throttling, it clearly would not work very well, and my guess is many block slots would be missed once you have more than 3 or 4 validators.
  • In the context of parachains consensus, it is necessary for specific validator nodes to be reachable by certain other nodes. In other words, not everything is done by gossiping. It is not really possible to guarantee that when the node is within a browser.

As a small toy it would work. In the real world, it wouldn’t.

1 Like
9

Thank you for the reply.

    1. The STUN server is an acceptable workaround. However, I’m wondering if it’s required by WebRTC itself, or if it’s just a solution to the problem with NATs? If the bootstrap node has a publicly accessible IP, would WebRTC work without STUN?
    1. and 3. We expect a super lightweight ad-hoc blockchain, each time started from scratch, with a maximum of 100 transactions over a few hours period. So in the optimistic scenario (if we assume even distribution), even one transaction per minute would work.
    1. We don’t need to connect to Polkadot.

“As a small toy it would work.” That’s fine for now. The question is how to do it without implementing everything on our own. I asked lib2p team and ironfish and WebRTC is not ready yet.

10

I’m not going in the details, but the WebRTC protocol requires the two parties that want to connect to each other to exchange some information in one way or another prior to connecting through WebRTC. This can only happen either if one party isn’t a browser node, or if both parties exchange information through a third party (that isn’t a browser node).

But we know that it will never work for anything that isn’t a toy. There’s no “for now”. The problems I mention will never be solved.

If you want to spend hundreds of hours working on something that we know will break down for any non-trivial chain, feel free to do so, but as the maintainer of smoldot I don’t really want to.

1 Like
11

Ok, thank you. We can cope with one non-browser node.

What is a toy for you may be a sufficient solution for others.
The problems you mentioned won’t be solved, but as I pointed out they do not apply to my project.