基于RegLang的区块链监管合约构建方法和区块链系统

摘要

本发明提供一种基于RegLang的区块链监管合约构建方法和区块链系统，涉及区块链技术领域。该方法通过RegLang语言定义监管规则对应的监管合约的表达形式，以及监管合约的执行过程，以实现监管规则在区块链系统上的数字化表达；监管合约通过RegLang语言编写，包括多个知识库代码块和规则代码块，每个监管合约包括任意个知识库代码块和任意个规则代码块；每个知识库代码块中包括多个知识，在知识库代码块中定义的知识能够在规则代码块中使用，每个规则代码块描述一条监管规则；区块链系统在现有的区块链基础上，支持业务合约和监管合约的运行，以实现通过监管合约对业务合约进行实时监管。

说明书

技术领域

本发明涉及区块链技术领域，尤其涉及基于RegLang的区块链监管合约构建方法和区块链系统。

背景技术

监管规则数字化是监管科技需要解决的核心技术问题之一，是实现监管科技应用的重要基础。数字化的监管规则是以技术标准和代码协议为基本框架，用以约束监管行为和规范被监管对象合规行为的技术规范，在一定程度上具备法律规制的功能。由于区块链具有信息共享、不可篡改、透明可信等特点，并且区块链上的智能合约能够自动执行，因此区块链能够成为监管科技的最佳实现方式之一。一方面区块链可作为监管部门与被监管对象之间的数据共享交换平台，另一方面智能合约是监管规则数字化的最佳载体，监管部门可以利用智能合约对金融业务进行有效监管，提升监管的实时性和穿透性。

英国金融行为监管局(Financial Conduct Authority，FCA)在2017年启动了数字监管报告(Digital Regulatory Reporting，DRR)项目，旨在探索如何通过创建机器可读规则和机器可执行规则来简化监管报告过程，使监管报告过程高效、简洁、自动化。DRR项目提出要通过领域特定语言实现监管规则的数字化，并且设计了一种原型语言UmLang用于探索监管规则语言所需要的关键特性。FCA和伦敦大学学院合作开展了面向数字化监管与合规的区块链关键技术研究项目(Blockchain technology for Algorithmic Regulation AndCompliance，BARAC)，提出在区块链上利用Python等编程语言编写智能合约实现监管规则的数字化，通过自动执行的数字化监管规则帮助监管部门提高监管的效率、可靠性和透明性，降低金融企业的合规成本。以太坊为了让企业能够在不违反美国证券交易委员会监管要求的基础上发行证券型代币，提出了ERC 1400系列标准，要求代币在转账之前需要通过指定函数的验证，通过特定函数向监管机构提供必要的信息和功能。然而，通过智能合约实现监管规则数字化的研究目前仍然处于初步阶段，利用智能合约实施监管尚未得到广泛应用，主要面临以下挑战：

(1)面向监管的智能合约编程语言的设计。现有的智能合约编程语言主要为实现任意业务逻辑而设计，通常是图灵完备的通用语言，这些语言大多具有较高的使用门槛，难以实际应用中监管科技领域。虽然研究人员提出了一些领域特定语言的设计方案，但是主要是面向金融业务进行设计，不适合编写监管规则。而现有的建模语言等适合于监管与合规应用的编程语言也难以引入到区块链中，无法利用现有语言在区块链上编写监管合约。

(2)监管合约的运行机制。通过面向监管的智能合约编程语言能够实现数字化的监管规则，使监管规则以监管合约的形式运行在区块链上。但是仍然需要对监管合约的运行机制进行研究，包括监管合约的执行方式、监管合约与业务合约的交互模式、监管区块链架构等。

发明内容

本发明要解决的技术问题是针对上述现有技术的不足，提供一种基于RegLang的区块链监管合约构建方法和区块链系统，利用区块链构建监管合约，实现监管规则数字化，对业务合约进行实时监管的目的。

为解决上述技术问题，本发明所采取的技术方案是：一方面，本发明提供基于RegLang的区块链监管合约构建方法，定义监管规则对应的监管合约的表达形式，以及监管合约的执行过程，以实现监管规则在区块链系统上的数字化表达；

所述监管规则对应的监管合约的表达形式为：监管合约通过RegLang语言编写，包括多个知识库代码块和规则代码块，每个监管合约包括任意个知识库代码块和任意个规则代码块；每个知识库代码块或规则代码块以关键字knowledgebase或rule以及名称开头，以关键字end结尾；每个知识库代码块中包括多个知识，在知识库代码块中定义的知识能够在规则代码块中使用；每个规则代码块描述一条监管规则，包括一个以reg开头，冒号结尾的监管范围语句和任意个监管规则语句；每个监管规则语句的内容除关键字外为一个逻辑表达式；逻辑表达式的值决定监管规则语句及监管范围语句的真或假，进而确定监管规则的值；

所述监管规则语句分为以require关键字开头的强制性监管规则语句和以prohibit关键字开头的禁止性监管规则语句；当监管规则语句的逻辑表达式的值为真时，监管范围语句的值为真；当逻辑表达式的值为假时，监管范围语句的值为假；当逻辑表达式的值为真时，强制性监管规则语句的值为真；当逻辑表达式的值为假时，强制性监管规则语句的值为假；当逻辑表达式的值为假时，禁止性监管规则语句的值为真；当逻辑表达式的值为真时，禁止性监管规则语句的值为假；如果监管范围语句的值为假，则该监管规则的值为真；如果监管范围语句的值为真，则：如果所有监管规则语句的值为真，则该监管规则的值为真；如果有任意一个或以上的监管规则语句的值为假，则该监管规则的值为假；

所述RegLang语言的语法规则为：

所述RegLang语言支持基础数据类型，支持数值数组和字符串数组；RegLang支持算术运算符、成员运算符、比较运算符和逻辑运算符四类运算符；RegLang语言提供四组内置函数：(1)at_least()和at_most()：这两个函数用于计算数组中至少或至多有若干元素满足逻辑表达式，两个函数均有两个参数：第一个参数是一个数值，第二个参数是一个逻辑表达式，表达式的左侧必须是一个数组；(2)any_item()和all_items()：这两个函数计算数组中是否存在满足逻辑表达式的元素或者数组中是否任一元素都满足逻辑表达式，两个函数都只有一个参数，该参数是一个逻辑表达式，表达式的左侧必须是一个数组；(3)length()：该函数用于计算数组中元素的个数，函数只有一个数组类型的参数；(4)count()：该函数用于计算参数中表达式为真的个数，函数有任意数量的参数，每个参数都是一个逻辑表达式，函数返回表达式为真的个数；

所述监管合约的执行过程为：

步骤S1、将监管合约解析为抽象语法树；

步骤S2、分析业务合约的源代码，获得对应业务合约的存储布局，即业务合约中的变量在区块链状态数据库中实际存储时的键；

步骤S3、依次执行监管合约的每条规则代码块，验证业务合约的交易是否符合监管合约的要求，在监管合约执行过程中，如果需要读取业务合约的变量状态数据，则连接到区块链的状态数据库，根据步骤S2中业务合约的存储布局读取变量所对应键的值；

步骤S4、如果所有规则代码块的执行结果都为真，则监管合约的执行结果为真，业务合约的交易符合监管规则；如果有任意一条或以上规则代码块的执行结果为假，则监管合约的执行结果为假，业务合约的交易不符合监管规则。

另一方面，本发明还提供一种区块链系统，在现有的区块链基础上，支持业务合约和监管合约运行，以实现通过监管合约对业务合约进行实时监管；

所述区块链系统的用户包含普通用户和监管用户；所有用户均能部署业务合约，只有监管用户能够部署监管合约；业务合约通过Solidity或其他智能合约编程语言编写，部署方式为用户将业务合约的二进制代码以交易的形式发布到区块链系统中；监管合约通过RegLang编写，部署方式为监管用户将监管合约的源代码和监管合约绑定的业务合约地址以交易的形式发布到区块链系统中；具体地，一个监管合约能够与一个或多个业务合约绑定，不同监管合约能够同时绑定到相同的业务合约上。

所述区块链系统处理交易的流程为：

步骤1、普通用户向区块链节点发送交易，调用业务合约；

步骤2、区块链记账节点将交易打包成区块，广播给区块链系统中的所有节点，并完成区块链系统的共识过程；

步骤3、区块链节点根据交易中的参数执行业务合约，生成交易读写集；

步骤4、区块链节点调用该业务合约对应的监管合约，如果监管合约的执行结果为真，则将读写集写入区块链的状态数据库；否则将交易标记为无效，不改变区块链的状态数据库。

