Solana aims to be a solution, or the best attempt thus far, at solving the Blockchain Trillema.

But how are they achieving this?

Let’s dive into Turbine, Solana’s block propagation protocol🧵👇🏼

1/x

This thread is part of an ongoing series that highlights the unique key features that make Solana operate in an easy to digest form for non-technical readers.

Let’s jump straight in…

2/x

In a blockchain, block propagation refers to the process of distributing new blocks to all nodes in the network.

Turbine is used to improve the distribution and the processing of transactions across the network. But how does it work?

3/x

Traditionally, blockchain networks process transactions in a linear, sequential manner. This can lead to bottlenecks and slow transaction processing times.

4/x

Turbine addresses this issue by allowing transactions to be processed in parallel, rather than sequentially, through a mechanism known as “parallelization.”

5/x

This is done by dividing the network into small collections of nodes called “neighborhoods”, each of which processes a subset of transactions concurrently.

6/x

Each node is responsible for sharing any data it receives with other nodes in its neighborhood, as well as propagating the data on to a small set of nodes in other neighborhoods.

This way each node only has to communicate with a small number of nodes.

7/x

This allows for a greater number of transactions to be processed simultaneously, improving the overall speed and scalability of the network.

8/x

In addition to parallel transaction processing, Turbine also uses intelligent routing algorithms to ensure that transactions are efficiently distributed across the network.

9/x

Take the following example:

Suppose the Solana network receives a large spike in transactions all at once - how does the network handle this without a corresponding spike in latency?

10/x

Without Turbine, these transactions would be processed one at a time, potentially causing delays and hikes in gas fees.

11/x

Through Turbine, the network automatically divides the transactions into smaller groups or clusters and distributes them to different nodes in their neighborhood for concurrent processing.

12/x

This allows the transactions to be processed more quickly and efficiently, improving the overall performance of the network.

13/x

TL;DR

Turbine is one of the key components that enables Solana to scale with transactions while maintaining proper decentralization by allowing efficient distribution and concurrent processing of transactions.

14/x

Solana Overview: Turbine

Let’s dive into another key feature of Solana that many users likely have never heard of: Tower BFT… 🧵👇🏼

1/x

This is a somewhat brief thread in an ongoing series on the unique features that power Solana, found on my profile, that is digestible for non-technical readers.

2/x

Tower BFT is one of the key ingredients of Solana. It plays an important role in ensuring the security and reliability of the network.

It is important to first understand Solana’s Proof of History mechanism, found below:

3/x

https://twitter.com/marbiusc/status/1600169285732532228?s=46&t=etj7VcJkTPDgfpoZEhcaQA

In decentralized networks, nodes need to reach consensus on the order in which transactions are processed.

This ensures that the network remains consistent and that transactions are processed correctly.

4/x

Reaching consensus can be challenging, especially in a high-throughput network like Solana.

Tower BFT is a solution to this problem.

5/x

Tower BFT leverages Solana’s PoH as a clock before consensus to reduce messaging overhead and latency.

6/x

Tower BFT is a variation of the traditional Byzantine Fault Tolerance (BFT) consensus mechanism, which enables nodes to reach consensus even in the presence of faulty or malicious nodes.

7/x

In the case of Solana, Tower BFT allows for node consensus regarding the order in which transactions are processed using PoH as a global source of time, ensuring that the network remains consistent and secure.

8/x

TL;DR

Tower BFT = high transaction speeds while maintaining security and reliability. Liveness > consistency.

9/x

I left out quite a few key details to keep this thread short and easy to understand at a high level. More technical readers should reference @aeyakovenko’s Medium Article linked below: https://medium.com/solana-labs/tower-bft-solanas-high-performance-implementation-of-pbft-464725911e79

10/x

Solana Unique Feature: Tower BFT

1/ Many Solana native users don’t fully understand what makes Solana different than other Layer 1’s.

A brief introduction to Proof of History🧵👇🏼

2/ Proof of History (PoH) is a blockchain architecture developed by the Solana team. It uses a unique, verifiable timestamp for each block of transactions to prevent double-spending and ensure the integrity of the blockchain.

3/ In Solana's PoH system, the "clock" is a mathematical function that generates a unique timestamp for each block of transactions. This timestamp is used to order the transactions and prevent double-spending.

4/ To ensure the accuracy of the clock, Solana uses a network of validators who compete to append new blocks of transactions to the blockchain. The validators use a PoS consensus mechanism to determine the winner of each round.

