Skip to content

Commit

Permalink
Merge branch 'main' into patch-1
Browse files Browse the repository at this point in the history
  • Loading branch information
nokcha75 authored Jun 18, 2024
2 parents 4084bb7 + 86cf738 commit 1232a8f
Showing 1 changed file with 35 additions and 7 deletions.
42 changes: 35 additions & 7 deletions docs/wiki/protocol/history.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ Useful links: [Overview from Ethereum.org](https://ethereum.org/en/history) and

## Frontier

The Frontier release marked the launch of the Ethereum Protocol. It was launched on July 30, 2015, at 3:26:13 AM UTC, which is the timestamp of the [Ethereum genesis block](https://etherscan.io/block/0). Frontier launched with a gas limit of 5000. This gas limit was hard coded into the protocol to ensure that miners and users could get up and running by installing clients during the initial launch of the protocol. The gas limit would later be increased to 3 million with the Frontier thawing fork (exactly 3,141,592). The canary contracts were contracts that gave a binary signal of either 0 or 1. These canary contracts were an initial launch mechanism used only during the Frontier release of Ethereum. If clients detected that multiple contracts had switched to a signal of 1, they would stop mining and urge the user to update their client. This prevented prolonged outages by ensuring that miners did not prevent a chain upgrade.
The Frontier release marked the launch of the Ethereum Protocol. The release was essentially a beta release that allowed developers to learn, experiment, and begin building Ethereum decentralized apps and tools. It was launched on July 30, 2015, at 3:26:13 AM UTC, which is the timestamp of the [Ethereum genesis block](https://etherscan.io/block/0). Frontier launched with a gas limit of 5000. This gas limit was hard coded into the protocol to ensure that miners and users could get up and running by installing clients during the initial launch of the protocol. The gas limit would later be increased to 3 million with the Frontier thawing fork (exactly 3,141,592). The canary contracts were contracts that gave a binary signal of either 0 or 1. These canary contracts were an initial launch mechanism used only during the Frontier release of Ethereum. If clients detected that multiple contracts had switched to a signal of 1, they would stop mining and urge the user to update their client. This prevented prolonged outages by ensuring that miners did not prevent a chain upgrade.

Learn more about Frontier in the following resources:

Expand All @@ -19,14 +19,42 @@ Learn more about Frontier in the following resources:

## Homestead

Homestead was the second major release of Ethereum. It introduced [EIP-2](https://eips.ethereum.org/EIPS/eip-2), [EIP-7](https://eips.ethereum.org/EIPS/eip-7), and [EIP-8](https://eips.ethereum.org/EIPS/eip-8). EIP-8 ensures that clients on Ethereum support future network upgrades by introducing devp2p forward compatibility requirements. EIP-7 introduced the DELEGATECALL opcode. EIP-2 contained numerous fixes, such as increasing the gas cost for contract creation via transactions, ensuring that contract creation either succeeded or failed (preventing empty contracts from being created), and modifications to the difficulty adjustment algorithm.
Homestead was the second major release of the Ethereum protocol, officially released on March 14, 2016, marking Ethereum’s transition from a beta phase to a more mature and stable platform.
Here are some of the notable features and changes introduced during the Homestead phase:

Learn more about Homestead in the following resources:
- [EIP-2](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md): Homestead Hard-fork Changes

- https://blog.ethereum.org/2016/02/29/homestead-release
- https://eips.ethereum.org/EIPS/eip-2
- https://eips.ethereum.org/EIPS/eip-7
- https://eips.ethereum.org/EIPS/eip-8
1. **Increased gas cost for contract creation:**
The gas cost for creating contracts via a transaction was increased from 21,000 to 53,000.
This change was designed to reduce the excessive incentive to create contracts through transactions rather than through the `CREATE` opcode within contracts, which remained unaffected.
2. **Invalidation of high s-value signatures:**
Transaction signatures with an s-value greater than `secp256k1n/2` are now considered invalid.
This measure addressed a transaction malleability issue, preventing the alteration of transaction hashes by flipping the s-value (`s` -> `secp256k1n - s`).
This change improved the reliability and integrity of transaction tracking.
3. **Contract creation out-of-gas handling:**
If a contract creation did not have enough gas to pay for the final gas fee to add the contract code to the state, the contract creation will fail (i.e., go out-of-gas) rather than leaving an empty contract.
4. **Change the difficulty adjustment algorithm:**
The difficulty adjustment algorithm was modified to address issues observed in the Frontier phase.
The new formula aimed to maintain the targeted block time and prevent excessive deviation by adjusting the difficulty based on the timestamp difference between blocks.

- [EIP-7](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7.md): `DELEGATECALL`

A new opcode, `DELEGATECALL`, was added at `0xf4`.
It functions similarly to `CALLCODE`, but propagates the sender and value from the parent scope to the child scope.
Propagating the sender and value makes it easier for contracts to store another address as a mutable source of code and "pass through" calls to it.
Unlike the `CALL` opcode, there is no additional stipend of gas added, which makes gas management more predictable.

- [EIP-8](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md): devp2p Forward Compatibility Requirements for Homestead

The **devp2p Wire Protocol**, **RLPx Discovery Protocol**, and **RLPx TCP Transport Protocol** specify that implementations should be liberal in accepting packets by ignoring version numbers and additional list elements in hello and ping packets, discarding unknown packet types silently, and accepting new encodings for encrypted key establishment handshake packets.
This ensures all client software can cope with future protocol upgrades and will accept handshakes, allowing liberal acceptance of data from others (see [Postel's Law](https://en.wikipedia.org/wiki/Robustness_principle)).

- Learn more about Homestead in the following resources:

- [Ethereum Homestead Documentation](https://readthedocs.org/projects/ethereum-homestead/downloads/pdf/latest/)
- [The Robustness Principle Reconsidered](https://queue.acm.org/detail.cfm?id=1999945)
- [Homestead blog release post](https://blog.ethereum.org/2016/02/29/homestead-release)
- [The Homestead release](https://github.com/ethereum/homestead-guide/blob/master/source/introduction/the-homestead-release.rst)

## The Merge

Expand Down

0 comments on commit 1232a8f

Please sign in to comment.