Restriction on resources or functionality to avoid abuse

[nvalerkos]

It would be best to include:

• Require resources (space ie. 5GB free, or cpu ie. 4 cores)
• Require functionality (Outgoing requests or Incoming )
• Require Minimum Run time (ie. 1 year)

This way a host can select which manifest to accept prior of installing docker image.

[justmoon]

Great suggestion! Thanks for that!

Based on the technology we are building off of (hyper/Kubernetes/etc.), here's what I would suggest:

Require resources (space ie. 5GB free, or cpu ie. 4 cores)

• We already have a "machine size" field that covers # of CPUs and amount of memory. I think that's good as-is. We currently have one size, small, which represents 1 vcpu and 512MB of memory. Multiple vcpus are actually pretty inefficient, so I think we would mostly add machine sizes that are 1 vcpu with different amounts of memory (maybe in powers of two, i.e. 512 MB, 1 GB, 2 GB, 4 GB, 8 GB or powers of four, i.e. 512 MB, 2GB, 8GB, 32 GB to fragment the market less). If you needed more CPU power, you'd just upload your pod to more hosts.

• For disk space, Kubernetes usually thinks of that separate as "volumes". So we could add a field in the manifest where you can basically buy storage space by the GB that gets attached to your pod. And then you can mount it in your pod wherever you want. Hyperd already supports that, so that would be pretty easy to add.

Require functionality (Outgoing requests or Incoming )

• One very interesting feature would be if hosts offer pods their own IPv4 and/or IPv6 addresses. Then we could even allow pods to listen on custom ports with custom protocols. (Right now, we only allow HTTPS.)

Require Minimum Run time (ie. 1 year)

• That's an interesting idea. The runtime is currently specified outside of the manifest but it would be potentially useful to specify a minimum runtime in the manifest, so that users can rely on the fact that the uploader prepaid at least that much, so that the contract doesn't suddenly stop. For example, if we do a contract that's supposed to monitor the weather for a year, we don't want it to suddenly stop after three months. I think even more useful than runtime would be runUntil with a date. I.e. the contract needs to be prepaid at least until such and such date. Otherwise, if the contract says minimum runtime one year, I still don't know if it's going to be online in a month, because it could have been running for 11.5 months already.

[nvalerkos]

Ok nice.

What I was going for functionality is to have a way to prevent or permit outgoing requests to third party so to avoid DDos by using this. A way to go for this to have like a limit on the outgoing requests. I have made a script which can bring down web servers by attacking search input fields.
Is there something that we avoid abuse?

[MarkusTeufelberger]

Something like https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ would be nice to have, there's a BIG difference if I need to specify 64 or 128 GiB RAM if I only need 70 GiB.

More exact limits would lead to better utilization and probably better pricing opportunities too, instead of having something similar to the instance types on https://aws.amazon.com/en/ec2/pricing/on-demand/ containers allow you to be more specific about resources required and requested from the get-go while also allowing the host to enforce these.