5/ PoH uses a cryptographic technique called "verifiable delay functions" (VDFs) to generate timestamps that are provably difficult to predict or alter. This allows the platform to generate unique and verifiable timestamps.

6/ The use of VDFs in Solana's PoH system adds an extra layer of security to the platform. VDFs make it much more difficult for attackers to manipulate the timestamps.

7/ Additionally, the use of unique and verifiable timestamps for each transaction ensures that each transaction is processed only once, further enhancing the security of the system.

8/ The use of PoH in Solana's blockchain allows for fast and secure transaction processing without sacrificing decentralization or security.

This makes it a highly scalable platform for handling a large number of transactions.

9/ Overall, the use of PoH in Solana's blockchain allows the platform to process transactions quickly and securely, without sacrificing decentralization or security.

10/ This makes it well-suited for handling a large number of transactions, making it a highly scalable platform.

Overview: Proof of History

Historically, privacy and scalability in the blockchain space have existed in an inverse.

So, how can developers and users ensure their privacy and security while maintaining the scalability provided by Layer 1 blockchains?

Introducing Zero-Knowledge Proofs.
1/x

This thread is part of a series of threads explaining all things Zero-Knowledge Proofs.

If you are completely new to the topic, I would recommend checking out my prior thread on Zero-Knowledge Proof basics before reading this to gain a surface-level understanding.

2/x

https://twitter.com/MarbiusC/status/1585467988802555904

First, let's talk about privacy.

Some may wonder "Why Privacy?" One of the most compelling tweets regarding the importance of privacy in crypto, apart of a fantastic Cybersecurity thread I highly recommend, is this example by @ZK_shark.

3/x

https://twitter.com/ZK_shark/status/1572665025818402816?s=20&t=UJG-sj1WhOn3fBk10JnZtg

The idea of protecting privacy in the space is not new.

Blockchains such as ZCash and Monero (both utilizing ZKPs) were created with specifically for privacy. Though these blockchains provide privacy, they lack scalability and support for web3 applications.

4/x

L1 chains (i.e. ETH & SOL) offer fast speeds and scalability, but this comes at a the cost of privacy:

Any transaction a user has ever made across multiple wallet addresses can be linked together with ease, compromising privacy and security.

5/x

This transactional paper trail via public ledger can have numerous consequences.

To name a few:

For individuals, the possibility of exchange doxxing.

6/x

Businesses transacting with cryptocurrencies risk entire supply chain (including vendors, COGS, etc.) becoming readily available for competitors.

Employers paying employees in cryptocurrencies risk an HR nightmare if coworkers see variable pay for the same jobs.

7/x

For blockchains to gain the mass adoption everyone is (very) patiently waiting for, transactions must evolve to support scalable privacy.

Thus, how can this inverse between scalability and privacy be mended?

8/x

One notable and widely used privacy application built on the Ethereum that allows users to break on-chain links to wallet addresses is Tornado Cash.

Though no longer viable (recent sanctioning), the functionality of Tornado Cash is still interesting to look into 👇🏼

9/x

Tornado Cash leverages smart contracts to act as a coin mixer, enabling users to break on-chain transaction links and enhance privacy between deposit and withdrawal addresses, making it difficult to know a user's identity.

Think of a bank’s safety deposit room...

10/x

Tornado Cash allows users to store coins in a “box” that only they are able to retrieve. A user generates a secret via zk-SNARKs, sent as a hash and a deposit, that can later be withdrawn from a different address if proof of knowledge of this secret is presented.

11/x

If there is a large number of people metaphorically going in and out of this room, there is no way to tell who has access to which boxes, or addresses (though there are ways for this to be deanonymized)

12/x

Although Tornado Cash, and similar applications, can mask some transactions, it still does not provide a perfect scalable solution to on-chain privacy.

A real scalable solution to on-chain privacy is through ZK Rollups.

13/x

I outlined ZK Rollups in my last thread, quoted below. A more In depth guide can also be found on my Notion:

https://www.notion.so/Detailed-Explanation-of-ZK-Rollups-92d3de5172e14868b80cbab621c40c4e

14/x

https://twitter.com/MarbiusC/status/1585468035158069248?s=20&t=7cELPB9VnZPyyT5-kCLZ5w

Another scalable solution to privacy are through zk-STARKs, also highlighted in my last thread!

This proof system in combination with hybrid systems like Rollups provide fantastic privacy with scalability!

15/x

