Sunshine Server

#1

It was great meeting @AdnanF at Consensus 2022 and sharing this idea with him. Adnan got the concept immediately and even named it “Sunshine Server”

The elegance of blockchain lays in its simplicity rather than its complexity. the climate impact of blockchain can be eliminated with a simple on/off switch. The sun rises, crypto is mined, the sun sets, crypto mining stops. Information is passed along longitudinally and latitudinally. A pulsating, living, breathing economy that follows the sun. Now called, Sunshine Server.

A prototype is all that is needed for vast potential. Is there a way for select (and connected) servers to only be processing when they are powered by solar energy, and turned off when they are not? On during the day, off at night.

Thank you,

Mike Duwe
Sharing Green Economy (SGE)

1 Like
#2

I think running nodes on renewable energy is fantastic, and there’s a grid enhancement proposal out there on giving different uptime requirements for nodes verifiably running on entirely renewable energy.

With that said good uptime is very good to have when hosting resources, perhaps less so in threefold’s case since it is self healing, but downtime every single night still would be bad. It’s definitely possible to run with fully renewable power and maintain a consistent 95% uptime.

2 Likes
#3

My only though of what would be a roadblock is how do all of the nightshifters stay online to access the sunshines servers if their network goes down every night…

Do you have an idea on what kind of workloads would lend to this type of setup?

1 Like
#4

Interesting question. Showing age here (but I don’t care): the whole Amazon cloud was invented because the amazon book selling website needed more capacity on the weeks before Christmas selling book gifts than on a regular Monday morning.

The difference between the peaks and throffs capacity needs for websites or services is enormous and all of the capacity that makes up the internet is always on while we do not need all of all the time. Imagine that all electrical household aids are on all the time and we use them a very small amount of time during the day.

I believe there is a huge opportunity to support workloads (machine learning, rendering, data sorting etc.) to use time based, not always on capacity and get the window of actual need for capacity as closely matched to the window of capacity creation / availability.

Not easy, but smart contract provisioning can get us a long way towards this :sunflower:

2 Likes
#5

Is it possible for a workload to change nodes seamlessly to the end user? Like say a workload is running on node y and it’s scheduled to go down, can it be shifted to node x temporarily?

3 Likes
#6

Great questions. The goal I think would be to just have a prototype with no nightshift usage (100% sunshine) and the workloads would be minimal (just enough to pass along what matters most to humanity). Just having that might prove to be profound in ways that we can’t fully realize at this point. Because the hard debate that usually doesn’t take place alongside the debate of blockchain consuming too much energy, and how to optimize for less energy usage, is whether blockchain is needed at all to solve our challenges. By achieving purity on both sides of the coin to begin with, this might provide some fascinating insights.

1 Like
#7

Yes, and to be honest this is not something that is new in the industry, this happens on a daily basis in all clouds. This is also more an “application feature” than a grid or cloud feature. For high available database workloads the concept of having a database cluster (simply said 2 database applications) with a high frequency data synchronization mechanism is doing that trick. If one physical server fails, the other one continuous to operate one database application (at risk of when this one fails the whole database function fails) while the failed one can be repaired and brought back in a working state to reinstate the cluster functions.

This can be done on the TF Grid in a fairly similar manner than on any other cloud.

3 Likes