Market Cap and Resource Pricing

The key purpose of fees is to deter possible abuse of the liveness of the system by hostile actors, there is also a secondary purpose of rationing access among the most highest value uses, but this can be done with a tip market which needs no lower bound pricing.

Such an attack would essentially boil down to exhausting the throughput of the system for some period of time. It is not feasible to really fully anticipate the external payoff that an attacker could derive from such an attack, hence one just has to make baseline assumptions which seem plausible based on the context at hand. For our chain I believe it is safe to assume that we only need to deter "vandalism", where primary payoff is just hedonic or reputational. To make things concrete, let us just assume that this type of attacker has willingness to pay of $10,000 USD/day to entirely block the transactional activity in the system.

Other things to consider:

Short selling

I think the assumption that primary payoff for an attacker is hedonic or reputational is extremely optimistic.
As soon as there is any reasonibly-sized market for JOY, an attacker would be able to short-sell JOY on leverage for profit,
which I think would be the main motivation.

In order to try to model the potential profit from such attack I picked a few cryptocurrencies with a market cap close to $60,000,000, that also belong to the Polkadot ecosystem and used Coingecko's market data, specifically "-2% Depth" column, to estimate the amount of each token that can be sold without affecting the price by more than 2%.

Cryptocurrency	Market cap	Volume (24h)	Sum of top10 "-2% depth" values
Moonriver	$58,210,000	$3,060,000	$810,000
Efinity	$60,454,000	$1,708,000	$180,000
Bifrost	$66,472,000	$412,000	$107,000

As shown in the table, it takes on average a ~$365,000 trade to drop the price of a token by 2%.
I'm going to use a number $500,000 for simplicity and also to be closer to the "safe side".

My assumption is therefore: Given a current price of JOY p, I can sell ~$500,000 of JOY without dropping the price of JOY lower than to 0.98 * p. If I short sell $500,000 of JOY my average entry price will be ~0.99 * p in this case.

Now to estimate how much a network congestion attack can affect the price of a cryptocurrency I've chosen a few known incidents that caused significant network distruptions:

Incident	Start time	End time	Start price	End price	Total price impact	Period	Avg. price impact / day
Solana DDoS-related outage	14 Sept 2021 12:00 UTC	15 Sept 2021 05:00 UTC	$165.16	$155.52	-5,8%	0.7 days	-8.3%
Helium blockchain halt	15 Nov 2021 22:00 UTC	17 Nov 2021 02:35 UTC	$48	$43.5	-9,4%	1.2 days	-7,8%
Acala AUSD incident leading to partial functionality freeze	Aug 14 2022, ~00:00 UTC	Now: Sept 25 2022, 00:00 UTC (most of the functionality remains frozen)	$0.314	$0.21	-33.1%	42 days	-0.79%
Ethereum denial-of-service attack	22 Sept 2016	17 Oct 2016	$13.23	$11.97	-9,5%	26 days	-0,37%

Although it's hard to draw any definitive conclusion from this data, it appears as though attacking the network over a period of time longer than 1 day is not optimal from the perspective of the attacker, as the time / price impact ratio is generally much lower for prolonged attacks.

It also seems like the price impact of making a blockchain unusable for about a day can be as high as ~8%.

With those assumptions we can calculate how much an attacker could potentially profit from a 1-day network congestion attack on a Joystream blockchain:

Let's say p is the initial price of JOY before the attack.
First the attacker short sells $500,000 JOY, causing the price to drop to 0.98 * p. The average entry price is 0.99 * p.
Then the attacker floods the network for one day causing the price to drop by 8%, to 0.92 * p
Let's say now the attackers buys-back the JOY at average price of 0.93 * p (we assume same market depth for buy and sell trades)
The attacker gains at most ~$500_000 * 0.99 / 0.93 - $500_000 = ~$32,000 from the attack

Of course this is almost a worst-case scenario, we're not taking into account the exchange fees and other costs associated with holding the short position, as well as whether the attacker would be willing to take the risk (as the effect on the price is uncertain).

Given this analysis, I think it is reasonable however to make the cost of such attack at least $30,000 /day.

Archival / validator node storage costs

This is very important factor and something we need to consider not only in context of an attack, but
also organic growth.

A day of full blocks (not counting operational extrinsics etc.) is: 3.75MB * 14400 = 54 GB

This is a problem not only because it increases storage requirements for validators, but also because it causes centralization and longer sync times.

However, if we focus just on storage, 1 GB of data on Amazon (I'm assuming EBS volume, since it's unclear whether S3 will have sufficient IOPS) will cost at least $0.08 / month, so each day of full blocks adds $4.32 / month of storage costs for each validator.

Assuming we have a maximum of 100 validators, that's $432 / month or $5,184 / year.

The cost increase may be even greater for Hydra Indexers / Squid Archives, since they store
all transactions and events in a less compact format and are also indexing this data to optimize
SQL queries (which requires additional storage), but for now I'm going disregard this, as it is unclear
how the people who run this kind of infrastructure will be incentivized.

For validators the incentivization proposal is clear - they earn a fixed amount of JOY a year (3%) + some percentage of transaction fees.

Transaction fees that get burned don't increase the value of validators yearly rewards directly,
they may only increase the value of their stake/holdings, but it's impossible to calculate the effect of this.

Therefore if we want the network to be suistainable, I think it's inevitible to give some percentage
of transaction fees to validators and adjust the parameters in such a way, that 1 day of full blocks equals
to at least $5,184 of total validators' earnings (which would make their operation sustainable for at least a year).

There are 2 parameters we can tweak to achieve that:

p - % of transaction fees going to validators
f - fee / byte

Having that in mind, I'll describe my proposal for both of those values later.

Polkadot/Kusama values

Tx fee / byte

Both Polkadot and Kusama use TransactionByteFee of 10 milicents. Of course Polkadot's hardcoded price assumption (1 DOT = $1) is a much more pessimistic than Kusama's (1 KSM = $300), so the real-world costs are currently much different, but I'm going to disregard the current market conditions.

Based on calculations from the previous sections, our fee should be at least $30,000 / 54 GB = ~0,056 milicents / byte.

This is a 180x lower value than 10 milicents, which could be a sign that it is underestimated.

Weight fee

Polkadot's/Kusama's weight fee is 1 cent / (10 * extrinsic_base_weight) per unit where extrinsic_base_weight = 85_212_000.
This means 1.174 nanocents / unit

Based on calculations from the previous sections, our fee should be at least $30,000 / (14400 * block_weight_limit_for_normal_dispatch) per unit, which is
$30,000 / (1.5 * 10^12 * 14400) = 0.139 nanocents / unit

This is ~8,5 lower value than 1.174 nanocents, which could be a sign that it is slightly underestimated.

Margin

We need to take into account some margin, as our calculations were based on certain assumptions, like:

Market cap of JOY being $60,000,000
JOY market having a certain liquidity
Network cogestion having a certain impact on JOY price
A certain cost of storage / GB for archival nodes
A certain number of archival nodes

For example, if the market cap of JOY were to drop to $20,000,000, while our other assumptions would remain intact,
suddenly an attack decribed in the first subsection would become profitable.

As also shown in the previous subsection, the fees I estimated are still extermely low compared to the ones of Polkadot/Kusama.

Having that in mind I suggest to take a safety margin by multiplying each fee at least 3-5 times to account for bad assumptions
(especially the one about market cap, since crypto markets tend to be very volatile)

Summary: My proposal

Taking all this into account I propose the following parameters:

Byte fee: 0.2 milicents / byte (this is still ~50x less than Polkadot/Kusama and ~4x more than the value calculated from $30,000 / day scenario)
Weight fee: 0.6 nanocents / unit (this is still ~2x less than Polkadot/Kusama and ~4x more than the value calculated from $30,000 / day scenario)
Percentage of fees going to validators: 20% (since the cost of running archival node increases by ~$5,184 / year per day of full blocks, as calculated in one of the previous sections, giving validators 20% of the fees and therefore ~$24,000 per day of full blocks with the currently proposed values seems like more than enough to account for those costs)

Why is it ok for the byte fee to be 50x less than Polkadot's/Kusama's if weight fee is just 2x less?

I think it all goes down to how many validators we want to have as described in Archival / validator node storage costs section.

For example, Polkadot and Kusama want to maximalize the number of validators. Kusama currently has 1000 validators, while in my calculations I used the max of 100.

Weight fee on the other hand shouldn't really depend that much on the number of validators, as the cost of running a validator doesn't increase proportionally to the weight of blocks being produced.

Proposal parameters

Here I'd like to specifically bring your attention to this setup:

        approval_quorum_percentage: TWO_OUT_OF_THREE,
        approval_threshold_percentage: HALF,

Because the approval quorum is greater than the approval threshold, this means there's no point in ever voting "Reject" for a proposal with those parameters, since voting "Abstain" has much more power than voting "Reject" in this case (because "Abstain" votes don't count to the quorum).

Assuming a council has 3 members, let consider this example:

I'm the first voter and I vote "Reject"
2nd CM comes in and votes "Approve"
The proposal passes, since quorum is reached (2 members voted) and approval threshold is also reached (50% of votes are "Approve" votes)

Now let's consider a different example:

I'm the first voter and I vote "Abstain"
2nd CM comes in and votes "Approve"
Approval quorum is not reached, so 3rd member decides, if (s)he votes anything other than "Approve", the proposal is rejected

This will hold true regardless of the number of council members, if approval quorum is harder to reach than the threshold,
"Abstain" will always be a more powerful vote than "Reject". With 10 CMs it would take just 4 "Abstain" votes, but no less than 6 (!) "Reject" votes to reject a proposal with those parameters.

My suggestion would be to therefore replace those parameters with:

        approval_quorum_percentage: TWO_OUT_OF_THREE,
        approval_threshold_percentage: TWO_OUT_OF_THREE,

Which makes the dynamic much clearer: It basically requires at least 2 Approve votes. If 2 out of 3 CMs vote for anything other than Approve, the proposal will not pass.

Council & Elections & Proposals

There should be a very small council, specifically with 3 members.

