Ethereum scalability and decentralization updates

Scalability is now at the forefront of technical discussions in the cryptocurrency space. The Bitcoin blockchain currently exceeds 12GB in size, requiring days for a new Bitcoin node to fully synchronize, the set of UTXOs that need to be stored in RAM is approaching 500MB, and continuous software improvements to the source code are trivial. . That’s not enough to flatten the trend. With each passing year, it becomes increasingly difficult for the average user to run a fully functional Bitcoin node locally on their desktop, even as Bitcoin’s price, seller acceptance, and popularity have skyrocketed the overall number of nodes on the network. The 1MB block size limit currently places a theoretical cap on this growth, but it is expensive. The Bitcoin network cannot process more than 7 transactions per second. If Bitcoin’s popularity jumps tenfold again, the cap would raise transaction fees to nearly $1, making Bitcoin less useful than PayPal. If there is one problem that needs to be solved for the effective implementation of Cryptocurrency 2.0, it is this.

The reason we’re having these problems in the cryptocurrency industry and making so little progress in finding a solution is because there’s one fundamental problem with every cryptocurrency design that needs to be addressed: Among the various proposed proof-of-work, proof-of-stake, and reputation consensus-based blockchain designs, not a single one overcomes the same core problem: that every single node must process every single transaction. It is possible to have a node that can process any number of transactions, up to thousands of transactions per second. Centralized systems like Paypal, Mastercard, and banking servers work well. However, the problem is that building such servers requires a lot of resources, so no one other than a few large corporations has an incentive to do so. When that happens, those few nodes are potentially vulnerable to profit motives and regulatory pressures, and could theoretically start making unauthorized changes to the state, including providing free money to all other users who rely on centralized nodes for security. . There is no way to prove that a block is invalid because there are no resources to process the entire block.

Currently, there is no fundamental improvement in Ethereum to the principle that every full node must process every transaction. There have been some original ideas proposed by various Bitcoin developers, including multiple merged mining chains along with protocols for moving funds from one chain to another, and this will be a big part of cryptocurrency research efforts, but at this point it is unclear how it will be implemented. This is a study on. It is not yet optimally mature. however, Block Protocol 2.0 (BP2), we do not overcome the fundamental blockchain scalability flaws, but only download small amounts of data from the blockchain, as long as there is at least one honest full node (and at least 0.01% mining power or ETH ownership for anti-spam reasons). “Light clients” that do this can maintain the same level of security as full nodes.

What is a light client?

The basic idea of ​​a light client is thanks to the data structures that exist in Bitcoin (and modified form, Ethereum) is called a Merkle Tree, which allows you to construct a proof that a particular transaction is in a block, so that the proof is much smaller than the block itself. Currently, the size of a Bitcoin block is approximately 150 KB. The Merkle proof of a transaction is approximately 0.5KB. Once a Bitcoin block reaches 2GB in size, the proof can scale to a full kilobyte. To construct a proof, simply follow the “branches” of the tree from the transaction to the root, providing nodes on the sides at every step. Using this mechanism, light clients can be confident that the transactions sent to them (or from the client) were actually included in the block.

This makes it much more difficult for malicious miners to spoof light clients. In a hypothetical world where running a full node is completely unrealistic for an average user, if a user wanted to claim that they sent 10 BTC to a merchant who lacks the resources to download the entire block, the merchant would not be powerless. They will ask for proof that the transaction sending them 10 BTC is actually in the block. If the attacker is a miner, they could potentially be more sophisticated and actually put such a transaction in a block, but end up spending funds that don’t actually exist (e.g. UTXOs). But there is a defense here too. A light client can request a second Merkle Tree proof showing that the funds used for the 10 BTC transaction also exist, allowing it to proceed to a somewhat safe block depth. From the perspective of a miner using a light client, this transforms into a challenge-response protocol. A full node that verifies a transaction can post a “challenge” to the network if it detects that the transaction has consumed non-existent output. And another node (perhaps the miner of that block) must post a “response” consisting of a Merkle tree proof showing that the output in question actually existed in some previous block. However, the Bitcoin protocol has one weakness: transaction fees. A malicious miner can post a block giving himself a 1000 BTC reward, and other miners running light clients won’t know that this block is invalid without adding up all the fees incurred from every transaction itself. . For all they know, someone else might actually be crazy enough to add 975 BTC worth of fees.

BP2

With the previous block protocol 1.0, Ethereum got even worse. There was no way for a light client to verify that a block’s state tree was a valid result of its parent state and transaction list. In practice, the only way to get a guarantee was for nodes to execute all transactions and apply them sequentially to the parent state itself. However, BP2 adds stronger guarantees. with BP2Now, every block has three trees: a state tree, a transaction tree, and a stack trace tree, which gives the intermediate root of the state tree and the transaction tree after each step. This allows a challenge-response protocol that, in simplified form, works like this:

1. Miner M publishes block B. Perhaps the miner is malicious, in which case the block incorrectly updates its state at some point.

2. Light node L receives block B and performs basic proof-of-work and structural validation on the header. If these checks pass, L begins to treat the block as legitimate, even though it has not been confirmed.

3. Full node F receives block B and begins the entire verification process, applying each transaction to its parent state and ensuring that each intermediate state matches the intermediate state provided by the miner. Suppose F discovers a discrepancy at point k. F then broadcasts a “challenge” to the network consisting of B’s hash and the value of k.

4. L receives the request and temporarily marks B as untrusted.

5. If F’s assertion is false and the block is valid at that point, M can generate a localized proof of consistency by showing k points in the stack trace, k+1 points in the stack trace, and Merkle tree proofs for the subset. The number of Merkle tree nodes in the state and transaction tree modified during the update from k to k+1. L then takes M’s word about the validity of the block up to point k, manually executes the update from k to k+1 (this consists of processing a single transaction), and proves it by checking if the root hash matches M’s hash. You can check . It is provided at the end. Of course, L also checks that the Merkle tree proof for the values ​​of state k and k+1 is valid.

6. If F’s claim is true, M will not be able to respond, and after some time, L will abandon B altogether.

The current model burns transaction fees rather than distributing them to miners, so weaknesses in the Bitcoin Lite client protocol do not apply. However, if you decide to change this, you can easily adapt the protocol to handle this. A stack trace simply maintains an execution counter of transaction fees along with a list of states and transactions. As an anti-spam measure, for F’s challenge to be valid, F must have mined one of the last 10000 blocks or at least held 0.01% of the total Ether supply for some period of time. If a full node sends an invalid challenge (meaning the miner successfully responded to it), the light node can blacklist the node’s public key.

Overall, what this means is that, unlike Bitcoin, Ethereum is likely still completely secure, including fraudulent issuance attacks, even if only a few full nodes exist. As long as at least one full node is honest, validating blocks and resolving publishing issues where appropriate, light clients can use this to point out which blocks are flawed. This protocol has one weakness. Now all transactions must be known in advance before processing a block, and adding a new transaction requires significant effort to recalculate intermediate stack trace values, making the block generation process more inefficient. . However, it is likely possible to patch the protocol to fix this issue, and if possible, BP2.1 will likely have such a fix.

Blockchain-based mining

We haven’t confirmed the details on this, but Ethereum will likely use something similar to the following for its mining algorithm:

1. H(i) = sha3(sha3(block header without nonce) ++ nonce ++ i) for i in (0 …16)

2. Let N be the number of transactions in the block.

3. Assume T(i) is the (H(i) mod N)th transaction in the block.

4. Let S be in the parent block state.

5. Apply T(0) … T(15) to S and let the resulting state be S’.

6. Let x = sha3(S’.root).

7. The block is valid if x * difficulty <= 2^256.

It has the following properties:

1. This is very difficult to remember. dagger, because mining effectively requires access to the entire blockchain. However, since it is parallelizable with shared disk space, it is likely that Dagger will be GPU-dominant rather than CPU-dominant as originally wanted.

2. The validity proof consists only of a relatively small subset of Patricia nodes used while processing T(0) … T(15), so it can be easily verified in memory.

3. All miners must be full nodes by default. Requesting block data from the network for every nonce is incredibly slow. Therefore, Ethereum will have a greater number of full nodes than Bitcoin.

4. As a result of (3), one of the main motivations for using centralized mining pools – the fact that miners can perform their operations without downloading the entire blockchain – is negated. Another main reason to use a mining pool is the fact that the payout rate is uniform, which can be easily achieved using a decentralized p2 pool (which we will eventually support as a development resource).

5. The ASIC for this mining algorithm is also the ASIC for transaction processing, so the Ethereum ASIC will help solve scalability issues.

There is really only one optimization that can be done here. The idea is to find a way to overcome the obstacle of having every full node process every transaction. This is a difficult problem. Developing a truly scalable and effective solution takes time. However, this is a strong start and may end up being one of the key elements of the final solution.