2019 年 3 月

第 34 卷,第 3 期

此文章由机器翻译

[区块链]

使用 Azure 区块链开发工具包中的智能合同来验证电子文档

通过Stefano Tempesta |2019 年 3 月

区块链网络中的智能协定引入已创建缺少的区块链在早期迭代中的业务逻辑层。智能协定提供适用于事务的条件逻辑之前就会执行它们, 的功能。尽管如此,智能协定只能对存储在区块链数字账本的数据进行操作。业务流程,但是,很少运行在隔离。通常需要与外部系统和设备的数据集成。

例如,进程可能包括分布式账本,它采用数据来源于外部系统、 服务或设备上启动的事务。外部系统可能需要在响应的验证逻辑的智能协定由引发的事件做出反应。本文介绍如何实现自动化文档签名和验证 SharePoint 使用最近发布的 Azure 区块链开发工具包中的工作流 (aka.ms/bcdevkit) 持久保存文件的哈希和在区块链的元数据数字分类帐。

Azure 区块链开发工具包

版本的 Azure 区块链开发工具包,构建基于 Microsoft 的无服务器技术,表示在企业环境中的区块链技术的采用率里程碑。借助区块链开发工具包,现在可以生成与最好的 Microsoft 和第三方软件应用程序无缝集成区块链解决方案。如前文所述上其发行说明,该工具包的初始版本设置优先级与三个关键主题相关的功能: 连接接口、 将数据和系统集成和部署智能协定和区块链网络。

连接包括通信通道,例如移动和 Web 应用、 短信和语音,以及 IoT 设备,甚至聊天机器人。与业务线应用程序集成跨多个系统,包括 SharePoint、 OneDrive for Business,Dynamics 365 开放源代码和任何已启用 API 的平台,以及如文件系统、 FTP 服务器或 SQL 数据库的旧版协议。智能协定和区块链网络的部署将帮助企业软件开发的主流区块链技术和区块链软件开发实践中向管理和 DevOps。

结合使用 Azure 逻辑应用和流,提供包括到 Microsoft 和第三方系统和服务的 200 多个连接器的工作流的可视化设计环境区块链开发工具包。配合使用,它们大大简化开发的端到端区块链应用程序访问和关闭的链上数据、 处理事件生成的数字账本,并将它们无缝集成的解决方案的 Azure 生态系统。我们来探讨企业内容管理上下文中的实际应用程序。

进行数字资产签名

使用区块链,您可以假设它们正在保护被删除、 篡改和修订的世界文档是数字的代码中嵌入和透明的共享数据库中存储。在这个世界中每个协议、 每个进程、 每个任务和每个付款将具有数字的记录和签名,无法进行标识、 验证、 存储和共享。像律师、 代理和机构可能不再是必要的中介。个人、 组织和机自由地将 transact 和什么冲突地彼此进行交互。这是区块链的巨大潜力。

内容分散化和分发的潜在应用程序是巨大的。使用单一的、 不可变的和可验证记录存储,将拥有的人员,其数字标识和记录-思考的标识或居住的文档、 医疗记录、 教育或专业的证书和许可证。所有这些文档和其元数据可以在区块链上发出并进行数字签名。没有更多虚设认证,没有详细程度 mills,没有更多"photoshopped"文档。

例如,学生,可能适用于进一步研究、 作业或移民到另一个国家/地区;并在该过程可能需要证明自己研究其级别或对语言参加大学的知识。实体等招聘、 雇主、 政府和大学可以验证学生的凭据,而不依赖于中央机构 — 只需几分钟,或者使用任何其他中间方。

图 1介绍所述的方案。证书颁发机构颁发的如教育 institute (1) 存储在集中的文档管理服务器 (2),或如 IPFS (ipfs.io) 的分布式的文件系统上,并使用加密函数签名。我将在本文后面会进入 IPFS 有关的详细信息。内容哈希的证书的元数据哈希是存储在区块链数字账本 (3) 上并存储此信息 (4) 的智能协定地址作为附加到用户的数字标识。这表示一种非可疑的方式标识文档的唯一真实性标志。

签名的执行组件和进程
图 1 的签名的执行组件和进程

一种常见模式是生成数字资产的唯一哈希和描述它的元数据的唯一哈希。这些哈希值随后存储在区块链中。如果文档的真实性受到过质疑,关闭链文件可以在更高版本的时间和哈希链上值比较的重新经过哈希处理。如果哈希值匹配,该文档是否可信,但如果修改了只需在文档中的字符,哈希不匹配,从而明显发生了更改。