I agree with @mochet that the number seems low. It makes council a very centralized body, very dependent on a single actor.
I don't think I have a good-enough argument against this particular number, but if we were to go with it, I think the council periods should be shorter, because in that case bad actors can be replaced quickly and will have a more limited impact (for example, they wouldn't be able to stale key proposals for weeks). I expand on this thought further below.

(Council term) Total: 21 days = 3 weeks

I think there are multiple issues to be considered w.r.t. longer council terms:

Council members have a very limited accountability currently, they cannot be slashed (ever) or replaced (before their term ends). They also recieve high rewards that cannot be customized on per-member basis. The longer the council term the less incentieve there is for a council member to do anything at all, unless their own stake is so extemely high that they would actualy feel the price impact that their idleness is causing.
Proposals with higher constitutionality (3-4) will take forever to execute. With current set of proposal parameters the runtime upgrade (which in worst case scenario could be an important bug fix that cannot wait very long) will take at least ~2 months to ship. Now considering this proposal also requires all CMs to vote "Approve", just one CM during those 4 council terms can delay an important upgrade by another ~2 months.

On the other hand I don't think there is that much cost associated with making council terms shorter. It seems reasonable to assume that competent council members with a great long-term vision will just get re-elected over and over. With time they will also gain the advantage of well established reputation in the community and it's very unlikely they'll become replaced unless they really mess something up.

Therefore my suggestion would be to:

Make constitutionality for runtime upgrade no higher than 3. This means at best it takes 1 council term + grace period to ship it and ~3 council terms at worst (unless rejected in the meantime), as opposed to 2-4. This means almost 2x faster best case scenario.
Lower total council period to 7-14 days, I'd even opt for 7 at the beginning, at least until we have a better accountibility mechanism.

Budgets & Spending and Inflation

Content, Membership, Forum, HR, Marketing

Content, Membership, Forum, HR, Marketing WGs: These groups have to start very modestly

I'm not sure I would put Content Working Group in the same bucket as the other ones mentioned here (membership, forum, HR, marketing).

I think Content Working Group has an important role to play since the very beginning, it also has a lot of responsibility given its on-chain privileges. Things can easily go astray if we don't have enough responsive curators to watch over the platform and prevent it from being flooded with inappropriate content.

Realistically I think there should be at least 5-10 curators being paid $1,000 - $2,000 a month + a lead with a salary of at least ~$5,000, therefore I suggest a $15,000 / month budget for the content group.

Storage and distribution

Storage WG: Lets say there are 10K active channels, each one with 10 videos, each of 20min length at 1080p (H264) i.e. 10GB, in total is 10,0001010GB = 1PB, which with replication factor 5 is 5PB in total storage. With storage cost of $20K per month per 1PB, including basic bandwidth budget, this equals $100K

Distribution WG: Lets say there are 10,000 DAUs each consuming about 10mins of content per day, this is 10000x5GBx30=1500000GB egress from distributors per month, and at price of $0.02/GB on AWS this works out to $30K

I think for the purpose of estimating the budget for those groups we need to:

establish some kind of timeline, as the infrastructure requirements will vary greatly over time and so will the price of JOY. In my opinion it makes no sense to plan more than a year ahead and council can adjust the budget increments at any point through a proposal to deal with this.
have some picture of what's the relationship between the amount of content stored vs. distributed by an "average video platform"

For the purpose of my calculations I'll assume 10,000 DAUs each consuming about 10mins of content per day (as put in the original propsal) is the average daily activity we strive to reach in the first year of existence.

Content uploaded vs content consumed

I had a suspicion that the proposed budget for the storage group may overestimated, so to get a better perspective I collected some statistics about the existing video platforms, as summarized in the table below:

Video platform	Content uploaded/streamed daily (avg.)	Content watched daily (avg.)	Uploaded / watched ratio	Stats from	Stats source
YouTube	576,000h	1,000,000,000h	1 / 1736	February 2017	https://en.wikipedia.org/wiki/YouTube
Rumble	6,158h	5,833,333h	1 / 947	August 2022	https://finance.yahoo.com/news/rumble-sets-time-records-across-200000301.html
Vimeo	350,000 videos	23,833,000 videos	1 / 68	2018 / 2021	https://expandedramblings.com/index.php/vimeo-statistics/ (note that here monthly views are oudated by ~3 years compared to videos uploaded)
Peertube	1,130 videos	56,400 videos	1 / 50	Jul 2022 - Sept 2022	https://instances.joinpeertube.org/instances/stats
Twitch	2,220,709h	62,838,064h	1 / 28	August 2022	https://twitchtracker.com/statistics/stream-time

Based on those statistics I think the best upload / distribution ratio to use for my calculations will be 1/50.
I think ratios like those of YouTube or Rumble are only achieveable for services that:

Already exist for quite some time (ie. they have already already built a huge library of content)
Are way more consumer-focused than creator-focused

I think Twich & Peertube kind of confirm that theory, Peertube being a relatively new invention, while Twich being primarly focused on livestreaming, making the impact of acumulated content less pronounced.

This means that if we assume 1,5 PB being consumed monthly on average during the first year of Joystream existence, we should assume about 1 / 50 * 1,5 PB = 30 TB of videos being uploaded monthly.

Calculating storage and distribution infrastructure costs

