Policies(策略)
What is a policy
At its most basic level, a policy is a set of rules that define the structure for how decisions are made and specific outcomes are reached. To that end, policies typically describe a who and a what, such as the access or rights that an individual has over an asset. We can see that policies are used throughout our daily lives to protect assets of value to us, from car rentals, health, our homes, and many more.
在最基本的级别上，策略是一组规则，这些规则定义了如何制定决策和达到特定结果的结构。为此，策略通常描述WHO和WHAT，例如个人对ASSET的访问或权利。我们可以看到，策略在我们的日常生活中一直被用来保护对我们有价值的资产，使其免受汽车租赁，医疗，房屋等的侵害。
For example, an insurance policy defines the conditions, terms, limits, and expiration under which an insurance payout will be made. The policy is agreed to by the policy holder and the insurance company, and defines the rights and responsibilities of each party.
例如，保险单定义了将要支付保险金的条件，条款，限额和有效期。该保单经保单持有人和保险公司同意，并定义了双方的权利和责任。
Whereas an insurance policy is put in place for risk management, in Hyperledger Fabric, policies are the mechanism for infrastructure management. Fabric policies represent how members come to agreement on accepting or rejecting changes to the network, a channel, or a smart contract. Policies are agreed to by the consortium members when a network is originally configured, but they can also be modified as the network evolves. For example, they describe the criteria for adding or removing members from a channel, change how blocks are formed, or specify the number of organizations required to endorse a smart contract. All of these actions are described by a policy which defines who can perform the action. Simply put, everything you want to do on a Fabric network is controlled by a policy.
尽管已为风险管理制定了保险单，但在Hyperledger Fabric中，风险管理是基础架构管理的机制。Fabric的策略代表成员如何就接受或拒绝对网络，渠道或智能合约的更改达成协议。最初配置网络时，策略是由联盟成员同意的，但是也可以随着网络的发展而修改策略。例如，它们描述了在通道中添加或删除成员，更改区块的形成方式或指定认可智能合约所需的组织数量的标准。所有这些动作均由定义了谁可以执行该动作的策略来描述。简而言之，您要在Fabric网络上执行的所有操作均受策略控制。
Why are policies needed
Policies are one of the things that make Hyperledger Fabric different from other blockchains like Ethereum or Bitcoin. In those systems, transactions can be generated and validated by any node in the network. The policies that govern the network are fixed at any point in time and can only be changed using the same process that governs the code. Because Fabric is a permissioned blockchain whose users are recognized by the underlying infrastructure, those users have the ability to decide on the governance of the network before it is launched, and change the governance of a running network.
策略是使Hyperledger Fabric与以太坊或比特币等其他区块链不同的原因之一。在比特币或以太坊系统中，交易可以由网络上的任意节点生成和验证。支配网络的策略在任何时间都是固定的，并且只能使用支配代码的相同过程进行更改。由于Fabric是许可的区块链，其用户被基础架构所识别，因此这些用户具有在启动网络之前决定网络治理的能力，并且也具有更改运行中网络的治理的能力。
Policies allow members to decide which organizations can access or update a Fabric network, and provide the mechanism to enforce those decisions. Policies contain the lists of organizations that have access to a given resource, such as a user or system chaincode. They also specify how many organizations need to agree on a proposal to update a resource, such as a channel or smart contracts. Once they are written, policies evaluate the collection of signatures attached to transactions and proposals and validate if the signatures fulfill the governance agreed to by the network.
策略允许成员决定哪些组织可以访问或更新一个Fabric网络，并提供执行这些决定的机制。策略包含对给定的资源的有访问权限的组织的列表，比如一个用户或者系统链码。策略还指定有多少组织需要就更新资源（例如通道或智能合约）的提案达成协议。一旦写入，策略将评估附加在交易和提议中的签名的集合，并验证签名是否满足网络所同意的治理。
How are policies implemented throughout Fabric
Policies are implemented at different levels of a Fabric network. Each policy domain governs different aspects of how a network operates.
策略是在Fabric网络的不同级别上实现的。每个策略域管理网络运行的不同方面。
A visual representation of the Fabric policy hierarchy.
Fabric策略层次结构的直观表示。
System channel configuration
Every network begins with an ordering system channel. There must be exactly one ordering system channel for an ordering service, and it is the first channel to be created. The system channel also contains the organizations who are the members of the ordering service (ordering organizations) and those that are on the networks to transact (consortium organizations).
每个网络都从一个排序系统通道开始。对排序服来说，必须有一个确定的排序系统通道，并且他是第一个需要创建的通道。系统通道还包含作为排序服务成员的组织（排序组织）和在网络上进行交易的组织（联盟组织）。
The policies in the ordering system channel configuration blocks govern the consensus used by the ordering service and define how new blocks are created. The system channel also governs which members of the consortium are allowed to create new channels.
排序系统通道配置区块中的策略控制排序服务使用的共识，并定义如何创建新区块。系统通道也控制联盟中的哪些成员允许创建新的通道。
Application channel configuration
Application channels are used to provide a private communication mechanism between organizations in the consortium.
应用程序通道用于在联盟中的组织之间提供专用的通信机制。
The policies in an application channel govern the ability to add or remove members from the channel. Application channels also govern which organizations are required to approve a chaincode before the chaincode is defined and committed to a channel using the Fabric chaincode lifecycle. When an application channel is initially created, it inherits all the ordering service parameters from the orderer system channel by default. However, those parameters (and the policies governing them) can be customized in each channel.
应用程序通道中的策略控制了从通道中添加或者移除成员的能力。应用程序通道也控制了在使用Fabric链码生命周期定义链码并将其提交给通道之前，需要哪些成员需要。最初创建应用程序通道时，默认情况下它将从排序系统通道继承所有排序服务参数。但是，可以在每个通道中自定义这些参数（以及控制它们的策略）。
Access control lists (ACLs)
Network administrators will be especially interested in the Fabric use of ACLs, which provide the ability to configure access to resources by associating those resources with existing policies. These “resources” could be functions on system chaincode (e.g., “GetBlockByNumber” on the “qscc” system chaincode) or other resources (e.g.,who can receive Block events). ACLs refer to policies defined in an application channel configuration and extends them to control additional resources. The default set of Fabric ACLs is visible in the configtx.yaml file under the Application: &ApplicationDefaults section but they can and should be overridden in a production environment. The list of resources named in configtx.yaml is the complete set of all internal resources currently defined by Fabric.
网络管理员可能对Fabric使用的AC特别感兴趣，ACL可以通过将资源与现有策略相关联来配置对资源的访问。这些“资源”可以是系统链码上的功能（如，在“ qscc”系统链码上的“ GetBlockByNumber”）或其他资源（如谁可以接收Block事件）。ACL引用在应用程序通道配置中定义的策略，并将其扩展以控制其他资源。默认的Fabric ACL集在configtx.yaml文件里的 Application: &ApplicationDefaults 部分下的可见，但是可以并且应该在生产环境中覆盖它们。configtx.yaml中命名的资源列表是Fabric当前定义的所有内部资源的完整集合。
In that file, ACLs are expressed using the following format:
在该文件中，ACL使用以下格式表示：
1 | # ACL policy for chaincode to chaincode invocation |
Where peer/ChaincodeToChaincode represents the resource being secured and /Channel/Application/Readers refers to the policy which must be satisfied for the associated transaction to be considered valid.
其中 peer/ChaincodeToChaincode 表示受保护的资源， /Channel/Application/Readers是指必须满足的策略，关联交易才被视为有效。
For a deeper dive into ACLS, refer to the topic in the Operations Guide on ACLs.
要深入了解ACLS，请参阅ACLs的操作指南中的主题。
Smart contract endorsement policies（智能合约的背书策略）
Every smart contract inside a chaincode package has an endorsement policy that specifies how many peers belonging to different channel members need to execute and validate a transaction against a given smart contract in order for the transaction to be considered valid. Hence, the endorsement policies define the organizations (through their peers) who must “endorse” (i.e., approve of) the execution of a proposal.
链码包里面的每个智能合约都有一个背书策略，这个背书策略指定了需要多少个来自不同通道成员的peer节点需要针对给定的智能合约执行和验证交易，以便该交易被视为有效。因此，背书政策定义了必须“背书”（即批准）提案执行的组织（通过其peer）。
Modification policies（修改政策）
There is one last type of policy that is crucial to how policies work in Fabric, the Modification policy. Modification policies specify the group of identities required to sign (approve) any configuration update. It is the policy that defines how the policy is updated. Thus, each channel configuration element includes a reference to a policy which governs its modification.
最后一种策略对于Fabric中的策略工作至关重要，即Modification policy。修改策略指定了任何配置更新时需要签名（批准）的一组身份。该策略定义了如何更新策略。因此，每个通道配置元素都包含一个对管理其修改的策略的引用。
The Fabric policy domains
While Fabric policies are flexible and can be configured to meet the needs of a network, the policy structure naturally leads to a division between the domains governed by either the Ordering Service organizations or the members of the consortium. In the following diagram you can see how the default policies implement control over the Fabric policy domains below.
虽然Fabric的策略是灵活的，可以配置为满足网络需求，但是策略结构自然会导致由排序服务组织或联盟成员管理的域之间的划分。在下图中你会看到默认策略是如何实现对结构策略域的控制。
A more detailed look at the policy domains governed by the Orderer organizations and consortium organizations.
更详细地了解由订购者组织和财团组织管理的策略域。
A fully functional Fabric network can feature many organizations with different responsibilities. The domains provide the ability to extend different privileges and roles to different organizations by allowing the founders of the ordering service the ability to establish the initial rules and membership of the consortium. They also allow the organizations that join the consortium to create private application channels, govern their own business logic, and restrict access to the data that is put on the network.
功能齐全的Fabric网络可以使许多个组织承担不同的职责。域通过允许排序服务的创建者建立联盟的初始规则和成员资格的能力来提供将不同的特权和角色扩展到不同组织的能力。域还允许加入该联盟的组织创建私有应用程序通道，管理他们自己的业务逻辑，并限制对网络上放置的数据的访问。
The system channel configuration and a portion of each application channel configuration provides the ordering organizations control over which organizations are members of the consortium, how blocks are delivered to channels, and the consensus mechanism used by the nodes of the ordering service.
系统通道配置和每个应用程序通道配置的一部分为排序组织提供了控制，这些组织可以控制哪些组织是联盟的成员，如何将区块交付到渠道以及排序服务的节点所使用的共识机制。
The system channel configuration provides members of the consortium the ability to create channels. Application channels and ACLs are the mechanism that consortium organizations use to add or remove members from a channel and restrict access to data and smart contracts on a channel.
系统通道提供了哪些联盟的成员有能力创建通道。系统通道和ACL是联盟组织用于在通道中添加或删除成员并限制对通道上数据和智能合约的访问的机制。
How do you write a policy in Fabric
If you want to change anything in Fabric, the policy associated with the resource describes who needs to approve it, either with an explicit sign off from individuals, or an implicit sign off by a group. In the insurance domain, an explicit sign off could be a single member of the homeowners insurance agents group. And an implicit sign off would be analogous to requiring approval from a majority of the managerial members of the homeowners insurance group. This is particularly useful because the members of that group can change over time without requiring that the policy be updated. In Hyperledger Fabric, explicit sign offs in policies are expressed using the Signature syntax and implicit sign offs use the ImplicitMeta syntax.
如果要更改Fabric中的任何内容，则与资源相关联的策略描述了谁需要批准它，可以是个人的显示签名，也可以是组的隐式签名。在保险领域，显示签名可以是房主保险代理人组的单个成员。隐式签名类似于要求房主保险集团的大多数管理人员批准。这特别有用，因为该组的成员可以随时间变化而无需更新策略。在Hyperledger Fabric中，策略中的显式签名使用Signature语法表示，而隐式签名使用ImplicitMeta语法。
Signature policies
Signature policies define specific types of users who must sign in order for a policy to be satisfied such as OR('Org1.peer', 'Org2.peer'). These policies are considered the most versatile because they allow for the construction of extremely specific rules like: “An admin of org A and 2 other admins, or 5 of 6 organization admins”. The syntax supports arbitrary combinations of AND, OR and NOutOf. For example, a policy can be easily expressed by using AND('Org1.member', 'Org2.member') which means that a signature from at least one member in Org1 AND one member in Org2 is required for the policy to be satisfied.
Signature 策略定义了必须由指定类型的用户签名才能满足策略，例如 OR('Org1.peer', 'Org2.peer')。这些策略被认为是最通用的，因为它们允许构建极其特定的规则，例如：“组织A的一个管理员和2个其他管理员，或6个组织中的5个管理员”。
ImplicitMeta policies
ImplicitMeta policies are only valid in the context of channel configuration which is based on a tiered hierarchy of policies in a configuration tree. ImplicitMeta policies aggregate the result of policies deeper in the configuration tree that are ultimately defined by Signature policies. They are Implicit because they are constructed implicitly based on the current organizations in the channel configuration, and they are Meta because their evaluation is not against specific MSP principals, but rather against other sub-policies below them in the configuration tree.
ImplicitMeta 策略仅在通道配置的上下文中有效，该配置基于配置树中策略的分层层次结构。 ImplicitMeta策略将在配置树中更深的策略的结果汇总在一起，这些策略最终由签名策略定义。它们是Implicit的，因为它们是基于渠道配置中的当前组织隐式构造的，之所以称为Meta，是因为它们的评估不是针对特定的MSP主体，而是针对配置树中位于其下方的其他子策略。
The following diagram illustrates the tiered policy structure for an application channel and shows how the ImplicitMeta channel configuration admins policy, named /Channel/Admins, is resolved when the sub-policies named Admins below it in the configuration hierarchy are satisfied where each check mark represents that the conditions of the sub-policy were satisfied.
下图说明了应用程序通道的分层策略结构,并显示名为 /Channel/Admins的 ImplicitMeta 通道配置管理员策略，当满足配置层次结构中位于其下方的名为Admins的子策略时，将解决此问题，其中每个复选标记表示已满足该子策略的条件。
As you can see in the diagram above, ImplicitMeta policies, Type = 3, use a different syntax, "<ANY|ALL|MAJORITY> <SubPolicyName>", for example:
如上图所示，ImplicitMeta 策略， Type = 3，使用不同的语法"<ANY|ALL|MAJORITY> <SubPolicyName>"，例如：
1 | `MAJORITY sub policy: Admins` |
The diagram shows a sub-policy Admins, which refers to all the Admins policy below it in the configuration tree. You can create your own sub-policies and name them whatever you want and then define them in each of your organizations.
该图显示了一个子策略Admins，它引用配置树中其下方的所有Admins策略。您可以创建自己的子策略，并根据需要命名它们，然后在你的每个组织中对其进行定义。
As mentioned above, a key benefit of an ImplicitMeta policy such as MAJORITY Admins is that when you add a new admin organization to the channel, you do not have to update the channel policy. Therefore ImplicitMeta policies are considered to be more flexible as the consortium members change. The consortium on the orderer can change as new members are added or an existing member leaves with the consortium members agreeing to the changes, but no policy updates are required. Recall that ImplicitMeta policies ultimately resolve the Signature sub-policies underneath them in the configuration tree as the diagram shows.
如上所述，ImplicitMeta策略（例如MAJORITY Admins）的主要优势在于，当您向通道添加新的管理员组织时，不必更新频道策略。因此，随着联盟成员的变化，ImplicitMeta策略被认为更加灵活。当添加新成员或现有成员离开时，排序者上的联盟可以更改，联盟成员同意更改，但是不需要更新策略。回想一下，ImplicitMeta策略最终在配置树中解决了其下方的Signature子策略，如图所示。
You can also define an application level implicit policy to operate across organizations, in a channel for example, and either require that ANY of them are satisfied, that ALL are satisfied, or that a MAJORITY are satisfied. This format lends itself to much better, more natural defaults, so that each organization can decide what it means for a valid endorsement.
您还可以定义一个应用程序级别的隐式策略，以在组织中（例如，在一个通道中）进行操作，并要求满足它们中的任何一个，满足所有条件或满足大多数条件。这种格式适合于更好，更自然的默认设置，以便每个组织可以决定对有效背书的含义。
Further granularity and control can be achieved if you include NodeOUs in your organization definition. Organization Units (OUs) are defined in the Fabric CA client configuration file and can be associated with an identity when it is created. In Fabric, NodeOUs provide a way to classify identities in a digital certificate hierarchy. For instance, an organization having specific NodeOUs enabled could require that a ‘peer’ sign for it to be a valid endorsement, whereas an organization without any might simply require that any member can sign.
如果在组织定义中包含NodeOU，则可以实现进一步的粒度和控制。组织单位（OU）在Fabric CA客户端配置文件中定义，并且在创建时可以与身份相关联。NodeOU提供了一种在数字证书层次结构中对身份进行分类的方法。例如，启用了特定NodeOU的组织可能要求“peer”标志才能有效地背书，而只有组织而不包含任何其他可能只要求任何成员都可以签名。
An example: channel configuration policy
Understanding policies begins with examining the configtx.yaml where the channel policies are defined. We can use the configtx.yaml file in the Fabric test network to see examples of both policy syntax types. We are going to examine the configtx.yaml file used by the fabric-samples/test-network sample.
The first section of the file defines the organizations of the network. Inside each organization definition are the default policies for that organization, Readers, Writers, Admins, and Endorsement, although you can name your policies anything you want. Each policy has a Type which describes how the policy is expressed (Signature or ImplicitMeta) and a Rule.
The test network example below shows the Org1 organization definition in the system channel, where the policy Type is Signature and the endorsement policy rule is defined as "OR('Org1MSP.peer')". This policy specifies that a peer that is a member of Org1MSP is required to sign. It is these signature policies that become the sub-policies that the ImplicitMeta policies point to.
1 | ################################################################################ |
The next example shows the ImplicitMeta policy type used in the Application section of the configtx.yaml. These set of policies lie on the /Channel/Application/ path. If you use the default set of Fabric ACLs, these policies define the behavior of many important features of application channels, such as who can query the channel ledger, invoke a chaincode, or update a channel config. These policies point to the sub-policies defined for each organization. The Org1 defined in the section above contains Reader, Writer, and Admin sub-policies that are evaluated by the Reader, Writer, and Admin ImplicitMeta policies in the Application section. Because the test network is built with the default policies, you can use the example Org1 to query the channel ledger, invoke a chaincode, and approve channel updates for any test network channel that you create.
1 | ################################################################################ |
Fabric chaincode lifecycle
In the Fabric 2.0 release, a new chaincode lifecycle process was introduced, whereby a more democratic process is used to govern chaincode on the network. The new process allows multiple organizations to vote on how a chaincode will be operated before it can be used on a channel. This is significant because it is the combination of this new lifecycle process and the policies that are specified during that process that dictate the security across the network. More details on the flow are available in the Fabric chaincode lifecycle concept topic, but for purposes of this topic you should understand how policies are used in this flow. The new flow includes two steps where policies are specified: when chaincode is approved by organization members, and when it is committed to the channel.
The Application section of the configtx.yaml file includes the default chaincode lifecycle endorsement policy. In a production environment you would customize this definition for your own use case.
1 | ################################################################################ |
-
The
LifecycleEndorsementpolicy governs who needs to approve a chaincode definition.LifecycleEndorsement策略管理谁需要批准链码定义 -
The
Endorsementpolicy is the default endorsement policy for a chaincode. More on this below.Endorsement策略是链码的默认背书策略，详情在下面。
Chaincode endorsement policies
The endorsement policy is specified for a chaincode when it is approved and committed to the channel using the Fabric chaincode lifecycle (that is, one endorsement policy covers all of the state associated with a chaincode). The endorsement policy can be specified either by reference to an endorsement policy defined in the channel configuration or by explicitly specifying a Signature policy.
在使用Fabric链码生命周期批准链码并将其提交给通道时便指定了链码的背书策略（即，一种背书策略涵盖了与链码相关联的所有状态）。可以通过参考在通道配置中定义的背书策略来指定背书策略，也可以通过显式指定签名策略来指定背书策略。
If an endorsement policy is not explicitly specified during the approval step, the default Endorsement policy "MAJORITY Endorsement" is used which means that a majority of the peers belonging to the different channel members (organizations) need to execute and validate a transaction against the chaincode in order for the transaction to be considered valid. This default policy allows organizations that join the channel to become automatically added to the chaincode endorsement policy. If you don’t want to use the default endorsement policy, use the Signature policy format to specify a more complex endorsement policy (such as requiring that a chaincode be endorsed by one organization, and then one of the other organizations on the channel).
Signature policies also allow you to include principals which are simply a way of matching an identity to a role. Principals are just like user IDs or group IDs, but they are more versatile because they can include a wide range of properties of an actor’s identity, such as the actor’s organization, organizational unit, role or even the actor’s specific identity. When we talk about principals, they are the properties which determine their permissions. Principals are described as ‘MSP.ROLE’, where MSP represents the required MSP ID (the organization), and ROLE represents one of the four accepted roles: Member, Admin, Client, and Peer. A role is associated to an identity when a user enrolls with a CA. You can customize the list of roles available on your Fabric CA.
Some examples of valid principals are:
- ‘Org0.Admin’: an administrator of the Org0 MSP
- ‘Org1.Member’: a member of the Org1 MSP
- ‘Org1.Client’: a client of the Org1 MSP
- ‘Org1.Peer’: a peer of the Org1 MSP
- ‘OrdererOrg.Orderer’: an orderer in the OrdererOrg MSP
There are cases where it may be necessary for a particular state (a particular key-value pair, in other words) to have a different endorsement policy. This state-based endorsement allows the default chaincode-level endorsement policies to be overridden by a different policy for the specified keys.
For a deeper dive on how to write an endorsement policy refer to the topic on Endorsement policies in the Operations Guide.
Note: Policies work differently depending on which version of Fabric you are using:
- In Fabric releases prior to 2.0, chaincode endorsement policies can be updated during chaincode instantiation or by using the chaincode lifecycle commands. If not specified at instantiation time, the endorsement policy defaults to “any member of the organizations in the channel”. For example, a channel with “Org1” and “Org2” would have a default endorsement policy of “OR(‘Org1.member’, ‘Org2.member’)”.
- Starting with Fabric 2.0, Fabric introduced a new chaincode lifecycle process that allows multiple organizations to agree on how a chaincode will be operated before it can be used on a channel. The new process requires that organizations agree to the parameters that define a chaincode, such as name, version, and the chaincode endorsement policy.
Overriding policy definitions
Hyperledger Fabric includes default policies which are useful for getting started, developing, and testing your blockchain, but they are meant to be customized in a production environment. You should be aware of the default policies in the configtx.yaml file. Channel configuration policies can be extended with arbitrary verbs, beyond the default Readers, Writers, Admins in configtx.yaml. The orderer system and application channels are overridden by issuing a config update when you override the default policies by editing the configtx.yaml for the orderer system channel or the configtx.yaml for a specific channel.
See the topic on Updating a channel configuration for more information.