https://twitter.com/MarbiusC/status/1585468024919756800?s=20&t=7cELPB9VnZPyyT5-kCLZ5w

To conclude, applications of zero-knowledge proofs are enabling smart contract capable decentralized platforms security and scalability, all while maintaining a users privacy.

ZK Proofs are continuosuly growing and are an important subject to grasp as the space evolves.

16/x

Make sure to check out my other threads on ZK Proofs and follow me for more threads to come!

A full ZK Proof breakdown can be found on my Notion as well:
https://www.notion.so/marbius/Zero-Knowledge-Proofs-A-Scalable-Privacy-Solution-6725af16408c4b688fa2c6082f8c0633

17/x

Zero-Knowledge Proofs - Privacy and Scalability

Zero-Knowledge Proofs are one of the most talked about topics in emerging blockchain technologies, but many people don't have an understanding of what they are or how they work. 🧵👇🏼

1/x

This thread is part of a series of threads explaining all things Zero-Knowledge Proofs.

If you are completely new to the topic, I would recommend checking out my prior thread on Zero-Knowledge Proof basics before reading this to gain a surface-level understanding.

2/x

https://twitter.com/MarbiusC/status/1585386051886977024?s=20&t=lfyLHleYT-ibb95kErxANA

In this thread, we will be covering the different "flavors" of ZK Proofs and some examples of their applications.

These flavors are:
1. Interactive Proofs
2. Non-Interactive Proofs

3/x

More specifically, we will also cover the different types of Non-Interactive Zero-Knowledge Proofs (NIZK), as these have the most implementation

1. zk-SNARKs
2. zk-STARKs
(Bonus: ZK Rollups)
3. Bulletproofs

4/x

1. Interactive Protocols

In an interactive proof system, the prover and the verifier have to communicate back and forth for multiple iterations; following these iterations, the verifier choses to Accept or Reject.

