I’m making some assumptions:
- Cloudflare deploys R2 with a storage cost of 1.5 cents/GB and no egress charges. Per-operation charges are 80% of S3 (that’s what they’ve set as a target). These charges are fairly insignificant.
- Storj charges .4 cents/GB for storage and .7 cents/GB for egress
- Any customer needing high egress will make R2 their primary reference, gradually migrating off services with egress charges with “copy to R2 on object reference”, perhaps keeping their old provider as a backup
- Other storage services will drastically reduce their egress charges (most likely IMO) or accept the loss of their high egress customers
Because of the storage price difference, Storj is still a better deal for backups IMO. But for content delivery, it will have a very hard time competing with R2. It depends on the ratio of storage to egress: if that tilts toward storage, Storj is a better deal. If it tilts toward egress, R2 wins. So for SNOs, I think egress being a payday like it is now will not continue, but that’s just my opinion.
Intentionally selecting slow nodes: yep! I’m making another assumption here that there are nodes that are inherently slower compared to other nodes, maybe because of the hardware used. The current system optimizes uploads and downloads relative to the point of upload or download. That’s clever, but there are always tradeoffs:
- 115 nodes are selected for upload but only 80 will win. The 35 slower nodes have wasted their time.
- If my goal is to distribute data similarly to the Storj network distribution to optimize worldwide downloads, long-tail cancellation on upload thwarts that by giving preference to faster nodes, either because the node uses faster hardware, has higher ingress bandwidth, or is “closer” in the network sense to the point of upload (lower latency). To achieve more even distribution, long-tail cancellation should be avoided on upload and repair.
- on download, 39 nodes are selected and the first 29 are used, with 10 wasting their time. A node might be inherently slow because it uses slower hardware, has slow egress bandwidth (I have 1Mbit/s for example), or is located on a remote island.
Slow but reliable nodes are still very useful for the Storj network to satisfy the durability and availability numbers. If there was a way to request downloads from slower nodes (best effort download w/o extra cost), it would let them actually contribute to lowering egress loads on better-performing nodes where fast egress is required, ie, content delivery, without wasting their resources trying to compete with fast nodes in situations they can’t possibly win. This might also help with the node churn issue. I don’t think there is an incentive to have a slow node, especially if egress payouts are reduced or eliminated to compete with R2.