生成签名的逻辑应用流

让我们看看此工作流中使用 Azure 逻辑应用的潜在实现。逻辑应用流将生成文档和元数据的哈希,并存储在先前 SharePoint 和后一种使用以太坊连接器发布以太坊网络上作为 Azure 区块链开发工具包的一部分。哈希值的计算是基于.NET 运行时堆栈的 Azure 函数中完成的。该函数取决于 HTTP 触发器模板,并立即收到 HTTP 请求将会运行它。

中的代码图 2实现 ComputeHashFunction Azure 函数以计算哈希使用 SHA256 算法。阅读后请求正文中的 Run 方法,该函数计算使用 SHA256 库 System.Security.Cryptography 命名空间中可用的哈希。UTF8 编码字符串形式返回哈希值。

图 2 ComputeHashFunction

public static class ComputeHashFunction
{
  [FunctionName("ComputeHashFunction")]
  public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function,
      "get", "post", Route = null)] HttpRequest req, ILogger log)
  {
    string requestBody =
      await new StreamReader(req.Body).ReadToEndAsync();
    string hash = ComputeHash(requestBody);
    return (ActionResult)new OkObjectResult(hash);
  }
  private static string ComputeHash(string data)
  {
    // Create a SHA256 hash
    using (SHA256 sha256 = SHA256.Create())
    {
      byte[] bytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(data));
      // Convert the byte array to a string
      return Encoding.UTF8.GetString(bytes);
    }
  }
}

一个新文档上载到 SharePoint 站点时,会触发逻辑应用流。此事件的处理由一个"时创建一个文件..."SharePoint 连接器上的操作 (如下图中所示图 3)。若要配置此操作,对于 SharePoint,输入你的身份验证凭据后,必须指定要监视的新文件和上传文件的特定文件夹的 SharePoint 站点的站点地址。此外可以设置的频率轮询此文件夹和检查新文件。合理设置为每分钟一次检查。

在 SharePoint 中的文件创建事件处理逻辑应用操作
图 3: 处理在 SharePoint 中的文件创建事件的逻辑应用操作

流的下一步,如前面预期上, 传的文件的内容和元数据的哈希。我实现了一个 Azure 函数的哈希函数,只需调用此函数是选择从 Azure Functions 连接器的 Azure 函数操作。一旦从可用函数列表中选择 ComputeHashFunction,将提示您指定将传递给该函数本身在请求正文。这是一个 JSON 对象,将输入中的函数,获取其哈希值作为输出传输。我已定义为文件元数据,以下属性,如中所示图 4: contentType,etag,id、 名称和路径。

哈希函数的请求正文中的属性
图 4 个属性中请求正文的哈希函数

在上一步需要进行哈希文件元数据。现在我必须哈希也要保留区块链网络中为不可变状态的整个文件内容。如之前,添加另一个选择的 Azure 函数操作从 Azure Functions 连接器,但这次,而不是多个文件属性,选择文件内容。

只要获取文件元数据和文件内容的哈希值,就可以将其存储在区块链网络上。为此,我使用 Azure Blockchain Workbench (aka.ms/abcworkbench) 用作智能协定以太坊上运行的运行时环境。Blockchain Workbench 应该以支持多个区块链平台,但现在我将坚持使用以太坊。

可以通过将一条消息发送到 Azure 服务总线 Blockchain Workbench 解决方案的一部分部署获得到数字账本的访问权限。类似于逻辑应用操作的外部系统可以与通过将一条消息发送到服务总线 Blockchain Workbench 中托管的智能协定通信。由 Blockchain Workbench 运行时提取消息并创建新的区块链事务时,它包含的消息。与以太坊通信可能仅由生成事务调用智能协定,如下图中所示图 5

将消息发送到智能协定
图 5 将消息发送到智能协定

若要将消息从逻辑应用流发送到服务总线可以在服务总线连接器上使用发送消息操作。连接名称和连接字符串由标识与 Azure 服务总线的连接。您可以输入任何方便的名称作为连接名称,并从其部署在 Azure 门户获取服务总线连接字符串。消息将发送到服务总线还需要以下参数:

  • requestId:逻辑应用操作生成的请求唯一标识符
  • processedDateTime:正在发送的请求的时间戳
  • userChainIdentifier:已部署的以太坊网络中的用户地址
  • 应用程序名称:以太坊的调用的智能协定的名称
  • workflowName:Blockchain Workbench 对其调用工作流的名称

