去中心化 去区块链_基于区块链的去中心化应用的四种架构模式候选

去中心化 去区块链

Blockchain has a diverse set of use cases, ranging from finance to a decentralized Internet. However, most blockchain use cases can be implemented using relatively few patterns. For example, A Pattern Collection for Blockchain-based Applications provides a list of 15 Blockchain patterns.

区块链有一系列用例，从金融到去中心化互联网。 但是，大多数区块链用例可以使用相对较少的模式来实现。 例如， 基于区块链的应用程序的模式集合提供了15种区块链模式的列表。

Fine-grained patterns, such as described above, are useful. However, system design needs a much higher level of abstractions. It is useful also to have more coarse-grained macro patterns, which we call architecture patterns. This post describes four such architecture patterns.

如上所述的细粒度图案是有用的。 但是，系统设计需要更高级别的抽象。 拥有更多粗粒度的宏模式(也称为架构模式)也很有用。 这篇文章描述了四种这样的架构模式。

Let’s get started. To describe patterns, I will use the template described in by Aleksandra Tešanovic in What is a Pattern?

让我们开始吧。 为了描述模式，我将使用AleksandraTešanovic在“ 什么是模式 ？”中描述的模板。

IAM的体系结构模式。 (Architecture Pattern for IAM.)

Context: IAM environments include many users and service providers. IAM systems give each user an account and set of capabilities enabling users to go to service providers, demonstrate their ownership of accounts, and then receive services based on their capabilities.

背景信息： IAM环境包括许多用户和服务提供商。 IAM系统为每个用户提供一个帐户和一组功能，使用户可以前往服务提供商，展示其帐户所有权，然后根据其功能接收服务。

Forces: Need to implement a decentralized IAM environment where a single rogue user or few users can’t significantly affect the system.

力量：需要实现一个分散的IAM环境，在该环境中，一个恶意用户或几个用户不会严重影响系统。

Solution: Proposed pattern candidate uses World Wide Web Consortium (W3C) DID specification and W3C Verifiable Claims specification in the following manner.

解决方案：建议的模式候选者以下列方式使用万维网联盟(W3C)DID规范和W3C可验证声明规范。

Let’s assume Alice needs an identity (DID, which is a unique identifier). As shown by the figure for creating a new DID, Alice creates an entry in the blockchain. This entry includes a randomly generated identifier, a link to the repository with her profile data, and a hash of the profile data. The user profile contains a public key and a set of verifiable claims. The generated random identifier now becomes Alice’s DID because only she owns the private key that corresponds to the public key.

假设Alice需要一个身份(DID，这是唯一的标识符)。 如创建新DID的图所示，Alice在区块链中创建了一个条目。 该条目包括随机生成的标识符，带有她的个人资料数据的存储库链接以及个人资料数据的哈希。 用户个人资料包含一个公共密钥和一组可验证的声明。 生成的随机标识符现在成为Alice的DID，因为只有她拥有与公钥相对应的私钥。

Verifiable claims are delegation tokens signed by a competent authority. The creator also records them in a blockchain together with the hash of the claim in a manner similar to the DID.

可验证的索赔是由主管当局签名的授权令牌。 创建者还以类似于DID的方式将它们与索赔的哈希一起记录在区块链中。

Alice obtains the verifiable claims in the first place by going to authorities. For example, the department of personal registration or equivalent is the proper authority for verifiable claims of name, address, and date of birth. Assuming authorities issue verifiable claims, Alice first demonstrates her ownership of the DID uses a challenge-response-protocol. Then she submits requests for verifiable claims for her attributes, which may, for example, include her name, address, degree, and date of birth. To update her profile data, Alice will add a new entry to the blockchain with a new hash of the profile.

爱丽丝首先去找当局以核实索赔。 例如，个人注册部门或同等部门是对名称，地址和出生日期进行可验证的声明的适当权限。 假设当局发布了可验证的索赔，爱丽丝首先使用质询-响应协议证明她对DID的所有权。 然后，她针对其属性提交可验证声明的请求，例如，可以包括她的姓名，地址，学位和出生日期。 为了更新她的个人资料数据，Alice将使用个人资料的新哈希将新条目添加到区块链。

In the challenge-response-protocol, the validator generates a random seed, encrypts it using Alice’s public key, and then challenges Alice to demonstrate that she has the private key by decrypting the encrypted seed. Since Alice has the private key, she must be the owner of the DID.

