1. GNuggies: A Proposal for Hosting Resilient Stateless Services Using Untrusted Nodes
Harshit Agarwal

2. Infrastructure as a Service (IaaS)
Cloud provider dynamically manages the allocation of machine resources.
AWS Lambda, Google Cloud Functions, Azure Functions.
Cheaper, Easier, Better.

3. Dealing with increasing censorship
Net neutrality repealed.
AWS refuses to host WikiLeaks.
Authoritarian regimes with limited freedom of speech and information.
Other applications with social benefits not allowed on popular hosting platforms (like PirateBay).

4. GNuggies: IaaS Using Volunteer Machines
Machines volunteered by people. Untrusted machines.
Architecture design to increase security and resilience.
No liability to volunteers, services tough to take down through legal or any other means.
Incentives for contributing.
Compatibility with existing protocols.

5. Related Work
BOINC,
IPFS
BitTorrent
Vectordash

6. Attack Model Malicious individuals Malicious institutions
Malicious responses
Reading private data
Malicious institutions

7. Attack Model: Malicious Institutions
Adding a large number of malicious machines to GNuggies.
Directives for ISPs.
DDos attacks.

8. Architecture: Preliminaries
Stateless and deterministic services.
Malicious machines once detected, will be removed from GNuggies immediately.
All machines uniquely identifiable and identity cannot be spoofed.

9. Architecture and Design

10. Architecture and Design: Client

11. Architecture and Design: Volunteers
Machines that are added to the GNuggies network by the public.
Maintains connection to other volunteer machines and core GNuggies services.
PCs, laptops, etc.

12. Architecture and Design: Services
Stateless and deterministic.
Hosted in Docker containers, Docker image to be replicated on volunteer machines.
Infrastructure details abstracted from service creator.

13. Architecture and Design: Service Clusters
Clusters to host a service.
Leader election and load balancing.
3 service cluster replicas per service, for response verification.
Membership keeper keeps clusters balanced.

14. Architecture and Design: Node Clusters

15. Trust∝Age

16. Architecture and Design: Node Clusters
Nodes split into 3 clusters, by age.
Oldest 1/3rd nodes in trusted cluster.
Each node cluster holds one service cluster replica per service.
Nodes unaware of their age and cluster.

17. Architecture and Design: Membership Manager

18. Architecture and Design: Membership Manager
Acts as an introducer.
Keeps track of age and task assignment.
Allocates tasks and services to volunteers.
In charge of Fairness in task allocation.

19. Architecture and Design: Task Allocation
Need fairness in allocation of services to volunteers.
Using Max-Min Fairness.
Services that receive more requests, will get more resources.
Allocations re-computed every 24 hours, nodes change services often.

20. Architecture and Design: DNS

21. Architecture and Design: DNS
For every service, IP of host constantly changing.
Need central Name Service to track services and hosts, which all services could point ISPs to.

22. Architecture and Design: Proxy

23. Architecture and Design: Verification

24. Architecture and Design: Verification
3 responses per request, look for consensus.
Inform Membership Keeper and remove nodes detected as malicious.

25. Architecture: Bringing it Together
Proxy
Client
GNuggies DNS
Trusted Node
Probation Node 1
Probation Node 2 r2 r1 r3
Proxy
r1, r2 &r3 r1
Verification Service
Client
Verified Correct response

26. Verification Look for consensus among the three responses.
In case of no consensus, use oldest machine’s response.
Any machine flagged as malicious is removed from GNuggies immediately.
Verification run for every single incoming request.

27. Formal Analysis

28. Terminology
Trustworthy machine: A machine that is known to currently not be malicious.
Fully trustworthy machine: A trustworthy machine that we know will not turn malicious at any point in the future.
Malicious response: A response sent by a malicious machine, which is not the same as the expected response from the hosted service.

29. Time Spent by Malicious Machines on GNuggies
Assuming all trustworthy machines, any machine that turns malicious, will be detected and removed from the platform immediately. In this scenario, number of malicious machines will always be close to 0.
Malicious machines removed from GNuggies right after their first malicious response is detected.

30. Reliability
If the oldest 2/3 machines are fully trustworthy, and there are no changes on the the size of the platform, it is impossible for any service to be disrupted, or for any client to receive a malicious response.
Malicious machines will only be in Probation Cluster 2, and will get detected and removed from GNuggies immediately, so no service disruptions will be observed.

31. Resilience to Malicious Institutions
Assuming all n machines on GNuggies are fully trustworthy, an outside agency will have to submit more than n/2 malicious machines as volunteer machines on the platform, in order to disrupt services or to fool the verification service.
More than n/2 machines needed to make fewer than the oldest 2/3rd machines fully trustworthy.

32. Minimum Requirements to Host Services
To host m services on GNuggies, at least 6m volunteer machines are needed (assuming they are all trustworthy).
At least one leader and one other machine needed, per service cluster. And we have 3 service clusters per service.

33. Incentives

34. Goals for Incentives Users should want to contribute compute.
Users should not want to behave maliciously.

35. Payoff∝Age

36. Payoff per Request
Assuming that service creator is charged 1 unit of some currency for every request served.
If there are n machines on the platform, age goes from 1 to n, 1 being the oldest.
3 machines service a request, in order of age: n1, n2, and n3

37. Average Payoff in Each Cluster

38. Incentives Incentive to join GNuggies. Incentive to stay on GNuggies.
Incentive to not turn malicious.

39. Questions?

40. Thank you!