move docs/ image files into images/ directory

Author: peterargue

CodingConventions.md

@@ -111,7 +111,7 @@ Per convention, a vertex should throw any unexpected exceptions using the relate
 
 3. **Whether a particular error is benign or an exception depends on the caller's context. Errors _cannot_ be categorized as benign or exception based on their type alone.**
 
-   ![Error Handling](/docs/ErrorHandling.png)
+   ![Error Handling](/docs/images/ErrorHandling.png)
 
    * For example, consider `storage.ErrNotFound` that could be returned by the storage lager, when querying a block by ID
    (method [`Headers.ByBlockID(flow.Identifier)`](https://github.com/onflow/flow-go/blob/a918616c7b541b772c254e7eaaae3573561e6c0a/storage/headers.go#L15-L18)).

DEVELOPMENT.md

@@ -40,7 +40,7 @@ incl. migrations of the entire execution state to a new formats become reasonabl
 Additional context on HCU vs sporks can be found [here](https://developers.flow.com/networks/node-ops/node-operation/hcu#hcu-versus-spork).   
 
 
-<img src='./docs/flow-go_branching-convention.png' width='350'>
+<img src='./docs/images/flow-go_branching-convention.png' width='350'>
 
 
 

cmd/access/README.md

@@ -88,4 +88,4 @@ This helps identify nodes in the system which are unreachable.
 
 ### Access node sequence diagram
 
-![Access node sequence diagram](/docs/AccessNodeSequenceDiagram.png)
+![Access node sequence diagram](/docs/images/AccessNodeSequenceDiagram.png)

consensus/hotstuff/README.md

@@ -148,15 +148,15 @@ For primary section, we use a randomized, weight-proportional selection.
 HotStuff's core logic is broken down into multiple components. 
 The figure below illustrates the dependencies of the core components and information flow between these components.
 
-![](/docs/ComponentInteraction.png)
+![](/docs/images/ComponentInteraction.png)
 <!--- source: https://drive.google.com/file/d/1rZsYta0F9Uz5_HM84MlMmMbiR62YALX-/ -->
 
 * `MessageHub` is responsible for relaying HotStuff messages. Incoming messages are relayed to the respective modules depending on their message type.
 Outgoing messages are relayed to the committee though the networking layer via epidemic gossip ('broadcast') or one-to-one communication ('unicast').
 * `compliance.Engine` is responsible for processing incoming blocks, caching if needed, validating, extending state and forwarding them to HotStuff for further processing.
   Note: The embedded `compliance.Core` component is responsible for business logic and maintaining state; `compliance.Engine` schedules work and manages worker threads for the `Core`.
 * `EventLoop` buffers all incoming events. It manages a single worker routine executing the EventHandler`'s logic.
-* `EventHandler` orchestrates all HotStuff components and implements the [HotStuff's state machine](/docs/StateMachine.png).
+* `EventHandler` orchestrates all HotStuff components and implements the [HotStuff's state machine](/docs/images/StateMachine.png).
 The event handler is designed to be executed single-threaded.
 * `SafetyRules` tracks the latest vote, the latest timeout and determines whether to vote for a block and if it's safe to timeout current round. 
 * `Pacemaker` implements Jolteon's PaceMaker.  It manages and updates a replica's local view and synchronizes it with other replicas.
@@ -190,7 +190,7 @@ The event handler is designed to be executed single-threaded.
 
 We have translated the HotStuff protocol into the state machine shown below. The state machine is implemented in `EventHandler`.
 
-![](/docs/StateMachine.png)
+![](/docs/images/StateMachine.png)
 <!--- source: https://drive.google.com/file/d/1la4jxyaEJJfip7NCWBM9YBTz6PK4-N9e/ -->
 
 
@@ -222,7 +222,7 @@ In contrast to HotStuff, Jolteon only allows a transition into view `V+1` after
 A central, non-trivial functionality of the PaceMaker is to _skip views_. 
 Specifically, given a QC or TC with view `V`, the Pacemaker will skip ahead to view `V + 1` if `currentView ≤ V`.
 
-![](/docs/PaceMaker.png)
+![](/docs/images/PaceMaker.png)
  <!--- source: https://drive.google.com/file/d/1la4jxyaEJJfip7NCWBM9YBTz6PK4-N9e/ -->
 
 
@@ -273,7 +273,7 @@ For completeness, we list the component implemented in each sub-folder below:
 The HotStuff state machine exposes some details about its internal progress as notification through the `hotstuff.Consumer`.
 The following figure depicts at which points notifications are emitted. 
 
-![](/docs/StateMachine_with_notifications.png)
+![](/docs/images/StateMachine_with_notifications.png)
  <!--- source: https://drive.google.com/file/d/1la4jxyaEJJfip7NCWBM9YBTz6PK4-N9e/ -->
 
 We have implemented a telemetry system (`hotstuff.notifications.TelemetryConsumer`) which implements the `Consumer` interface.

consensus/hotstuff/cruisectl/README.md

@@ -61,7 +61,7 @@ The desired idealized system behaviour would a constant view duration $\tau_0$ t
 
 However, in the real-world system we have disturbances (varying message relay times, slow or offline nodes, etc) and measurement uncertainty (node can only observe its local view times, but not the committee’s collective swarm behaviour).
 
-<img src='https://github.com/onflow/flow-go/blob/master/docs/CruiseControl_BlockTimeController/PID_controller_for_block-rate-delay.png' width='680'>
+<img src='https://github.com/onflow/flow-go/blob/master/docs/images/CruiseControl_BlockTimeController/PID_controller_for_block-rate-delay.png' width='680'>
 
 
 After a disturbance, we want the controller to drive the system back to a state, where it can closely follow the ideal behaviour from there on.
@@ -72,21 +72,21 @@ After a disturbance, we want the controller to drive the system back to a state,
     - setting the differential term $K_d=0$, the controller responds as expected with damped oscillatory behaviour
       to a singular strong disturbance. Setting $K_d=3$ suppresses oscillations and the controller's performance improves as it responds more effectively.
 
-      <img src='https://github.com/onflow/flow-go/blob/master/docs/CruiseControl_BlockTimeController/EpochSimulation_029.png' width='900'>
+      <img src='https://github.com/onflow/flow-go/blob/master/docs/images/CruiseControl_BlockTimeController/EpochSimulation_029.png' width='900'>
 
-      <img src='https://github.com/onflow/flow-go/blob/master/docs/CruiseControl_BlockTimeController/EpochSimulation_030.png' width='900'>
+      <img src='https://github.com/onflow/flow-go/blob/master/docs/images/CruiseControl_BlockTimeController/EpochSimulation_030.png' width='900'>
 
     - controller very quickly compensates for moderate disturbances and observational noise in a well-behaved system:
 
-      <img src='https://github.com/onflow/flow-go/blob/master/docs/CruiseControl_BlockTimeController/EpochSimulation_028.png' width='900'>
+      <img src='https://github.com/onflow/flow-go/blob/master/docs/images/CruiseControl_BlockTimeController/EpochSimulation_028.png' width='900'>
 
     - controller compensates massive anomaly (100s network partition) effectively:
 
-      <img src='https://github.com/onflow/flow-go/blob/master/docs/CruiseControl_BlockTimeController/EpochSimulation_000.png' width='900'>
+      <img src='https://github.com/onflow/flow-go/blob/master/docs/images/CruiseControl_BlockTimeController/EpochSimulation_000.png' width='900'>
 
     - controller effectively stabilizes system with continued larger disturbances (20% of offline consensus participants) and notable observational noise:
 
-      <img src='https://github.com/onflow/flow-go/blob/master/docs/CruiseControl_BlockTimeController/EpochSimulation_005-0.png' width='900'>
+      <img src='https://github.com/onflow/flow-go/blob/master/docs/images/CruiseControl_BlockTimeController/EpochSimulation_005-0.png' width='900'>
 
   **References:**
 
@@ -120,7 +120,7 @@ Upon observing block `B` with view $v$, the controller updates its internal stat
 
 Note the '+1' term in the computation of the remaining views $k[v] := F[v] +1 - v$  . This is related to our convention that the epoch begins (happy path) when observing the first block of the epoch. Only by observing this block, the nodes transition to the first view of the epoch. Up to that point, the consensus replicas remain in the last view of the previous epoch, in the state of `having processed the last block of the old epoch and voted for it` (happy path). Replicas remain in this state until they see a confirmation of the view (either QC or TC for the last view of the previous epoch).
 
-<img src='https://github.com/onflow/flow-go/blob/master/docs/CruiseControl_BlockTimeController/ViewDurationConvention.png' width='600'>
+<img src='https://github.com/onflow/flow-go/blob/master/docs/images/CruiseControl_BlockTimeController/ViewDurationConvention.png' width='600'>
 
 In accordance with this convention, observing the proposal for the last view of an epoch, marks the start of the last view. By observing the proposal, nodes enter the last view, verify the block, vote for it, the primary aggregates the votes, constructs the child (for first view of new epoch). The last view of the epoch ends, when the child proposal is published.
 
@@ -151,7 +151,7 @@ and controller parameters (values derived from controller tuning):
 
 Each consensus participant observes the error $e[v]$ based on its local view evolution. As the following figure illustrates, the view duration is highly variable on small time scales.
 
-![](/docs/CruiseControl_BlockTimeController/ViewRate.png)
+![](/docs/images/CruiseControl_BlockTimeController/ViewRate.png)
 
 Therefore, we expect $e[v]$ to be very variable. Furthermore, note that a node uses its local view transition times as an estimator for the collective behaviour of the entire committee. Therefore, there is also observational noise obfuscating the underlying collective behaviour. Hence, we expect notable noise.