Merge pull request #855 from cdetrio/eip-4-author

clarify EIP 4 author

EIPS/eip-4.mediawiki → EIPs/eip-4.md

@@ -2,52 +2,52 @@
   EIP: 4
   Layer: Process
   Title: EIP Classification
-  Author: Eric Lombrozo
+  Author: Joseph Chow
   Status: Draft
   Type: Process
   Created: 2015-11-17
 </pre>
 
-==Abstract==
+# Abstract
 
-This document describes a classification scheme for EIPs, adapted from BIP123.
+This document describes a classification scheme for EIPs, adapted from [BIP 123](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki).
 
 EIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements.
 
 The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards EIP belongs.
 
-==Motivation==
+# Motivation
 
 Ethereum is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them.
 
 In order to have a EIP process which more closely reflects the interoperability requirements, it is necessary to categorize EIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed.
 
-==Specification==
+# Specification
 
 Standards EIPs are placed in one of four layers:
 
-# Consensus
-# Networking
-# API/RPC
-# Applications
+1. Consensus
+2. Networking
+3. API/RPC
+4. Applications
 
-===1. Consensus Layer===
+# 1. Consensus Layer
 
 The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence.
 
 The consensus layer is not concerned with how messages are propagated on a network.
 
 Disagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks.
 
-====Soft Forks====
+## Soft Forks
 
 In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules.
 
-====Hard Forks====
+## Hard Forks
 
 In a hard fork, structures that were invalid under the old rules become valid under the new rules.
 
-===2. Networking Layer===
+# 2. Networking Layer
 
 The networking layer specifies the Ethereum wire protocol (eth) and the Light Ethereum Subprotocol (les).  RLPx is excluded and tracked in the [https://github.com/ethereum/devp2p devp2p repository].
 
@@ -56,12 +56,12 @@ Only a subset of subprotocols are required for basic node interoperability. Node
 It is always possible to add new subprotocols without breaking compatibility with existing protocols, then gradually deprecate older protocols. In this manner, the entire network can be upgraded without serious risks of service disruption.
 
 
-===3. API/RPC Layer===
+# 3. API/RPC Layer
 
 The API/RPC layer specifies higher level calls accessible to applications. Support for these EIPs is not required for basic network interoperability but might be expected by some client applications.
 
 There's room at this layer to allow for competing standards without breaking basic network interoperability.
 
-===4. Applications Layer===
+# 4. Applications Layer
 
-The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data. 
+The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.

README.md

@@ -14,7 +14,7 @@ First review [EIP-1](EIPS/eip-1.md). Then clone the repository and add your EIP
 | Number                    | Title                                                   | Author                        | Layer     | Status     |
 | ------------------------- | ------------------------------------------------------- | ----------------------------- | --------- | ---------- |
 | [3](EIPS/eip-3.mediawiki) |  Addition of CALLDEPTH opcode                           | Martin Holst Swende           | Core      | Draft      |
-| [4](EIPS/eip-4.mediawiki) |  EIP Classification                                     | Eric Lombrozo                 | Meta      | Draft      |
+| [4](EIPS/eip-4.mediawiki) |  EIP Classification                                     | Joseph Chow                   | Meta      | Draft      |
 | [5](EIPS/eip-5.md)        |  Gas Usage for `RETURN` and `CALL*`                     | Christian Reitwiessner        | Core      | Draft      |
 | [101](EIPS/eip-101.md)    |  Serenity Currency and Crypto Abstraction               | Vitalik Buterin               |           | Active     |
 | [158](EIPS/eip-158.md)    |  State clearing                                         | Vitalik Buterin               | Core      | Superseded |