Move images from img/ to .gitbook/assets

book/makefile

@@ -2,7 +2,7 @@ BOB_SRCS=$(wildcard art/*.bob)
 MSC_SRCS=$(wildcard art/*.msc)
 MD_SRCS=$(wildcard src/*.md)
 
-SVG_IMGS=$(BOB_SRCS:art/%.bob=src/img/%.svg) $(MSC_SRCS:art/%.msc=src/img/%.svg)
+SVG_IMGS=$(BOB_SRCS:art/%.bob=src/.gitbook/assets/%.svg) $(MSC_SRCS:art/%.msc=src/.gitbook/assets/%.svg)
 
 TARGET=html/index.html
 TEST_STAMP=src/tests.ok
@@ -19,11 +19,11 @@ open: $(TEST_STAMP)
 watch: $(SVG_IMGS)
 	mdbook watch
 
-src/img/%.svg: art/%.bob
+src/.gitbook/assets/%.svg: art/%.bob
 	@mkdir -p $(@D)
 	svgbob < $< > $@
 
- src/img/%.svg: art/%.msc
+src/.gitbook/assets/%.svg: art/%.msc
 	@mkdir -p $(@D)
 	mscgen -T svg -i $< -o $@
 

book/src/ed_economic_sustainability.md

@@ -7,7 +7,7 @@ The dominant remittances from the Solana mining pool are validator and replicato
 The Replicator rewards are to be delivered to replicators as a portion of the network inflation after successful PoRep validation. The per-PoRep reward amount is determined as a function of the total network storage redundancy at the time of the PoRep validation and the network goal redundancy. This function is likely to take the form of a discount from a base reward to be delivered when the network has achieved and maintained its goal redundancy. An example of such a reward function is shown in **Figure 3**
 
 <!-- ![image alt text](porep_reward.png) -->
-<p style="text-align:center;"><img src="img/porep_reward.png" alt="==PoRep Reward Curve ==" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/porep_reward.png" alt="==PoRep Reward Curve ==" width="800"/></p>
 
 **Figure 3**: Example PoRep reward design as a function of global network storage redundancy.
 

book/src/ed_overview.md

@@ -11,6 +11,6 @@ Transaction fees are market-based participant-to-participant transfers, attached
 A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics.md), [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. Additionally, in [Storage Rent Economics](ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. The [Replication-client Economics](ed_replication_client_economics.md) chapter will review the Solana network design for global ledger storage/redundancy and replicator-client economics ([Storage-replication rewards](ed_rce_storage_replication_rewards.md)) along with a replicator-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md). <!-- The [Economic Sustainability](ed_economic_sustainability.md) section dives deeper into Solana’s design for long-term economic sustainability and outlines the constraints and conditions for a self-sustaining economy.--> An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. Finally, in chapter [Attack Vectors](ed_attack_vectors.md), various attack vectors will be described and potential vulnerabilities explored and parameterized.
 
 <!-- ![img alt text](solana_economic_design.png) -->
-<p style="text-align:center;"><img src="img/economic_design_infl_230719.png" alt="== Solana Economic Design Diagram ==" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/economic_design_infl_230719.png" alt="== Solana Economic Design Diagram ==" width="800"/></p>
 
 **Figure 1**: Schematic overview of Solana economic incentive design.

book/src/ed_vce_state_validation_protocol_based_rewards.md

@@ -21,10 +21,10 @@ The first factor is a function of protocol parameters only (i.e. independent of
 
 At any given point in time, a specific validator's interest rate can be determined based on the porportion of circulating supply that is staked by the network and the validator's uptime/activity in the previous epoch. For example, consider a hypothetical instance of the network with an initial circulating token supply of 250MM tokens with an additional 250MM vesting over 3 years. Additionally an inflation rate is specified at network launch of 7.5%, and a disinflationary schedule of 20% decrease in inflation rate per year (the actual rates to be implemented are to be worked out during the testnet experimentation phase of mainnet launch). With these broad assumptions, the 10-year inflation rate (adjusted daily for this example) is shown in **Figure 2**, while the total circulating token supply is illustrated in **Figure 3**. Neglected in this toy-model is the inflation supression due to the portion of each transaction fee that is to be destroyed.
 
-<p style="text-align:center;"><img src="img/p_ex_schedule.png" alt="drawing" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/p_ex_schedule.png" alt="drawing" width="800"/></p>
 **Figure 2:** In this example schedule, the annual inflation rate [%] reduces at around 20% per year, until it reaches the long-term, fixed, 1.5% rate.
 
-<p style="text-align:center;"><img src="img/p_ex_supply.png" alt="drawing" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/p_ex_supply.png" alt="drawing" width="800"/></p>
 **Figure 3:** The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in **Figure 2**
 
 Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabalize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for state-validation and ledger storage replication (PoReps) are not accounted for here. 
@@ -33,7 +33,7 @@ Given these example parameters, annualized validator-specific interest rates can
 
 <!-- ![== Validation Client Interest Rates Figure ==](validation_client_interest_rates.png =250x) -->
 
-<p style="text-align:center;"><img src="img/p_ex_interest.png" alt="drawing" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/p_ex_interest.png" alt="drawing" width="800"/></p>
 
 **Figure 4:** Shown here are example validator interest rates over time, neglecting transaction fees, segmented by fraction of total circulating supply bonded as stake.
 

book/src/fork-generation.md

@@ -67,7 +67,7 @@ PoH stream with possible forks over time.  L1, L2, etc. are leader slots, and
 represent ticks only, and time flows downwards in the diagram.
 
 
-<img alt="Fork generation" src="img/fork-generation.svg" class="center"/>
+<img alt="Fork generation" src=".gitbook/assets/fork-generation.svg" class="center"/>
 
 Note that an `E` appearing on 2 forks at the same slot is a slashable
 condition, so a validator observing `E3` and `E3'` can slash L3 and safely

book/src/managing-forks.md

@@ -30,7 +30,7 @@ An active fork is as a sequence of checkpoints that has a length at least one
 longer than the rollback depth. The shortest fork will have a length exactly
 one longer than the rollback depth.  For example:
 
-<img alt="Forks" src="img/forks.svg" class="center"/>
+<img alt="Forks" src=".gitbook/assets/forks.svg" class="center"/>
 
 The following sequences are *active forks*:
 
@@ -50,14 +50,14 @@ can into the root.
 Starting from the example above, wth a rollback depth of 2, consider a vote on
 5 versus a vote on 6. First, a vote on 5:
 
-<img alt="Forks after pruning" src="img/forks-pruned.svg" class="center"/>
+<img alt="Forks after pruning" src=".gitbook/assets/forks-pruned.svg" class="center"/>
 
 The new root is 2, and any active forks that are not descendants from 2 are
 pruned.
 
 Alternatively, a vote on 6:
 
-<img alt="Forks" src="img/forks-pruned2.svg" class="center"/>
+<img alt="Forks" src=".gitbook/assets/forks-pruned2.svg" class="center"/>
 
 The tree remains with a root of 1, since the active fork starting at 6 is only
 2 checkpoints from the root.

book/src/programs.md

@@ -10,7 +10,7 @@ transaction are discarded.
 
 ## Deploying Programs to a Cluster
 
-<img alt="SDK tools" src="img/sdk-tools.svg" class="center"/>
+<img alt="SDK tools" src=".gitbook/assets/sdk-tools.svg" class="center"/>
 
 As shown in the diagram above a client creates a program and compiles it to an
 ELF shared object containing BPF bytecode and sends it to the Solana cluster.

book/src/runtime.md

@@ -34,7 +34,7 @@ memory is committed.
 The TVU runtime ensures that PoH verification occurs before the runtime
 processes any transactions.
 
-<img alt="Runtime pipeline" src="img/runtime.svg" class="center"/>
+<img alt="Runtime pipeline" src=".gitbook/assets/runtime.svg" class="center"/>
 
 At the *execute* stage, the loaded accounts have no data dependencies, so all the
 programs can be executed in parallel.

book/src/simple-payment-and-state-verification.md

@@ -68,7 +68,7 @@ transaction to the required set of validator votes.
 An Entry-Merkle is a Merkle Root including all transactions in the entry, sorted
 by signature.
 
-<img alt="Block Merkle Diagram" src="img/spv-block-merkle.svg" class="center"/>
+<img alt="Block Merkle Diagram" src=".gitbook/assets/spv-block-merkle.svg" class="center"/>
 
 A Block-Merkle is a Merkle root of all the Entry-Merkles sequenced in the block.
 Transaction status is necessary for the receipt because the state receipt is
@@ -95,7 +95,7 @@ state receipt would point to the same value for A or B.
 The Bank-Merkle is computed from the Merkle Tree of the new state changes, along
 with the Previous Bank-Merkle, and the Block-Merkle.
 
-<img alt="Bank Merkle Diagram" src="img/spv-bank-merkle.svg" class="center"/>
+<img alt="Bank Merkle Diagram" src=".gitbook/assets/spv-bank-merkle.svg" class="center"/>
 
 A state receipt contains only the state changes occurring in the block. A direct
 Merkle Path to the current Bank-Merkle guarantees the state value at that bank

book/src/stake-delegation-and-rewards.md

@@ -199,7 +199,7 @@ stake.
 
 ## Example Callflow
 
-<img alt="Passive Staking Callflow" src="img/passive-staking-callflow.svg" class="center"/>
+<img alt="Passive Staking Callflow" src=".gitbook/assets/passive-staking-callflow.svg" class="center"/>
 
 ## Staking Rewards
 

book/src/tpu.md

@@ -1,3 +1,3 @@
 # The Transaction Processing Unit
 
-<img alt="TPU Block Diagram" src="img/tpu.svg" class="center"/>
+<img alt="TPU Block Diagram" src=".gitbook/assets/tpu.svg" class="center"/>

book/src/turbine-block-propagation.md

@@ -56,15 +56,15 @@ The following diagram shows how the Leader sends shreds with a Fanout of 2 to
 Neighborhood 0 in Layer 0 and how the nodes in Neighborhood 0 share their data
 with each other.
 
-<img alt="Leader sends shreds to Neighborhood 0 in Layer 0" src="img/data-plane-seeding.svg" class="center"/>
+<img alt="Leader sends shreds to Neighborhood 0 in Layer 0" src=".gitbook/assets/data-plane-seeding.svg" class="center"/>
 
 The following diagram shows how Neighborhood 0 fans out to Neighborhoods 1 and 2.
 
-<img alt="Neighborhood 0 Fanout to Neighborhood 1 and 2" src="img/data-plane-fanout.svg" class="center"/>
+<img alt="Neighborhood 0 Fanout to Neighborhood 1 and 2" src=".gitbook/assets/data-plane-fanout.svg" class="center"/>
 
 Finally, the following diagram shows a two layer cluster with a Fanout of 2.
 
-<img alt="Two layer cluster with a Fanout of 2" src="img/data-plane.svg" class="center"/>
+<img alt="Two layer cluster with a Fanout of 2" src=".gitbook/assets/data-plane.svg" class="center"/>
 
 #### Configuration Values
 
@@ -87,4 +87,4 @@ in a neighborhood in the upper layer, we'd need a big network failure in the upp
 layers to end up with incomplete data.
 
 <img alt="Inner workings of a neighborhood"
-src="img/data-plane-neighborhood.svg" class="center"/>
+src=".gitbook/assets/data-plane-neighborhood.svg" class="center"/>

book/src/tvu.md

@@ -1,3 +1,3 @@
 # The Transaction Validation Unit
 
-<img alt="TVU Block Diagram" src="img/tvu.svg" class="center"/>
+<img alt="TVU Block Diagram" src=".gitbook/assets/tvu.svg" class="center"/>

book/src/validator-proposal.md

@@ -36,7 +36,7 @@ We unwrap the many abstraction layers and build a single pipeline that can
 toggle leader mode on whenever the validator's ID shows up in the leader
 schedule.
 
-<img alt="Validator block diagram" src="img/validator-proposal.svg" class="center"/>
+<img alt="Validator block diagram" src=".gitbook/assets/validator-proposal.svg" class="center"/>
 
 ## Notable changes
 

book/src/validator.md

@@ -1,6 +1,6 @@
 # Anatomy of a Validator
 
-<img alt="Validator block diagrams" src="img/validator.svg" class="center"/>
+<img alt="Validator block diagrams" src=".gitbook/assets/validator.svg" class="center"/>
 
 ## Pipelining