Understanding Decentralized Event Distribution

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.2 Decentralized Event Distribution

Event distribution is a critical element for a FaaS platform, including DeFaaS. It needs particular care in a multi-cloud setting because cloud dependent event mechanism for FaaS (e.g. [Amazon([n. d.])]) is not portable to the multi-cloud environment. Existing approaches to allow functions to consume events from different event sources on multiple clouds (e.g. [TriggerMesh([n. d.]), Knative([n. d.])]) are not designed for Web3 or dApp applications. In another word, although they can support cloud agnostic event sources/event consumers, they are not designed for decentralization.

In this work, we use GossipSub [Vyzovitis et al.(2020b)] to build the event distribution system for dApps and Web3 applications. GossipSub is a robust message propagation system adopted by several important blockchain systems including Filecoin and ETH2.0 Network, and it works in the publish-subscribe mode that relies on a mesh network structure and a score function [Baldoni et al.(2007)] to disseminate messages. GossipSub builds on top of floodsub, which is a basic version of the PublishSubscribe system that is used in IPFS and Libp2p. It works by sending messages to all nodes in a network, rather than using a more efficient method called CastTree forming [libp2p(2022a)]. FloodSub is sometimes referred to as DumbSub or PubSub-Flood.

The mesh network structure allows any node to participate in the message dissemination process, and the score function controls the transmission of messages based on the behavior of individual nodes. The features of GossipSub makes it a suitable tool for DeFaaS to manage events distribution in a decentralized manner across multiple cloud service providers.

Support for function triggers can be implemented as a connector module in OpenFaaS. OpenFaaS is flexible enough to support multiple event trigger sources including third party event sources. In addition, after receiving a triggering event, function can be invoked. GossipSub connector is a module that maps topic based events to the registered functions in OpenFaaS.

Nodes in the network can connect to each other in two ways: by sending complete messages to sparsely connected nodes called mesh members, or by sharing metadata about the availability of messages. Nodes can switch between these two types of connections, known as pruning and grafting, as needed. GossipSub [Vyzovitis et al.(2020a)] is designed to be efficient and scalable, with any peer able to participate in the message dissemination process.

In addition to the mesh network and peering structure described previously, GossipSub also includes a system for scoring and limiting the transmission of messages based on the behavior of individual nodes. Nodes that do not reach a certain score threshold [libp2p(2022b)] will not receive messages. Additionally, nodes can publish messages on topics that they are not subscribed to by sending the message to a small number of randomly selected nodes, called fan-out peers, which will then redistribute the message throughout the network[libp2p(2022c)]. The combination of these features makes GossipSub highly efficient, reliable, and resistant to attacks, and allows it to scale effectively [Vyzovitis et al.(2020a)].

4.3 API Registration and Access Control

API providers need to register API end-points to the management blockchain. Registration is done through smart contract with a map that associates API end-point with the API provider’s account. API end-points can be offered to the public. Alternatively, API end-points can be private (only accessible by certain wallet accounts). Access control policies can be created for each API end-point. The policies are stored as a map from the API end-point and wallet address to a boolean value of true. If the map can be found, it means that the access is permitted. Note that for public API end-points, there is no need to perform this verification. Query of access control setting only involves view of on-chain state. Listing 1 shows an example of API registration with permission setting using Solidity. Since blockchain and smart contract based access control management has been intensively studied in the last few years (e.g., [Liu et al.(2021), Yang et al.(2020), Maesa et al.(2019), De and Ruj(2020), Almutairi et al.(2021)]), we skip details to save space and provide references for interested readers [Liu et al.(2021)].

4.4 OAuth2.0 Support

API gateways often apply common standard such as OAuth2.0 [Hardt(2012), Jones and Hardt(2012)] and OpenID [Sakimura et al.(2014)] to enable authentication to services and applications. OAuth2.0 [Hardt(2012), Jones and Hardt(2012)] is the industry-standard protocol for authorization through which an client obtains an access token from an authorization server, to access a protected resource, stored in a resource server. OAuth 2.0 has received widespread adoption by the cloud providers. It supports delegation and interoperability, and facilitates access control management.

To support authorization for API calls, our platform comprises element to enable interoperability between blockchain based authorization and the API gateways using OAuth2.0 access tokens. For this objective, we take advantages of the existing research and prior work that attempt to integrate OAuth2.0 with smart contract and blockchains [Cha et al.(2021), Fotiou et al.(2020)]. Our implementation is based on [Fotiou et al.(2020)] and OpenFaaS plugin support for authentication. At high level, the workflow is the following. After verifying a client’s permission to access an API end-point, smart contract can generate an ERC token (ERC-721) and OAuth2.0 access token [Jones et al.(2015)]. The ERC token is transferred to the client’s wallet account, and the access token is provided to the client. Then, the client can request access to the API end-point providing the access token. The gateway node can retrieve the corresponding ERC-721 token which is used for verifying the validity and the ownership of the access token. If the verifications are successful, the gateway node will route the API call to the targeted function and return the response. In context of OpenFaaS, verification can be implemented as a plugin. Access tokens have expiration time. This reduces the overall performance impact of the described design.