(See prior thread on "The Cave of Ali Baba)

5/x

Interactive proof systems have their drawbacks; they tend to be computationally heavy and very slow (though they can be useful for situations in which there is only a single verifier).

Thus, in practice, systems tend to use Non-Interactive Proof Systems.

6/x

In a non-interactive proof, the prover only sends one message to the verifier, which is very advantageous for systems containing multiple verifiers.

The idea of an NIZK leads us to one of the most widely used ZK Proof systems - the zk-SNARK.

7/x

zk-SNARKs, or "Zero-Knowledge Succinct Non-Interactive Argument of Knowledge," wherein (as the title suggests) require no interaction with the verifier.

8/x

SNARKs also demand that the proof is short and fast to verify (hence Succinct), giving systems the ability to process very large program statements with a proof of only a few hundred bytes.

9/x

zk-SNARKs have a tremendous amount of applications in the blockchain space. They provide scalability by placing the burden of computational overhead on the prover, often times off-chain (see ZK Rollups section later on) not the validators.

10/x

A full breakdown on zk-SNARKs can be found on my Notion page below:

https://www.notion.so/marbius/In-Depth-Explanation-of-zk-SNARKS-74b8e89d3a694444bcf6c992b3ca5fc8

11/x

Some zk-SNARK system examples:

- Tornado Cash
- ZCash
- Dark Forest (on chain RST game)

12/x

zk-SNARKs depend on a trusted setup, meaning that a set of public parameters are required for conducting private transactions. Protocols using trusted setups are face centralization issues, as these random parameter generators are usually formulated by a small group.

13/x

The two main zero-knowledge proof systems that do not use a trusted setup but instead use a transparent setup are Bulletproofs, and STARKs(Zero-Knowledge Scalable Transparent Arguments of Knowledge).

14/x

2. zk-STARKs

zk-STARKs, or Zero-Knowledge Scalable Transparent Arguments of Knowledge are a derived improvement to zk-SNARKs.

They are less complex to perform, more secure and (in theory) resistant to quantum computing.

zk-STARKs must also be scalable (more details found

15/x

Without going into too much detail here, trusted setups (unlike transparent setups) do not rely on trusted parties and have no "toxic waste," or random keys used in trusted setups that can compromise an entire blockchain system.

16/x

The key downside when comparing STARKs to SNARKs is the size of the proofs; proofs in a STARK are orders of magnitude larger than for SNARKs, though as research progresses, proof sizes will likely be reduced.

17/x

One way scalability can be improved with STARKs which is seeing implementations today is through a “hybrid” model, wherein off-chain STARK proofs are generated that attest to the integrity of on-chain transactions.

This leads us to the next category: ZK Rollups

18/x

Bonus: ZK Rollups

I chose to include ZK Rollups as a bonus, as they are technically not a ZK Proof system in and of itself. There are no "pure" zk-STARK systems (AFAIK) due to the key issues mentioned above, though there are many applications thanks to ZK Rollups.

19/x

ZK Rollups are hybrid system that bundle transactions into batches, executed off-chain.

Off-chain computations allow for the processing of thousands of transactions in a batch while posting a minimal data summary to the blockchain, rather than individual transactions.

20/x

A detailed explanation on how ZK Rollups work in practice can be found in my Notion:

https://www.notion.so/marbius/Detailed-Explanation-of-ZK-Rollups-92d3de5172e14868b80cbab621c40c4e

21/x

One of the most widely used applications of zk-STARKs is StarkWare, a company that provides STARK-based validity proofs on Ethereum through their Layer 2 scalability ZK Rollup engine.

Some products powered by StarkWare:
- dYdX
- DeversiFi
- iMMUTABLE

22/x

3. Bulletproofs

Bulletproofs are a form of non-interactive zero-knowledge proofs powered by efficient inner product arguments and zero-knowledge range proofs.

Bulletproofs vary from the two systems above in that they are not powered by SNARKs.

23/x

The technicalities and the mathematics behind the terms above like efficient inner product arguments and range proofs can be found on my Notion:

https://www.notion.so/marbius/Detailed-Explanation-of-Bulletproofs-bef58d78cc82432194b1ce229342cdcd

24/x

Bulletproofs can be summarized as a system that allows multiple parties with secret committed values to jointly generate a single small range proof for all their values, without revealing their secret values to each other.

A common Bulletproof based system is Monero.

25/x

That's the end of the somewhat lengthy thread on ZK Proof Applications!

If you learned something, please like and RT! Follow my page for more ZK Proof explanation threads to come!

In-Depth ZK Proof Guide below:

https://www.notion.so/marbius/Zero-Knowledge-Proofs-A-Scalable-Privacy-Solution-6725af16408c4b688fa2c6082f8c0633

26/x

Zero-Knowledge Proof Applications

Many of you have heard the term Zero-Knowledge, or ZK, in relation to emerging blockchain technology, but what exactly is it?

A simple conceptual overview of what a ZK Proof is and why it is important (no math required!) 🧵👇🏼

1/x

This thread is part of an ongoing series covering ZK Proofs from basics to advanced topics. Make sure to check my page for more threads to come!

Now, let's dive in...

2/x

Simply put, Zero-knowledge proofs are a way for an individual to prove to another that a statement is true, without disclosing any information beyond the validity of the statement.

3/x

Let's start with a quick warmup:

Suppose I want to go into a bar. Before I am allowed entrance, I must first convince the bouncer that I am of legal drinking age. Thus, I hand the bouncer my ID Card that confirms my age > the minimum age required.

4/x

This system, however, is flawed.

By handing this stranger my ID Card, I in turn relinquish unnecessary personal information about myself, such as my name, home address, etc.

5/x

What if there was a way for me to prove my requirements for entrance while keeping all personal information secret, even my DOB?

Unfortunately, this scenario has not seen a practical solution just yet, but it is a good example to get us on track for the genius of ZK Proofs.

6/x

Let's jump into a scenario that, through ZK Proofs, allows for one party to convince another of the validity of a secret known as "The Cave of Ali Baba."

7/x

Consider two friends, Peter and Veronica, who find themselves at the opening of a ring-shaped cave with two distinct entrances to two separate paths, Path A and Path B.

Inside the cave, a locked door, opened only via secret code, blocks the two paths from connecting.

8/x

Peter claims to know the code to this door but, being a very private person, does not want to reveal the code to Veronica, nor let it be publicly known he possesses this knowledge in general.

Skeptical of his knowledge, Veronica proposes a system to verify this claim...

9/x

The system is as follows:

Peter instructs Veronica to stand outside the entrance of the cave. He enters one pathway at random without Veronica seeing which way he went. Once inside, Veronica can approach the entrance and call out the path she would like him to exit from.

10/x

Knowing the secret code that opens the door, Peter can exit the cave down the pathway he chooses; he can either return down the path he originally entered, or by unlock the door to gain access to the other path.

11/x

Upon returning out the exit of her choice, Veronica is still not convinced, as she suspects that Peter could have gotten lucky; she picked Path A or Path B at random, giving a 50% chance of guessing correctly.

12/x

Peter suggests they continue to iterate this trial another 20 times, as the chances of Peter guessing correctly each time would be very unlikely (1/2^20) if he could not travel through the locked door.

13/x

Peter successfully completes all of these trials correctly each time, convincing Veronica it is extremely probable that he does in fact know the secret code to open the door.

14/x

Peter has convinced Veronica he possesses this knowledge while providing Veronica with "Zero-Knowledge."

Veronica did not learn anything she did not previously know about Peter's secret, yet believes to a high degree of confidence that the secret is valid.

15/x

This example above is a great first step into the realm of ZK Proofs, more specifically an Interactive Probabilistic ZK Proof, and begins to highlight the role ZK Proofs can play in privacy.

16/x

More threads on ZK Proofs, such as the underlying math, protocols implementation, and different ZKP systems, coming soon!

For a full, in-depth explanation of Zero-Knowledge Proofs, check out my Notion:

17/x
https://www.notion.so/marbius/Zero-Knowledge-Proofs-A-Scalable-Privacy-Solution-6725af16408c4b688fa2c6082f8c0633

Zero-Knowledge Proofs - The Basics

I know I am a bit late to the topic, however the censorship surrounding Tornado Cash got me thinking...

In what other ways, potentially larger ways, could ETH be censored in the future and how?

The results were quite staggering... 🧵👇🏼

[1/x]

The main topic of this thread is surrounding the centralization of Ethereum Nodes, specifically the servers they are being hosted on.

[2/x]

Note: I will not be going into all of the technicalities as to what constitutes a "decentralization." That not only justifies its own thread, but also, I am very likely to leave something out and get rekt in the comments. 

So for now, I will stick to a narrower scope.

[3/x]

Eth maxis pride themselves on the decentralization of their network, and rightfully so:

According to Etherscan, there are roughly 4550 nodes operating on mainnet globally (10396 total) and such, the network is very robust.

[4/x]

Below is a graphical representation of the node distribution globally, provided by Etherscan:

[5/x]

Although there are many nodes operating across the globe, how many of them rely on centralized servers?

Lets dive in👇🏼

[6/x]

The following stats are from ethernodes.org:

Of the nodes operating on mainnet, 2849, or 62.6%, are hosted.

[7/x]

An even more staggering statistic is that of the hosted nodes, 52.5% of nodes operate on AWS with 17% of them out of a single data center in Ashburn, VA. 

[8/x]

Additionally, 34.7% of nodes are operating in residential settings. Of the residental nodes, over 50% are operating through just a few  Us-Internet providers such as Comcast, Verizon Spectrum and AT&T.

[9/x]

Therefore, the data provided above shows that of all of the Ethereum nodes on mainnet, nearly 50% are facilitated by Amazon, Comcast, Verizon, AT&T and Spectrum, which conveniently enough corresponds with the Etherscan stat of ~49% of Eths US network distribution. 

[10/x]

I should remind everyone that although a 51% attack isn't enough to take absolute control of the network, it could still have massive repercussions through reverting transaction/double spending. 

[11/x]

Conveniently enough, Amazon also launched a node-as-a-service platform on Amazon Managed Blockchain which allows node activation for ETH in a few simple steps. 

[12/x]

"But what about The Merge? Won't POS save us from a crushing blow from Uncle Jeff?"

Although the transition to Proof of Stake will improve decentralization, it is not the saving grace many hope for...

[13/x]

Of the current validators running on ETHs Becon Chain, more than 50% of all staked ETH is contained to three pools by (you guessed it!): the centralized servers of Coinbase, Lido and Kraken.

There is a similar inherent risk to this distribution of staked ETH.

[14/x]

This is highly concerning for the decentralized narrative of Ethereum's network and appears to be overlooked by many. 

[15/x]

We saw how easily the US Government was able to shut down Tornado, a simple dApp operating on ETH, slapping severe enough OFAC sanctions to prevent its use entirely. 

[16/x]

What does everyone think will happen if the US decides to try to gain more control over ETH validators/nodes through threats and legislation?

We already know where Coinbase stands on this issue:
https://twitter.com/brian_armstrong/status/1558941361465749504?s=20&t=zwKfgneMU9Eiic5kCDHgZQ

[16/x]

My point is: a blockchain is only ever as decentralized as the nations that govern their validators. 

The classic tale of big fucks small. Centralized Power will always trump Decentralized Technology.

[17/x]