采用上述技术方案所产生的有益效果在于：本发明提供的基于RegLang的区块链监管合约构建方法和区块链系统，在区块链系统中引入了监管合约，并设计了一种新型的智能合约编程语言RegLang编写监管合约，能够使监管规则通过智能合约的形式进行数字化表达，使监管规则以监管合约的形式运行在区块链上，实现对业务合约交易的实时监管。

附图说明

图1为本发明实施例提供的RegLang的语法规则图；

图2为本发明实施例提供的区块链系统运行支持业务合约和监管合约的示意图；

图3为本发明实施例提供的Solidity业务合约实例图；

图4为本发明实施例提供的RegLang监管合约实例图；

图5为本发明实施例提供的普通用户调用业务合约的交易实例图；

图6为本发明实施例提供的业务合约交易读写集实例图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

本实施例中，基于RegLang的区块链监管合约构建方法，定义监管规则对应的监管合约的表达形式，以及监管合约的执行过程，以实现监管规则在区块链系统上的数字化表达；

所述监管规则对应的监管合约的表达形式为：监管合约通过RegLang语言编写，包括多个知识库(knowledgebase)代码块和规则(rule)代码块，每个监管合约包括任意个知识库代码块和任意个规则代码块；每个知识库代码块或规则代码块以关键字knowledgebase或rule以及名称开头，以关键字end结尾；每个知识库代码块中包括多个知识(knowledge)，在知识库代码块中定义的知识能够在规则代码块中使用；每个规则代码块描述一条监管规则，包括一个以reg开头，冒号结尾的监管范围语句和任意个监管规则语句(在监管范围语句之后，end之前，每行代码为一个监管规则语句)；每个监管规则语句的内容除关键字外为一个逻辑表达式；逻辑表达式的值决定监管规则语句及监管范围语句的真或假，进而确定监管规则的值；

所述监管规则语句分为以require关键字开头的强制性监管规则语句和以prohibit关键字开头的禁止性监管规则语句；当监管规则语句的逻辑表达式的值为真时，监管范围语句的值为真；当逻辑表达式的值为假时，监管范围语句的值为假；当逻辑表达式的值为真时，强制性监管规则语句的值为真；当逻辑表达式的值为假时，强制性监管规则语句的值为假；当逻辑表达式的值为假时，禁止性监管规则语句的值为真；当逻辑表达式的值为真时，禁止性监管规则语句的值为假；如果监管范围语句的值为假，则该监管规则的值为真；如果监管范围语句的值为真，则：如果所有监管规则语句的值为真，则该监管规则的值为真；如果有任意一个或以上的监管规则语句的值为假，则该监管规则的值为假；

本实施例中，RegLang语言的语法规则如图1所示，RegLang语言的源文件的扩展名为.rl。RegLang的源文件包含任意数量的知识库代码块和规则代码块。每个代码块以关键字knowledgebase或rule以及代码块的名称开头，以关键字end结尾。解释RegLang文件的顺序为首先解释所有知识库代码块，然后依次解析规则代码块。

每个知识库可以包括多个知识。知识的命名空间为所在的知识库，也就是说不同知识库中相同名称的知识是不同的。知识可以通过函数add()或del()进行更新，或者通过重定义进行覆盖。函数add()和del()可以接受数值、字符串和数组作为参数。当一个重复的值被添加到知识中，或者从知识中删除一个不存在的值，那么这个值会被跳过，不会导致知识的更新发生异常。与知识不同，同名的知识库会更新之前的知识库，而不是对其覆盖。

规则代码块维护所有的监管规则。一个规则必须包含一个监管范围和至少一条require或prohibit语句。当表达式的值为真时，require语句是被满足的；当表达式的值为假时，prohibit语句是被满足的。规则代码块的名称不是唯一的，两条具有相同名称的规则代码块都是有效的。一旦有一个规则语句未被满足，则不再计算其他的语句和规则。

