fix(1901): change ordering + small fixes

ethereum · axic · Jul 5, 2019 · Apr 2, 2019 · Apr 2, 2019 · Apr 30, 2019
commit bfad558dba940d85c6cd640266f6c6a90129a739
@@ -19,34 +19,35 @@ The OpenRPC Document and generated Documentation that specifies all the methods
 This was first proposed [here as an ECIP](https://github.com/etclabscore/ECIPs/blob/master/ECIPs/ECIP-1053.md), but the benefits of this kind of tooling is apparent across Bitcoin, Ethereum Classic, Ethereum and other JSON-RPC accessible blockchains.
 
 ## Motivation
-EVM-based blockchains lack a form RPC Specification. This proposal attempts to standardize such a specification in a way that is versionable, and both human and machine readable.
+
+Although [EIP-1474](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1474.md) outlines a JSON-RPC specification. Ethereum still lacks a machine-readable JSON-RPC Specification that can be used as the industry standard for tooling. This proposal attempts to standardize such a specification in a way that is versionable, and both human and machine readable.
 
 Ethereum clients can expose RPC endpoints with different method signatures and cause compatability issues between clients.
 
 Developers need a reliable developer experience, and an industry standard way to describe Ethereum JSON-RPC 2.0 APIs.
 
-
-## Implementation
-### How do I Solve the problem?
-JSON-RPC APIs can support the OpenRPC specification by implementing a service discovery method that will return the [OpenRPC document](https://github.com/open-rpc/spec#openrpc-document) for the JSON-RPC API. The method MUST be named `rpc.discover`. The `rpc.` prefix is a reserved method prefix for [JSON-RPC 2.0 Specification](https://www.jsonrpc.org/specification) system extensions.
-
-### Use Case
-This is the vision for the use case of OpenRPC and how it would relate to multi-geth:
-
-![MultGethRpc-usecase](../assets/multi-geth-use-case.png)
-
 ## Specification
 
 ### What is OpenRPC?
+
 The [OpenRPC](https://github.com/open-rpc/spec) Specification defines a standard, programming language-agnostic interface description for [JSON-RPC 2.0](https://www.jsonrpc.org/specification) APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenRPC, a consumer can understand and interact with the remote service with a minimal amount of implementation logic, and share these logic patterns across use cases. Similar to what interface descriptions have done for lower-level programming, the OpenRPC Specification removes guesswork in calling a service.
 
 ##### Structure
+
 This is the structure of an OpenRPC Document:
 
-![openrpc-spec-structure](../assets/OpenRPC_structure.png)
+![openrpc-spec-structure](../assets/eip-1901/OpenRPC_structure.png)
+
+JSON-RPC APIs can support the OpenRPC specification by implementing a service discovery method that will return the [OpenRPC document](https://github.com/open-rpc/spec#openrpc-document) for the JSON-RPC API. The method MUST be named `rpc.discover`. The `rpc.` prefix is a reserved method prefix for [JSON-RPC 2.0 Specification](https://www.jsonrpc.org/specification) system extensions.
+
+### Use Case
 
+This is the vision for the use case of OpenRPC and how it would relate to a client implementation like multi-geth:
+
+![MultGethRpc-usecase](../assets/eip-1901/multi-geth-use-case.png)
 
 ## Rationale
+
 ### Why would we do this?
 Services need to figure out how to talk to each other. If we really want to build the next generation of automation, then having up to date libraries, documented APIs, and modern tools are going to provide easy discovery, on-boarding, and enable end user and developer interaction.
 
@@ -59,16 +60,20 @@ Use cases for machine-readable [JSON-RPC 2.0](https://www.jsonrpc.org/specificat
 - Tests generated in many languages
 - Documentation Generation
 
+### Alternative
 
-## Alternative
-[OpenRPC](https://github.com/open-rpc/spec) documents just describe [JSON-RPC](https://www.jsonrpc.org/specification) APIs services, and are represented in JSON format. These documents may be produced and served statically OR generated dynamically from an application and returned via the [`rpc.discover`](https://github.com/open-rpc/spec#service-discovery-method) method. This gives projects and communities the flexibility to adopt tools before the [`rpc.discover`](https://github.com/open-rpc/spec#service-discovery-method) method is implemented.
+[OpenRPC](https://github.com/open-rpc/spec) documents just describe [JSON-RPC](https://www.jsonrpc.org/specification) APIs services, and are represented in JSON format. These documents may be produced and served statically OR generated dynamically from an application and returned via the [`rpc.discover`](https://github.com/open-rpc/spec#service-discovery-method) method. This gives projects and communities the opportunity to adopt tools, documentation, and clients outlined in the [etclabscore/ethereum-json-rpc-specification](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1474.md) before the [`rpc.discover`](https://github.com/open-rpc/spec#service-discovery-method) method is implemented for a particular client.
+
+## Implementation
+
+- [Multi-Geth OpenRPC Discovery](https://github.com/multi-geth/multi-geth#openrpc-discovery)
 
 ## Resources
 
 - [Multi-Geth OpenRPC Discovery](https://github.com/multi-geth/multi-geth#openrpc-discovery)
 - [EDCON 2019 talk on OpenRPC and The Future of JSON-RPC Tooling](https://www.youtube.com/watch?v=UgSPMZ9FQ4Q)
-- [open-rpc.org](https://open-rpc.org)
 - [etclabscore/ethereum-json-rpc-specification](https://github.com/etclabscore/ethereum-json-rpc-specification)
+- [open-rpc.org](https://open-rpc.org)
 
 ## Copyright