status-im
/
status-react
mirror of https://github.com/status-im/status-react.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
status-react/doc/decisions/0003-geth-node.md

3.4 KiB
Raw Blame History

0003. Geth node for Beta

Date Tags
2018-05-14 architecture, p2p, scope

Status

proposed

Context

On the path to releasing a usable beta we've faced a variety of performance issues:

Some of these performance issues are related to the use of LES, especially on Mainnet. Examples of problems include: slow/hot sync, disk filling up, bandwidth usage, etc. This can partly be remedied by the use of CHT to speed up sync (https://github.com/status-im/status-go/wiki/Updating-CHT-BloomTrie).

In order to simplify the problem, we decided earlier this year to not spend too much time looking into performance improvements related to LES, instead focusing our efforts on improving the performance on Whisper and in client-side code.

This also means we don't have a full picture of to what extent LES is a performance bottleneck for the Status app. It is possible proper use of CHT, slowing sync down, vary load depending on if you are on WiFi or not, etc, can solve these problems. However, the consensus right now is that ULC is the more promising route to take.

However, since ULC isn't ready yet, this means we are relying on Infura. This is a bad idea from a decentralization and security point of view. This can be partly remedied by allowing the user to run an upstream node. It is still a bad trust model, relying on third-party Ethereum nodes, and we want to get away from this as soon as possible.

With ULC it is possible to connect to more than one node, which increases decentralization and security.

Decision

  1. Rely on upstream nodes for beta. For the closed beta scheduled to be releases Q2 we will provide two ways of accessing the Ethereum network:

From a decentralization point of view we need the latter before we can release the beta.

  1. ULC MVP. Additionally, as soon as beta is released, assess and start to introduce ULC as an experimental non-default mode in the app.

By doing this we also support the network, since it is still a very new protocol. ULC requires trusted peers to operate, and right now trust is established by config (list of trusted peers).

Initially we could hardcode these nodes, with option to add your own. Later on we can have some form of distributed directory with a rating system. This also likely requires merging ULC upstream, so we aren't the only ones running trusted nodes.

  1. LES track (optional). If we still have resources and there's interest, optionally run a parallel track to clean up LES usage (update CHT, cluster) and understand exact performance impact and viablity of running LES on resource-constrained devices.

These three decisions balances the following trade-offs:

  • get a usable beta released as soon as possible
  • provide users with options to get minimal amount of decentralization
  • pave the way for trustless usage by default (ULC/LES node)

Consequences

Most of this is captured above.

    1. Make sure custom upstream RPC is in beta and works
    1. Disable LES from beta release as it currently doesn't work reliably
    1. Continue work on https://github.com/status-im/ideas/pull/254/files, consider adding more resources to get it into MVP state as soon as possible