CN116257251A - 文本信息的验证方法和装置 - Google Patents
文本信息的验证方法和装置 Download PDFInfo
- Publication number
- CN116257251A CN116257251A CN202310140797.4A CN202310140797A CN116257251A CN 116257251 A CN116257251 A CN 116257251A CN 202310140797 A CN202310140797 A CN 202310140797A CN 116257251 A CN116257251 A CN 116257251A
- Authority
- CN
- China
- Prior art keywords
- variable
- contract
- name
- intelligent contract
- language
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/42—Syntactic analysis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
本申请提供了一种文本信息的验证方法和装置,属于金融科技(Fintech)领域,该方法包括:获取待验证的智能合约,所述智能合约中包括有至少一个结构体,所述结构体包括有至少一个数据类型为用户定义的变量;对所述智能合约中的结构体进行拆分,确定该结构体的结构体信息,所述结构体信息至少包括该结构体的结构体名称、该结构体所处的合约的合约名、结构体中变量的数据类型和变量名;根据所述结构体信息,翻译所述智能合约得到中间验证语言表示的智能合约;获取形式规约并根据所述形式规约对所述中间验证语言进行验证。该技术方案可以将智能合约中的任意数据类型的变量翻译到中间验证语言,并基于中间验证语言和规约实现了对智能合约的验证。
Description
技术领域
本申请涉及金融科技(Fintech)领域,尤其涉及一种文本信息的验证方法和装置。
背景技术
随着计算机技术的发展,越来越多的技术应用在金融领域,传统金融业正在逐步向金融科技(Fintech)转变,例如区块链技术。智能合约是运行在区块链系统上的一份代码和数据的集合,智能合约通常需要进行安全验证。
目前,对智能合约的验证主要是将智能合约转译为中间验证语言,然后利用对中间验证语言的验证工具链进行验证。
但是,在智能合约转译为中间验证语言的过程中,由于智能合约中涉及到大量与程序执行核心逻辑相关的变量信息,如果中间验证语言中不存在该变量的数据类型,就会导致智能合约中该变量无法翻译得到中间验证语言,从而无法实现对智能合约的安全验证。
发明内容
本申请提供一种文本信息的验证方法和装置,以解决由于中间验证语言中存在的数据类型有限,造成智能合约中任意数据类型的变量无法翻译为中间验证语言,导致智能合约无法进行安全验证的问题。
第一方面,本申请提供一种文本信息的验证方法,该方法包括:
获取待验证的智能合约,所述智能合约中包括有至少一个结构体,所述结构体包括有至少一个数据类型为用户定义的变量;
对所述智能合约中的结构体进行拆分,确定该结构体的结构体信息,所述结构体信息至少包括该结构体的结构体名称、该结构体所处的合约的合约名、结构体中变量的数据类型和变量名;
根据所述结构体信息,翻译所述智能合约得到中间验证语言表示的智能合约;
获取形式规约并根据所述形式规约对所述中间验证语言表示的智能合约进行验证。
在一种可能的设计中,所述拆分所述智能合约中的结构体,得到该结构体中的变量和变量信息之前,还包括:
获取所述智能合约中每个合约的合约名,所述智能合约包括有至少一个合约;
确定所述智能合约中每个合约在所述智能合约中占用的文本范围、各个结构体在所述智能合约中占用的文本范围;
根据各个结构体占用的文本范围和每个合约占用的文本范围,确定是否存在外部结构体,所述外部结构体处于各个合约占用的文本范围之外;
若存在所述外部结构体,则将所述外部结构体内置到每个合约中。
在一种可能的设计中,所述对所述智能合约中的结构体进行拆分,确定该结构体的结构体信息,包括:
编译所述智能合约并进行反序列化,得到所述智能合约的抽象语法树,所述抽象语法树包括至少一个节点,所述节点中包括有所述合约名或所述变量信息或结构体信息;
遍历所述抽象语法树中的各个节点,根据各个节点中的信息,确定所述结构体信息。
在一种可能的设计中,所述根据所述结构体信息,翻译所述智能合约得到中间验证语言表示的智能合约,包括:
根据所述结构体信息,生成结构体对应的变量、结构体的构造函数,并翻译所述智能合约中结构体的相关语句;
根据所述结构体对应的变量、结构体的构造函数、相关语句的翻译结果,构造中间验证语言的抽象语法树;
将所述中间验证语言的抽象语法树转化为文本表达形式,得到所述中间验证语言表示的智能合约。
在一种可能的设计中,所述生成结构体对应的变量,包括:
遍历所述智能合约的抽象语法树中的每个节点,确定所述智能合约中合约的合约名、结构体名称和变量名;
根据所述合约名、结构体名称和变量名,构建变量的完整变量名,作为该变量在所述中间验证语言中的变量名;
获取该变量在智能合约中的数据类型;
根据该变量在智能合约中的数据类型,确定该变量在所述中间验证语言中的数据类型;
根据该变量在所述中间验证语言中的变量名、该变量在所述中间验证语言中的数据类型,生成结构体类型对应的变量。
在一种可能的设计中,所述根据该变量在智能合约中的数据类型,确定该变量在所述中间验证语言中的数据类型,包括:
若该变量在智能合约中的数据类型为用户自定义的,则确定该变量在中间验证语言中的数据类型为引用;
若该变量在智能合约中的数据类型不为用户自定义的,则根据该变量在智能合约中的数据类型和预设数据类型对应关系,确定目标数据类型,作为该变量在中间验证语言中的数据类型。
所述生成结构体的构造函数,包括:
根据结构体名称,确定该结构体的构造函数的函数名;
获取该结构体中包含的所有变量,为其中一个目标变量配置对应的引用值;
针对该结构体中的每个变量,确定每个在中间验证语言中的赋值表达式;
根据所述函数名、目标变量对应的引用值、每个变量在中间验证语言中的赋值表达式,生成结构体的构造函数。
在一种可能的设计中,所述翻译所述智能合约中结构体的相关语句,包括:
遍历智能合约的抽象语法树中的节点;
根据节点中包含的信息,将智能合约中结构体的相关语句翻译为中间验证语言形式,作为该相关语句的翻译结果。
在一种可能的设计中,所述获取形式规约并根据所述形式规约对所述中间验证语言表示的智能合约进行验证,包括:
获取形式规约;
将所述形式规约翻译为中间验证语言形式,嵌入所述中间验证语言表示的智能合约中;
根据预设中间验证语言工具,对完成嵌入后的中间验证语言表示的智能合约进行验证。
第二方面,本申请提供一种文本信息的验证装置,包括:
合约获取模块,用于获取待验证的智能合约,所述智能合约中包括有至少一个结构体,所述结构体包括有至少一个数据类型为用户定义的变量;
合约拆分模块,用于对所述智能合约中的结构体进行拆分,确定该结构体的结构体信息,所述结构体信息至少包括该结构体的结构体名称、该结构体所处的合约的合约名、结构体中变量的数据类型和变量名;
合约翻译模块,用于根据所述结构体信息,翻译所述智能合约得到中间验证语言表示的智能合约;
合约验证模块,用于获取形式规约并根据所述形式规约对所述中间验证语言表示的智能合约进行验证。
本申请提供了一种文本信息的验证方法和装置,通过利用结构体名称、合约名、变量的数据类型和变量名等结构体信息,可以将任意数据类型的变量翻译为对应的中间验证语言,实现对智能合约的验证。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。
图1为本申请实施例提供的智能合约的文本示意;
图2为本申请实施例提供的文本信息的验证方法的流程示意图;
图3为本申请实施例提供的智能合约的翻译过程示意图;
图4为本申请另一实施例提供的智能合约的翻译和验证流程示意图;
图5为本申请实施例提供的智能合约的预处理示意图;
图6为本申请另一实施例提供的智能合约的翻译和验证流程示意图;
图7为本申请实施例提供的智能合约抽象语法树的文本示意图;
图8为本申请实施例提供的智能合约的抽象语法树的示意图;
图9为本申请实施例提供的中间验证语言的抽象语法树的示意图;
图10为本申请实施例提供的结构体对应的翻译结果的示意图;
图11为本申请实施例提供的结构体生成对应构造函数的示意图;
图12为本申请实施例提供的代码翻译示意图;
图13为本申请实施例提供的文本信息的验证装置的结构示意图;
图14为本申请实施例提供的电子设备的结构示意图。
通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,包括但不限于对多个实施例的组合,都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
“需要说明的是,本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、使用和处理需要遵守相关法律法规和标准,并提供有相应的操作入口,供用户选择授权或者拒绝。”
下面对本申请所涉及到的专业名词作出解释:
区块链:区块链是一种由多个节点共同维护的及信任的分布式存储系统。区块链底层是由一系列区块组成的一条链,每个块上除了记录本块的数据还会记录上一块的哈希值,通过这种方式组成链式的数据结构。一个区块由块头和块体组成,其中块头定义包括该区块高度、上一个区块的哈希值等重要字段,而块体主要存储交易数据。区块链利用密码学的方式保证数据传输和访问的安全,并利用链式结构保证链上数据不可被篡改。
智能合约:智能合约是运行在区块链系统之上的一份代码和数据的集合,其中代码负责实现智能合约的功能,数据负责存储智能合约状态,智能合约可以接收和发送信息。
结构体类型:结构体是由一批数据组合而成的结构型数据。组成结构型数据的每个数据称为结构型数据的“成员”。结构体类型不是由系统定义好的,而是需要程序设计者自己定义的。智能合约语言Solidity提供了关键字“struct”来标识所定义的结构体类型。
程序验证(Program Verification):证明程序的正确性,即程序在运行的过程中不会出错,并且程序的功能能够满足。
中间验证语言(Intermediate Verification Language,IVL):一种中间验证语言,利用中间验证语言可以更加方便地对程序代码进行验证,使用者只需要重点关注如何将代码翻译成中间验证语言,而无需关心中间验证语言如何验证代码属性,常见的中间验证语言包括Boogie等。
抽象语法树(Abstract Syntax Tree,AST):是源代码语法结构的一种抽象表示,它以树状的形式表现编程语言的语法结构,树上的每个节点都表示源代码中的一种结构。
形式规约(Specification):由形式规约语言(由严格的递归语法规则所定义的语言)严格描述的系统模型或者系统需要满足的性质,前者是模型规约,后者是性质规约。在本发明中主要指性质规约(以下简称规约),性质规约语言基于程序逻辑系统,通过逻辑公式来描述一组性质以定义所期望的系统行为。常见的性质规约包括线性时序逻辑(LinearTemporary Logic),它是一种描述系统线性时序性质的逻辑表示。
区块链技术在金融科技领域逐步得到重视和认可,智能合约作为运行在区块链系统之上的一份代码和数据的集合,通常需要进行安全验证。而随着智能合约功能不断丰富,智能合约代码中针对结构体类型的使用越来越频繁,嵌套结构体(即结构体类型中包含另一个结构体类型)的情形在智能合约代码中经常出现,且结构体类型被定义得越来越复杂。由于结构体包含了大量与程序执行核心逻辑相关的变量信息,智能合约的安全验证往往依赖于针对嵌套结构体中的变量属性进行准确分析。示例性的,图1为本申请实施例提供的智能合约的文本示意图,如图1所示,用关键字“struct”来表示结构体,智能合约包括有结构体A和结构体B,其中,结构体A中包括有变量‘e1’和变量‘e2’,结构体B中包括有变量‘e3’和变量‘a’(在智能合约中,常用的数据类型包括整型(int),字符串型(string),地址类型(address),映射类型(mapping))。例如图1中的‘int e1’表示定义变量e1的数据类型为整型,又例如‘A a’表示定义变量a的数据类型为结构体类型(即嵌套结构体,结构体B中包含另一个结构体A)。
目前,智能合约安全验证主要有以下两种方式:(1)通过Verisol形式化验证工具进行验证。具体的,该工具采用中间验证语言Boogie的验证工具链,构建了针对Solidity编程语言开发的智能合约的形式化验证和分析系统原型。它首先将Solidity语言的程序转换为Boogie中间验证语言,然后利用对中间验证语言的程序的验证工具链,Boogie(同名,前面是指一种中间验证语言,这里指验证器)或Corral等验证器来对翻译后的程序进行验证。(2)通过SmartPulse线性时序逻辑规约验证工具,其中,SmartPulse是基于Verisol进一步开发的工具原型。具体的,它首先利用扩充版的Verisol来将智能合约转换为中间验证语言,然后将SmartLTL表示的规约嵌入中间验证语言中,最后利用Ultimate工具链来对规约进行验证。
但是在中间验证语言(例如Boogie)中,用户只能声明内置类型的数据结构,不能自定义数据类型(由于在区块链上最小单位为整数,因此常用的数据类型包括:1)整型int,表示一个整数,2)引用类型Ref,表示引用;3)映射map,将一个类型K映射为值V。例如,a:int,表示变量a的类型是一个整数。A:[Ref]int,表示a的类型为从Ref到int的映射,即一个引用对应一个整数。)。而上述的两种方法采用的翻译算法为:源语言的变量类型和翻译后的变量类型是对应的,即变量a在源语言中是什么类型,那么在翻译后的语言中也应该是什么类型。参考上述图1,采用上述两种方法翻译时,将智能合约中结构体A中的‘int e1’翻译后在中间验证语言中也同样是int类型,因为在翻译前后语言中都有int类型。但是由于中间验证语言中并不存在用户自定义的结构体A,中间验证语言中只能使用其自带的数据类型,因而没有A这个自定义的结构体类型,故上述的两种方式无法将结构体类型B中的‘A a’这一变量a进行翻译。另外,上述两种方法采用的一一映射的翻译算法也使得其无法确定结构体中出现嵌套结构体情形时,该变量属于谁。比如说,随着结构体类型嵌套层数的增多,要定位某一个变量属于哪一个结构体也同样困难,例如上述的‘A a’成员变量中的‘e1’,也应当标记为结构体类型B的一个成员。上述的这两种方式不能解决上述问题的原因主要有两方面:(1)实现任意结构体类型的翻译需要保证翻译前后代码表达含义和表达能力的一致性。目前的这两种方法需要翻译前后的变量具有相同的类型,然而对于结构体这样的类型,在中间验证语言不存在,因而无法实现。对于结构体类型,由于其中的每一个成员变量都是用户定义的,并且这些变量同时也可以是结构体类型的,这使得翻译过程需要仔细考虑如何保证翻译前后每一个成员变量都能有所对应,并且能够确定是属于哪一个结构体类型的。尤其是当出现嵌套情形时,需要对嵌套的结构体进行解析或特殊处理。目前的这两种方法仅能对每一个变量进行一一对应,因此,当出现用户自定义的类型时,此时无法在中间验证语言中找到对应的类型,也无法确定成员变量属于哪一个结构体,因而无法实现对任意结构体的翻译。(2)对结构体类型进行翻译,还面临结构体类型的每一个该变量如何表示,如何声明一个该结构体类型的变量,如何将规约中的变量表示为翻译后的变量等一系列问题。现有方法在中间验证语言和源语言中对变量使用相同或固定格式的名称,但当出现嵌套结构体时,这种方式就无效了,它会导致无法实现对结构体成员进行赋值或初始化,例如上述的‘B.a’是一个结构体,在中间验证语言中,对它赋值并不是直接对a进行赋值,而是对其中的‘B.a.e1’进行赋值。
总之,如何有效支持将任意结构体类型翻译为中间验证语言,且有效辅助智能合约的安全检测面临较大技术挑战。具体而言,(1)由于结构体类型形式多样,不同的成员变量需要根据其特定类型来进行翻译。尤其是对于存在嵌套情形的结构体,解析相关变量则更为复杂。(2)将智能合约代码翻译为中间验证语言后,翻译前后变量需要一一对应,且准确记录哪些变量属于同一个结构体。此处核心难点在于如何确保翻译前后的变量、结构一致性,进一步辅助针对不同安全规约的验证。
鉴于上述技术挑战及现有方案的缺陷,已有的形式化验证方法在解析智能合约时,未解决如何将嵌套结构体转换为中间验证语言,同时也无法针对包含嵌套结构体类型的智能合约进行有效验证。针对上述难题,本申请主要具有以下两项核心创新点:(1)本申请提出了一种可以将任意结构体类型翻译为中间验证语言的技术,能够通用地将智能合约中任意结构体类型翻译到中间验证语言,并保证了翻译后的结构体类型与智能合约中的结构体类型有一致的含义和功能。而在实际应用中,将智能合约源代码中的任意结构体类型翻译到中间验证语言是困难的,需要准确实现翻译前后变量的表示方式、对应关系、所属数据结构、构造函数等需求。由于技术困难,现有的方法未解决将任意结构体类型,例如嵌套结构体类型,实现翻译到中间验证语言的问题,也就无法完成任意结构体类型的验证。(2)本申请解决了如何将形式规约中源变量与翻译后中间验证语言变量实现准确映射,它能够根据形式规约的形式,发现形式规约中需要替换的变量,并将其替换,从而实现对结构体类型的验证。在实际应用中,要想对中间验证语言进行验证,则需要准确对应其中的变量。然而,翻译后的中间验证语言代码会扩充许多内容,变量名称也将变得更加冗余而导致难以理解,并且根据所在函数不同,在源代码中名称相同的变量,翻译后也会不同。因此,给定一个源代码中的变量,很难在中间验证语言代码中确定翻译后对应的变量名。现有的方法未实现将描述任意结构体变量的规约,例如线性时态逻辑表示的规约,处理为中间验证语言的验证器可识别的内容的方法,也就无法完成对任意结构体变量性质的验证。
下面通过具体实施例对本申请的技术方案进行详细说明。需要说明的是,下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图2为本申请实施例提供的文本信息的验证方法的流程示意图,该方法的执行主体可以是电子设备,示例性的,以计算机设备为例,如图2所示,该方法包括如下步骤:步骤S201,获取待验证的智能合约,智能合约中包括有至少一个结构体,结构体包括有至少一个数据类型为用户定义的变量。
示例性的,图3为本申请实施例提供的智能合约的翻译过程示意图,如图3所示,智能合约中包括有至少一个合约C(用contract C标识),合约C中包括有两个结构体(即结构体A和结构体B),结构体A中包括有变量‘e1’和变量‘e2’,结构体B中包括有变量e3和a。其中,变量‘e1’、变量‘e2’和变量‘e3’的数据类型均为整型,是非自定义的,在翻译为中间验证语言时可以对应的也为整型,而结构体B中的变量a的数据类型是结构体类型,结构体类型由于是用户自定义的,在中间验证语言中是不支持的,故而在翻译成中间验证语言时需要根据其数据类型特定的进行翻译。另外,由于在将智能合约代码翻译为中间验证语言时,需要准确记录哪一个变量属于哪一个结构体,故在翻译时还需要修改变量名,通过翻译后的变量名来标识记录哪一个变量属于哪一个合约中的哪一个结构体,例如在图3中,智能合约中变量‘e1’在翻译为中间验证语言之后,其变量名修改为‘e1_C.A’,其表示的是变量e1位于合约C的结构体A中。
在本实施例中,用户定义的数据类型可以包括用户自定义的数据类型(例如结构体A)和系统本身有的数据类型(例如整型int),示例性的,以图3为例,StructA(即结构体A)是用户自定义的数据类型,而‘int a’是系统本身有的数据类型(即整型),对于用户自定义的数据类型,在中间验证语言中是不支持的,而对于系统本身有的数据类型,中间验证语言是支持的,故而智能合约中的‘int a’在翻译为中间验证语言形式时可以对应的也为整型。
步骤S202,对智能合约中的结构体进行拆分,确定该结构体的结构体信息,结构体信息至少包括该结构体的结构体名称、该结构体所处的合约的合约名、结构体中变量的数据类型和变量名。
在本实施例中,通过上文阐述可知,由于IVL不存在其它用户自定义的数据类型(例如结构体类型),因此不能完全按照智能合约中的语法进行翻译,需要将智能合约总的结构体类型进行进一步的拆分,再将其分别表示为中间验证语言。其中,在拆分的过程中,需要满足如下要求:1)拆分之后,拆分得到的IVL中的变量与之前结构体中声明的变量数量一致,2)拆分之后,依然知道每一个变量之前是属于哪一个结构体的;3)拆分之后,拆分得到的变量能够完整表示之前的信息,换句话说,也即是做到一一对应。
示例性的,继续参考上述图3,智能合约中包括有合约C(合约C的合约名可直接用字母C表示),合约C中包括有结构体A和结构体B,结构体A中包括有变量‘e1’和变量‘e2’,变量‘e1’和变量‘e2’的数据类型均为整型,结构体B中包括有变量‘e3’和变量‘a’,其中,变量‘e3’的数据类型为整型,而变量‘a’的数据类型为结构体类型,是用户自定义的,在翻译为中间验证语言时无法找到对应的类型,需要进行特定翻译。
步骤S203,根据结构体信息,翻译智能合约得到中间验证语言表示的智能合约。
在本实施例中,在将智能合约翻译为中间验证语言时,其存在主要问题是如何对那些用户自定义数据类型的变量(例如图3中的A a)进行翻译,该问题主要是由于中间验证语言中不存在用户自定义的数据类型(例如结构体类型),导致这些变量无法翻译。为此翻译过程主要包括如下5个小步骤:1)首先获取一个结构体的所有信息;2)遍历整个结构体中的每个变量;3)判断每一个变量的数据类型,将其翻译为‘变量名_合约名.结构体名’这样的格式,以实现一一对应关系,例如图3中的a,表示变量的名称,4)接下来就需要确定其数据类型,如果它是简单类型(此处是智能合约中的类型,例如整数),即非用户自定义的数据类型,则直接表示为IVL中对应的类型;如果它是一个结构体,即用户自定义的数据类型,则将其表示为引用;5)根据这一规则,我们便可以将智能合约中的所有结构体进行翻译。
示例性的,继续参考图3,可以先根据结构体信息识别出要智能合约中的变量的数据类型,如果智能合约中的变量的数据类型在中间验证语言中也存在,则可以直接翻译,例如智能合约中的变量‘e1’的数据类型为整型,在中间验证语言中也存在有整型,则直接将智能合约中的‘int e1’翻译为‘e1_C.A:int’,但是智能合约中的变量‘a’是结构体类型,此时就需要进行特定翻译,即将其表示为引用(即将智能合约中的‘A a’翻译为‘a_C.B:Ref’)。其中。用户自定义的数据类型包括结构体类型。
步骤S204,获取形式规约并根据形式规约对中间验证语言表示的智能合约进行验证。
在本实施例中,形式规约的格式可以是‘执行状态(合约.函数,变量属性)’,其中变量属性一般为一个逻辑表达式,例如‘b.a.e1<1’表示变量b.a.e1的值小于1。在验证时,可以先将形式规约翻译为中间验证语言形式,然后嵌入到中间验证语言表示的智能合约中,再通过中间验证语言验证工具完成验证。
本申请实施例提供的将智能合约中用户定义的任意结构体类型转换为中间验证语言形式的算法,针对目前方法未解决将任意结构体类型,例如嵌套结构体类型,实现翻译到中间验证语言形式的问题,导致无法完成任意结构体类型的验证的问题,能够通用地将智能合约中任意结构体类型翻译到中间验证语言形式,并保证了翻译后的结构体类型与智能合约中的结构体类型有一致的含义和功能,从而完成对智能合约的验证。
示例性的,图4为本申请另一实施例提供的智能合约的翻译和验证流程示意图,以计算机设备作为执行主体为例,如图4所示,智能合约在输入至计算机设备之后,可以先进行预处理得到预处理后的智能合约,然后在进行编译和反序列化得到智能合约的抽象语法树,基于智能合约的抽象语法树逐步翻译智能合约中的源代码,得到中间验证语言的抽象语法树,最后基于中间验证语言的抽象语法树,输出中间验证语言形式的合约代码,至此完成了整个智能合约的翻译,之后再将形式规约翻译成中间验证语言形式嵌入到中间验证语言形式的合约代码,通过中间验证语言的验证工具进行验证,输出验证结果。
在本实施例中,计算机设备获取到的运行参数主要包括有合约文件名(用于表示要验证的合约文件),合约名(用于表示要验证的合约。其中,一个智能合约指的是一个文件,一个这样的文件中可能有多个合约(例如上述图3中contract C),类似于面向对象语言中的类(class),后文合约指合约(contract),而不是整个文件),形式规约(用于表示智能合约具有的性质)。
在另一些实施方式中,在对智能合约进行预处理时,具体可以通过如下步骤实现:获取智能合约中每个合约的合约名,智能合约包括有至少一个合约;确定智能合约中每个合约在智能合约中占用的文本范围、各个结构体在智能合约中占用的文本范围;根据各个结构体占用的文本范围和每个合约占用的文本范围,确定是否存在外部结构体,外部结构体处于各个合约占用的文本范围之外;若存在外部结构体,则将外部结构体内置到每个合约中。
示例性的,图5为本申请实施例提供的智能合约的预处理示意图,如图5所示,智能合约包括有合约C(在图5中用contract C表示)和三个结构体(在图5中分别用struct D、struct A和struct B表示,其中,结构体D处于合约之外),在进行预处理时,需要精确定位到智能合约包含的结构体的位置,当结构体定义在合约之外时,需要将其移动至合约内。具体的,其包括如下3个小步骤:(1)根据智能合约的文件名,获取待验证的源代码(即智能合约的源代码)。(2)扫描源代码,判断关键词‘struct’是否位于关键词‘contract’内部,如果不在则记录下该结构体;如果在,则跳过。(3)因为每一个合约都是可以调用在外部的结构体的,需要把外部结构体移动到每一个合约中。扫描源代码,找到每一个contract合约,将位于合约外部的结构体插入合约中。
本申请实施例通过对智能合约进行预处理,将外部结构体移动到每一个合约中,这样避免翻译时出现遗漏,准确的定位出某一个变量在哪一个合约的哪一个结构体中,保证翻译前后每一个变量都能有所对应。
示例性的,图6为本申请另一实施例提供的智能合约的翻译和验证流程示意图,如图6所示,其包括如下步骤:步骤S601,输入运行参数。步骤S602,内置合约外部结构体。步骤S603,编译智能合约并进行反序列化。步骤S604,生成结构体类型对应的变量。步骤S605,生成结构体类型的构造函数。步骤S606,翻译源代码中结构体类型相关语句。步骤S607,输出翻译后的中间验证语言的翻译状态表。步骤S608,将形式规约表示为中间验证语言形式。步骤S609,验证中间验证语言表示的智能合约。
在一些实施例中,在对智能合约的结构体进行拆分时,可以通过编译智能合约并进行反序列化,得到智能合约的抽象语法树,抽象语法树包括至少一个节点,节点中包括有合约名或变量信息或结构体信息;遍历抽象语法树中的各个节点,根据各个节点中的信息,确定结构体信息。
具体的,在对智能合约进行编译时,利用智能合约编译器(例如Solidity的编译器solc等)编译合约,输出其抽象语法树的文本表示,如此能够获悉合约中每一个变量的数据类型和值。示例性的,图7为本申请实施例提供的智能合约抽象语法树的文本示意图,如图7所示,其为上述图5中结构体A的抽象语法树的文本表示,其中包含了结构体A的所有信息,包括名称,成员(member)和值。
其中,计算机设备直接对上述这样的抽象语法树的文本进行处理是非常困难的,因此首先要把它解析为程序可以直接操作的树结构。示例性的,图8为本申请实施例提供的智能合约的抽象语法树的示意图,如图8所示,其包括有若干个节点,针对每一个节点类型nodetype(例如图8中的合约定义、结构体定义等),按照智能合约的语法结构或上述通过编译器得到的文本表示的抽象语法树,构建对应的类,保存该节点的信息。其中合约源文件类为根节点,每个节点都可以有子节点,从而形成一棵树。如果编程语言自带的反序列化解析函数则直接使用,否则根据上图7所示的抽象语法树文本信息(每个节点都有一些‘属性:值’的信息,其中member后表示子节点,据此可以在当前节点保存对应的信息,然后插入相应的子节点,对于子节点采用同样的方式,直到构建出用上述定义的AST类来表示的语法树对象,实际上这个过程就是反序列化),将纯文本的抽象语法树信息,生成一个能够直接操作的抽象语法树对象。
在本实施例中,反序列化可以理解为将一串文本,重新变为代码可以直接操作的对象。因为,编译得到的AST是一串序列化的文本,本质是一串文本,为了能够更好地操作,需要将其转变为对象,所以需要进行反序列化操作。抽象语法树(Abstract Syntax Tree,AST),是源代码语法结构的一种抽象表示,它以树状的形式表现编程语言的语法结构,树上的每个节点都表示源代码中的一种结构。当构建得到一个如图8所示的智能合约的抽象语法树之后,当获取到A这个节点之后,通过遍历其子节点就能得到它的所有信息。
其中,遍历实际上就是访问完树上的所有节点,这样做相当于就是对整个文件进行了处理。上图8为智能合约抽象语法树的一个抽象说明,最顶层为整个文件节点,第二层为合约节点,第三层为各种定义节点,第四层为函数中内容节点。在遍历时,采用先序遍历,即优先完成一个节点的所有子节点。在上图8中,首先从合约源文件节点出发,到节点C,再到节点A,再到节点e1,…,直到访问完所有节点。遍历操作在后续大量使用,因为我们执行翻译操作时,需要对整个文件中的相关内容进行处理,也就相当于遍历一遍树,然后对相关的节点进行处理。类(class)实际上是一种自定义的数据结构;对象实际上是类的实例化,可以理解为类没有具体的值,但是对象有。
本申请实施例通过编译智能合约并进行反序列化形成智能合约的抽象语法树,通过对抽象语法树中的节点及其子节点进行遍历就可以获得节点的所有信息,提高信息获取和处理的效率。
在一些实施例中,继续参考上述图4,在得到智能合约的抽象语法树之后,需要构建中间验证语言的抽象语法树,通过将中间验证语言的抽象语法树转化为文本表达形式,才可得到中间验证语言。具体的,在翻译智能合约得到中间验证语言表示的智能合约时,可以通过如下步骤实现:根据结构体信息,生成结构体对应的变量、结构体的构造函数,并翻译智能合约中结构体的相关语句;根据结构体对应的变量、结构体的构造函数、相关语句的翻译结果,构造中间验证语言的抽象语法树;将中间验证语言的抽象语法树转化为文本表达形式,得到中间验证语言表示的智能合约。
在本实施例中,构建中间验证语言的抽象语法树与构建智能合约的抽象语法树过程类似,但用途不同,构建智能合约的抽象语法树过程是要把文本表示的抽象语法树恢复到可操作性的数据结构,而构建中间验证语言的抽象语法树则是要把中间验证语言的抽象语法树变为代码形式输出到文本。因为在翻译时直接插入翻译后的代码是十分困难的,首先翻译后的代码并不是一行一行增加的,同时直接对文本表示的代码进行处理也会比对抽象语法树进行处理更加困难。
具体的,在构建中间验证语言的抽象语法树时,主要包括如下两个步骤:(1)根据中间验证语言的语法,确定具有的节点类型,构建中间验证语言的抽象语法树节点类。在本实施例中,至少需要构建程序定义、变量声明节点、函数节点、参数节点、表达式节点等。(2)生成空的中间验证语言的抽象语法树类对象,用于后续根据生成的结构体对应的变量、结构体的构造函数和相关语句的翻译结果,向其中添加结点,便于后续翻译。其中,在对智能合约翻译完成后会形成类似图8的中间验证语言的抽象语法树。示例性的,图9为本申请实施例提供的中间验证语言的抽象语法树的示意图,如图9所示,智能合约中的变量‘e1’的变量名翻译为‘e1_C.A’,其变量类型为[Ref]int,填入至变量生命节点中,智能合约中的结构体B的结构体名称翻译为‘constructor_B’,其函数类型为构造函数,填入至函数节点中。
本申请实施例通过构建中间验证语言的抽象语法树,然后再将中间验证语言的抽象语法树变为代码形式输出到文本,这样在翻译过程中不需要直接对文本表示的代码进行处理,能够提高翻译过程中的效率。
进一步的,在另一些实施例中,在生成结构体类型对应的变量时,可以通过如下步骤实现:遍历智能合约的抽象语法树中的每个节点,确定智能合约中合约的合约名、结构体名称和变量名;根据合约名、结构体名称和变量名,构建变量的完整变量名,作为该变量在中间验证语言中的变量名;获取该变量在智能合约中的数据类型;根据该变量在智能合约中的数据类型,确定该变量在中间验证语言中的数据类型;根据该变量在中间验证语言中的变量名、该变量在中间验证语言中的数据类型,生成结构体类型对应的变量。
在本实施例中,这一步是要将源语言中的结构体在中间验证语言中进行声明。由于中间验证语言不能定义用户自定义类型,因此我们在声明时需要将其当作数组来进行,然后通过引用来找到当前变量的值。具体包括如下步骤:第(1)步遍历智能合约的抽象语法树,对每一个节点执行第(2)步第(2)步判断当前节点的类型,如果当前节点为合约定义,则进入第(3)步;第(3)步如果当前节点为结构体定义,则进入第(4)步;第(4)步从节点存储的信息中获取当前合约的名称,在翻译时,通过对智能合约翻译得到的抽象语法树进行遍历,首先会经过根节点,然后到合约节点,此时便可记录下当前的合约名,便于在后续使用。第(5)步获取结构体完整信息。具体为,获取当前节点信息,得到结构体名称。遍历该节点的所有子节点,获取每一个节点的名称和类型。对每一个子节点,将变量名表示为‘变量名_合约名.结构体名’的形式,称作完整变量名,作为其在抽象语法树中的变量名;第(6)步确定翻译后的变量的数据类型,获取变量的数据类型,根据不同的数据类型进行不同操作。例如若该变量在智能合约中的数据类型为用户自定义的,则确定该变量在中间验证语言中的数据类型为引用;若该变量在智能合约中的数据类型不为用户自定义的,则根据该变量在智能合约中的数据类型和预设数据类型对应关系,确定目标数据类型,作为该变量在中间验证语言中的数据类型。具体的,1)如果数据类型为‘整型int、字符串型string、地址类型address’,则在中间验证语言中翻译为整数int类型;2)如果为‘结构体类型struct’,则翻译成引用Ref类型;3)如果为‘映射类型map’,则按照原方案中映射的翻译方式进行,映射类型中的数据类型为上述1)或2)两种时,则对应的按照上述1)或2)方案进行。例如对于类型‘map(int->A)’,表示将一个int类型数据映射到A,对int和A的翻译需根据1)或2)进行,对于映射过程本身按照原方案进行。
在本实施例中,利用引用能够使得翻译过程更加通用,即无论嵌套多少层,都可以运用相似的方法实现翻译。但是实际上,在其他实施方式中,翻译结构体存在一种替代方案,具体的,可以将结构体中的所有变量都进行拆解,当嵌套时,则需要进一步分析嵌套的合约进行且一并拆解。例如b.a.e1这样一个变量,表示合约C中结构体b中结构体a的e1变量,可以翻译为‘e1_A_C.B’如下形式,其类型即为e的类型。这种方法在不会出现对嵌套结构体的情况下是可接受的,但是当要对嵌套的结构体进行赋值时(例如对a进行赋值),则会导致需要增添大量处理结构体中每一个成员的翻译代码。例如,上例中要对a进行赋值,则需要对a中每一个变量都进行赋值。
另外,需要说明的是,上述几类类型即为智能合约中常见的类型,在智能合约中常常还有int4、int8等这类带变量长度的关键词,此时均统一按照1)来进行处理。在中间验证语音的抽象语法树中插入变量声明节点,针对每一个结构体中的变量插入如下格式的内容,括号中为示例,即不包括括号:
变量名:完整变量名例如:(a_C.B)
类型:[Ref]变量类型例如:([Ref]Ref)
并定义其输出为:完整变量名:[Ref]变量类型例如:(a_C.B:[Ref]Ref)。
其中:输出的意思就是当将中间验证语言的抽象语法树输出到翻译后代码文本时的格式。此处涉及一个重要的思想,在一般的高级语言中,可以对同一个类型声明不同的变量,例如‘int a,int b’,但在中间验证语言中,这样做会导致翻译后的代码量激增,因为针对a和b都需要定义对应的变量,因此翻译后的结构体被表示为列表,而a,b之类的变量被翻译为引用Ref,这样对于‘A a’这样一个定义,a是引用类型Ref,只需要在声明的翻译后的结构体变量中找到引用对应的值即可,因此需要加上使用映射‘[]’,表示为[Ref]类型。
示例性的,图10为本申请实施例提供的结构体对应的翻译结果的示意图,如图10所示,结构体B中的‘int e3’翻译为‘e3_C.B:[Ref]int’,‘A a’翻译为‘a_C.B:[Ref]Ref’。
本申请实施例通过遍历智能合约的抽象语法树中的节点,获取合约名、结构体名称、变量名,组合形成完整变量名,作为中间验证语言中该变量的名称,如此在智能合约中出现结构体类型嵌套时,在翻译该结构体中的变量时也能够基于该变量的名称识别出其属于哪个结构体,实现任意结构体类型翻译到中间验证语言。
在另一些实施例中,在生成结构体的构造函数时,可以通过如下步骤实现:根据结构体名称,确定该结构体的构造函数的函数名;获取该结构体中包含的所有变量,为其中一个目标变量配置对应的引用值;针对该结构体中的每个变量,确定每个在中间验证语言中的赋值表达式;根据函数名、目标变量对应的引用值、每个变量在中间验证语言中的赋值表达式,生成结构体的构造函数。
在本实施例中,与在高级语言中类似,在对一个结构体进行构造时,需要对其中的每一个值进行初始化,该构造器的用处即为此。即只需要给出是哪一个自定义的变量,即可对其中每一个值进行赋值。具体的,其包括如下步骤:步骤(1),①首先获取一个结构体的所有信息;②遍历整个结构体中的每个成员变量;③判断每一个变量的类型,将其翻译为‘变量名_合约名.结构体名’这样的格式,以实现一一对应关系,例如上面的a,表示变量的名称;④接下来就需要确定其类型,如果它是简单类型(此处是智能合约中的类型,例如整数),则直接表示为中间验证语言中对应的类型;如果它是一个结构体,则将其表示为引用;⑤根据这一规则,即可以将合约中的所有结构体进行翻译。步骤(2)根据已经得到结构体名称,将其扩充为‘constructor_结构体名称’的形式,作为该构造函数的函数名。步骤(3)在中间验证语言的抽象语法树中添加函数节点,内容为:函数名:构造函数的函数名,例如:(constructor_A),类型:构造函数。步骤(4)在函数节点下中添加参数节点。完成对一个结构体类型变量的初始化需要对每一个变量进行赋值,因此参数至少包含结构体中的每一个变量,同时还应当包含一个对该构造出的变量的一个引用。即参数形式为(this:Ref,变量名1:类型1,变量名2:类型2,…)对每一个‘变量名:类型’的内容,并将该内容添加到中间验证语言的抽象语法树对象中,内容为:参数名:变量名,例如:(this);类型:对应的类型,例如:(Ref);步骤(5)在函数节点下添加表达式节点,将参数的值,赋值到对应的翻译后的变量中。针对每一个变量,在中间验证语言的抽象语法树对象中加入如下赋值表达式。此处做了简化,实际上表达式节点应该由三个子节点组成,表达式左边变量,表达式右边变量和操作符。表达式:完整变量名[this]=变量名,例:(e3_C.B[this]=e3),类型:表达式;步骤(6)构建完整构造函数节点的输出,格式为:函数名(所有参数){所有表达式}
示例性的,图11为本申请实施例提供的结构体生成对应构造函数的示意图,如图11所示,结构体B(通过‘structB’表示)被翻译为‘Constructor_B(this:Ref,e3:int,a:Ref)’,‘int e3’被翻译为‘e3_C.B[this]=e3’,‘A a’被翻译为‘a_C.B[this]=a’。
本申请实施例通过对一个结构体进行构造,生成构造函数,在需要对其中的每一个值进行初始化时,只需要给出哪一个是自定义数据类型的变量,即可对其中每一个值进行赋值,提高翻译效率。
在一些实施例中,在翻译智能合约中结构体的相关语句时,具体可以通过如下步骤实现:遍历智能合约的抽象语法树中的节点;根据节点中包含的信息,将智能合约中结构体的相关语句翻译为中间验证语言形式,作为该相关语句的翻译结果。
在本实施例中,结构体中可能存在有A.B.e这样的相关语句,这种语句由于存在结构体嵌套的情况,需要进行特定翻译。具体的,按照遍历顺序,首先会遍历到智能合约的抽象语法树上的A节点,确定其为一个结构体,且是最上层的,此处将‘A’翻译为A’;然后分析下一个节点B,同样确定其为一个结构体节点,按照上述规则,将其翻译为与之前翻译的名称相同的节点,B’,并将其组合得到B’[A’];再接下来,继续分析‘e’得到其是一个简单变量,同样按照规则得到e’,组合得到e’[B’][A’],至此即完成了对A.B.e的翻译。
在本实施例中,在对A.B.e这样的相关语句之后再继续构造中间验证语言的抽象语法树,整个翻译和构造过程包括如下步骤:(1)初始时,记默认当前合约名为‘空’,函数名为‘全局’。因为后续要知道待翻译的表达式所属的合约和函数,当没有函数时代表是全局。(2)遍历整棵智能合约的抽象语法树,判断当前节点类型,如果为合约节点或函数节点,则记录当前处理的合约名和函数名;如果是结构体类型,则进入(3)。(3)获取结构体变量名,对结构体变量的名称的第一部分进行扩充,以区分不同的使用。所谓第一部分即是b.a.e1中的b。假设b是一个结构体类型的变量,它会被翻译为一个引用类型的值,为了区分不同的b,因为这个变量可能出现在其他函数,为了避免值被覆盖,因此需要将其扩充为‘b_n’这样的格式,‘n’是一个任意可以用作区分的数。(4)递归处理结构体访问的成员,获得翻译后完整变量名。事实上,许多时候不会直接用b,而是会用b.a.e1这样的形式,因此真正要表示的实际上是b.a.e1。具体做法为:1)判断下一个节点是否为b的成员(即b.a这样的带有.的调用),如果是则继续,不是则结束;2)查找a在翻译后代码中的数据类型和对应的变量a’,并将其和之前的内容形成a’[b_n]的结构,3)重复执行该操作直到下一个节点不是成员。(5)在中间验证语言的抽象语法树中插入变量节点,具体为:变量名:翻译后完整变量名,例:(e1_C.A[a_C.B[b_1]])并输出为翻译后完整变量名。(6)记录翻译状态,按照(合约名、函数名、变量名、翻译后完整名称)的格式,记录下每一个变量翻译后的名称,如果遇到重复的则不记录。
示例性的,假设有一个结构体‘struct B’的一个具体变量为b,它有这样一个使用情形b.a.e1-1,那么处理过程如下:(1)获取到b对应的引用名称和类型,例如类型为结构体struct,名称为b_1;(2)读取到a,是b中的一个结构体成员变量,格式为a_C.B[],将二者组合即得到a_C.B[b_1];(3)读取到e1是a中的一个成员变量,格式为e1_C.A[],将二者组合即可得到e1_C.A[a_C.B[b_1]],至此便完成了变量的翻译。即合约C中的b.a.e1-1,最终被翻译为e1_C.A[a_C.B[b_1]]-1。
示例性的,图12为本申请实施例提供的代码翻译示意图,如图12所示,智能合约中的文本代码通过翻译之后得到翻译后代码,作为中间验证语言形式的智能合约。
本申请实施例根据遍历顺序,对智能合约的抽象语法树中的节点进行遍历,获取各个节点中的信息,可以实现对嵌套结构体这样的文本语句进行翻译,通用地实现任意结构体类型变量翻译到中间验证语言,且保证了翻译后与源代码表达的含义一致。
在一些实施例中,在完成对智能合约的翻译之后,可以通过如下步骤实现进行验证:获取形式规约;将形式规约翻译为中间验证语言形式,嵌入中间验证语言表示的智能合约中;根据预设中间验证语言工具,对完成嵌入后的中间验证语言表示的智能合约进行验证。
在本实施例中,形式规约的格式为:‘执行状态(合约.函数,变量属性)’,其中变量属性一般为一个逻辑表达式,例如‘b.a.e1<1’表示变量b.a.e1的值小于1。其中,将形式规约中高级语言表示的变量,翻译成中间验证语言中的变量,具体可以通过如下步骤实现:(1)读取输入的形式规约,根据形式规约格式,通过匹配的方式,即在括号内的前半部分和后半部分,获取涉及到的‘合约.函数’和‘变量属性’两部分的值。又由于变量名是‘字符串.字符串’这样的结构,进而可以确定合约名,函数名和变量名称。(2)判断形式规约中变量的格式和来源,具体可如下几个小步骤:1)判断变量属性中是否有‘.’这样的变量访问符号(即是否为结构体类型),若有则进行替换,否则结束处理。2)判断变量名中是否包含关键词[this],若包含则将函数名替换为全局。(3)从输出的翻译状态中查表找到对应名称并进行替换。根据(合约名,函数名,变量名称)从上述记录的内容查找翻译前后的变量的名称,并将该变量名称替换为翻译后的变量名称。
示例性的,有形式规约‘合约执行完成(全局,b.a.e1<1)’,被翻译为‘合约执行完成(全局,e1_C.A[a_C.B[b_1]]<1)’。
在本实施例中,在将合约翻译成中间验证语言形式之后,可以嵌入到翻译后的代码(即翻译智能合约得到的中间验证语言)中,然后通过中间验证语言验证工具完成验证。
本申请实施例通过将形式规约翻译为中间验证语言形式,能够将形式规约中含有结构体类型的变量自动对照为翻译后的变量,从而实现了规约属性与中间验证语言对应,确保后续验证工具链能够有效运行。
下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。
图13为本申请实施例提供的文本信息的验证装置的结构示意图,如图13所示,该文本信息的验证装置1300包括有合约获取模块1310、合约拆分模块1320、合约翻译模块1330、合约验证模块1340。其中,合约获取模块1310用于获取待验证的智能合约,智能合约中包括有至少一个结构体,结构体包括有至少一个数据类型为用户定义的变量。合约拆分模块1320用于对智能合约中的结构体进行拆分,确定该结构体的结构体信息,结构体信息至少包括该结构体的结构体名称、该结构体所处的合约的合约名、结构体中变量的数据类型和变量名。合约翻译模块1330用于根据结构体信息,翻译智能合约得到中间验证语言表示的智能合约。合约验证模块1340用于获取形式规约并根据形式规约对中间验证语言表示的智能合约进行验证。
可选的,该文本信息的验证装置还可以包括预处理模块,用于获取智能合约中每个合约的合约名,智能合约包括有至少一个合约;确定智能合约中每个合约在智能合约中占用的文本范围、各个结构体在智能合约中占用的文本范围;根据各个结构体占用的文本范围和每个合约占用的文本范围,确定是否存在外部结构体,外部结构体处于各个合约占用的文本范围之外;若存在外部结构体,则将外部结构体内置到每个合约中。
可选的,合约拆分模块具体可以用于编译智能合约并进行反序列化,得到智能合约的抽象语法树,抽象语法树包括至少一个节点,节点中包括有合约名或变量信息或结构体信息;遍历抽象语法树中的各个节点,根据各个节点中的信息,确定结构体信息。
可选的,合约翻译模块具体可以用于:根据结构体信息,生成结构体对应的变量、结构体的构造函数,并翻译智能合约中结构体的相关语句;根据结构体对应的变量、结构体的构造函数、相关语句的翻译结果,构造中间验证语言的抽象语法树;将中间验证语言的抽象语法树转化为文本表达形式,得到中间验证语言表示的智能合约。
可选的,合约翻译模块具体可以用于:遍历智能合约的抽象语法树中的每个节点,确定智能合约中合约的合约名、结构体名称和变量名;根据合约名、结构体名称和变量名,构建变量的完整变量名,作为该变量在中间验证语言中的变量名;获取该变量在智能合约中的数据类型;根据该变量在智能合约中的数据类型,确定该变量在中间验证语言中的数据类型;根据该变量在中间验证语言中的变量名、该变量在中间验证语言中的数据类型,生成结构体类型对应的变量。
可选的,合约翻译模块具体可以用于:若该变量在智能合约中的数据类型为用户自定义的,则确定该变量在中间验证语言中的数据类型为引用;若该变量在智能合约中的数据类型不为用户自定义的,则根据该变量在智能合约中的数据类型和预设数据类型对应关系,确定目标数据类型,作为该变量在中间验证语言中的数据类型。
可选的,合约翻译模块具体可以用于:根据结构体名称,确定该结构体的构造函数的函数名;获取该结构体中包含的所有变量,为其中一个目标变量配置对应的引用值;针对该结构体中的每个变量,确定每个在中间验证语言中的赋值表达式;根据函数名、目标变量对应的引用值、每个变量在中间验证语言中的赋值表达式,生成结构体的构造函数。
可选的,合约翻译模块具体可以用于:遍历智能合约的抽象语法树中的节点;根据节点中包含的信息,将智能合约中结构体的相关语句翻译为中间验证语言形式,作为该相关语句的翻译结果。
可选的,合约验证模块具体可以用于:获取形式规约;将形式规约翻译为中间验证语言形式,嵌入至中间验证语言表示的智能合约中;根据预设中间验证语言工具,对完成嵌入后的中间验证语言表示的智能合约进行验证。
本申请实施例提供的装置,可用于执行上述实施例中的方法,其实现原理和技术效果类似,在此不再赘述。
需要说明的是,应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块通过处理元件调用软件的形式实现,部分模块通过硬件的形式实现。例如,合约拆分模块可以为单独设立的处理元件,也可以集成在上述装置的某一个芯片中实现,此外,也可以以程序代码的形式存储于上述装置的存储器中,由上述装置的某一个处理元件调用并执行以上合约拆分模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起,也可以独立实现。这里的处理元件可以是一种集成电路,具有信号的处理能力。在实现过程中,上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
图14为本申请实施例提供的电子设备的结构示意图。如图14所示,该电子设备1400可以包括:至少一个处理器1401和存储器1402。图14示出的是以一个处理器为例的电子设备。存储器1402,用于存放程序。具体地,程序可以包括程序代码,程序代码包括计算机操作指令。存储器1402可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。处理器1401用于执行存储器1402存储的计算机执行指令,以实现以上各方法实施例的方法。
其中,处理器1401可能是一个中央处理器(central processing unit,简称为CPU),或者是特定集成电路(application specific integrated circuit,简称为ASIC),或者是被配置成实施本申请实施例的一个或多个集成电路。
可选地,存储器1402既可以是独立的,也可以跟处理器1401集成在一起。当存储器1402是独立于处理器1401之外的器件时,电子设备1400还可以包括:总线1403,用于连接处理器1401以及存储器1402。总线可以是工业标准体系结构(industry standardarchitecture,简称为ISA)总线、外部设备互连(peripheral component,PCI)总线或扩展工业标准体系结构(extended industry standard architecture,EISA)总线等。总线可以分为地址总线、数据总线、控制总线等,但并不表示仅有一根总线或一种类型的总线。
可选的,在具体实现上,如果存储器1402和处理器1401集成在一块芯片上实现,则存储器1402和处理器1401可以通过内部接口完成通信。
本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质可以包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random accessmemory,RAM)、磁盘或者光盘等各种可以存储程序代码的介质,具体的,该计算机可读存储介质中存储有程序指令,程序指令用于上述各方法实施例中的方法。
本申请实施例还提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现上述各方法实施例中的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由本申请的权利要求书指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。
Claims (10)
1.一种文本信息的验证方法,其特征在于,包括:
获取待验证的智能合约,所述智能合约中包括有至少一个结构体,所述结构体包括有至少一个数据类型为用户定义的变量;
对所述智能合约中的结构体进行拆分,确定该结构体的结构体信息,所述结构体信息至少包括该结构体的结构体名称、该结构体所处的合约的合约名、结构体中变量的数据类型和变量名;
根据所述结构体信息,翻译所述智能合约得到中间验证语言表示的智能合约;
获取形式规约并根据所述形式规约对所述中间验证语言表示的智能合约进行验证。
2.根据权利要求1所述的方法,其特征在于,所述拆分所述智能合约中的结构体,得到该结构体中的变量和变量信息之前,还包括:
获取所述智能合约中每个合约的合约名,所述智能合约包括有至少一个合约;
确定所述智能合约中每个合约在所述智能合约中占用的文本范围、各个结构体在所述智能合约中占用的文本范围;
根据各个结构体占用的文本范围和每个合约占用的文本范围,确定是否存在外部结构体,所述外部结构体处于各个合约占用的文本范围之外;
若存在所述外部结构体,则将所述外部结构体内置到每个合约中。
3.根据权利要求1所述的方法,其特征在于,所述对所述智能合约中的结构体进行拆分,确定该结构体的结构体信息,包括:
编译所述智能合约并进行反序列化,得到所述智能合约的抽象语法树,所述抽象语法树包括至少一个节点,所述节点中包括有所述合约名或所述变量信息或结构体信息;
遍历所述抽象语法树中的各个节点,根据各个节点中的信息,确定所述结构体信息。
4.根据权利要求1所述的方法,其特征在于,所述根据所述结构体信息,翻译所述智能合约得到中间验证语言表示的智能合约,包括:
根据所述结构体信息,生成结构体对应的变量、结构体的构造函数,并翻译所述智能合约中结构体的相关语句;
根据所述结构体对应的变量、结构体的构造函数、相关语句的翻译结果,构造中间验证语言的抽象语法树;
将所述中间验证语言的抽象语法树转化为文本表达形式,得到所述中间验证语言表示的智能合约。
5.根据权利要求4所述的方法,其特征在于,所述生成结构体对应的变量,包括:
遍历所述智能合约的抽象语法树中的每个节点,确定所述智能合约中合约的合约名、结构体名称和变量名;
根据所述合约名、结构体名称和变量名,构建变量的完整变量名,作为该变量在所述中间验证语言中的变量名;
获取该变量在智能合约中的数据类型;
根据该变量在智能合约中的数据类型,确定该变量在所述中间验证语言中的数据类型;
根据该变量在所述中间验证语言中的变量名、该变量在所述中间验证语言中的数据类型,生成结构体类型对应的变量。
6.根据权利要求5所述的方法,其特征在于,所述根据该变量在智能合约中的数据类型,确定该变量在所述中间验证语言中的数据类型,包括:
若该变量在智能合约中的数据类型为用户自定义的,则确定该变量在中间验证语言中的数据类型为引用;
若该变量在智能合约中的数据类型不为用户自定义的,则根据该变量在智能合约中的数据类型和预设数据类型对应关系,确定目标数据类型,作为该变量在中间验证语言中的数据类型。
7.根据权利要求4所述的方法,其特征在于,所述生成结构体的构造函数,包括:
根据结构体名称,确定该结构体的构造函数的函数名;
获取该结构体中包含的所有变量,为其中一个目标变量配置对应的引用值;
针对该结构体中的每个变量,确定每个在中间验证语言中的赋值表达式;
根据所述函数名、目标变量对应的引用值、每个变量在中间验证语言中的赋值表达式,生成结构体的构造函数。
8.根据权利要求4所述的方法,其特征在于,所述翻译所述智能合约中结构体的相关语句,包括:
遍历智能合约的抽象语法树中的节点;
根据节点中包含的信息,将智能合约中结构体的相关语句翻译为中间验证语言形式,作为该相关语句的翻译结果。
9.根据权利要求1-8中任一项所述的方法,其特征在于,所述获取形式规约并根据所述形式规约对所述中间验证语言表示的智能合约进行验证,包括:
获取形式规约;
将所述形式规约翻译为中间验证语言形式,嵌入所述中间验证语言表示的智能合约中;
根据预设中间验证语言工具,对完成嵌入后的中间验证语言表示的智能合约进行验证。
10.一种文本信息的验证装置,其特征在于,包括:
合约获取模块,用于获取待验证的智能合约,所述智能合约中包括有至少一个结构体,所述结构体包括有至少一个数据类型为用户定义的变量;
合约拆分模块,用于对所述智能合约中的结构体进行拆分,确定该结构体的结构体信息,所述结构体信息至少包括该结构体的结构体名称、该结构体所处的合约的合约名、结构体中变量的数据类型和变量名;
合约翻译模块,用于根据所述结构体信息,翻译所述智能合约得到中间验证语言表示的智能合约;
合约验证模块,用于获取形式规约并根据所述形式规约对所述中间验证语言表示的智能合约进行验证。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310140797.4A CN116257251A (zh) | 2023-02-15 | 2023-02-15 | 文本信息的验证方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310140797.4A CN116257251A (zh) | 2023-02-15 | 2023-02-15 | 文本信息的验证方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116257251A true CN116257251A (zh) | 2023-06-13 |
Family
ID=86683861
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310140797.4A Pending CN116257251A (zh) | 2023-02-15 | 2023-02-15 | 文本信息的验证方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116257251A (zh) |
-
2023
- 2023-02-15 CN CN202310140797.4A patent/CN116257251A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Mogensen | Introduction to compiler design | |
Friedman et al. | Essentials of programming languages | |
US8516458B2 (en) | System representation and handling techniques | |
US7958493B2 (en) | Type inference system and method | |
US4686623A (en) | Parser-based attribute analysis | |
JPS6375835A (ja) | 目的コ−ド、プログラム・リスト及び設計文書を生成する装置 | |
CN111249736B (zh) | 代码处理方法及装置 | |
JP2008501192A (ja) | キーフィールドレベルにおけるオントロジーコンテキストロジック | |
JP2007521568A (ja) | 複数の例外処理モデルの中間表現 | |
Uhl et al. | An attribute grammar for the semantic analysis of Ada | |
Fritzson et al. | Towards Modelica 4 meta-programming and language modeling with MetaModelica 2.0 | |
CN116166236A (zh) | 代码推荐方法、装置、计算机设备及存储介质 | |
Zhao et al. | Pattern-based design evolution using graph transformation | |
Denney | A prototype proof translator from HOL to Coq | |
Fritzson et al. | Metamodelica–a symbolic-numeric modelica language and comparison to julia | |
CN116257251A (zh) | 文本信息的验证方法和装置 | |
JP5600301B2 (ja) | システム表現およびハンドリング技術 | |
CN111381827A (zh) | 生成代码文件的语法树的方法、装置及电子设备 | |
Feldman | Edward W. Czeck | |
Mazanek et al. | Parsing of hyperedge replacement grammars with graph parser combinators | |
Jeffery | Build Your Own Programming Language: A programmer's guide to designing compilers, interpreters, and DSLs for solving modern computing problems | |
CN118092937A (zh) | 一种支持iec61131标准的st语言转c语言的编译方法 | |
Lempsink | Generic type-safe diff and patch for families of datatypes | |
Sabharwal et al. | Verifying correctness of Haskell programs using the programming language Agda and framework agda2hs | |
Bertolotti | * PILER: NOT A VM TO RULE NO ONE |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |