The present disclosure generally relates to blockchain systems, and more specifically, to systems and methods for maintaining private data with consortium blockchain.
In related art implementations, such as that disclosed in US 2019/0251566A1, there are systems and methods to facilitate private transactions on a consortium blockchain. Private data in transactions are recorded in a specific client node, and the hash values for the data are recorded in the blockchain network. A client node has communication channels that are each private to another client node. Therefore private transactions between two client nodes can be issued using the channel without exposing the transactions to other client nodes. By referring to the hashes recorded in the blockchain network, a client node can verify data in the private transaction that are passed from another organization and ensure that the data have not been altered since they are stored.
However, the related art implementations do not disclose a method to handle so-called the SPoT (single point of trust) issue for private data.
Example implementations described herein are directed to systems and methods with a consortium blockchain. Consortium blockchain is known as permissioned blockchain or enterprise blockchain, and is configured to limit the access to only a set of known participants, is not anonymous, and is not open to the public. In a consortium blockchain, participants are also grouped into organizations; every participant must belong to one and only organization. Blockchain is facilitated through multiple computer nodes, each of which belongs to a particular organization, are connected, and communicate with one another. Data shared and distributed in the system is called a ledger, and each computer node has a ledger locally. The blockchain maintains every computer node which is participating in the blockchain so that it has the same contents for the ledger in the system (i.e., every blockchain node has a replica of the ledger, which eventually has the same contents).
Data models used in the blockchain include UTXO (unspent transaction output) and key-value pairs. The ledger typically contains only transactions, wherein each transaction contains values only for the relevant data (which are identified by addresses in UTXO, keys in key-value). While it is possible to get the latest values for all the data by traversing all the history, or transactions in the ledger, the blockchain nodes can also optionally have the snapshot of the latest data for efficiency and update it for every new transaction.
Various consensus algorithms are used to facilitate maintaining the same ledger in the computer nodes in blockchain systems. One example is the three-phase consensus in Hyperledger Fabric, which involves endorsement, ordering and validation. In the endorsement phase, a client requests a transaction to blockchain nodes by sending a transaction proposal. A blockchain node executes a program which is called a smart contract according to the transaction proposal, and sends back the result with the signature of the node, which is called an endorsement, to the client. In the ordering phase, a client sends a transaction, which involves the proposal and the endorsement(s), to the special blockchain node(s) that are specialized for determining the order of the transactions. The node(s) providing the ordering service determine the order of the transactions received, and create blocks by aggregating one or multiple transactions. In the validation phase, the ordering service delivers the blocks to the blockchain nodes. The blockchain nodes inspect each transaction in every block and check if the endorsements are valid and the result does not conflict with other “previous” transactions. When a transaction passes all the checks, it is considered valid, and if the blockchain nodes have snapshot data, it updates the snapshot according to the result of the transaction. Otherwise, it is considered invalid and has no effect. The following explanation is based on this three-phase consensus, but the example implementations are not limited to the particular algorithm.
Aspects of the present disclosure can include a method for a blockchain system configured to facilitate a smart contract transaction, the blockchain system having a plurality of nodes, the method involving: responsive to receiving, at a first node from the plurality of nodes, a proposal for the smart contract transaction from a second node of the plurality of nodes, identifying, at the first node, an organization in the blockchain system associated with the second node; determining, at the first node, whether the organization is capable of executing the smart contract transaction indicated by the proposal; for the determining indicating that the organization does not have capability of executing the smart contract transaction indicated by the proposal, returning an error to the second node; and for the determining indicating that the organization does have capability of executing the smart contract transaction indicated by the proposal, executing the smart contract transaction.
Aspects of the present disclosure can include a non-transitory computer readable medium, storing instructions for a blockchain system configured to facilitate a smart contract transaction, the blockchain system involving a plurality of nodes, the instructions involving: responsive to receiving, at a first node from the plurality of nodes, a proposal for the smart contract transaction from a second node of the plurality of nodes, identifying, at the first node, an organization in the blockchain system associated with the second node; determining, at the first node, whether the organization is capable of executing the smart contract transaction indicated by the proposal; for the determining indicating that the organization does not have capability of executing the smart contract transaction indicated by the proposal, returning an error to the second node; and for the determining indicating that the organization does have capability of executing the smart contract transaction indicated by the proposal, executing the smart contract transaction.
Aspects of the present disclosure can include a blockchain system configured to facilitate a smart contract transaction, the blockchain system having a plurality of nodes, the blockchain system involving: responsive to receiving, at a first node from the plurality of nodes, a proposal for the smart contract transaction from a second node of the plurality of nodes, means for identifying, at the first node, an organization in the blockchain system associated with the second node; means for determining, at the first node, whether the organization is capable of executing the smart contract transaction indicated by the proposal; for the determining indicating that the organization does not have capability of executing the smart contract transaction indicated by the proposal, means for returning an error to the second node; and for the determining indicating that the organization does have capability of executing the smart contract transaction indicated by the proposal, means for executing the smart contract transaction.
Aspects of the present disclosure can include a blockchain system configured to facilitate a smart contract transaction, the blockchain system involving a plurality of nodes; wherein a first node of the plurality of nodes involve a processor, configured to, responsive to receiving a proposal for the smart contract transaction from a second node of the plurality of nodes: identify an organization in the blockchain system associated with the second node; determine whether the organization is capable of executing the smart contract transaction indicated by the proposal; for the determination indicating that the organization does not have capability of executing the smart contract transaction indicated by the proposal, return an error to the second node; and for the determination indicating that the organization does have capability of executing the smart contract transaction indicated by the proposal, executing the smart contract transaction.
The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.
The blockchain technology provides immutable, distributed and trustful data store among multiple stakeholders. Although blockchain was started to realize cryptoassets, it has also been employed also by enterprise systems, especially ones in which multiple companies or organizations are involved. Most blockchain platforms for enterprise use employ simpler and conventional algorithms to reach a consensus among the participants on the data stored in the blockchain rather than novel but time-consuming algorithms such as PoW (Proof of Work), PoS (Proof of Stake), and PoET (Proof of Elapsed Time). The consensus algorithms for enterprise blockchain includes variations of CFT (Crash fault tolerance) and BFT (Byzantine fault tolerance), such as Paxos, RAFT and PBFT. They typically assume that when innocent participants execute a transaction, they should reach the same result. Therefore, for the transaction and result to be considered valid, the certain number of the participants should verify that they reach the identical result.
Blockchain can work well for the transactions when all the data involved are shared among the participants. However, while the blockchain technology accomplishes immutability and authenticity of the stored data by sharing the data publicly with the participants of blockchain network, enterprise use cases often require data that an organization cannot expose to other organizations. To fulfill such requirements, private data features are introduced in many enterprise blockchain platforms. In related art implementations, private data are stored in a certain part of the participants who are allowed to see the data, and the hash values of the data are stored in the blockchain to be made available to all the participants. Still such features have challenges to be solved when they are to be used in transactions which involve multiple private data.
To illustrate one of the challenges, suppose there are three organizations: A, B, and C. They maintain their own balances in bilateral private data. For example, B maintains two balances: one to share with A (“balance BA”) and the other to share with C (“balance BC”). When A and B execute a trade, the balances are mutually checked and the transaction for the trade will be verified by the two organizations: A and B. Then B may want to transfer some money from the balance BA to the balance BC to start a transaction that pays to C. Because B is the only organization which can see the two balances, the balances after the transaction can only be verified by B, which allows B to falsify the balances. No other organization can verify the correctness of the transaction because they only know the hash values for the balances and are not able to calculate how much is deducted from the first balance and is deposited to the second balance from their hash values. The root cause of this issue is that B is the single point of trust for the transaction.
Example implementations described herein are directed to providing systems based on enterprise blockchain with an increased number of points of trust for transactions in which private data are involved. One implementation is composed of: one or more organizations, one or more read-only organizations, one or more blockchain nodes in each organization and each read-only organization, network connecting the blockchain nodes which facilitate peer-to-peer communication among the nodes, and ordering service. The read-only organizations are configured to be eligible to access private data in other organizations so that they can verify transactions that involve multiple private data, especially when the number of organizations that can access all the private data is only one.
Each blockchain node in an organization, including the read-only organization, has endorsing logic that executes a smart contract according to a transaction proposal and returns the result with its endorsement, and committing logic that validates transactions with validating logic and persists the transaction in its local ledger. The endorsing logic performs a check before it goes to the execution of the smart contract if the proposal is sent from a read-only organization based on the identity in the proposal. If so, the endorsing logic rejects the proposal to ensure that no read-only organization proposes or makes transactions. The validating logic also has a check for the creator of the transaction even if the read-only organization manages to submit a transaction. It marks the transaction with “invalid” if the creator belongs to any read-only organization to ensure that the result of the transaction cannot be applied to the blockchain. By enforcing checks to prevent read-only organizations from performing transactions to modify the ledger, they can be more trustable and more appropriate to be a mediator or an auditor. Such implementations thereby allow other organizations allow the read-only organizations to access their private data.
A blockchain node 110 is a computer that has computation capability, memory, persistent storage and communication capability via network. It can be a physical computer server, a virtual machine, a container, or any other form that has the similar capabilities to a computer to facilitate the desired implementation. As described herein, it persists ledger, state database, and private data, executes a smart contract (a program to which the participants agreed) according to a received transaction proposal, and validates and updates transactions after they get ordered by the ordering service 130.
The ordering service 130 is a service provided by one or multiple computers, which can be physical computers, virtual machines, containers, any other similar machines, in singular or in combination in accordance with the desired implementation. The ordering service 130 is responsible for deciding the full order of the transactions issued in the system, for creating the blocks each of which include the one or multiple transactions in the order decided, and for delivering the blocks to all the blockchain nodes 110. Blockchain client 120 and CA 150 are programs executed in a computer, which can be a physical computer, a virtual machine, a container or any other similar machine in accordance with the desired implementation. It may be executed in the same computer as any of the blockchain nodes 110, or may be executed in a separate computer. A blockchain client 120 initiates transactions by sending the transaction proposal to one or more of the blockchain nodes 110, and sending the responses as transactions to the ordering service 130, which in turn delivers the blocks that contain the transactions to the blockchain nodes 110. A read-only organization 101 does not have blockchain clients because it is not allowed to invoke transactions.
A CA 150 is a computer program which issues verifiable identities and can be executed in a physical computer, virtual machine, container, and so on, in accordance with the desired implementation. The CA 150 can use a cryptographic method such as issuing a digital certificate signed with the CA's private key with a cryptographic algorithm such as RSA and ECDSA. A CA 150 also has its own identity such as a digital certificate signed by itself or by another superior CA, the public key of which corresponds to the private key used for signing the certificates it issued. The blockchain nodes 110, the blockchain clients 120, the ordering service 130, and optionally CAs 150 are connected by the network 140 and can communicate with one another in a peer-to-peer fashion. The network 140 can be a local area network (LAN), wide area network (WAN), or virtual private network (VPN), and can be wired or wireless depending on the desired implementation. The communication between them can be encrypted and/or secured, for example, by using Transport Layer Security (TLS).
The data shared in the system is stored in the ledger 250. The data is stored as a chain with the blocks 260. The state database 270 is a snapshot of the latest version of data in the ledger 250. Because each transaction in the block 260 typically only has information for the values that are involved in the transaction, the blockchain node 110 maintains and updates the snapshot of the latest state after every valid transaction is committed to obtain the latest state. The private data store 280 holds private data that is not to be shared outside of specified organizations. The private data is stored in the private data store 280 and generally has the same data model as the non-private data (e.g., public data stored in the ledger 250 and the state database 270). A transaction contains values for the non-private data, and hashes of the values for the private data. There can be multiple private data stores 280, so that the blockchain node 110 can have different data stores, each of which involving different set of organizations that are granted access.
The temporary private data store 290 holds private data that are not committed yet. Private data are written to the private data store 280 once the transaction involving the data is committed. In the endorsement phase, when the endorsement logic 210 invokes the smart contract 240 upon receiving a transaction proposal 370 involving private data from the blockchain client 120, the smart contract 240 returns the result including values for the private data as well as for the non-private data. Due to their nature, the values of the private data cannot be shared with all the participants, and the endorsement logic 210 does not return the values for the private data but the hashes of the values. Because there is a need to hold the new values for the private data until it is committed in the validation phase, the endorsement logic 210 stores private data in the temporary private data store 290. Once the transaction is validated in the validation phase, the committing logic 220 updates the state database 270 for the non-private data, and updates the private data store 280 for the private data.
A normal transaction 310 has the proposer identity 311, the function and parameters 312, the result 313, and one or more endorsements 315. The proposer identity 311 contains information to identify the entity which requested the transaction, or that sent the transaction proposal 370. The proposer identity 311 can contain a certificate issued for the blockchain client 120 and a digital signature for the contents of the transaction.
The function and parameters 312 represent the name or identifier of the function and the parameters that are used to execute a smart contract 240. The result 313 contains the result obtained by executing the smart contract 240 with the function and parameters 312. The result 313 can contain identifiers such as addresses and keys of the data in the ledger 250 with their respective new values. The result 313 can have the old values or the values read during execution of the smart contract to detect conflicts with other transactions by comparing the values read with the latest values in the validation phase to prevent read-after-write (RAW) data hazards. The result 313 can have the versions of the old values or the values read instead of their actual values. When private data is used, the result 313 may contain values for non-private data as well as hashes for values for private data. The endorsements 315 contain verifiable evidence that blockchain nodes 110 have agreed to obtain the result 313 by executing the smart contract 240 with the function and parameters 312. For example, an endorsement can include a digital signature for the result 313 using the private key of a blockchain node 110 and an identity of the entity, specifically the blockchain node 110 that created the signature.
A config transaction 320 contains the organization information 330, private data information 340, endorsement policy 350, and one or multiple endorsements 315. The organization information 330 contains information for an organization which participates in the blockchain system, i.e. in the consortium. The private data information 340 contains information for private data if any. The endorsement policy 350 defines a condition for endorsements for a transaction to comply with. Only when the endorsements in a transaction satisfy the condition, the transaction is considered valid. One example for the condition is a minimum number of different organizations which gave endorsements. The other example is an AND-OR tree of organizations which gave endorsements such as “Organization A AND (Organization B OR Organization C)”. It may define different conditions for normal transactions 310 and for config transactions 320. A config transaction 320 may have all the information described above or may have the difference of the information for which the transaction is going to apply, depending on the desired implementation.
A transaction proposal 370 is sent from the blockchain client 120 to the blockchain nodes 110 in order to request execution of the smart contract 240 during the endorsement phase. It contains the proposer identity 311 and the function and parameters 312 for the smart contract to be invoked in the transaction. As described in
At step 406, when the proposal 370 is successful (No), the blockchain client 120 compares the result with the previous results it obtained from other blockchain nodes 110 for the same proposal 370 at step 407. If they are identical (Yes), then the blockchain client 120 keeps the result and the new endorsement, and goes back to the step 402. Otherwise (No), as the blockchain nodes 110 cannot reach the consensus on the result of the transaction proposal 370, the blockchain client 120 discards all the endorsements it obtained, and starts again from the step 402. The steps 401-408 form the endorsement phase in the three-phase consensus of the blockchain system. Once the endorsement(s) obtained are sufficient, the blockchain client 120 switches to the next step (Step 402:Yes).
At 410, the blockchain client 120 composes a normal transaction 310 with the proposer identity 311, the function and parameters 312, the result 313 and the accumulated endorsement(s) 315, and it sends the transaction to the ordering service 130. At step 411, if it encounters an error (Yes), it returns the error to the user (Step 415). Otherwise (No), after it receives a transaction, the ordering service 130 determines the order of transactions it received from the organizations, and creates blocks, each involving one or more transactions, and delivers them to the blockchain nodes 110. This forms the ordering phase in the consensus. The blockchain client 120 waits for the result of the validation phase from any of the blockchain nodes 110 at step 412. If the result indicates an error or that the transaction is considered invalid (Yes), the blockchain client 120 returns the error to the user at step 415. Otherwise (No i.e. the result is successful) the transaction is considered valid, the blockchain client 120 returns the success to the user at step 414. Optionally, the blockchain client 120 returns the result from the smart contract 240 for the user to know the new values depending on the desired implementation.
The checks include if the certificate is issued by the CA 150 and if the signature for the transaction proposal 370 is correct. If the checks fail (No), the endorsing logic 210 returns the error to the blockchain client 120 (Step 511). Otherwise (Yes), the endorsing logic 210 executes the smart contract 240 according to the function and parameters in the transaction proposal 370 (step 505).
At Step 506, if the smart contract fails (Yes), the endorsing logic 210 returns the error to the blockchain client 120 (Step 511). If the smart contract returns the result successfully (No), the endorsing logic 210 checks if the result contains any private data (Step 507). If it contains private data (Yes), the endorsing logic 210 stores the private data into the temporary private data store 290 (Step 508). The endorsing logic 210 removes the private data from the result, and adds the hash values for the private data instead in case the smart contract did not calculate them. Finally, the endorsing logic 210 returns the result as well as the endorsement for the result to the blockchain client 120 (Step 510).
If the private data is involved in the transaction, and the organization is permitted to read the private data according to the permissions 342 for the private data (Step 607: Yes)), it gets the actual values for the private data, either from the temporary private data store 290 or from the other blockchain node 110 that has the private data (Step 608). Methods to achieve the latter implementation include peer-to-peer communication protocols such as gossip.
After the committing logic 220 obtains the values, it updates the private data store 280 as per them. If the validation result is invalid (Step 605:No), the committing logic 220 skips updating the state database 270 and the private data store 280. Finally, the committing logic 220 emits the result of the commitment for the transaction, including the validity of the transaction, to the blockchain clients 120 if there are any listening to (Step 609). Step 609 may be executed for each transaction, for each block, aggregating the results for the transactions, or for multiple blocks, in order to optimize the communication. It goes back to Step 602 and repeats until all the transactions are consumed. The committing logic is distributed and executed in each blockchain node 110. Because they have the same blocks in the ledger and the same logic, it is ensured that the committing logics 220 in all the blockchain nodes 110 obtain the same result.
With the first example implementation described above, the blockchain system can have two types of the organizations: organizations with the full permission and read-only organizations. The endorsing logic and the validation logic ensure that any transaction proposed by any entity in read-only organizations are rejected or marked invalid. On the other hand, the blockchain nodes in read-only organizations are able to endorse transactions. When these read-only organizations are allowed to read the private data, they add more chances to get multiple endorsements for transactions including the private data, and therefore it alleviates the SPoT issue regarding the private data. The limitation that the read-only organizations cannot perform transactions encourages the other organizations to trust them as neutral third-parties, and would increase chances to expose their private data to get their endorsements.
The example may be extended for the system to always allow the read-only organization to read any private data. This is equivalent to implicitly adding “read by the read-only organizations” to the permissions for every private data.
In a second example implementation,
In this second example implementation, as a trusted third-party organization, the read-only organization can audit the blockchain-based system. In addition to verifying the integrity of the blockchain, the read-only organization can perform various checks recommended or mandated by regulations, laws, etc. based on the verified immutability. It contributes to make auditing more robust and efficient.
In a third example implementation,
In this example, one read-only organization provisions a test environment for the system. To test blockchain-based systems during the development and before the deployment, it can be desirable to use the same data as in the real system. For updates of the existing systems, the ledger in the existing system is a promising candidate for the data to be used in the test environment to achieve more practical and effective tests. However, the cryptographic materials, such as public keys and private keys, are not available and should not be used for the test environment because signatures by the materials in the test environment can have the same effect and implications as in the production environment. Moreover, the private data are also necessary, but are not included in the ledger. In this example, the read-only organization can provide test environments with the data extracted from the existing blockchain system, with the necessary conversion for cryptographic materials and relevant information, and with the private data of all the organizations.
The test environment manager 1310 converts blocks, transactions and private data properly, and generates and destroys blockchain network for testing purposes using the converted data. It can be a physical computer, a virtual machine, a container, etc. and its hardware can be shared with other components. It can communicate with the blockchain node 110 using the network 140 or other network internal to the read-only organization 101. It obtains blocks and private data in the manner shown in the second example implementation. The test blockchain networks 1320 are blockchain-based systems generated and configured by the test environment manager 1310. They have structures that are the same as or similar to
If a transaction is a config transaction (Step 1505: Yes), the transform logic 1410 transforms the trust roots 332 for the organizations in the organization information 330 in the transaction (Step 1511). Because different CAs will be used in the test blockchain network 1320 and the certificates in the trust roots should be different from those in the trust roots 332 in the production environment, the trust roots 332 should be replaced with the certificates for the CAs 150 in the test environment manager 1310. Then, the transform logic 1410 transforms the proposer identity and the endorsements like Step 1506 (Step 1512).
When all the transactions in the block are transformed (Step 1503:No), the transform logic 1410 calculates the hash value for the block and replaces the block hash value 302 with the new value. At step 1520, it also replaces the hash value for the previous block 301 with that for the previous block in the transformed ledger 1430. Finally, the transform logic 1410 adds the transformed block into the transformed ledger 1430 (Step 1521).
Computer device 1705 can be communicatively coupled to input/user interface 1735 and output device/interface 1740. Either one or both of input/user interface 1735 and output device/interface 1740 can be a wired or wireless interface and can be detachable. Input/user interface 1735 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, and/or the like). Output device/interface 1740 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface 1735 and output device/interface 1740 can be embedded with or physically coupled to the computer device 1705. In other example implementations, other computer devices may function as or provide the functions of input/user interface 1735 and output device/interface 1740 for a computer device 1705.
Examples of computer device 1705 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like).
Computer device 1705 can be communicatively coupled (e.g., via IO interface 1725) to external storage 1745 and network 1750 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration. Computer device 1705 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.
IO interface 1725 can include, but is not limited to, wired and/or wireless interfaces using any communication or IO protocols or standards (e.g., Ethernet, 802.11x, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment 1700. Network 1750 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).
Computer device 1705 can use and/or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.
Computer device 1705 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).
Processor(s) 1710 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 1760, application programming interface (API) unit 1765, input unit 1770, output unit 1775, and inter-unit communication mechanism 1795 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor(s) 1710 can be in the form of hardware processors such as central processing units (CPUs) or in a combination of hardware and software units.
In some example implementations, when information or an execution instruction is received by API unit 1765, it may be communicated to one or more other units (e.g., logic unit 1760, input unit 1770, output unit 1775). In some instances, logic unit 1760 may be configured to control the information flow among the units and direct the services provided by API unit 1765, input unit 1770, output unit 1775, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 1760 alone or in conjunction with API unit 1765. The input unit 1770 may be configured to obtain input for the calculations described in the example implementations, and the output unit 1775 may be configured to provide output based on the calculations described in example implementations.
The blockchain system is configured to facilitate a smart contract transaction through a plurality of nodes. In an example for a first node (e.g., any node of the plurality of nodes in the blockchain) processor(s) 1710 is configured to, responsive to receiving a proposal for the smart contract transaction from a second node of the plurality of nodes, identify an organization in the blockchain system associated with the second node; determine whether the organization is capable of executing the smart contract transaction indicated by the proposal; for the determination indicating that the organization does not have capability of executing the smart contract transaction indicated by the proposal, return an error to the second node; and for the determination indicating that the organization does have capability of executing the smart contract transaction indicated by the proposal, executing the smart contract transaction as illustrated in
In an example of a first node, processor(s) 1710 is configured to determine whether the organization is capable of executing the smart contract transaction indicated by the proposal by determining that the organization is indicative of not having the capability of executing the smart contract transaction indicated by the proposal for the organization being a read-only organization; and determining that the organization is indicative of having the capability of executing the smart contract transaction indicated by the proposal for the organization not being a read-only organization as illustrated at
In an example of a first node, processor(s) 1710 is configured to, responsive to receiving a request for committing and validating the smart contract transaction from the second node (e.g., another node coupled to the first node), identify the organization in the blockchain system associated with the second node; determine whether the organization is capable of executing the smart contract transaction indicated by the proposal; for the determination indicating that the organization does not have capability of executing the smart contract transaction indicated by the proposal, return an error to the second node; and for the determination indicating that the organization does have capability of executing the smart contract transaction indicated by the proposal, execute an order of transactions provided by an ordering service as illustrated in
In an example for ordering service 130, processor(s) 1710 can be configured to determine an order for executing the request for committing the smart contract transaction from second nodes with other requests for committing smart contract transactions; and provide the order to the first node as illustrated in
In an example of a third node such as an auditing node 1110, processor(s) 1710 configured to execute an auditing process, the auditing process involving receiving the smart contract transaction and private data associated with the smart contract transaction; and executing integrity checks on the smart contract transaction and the private data as illustrated in
In an example of an apparatus belonging to the read-only organization 101, processor(s) 1710 configured to, for receipt of an initiation of a test environment replace an identity of the organization in the blockchain system that initiated the proposal in the smart contract transaction and endorsements with the identity and endorsements issued by a test environment manager managing the test environment; and for the smart contract transaction indicative of a change in a configuration of the system, transform trust roots for organizations in the blockchain system indicated by organization information in the smart contract transaction as illustrated at
In an example of such an apparatus belonging to the read-only organization 101, processor(s) 1710 is configured to launch a new blockchain network on the test environment, the launch facilitated by a test network launcher, the launch comprising copying a ledger transformed by the test environment manager and a state database transformed by the test environment manager to each blockchain node in the new blockchain network; and copying private data transformed by the test environment manager corresponding to organizations in the blockchain system associated with the smart contract transaction to the each blockchain node in the new blockchain network corresponding to the organizations as illustrated in
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.
Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.
Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.
Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.
As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.
Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2020/025780 | 3/30/2020 | WO |