CN107240017B

CN107240017B - Block chain transaction management system and method

Info

Publication number: CN107240017B
Application number: CN201710595474.9A
Authority: CN
Inventors: 伍鹏程
Original assignee: Jiede China Technology Co ltd
Current assignee: Jiede China Technology Co ltd
Priority date: 2017-07-20
Filing date: 2017-07-20
Publication date: 2021-08-03
Anticipated expiration: 2037-07-20
Also published as: CN107240017A

Abstract

The invention provides a block chain transaction management system and a method, wherein an authority side counts the balance and the state of all accounts related to a plurality of previous blocks with the longest history in a block chain at proper time, and the counted information is contained in a clearing message for issuing; in response to determining that the received clearing message is from the authority, the biller replaces the block counted by the authority as the first block of the block chain. Therefore, the memory space of blocks at each node in the block chain system can be reduced, the workload of an bookkeeper for backtracking transaction history when verifying the validity of the transaction message is reduced, the time for positioning or counting data from the block chain and the waiting time required by chaining the transaction data are reduced, the transaction speed is accelerated, and the access efficiency of the block chain is improved.

Description

Block chain transaction management system and method

Technical Field

The present invention relates to a blockchain technology, and more particularly, to a transaction management system and method based on blockchain.

Background

The block chain is a chain data structure formed by combining data blocks in a sequential connection mode according to the time sequence, and is a distributed accounting system which is cryptographically guaranteed to be not falsifiable and counterfeitable. The block structure generally includes a head (head) and a body (body). The block header is used to link to the previous block, and the transaction information recorded by the block is all value exchange activities that occurred after the last block was formed and before the block was created, which feature ensures the integrity of the database. Each piece of transaction data on the block chain can be traced through the structure of the block chain, and can be verified at one stroke.

The block chain better solves the problems of decentralization and distrust through a distributed accounting mode, and each transaction is effective only when an account-taker is counted in the block chain (hereinafter referred to as uplink). The transaction accounting is completed by a plurality of nodes distributed in different places, and each node records a complete account, and each node also verifies the correctness of the recording result of other nodes while participating in the recording. Only when most nodes (or even all nodes) in the whole network consider the record to be correct at the same time, or all nodes participating in the record pass the comparison result in a consistent way, the authenticity of the record can be approved by the whole network, and the uplink is allowed to be recorded.

However, as the size of the blockchain is expanded, the amount of storage required for the blockchain increases, and the time for locating or counting data from the blockchain and the waiting time required for linking transaction data increases with the number of blocks and the transaction amount, which affects the access and utilization efficiency of the blockchain.

Disclosure of Invention

It is therefore an object of the present invention to overcome the above-mentioned drawbacks of the prior art and to provide a blockchain transaction management system that improves the efficiency of blockchain access and usage.

The purpose of the invention is realized by the following technical scheme:

in one aspect, the present invention provides a blockchain transaction management system, the system comprising an authority and an accountant, wherein:

the authority party is used for counting balances and states of all accounts related to a plurality of previous blocks with the longest history in the block chain, and the counted information is contained in the clearing message for issuing;

the bookkeeper is used for determining that the received clearing message comes from the authority party based on the authority party parameters issued by the authority party, and in response to the determination, taking the clearing message as a first block of a block chain, wherein the block number of the first block is the number of the last block in the previous blocks counted by the authority party;

the authority parameters comprise one or more services of the authority and a system public key for signing when the authority executes each service, and a system private key corresponding to the system public key of each service is kept by the authority.

In the above system, the clearing message may further include remaining information unrelated to the account, which is related to the block counted by the authority.

In the above system, the authority may sign the clearing message by using a system private key corresponding to the clearing service before issuing the clearing message.

In the system, the bookkeeper can verify the received clearing message by using the system public key corresponding to the clearing service in the authority parameter.

In the above system, the authority may use the same pair of system public key and system private key for each of its services.

In the above system, the authority may use different pairs of system public and system private keys for different services.

