Thread by @ishaheen10

What does an optimal blockchain for telecom need?

This response is from @ttk314 and covers:

- Key problem of blockchains i.e. latency
- Uncle blocks on @ethereum
- @cosmos vs @solana design choices
- Why @AltheaNetwork is building on @cosmos

Thank you Justin for teaching me!

1. Key problem of blockchains is latency. In a decentralized system many people are participating who have have a given latency to each other.

Exactly how you decide what the 'present' is takes time, since your messages take an unpredictable amount of time to arrive.

2. For example, Ethereum produces a block every 15 seconds, the 'winning' block is the one the next successful miner choses to build on.

This is why you have to wait 3-4 blocks before exchanges will give you funds or anything is considered final.

3. You can hear about a block, and then realize 500ms or even a few minutes later that the network has adopted a different history because the next miner chose a different block than the one you heard about.

In Ethereum these are called uncle blocks.

etherscan.io/uncles?p=1

4. Uncle blocks are blocks that 'executed' and then 'didn't execute' because a new block was found before the uncle managed to spread.

This property is called Finality, it's the time taken from a transaction being sent to the time that it becomes part of a shared history.

5. @cosmos and most proof of stake blockchains have 'instant' finality, meaning as soon as something is in a block it is guaranteed to be final.

This is because a block is not produced until it's run by all the validators.

6. This is why there's a limit of only 125 validators on the @cosmos hub, given that number of validators they can all sync up and produce a block every ~5 seconds.

Larger numbers of validators increase finality time exponentially.

7. Now we get to @solana: what they are doing is trying to run faster than either proof-of-work or proof-of-stake that we've talked about so far.

This is why their paper solana.com/solana-whitepa… is so focused on 'proof of history' and the concept of a 'leader node'.

8. A @solana leader node is running the blockchain, as quickly as it can, as if it's just a very fast database server that's doing cryptography, because it doesn't have to consult anyone else it can push transactions really really fast.

9. Proof of history is supposed to provide a way for verifying nodes to keep up and determine that what the leader node said happened, actually did happen when it says it happened.

But this has limits.

10. If the leader node misbehaves, reality will get rolled back. Exactly how much roll-back happens is a function of the decentralization of the chain.

If you expect all the other validators to be very fast maybe you can do a new leader election in under a second.

11. But the more people you allow to join this group and the more decentralized you get the slower it has to be and the longer 'finality' takes on this 'ultra fast' blockchain.

@cosmos proof of stake just pays that finality price up front, it asks everyone.

12. @solana bets that the common case (honest leader nodes) will happen most of the time and they will achieve lower latency and higher throughput that way.

While dishonest leaders will be kicked out for blatant misconduct, they can get away with front-running.

13. Consider our example of an Automated Market Maker (AMM) the biggest actual reason to use blockchains right now.

Proof of history can't prove a negative, so the leader could insert some transactions to front-run a trade it saw coming.

14. It's simply not possible to prove that the leader node didn't get a valid transaction from a 'friend' at exactly the right time.

So it can't be slashed even while sitting there frontrunning everyone all day.

15. On @ethereum you get miners trying to front-run the AMM as well. This is called MEV or Miner Extracted Value.

But since it's random who gets to produce the next block they can't just sit there and do it forever until an election is called.

16. Ultimately 'throughput' is a big thing with lots of variables.

A transaction having finality in 1 second is 'fast' but confirming one million transactions per second but with a finality of 60 seconds is also 'fast'.

17. There's also a difference between having a database server at a bank that you can verify (Solana's design choice, which does have a lot of value!) and having a system that's more open to participants.

18. Ethereum 2 spent a lot of time in the POS system where they only have ~300 or so active validators, but a pool of thousands waiting that they swap in and out.

This provides better decentralization with similar speed properties to cosmos at the cost of a lot of complexity.

19. For telecom we don't need finality that's all that fast.

What we need is decentralization so that people care about joining a network and can believe the chain is legitimate, and throughput so that we can serve a lot of users.

20. We can design the router software to wait 60 seconds for a payment to go through.

We can also design it to decrease the frequency of payments as network load increases (payments of 1c during low activity, payments of 25c during high activity).

21. Finally we don't need to worry about frontrunning much, at least for the telecom stuff, so there's freedom we have to play with there as well.

@cosmos has a simple consensus system, the throughput is moderately good and so is the latency.

22. Where @cosmos stands out is in its focus on governance, built in functions that let token holders vote and make changes automatically.

Governance in most chains is implicit. Ethereum upgrades because someone pushes software and miners upgrade. Things break if they don't.

23. No votes involved in @cosmos. It's a democratic system with token weighted votes that are public for everyone to see.

Cosmos lets us to deploy our own chain. This is where we get back to some key questions for a blockchain for telecom.

24. How much does a tx cost?

Do we focus on throughput or finality?

What's an acceptable level of decentralization?

These are decisions that the @AltheaNetwork community will make.