Hi! I would like to ask what will be the requirements for running a storj satellite?
I had the same question, no answer yet
You havent gotten an answer because there not allowing anyone to run a satellite as of right now.
Hi All,
The goal is to enable anyone to run a Satellite on the Storj network. We have already come across plenty of providers that plan on operating their own Satellites.
We are in the process of breaking up the satellite peer class into modular components to facilitate third-party operation. We are working with a number of third-parties and community members to test the waters, which enables us to build a comprehensive framework with detailed documentation around Satellite Operation. This will enable anyone with the technical know-how to run them.
In terms of functionality, the Satellite participates directly in the node discovery system, and caches node address information, stores per-object metadata, maintains storage node reputation, aggregates billing data, pays storage nodes, performs audits and repair, and manages authorization and user accounts.
Thus running one is no small task, and will be much more intensive than running a Storage Node.
Satellites that meet certain metrics will qualify as Tardigrade Satellites. Tardigrade Approved Satellites are approved and audited to ensure they are using unmodified code and maintaining S3-equivalent or better quality, durability and performance.
Eventually, as blockchain and distributed compute platforms mature, the goal is to feed all of the satellite processes back into the network itself.
For more information around the Satellite peer class, operation thereof, and Tardigrade eligibility, here are some relevant posts:
Additionally, check out section 4.10 of our whitepaper, https://storj.io/whitepaper
2 Likes
How about for more information on this? 
1 Like
We have a few design docs structured around this. I would love to open up a deep community discussion around it, once it comes time to share. Generally, we’ve found that the tradeoffs for running Satellite processes onchain (today) are much slower performance, more complex behaviour, and new attack surface vectors.
For some users there may be an advantage to using a satellite where processes are hosted onchain, unstoppable world-computer style. However for general population, we believe the tradeoffs around performance (today) would probably not be worth it.
By avoiding Nakamoto Consensus for processes like repair, audit, metadata retrieval, we are able to create a network that is faster than Amazon, while retaining decentralized peer-selection, open-source nature, and decentralized economics – enabling anybody to #bethecloud and compete with MEGACORP, today!
A good overview of our emphasis on coordination avoidance can be found here: https://storj.io/blog/2019/05/coordination-avoidance-on-the-storj-network/.
I think that ETH2.0, sidechains, state-channels, etc. may open up new opportunities to make this a more realistic alternative for users in the future. Would love to hear more of your thoughts @BrightSilence.
3 Likes