Merge pull request #69 from rauljordan/diagram-changes

Modified Diagrams to Reflect Glossary Changes

Former-commit-id: cc808724ebbd9830acd5ef094451f35a420a3939 [formerly 9102a7bce3efa1e2540dacc6bf9a5c1a75f08da9]
Former-commit-id: c4964610a1a08da92347beefe20694776fdb75e5

README.md

@@ -94,7 +94,7 @@ Then, the geth console can start up and you can start a miner as follows:
     > miner.setEtherbase(eth.accounts[0])
     > miner.start(1)
 
-Now, save the passphrase you used in the geth node into a text file called password.txt. Then, once you have this private geth node running on your local network, we will need to generate test, pending transactions that can then be processed into shards by validators and collation proposers. For this, we have created an in-house transaction generator CLI tool.
+Now, save the passphrase you used in the geth node into a text file called password.txt. Then, once you have this private geth node running on your local network, we will need to generate test, pending transactions that can then be processed into collations by proposers. For this, we have created an in-house transaction generator CLI tool.
 
 ## Transaction Generator
 

sharding/README.md

@@ -78,7 +78,8 @@ These collations are holistic descriptions of the state and transactions on a ce
 
 For detailed information on protocol primitives including collations, see: [Protocol Primitives](#protocol-primitives). We will have two types of nodes that do the heavy lifting of our sharding logic: **proposers and collators**. The basic role of proposers is to fetch pending transactions from the txpool, execute any state logic or computation, wrap them into collations, and submit them along with an ETH deposit to a **proposals pool**.
 
-![proposers](https://yuml.me/8a367c37.png)
+<!--[Proposer{bg:wheat}]fetch txs-.->[TXPool], [TXPool]-.->[Proposer{bg:wheat}], [Proposer{bg:wheat}]-package txs>[Collation|header|ETH Deposit], [Collation|header|ETH Deposit]-submit>[Proposals Pool], [Collator{bg:wheat}]subscribe to-.->[Proposals Pool]-->
+![proposers](https://yuml.me/6da583d7.png)
 
 Collators add collations in the proof of work chain, throughout the document named the **canonical chain**. Collators subscribe to updates in the proposals pool and pick a collation in their best interest. Once collators are selected to add collations to the canonical chain, and do so successfully, they get paid by the deposit the proposer offered.
 
@@ -213,7 +214,8 @@ Back to the collators, the collator client begins to work by its main loop, whic
 6.  _**Otherwise, collating client keeps subscribing to block headers:**_ If the user chooses to keep going,
 It will be the proposer client’s responsibility to listen to any new broadcasted transactions to the node and interact with collators that have staked their ETH into the SMC through an open bidding system for collation proposals. Proposer clients are the ones responsible for **state execution** of transactions in the tx pool.
 
-![system functioning](https://i.imgur.com/C54LL1R.png)
+<!--[Transaction Generator]generate test txs->[Shard TXPool],[Geth Node]-deploys>[Sharding Manager Contract{bg:wheat}], [Shard TXPool]<fetch pending txs-.->[Proposer Client], [Proposer Client]-propose collation>[Collator Client],[Collator Client]add collation header->[Sharding Manager Contract{bg:wheat}]-->
+![system functioning](https://yuml.me/4a7c8c5b.png)
 
 ## The Collator Manager Contract
 
@@ -227,7 +229,7 @@ In our Solidity implementation, we begin with the following sensible defaults:
 // Constant values
 uint constant periodLength = 5;
 int constant public shardCount = 100;
-// The exact deposit size which you have to deposit to become a validator
+// The exact deposit size which you have to deposit to become a collator
 uint constant depositSize = 100 ether;
 // Number of periods ahead of current period, which the contract
 // is able to return the collator of that period
@@ -240,7 +242,7 @@ Then, the 4 minimal functions required by the SMC are as follows:
 
 ```javascript
 function deposit() public payable returns(int) {
-    require(!isValidatorDeposited[msg.sender]);
+    require(!isCollatorDeposited[msg.sender]);
     require(msg.value == depositSize);
     ...
 }