我通过使用初始化变量操作从变量连接器为逻辑应用流中的变量定义这些参数。RequestId 变量可以设置为 guid,这是一个表达式,生成一个唯一 GUID。ProcessedDateTime 变量可以设置为 utcNow,表示当前的协调世界时。对于 userChainIdentifier,可以在有权运行智能协定,而根据名称和智能协定,用于处理此事务的工作流定义应用程序名称和 workflowName Blockchain Workbench 来输入用户的地址。

下一节介绍用于处理由逻辑应用流发送这些消息的智能协定。图 6总结了消息正文,采用 JSON 格式,将发送到服务总线。< 锐角尖括号 > 中的表达式必须替换为相应的值。

图 6 发送到 Azure 服务总线的消息的结构

{
  "requestId": "<The requestId variable>",
  "userChainIdentifier": "<User address in Azure Blockchain Workbench>",
  "applicationName": "<Smart contract name>",
  "workflowName": "<Smart contract workflow name>",
  "parameters": [
    {
      "name": "registryAddress",
      "value": "<Contract address in Azure Blockchain Workbench>"
    },
    {
      "name": "fileId",
      "value": "<File identifier>"
    },
    {
      "name": "location",
      "value": "<File path>"
    },
    {
      "name": "fileHash",
      "value": "<File content hash>"
    },
    {
      "name": "fileMetadataHash",
      "value": "<File metadata hash>"
    },
    {
      "name": "contentType",
      "value": "<File content type>"
    },
    {
      "name": "etag",
      "value": <File entity tag>
    },
    {
      "name": "processedDateTime",
      "value": "<The processedDateTime variable>"
    }          
  ],
  "connectionId": 1,
  "messageSchemaVersion": "1.0.0",
  "messageName": "CreateContractRequest"
}

用于处理数字资产智能协定

首先,我将巩固数字资产不存储在区块链上的消息。文件元数据和内容的哈希值。在本文中,我将介绍文档的存储在 SharePoint 上,这是集中式的服务。在"纯"区块链部署中,可能想要获取的存储服务还分散化。行星文件系统 (IPFS) 是对等超媒体协议 (如我之前提到的),可提供分散式的文件存储。与 IPFS 集成不在范围内的这篇文章,但如果您想要了解此技术可帮助删除集中管理的存储,不是区块链中的块的一部分,可以参考第 9 频道上的"IPFS in Azure"视频 (bit.ly/2CURRq0)。

用于运行我的智能协定使用 Azure Blockchain Workbench,我需要两个文件:

  • FileContract.sol 来描述自身,Solidity 编程语言中的智能协定。
  • 若要配置 Azure Blockchain Workbench,为应用程序中加载的工作流的 FileContract.json。

FileContract 智能协定描述通过基于传递到通过 Azure 服务总线 Blockchain Workbench 通过逻辑应用发送的消息中的值,其元数据文件。下面是源代码的智能协定,用于定义这些参数的代码片段:

contract FileContract
{
  // File metadata
  string public FileId; // File identifier
  string public Location; // File path
  string public FileHash; // File content hash
  string public FileMetadataHash; // File Metadata Hash
  string public ContentType; // File content type
  string public Etag; // File entity tag
  string public ProcessedDateTime; // Timestamp
  address public User; // User address

若要将文件元数据存储在区块链,我需要定义,按如下所示的文件结构:

struct File {
  string FileId;
  address FileContractAddress;
}

文件实体都由其文件 ID 和 FileContract 智能协定包含的元数据的区块链上的地址标识。此结构保存在专用集合定义为字典,其键与 FileId 字符串。密度中的映射关键字定义为字典和其键和值类型,如下所示:

mapping(string => File) private Registry;

若要保存的文件实体 (其 ID 和元数据),我只需将构成值添加到注册表字典中的 Save 方法中。为简单起见,我省略了任何必要控件上的文件 ID 和合同地址的有效性,并且是否已存在文件在注册表中。代码如下:

function Save(string fileId, address fileContractAddress) public
{
  Registry[fileId].FileId = fileId;
  Registry[fileId].FileContractAddress = fileContractAddress;
}

验证过程

需要与第三方验证其证书的用户为此共享的真实性令牌 (即文件协定地址),其中包含所有必要的信息确认文档是否存在并且是可信并不假冒。图 7介绍了参与方以及验证过程中涉及的操作。用户检索证书来验证从其位置 (1) 并启动新事务区块链网络上的传输的真实性令牌 (2) 验证颁发机构。颁发机构获取的签名的内容和证书的元数据验证 (3),其存储在不可变的数字账本上,,然后将其关闭链副本中的等效哈希值进行比较。如果值匹配,该文档是已验证 (4)。

验证执行组件和过程
图 7 验证执行组件和过程

一旦签名并验证文档和非结构化的数据 — 和其内容和元数据的哈希存储在区块链 — 创建不可变和独立的可验证记录的事务。此过程称为证明存在和证明数字资产的真实性。

存在的概念是指创建的方式更改日期和时间戳; 如果为特定对象。这意味着,您可以证明某些信息对象 —,例如电子邮件、 文档或图像 — 在时间中存在某个特定点。

对象是可信的真实性证明断言 — 也就是说,它并未已更改,因为它已存储在指定的时间即时。这被通过对对象进行数字签名,从而创建哈希,它的唯一标识符。然后标识符获取提交到区块链分布式的分类帐,并在事务获取加盖时间戳以及。因为区块链中的每个条目是不可变的这意味着必须在时间中此特定对象存在某个特定点的概念。

使用相同的方法,对象可以对其验证和验证。类似于我针对签名过程所述的流创建的唯一标识符,并验证区块链分类帐针对此唯一标识符。如果没有匹配项,智能协定将返回原始的哈希值。如果没有,正在验证的文档并不完全相同的原始副本,不应隐式受信任。因此,您可以,任何一定更高版本,能够证明文档或任何数字的对象,可信和现有在某些时刻。

FileContract 智能协定公开的 GetFile 方法,以便在输入中提供的文件 ID 返回其协定地址上的区块链。从文件协定地址就可以获取文件内容和元数据哈希值和比较它们的哈希值的文档进行验证,如下所示:

function GetFile(string fileId) public constant
returns(address fileContractAddress)
{
  return Registry[fileId].FileContractAddress;
}

总结

为何使用区块链进行签名和验证数字资产已存在并得到广泛应用行业中的一种电子签名的解决方案时?简单地说,区块链中删除对中央证书颁发机构或中部时间戳服务器的需要,并启用存储在区块链生存独立于被签名的对象上的数字签名。对于并行签名和独立验证,无论对象本身的机会,这将打开。

传统电子签名解决方案存储在文档内的数字签名。这意味着需要检查在文档被签名的任何人都将在文档中具有完全读访问权限的所有内容。此外,由于使用每个签名更改文档,签名中并行的文档不可能 — 每个人都需要按顺序对文档进行签名。通过签名区块链上的文档,对象本身不改变签名,并且这使您可以并行文档签名和实现业务规则,根据要求、 4 眼睛、 大多数投票、 资历和类似的内容。

最后,但不是太重要的是,您可以注册多个操作在区块链序列中。每个注册链接到特定的用例、 文档和相关,方创建的事务链所执行的任务: 的可审核线索。此审核记录可以通过提供透明度、 法规遵从性的被授权第三方进行验证,并且最重要的是信任。

若要了解有关 Azure 区块链开发工具包的详细信息,可大量视频第 9 频道上下找到"块交谈"显示 (aka.ms/bcblocktalk)。如果您愿意,您还可随时保持最新 Azure 区块链产品小组的最新公告按照 @MSFTBlockchain Twitter 句柄 (twitter.com/MSFTBlockchain)。

Azure 区块链开发工具包项目欢迎贡献和建议。大多数参与需要同意声明具有的权限,实际执行操作,授予 Microsoft 使用您的发布内容的权利参与者许可协议 (CLA)。当提交拉取请求时,CLA 机器人将自动确定您是否需要提供 CLA,并相应地修饰请求 (即,添加标签或到你的代码注释)。


Stefano Tempesta是 Microsoft 区域总监,MVP AI 和业务应用程序和区块链委员会的成员。在国际 IT 会议,包括 Microsoft Ignite 和技术大会上发表演讲 Tempesta 的兴趣扩展到区块链和 AI 相关技术。他创建了"Blogchain 空间"(blogchain.space),有关区块链技术博客的 MSDN 杂志 》 和 MS Dynamics 世界中,将写入,并将发布 Azure AI 库中的机器学习试验。

衷心感谢以下技术专家对本文的审阅:Jonathan Waldman