CN109088722B

CN109088722B - Block chain node evolution method and block chain node

Info

Publication number: CN109088722B
Application number: CN201811168607.5A
Authority: CN
Inventors: 何山
Original assignee: Shenzhen Toushi Technology Co ltd
Current assignee: Shenzhen Toushi Technology Co ltd
Priority date: 2018-10-08
Filing date: 2018-10-08
Publication date: 2021-10-19
Anticipated expiration: 2038-10-08
Also published as: CN109088722A

Abstract

The present invention relates to the field of block chain technologies, and in particular, to a block chain link point evolution method and a block chain node. The block link point evolution method comprises the following steps: the link point of the target block acquires the confirmation result of the service function, and the service function is executed by the link point of the target block; and the target block chain node evolves the service function according to the confirmation result. Because the privileged node is not required to be predefined, the service function can be evolved according to the result of the service function executed by the user at the corresponding block chain node, so that the service function role of the node is gradually and flexibly adjusted, the service capability of a participant behind the node is furthest exerted, and the application quality of the whole block chain system is improved under the initial aim of keeping the decentralization of the block chain.

Description

Block chain node evolution method and block chain node

Technical Field

The present invention relates to the field of block chain technologies, and in particular, to a block chain link point evolution method and a block chain node.

Background

The block chain technology integrates the technologies of algorithm, mathematics, cryptography, economic model and the like, establishes a trust mechanism based on the point-to-point network relationship, and becomes a decentralized system which can operate without mutual trust foundation and single centralized mechanism.

In the process of implementing the invention, the inventor finds that the traditional technology has at least the following problems: since the blockchain is decentralized, no central node assigns the role of a service function to other nodes. However, in the block chain application, the user is responsible for managing or executing the service function corresponding to each node. Due to the difference in the management or execution capabilities of the users, the effect of each node after performing the service function is also different, for example, there is a reliable or unreliable difference. If a particular node is predefined to have special business capabilities, it is clear that there are administrative privileges and privileged nodes that compromise the original purpose of blockchain decentralization.

Disclosure of Invention

An object of the embodiments of the present invention is to provide a method for block link point evolution and a block link node, which can follow the principle of block link decentralized, and the service function of the evolution node.

In order to solve the above technical problems, embodiments of the present invention provide the following technical solutions:

in a first aspect, an embodiment of the present invention provides a method for block link point evolution, including:

the target block chain node acquires a confirmation result of a service function, and the service function is executed by the target block chain node;

and the target block chain node evolves the service function according to the confirmation result.

Optionally, each of the service functions corresponds to a weight;

the target block chain node evolves the service function according to the confirmation result, and the method comprises the following steps:

the target block chain node adjusts the weight of the service function according to the confirmation result;

and the target block chain node evolves the service function according to the adjusted weight of the service function.

Optionally, the adjusting, by the target blockchain node, the weight of the service function according to the confirmation result includes:

the target block chain node counts the number of confirmation results, wherein the confirmation results are the results of checking the target block chain node to execute the service function for each non-target block chain node;

and the target block chain node adjusts the weight of the service function according to the number of the confirmation results.

Optionally, the adjusting, by the target block chain node, the weight of the service function according to the number of the confirmation results includes:

the target block chain node judges whether the number of the confirmation results is greater than a preset threshold value;

if the target block chain node is larger than the target block chain node, updating the weight of the service function;

and if the target block link node is smaller than the target block link node, processing the weight of the service function according to preset logic.

Optionally, the evolving, by the target blockchain node, the service function according to the adjusted weight of the service function includes:

and the target block chain node encapsulates the adjusted weight of the service function into an execution result of executing the service function next time, wherein different weights correspond to different credibility of the service function of the target block chain node.

Optionally, the greater the weight, the higher the reliability of the service function;

the smaller the weight, the lower the trustworthiness of the business function.

Optionally, the method further comprises:

when the target block chain node executes the service function, temporarily updating the current weight of the service function according to a preset weight increment;

the target block link point encapsulates the current weight after the business function is temporarily updated into the current execution result of the business function;

the target block chain node sends the current execution result of the service function to each non-target block chain node, so that each non-target block chain node returns a confirmation result according to the current execution result;

the target block chain node adjusts the weight of the service function according to the confirmation result, and the method comprises the following steps:

and the target block chain node adjusts the weight of the temporarily updated service function according to the confirmation result.

Optionally, the sending, by the target block chain node, the current execution result of the service function to each non-target block chain node, so that each non-target block chain node returns a confirmation result according to the current execution result, includes:

the target block chain link defines a time window parameter, and the time window parameter is used for indicating each non-target block chain node to return a confirmation result according to the current execution result within a specified time;

and the target block chain node encapsulates the time window parameter in the current execution result of the service function, and sends the encapsulated current execution result to each non-target block chain node.

and the target block chain node sends the current execution result of the service function and notification information to each non-target block chain node, wherein the notification information is used for indicating each non-target block chain node to return a confirmation result according to the current execution result.

In a second aspect, an embodiment of the present invention provides a block link point evolution apparatus, including:

an obtaining module, configured to obtain a confirmation result of a service function, where the service function is executed by a target blockchain node;

and the evolution module is used for evolving the service function according to the confirmation result.

Optionally, each of the service functions corresponds to a weight;

the evolution module comprises:

an adjusting unit, configured to adjust a weight of the service function according to the confirmation result;

and the evolution unit is used for evolving the service function according to the adjusted weight of the service function.

Optionally, the adjusting unit is specifically configured to:

counting the number of confirmation results, wherein the confirmation results are the results of checking the service function executed by the target block chain node for each non-target block chain node;

and adjusting the weight of the service function according to the number of the confirmation results.

Optionally, the adjusting unit is further specifically configured to:

judging whether the number of the confirmation results is greater than a preset threshold value or not;

if so, updating the weight of the service function;

and if the weight is smaller than the preset weight, processing the weight of the service function according to preset logic.

Optionally, the evolution unit is specifically configured to:

and encapsulating the adjusted weight of the service function in an execution result of executing the service function next time, wherein different weights correspond to different credibility of the service function of the target block chain node.

the smaller the weight, the lower the trustworthiness of the business function.

Optionally, the apparatus further comprises:

the execution module is used for temporarily updating the current weight of the business function according to a preset weight increment when the business function is executed;

the encapsulation module is used for encapsulating the current weight after the temporary updating of the business function into the current execution result of the business function;

a sending module, configured to send a current execution result of the service function to each non-target block link node, so that each non-target block link node returns a confirmation result according to the current execution result;

the adjusting unit is specifically configured to:

and adjusting the weight of the temporarily updated service function according to the confirmation result.

Optionally, the sending module is specifically configured to:

defining a time window parameter, wherein the time window parameter is used for indicating each non-target block chain node to return a confirmation result according to the current execution result within the designated time;

and encapsulating the time window parameter in the current execution result of the service function, and sending the encapsulated current execution result to each non-target block chain node.

Optionally, the sending module is specifically configured to:

and sending the current execution result of the service function and notification information to each non-target block chain node, wherein the notification information is used for indicating each non-target block chain node to return a confirmation result according to the current execution result.

In a third aspect, embodiments of the present invention provide a block link point, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform any one of the block-wise nodal evolution methods.

In a fourth aspect, embodiments of the present invention provide a non-transitory computer-readable storage medium having stored thereon computer-executable instructions for causing a block-link point to perform any one of the block-link point evolution methods described herein.

In a fifth aspect, embodiments of the present invention provide a computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions which, when executed by a block link point, cause the block link point to perform any one of the block link point evolution methods.

In the block link point evolution method and the block link node provided in each embodiment of the present invention, first, a target block link node obtains a confirmation result of a service function, and the service function is executed by the target block link node; and secondly, the target block chain node evolves the service function according to the confirmation result. Because the privileged node is not required to be predefined, the service function can be evolved according to the result of the service function executed by the user at the corresponding block chain node, so that the service function role of the node is gradually and flexibly adjusted, the service capability of a participant behind the node is furthest exerted, and the application quality of the whole block chain system is improved under the initial aim of keeping the decentralization of the block chain.

Drawings

One or more embodiments are illustrated by way of example in the accompanying drawings, which correspond to the figures in which like reference numerals refer to similar elements and which are not to scale unless otherwise specified.

FIG. 1 is a block chain architecture model according to an embodiment of the present invention;

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

fig. 3 is a flowchart illustrating a method for block link point evolution according to an embodiment of the present invention;

FIG. 4a is a schematic diagram of a prediction system provided in accordance with an embodiment of the present invention during initialization;

FIG. 4b is a schematic diagram of FIG. 4a after providing a prediction of system evolution;

FIG. 5 is a schematic flow chart of S32 in FIG. 3;

fig. 6 is a schematic flow chart of S321 in fig. 5;

fig. 7a is a schematic structural diagram of a target block chain node when performing a service function according to an embodiment of the present invention;

figure 7b is a schematic flow diagram of the target blockchain node provided in figure 7a performing a business function;

fig. 8a is a schematic structural diagram of a block link point evolution apparatus according to an embodiment of the present invention;

FIG. 8b is a schematic diagram of the structure of the evolution module in FIG. 8 a;

fig. 8c is a schematic structural diagram of a block link point enodeb according to another embodiment of the present invention;

fig. 9 is a schematic diagram of a block link point according to an embodiment of the present invention.

Detailed Description

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

The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm. Blockchain techniques can store and process information in a decentralized manner and assign different proofs based on the degree of contribution of the participants.

The Block chain provided by the embodiment of the invention comprises a Public Block chain (Public Block Chains), a joint Block chain (Consortium Block Chains) and a Private Block chain (Private Block Chains).

Referring to fig. 1, fig. 1 is a block chain architecture model according to an embodiment of the invention. As shown in fig. 1, the blockchain architecture model 100 includes a data layer 11, a network layer 12, a consensus layer 13, and an intelligent contract layer 14.

The data layer 11 encapsulates the underlying data blocks and associated basic data and basic algorithms such as data encryption and time stamping. The network layer 12 includes a distributed networking mechanism, a data propagation mechanism, a data validation mechanism, and the like. The consensus layer 13 encapsulates various kinds of consensus algorithms for the network nodes. Intelligent contract layer 14 encapsulates various types of scripts, algorithms, and intelligent contracts.

The method for block link point evolution according to the embodiments of the present invention may be implemented in any suitable type of block link node with computing capability, such as a server, a desktop computer, a smart phone, a tablet computer, and other electronic products. The server may be a physical server or a logical server formed by virtualizing a plurality of physical servers. The server may also be a server cluster formed by a plurality of servers capable of communicating with each other, and each functional module may be respectively distributed on each server in the server cluster.

The block link point evolution device in the embodiment of the present invention may be independently arranged in the block link node as a software system, or may be integrated into one of the functional modules in the processor to execute the block link point evolution method in the embodiment of the present invention.

Referring to fig. 2, fig. 2 is a block chain system according to an embodiment of the present invention. As shown in fig. 2, the block chain system 200 includes a normal node 21, a proxy node 22, and a miner node 23.

The regular node 21, the proxy node 22 and the miner node 23 all serve as a block link node in the block chain system 200, which all support a Point-to-Point communication (P2P) and broadcast block chain data to each other through a P2P. Wherein, the ordinary node 21 communicates with the agent node 22, and the agent node 22 communicates with the miner node 23.

In this embodiment, the number of the ordinary nodes 21, the agent nodes 22 and the miner nodes 23 may be multiple and distributed in each geographic area.

The normal node 21 holds the circulated electronic money and has the right to vote in the blockchain system. The common node 21 can perform related transaction operations, but has no block packaging accounting right, and can only synchronously record block data from the related node with the packaging accounting right.

The common node 21 is written with an intelligent contract code, and a user can edit intelligent contract contents by himself according to business needs, for example, the intelligent contract contents include business contents for predicting occurrence of an event, business contents for issuing a two-place best real-time route, business contents for inquiring the two-place best real-time route, and the like.

The user operates the common node 21 to trigger the intelligent contract, so that the common node 21 executes the intelligent contract to obtain the execution result of the corresponding service function. For example, the user operates the general node 21, executes an intelligent contract for predicting the occurrence of an event, causes the general node 21 to obtain a prediction result, and broadcasts the prediction result to the entire network. For another example, the user operates the general node 21 to execute an intelligent contract for issuing the two-place optimal real-time route, so that the general node 21 broadcasts the optimal real-time route to the entire network.

In some embodiments, the blockchain system has a plurality of service functions, wherein each blockchain node is also assigned and responsible for one or more service functions, and each blockchain node completes each service function to implement the application of the blockchain system. When a plurality of blockchain nodes in the blockchain system are responsible for the same service function, on one hand, the number of blockchain nodes responsible for the same service function is large, which results in resource waste. On the other hand, because the participation ability and experience of the user operation block chain nodes are different, when each block chain node has the same service function, the difference of participants cannot be reflected, the professional ability cannot be exerted, and the application effect of the whole group cannot reach a higher level.

For example, in the prediction field, a trader with experience of stock analysis has higher credibility on the opinion of stock tendency, the trader has higher credibility on the prediction result obtained by operating the ordinary node 21, the ordinary shareholder has lower credibility on the prediction result obtained by operating the ordinary node 21, and moreover, the credibility of the opinion of the trader with wrong prediction for a long time is very low. The user A operates the common node 21 to issue the two-place optimal real-time route more accurately, and the user B operates the common node 21 to issue the two-place optimal real-time route more accurately. Therefore, the execution result obtained by the user operating the common node 21 to execute the intelligent contract will vary from person to person, the service capability of the user will vary, the execution result will also vary,

for this reason, in the conventional technology, in order to implement different service functions in different blockchain nodes, it is common practice in centralized systems to set different permissions for different blockchain nodes to ensure that each service function can be safely executed, which requires defining the service functions of different blockchain nodes in advance and specifying which users can install blockchain nodes implementing specific service functions. Obviously, the conventional approach results in the presence of privileged nodes, which runs counter to the original intention of decentralized blockchain. Accordingly, at least one embodiment is provided below to address the deficiencies of the conventional art.

In this embodiment, the common node 21 may pre-store multiple types of intelligent contracts, and may parse the execution type of the intelligent contract according to a trigger request distributed by a user operating the common node 21. The normal node 21 then executes the corresponding intelligent contract according to the execution type of the analyzed intelligent contract to generate the original block data.

The proxy node 22 packs the original block data into block data to be verified. Then, the agent node 22 also signs the block data to be verified, and packages the signed block data to be sent to the miner node 23. The miner node 23 verifies the signed block data by using the public key of the agent node 22, and if the verification is successful, the signed block data is considered to be sent by the legal agent node 22, and then the block data is subjected to consensus processing. And if the verification is not successful, the signed block data is considered to be sent by the illegal proxy node. For example, the proxy node 22 uses its private key to perform a signature operation on the hash content of the current block, and obtains the signature.

The miner node 23 is used for commonly recognizing the block data uploaded by the verification agent node 22. The miner node 23 may support any one of the following consensus algorithms: proof of Work (PoW), Proof of rights of interest (POS), Proof of equity authorization (Delegate Proof of stamp, DPoS), Practical Byzantine Fault Tolerance (PBFT), authorized Byzantine Fault Tolerance (DBFT), and so forth.

Each miner node 23 needs to register with the agent node 22, and after successful registration, the miner node is a valid miner node. The registration process is as follows:

1. the miner node 23 submits the registration information to the agent node 22.

Wherein the registration information includes one or more of the following: the equipment serial number SN of the miner node 23, user information, and the miner's wallet address.

2. The proxy node 22 checks the registration information.

The checking process comprises the following steps: whether the SN exists in a database, whether the SN has been bound to other users, and so on.

3. The proxy node 22 records the registration information.

4. The proxy node 22 returns the registration result to the miner node 23.

5. The proxy node 22 broadcasts the new registration data to the blockchain system 200.

In the block chain system 200, the blocks are carriers for storing transaction summary information, each block includes a block header and a block body, and the information recorded in the block header is used to identify the block itself, the information summary of the previous block, and the position of the block in the whole account. The block body is used for storing the transaction summary information and verifying the transaction information and keeping the transaction from being tampered.

The block chain is formed by connecting each block one by one according to the sequence of the generation time. In the whole block chain, the first block is called a created block, the block height of the created block is 0, the block height of each subsequent block is sequentially added with 1, and the hash value of the previous block header is written in the block header. And all blocks on the block chain are linked by the last block head hash value on each block. Therefore, the block chains have non-tamper-proof properties.

It is understood that the execution of the service function may be implemented in an intelligent contract manner, and may also be implemented in a non-intelligent contract manner.

Referring to fig. 3, fig. 3 is a flowchart illustrating a method for block link point evolution according to an embodiment of the present invention. As shown in fig. 3, the block-link point evolution method S300 includes:

s31, the link point of the target block acquires the confirmation result of the service function, and the service function is executed by the link point of the target block;

in this embodiment, the block link points include a target block link point and a non-target block link node, and for a certain service function, when the block link point executes the certain service function, the block link node is the target block link node, and other block link nodes are non-target block link nodes. It is to be understood that the "target" in the "target blockchain node" is used to distinguish a blockchain node that performs a certain service function from a blockchain node that does not perform the certain service function at a specific time, and the use of "target" or "non-target" is not intended to limit the scope of explanation and protection of the blockchain node provided by the embodiment of the present invention, but only to assist in explaining the embodiment of the present invention. Thus, in some usage environments, the "target blockchain node" and the "non-target blockchain node" may be switched, for example, at time t1, blockchain node Q1 may be able to perform traffic function F1 and blockchain node Q2 may not be able to perform traffic function F1, and thus, for traffic function F1, blockchain node Q1 is the target blockchain node and blockchain node Q2 is the non-target blockchain node.

In the present embodiment, the service function may be any suitable type and can be applied to service logic on a block chain, and the block chain node executes the service function according to the service logic and generates an execution result of the service function, for example, the service function includes a prediction function, a collection prediction result function, a confirmation prediction result function, a distribution route function, and the like.

In order to maintain the original purpose of decentralization of the block chain, during initialization, a plurality of block chain nodes can execute the same service function, after the service function is executed, each block chain node generates an execution result and sends the execution result to other block chain nodes, so that the other block chain nodes return confirmation results according to the execution results, and the confirmation results are used for evaluating the accuracy or reliability or real-time performance of the execution results and the like. For example, referring to fig. 4a, each of the blockchain nodes is used as an initial node to execute the same service function F1, where the blockchain node 41 sends an execution result to the blockchain nodes 42, 43 and 44, and the blockchain nodes 42 and 43 consider the execution result to be more accurate, so that the blockchain nodes 42 and 43 send confirmation results to the blockchain node 41 within a preset time period, and the blockchain node 44 considers the execution result to be less accurate, so that it does not send confirmation results to the blockchain node 41 within the preset time period. At this time, the block link point 41 receives a total of 2 acknowledgments within the preset time period.

And S32, the target block chain node evolves the service function according to the confirmation result.

In this embodiment, as the user operates the block link node multiple times, the role of the service function performed by each block link node changes, and when the corresponding block link node is subsequently operated again, the functional effect achieved by the corresponding block link node is also different, thereby implementing the evolution of the service function of the block link node.

The following describes the embodiment of the present invention in detail by taking a prediction system as an example. In the present embodiment, the prediction system is defined as: and for the things which do not happen yet, asking the user to give a prediction result in a questioning mode, judging whether the prediction of the user is accurate or not after the things happen, and then giving different rewards to the users with different accuracies.

Referring to fig. 4a and 4b, when the prediction of the block chain node 41 in fig. 4a is determined to be successful for multiple times, the reliability of the prediction function of the block chain node 41 corresponding to the participant is improved, and then the block chain node 41 gradually becomes the prediction authoritative node 410 of the prediction function. When the prediction of the blockchain node 42 is determined to fail for a plurality of times, the reliability of the prediction function of the blockchain node 42 corresponding to the participant is lowered, and subsequently, the blockchain node 42 becomes the prediction garbage node 420, and the prediction function of the subsequent blockchain node 42 is gradually eliminated. When the prediction is completed, the block link point 43 can accurately determine that the prediction is correct for a plurality of times, and the block link point 43 serves as a high-reliability determination node 430. When the prediction is finished and the fact result is waited to appear, if the fact result recorded by the block link node 44 is judged to be in accordance with the actual situation for a plurality of times, the block link node 44 is used as the prediction machine node 440 with high reliability. When the prediction system is executed for multiple times, each block link point in the prediction system can show different responsibilities, so that the method is different from the prior art, not only is the same service function in charge of initialization evolved to be professionally responsible for a specific service function, but also the centralized predefined function is avoided.

Therefore, in this embodiment, since there is no need to define privileged nodes in advance, it can evolve the service function according to the result of the user executing the service function at the corresponding blockchain node, thereby gradually and flexibly adjusting the service function role of the node, so as to exert the service capability of the participant behind the node to the maximum extent, and under the original purpose of keeping decentralization of the blockchain, the application quality of the whole blockchain system is improved.

To enable visualization of the evolution of business functions, in some embodiments, each business function corresponds to a weight. For example, referring to table 1, table 1 is a schematic table of fig. 4b providing weights corresponding to traffic functions of each blockchain node in the prediction system. As shown in table 1:

TABLE 1

Business function	Weight of	Weight interpretation
			Predictive function	10	High reliability of prediction function
Function of inputting actual result	0	The reliability of the input actual result is low; the function of recording actual results is not executed
			Actual result verification function	9	High feasibility of checking actual results

As can be seen from table 1, the greater the weight, the higher the reliability of the service function; the smaller the weight, the lower the trustworthiness of the business function. Thus, in some embodiments, it may enable evolution by adjusting the weights of the traffic functions. Referring to fig. 5, S32 includes:

s321, the target block link node adjusts the weight of the service function according to the confirmation result;

and S322, the target block chain node points evolve the service functions according to the adjusted weight of the service functions.

In this embodiment, when the confirmation result satisfies the predetermined condition, the block link point may increase or decrease the weight of the service function. When the confirmation result does not satisfy the preset condition, the block link point may decrease or increase the weight of the service function. The preset conditions are customized by the user according to the service requirements, and the weight adjusting mode is also customized by the user according to the service requirements.

When the target block link point evolves the service function according to the adjusted weight of the service function, it may encapsulate the adjusted weight of the service function in an execution result of executing the service function next time. Because different weights correspond to different credibility of the service function of the target block chain node, other participants can know the credibility of the service function through the weights. For example, in the prediction system, when the prediction authority node 410 predicts an event, the current weight "10" is encapsulated in the execution result of the predicted event, and the other participants obtain the current weight "10" of the prediction authority node 410 by analyzing the execution result, so as to compare the prediction results based on the prediction authority node 410. When other blockchain nodes predict the same event, the current weight "2" is also encapsulated on the execution result of the predicted event, and other participants obtain the current weight "2" of the blockchain node by analyzing the execution result, so that the other participants tend to rely on the prediction result given by the prediction authority node 410 rather than the prediction result given by the blockchain node 410 compared with the prediction authority node 410. Of course, when the prediction authority node 410 makes a bad prediction, a prediction result is not given for a long time or subsequent prediction results are judged to be wrong many times, and other participants may change the trust direction.

In some embodiments, when a target tile link point performs a business function, it may temporarily update the current weight of that business function. For example, first, the user operates the target tile link point to perform the service function F2, and the target tile link point temporarily updates the current weight "5" of the service function by a preset weight increment "2", so that the current weight after the temporary update is "7". Referring to table 2, table 2 provides an exemplary table of temporarily updating the current weight of the service function according to the embodiment of the present invention. As shown in table 2:

TABLE 2

Type of service	Preset weight increment	Status of state
			Service function F1	0.1	To be confirmed
Service function F2	2	To be confirmed
			Service function F3	3.5	To be confirmed

Secondly, the target block chain node encapsulates the current weight after the business function is temporarily updated into the current execution result of the business function. For example, the target block link point encapsulates the temporarily updated current weight "7" in the current execution result.

And thirdly, the target block chain node sends the current execution result of the service function to each non-target block chain node, so that each non-target block chain node returns a confirmation result according to the current execution result.

And finally, the target block link node adjusts the weight after the temporary updating of the service function according to the confirmation result. For example, when the confirmation result satisfies the preset condition, the target blockchain node takes the weight "7" after the temporary update of the service function as the final weight and continues to be the current weight when the next service function is executed. When the confirmation result does not satisfy the preset condition, the target blockchain node adjusts the weight "7" after the temporary update of the service function to "3 (5-2 = 3)" as a final weight, and takes the final weight as the current weight when the next service function is executed.

In some embodiments, when sending the current execution result of the service function to each non-target blockchain node, first, the target blockchain node may define a time window parameter, where the time window parameter is used to indicate that each non-target blockchain node returns a confirmation result according to the current execution result within a specified time. Secondly, the target block chain node encapsulates the time window parameter into the current execution result of the service function, and sends the encapsulated current execution result to each non-target block chain node. For example, in the prediction system, the time window parameter is a time from the time when the target blockchain node receives the prediction result to the time before the actual event occurs. It is not valid for the non-target blockchain node to send an acknowledgement outside the specified time of the time window parameter.

The difference from the manner of sending the acknowledgement result described in the above embodiments is that: and when the target block chain node sends the current execution result of the service function to each non-target block chain node, the target block chain node simultaneously sends notification information to each non-target block chain node, wherein the notification information is used for indicating each non-target block chain node to return a confirmation result according to the current execution result.

It is understood that other manners may be used to notify the non-target block node of sending the acknowledgement result, which is not described herein again.

In order to make the validation result and the adjustment of the weight more reliable, in some embodiments, please refer to fig. 6, S321 includes:

s3211, the target block chain node counts the number of the confirmation results, and the confirmation results are the results of checking the service function executed by the target block chain node for each non-target block chain node;

and S3212, the target block link node adjusts the weight of the service function according to the number of the confirmation results.

In this embodiment, in the blockchain system, after the target blockchain node generates an execution result of a certain service function, the target blockchain node sends the execution result to each non-target blockchain node according to a preset logic. The selection of the non-target blockchain node may be all blockchain nodes in the blockchain system, or may be a part of blockchain nodes, and the selected proportion threshold of the non-target blockchain node may be user-defined. For example, when the non-target blockchain node is selected, the non-target blockchain node is a node whose delay error of the communication speed with the target blockchain node is maintained at a preset time period, and the number of the non-target blockchain nodes is 200 randomly selected when the above conditions are satisfied.

As described above, the target blockchain node sends the execution result to each non-target blockchain node, and each non-target blockchain node verifies the execution result to generate the confirmation result. The confirmation result can be used to evaluate the quality of the execution result. For example, in a prediction system, in favor of the block chain node 42 to perform the prediction function, the favored block chain node sends an acknowledgement to the block chain node 4. If not, no confirmation result is sent to the blockchain node 42. The number of confirmation results is then counted at block link points 42.

In some embodiments, when the target blockchain node adjusts the weight of the service function according to the number of the confirmation results, it may determine whether the number of the confirmation results is greater than a preset threshold; if so, updating the weight of the service function; and if the weight is smaller than the preset weight, processing the weight of the service function according to preset logic. For example, when the number of the target blockchain node statistics validation results is greater than 51% of the total number of blockchain nodes, the target blockchain node updates the weight of the service function, for example, agrees to increase the weight or agrees to decrease the weight.

In order to further understand the embodiment of the present invention, the embodiment of the present invention is described in detail by taking a navigation system as an example.

The navigation system comprises N block chain nodes, and the initial state of the service function of each block chain node is the same when the navigation system is started to be started. As the user application degree deepens, the block link points evolve into two categories:

the publisher node: the node that issued the best route. Such nodes are often operated by users who are familiar with the route, who post the best real-time route to both locations, and post the information synchronized to other blockchain nodes in the blockchain system. If the user of the other blockchain node needs the route, the confirmation result is sent to the publisher node after the actual verification, and then the weight change of the publisher node in the publishing function is confirmed.

The inquirer node: the node of the best route is used. When the optimal real-time route of two places needs to be inquired, other users use the inquired route to drive after the inquiry. The other users generate confirmation results for the publisher nodes according to actual conditions (the route is consistent with the actual conditions and the route is not consistent with the actual conditions) encountered during driving, and the confirmation results are sent to the publisher nodes. In some embodiments, after the confirmation results sent by the querier node are summarized at the publisher node, the blockchain system can identify which querier node sent the confirmation result is true, and which querier node sent the confirmation result is not true, so that the blockchain system can also score the honesty of the querier, refresh the honesty of the querier, for example, increase or decrease the weight of the querier.

Along with the operation practice of the user, the blockchain system may have a publisher node with high weight, a publisher node with low weight, an honest querier node, and a dishonest querier node.

In the above embodiments, referring to fig. 7a, the target blockchain node 700 includes the service function module 71, the node capability management module 72, and the data synchronization module 73. The service function module 71, the node capability management module 72 and the data synchronization module 73 cooperate to complete the evolution of the service function.

The service function module 71 is used to provide a user interaction device, responding to the operation input by the user, to execute various service functions, for example, three service functions as shown in table 1. The business function performed by the user will be recorded in the node capability management module 72 and have an impact on the weight of the business function. The user performs an operation on a target blockchain node, and the execution result is synchronously sent to other blockchain nodes by the data synchronization module 73.

The node capability management module 72 is configured to refresh and record the weight of each service function in the target block chain node, thereby implementing the evolution of the node capability.

The data synchronization module 73 is configured to send an execution result of the service function of the node to other blockchain nodes, and obtain capability confirmation of the weight of the service function of the node from the other blockchain nodes. In the initial state, the service functions on each node are the same, and the weight of each service function is an initial value.

Referring to fig. 7b, the process of the target block link point executing the service function is as follows:

and S1.0, receiving user operation.

The service function module 71 receives a user operation. The user executes the service function on the service function module 71, and there may be a difference between the service functions executed by different users, or there may be no difference between the service functions executed by different users.

And S1.1, sending user operation.

The service function module 71 transmits the user operation to the node capability management module 72. The user operation includes: user identification and operation type. Taking the prediction system as an example, the user identifier is user001, and the operation type is a prediction item.

S1.2, temporarily updating the weight.

The node capability management module 72 temporarily updates the weight of the own node. For example, for the prediction function, the weight is increased by a certain value every time the user participates. However, the weight increase is only temporary at this time, which also requires a weight confirmation process to complete the actual increase.

And S1.3, synchronously executing results.

The service function module 71 synchronously transmits the execution result to the data synchronization module 73.

And S1.4, sending an execution result.

The data synchronization module 73 sends the execution result to the other blockchain node 74.

S1.5, sending a confirmation result.

The other blockchain node 74 sends an acknowledgement result to the data synchronization module 73.

S1.6, forwarding the confirmation result.

The data synchronization module 73 forwards the confirmation result to the node capability management module 72.

S1.7, confirming the updating of the weight.

And the node capacity management module updates the weight according to the number of the confirmation results.

In the above embodiments, the service function module 71, the node capability management module 72 and the data synchronization module 73 may be general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), single-chip processors, arm (acorn RISC machines) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components or any combinations of these components. Also, it may be any conventional processor, controller, microcontroller, or state machine, or may be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

In summary, the method for block chain evolution provided by the embodiment of the present invention completely meets the original purpose of block chain decentralization, and does not need a pre-designed privileged node, so that the reliability of the service system is strong; in the evolution process of the service system, the function weight of the node is changed under the common supervision of all the nodes, so that professional people can do professional things, and the professional value of the whole service system is enhanced.

It should be noted that, in the foregoing embodiments, a certain order does not necessarily exist between the foregoing steps, and it can be understood by those skilled in the art from the description of the embodiments of the present invention that, in different embodiments, the foregoing steps may have different execution orders, that is, may be executed in parallel, may also be executed in an exchange manner, and the like.

As another aspect of the embodiments of the present invention, an embodiment of the present invention provides a block link point evolution apparatus. The block chain link point evolution device provided by the embodiment of the invention can be used as one of the software functional units, and comprises a plurality of instructions, wherein the instructions are stored in the memory, and the processor can access the memory and call the instructions to execute so as to complete the block chain node evolution method.

Referring to fig. 8a, a block link point enodeb 800 includes: an obtaining module 81 and an evolving module 82.

The obtaining module 81 is configured to obtain a confirmation result of a service function, where the service function is executed by a target blockchain node;

the evolution module 82 is configured to evolve the service function according to the confirmation result.

Because the privileged node is not required to be predefined, the service function can be evolved according to the result of the service function executed by the user at the corresponding block chain node, so that the service function role of the node is gradually and flexibly adjusted, the service capability of a participant behind the node is furthest exerted, and the application quality of the whole block chain system is improved under the initial aim of keeping the decentralization of the block chain.

In some embodiments, each service function corresponds to a weight. Referring to fig. 8b, the evolution module 82 includes: an adjusting unit 821 and an evolution unit 822.

The adjusting unit 821 is configured to adjust the weight of the service function according to the confirmation result;

the evolution unit 822 is configured to evolve the service function according to the adjusted weight of the service function.

In some embodiments, the adjusting unit 821 is specifically configured to: counting the number of confirmation results, wherein the confirmation results are the results of checking the service function executed by the target block chain node for each non-target block chain node; and adjusting the weight of the service function according to the number of the confirmation results.

In some embodiments, the adjusting unit 821 is further specifically configured to: judging whether the number of the confirmation results is greater than a preset threshold value or not; if so, updating the weight of the service function; and if the weight is smaller than the preset weight, processing the weight of the service function according to preset logic.

In some embodiments, evolution unit 822 is specifically configured to: and encapsulating the adjusted weight of the service function in an execution result of executing the service function next time, wherein different weights correspond to different credibility of the service function of the target block chain node.

In some embodiments, the greater the weight, the higher the trustworthiness of the business function; the smaller the weight, the lower the trustworthiness of the business function.

In some embodiments, referring to fig. 8c, the block link point enodeb 800 further includes: an execution module 83, a packaging module 84, and a sending module 85.

The execution module 83 is configured to, when executing the service function, temporarily update the current weight of the service function according to a preset weight increment;

the encapsulating module 84 is configured to encapsulate the current weight after the temporary update of the service function into a current execution result of executing the service function;

the sending module 85 is configured to send the current execution result of the service function to each non-target block link node, so that each non-target block link node returns a confirmation result according to the current execution result.

Then: the adjusting unit 821 is specifically configured to: and adjusting the weight of the temporarily updated service function according to the confirmation result.

In some embodiments, the sending module 85 is specifically configured to: defining a time window parameter, wherein the time window parameter is used for indicating each non-target block chain node to return a confirmation result according to the current execution result within the designated time; and encapsulating the time window parameter in the current execution result of the service function, and sending the encapsulated current execution result to each non-target block chain node.

In other embodiments, the sending module 85 is specifically configured to: and sending the current execution result of the service function and notification information to each non-target block chain node, wherein the notification information is used for indicating each non-target block chain node to return a confirmation result according to the current execution result.

It should be noted that the above-mentioned device for evolution of a block link node can execute the method for evolution of a block link node provided in the embodiments of the present invention, and has corresponding functional modules and beneficial effects of the execution method. For details of the block link point evolution apparatus, reference may be made to the block link point evolution method provided in the embodiments of the present invention.

As another aspect of the embodiments of the present invention, the embodiments of the present invention provide a block link point. Referring to fig. 9, the block link point 900 includes: one or more processors 91 and memory 92. In fig. 9, one processor 91 is taken as an example.

The processor 91 and the memory 92 may be connected by a bus or other means, and fig. 9 illustrates the connection by a bus as an example.

The memory 92, which is a non-volatile computer-readable storage medium, may be used for storing non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions/modules corresponding to the block link point evolution method in the embodiment of the present invention. The processor 91 executes the block link point evolution method of each of the above embodiments or various functional applications and data processing of the block link point evolution apparatus of each of the above embodiments by running a nonvolatile software program, instructions and modules stored in the memory 92.

The memory 92 may include high speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, the memory 92 may optionally include memory located remotely from the processor 91, and such remote memory may be connected to the processor 91 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The program instructions/modules are stored in the memory 92 and when executed by the one or more processors 91, perform the block-link point evolution method in any of the above-described method embodiments, for example, to perform the block-link point evolution method in each of the above-described embodiments, or various functional applications and data processing of the block-link point evolution apparatus in each of the above-described embodiments.

Embodiments of the present invention also provide a non-transitory computer-readable storage medium storing computer-executable instructions for causing a block-link point to perform the block-link point evolution method as described in any one of the above.

An embodiment of the invention provides a computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions which, when executed by a block link point, cause the block link point to perform any one of the block link point evolution methods.

In summary, since the privileged node is not required to be defined in advance, it can evolve the service function according to the result of the user executing the service function at the corresponding block link node, thereby gradually and flexibly adjusting the service function role of the node, so as to exert the service capability of the participant behind the node to the maximum extent, and improve the application quality of the whole block link system under the original intention of keeping the decentralization of the block link.

The above-described embodiments of the apparatus or device are merely illustrative, wherein the unit modules described as separate parts may or may not be physically separate, and the parts displayed as module units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network module units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a general hardware platform, and certainly can also be implemented by hardware. Based on such understanding, the above technical solutions substantially or contributing to the related art may be embodied in the form of a software product, which may be stored in a computer-readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.

Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; within the idea of the invention, also technical features in the above embodiments or in different embodiments may be combined, steps may be implemented in any order, and there are many other variations of the different aspects of the invention as described above, which are not provided in detail for the sake of brevity; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for block-link node evolution, comprising:

a link point of a target block acquires a confirmation result of a service function, wherein the service function is executed by the link node of the target block, when the link point of the block executes a certain service function, the link node of the block is the link node of the target block, and other link nodes of the block which do not execute the service function are non-target link nodes of the block; the target block chain node executes the service function, generates an execution result of the service function and sends the execution result to the non-target block chain node, and the non-target block chain node returns a confirmation result according to the execution result, wherein the confirmation result is used for evaluating the quality of the execution result;

the target block chain node evolves the service function according to the confirmation result;

each business function corresponds to a weight; the target block chain node evolves the service function according to the confirmation result, and the method comprises the following steps:

the target block chain node evolves the service function according to the adjusted weight of the service function;

the target block chain node evolves the service function according to the adjusted weight of the service function, and the method comprises the following steps:

2. The method of claim 1, wherein the target blockchain node adjusting the weight of the service function according to the confirmation result comprises:

3. The method of claim 2, wherein the target blockchain node adjusting the weight of the service function according to the number of the confirmation results comprises:

4. The method of claim 1,

the greater the weight, the higher the reliability of the service function;

the smaller the weight, the lower the trustworthiness of the business function.

5. The method according to any one of claims 2 to 4,

the method further comprises the following steps:

6. The method according to claim 5, wherein the target blockchain node sends a current execution result of the service function to each non-target blockchain node, so that each non-target blockchain node returns a confirmation result according to the current execution result, including:

7. The method according to claim 5, wherein the target blockchain node sends a current execution result of the service function to each non-target blockchain node, so that each non-target blockchain node returns a confirmation result according to the current execution result, including:

8. A block link point, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the block-link point evolution method of any one of claims 1 to 7.