Scalability has now emerged as a critical aspect of the technical dialogue within the cryptocurrency arena. The Bitcoin blockchain has surpassed 12 GB in size, necessitating several days for a new bitcoind node to completely synchronize; the UTXO set that needs to be kept in RAM is nearing 500 MB, and ongoing software enhancements in the source code are simply insufficient to counteract the trend. With each passing year, it becomes increasingly challenging for an average user to operate a fully functional Bitcoin node on their desktop, and despite the fact that the price, merchant acceptance, and popularity of Bitcoin have soared, the number of full nodes in the network has essentially remained unchanged since 2011. The 1 MB block size restriction currently imposes a theoretical limit on this expansion, but at a significant cost: the Bitcoin network is unable to process more than 7 transactions per second. If the popularity of Bitcoin increases tenfold once again, then this limit could drive the transaction fee up to nearly a dollar, rendering Bitcoin less effective than PayPal. If there is one challenge that a successful implementation of cryptocurrency 2.0 must resolve, it is precisely this.<\/p>\n
<\/p>\n
The reason we in the cryptocurrency field are facing these issues and making minimal progress in finding a resolution is a singular foundational problem with all cryptocurrency models that requires attention. Of all the different proof of work, proof of stake, and reputational consensus-based blockchain designs proposed, not one has succeeded in overcoming the same fundamental issue: every full node is required to process each individual transaction. While creating nodes capable of processing every transaction, even potentially handling thousands of transactions per second, is feasible in centralized systems like PayPal, Mastercard, and banking servers, the challenge lies in the significant amount of resources needed to establish such a server. Thus, there exists no incentive for anyone besides a few large corporations to undertake this task. Once that scenario occurs, those few nodes may become susceptible to profit motives and regulatory influence, potentially making theoretically unauthorized modifications to the state, such as granting themselves free funds, while all other users, reliant on those centralized nodes for security, would lack any means to demonstrate that the block is invalid since they cannot process the entire block due to resource limitations.<\/p>\n
<\/p>\n
In Ethereum, as of now, there are no fundamental advancements regarding the principle that every full node must process every transaction. Numerous ingenious concepts have been proposed by various Bitcoin developers involving multiple merge-mined chains with a protocol for transferring funds from one chain to another, and these ideas will comprise a significant portion of our cryptocurrency research endeavors; however, the investigation into how to optimally implement this is still in its early stages. Nonetheless, with the advent of Block Protocol 2.0<\/a> (BP2), we possess a protocol that, although it does not address the inherent blockchain scalability flaw, does move us partially in that direction: provided that at least one honest full node exists (and, for anti-spam purposes, possesses at least 0.01% of the mining power or ether ownership), \u201clight clients\u201d that only download a minimal amount of data from the blockchain can maintain equivalent security levels as full nodes.<\/p>\n <\/p>\n The fundamental concept behind a light client is that, courtesy of a data structure found in Bitcoin (and, in a modified variant<\/a>, Ethereum) referred to as a Merkle tree, it is feasible to construct a proof that a specific transaction exists within a block, such that the proof is considerably smaller than the block itself. Currently, a Bitcoin block is roughly 150 KB in size; a Merkle proof for a transaction is approximately half a kilobyte. If Bitcoin blocks grow to 2 GB in size, the proofs might extend to a full kilobyte. To create a proof, one simply needs to trace the \u201cbranch\u201d of the tree from the transaction up to the root, providing the nodes along the way. Utilizing this mechanism, light clients can be assured that transactions directed to them (or originating from them) actually reached a block.<\/p>\n <\/p>\n This significantly complicates matters for malicious miners attempting to deceive light clients. In a theoretical situation where operating a full node is entirely impractical for ordinary users, if a user claims to have sent 10 BTC to a merchant without the resources to download the complete block, the merchant would not be powerless; they could request a proof that the transaction sending 10 BTC to them is indeed included in the block. If the attacker is a miner, they might employ more sophisticated tactics and actually position such a transaction within a block but utilize funds (i.e., UTXO) that do not exist. Nevertheless, even in this scenario, a countermeasure exists: the light client can request an additional Merkle tree proof demonstrating that the funds being spent by the 10 BTC transaction are indeed valid, continuing down to a secure block depth. From the perspective of a miner using a light client, this evolves into a challenge-response protocol: full nodes verifying transactions that detect a transaction spending an output that does not exist can announce a \u201cchallenge\u201d to the network, and other nodes (likely the miner of that block) would need to present a \u201cresponse\u201d consisting of a Merkle tree proof showing that the questioned outputs do actually exist in some preceding block. Nevertheless, there is one flaw in this protocol within Bitcoin: transaction fees. A malicious miner could release a block awarding themselves a 1000 BTC reward, and other miners operating light clients would lack any means of knowing this block is invalid without calculating all of the fees from each transaction themselves; they could assume that perhaps someone else was insane enough to actually contribute 975 BTC worth of fees.<\/p>\n <\/p>\nWhat Is A Light Client?<\/h3>\n
\n<\/p>\nBP2<\/h3>\n
![\"block-protocol-20\"](\"https:\/\/blog.ethereum.org\/images\/posts\/2013\/12\/block-protocol-20.jpg\")
\n<\/p>\n