Contract creation method and apparatus, and related product

Abstract

The invention discloses a contract creation method and device and a related product. Firstly, a first contract creation request initiated by a user side is received; determining a contract file according to the first contract file path; carrying out multi-thread downloading on the contract file, wherein the multi-thread downloading process comprises the step of reading the contract file into a plurality of pieces of binary data; finally, the multiple pieces of binary data are recombined, and recombined binary data are obtained; and performing broadcast consensus on the recombined binary data in other nodes except the target node in the block chain system to complete contract creation. Visibly, in the technical scheme of the invention, the contract file is determined according to the request information carried in the first contract creation request, and then the contract file is transmitted by adopting a multi-thread downloading means, so that the situation that the contract file with relatively large data is transmitted at one time is avoided; and the conditions of low transmission speed and long time consumption caused by transmission of a relatively large contract file are avoided, so that the contract creation efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a contract creation method, device and related products. Background Art

[0002] Smart contracts are automated contracts based on blockchain technology. With the continuous development of blockchain technology, smart contracts are increasingly used in blockchain. Currently, before using smart contracts, you need to create them first.

[0003] In the related art, before creating a smart contract, it is necessary to compile the smart contract file first, and then transfer the compiled smart contract file to the blockchain, which creates the contract. Since the data size of smart contract files varies, when the data of the compiled smart contract file is large, the speed of transmitting the smart contract file will be very slow and time-consuming, which seriously affects the efficiency of contract creation.

[0004] Therefore, how to improve the efficiency of contract creation has become a technical problem that needs to be solved urgently in the current field. Summary of the invention

[0005] The embodiments of the present application provide a contract creation method, device and related products, aiming to improve the efficiency of contract creation.

[0006] The first aspect of the present application provides a contract creation method, comprising:

[0007] Receive a first contract creation request initiated by a user end, where the first contract creation request includes a first contract file path corresponding to the user end;

[0008] Determine the contract file according to the first contract file path;

[0009] Performing multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into a plurality of binary data;

[0010] Reorganizing the plurality of binary data to obtain reorganized binary data;

[0011] In the remaining nodes of the blockchain system except the target node, the reorganized binary data is broadcasted and consensus is reached to complete the creation of the contract.

[0012] A second aspect of the present application provides a contract creation device, comprising:

[0013] A first creation request receiving unit, configured to receive a first contract creation request initiated by a user terminal, wherein the first contract creation request includes a first contract file path corresponding to the user terminal;

[0014] A contract file determining unit, configured to determine a contract file according to the first contract file path;

[0015] A multi-thread download unit, used for performing multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into a plurality of binary data;

[0016] A binary data reorganization unit, used for reorganizing the plurality of binary data to obtain reorganized binary data;

[0017] The data broadcast consensus unit is used to broadcast consensus on the reorganized binary data in the remaining nodes of the blockchain system except the target node to complete the creation of the contract.

[0018] A third aspect of the present application provides a computer device, the device comprising a processor and a memory:

[0019] The memory is used to store a computer program and transmit the computer program to the processor;

[0020] The processor is used to execute the steps of the contract creation method provided in the first aspect according to the instructions in the computer program.

[0021] The fourth aspect of the present application provides a computer-readable storage medium, which is used to store a computer program. When the computer program is executed, the steps of the contract creation method provided in the first aspect are implemented.

[0022] The fifth aspect of the present application provides a computer program product, including a computer program, which, when executed, implements the steps of the contract creation method provided in the first aspect.

[0023] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0024] In the technical solution of the present application, the first contract creation request initiated by the user end is first received, and the contract file is determined according to the request information carried in the first contract creation request, and then the contract file is downloaded in multiple threads, and the contract file is read as multiple binary data during the multi-thread download process, and finally the multiple binary data are reorganized to obtain the reorganized binary data, and the reorganized binary data is broadcasted and consensus is reached in the remaining nodes of the blockchain system except the target node to complete the creation of the contract. It can be seen that in the technical solution of the present application, the contract file is first determined according to the request information carried in the first contract creation request, and then the contract file is transmitted by means of multi-thread download. In this way, the one-time transmission of a large contract file is avoided, and the transmission of a large contract file resulting in slow transmission speed and long time consumption is avoided, thereby improving the efficiency of contract creation. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A flowchart for contract compilation and deployment in related technologies;

[0026] Figure 2 A scenario architecture diagram of a contract creation method provided in an embodiment of the present application;

[0027] Figure 3 An overall flow chart of a contract creation method provided in an embodiment of the present application;

[0028] Figure 4 A flowchart of a contract creation method provided in an embodiment of the present application;

[0029] Figure 5 A flowchart of compiling a contract file in the contract creation method provided in an embodiment of the present application;

[0030] Figure 6 A scene diagram for determining a contract file in the contract creation method provided in an embodiment of the present application;

[0031] Figure 7 A scene diagram of multi-threaded downloading of contract files in the contract creation method provided in an embodiment of the present application;

[0032] Figure 8 A scenario diagram of broadcasting consensus in the contract creation method provided in an embodiment of the present application;

[0033] Fig. 9 A schematic diagram of batch creation of contracts in the contract creation method provided in an embodiment of the present application;

[0034] Fig.10 A schematic diagram of the structure of a contract creation device provided in an embodiment of the present application;

[0035] Fig.11 A schematic diagram of the structure of the server in the embodiment of the present application;

[0036] Fig.12 A schematic diagram of the structure of a terminal device in an embodiment of the present application. DETAILED DESCRIPTION

[0037] The embodiments of the present application are described below in conjunction with the accompanying drawings.

[0038] First, several terms that may be involved in the embodiments of the present application are explained below.

[0039] Multi-threaded downloading: Open multiple threads to download the same contract file at the same time, and each thread downloads a different part of the file to increase the download speed.

[0040] Bytecode: including Wasm (WebAssembly) and Evm (Ethereum Virtual Machine) bytecode.

[0041] Wasm: Wasm (WebAssembly) is a low-level bytecode format, a portable binary format that can run on multiple platforms. In blockchain technology, Wasm can be used to write smart contracts. Usually, after writing a smart contract, it is compiled into Wasm bytecode and then run on the blockchain. Among them, the file size of Wasm is about 200k.

[0042] Evm: Evm is a stack-based virtual machine that supports multiple programming languages, such as Solidity.

[0043] Solidity: Solidity is a contract-oriented programming language and one of the main programming languages ​​for Ethereum smart contracts. In blockchain technology, Solidity can be used to write smart contracts. The Solidity compiler is usually used to compile the Solidity code into EVM bytecode, and then the bytecode is deployed to the Ethereum network. Among them, the file size of Solidity is about 200k.

[0044] Contracts running on Docker: including Go language contracts and Java language contracts. Go contracts are directly compiled into platform machine code and compressed for deployment and calling. Java contracts are compiled into Java bytecode for deployment and calling. Among them, the file size of Dockergo is about 3M; the file size of Dockerjava is about 32M.

[0045] BT (BitTorrent) download: BT is a peer-to-peer (P2P) file sharing protocol. Files are divided into several small file blocks, each of which is usually 512KB to 4MB. This allows different parts of the same file to be downloaded at the same time, thereby speeding up the overall download speed. The metadata information of the file is usually transmitted in the form of a seed file, which includes the file name, size, block information, hash value, etc. The seed file is the unique identifier of the download task, and the file can only be downloaded through the seed file.

[0046] Direct download: FTP (File Transfer Protocol) download. FTP is a file transfer protocol. Through the FTP client and FTP server connection, files can be uploaded and downloaded. FTP download can provide higher download speed and stability, but requires knowledge of FTP server and client configuration and use.

[0047] Magnet download: In the magnet download method, a unique text-formatted fingerprint is generated based on the hash value of the downloaded file, and the file is then identified and downloaded using this fingerprint. Since anyone can generate such a file fingerprint, magnet download can be performed normally without any central organization (server), ensuring the stability of the download.

[0048] Smart contracts are automated contracts based on blockchain technology. With the continuous development of blockchain technology, smart contracts are increasingly used in blockchain, such as decentralized applications and supply chain management. Currently, before using smart contracts, you need to create them first.

[0049] Figure 1 This is a flowchart of contract compilation and deployment in related technologies. Figure 1 The contract compilation and deployment process in the related technology is introduced. In the related technology, during compilation, the compiled source code is generated into bytecode. During deployment, a deployment request is generated according to the bytecode, which includes the bytecode, and then the deployment request is transmitted to the blockchain, which creates the contract according to the deployment request. Since the data size of the bytecode varies, such as from a few k to tens of m, or when the network speed is slow, the transmission speed of the deployment request will be very slow and time-consuming, which seriously affects the efficiency of contract creation. Therefore, how to improve the efficiency of contract creation has become a technical problem that needs to be solved urgently in the current field.

