4种主流区块链应用架构「区块链应用系统架构」

区块链有各种各样的应用场景，从金融到去中心化互联网。不过 绝大多数用例都可以归纳为几种模式。在这篇文章中，我们将介绍 基于区块链的去中心化应用的常见的4种架构模式。

以太坊教程链接： Dapp入门 | 电商Dapp实战 | Token实战 | Php对接 | Java对接 | Python对接 | C#对接 | Dart对接

IAM环境中包括很多用户和服务提供商。IAM系统为每个用户分配 一个账户以及一组访问能力，用户基于其账户权限及访问能力访问提供商 的服务。可以采用以如下方式利用W3C的DID规范和W3C的可验证声明规范：

假设Alice需要一个身份（DID，唯一标识符）。如上图所示，为了创建一个 新的DID，Alice需要在区块链上创建一个数据项，该数据项中包含了随机 生成的标识符、指向其个人档案数据的链接、以及其个人档案数据的哈希。 档案数据中包含了公钥以及一组可验证的声明，所生成的随机标识符现在 成为Alice的DID，因为只有她持有与公钥对应的私钥。

可验证声明是由授权机构签名的通证，创建者同时也会在区块链上记录 声明数据的哈希，类似于DID的实现方式。

Alice首先前往权威机构获取可验证声明。例如，个人注册部可能是姓名、 地址、出生日期这些信息的负责机构。假设权威机构签发了可验证的声明， Alice首先展示其对DID的所有权，然后提交对可验证声明的请求。为了更新 其个人档案数据，Alice需要在区块链中添加一个新的数据项，其中包含 更新后的个人档案数据的新的哈希。

在验证Alice对DID的所有权时使用的挑战-应答协议，验证者会生成一个随机 种子，然后使用ALice的公钥进行加密，接下来Alice需要使用其私钥解密种子 以展示其确实持有公钥对应的私钥。

另一个希望识别Alice身份的用户或机构，例如Bob，首先会从Alice处接收到 DID，然后从区块链上读取所有该DID相关的数据并进行验证。Bob可以同样的 挑战-应答方式验证Alice的身份。

我们可以在这一架构模式上处理大多数的IAM用例。例如，我们可以通过 可验证声明来控制访问权限，确保只有具备某些特征的用户可以访问区块链系统。

多方协同交易，各方的活动需要无争议的记录。可以在区块链上记录活动以及其哈希， 因此不会有争议。

例如，假设Alice想要缴税。税务系统服务器接受了支付申请，创建了数字收据，并在 区块链上记录该活动的哈希，然后将收据发送给Alice。Alice可以通过计算区块链上 存储数据的哈希来进行验证。此后，Bob不能质疑该收据的有效性，因为收据的哈希 和时间都记录在区块链上。

如果存在大量的活动，可能需要考虑区块链的性能局限性。因此，有些实现可能 会记录若干个活动的哈希，而不是每个活动记录一个哈希。

注册表是一组数据的集合，可供搜索和查询。集市是一种允许用户购买服务或 产品的注册表，它使用数据项来标识服务或产品。例如，一个注册表可能是一组可用 API的目录。建议模式的运作机制如下：

当一个用户更新注册表后，客户端会在区块链上记录变化。如果更新中的数据很大， 区块链记录中可能包含指向数据的链接。如果存储在注册表中的数据需要修改，那么 注册表客户端会在区块链上添加一个新包含了修正后的信息的记录。

在上图中，每个用户都有一个注册表客户端运行在本地机器上，每个注册表客户端 从区块链读取更新后的记录，并利用记录中的哈希进行验证。

区块链可以很好地实现一个服务市场，因为同一个服务可能会出售很多次。然而， 考虑到性能的问题，基于区块链的集市并不适合那些只能出售一次的商品。

多个用户都要遵守合约，即可运行的智能合约。在指定时刻，合约会经历 状态迁移，每个人都认可合约的当前状态。智能合约是区块链技术的一部分， 很多区块链都支持，例如以太坊。

我们可以利用智能合约来跟踪真实世界中的物品的所有权：

在上图中，汽车生产商记录车辆持有人的DID和公钥。当所有权变化之后，车辆 持有人在区块链上添加一条新的记录。当检查车辆所有权时，从区块链提取所有 记录并通过检查用户公钥进行验证。链上记录的最后一个持有人就是车辆的当前 持有人。

原文链接：http://blog.hubwiz.com/2020/01/23/dapp-architecture-patterns/