Vitalik Buterin, one of Ethereum’s co-founders, is credited with this trilemma, and this (AFAICT) is where he first posted about it:
The trilemma claims that blockchain systems can only at most have
two of the following three properties:
* Decentralization (defined as the system being able to run in a
scenario where each participant only has access to O(c) resources,
i.e. a regular laptop or small VPS)
* Scalability (defined as being able to process O(n) > O(c) transactions)
* Security (defined as being secure against attackers with up to O(n) resources)
In the rest of this document, we'll continue using c to refer to the size
of computational resources (including computation, bandwidth and storage)
available to each node, and n to refer to the size of the ecosystem in some
abstract sense; we assume that transaction load, state size, and the market cap
of a cryptocurrency are all proportional to n. The key challenge of scalability
is finding a way to achieve all three at the base layer.
The CAP theorem is a precursor of that, even if they are different [1][2][3] and Micali from Algorand claims they solved it (it is included in the original article).
Algorand’s solution as originally stated is predicated on a non-colluding majority. At IACR when this algorithm was proposed, Silvio famously said as a counterpoint to the very apt criticisms that a colluding majority could defraud the protocol “my proof is that society exists!”
In the end I believe Algorand changed their algorithms to a more centralized approach for the sake of performance as fully distributed validation did not perform adequately. Please correct me if I’m wrong.
Yes, full relay nodes were few and very centralized historically. Source: we have been working with Algorand since the beginning. BTW: we publish updated information about the protocol that you cannot find in the original papers [1].
> Currently, Algorand blocks are produced in less than 3 seconds with instant finality. The network can process 10,000 transactions per second, and at a cost of a fraction of a cent per transaction.
I feel like there's a way to directly derive the blockchain trilemma from the CAP theorem (or probably the more formal PACELC). Reasoning through it in my head makes sense so I've been saying that it's a corollary to CAP but I haven't actually seen it written out formally.
I think it all comes down to relativity and the speed of light.
There is no single, universal, true ordered state (ledger/db). Participants need a conflict resolution mechanism to figure out whose truth is correct. One must rely on a localized consinstent state of some authority (leader/consensus).
The fact that every human society ends up with some kind of centralized oligarchy is probably also due to this effect. Something has to resolve disputes about the state of the system.
A solution that somehow goes around these limitations could have implications beyond computing. It could enable “headless” large scale cooperation. This would be a fundamental innovation in the evolution of intelligence generally.
Proof of work is the only one we have that kind of works and it’s massively expensive. You could argue that it’s just a way to make economically irrational or short sighted collusion prohibitively expensive rather than a true solution and might only work in a domain like a currency where there is a direct mapping to cost.
Proof of work essentially allows for a periodic leader election, where the leader has sufficient time to propagate its state update along with a verifiable proof of authority in a permissionless decentralized system.
Decentralized cooperation in society likely wouldn't be permissionless, in most cases you would probably want to assign some voting power per human/citizen/share certificate/whatever. I'm also not sure if decentralized, verifiable randomness is easier to achieve outside of computer networks (for example, source some verifiable randomness from the universe based on a pre-defined algorithm).
Cap is different because cap is about network planning constraints and doesn’t take into account things like security per se.
I think parts of Vitalik’s points are kinda moot and break down when you examine them through the lens of “any sufficiently complicated system can and will break.”
In the case of bitcoin, the breaks are few now because it is basically static. I’m sure there’s some bugs in that codebase though… (and they’re worth a very pretty penny if you can find them!!).
The lighting protocol works on top of Bitcoin to be able to support orders of magnitude more transactions off chain with final settlement performed by Bitcoin. Using off chain layers like this avoids needing to solve an unsolveable trilemma. Certainly though bitcoin should be improved to allow a few more transactions per second :)
Background: I was around for August 2017 hard-fork, running one of (then) ~2000 worldwide verification nodes (i.e. not mining, rule-setting): I can assure you the lack of offchain usage was predictable.
For the diehard technologists, it's interesting to note that Satoshi's original whitepaper called for a much larger blocksize (32MB, verse 1MB pre-SegWit/Lightning); myself, I ran BitcoinUnlimited with 16MB block acceptance well into 2018 (I'm anti anti anti SegWit/Lightning).
For some reason, years of BIPs have claimed that "1MB is necessary due to bandwidth limitations..." which even in 2017 was horseshit... but now it's 2024 and I can get 300mbps fiber for $57.99/month (with a ping <3ms).
Miners are (and always have been) allowed to mine blocks containing zero transactions (i.e. ~0kB, not including necessities). It's us nodes that choose to reject/accept (of course there is Venn overlap).
This was common until block congestion actually started encouraging senders to include transaction fees; these [still!-]voluntarily fees represent a healthy addition to the blockreward, so most miners incur the minimal overhead for much-greater profit.
Yet zero-transaction blocks continue to be mined (albeit less-frequently).
Nothing centralized about it and it's not a service. I can open a Lightning channel to my friend and make as many transactions as I want. Only the final difference is broadcasted to the Bitcoin blockchain. A similar method was originally suggested by Satoshi for scaling Bitcoin, so I don't know how it could be a "scam".
So right, but the issue is that block size increases only get you a linear increase in transaction rates which doesn't really address the problem (would 50 t/s somehow resolve any blockchain congestion?). So you make your currency less secure, risk chain splits but haven't even really solved any problems
No. Lightning simply gives up more decentralization and security for the illusion of scalability.
I say illusion of scalability because it's still hamstrung by Bitcoin in a major way. You still need to use Bitcoin to enter the system, which is a big bottleneck. For security you also need to be able to settle to the Bitcoin blockchain in a cheap and reliable way, which just won't scale with a congested blockchain.
Lightning is honestly pretty shit and it's not at all a solution to Bitcoin's problems.
If Bitcoin scalability is the problem Lightning Solves, then it almost tautologically fails when you realize that entering into a Lightning Channel requires a base Bitcoin transaction. If every person on Earth tried to take on-chain Bitcoin into a LN Channel, it would skyrocket the fee-rate.
The only other option then would be for all Bitcoin purchased to exist on Lightning, so people simply buy LN Bitcoin. This is not impractical to get started; exchanges simply send and receive LN BTC. But Lightning security relies on the ability to get a transaction posted to the base layer Bitcoin.
If everyone is using lightning, and thousands of users are attacked on Lightning at once, the chain would not be able to handle the influx and would leave many victims. Not only that, but the LN node network would naturally centralize, especially with liquidity requirements.
It would be much better to properly scale some base layer.
If I understand correctly, lightning allow an unbounded amount of transactions for the cost of a couple of on chain transactions. So sure, there are still the need to hit the chain, but if you were to do all transactions on chain, you'd be even less scalable. In that respect, I don't see how you can claim that it is only an illusion.
Exactly. Lightning minimizes the use of the globally consistent ledger, which inevitably has to make trade-offs due to the "trilemma".
You set aside some funds on the global ledger and then you can use those funds to transact in a much more efficient, truly p2p manner, without touching the global ledger. Eventually, you net out everything and settle it all at once on-chain, utilizing its features to resolve any conflicts.
.. between the two parties that started the link, up to the initial value. It's so limited as to be useless. It's like a bar tab where you have to put down a deposit of the maximum amount you might spend first.
Well you can use intermediate nodes, it doesn't have to be a direct payment channel between sender and receiver.
But to make that work, you have to be online in real time to receive funds. It's not like on-chain transactions that complete without needing your direct involvement. If you're not online, then somebody has to do that on your behalf and now you're back to having someone else custody your funds. Here's a good article explaining it:
(You also need someone online monitoring for fraud, even without intermediates, but at least that part can be outsourced without trusting someone with custody.)
kaspa is running 1 bps and 10s confirmation now, and 10bps on testnet, it's amazing nobody seems to know it, it's the closest thing to say we solved this 'trilemma'.
Yes, but this doesn't account for the fact that a cryptocurrency can be recorded across multiple blockchains (e.g. sharding). So a cryptocurrency (as opposed to a blockchain) can have all three properties of decentralization, scalability, and security.
Also, the problem can be solved even more simply and elegantly than sharding by having a multi-cryptocurrency ecosystem which supports fast, decentralized, and low friction conversions exposed via the same (interoperable) transaction APIs. If the on-chain volume is sufficient on all chains, it's possible to automatically determine relative prices of tokens... In the same way that tourists from different countries can spend their native country's currency locally (conversion is not always necessary if the relative prices and volumes are somewhat stable).
If the on-chain transaction volumes of different cryptocurrencies are similar (or above a certain threshold that corresponds to the size of the businesses accepting the cryptocurrency as payment), then a business can effectively accept payment in any cryptocurrency which they know/trust the existence of since the API would be the same across all chains. So you could use the same passphrase to log into all the different chains (including ones you never heard of) and you would already have an account there. You don't need to trust the chains themselves with your passphrase, you only need to trust your wallet app since the passphrase should never be sent over the wire.
Wouldn't it be great if you could just walk up to a local business and offer to pay them in some new cryptocurrency they've never heard of which supports the same API? They could verify whether or not it meets their volume/stability and exposure requirements automatically in a couple of minutes.
We're so close to achieving this ideal. The tech already exists in various forms. We just need regulatory/taxation clarity and a bit of willpower.
How does someone verify the authenticity of a unknown coin based solely on API requests to an endpoint that the 2nd party provides?
Also, if we hold the Trilemma to be true then presumably some point in the network will have weaker security to improve the other 2. Thereby compromising the entire network.
You don't beat CAP/Trilemma by gluing 2 databases together.
If you don't know the coin but you can see that its blockchain is connected to a blockchain that you know and trust, you can look at DEX chain-to-chain trade volume between your blockchain and the unfamiliar blockchain to determine its value and the amount of volume trustlessly (the volume would be measured in your own trusted coin coming from its own blockchain in a cryptographically verifiable way).
If you can see that $1 million worth of your own coin is being exchanged for that other unknown coin each day and people are paying $50K worth of your own coin every day to cover cross-chain transaction fees, surely you can take a risk and accept that unknown coin as payment for a $100 product. The risk of the coin being a scam goes down with the amount of verifiable trade volume.
The problem is not solved by having excellent support for interoperability between chains. The security of any bridge interaction between chains is no better than the weaker chain.
And the security of two chains does not add up, in fact, the more resources are split up between multiple chains, the less secure they all become. So this doesn't solve for the security side of the trilemma.
If the chains are distinct and tokens are merely easily interchangeable, they are isolated security-wise. Of course, accepting payment in a token you've never heard of presents a risk, but this risk isn't significant if that new token's blockchain is connected to a blockchain which you trust via a DEX or bridge. It's possible to build simple client-side cryptographic tools to verify trades or bridging across different blockchains... If you can cryptographically verify that a new token is traded chain-to-chain against a token you trust with a certain amount of volume, then you know you can trust that new coin to some extent.
Also, as a business owner, you can charge an additional fee when accepting unknown or low volume coins, or coins that are backed by blockchains which have a small number of nodes.
Imagine how many more people would be able to afford to buy your products if you would accept just about any token as payment. It could be a way to gain a competitive edge and boost your profit margins by accepting riskier coins from unfamiliar communities.
It's not quite the same as if everyone could print their own money on pieces of paper; we know that wouldn't work because nobody would have an incentive to do any work to produce anything... But the opposite extreme (which is our current reality) also doesn't work; there are all these people with no money and no opportunities who could be doing business with each other, but they can't because they have no money and are not allowed to create their own money to get their parallel 'unbanked people' economy going.
> So you could use the same passphrase to log into all the different chains (including ones you never heard of) and you would already have an account there.
The UX on this has improved significantly in just the last year or so. We have wallets, like Rabby, which interact seamlessly across multiple (many!) chains and can even switch within the same dapp on a per transaction basis. It just works.
1. Business gets a sale they might not have received otherwise.
2. Business receives funds in their preferred currency.
3. Customer gets what they want.
Not much different than me going to Vietnam with USD and then trying to buy a Nước mía (sugar cane juice) from a local vendor that can't legally accept USD.
My only alternative is to rely on a third party to convert my USD to VND. Which begs the question, why isn't this digital and why do we need the middlemen taking their cut of the transaction? Expand that out into larger purchases, which then imply you're a criminal unless you provide full KYC.
> Expand that out into larger purchases, which then imply you're a criminal unless you provide full KYC.
Well yeah, that's the whole point isn't it? Like, the business doesn't want to be getting paid out of ransomware ransoms, they want money in a clean currency, and so at some point someone has to exchange clean money for ransom tokens, and if you offer to do that without verification then you're essentially part of the ransomware industry and people will treat you accordingly.
* business doesn't want to be getting paid out of ransomware ransoms
Exactly why I said my point 2 above.
* at some point someone has to exchange clean money for ransom tokens
There is no such thing as "clean money" or "clean currency". There is fiat (aka: government money), which definitely isn't something I'd describe as "clean". It is usually backed by a bunch of people who tend to kill others (aka: US military) and that tends to be rather... dirty.
What is really going on is that they are referring to the crypto industry as some sort of "ransomware ransoms" and if you combine those two nonsense arguments (ransomware+clean), with the HN crypto hater bias, I didn't see it worth the effort to continue on, regardless of the downvotes I received.
