This work assumes that dApp and Web3 software is hosted in multi-cloud data centers. The targeted environment focuses on off-chain applications, for instance, off-chain Oracle applications, and light-weighted applications executed off-chain in Web3. This means that services like blockchain as a service (BaaS) or validator as a service (VaaS) are outside the scope of this work. Furthermore, we assume that dApp and Web3 applications can be executed by container-based FaaS. In the future, the framework can be extended to support broad backend services like virtual machine instances. We further make the assumption that the services are invoked using API calls through API gateways. After invoked, execution of a dApp may create blockchain transactions, for instance, update on-chain state/states. However, it is not required that each time, a function is invoked, it must involve any on-chain interaction. One dApp may trigger execution of other dApp functions. A dApp or Web3 application may be triggered by on-chain state update, for instance, run a Web3 function after an on-chain payment is confirmed. For dApp and Web3 applications, IAM is based on blockchain identities. This means that if execution of a function requires authorization, access control is based on blockchain wallet accounts. The environment aims to support dApp and Web3 applications in a multi-blockchain context. We assume the existence of cross-chain bridges for sharing states and exchanging digital assets across blockchains (e.g., [Robinson(2021)]) like cross-chain billing for services (e.g., [Herlihy(2018), Pillai et al.(2022)]). The cross-chain bridges are assumed to be secure[2]. There exists trust management scheme for the ecosystem. For instance, stake using tokens may be required for the dApp/Web3 service providers (e.g., API gateway service provider, dApp provider) in the environment. If a service provider misbehaves, its stake may be slashed. Cloud providers are assumed to be somewhat trusted, which means that they will mostly abide by the service level agreements. Cloud providers will not act maliciously and attack the hosted dApp or Web3 applications like launching denial of service attacks. Although this work focuses on multi-cloud setting, the work can be extended in future to a hybrid environment comprising both multi-cloud data centers and user contributed computing resources (a topic of future research).

3.2 Overall Architecture of DeFaaS

Figure 1 provides an overview of the system architecture. The framework avoids centralized component, and is fully decentralized in the sense that there is no single entity that can control a major component of the system. Management is achieved using a specific blockchain. At high level, the exact nature of this blockchain, for instance type of consensus protocol, supported smart contract languages, is irrelevant because one can imagine different implementations to match specific requirements in certain contexts. We assume the existence of a management blockchain. This management blockchain connects to other blockchains using cross-chain bridges for enabling multi-chain support such that dApp and Web3 applications based on different blockchains can be managed by this single management blockchain. Under this framework, a dApp or Web3 function can be invoked by users from multiple blockchains. This management blockchain is also responsible for billing. It accumulates bills for each user. After a period of time, it can send a billing request to the corresponding blockchain to charge the users for the services. For instance, if a user is affiliated with blockchain A and the user has accumulated a total bill of $100 (say billed in stable coins) in a week. The management chain can use the cross-chain bridge and cross-chain transactions to charge the user on blockchain A.

\ The framework supports a network of API gateways hosted in a multi-cloud setting. API gateways are decentralized. The system may require gateway providers to be stake holders. In case that a gateway provider is malicious, its stake can be slashed. The mechanism is similar to how validators are managed in Proof-of-Stake blockchains. The gateway nodes form a distributed mesh network. API calls can be routed among the gateways.

\ dApps and Web3 applications are executed on-demand using containerized FaaS (function-as-a-service). There are many benefits using such infrastructure. Firstly, container-based FaaS is cloud agnostic, and achieves high portability. Secondly it is secure and agile with the strong isolation of containers. Thirdly, there is no need to plan node capacity and no need to manage server nodes. Fourthly, the system can easily scale out using container based scaling. Fifthly, there is no waste of resources because billing is pay-as-you-go based.

\ As illustrated in Figure 1, the management blockchain offers the main services like API end-point registration, identity management, interoperability support between cloud and blockchain, access control and authorization for the API calls, billing management, policy management, support for monitoring and logging (see details in the next section). At the end, it is worth mentioning that the design does not hold any assumption on the hosting environment of the management blockchain itself.

3.3 Prototype Components of DeFaaS

In this specific work, we choose Hyperledger Besu [Besu([n. d.])] as the management blockchain. It is important to highlight that the overall design is not restricted to Besu or Hyperledger. Besu supports EVM and smart contracts. It can be applied for both public and private blockchain network use cases. For FaaS, we use OpenFaaS [OpenFaaS([n. d.])]. There are many platforms for FaaS and serverless computing (e.g., [OpenWhisk([n. d.]), Kubeless([n. d.]), Fission([n. d.])]). OpenFaaS is selected for demonstration purposes. This means that our framework does not exclude the adoption of other FaaS platforms. OpenFaaS supports containerized FaaS using Kubernetes. It is easy for the developers to deploy event-driven functions and microservices to multi-cloud using OpenFaaS. Applications can be packaged in an OCI-compatible image for deployment. The platform is extensible and customizable. Endpoints are highly scalable with auto-scaling.

:::info Authors:

(1) Rabimba Karanjai, Department of Computer Science, University of Houston ([email protected]);

(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.

:::

:::info This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license.

:::

[2] Cross-chain bridge security is a research topic of its own, and this work assumes that developers of the bridges have taken necessary steps to protect the bridges and the bridge code has been rigorously audited for security.

Feed: Hacker Noon - Medium

View: Original article

Tags: api application applications blockchain decentralized digital distribution framework management