Ethereum scalability and decentralization updates

Scalability is now at the forefront of the technical discussion in the cryptocurrency scene. The size of the Bitcoin blockchain is currently over 12 GB, requiring a period of several days for a new bitcoind node to be fully synchronized, the pool of UTXO that must be stored in RAM is approaching 500 MB, and constant software improvements in the source code are simply not enough to mitigate the This trend. With each passing year, it becomes more and more difficult for the average user to run a fully-functional Bitcoin node locally on their desktop, and even as the price, merchant acceptance and popularity of Bitcoin rise, the number of full nodes in the network has remained the same since 2011. It sets the maximum size A 1MB block is currently a theoretical limit for this growth, but at a high cost: the Bitcoin network cannot process more than 7 transactions per second. If Bitcoin’s popularity jumps tenfold again, the limit will force transaction fees back up to nearly a dollar, making Bitcoin less useful than PayPal. If there is one problem that effective implementation of Cryptocurrency 2.0 needs to solve, it is this.

The reason we in the cryptocurrency space are running into these issues, and not making much progress toward a solution, is because there is one fundamental problem in all cryptocurrency designs that needs to be addressed. Of all the various proof-of-work, proof-of-stake, and reputation-consensus-based blockchain designs that have been proposed, none have been able to overcome the same basic problem: that each full node must process each transaction individually. It is possible to have nodes that can process every transaction, up to a level of thousands of transactions per second; Centralized systems like Paypal, Mastercard, and banking servers do this well. However, the problem is that setting up such a server requires a large amount of resources, and thus there is no incentive for anyone except a few large companies to do so. Once that happens, those few nodes will likely be vulnerable to profit motives and regulatory pressure, and may start making theoretically unauthorized changes to the state, such as giving themselves free money, and all other users, who rely on those central nodes for security. They will have no way to prove that the block is invalid because they do not have the resources to process the entire block.

In Ethereum, up to this point, we don’t have any fundamental improvements to the principle that every full node should process every transaction. There have been ingenious ideas proposed by many Bitcoin developers that involve multiple chains being mined in combination with a protocol to move funds from one chain to another, and this will be a large part of our research efforts in the cryptocurrency space, but at this stage research into how this can be implemented optimally has not been done. Ripen yet. However, with the introduction of… Protocol Block 2.0 (BP2), we have a protocol that, while not getting past the fundamental flaw in blockchain scalability, gets us there: as long as there is at least one honest full node (which, for anti-spam reasons, contains at least 0.01%) mining power or ownership of ether), “light clients” that download only a small amount of data from the blockchain can maintain the same level of security as full nodes.

What is a light client?

The basic idea behind the light client is that thanks to the data structure found in Bitcoin (and thus Modified form, Ethereum) called a Merkle tree, it is possible to create a proof of the existence of a particular transaction in a block, such that the proof is much smaller than the block itself. Currently, the Bitcoin block size is around 150 KB; The size of Merkle’s proof of transaction is about half a kilobyte. If Bitcoin blocks become 2GB in size, proofs may expand to a full kilobyte. To create a directory, one simply needs to follow the “branch” of the tree all the way from transaction to root, providing nodes on the side every step of the way. Using this mechanism, light clients can ensure that transactions sent to them (or from them) have actually been converted into a block.

This makes it very difficult for malicious miners to trick light clients. If, in a virtual world where running a full node is completely impractical for ordinary users, if a user wanted to claim that he sent 10 BTC to a merchant who did not have enough resources to download the entire block, the merchant would not be helpless; They will ask for proof that the transaction sending 10 BTC to them actually exists in the block. If the attacker were a miner, they would likely be more sophisticated and actually place such a transaction in a block, but make them spend money (eg UTXO) that doesn’t actually exist. However, even here there is a defense: a light client can request a second Merkle tree proof showing that the money spent by the 10 BTC transaction also exists, and so on down to the safe block depth. From the point of view of a miner using a light client, this turns into a challenge response protocol: full nodes verifying transactions, upon discovering that a transaction has spent non-existent output, can publish a “challenge” on the network, and other nodes (potentially a miner That block) needs to post a “response” consisting of a Merkle tree proof showing that the output in question already exists in some previous block. However, there is one weakness of this Bitcoin protocol: transaction fees. A malicious miner could post a block giving themselves a 1,000 BTC reward, and other miners using light clients would have no way of knowing that this block is invalid without adding in all the fees from all the transactions themselves; For all they knew, someone else could have been crazy enough to add a 975 BTC fee.

