1. Key concepts
1.1. Network Architecture
1.1.1. Deal
Like other blockchain systems, Fabric interacts with the state machine through transactions. A transaction is initiated by an account with write permission, which invokes the chain code interface to modify the corresponding state. All nodes executing the transaction should obtain the same result, so as to maintain the consistency of the entire state machine.
Slightly different from other systems are the criteria for successful execution. In Ethereum, the nodes execute the transactions in the block in sequence. Each transaction is executed, a change is made to the ledger, and the next transaction is executed in the new state. For example, Ming has 100 yuan, 10 yuan is deducted from the first transaction, and 90 yuan is deducted from the second transaction. However, in Fabric, the second transaction will not succeed and will be marked as invalid.
Here comes the concept of an RWSet. Each transaction has an execution state, called the read set, and an execution result, called the write set, which is determined at endorsement time. During the transaction execution, the KVPair corresponding to the read set must be in the same state as the current one. If the status is the same, you can change the status according to the write set.
After an endorsement, first deal TX1 {< RSet: (K: xiao Ming, V: 100) >, < WSet: (K: xiao Ming, V: 90) >}, the second transaction TX2 {< RSet: (K: xiao Ming, V: 100) >, < WSet: (K: xiao Ming, V: 80)>}, the read set of TX2 is the same, and when the second transaction is executed, the read set of TX2 is found to be different from the current state, then the transaction is marked as an error.
The main feature of Fabric is that when the read sets are different, that is, when the expected states of execution are different, the transaction fails. Compared with public chains such as Ethereum, this restriction is more stringent.
1.1.2. The channel
A channel in a Hyperledger Fabric is a dedicated “subnet” for communication between two or more specific network members for private and confidential transactions. Channels are defined by members (organizations), anchor nodes for each member, shared ledgers, linked code applications, and sorting service nodes. Every transaction on the network is performed over a channel where each party must be authenticated and authorized to conduct a transaction over that channel.
Channel is defined as above. Channel is a sub-network composed of multiple organizations, with its own blockchain ledger, and member management is also managed by channel itself. A channel can be divided into two types. One is a system channel, which runs the Fabric sorting service and maintains a list of all organizations that can create channels. This list is called a “federation”. Other channels rely on the sorting service for their own consistency; The other is application channels, which are jointly created by multiple organizations to run chain codes and perform certain services.
Access to a channel is controlled by a CA, which can be regarded as an account in a Fabric. A CA contains many attributes of the entity, such as roles, permissions, and public keys. Each organization can create its own private key and corresponding root CA, and issue cas to other members of the organization. Fabric provides a number of tools such as FabricCA to do this.
Information such as root certificates for all organizations of the channel is stored in the ledger, so certificates issued by any organization can be verified by nodes of other organizations.
1.2. Node Roles
1.2.1. The Orderer
The Orderer node is the sort service node that packages blocks for all channels and maintains a list of federated organizations that can create channels, but non-federated members can also join channels.
1.2.2. Peer
The Peer node is responsible for maintaining the blockchain ledger of a channel. Each organization can have multiple Peer nodes. The Peer node is responsible for endorsing the transaction of the channel. The application interacts directly with the Peer node. In short, Peer identity has the right to endorse, submit transactions and query.
Each role corresponds to a CA certificate, and the certificate contains the corresponding information.
1.2.3. Client
A Client is an identity required by an application program and has the rights to propose transactions and query peers.
1.3. Account Management
1.3.1. Certificate System
In a Fabric, a certificate is an account, and only a valid certificate can be used to send transactions to the network.
Each certificate corresponds to a public and private key pair, but a public and private key pair can have more than one certificate. The unique ID of the certificate can be determined by its Subject and Issuer.
Each organization needs to maintain its own certificate system and handle the issuance, collection, and recording of certificates within the organization.
An organization’s certificate system consists of an organization root certificate and an organization member certificate. The root certificate is usually a self-licensing document that issues certificates to organization members, a process that can be implemented through the Fabric CA tool. Organization members can be divided into many roles, such as administrator, Peer, and Client. They can add properties to the CA, or they can be intermediate cas issued by the root CA. They can define various permissions, such as revoking certificates, issuing certificates, and defining properties. These properties can be used as permission control in different businesses, such as checking whether the caller has a property in a chain code.
1.3.2. MSP
Faced with complex certificate systems and permission controls, Fabric abstracts these into an entity called Membership Provider, or MSP. The MSP contains all the information you need to prove your or someone else’s permissions. Examples are as follows:
[email protected] ├── MSP │ ├─ adminCerts // Admin folder, store the admin certificate of the current organization, There is no │ ├ ─ ─ cacerts / / store the current organization of the root certificate │ │ └ ─ ─ ca.org1.example.com - cert. Pem │ ├ ─ ─ config. The yaml │ ├ ─ ─ keystore / / store the current account to the private key │ │ └ ─ ─ d6a78efa7db939cd68e059a9593cbbb89bc68d14e7caebbbc38e4fb81e0fe579_sk │ ├ ─ ─ signcerts / / current account certificate, Issued by organization root certificate │ │ └ ─ ─ cert. Pem │ └ ─ ─ tlscacerts / / TLS root certificate │ └ ─ ─ tlsca.org1.example.com - cert. Pem └ ─ ─ the TLS ├ ─ ─ ca. CRT / / ├─ ├─ custom.key // TLS private key ├─ custom.key // TLS private keyCopy the codeThe entity of an MSP is a file containing certificates and private keys in PEM format, which is called LocalMSP in Fabric and is used by local accounts. Peer nodes and Orderer nodes maintain a copy, and for the entire channel, maintain the root certificates of all organizations and other information. This is stored in a ledger for use by all organizations on the entire channel.
1.3.3. TLS
Fabric can enable two-way TLS to protect the privacy of information on the network, such as certificates, which contain a lot of permission and organization information, which may be critical business information.
In TLS protocol of CS mode, is often only the server certificate, the client only need to verify the server certificate, with the server public key encryption key information of backwardness to the server, the server with the private key is to work out this information, locally generated on both sides of the same symmetric key, follow-up communication using the symmetric key encryption. Two-way TLS requires the server to verify the CLIENT’s TLS certificate, and the subsequent process is the same as one-way.
2. Transaction process
2.1. Endorsement of transactions
Unlike Ethereum, where it is none of the user’s business to broadcast a transaction, Fabric users issue transactions in two steps, first endorsing the transaction and second submitting the transaction to Orderer.
In this case, a user is an application whose CA has write permission. Assume that there are two organizations Org1 and Org2 in the channel, and now they want to call the chain code CC. To send a transaction and call CC, they need to meet its endorsement policy, which is required by the chain code, and endorsement refers to the process of meeting the endorsement policy. For example, the Peer of some organizations is required to sign the transaction.
The application program first sends its signed transaction request to the Peer nodes of Org1 and Org2, and the Peer node verifies whether the application program has enough permission, and then performs the transaction to judge whether it is valid. At this time, the transaction is not written into the account book. If the transaction request passes the inspection, the Peer will sign it and return it to the application program.
The application then collects the Peer’s return, assembles the transaction, and sends it to the Orderer node, which packages the transaction into the block of the current channel.
The block is distributed to each Peer. The Peer executes the transaction and changes the ledger state at the same time. The transaction may not succeed because the RSet may not match the current state and the transaction is marked as invalid.
The specific process can be seen
3. Chain code development
3.1. Endorsement strategy
Endorsement is actually the organization to check and sign a proposal, which organizations and roles need to sign is the endorsement strategy.
The endorsement policy is for chain code. When chain code is installed or upgraded, an endorsement policy will be set, which is an endorsement policy for the whole chain code. In addition, policies can be set for some special keys to cover the whole endorsement policy, which is called state-based endorsement policy.
AND(‘ org1. member’, ‘org2. member’)
This is the expression of endorsement strategy. Simply speaking, it requires that the invocation of the chain code be endorsed by any member of Org1 and Org2. Details visible
The key-level endorsement strategy needs to be pre-written in the form of code when the chain code is written, and there are specific interfaces.
3.2. Installation and initialization
Chain codes in the Fabric are in the form of docker containers.
Install the command can go through the tutorial, go familiar with it.
Installation actually sends the code to the Peer nodes, instantiation compiles the chain code and starts a container for it, and the Peer node communicates with it through the gRPC.
3.3. Standard interface
Chain code is relatively simple to write, 1.4 provides interface and 2.0 has a big gap, later study.
The chain code is actually the implementation interface:
// Chaincode interface must be implemented by all chaincodes. The fabric runs
// the transactions by calling these functions as specified.
type Chaincode interface {
// Init is called during Instantiate transaction after the chaincode container
// has been established for the first time, allowing the chaincode to
// initialize its internal data
Init(stub ChaincodeStubInterface) pb.Response
// Invoke is called to update or query the ledger in a proposal transaction.
// Updated state variables are not committed to the ledger until the
// transaction is committed.
Invoke(stub ChaincodeStubInterface) pb.Response
}
Copy the codeHere the authors implement several examples of the Fabric side protocol implementation in Poly cross-chain protocol. Unlike the Solidity contract, a pure contract is a contract entity, like writing a class or structure, where the main entry needs to be implemented and is the full executable.
3.4. Cross-chain code invocation
There are some problems when using cross-chain code calls.
First of all, there is no such concept as contract account in Fabric. Chain code is simply logic and business. When cross-chain code is invoked, the transaction context does not change except for parameters, and the original information can be manually solved from the Proposal.
When cross-chain code is invoked, the log of the chain code will not be written to the block, the specific need to look at the code.