FBaaS：功能区块链即服务
摘要
无服务器架构在过去三年中越来越受欢迎。函数即服务（FaaS） 是无服务器架构的一种具体实现，具有多种优势和特性。本文提出一种基于FaaS模型的新服务模式，命名为FBaaS——功能区块链即服务。与区块链即服务（BaaS）相比，FBaaS在顶层业务逻辑的实现上更为轻量，带来了一系列优势：首先，它可以提高区块链的运行速度；其次，由于其分层架构，底层FaaS网络在高鲁棒性和高可用性方面的持续进步可自然地应用于FBaaS；第三，FaaS实现了更简洁的业务逻辑高层次抽象。此外，本文提出了一种用于实现联盟链业务逻辑的抽象方法，可进一步提升性能。本文还详细展开一个具体的实例网络，即为2018年服务计算会议联合会 （SCF）设计的会议区块链网络。
1 引言
无服务器架构[6,16]在过去的三年中越来越受欢迎。函数即服务（FaaS） [10,12]是无服务器架构的一种具体实现，具有多项优势和特点。本文提出了一 种基于FaaS模型的新服务模式，命名为FBaaS——功能区块链即服务。与传统 的区块链即服务（BaaS）相比，[8,9,11,13], FBaaS在顶层业务逻辑上实现了 更轻量的实现，带来了诸多直接优势。首先，它可以提高区块链的运行速度。其次，由于其分层架构，底层FaaS网络所具备的高鲁棒性和高可用性优势可以 自然地应用于FBaaS。第三，FaaS对逻辑实现了更高层次的抽象，使得逻辑更 加简洁[12]。本文提出了一种在联盟链业务逻辑实现中的抽象方法，可进一步 提升整体性能。本文还展开介绍了一个具体示例网络的详细设计，即服务于服 务计算会议联合会（SCF）的会议区块链网络 2018[14]。未来，所提出的技术可以部分应用于公有链，例如 [13]。本文组织如下：第2节介绍无服务器架构的概念。第3节简要介绍区块链即 服务（BaaS）。第4节阐述所提出的功能区块链即服务（FBaaS）的理念。第 5节总结全文并概述一些未来研究方向。
2 无服务器
DevOps（开发与运维）和无服务器架构在过去三年中越来越受欢迎[6,10,12]。特别是，微服务架构显著推动了DevOps的发展。微服务架构有助于将单体应 用拆分为多个更小的服务，这些服务是自治的，并且可以由小型开发团队轻松 开发和维护。无服务器架构[6,12]相比微服务架构对服务进行了更细粒度的划 分，为应用程序带来了四重优势（图1）：
– 它降低了成本。无服务器产生的功能模块比单体应用和微服务更小，通过仅 按需分配资源的方式，减少了大型功能模块的开销。
– 它加速了执行。由于服务被划分为更小的函数，只有在运行时需要的函数才 会被调用。那些不必要的函数可以完全停止，而不是占用资源的待机状态。
– 它能够提供更好的弹性。较小的区块意味着较短的启动时间，从而更快地响 应调用方。此外，由于开销更小，资源分配可以更加灵活和高效。
– 它支持事件驱动应用。无服务器实际上是一种IPO（输入‐处理‐输出）模型， 适用于事件驱动应用，例如物联网应用。无服务器架构中的功能模块仅在真正 需要时才会被触发，在调用者不再请求其能力后会立即被销毁。换句话说，该 函数的生命周期比单体架构和微服务架构更短。因此，事件驱动应用可以利用 更轻量级的框架（如无服务器）实现更加敏捷的执行。
3 区块链即服务
区块链即服务（BaaS） [8,9,11,13]提供对区块链的操作以及在区块链网络上 构建、部署和运行业务逻辑的服务。知名的解决方案包括但不限于 IBM区块链 [8], Azure上的以太坊区块链 [13],微软Azure区块链 [11]和 R3 Corda [9]。尽管许多供应商提供了不同的区块链即服务，但现有解决方案主要采用传统的 三层云架构：基础设施即服务、平台即服务和软件即服务。本文提出了一种与 传统区块链即服务显著不同的功能区块链即服务（FBaaS）。
4 功能区块链即服务
本节详细提出功能区块链即服务（FBaaS），通过展开其架构、实现过程和一 个具体的示例网络来说明。图2展示了详细的FBaaS架构。
4.1 架构
功能区块链即服务（FBaaS）的底层架构部分遵循CCOA的理念 [17],但不包含 企业服务总线（ESB） [15]。更具体地说，该系统是根据大数据开放架构（ BDOA）实现的 [7]。在FBaaS的实现中已开发和部署的BDOA层包括：
– 第一层：基础设施层，实现了FBaaS的第一层和第二层。该系统构建于亚马 逊云科技（AWS）之上，未使用任何亚马逊Lambda函数，仅使用了弹性计算 云（EC2）等常规组件。换句话说，我们并未采用亚马逊云科技（AWS）提供 的无服务器框架或函数即服务。
– 第二层：组件层，实现了FBaaS的第三层。基本功能在此层内实现。例如，身份验证功能和授权功能在此开发，以便在上层中频繁复用。
– 第三层：服务层，由FBaaS的第四层和第五层实现。该层实现了区块链即服 务的大部分功能。我们将在后面展开详细说明。
– 第四层：业务逻辑层，在图 2中由应用程序和大规模服务实现。通过将第三层的功能进行分组，我们可以 轻松地建立区块链以及复杂的 大规模服务。
4.2 服务层中的功能
功能1：对象存储。
对象存储具有强原子性，这意味着整个对象存储过程要么成功，要么失败，在存储过程中不存在中间或不确定状态。同时，上传的对象是 完整的，不允许断点续传上传。这种对象存储方案的强一致性为用户带来了极 大的便利。用户无需担心分布式区块链网络中存在的最终一致性问题（图3）。
Function: 新交易。
该功能将交易内容添加到一个新区块中，随后该区块将被 加密并被挖出。对于交易内容没有限制，但为了存储考虑，最好设定一个限制。此外，最好对内容进行抽象，我们将在本文的后续部分展开详细说明。
功能：挖矿。
挖出一个区块实际上是一个简单的枚举和哈希过程。为了加速挖 矿过程，可以应用CUDA [2]英伟达GPU。在函数即服务（FaaS）的背景下， 直接应用较为困难。我们引入了消息系统Kafka[3]以极快的方式分发哈希需求， 而不是采用传统方法。通常情况下，其性能相比CPU哈希方法最高可达40倍。
功能：链信息。
区块链信息可通过此功能获取。典型数据包括区块数量和区块 链长度。需要强调的是，此处的长度代表众多未被挖出的链中唯一已认证的链。
Function: 解决.
解决函数通过运行一致性算法来尝试解决冲突，旨在确保所 有节点都拥有唯一正确的链。
功能：添加节点。
使用传统解决方案添加节点较为复杂。然而，在函数即服务 （FaaS）的帮助下，我们可以轻松地向现有网络中添加节点。首先，我们将当 前状态保存到持久化存储中。然后，通过容器即服务（CaaS）的复制功能复制 一个节点。随后，通过调整副本节点的配置文件来完成新节点的配置。最后，从持久化存储中恢复状态，并继续执行网络。添加节点的性能取决于现有网络 的规模。网络操作（例如复制节点）本身耗时不多，有时甚至可以忽略不计。大部分时间消耗在存储和恢复系统状态的子过程中。
4.3 实现
函数服务器。
系统使用Python和Go语言实现。Python用于顶层框架以及函数 内部的逻辑，这些逻辑需要被频繁且同时调用。而函数服务器和容器即服务层 则使用Go语言实现。我们在OpenFaaS[12]的模块API网关和函数看门狗基础上 进行开发，如图4所示，其中基于角色的访问控制（RBAC）服务器用于函数的 身份认证和授权。将RBAC实现在函数服务器层会增加系统的复杂性并降低性 能，因为每次函数调用过程都需要进行检查。然而，这种方案允许系统管理员 限制来自内部系统的异常违规调用。一个典型场景是短消息服务。如果RBAC 仅存在于API网关中，一旦函数被黑客攻击，消息发送将无法控制。相反，在 函数服务器中实现RBAC可以仅阻止其应用服务器包含被攻击函数的用户，而 允许具有相同功能但不同授权的其他函数继续运行。
更细粒度的函数即服务。
微服务提供的功能比单体系统更少，但从另一方面来看， 它为所提供的服务提供了更高层次的抽象。将微服务分解为多个函数具有相似性， 其中函数即服务（FaaS）通常被视为具有最终级别抽象的形式。在 FaaS 之上，我 们能否实现一个具有更细粒度的新层级？确切的答案是将 FaaS 的某些组件冻结为 常量。形式上，我们可以将函数 λ 定义为微服务 μ 某一部分的抽象。
$$
λ = \\text{abs}(μ(α, δ)) \\quad (1)
$$
α表示变量部分，其中 δ表示常量部分。当我们冻结 δ时，函数变得更简 单，其抽象程度可以进一步提高。在实现过程中，我们可以引入一些预定义的 函数来模拟这些常量部分。在图5中，函数即服务以灰色显示，并通过引入 IFTTT [4]和 Zapier [5]对其进行进一步分解。这种分解方式产生了更细的粒度， 并提高了函数即服务的抽象程度。
通过逻辑抽象提升性能。
在规则简单的情况下，如果向节点提交复杂的交易， 并且在高并发情况下，联盟链（如Hyperledger Fabric）的速度会非常慢，这 将影响交易记录速度和区块生成速度。如果我们通过分配复杂规则来降低交易 提交频率，则可以在一定程度上有效提高交易速度。例如，我们可以改变生成 区块的时间段以及一个区块内容的大小。形式上，我们通过逻辑抽象方法将业 务系统中的复杂事务抽象为简单的逻辑，从而提高系统性能。这种性能提升本 质上是通过减少记录内容的数量实现的，此时的内容已经是实际内容的逻辑抽 象。需要注意的是，真实状态空间与抽象状态空间首先满足伽罗瓦连接：
$$
η(θ(\\text{abs})) = \\text{abs} \\quad \\theta(η(\\text{real})) ⊃ \\text{real} \\quad (2)
$$
这意味着，如果我们从抽象空间中提取一个元素，将其具体化，然后再对这个 具体版本进行抽象，结果等于原始元素。另一方面，如果从真实空间中选择一 个元素并抽象出一个特定的抽象版本，最终结果是原始的超集。具体的抽象过 程如图6所示。原始逻辑若不进行抽象，则按照原始逻辑（虚线）流程执行。实 线表示新流程。首先，对输入逻辑进行形式化评审，以确保其形式正确，符合 交易应具备的特征。然后进行抽象规则匹配。抽象规则主要包括以下类型：
– 仅记录事物的最后一个操作对象；
– 仅记录操作的第一个对象；
– 仅记录 奇数次（或偶数次）原子级操作对象；
– 仅记录创建和删除操作；
– 仅记录 关键数据对象的更新操作；
– 仅记录汇聚数据对象以及受整体系统服务接口 API暴露接口影响的路径；
– 仅记录服务接口API中关键数据对象的变化，即 通过记忆状态来记录变更。
4.4 一个示例网络
图7展示了会议区块链的示例网络。该区块链网络由五个节点组成，每个节点 记录从“征稿启事”（“CFP”）到“上线”的整个流程。一旦某个阶段的记 录（例如“展示”过程中的论文展示）被标记，该记录将被发布到所有节点。在整个网络中，所有记录最终将达到最终一致性。我们将所提出的方法应用于 该网络，对该网络进行了基准测试，发现其性能满足会议区块链的需求，其中 原始要求的每秒事务处理量通常小于10。
函数即服务架构减少了开销，使开发者能够专注于业务逻辑。例如在会议 区块链中，通过使用函数即服务，我们能够集中于6个业务逻辑阶段，即“征稿 启事”、“评审”、“录用”、“终稿”、“展示”和“上线”，而无需关心 底层复杂组件。通常在传统区块链即服务解决方案中，实际瓶颈往往出现在网 络传输上，我们必须考虑网络本身。通过利用功能区块链即服务，随着底层 FBaaS依赖组件的进步，性能可以自然得到提升。
5 结论
本文首次提出了基于无服务器架构的功能区块链即服务（FBaaS）区块链服务 模型。我们还提出了一种抽象方法，以降低在区块链网络上开发业务逻辑的复 杂性，并提升其性能。所提出的FBaaS不仅适用于联盟链，也可部分适用于公 有区块链。在公有区块链上应用时可能出现的问题源于存储过大，这有望通过 进一步改进的抽象技术加以改善。因此，未来的研究方向包括为公有区块链开 发FBaaS，以及进一步优化抽象技术。
