Ethereum Five Years: Awakening from Nirvana
Editor's Note: This article comes fromUnitimes（ID：Uni-times）, published with permission.
Editor's Note: This article comes from
"The Prehistory of the Ethereum Protocol" by Vitalik Buterin, translated by: Nabaier
"Ethereum is 5 years old! "Author: Ethereum Foundation, translation: Johnny
secondary title
When the blockchain once again entered the general public's field of vision and received unprecedented attention from technology giants, Ethereum has become a giant ship that cannot be ignored in the blockchain field. In the chaotic era of unscrupulous and brutal growth of capital, the developers and community of Ethereum have always carefully cared for this small ship, kept a steady direction, and upgraded it into a generation of giant ships along the way.
July 30, 2020 is not only the fifth anniversary of Ethereum, but also the expected one: a few days later, the test network of Ethereum 2.0 will be officially launched, marking that Ethereum is one step away from the world's computers. stride. Up to now, more than 92% of the launch progress of the Ethereum 2.0 test network has been completed.
secondary title
catastrophe
On June 17, 2016, Vitalik, the founder of Ethereum, issued an urgent warning on Reddit, informing that "DAO was attacked by hackers, all trading platforms are requested to immediately suspend ETH/DAO transactions and deposit and withdrawal". This one-month offensive and defensive war ended with the split of the Ethereum blockchain into ETH (continuing the name "Ethereum") and ETC (Ethereum Classic). After experiencing The DAO incident, Ethereum could not get rid of the question of "centralization" for a long time, and was besieged by other outside communities.
People's celebrations today seem to have forgotten the lessons of yesterday. In the future, the biggest enemy of Ethereum is not from the outside, but from the inside itself. Ensuring that every detailed module of an aircraft carrier is functioning properly is far more difficult than defending against foreign enemies.
After the birth of Ethereum, the founding team members gradually shifted their focus to a broader field, or devoted themselves to expanding the ecology of Ethereum, or devoted themselves to exploring new technologies, and became competitors of Ethereum. Today, apart from Vitalik who is still focusing on the development of Ethereum, the other founders are working on the Ethereum social framework Akasha (Mihai Alisie), Jaxx Wallet (resigned, Anthony Dilorio), public chain Cardano (Charles Hoskinson), Polkadot and Web3 Foundation Will (Gavin Wood).
to be continued
secondary titlehttps://vitalik.cato be continued
Wrote an article reviewing "How Ethereum was born". On the occasion of the fifth birthday of Ethereum, we might as well review this "Prehistory of the Ethereum Protocol".
This article is an excerpt from "Ideal: The Genesis of Ethereum's Blockchain" written by Vitalik Buterin and translated and published by Lingtai Technology and Unicorn Times. At the same time, I sincerely thank every developer, translator and evangelist in the Ethereum community. Because of you, the world of blockchain is no longer monotonous.
secondary title
The Prehistory of the Ethereum Protocol
(September 14, 2017)
Editor’s note: This article is Vitalik’s recollection of the development process of the Ethereum protocol, telling the story of the Ethereum protocol from conception to initial release and iteration.
Although the ideas behind the current Ethereum protocol have largely stabilized in the past two years, the current idea and complete form of Ethereum did not take shape overnight. After the launch of the Ethereum blockchain, its protocol has undergone a series of significant evolutions and decisions. This article aims to review the evolution of the Ethereum protocol from its inception to its release. As for the extensive work done by Geth, cppethereum, pyethereum, and EthereumJ in the process of implementing the protocol, as well as the application and business history of the Ethereum ecosystem, it will be beyond the scope of this article.
Also out of scope is the history of Casper and sharding research. No doubt we could write more articles discussing the various points that Vlad, Gavin, myself, and others have made and discarded, including proof-of-work, round-robin Auxiliary multi-chain, hypercube, shadow chain (can be said to be the predecessor of Plamsa), chain fiber and various iterative versions of Casper, as well as Vlad's proposed incentive mechanism and its nature for participants in the consensus protocol The rapid evolution of reasoning ideas. The story behind these points is itself complex enough to deserve another article. Therefore, we will not discuss them for now.
Let's start with the earliest version. This version eventually became Ethereum, but at the time it wasn't even called Ethereum. When I visited Israel in October 2013, I spent a lot of time with the Mastercoin team and even suggested that they add certain features. After thinking twice about what they've done, I sent the team a proposal to make their protocol more general and able to support more types of contracts without adding a large and complex feature set:
It should be noted that this version is very different from the broader vision of Ethereum in the later period: it focuses purely on the technology that Mastercoin was trying to break through at the time, namely two-party contracts. In this contract, party A and party B jointly invest funds, and then both parties can withdraw funds according to some formula specified in the contract (for example, the content of the bet is "if X happens, give all funds to A; Otherwise, give all funds to B"). The scripting language implementing this contract is not Turing complete.
The Mastercoin team is impressed by this, but they are not interested in giving up everything they have done to move in this direction, and I am increasingly convinced that this is the right choice. So, around December, a second version came out:
In this release, you can see the results of the extensive refactoring done. Much of these results came to mind during a long walk in San Francisco in November. At that point, I realized that smart contracts have the potential to be completely general. Compared with the script language that can only simply describe the relationship between the two parties, the contract itself is a mature account, and has the ability to hold, send and receive assets, and can even maintain permanent storage (at that time, permanent storage was called "memory", and the only temporary "memory" is 256 registers). It's just that the language has changed from a stack-based virtual machine to a register-based virtual machine that is more in line with my wishes. I have little issue with this, except that it seems more complicated.
"Ether" literally means ether (that is, fuel, equivalent to gas). After each calculation step is completed, the balance of the contract called by a transaction will be reduced by some. If the funds of the contract are exhausted, then the execution process will stop. Note that this receiver pays mechanism means that the contract itself must require the sender to pay a fee to the contract. If the fee has not been received, the execution will be withdrawn immediately. This version of the protocol assigns a limit of 16 free execution steps, allowing contracts to reject transactions that do not pay a fee.
As of this point, the Ethereum protocol is completely built by me alone. However, from this point on, new players started to join the Ethereum camp. The most prominent player in terms of agreement so far has been Gavin, who started contacting me in December 2013 via a private message on about.me.
Jeffrey Wilcke, lead developer of the Go client (then called "ethereal"), also contacted me around the same time and started programming. Although his contributions were more in client development than protocol research.
Gavin's early contributions were twofold. First, you may have noticed that the contract invocation model in the original design was asynchronous: although contract A could create an internal transaction to contract B ("internal transactions" are Ethereum jargon: originally they were just called "transactions") , subsequently referred to as "message call" or "call"). The execution of the internal transaction will not start until the execution of the first transaction is fully completed. This means that transactions cannot use internal transactions as a way to get information from other contracts; to get information from other contracts, you can only use the EXTRO opcode (kind of like the SLOAD you use to read other contract storage), but this opcode is then Removed with support from Gavin and others.
Gavin made a very subtle change in the vision of Ethereum in a big way: from a platform for building programmable money - a platform with blockchain-based contracts that can hold digital assets and follow pre-set transfers according to the rules - to a common computing platform. This change started with a slight change in focus and terminology for Ethereum, and later as we embraced Web 3 integration (which sees Ethereum as part of the decentralized technology suite, the other two being Whisper and Swarm, Figure 1) is increasingly emphasized, and this effect is also continuously strengthened.
figure 1
Around early 2014, we also made some changes based on suggestions from others. After Andrew Miller et al floated the idea of going back to a stack-based architecture, we eventually went back (Figure 2).
figure 2
image description
figure 2
Charles Hoskinson suggested that we switch from Bitcoin's SHA256 to the newer SHA3 (or, more precisely, keccak256). Although it was debated for a while, discussions with Gavin, Andrew, and others established that the size of values on the stack should be limited to 32 Bytes. An alternative—unbounded integers—is still under consideration because of the problem with it that it's hard to figure out how much gas is needed to perform additions, multiplications, and other operations.
Back in January 2014, the mining algorithm we first thought of was something called Dagger:
Dagger is named after a Directed Acyclic Graph (DAG). DAG is a mathematical structure used in the algorithm. The idea is that every N blocks, there will be a new DAG pseudo-randomly generated by the seed. Moreover, the bottom layer of DAG will be a collection of nodes that need to be stored in billions of bytes. However, in a DAG, generating any individual value only requires computing a few thousand entries. A dagger computation consists of taking a certain number of values anywhere in this underlying dataset, and then hashing those values together. This means that there is a fast way to do dagger calculations - already storing the data in memory, and then in a slow but not memory-intensive way - to regenerate from the DAG every bit you need to fetch from scratch a value.
The purpose of this algorithm is to have the same memory-constrained properties as popular algorithms at the time, like the Scrypt algorithm, but still be friendly to light clients. Miners will use fast methods, so their mining will be limited by memory bandwidth (theoretically, consumer-level memory is optimized enough that further optimization with ASICs is very difficult), but light clients Validation can be done in a memory-forgiving and slow manner. Fast methods may take microseconds, while slow and memory-friendly methods may take milliseconds, so this is still feasible for light clients.
From here, the algorithm has undergone several changes over the course of Ethereum's development. The next idea is Adaptive Proof of Work. In this scheme, proof-of-work would involve executing randomly selected Ethereum contracts, and there is a clever way to resist ASICs: if ASICs are developed, then competing miners will have an incentive to Create and issue a contract that the ASIC is not good at executing. No ASIC can be used for general computing because it is just a CPU. Thus, we can leverage these types of adversarial incentives to implement proof-of-work that essentially performs general-purpose computation.
The idea later fell apart for one simple reason. This reason is a long-range attack. An attacker can build a chain starting from block 1 and populate the chain with only simple contracts. It should be noted that the attacker can design special hardware for this simple contract, so that the attack chain can quickly catch up with the main chain. So... back to square one.
The next algorithm is called "random circuits" and its description can be found in its Google documentation. This algorithm was proposed by me and Vlad Zamfir and analyzed by Matthew Wampler-Doty and others. The idea of this algorithm is to simulate the general computation in the mining algorithm by implementing a pseudo-random generation circuit. This time, there isn't any hard evidence that something based on these principles won't work. But the computer hardware experts we spoke to in 2014 were very pessimistic. Matthew Wampler-Doty proposed a proof-of-work based SAT solution, which was also rejected.
In the end, after a bit of a spin, we came up with the Dagger Hashimoto algorithm, sometimes simply called Dashimoto. This algorithm borrows many ideas from Hashimoto. Hashimoto is a proof-of-work mechanism proposed by Thaddeus Dryja, which pioneered the concept of "I/O-constrained proof-of-work". In this mechanism, the main limiting factor in mining speed is not the speed of hash operations per second, but the number of megabytes of RAM accessible per second. However, Dagger Hashimoto combines this proof-of-work mechanism with datasets generated by a light-client-friendly DAG in the Dagger algorithm. After many tweaks by myself, Matthew, Tim, and others, these ideas were finally incorporated into the algorithm we now call "Ethash".
By the summer of 2014, except that the proof of work will not reach the Ethash stage until early 2015, the protocol has been quite stable, and its semi-formal specification has been published in the form of Gavin's yellow paper.
In August 2014, I developed and introduced the uncle block mechanism. This mechanism can enable Ethereum's blockchain to have shorter block times and higher processing capabilities, while reducing the risk of centralization. For the introduction of the uncle block mechanism, please refer to PoC6.
After discussions with the BitShares team, we considered using the heap as a first-class data structure - although in the end we didn't do so due to lack of time, and later security audits and DoS attacks made it clear to us that implementing this feature safely at the time was far more difficult than we thought more difficult.
In September, Gavin and I plan to make two major changes to the protocol design. First of all, in addition to the state tree and transaction tree, each block will also contain a receipt tree. The receipt tree will contain a hash of the log created by each transaction and an intermediate state root. The log will allow transactions to create outputs that can be stored in the blockchain and accessed by light clients. However, future state computations do not have access to these logs. This approach enables decentralized applications to easily query events such as token transfers, purchases, exchange orders being created and matched, auctions in progress, etc.
We also considered other ideas, such as extracting Merkle trees from the complete execution trace of a transaction to allow arbitrary content to be proved. After a compromise between simplicity and completeness, we chose to use logs.
The second is the idea of precompilation. Precompilation solves the problem of allowing complex cryptographic computations to be available in the EVM without having to deal with EVM overhead. We've also come up with a lot of ambitious ideas for native contracts. In these ideas, if miners have a better implementation method for certain contracts, then they will vote to lower the gas price of these contracts. In this way, those contracts that can be executed quickly by most miners will naturally have lower gas prices. However, all these ideas were rejected because we could not come up with a cryptoeconomically secure way to implement it. An attacker can always create some contract to perform a cryptographic operation with a trapdoor, and then distribute the trapdoor to himself and their friends to be able to execute this contract faster. The attacker then votes to lower gas prices and uses this to DoS the network. Instead, we opted for a less ambitious approach of simply specifying small precompiled quantities in the protocol for common operations like hashing and signature schemes.
Gavin was also a key figure in the initial support for the idea of developing protocol abstractions. The so-called protocol abstraction is to migrate many parts of the protocol, such as the balance of Ethereum, transaction signature algorithm, random number, etc., into the protocol itself as a contract. Its theoretical ultimate goal is to achieve a goal where the entire Ethereum protocol can be described as adding function calls to a virtual machine with a specific pre-initialized state. We didn't have enough time to incorporate all of these ideas into the initial bleeding edge release, but expect these principles to slowly start to be integrated through some changes in "Constantinople", Casper contracts, and sharding specifications.
These are all implemented in PoC 7. The protocol hasn't really changed much after PoC 7, except for a few minor but in some cases significant changes. These details will be announced after passing a security audit.
By early 2015, Jutta Steiner and others organized pre-release security audits, including software code audits and academic audits. Software code auditing is mainly implemented in C++ and Go languages led by Gavin and Jeffrey respectively. Although my Pyethereum implementation also does a simple audit. Of the two academic audits, one was conducted by Ittay Eyal (of fame for proposing "selfish mining") and the other by Andrew Miller and other members of the Least Authority. Eyal's audit resulted in a slight protocol change whereby uncle blocks would not be included in the chain's total difficulty value. The audit by Least Authority focused more on smart contracts, fuel economics, and Patricia trees. The audit also resulted in several protocol changes. Among them, a relatively small change is to use sha3(addr) and sha3(key) as the key value of the tree instead of directly using the address and key value. This will make it harder for an attacker to mount worst-case attacks on the tree.
Another important issue we discussed was the gas limit voting mechanism. At that point, we were already concerned about the lack of progress in the Bitcoin block size debate and wanted to have a flexible design in Ethereum: one that could be adjusted over time as needed. But the challenge is, what are the optimal constraints? My initial thought was to have a dynamic limit of 1.5 times the long term exponential moving average of actual fuel usage. Therefore, in the long run, the average block will take up 2/3 of the capacity. However, Andrew demonstrates that this limit can be exploited in some ways—specifically, that miners who want to raise the limit need only include transactions that consume a lot of gas but take little processing time in their own of blocks, thus creating fully loaded blocks without losing costs. Therefore, at least in the end result, the security model of this mechanism is equivalent to just letting miners vote on the gas limit.
After a mini-hackathon with Gavin and Jeff, PoC 9 finally came out in March. It is intended to be the final version of the proof of concept. We ran a testnet called "Olympiad" for 4 months. This testnet uses the protocol that will be used in the mainnet. At the same time, we also established our long-term plans for Ethereum. Vinay Gupta wrote an article - "The Ethereum Launch Process". This article describes 4 phases of Ethereum mainnet development, giving corresponding names that are now familiar to everyone: "Frontier", "Homeland", "Metropolis" and "Serenity".
The "Olympic" testnet has been running for 4 months. In the first 2 months, we found many bugs in various implementation versions, and other issues such as consensus failures also occurred. But around June, the network has stabilized significantly. In July, we decided to freeze the code; on July 30, the Ethereum mainnet was officially released.
A birthday celebration from the Ethereum Foundation
text
text
text
text
text
text
In these 5 years, Ethereum has grown beyond the scope of any builder, team, or organization, but I hope you will continue to keep your thoughts flowing as always, and continue to work together to make Ethereum achieve everything we can all dream of, and even more many. 🦄
