you are correct, there are 4 satellites
No it is not. You can run your own satellite:
You just cannot run Storj satellites, only your own. And that includes everything from node operator management and payments to customer acquisition, handling customer payments and high level of availability with potentially global scope and operation without errors and data loss as the satellites hold the database for the customer files. If that breaks SNOs and customers wonāt be happy.
1 Like
I hope you know that even though āweā call it ONE satellite, its actually a cluster of servers.
Actually @alpharabbit is right, it can be implemented as a one production satellite, because it consist of hundreds distributed services anyway, so we can make the distribution not regional but global. We can also make the selection of the closest instance automatic, as we do for the gateway (which is a distributed service too).
So, I think it can evolve like that.
Currently, there are no reliable and inexpensive decentralized computing systems that do not require trust, so you cannot join a production cluster because it requires trust, which is not guaranteed in a Byzantine network of nodes.
Therefore, as many others have already said, you can only create a separate Storj network with your own storage node operators (SNOs), clients, and your own satellite cluster, database cluster, 24/7 network operations center (NOC), and full high availability (i.e., redundancy of equipment, internet and personnel, as well as cooling systems, and so on).
see that is not what i thought, i thought it was one just like the node
so only 4 needed now makes sense since there might be 12 or more āhidingā behind the number of 4
adding on top of that that everything has to have redundancy in equipment etc etc
yeah now i start to see why this is not for the individual that ājustā wants to take on another task and help out,
it could be a task for those that work in a NOC anyway and can get 24/7 access (so that they can access on their time off should it be needed
There were/are plans in the future to offload tasks like the ārepair workā to special nodes but its in the pipeline. Maybe @Alexey knows the current status.
No, I donāt know, I donāt see it on the roadmap either:
I was referring to this
Yes, itās a blueprint. It doesnāt meant that it would be used for a Public network, do you see a word ātrustedā in its name? The Public network is Byzantine by default, so itās not applicable.
This blueprint has been used to implement the distributed repair workers, which can be run outside of the satellite cluster, even working across the globe to distribute pieces more evenly, but they are run in a trusted (controlled by us) environments.
The design for Byzantine environments has not been prepared yet.
1 Like
then what about those that are willing to host (give the equipment a home)? or would you need to have physical access ?
EDIT: reading the blueprintā¦.
- Disable satellite-side repair, allowing the delegated repair workers to perform all repairs as needed.
i would call that a bad idea, at least in the beginning, what if there are not enough external repair workers to take over fully?
Your environment, especially home equipment, is unreliable. Currently, there is no fast, inexpensive, and reliable protocol/solution for ensuring computational security in a zero-trust environment.
In reality, the satellite cluster itself does not require significant computing resources; the calculations are relatively inexpensive. The main burden falls on the distributed database. Currently, there is no protocol or solution for creating fast, reliable and inexpensive distributed databases that could operate in a zero-trust environment.
They are scaled automatically. We also have an alerting system, so we can increase them manually too.
However, there is another problem ā the distributed database. It needs to be scaled further if the repair queue becomes too long, and thatās not cheap. Thus, while the number of worker processes for repairs can be scaled indefinitely, the distributed database is much more expensive, and currently there is no solution to offload it using a distributed network with zero trust level without data leaks. So, it requires trust, which is not possible with the Byzantine network.
So i see 2 things
- equipment
- environment
i guess the equipment needs to meet a certain minimum and that tamper dectection is possible, ie its not possible to gain access to the inside of the unit without it triggers an event.
also it would need dual power supply, that one might be harder but prop it would cost more than a new car (with danish taxās on it), would it be enough to make sure that something else in the house could not bring the power down and then add 2 UPSās in front of it? here in denmark that could be done by running the power on its own GFCI, so say there is a fault in the dishwasher or the stove the āhouseā GFCI would trip but not the that feeds the satellite unit. of course that would cost a bit, but not nearly as much as a true independant feed that might need to be dug from maybe 12 miles or more away. the 2 GFCI is something i might do anyway to protect my pcās and 3d printers, and along with it also internet connection.
the internet connection (fiber optic in my case) is harder, i dont think i will get the owner of the fiber (which is seperate from the ISP) to install another fiber that does not come from the same cabinet. the only alternative i could think of is a 5G connection. that one would cost about the same as the fiber connection, but its limited in speed (50/20 ping 24 ping during download 462 during upload 1334 jitter 2)
also i assume there would be a need for personal to be able to get to the unit within relative short time, i have the lux of being on a pension so iām home almost all the time except for some shopping and dog walks, but iām never more than an hour away
did i miss anything?
yes, but you still need enough before you can tell the satellite not to repair, extreme example would be only one repair nodeā¦. what would happen if the satellites where told not to repair
and i guess the DB is not encrypted hence the need for trust?
There is no official requirements as it will NEVER be a storj satellite, it will be your satellite, there for It will not be listed automatically in satellite list.
So for tests you can take any hardware. If you would like to make it a business, then it is you will decide what hardware you need to convince your clients to use it. There Never will be storj clients. Also you have to convince node operators to use your satellite. Node operators will need to add it manually.
1 Like
Itās encrypted. However, itās not the same as running storagenode. The customers data is encrypted with their keys, yes, but also to join the cluster there is another encryption. Did you setup a raft cluster (Consul, Nomad, Vault, docker swarm, etc.)? itās very similar.
But the main problem is trust to you as an operator - you will have an access to data and can delete it or corrupt or try to decrypt or hack. There is no distributed databases which can work as we implemented the distributed storage in a Byzantine network.
But is that not also the case at the Storj end? it would only take one person that gets disgruntled
sounds like you are a bit PI***D off? there once was a wise lady that said if you dont have anything good to say then stay silentā¦
i know damm well that the chances of community satellites that is part of the network is pretty slim, but if one never ask where the true problem is, then one will never get any smarter
I wouldnāt be discouraged: it still sounds like a fun project to get another community satellite working! And for just running at home you donāt need any HA features. If you do decide to make something more official: renting some colo space would probably be a great start.
Anyone using the firstā¦ would probably gladly test with yours too. I imagine you need around 100 nodes to jump-start your network? We have almost 30k nodes today - if you make a new post in this forum it should be easy to find those volunteers!
as said by @Alexey the problem is not so much the hardware or the environment you run it in, its more the trust to the operator, that they dont start to hack the data that passes through and in that way get access to the data
my point is the risk is the same with storj staffā¦ just one disgruntled staff memberā¦ and they dont have to hack to get access