You can listen to or watch this article here:
One of the brilliant inventions of the Ethereum blockchain standard, which is the underlying protocol in Ethereum Classic (ETC), is the Ethereum Gas System, which solved the halting problem in secure distributed Turing complete computing networks.
As Bitcoin accepts a very limited, specific, and simple set of transaction types all nodes and miners in the network just accept those transactions based on their structure and post them on the blockchain after hashing and validation. For transactions to be accepted and hashed by miners, users need to send them with a fee that is paid to them. However, regardless of the fees paid to miners, or the volume of transactions, each block in Bitcoin has a fixed size in megabytes and weight, as per protocol, that determines the number of transactions that fit in a block.
The problem with the Ethereum standard is that it stores software programs that are executed by what is called a shared virtual machine by all nodes in parallel in the peer-to-peer network. Those programs can be very complex and diverse. In computer science, when programs become complex and diverse they may, sometimes, have processes or bugs that either don’t finish computing and/or that cause the host machine to run indefinitely without delivering a result.
It is a similar problem as when your laptop starts the infinite spinning wheel and you have to restart it:
The Ethereum specification, as per its yellow paper, determines a list of operations the Ethereum Virtual Machine (EVM) can compute. Developers and users then enter and store software programs, or smart contracts, based on those defined operations, or opcodes. As these programs can be complex, consume a lot of time and computation, or can create the halting problem, the yellow paper also specifies a maximum amount of computation each opcode can consume.
Just as humans many times work and get paid by the hour, e.g. 8 hours a day at $X per hour, or $Y dollars per hour for consulting, or lawyers charge $Z by the hour, the computers in the Ethereum protocol charge “gas” instead of “hours”. This gas is determined per opcode in proportion to its complexity and demand in computing effort.
For example, just as a lawyer would charge 10 hours to draft a contract at $75 per hour, a computer in Ethereum would charge 32000 gas at 0.00000001 ETH per gas for a “Gcreate” operation:
So, the design is brilliant because it:
• Solves the halting problem in a p2p computing network.
• Efficiently allocates scarce computing resources in an Ethereum based network.
• Prevents network abuse as the computers in the system charge a fee in exchange for their work, imposing a cost to potential attackers.
Physical and Economic Constraints
However, the last problem the system had to solve is that it needed to establish a limit to all the transactions, or computations, it could take per block. This is because, in a global computer peer-to-peer consensus blockchain, there are a set of constraints that bound its efficient and secure operation:
1) The time it takes to propagate transactions and blocks.
2) The time it takes for the same transactions and blocks to process locally in each computer in the network.
3) The fee levels per transaction.
4) The total size of the database, or blockchain, as blocks are added every 15 seconds.
In searching to solve this problem, the choice of the Ethereum designers was to have miners, who are the block producers through proof of work, set the limit of each block by signaling a “block limit” to the network. Once all miners agree on a limit, then all accept transactions up to that number to build new blocks.
Using this system, as the Ethereum network increased in popularity, the history of the gas limit per block, which is analogous to block size, has been increasing steadily as miners felt comfortable with block size, propagation times, and their fee levels. Recently they made their last increase to 10,000,000 gas per block:
The Node Count vs Miner Tragedy of the Commons
However, one of the problems the gas system has created for the Ethereum network is that, as miners have been enlarging the block size by increasing the gas limit, the chain has been running the risk of decreasing its node count, a critical security metric, because for new users to synchronize new nodes it is becoming too big of a task given average bandwidth rates in different parts of the world.
What this situation is indicating is a sort of “Tragedy of the Commons” scenario: That miners in Ethereum are evidently managing very well constraints 1), 2) and 3) as explained above, because they benefit them directly and in the short term, but are not as concerned with 4), the total blockchain size, thus lower node count in the network, even if those undermine the network in the medium and long term.
Implications for Ethereum Classic
As Anthony Lusardi has said, Ethereum Classic, as another implementation of the Ethereum protocol, has the advantage of hindsight, so he has introduced ECIP-1047 to mitigate this issue by requesting “that miners target a gas limit of 1 million which is an ~8x reduction from the current limit of ~7.95 million”.
I agree to lower the gas limit in ETC.
My rationale is that it seems there is a loophole in the GAS system: There is a sort of conflict of interest where miners are incentivized to increase gas limit, on one hand, but also to limit it up to a point where they believe they will win the race to earn the rewards and fees per block, and propagate their blocks ASAP as only one wins every round.
That limit seems to have been 8,000,000 gas for a long time, but recently, in the Ethereum network, they increased it to 10,000,000, even if there is ample evidence of network bloating and decreasing node counts. In fact, from more than 15,000 nodes a few years ago, the network is currently operating with around 6500 nodes at the time of this writing.
However, miners don’t care about node count or bloat. In other words, that 8 or 10 million gas limit is only for miner efficiency levels, not for node count maximization.
The 8 or 10 million gas limit, is, evidently, as seen empirically, not a desirable block size for full node users, developers, and enterprise to download and operate nodes. This is why all are using risky trusted third party node and hosting services such as Infura and AWS.
The problem seems to be that block processing and propagation efficiency points are not equivalent to node size, syncing time, and thus node count efficiency points. Both points are different and the miner optimal point is higher than full node optimal point.
This is the loophole in the gas system, and the general misalignment of economic incentives.
What Solutions can be Debated?
In Bitcoin, Satoshi “solved” the block size problem by establishing an arbitrary limit at 1MB in the early days. This does not delegate to miners, or any other party, other than the whole ecosystem by rough consensus, the setting of the block size.
In the case of Ethereum Classic, ECIP-1047 is proposing a suggested gas limit of only 1 million that miners have to agree to. Perhaps that level is too low. At 67000 gas per transaction, which is the average gas cost per transaction I calculated since Ethereum has been operating at “almost full” capacity, starting in August of 2017, that would imply less than 86,000 transactions per day, which would be too restrictive, in my opinion.
The 8,000,000 gas limit, at 67000 gas per transaction, is 680,000 transactions per day, and Ethereum has been floating at around 750,000, so that seems to be the transaction capacity per day for this design and gas limit levels. This is also competitive with large value settlement systems in the fiat world such as FEDWIRE and CHIPS.
As Ethereum is moving to Ethereum 2.0, and the Constantinople and Istanbul upgrades don’t seem to have significant scaling solutions, it seems ETC has to start working on its own scaling research in the Turing complete + proof of work + fixed monetary policy segment.
It seems one part of the solution is to not have miners decide the block size in the first place, and to set it at a certain point that is optimal for both miners and new syncing node operators.
To be able to execute relatively complex transactions with as little gas as possible, while keeping a higher transaction count, to have a block size hard-fixed, as Bitcoin does, at, say, 4,000,000 gas limit would perhaps benefit full node operators and also miners because fees would be higher.
The problem is there needs to be a way to enable ~680,000 transactions or more per day with a 4,000,000 gas limit. That is the next problem to solve.
Code Is Law