在质询-响应协议中，验证器生成一个随机种子，使用Alice的公钥对其进行加密，然后向Alice挑战以通过解密加密的种子来证明她具有私钥。 由于爱丽丝拥有私钥，因此她必须是DID的所有者。

A different user or an organization (authenticator), Bob, who wants to identify Alice, first receives the DID from Alice, read all entries related to that DID from the blockchain, retrieve Alice’s profile data, and verify them. Bob can verify the identity of Alice (identification) again using challenge-response-protocol. Then Bob can confirm the verifiable claims and be assured that the claims about Alice are true.

要标识Alice的另一个用户或组织(验证者)，Bob首先从Alice接收DID，从区块链读取与该DID相关的所有条目，检索Alice的配置文件数据并进行验证。 鲍勃可以使用质询-响应协议再次验证爱丽丝的身份(标识)。 然后，Bob可以确认可验证的主张，并确信有关Alice的主张是真实的。

We can layer most IAM use cases on top of this architecture pattern. For example, we can achieve access control either by issuing verifiable claims for actions we want users to perform or by only accepting users who have certain properties (e.g., age, job description, group membership) in their verifiable claims. An implementation may choose to cache relevant subsets of the profile data in a database to improve performance.

我们可以在此架构模式之上分层大多数IAM用例。 例如，我们可以通过发布我们要用户执行的操作的可验证声明，或者仅接受在其可验证声明中具有某些属性(例如年龄，工作描述，组成员身份)的用户，来实现访问控制。 一种实现可以选择将简档数据的相关子集缓存在数据库中以提高性能。

可审核的历史记录或工作区的体系结构模式 (Architecture Pattern for Auditable History or Workspace)

Context: A two or more parties perform transactions or works together, and their activities need to be recorded in an indisputable manner.

背景信息：两个或多个参与方进行交易或一起工作，其活动需要以无可争议的方式记录下来。

Forces: Need to implement a decentralized audit log or a workspace where a single rogue user or few users can’t significantly affect the system.

强制措施：需要实施一个分散的审核日志或一个工作空间，在此工作空间中，一个恶意用户或几个用户不会对系统产生重大影响。

Solution: The proposed system records activities and creates entries in the blockchain for those records. The entry contains the hash of activity records, and therefore, the records can’t be disputed later.

解决方案：提议的系统记录活动并在区块链中为这些记录创建条目。 该条目包含活动记录的哈希，因此，以后不能对记录进行争议。

For example, let’s assume Alice wants to pay a tax. Tax Server accepts the payment application, creates a digital receipt, records its hash in the blockchain, and sends the receipt to Alice. Alice can verify the receipt by calculating the hash and checking against the value stored in the blockchain. After this, Bob can’t deny the receipt because the receipt hash and time are recorded in the blockchain.

例如，假设爱丽丝想缴税。 Tax Server接受付款应用程序，创建数字收据，将其哈希记录在区块链中，然后将收据发送给Alice。 爱丽丝可以通过计算哈希并对照存储在区块链中的值来验证收据。 此后，Bob无法拒绝收据，因为收据哈希值和时间记录在区块链中。

If the activities are numerous, there may be a need to workaround blockchain performance limitations. Therefore, some implementations may record a hash of several activity records as a block instead of a single activity record.

如果活动很多，可能需要解决区块链性能限制。 因此，某些实现可以将多个活动记录的哈希记录而不是单个活动记录记录为一个块。

注册中心或市场的体系结构模式 (Architecture Pattern for Registry or Marketplace)

Context: A registry is a collection of data entries that can be searched and retrieved over the network. A market place is a registry that allows users to buy the services or products represented by data entries. For example, a registry may be a catalog of available APIs.

上下文：注册表是可以通过网络搜索和检索的数据条目的集合。 市场是一个注册表，允许用户购买数据条目代表的服务或产品。 例如，注册表可以是可用API的目录。

Forces: Need to implement a decentralized environment where a single rogue user or few users can’t significantly affect the system.

力量：需要实现一个分散的环境，在该环境中，一个恶意用户或几个用户不会对系统造成重大影响。

Solution: The proposed pattern works as follows.

解决方案：建议的模式如下。

Let’s first consider a registry. With the proposed architecture, when a user issues a registry update (to add or modify an entry), the client records the change in the blockchain. If data in the update is large, the blockchain record may contain a link to the data and a hash value of the data. If data stored in the registry needs to be amended, the registry client adds a new record to the blockchain with amended information.

让我们首先考虑一个注册表。 使用建议的体系结构，当用户发布注册表更新(以添加或修改条目)时，客户端会将更改记录在区块链中。 如果更新中的数据很大，则区块链记录可能包含指向该数据的链接和该数据的哈希值。 如果需要修改存储在注册表中的数据，则注册表客户端会将带有修改信息的新记录添加到区块链中。

In the diagram above, each user has a registry client running in the local machine (e.g., laptop or phone). Each registry client reads the update records from the blockchain, verifies the update data against the hash included in the records, and reconstructs the most current view of records from updates. For example, by reading blockchain records about APIs, their additions, amendments, and removals, the registry client can create a view that shows current APIs included in the registry. To avoid having to read and verify all records every time the registry is used, clients might store data in a database and index it. The client should periodically check the blockchain and update the registry.

在上图中，每个用户都有一个在本地计算机(例如，笔记本电脑或电话)中运行的注册表客户端。 每个注册客户端都从区块链读取更新记录，根据记录中包含的哈希验证更新数据，并从更新中重建记录的最新视图。 例如，通过读取有关API，它们的添加，修正和删除的区块链记录，注册表客户端可以创建一个视图，以显示注册表中包含的当前API。 为了避免每次使用注册表时都必须读取和验证所有记录，客户端可以将数据存储在数据库中并为其建立索引。 客户端应定期检查区块链并更新注册表。

Blockchain works well as a “service marketplace,” since the same service may be sold many times. However, due to performance limitations, blockchain-based marketplaces are not suitable for items that can be sold only once.

区块链可以很好地作为“服务市场”，因为同一服务可能被多次出售。 但是，由于性能限制，基于区块链的市场不适用于只能出售一次的商品。

To illustrate, the functionality of a blockchain-based registry, let’s look at when Alice wants to subscribe to “weather news service” in the blockchain marketplace. When she submits her request, the registry creates credentials for the service and shares it with Alice. The payment may happen in one of several ways: using Bitcoins, via a smart contract where payments are made on a timely basis, or by some out-of-bound means.

为了说明这个基于区块链的注册表的功能，让我们看一下爱丽丝何时想在区块链市场上订阅“天气新闻服务”。 当她提交请求时，注册中心会为该服务创建凭据并与Alice共享。 支付可能以以下几种方式之一进行：使用比特币，通过及时进行支付的智能合约或通过一些越界手段。

智能合约和托管物的架构模式 (Architecture Pattern for Smart Contracts and Managed Things)

Under this pattern, we consider two cases. First, we consider smart contracts, and as the second, we consider a common special case of smart contracts: “Managed Things.”

在这种模式下，我们考虑两种情况。 首先，我们考虑智能合约，其次，我们考虑智能合约的一种常见特殊情况：“托管物”。

智能合约模式 (Smart Contracts Pattern)

Context: Multiple users want to abide by a contract, described as an executable program. Contract undergoes state transitions as per conditions defined in the contract, and at a given time, everyone can agree on the current status of the contract.

上下文：多个用户希望遵守合同，称为可执行程序。 合同按照合同中定义的条件进行状态转换，并且在给定时间，每个人都可以就合同的当前状态达成一致。

Forces: need to implement an environment where a single rogue user or few users can’t significantly affect the system.

强制措施：需要实现一个环境，在该环境中，一个恶意用户或几个用户不会严重影响系统。

Solution: Smart contacts are part of blockchain technologies and supported by blockchain implementations, such as Ethereum. A contract is described using a smart contract language and distributed to all participants. As conditions defined in the contract changes, each participant executes the contract and records the current status in the blockchain using the consensus algorithm.

解决方案：智能联系人是区块链技术的一部分，并受到以太坊等区块链实施的支持。 使用智能合约语言描述合约并分发给所有参与者。 随着合同中定义的条件的变化，每个参与者执行合同并使用共识算法将当前状态记录在区块链中。

托管事物模式 (Managed Things Pattern)

Context: We need to track the ownership of real-world smart things. Here smart things are real-world objects that are capable of running computing logic within them. The owner is allowed to control and perform actions on the real world things. Also, the owner may transfer his ownership to someone else.

上下文：我们需要跟踪现实世界中智能事物的所有权。 在这里，智能事物是现实世界中的对象，能够在其中运行计算逻辑。 允许所有者控制现实世界中的事物并对其执行操作。 同样，所有者可以将其所有权转让给其他人。

Forces: need to implement an environment where a single rogue user or few users can’t significantly affect the system.

强制措施：需要实现一个环境，在该环境中，一个恶意用户或几个用户不会严重影响系统。

Solution: Following describes the implementation of the pattern using Car as the managed thing as an example.

解决方案：下面以Car作为托管对象来描述模式的实现。

We can implement a blockchain for a managed thing, in this case, a car, in two steps. First, the manufacturer records the DID and the public key of the owner of the car. When ownership changes, the owner adds a new record in the blockchain specifying the new owner. Second, when checking for ownership, the car first retrieves all records in the blockchain and verifies that each record is added by the owner at that time. This is done by checking the public key of the user who wrote the record against the public key included in the previous ownership record. The last owner in this valid chain is the current owner.

我们可以分两步为托管物品(在本例中为汽车)实现区块链。 首先，制造商记录汽车所有者的DID和公共密钥。 当所有权更改时，所有者在区块链中添加一条新记录，指定新所有者。 其次，在检查所有权时，汽车首先会检索区块链中的所有记录，并验证所有者当时是否添加了每条记录。 这是通过对照先前所有权记录中包含的公共密钥检查编写记录的用户的公共密钥来完成的。 此有效链中的最后一个所有者是当前所有者。

After determining the owner, the car logs in the current owner, Alice, by retrieving her public key and carrying out a challenge-response-protocol-based login with Alice’s phone, which has Alice’s private key.

确定所有者之后，汽车将通过检索她的公钥并使用具有Alice私钥的Alice手机进行基于质询-响应-协议的登录来登录当前所有者Alice。

Such a system reduces the risks associated with remotely controlled artifacts. For example, in a non-blockchain implementation, someone with access can change the ownership of your car. However, with the blockchain-based model, to remotely control the car, a would-be attacker must change the ownership record in the blockchain, which is very hard to achieve without being the owner.

这样的系统降低了与远程控制伪像相关的风险。 例如，在非区块链实施中，具有访问权限的人可以更改您的汽车所有权。 但是，使用基于区块链的模型来远程控制汽车，潜在的攻击者必须更改区块链中的所有权记录，如果没有所有者，这是很难实现的。

However, it is hard to stop someone who has access to the “thing” from physically changing the logic running inside (e.g., by replacing the firmware of the car). One solution to this problem is to build some form of self-destruct that triggers when tampering into the artifact is detected.

但是，很难阻止有权访问“事物”的人实际更改内部运行的逻辑(例如，通过更换汽车的固件)。 解决此问题的一种方法是构建某种形式的自毁，在检测到篡改伪影时触发。

For example, Alice buys the car from Bob using a smart contract that pays Bob and updates the ownership of the vehicle. After the transaction, Alice walks to the car, which reads Alice’s DID from the phone, retrieves her public key, authenticates her using a challenge-response-protocol by communicating with the phone that has Alice’s private key, verifies her ownership, and unlocks the car.

例如，爱丽丝使用支付给鲍勃的智能合约从鲍勃购买了汽车，并更新了车辆的所有权。 交易之后，爱丽丝走到汽车上，汽车从电话中读取爱丽丝的DID，检索她的公钥，通过与具有爱丽丝私钥的电话进行通信，使用质询-响应协议对她进行身份验证，验证她的所有权并解锁汽车。

结论 (Conclusion)

We discussed four blockchain based architecture patterns. The GitHub document, Blockchain-based Integration Use Cases, shows these patterns in action, describing how 30-plus blockchain use cases can be implemented using these four patterns.

我们讨论了四种基于区块链的架构模式。 GitHub文档基于区块链的集成用例展示了这些模式的实际应用，描述了如何使用这四种模式实现30多个区块链用例。

If you have opinions about the above patterns or know about other patterns, I would really like to hear about them.

如果您对以上模式有意见或对其他模式有所了解，我真的很想听听它们。

I hope this was useful. If you like this, you might also like a detailed blockchain analysis in our recently published paper, “A use case centric survey of Blockchain: status quo and future directions.”

我希望这是有用的。 如果您愿意，您还可能希望在我们最近发表的论文“ 以用例为中心的区块链调查：现状和未来方向 ”中进行详细的区块链分析。

翻译自: https://www.freecodecamp.org/news/https-medium-com-srinathperera-blockchain-patterns-6cf58fdc2d9b/

去中心化 去区块链