Using 'Light' or limited nodes for wallet

Development and Technical Discussion
#1

In think topic let’s think about the strength of the network and using of limited nodes.

About this problem:

There are multiple of examples of using the light or limited nodes with a wallet. There are examples:

  • Grin has discussion about the ‘light’ node. It looks great form the mobile devices, not much power needed to run it. But with node will not be able to participate in the Sync model. Please note, so far it is not implemented.
  • Beam announced the ‘light’ node, it is part of the latest mobile wallet. Such nodes can’t participate in the sync, they can only consume the traffic, but can’t provide it.
  • Our QT wallet embedded node that runs without the TOR. Normally user runs QT wallet behind the firewall, so node unable to accept the connections. Even it has the full data, it can’t provide it.

Example of what can happens if we go this direction.

Currently Dogecoin mainnet is suffering with sync. In the node logs I see that about 90% of the peers height is below the tip and majority of the nodes rejecting connection. The testnet is doing fine. As result I was able to sync with testnet without problems, but for the mainnet that will take probably weeks.

This problem happens because Doge wallet run a node exactly as our old QT wallet without the TOR. As a result most users runs wallet behind the router firewall (nobody want to setup port forwarding), IP6 is not supported as well. As a result the nodes with public IPs are overloaded.

Doge dev team is aware about that but there is nothing what they can do. New wallets are not able to sync. They suggest retrieve wallet private keys and migrate to the wallets that are using public node (it is now our QT wallets runs majority of our users). I think Doge devs see that it is impossible for them to deploy so many nodes with public IPs. Also this makes network centralized because nodes with public IPs will run under the same service provides like AWS.

The most ironic that this situation happens because of the recent pump. Pump happens, more users come and install the wallet. And those new wallets killing the network.

The conclusion

Unless new wallets doesn’t contribute to the network strength, this situation will be applicable to any coin. Since “light” or limited nodes doesn’t contribute to the network strength but instead make it overloaded, it is wrong way to go. The wallet node must be full node that can accept the connections. Light alternative can be public node.

I think we can even rephrase that it is impossible to build large scale decentralized network if wallet nodes are not full nodes that can accept connections.

4 Likes
#2

I completely agree, a strong decentralized network need multiple nodes and if users run wallets without nodes it weaker network performance, and resilience.

1 Like
#3

Would you propose to go with TOR as default?

How to achieve that?

#4

In current release if TOR activated, the node will run on the tor as well.
And with TOR node can accept income connection.
So far if tor activated we are good. The project is going in right direction.

This post is about possible solutions that we discuss sometimes. There are projects about light nodes because there are bunch of benefits. I think we need to understand the another side of that.

#5

Not sure but aren’t mobile Wallets (and hence nodes) unreliable anyway? Like I most likely won’t pull the chain from a mobile wallet will I? They are likely to go offline when the wallet is closed I’d assume.

For “non-mobile” Wallets internal Nodes behind TOR would be preferable imho, maybe it’s worth thinking of “light nodes” in the context of mobile wallets only?

#6

@anon99538168, the mobile node can be online most of the time. We did some testing, tor and mwc713 was online. Android put them to sleep for tenth of seconds, but they are still online and works fine. Unless user turn off the wallet, it runs in the background. We are going to try optimize the node, so it will consume less resources. For example, transaction pool can be cut off and it consume a lot of CPU.

But even if node goes offline / online it is still important if it can supply the data. I think from scalability point switching on/off doesn’t change much.

1 Like
#7

Oh thats cool. Well then a full Node would be prefferable if feasible ofc.
I somehow assumed Android would “kill it” if inactive, but great to know that works =)

#8

Yes, Android will kill if it need more RAM for OS. Our goal to make it light enough so modern Android devices will have enough RAM