同时，RegLang语言支持单行注释(//)和多行注释(/*...*/)。

RegLang语言支持数值、字符串、布尔值等基础数据类型，支持数值数组和字符串数组；RegLang是弱类型语言。监管专家在定义知识时不需要声明其类型，并且RegLang不提供类型转换函数。RegLang的数值只支持无符号整数，并且数值的长度是无限的。数值能够被赋值给一个知识，或者在规则语句中用作常量。RegLang的字符串由双引号("")包围。字符串是大小写不敏感的，即"ABC"、"abc"和"AbC"是相同的。字符串能够被赋值给一个知识，或者在规则语句中用作常量。RegLang的布尔值可以是true和false。布尔值能够被赋值给一个知识，或者在规则语句中用作常量。RegLang只支持数值数组和字符串数组，不支持混合数组。数组只能够被赋值给一个知识。RegLang中的知识与面向过程的编程语言和面向对象的编程语言中的变量类似。知识能够在知识库代码块中进行定义和更新，在规则代码块中使用。

RegLang语言也可以在规则代码块中使用区块链相关变量，包括事务相关变量(transaction-related variables)和合约相关变量(contract-related variables)。事务相关变量包括tx.from、tx.to、tx.function、tx.readset(xxx).yyy、tx.readset(xxx).yyy和tx.args.yyy，其中，xxx表示合约地址，yyy表示Solidity中的变量名。合约相关变量包括contract(xxx).name、contract(xxx).owner和contract(xxx).state.yyy，其中xxx表示合约地址，yyy表示Solidity中的变量名。

RegLang支持优先级从高到低的算术运算符、成员运算符、比较运算符和逻辑运算符四类运算符；

RegLang中的算术运算符能够接受字符串类型的数值作为参数，并且能够进行自动类型转换。RegLang支持十进制和十六进制的字符串(十六进制字符串必须以"0x"开头)，也就是说10+"0xa"+"10"是合法的。算术运算符是用来对数值执行常见数学运算的运算符。与Solidity中的算术运算符不同，由于RegLang中的数值长度没有限制，因此运算不会溢出。

RegLang不支持浮点数类型，因此RegLang中的除法是向下取整的整除(例如，5/3的结果是1)。RegLang不支持负数类型，因此如果减法的数学运算结果是负数，那么表达式的结果是0(例如1-2的结果是0)。

成员运算符in用作检查一个常量或者一个变量的值是否在一个知识中。运算符in的右侧必须是一个数组类型的知识。

比较运算符用于比较两个数值或者字符串。

与算术运算符相似，比较运算符也支持自动类型转换，即10＝＝"10"、10＝＝"0xa"和"10"＝＝"0xa"的结果都是true。RegLang中的字符串是大小写不敏感的，因此"abc"＝＝"ABC"的结果是true。

逻辑运算符用于组合逻辑表达式。因为多重否定通常使非开发人员困惑，所以RegLang不支持"not"作为运算符。取而代之的是，RegLang使用require语句和prohibit语句实现逻辑中的“非”，避免了否定词的深层嵌套，并使编写规则更加容易且不易出错。

除了以上运算符以外，为使编写规则更加方便和灵活，RegLang语言还提供四组内置函数：(1)at_least()和at_most()：这两个函数用于计算数组中至少或至多有若干元素满足逻辑表达式，两个函数均有两个参数：第一个参数是一个数值，第二个参数是一个逻辑表达式，表达式的左侧必须是一个数组；(2)any_item()和all_items()：这两个函数计算数组中是否存在满足逻辑表达式的元素或者数组中是否任一元素都满足逻辑表达式，两个函数都只有一个参数，该参数是一个逻辑表达式，表达式的左侧必须是一个数组；(3)length()：该函数用于计算数组中元素的个数，函数只有一个数组类型的参数；(4)count()：该函数用于计算参数中表达式为真的个数，函数有任意数量的参数，每个参数都是一个逻辑表达式，函数返回表达式为真的个数；

所述监管合约的执行过程为：

步骤S1、将监管合约解析为抽象语法树；

步骤S2、分析业务合约的源代码，获得对应业务合约的存储布局，即业务合约中的变量在区块链状态数据库中实际存储时的键(key)；

步骤S3、依次执行监管合约的每条规则代码块，验证业务合约的交易是否符合监管合约的要求，在监管合约执行过程中，如果需要读取业务合约的变量状态数据，则连接到区块链的状态数据库，根据步骤S2中业务合约的存储布局读取变量所对应键的值；

步骤S4、如果所有规则代码块的执行结果都为真，则监管合约的执行结果为真，业务合约的交易符合监管规则；如果有任意一条或以上规则代码块的执行结果为假，则监管合约的执行结果为假，业务合约的交易不符合监管规则。

一种区块链系统，在现有的区块链基础上，支持业务合约和监管合约运行，以实现通过监管合约对业务合约进行实时监管，如图2所示；

所述区块链系统的用户包含普通用户和监管用户；所有用户均能部署业务合约，只有监管用户能够部署监管合约；业务合约通过Solidity或其他智能合约编程语言编写，部署方式为用户将业务合约的二进制代码以交易的形式发布到区块链系统中；监管合约通过RegLang编写，部署方式为监管用户将监管合约的源代码和监管合约绑定的业务合约地址以交易的形式发布到区块链系统中；具体地，一个监管合约能够与一个或多个业务合约绑定，不同监管合约能够同时绑定到相同的业务合约上。

所述区块链系统处理交易的流程为：

步骤1、普通用户向区块链节点发送交易，调用业务合约；

步骤2、区块链记账节点将交易打包成区块，广播给区块链系统中的所有节点，并完成区块链系统的共识过程；

步骤3、区块链节点根据交易中的参数执行业务合约，生成交易读写集；

步骤4、区块链节点调用该业务合约对应的监管合约，如果监管合约的执行结果为真，则将读写集写入区块链的状态数据库；否则将交易标记为无效，不改变区块链的状态数据库。

本实施例中，如图3所示为一个通过Solidity编写的业务合约实例，其主要功能为定义一种资产，并支持转账、查询等功能。如图4所示为与该业务合约实例对应的一个通过RegLang编写的监管合约实例，该实例中的前三行代码在black知识库中添加了一条知识blacklist，其他代码创建了一条规则CheckTransfer。在规则部分，第6行表示调用EIP20合约中transfer函数的事务会被检查；第7行是一条强制性监管规则语句，表示监管规则要求事务参数_value的值应不大于1000000；第8行是一条禁止性语句，表示如果事务的发起方或转账的接收方在黑名单中，事务就会被监管合约拒绝。

下面结合用户调用业务合约的一个实例对区块链系统处理交易的流程和监管合约的执行过程进行说明。在本实例中，普通用户的区块链地址为0x5929EBA30850986dE6F93397A86f9B80901896e8，在区块链上部署的业务合约地址为0x50C8B0AF204B87AAA1e393c8a8dd9c2B0750B0C7。该用户在发起智能合约调用前具有1000000个数字资产，即业务合约中balances[0x5929EBA30850986dE6F93397A86f9B80901896e8]＝1000000。

本实施例中，区块链系统处理交易的过程为：

步骤1、普通用户向区块链节点发送如图5所示的交易，调用如图3所示的业务合约，即将账户0x5929EBA30850986dE6F93397A86f9B80901896e8的数字资产中的10000个转移给账户0x84C7768aC1Cd6d07FCA1e2BC4C3551510F6E4ABC；

步骤2、区块链记账节点将交易打包成区块，广播给区块链系统中的所有节点，并完成区块链系统的共识过程；

步骤3、区块链节点根据如图5所示的交易中的参数执行业务合约，生成交易读写集，如图6所示；

步骤4、区块链节点调用如图4所示的监管合约，监管合约的执行结果为真，将读写集写入区块链的状态数据库。

其中，步骤4中监管合约的执行过程如下：

步骤S1、将如图4所示的监管合约解析为抽象语法树；

步骤S2、分析业务合约的源代码，获得对应业务合约的存储布局，即业务合约中的变量在区块链状态数据库中实际存储时的键(key)，其中balances[0x5929EBA30850986dE6F93397A86f9B80901896e8]对应的键为0xb25d917326bbb11780c75cb17c3902fdd3325bcfb75eb4c1d2e41d8fabe4a26c，balances[0x84C7768aC1Cd6d07FCA1e2BC4C3551510F6E4ABC]对应的键为0x197b7f4442862bd651f49aa6256f2e268835f42a82c8daa336e3c15f4837830f；

步骤S3、依次执行监管合约的每条规则，在本实施例中首先执行知识库black，然后执行监管规则CheckTransfer。在执行监管规则CheckTransfer时，第6行监管范围语句执行结果为真，第7行强制性语句的执行结果为真，第8行禁止性语句的执行结果为真，因此该监管规则的执行结果为真。

步骤S4、该监管合约只有一条监管规则CheckTransfer，其执行结果为真，因此监管合约的执行结果为真。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明权利要求所限定的范围。