Normally I would expect some kind of exponential growth when it comes to storage space required (due to increasing adoption), but even if we assume it happens linearly, so there is actually 30 TB of content upladed every day, with the replication factor of 5, the storage nodes only need on average ~1 PB of capacity during the first year (ie. in the first month they need 5x30 TB, in the 2nd month - 5x60 TB and so on). That's 1 PB of average capacity for storage system as a whole.

Here are a few things that I think were overlooked in the original proposal:

Some of those calculations depend on the total number of storage / distribution nodes and workers. In my calculations I'm assuming there are 30 storage nodes and 100 distributor nodes and the number of workers is the same as the number of nodes in each group.

The transfer out of AWS (egress) is not $0,02 / GB, but actually $0,05 - $0,09 / GB (source 1, source 2). If all distributors together transfer 1,5 PB out of AWS per month, then each individual distributor transfers on average 15 TB / month, which means almost all costs end up in $0,09 / GB tier. After giving it some thought, however, I think AWS may just not be the best choice for our distributors. If egress is our main concern, they are way cheaper alternatives, like DigitalOcean, OVHCloud or Linode, just to name a few. All those providers offer a substantial amount of transfer for free (~5TB on average) and just $0,01 per GB of transfer above the monthly free limit. This means the transfer costs can be as low as $100 / month per node, giving us a total transfer cost of $10,000 / month (assuming 100 nodes).
Distributors also need storage, In case total size of Joystream content directory is ~200TB on average during the first year (1 PB / 5x replication factor), the distributors probably need at at least ~2 TB (1%) of cache storage to work efficiently. If we assume each distributor uses a separate block storage (since high throughput and latency is required), which costs ~$0,1 / GB-month (AWS, Linode, DigitalOcean), that gives us $200 per distributor per month, which is $20,000 / month assuming 100 distributors.
Storage nodes also need bandwidth: In context of CDN's we're usually talking about cache hit ratio of ~90-95%, which means a cache miss ratio of 5-10%. If we assume our distributor's cache is "good enough", we should probably get ~10% miss ratio. Each cache miss is a request from distributor node to storage node. This implies storage nodes also need to worry about egress costs, as in worst case scenario they will pay ~$0,09 / GB (as described in 1.), which is $13,500 / month. However, since we already ruled out AWS as a feasible choice for distributors, I'll do the same here and just assume that ~5 TB of outbout transfer a month is within a free tier of whichever cloud provider (if any) they end up choosing, meaning that during the first year the cost of transfer is $0 / month.
Storage/distributor nodes need CPU and memory: Each storage and distributor node needs to be ran on an instance with specs like at least those of AWS t3.large instance. The cost of such instances are compareable between different cloud providers and usually ~$60 / month. If we assume there are 30 storage nodes and 100 distributor nodes, this gives us $1,800 / month for storage WG and $6,000 / month for distribution WG.
There are supervision/administration costs involved. Ideally storage/distributor nodes would just be started and forgotten about, but in reality they will probably need some supervision, maintenance, manual work (like updates, fixes) etc. Also, if storage/distributor workers earn just enough to cover the costs of their infrastructure, there would be no incentive for them to take the job. I think it's reasonable to assume that each worker will need to earn at least ~$1,000 / a month and the lead will need to earn substantially more (like $5,000 - $10,000), as (s)he would be responsible for managing all the workers, constantly monitoring the storage infrastructure etc. With our assumptions about the number of nodes/workers this gives us an additional $110,000 for distributors and $40,000 for storage working group.

Strage and distribution budget: My proposal

Based on my calculations I propose following budget parameters for storage and distribution working groups:

Storage WG