HB2

With the previous Block Protocol 1.0, Ethereum was even worse; There was no way for a light client to verify that the block’s state tree was a valid result of the original state and transaction list. In fact, the only way to get any guarantees at all was for the node to run each transaction and apply it sequentially to the parent state itself. However, H.A.2 adds some stronger assertions. with HB2Each block now has three trees: a state tree, a transaction tree, and a stack trace tree that provides the intermediate root of the state tree and transaction tree after each step. This allows for a challenge response protocol that works, in simplified form, as follows:

1. Miner M publishes block B. The miner may be malicious, in which case the block incorrectly updates the state at some point.

2. Light node L receives block B, and performs basic checks of functionality and structural validity on the head. If these verifications succeed, L begins to treat the block as legitimate, even though it is unconfirmed.

3. Full node F receives block B, and initiates a full verification process, applying each transaction to the original state, and ensuring that each intermediate state matches the intermediate state provided by the miner. Suppose F finds an asymmetry at point k. Next, F broadcasts a “challenge” to the network consisting of the hash B and the value k.

4. L receives the challenge, and temporarily flags B as untrustworthy.

5. If F’s claim is false, and the block is valid at that point, M can produce proof of local consistency by showing the Merkle tree proof for point k in the stack trace, point k+1 in the stack trace, and the subset Merkle tree nodes in the state and transaction tree which is modified during the update process from k to k+1. L can then verify the proof by taking M’s word about the validity of the block up to point k, manually running the update from k to k+1 (this consists of processing a single transaction), and ensuring that the root hash matches the M provided at the end. Of course, L will also check the validity of the Merkle tree proof for values ​​in state k and k+1.

6. If F’s claim is true, M will be unable to come up with a response, and after a while will completely ignore LB.

Note that the current model is to burn transaction fees, not distribute them to miners, so the vulnerability in Bitcoin’s light client protocol does not apply. However, even if we decide to change this, the protocol can easily be adapted to handle it; The stack trace will also simply keep a running counter of transaction fees along with a list of status and transactions. As an anti-spam measure, for an F challenge to be valid, F must either mine one of the last 10,000 blocks or hold 0.01% of the total supply of ether for at least a certain period of time. If a full node sends a false challenge, meaning the miner successfully responds to it, light nodes can blacklist the node’s public key.

Overall, what this means is that, unlike Bitcoin, Ethereum is likely to remain quite secure, including against fraudulent issuance attacks, even if there are only a small number of full nodes; As long as at least one full node is honest, verifies blocks and posts challenges where appropriate, light clients can rely on it to flag faulty blocks. Note that there is one weak point in this protocol: now you need to know all the transactions in advance before processing the block, and adding new transactions requires a lot of effort to recalculate the intermediate stack trace values, so the block production process will be less efficient. However, the protocol will likely need to be patched to overcome this issue, and if possible, BP2.1 will have such a fix.

Blockchain based mining

We haven’t finalized the details of this, but Ethereum will likely use something similar to the following in its mining algorithm:

1. Let 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. Let T[i] be (h[i] mod N) The transaction in the block.

4. Let S be the state of the original block.

5. Application T[0] … T[15] to S, and let the resulting state be S’.

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

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

This has the following characteristics:

1. This is very difficult for memory, even more so daggerSince mining effectively requires access to the entire blockchain. However, it is parallelizable to shared disk space, so it will likely be dominated by the GPU, not the CPU as Dagger originally hoped.

2. This is easy to verify by memory, since the validity proof only consists of a relatively small subset of the Patricia nodes used during the processing of T[0] … T[15]

3. All miners must be full nodes; Asking the network for blocking data every time is very slow. Therefore, there will be more full nodes in Ethereum than in Bitcoin.

4. As a result of (3), one of the main motivations for using centralized mining pools is eliminated, which is the fact that they allow miners to work without downloading the entire blockchain. The other main reason to use mining pools, the fact that they bypass the payout rate, can just as easily be achieved through a decentralized p2pool (which we will likely end up backing with development resources).

5. The ASICs of this mining algorithm are at the same time ASICs for processing transactions, so Ethereum ASICs will help solve the scalability problem.

From here, there is only one improvement that can be made: discovering some way to get around the hurdle that every full node must process every transaction. This is a difficult problem. Developing an effective and scalable solution will take time. However, this is a strong start, and may end up being one of the key components of the final solution.