Contract layer rework - Power management

[DylanVerstraete]

So, to get the discussion started I would like to indicate that the whilst the current progress on smart contract regarding power management will work, it will not be the "best" solution we can come up with. It is quite bad that we did not really explore other viable paths before we spent 2 months working on this feature. What mostly triggered this discussion is the amount of storage tfchain is accumulating. Since the inception of Zonaris (2 weeks ago) our data size increased with a whopping 9GB (from 60gb to 69gb). This is due to all the items we store on chain and the amount of events that are emitted by running a workload. Since we are only in a starting phase, we don't think it will be scalable on the long term. A lot more nodes will register and a lot more deployments will be created in the future, having all this storage items for all these objects will cause a lot more data.

Currently, capacity planning is implemented on the chain side. Since the chain knows about all used / free resources of the nodes it looked only obvious to us that capacity planning should have been implemented on chain. What we didn't know is that a lot more storage was needed and the contract also needed extension which made the API cleaner but behind the hood to much is happening at once and it's become very obvious that it will not scale.

To give some easy example, when someone wants to deploy a network on a node the user needs to first create a CapacityContract which reserves resources on a node, to later create a Deployment where the actual workload is defined in. The CapacityContract abstraction was a good solution to work with capacity planning but it made the UX only harder.

The problem

How do you implement capacity planning in a "decentralised" way whilst keeping storage on the chain as minimal as possible.

Solution 1: Farmerbot

In this solution, the farmer needs to run a process called Farmerbot. This process will take care of capacity planning and powering on / off nodes. In this case, when a user wants to deploy something, he creates a minimal agreement with a Farmer. Then he sends the deployment to the farmerbot and the farmerbot delegates the workload to a node that can handle it.

When a node deploys the workload, the node sends proof to the chain. The farmerbot should also bill the user for the used capacity on the node within some frequency.

The chain could also verify if the farmer bots are honest by doing verification after a bill happened. Validators on tfchain would need to run RMB to contact nodes and verify what is deployed and how much the farmer bot billed the user for it.

Solution 2: Nodes do capacity planning

TODO