Table of Links Abstract and 1 Introduction 2 Background and Motivation 2.1 Decentralized Computing Infrastructure and Cloud 2.2 Advantages of DeFaaS 2.3 System Requirements 3 Overview of DeFaaS 4 Detailed Design of DeFaaS and 4.1 Decentralized Scheduling and Load Balancing 4.2 Decentralized Event Distribution 4.3 API Registration and Access Control 4.4 OAuth2.0 Support 4.5 Logging and Billing and 4.6 Trust Management 4.7 Supporting Multi-Cloud Service Mesh 5 Implementation and Evaluation 5.1 Implementations 5.2 Experiments 5.3 Evaluation 6 Related Work 7 Conclusions and References 4 Detailed Design of DeFaaS In this section, we describe the details of the main components of the system. 4.1 Decentralized Scheduling and Load Balancing Different from the conventional multi-cloud deployment of FaaS, DeFaaS avoids any centralized component as a front-end for scheduling API calls. A user can make API calls to any API gateway. The management blockchain can keep track of the reputation and support trust management of the gateway nodes. Each API gateway needs to be registered with the management blockchain. The system can require a minimal stake to be deposited for the gateway providers. To avoid fragmentation, the system can enforce certain policies like enforcing maximal number of gateways for each cloud, minimal setting of a gateway like types of instances, memory size and the number of vCPUs. To dispatch the API calls across cloud data centers, the system applies randomized load balancing (e.g., [Mitzenmacher(2001a)]) to avoid scenarios that all the API calls are sent to a single cloud provider. In randomized load balancing, when a gateway receives an API call, depending on the policy setting for the dApp or Web3 application, the gateway randomly routes the call to one of the available cloud service providers. For instance, the popular power of two heuristic [Mitzenmacher(2001b)] can achieve good performance with very low overhead. A unique characteristic of our design different from all the prior work in randomized load balancing is that scheduling outcome must be publicly verifiable. This is a fundamental difference between distributed system vs. decentralized system. To support public verification, randomization by the gateway nodes must use a random source that can be verified publicly. A simple approach is to use an on-chain random source like block hash. Using block hash like Bitcoin block hash as publicly verifiable random source is a common practice [Bonneau et al.(2015)]. In this work, gateway node applies block hash from a reference chain like Bitcoin or the management blockchain as the random source for randomized load balancing. Gateway providers are compensated based on the number of successfully handled API calls. To provide incentives for the gateway providers, payments to the gateways are weighted. This means that if the number of API calls handled by a gateway is skewed from the prediction based on the randomized load balancing and target distribution, its received payment will be reduced. As an example, for a dApp, the system may require all the calls be evenly distributed among three cloud providers. Gateway nodes that cheat the system can be punished, for instance receiving negative payment for the handled API calls that exceed a limit. Scheduling policies are recorded on the management blockchain. Depending on the utility of the use cases, scheduling policies can be configured to achieve proper trade-offs among requirements such as decentralization, cost, performance. For instance, policies prioritizing decentralization may reward distribution of the API calls to multiple clouds. To provide scheduling assistance, the system employs Oracle providers who send gateway load data feed to the management blockchain. The Oracle providers estimate gateway load by sending testing API calls and measure performance metrics like the completion time. It is important to mention that the API gateways only query the management blockchain periodically to read other gateways’ load status. The gateway load status is cached locally and used for randomized load balancing. There is no on-chain update for viewing gateway load status. Authors:
(1) Rabimba Karanjai, Department of Computer Science, University of Houston (rkaranjai@uh.edu);
(2) Lei Xu, Department of Computer Science, Kent State University;
(3) Lin Chen, Department of Computer Science, Texas Texh University;
(4) Nour Diallo, Department of Computer Science, University Of Houston;
(5) Weidong Shi, Department of Computer Science, University Of Houston. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Background and Motivation 2.1 Decentralized Computing Infrastructure and Cloud 2.1 Decentralized Computing Infrastructure and Cloud 2.2 Advantages of DeFaaS 2.2 Advantages of DeFaaS 2.3 System Requirements 2.3 System Requirements 3 Overview of DeFaaS 3 Overview of DeFaaS 4 Detailed Design of DeFaaS and 4.1 Decentralized Scheduling and Load Balancing 4 Detailed Design of DeFaaS and 4.1 Decentralized Scheduling and Load Balancing 4.2 Decentralized Event Distribution 4.2 Decentralized Event Distribution 4.3 API Registration and Access Control 4.3 API Registration and Access Control 4.4 OAuth2.0 Support 4.4 OAuth2.0 Support 4.5 Logging and Billing and 4.6 Trust Management 4.5 Logging and Billing and 4.6 Trust Management 4.7 Supporting Multi-Cloud Service Mesh 4.7 Supporting Multi-Cloud Service Mesh 5 Implementation and Evaluation 5.1 Implementations 5.1 Implementations 5.2 Experiments 5.2 Experiments 5.3 Evaluation 5.3 Evaluation 6 Related Work 6 Related Work 7 Conclusions and References 7 Conclusions and References 4 Detailed Design of DeFaaS In this section, we describe the details of the main components of the system. 4.1 Decentralized Scheduling and Load Balancing Different from the conventional multi-cloud deployment of FaaS, DeFaaS avoids any centralized component as a front-end for scheduling API calls. A user can make API calls to any API gateway. The management blockchain can keep track of the reputation and support trust management of the gateway nodes. Each API gateway needs to be registered with the management blockchain. The system can require a minimal stake to be deposited for the gateway providers. To avoid fragmentation, the system can enforce certain policies like enforcing maximal number of gateways for each cloud, minimal setting of a gateway like types of instances, memory size and the number of vCPUs. To dispatch the API calls across cloud data centers, the system applies randomized load balancing (e.g., [Mitzenmacher(2001a)]) to avoid scenarios that all the API calls are sent to a single cloud provider. In randomized load balancing, when a gateway receives an API call, depending on the policy setting for the dApp or Web3 application, the gateway randomly routes the call to one of the available cloud service providers. For instance, the popular power of two heuristic [Mitzenmacher(2001b)] can achieve good performance with very low overhead. A unique characteristic of our design different from all the prior work in randomized load balancing is that scheduling outcome must be publicly verifiable. This is a fundamental difference between distributed system vs. decentralized system. To support public verification, randomization by the gateway nodes must use a random source that can be verified publicly. A simple approach is to use an on-chain random source like block hash. Using block hash like Bitcoin block hash as publicly verifiable random source is a common practice [Bonneau et al.(2015)]. In this work, gateway node applies block hash from a reference chain like Bitcoin or the management blockchain as the random source for randomized load balancing. Gateway providers are compensated based on the number of successfully handled API calls. To provide incentives for the gateway providers, payments to the gateways are weighted. This means that if the number of API calls handled by a gateway is skewed from the prediction based on the randomized load balancing and target distribution, its received payment will be reduced. As an example, for a dApp, the system may require all the calls be evenly distributed among three cloud providers. Gateway nodes that cheat the system can be punished, for instance receiving negative payment for the handled API calls that exceed a limit. Scheduling policies are recorded on the management blockchain. Depending on the utility of the use cases, scheduling policies can be configured to achieve proper trade-offs among requirements such as decentralization, cost, performance. For instance, policies prioritizing decentralization may reward distribution of the API calls to multiple clouds. To provide scheduling assistance, the system employs Oracle providers who send gateway load data feed to the management blockchain. The Oracle providers estimate gateway load by sending testing API calls and measure performance metrics like the completion time. It is important to mention that the API gateways only query the management blockchain periodically to read other gateways’ load status. The gateway load status is cached locally and used for randomized load balancing. There is no on-chain update for viewing gateway load status. Authors: (1) Rabimba Karanjai, Department of Computer Science, University of Houston (rkaranjai@uh.edu); (2) Lei Xu, Department of Computer Science, Kent State University; (3) Lin Chen, Department of Computer Science, Texas Texh University; (4) Nour Diallo, Department of Computer Science, University Of Houston; (5) Weidong Shi, Department of Computer Science, University Of Houston. Authors: Authors: (1) Rabimba Karanjai, Department of Computer Science, University of Houston (rkaranjai@uh.edu); (2) Lei Xu, Department of Computer Science, Kent State University; (3) Lin Chen, Department of Computer Science, Texas Texh University; (4) Nour Diallo, Department of Computer Science, University Of Houston; (5) Weidong Shi, Department of Computer Science, University Of Houston. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Understanding Decentralized Event Distribution

What is DeFaaS? A New Framework for Web3 Apps in the Cloud

Blockchainize.TECH

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

How DeFaaS Uses Randomized Load Balancing for Decentralized API Calls

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Optimizing NFT Experiences: Insights from Performance & Usability Studies

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

Optimizing NFT Experiences: Insights from Performance & Usability Studies

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps