During the dev call today, we talked about future connectivity options, in relation to the goal of reintroducing LES, introducing ULC and decreasing reliance on any single point of failure.
During the call, several observations were made:
infura provides good service, but we don’t want to rely on it exclusively
LES takes a long time to boot up, hard to find free spot
ULC needs trusted setup or M/N
vipnode is one way of getting connectivity
additional ways of connecting to ethereum may appear (websockets? libp2p, etc)
we’re not sure what works best for our users - or under which conditions (connectivity, power, etc)
we’re happy to host some servers ourselves as a way of providing service to the ethereum network as a whole, but we don’t want to be the only ones running these nodes, as this makes us the single point of failure (we become infura, but worse)
need to be careful so that our app has les slots to connect to / some form of connectivity - these might get filled up by other network participants → need to encourage more free les slots on the network generally
mist recently added a clever feature called Layered Nodes whereby it uses both infura and an ordinary ethereum node to provide connectivity - this is good UX in the sense that the user can start using the application immediately, but in case infura is compromised / stops working, the application continues to work
Now seems like a good time to brainstorm around options for this issue, to build a shared sense direction or plan as to where we want to go with this - here are some good questions to begin with:
what are the properties of the various connectivity options, in terms of bandwidth, security, power consumption, threat model etc?
how do we present the various connectivity choices to users? should they be able to pick and choose?
should we establish a hierarchy of connectivities where some are “better” than others? by what criteria? are these conditional (“connected to wifi / connected to power source”)?
should we allow transactions / economic activity / chat when we’re in “degraded” mode?
how do we present the current connectivity status to users?
what happens when connectivities disagree as to the current state of the network?
I think there is one more option that can give us advantagers from Infura and ULC both. We can use Infura for write side(transactions) and ULC for read side.
ULC servers have a new option ‘onlyAnnounce’ that switch les server in ‘only for sync mode’ and rise user limit from ~100 to +600. It can be useful for read side. And ULC can give us better API than Infura (eg. filters without any hacks).
Infura can be used for write side and if it is not available at the moment we can quickly add one untrusted node without onlyAnnounce to user’s app node and handle write site in LES.
I think we need to start there.
Theoretically, I don’t see how LES/ULC client might affect the application performance and energy efficiency very much. Why I think that way? We already have static peers, heartbeat and traffic that Whisper uses. If Whisper static nodes and LES servers will be the same, it won’t add any additional connections, because the same underlying p2p mechanism is used. It will only add traffic.
Practically, I’m pretty sure there are a lot of implementation quirks that make LES less efficient than Infura (or other RPC endpoint).
Yes, probably. But that would heavily depend on what issues we find in the implementation. Connectivity and limited traffic will probably be a big issue there.
As a side note: chat is standing separate there, sure it uses the same P2P mechanisms, but it has nothing to do with ULS or LES or ETH or RPC per se.
@petty was asking a similar question the other day - do we consider chat to be part of the “secure” package, along with transactions? also, while it stands separate, some of the same questions apply - what can a bad node do? censor traffic? track mailserver replay requests? etc…
Yes, all these questions are valid for the chat, but it doesn’t have Infura. Hence, any hybrid solution won’t work there.
Otherwise, it isn’t different from the blockchain client itself, that’s true.
Whisper on its own is a totally separate from the transactions, keys and network. However, if we consider:
using the same keys for wallet and Whisper,
introducing incentivization layer on top of Whisper,
the perspective might be distorted.
There is an idea to use different keys for wallet and Whisper, so the first point would be solved.
Regarding the incentivization, it depends on the implementation. However, I believe it’s possible to implement in a way that nodeID is all what will be needed to handle clients and payment will be done using a separate, from messaging, channel.
Having said that, I think we should treat messaging and transactions as two separate systems and have different security characteristics but there will always be common parts until Whisper and Ethereum stop sharing the same stack (which I believe should happen).
also, while it stands separate, some of the same questions apply - what can a bad node do? censor traffic? track mailserver replay requests?
Censor traffic – yes, but only if all connected Whisper peers do that collectively. MailServer uses direct p2p connection to communicate with a client so replies can’t be tracked. However, MailServer can be a bad node itself, then some metadata can be collected. Messages are always safe.