【论文笔记04】Model-driven approach for the design of multi-chainsmart contracts—用于设计多链智能合约的模型驱动方法

A. Barišić, E. Zhu and F. Mallet, "Model-driven approach for the design of Multi-Chain Smart Contracts," 2021 3rd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS), 2021, pp. 37-38, doi: 10.1109/BRAINS52497.2021.9569809.

原文作者：A. Barišić, E. Zhu and F. Mallet*
原文标题：Model-driven approach for the design of Multi-Chain Smart Contracts*
原文链接：https://ieeexplore.ieee.org/document/9569809
原文来源： BRAINS 2021
笔记作者：quangaoyuan
笔记小编：quangaoyuan

0x00 关键词

多链、智能合约、模型驱动工程、形式验证

0x01 摘要

基于区块链的智能合约在广泛的服务中提供透明的自动化，包括金融、物联网和自治系统。但是，此类服务的实现很容易涉及安全风险和功能错误，尤其是对于由不同区块链组成的复杂服务。为了帮助开发人员专注于他们的业务模型，而不是深入研究区块链架构的异构性，我们提出了一个框架，可以在部署之前对组合服务进行分析和比较。这是通过大量使用基于模型的工程实现的，允许在生成具体部署工件之前对模型进行推理，特别是对于合约调用事务的安全编排。

0x02 INTRODUCTION

作为驻留在分布式账本 [1] 上特定地址的一段可执行代码，基于区块链的智能合约允许在不信任的实体之间不可逆地执行透明交易。以物联网场景为例，智能合约可用于自动化数据共享、设备所有权转移、用户注册、证书部署和撤销等。智能合约还可以实现加密货币作为激励，有助于创建数字市场跨多个系统交易资源，例如智能电网、运输系统和物流网络.

整个生态系统包括具有不同行为保证的利益相关者。为了在容错能力和交易速度之间进行权衡，鼓励开发者使用不同的区块链来解决相应的利益相关者。但是，它们交互的结果并不像单个链上的交易那样明确定义。为了给组合服务提供额外的保证，使用了模型驱动工程（MDE）。 MDE 提供了显式模型，通常称为“一流工件”，这些模型可以进一步转换为具有更多细节的较低级别模型。由于其快速原型、模拟、验证和验证能力，这种方法被用于解决大规模软件工程问题。此类模型通过不同的领域特定建模语言 (DSML) [2] 表示。

MDE 在生成用于部署的具体工件之前对模型进行推理，包括服务的编排和区块链技术的规范。通过拥有适当的 DSML，我们可以为创建在给定的多链后端上运行的合约的服务级别语义，在此基础上，可以通过在适当的抽象级别启用模拟来正式验证一些安全性和时间属性。

0x03 相关工作

在单链场景下，业务模型翻译和智能合约验证分别进行了探索。以金融应用为例，数字资产建模语言（DAML）1用于资产管理逻辑描述，提供更高抽象层次的解决方案。但是，这种方法缺乏验证功能的集成。在验证方面，Tezos 区块链 [3] 已经在协议设计阶段和代码实现阶段考虑了形式验证问题。属性是从虚拟机代码中提取的，并提供给像 Coq [4] 这样的定理证明器。对于没有这种特性的其他区块链项目，额外的形式化框架，如 Kframework [5] 和状态机抽象提供了形式语义。

有研究致力于使用 MDE [6] 生成基于以太坊的智能合约，甚至通过从自然语言模型生成代码 [7]。 FSolidM 就是这样一种解决方案，它提供了正式的定义来解决诸如重入和事务排序之类的漏洞，并支持诸如时间约束和授权之类的设计模式 [8]。因此，它通过为验证提供支持，为开发人员提供了一种制定智能合约的新方法，但商业模式仍然与 Solidity 实施紧密相关。

在多链场景下，已经提出了几种跨区块链应用框架，但它们的通信成本并不明确[9]。 BlockSY 2 提出了一种与技术无关的 Web 服务，以轻松更改底层区块链。虽然它处理句法适应，但它没有明确定义交易的预期语义，并且紧密依赖于底层区块链之一。

0x04 多链智能合约的开发

我们假设整个业务逻辑是基于一个工作流的。该工作流程的每个步骤在不同的区块链中以库的形式都有一组实现。当前的跨区块链交互模型是简单的消息传递，没有状态同步。

我们方法的目标是明智地重用在不同区块链中实现的现有库，并明确指定和分析生成的组合智能合约的行为。我们需要在不同的区块链上编排步骤，同时确保生成的智能合约满足预期的属性。当可能有多个有效的编排时，我们选择优化非功能属性的一个，例如执行时间或气体消耗。

我们的方法由具有综合阶段的三层框架表示。最上层是关于服务设计的，包括三个要素：业务模型的工作流程、每一步的规范、业务模型的规范。底层是一组候选区块链平台，托管库以实现上述工作流程的每个步骤。中间层是将每个步骤映射到一个区块链平台上所选库中的相应函数的配置。我们使用三个 DSML 分别描述抽象行为（工作流程）、属性（业务模型规范）和配置（步骤功能映射）。整个服务基于由选定区块链托管的智能合约，该合约调用部署在其他区块链上的库中的功能。该智能合约预计将由抽象行为、配置和公认的跨区块链上下文解析规则生成。

假设配置中选择的功能是通过单链验证方法证明的，一旦工作流的控制逻辑得到形式上的证明，整个服务的生成工件将满足业务模型规范。

我们的方法依赖于 GeMoC 工作室 [10]，这是一种基于 Eclipse 的语言和建模工作台。该框架提供了一个通用接口来汇集多个 DSML 并描述它们协调的语义。它允许为每种特定的元语言插入不同的执行引擎。我们开发了几种具体的语法来指定智能合约、库和部署配置的模型实例。

为了分析综合服务行为，我们可以使用 GeMoC 工具进行仿真、模型检查、调试和运行时验证。 GeMoC 还支持从应用于每个 DSML 的一组模式生成完整的语义模型。这个语义模型是使用时钟来描述的约束规范语言（CCSL），为进行详尽的验证提供正式支持[11]。

我们的方法开启了在智能合约之上引入新功能的可能性，这些新功能可以由第三方定义。一种可能的应用是添加用于定义法律条款的特定语言，这些法律条款可用于在运行时对智能合约进行治理。例如，我们可以引入诸如终止合同或在现有合同条款中添加附录等概念。另一方面，明确定义了合约行为，就可以提供一个模拟环境来在运行时监控合约。

0x05 结论

这项工作为解决多链智能合约设计的可靠性问题提供了一个框架。虽然代码生成部分还没有完成，但我们构建了一些自动支持来描述合约的行为并协调交易的执行。主要贡献是使用模型驱动方法创建了多链交互模型的服务组合语义，可以将其转移到现有的验证工具中。