Average size of data stored during the first year: 200 TB (of unique data) * 5 (replication factor) = 1 PB
Cost of storing 1 PB / month: ~$20,000
Cost of 150 TB transfer / month (spread across 30 nodes): ~$0 (assuming it's within free tier)
Cost of instances / month (assuming 30 nodes): $1,800
Worker & lead payouts / month (assuming 30 workers): $40,000
Total budget / month: $61,800

Distributor WG

Cost of transfering 1,5 PB / month (assuming 100 nodes): $10,000
Cost of high throughput cache storage / month (100 x 2TB): $20,000
Cost of instances / month (assuming 100 nodes): $6,000
Worker & lead payouts / month (assuming 100 workers): $110,000
Total budget / month: $146,000

The key aspect of my proposal is that the budget for distributor working group is actually significantly higher than the one for storage working group, which I think is reasonable considering it's assumed to have much more workers.

Creators & creator payouts

Creators payouts: Lets say there are 1K creators involved, each receiving $500 on average/month, this nets out to $500K (omg!).

I think it general it is a good strategy to estimate budgets for different groups based on the set of assumption that were already made w.r.t. other groups, in this case storage and distribution group specifically.

For example, we assumed that on average 1,5 PB of content is consumed each month during the first year. If we take and average length of video
of ~10 min (for example YouTube has ~5 bln views per day and ~1 bln hours of content watched per day, which gives 12m per view), which is ~200 MB (full HD), this gives us ~7,500,000 views / month.

Youtube creators earn ~$5 per 1000 views (source), which
means if we want to be competitive we should probably offer up to ~$10 / 1000 views.

With those assumptions realistically creator payouts could be as low as ~$75 000 / month

Total monthly budget & inflation

My proposal

Using my proposed estimation of budget spendings, we get:

Council: $30,000 (unchanged)
Spending proposals: $5,000 (unchanged)
Content: $15,000 (+ $13,000)
Membership / Forum / HR / Marketing: $8,000 in total (unchanged)
Gateway: $30,000 (unchanged)
Builders: $50,000 (unchanged)
Storage: $62,000 (- $48,000)
Distribution: $146,000 (+ $106,000)
Creators: $75,000 (- $425,000)
Stakers: $150,000 (unchanged)
Total / month: ~$570,000
Annual inflation rate: ~11.4%

How sustainable is this?

Ideally we would need to burn more or less the same amount of JOY that we mint or just slightly less in order for the price of JOY to be sustainable over time.

We've made some assumptions about content comsumption and storage, one of which was that there is about ~1 TB of videos uploaded daily.
We've also made an assumption before that 1 video view is equal to ~200 MB of content being consumed.
Similarly, we can assume average video size is also ~200 MB (for example, average video length on
YouTube is ~12 minutes).

This means there are ~5,000 videos uploaded daily.
Each video upload is a transaction with inclusion fee of ~1,3 cent
(I'm assuming the byte fee and weight fee I proposed in Market Cap and Resource Pricing section, I'm also using weights based on https://github.com/Joystream/joystream/tree/carthage-weights-gen, 10 storage buckets / channel, and some standard metadata length)

Out of this 1,3 cent, 80% is burned, which gives us ~1 cent burned per video.

With 5k videos uploaded daily that's just $50 of JOY burned per day for video upload inclusion fees.
That's almost nothing compared to how much we actually need to burn per day (~$19,000).

Another source of burning is membership fees.
According to some YouTube statistics, given ~800 mln videos, there are ~33 mln active channels and ~122 mln daily active users. This can give us a pretty rough estimate of the number of members beeing ~6-20x lower than the number of videos. For simplicity I'll assume it's 10x lower, in that case we would have ~500 new members daily. With a reasonable membership fee of ~$1 this is still only $500 / day.

Other sources of burning include:

Other transactions inclusion fees
Data size fees
CRT sale platform fees
NFT sale platform fees

For the last 2 it's very hard to estimate the number of tokens burned, but with 2% platform fee we would need a volume of ~$950,000 / day to burn $19,000 of JOY/day, which to me seems very unlikely to achieve with our assumptions about usage within the first year. As to inclusion fees of other transactions - even if we were to assume that video creation transactions burns only constitute 1% of all transaction burns (which seems very optimistic), we'll still get $5,000 / day, which is only 25% of what we need.

That leaves us with data size fee as our last hope to counter high inflation. Ideally they should cover at least ~$10,000 of burns per day.

How much should the data size fee be?

My answer would be: As high as we can tolerate. It's not hard to calculate that we would need an average (200 MB) video upload to cost ~$2 to fully cancel the inflation. This may seem high, but note that even if each person uploading a video were to just pay the cost of storing it for one year with the replication factor of 5, it would cost them ~25 cents to upload 200 MB video, therefore I believe we cannot make it very cheap regardless. I think we should make the cost of uploading a 200 MB video somewhere in between $0,25 and $2.

My suggestion: Make data fee $0,003 / MB. This is ~$0,6 for a 200 MB video, which doesn't sound that terrible. It also means that given 1 TB of content uploaded daily there is ~$3,000 of JOY being burned each day on data size fees. Although this is just 15% of what we would need to burn to cancel inflation, it would at least be a start before we get the gateway payments rolling.

State bloat bond pricing

The cost of storing `AccountData`

// The price applied to
// We assume that if balances map is protected purely by the `ExistentialDeposit`, then
// this would be sufficient for any other storage map as well. In fact, the `balances`
// pallet this is also covering the storage cost of `AccountData` which currently has form
//
// pub struct AccountData<Balance> {
//  pub free: Balance,
//  pub reserved: Balance,
//  pub misc_frozen: Balance,
//  pub fee_frozen: Balance,
// }
//
// This has `sizeof(AccountData<u128>)` = `4*sizeof(u128)` bytes = `512` bytes, hence
// and implied upper bound for the variable cost would be `ExistentialDeposit/512`,
// so we use that
pub const FixedBloatBondPrice: Balance = ExistentialDeposit::get();
pub const PerByteBloatBondPrice: Balance = ExistentialDeposit::get().saturating_div(512);

The calculation is a bit off here:

u128 is 16 bytes (128 bits = 16 bytes)
sizeof(AccountData<u128>) is therefore 64 bytes
We also need to factor in the size of the key in frame_system::Account map, which is Twox128(Prefix::pallet_prefix()) ++ Twox128(Prefix::STORAGE_PREFIX) ++ Hasher1(encode(key)). The Twox128 encoding result is 16 bytes, so that is 16 + 16 + Blake2_128Concat(encode(account_id)) bytes, so 16 + 16 + 48 = 80 bytes. 64 + 80 gives 144 bytes in total (I'll explain the map entry size calculation in more detail later in this review)
Most importantly: our current value for ExistentialDeposit was chosen completely randomly, we cannot rely on it as an ultimate source of truth about what should be the cost of bloating the runtime state.

Reasonable value for `ExistentialDeposit` (and therefore state blond bonds)

So we know that ExistentialDeposit is a cost of storing 144 bytes in the state.

Polkadot's ExistentialDeposit is $1 (under their assumption of 1 DOT = $1)
Kusama's ExistentialDeposit is $0.01 (under their assumption of 1 KSM = $300)

Based on that and the supply of DOT and KSM (~1bln and ~10mln respectively), we can calculate the max. possible
state size (that was assumed when those values were hardcoded):

For Polkadot it's: 1,000,000,000 * 144 bytes = 144 GB
For Kusama it's: 30,000 * 10,000,000 * 144 bytes = ~43,2 TB

They seem very inconsistent, but considering Kusama was never meant to be a "safe" chain, I believe a safe value is closer to Polkadot's 144 GB. This is also the size of Ethereum's state about a year ago, when Vitalik called optimizing the state the next major challenge for Ethereum, so the value seems about right.

If we would want the same limit (144 GB) for Joystream, we will end up with a value like:

1,000,000,000 JOY = 144,000,000,000 bytes
1 JOY = 144 bytes
1 byte = ~0.007 JOY = ~42 milicents (under the assumption of 1 JOY = $0.06)

Now the size_of::<Channel<T>> for example is 320 bytes and the size of encoded ChannelById map key is 56 bytes (32 bytes prefix + Blake2_128Concat(channel_id)) which means channel bloat bond under those assumptions will be:

376 * 42 milicents = ~15.8 cents

This doesn't seem terrible, however I think there's some room here to make the fee even lower, as the 144 GB value that we chose was very restrictive.

I think it would still be safe if we were to make the fee 2-3 times lower.

My suggestion:

Existential deposit: 2 cents / 0.33 JOY
State bloat bond per byte (based on ED): ~13.9 milicents
Channel bloat bond (based on ED): ~5.2 cents
Video bloat bond (based on ED): ~4,3 cents

Calculating max cleanup inclusion fee

Unfortunately, this means we need to have estimates of the inclusion fees of such operations built into the configuration of the chain itself, which is hassle to remember to maintain. Ideally, these could be derived by just calling TransactionPayment::query_info in the configuration, but the problem is that this is not a const computation (e.g. it depends on fee multiplier in storage).

So first of all - it doesn't have to be constant in order for us to be able to use its result as a config parameter, for example we can do:

pub fn compute_fee(call: Call) -> Balance {
    let xt = UncheckedExtrinsic::new_unsigned(call);
    TransactionPayment::compute_fee(
        xt.encode().len() as u32 + 101, // I'm adding 101 bytes, as this is the length of a typical signature
        &<UncheckedExtrinsic as GetDispatchInfo>::get_dispatch_info(&xt),
        0,
    )
}

parameter_types! {
    pub PostDeposit: Balance = compute_fee(
        Call::Forum(forum::Call::<Runtime>::delete_posts {
            forum_user_id: <Runtime as MembershipTypes>::MemberId::zero(),
            posts: BTreeMap::from_iter(vec![(
                forum::ExtendedPostId::<Runtime> { category_id: 0, thread_id: 0, post_id: 0 },
                true
            )]),
            rationale: Vec::new()
        })
    );
}

The fee_multiplier starts at 1 and then is adjusted based on how congested the network is.
I think just using the default value of 1 (which assumes we operate at blocks being ~25% full) is reasonable.

The only problem here is that I'm using unsigned extrinsic to estimate the fee, which is smaller than signed extrinsic, so I need to manually add the length of a signature (xt.encode().len() as u32 + 101). This is just for simplification, because constructing a signed extrinsic is much more involved.

To comfirm this works as expected I used the CLI fee-profile command:

As you can see it works exactly as expected.

`pallet_multisig` and calculating storage entry size

// So for adding to `Multisigs` we are paying for
// `sizeof((AccountIdx[u8; 32] -> fixed_part[Multisig]))`
//  = `sizeof(AccountId)` + `sizeof([u8; 32])` + `sizeof(fixed_part[Multisig])`
//  = `sizeof(AccountId)` + `sizeof([u8; 32])` + `sizeof(BlockNumber || Balance || AccountId)`
//  = `sizeof(AccountId)` + `sizeof([u8; 32])` + `sizeof(BlockNumber)` + `sizeof(Balance)` + `sizeof(AccountId)`
//  = `32` + `32` + `32` + `128` + `32`
//  = `256`
//

This is incorrect. To actually calculate the cost of adding to Multisigs we need to look at the storage map type:

	#[pallet::storage]
	pub type Multisigs<T: Config> = StorageDoubleMap<
		_,
		Twox64Concat,
		T::AccountId,
		Blake2_128Concat,
		[u8; 32],
		Multisig<T::BlockNumber, BalanceOf<T>, T::AccountId>,
	>;

This implementation tells us that:

First key is AccountId and is encoded using Twox64Concat.
Twox64Concat encoding of AccountId produces an output of size: size_of::<AccountId>() + 8 bytes (40 bytes)
Second key is [u8; 32] and is encoded using Blake2_128Concat.
Blake2_128Concat encoding of [u8; 32] produces an output of size: size_of::<[u8; 32]>() + 16 bytes (48 bytes)

Now the final key of a double map looks like this:

/// Each value is stored at:
/// ```nocompile
/// Twox128(Prefix::pallet_prefix())
/// 		++ Twox128(Prefix::STORAGE_PREFIX)
/// 		++ Hasher1(encode(key1))
/// 		++ Hasher2(encode(key2))
/// ```

Which means we need to add the size of Twox128(Prefix::pallet_prefix()) and Twox128(Prefix::STORAGE_PREFIX)
to the values we just calculated, which gives us: 16 + 16 + 40 + 48 = 120 bytes.

If we look at an example key from Multisigs map using https://polkadot.js.org/apps/#/chainstate:

0x7474449cca95dc5d0c00e71735a6d17d3cd15a3fd6e04e47bee3922dbfa92c8d3e73123ebcdee9161cbd2d43530a44705ad088af313e18f80b53ef16b36177cd4b77b846f2a5f07cff0f22492f44bac4c4b30ae58d0e8daa0000000000000000000000000000000000000000000000000000000000000000

We can see that it's indeed 120 bytes (240 hex characters)

Now if we look at the type definition of Multisig, it's:

pub struct Multisig<BlockNumber, Balance, AccountId> {
	/// The extrinsic when the multisig operation was opened.
	when: Timepoint<BlockNumber>,
	/// The amount held in reserve of the `depositor`, to be returned once the operation ends.
	deposit: Balance,
	/// The account who opened it (i.e. the first to approve it).
	depositor: AccountId,
	/// The approvals achieved so far, including the depositor. Always sorted.
	approvals: Vec<AccountId>,
}

pub struct Timepoint<BlockNumber> {
	/// The height of the chain at the point in time.
	height: BlockNumber,
	/// The index of the extrinsic at the point in time.
	index: u32,
}

So the size_of::<Multisig> is:

size_of::<Timepoint<BlockNumber>> which is size_of::<BlockNumber> + size_of::<u32> so 4 + 4 = 8 bytes (remember u32 is just 4 bytes, since 32 refers to the number of bits) +
size_of::<Balance> which is 128 / 8 = 16 bytes +
size_of::<AccountId> which is 32 bytes

Which totals to 8 + 16 + 32 = 56 bytes.

Together the size of the Multisigs double map key + the size of value is therefore 120 + 56 = 176 bytes

For all other maps we need to follow a similar pattern when calculating the size of an entry.

This is a common mistake in this proposal, so I won't point it out in all the other places where it occurs, unless it results in some broken assumptions.

Staking:

        /// the minimal amount to be rewarded between validators, expressed as a fraction
        /// of total issuance. Known as `I_0` in the literature. Expressed in millionth, must be between 0
        /// and 1_000_000.
        min_inflation: percentage_to_millionth(3),

        /// the maximum amount to be rewarded between validators, expressed as a fraction
        /// of total issuance. This is attained only when `ideal_stake` is achieved. Expressed in
        /// millionth, must be between min_inflation and 1_000_000.
        max_inflation: percentage_to_millionth(3),

With min_inflation exactly the same as max_inflation don't we effectively end up with a flat line?
It seems like other parameters (like ideal_stake) have no meaning in this case.

`council`

pub const MinCandidateStake: Balance = dollars!(10_000);

As I already mentioned, I'm not a fan of 21 days council periods, but this is another reason.
If a bad actor ends up in council with just minimum stake and the proposed parameters of 21 days council term and a $10,000 reward a month, they're almost doubling their stake during the term, no matter what they do or don't do during said term.

next_budget_refill

Type: T::BlockNumber

Description: The next block in which the budget will be increased.

Values: 0

It's not a good idea to set this value to 0.
It's used during on_initialize, where it's compared against the current block number, which is never 0:

    // Checkout elected council members reward payments.
    fn try_process_budget(now: T::BlockNumber) {
        // budget autorefill
        if now == NextBudgetRefill::<T>::get() {
            Self::refill_budget(now);
        }

        // council members rewards
        if now == NextRewardPayments::<T>::get() {
            Self::pay_elected_member_rewards(now);
        }
    }

Although we can away with next_reward_payments being 0, because it's also modified when new council is elected:

    fn elect_new_council(elected_members: &[CouncilMemberOf<T>], now: T::BlockNumber) {
        // ...
        // try to pay any unpaid rewards (any unpaid rewards after this will be discarded call)
        Module::<T>::pay_elected_member_rewards(now);

If we set next_budget_refill to 0, the budget will never refill.

Suggestion: Change the value of next_budget_refill in genesis config to 1 or leave it as it is now (<Runtime as CouncilTrait>::BudgetRefillPeriod::get())

`members`

    pub const DefaultMembershipPrice: Balance = cents!(5);
    pub const ReferralCutMaximumPercent: u8 = 50;
    pub const DefaultInitialInvitationBalance: Balance = dollars!(5);

Notice that membership pallet has this constant hardcoded outside of the Config:

pub(crate) const DEFAULT_MEMBER_INVITES_COUNT: u32 = 5;

This means that by buying membership for 5 cents we get 5 invites.

If each of these invites can produce a new membership with $5 of invitation-locked funds, this means we can very cheaply acquire a lot of locked JOY, which can then be used to spam the blockchain (as invitation lock can pay for tx fees), or for voting.

For example, if I buy 1000 memberships for just $50, I'll get 5000 invites and can effectively get $25,000 of invitation-locked JOY. I can then use this locked JOY to spam the blockchain with full blocks for almost an entire day(!)

Therefore I think it only makes sense for DefaultInitialInvitationBalance to be no more than DefaultMembershipPrice / DEFAULT_MEMBER_INVITES_COUNT.

My suggestion:

DefaultInitialInvitationBalance: 50 cents
DefaultMembershipPrice: $1
DEFAULT_MEMBER_INVITES_COUNT: 2

Individual members can recieve more invites provided they are not abusing this feature.

`working_group`

    pub const MaxWorkerNumberLimit: u32 = 30;

As already pointed out by @mochet, 30 seems very low.
I think this especially applies to DistributionWorkingGroup, unless we want each member to run at least 3-4 nodes?

// Setup all reward payouts to be happening in a cascade of 10 blocks apart.
 pub const ForumWorkingGroupRewardPeriod: u32 = days!(1) + 10;
 pub const StorageWorkingGroupRewardPeriod: u32 = ForumWorkingGroupRewardPeriod + 10;
 pub const ContentWorkingGroupRewardPeriod: u32 = StorageWorkingGroupRewardPeriod + 10;
 pub const MembershipRewardPeriod: u32 = ContentWorkingGroupRewardPeriod + 10;
 pub const GatewayRewardPeriod: u32 = MembershipRewardPeriod + 10;
 pub const OperationsAlphaRewardPeriod: u32 = GatewayRewardPeriod + 10;
 pub const OperationsBetaRewardPeriod: u32 = OperationsAlphaRewardPeriod + 10;
 pub const OperationsGammaRewardPeriod: u32 = OperationsBetaRewardPeriod + 10;
 pub const DistributionRewardPeriod: u32 = OperationsGammaRewardPeriod + 10;

The effect of this will be cumulative, so the rewards will no longer happen in "cascase od 10 blocks apart" right after the first reward.

Let's say for Forum working group the first batch of rewards is paid at block x, and for Storage at x+10.
Then for Forum the second batch will be paid at block 2x, for Storage at 2*(x+10) = 2x + 20, for Content: 2*(x+20) = 2x + 40 and so on...
So the second time the rewards are paid, individual groups will already be 20 blocks apart, and the n-th time they are paid they will be 10 * n blocks aprart (and some point some groups will be days behind...)

`bounty`

 pub const MinWorkEntrantStake: Balance = compute_single_bloat_bond_with_cleanup(EntryMapItemByteSize, MaxWorkEntrantCleanupFee);

This will be possibly much lower than CandidateStake which is described as "lower bound for any stake binding", although I'm not sure if that by itself is a problem.

`storage`

pub DataObjectPerMegabyteFee get (fn data_object_per_mega_byte_fee) config(): BalanceOf<T> = (100*BYTES_IN_GB).saturating_div(cents!(1));

I don't understand this formula.
It basically says the fee per megabyte is (100 * 10^9) / (HAPI per $0.01), which is 10^11 / 1666666666 = 60 HAPI.
So it's just $0,0000000004 per MB, which is obviously too low (that's $0,0004 per TB of uploaded data!)

My suggestion is to make data size fee $0,003 / MB, I provided a rationale for this in the How much should the data size fee be? subsection above.

    pub const StorageBucketsPerBagValueConstraint: storage::StorageBucketsPerBagValueConstraint =
       storage::StorageBucketsPerBagValueConstraint {min: 3, max_min_diff: 10};

I recently changed this sematic to MinStorageBucketsPerBag and MaxStorageBucketsPerBag, as it's more clear and also makes it easier to define bounded collections based on those values.

So having that in mind, do we want MaxStorageBucketsPerBag to be 13 or 10?

`proposals_engine`

// Its difficult to select one uniform value here, and since this fee actually
// is collected regardless of how much was actually staked, it should be kept low for now.
pub const ProposalCancellationFee: Balance = dollars!(1);

I think the only real risk of this value being to low is that since there can be only some number of active proposals at any given time, this means someone
can quite cheaply create new proposals and keep canceling them before they get slashed, possibly blocking some important proposal from being submitted.

Initially I thoght 1 USD may be too low to discourage this kind of attack, but on the second thought it's probably just enough, given how easily it can be mitigated by a responsive council.

`proposals_codex`

// We are keeping this purposefully small for now becuase we only have one funding request
// proposal, and if it was to allow big spends, then we would need different parameter settings.
// This can be introduced later
pub const FundingRequestProposalMaxAmount: Balance = dollars!(10_000)
pub const FundingRequestProposalMaxAccounts: u32 = 20;

Please note that FundingRequestProposalMaxAmount is actualy per account, so with FundingRequestProposalMaxAccounts we get $200k per proposal.

First Proposal: Mainnet Parameters #4300

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions