基于区块链技术的智能合约的签署方法和签署系统

技术领域

本申请涉及区块链技术领域，具体而言，涉及一种基于区块链技术的智能合约的签署方法和签署系统。

背景技术

在通常情况下，用户在平台签订合约时，只需要点击同意协议，即默认根据协议建立了双方的权利义务关系。实际纠纷问题产生时，用户可能以平台“未采取合理方式让用户注意”“非本人操作”等原因为由，主张合同无效，影响平台的有效运营，运营风险较高。究其原因，主要是点击同意协议可能存在漏洞。电子签名如需有法律效力需要满足以下条件：1）身份经过第三方有效认证，满足法律规定的认证要求；2）电子签名能够标识签署人、签署时间，防篡改，满足法律规定的有效电子签名要求；3）数据电文原件，能够可靠地保持内容完整、防篡改，满足法律规定的原件形式及文件保存要求。而通过点击同意的形式签署协议，容易存在非本人操作、平台对协议的防篡改保障不足、签署人意愿证明不足等问题，导致合约纠纷增加，致使平台或合约方面临更高的法务风险。

发明内容

本申请的内容部分用于以简要的形式介绍构思，这些构思将在后面的具体实施方式部分被详细描述。本申请的内容部分并不旨在标识要求保护的技术方案的关键特征或必要特征，也不旨在用于限制所要求的保护的技术方案的范围。

作为本申请的第一个方面，现有的合约在签订过程中，因为无法确定签约人的身份、签约人的意愿，以及保证智能合约无法被篡改，所以导致了网络上签订的合约有效性低，针对这一问题，本申请提供了一种基于区块链技术的智能合约的签署方法，包括：

系统配置阶段：

第三方签约平台下辖有若干个签约方和若干个合约方，签约方和合约方分别与监管平台信号连接；签约方、合约方，以及第三方签约平台分别连接至区块链网络；

预设加密算法，加密算法分别储存至签约方、合约方、第三方签约平台，以及区块链网络；

签约请求阶段：

签约方向第三方签约平台发送签约请求，第三方签约平台记录签约请求，并将签约请求发送给合约方；合约方根据签约请求将空白合约文件发送给第三方签约平台，第三方签约平台将空白合约和签约请求的相关信息上传至区块链网络并将空白合约发送至签约方；

合约签订阶段：

签约方阅读空白合约文件，并将阅读空白合约文件时所记录的意愿文件制作为数字水印，并将数字水印植入到空白合约文件中，以生成签约文件，然后将签约文件发送至第三方签约平台；其中，意愿文件为签约方在阅读空白合约文件时的音频信息或者视频信息；

合约认证阶段：

第三方签约平台将签约文件发送至合约方，合约方生成数字授权证书，然后将数字授权证书发送至第三方签约平台，第三方签约平台将数字授权证书发送给签约方和区块链网络。

在本申请所提出的技术方案中，当进行合约签订时，本申请引入了第三方的签约平台。无论是签约方还是合约方在交换信息，以及保存已经签约的文件时，这个第三方的签约平台都会将相应的信息上传到无法更改的区块链平台中。这样就确保了签约完成后，无论是合约方还是签约方都无法对签约文件进行任何修改，同时合约方也不能隐藏已经签约的文件。而对于第三方的签约平台来说，它也无法独立生成签约文件，从而保证了签约文件的不可更改性。针对签约方可能通过“未采取合理方式让用户注意”或“非本人操作”的方式来否认签约文件的真实性的问题，本申请在签约文件中加入了保证签约方在阅读空白合约文件时的意愿文件。这样就确保了签约文件中包含了用户在签约时的意愿信息，从而提高了签约文件的法律效力和有效性。

虽然区块链网络以其不可篡改性而著名，但其公开性也为签约内容的保密性带来了挑战。实际上，签约内容往往不能在大范围内公开。因此，在实际操作中，通常是由多台服务器组成一个区块链网络，即所谓的区块链联盟。然而，如果能够控制这个区块链联盟中的服务器，那么依然有可能篡改区块链网络中的信息，从而降低了签约文件的有效性。针对这一问题，本申请提供了以下的技术方案：

系统配置阶段具体包括如下步骤：

合约方和第三方签约平台分别提供若干个服务器组成区块链网络，并在区块链网络储存加密算法；

合约方根据加密算法生成一对秘钥（Hu，He），Hu为公钥，He为私钥，合约方将自身的公钥广播至区块链网络；

签约方根据加密算法生成一对秘钥（Qu，Qe），Qu为公钥，Qe为私钥，签约方将公钥发送至第三方签约平台，由第三方签约平台广播至区块链网络。

在本申请所提出的技术方案中，由于签约方通常是个体或用户，他们无法稳定地组成一个区块链网络。因此，为了避免合约方单独控制区块链网络而导致区块链上的信息被篡改，使用其他公共区块链网络又容易导致信息泄露的问题。本申请让第三方签约平台和合约方共同组成一个区块链网络，从而最大限度地避免了合约方独立控制区块链平台上的信息，为自己非法牟利。

第三方签约平台作为监管平台，需要具有更高的开放性和透明性，即监管平台上记录的信息需要对外公开。然而，对于具体的签约用户来说，他们不希望自己的签约内容被公开。为了解决现有合约签订监管方式中隐秘性不高的问题，本申请提供了以下技术方案：

进一步的，签约请求阶段包括如下步骤：

步骤21：签约方生成签约信息，签约信息包括请求人、请求内容，以及请求时间；

步骤22：签约方将签约信息用公钥Hu加密为签约请求，然后发送至第三方签约平台；第三方签约平台将签约请求发送至合约方；

步骤23：合约方用私钥He解密签约请求，得到签约信息，对签约信息核对之后，生成空白合约文件，然后将空白合约文件用公钥Qu加密，得到加密空白文件，然后将加密空白文件发送至第三方签约平台；

步骤24：第三方签约平台保存加密空白文件，并将加密空白文件的哈希值上传到区块链网络，签约方从第三方签约平台上下载加密空白文件。

在本申请所提供的方案中，当签约方和合约方通过第三方签约平台进行信息交流时，他们分别使用合约方和签约方的公钥进行加密。因此，上传到第三方签约平台的信息对于其他用户来说是加密的，无法了解合约的签订情况和签订内容。这种方法确保了签约信息的保密性和安全性。

在现有的合约签订过程中，用户（签约方）通常只是简单地勾选“我已经同意上述内容”，或在合约结尾填写一个签名。这种方式很难直观地表现出用户的真实意愿，导致在后续执行合约条款时，签约方容易以此为理由拒绝履行合约义务。针对这一问题，本申请提供了以下技术方案：

合约签订阶段包括如下步骤：

步骤31：签约方用私钥Qe解密加密空白文件，得到空白合约文件；

步骤32：记录签约方阅读空白合约文件时的视频信息，或者音频信息，将视频信息或者音频信息合并为加密信息矩阵；

步骤33：记录签约方阅读空白合约文件最后得到的签名，将该签名制作为水印信息嵌入到加密信息矩阵，得到数字水印；

步骤34：将数字水印嵌入到空白合约文件中，并用公钥Hu加密之后，得到签约文件，然后将签约文件发送至第三方合约平台。

在本申请所提出的技术方案中，本申请不仅仅收集签约方的签名信息，还会收集签约方在阅读空白合约文件时的视频信息或音频信息。通过将这些信息制作成数字水印，本申请能够更加直观地展现签约方的意愿。因此，在后期需要根据合约内容界定签约方和合约方的义务时，签约方无法以自身没有参与合约生成或不知晓合约内容为由，否认合约签订的真实性。这种方法提高了合约的法律效力和可执行性。

在现有的技术方案中，当签约方同意合约内容后，他们通常无法了解合约方的真实意愿，这会导致签约方丧失最后的反悔机会，或者很难确定合约何时正式开始。针对这一问题，本申请提供了以下技术方案：

进一步的，合约认证阶段包括如下步骤：

步骤41：第三方签约平台将签约文件发送至合约方；

步骤42：合约方用私钥He解密签约文件，得到嵌入了数字水印的空白合约文件；

步骤43：合约方将数字水印从空白合约文件中剥离出来，分别验证合约文件和数字水印，验证成功之后，将数字水印、合约方的数字签章、签约文件，用公钥Qu加密后生成数字授权证书，然后将数字授权证书发送至第三方签约平台；

步骤44：第三方签约平台将数字授权证书分别发送至签约方和区块链网络。

在本申请所提供的方案中，当签约文件到达合约方后，合约方会正式提供一个由数字签章制作的数字授权证书给签约方。这样，签约方可以直观地了解到合约的开始履行时间，并通过合约方的数字签章对合约方的真实性进行检测。这种方法增强了签约方的信心和安全感，同时也为合约的履行提供了可靠的保障。

在签约方签订合约时，他们通常无法将电子合约打印出来阅读，而是在移动终端（如手机）上阅读。因此，本申请可以在阅读时使用签约方的移动终端记录视频信息，并将其制作为水印嵌入到合约中。然而，仅仅嵌入一张图片到合约上是很难证明用户阅读了足够长的时间或用户在足够长的时间内都在阅读。如果将用户在阅读过程中产生的所有帧数的图像都嵌入到合约中，则会导致水印过多而难以提取，从而无法表现出用户的签订意愿。针对这一问题，本申请提供了以下技术方案：

步骤32中，将视频信息合并为加密矩阵时，采用如下步骤：

步骤321：通过签约方的移动终端获取用户在阅读空白合约文件时的视频信息，并将视频解析为n帧图片分别为，J

J

每个像素格用红、绿、蓝三个通道的值来表示，对于像素格J

步骤322：将每帧图片的像素格一一对应，并给每帧图片J

其中，W

步骤323：根据每帧图片的加权系数，得到合成图片

其中，

的绿色通道的值/>

的蓝色通道的值/>

步骤324：将合成图片

在本申请所提供的方案中，本申请将由多帧图片组成的视频信息合并为一张图片，并将剩余的信息制作成还原文件。在将水印嵌入到空白合约中时，实际上只有一张图片被嵌入，因此不会因为水印过多而导致图片失真。这样，嵌入到空白合约文件中的水印图片能够真实表达签约人的意愿。这种方法提高了签约文件的可靠性和法律效力。

进一步的，步骤33包括如下步骤：

步骤331：获取签约方在阅读完空白合约文件后的签名，并将签名制作为水印信息；

步骤332：提取加密矩阵中的特征点，得到第一特征点集，将水印信息嵌入到第一特征点集中，得到数字水印。

进一步的，步骤34包括如下步骤：

步骤341：提取空白合约文件中的特征点，得到第二特征点集，将数字水印植入到第二特征点集，得到签名合约文件；

步骤342，将签名合约文件、还原文件、第一特征点集，以及第二特征点集用公钥Hu加密得到签约文件，然后将签约文件发送至第三方合约平台。

进一步的：步骤42具体为：合约方用私钥He解密签约文件，得到签名合约文件、缓缓文件、第一特征点集，以及第二特征点集。

进一步的，步骤43包括如下步骤：

步骤431：合约方用第二特征点集在签名合约文件中分离出数字水印；

步骤432：合约方用第一特征点集在数字水印中分离出水印信息和加密矩阵；

步骤433：合约方对水印信息进行检验，同时用还原文件还原加密矩阵，得到多帧图片。

作为本申请的第二个方面，本申请的一些实施例提供了一种基于区块链技术的智能合约的签署系统，包括第三方签约平台，第三方签约平台与合约方共同组成一个区块链网络；采用前述的基于区块链技术的智能合约的签署方法来签订合约。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。

另外，贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，元件和元素不一定按照比例绘制。

在附图中：

图1为基于区块链技术的智能合约的签署系统的结构示意图。

图2为基于区块链技术的智能合约的签署方法的示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现， 而且不应该被解释为限于这里阐述的实施例。相反，提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。

下面将参考附图并结合实施例来详细说明本公开。

参照图1和图2， 一种基于区块链技术的智能合约的签署方法包括：系统配置阶段：第三方签约平台下辖有若干个签约方和若干个合约方，签约方和合约方分别与监管平台信号连接；签约方、合约方，以及第三方签约平台分别连接至区块链网络。

预设加密算法，加密算法分别储存至签约方、合约方、第三方签约平台，以及区块链网络。

系统配置阶段具体包括如下步骤：合约方和第三方签约平台分别提供若干个服务器组成区块链网络，并在区块链网络储存加密算法。

其中，在目前的电子合约的运用场所中，合约方一般都是网络公司，属于合约乙方，主要是起到履行合约的相关条款和任务。签约方一般都是个人，或者说属于网络公司的用户，其属于合约的甲方，主要是用于支付乙方相应费用的一方。总体上而言，合约方对于单独的签约方而言，其体量更加庞大，所以合约方和第三签约平台可以共同构建并维护区块链网络。实际上，在不引入第三方签约平台的情况下，在合约签订过程中，所产生的相关文件，也依旧需要合约方保存和维护。

合约方根据加密算法生成一对秘钥（Hu，He），Hu为公钥，He为私钥，合约方将自身的公钥广播至区块链网络。

签约方根据加密算法生成一对秘钥（Qu，Qe），Qu为公钥，Qe为私钥，签约方将公钥发送至第三方签约平台，由第三方签约平台广播至区块链网络。

加密算法可以是椭圆加密算法。具体的加密过程这里不再解释，该部分内容为区块链技术中非常常见的技术。

进一步的，为了避免在区块链网络上储存过多的数据，还需要预先配置哈希算法，用于计算需要保存到区块链网络中的哈希值，从而在区块链网络上仅仅保存哈希值，对应的文件保存在第三方签约平台上。

签约请求阶段：

签约方向第三方签约平台发送签约请求，第三方签约平台记录签约请求，并将签约请求发送给合约方；合约方根据签约请求将空白合约文件发送给第三方签约平台，第三方签约平台将空白合约和签约请求的相关信息上传至区块链网络并将空白合约发送至签约方。

具体的，签约请求阶段包括如下步骤：

步骤21：签约方生成签约信息，签约信息包括请求人、请求内容，以及请求时间。

签约信息就是签约方向合约方申请的相关信息；其中，请求人就需要包括对应的账户信息，在一些实施方式中，还需要包括账号和密码。请求内容，则是签约方所需要签订的合约内容。请求时间，则是生成这次签约信息的时间。

步骤22：签约方将签约信息用公钥Hu加密为签约请求，然后发送至第三方签约平台；第三方签约平台将签约请求发送至合约方。

步骤23：合约方用私钥He解密签约请求，得到签约信息，对签约信息核对之后，生成空白合约文件，然后将空白合约文件用公钥Qu加密，得到加密空白文件，然后将加密空白文件发送至第三方签约平台。

步骤24：第三方签约平台保存加密空白文件，并将加密空白文件的哈希值上传到区块链网络，签约方从第三方签约平台上下载加密空白文件。

在步骤24中，加密空白文件按照之前配置的哈希值的计算方式，在计算得到哈希值之后，将哈希值上传到区块链网络上，然后加密空白文件就能够留存在第三方签约平台上。如此，采用这种方式，可以避免签约方以发送了签约请求，但是未收到后续的空白合约文件为由，对合约方进行不法侵害。

进一步的：第三方签约平台因为无法知道签约方和合约方上传的信息中的具体内容，而第三方签约平台又会存在大量的签约信息进行交换。所以，第三方签约平台将无法很好的对信息进行中转。主要是，第三方签约平台不知道将信息发送给哪个签约方。

为此：在第三方签约平台接收到签约请求之后，则会给该签约请求生成一个编号；如此，签约方和合约方在向第三方签约平台，上传对应的信息时，都会发送该编号。进而，第三方签约平台能够根据这个编号，来发送文件。

例如，签约方101生成了一个签约请求给第三方签约平台之后，第三方签约平台会给这个签约请求生成一个编号10a，然后将编号10a和签约请求都发送给合约方。合约方，在生成了加密空白文件之后，也会附带对应的编号10a。所以，第三方签约平台就能够根据这个编号10a，将接收到的加密空白文件发送给签约方101。相应的后续步骤的中需要交换的文件或者说信息，也是采用这种方式进行交换。

合约签订阶段：

签约方阅读空白合约文件，并将阅读空白合约文件时所记录的意愿文件制作为数字水印，并将数字水印植入到空白合约文件中，以生成签约文件，然后将签约文件发送至第三方签约平台；其中，意愿文件为签约方在阅读空白合约文件时的音频信息或者视频信息。

步骤31：签约方接收加密空白文件，签约方用私钥Qe解密加密空白文件，得到空白合约文件。

空白合约文件就是合约方和签约方所需要签订的合约内容。在表现形式上，其实就是一份图片文件。

步骤32：记录签约方阅读空白合约文件时的视频信息，或者音频信息，将视频信息或者音频信息合并为加密信息矩阵。

步骤32中，签约方在签订合约时，是通过手机这类终端来进行查阅空白合约文件，而手机是有前置摄像头的。所以在签约方查阅空白合约文件时，打开前置摄像头，捕捉这段视频信息，所以就能够表明了用户至少对智能合约查阅了15s，或者预设的时间，从而能够反映出用户的意愿。

具体的，在步骤32中，如果需要处理视频信息时，采用如下方法：

步骤321：通过签约方的移动终端获取用户在阅读空白合约文件时的视频信息，并将视频解析为n帧图片分别为，J

步骤322：将每帧图片的像素格一一对应，并给每帧图片J

其中，W

步骤323：根据每帧图片的加权系数，得到合成图片

步骤324：将合成图片

举例说明，假设3张图片，每张图片都有4个像素格，每个像素格都有红、绿、蓝三个通道的值，如下所示：

图片1：R11=255、 G11=0、B11=0；这是第1张图片，第1个像素格的三个通道的值。

R12=0、G12=255、B12=0；这是第1张图片，第2个像素格的三个通道的值；

R13=0、G13=0、B13=255；这是第1张图片，第3个像素格的三个通道的值；

R14=255, G14=255, B14=0；这是第1张图片，第4个像素格的三个通道的值；

图片2：R21=0、 G21=255、 B2,1=0；

R22=255、G22=0、B22=0;

R23=0、G23=0、B23=255;

R24=0、 G24=255、 B24=255；

图片3：R31=0、 G31=0、 B31=255;

R32=255、 G32=0、 B32=0;

R33=0、 G33=255、 B33=0;

R34=0、 G34=0、 B34=255；

将这三张图片合并为一帧，并假设每张图片的权重都为1，那么合并后的图像中每个像素格的红、绿、蓝通道值如下所示：

R'1=(255+0+0)/3=85, G'1=(0+255+0)/3=85, B'1=(0+0+255)/3=85；R'2=(0+255+255)/3=170, G'2=(255+0+0)/3=85, B'2=(0+0+0)/3=0；R'3=(0+0+0)/3=0, G'3=(0+0+255)/3=85, B'3=(255+0+255)/3=170；R'4=(255+0+0)/3=85, G'4=(255+255+0)/3=170,B'4=(0+255+0)/3=85。

在上述步骤中，采用了平均值法，将多帧的视频图像，合成为了一张图片。除开采用这种方式之外，还可以采用其余的方式来进行合成。并且结合上述内容可见，本申请所需要的加密信息矩阵，其实就是一个由像素点组成的信息矩阵。如此，可以在这个矩阵上嵌入相应的水印信息。

实际上，对于音频文件，也同样能够转化为加密信息矩阵；具体的，对于音频文件，可以用小波变化的方式，将音频信息转化为加密矩阵。

音频文件的方案，适用于签约方缺少前置摄像头的场景，在签约方无法提供前置摄像头的情况下，可以录制签约方的一段语音作为意愿文件。然后将这段音频文件用小波变化为加密矩阵。小波变化将音频文件处理为矩阵信息，为本领域的常用手段。这里不在赘述其细节。

步骤33：记录签约方阅读空白合约文件最后得到的签名，将该签名制作为水印信息嵌入到加密信息矩阵，得到数字水印。

步骤33包括如下步骤：

步骤331：获取签约方在阅读完空白合约文件后的签名，并将签名制作为水印信息；

步骤332：提取加密矩阵中的特征点，得到第一特征点集，将水印信息嵌入到第一特征点集中，得到数字水印。

步骤34：将数字水印嵌入到空白合约文件中，并用公钥Hu加密之后，得到签约文件，然后将签约文件发送至第三方合约平台。

步骤34包括如下步骤：

步骤341：提取空白合约文件中的特征点，得到第二特征点集，将数字水印植入到第二特征点集，得到签名合约文件。

步骤342，将签名合约文件、还原文件、第一特征点集，以及第二特征点集用公钥Hu加密得到签约文件，然后将签约文件发送至第三方合约平台。

在步骤33和步骤34中，为现有技术中，水印的植入过程。在步骤34和步骤35中，在提取图片中的特征点时，可以采用SIFT算法，也可以采用SURF算法来进行特征提取。在特征提取之后，就能够将相应的水印信息植入到特征点的位置。

合约认证阶段：

第三方签约平台将签约文件发送至合约方，合约方生成数字授权证书，然后将数字授权证书发送至第三方签约平台，第三方签约平台将数字授权证书发送给签约方和区块链网络。

进一步的，合约认证阶段包括如下步骤：

步骤41：第三方签约平台将签约文件发送至合约方。

步骤42：合约方用私钥He解密签约文件，得到嵌入了数字水印的空白合约文件。

步骤43：合约方将数字水印从空白合约文件中剥离出来，分别验证合约文件和数字水印，验证成功之后，将数字水印、合约方的数字签章、签约文件，用公钥Qu加密后生成数字授权证书，然后将数字授权证书发送至第三方签约平台。

步骤44：第三方签约平台将数字授权证书分别发送至签约方和区块链网络。

步骤43包括如下步骤：

步骤431：合约方用第二特征点集在签名合约文件中分离出数字水印。

步骤432：合约方用第一特征点集在数字水印中分离出水印信息和加密矩阵。

步骤431和步骤432中，水印信息分离的过程，其实就是将水印植入过程进行逆运算。因为已经知道了水印的植入位置，所以能够将水印剥离出来。相应的水印分离方式，也与前文相同，为本领域的常用技术手段。

步骤433：合约方对水印信息进行检验，同时用还原文件还原加密矩阵，得到多帧图片。

还原文件中已经包含了原始帧的图像，还原得到的多帧图片，主要是用于对比嵌入在合约文件中的图片，是否为原始的视频信息。

参考图1，实施例2：一种基于区块链技术的智能合约的签署系统，包括第三方签约平台，第三方签约平台与合约方共同组成一个区块链网络；采用前述的基于区块链技术的智能合约的签署方法来签订合约。

以上描述仅为本公开的一些较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开的实施例中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开的实施例中公开的（但不限于）具有类似功能的技术特征进行互相替换而形成的技术方案。