[0050] In view of the above problems, a contract creation method, device and related products are provided in the present application, the purpose of which is to improve the efficiency of contract creation. In the technical solution provided in the present application, the first contract creation request initiated by the user end is first received, and the contract file is determined from the user end according to the request information carried in the first contract creation request, and then the contract file is downloaded by multi-threading, that is, the contract file is read as multiple binary data by multi-threaded download, thereby avoiding the slow transmission speed and long time caused by the one-time transmission of a large contract file. Finally, the multiple binary data are reorganized to obtain the reorganized binary data, and the reorganized binary data is broadcasted and consensus is reached in the remaining nodes of the blockchain system except the target node to complete the creation of the contract. It can be seen that in the technical solution of the present application, the contract file is first determined according to the request information carried in the first contract creation request, and then the contract file is transmitted by multi-threaded download, which improves the efficiency of contract creation.

[0051] The execution subject of the contract creation provided in the embodiment of the present application can be a terminal device. For example, a first contract creation request initiated by a user terminal is received on a terminal device. As an example, the terminal device can specifically include but is not limited to a mobile phone, a desktop computer, a tablet computer, a laptop computer, a PDA, an intelligent voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, etc. The execution subject provided in the embodiment of the present application can also be a server, that is, the first contract creation request initiated by a user terminal can be received on the server. The contract creation method provided in the embodiment of the present application can also be executed collaboratively by a terminal device and a server. Therefore, in the embodiment of the present application, there is no limitation on the implementation subject for executing the technical solution of the present application.

[0052] Figure 2 The following is an example of a scenario architecture diagram of a contract creation method, which includes a server and various forms of terminal devices. Figure 2 The server shown can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. In addition, the server can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0053] The contract creation method provided in this application relates to the field of blockchain. Among them, blockchain is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods, each of which contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product service layer, and the application service layer.

