If you’re a geek or like to dabble around with brand new shiny stuff, like the Ethereum EVM or Stellar Labs, read on.

I will take a look at both protocols in terms of TPS, block confirmation times and number of nodes, while paying close attention to each purpose and goals. I’ll add additional dimensions on the next instalment, when I conclude the analysis by identifying when you should pick Ethereum or Stellar.

*Don’t forget: one is not better or worse than the other. They serve different purposes.*

Ethereum

As stated by Vitalik himself, Ethereum’s goal is to be, in essence, a world computer.  Ethereum provides developers with the tools to build their own decentralised applications (Dapps), allowing a huge range of possibilities.

The purpose of Ethereum is to build a web 3.0, fully autonomous and decentralised, where users benefit from their contributions directly and data is privately owned and encrypted. The ultimate goal is for Ethereum to be a base-layer protocol where developers build their own Dapps, which can interact with other Dapps, blockchains. All information is stored in the Ethereum blockchain, similar to Bitcoin’s in terms of working mechanics.

Dapps and other services can register data, in bytecode, into Ethereum transactions, meaning, other assets and smart-applications can be created and stored in the Ethereum blockchain, allowing for a decentralised layer of trust.

The ultimate goal of Ethereum is to promote security and decentralisation, while scalability will be achieved by leveraging side-chains and P2P channels.

Stellar

Stellar’s goal is to become the go-to network for micro-payments, including inter-banking and intra-banking payments and settlements, through the use of its Lumens (XLM) token.

This means that the Stellar network does not depend on any single entity, as the general idea is to have as many independent servers participating in the Stellar network as possible, so that the network will still run successfully even if some servers fail.

The Stellar servers communicate and sync with each other to ensure that transactions are valid and get applied successfully to the global ledger through its Stellar Consensus Protocol, or SCP. This is essentially an improved version of a Federated Byzantine Agreement, where Stellar Lumens (XLM) holders can become validators or vote for validators.

The ultimate goal of Stellar is to promote security and scalability, while decentralisation is not really a concern given the corporate and business-oriented nature of customers. 

Brief comparison

If we compare both Ethereum and Stellar for their transaction speed and block confirmation time, we can quickly conclude Stellar is at least 100x faster. Interestingly enough, at the moment of writing there are more than 9,000 Ethereum nodes in operation, while Stellar only has 137 active nodes.

The real first conclusion is that in order for Stellar to achieve 100x speed over Ethereum, it had to concede 30x in terms of number of nodes, due to the network latency.

Other issues associated to high TPS, is that protocols require some degree of centralisation, due to network latency issues. To understand the relation between the need for centralisation in high throughput systems, one needs to refer back to consider latency, or the time it takes information to go from the origin to the destination, and fault tolerance, as in the ability for a system to sustain malicious nodes and remain functional.

In a decentralised network nodes have to be synchronous; the longer information takes to arrive, the higher the probability blocks get orphaned and attacks take place. Higher TPS means higher latency, resulting in information taking more time to arrive, which in turn leads to less fault tolerant protocols.

To conclude this part, any blockchain with high TPS must concede some degree of decentralisation, as it requires (most likely) some form of central coordination and delegation to prevent double-spending or DDoS attacks.

Next week, I’ll look at which dimensions matter more for Ethereum and Stellar, compare both, and come to a conclusion advising when should you use each.