How to Achieve High Throughput Without Sacrificing Security or Decentralisation
The so-called “Scalability Trilemma” asserts that a blockchain must compromise on either security, decentralisation, or scalability, it seemingly cannot excel in all three. This idea, widely attributed to certain high-profile developers, has shaped much of the industry’s design choices, often leading to high fees, heavy Layer-1 “smart contracts,” or reliance on centralised second layers. However, the Trilemma itself is based on flawed assumptions. By distinguishing data availability from computation, optimizing for truly low-fee base layers, and ensuring fair token distribution, we can build systems that are both highly scalable and censorship resistant without sacrificing security.
A core claim of the Trilemma is that security, decentralisation, and scalability are three separate pillars that a blockchain must juggle. Yet, in reality:
Any framework that treats security and decentralisation as separate categories is already conflating the same property in two forms. This conceptual redundancy leads many projects astray.
Many protocols that attempt to handle everything including smart contract computation and data storage at the base layer end up with:
These symptoms are not inevitable but arise if you force every node to perform all heavy computations on every block. By separating the roles leaving text-based data availability to the base layer, while pushing complex computations to Layer-2 systems blockchains can avoid the trade-offs that the Trilemma insists upon.
“Scalability” often means the network can handle many transactions per second (TPS), but ironically, many “scalable” chains impose high base layer fees or complex Layer 1 logic that undermines widespread usage and results in fat nodes that are uneconomic to operate without passing excessive costs onto the user base.
A truly scalable Layer 1 should focus almost exclusively on being a data availability layer with near-feeless (or staked-resource) transactions. Layer-2 solutions, which rely on that base-layer security, can then run intensive computations or store large non-text based data off-chain, referencing the base chain for its immutability requirements. If the base Layer 1 is too expensive to write to, then any purported Layer-2 will become centralised because it cannot afford to commit its data or proofs back on-chain on a regular enough basis without having to "trust" the Layer-2 system. This undermines the "trustlessness" that blockchain technology was supposed to minimise.
Example
Standard blockchains often rely on fee auctions: users outbid each other, so the chain always “chooses” the highest-paying transactions first. This leads to:
By contrast, a resource-credit or stake-based model requires:
Result: By applying a fee-less, resource credit model, you get a chain that can handle large volumes of traffic without punishing normal users with unpredictable fee changes.
If a project claims to solve “the Trilemma” by scaling up yet remains easily censorable, it fails on security. Real security means no single entity can freeze accounts or remove data. This is only feasible if:
Proof of Stake systems without guardrails (“Un-Parameterised Coin Voting”) often devolve into a handful of (2-4) large staking pools (e.g., lido Finance) controlling consensus. Unless carefully designed, this leads to:
A better approach, especially for social and highly nuanced community governance is Parameterised Coin Voting (e.g., Delegated Proof of Stake with a fixed number of validators and mandatory stake lock-ups). This ensures:
A Proof of Stake (PoS) or Delegated Proof of Stake (DPoS) blockchain can only be censorship resistant if its tokens are meaningfully and widely distributed. If a small group of venture capitalists, founders, or pre-miners holds the majority of tokens, they can override governance or be legally pressured into compliance that ultimately represents a take over of a community causing it to operate against its own best interests. Achieving broad distribution typically requires:
Scaling blockchain networks for mainstream use has been challenging due to network congestion and high transaction costs on layer 1's. Zero-knowledge (ZK) roll-ups, a layer-2 solution, address these issues by moving computation off the Layer 1 chain and validating transactions with compact proofs on layer 1, reducing congestion and costs.
ZK proofs work, essentially by allowing someone to prove that they have access to information without actually showing that information to the party asking for proof. For example, if the information that they posses allows them to correctly solve a complex mathematical problem over numerous iterations and adjustments in input variables so that expected outputs are received in return, then after a number of repeated correct responses in a row, the party asking for the proof can be satisfied that the party with the information actually has it, even though they do not know what the information is and do not need to reveal it.
A simple example of a ZK Proof is where you ask a friend to tweet out a word from a Twitter account that they say they control. They oblige and a few minutes later you see the Twitter account in question has posted the word you requested. There is now a good chance that your friend is proven to be the owner of this account, but to be sure you ask them to repeat the process several times, each time posting a different word that you have specified. After several correct tweets, you have enough evidence to be convinced that your friend controls the password to that twitter account. Your friend does not need to reveal to you the password to their Twitter account to prove to you that they do in fact have the keys to that account. This is a Zero Knowledge Proof.
The process of ZK roll-ups is where the computation to carry out and verify transactions is not done on the blockchain Layer 1, but on a ZK capable Layer 2. ZK Roll-ups on such a Layer 2 can batch or roll up many thousands of transactions. Then a ZK Proof can be published to the Layer 1 for final clearing and security, verifying the correctness of the transactions in the process.
The important thing to note here is that these ZK proofs are far smaller than complete Layer 1 transaction data making the Layer 1 far less congested when it uses ZK Proofs to scale while not adding to the cost of transactions.
Because of their Zero Knowledge nature, these proofs can be adapted to enable Layer 1 block producers to validate Layer 2 transactions without needing the transaction information itself. This makes the transactions private, obscuring information from both the Layer 1 block producers, third party observers and even the person receiving the transaction.
The evolution of certain DPoS systems shows how distribution often arises from unexpected events such as hostile takeovers or forks rather than neat, planned “token sales.” When a community must set aside its internal differences and unify to fork out a malicious actor’s stake, distribution can become more organic:
The so-called “Scalability Trilemma” posits that a chain must sacrifice security (decentralisation) for scalability or vice versa. In practice, this trilemma stems from conflating data availability with computation and ignoring the power of Parameterised Coin Voting combined with a widely distributed token.
Key Lessons
Separate Computation from the Base Layer
Resource-Credit or Staking Models
Ensure No Single Entity Can Dominate
True Security = Decentralisation
Broad Distribution Is Non-Negotiable
By following these principles, a blockchain can deliver robust throughput and maintain censorship resistance disproving the notion that one must compromise “security vs. decentralisation vs. scalability.” Properly built systems show these are not mutually exclusive trade-offs but rather aspects of a carefully designed, parameterised network where no single dimension has to be sacrificed.
▶️ 3Speak