[0054] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation control. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining the generation of public and private keys (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first adapts the interface for parsing and authentication (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation control module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarms, control network conditions, control node equipment health status, etc.

[0055] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0056] Next, combine Figure 3 The technical solution of this application is introduced. Figure 3 , Figure 3 The overall flow chart of a contract creation method provided in an embodiment of the present application is as follows: Figure 3 As shown:

[0057] In the technical solution of the present application, in order to improve the efficiency of contract creation, it is proposed to use multi-threaded downloading to transmit contract files. Specifically, the target node applied to the blockchain system is taken as an example to illustrate the contract creation process of the present application, and the target node is any node in the blockchain system. First, the target node receives the first contract creation request initiated by the user end, and then determines the contract file from the user end according to the request information carried in the first contract creation request. The request information includes the first file path, and uses multi-threaded downloading to transmit the contract file, that is, the contract file is read as multiple binary data for easy transmission, thereby avoiding slow transmission speed and long time consumption. Finally, the target node reorganizes the multiple binary data and broadcasts the reorganized binary data to the other nodes in the blockchain system for consensus. In this way, the creation of the contract is completed efficiently.

[0058] Figure 4 A flowchart of a contract creation method provided in an embodiment of the present application. Figure 4 The contract creation method shown includes:

[0059] S401: Receive a first contract creation request initiated by a user terminal.

[0060] In this step, the first contract creation request includes the first contract file path corresponding to the user end. The first contract creation request also includes the download type and the digital signature of the user end, and the download type includes direct link download, BT download and magnet download. It is understandable that when generating the first contract creation request, the user end will also sign the first contract creation request with a private key.

[0061] Specifically, the first contract creation request in this application can be embodied in code form, as shown below:

[0062] . / cmc client contract user create\

[0063] --contract-name=dockerjava\

[0064] --runtime-type=DOCKER_JAVA\

[0065] --by1e-code-remote-path="81,222.32.12:9912, / user / contracts / api.jar"\

[0066] --version=1.0\

[0067] --sdk-conf-path=. / testdata / sdk_config.yml\

[0068] --admin-key-file-paths=. / testdata / crypto-config / wx-org1.chainmaker.org / user / admin1 / admin1.sign.key\

[0069] --admin-crt-file-paths=. / testdata / crypto-config / wx-org1.chainmaker.org / user / admin1 / admin1.sign.crt\

[0070] --sync-result=true\

[0071] --perams="{}"

[0072] In the --by1e-code-remote-path field of the above code, only the IP address, port number and contract file path are displayed. In actual application scenarios, the request information carried in the first contract creation request can also be set according to the actual situation, such as setting the separator, contract file version number, etc. If you need to modify the request information carried in the first contract creation request, just modify the --by1e-code-remote-path field in the above code.

[0073] It should also be noted that before the target node receives the first contract creation request initiated by the user terminal, the user will first write a smart contract on the user terminal to generate the first contract creation request. Figure 5 A flowchart of compiling a contract file in the contract creation method provided in the embodiment of the present application is shown below in conjunction with Figure 5 The process of compiling contract files in this application is described. The user end compiles the written smart contract into bytecode through the compiler in combination with the smart contract SDK. In the blockchain system, the contract types include Wasm, Solidity, and contracts based on Docker. In this application, any of the above contract types can be used to create a contract. For example: if a java contract is written using a contract based on Docker, the corresponding jar package will be generated after compilation by the compiler.

[0074] S402: Determine the contract file according to the first contract file path.

[0075] Figure 6This is a scene diagram for determining a contract file in the contract creation method provided in the embodiment of the present application. Figure 6 Step S402 in the present application is described. According to step S401, it is known that the request information carried in the first contract creation request includes the first contract file path. It can be understood that in this step, the contract file can be determined according to the first contract file path.

[0076] It can be further understood that the --bye-code-remote-path field in the first contract creation request introduced in step S401 includes request information, that is, in this step, the contract file can be determined according to the --bye-code-remote-path field. In this way, the convenience of finding and determining the contract file is improved.

[0077] It should be noted that before determining the contract file according to the first contract file path, the IP address and port number corresponding to the user end can also be verified. The IP address and port number are the remaining request information carried by the first contract creation request to verify the authenticity of the IP address and port number. If both the IP address and port number are verified, that is, if the IP address and port number are valid, the contract file is determined according to the first contract file path; if any one of the parameters of the IP address and port number fails to be verified, that is, if the IP address and port number are invalid, it is prohibited to determine the contract file according to the first contract file path. In this way, the security of contract creation is further improved.

[0078] In an achievable implementation, the verification result can be returned to the user in the form of a page. If the verification is successful, it can be displayed to the user in the form of a progress bar for multi-threaded downloading of the contract file; if the verification is unsuccessful, it can be displayed to the user in the form of a pop-up window with the words "Verification failed, unable to create the contract" displayed in the pop-up window.

[0079] S403: Perform multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into multiple binary data.

[0080] In this step, after the contract file is determined, multi-threaded download is started for the contract file, that is, the contract file is read as multiple binary data during the multi-threaded download process, and the multiple binary data can be stored in the memory of the target node to facilitate the reorganization of the subsequent process. Among them, multi-threading includes two or more threads. In this way, the situation of slow transmission speed and long time caused by transmitting a large contract file at one time is avoided.

[0081] Figure 7 A scene diagram of multi-threaded downloading of contract files in the contract creation method provided in the embodiment of the present application. Figure 7The example in illustrates step S403 in the present application. In this example, the multithreading may include three threads, such as the first thread, the second thread, and the third thread. The contract file is downloaded in multiple threads in the first thread, the second thread, and the third thread, respectively. It can be understood that the contract file is segmented and read as the first binary data in the first thread; the contract file is segmented and read as the second binary data in the second thread; and the contract file is segmented and read as the third binary data in the third thread, wherein the parts of the contract file read by the first thread, the second thread, and the third thread are all different. In this way, the multithreaded download of the contract file is realized.

[0082] S404: Reorganize the multiple binary data to obtain reorganized binary data.

[0083] In this step, since the binary data read by each thread may be different, it is possible that multiple binary data are not obtained at the same time. In this case, when all the binary data read are obtained in the memory of the target node, the multiple binary data can be reorganized to obtain the reorganized binary data. In this way, multi-threaded download of contract files is realized, the transmission speed is improved, and the complete reorganized binary data is obtained in a short time. Among them, in this application, the target reorganized data model can be trained to reorganize multiple binary data.

[0084] It should be noted that after reorganizing multiple binary data to obtain reorganized binary data, the reorganized binary data needs to be digitally signed, wherein the reorganized binary data includes the digital signature of the target node and the digital signature of the user end. In this way, the authenticity of the sent information is guaranteed.

[0085] S405: Broadcasting consensus on the reorganized binary data in the remaining nodes of the blockchain system except the target node to complete the creation of the contract.

[0086] Figure 8 This is a scene diagram of broadcasting consensus in the contract creation method provided in the embodiment of this application. Figure 8 The example in illustrates step S405 in this application. In this example, the blockchain system includes a target node, a first node, a second node, and a third node. After the target node obtains the reorganized binary data, the reorganized binary data is broadcast to the first node, the second node, and the third node. In this way, the creation of the contract is completed. It can be understood that the scenario in which the blockchain system includes a target node, a first node, a second node, and a third node is only used as an example implementation scenario of an embodiment of the present application. In practical applications, there is no limitation on the number and naming of nodes in the blockchain system.

[0087] Specifically, the reorganized binary data for broadcast consensus in this application can be embodied in code form, as shown below:

[0088] contract_name:fact

[0089] bytecode:XX

[0090] version:1.0

[0091] client_signature:XX

[0092] server_signature:mubiaonode_signature

[0093] In the technical solution of the present application, whether it is to create a contract file with large data or a contract file with small data, the contract file can be efficiently created by using the request information carried in the contract creation request in the present application to determine the contract file, and then using the multi-threaded download method to transmit the contract file. In particular, the contract creation method proposed in the present application can be applied in the scenario of batch creation of contracts or in the scenario of blockchain performance testing. For example: a platform connected to the blockchain needs to register accounts in batches, that is, when it needs to create contracts according to account names, it is a scenario where batch creation of contracts is required. At this time, the contract creation method proposed in the present application can be used to create contracts to improve the efficiency of contract creation.

[0094] The above steps have explained the process of creating a contract. Next, we will introduce the process of creating contracts in batches:

[0095] It should be noted that in the present application, in addition to receiving a first contract creation request initiated by a user terminal, a second contract creation request initiated by the same user terminal can also be received, wherein the first contract creation request also includes the first contract file name, and the second contract creation request includes a request IP address, a request port number, a second contract file path and a second contract file name.

[0096] First, verify the request IP address and request port number carried in the second contract creation request to verify the authenticity of the request IP address and request port number. If both the request IP address and request port number are verified, that is, when the request IP address and request port number are valid, determine whether the first contract file path in the first contract creation request is the same as the second contract file path in the second contract creation request, and determine whether the first contract file name in the first contract creation request is different from the second contract file name in the second contract creation request. If any one of the parameters of the request IP address and request port number fails to be verified, that is, when the request IP address and request port number are invalid, it is prohibited to determine whether the first contract file path in the first contract creation request is the same as the second contract file path in the second contract creation request, and it is prohibited to determine whether the first contract file name in the first contract creation request is different from the second contract file name in the second contract creation request.

[0097] If the first contract file path in the first contract creation request is the same as the second contract file path in the second contract creation request, and the first contract file name and the second contract file name are different, then it is determined that when the contract files corresponding to the first contract creation request and the second contract creation request are the same, and the first contract file name and the second contract file name are different, the reorganized binary data is read. If the first contract file path in the first contract creation request is different from the second contract file path in the second contract creation request, or the first contract file name and the second contract file name are the same, reading the reorganized binary data is prohibited, and it can be displayed to the user in the form of a pop-up window, and the pop-up window displays the words "Verification failed, unable to read reorganized binary data". At this time, it means that the contract files corresponding to the first contract creation request and the second contract creation request are different, and it is necessary to re-download the contract files through multiple threads.

[0098] Finally, the read reorganized binary data is assigned to the second contract creation request, and the reorganized binary data corresponding to the second contract creation request is broadcast and identified in other nodes in the blockchain system to complete the contract creation of the second contract creation request.

[0099] It can be understood that, unlike the process of creating a contract for the first time, when the same user terminal initiates a contract creation request for the second time or more, after verifying whether the request information carried in the contract creation request is valid, it is first determined whether the request information carried in this contract creation request is the same as the request information carried in the first contract creation request, and whether the corresponding contract file names are different. If the request information is the same and the contract file names are different, the reorganized binary data after multi-threaded download and reorganization is directly used, which avoids repeated downloads and further improves the effect of contract creation.

[0100] It should also be noted that, in the embodiment of the present application, a cache area can be preset for the target node, and the cache area is used to store the reorganized binary data. In addition, a time interval can be preset for the cache area. The preset time interval is used to constrain the range of the cached reorganized binary data from the time dimension. For example, after the time interval is set, the cache area is specifically used to cache the reorganized binary data within a certain time range, and the reorganized binary data beyond the certain time range is cleared.

[0101] Specifically, if it is determined within the preset time interval that the contract files corresponding to the first contract creation request and the second contract creation request are the same, and the first contract file name and the second contract file name are different, that is, a read operation on the reorganized binary data is received within the time interval, then the reorganized binary data is read from the cache area. If it is determined within the preset time interval that the contract files corresponding to the first contract creation request and the second contract creation request are different, or the first contract file name and the second contract file name are the same, that is, no read operation on the reorganized binary data is received within the time interval, then the reorganized binary data is cleared from the cache area. In this way, memory space is saved.

[0102] For example, if the preset time interval for this cache area is 1 hour, from the time when the reorganized binary data is stored in the cache area to 1 hour, if a user needs to use the reorganized binary data, the reorganized binary data is directly obtained; if the reorganized binary data is not called for more than 1 hour, the reorganized binary data is cleared from the cache area.

[0103] Fig. 9 This is a schematic diagram of batch creation of contracts in the contract creation method provided in the embodiment of the present application. Fig. 9 The example in illustrates the process of batch creation of contracts in this application. Fig. 9 The cache records of different contract files are shown, including different contract files under the same IP address and different contract files under different IP addresses. Different contract files under the same IP address can be obtained by re-downloading and reorganizing the binary data after the time interval is exceeded and the reorganized binary data is not read.

[0104] Based on the contract creation method provided in the above embodiment, the present application also provides a contract creation device. Fig.10 Provide explanation. Fig.10 A schematic diagram of the structure of a contract creation device provided in an embodiment of the present application.

[0105] like Fig.10 The contract creation device shown includes:

[0106] A first creation request receiving unit 1001 is used to receive a first contract creation request initiated by a user terminal, wherein the first contract creation request includes a first contract file path corresponding to the user terminal;

[0107] A contract file determining unit 1002, configured to determine a contract file according to the first contract file path;

[0108] A multi-thread download unit 1003, used for performing multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into a plurality of binary data;

[0109] A binary data reorganization unit 1004, configured to reorganize the plurality of binary data to obtain reorganized binary data;

[0110] The data broadcast consensus unit 1005 is used to broadcast consensus on the reorganized binary data in the remaining nodes of the blockchain system except the target node to complete the creation of the contract.

[0111] Optionally, the device further comprises:

[0112] A second creation request receiving unit, configured to receive a second contract creation request initiated by the user terminal, wherein the second contract creation request includes a second contract file name;

[0113] a binary data reading unit, configured to read the reorganized binary data if the contract files corresponding to the first contract creation request and the second contract creation request are the same, and the first contract file name and the second contract file name are different;

[0114] A contract creation completion unit is used to assign the read reorganized binary data to the second contract creation request to complete the contract creation of the second contract creation request.

[0115] Optionally, the device further comprises:

[0116] a cache area preset unit, used to preset a cache area and preset a time interval for the cache area, the cache area being used to store the reorganized binary data;

[0117] The binary data reading unit is specifically used for:

[0118] If a read operation on the reorganized binary data is received within the time interval, the reorganized binary data is read from the cache area.

[0119] Optionally, the device further comprises:

[0120] a request information determination unit, configured to determine whether the first contract file path in the first contract creation request is the same as the second contract file path in the second contract creation request, where the second contract file path is the request information carried in the second contract creation request;

[0121] A request information determination unit is used to determine that the contract files corresponding to the first contract creation request and the second contract creation request are the same if the first contract file path in the first contract creation request is the same as the second contract file path in the second contract creation request.

[0122] Optionally, the device further comprises:

[0123] A second request information verification unit, used to verify the IP address and the port number;

[0124] A contract file execution unit is used to execute the step of determining the contract file according to the first contract file path if both the IP address and the port number are verified.

[0125] Optionally, the device further comprises:

[0126] A data digital signature unit is used to digitally sign the reorganized binary data, wherein the reorganized binary data includes the digital signature of the target node and the digital signature of the user terminal.

[0127] An embodiment of the present application provides a computer device, which may be a server. Fig.11 : is a schematic diagram of a server structure provided in an embodiment of the present application. The server 900 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 922 (for example, one or more processors) and memory 932, and one or more storage media 930 (for example, one or more mass storage devices) storing application programs 942 or data 944. Among them, the memory 932 and the storage medium 930 can be short-term storage or permanent storage. The program stored in the storage medium 930 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the central processing unit 922 can be configured to communicate with the storage medium 930 to execute a series of instruction operations in the storage medium 930 on the server 900.

[0128] The server 900 may also include one or more power supplies 926, one or more wired or wireless network interfaces 950, one or more input and output interfaces 958, and / or one or more operating systems 941, such as Windows Server 2000. TM , Mac OS X TM , Unix TM ,Linux TM , FreeBSD TM etc.

[0129] The CPU 922 is used to execute the following steps:

[0130] Receive a first contract creation request initiated by a user end, where the first contract creation request includes a first contract file path corresponding to the user end;

[0131] Determine the contract file according to the first contract file path;

[0132] Performing multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into a plurality of binary data;

[0133] Reorganizing the plurality of binary data to obtain reorganized binary data;

[0134] In the remaining nodes of the blockchain system except the target node, the reorganized binary data is broadcasted and consensus is reached to complete the creation of the contract.

[0135] The present application embodiment also provides another computer device, which may be a terminal device. Fig.12 For the sake of convenience, only the parts related to the embodiments of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiments of the present application. Take the terminal device as a mobile phone as an example:

[0136] Fig.12 The block diagram shows a partial structure of a mobile phone provided in an embodiment of the present application. Fig.12 The mobile phone includes: a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a wireless fidelity (WiFi) module 1070, a processor 1080, and a power supply 1090. Those skilled in the art can understand that Fig.12 The mobile phone structure shown in the figure does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0137] Combine the following Fig.12 A detailed introduction to the various components of the mobile phone:

[0138] The RF circuit 1010 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 1080 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit 1010 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (full name: LowNoiseAmplifier, English abbreviation: LNA), a duplexer, etc. In addition, the RF circuit 1010 can also communicate with the network and other devices through wireless communication. The above-mentioned wireless communications may use any communication standard or protocol, including but not limited to Global System of Mobile communications (Global System of Mobile communication, English abbreviation: GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, English abbreviation: CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (Long Term Evolution, English abbreviation: LTE), e-mail, Short Messaging Service (SMS), etc.

[0139] The memory 1020 can be used to store software programs and modules. The processor 1080 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 1020. The memory 1020 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 1020 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0140] The input unit 1030 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone. Specifically, the input unit 1030 may include a touch panel 1031 and other input devices 1032. The touch panel 1031, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 1031 or near the touch panel 1031 using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 1031 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 1080, and can receive and execute commands sent by the processor 1080. In addition, the touch panel 1031 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 1031, the input unit 1030 may further include other input devices 1032. Specifically, the other input devices 1032 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

[0141] The display unit 1040 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 1040 may include a display panel 1041. Optionally, the display panel 1041 may be configured in the form of a liquid crystal display (full name in English: Liquid Crystal Display, English abbreviation: LCD), an organic light-emitting diode (full name in English: Organic Light-Emitting Diode, English abbreviation: OLED), etc. Further, the touch panel 1031 may cover the display panel 1041. When the touch panel 1031 detects a touch operation on or near it, it is transmitted to the processor 1080 to determine the type of touch event. Subsequently, the processor 1080 provides a corresponding visual output on the display panel 1041 according to the type of touch event. Although in Fig.12 In the embodiment, the touch panel 1031 and the display panel 1041 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 1031 and the display panel 1041 can be integrated to realize the input and output functions of the mobile phone.

[0142] The mobile phone may also include at least one sensor 1050, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 1041 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 1041 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

[0143] The audio circuit 1060, the speaker 1061, and the microphone 1062 can provide an audio interface between the user and the mobile phone. The audio circuit 1060 can transmit the received audio data to the speaker 1061 after converting the received audio data into an electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 1062 converts the collected sound signal into an electrical signal, which is received by the audio circuit 1060 and converted into audio data, and then the audio data is output to the processor 1080 for processing, and then sent to another mobile phone through the RF circuit 1010, or the audio data is output to the memory 1020 for further processing.

[0144] WiFi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the WiFi module 1070. It provides users with wireless broadband Internet access. Fig.12 A WiFi module 1070 is shown, but it is understandable that it is not an essential component of the mobile phone and can be omitted as needed without changing the essence of the invention.

[0145] The processor 1080 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. By running or executing software programs and / or modules stored in the memory 1020, and calling data stored in the memory 1020, it executes various functions of the mobile phone and processes data, thereby collecting overall data and information of the mobile phone. Optionally, the processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 1080.

[0146] The mobile phone also includes a power supply 1090 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 1080 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

[0147] Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.

[0148] In the embodiment of the present application, the processor 1080 included in the mobile phone also has the following functions:

[0149] Receive a first contract creation request initiated by a user end, where the first contract creation request includes a first contract file path corresponding to the user end;

[0150] Determine the contract file according to the first contract file path;

[0151] Performing multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into a plurality of binary data;

[0152] Reorganizing the plurality of binary data to obtain reorganized binary data;

[0153] In the remaining nodes of the blockchain system except the target node, the reorganized binary data is broadcasted and consensus is reached to complete the creation of the contract.

[0154] An embodiment of the present application also provides a computer-readable storage medium for storing a computer program. When the computer program is executed on a computer device, the computer device executes any one of the implementation methods of a contract creation method described in the aforementioned embodiments.

[0155] An embodiment of the present application also provides a computer program product including a computer program, which, when executed on a computer device, enables the computer device to execute any one of the implementations of a contract creation method described in the aforementioned embodiments.

[0156] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems and devices described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0157] In the several embodiments provided in the present application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are only schematic. For example, the division of the system is only a logical function division. There may be other division methods in actual implementation, such as multiple systems can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0158] The systems described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0159] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0160] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (full name in English: Read-Only Memory, English abbreviation: ROM), random access memory (full name in English: Random Access Memory, English abbreviation: RAM), disk or optical disk and other media that can store computer programs.

[0161] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A contract creation method, characterized in that: Applied to a target node in a blockchain system, the target node being any node in the blockchain system, the method comprising: Receive a first contract creation request initiated by a user end, where the first contract creation request includes a first contract file path corresponding to the user end; Determine the contract file according to the first contract file path; Performing multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into a plurality of binary data; Reorganizing the plurality of binary data to obtain reorganized binary data; In the remaining nodes of the blockchain system except the target node, the reorganized binary data is broadcasted and consensus is reached to complete the creation of the contract.

2. The method according to claim 1, characterized in that The first contract creation request also includes a first contract file name, and the method further includes: Receiving a second contract creation request initiated by the user end, wherein the second contract creation request includes a second contract file name; If the contract files corresponding to the first contract creation request and the second contract creation request are the same, and the first contract file name and the second contract file name are different, reading the reorganized binary data; The read reorganized binary data is assigned to the second contract creation request to complete the contract creation of the second contract creation request.

3. The method according to claim 2, characterized in that The method further comprises: Preset a cache area and a preset time interval for the cache area, the cache area is used to store the reorganized binary data; The reading of the reorganized binary data comprises: If a read operation on the reorganized binary data is received within the time interval, the reorganized binary data is read from the cache area.

4. The method according to claim 2, characterized in that: Before reading the reorganized binary data, the method further includes: Determine whether the first contract file path in the first contract creation request is the same as the second contract file path in the second contract creation request, where the second contract file path is request information carried in the second contract creation request; If the first contract file path in the first contract creation request is the same as the second contract file path in the second contract creation request, it is determined that the contract files corresponding to the first contract creation request and the second contract creation request are the same.

5. The method according to claim 1, characterized in that The first contract creation request also includes an IP address and a port number corresponding to the user terminal. Before determining the contract file according to the first contract file path, the method also includes: Verifying the IP address and the port number; If both the IP address and the port number are verified, the step of determining the contract file according to the first contract file path is executed.

6. The method according to claim 1, characterized in that The first contract creation request also includes a download type and a digital signature of the user end, and the download type includes direct link download, BT download and magnet download; After the plurality of binary data are reorganized to obtain reorganized binary data, the method further includes: The reorganized binary data is digitally signed, wherein the reorganized binary data includes the digital signature of the target node and the digital signature of the user terminal.

7. A contract creation device, characterized in that: include: A first creation request receiving unit, configured to receive a first contract creation request initiated by a user terminal, wherein the first contract creation request includes a first contract file path corresponding to the user terminal; A contract file determining unit, configured to determine a contract file according to the first contract file path; A multi-thread download unit, used for performing multi-thread downloading on the contract file, wherein the multi-thread downloading process includes reading the contract file into a plurality of binary data; A binary data reorganization unit, used for reorganizing the plurality of binary data to obtain reorganized binary data; The data broadcast consensus unit is used to broadcast consensus on the reorganized binary data in the remaining nodes of the blockchain system except the target node to complete the creation of the contract.

8. A computer device, characterized in that: The device comprises a processor and a memory: The memory is used to store a computer program and transmit the computer program to the processor; The processor is configured to execute the steps of the contract creation method according to any one of claims 1 to 6 according to the instructions in the computer program.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store a computer program, and when the computer program is executed, the steps of the contract creation method described in any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that It comprises a computer program which, when executed, implements the steps of the contract creation method described in any one of claims 1 to 6.

Images