Züs - Whitepapers - Tokenomics

A protocol rewarding storage providers for staked capacity, free reads, and data stored Mo Siam, Saswata Basu, Thomas Austin December 2022 Abstract Today, most decentralized storage networks are archival in nature and designed around niche use cases. For decentralized storage (dStorage) to gain mainstream adoption, it needs to compete at an enterprise level akin to what a typical cloud storage provider offers today. In addition, it must integrate with and complement existing cloud infrastructure. To do so without a central authority, an incentive model enabling cost efficient reads and writes of data is needed for both the client and storage providers. A. Existing Network Architectures Almost all state-of-the-art layer-11 dStorage networks existing today utilize a form of Proof of Work, such as Filecoin's Proof of Space-Time (PoST-PoREP) and Proof of Replication (PoRep)2 and Arweave's Proof of Access (POA)3 . 1 https://www.gemini.com/cryptopedia/blockchain-layer-2-network-layer-1-network 2 https://filecoin.io/filecoin.pdf 3 https://www.arweave.org/yellow-paper.pdf 1 Such PoW systems combine the ability of a storage provider to mine a block with the amount of data a provider is storing. This indirectly couples the data value to the compute power spent and may have an adverse effect that amplifies node churn, and thereby data loss. PoW architectures tend to adopt replication of data (as indicated with “R” in the above diagram), with the exception of the Sia4 and Storj5 protocols, using different approaches albeit with a general underlying theme - one that combines the hashing power with the storage resources to avoid miner centralization. The use of replication is a suboptimal utilization of the storage space resource compared to other approaches such as erasure coding6 , which requires more computation at the client and has been a hindrance until lately as the mobile and desktop compute power have continually increased. Appendix A explores and discusses different dStorage networks, such as Filecoin and Arweave. As data demand pushes cloud storage7 into exabyte volume, there is a need to increase storage efficiency for sustainability. As the pace of data generation8 exceeds the ability to bring on new infrastructure online, dStorage networks will gain more prominence. Moreover, with the advent of user generated content such as NFT9 image and eventually videos, demand for dStorage networks to deliver quality will be significant to the creators and traders as the value of the NFT is in the data visualization and perception of such. Compared to 3-way replication, a (5,3) EC can tolerate the same number of node failures as with triplication while improving storage efficiency by 80% [4]. That said, while EC is better than replication in terms of storage efficiency, it needs reconstruction at the client, which introduces latency and may slow down the experience if the client does not have enough compute power. B. Züs Network Architecture The Züs network is designed to decouple the blockchain layer from the storage layer, enabling a scalable and performant system for enterprise applications. B.1 Blockchain Layer Consensus on the Züs network leverages a voting based proof of stake (PoS) algorithm, the details of which are beyond the scope of this paper10 . It suffices to know that consensus and block mining can only happen by miners elected into the Active Set11 which is shuffled periodically12 to include the top miners by their stake. The specifics of the Active Set is discussed in Appendix B. B.2 Storage Layer Storage providers are referred to as blobbers on the Züs network. Each blobber needs to register the following with the StorageSC whose state is maintained by the network: 1. Their read and write price asks in USD per GB and USD per GB per year, respectively. 4 https://sia.tech/sia.pdf 5 https://www.storj.io/storjv3.pdf 6 https://en.wikipedia.org/wiki/Erasure_code 7 “The unquenchable demand for video shows no signs of slowing down, and the move to cloud has forced substantial changes in network environments.” [CISCO WP] 8 “It has been reported that the storage space used for photo storage only in Facebook has been over 20PB in 2011 and is increasing by 60TB every week” [Jun Li] 9 NFTs are essentially certificates of ownership of the underlying data. The hosting of the underlying data needs to be on a decentralized network to ensure owner's sovereignty over the value of such certificate, which is the data itself. 10 The details of this algorithm can be found at https://drive.google.com/file/d/1KcfkQ1HmtGXvXzZtalNkVHMmIcwOiA7k/ view. 11 At the time of writing, the active set includes 111 miners and 30 sharders. 12 The shuffling of the active set is handled by the View Change protocol. During the first release, Fuji, View Change is not enabled and the active set is static. View Change is slated to be part of the Kilimanjaro release, expected 12 months after Fuji. 15 miners and 5 sharders have committed to accepting delegation during the Fuji release. 2 2. (Optional.) Their staked capacity. 3. Their available capacity. 4. A minimum stake equal to or greater than the product of the blobber's offered capacity and write price13 . B.3 Blobber Reward Mechanism For every block, a blobber is randomly assigned to a group, and a group is randomly selected to share the block reward with the Active Set. The blobbers' share is then distributed on a prorated basis between the blobbers in the selected group based on their weight w, which is based on their stake, price, data stored and data served. Given a similar stake, S, blobbers that store and serve data have a higher weight w. Blobbers who provide free egress will also have a higher weight. C. Client Storage The Züs storage protocol leverages erasure coding (EC). The client data is split into data and parity chunks and striped over servers, thereby slightly expanding the original data footprint, albeit much less than replication. Unlike other dStorage solutions, the client has full control over this expansion factor. A single chunk is then written to each of the client's chosen blobbers for a specific allocation, described in the next section. C.1 Allocations An allocation is essentially a group of N blobbers chosen by the client, comprised of k data blobbers and m parity blobbers. A client has full flexibility in choosing the numbers of blobbers per allocation as well as selecting the blobbers based on criteria he deems necessary, such as price, location or performance. Furthermore, a client can have multiple allocations of various EC (k, N ) ratios for different data sets. Allocations with the same k/N ratio have the same expansion factor and thus may have the same cost to the client; however, allocations with larger maximum distance separable codes (MDS) have higher data durability and availability e.g. EC (2,4) and EC (4, 8) may have similar expansion, performance, and likely cost (assuming blobber pricing is similar), but EC (8, 16) will have orders of magnitude better availability and durability. C.2 Reading from an Allocation When a client reads data from an allocation, the first k chunks of data received from a subset of the N blobbers are used to reconstruct the data. So, blobbers are incentivized to respond as fast as possible because the number of reads affects their block reward weight. C.3 Cost of Storage - Client Perspective The Züs Network provides a marketplace between storage consumers and blobbers. Clients can choose blobbers based on price, geolocation, performance, capacity, stake, and other metrics in the future Blobbers compete to acquire data because it increases the weight used to calculate their block rewards. Furthermore, blobber block rewards weighting is maximized as the blobber's ratio of read price to write price approaches zero to encourage free reads. This competition between storage providers is expected to result in lower and fair pricing of storage to the benefit of the client, irrespective of the client's size and status. 13 Minimum Blobber stake is 1000 tokens. 3 According to Züs's storage protocol [5], the client pays the blobbers a combined write price per GB, for the duration of the allocation, as data is written to the allocation. All allocations have a duration of one year. Such payment goes into the allocation's write pool and is released to the blobbers as they pass challenges over the duration of the allocation. If blobbers fail a challenge14 , the challenge proceeds less validators fees goes back to the client. A storage client needs to deposit into the write pool, for each allocation he owns, an amount of tokens corresponding to the size of the allocation15 . At the end of the allocation duration, if there are no writes then these tokens are disbursed back to the clients less a fixed cancellation penalty. If the allocation is cancelled before expiry, the client pays a cancellation charge (about 20%) of the deposit should the write pool have sufficient tokens remaining. Blobbers can change their price at any time. However, for existing allocations, the price remains the same as when the contract was created, and thus any price change for existing allocations can only be effected if the client accepts the change. A client can add or replace blobbers on the fly at any time if they want to add reliability and availability, or to change the price and performance of the allocation. To read data from an allocation, if the blended read price is non-zero, the client needs to deposit tokens into their read pool. C.4 Allocation Pools Each allocation has a write pool. A good feature is that any client can deposit into the write pool of an allocation in order to sustain stored data in the event that the owner of an allocation contains publicly available documents used by everyone and needs to be funded over time, regardless of the ownership. D. Storage Provider Revenue A blobber's annual revenue Vb is composed of four revenue streams: • proceeds from clients' writes (Vwrite ) • proceeds from clients' reads (Vread ) • annual block rewards (Vblock ) • proceeds from validating challenges (Vvalidation ) In this section, we outline how each of these revenue streams are paid out to blobbers. D.1 Rewards from Client Reads and Writes Blobbers storing data are challenged every t blocks generation. Once a blobber is selected for a challenge, a valid allocation is selected randomly from that blobber. Section D.4 details this process further. The values of Vwrite and Vread are derived from the corresponding prices of writes and reads (PW and PR , respectively), and from the amount of writes and reads for a year, given by DW and DR . These values give us the following formula for Vb : Vb = Vwrite + Vread + Vblock + Vvalidation ≡ Pw DW + Pr DR + Vblock + Vvalidation (1) 14 Blobbers stake is also slashed for failing challenges. For each challenge failed, blobbers stake is slashed by an amount equivalent to a small percentage of the challenge reward. All tokens from slashed stakes are burnt. 15 Each allocation effectively locks an amount of tokens equivalent to twice its size-price token value, equally coming from the client and the blobbers. 4 The share a blobber gets from network block rewards is designed to increase for a blobber as the blobber's read to write price ratio Pr /Pw decreases and is maximized for free reads to encourage such offering from the blobbers. The protocol allows for different pricing at the blobber level and creates a free marketplace allowing for the Züs platform to attract different storage providers without imposing a restrictive economic model. Moreover, blobbers automatically participate as validators of challenges to prove that a blobber is storing the data, and they receive a small percentage (around 2.5%) from the write proceeds. D.2 Blobbers Block Rewards Now that we have shown how clients pay blobbers through reads and writes, we discuss how the network pays blobbers through the block reward (Vblock ). The Vblock reward is on an annual basis, the reward on a per-block basis, R. A random group of blobbers of size n is selected every block from the overall blobber population on the network, N . This group shares the block reward R with the active set. The variables a and b represent the portions of the reward allocated to the active set (RAS ) and the blobbers (Rb ), respectively. The blobbers' share of the block reward Rb is then distributed among the blobbers based on their reward weight, w: R = aR + bR ≡ RAS + Rb where a + b = 1 (2) Given its weight w, each blobber in the selected lottery group G gets a reward ri where: n ri = Rb ( X wi ) where WG = wj WG j=1 (3) The weighting of blobbers is discussed in depth in Section E. D.3 Expected Rewards This section explains how the expected rewards for a blobber can be calculated. This discussion is mathematically dense, and could perhaps be skimmed over on an initial reading of the paper. The expected rewards is based on how the weight is distributed across the blobbers since the blobber selection in a partition and partition selection for a reward are both random events. The average weight of the lottery group is simply: n w= 1X wi n i=1 (4) While we know the size of each lottery group in advance to be n, we only can estimate the average blobber weight of each lottery group, with 95% confidence, to be within r r 4σ 2 4σ 2 W− ≤w≤W + (5) n n Where W is the average blobber weight of the whole blobber population and σ 2 is the variance of such population, both of which are parameters of the network and known at any given time. W = N N 1 X 1 X wi where σ 2 = (wi − W )2 N 1 N 1 (6) That said, absent network information, we know that the distribution of the lottery groups' means follows a normal distribution around the population mean. Assuming that the probability of getting a sample mean 5 within half a standard deviation16 from the population mean is practically identical17 . We can approximate for the expected value of the rewards (E(rb )), given that the blobber makes it into lottery group G: ρRb E(ri ) = w (7) n G Where ρ is a network variance factor defined as:  W+ ρ ≡ log  W− q q σ2 4n σ2   √ n σ (8) 4n The probability that any arbitrary blobber is selected into the lottery group is simply n/N , and thus relaxing the previous assumption; it follows that the expected reward per block for an arbitrary blobber, E(ri ), given multiple lotteries, is ρRb w E(ri ) = N w Rb w Rb Vblock = ρW ≡ω ≡ B W N W N (9) Where ω is the network's variance weight at any given point in time and defined as ω ≡ ρW and B is the number of blocks in a year. D.4 Storage Provider Challenges Every t blocks18 , five (5) blobbers are chosen at random. The one with the highest stake, s, out of these five is chosen for a challenge. A random file is then chosen and a random file segment is selected thereafter for the blobber to provide a Merkle path and the challenged data segment. D.4.1 Passing Challenges If the blobber passes the challenge, his stake is adjusted by the number of challenges passed. This adjustment is reset every m blocks, the stats window. Furthermore, the blobber receives the write proceeds associated with this challenge, less validator fees, from the allocation's write pool, where the size of the write proceed depends on the size of the allocation write pool and the time left on the allocation. Likewise, if the blobber fails the challenge then no stake adjustment occurs and the validators still get their challenge associated fees from the allocation write pool. Stake adjustment by challenges passed is a measure against non-performing high stake blobbers, and under the presumption of a non-Byzantine network, can be replaced with nominal stake for the purpose of further analysis. Going forward, when mentioning stake, we implicitly assume ‘challenge adjusted stake' unless otherwise explicitly mentioned or logically apparent. D.4.2 Failing Challenges (Schadenfreude Burn) If a blobber fails a challenge, the challenge reward less validator fees goes back to the client. Moreover, the blobber's stake is slashed by an amount proportional to the challenge reward19 . Slashed tokens are burnt. 16 38.2% of the lottery groups are within half a standard deviation of the mean. h population i ′ ′ √ a uniform distribution around the mean over the interval W − σ2 , W + σ2 where σ ′ = σ/ n. 18 Currently t = 30. 19 The slash proportionality factor is 20% - i.e the equivalent of 20% of the challenge reward gets slashed from a blobber's stake on failing a challenge. The size of the challenge reward is equal to the product of the blobber's write price, the size of the original file being challenged, and the duration of the allocation. 17 Assuming 6 Thus a blobber failing a challenge is considered to be a schadenfreude event as it is a deflationary token dynamic. E. Calculating Provider Weights The Züs network seeks to keep reads inexpensive. Blobbers maximize their profits when the read price is set to 0. The provider weight depends on three attributes: • The blobber's read to write price ratio in tokens, p. • The blobber's ratio, z, of data egress (in GB) from the blobber within a period of m blocks to the total aggregate data stored with the blobber (in GB). • The challenge-adjusted blobber's stake, S, based on the product of tokens staked (nominal stake, s) and the number of challenges passed within a period of m blocks. We join the first two factors together in a read/write price and data flow ratio, β, which we describe later in this section. The weight w of a blobber is then a direct function of their total adjusted stake, inclusive of any delegation, as well as β: w = βS where β = Γζ + 1 (10) The ζ and Γ functions are known as the free egress function and the fair usage function, respectively. We detail these functions and then show how β is derived. E.1 Free Egress Function - ζ In keeping with the industry trend, the network incentivizes blobbers to offer lower read prices, preferably zero. The fair egress function details how the network incentivizes this behavior. The free egress function is derived from the write price ratio, p. Pr p where p ≡ ζ = I −K (11) p+ϕ Pw In the above formula, I and K are scaling constants, and ϕ is a tuning parameter. ϕ is defined as the price sensitivity parameter chosen such that ζ = 0.25 at p = 1. ζ attains max value I when p = 0 and approaches min value of 0 for small write prices Pw or large read price Pr , i.e as p → ∞. Figure 1 shows the curve of the free egress function. The scaling constants and tuning parameter for this graph, I = 2, K = 0.9, ϕ = 0.2, were chosen to encourage a low read price. As the graph shows, when the read price is zero, the free egress function is maximized. E.2 Fair Usage Function - Γ Centralized cloud storage providers offering free reads impose a hard egress limit per month, or impose a subjective abuse limit based on the ratio of egress to the amount of data a client has stored with them within some period. This approach is used by services such as Wasabi. While fair, such approaches may be subject to abuse, and traditionally use a central authority to enforce. The Züs protocol takes a similar approach as Wasabi, albeit one that is algorithmic and driven by incentives. For a blobber offering free egress, the more data the blobber has stored, the more data he will serve in a quest to optimize Γ and thereby maximize his weight w. The fair usage function is defined from z: E α−z where z ≡ (12) Γ= A−B α+z X 7 Figure 1: Free Egress Function Curve In the above formula, A and B are scaling constants and α is the bandwidth inflection parameter. X is the amount of data stored by the blobber, and E is the amount of data egress. Figure 2 shows the curve of the fair usage function. The scaling constants and bandwidth inflection parameter are set to A = 10, B = 9, α = 0.2, chosen based on how sharp the curve is desired and the desired data flow of reads and stored data. As the graph shows, Γ is maximized when a blobber has served an amount of data equal to 20% of the total amount of data he is storing with a period of m blocks (approximately 3 weeks). Γ has the characteristic shape of a semi-symmetric function around the bandwidth inflection point α. The rate of change in Γ is different for z ≤ α and for z ≥ α; Γ increases faster than it decreases. E.3 Read/Write Price and Data Flow Ratio Now that we have the fair egress and fair usage functions derived, we can discuss how p and z are joined together. The β function is defined below: β = Γζ + 1 = α−z A−B α+z I −K where p ≡ p p+ϕ +1 E Pr and z ≡ Pw X (13) Note that the “+1” ensures a minimum weight for β, even when there is no data stored. β = Γζ + 1 where Pw > 0 and X > 0 β = 1 where Pw = 0 or X = 0 (14) β attains max value A at z = α, and min value A − B when the blobber holds a large amount of data that is relatively stale (z = 0). The variables z and p have a soft logical coupling; for high write prices, the chance of a blobber being selected to store data decreases: X → 0 as Pw → ∞ =⇒ β → 1 8 Figure 2: Fair Usage Function Curve The constants chosen below are designed to achieve a sharper maximization of rewards for specific target goals of free reads and normal data flow patterns. Γ constants A B α E.4 Value 10 9 0.2 ζ constants I K ϕ Value 1 0.9 0.2 Storage Provider Weight, w As shown earlier, the blobber's weight is derived from β and the amount of tokens staked. Given average stake (Savg ) and total network stake (Stot ), it follows that the average blobber weight, as defined previously, can be written in terms of an average read/write price and data flow ratio β: W = N N 1 X Stot 1 X wi ≡ βSavg where Savg = ≡ Si N 1 N N 1 (15) And thus we can rewrite the expected blobber block reward, or simply income I, in terms of stake as follows: S Rb β where ω ≈ 1 (16) I = E(ri ) = ω Savg N β | {z} |{' '} {z}η θ We define the blobber competitiveness (optimal fair usage/free egress) of a blobber as θ and the adjusted stake competitiveness as η. The blobber competitiveness can be thought of as a measure analogous to the average hashing power per miner in a PoW network, except here work is aligned with pricing and bandwidth, instead of energy. 9 Figure 3: We model for the APR of an average blobber operating with a unit blobber competitiveness, i.e. θ = 1, as a function of total blobbers on the network, N , for different average population stakes, Savg . F. Storage Provider APR The annual income of a blobber is the product of his expected yield per block, y, and the number of blocks in a year, B. Moreover, the annual percentage return (APR) for a blobber is the ratio of the blobber's annual yield to his stake: AP R ≡ yB ωRb B ∼ Rb B 11 1 ≡ θ= θ where ≤ θ ≤ S N Savg Stot β β (17) Provided the above, we model for the APR in the first year of the network with basis B ∼ = 30M il blocks in a year and a lottery group block reward Rb = 0.25. The results are shown in Figure 3 and Figure 4. Figure 3 shows that the APR decreases as average stake increases and as the number of blobbers on the network increase. This is intuitive since the blobber reward is fixed and individual reward will go down with more blobbers, if they have average stake and beta. Figure 4 shows that the individual blobber APR increases based on their competitiveness in terms of their read price and data flow ratio relative to other blobbers and decreases as the total stake for the network increases. G. Staking and Delegation All service providers (miners, sharders, blobbers, authorizers, validators) on the Züs network can have delegators that can stake on the infrastructure, based on the requirement set up by the service provider in terms of minimum stake and number of delegators. The reward a service provider receives less any commission fees is shared among the delegators on a pro rata basis based on their stake. 10 Figure 4: We model for the APR of an average blobber for different blobber competitiveness theta as a function of total staked by all blobbers (Stot ), given β = 5. Let the total stake of a blobber be S ≡ Sb + SD where Sb is the stake provided by the service provider and where SD is the sum of stakes provided by all other delegators. Let C be the commission (as a portion of the total profits) charged by the service provider on any reward received. The service provider's reward due to their commission (Ic ) is given by the following formula: Ic = I ∗ C (18) Additionally, the provider also earns rewards (Id ) based on the amount of tokens that they have “delegated” to themselves: I Sb ) = ( )Sb (1 − C) S S Thus, the service provider's total rewards (Ib ) are: I (1 − C)Sb Ib = Ic + Id = IC + ( )Sb (1 − C) = I C + S S Id = I(1 − C)( (19) (20) The income equation shows how there are different types of individuals who can participate on our network. A datacenter or a managed storage provider can easily provide their spare server on the network without the need to stake or risk and be able to derive income from the commission. If the cost of space, bandwidth, and server is sunk or already paid for as part of other services, then it is all net profit. Alternatively, entrepreneurs with no IT experience and looking for a safer investment may simply stake their idle tokens as a delegate and share in the income from the blobber. G.1 Stake Lock Up Period On the Züs network each blobber has its own stake pool. All tokens delegated to a blobber, except those locked up by allocations (until expiry, renewal, or update), are available for unstaking from such pool at any point in time without any lock up period. 11 This pool dynamics allows for at least two logical classes of blobbers; those who are over delegated and those who are under delegated in respect to their staked capacity. The degree of over delegation or under delegation is subjective and relative to the perspective of the delegator. For example, a delegator who wants assured liquidity all the time may only delegate to blobbers who have a total pool size larger than some multiple above the amount of tokens necessary for the offered capacity; such that in the event such a blobber reaches a high degree of utilization there remains ample liquidity for the delegator to unstake his tokens. Alternatively, a delegator who is seeking higher returns may prefer to delegate to a relatively under delegated blobber despite a higher possibility of being partially or fully locked-in should the blobber's utilization (allocation commitment) increase dramatically within a short period of time and absent further delegation to that blobber during this period. H. Cost of Mining A blobber on the Züs network has a cost for each token earned; and thus collectively there is a perceived cost by the blobbers for each token minted and rewarded to them. The following analysis is normalized on an exogenous fiat basis and one year period. This cost is comprised of the average fiat cost of each TB on offer, Ĉ, and is a function of both ingress and egress costs, as well as the average capital cost δc (%) for each token staked by the blobbers, less any revenue generated from client reads or writes, where p̂w is the fiat write price per terra-byte per year (e.g. $5 per TB for a year of storage) and p̂r is the fiat read price per TB. The cost of total capacity offered in terra-bytes, Ω (TB), has an exogenous fiat cost on the blobbers, and so is the cost of buying tokens and staking them, as well as the cost of capital associated with such action. Given a storage utilization X ≤ Ω and a corresponding write and read utilization percentages, δX and δr respectively; the blobbers' fiat revenue from write and read activity at a storage utility X (TB) and read utility Xδr (TB) is defined as: K = X p̂w + δr X p̂r ≡ Ωδx (p̂w + δr p̂r ) (21) And similarly, the blobbers' nominal fiat investment (expense) into the network, both operational and capital cost respectively, is defined as: E = ĈΩ + δc Ωp̂w + δc (p̄Stot − Ωp̂w ) = ĈΩ + δc p̂Stot (22) Where p̄ is the average cost of purchase per staked token20 and Stot is the total staked tokens at equilibrium, where Stot is upper bounded by the token available supply less that staked by miners and sharders and those acquired for reading and writing data from and to blobbers respectively. The product p̂Stot is the total cost of tokens staked by blobbers on the network, i.e. the realized capitalization of the blobber's network. Accordingly, the following inequality follows for the perceived mining value of blobbers' block rewards, R̂ (in fiat), at a given network state: 20 The average cost of purchase can be estimated from the network's realized capitalization. Whilst originally Realized Capitalization was pioneered for UTXO chains, adaptations have been made for account based chains, where realized capitalization can be estimated via virtual UTXOs accounting. Virtual UTXO accounting are based on two rules (1) each incoming payment creates a new coin attached to the account, the coin is valued at the price of the movement; and (2) each outgoing payment triggers a coin selection on the coins attached to the account, the change is valued at the current market price. Research on the topic can be found at https://coinmetrics.io/realized-capitalization/ and https://academy.glassnode.com/market/realized-capitalization. 12 R̂ + (X p̂w + δr X p̂r ) ≥ ĈΩ + δc p̄Stot ≡ R̂ + K ≥ E (23) The perceived value of the blobbers' block rewards should at a minimum be equal to the capital and operational costs of the network less any transactional revenue from read and write activity. The soft bifocal economy between blobbers favoring block rewards vis a vis those favoring transactional revenue enables a heterogeneous network of storage providers, between these two focal economic points, that can adapt to market conditions, thereby reducing node churn and ensuring continuity of storage21 during challenging market periods22 . I. Stake-Storage Demand Dynamics Clients up-taking storage on the network need to lock in to the write-pool an amount equivalent to the write-size of the allocation they are up-taking. Whilst this amount is not staked, and does not earn any rewards, it removes supply from the network and thus the more tokens that are allocated, the fewer tokens are available for blobbers to stake. See Section C. J. Summary The Züs network blobbers' economic protocol leverages a pseudo-random stake based challenge dynamic to elect blobbers for a reward lottery should they pass the challenge and prove that they store the client's data. Every block, a set of blobbers are chosen at random and the one with the highest stake within this set is chosen for a challenge. Once they pass the challenges, the blobber is added to the reward lottery pool. Simultaneously, every block a group of blobbers is chosen from the reward lottery pool and the reward is distributed between them on a weight basis. The weight of each blobber is proportional to their stake, and the number of challenges they have passed during a previous reference period. The proportionality factor is referred to as the goodness factor and is skewed in favor of blobbers offering free-egress and fair egress to stored capacity ratio. Such lottery mechanism creates a stake-supply dynamics that bootstraps storage supply ahead of storage demand by incentivizing blobbers to have delegation pools with stake above that is required by the staked capacity. The size of a blobber's delegation pool provides prospective storage clients with a metric on the blobber's level of commitment and availability; and thus encourages usage of capacity by clients, which in turn provides for a positive feedback loop between storage supply23 and demand on the network. References [1] Arweave fees calculator. URL: https://arweavefees.com. [2] Filecoin FAQ. “If you are retrieving your data from IPFS or a remote pinning layer such as an FPS, retrieval should take on the order of milliseconds to seconds in the worst case. Our latest tests for retrieval from the Filecoin network directly show that a sealed sector holding data takes 1 hour to unseal. 1-5 21 This is akin to adjusting difficulty of mining reward tokens. As blobbers migrate to transactional revenue, the share of rewards for blobbers operating in favor of block rewards increases until dynamic equilibrium is established. 22 Allocated storage is not affected by a blobber's interim shift in strategy unless the client(s) of such allocated storage accept such changes by the blobbers. 23 Decentralized storage networks have shown their ability to scale in 2021-2022. Filecoin's committed storage capacity has steadily over the period 2021-2022, reaching 16 ExB in March 2022, albeit with a storage utilization of 0.3% - Sia and Storj have storage utilization of 36% (2.2 PB) and 60% (8.6 PB) respectively as of March 2022 - Messari Report. 13 hours is our best real-world estimate to go from sector unsealing to delivery of the data. If you need faster data retrieval for your application, we recommend building on Powergate or an FPS”. URL: https://docs.filecoin.io/about/basics/filecoin-faq/. [3] Ben Fisch, Joseph Bonneau, Nicola Greco, and Juan Benet. Scaling proof-of-replication for filecoin mining. Protocol Labs: San Francisco, CA, USA, 2018. [4] Jun Li and Baochun Li. Erasure coding for cloud storage systems: A survey. Tsinghua Science and Technology, 18(3):259–272, 2013. [5] Paul Merrill, Thomas H. Austin, Jenil Thakker, Younghee Park, and Justin Rietz. Lock and load: A model for free blockchain transactions through token locking. In IEEE International Conference on Decentralized Applications and Infrastructures, DAPPCON 2019, Newark, CA, USA, April 4-9, 2019, pages 19–28. IEEE, 2019. [6] Sam Williams, Viktor Diordiiev, Lev Berman, India Raybould, and Ivan Uemlianin. Arweave: A protocol for economically sustainable information permanence. Technical report, Arweave, 2019. URL: https: //www.arweave.org/yellow-paper.pdf. Appendix A. A.1 Alternate dStorage Networks PoST-PoREP (Filecoin) Architecture In PoST-PoREP (proof of space time and proof of replication) systems, the storage fees paid by the client to the storage provider to store data need to be equal or greater than the storage provider's rental cost of colocation, server, and disk space; otherwise the storage provider will try to hack rewards by storing self generated data [3]. In PoST-PoREP systems, each replica stored with the same storage provider or a different storage provider is a cryptographically provable unique entity (PoREP). The client pays the storage provider for each deal, and the storage provider is paid a block reward for proving to the network that it has been storing the replica at various time checks (PoST). Retrievability of data is an off-chain process, where the price to read data is set by the storage providers. The ability of a client to retrieve his data from a specific provider is dependent on the price set by that storage provider. Thus, data accessibility increases with the number of replicas a client stores. In PoREP (proof of replication) systems, the time it takes to unseal a sector containing the data and deliver it to the client is on the order of 3-5 hours. Such a system is thus suitable for cold storage only. To address hot data acquisition, Filecoin encourages storage providers to pin client data on IPFS; thus, it relegates the retrievability market to a measure of last resort [2]. A.2 PoA (Arweave) architecture In Proof of Access systems, a miner must have access to a subset of the previous blocks in order to mine the next block. Arweave imposes this requirement to ensure that the data permeates the network after the client has uploaded it to a storage provider. It does so by writing / weaving the data into the block. For such a block to be accepted into the blockchain, the successful miner needs to have a pseudo-randomly chosen block's data and to solve a computational puzzle. This recall block dynamic incentivizes miners to store blocks and the associated data locally. Essentially, it incentivizes miners to replicate data, and thus it implicitly requires nodes to share (seed) blocks and the associated data to other nodes free of charge. This architecture requires free egress by design regardless of the use case. To incentivize this behavior, Arweave borrows from BitTorrent; the more a node shares, the higher its rank and the more other nodes share with it, and consequently, the better its chance is at mining a block. 14 As the amount of data on the network increases, the miner will be less likely to have the recall block, increasing the difficulty to mine a block. Consequently, given a non-trivial node churn relative to the permeability of a specific data set on the network, any permanency of such data is a perceived one and thus data availability is probabilistic. Any remedial actions are beyond the client's control, unless the client is a miner retaining that data and seeding it [6]. A client pays for storage of data in perpetuity and implicitly for its replication. The cost to store 1TB of data on the Arweave network is approximately 8,000 USD as seen at the time of writing [1], equivalent to about 30 years worth of storage on AWS and about 180 years worth of storage on Filecoin paid upfront. A small portion of what the client pays in transaction fees goes to the block miner, and the remaining amount goes to an endowment pool. The endowment pools serves to supplement the block rewards in the event that the total network's expenditure towards hashing power and storage exceeds the total block rewards value during a given period of time. While this seems a stop gap mechanism to counter node churn, the expenditure of the miners is external to the network, and thus can only be inferred by the network via some statistics such as node churn. Appendix B. Details on Rewards The active set has 141 nodes — 111 miners and 30 sharders — and is shuffled every view change epoch (approximately 1 week). The minimum stake to join the active set is 50,000 tokens. Only the top 111 miners and 30 sharders by stake squared make it into the active set. Using stake squared incentivizes nodes to concentrate their funds in a single account to maximize their chances of being selected, and therefore helps to reduce the threat of Sybils. Each block, one (1) miner and thirty (30) sharders share the reward (RAS ≡ aR); the rest (Rb ≡ bR) 111 RAS , i.e. roughly 80% of the active set block reward. goes to the blobbers. The share of the miner is 141 30 The share of all the 30 sharders is 141 RAS , i.e about 20% of the active set block reward. For the first 30 million blocks (or about a year) the active set receives 8.5 million tokens, and the blobbers receive 7.5 million tokens. The block reward, is reduced by 10% every 30 million blocks thereafter. 15