Detailed Description
The subject matter described herein will be discussed with reference to example embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and thereby implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the embodiments of the disclosure. Various examples may omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples may also be combined in other examples.
As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.
The method and apparatus for initiating a blockchain transaction of embodiments of the present specification are now described with reference to the accompanying drawings.
The block chain is a chain data structure formed by connecting and combining data blocks according to a time sequence, and the data blocks are guaranteed to be not falsifiable and not forged in a cryptographic mode. A block chain includes one or more blocks. Each chunk in the chain of chunks is linked to the immediately preceding chunk in the chain of chunks by including a cryptographic hash of the preceding chunk. Each chunk also includes a timestamp, a cryptographic hash of the chunk, and one or more transactions (transactions). Transactions that have been verified by nodes of the blockchain network are hashed and form a Merkle tree. In a Merkle tree, data at leaf nodes is hashed and, for each branch of the Merkle tree, all hash values of the branch are concatenated at the root of the branch. The above process is performed for the Merkle tree up to the root node of the entire Merkle tree. The root node of the Merkle tree stores a hash value representing all the data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, a quick verification can be performed by determining whether the hash value is consistent with the structure of the Merkle tree.
A blockchain is a data structure used to store transactions. A blockchain network is a network of computing nodes used to manage, update and maintain one or more blockchain structures. As described above, the blockchain network may include a public blockchain network, a private blockchain network, or a federated blockchain network.
In a public blockchain network, the consensus process is controlled by nodes of the consensus network. For example, there may be thousands of entity co-processes in a public blockchain network, each entity operating at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network of participating entities. In some examples, most entities (nodes) must sign each chunk in sequence and add the signed chunk to the blockchain of the blockchain network. An example of a public blockchain network may include a particular peer-to-peer payment network. Furthermore, the term "blockchain" does not particularly refer to any particular blockchain.
Public blockchain networks support public transactions. Public transactions are shared among all nodes within a public blockchain network and are stored in a global blockchain. A global blockchain refers to a blockchain that is replicated across all nodes. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within a public blockchain network. Examples of consensus protocols include, but are not limited to: proof of work (POW), proof of rights (POS), and proof of authority (POA). In the embodiments of the present specification, POW is taken as a non-limiting example.
A private blockchain network is provided for a particular entity. The read-write authority of each node in the private blockchain network is strictly controlled. Thus, private blockchain networks, also commonly referred to as licensed networks, limit who is allowed to participate in the network and the level of network participation (e.g., only in certain transaction scenarios). In private blockchain networks, various types of access control mechanisms may be used (e.g., existing participants voting for adding new entities, regulatory body controlled permissions, etc.).
A federation blockchain network is private between participating entities. In a federated blockchain network, the consensus process is controlled by an authorizing node. For example, a federation consisting of several (e.g., 10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, each entity operating at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network of participating entities. In some examples, each participating entity (node) must sign each chunk in sequence and add the chunk to the chain of chunks. In some examples, each tile may be signed by a subset of participating entities (nodes) (e.g., at least 7 entities) and added to the tile chain.
Embodiments of the present specification embodiments are described in detail with reference to a federated blockchain network in the present specification embodiments. However, it is contemplated that embodiments of the present specification can be implemented in any suitable blockchain network.
Blockchains are tamper-resistant shared digital ledgers that record transactions in public or private peer-to-peer networks. Ledgers are distributed to all member nodes in the network and asset transaction histories occurring in the network are permanently recorded in blocks.
The consensus mechanism ensures that all network nodes in the distributed blockchain network perform transactions in the same order and then write the same ledger. The consensus model aims at solving the byzantine problem. In the byzantine problem, components such as servers or network nodes in a distributed blockchain network may fail or intentionally propagate erroneous information to other nodes. Other network nodes have difficulty declaring the component as a failure and excluding it from the blockchain network because they need to agree first on which network node failed first.
Fig. 1 illustrates a schematic diagram of an example of an environment 100 that may be used to perform a method for initiating a blockchain transaction according to embodiments of the present description. In some examples, environment 100 enables entities to participate in blockchain network 102. As shown in FIG. 1, environment 100 includes a network 104, and computing devices/systems 106, 108. In some examples, the network 104 may include a Local Area Network (LAN), a Wide Area Network (WAN), the internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems. In some examples, network 104 may be accessed through wired and/or wireless communication links. In some examples, computing devices/systems 106, 108 communicate with each other over network 104, as well as with blockchain network 102 over network 104, and nodes (or node devices) in blockchain network 102 communicate over network 104. In general, the network 104 represents one or more communication networks. In some cases, the computing devices/systems 106, 108 may be nodes of a cloud computing system (not shown), or each computing device/system 106, 108 may be a separate cloud computing system that includes multiple computers interconnected by the network 104 and functions as a distributed processing system.
In the illustrated example, each of the computing devices/systems 106, 108 may comprise any suitable computing system capable of participating as a node in the blockchain network 102. Examples of computing devices/systems include, but are not limited to, servers, desktop computers, laptops, tablet devices, smartphones, and the like. In some examples, one or more computer-implemented services may be installed on the computing devices/systems 106, 108 for interacting with the blockchain network 102. For example, the computing device/system 106 may have installed thereon a service of a first entity (e.g., user a), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). The computing device/system 108 may have installed thereon a service of a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., other users). In the example of fig. 1, the blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing devices/systems 106, 108 act as nodes for first and second entities participating in the blockchain network 102, respectively.
Fig. 2 shows a schematic diagram of an example of a system architecture 200 that performs a method for initiating a blockchain transaction according to an embodiment of the present specification. An example of system architecture 200 includes participant systems 202, 204, 206 corresponding to participant a, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in blockchain network 212, which is provided as a peer-to-peer network. The blockchain network 212 includes a plurality of nodes 214, wherein at least some of the nodes 214 record information in blockchain 216, and the recorded information is not alterable. Although a single blockchain 216 is schematically shown within blockchain network 212, multiple copies of blockchain 216 may be provided and maintained in blockchain network 212, as described in detail later.
In the illustrated example, each participant system 202, 204, 206 is provided by or as participant a, participant B, and participant C, respectively, and acts as a corresponding node 214 within the blockchain network 212. As used herein, a node generally refers to a single system (e.g., computer, server) that is connected to the blockchain network 212 and enables the respective participants to participate in the blockchain network. In the example shown in fig. 2, a participant corresponds to each node 214. However, one participant may operate multiple nodes 214 within blockchain network 212, and/or multiple participants may share a single node 214. In some examples, the participant systems 202, 204, 206 communicate with the blockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs), or communicate over the blockchain network 212.
The node 214 may have different participation in the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a full copy of blockchain 216, while other nodes 214 store only partial copies of blockchain 216. In the example of fig. 2, the participant systems 202, 204, 206 each store a complete copy 216', 216 "' of the chain of blocks 216.
A block chain (e.g., block chain 216 in fig. 2) consists of a series of blocks, each of which stores data. Examples of data may include transaction data representing transactions between two or more parties. In the present specification embodiments, transactions are used as non-limiting examples, and it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, exchanging things of value (e.g., assets, products, services, and currency, etc.). Transaction data is unalterably stored in the blockchain.
The transaction data is hashed prior to storage in the block. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). After the transaction data is subjected to the hash processing, even if slight change occurs in the transaction data, completely different hash values can be obtained. The hash value is typically generated by hashing the transaction data using a hash function. Examples of hash functions include, but are not limited to, Secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.
Transaction data for a plurality of transactions may be stored in the block after being hashed. For example, two transaction data are hashed to obtain two hash values, and then the two obtained hash values are hashed again to obtain another hash value. This process is repeated until a single hash value is obtained for all transactions to be stored in the block. This hash value is called a Merkle root hash and is stored at the head of the chunk. Any change to a transaction will cause its hash value to change, eventually causing the Merkle root hash value to change.
The blocks are added to the block chain by a consensus protocol. Multiple nodes in a blockchain network participate in a consensus protocol and add blocks to the blockchain after contention. Such nodes are referred to as miner nodes (or accounting nodes). The POW introduced above is used as a non-limiting example.
The miner node performs a consensus process to add the transaction (the corresponding tile) to the chain of tiles. Although multiple miner nodes participate in the consensus process, only one miner node may write a block into the blockchain. That is, the miners nodes compete in the consensus process to add their blocks to the blockchain. In more detail, the miner node periodically collects pending transactions from the transaction pool (e.g., until a predetermined limit, if any, on the number of transactions that may be included in the block is reached). The transaction pool includes transaction messages from participants in the blockchain network. The miner node creates a block and adds the transaction to the block. Before adding a transaction to a block, the miner node checks whether there is a transaction in the block of the blockchain in the transaction to be added. If the transaction has been added to another block, the transaction will be discarded.
The mineworker node generates a chunk header, hashes all transactions in the chunk, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root hash) is obtained for all transactions in the chunk. The Merkle root hash is then added to the chunk header. The miners also determine the hash value of the latest chunk in the blockchain (i.e., the last chunk added to the blockchain). The mineworker node may also add a random value (a noune value) and a timestamp in the block header. During the mining process, the miners' nodes attempt to find hash values that satisfy the required parameters. The mineworker node continually changes the nonce value until a hash value is found that meets the required parameters.
Each miner in the blockchain network attempts to find a hash value that satisfies the required parameters and competes with each other in this manner. Finally, one miner node finds a hash value that satisfies the required parameters and advertises the hash value to all other miner nodes in the blockchain network. Other miners nodes verify the hash value, and if determined to be correct, verify each transaction in the block, accept the block, and append the block to their blockchain copy. In this way, the global state of the blockchain is made consistent across all miner nodes within the blockchain network. The above process is a POW consensus protocol.
In the example provided in fig. 2, party a wants to send a certain amount of funds to party B. Party a generates a transaction message and sends the transaction message to the blockchain network, which is added to the transaction pool. Each mineworker node in the blockchain network creates a block and obtains transactions from the transaction pool and adds the transactions to the block. In this manner, the transaction issued by party a is added to the block of the miner node.
In some blockchain networks, cryptographic techniques are implemented to maintain privacy of transactions. For example, if two nodes want to maintain transaction privacy so that other nodes in the blockchain network cannot learn the transaction details, the nodes may encrypt the transaction data. Examples of encryption methods include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key for both encryption (to generate ciphertext from plaintext) and decryption (to generate plaintext from ciphertext). In symmetric encryption, multiple nodes may use the same key, so each node may encrypt/decrypt transaction data.
Asymmetric encryption refers to encryption using a key pair. Each key pair comprises a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node and may decrypt the encrypted data using a private key of the other node. For example, refer again to fig. 1. Party a may encrypt data using party B's public key and send the encrypted data to party B. Messages encrypted using a node's public key can only be decrypted using the node's private key.
Asymmetric encryption is used to provide a digital signature that enables a party in a transaction to confirm the validity of other parties in the transaction and the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of party a. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, refer again to fig. 1. Party a will send a message to party B. Party a generates a hash value of the message and then encrypts the hash value using its private key to generate a digital signature. Party a attaches the digital signature to the message and sends the message with the digital signature to party B. Party B decrypts the digital signature using party a's public key, thereby decrypting the corresponding hash value. Party B hashes the received message to get another hash value and then compares the two hash values. If the hash values are the same, party B can confirm that the message is indeed from party A and has not been tampered with.
Fig. 3 shows a schematic diagram of an example of a blockchain network to which a method for initiating a blockchain transaction is applicable according to an embodiment of the present description.
As shown in fig. 3, the blockchain network 300 includes lightweight nodes and full-scale nodes, the full-scale nodes include blockchain nodes 301 and 302, and the like, and the lightweight nodes are connected to one or more full-scale nodes. For example, the block link nodes 301a, 301b, and 301c, which are lightweight nodes, are connected to the full-scale node 301, and the block link nodes 302a, 302b, and 302c are connected to the full-scale node 302. Each of the wholesale nodes in the blockchain network 300 are interconnected and may act as accounting nodes to collectively maintain an accounting of all transactions in the blockchain system based on blockchain techniques. The accounting node may perform accounting operations such as transaction verification, transaction consensus, block generation, etc. The quorum node will typically maintain all data of the blockchain locally, including the blockbodies and blockheaders of the various blocks in the blockchain. The lightweight node may only store the block headers of the various blocks in the block chain locally for simple authentication operations (e.g., SPV authentication). The lightweight nodes can be always connected to the same full-scale node, and the full-scale node connected with the lightweight nodes can be replaced based on the connection rule so as to reduce the trust risk.
Transactions initiated by various blockchain nodes may be broadcast into the blockchain network for consensus processing (e.g., consensus processing may be performed based on a PoW mechanism). The transaction initiated by the full-scale node may be broadcast to each of the other full-scale nodes, and each full-scale node may broadcast to the lightweight nodes to which it is connected after receiving the transaction. The transaction initiated by the lightweight node may be sent to the full-scale node to which the lightweight node is connected for broadcast by the full-scale node to other full-scale nodes or lightweight nodes.
The participants referred to in the embodiments described below may be any of the lightweight nodes in fig. 3.
Fig. 4 is a flow diagram of a method for initiating a blockchain transaction according to one embodiment of the present description.
As shown in FIG. 4, at block 420, first transaction data is obtained, the first transaction data including transaction information for the participant. Transaction information may be entered by the parties and may include transaction initiator address, transaction object address, transaction amount, etc.
At block 440, a bridging device for a corresponding smart contract for executing a transaction to which the first transaction data corresponds is determined based on the first transaction data. The bridge device is obtained from a bridge device provider server. The bridge device provider server may be, for example, a provider server of a smart contract. The bridging device is generated based on contract rules of the smart contract so that transaction initiation processing can be performed.
The bridging device provider server may be preconfigured with one or more bridging devices. The participant may apply authorization to the bridge device provider server to use the bridge device when applying for joining the blockchain system. After obtaining authorization, the participant may obtain the requested bridging device from the bridging device provider server. In addition, the participant may send information of the intelligent contract that may be invoked to the bridge device provider server to apply for configuration of the bridge device, and the bridge device provider server may configure the bridge device for the participant after receiving the application of the participant. In one example, there may be only one bridging device acquired by the participant. Upon acquiring the first transaction data, the bridging device may be determined to be a bridging device for performing transaction initiation processing.
A smart contract for executing a respective transaction, and thus a respective bridging device, may be determined based on the transaction information in the first transaction data. For example, a transaction type (e.g., a transfer-type transaction or an account-type transaction, etc.) for a corresponding transaction may be determined from the transaction information, and then a smart contract may be determined based on the transaction type. As another example, the smart contract may be determined based on information such as the transaction object address, the transaction amount, and the like.
In another example, a smart contract for performing a respective transaction may be specified by a participant. At this time, the first transaction data may further include smart contract information, which may indicate a smart contract for performing a corresponding transaction. In this example, a bridging device for the intelligent contract may be determined based on the intelligent contract information. The intelligent contract information may be, for example, an intelligent contract identification, and an index of the intelligent contract identification and corresponding bridging device may be stored at the participant business server so that the bridging device may be determined based on the intelligent contract identification. In another example, a participant may specify a contract name and a contract method in the transaction information for performing a corresponding transaction. An intelligent contract corresponding to the same contract name may include multiple contract methods for invocation when performing a transaction. An intelligent contract for performing a corresponding transaction may be determined based on the contract name and the contract method, and a corresponding bridging device may be determined based on the determined intelligent contract.
After the bridge device is determined, the first transaction data is provided to the bridge device for execution of a transaction initiation process by the bridge device at block 460. The bridging device may be configured for one or more intelligent contracts. Since the bridging device is generated based on the contract generation logic (or contract generation rules) of the respective intelligent contract, parameters matching the respective intelligent contract can be generated based on the first transaction data with the bridging device for initiating the blockchain transaction. After initiating the blockchain transaction, the full-scale nodes in the blockchain system may provide the parameters generated by the bridging device to the corresponding intelligent contract after verifying the blockchain transaction to execute the corresponding transaction.
Fig. 5 is a flow diagram of one example of a transaction initiation process in a method for initiating a blockchain transaction according to one embodiment of the present description.
As shown in FIG. 5, at block 502, intelligent contract parameters are generated based on parameter generation rules corresponding to the intelligent contract and the first transaction data. Intelligent contract parameters are parameters that need to be used when invoking an intelligent contract. Because the logic of the intelligent contract is different from the business logic of the participant, the first transaction data provided by the participant needs to be processed to be input into the intelligent contract. Thus, the first transaction data may be converted to smart contract parameters that match the smart contract based on the parameter generation rules of the smart contract.
After generating the intelligent contract parameters, at block 504, the intelligent contract parameters are cryptographically processed using the blockchain private key of the participant. The encryption process is a process of generating a digital signature by signing with the private key of the block chain of the participant.
After being encrypted, the encrypted smart contract parameters are sent to the full blockchain node to initiate a blockchain transaction at block 506. A participant may connect one or more quorum nodes. When a participant connects with a plurality of full-scale nodes, the bridging device may select one or more of the connected full-scale nodes after the encryption process and send the encrypted intelligent contract parameters to the selected full-scale nodes. In one example, a participant may specify a full number of blockchain nodes for a transaction that is desired to be initiated. The full volume blockchain node can utilize the public key of the participant to decrypt after receiving the encrypted intelligent contract parameters. Alternatively, the unencrypted smart contract parameters and the encrypted smart contract parameters may be sent to the full-scale blockchain node for verification by the full-scale blockchain node using the public key of the participant. When the verification passes, a blockchain transaction may be initiated based on the smart contract parameters.
A participant may participate in multiple blockchain systems. In this example, the first transaction data may have a blockchain system identification for indicating the blockchain system designated to process the transaction. In this example, a full number of blockchain nodes may be determined based on the blockchain system identification. After determining the full-scale blockchain link points, the cryptographically processed intelligent contract parameters may be sent to the determined full-scale blockchain nodes.
Fig. 6 is a flow diagram of another example of a transaction initiation process in a method for initiating a blockchain transaction according to one embodiment of the present description. In this example, the business logic of the participant can be generated based on a first language type and the smart contract can be generated based on a second language type. Accordingly, the first transaction data may be data based on a first language type. Language type refers to a computer language type. For example, the business logic of a participant may be written based on Java, and the intelligent contract may be written based on an EVM (virtual machine) language, such as the Solidity language, the bambooo language, and the like. Different intelligent contracts may be generated based on different EVM languages.
As shown in FIG. 6, at block 602, a language-type conversion rule between a first language type and a second language type is determined based on first transaction data. The bridging device may correspond to intelligent contracts of multiple language types, and at this time, when the first transaction data includes the intelligent contract information, the bridging device may determine a corresponding intelligent contract based on the intelligent contract information, and then determine a second language type corresponding to the intelligent contract. The corresponding second language type may also be determined after the smart contract is determined based on the transaction information in the first transaction data. After determining the second language type, a language type conversion rule between the first language type and the second language type may be determined based on the determined second language type. The bridging device may also correspond to only one language type of smart contract, in which case the language type conversion rule determination process may not be performed.
Upon determining the language-type conversion rules, the first transaction data is converted to second transaction data based on the second language type based on the language-type conversion rules between the first language type and the second language type at block 604. The transaction data conversion process may include data expression conversion or description language conversion. For example, for conversion between Java-type solids, int (integer type) type data in Java may be converted to uint32 or uint256 (integer type) type data in the solids language.
After the second transaction data is obtained, at block 606, third transaction data is assembled and generated as smart contract parameters based on the second transaction data and parameter assembly rules. When the intelligent contract is called, the calling parameters need to be input according to rules, for example, the parameters need to be input according to a specified sequence or a data structure. The parameter assembly rule may include a data structure of the intelligent contract invocation parameter or a parameter input order, etc.
After the third transaction data is assembled and generated, at block 608, the third transaction data may be encoded based on parameter encoding rules of an execution device of the smart contract to obtain smart contract parameters. The execution means of the smart contract may be, for example, virtual machines, different virtual machines corresponding to different parameter encoding rules. The parameter encoding rule may be a parameter encoding rule used by any virtual machine. As an example, the intelligent contract information (function name and parameter name corresponding to the function) may be first encoded by using the function selector to obtain the function identifier, for example, the function identifier may be determined using bytes4(keccak256("baz 32, boul)"). The parameters input to call the function are then encoded. For example, after the parameter is converted into a 16-ary expression, it is complemented to the number of bytes regulated by the parameter. For example, the function may be baz (uint32 x, pool y), and the call to the function may be baz (69, true). The function identifier obtained by the function selector is 0xcdcd77c 0. For parameter 69, after it is converted to 16-ary expression 0x45, it is padded to the specified 32 bytes (0 can be padded between "0 x" and "45").
After encoding the parameters, the intelligent contract parameters are encrypted using the blockchain private key of the participant at block 610. After the encryption process, the encrypted parameters may be encoded into a byte stream by an encoding method required by a message transmission process, such as RLP encoding.
The cryptographically processed smart contract parameters are then sent to the full blockchain node to initiate a blockchain transaction at block 612.
The individual processes in fig. 6 are not all necessary, and some of them may be omitted as practically necessary.
Fig. 7 is a flow diagram of a bridge device update process in a method for initiating a blockchain transaction according to another embodiment of the present description.
As shown in fig. 7, at block 720, update information for the bridging device is listened to. And at block 740, a determination is made as to whether updated information for the bridge device exists at the bridge device provider server.
When there is update information for the bridge device at the bridge device provider server, the bridge device provider server obtains the update information at block 460. When the intelligent contract has logic change or version change, the bridge device provider can correspondingly update the bridge device. A corresponding update operation may be configured for the bridge device provider to publish update information on the bridge device provider server for retrieval by the participants.
Upon acquiring the update information, the bridge device is updated based on the acquired update information at block 780. By the embodiment, the change and maintenance operations of the bridge device can be acquired from the bridge device provider server in an information updating mode, so that the maintenance cost of the bridge device is saved for the participants.
Fig. 8 is a block diagram of an apparatus for initiating a blockchain transaction according to one embodiment of the present description. As shown in fig. 8, the blockchain transaction initiating device 800 includes a transaction data obtaining unit 810, a bridge device determining unit 820, a transaction initiating processing executing unit 830, an update information obtaining unit 840, and a bridge device updating unit 850.
The transaction data obtaining unit 810 obtains first transaction data including transaction information of the participating parties and smart contract information indicating a smart contract for executing a transaction corresponding to the transaction information. After acquiring the first transaction data, the bridge device determination unit 820 determines a bridge device for a corresponding smart contract for executing a transaction corresponding to the first transaction data based on the smart contract information, the bridge device being acquired from the bridge device provider server. In one example, the first transaction data may also include smart contract information indicating a smart contract for performing a transaction to which the transaction information corresponds. In this example, the bridge device determination unit 820 determines a bridge device for the intelligent contract based on the intelligent contract information.
After determining the bridge device, the transaction initiation process execution unit 830 provides the first transaction data to the bridge device for performing a transaction initiation process by the bridge device.
The update information acquisition unit 840 acquires update information for the bridge device from the bridge device provider server when the update information exists at the bridge device provider server. After acquiring the update information, the bridge device update unit 850 updates the bridge device based on the acquired update information.
Each unit shown in fig. 8 is not necessarily a constituent element, and in other examples, some units may not be included, for example, the update information acquisition unit and the bridge device update unit may not be included.
Fig. 9 is a block diagram of a bridging device for use with the device for initiating blockchain transactions shown in fig. 8. As shown in fig. 9, the bridging apparatus 900 includes an intelligent contract parameter generation unit 910, an intelligent contract parameter encryption unit 920, and an intelligent contract parameter transmission unit 930.
The intelligent contract parameter generating unit 910 generates an intelligent contract parameter based on a parameter generating rule corresponding to the intelligent contract and the first transaction data. The intelligent contract parameter encryption unit 920 encrypts the intelligent contract parameters using the blockchain private key of the participant. Then, the intelligent contract parameter transmission unit 930 transmits the encrypted intelligent contract parameters to the full-scale blockchain node to initiate a blockchain transaction.
Fig. 10 is a block diagram showing the structure of an example of an intelligent contract parameter generation unit in the bridge device shown in fig. 9. The first transaction data is data based on a first language type and the smart contract is generated based on a second language type. As shown in fig. 10, the intelligent contract parameter generating unit 910 includes a transaction data converting module 911, a transaction data assembling module 912, and a transaction data encoding module 913.
The transaction data conversion module 911 converts the first transaction data into second transaction data based on the second language type based on a language type conversion rule between the first language type and the second language type. The transaction data assembly module 912 generates third transaction data as smart contract parameters based on the second transaction data and the parameter assembly rules.
The transaction data encoding module 913 encodes the third transaction data based on the parameter encoding rule of the executing apparatus of the intelligent contract to obtain the intelligent contract parameter. In another example, the intelligent contract parameter generation unit may not include the transaction data encoding unit.
In another example, the contract parameter generation unit may further include a language type conversion rule determination module (not shown in the drawings), which determines a language type conversion rule between the first language type and the second language type based on the intelligent contract information before converting the first transaction data into the second transaction data based on the second language type based on a language type conversion rule between the first language type and the second language type.
Embodiments of methods and apparatus for initiating blockchain transactions according to embodiments of the present specification are described above with reference to fig. 1 through 10. The details mentioned in the above description of the method embodiments apply equally to the embodiments of the device of the embodiments of the present description.
The means for initiating blockchain transactions of the embodiments of the present description may be implemented in hardware, or may be implemented in software, or a combination of hardware and software. The various embodiments in this specification are described in a progressive manner, with like reference to each other.
The means for initiating blockchain transactions of the embodiments of the present description may be implemented in hardware, or may be implemented in software, or a combination of hardware and software. The software implementation is taken as an example, and is formed by reading corresponding computer program instructions in the storage into the memory for operation through the processor of the device where the software implementation is located as a logical means. In embodiments of the present description, the means for initiating a blockchain transaction may be implemented, for example, using a computing device.
Fig. 11 is a block diagram of a computing device for implementing a method for initiating a blockchain transaction according to one embodiment of the present description. As shown in fig. 11, computing device 1100 includes a processor 1110, a memory 1120, a memory 1130, a communication interface 1140, and an internal bus 1150, and processor 1110, memory (e.g., non-volatile memory) 1120, memory 1130, and communication interface 1140 are connected together via bus 1150. According to one embodiment, the computing device 1100 may include at least one processor 1110, the at least one processor 1110 executing at least one computer-readable instruction (i.e., an element described above as being implemented in software) stored or encoded in a computer-readable storage medium (i.e., memory 1120).
In one embodiment, computer-executable instructions are stored in the memory 1120 that, when executed, cause the at least one processor 1110 to: acquiring first transaction data, wherein the first transaction data comprises transaction information of a participant; determining, based on first transaction data, a bridging device for a corresponding smart contract for executing a transaction to which the first transaction data corresponds, the bridging device being obtained from a bridging device provider server; and providing the first transaction data to the bridge device for execution of the transaction initiation process by the bridge device.
It should be appreciated that the computer-executable instructions stored in the memory 1120, when executed, cause the at least one processor 1110 to perform the various operations and functions described above in connection with fig. 1-10 in the various embodiments of the present specification.
According to one embodiment, a program product, such as a non-transitory machine-readable medium, is provided. A non-transitory machine-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a machine, cause the machine to perform various operations and functions described above in connection with fig. 1-10 in various ones of the embodiments of the present specification.
Specifically, a system or apparatus may be provided which is provided with a readable storage medium on which software program code implementing the functions of any of the above embodiments is stored, and causes a computer or processor of the system or apparatus to read out and execute instructions stored in the readable storage medium.
In this case, the program code itself read from the readable medium can realize the functions of any of the above-described embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code form part of the present invention.
Examples of the readable storage medium include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or from the cloud via a communications network.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Not all steps and elements in the above flows and system structure diagrams are necessary, and some steps or elements may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or some units may be implemented by some components in a plurality of independent devices.
The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.
Although the embodiments of the present disclosure have been described in detail with reference to the accompanying drawings, the embodiments of the present disclosure are not limited to the specific details of the embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present disclosure within the technical concept of the embodiments of the present disclosure, and all of them fall within the scope of the embodiments of the present disclosure.
The previous description of the contents of the embodiments of the present specification is provided to enable any person skilled in the art to make or use the contents of the embodiments of the present specification. Various modifications to the disclosure of the embodiments herein will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the embodiments herein. Thus, the present specification embodiments are not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.