In the above system, the authority may make the statistics in response to a request or periodically.

In the above system, the one or more services may further include a service of changing a rule of the blockchain, and when the service of modifying the blockchain rule is executed, the authority generates a new rule description document and includes the new rule description document in the blockchain rule modification message for distribution, and the bookkeeper verifies the received blockchain rule modification message and records the received blockchain rule modification message in the blockchain.

In the system, the authority can respond to the change of the authority parameter to execute the service of modifying the block chain rule, and the changed authority parameter is contained in the block chain rule modification message for issuing.

In another aspect, the present invention provides a method for managing blockchain transactions, including:

counting balances and states of all accounts related to a plurality of previous blocks with the longest history in a block chain by an authority party, and including the counted information in a clearing message for issuing;

determining, by the biller, that the received clearing message comes from the authority based on authority parameters issued by the authority, wherein the authority parameters include one or more services of the authority and a system public key for signing when the authority executes each service, and a system private key corresponding to the system public key of each service is kept by the authority;

and responding to the determination by the bookkeeper, and taking the clearing message as the first block of the block chain, wherein the block number of the first block is the number of the last block in the previous blocks counted by the authority.

In the above method, the statistics are performed by an authority in response to a request or periodically.

In yet another aspect, the present invention provides a blockchain-based transaction method, including:

sending a transaction request to a payee by a payer, wherein the transaction request comprises a payer account and a payee account to be transacted, the amount to be paid by the payer and a signature generated by the payer by using an account private key of the payer;

the payee sends a transaction response to the payer in response to determining to accept the transaction request, wherein the transaction response comprises the transaction request from the payer and a signature generated by the payee by using a private key of an account of the payee;

the payer responds to the received transaction response, generates a transaction payment message and sends the transaction payment message to the payee to complete the transaction, wherein the transaction payment message comprises the transaction response from the payee and a signature generated by the payer by using an account private key of the payer;

wherein the transaction payment message is issued by either the payee or payer at the appropriate time for posting to the blockchain by the biller.

Compared with the prior art, the invention has the advantages that:

the authority part regularly clears a plurality of blocks with the longest history in the block chain, so that the memory space of each node block in the system can be reduced, and the workload of backtracking the transaction history and the uplink waiting time of an bookkeeper when verifying the validity of the transaction message are reduced, thereby accelerating the transaction speed and improving the access efficiency of the block chain.

Drawings

Embodiments of the invention are further described below with reference to the accompanying drawings, in which:

FIG. 1 is a block chain transaction management system according to an embodiment of the present invention;

fig. 2 is a flowchart illustrating a blockchain transaction management method according to an embodiment of the invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail by embodiments with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

Fig. 1 is a schematic structural diagram of a block chain transaction management system according to an embodiment of the present invention. The system mainly comprises an authority party, an accounting person and a user. Where the authority is a trusted role trusted by billers and users, it may be a governmental agency, industry organization, company, or even individual. The authority is not limited to a particular organization or individual in this context, and there may be multiple authorities, responsible for different services, such as authorities for account management, authorities for money management, etc. The biller is the node in the blockchain responsible for packing various data and information into the blockchain (which may be referred to as uplink). The authority can save various relevant information thereof to the blockchain through the biller, and the user can use the account to conduct various transaction operations such as payment and the like through the blockchain. Each user may have one or more accounts, which are entities that the user transacts in the blockchain, each account having a public and private key pair bound or naturally associated with it, the private key being kept by the account owner without leakage. Neither are the number of billers and user accounts limited, nor are the specific modalities of blockchains used.

More specifically, in the system of embodiments of the present invention, the authority is in a trusted role trusted by the billers and users, and each of the billers and users, upon receiving information from the authority, performs operations related to the information of the authority without confirmation or verification by other users or billers in the system. The authority may perform different services or operations according to actual needs, such as account management, money management, transaction management, and so on. Typically, an authority selects, generates, or sets a public key and a private key for digital signing for the operation or service it is to perform. In one embodiment, an authority may sign with the same pair of public and private keys in all operations or transactions it performs. Preferably, the authority may sign using different asymmetric key pairs in different operations or services, and may also employ different asymmetric encryption algorithms, such as RSA, Elgamal, SM2, elliptic curve encryption algorithm (ECC), and the like. These Public and Private keys may be collectively referred to as a System Public Key (System _ Public _ Key) and a System Private Key (System _ Private _ Key), respectively. Table 1 shows the service of the authority party and the corresponding relationship between the corresponding signature algorithm and the public and private key pair.

TABLE 1

The System _ Public _ Key and the System _ Private _ Key of different services may be the same or different, and the specific algorithms used may also be the same or different. Because the authority may be constituted by a plurality of relatively independent entities, for example, different entities may be allowed to be respectively responsible for account establishment, account management, money issuance, money recovery, clearing, and other services or operations; it is also possible to allow more than two different entities to perform the same transaction, for example, the money issuing operations by two different banks or other financial organizations, and different entities may be signed with different algorithms and asymmetric keys when issuing money.

The authority may set and issue the authority parameters at the initial system setup or at the block chain setup. The authority parameters may include the services of the authority and the System Public Key and signature algorithm corresponding to each service, for example, the contents corresponding to the "service", "algorithm" and "System _ Public _ Key" lines in table 1. And the system private key is strictly kept by an authority and cannot be revealed. Typically, the authority parameters issued by the authority may be stored in the first block of the block chain, and the billers and users may load the authority parameters into their devices for subsequent use after they issue them.

In one embodiment, the services of the authority include clearing services. The authority makes a full clearing of the first few blocks of the block chain history which is the longest, at the appropriate time, in response to a request, or periodically, and counts the balances and status of all accounts involved in these blocks. For example, assuming that the authority clears the first N blocks of the block chain, the authority traverses from the first block to the nth block of the block chain, counts the balances and current states of all accounts involved in the blocks, and includes these contents in the clearing message generated by the authority. Table 2 gives an example of an authority clearing message.

TABLE 2

The authority clearing message is composed of a body and a signature for the body, and the body content may include, but is not limited to, an authority clearing message identifier, a clearing block number (i.e. indicating that the block and its previous blocks have been cleared), a public key corresponding to a clearing service, a list of all account attributes (including balance and status, for example), and the like. And the authority uses a private key corresponding to the clearing service to sign the body of the clearing message of the authority so as to obtain a digital signature of the body. In addition, the information (such as authority parameters) which is related to the blocks counted by the authority and is issued by the authority and unrelated to the account can also be included in the body of the authority clearing message for issuing.

After receiving the clearing message issued by the authority, the bookkeeper verifies the validity of the clearing message of the authority, and the verification content includes but is not limited to: (1) verifying whether the system public key in the clearing message of the authority party has authority, namely verifying whether the system public key in the clearing message exists in authority party parameters which are stored by the account-keeping person previously and corresponds to clearing business of the authority party parameters; (2) and verifying the validity of the digital signature in the clearing message, for example, verifying the digital signature by using a system public key and a cryptographic algorithm corresponding to the clearing service in the authority parameter. After the verification is passed, the accountant uses the clearing message as the first block of the block chain to replace the block indicated by the clearing interception block number in the clearing message of the authority party and all the blocks before the block, and at this time, the number of the first block of the block chain is the clearing interception block number in the clearing message of the authority party. The authority can execute the clearing service or operation regularly or in response to the request, which not only can reduce the storage amount of blocks at each node in the system, but also can reduce the workload of a bookkeeper for backtracking the transaction history when verifying the validity of the transaction message, and simultaneously reduces the time for positioning or counting data from the block chain and the waiting time required for chaining the transaction data, thereby undoubtedly accelerating the transaction speed and improving the access efficiency of the block chain.

In yet another embodiment, the traffic of the authority includes rules for changing the blockchain. The existing blockchain is generally operated according to rules established when the existing blockchain is established, if the rules of the existing blockchain are required to be changed, the approval of all participating nodes is required to be obtained, and the existing version can be updated to be effective. However, with the rapid expansion of the size of the blockchain, it is almost impossible to obtain the agreement of all the participating nodes on the change of the blockchain rule, so that it often happens that part of the nodes adopt the old rule and another part of the nodes use the new rule, so that the blockchain is continuously branched, and the blockchain data is difficult to ensure consistency and reliability. Due to the introduction of the authority, the system of the invention can simply complete the modification and the upgrade of the block chain rule through the authority trusted by the biller and the user, thereby reducing the overall operation and maintenance cost of the block chain and submitting the upgrade efficiency thereof. When the blockchain rule needs to be changed, the authority generates a new rule description document and distributes a blockchain rule modification message. Table 3 gives an example of a blockchain rule modification message. The block chain rule modification message is composed of a text and a signature of the text, and the text content may include, but is not limited to, a block chain rule modification message identifier, release time, a system public key corresponding to a block chain rule modification service, a hash value of a block chain new rule description document, an acquisition address of the block chain new rule description document, and the like. Or directly packaging the new rule of the block chain into the message body. And the authority party signs the block chain rule modification message body by using a system private key corresponding to the block chain rule modification service, so as to obtain a digital signature of the body.

TABLE 3

When receiving a block chain rule modification message issued by an authority, an bookkeeper firstly verifies the validity of the block chain rule modification message, and the verification contents include but are not limited to: (1) whether the system public key in the block chain rule modification message has permission or not, namely whether the system in the message exists in the authority parameter received before and corresponds to the block chain rule modification service or not; (2) and verifying the digital signature verification by using a system public key and a cryptographic algorithm corresponding to the block chain rule modification service, and the like. After the verification is passed, the bookkeeper modifies the block chain rule modification message package uplink, and all nodes follow the new rule defined in the block chain new rule description document. The change of the authority parameter can also be completed by modifying the message according to the block chain rule. When the authority needs to change the authority parameters in response to the request or the specific requirement, the new authority parameters can be included in the block chain rule modification message and issued, or the new authority parameters can be written into the block chain rule description document and the address of the document is included in the block chain rule modification message and issued.

In yet another embodiment, the services of the authority further include managing user accounts, such as establishing an account, destroying an account, freezing an account, and the like. For example, an authority may establish one or more accounts including a real-name account and an anonymous account for a user based on the identity of the user according to an account opening request of the user. The user identity refers to an identification of the real identity of the user, and the user identity can be uniquely determined through the identification, and may be, for example, an identity card number, a passport number, a company registration number, and the like. In one example, the user identity may be populated according to a predetermined population rule to obtain one or more real-name accounts, and the populated content may include, but is not limited to, random numbers, characters, and the like. If the user still needs to establish an anonymous account, the filled real-name account can be encrypted, and the encrypted ciphertext data is used as the anonymous account. The authority may encrypt the real-name account using symmetric encryption or asymmetric encryption methods. For example, the populated real-name account may be encrypted with a public key to obtain an anonymous account, and the anonymous account may be decrypted with a private key such that the user identity is only visible to the authority. For another example, the authority may encrypt the populated real-name account with a symmetric key, for example, using DES, 3DES, IDEA, or other algorithms, and decrypt the anonymous account with the symmetric key. The authority is responsible for keeping the keys used to decrypt the anonymous account closely. The account opening mechanism combining the real-name account and the anonymous account can meet different requirements of users.

For each generated account, the authority uses the account itself as a public key to generate a private key corresponding to the account using a private key generation algorithm in identity-based cryptography. Identity-based Cryptography (IBC) is also an asymmetric encryption mechanism, in which a public key may be an arbitrary character string or bit string, and a private key corresponding to the public key is generated by a Private Key Generator (PKG). A master key and system parameters are automatically generated during initialization, and then a private key generator PKG generates a private key corresponding to a user account based on the master key, the system parameters, and the user account. Where the master key is strictly kept secret by the authority, the system parameters may be published by the authority, and the generated account private key is provided to the user via a secure secret channel.

Meanwhile, the authority sends the information related to the user account to an accountant on the block chain after signing with a system private key corresponding to the account management service, and the accountant records the information related to the user account in the block chain. The biller can verify the digital signature in the received information by using the system public key corresponding to the account management service in the authority parameter, thereby verifying the reliability and validity of the information. After the verification is passed, the account-keeping person links the account opening message, so that the account opening is completed. In addition, the authority can also distribute the system parameters for identity-based encryption in the form of authority parameters and store the authority parameters in the blockchain through the bookkeeper.

After the user receives the private keys corresponding to each account and the system parameters of the authority, the user can use each account to conduct various digital currency transactions based on the blockchain, and related transaction information is recorded in the blockchain through the bookkeeper. For example, a user may sign outgoing messages using their account private key and system parameters, and a party receiving a message may verify the signature of the received message using the user's account itself and system parameters. When a trusted third party needs to acquire the real identity of a user corresponding to an account, a request query can be made to an authority. When the authority approves the request of the trusted third party, if the account is an anonymous account, the account can be decrypted through a key kept by the authority and used for decrypting the anonymous account, and then filling information is removed from decrypted plaintext data according to a preset filling rule, so that the user identity corresponding to the account can be obtained. In this embodiment, the authority does not need to maintain and maintain any database, for example, a database about the correspondence between the user account and the user identity, which reduces both the operation cost and the risk of user information leakage. When the anonymous account is adopted, the user identity is anonymous to other users and an bookkeeper in the digital currency transaction, and only an authoritative party can acquire the real identity of the user according to the user account, so that the transparency and flexibility of the digital currency transaction are ensured, and all transaction parties can be effectively supervised by the authoritative party to prevent illegal actions. Meanwhile, various information related to the user account is stored by adopting a block chain, and the advantages of going to the center management, low transaction cost and the like are maintained.

In addition, the existing block chain needs to be an online transaction, and an bookkeeper needs to wait for the transaction message to be confirmed by most nodes before packing the transaction message into the block chain. As the size of the blockchain expands, the waiting time is longer and longer, which has a great influence on the transaction speed. In the system of the invention, because the authority is in a public credibility role trusted by the bookkeeper and the user, the identity of the user can be confirmed by the authority, compared with the existing block chain, two parties participating in the transaction are more easy to generate a sense of trust, and the parties are dare not to break rules randomly. Therefore, in one embodiment of the invention, the transaction speed between the two parties can be accelerated by adopting an offline transaction mode based on the block chain. The off-line transaction refers to the transaction between two parties through a mode other than the blockchain, and the transaction information is finally linked for storage. More specifically, a payer sends a fast offline transaction request message to a payee as a request for initiating a fast offline transaction. Table 4 gives an example of a fast offline transaction request message where the fast offline transaction request message consists of a body and a signature to the body, the body content may include, but is not limited to, the message identifier, the payer and payee accounts to be transacted, the amount to be paid to the payee by the payer, etc. The payer signs the text of the message using his account private key, thus obtaining a digital signature of the text.

TABLE 4

The payer may send the fast offline transaction request message to the payee in any communication manner other than blockchain. After receiving the fast offline transaction request message, the payee verifies the validity of the fast offline transaction request message, where the verification content may include, but is not limited to, whether the accounts of both parties are correct, whether the payment amount is correct, the validity of the digital signature (for example, verification is performed using the public key of the account of the payer), and the like. After the verification is passed, the payee evaluates and decides whether to accept the fast offline transaction. And if the payee decides to accept the quick off-line transaction, the payee generates a quick off-line transaction response message. Table 5 gives an example of a fast offline transaction response message, which consists of a body and a signature to the body. The body may include, but is not limited to, a fast offline transaction response message identifier, a fast offline transaction request message from a payer, an operation time, and the like. The payee signs the body of the fast off-line transaction response message by using the private key of the payee account to obtain a digital signature of the body.

TABLE 5

The payee also sends a fast offline transaction response message to the payer in an offline manner (i.e., a manner other than blockchain), and the message is used as a response for approving the fast offline transaction. The payer verifies the validity of the fast offline transaction response message after receiving the fast offline transaction response message, and the verification content can include but is not limited to the validity of a digital signature (for example, verification is performed by using a public key of the payee account) and the like. And after the verification is passed, generating a quick off-line transaction payment message. Table 6 gives an example of a fast offline transaction payment message consisting of a body and a signature to the body. The body may include, but is not limited to, a fast offline transaction payment message identifier, a fast offline transaction response message sent by the payee, operation time, and other information. The payer signs the text of the fast off-line transaction payment message by using the private key of the payer account to obtain a digital signature of the text.

TABLE 6

And after the payer sends the quick off-line transaction payment message to the payee, the quick off-line transaction is completed. Any one of the payee or payer can choose to issue the fast off-line transaction payment message at a proper time, and the bookkeeper links the message. Before the message is linked, the payer must ensure the ability of the payer account to redeem the message, otherwise, the rule is violated. After receiving the fast offline transaction payment message, the bookkeeper verifies the validity of the fast offline transaction payment message, and the verification content may include, but is not limited to, the account status of both parties therein, the validity of respective signature, and the like. Particularly, whether the balance of the account of the payer is enough to pay is verified, and when the balance of the account of the payer is found not enough to pay, a punishment process is entered according to the rule. For example, the payer's default obligation may be followed by the authority, the payer's account may be frozen, the payer's credit may be reduced, and so forth.

Fig. 2 is a flow chart of a blockchain transaction management method according to an embodiment of the invention. The method comprises the steps that the authority carries out comprehensive clearing on the first blocks with the longest block chain history at a proper time or regularly, the balance and the state of all accounts involved in the blocks are counted, and the contents are contained in a clearing message generated by the authority and issued. The account-independent information (e.g., authority parameters) issued by the authority, which is related to the blocks counted by the authority, may also be included in the body of the authority clearing message for issuance. When issuing the clearing message, the authority signs the clearing message with a system private key corresponding to the clearing service executed by the authority. The method also comprises the step that after the bookkeeper receives the clearing message issued by the authority, the validity of the clearing message of the authority is verified based on the authority parameters issued by the authority. As introduced above, the authority parameters may include the respective services of the authority and the system public key and signature algorithm corresponding to each service. After the verification is passed, the accountant uses the clearing message as the first block of the block chain to replace the block indicated by the clearing interception block number in the clearing message of the authority party and all the blocks before the block, and the number of the first block of the block chain is the clearing interception block number in the clearing message of the authority party. The authority can execute the clearing service or operation regularly or in response to the request, which not only can reduce the storage amount of blocks at each node in the system, but also can reduce the workload of a bookkeeper for backtracking the transaction history when verifying the validity of the transaction message, and simultaneously reduces the time for positioning or counting data from the block chain and the waiting time required for chaining the transaction data, thereby undoubtedly accelerating the transaction speed and improving the access efficiency of the block chain.

In another embodiment of the present invention, a block chain-based fast transaction method is further provided, wherein two parties performing a transaction complete the transaction quickly through a communication method outside the block chain, and the finally completed transaction information is recorded into the block chain by an bookkeeper at any time, at idle time or at any appropriate time. The method comprises the steps that a payment party sends a transaction request to a receiving party, wherein the transaction request comprises a payment party account and a receiving party account which are to be transacted, the amount to be paid by the payment party and a signature generated by the payment party by using an account private key of the payment party. The transaction request may take the form of a fast offline transaction request message as shown in table 4, for example. The method further includes verifying the validity of the transaction request by the payee after receiving the transaction request, wherein the verification content may include but is not limited to whether the accounts of the two parties are correct, whether the payment amount is correct, the validity of the digital signature (e.g., using the public key of the account of the payer) and the like. After the verification is passed, the payee evaluates and decides whether to accept the fast offline transaction. The method further includes generating a transaction response by the payee and sending it to the payer if the payee decides to accept the transaction request. The transaction response includes a transaction request from the payer and a signature generated by the payee using the payee account private key. The transaction response may take the form of a fast offline transaction response message as shown in table 5, for example. The method further includes verifying the validity of the transaction response by the payer in response to receiving the transaction response, wherein the verification content may include but is not limited to the validity of the digital signature (e.g., verification using the public key of the payee account), and the like, and after the verification is passed, generating a transaction payment message by the payer, which includes the transaction response from the payee and the signature generated by the payer using the private key of the account thereof, and sending the transaction payment message to the payee to complete the transaction. The transaction payment message may take the form of a fast offline transaction payment message as shown in table 6, for example. Therefore, the payer and the payee quickly complete the transaction in an off-line mode, and communication between the two parties, such as a transaction request, a transaction response and a transaction payment message, does not need to be linked up immediately or in real time. The method further includes issuing a transaction payment message by either the payee or payer at an appropriate time and posting it to the blockchain by the biller.

Although the present invention has been described by way of preferred embodiments, the present invention is not limited to the embodiments described herein, and various changes and modifications may be made without departing from the scope of the present invention.

Claims

1. A blockchain transaction management system, the system comprising an authority and an biller, wherein:

the authority party is used for counting the balance and the state of all accounts related to a plurality of previous blocks with the longest history in the block chain from the first block of the block chain, and including the counted information in a clearing message for issuing;

the bookkeeper is used for determining that the received clearing message comes from the authority party based on the authority party parameters issued by the authority party, wherein the authority party parameters are stored in a first block of the block chain, and in response to the determination, the clearing message is used as the first block of the block chain, and the block number of the clearing message is the number of the last block in the first blocks counted by the authority party; wherein the clearing message further comprises the authority parameter;

wherein the authority parameters include one or more services of the authority and a system public key for the authority to sign in executing each service, and a system private key corresponding to the system public key of each service is kept by the authority, and wherein the authority makes the statistics in response to a request or periodically.

2. The system of claim 1, wherein the clearing message further comprises remaining account-independent information involved in the block counted by an authority.

3. The system of claim 1, wherein the authority uses the same pair of system public key and system private key for each of its services.

4. The system of claim 1, wherein the authority uses different system public and system private key pairs for different services.

5. The system according to claim 1, wherein the one or more services further include a service of changing a rule of the blockchain, and when the service of modifying the blockchain rule is executed, the authority generates a new rule description document and includes the new rule description document in the blockchain rule modification message for issuing, and the bookkeeper verifies the received blockchain rule modification message and logs the received blockchain rule modification message in the blockchain.

6. The system of claim 5, wherein the authority performs the service of modifying the blockchain rule in response to a change in the authority parameter, the changed authority parameter being included in the blockchain rule modification message for distribution.

7. A blockchain transaction management method, the method comprising:

counting balances and states of all accounts related to a plurality of previous blocks with the longest history in a block chain from a first block of the block chain by an authority party, and including the counted information in a clearing message for issuing;

determining, by the biller, that the received clearing message comes from the authority based on authority parameters issued by the authority, wherein the authority parameters are stored in a first block of a block chain, the first block includes one or more services of the authority and a system public key for signing when the authority executes each service, and a system private key corresponding to the system public key of each service is kept by the authority;

responding to the determination by the bookkeeper, and taking the clearing message as a first block of the block chain, wherein the block number of the first block is the number of the last block in the previous blocks counted by the authority party; and

wherein the clearing message further includes the authority parameter, wherein the statistics are performed by an authority in response to a request or on a periodic basis.

8. A blockchain based transaction method, wherein the blockchain is maintained in accordance with the system of any one of claims 1-6, the method comprising: