US20180225661A1 - Consortium blockchain network with verified blockchain and consensus protocols - Google Patents

Consortium blockchain network with verified blockchain and consensus protocols Download PDF

Info

Publication number
US20180225661A1
US20180225661A1 US15/638,203 US201715638203A US2018225661A1 US 20180225661 A1 US20180225661 A1 US 20180225661A1 US 201715638203 A US201715638203 A US 201715638203A US 2018225661 A1 US2018225661 A1 US 2018225661A1
Authority
US
United States
Prior art keywords
blockchain
tee
code
examples
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US15/638,203
Inventor
Mark Russinovich
Manuel Costa
Matthew Kerner
Thomas Moscibroda
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Priority to US15/638,203 priority Critical patent/US20180225661A1/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KERNER, MATTHEW, MOSCIBRODA, THOMAS, COSTA, MANUEL, RUSSINOVICH, MARK
Priority to PCT/US2018/016057 priority patent/WO2018148068A1/en
Priority to ES18706017T priority patent/ES2909088T3/en
Priority to EP18706017.3A priority patent/EP3580905B1/en
Priority to CN201880010516.0A priority patent/CN110268691B/en
Publication of US20180225661A1 publication Critical patent/US20180225661A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00217Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
    • G11B20/00253Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier
    • G11B20/00282Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier the key being stored in the content area, e.g. program area, data area or user area
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101Access control lists [ACL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104Grouping of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127Trusted platform modules [TPM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures

Definitions

  • Blockchain systems have been proposed for a variety of application scenarios, including applications in the financial industry, health care, IoT, and so forth.
  • the Bitcoin system was developed to allow electronic cash to be transferred directly from one party to another without going through a financial institution.
  • a bitcoin e.g., an electronic coin
  • a new transaction may be generated and added to a stack of transactions in a block.
  • the new transaction which includes the public key of the new owner, may be digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner public key.
  • the block may be “capped” with a block header that is a hash digest of all the transaction identifiers within the block.
  • the block header may be recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a “blockchain.”
  • the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction.
  • the new owner need only have the private key that matches the public key of the transaction that transferred the bitcoin.
  • the blockchain may create a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which in the case of the bitcoin system is pseudo-anonymous.
  • the disclosed technology is generally directed to blockchain and other authentication technology.
  • a pre-determined type of blockchain or other authentication protocol code and a pre-determined type of consensus code are stored in a trusted execution environment (TEE) of a processor.
  • TEE attestation is used to verify that the blockchain or other authentication protocol code stored in the TEE is the pre-determined type of blockchain or other authentication protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code.
  • a request to alter the pre-determined type of blockchain or other authentication protocol code may be received.
  • a determination may be made as to whether to change the pre-determined type of blockchain or other authentication protocol code based on the pre-determined consensus code.
  • prospective members of a blockchain consortium agree upon certain aspects of a consortium blockchain network before establishing the network, including, for example, the blockchain protocol code to be used, the consensus protocol to be used, the initial membership list, and possibly also many other aspects of the blockchain network.
  • At least one of the prospective members may endorse a validation node (VN).
  • VN validation node
  • TEE attestation may be used to verify that each of the nodes store the agreed-upon blockchain network protocol and the agreed-upon consensus protocol.
  • consortium network may then be bootstrapped, and private keys may be exchanged, with all of the prospective members now members of the consortium network.
  • a blockchain master key may be generated from the private keys of the members.
  • participants of the network may then be approved to join by the members.
  • the network is established and is ready to receive transactions.
  • a participant of a blockchain network may submit a transaction to the blockchain network.
  • the transaction may be forwarded to a VN in the blockchain network that is selected based on the agreed-upon consensus protocol.
  • the selected VN may then process the transaction by executing the code of the transaction, and may then resolve any conflicts.
  • the VN may then directly update the official state of the processed blockchain based on the processing of the blockchain transaction.
  • the VN may then broadcast the updated official state of the processed blockchain to the blockchain network.
  • FIG. 1 is a block diagram illustrating one example of a suitable environment in which aspects of the technology may be employed
  • FIG. 2 is a block diagram illustrating one example of a suitable computing device according to aspects of the disclosed technology
  • FIG. 3 is a block diagram illustrating an example of a system
  • FIG. 4 is a block diagram illustrating an example of a validation node
  • FIGS. 5A-5C are a diagram illustrating an example dataflow for a process for establishing a blockchain network
  • FIGS. 6A-6B are a diagram illustrating an example dataflow for a process for transaction processing for a blockchain network
  • FIG. 7 is a diagram illustrating another example process for transaction processing for a blockchain network
  • FIG. 8 is a block diagram illustrating an example of a system including a Confidential Consortium Blockchain Framework (COCO) network with three members;
  • COCO Confidential Consortium Blockchain Framework
  • FIG. 9 is a block diagram illustrating an example of system that includes a portion of a COCO network including two validation nodes undergoing validation node attestation and key exchange;
  • FIG. 10 is a diagram illustrating example steps for adding a new member to a COCO network.
  • FIG. 11 is a diagram illustrating an example dataflow for a process for a blockchain system, in accordance with aspects of the present disclosure.
  • each of the terms “based on” and “based upon” is not exclusive, and is equivalent to the term “based, at least in part, on”, and includes the option of being based on additional factors, some of which may not be described herein.
  • the term “via” is not exclusive, and is equivalent to the term “via, at least in part”, and includes the option of being via additional factors, some of which may not be described herein.
  • the meaning of “in” includes “in” and “on.”
  • the phrase “in one embodiment,” or “in one example,” as used herein does not necessarily refer to the same embodiment or example, although it may.
  • a widget selected from the group consisting of a third foo and a fourth bar would not itself imply that there are at least three foo, nor that there are at least four bar, elements.
  • References in the singular are made merely for clarity of reading and include plural references unless plural references are specifically excluded.
  • the term “or” is an inclusive “or” operator unless specifically indicated otherwise.
  • the phrases “A or B” means “A, B, or A and B.”
  • the terms “component” and “system” are intended to encompass hardware, software, or various combinations of hardware and software.
  • a system or component may be a process, a process executing on a computing device, the computing device, or a portion thereof.
  • the disclosed technology is generally directed to blockchain and other authentication technology.
  • a pre-determined type of blockchain or other authentication protocol code and a pre-determined type of consensus code are stored in a trusted execution environment (TEE) of a processor.
  • TEE attestation is used to verify that the blockchain or other authentication protocol code stored in the TEE is the pre-determined type of blockchain or other authentication protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code.
  • a request to alter the pre-determined type of blockchain or other authentication protocol code may be received.
  • a determination may be made as to whether to change the pre-determined type of blockchain or other authentication protocol code based on the pre-determined consensus code.
  • prospective members of a blockchain consortium agree upon certain aspects of a consortium blockchain network before establishing the network, including, for example, the blockchain protocol code to be used, the consensus protocol to be used, the initial membership list, and possibly also many other aspects of the blockchain network.
  • At least one of the prospective members may endorse a validation node (VN).
  • VN validation node
  • TEE attestation may be used to verify that each of the nodes store the agreed-upon blockchain network protocol and the agreed-upon consensus protocol.
  • consortium network may then be bootstrapped, and private keys may be exchanged, with all of the prospective members now members of the consortium network.
  • a blockchain master key may be generated from the private keys of the members.
  • participants of the network may then be approved to join by the members.
  • the network is established and is ready to receive transactions.
  • a participant of a blockchain network may submit a transaction to the blockchain network.
  • the transaction may be forwarded to a VN in the blockchain network that is selected based on the agreed-upon consensus protocol.
  • the selected VN may then process the transaction by executing the code of the transaction, and may then resolve any conflicts.
  • the VN may then directly update the official state of the processed blockchain based on the processing of the blockchain transaction.
  • the VN may then broadcast the updated official state of the processed blockchain to the blockchain network.
  • FIG. 1 is a diagram of environment 100 in which aspects of the technology may be practiced.
  • environment 100 includes computing devices 110 , as well as network nodes 120 , connected via network 130 .
  • environment 100 can also include additional and/or different components.
  • the environment 100 can also include network storage devices, maintenance managers, and/or other suitable components (not shown).
  • Computing devices 110 shown in FIG. 1 may be in various locations, including on premise, in the cloud, or the like.
  • computer devices 110 may be on the client side, on the server side, or the like.
  • network 130 can include one or more network nodes 120 that interconnect multiple computing devices 110 , and connect computing devices 110 to external network 140 , e.g., the Internet or an intranet.
  • network nodes 120 may include switches, routers, hubs, network controllers, or other network elements.
  • computing devices 110 can be organized into racks, action zones, groups, sets, or other suitable divisions. For example, in the illustrated example, computing devices 110 are grouped into three host sets identified individually as first, second, and third host sets 112 a - 112 c .
  • each of host sets 112 a - 112 c is operatively coupled to a corresponding network node 120 a - 120 c , respectively, which are commonly referred to as “top-of-rack” or “TOR” network nodes.
  • TOR network nodes 120 a - 120 c can then be operatively coupled to additional network nodes 120 to form a computer network in a hierarchical, flat, mesh, or other suitable types of topology that allows communications between computing devices 110 and external network 140 .
  • multiple host sets 112 a - 112 c may share a single network node 120 .
  • Computing devices no may be virtually any type of general- or specific-purpose computing device.
  • these computing devices may be user devices such as desktop computers, laptop computers, tablet computers, display devices, cameras, printers, or smartphones.
  • these computing devices may be server devices such as application server computers, virtual computing host computers, or file server computers.
  • computing devices 110 may be individually configured to provide computing, storage, and/or other suitable computing services.
  • FIG. 2 is a diagram illustrating one example of computing device 200 in which aspects of the technology may be practiced.
  • Computing device 200 may be virtually any type of general- or specific-purpose computing device.
  • computing device 200 may be a user device such as a desktop computer, a laptop computer, a tablet computer, a display device, a camera, a printer, embedded device, programmable logic controller (PLC), or a smartphone.
  • computing device 200 may also be server device such as an application server computer, a virtual computing host computer, or a file server computer, e.g., computing device 200 may be an example of computing device 110 or network node 120 of FIG. 1 .
  • Computing device 200 may also be an IoT device that connects to a network to receive IoT services.
  • computing device 200 may be an example any of the devices, nodes, members, or other entities illustrated in or referred to in various figures, as discussed in greater detail below.
  • computing device 200 includes processing circuit 210 , operating memory 220 , memory controller 230 , data storage memory 250 , input interface 260 , output interface 270 , and network adapter 280 .
  • Each of these afore-listed components of computing device 200 includes at least one hardware element.
  • Computing device 200 includes at least one processing circuit 210 configured to execute instructions, such as instructions for implementing the herein-described workloads, processes, or technology.
  • Processing circuit 210 may include a microprocessor, a microcontroller, a graphics processor, a coprocessor, a field-programmable gate array, a programmable logic device, a signal processor, or any other circuit suitable for processing data.
  • the aforementioned instructions, along with other data may be stored in operating memory 220 during run-time of computing device 200 .
  • Operating memory 220 may also include any of a variety of data storage devices/components, such as volatile memories, semi-volatile memories, random access memories, static memories, caches, buffers, or other media used to store run-time information. In one example, operating memory 220 does not retain information when computing device 200 is powered off. Rather, computing device 200 may be configured to transfer instructions from a non-volatile data storage component (e.g., data storage component 250 ) to operating memory 220 as part of a booting or other loading process.
  • a non-volatile data storage component e.g., data storage component 250
  • Operating memory 220 may include 4th generation double data rate (DDR4) memory, 3rd generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), High Bandwidth Memory (HBM), Hybrid Memory Cube memory, 3D-stacked memory, static random access memory (SRAM), or other memory, and such memory may comprise one or more memory circuits integrated onto a DIMM, SIMM, SODIMM, or other packaging.
  • Such operating memory modules or devices may be organized according to channels, ranks, and banks.
  • operating memory devices may be coupled to processing circuit 210 via memory controller 230 in channels.
  • One example of computing device 200 may include one or two DIMMs per channel, with one or two ranks per channel. Operating memory within a rank may operate with a shared clock, and shared address and command bus.
  • an operating memory device may be organized into several banks where a bank can be thought of as an array addressed by row and column. Based on such an organization of operating memory, physical addresses within the operating memory may be referred to by a tuple of channel, rank, bank, row, and column.
  • operating memory 220 specifically does not include or encompass communications media, any communications medium, or any signals per se.
  • Memory controller 230 is configured to interface processing circuit 210 to operating memory 220 .
  • memory controller 230 may be configured to interface commands, addresses, and data between operating memory 220 and processing circuit 210 .
  • Memory controller 230 may also be configured to abstract or otherwise manage certain aspects of memory management from or for processing circuit 210 .
  • memory controller 230 is illustrated as single memory controller separate from processing circuit 210 , in other examples, multiple memory controllers may be employed, memory controller(s) may be integrated with operating memory 220 , or the like. Further, memory controller(s) may be integrated into processing circuit 210 . These and other variations are possible.
  • bus 240 data storage memory 250 , input interface 260 , output interface 270 , and network adapter 280 are interfaced to processing circuit 210 by bus 240 .
  • FIG. 2 illustrates bus 240 as a single passive bus, other configurations, such as a collection of buses, a collection of point to point links, an input/output controller, a bridge, other interface circuitry, or any collection thereof may also be suitably employed for interfacing data storage memory 250 , input interface 260 , output interface 270 , or network adapter 280 to processing circuit 210 .
  • data storage memory 250 is employed for long-term non-volatile data storage.
  • Data storage memory 250 may include any of a variety of non-volatile data storage devices/components, such as non-volatile memories, disks, disk drives, hard drives, solid-state drives, or any other media that can be used for the non-volatile storage of information.
  • data storage memory 250 specifically does not include or encompass communications media, any communications medium, or any signals per se.
  • data storage memory 250 is employed by computing device 200 for non-volatile long-term data storage, instead of for run-time data storage.
  • computing device 200 may include or be coupled to any type of processor-readable media such as processor-readable storage media (e.g., operating memory 220 and data storage memory 250 ) and communication media (e.g., communication signals and radio waves). While the term processor-readable storage media includes operating memory 220 and data storage memory 250 , the term “processor-readable storage media,” throughout the specification and the claims whether used in the singular or the plural, is defined herein so that the term “processor-readable storage media” specifically excludes and does not encompass communications media, any communications medium, or any signals per se. However, the term “processor-readable storage media” does encompass processor cache, Random Access Memory (RAM), register memory, and/or the like.
  • processor-readable storage media e.g., operating memory 220 and data storage memory 250
  • communication media e.g., communication signals and radio waves.
  • Computing device 200 also includes input interface 260 , which may be configured to enable computing device 200 to receive input from users or from other devices.
  • computing device 200 includes output interface 270 , which may be configured to provide output from computing device 200 .
  • output interface 270 includes a frame buffer, graphics processor, graphics processor or accelerator, and is configured to render displays for presentation on a separate visual display device (such as a monitor, projector, virtual computing client computer, etc.).
  • output interface 270 includes a visual display device and is configured to render and present displays for viewing.
  • computing device 200 is configured to communicate with other computing devices or entities via network adapter 280 .
  • Network adapter 280 may include a wired network adapter, e.g., an Ethernet adapter, a Token Ring adapter, or a Digital Subscriber Line (DSL) adapter.
  • Network adapter 280 may also include a wireless network adapter, for example, a Wi-Fi adapter, a Bluetooth adapter, a ZigBee adapter, a Long Term Evolution (LTE) adapter, or a 5G adapter.
  • computing device 200 is illustrated with certain components configured in a particular arrangement, these components and arrangements are merely one example of a computing device in which the technology may be employed.
  • data storage memory 250 , input interface 260 , output interface 270 , or network adapter 280 may be directly coupled to processing circuit 210 , or be coupled to processing circuit 210 via an input/output controller, a bridge, or other interface circuitry.
  • Other variations of the technology are possible.
  • computing device 200 include at least one memory (e.g., operating memory 220 ) adapted to store run-time data and at least one processor (e.g., processing unit 210 ) that is respectively adapted to execute processor-executable code that, in response to execution, enables computing device 200 to perform actions.
  • memory e.g., operating memory 220
  • processor e.g., processing unit 210
  • FIG. 3 is a block diagram illustrating an example of a system ( 300 ) for a blockchain consortium.
  • System 300 may include network 330 , VNs 351 - 353 , member devices 341 - 343 , and participant devices 311 - 313 .
  • Each VN 351 - 353 includes a corresponding TEE 361 - 363 .
  • Each of the member devices 341 - 343 , participant devices 311 - 313 , and/or VNs 351 - 353 may include examples of computing device 200 of FIG. 2 .
  • FIG. 3 and the corresponding description of FIG. 3 in the specification illustrates an example system for illustrative purposes that does not limit the scope of the disclosure.
  • Network 330 may include one or more computer networks, including wired and/or wireless networks, where each network may be, for example, a wireless network, local area network (LAN), a wide-area network (WAN), and/or a global network such as the Internet.
  • LAN local area network
  • WAN wide-area network
  • Internet global network
  • a router acts as a link between LANs, enabling messages to be sent from one to another.
  • communication links within LANs typically include twisted wire pair or coaxial cable
  • communication links between networks may utilize analog telephone lines, full or fractional dedicated digital lines including T 1 , T 2 , T 3 , and T 4 , Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communications links known to those skilled in the art.
  • ISDNs Integrated Services Digital Networks
  • DSLs Digital Subscriber Lines
  • wireless links including satellite links
  • remote computers and other related electronic devices could be remotely connected to either LANs or WANs via a modem and temporary telephone link.
  • Network 330 may include various other networks such as one or more networks using local network protocols such as 6LoWPAN, ZigBee, or the like. Some IoT devices may be connected to a user device via a different network in network 330 than other IoT devices.
  • network 330 includes any communication method by which information may travel between VNs 351 - 353 , member devices 341 - 343 , and participant devices 311 - 313 .
  • each device or service is shown connected as connected to network 330 , that does not mean that each device communicates with each other device shown. In some examples, some devices/services shown only communicate with some other devices/services shown via one or more intermediary devices.
  • network 330 is illustrated as one network, in some examples, network 330 may instead include multiple networks that may or may not be connected with each other, with some of the devices shown communicating with each other through one network of the multiple networks and other of the devices shown communicating with each other with a different network of the multiple networks.
  • member devices 341 - 343 are devices used by members to communicate over network 330 , such as for communication between a member and its corresponding VN, for example to endorse a VN.
  • participant devices 311 - 313 are devices used by members to communicate over network 330 , such as to request a transaction.
  • VNs 351 - 353 are devices that, during normal operation, validate and process submitted blockchain transactions, and execute chaincode.
  • each VN 351 - 353 includes a TEE.
  • the TEE enables the creation of a protected region inside of a processor, so that the memory in the protected region is encrypted, and only decrypted inside the TEE.
  • a TEE may be interchangeably referred to as an enclave, or, in some examples, the TEE can be seen as a subset of the enclave.
  • TEE attestation can be used to verify the code running in the TEE.
  • the TEE allows integrity of the calculations occurring inside the TEE and confidentiality of what happens inside the TEE.
  • TEE Some examples of a TEE are based on hardware, and others are based on software. Examples of a hardware-based TEE use hardware-based protection of a memory range that defines the address range of the TEE. In some examples, writes to the TEE are encrypted. In some examples, the CPU does not allow anything outside of the address range of the TEE to see that address range in clear text, and writes from outside of the address range area not permitted in the address range of the TEE.
  • certain details are agreed upon by prospective members of the blockchain network, including which blockchain protocol code and which consensus protocol code are to be executed in the TEE of each validation node of the consortium blockchain network.
  • one or more validation node is endorsed by one of more members of the consortium blockchain network.
  • TEE attestation may be used to verify that each validation node is executing the agreed-upon blockchain protocol code and the agreed-upon consensus protocol code.
  • the consortium blockchain network After the consortium blockchain network is established, in some examples, it is possible to change the initially agreed-upon parameters, such as the agreed-upon blockchain protocol code to be run in the TEE—in some examples, such a change is determined based on the consensus protocol, M-of-N voting, and/or the like, as explained in greater detail below.
  • the initially agreed-upon parameters such as the agreed-upon blockchain protocol code
  • System 300 may include more or less devices than illustrated in FIG. 3 , which is shown by way of example only.
  • FIG. 4 is a block diagram illustrating an example of VN 451 , which may communicate with, e.g., participant 411 and/or endorser 441 .
  • VN 451 may include TEE 461 , blockchain service 471 , and disk storage 472 .
  • TEE 461 may include blockchain protocol 465 , Confidential Consortium (COCO) Blockchain application programming interface (API) 466 , and COCO core 467 .
  • COCO Confidential Consortium
  • API application programming interface
  • Blockchain service 471 may include software that performs functions for maintaining the availability and durability of the blockchain system.
  • Disk storage 472 may, for example, include encrypted blockchain data and metadata when there is insufficient storage available in the TEE to store all of the data, or in other suitable situations.
  • Blockchain protocol 465 may include the agreed-upon blockchain protocol code.
  • COCO core is the core COCO framework code, which is explained in greater detail below.
  • COCO API 466 is the API for the COCO framework.
  • VN 451 may communicate over a network with other VNs, one or more participant, and/or one or more endorser, including, for example, participant 411 and endorser 441 , where endorser 441 is a member that endorses VN 451 .
  • everything in the VN outside of the TEE is modeled as untrusted.
  • the portions of the VN outside of the TEE function to maintain availability and durability of the system.
  • the lifecycle of the blockchain protocol in the TEE is governed by the software running inside of the TEE, based on the members' instructions, and later based on the decision of the consortium (e.g., quorum) as a whole, as discussed in greater detail below.
  • the TEE is split into two separate protected regions, one with the blockchain API, and the other one running the blockchain protocol, with a secure connection between them.
  • processor-readable instructions stored in a processor-readable storage medium or be performed as a computer-implemented process.
  • these processes may be encoded as processor-executable instructions and transmitted via a communications medium.
  • FIGS. 5A-5C are a diagram illustrating an example dataflow for a process ( 520 ) for establishing a consortium blockchain network.
  • step 521 occurs first.
  • prospective members of a blockchain consortium agree upon certain aspects of a consortium blockchain network before establishing the network.
  • the agreed-upon aspects may include one or more of the following: who the initial members will be, what code is approved to execute in a TEE of the VNs of the network (including blockchain protocol code and consensus protocol code), what processor(s) is acceptable in the VNs of the network, what constitutes an accepted TEE, what software versions of blockchain code will be executed, and/or the like.
  • step 522 occurs next in some examples.
  • each prospective member endorses at least one separate VN.
  • the prospective member stores the agreed-upon code in the TEE, and stores the public/private key pair (PBK and KBK respectively) in the TEE.
  • PBK and KBK respectively the public/private key pair
  • Some of the agreed-upon aspects may also be stored in the VN, such as the agreed-upon membership list and an identification of the agreed-upon code to execute in the TEE.
  • step 522 may be performed in a different manner than described above. For instance, in some example, not every prospective member endorses a separate VN. For instance, in some examples, only one VN is endorsed.
  • step 523 occurs next in some examples.
  • each VN discovers the other VNs in the network. In some examples, there is only one VN, and step 523 is not performed.
  • step 524 occurs next in some examples.
  • the following are received: a plurality of membership lists, and a plurality of authorizations from the plurality of prospective members of the consortium.
  • the authorizations are indications associated with a pre-determined type of blockchain protocol code and a pre-determined type of consensus protocol code.
  • the membership lists and authorizations are sent by each of the VNs and each VN receives the memberships lists and authorizations sent by each other VN. In other examples, there is only one VN, and the memberships lists and authorizations are received from the member devices of the prospective members.
  • decision block 525 occurs next in some examples.
  • a determination is made as to whether the membership lists from each of the prospective members match each other. If not, in some examples, the process proceeds to a return block, where other processing is resumed. If, however, the determination at decision block 525 is positive, in some examples, the process moves to decision block 526 .
  • TEE attestation may be used to verify that nodes associated with prospective members of the consortium stores the agreed-upon authorized blockchain protocol code and consensus protocol code to be run on the TEE. If the TEE attestation is negative, in some examples, the process moves to the return block. Otherwise, in some examples, the process advances to block 528 .
  • private keys may be exchanged among the VNs.
  • block 529 occurs next in some examples.
  • a blockchain master key (BMK) may be generated from each of the private keys.
  • decision block 530 occurs next in some examples.
  • participants are approved to join by members. In some examples, participants are allowed to request transactions and to see transactions that they are authorized to see, but do not have other rights of members, such as voting rights to vote on changing membership, change the protocol blockchain code used, or the like.
  • the network is now ready to process transactions from participants. The process may then proceed to the return block.
  • a public network may allow any participant to submit transactions, but a non-public network requires participants to be provisioned, which is another privilege of a VN's endorser.
  • Participants may be represented by a public/private key pair that's allowed to submit transactions for execution by the network.
  • the set of participants does not necessarily include the members, though in some examples it does.
  • Members may authorize participants by submitting to their VN the public transaction key(PTK) of a participant, and VNs may share, with the network, the list of their provisioned participants. If a network requires participants to be approved by more than one member, the network may use a protocol similar to that of approving a new member, as discussed in greater detail below.
  • consortium blockchain network may begin receiving and processing transactions.
  • FIGS. 6A-6B are a diagram illustrating an example dataflow for a process ( 620 ) for transaction processing for a consortium blockchain network.
  • step 621 occurs first.
  • a participant encrypts a blockchain transaction with the blockchain master key.
  • step 622 occurs next.
  • the participant transmits the encrypted blockchain transaction.
  • step 623 occurs next in some examples.
  • the encrypted blockchain transaction may be forwarded to a particular VN that is selected based on the agreed-upon consensus protocol code.
  • a consensus algorithm may be used to elect a VN leader, and the VN leader receives transactions, commits transactions, and broadcasts the transactions to all of the other members.
  • the VN leader is interchangeably referred to herein as the master VN.
  • the consensus algorithm is used to elect the VN leader, and the encrypted blockchain transaction is forwarded to the VN leader.
  • step 624 occurs next in some examples.
  • the VN to which the encrypted transaction was forwarded receives the encrypted blockchain transaction.
  • step 625 occurs next in some examples.
  • the VN processes the blockchain transaction by executing the code of the transaction.
  • step 626 occurs next in some examples.
  • the VN directly updates the official state of the processed blockchain based on the processing of the blockchain transaction.
  • step 627 occurs next in some examples. “Directly” updating the state means that the VN updates the state without any actions or confirmation being required by any other entity in order to update the state.
  • the updated official state of the processed blockchain may be broadcast to the blockchain network.
  • VNs do not do re-computation for verification, which makes it possible for blockchain states to be directly updated at step 626 .
  • the VNs in the blockchain consortium network are fully trusted, other VNs on the network can implicitly accept any blockchain state updates it receives from a trusted VN as being compliant with the blockchain's protocol and protected from external tampering by the TEE. Further, in some examples, there is no need for a copy of the transaction in order to confirm a block.
  • the process may then proceed to a return block, where other processing is resumed.
  • chaincode need not be executed more than once by the network, chaincode may be non-deterministic, and chaincode may include interactions with external systems.
  • blockchains may also be constructed with varying levels of defense against hostile participants attempting to compromise integrity and confidentiality, from protection against a single rogue member, to M of N voting, to requiring all members to agree on state changes.
  • the network may accommodate arbitrary blockchain abstractions, arbitrary blockchain protocols, and arbitrary ledgers, and may be able to integrate existing blockchain technologies of any type.
  • M of N voting N refers to the total number of members, and M refers to the number of members for establishing a quorum in a vote.
  • Examples of the network may enable improving the performance characteristics of blockchains without changing the trust assumptions between the members. Examples of the network may allow for data to remain private when put onto a blockchain so that only relevant parties can see a transaction. Examples of the network may enable code that runs inside of a blockchain to be non-deterministic, so that, for example, a different result may be produced every time. Examples of the network may achieve such results without introducing unneeded complexity, introducing additional significant performance overheads, or introducing an unnatural trust assumption.
  • Examples of the network make TEE Attestation in VNs of the network so that the code inside of the TEE can have the trust accepting that the operating system and the other user-mode code around the TEE in the operating environment of the TEE is completely untrusted, and yet the TEE can still operate in a trusted way by relying on the hardware-enforced privacy (e.g., by leveraging or otherwise employing Software Guard Extensions, a Platform Security Processor, a Secure Execution Environment, or the like) and the TEE can project the trust externally by establishing a secure connection to some endpoint outside of the TEE. In some examples, this allows integrity of the calculations occurring inside the TEE and confidentiality of what happens inside the TEE. Examples of the network use the trust associated with the TEE as the building block of trust assumptions in the blockchain system.
  • each VN in the network is fully trusted by the network by virtue of the fact that other VNs can verify the endorsement of a VN by its endorsing member, and using TEE attestation that the VN is executing code approved by the membership.
  • VNs may establish trusted connections with each other through a similar process to endorsement where, after a VN attests to the fact that the VN's code is a trusted version running in a trusted TEE, as well as to the fact that it has the same membership list, other VNs release the KBK of their endorsing member.
  • the output of one node that is provided as input from another node can be trusted because the code that generated the output is proven to be trusted code previously approved by the membership.
  • all the contents of the blockchain are encrypted, and the contents of the blockchain are only decrypted inside of a TEE with a valid attestation, which enables confidentiality.
  • the code in a TEE with valid attestation can be non-deterministic—since the TEE is trusted, there is no need for other nodes to reproduce the results of other nodes in such examples.
  • the VNs operate according to a Confidential Consortium Blockchain Framework (COCO) framework, which allows any suitable blockchain protocol to be used, and allows any suitable consensus protocol to be used in conjunction with the COCO framework.
  • COCO Confidential Consortium Blockchain Framework
  • some examples of the COCO framework include confidentiality, and some examples of the COCO framework do not include confidentiality.
  • the COCO framework is not used by itself, but in conjunction with, for example, a blockchain protocol and a consensus protocol selected by the membership.
  • the COCO framework is the code operating in the VN that is used for establishing the blockchain network, enabling arbitrary blockchain and consensus protocols, arbitrary blockchain ledgers, arbitrary blockchain abstractions, and the use of any suitable blockchain technology.
  • COCO framework does not itself define blockchain ledgers and the actual blockchain transaction processing, but allows any suitable ledgers and blockchain protocols to be used, and enables confidential properties for the transactions, governs trust assumptions, allows chaincode to be executed only once by the network, allows the chaincode to be non-deterministic, and allows chaincode to include interactions with external systems.
  • the COCO framework may also include varying levels of defense against hostile participants attempting to compromise integrity and confidentiality, from protection against a single rogue member, to “M of N” voting, to requiring all members to agree on state changes.
  • a network of VNs that operate according to a COCO framework being executed on each of the VNs may be referred to as a COCO network.
  • the members initially agree on certain approvals, including, for example, who the members will be, what code is approved to execute in a TEE, what processor(s) are acceptable, what constitutes an accepted TEE, what COCO framework to use, what software versions of blockchain code will be executed, and each member starts at least one VN.
  • each member maintains at least one VN, each of which participates in the blockchain network's transaction processing and consensus protocol. In other examples, each member does not necessarily maintain its own VN.
  • certain initial approvals require unanimous agreement in order for the network to be established, and other of the approvals may only require agreement among a quorum of prospective members, or the initial approval may be determined based on the consensus protocol in the consensus protocol code.
  • VNs validate and process submitted transactions, and execute chaincode.
  • a member may deploy a version of the blockchain protocol implementation that they trust to a Trusted Execution Environment (TEE), and once the blockchain code attests to the fact that it is code that the member trusts and that it's executing in a TEE also trusted by the member, the member endorses the VN by provisioning it with their public and private blockchain keys (PBK and KBK, respectively).
  • TEE Trusted Execution Environment
  • PBK and KBK public and private blockchain keys
  • the owner of a VN is considered its endorser, and the endorser can update the membership list the VN trusts by submitting the public blockchain signing keys of the members.
  • consensus is required for membership and protocol updates, as well as updates to blockchain and chaincode state.
  • the consensus protocol used is one of the agreed-upon parameters for establishing the network.
  • every VN fully trusts every other with which it has established a trusted connection. Accordingly, in some examples, so long as blockchain updates are non-conflicting with the existing state maintained by a VN, it can be unequivocally accepted; in these examples, it's only when there's potential for conflicting updates that an explicit consensus protocol is required.
  • the network can implement consensus in various examples, but in some examples, the network does not require wasteful proof-of-work, latency-causing time-bound, or potentially unfair proof-of-stake algorithms.
  • consensus relies on Paxos or one of the many Paxos-like consensus algorithms, which is practical when the network consists of a relatively small number of consensus participants.
  • the blockchain code executing in the TEE implements consensus, and because the code is trusted, there is no need to defend against byzantine faults such as malicious messages.
  • Paxos is allowed to set to grow to accommodate at least one VN of each member, though in some examples more than one is not included so as to keep the consensus participant set small for maximum efficiency.
  • Paxos-type consensus is used to implement high-availability for centralized databases, so example small networks can use this to achieve database-level throughput and latency. This approach may ensure that there's one version of the blockchain state that's agreed upon by the network's majority.
  • FIG. 7 is a diagram illustrating an example dataflow for a process ( 760 ) for blockchain transaction processing.
  • a participant may submit a transaction.
  • the transaction is encrypted with the BMK.
  • any VN in the network may accept and process transactions, and the agreed-upon consensus protocol is used.
  • a received transaction is forwarded to the VN acting as a master based on the consensus protocol.
  • the master VN then receives the transaction.
  • the VN which is to process the transaction, according to the agreed-upon consensus protocol, may process the transaction by executing the code of the transaction.
  • the master VN then resolves any conflicts.
  • all the data inside of TEE is in plain text.
  • data outside of TEE disk/network
  • BMK disk/network
  • each VN stores a full copy of the ledger
  • the data inside the TEE is in plain text
  • data outside of the TEE such as data on disk or being communicated over the network, is signed by the BSK and encrypted by the BMK.
  • each VN need not store a copy of the ledger.
  • the ledger can be stored in an external storage cloud service or in an on-premises storage array.
  • the VN may broadcast the transaction and the state of the transaction to the other VNs.
  • the VN may directly update the blockchain state.
  • VNs because of the trust, VNs do not need to do re-computation for verification, and blockchain states are directly updated.
  • FIG. 8 is a block diagram illustrating an example of a system including an example COCO network ( 800 ) with three members and three corresponding VNs.
  • FIG. 8 shows an example COCO network where three VNs have been provisioned, each by a different member.
  • the public key for member i is depicted as PBKmi, and its private key KBKmi.
  • the VNs in the example of FIG. 8 have established trusted connections and shared these keys.
  • VNs a foundation is in place on which blockchain protocols can be implemented that employ efficient consensus algorithms, where a single VN can act on behalf of the entire network such that other nodes accept the transactions, including chaincode transactions, knowing that they conform to the rules of the blockchain.
  • VNs can also unilaterally, or by a voting scheme, approve participants, including themselves.
  • a participant has no network voting privileges, but by virtue of the network being provisioned with their public transaction keys (PTKs), can submit transactions.
  • PTKs public transaction keys
  • a VN's blockchain protocol code may accept transactions from other VNs knowing that they adhere to the blockchain protocol rules, and commit any that do not conflict with any already committed transactions. In some examples, if a transaction conflicts with another uncommitted transaction, the VN uses a consensus protocol to determine which transaction wins, and the majority of the VNs will quickly converge on the winning transactions. Further, because a VN's execution may be protected by a TEE from outside inspection, it may implement arbitrary confidentiality models, including only allowing the members that are participants in a transaction to see the transaction.
  • VNs protect the integrity of externally stored blockchain state by using a pair of blockchain public key and private key (BPK and BSK), and optionally its confidentiality by using a blockchain master key (BMK) derived from a set of KBKs of the members.
  • BPK and BSK blockchain public key and private key
  • BMK blockchain master key
  • KBKs are shared across the VNs of a network for this reason.
  • BMKs are specific to a membership set, and a flexible M of N scheme protects BMKs from compromise by fewer than M colluding members.
  • the network when the membership set updates, the network generates a new BMK to protect all subsequently appended states.
  • one, some or all of initially agreed-upon parameters such as the membership, blockchain protocol code, consensus protocol code, COCO framework, processor, TEE, and other parameters may be changed, based on the consensus protocol code.
  • a request may be made to the validation nodes, to alter one of these parameters, such as a membership addition, a membership removal, a processor type for the processor that includes the TEE, a TEE type, a code version executing in the TEE, or a Confidential Consortium Blockchain Framework (COCO) version executing in the TEE.
  • COCO Confidential Consortium Blockchain Framework
  • the BMK can only be recovered with the consent of M of N members.
  • changes to some or all of the parameters discussed above may be changed by M of N voting, where N is the total current number of members, and M is a number from 1 to N that is the quorum for changing a parameter, where M is one of the agreed-upon parameters when initially establishing the consortium blockchain network.
  • members have voting privileges, and participants that are not members do not have voting privileges.
  • the addition of new participants requires consensus based on the agreed-upon consensus protocol.
  • a member can unilaterally add new participants. Whether the addition of new participants can be done unilaterally may be one of the agreed-upon initial parameters.
  • the approval of additions to, and removals from, the network's membership list, and changes to the set of approved blockchain implementations the network allows to participate may be made based on the agreed-upon consensus protocol. Further, in some examples, for networks that require participants to be authorized by members, members can also approve the set of participants that have permission to submit transactions to the network. The protocol for reaching agreement among members, may be implemented by the agreed-upon code stored in the TEE of each validation node.
  • each member is represented with a public/private key pair (PBK and KBK) that the member uses to bootstrap their membership in the COCO through a process of endorsement.
  • endorsement represents the fact that the member fully trusts a specific implementation of the network's blockchain protocol.
  • VNs execute endorsed blockchain code in a Trusted Execution Environment (TEE), and each VN is endorsed by exactly one member. For example, code that is stored on the blockchain can be executed as part of a transaction.
  • TEE Trusted Execution Environment
  • a member shares the member's KBK with the VN.
  • each member endorses at least one VN, but endorsing multiple nodes can provide high availability.
  • Endorsement may provide the endorsing member the exclusive ability to authorize which other members and other implementations of the blockchain protocol implementation the VN will participate with.
  • a VN will accept membership updates and approval to trust blockchain protocol implementations other than its own only from the VN's endorsing member.
  • a VN to protect all the VN's external communications, a VN generates a public/private key pair using the TEE and shares its public key externally.
  • a member may establish a secure tunnel with a VN, including potentially ones for which the VN is not the endorser, using the VN's public key. The VN may then use proof-of-possession of the VN's KBK to authenticate VN requests.
  • VN request is authorizing a network member, which as mentioned, only a node's endorser can execute in some examples.
  • the endorser submits the PBK of that member.
  • a VN can join the network.
  • joining is the act of a VN establishing trusted connections with the network's other VNs.
  • a network may use a discovery protocol that suits the network's requirements to provide a VN the ability to find and connect with the network's other VNs.
  • the endorser may provide the list of nodes by submitting the nodes' DNS names, IP addresses, or identifiers specific to the blockchain network's discovery and connection system.
  • establishing a trusted connection with another VN starts with the creation of a mutually-authenticated secure tunnel built on the public keys of the communicating VNs.
  • a VN proves that it possesses its endorser's KBK. In some examples, this ensures that a remote node has been endorsed by an authorized member, since the tunnel proves that the node can provide an endorsement referencing the VN's public key signed by a member's KBK that matches the member's PBK.
  • FIG. 9 is a block diagram illustrating an example of system ( 900 ) that includes a portion of a COCO network including two validation nodes undergoing validation node attestation and key exchange as the final part of a new member joining the network.
  • FIG. 9 shows an example of VN attestation and key exchange as the final step in establishing trust between nodes via an exchange of the exact version of the blockchain protocol implementation the node is running, as well as a comparison of membership lists.
  • a node may do this using TEE attestation, which includes proof that the node is running the specific implementation in a specific TEE.
  • VN determines that a remote node is executing trusted code in a TEE that the VN also trusts
  • the VN checks to make sure that the remote endorser is in the local membership list, and if so, the channel is considered trusted and the VN will accept blockchain updates from the remote node. In some examples, this means that the VN is confident that the remote node will not expose or leak data that the blockchain protocol doesn't allow.
  • the agreed-upon membership set itself can be kept confidential by having VNs refer to members by hashes (e.g., salted hashes) of their PBKs, rather than the PBKs themselves.
  • a VN shares the VN's endorser's KBK.
  • the blockchain evolves in two ways: membership updates, as described above, and blockchain code updates.
  • membership updates As described above, this may result in the desire for the network to accept one or more new implementations of the blockchain code.
  • a member that wishes to upgrade the blockchain code may shut down their existing VNs and launch new ones in place of the existing VNs.
  • the member may choose to allow the new VNs to trust previous versions, or to only trust new versions.
  • Trusting existing versions may ensure that transactions can continue to be processed while the new version doesn't have a M of N majority, but new versions and not existing versions may be done instead if the previous code is considered untrustworthy for some reason, or if the complexity to maintain protocol compatibility it too great.
  • Cross-version incompatibility during the upgrade may interrupt transaction processing, however.
  • the establishment of trust between VNs that represent every member results in each node eventually obtaining a copy of the KBKs of all the network's members.
  • a node will accept blockchain updates signed with the private signing key of the members that the node is provisioned to participate with, regardless of whether the node receives the transactions directly from the member's VN, or from another trusted VN.
  • Adding a new member to the network may require that a VN's endorser proposes it to the network by provisioning the PBK of the new member. The endorser may then let the other VNs know of the proposal, and the fact that the endorser has voted for the new member's admission to the network. As other members propose the same member, their VNs may note the vote and let the network know. In some examples, a VN does not accept blockchain updates proposed by a member until a consensus is reached based on the agreed-upon consensus protocol.
  • FIG. 10 is a diagram illustrating example of a process ( 1080 ) for adding a new member to a consortium blockchain network.
  • FIG. 10 shows an example of the steps followed by a network with two members (m 1 and m 2 ) adding a third member m 3 .
  • An example of the steps of FIG. 10 proceeds as follows.
  • member m 1 proposes the new member, m 3 .
  • the member's VN notes the proposal and the member's endorser votes, and then passes the proposal to the other VNs.
  • the VN of m 1 notes the proposal and m 1 's admission vote.
  • member m 2 proposes the new member, and both VNs note the vote, which is now unanimous, so in (c) each VN has added the new member and once it does, the VN considers the new member in voting and will accept blockchain updates from the new member.
  • a member can request that the blockchain network (meaning the VNs) remove it from the membership set.
  • the blockchain network meaning the VNs
  • a VN will only remove a member when either a majority or all VNs representing members except the one being removed agree to remove the member, depending on the membership rules of the network.
  • a majority ( ⁇ 1 ⁇ 2N+1, where N is the initial membership count), with the caveat that the removing member does not have a vote (so effectively ⁇ 1 ⁇ 2N), is required to remove a member, in order to prevent a rogue member from instructing its VNs to remove all other members, which would leave it with the ability to decrypt all of the blockchain's state (examples of the blockchain encryption scheme are discussed in greater detail below).
  • VNs destroy the VNs' ephemeral copies of the member's private symmetric encryption key and trigger the generation of a new membership metadata block.
  • a member may also request a key rollover operation, whereby the membership metadata is updated to reflect the new public key and the member's old KBK is encrypted with the new one and stored in the membership metadata.
  • the network will not accept any transactions referencing the old KBK. However, the network may allow the member to access any transactions associated with the old key when a member proves they have access to the new one, which may enable the member full access to their data while preventing access by the old key.
  • COCO supports arbitrary blockchain protocols.
  • the blockchain code may implement Ethereum, Corda, Chain Core, or a Hyperledger system.
  • existing systems are not designed to take advantage of the trust and confidentiality properties of some examples of COCO.
  • COCO VNs are fully trusted, other VNs on the network can implicitly accept any blockchain state updates it receives from a trusted VN as being compliant with the blockchain's protocol and protected from external tampering by the TEE.
  • Chaincode may use the TEE's non-determinism, for example, to generate random numbers for use in lotteries or to resolve conflicts.
  • the chaincode may also call out to external systems, which may replace the need for on-chain oracles with external ones trusted by the chaincode, with the advantage that the external system may be referenced at the time a VN accepts the chaincode transaction.
  • Chaincode can also execute external operations that have side-effects, so long as compensating actions can undo the operation if there's any possibility that such an operation will be rendered obsolete by a superseding conflict or the transaction is lost before it is committed by a majority of the VNs.
  • a participant may ensure that the network, or more specifically, the VN to which it is submitting transactions will be confidential by encrypting the transaction with the PBK of a member's KBK.
  • the VN's representative member has endorsed will have access to the contents of the transaction, which may include sensitive information.
  • a transaction may be encrypted with a unique key that itself is encrypted with an M of N encoding of the PBK's of those members.
  • the VNs all process the transaction in the clear, but the transaction itself is stored in the blockchain encrypted with the BMK. In some examples, the VNs then only allow the members involved in the transaction to see the transaction. The same model may be applied to chaincode and chaincode state.
  • a majority of members may request to reveal an otherwise confidential transaction, something that may be desirable for cases where the consortium subsequently requires a full view of historical activity.
  • Other examples allow for the provisioning of auditing members.
  • an M of N scheme can enable members to agree to admit members with special privileges, like being able to read all transactions, even ones marked confidential.
  • VNs achieve consensus. Distributing transactions throughout the network may be performed using multi-cast, broadcast trees, or any other protocol deemed efficient by the membership for the scale of membership and the topology of the VN communications network.
  • the trusted nature of VNs means that consensus can be achieved as quickly as messages can be distributed to a majority of the nodes.
  • each VN can build a different version of the blockchain.
  • a VN may have some transactions that have been committed by majority subset N of the VNs, and other transactions committed by a different subset N.
  • the committed blockchain state of every VN is a correct representation of the blockchain's state, even if the order of blocks is unique.
  • COCO networks may be built with other consensus protocols, but some examples use consensus protocols that can take advantage of the fact that a message received from a trusted VN is itself trusted to achieve efficient agreement and maximum throughput.
  • transaction processing proceeds as follows. First, a participant submits a transaction.
  • the transaction submitted by the participant may be encrypted with the BMK and forwarded to the VN acting as a master based on the consensus protocol.
  • the master VN is interchangeably referred to as the leader VN.
  • the master VN receives the transaction and processes the transaction by executing the code of the transaction.
  • the master VN resolves any conflicts, and broadcasts the transaction and the state of the transaction to the other VNs.
  • each VN stores a full copy of the ledger
  • the data inside the TEE is in plain text
  • data outside of the TEE such as data on disk or being communicated over the network, is signed by the BSK and encrypted by the BMK.
  • the VN can then update the transaction state directly.
  • each VN need not store a copy of the ledger.
  • the ledger can be stored in an external storage cloud service or in an on premises storage array.
  • a COCO blockchain's persistent state meaning the state that's written to durable storage, may include three types of data: metadata, transactions, and chaincode state.
  • Chaincode code may be considered part of chaincode state.
  • a pair of blockchain public key (BPK) and blockchain private key (BSK) may be used to protect the integrity of the persistent state.
  • BPK blockchain public key
  • BSK blockchain private key
  • the BPK may be used to verify the block state digests signed by the corresponding BSK.
  • the chain is append-only with any additions to the chain bound to previous portions of the chain using BSK-signed digests. If the BSK leaks, rogue or colluding members may be able to compromise the integrity of the blockchain, which is why, in some examples, the BSK is generated in and exclusively sealed within TEEs.
  • the metadata includes the BPK in plaintext for integrity verification.
  • confidentiality of any blockchain state that is not to be exposed in the clear is protected, using symmetric cryptography, with a blockchain master key (BMK).
  • the BMK may also be part of the blockchain metadata, in a protected way, because a quorum of members may need or want to decrypt and recover the blockchain data bypassing TEEs in case of emergency (e.g. disaster recovery after all TEEs are destroyed).
  • blockchains include ledgers that grow over time.
  • a blockchain ledger may grow too large to be stored in the TEE, and is stored to disk instead.
  • the BPK and BSK enable data to be stored on disk, and to verify, once the data is read back in, that the data hasn't been tampered with.
  • the BMK may be used to encrypt private data stored to disk, so that even when the data is stored on disk, the data cannot be seen.
  • One approach to protecting the BMK is to store in the blockchain metadata a copy of the BMK for each member that's encrypted to that member's KBK. This may prevent the BMK from leaking beyond the members. However, in some examples, it does not defend against a rogue or compromised member from leaking it.
  • COCO-based blockchains may use M of N encryption schemes to require that the KBKs of some threshold number of members must be known to obtain the BMK. VNs may then gain access as soon as they join with enough other VNs endorsed by that number of members, but, in some examples, no sooner. In some examples, since a member only has access to their own key outside of the TEE, it takes at least M members to leak or share their KBKs for the chain to be decrypted outside of a VN's TEE.
  • M can equal N, or even be 1
  • some examples of a COCO implementation require that M be at least 1 ⁇ 2N+1 and match the membership set agreement consensus model, which may ensure that so long as a majority set of members do not collude, the confidentiality of the blockchain's state is protected by the mutually trusted code that executes within TEEs. It may also ensure that so long as the network can establish a connection with VNs representing at least M+1 members, it can operate, thus ensuring resiliency even in the case when a member withdraws its VNs or its VNs are partitioned from the network.
  • an M of N scheme may be implemented as follows. Each member listed in the blockchain's membership metadata block is represented by the member's public key, as well as a fragment of the BMK encrypted to that public key, as shown in Table 1.
  • the first metadata membership block is created during network bootstrap, encrypting the BMK to the initial membership set.
  • COCO takes steps to adjust M and N by creating a new BMK, fragmenting it across the updated N set of members, and appending a new metadata block that includes both the previous BMK encrypted by the new BMK, as well as the updated membership list.
  • blockchain state up to the point of a membership update may be subject to compromise by a colluding set of the previous membership set according to the blockchain's implementation of M of N. But by creating a new BMK, all blockchain state from that point forward in the blockchain's timeline may be protected by the updated membership set, including an updated M of N scheme, if the blockchain implements one.
  • a signature, authentication code, or a unique identifier of the last addition to the chain can be stored in trusted non-volatile storage accessible only to the VNs.
  • the signature of the last addition to the blockchain may be included in all interactions with members to allow members to detect any attempts to roll back the blockchain to a previous state.
  • members roll over KBKs upon membership changes to protect against bugs in old code versions.
  • attestation, key exchange, or both is rerun after every membership version in certain circumstances, such as code version removal from the approval list of code.
  • COCO is adapted to a model that does not require each member to have dedicated VNs.
  • Shared VNs may be useful for development and/or testing, cost-conscious members, or as the basis for a multitenant hosted solution either by a cloud provider or by a member who acts as the hosting agent for other members.
  • all members rely upon a single VN (or set of VNs for high availability) hosted by a single centralized party.
  • all members may need to rely upon the centralized party to process transactions and to process membership updates, and unless blockchain state is streamed or exported, the centralized infrastructure may become a single point of failure for blockchain state.
  • the endorsement handler accepts member inputs as above, storing separate endorsement states per member inside the TEEs. In some examples, the endorsement handler only commits changes once quorum has been reached among the members participating in the shared VN.
  • COCO VNs trust their peers, enabling highly efficient, scalable and performant transaction processing across VNs.
  • TEE compromise can be reduced in several ways.
  • One way of reducing the likelihood of TEE compromise may be accomplished as follows.
  • Each VN is factored into two parts.
  • the manager TEE may be responsible for private key management, cryptographic processing, and membership update logic so that the amount of code required to implement the manager TEE is bounded, and that code need not vary with each blockchain integration. This code can then be formally verified and heavily audited to further minimize the risk of compromise.
  • the manager TEE is essentially a TEE-based hardware security module (HSM) responsible for the most trusted operations of the VN
  • the worker TEE is a separate enclave that hosts the blockchain protocol code.
  • the worker TEE may include a significantly larger codebase than the manager TEE, and the codebase of the worker TEE varies with each ledger that is integrated with COCO.
  • the worker TEE makes requests to the manager TEE for encryption, decryption, and signing of data using the VN's private keys such that if the worker TEE is compromised, an attacker could access any plaintext data that is loaded in memory by the worker TEE—but it could not directly access the keys, independently decrypt blocks on disk or propose or approve membership changes.
  • This example of two-TEE factoring reduces the likelihood of manager TEE compromise, and reduces the impact of a worker TEE compromise.
  • the network can also enforce a rule that VN authorization to participate in the network is a lease which must be periodically renewed.
  • the renewal process may require that the TEE is reset to a pristine state, and might eliminate any toehold that an attacker might be able to gain.
  • VNs that do not renew their lease may be quarantined from the network, and thus might prevent exposure of new data added to the blockchain after quarantine takes effect.
  • the encryption and authentication functions of the KBK may be split apart into two separate keys. This split may eliminate the need for the VNs to replicate the authentication private key. In some examples, only the encryption key needs to be replicated across VNs—which may eliminate global exposure of member authentication private keys upon manager TEE compromise.
  • VNs may sample transactions sent from other VNs and to fully validate the sample synchronously before commitment. This may ensure that a VN producing bogus results could be detected quickly to drive alerts without a major performance reduction. Similarly, a separate node may asynchronously validate all transactions, also driving alerts if any problems are detected.
  • a blockchain system leverage the properties of TEEs, and may serve as a foundation for blockchain implementations that support database-level transaction throughputs and latencies, as well as flexible confidentiality models.
  • many different blockchain protocols can take advantage of examples of the COCO framework to provide efficient transaction processing with blockchain and transaction confidentiality.
  • FIG. 11 is a diagram illustrating an example dataflow for a process ( 1190 ) for a blockchain system.
  • the process of FIG. 11 is performed by a validation node.
  • step 1191 occurs first.
  • a pre-determined type of blockchain protocol code and a pre-determined type of consensus code are stored in a trusted execution environment (TEE) of a processor.
  • TEE trusted execution environment
  • step 1192 occurs next in some examples.
  • TEE attestation is used to verify that the blockchain protocol code stored in the TEE is the pre-determined type of blockchain protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code.
  • step 1193 occurs next in some examples.
  • a request to alter the pre-determined type of blockchain protocol code may be received.
  • step 1194 occurs next in some examples.
  • a determination is made as to whether to change the pre-determined type of blockchain protocol code based on the pre-determined consensus code. The processing then proceeds to a return block, where other processing is resumed.

Abstract

The disclosed technology is generally directed to blockchain and other authentication technology. In one example of the technology, a pre-determined type of blockchain or other authentication protocol code and a pre-determined type of consensus code are stored in a trusted execution environment (TEE) of a processor. In some examples, TEE attestation is used to verify that the blockchain or other authentication protocol code stored in the TEE is the pre-determined type of blockchain or other authentication protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code. A request to alter the pre-determined type of blockchain or other authentication protocol code may be received. A determination may be made as to whether to change the pre-determined type of blockchain or other authentication protocol code based on the pre-determined consensus code.

Description

    CROSS-REFERENCE TO RELATED APPLICATION(S)
  • This application claims the benefit of U.S. Provisional Application No. 62/455,981, filed Feb. 7, 2017. The entirety of this afore-mentioned application is incorporated herein by reference.
  • BACKGROUND
  • Blockchain systems have been proposed for a variety of application scenarios, including applications in the financial industry, health care, IoT, and so forth. For example, the Bitcoin system was developed to allow electronic cash to be transferred directly from one party to another without going through a financial institution. A bitcoin (e.g., an electronic coin) is represented by a chain of transactions that transfers ownership from one party to another party. To transfer ownership of a bitcoin, a new transaction may be generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, may be digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner public key.
  • Once the block is full, the block may be “capped” with a block header that is a hash digest of all the transaction identifiers within the block. The block header may be recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a “blockchain.” To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction. The new owner need only have the private key that matches the public key of the transaction that transferred the bitcoin. The blockchain may create a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which in the case of the bitcoin system is pseudo-anonymous.
  • SUMMARY OF THE DISCLOSURE
  • This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
  • Briefly stated, the disclosed technology is generally directed to blockchain and other authentication technology. In one example of the technology, a pre-determined type of blockchain or other authentication protocol code and a pre-determined type of consensus code are stored in a trusted execution environment (TEE) of a processor. In some examples, TEE attestation is used to verify that the blockchain or other authentication protocol code stored in the TEE is the pre-determined type of blockchain or other authentication protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code. A request to alter the pre-determined type of blockchain or other authentication protocol code may be received. A determination may be made as to whether to change the pre-determined type of blockchain or other authentication protocol code based on the pre-determined consensus code.
  • In some examples, prospective members of a blockchain consortium agree upon certain aspects of a consortium blockchain network before establishing the network, including, for example, the blockchain protocol code to be used, the consensus protocol to be used, the initial membership list, and possibly also many other aspects of the blockchain network. At least one of the prospective members may endorse a validation node (VN). Upon verification that certain agreed-upon aspects by all of the members are the same, such as the blockchain protocol to be used and consensus protocol to be used, TEE attestation may be used to verify that each of the nodes store the agreed-upon blockchain network protocol and the agreed-upon consensus protocol.
  • If the TEE attestation is successful, the consortium network may then be bootstrapped, and private keys may be exchanged, with all of the prospective members now members of the consortium network. A blockchain master key may be generated from the private keys of the members. In some examples, participants of the network may then be approved to join by the members. In some examples, at this point, the network is established and is ready to receive transactions.
  • In some examples, a participant of a blockchain network may submit a transaction to the blockchain network. The transaction may be forwarded to a VN in the blockchain network that is selected based on the agreed-upon consensus protocol. The selected VN may then process the transaction by executing the code of the transaction, and may then resolve any conflicts. The VN may then directly update the official state of the processed blockchain based on the processing of the blockchain transaction. The VN may then broadcast the updated official state of the processed blockchain to the blockchain network.
  • Other aspects of and applications for the disclosed technology will be appreciated upon reading and understanding the attached figures and description.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Non-limiting and non-exhaustive examples of the present disclosure are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified. These drawings are not necessarily drawn to scale.
  • For a better understanding of the present disclosure, reference will be made to the following Detailed Description, which is to be read in association with the accompanying drawings, in which:
  • FIG. 1 is a block diagram illustrating one example of a suitable environment in which aspects of the technology may be employed;
  • FIG. 2 is a block diagram illustrating one example of a suitable computing device according to aspects of the disclosed technology;
  • FIG. 3 is a block diagram illustrating an example of a system;
  • FIG. 4 is a block diagram illustrating an example of a validation node;
  • FIGS. 5A-5C are a diagram illustrating an example dataflow for a process for establishing a blockchain network;
  • FIGS. 6A-6B are a diagram illustrating an example dataflow for a process for transaction processing for a blockchain network;
  • FIG. 7 is a diagram illustrating another example process for transaction processing for a blockchain network;
  • FIG. 8 is a block diagram illustrating an example of a system including a Confidential Consortium Blockchain Framework (COCO) network with three members;
  • FIG. 9 is a block diagram illustrating an example of system that includes a portion of a COCO network including two validation nodes undergoing validation node attestation and key exchange;
  • FIG. 10 is a diagram illustrating example steps for adding a new member to a COCO network; and
  • FIG. 11 is a diagram illustrating an example dataflow for a process for a blockchain system, in accordance with aspects of the present disclosure.
  • DETAILED DESCRIPTION
  • The following description provides specific details for a thorough understanding of, and enabling description for, various examples of the technology. One skilled in the art will understand that the technology may be practiced without many of these details. In some instances, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of examples of the technology. It is intended that the terminology used in this disclosure be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain examples of the technology. Although certain terms may be emphasized below, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section. Throughout the specification and claims, the following terms take at least the meanings explicitly associated herein, unless the context dictates otherwise. The meanings identified below do not necessarily limit the terms, but merely provide illustrative examples for the terms. For example, each of the terms “based on” and “based upon” is not exclusive, and is equivalent to the term “based, at least in part, on”, and includes the option of being based on additional factors, some of which may not be described herein. As another example, the term “via” is not exclusive, and is equivalent to the term “via, at least in part”, and includes the option of being via additional factors, some of which may not be described herein. The meaning of “in” includes “in” and “on.” The phrase “in one embodiment,” or “in one example,” as used herein does not necessarily refer to the same embodiment or example, although it may. Use of particular textual numeric designators does not imply the existence of lesser-valued numerical designators. For example, reciting “a widget selected from the group consisting of a third foo and a fourth bar” would not itself imply that there are at least three foo, nor that there are at least four bar, elements. References in the singular are made merely for clarity of reading and include plural references unless plural references are specifically excluded. The term “or” is an inclusive “or” operator unless specifically indicated otherwise. For example, the phrases “A or B” means “A, B, or A and B.” As used herein, the terms “component” and “system” are intended to encompass hardware, software, or various combinations of hardware and software. Thus, for example, a system or component may be a process, a process executing on a computing device, the computing device, or a portion thereof.
  • Briefly stated, the disclosed technology is generally directed to blockchain and other authentication technology. In one example of the technology, a pre-determined type of blockchain or other authentication protocol code and a pre-determined type of consensus code are stored in a trusted execution environment (TEE) of a processor. In some examples, TEE attestation is used to verify that the blockchain or other authentication protocol code stored in the TEE is the pre-determined type of blockchain or other authentication protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code. A request to alter the pre-determined type of blockchain or other authentication protocol code may be received. A determination may be made as to whether to change the pre-determined type of blockchain or other authentication protocol code based on the pre-determined consensus code.
  • In some examples, prospective members of a blockchain consortium agree upon certain aspects of a consortium blockchain network before establishing the network, including, for example, the blockchain protocol code to be used, the consensus protocol to be used, the initial membership list, and possibly also many other aspects of the blockchain network. At least one of the prospective members may endorse a validation node (VN). Upon verification that certain agreed-upon aspects by all of the members are the same, such as the blockchain protocol to be used and consensus protocol to be used, TEE attestation may be used to verify that each of the nodes store the agreed-upon blockchain network protocol and the agreed-upon consensus protocol.
  • If the TEE attestation is successful, the consortium network may then be bootstrapped, and private keys may be exchanged, with all of the prospective members now members of the consortium network. A blockchain master key may be generated from the private keys of the members. In some examples, participants of the network may then be approved to join by the members. In some examples, at this point, the network is established and is ready to receive transactions.
  • In some examples, a participant of a blockchain network may submit a transaction to the blockchain network. The transaction may be forwarded to a VN in the blockchain network that is selected based on the agreed-upon consensus protocol. The selected VN may then process the transaction by executing the code of the transaction, and may then resolve any conflicts. The VN may then directly update the official state of the processed blockchain based on the processing of the blockchain transaction. The VN may then broadcast the updated official state of the processed blockchain to the blockchain network.
  • Illustrative Devices/Operating Environments
  • FIG. 1 is a diagram of environment 100 in which aspects of the technology may be practiced. As shown, environment 100 includes computing devices 110, as well as network nodes 120, connected via network 130. Even though particular components of environment 100 are shown in FIG. 1, in other examples, environment 100 can also include additional and/or different components. For example, in certain examples, the environment 100 can also include network storage devices, maintenance managers, and/or other suitable components (not shown). Computing devices 110 shown in FIG. 1 may be in various locations, including on premise, in the cloud, or the like. For example, computer devices 110 may be on the client side, on the server side, or the like.
  • As shown in FIG. 1, network 130 can include one or more network nodes 120 that interconnect multiple computing devices 110, and connect computing devices 110 to external network 140, e.g., the Internet or an intranet. For example, network nodes 120 may include switches, routers, hubs, network controllers, or other network elements. In certain examples, computing devices 110 can be organized into racks, action zones, groups, sets, or other suitable divisions. For example, in the illustrated example, computing devices 110 are grouped into three host sets identified individually as first, second, and third host sets 112 a-112 c. In the illustrated example, each of host sets 112 a-112 c is operatively coupled to a corresponding network node 120 a-120 c, respectively, which are commonly referred to as “top-of-rack” or “TOR” network nodes. TOR network nodes 120 a-120 c can then be operatively coupled to additional network nodes 120 to form a computer network in a hierarchical, flat, mesh, or other suitable types of topology that allows communications between computing devices 110 and external network 140. In other examples, multiple host sets 112 a-112 c may share a single network node 120. Computing devices no may be virtually any type of general- or specific-purpose computing device. For example, these computing devices may be user devices such as desktop computers, laptop computers, tablet computers, display devices, cameras, printers, or smartphones. However, in a data center environment, these computing devices may be server devices such as application server computers, virtual computing host computers, or file server computers. Moreover, computing devices 110 may be individually configured to provide computing, storage, and/or other suitable computing services.
  • Illustrative Computing Device
  • FIG. 2 is a diagram illustrating one example of computing device 200 in which aspects of the technology may be practiced. Computing device 200 may be virtually any type of general- or specific-purpose computing device. For example, computing device 200 may be a user device such as a desktop computer, a laptop computer, a tablet computer, a display device, a camera, a printer, embedded device, programmable logic controller (PLC), or a smartphone. Likewise, computing device 200 may also be server device such as an application server computer, a virtual computing host computer, or a file server computer, e.g., computing device 200 may be an example of computing device 110 or network node 120 of FIG. 1. Computing device 200 may also be an IoT device that connects to a network to receive IoT services. Likewise, computer device 200 may be an example any of the devices, nodes, members, or other entities illustrated in or referred to in various figures, as discussed in greater detail below. As illustrated in FIG. 2, computing device 200 includes processing circuit 210, operating memory 220, memory controller 230, data storage memory 250, input interface 260, output interface 270, and network adapter 280. Each of these afore-listed components of computing device 200 includes at least one hardware element.
  • Computing device 200 includes at least one processing circuit 210 configured to execute instructions, such as instructions for implementing the herein-described workloads, processes, or technology. Processing circuit 210 may include a microprocessor, a microcontroller, a graphics processor, a coprocessor, a field-programmable gate array, a programmable logic device, a signal processor, or any other circuit suitable for processing data. The aforementioned instructions, along with other data (e.g., datasets, metadata, operating system instructions, etc.), may be stored in operating memory 220 during run-time of computing device 200. Operating memory 220 may also include any of a variety of data storage devices/components, such as volatile memories, semi-volatile memories, random access memories, static memories, caches, buffers, or other media used to store run-time information. In one example, operating memory 220 does not retain information when computing device 200 is powered off. Rather, computing device 200 may be configured to transfer instructions from a non-volatile data storage component (e.g., data storage component 250) to operating memory 220 as part of a booting or other loading process.
  • Operating memory 220 may include 4th generation double data rate (DDR4) memory, 3rd generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), High Bandwidth Memory (HBM), Hybrid Memory Cube memory, 3D-stacked memory, static random access memory (SRAM), or other memory, and such memory may comprise one or more memory circuits integrated onto a DIMM, SIMM, SODIMM, or other packaging. Such operating memory modules or devices may be organized according to channels, ranks, and banks. For example, operating memory devices may be coupled to processing circuit 210 via memory controller 230 in channels. One example of computing device 200 may include one or two DIMMs per channel, with one or two ranks per channel. Operating memory within a rank may operate with a shared clock, and shared address and command bus. Also, an operating memory device may be organized into several banks where a bank can be thought of as an array addressed by row and column. Based on such an organization of operating memory, physical addresses within the operating memory may be referred to by a tuple of channel, rank, bank, row, and column.
  • Despite the above-discussion, operating memory 220 specifically does not include or encompass communications media, any communications medium, or any signals per se.
  • Memory controller 230 is configured to interface processing circuit 210 to operating memory 220. For example, memory controller 230 may be configured to interface commands, addresses, and data between operating memory 220 and processing circuit 210. Memory controller 230 may also be configured to abstract or otherwise manage certain aspects of memory management from or for processing circuit 210. Although memory controller 230 is illustrated as single memory controller separate from processing circuit 210, in other examples, multiple memory controllers may be employed, memory controller(s) may be integrated with operating memory 220, or the like. Further, memory controller(s) may be integrated into processing circuit 210. These and other variations are possible.
  • In computing device 200, data storage memory 250, input interface 260, output interface 270, and network adapter 280 are interfaced to processing circuit 210 by bus 240. Although, FIG. 2 illustrates bus 240 as a single passive bus, other configurations, such as a collection of buses, a collection of point to point links, an input/output controller, a bridge, other interface circuitry, or any collection thereof may also be suitably employed for interfacing data storage memory 250, input interface 260, output interface 270, or network adapter 280 to processing circuit 210.
  • In computing device 200, data storage memory 250 is employed for long-term non-volatile data storage. Data storage memory 250 may include any of a variety of non-volatile data storage devices/components, such as non-volatile memories, disks, disk drives, hard drives, solid-state drives, or any other media that can be used for the non-volatile storage of information. However, data storage memory 250 specifically does not include or encompass communications media, any communications medium, or any signals per se. In contrast to operating memory 220, data storage memory 250 is employed by computing device 200 for non-volatile long-term data storage, instead of for run-time data storage.
  • Also, computing device 200 may include or be coupled to any type of processor-readable media such as processor-readable storage media (e.g., operating memory 220 and data storage memory 250) and communication media (e.g., communication signals and radio waves). While the term processor-readable storage media includes operating memory 220 and data storage memory 250, the term “processor-readable storage media,” throughout the specification and the claims whether used in the singular or the plural, is defined herein so that the term “processor-readable storage media” specifically excludes and does not encompass communications media, any communications medium, or any signals per se. However, the term “processor-readable storage media” does encompass processor cache, Random Access Memory (RAM), register memory, and/or the like.
  • Computing device 200 also includes input interface 260, which may be configured to enable computing device 200 to receive input from users or from other devices. In addition, computing device 200 includes output interface 270, which may be configured to provide output from computing device 200. In one example, output interface 270 includes a frame buffer, graphics processor, graphics processor or accelerator, and is configured to render displays for presentation on a separate visual display device (such as a monitor, projector, virtual computing client computer, etc.). In another example, output interface 270 includes a visual display device and is configured to render and present displays for viewing.
  • In the illustrated example, computing device 200 is configured to communicate with other computing devices or entities via network adapter 280. Network adapter 280 may include a wired network adapter, e.g., an Ethernet adapter, a Token Ring adapter, or a Digital Subscriber Line (DSL) adapter. Network adapter 280 may also include a wireless network adapter, for example, a Wi-Fi adapter, a Bluetooth adapter, a ZigBee adapter, a Long Term Evolution (LTE) adapter, or a 5G adapter.
  • Although computing device 200 is illustrated with certain components configured in a particular arrangement, these components and arrangements are merely one example of a computing device in which the technology may be employed. In other examples, data storage memory 250, input interface 260, output interface 270, or network adapter 280 may be directly coupled to processing circuit 210, or be coupled to processing circuit 210 via an input/output controller, a bridge, or other interface circuitry. Other variations of the technology are possible.
  • Some examples of computing device 200 include at least one memory (e.g., operating memory 220) adapted to store run-time data and at least one processor (e.g., processing unit 210) that is respectively adapted to execute processor-executable code that, in response to execution, enables computing device 200 to perform actions.
  • Illustrative Systems
  • FIG. 3 is a block diagram illustrating an example of a system (300) for a blockchain consortium. System 300 may include network 330, VNs 351-353, member devices 341-343, and participant devices 311-313. Each VN 351-353 includes a corresponding TEE 361-363.
  • Each of the member devices 341-343, participant devices 311-313, and/or VNs 351-353 may include examples of computing device 200 of FIG. 2. FIG. 3 and the corresponding description of FIG. 3 in the specification illustrates an example system for illustrative purposes that does not limit the scope of the disclosure.
  • Network 330 may include one or more computer networks, including wired and/or wireless networks, where each network may be, for example, a wireless network, local area network (LAN), a wide-area network (WAN), and/or a global network such as the Internet. On an interconnected set of LANs, including those based on differing architectures and protocols, a router acts as a link between LANs, enabling messages to be sent from one to another. Also, communication links within LANs typically include twisted wire pair or coaxial cable, while communication links between networks may utilize analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communications links known to those skilled in the art. Furthermore, remote computers and other related electronic devices could be remotely connected to either LANs or WANs via a modem and temporary telephone link. Network 330 may include various other networks such as one or more networks using local network protocols such as 6LoWPAN, ZigBee, or the like. Some IoT devices may be connected to a user device via a different network in network 330 than other IoT devices. In essence, network 330 includes any communication method by which information may travel between VNs 351-353, member devices 341-343, and participant devices 311-313. Although each device or service is shown connected as connected to network 330, that does not mean that each device communicates with each other device shown. In some examples, some devices/services shown only communicate with some other devices/services shown via one or more intermediary devices. Also, although network 330 is illustrated as one network, in some examples, network 330 may instead include multiple networks that may or may not be connected with each other, with some of the devices shown communicating with each other through one network of the multiple networks and other of the devices shown communicating with each other with a different network of the multiple networks.
  • In some examples, member devices 341-343 are devices used by members to communicate over network 330, such as for communication between a member and its corresponding VN, for example to endorse a VN. In some examples, participant devices 311-313 are devices used by members to communicate over network 330, such as to request a transaction.
  • In some examples, VNs 351-353 are devices that, during normal operation, validate and process submitted blockchain transactions, and execute chaincode. As mentioned above, in some examples, each VN 351-353 includes a TEE. In some examples, the TEE enables the creation of a protected region inside of a processor, so that the memory in the protected region is encrypted, and only decrypted inside the TEE. A TEE may be interchangeably referred to as an enclave, or, in some examples, the TEE can be seen as a subset of the enclave. TEE attestation can be used to verify the code running in the TEE. In some examples, the TEE allows integrity of the calculations occurring inside the TEE and confidentiality of what happens inside the TEE.
  • Some examples of a TEE are based on hardware, and others are based on software. Examples of a hardware-based TEE use hardware-based protection of a memory range that defines the address range of the TEE. In some examples, writes to the TEE are encrypted. In some examples, the CPU does not allow anything outside of the address range of the TEE to see that address range in clear text, and writes from outside of the address range area not permitted in the address range of the TEE.
  • In some examples, prior to a consortium blockchain network being established, certain details are agreed upon by prospective members of the blockchain network, including which blockchain protocol code and which consensus protocol code are to be executed in the TEE of each validation node of the consortium blockchain network. During the establishment of the consortium blockchain network, one or more validation node is endorsed by one of more members of the consortium blockchain network. Also, TEE attestation may be used to verify that each validation node is executing the agreed-upon blockchain protocol code and the agreed-upon consensus protocol code. After the consortium blockchain network is established, in some examples, it is possible to change the initially agreed-upon parameters, such as the agreed-upon blockchain protocol code to be run in the TEE—in some examples, such a change is determined based on the consensus protocol, M-of-N voting, and/or the like, as explained in greater detail below.
  • System 300 may include more or less devices than illustrated in FIG. 3, which is shown by way of example only.
  • FIG. 4 is a block diagram illustrating an example of VN 451, which may communicate with, e.g., participant 411 and/or endorser 441. VN 451 may include TEE 461, blockchain service 471, and disk storage 472. TEE 461 may include blockchain protocol 465, Confidential Consortium (COCO) Blockchain application programming interface (API) 466, and COCO core 467.
  • Blockchain service 471 may include software that performs functions for maintaining the availability and durability of the blockchain system. Disk storage 472 may, for example, include encrypted blockchain data and metadata when there is insufficient storage available in the TEE to store all of the data, or in other suitable situations. Blockchain protocol 465 may include the agreed-upon blockchain protocol code. In some examples, COCO core is the core COCO framework code, which is explained in greater detail below. In some examples, COCO API 466 is the API for the COCO framework.
  • VN 451 may communicate over a network with other VNs, one or more participant, and/or one or more endorser, including, for example, participant 411 and endorser 441, where endorser 441 is a member that endorses VN 451.
  • In some examples, everything in the VN outside of the TEE is modeled as untrusted. In some examples, the portions of the VN outside of the TEE function to maintain availability and durability of the system. In some examples, there is an SSL, TLS, or other secure tunnel between the participant or endorser and the TEE for secure communications, with the elements in the VN outside of the TEE being a pass-through for the secure communications.
  • In some examples, the lifecycle of the blockchain protocol in the TEE is governed by the software running inside of the TEE, based on the members' instructions, and later based on the decision of the consortium (e.g., quorum) as a whole, as discussed in greater detail below.
  • As discussed in greater detail below, although not shown in FIG. 4, in some examples, the TEE is split into two separate protected regions, one with the blockchain API, and the other one running the blockchain protocol, with a secure connection between them.
  • Illustrative Processes
  • For clarity, the processes described herein are described in terms of operations performed in particular sequences by particular devices or components of a system. However, it is noted that other processes are not limited to the stated sequences, devices, or components. For example, certain acts may be performed in different sequences, in parallel, omitted, or may be supplemented by additional acts or features, whether or not such sequences, parallelisms, acts, or features are described herein. Likewise, any of the technology described in this disclosure may be incorporated into the described processes or other processes, whether or not that technology is specifically described in conjunction with a process. The disclosed processes may also be performed on or by other devices, components, or systems, whether or not such devices, components, or systems are described herein. These processes may also be embodied in a variety of ways. For example, they may be embodied on an article of manufacture, e.g., as processor-readable instructions stored in a processor-readable storage medium or be performed as a computer-implemented process. As an alternate example, these processes may be encoded as processor-executable instructions and transmitted via a communications medium.
  • FIGS. 5A-5C are a diagram illustrating an example dataflow for a process (520) for establishing a consortium blockchain network.
  • In the illustrated example, step 521 occurs first. At step 521, in some examples, prospective members of a blockchain consortium agree upon certain aspects of a consortium blockchain network before establishing the network. In some examples, the agreed-upon aspects may include one or more of the following: who the initial members will be, what code is approved to execute in a TEE of the VNs of the network (including blockchain protocol code and consensus protocol code), what processor(s) is acceptable in the VNs of the network, what constitutes an accepted TEE, what software versions of blockchain code will be executed, and/or the like.
  • As shown, step 522 occurs next in some examples. At step 522, in some examples, each prospective member endorses at least one separate VN. In some examples, as part of the validation, the prospective member stores the agreed-upon code in the TEE, and stores the public/private key pair (PBK and KBK respectively) in the TEE. Some of the agreed-upon aspects may also be stored in the VN, such as the agreed-upon membership list and an identification of the agreed-upon code to execute in the TEE.
  • In some examples, step 522 may be performed in a different manner than described above. For instance, in some example, not every prospective member endorses a separate VN. For instance, in some examples, only one VN is endorsed.
  • As shown, step 523 occurs next in some examples. At step 523, each VN discovers the other VNs in the network. In some examples, there is only one VN, and step 523 is not performed.
  • As shown, step 524 occurs next in some examples. At step 524, in some examples, from each of the prospective members of the consortium, the following are received: a plurality of membership lists, and a plurality of authorizations from the plurality of prospective members of the consortium. In some examples, the authorizations are indications associated with a pre-determined type of blockchain protocol code and a pre-determined type of consensus protocol code. In some examples, the membership lists and authorizations are sent by each of the VNs and each VN receives the memberships lists and authorizations sent by each other VN. In other examples, there is only one VN, and the memberships lists and authorizations are received from the member devices of the prospective members.
  • As shown, decision block 525 occurs next in some examples. At decision block 525, in some examples, a determination is made as to whether the membership lists from each of the prospective members match each other. If not, in some examples, the process proceeds to a return block, where other processing is resumed. If, however, the determination at decision block 525 is positive, in some examples, the process moves to decision block 526.
  • At decision block 526, in some examples, a determination is made as to whether the authorizations of the type of blockchain protocol code and consensus protocol code from each of the prospective members match each other. If not, in some examples, the process proceeds to a return block, where other processing is resumed. If, however, in some examples, the determination at decision block 526 is positive, the process moves to decision block 527.
  • At decision block 527 TEE attestation may be used to verify that nodes associated with prospective members of the consortium stores the agreed-upon authorized blockchain protocol code and consensus protocol code to be run on the TEE. If the TEE attestation is negative, in some examples, the process moves to the return block. Otherwise, in some examples, the process advances to block 528.
  • At block 528, private keys may be exchanged among the VNs. As shown, block 529 occurs next in some examples. At block 529, a blockchain master key (BMK) may be generated from each of the private keys. As shown, decision block 530 occurs next in some examples. At block 530, in some examples, participants are approved to join by members. In some examples, participants are allowed to request transactions and to see transactions that they are authorized to see, but do not have other rights of members, such as voting rights to vote on changing membership, change the protocol blockchain code used, or the like. In some examples, the network is now ready to process transactions from participants. The process may then proceed to the return block.
  • In some examples, a public network may allow any participant to submit transactions, but a non-public network requires participants to be provisioned, which is another privilege of a VN's endorser. Participants may be represented by a public/private key pair that's allowed to submit transactions for execution by the network. The set of participants does not necessarily include the members, though in some examples it does. Members may authorize participants by submitting to their VN the public transaction key(PTK) of a participant, and VNs may share, with the network, the list of their provisioned participants. If a network requires participants to be approved by more than one member, the network may use a protocol similar to that of approving a new member, as discussed in greater detail below.
  • Once the consortium blockchain network is established, the consortium blockchain network may begin receiving and processing transactions.
  • FIGS. 6A-6B are a diagram illustrating an example dataflow for a process (620) for transaction processing for a consortium blockchain network.
  • In the illustrated example, step 621 occurs first. At step 621, in some examples, a participant encrypts a blockchain transaction with the blockchain master key. As shown, step 622 occurs next. At step 622, in some examples, the participant transmits the encrypted blockchain transaction. As shown, step 623 occurs next in some examples. At step 623, the encrypted blockchain transaction may be forwarded to a particular VN that is selected based on the agreed-upon consensus protocol code.
  • For instance, in some examples, a consensus algorithm may be used to elect a VN leader, and the VN leader receives transactions, commits transactions, and broadcasts the transactions to all of the other members. (The VN leader is interchangeably referred to herein as the master VN.) In these examples, at step 623, the consensus algorithm is used to elect the VN leader, and the encrypted blockchain transaction is forwarded to the VN leader.
  • As shown, step 624 occurs next in some examples. At step 624, in some examples, the VN to which the encrypted transaction was forwarded receives the encrypted blockchain transaction. As shown, step 625 occurs next in some examples. At block 625, in some examples, the VN processes the blockchain transaction by executing the code of the transaction.
  • As shown, step 626 occurs next in some examples. At block 626, in some examples, the VN directly updates the official state of the processed blockchain based on the processing of the blockchain transaction. As shown, step 627 occurs next in some examples. “Directly” updating the state means that the VN updates the state without any actions or confirmation being required by any other entity in order to update the state. At step 627, the updated official state of the processed blockchain may be broadcast to the blockchain network.
  • In some examples, because of the trust, VNs do not do re-computation for verification, which makes it possible for blockchain states to be directly updated at step 626. In some examples, because the VNs in the blockchain consortium network are fully trusted, other VNs on the network can implicitly accept any blockchain state updates it receives from a trusted VN as being compliant with the blockchain's protocol and protected from external tampering by the TEE. Further, in some examples, there is no need for a copy of the transaction in order to confirm a block.
  • The process may then proceed to a return block, where other processing is resumed.
  • In some examples, chaincode need not be executed more than once by the network, chaincode may be non-deterministic, and chaincode may include interactions with external systems. In some examples, blockchains may also be constructed with varying levels of defense against hostile participants attempting to compromise integrity and confidentiality, from protection against a single rogue member, to M of N voting, to requiring all members to agree on state changes. The network may accommodate arbitrary blockchain abstractions, arbitrary blockchain protocols, and arbitrary ledgers, and may be able to integrate existing blockchain technologies of any type. Herein, with regard to M of N voting, N refers to the total number of members, and M refers to the number of members for establishing a quorum in a vote.
  • Examples of the network may enable improving the performance characteristics of blockchains without changing the trust assumptions between the members. Examples of the network may allow for data to remain private when put onto a blockchain so that only relevant parties can see a transaction. Examples of the network may enable code that runs inside of a blockchain to be non-deterministic, so that, for example, a different result may be produced every time. Examples of the network may achieve such results without introducing unneeded complexity, introducing additional significant performance overheads, or introducing an unnatural trust assumption.
  • Examples of the network make TEE Attestation in VNs of the network so that the code inside of the TEE can have the trust accepting that the operating system and the other user-mode code around the TEE in the operating environment of the TEE is completely untrusted, and yet the TEE can still operate in a trusted way by relying on the hardware-enforced privacy (e.g., by leveraging or otherwise employing Software Guard Extensions, a Platform Security Processor, a Secure Execution Environment, or the like) and the TEE can project the trust externally by establishing a secure connection to some endpoint outside of the TEE. In some examples, this allows integrity of the calculations occurring inside the TEE and confidentiality of what happens inside the TEE. Examples of the network use the trust associated with the TEE as the building block of trust assumptions in the blockchain system.
  • In some examples, each VN in the network is fully trusted by the network by virtue of the fact that other VNs can verify the endorsement of a VN by its endorsing member, and using TEE attestation that the VN is executing code approved by the membership. As previously discussed, VNs may establish trusted connections with each other through a similar process to endorsement where, after a VN attests to the fact that the VN's code is a trusted version running in a trusted TEE, as well as to the fact that it has the same membership list, other VNs release the KBK of their endorsing member. In some examples, the output of one node that is provided as input from another node can be trusted because the code that generated the output is proven to be trusted code previously approved by the membership. In some examples, all the contents of the blockchain are encrypted, and the contents of the blockchain are only decrypted inside of a TEE with a valid attestation, which enables confidentiality. Also, the code in a TEE with valid attestation can be non-deterministic—since the TEE is trusted, there is no need for other nodes to reproduce the results of other nodes in such examples.
  • In some examples, the VNs operate according to a Confidential Consortium Blockchain Framework (COCO) framework, which allows any suitable blockchain protocol to be used, and allows any suitable consensus protocol to be used in conjunction with the COCO framework. Despite the word “confidential” in COCO, some examples of the COCO framework include confidentiality, and some examples of the COCO framework do not include confidentiality. In some examples, the COCO framework is not used by itself, but in conjunction with, for example, a blockchain protocol and a consensus protocol selected by the membership. In some examples, the COCO framework is the code operating in the VN that is used for establishing the blockchain network, enabling arbitrary blockchain and consensus protocols, arbitrary blockchain ledgers, arbitrary blockchain abstractions, and the use of any suitable blockchain technology. In some examples, most of the COCO code is executed in the TEE, but some peripheral aspects of COCO may execute outside of the TEE, as discussed in greater detail below. In some examples, the COCO framework does not itself define blockchain ledgers and the actual blockchain transaction processing, but allows any suitable ledgers and blockchain protocols to be used, and enables confidential properties for the transactions, governs trust assumptions, allows chaincode to be executed only once by the network, allows the chaincode to be non-deterministic, and allows chaincode to include interactions with external systems. The COCO framework may also include varying levels of defense against hostile participants attempting to compromise integrity and confidentiality, from protection against a single rogue member, to “M of N” voting, to requiring all members to agree on state changes. A network of VNs that operate according to a COCO framework being executed on each of the VNs may be referred to as a COCO network.
  • As discussed above, in some examples, the members initially agree on certain approvals, including, for example, who the members will be, what code is approved to execute in a TEE, what processor(s) are acceptable, what constitutes an accepted TEE, what COCO framework to use, what software versions of blockchain code will be executed, and each member starts at least one VN. In some examples, each member maintains at least one VN, each of which participates in the blockchain network's transaction processing and consensus protocol. In other examples, each member does not necessarily maintain its own VN.
  • In some examples, certain initial approvals require unanimous agreement in order for the network to be established, and other of the approvals may only require agreement among a quorum of prospective members, or the initial approval may be determined based on the consensus protocol in the consensus protocol code.
  • In some examples, during normal operation, VNs validate and process submitted transactions, and execute chaincode. A member may deploy a version of the blockchain protocol implementation that they trust to a Trusted Execution Environment (TEE), and once the blockchain code attests to the fact that it is code that the member trusts and that it's executing in a TEE also trusted by the member, the member endorses the VN by provisioning it with their public and private blockchain keys (PBK and KBK, respectively). In some examples, the owner of a VN is considered its endorser, and the endorser can update the membership list the VN trusts by submitting the public blockchain signing keys of the members.
  • In some examples, consensus is required for membership and protocol updates, as well as updates to blockchain and chaincode state. In some examples, as discussed above, the consensus protocol used is one of the agreed-upon parameters for establishing the network. In some examples, every VN fully trusts every other with which it has established a trusted connection. Accordingly, in some examples, so long as blockchain updates are non-conflicting with the existing state maintained by a VN, it can be unequivocally accepted; in these examples, it's only when there's potential for conflicting updates that an explicit consensus protocol is required. There are several ways that the network can implement consensus in various examples, but in some examples, the network does not require wasteful proof-of-work, latency-causing time-bound, or potentially unfair proof-of-stake algorithms.
  • In some examples, consensus relies on Paxos or one of the many Paxos-like consensus algorithms, which is practical when the network consists of a relatively small number of consensus participants. In some examples, the blockchain code executing in the TEE implements consensus, and because the code is trusted, there is no need to defend against byzantine faults such as malicious messages. In some examples, Paxos is allowed to set to grow to accommodate at least one VN of each member, though in some examples more than one is not included so as to keep the consensus participant set small for maximum efficiency. In some examples, Paxos-type consensus is used to implement high-availability for centralized databases, so example small networks can use this to achieve database-level throughput and latency. This approach may ensure that there's one version of the blockchain state that's agreed upon by the network's majority.
  • FIG. 7 is a diagram illustrating an example dataflow for a process (760) for blockchain transaction processing.
  • First, a participant may submit a transaction. In some examples, the transaction is encrypted with the BMK.
  • In some examples, any VN in the network may accept and process transactions, and the agreed-upon consensus protocol is used. In some examples, a received transaction is forwarded to the VN acting as a master based on the consensus protocol. In this example, the master VN then receives the transaction.
  • Next, the VN which is to process the transaction, according to the agreed-upon consensus protocol, may process the transaction by executing the code of the transaction. In some examples, the master VN then resolves any conflicts. In some examples, all the data inside of TEE is in plain text. In some examples, data outside of TEE (disk/network) is signed by BSK and encrypted by BMK. In some examples, each VN stores a full copy of the ledger, the data inside the TEE is in plain text, and data outside of the TEE, such as data on disk or being communicated over the network, is signed by the BSK and encrypted by the BMK.
  • In other examples, each VN need not store a copy of the ledger. In other examples, the ledger can be stored in an external storage cloud service or in an on-premises storage array.
  • Next, the VN may broadcast the transaction and the state of the transaction to the other VNs. Next, the VN may directly update the blockchain state. In some examples, because of the trust, VNs do not need to do re-computation for verification, and blockchain states are directly updated.
  • FIG. 8 is a block diagram illustrating an example of a system including an example COCO network (800) with three members and three corresponding VNs. FIG. 8 shows an example COCO network where three VNs have been provisioned, each by a different member.
  • The public key for member i is depicted as PBKmi, and its private key KBKmi. The VNs in the example of FIG. 8 have established trusted connections and shared these keys.
  • In some examples, once the trusted network is established with a majority of members represented by VNs, a foundation is in place on which blockchain protocols can be implemented that employ efficient consensus algorithms, where a single VN can act on behalf of the entire network such that other nodes accept the transactions, including chaincode transactions, knowing that they conform to the rules of the blockchain.
  • In some examples, VNs can also unilaterally, or by a voting scheme, approve participants, including themselves. In some examples, a participant has no network voting privileges, but by virtue of the network being provisioned with their public transaction keys (PTKs), can submit transactions.
  • By leveraging the network's trust, a VN's blockchain protocol code may accept transactions from other VNs knowing that they adhere to the blockchain protocol rules, and commit any that do not conflict with any already committed transactions. In some examples, if a transaction conflicts with another uncommitted transaction, the VN uses a consensus protocol to determine which transaction wins, and the majority of the VNs will quickly converge on the winning transactions. Further, because a VN's execution may be protected by a TEE from outside inspection, it may implement arbitrary confidentiality models, including only allowing the members that are participants in a transaction to see the transaction.
  • In some examples, VNs protect the integrity of externally stored blockchain state by using a pair of blockchain public key and private key (BPK and BSK), and optionally its confidentiality by using a blockchain master key (BMK) derived from a set of KBKs of the members. In some examples, KBKs are shared across the VNs of a network for this reason. In some examples, BMKs are specific to a membership set, and a flexible M of N scheme protects BMKs from compromise by fewer than M colluding members. In some examples, when the membership set updates, the network generates a new BMK to protect all subsequently appended states.
  • Various examples above discuss the establishment of a consortium blockchain network and transaction processing in a consortium blockchain network. In some examples, one, some or all of initially agreed-upon parameters such as the membership, blockchain protocol code, consensus protocol code, COCO framework, processor, TEE, and other parameters may be changed, based on the consensus protocol code. For instance, in some examples, a request may be made to the validation nodes, to alter one of these parameters, such as a membership addition, a membership removal, a processor type for the processor that includes the TEE, a TEE type, a code version executing in the TEE, or a Confidential Consortium Blockchain Framework (COCO) version executing in the TEE. The validation nodes receiving the request may determine whether to alter the parameter based on the consensus protocol code.
  • As discussed above, in some examples, the BMK can only be recovered with the consent of M of N members. Similarly, changes to some or all of the parameters discussed above may be changed by M of N voting, where N is the total current number of members, and M is a number from 1 to N that is the quorum for changing a parameter, where M is one of the agreed-upon parameters when initially establishing the consortium blockchain network. As discussed above, in some examples, members have voting privileges, and participants that are not members do not have voting privileges.
  • In some examples, the addition of new participants requires consensus based on the agreed-upon consensus protocol. In other examples, a member can unilaterally add new participants. Whether the addition of new participants can be done unilaterally may be one of the agreed-upon initial parameters.
  • In some examples, the approval of additions to, and removals from, the network's membership list, and changes to the set of approved blockchain implementations the network allows to participate, may be made based on the agreed-upon consensus protocol. Further, in some examples, for networks that require participants to be authorized by members, members can also approve the set of participants that have permission to submit transactions to the network. The protocol for reaching agreement among members, may be implemented by the agreed-upon code stored in the TEE of each validation node.
  • In some examples, each member is represented with a public/private key pair (PBK and KBK) that the member uses to bootstrap their membership in the COCO through a process of endorsement. In some examples, endorsement represents the fact that the member fully trusts a specific implementation of the network's blockchain protocol. In some examples, VNs execute endorsed blockchain code in a Trusted Execution Environment (TEE), and each VN is endorsed by exactly one member. For example, code that is stored on the blockchain can be executed as part of a transaction. In some examples, as part of the endorsement operation, a member shares the member's KBK with the VN. In these examples, because the member shares the member's KBK with the VN, for security reasons, it may be useful for the member to trust the blockchain protocol implementation and the TEE to not to leak the key. This trust may be accomplished by careful review of the blockchain protocol and its implementation, and based on the threat model and risks of a TEE compromise. In some examples, each member endorses at least one VN, but endorsing multiple nodes can provide high availability.
  • Endorsement may provide the endorsing member the exclusive ability to authorize which other members and other implementations of the blockchain protocol implementation the VN will participate with. In some examples, a VN will accept membership updates and approval to trust blockchain protocol implementations other than its own only from the VN's endorsing member. In some examples, to protect all the VN's external communications, a VN generates a public/private key pair using the TEE and shares its public key externally. A member may establish a secure tunnel with a VN, including potentially ones for which the VN is not the endorser, using the VN's public key. The VN may then use proof-of-possession of the VN's KBK to authenticate VN requests.
  • One type of VN request is authorizing a network member, which as mentioned, only a node's endorser can execute in some examples. In some examples, to authorize a member, the endorser submits the PBK of that member. In some examples, once populated with the endorser's keys and the list of network members identified by their PBKs, a VN can join the network. In some examples, joining is the act of a VN establishing trusted connections with the network's other VNs. A network may use a discovery protocol that suits the network's requirements to provide a VN the ability to find and connect with the network's other VNs. For example, the endorser may provide the list of nodes by submitting the nodes' DNS names, IP addresses, or identifiers specific to the blockchain network's discovery and connection system.
  • As discussed above, in some examples, establishing a trusted connection with another VN starts with the creation of a mutually-authenticated secure tunnel built on the public keys of the communicating VNs. As part of the trust establishment, in some examples, a VN proves that it possesses its endorser's KBK. In some examples, this ensures that a remote node has been endorsed by an authorized member, since the tunnel proves that the node can provide an endorsement referencing the VN's public key signed by a member's KBK that matches the member's PBK.
  • FIG. 9 is a block diagram illustrating an example of system (900) that includes a portion of a COCO network including two validation nodes undergoing validation node attestation and key exchange as the final part of a new member joining the network.
  • FIG. 9 shows an example of VN attestation and key exchange as the final step in establishing trust between nodes via an exchange of the exact version of the blockchain protocol implementation the node is running, as well as a comparison of membership lists. A node may do this using TEE attestation, which includes proof that the node is running the specific implementation in a specific TEE.
  • In some examples, once a VN determines that a remote node is executing trusted code in a TEE that the VN also trusts, the VN checks to make sure that the remote endorser is in the local membership list, and if so, the channel is considered trusted and the VN will accept blockchain updates from the remote node. In some examples, this means that the VN is confident that the remote node will not expose or leak data that the blockchain protocol doesn't allow. In some examples, the agreed-upon membership set itself can be kept confidential by having VNs refer to members by hashes (e.g., salted hashes) of their PBKs, rather than the PBKs themselves. In some examples, once a trusted connection is established, a VN shares the VN's endorser's KBK.
  • In some examples, there are two ways that the blockchain evolves: membership updates, as described above, and blockchain code updates. When the network agrees on a protocol update, this may result in the desire for the network to accept one or more new implementations of the blockchain code. A member that wishes to upgrade the blockchain code may shut down their existing VNs and launch new ones in place of the existing VNs. The member may choose to allow the new VNs to trust previous versions, or to only trust new versions. Trusting existing versions may ensure that transactions can continue to be processed while the new version doesn't have a M of N majority, but new versions and not existing versions may be done instead if the previous code is considered untrustworthy for some reason, or if the complexity to maintain protocol compatibility it too great. Cross-version incompatibility during the upgrade may interrupt transaction processing, however.
  • In some examples, the establishment of trust between VNs that represent every member results in each node eventually obtaining a copy of the KBKs of all the network's members. In some examples, a node will accept blockchain updates signed with the private signing key of the members that the node is provisioned to participate with, regardless of whether the node receives the transactions directly from the member's VN, or from another trusted VN.
  • Adding a new member to the network may require that a VN's endorser proposes it to the network by provisioning the PBK of the new member. The endorser may then let the other VNs know of the proposal, and the fact that the endorser has voted for the new member's admission to the network. As other members propose the same member, their VNs may note the vote and let the network know. In some examples, a VN does not accept blockchain updates proposed by a member until a consensus is reached based on the agreed-upon consensus protocol.
  • FIG. 10 is a diagram illustrating example of a process (1080) for adding a new member to a consortium blockchain network. FIG. 10 shows an example of the steps followed by a network with two members (m1 and m2) adding a third member m3. An example of the steps of FIG. 10 proceeds as follows. In (a), member m1 proposes the new member, m3. The member's VN notes the proposal and the member's endorser votes, and then passes the proposal to the other VNs. The VN of m1 notes the proposal and m1's admission vote. Then in (b), member m2 proposes the new member, and both VNs note the vote, which is now unanimous, so in (c) each VN has added the new member and once it does, the VN considers the new member in voting and will accept blockchain updates from the new member.
  • In some examples, at any time, a member can request that the blockchain network (meaning the VNs) remove it from the membership set. However, in some examples, a VN will only remove a member when either a majority or all VNs representing members except the one being removed agree to remove the member, depending on the membership rules of the network. In some examples, a majority (≥½N+1, where N is the initial membership count), with the caveat that the removing member does not have a vote (so effectively ≥½N), is required to remove a member, in order to prevent a rogue member from instructing its VNs to remove all other members, which would leave it with the ability to decrypt all of the blockchain's state (examples of the blockchain encryption scheme are discussed in greater detail below). In some examples, when a member is removed, VNs destroy the VNs' ephemeral copies of the member's private symmetric encryption key and trigger the generation of a new membership metadata block.
  • A member may also request a key rollover operation, whereby the membership metadata is updated to reflect the new public key and the member's old KBK is encrypted with the new one and stored in the membership metadata. In some examples, once rolled over, the network will not accept any transactions referencing the old KBK. However, the network may allow the member to access any transactions associated with the old key when a member proves they have access to the new one, which may enable the member full access to their data while preventing access by the old key.
  • In some examples, beyond COCO's options for membership, trusted connection establishment, and consensus, COCO supports arbitrary blockchain protocols. For instance, the blockchain code may implement Ethereum, Corda, Chain Core, or a Hyperledger system. However, existing systems are not designed to take advantage of the trust and confidentiality properties of some examples of COCO.
  • In some examples, because COCO VNs are fully trusted, other VNs on the network can implicitly accept any blockchain state updates it receives from a trusted VN as being compliant with the blockchain's protocol and protected from external tampering by the TEE. This allows the possibility of one-time and non-deterministic execution of chaincode. Chaincode may use the TEE's non-determinism, for example, to generate random numbers for use in lotteries or to resolve conflicts. The chaincode may also call out to external systems, which may replace the need for on-chain oracles with external ones trusted by the chaincode, with the advantage that the external system may be referenced at the time a VN accepts the chaincode transaction. Chaincode can also execute external operations that have side-effects, so long as compensating actions can undo the operation if there's any possibility that such an operation will be rendered obsolete by a superseding conflict or the transaction is lost before it is committed by a majority of the VNs.
  • With the COCO trust foundation, arbitrary confidentiality models may be built.
  • For example, first, a participant may ensure that the network, or more specifically, the VN to which it is submitting transactions will be confidential by encrypting the transaction with the PBK of a member's KBK. In these examples, only VNs of a network the VN's representative member has endorsed will have access to the contents of the transaction, which may include sensitive information. For networks where participants wish to only reveal transactions to VNs that are part of networks with additional members, a transaction may be encrypted with a unique key that itself is encrypted with an M of N encoding of the PBK's of those members.
  • In some examples, where a member designates a transaction between itself and another member or members as confidential, the VNs all process the transaction in the clear, but the transaction itself is stored in the blockchain encrypted with the BMK. In some examples, the VNs then only allow the members involved in the transaction to see the transaction. The same model may be applied to chaincode and chaincode state.
  • In other examples, instead, a majority of members may request to reveal an otherwise confidential transaction, something that may be desirable for cases where the consortium subsequently requires a full view of historical activity. Other examples allow for the provisioning of auditing members. Just like for M of N acceptance of new participating members, an M of N scheme can enable members to agree to admit members with special privileges, like being able to read all transactions, even ones marked confidential.
  • One aspect of example blockchain networks is how the VNs achieve consensus. Distributing transactions throughout the network may be performed using multi-cast, broadcast trees, or any other protocol deemed efficient by the membership for the scale of membership and the topology of the VN communications network. In some examples, the trusted nature of VNs means that consensus can be achieved as quickly as messages can be distributed to a majority of the nodes.
  • In some examples, in a model where any VN can accept transactions, each VN can build a different version of the blockchain. At any time, a VN may have some transactions that have been committed by majority subset N of the VNs, and other transactions committed by a different subset N. In some examples, because eventually all nodes converge to a common view of the committed transactions, the committed blockchain state of every VN is a correct representation of the blockchain's state, even if the order of blocks is unique.
  • COCO networks may be built with other consensus protocols, but some examples use consensus protocols that can take advantage of the fact that a message received from a trusted VN is itself trusted to achieve efficient agreement and maximum throughput.
  • In some examples, transaction processing proceeds as follows. First, a participant submits a transaction. The transaction submitted by the participant may be encrypted with the BMK and forwarded to the VN acting as a master based on the consensus protocol. (The master VN is interchangeably referred to as the leader VN.) In this example, the master VN then receives the transaction and processes the transaction by executing the code of the transaction. In this example, the master VN then resolves any conflicts, and broadcasts the transaction and the state of the transaction to the other VNs. In one example, each VN stores a full copy of the ledger, the data inside the TEE is in plain text, and data outside of the TEE, such as data on disk or being communicated over the network, is signed by the BSK and encrypted by the BMK. The VN can then update the transaction state directly.
  • In other examples, each VN need not store a copy of the ledger. In other examples, the ledger can be stored in an external storage cloud service or in an on premises storage array.
  • A COCO blockchain's persistent state, meaning the state that's written to durable storage, may include three types of data: metadata, transactions, and chaincode state. Chaincode code may be considered part of chaincode state. A pair of blockchain public key (BPK) and blockchain private key (BSK) may be used to protect the integrity of the persistent state. The BPK may be used to verify the block state digests signed by the corresponding BSK. In some examples, the chain is append-only with any additions to the chain bound to previous portions of the chain using BSK-signed digests. If the BSK leaks, rogue or colluding members may be able to compromise the integrity of the blockchain, which is why, in some examples, the BSK is generated in and exclusively sealed within TEEs.
  • In some examples, the metadata includes the BPK in plaintext for integrity verification. In some examples, the confidentiality of any blockchain state that is not to be exposed in the clear is protected, using symmetric cryptography, with a blockchain master key (BMK). The BMK may also be part of the blockchain metadata, in a protected way, because a quorum of members may need or want to decrypt and recover the blockchain data bypassing TEEs in case of emergency (e.g. disaster recovery after all TEEs are destroyed).
  • In some examples, blockchains include ledgers that grow over time. In some examples, a blockchain ledger may grow too large to be stored in the TEE, and is stored to disk instead. In some examples, when private data is stored to disk, the BPK and BSK enable data to be stored on disk, and to verify, once the data is read back in, that the data hasn't been tampered with. In some examples, the BMK may be used to encrypt private data stored to disk, so that even when the data is stored on disk, the data cannot be seen.
  • One approach to protecting the BMK, as used in some examples, is to store in the blockchain metadata a copy of the BMK for each member that's encrypted to that member's KBK. This may prevent the BMK from leaking beyond the members. However, in some examples, it does not defend against a rogue or compromised member from leaking it.
  • To defend against rogue nodes or colluding members, COCO-based blockchains may use M of N encryption schemes to require that the KBKs of some threshold number of members must be known to obtain the BMK. VNs may then gain access as soon as they join with enough other VNs endorsed by that number of members, but, in some examples, no sooner. In some examples, since a member only has access to their own key outside of the TEE, it takes at least M members to leak or share their KBKs for the chain to be decrypted outside of a VN's TEE.
  • While M can equal N, or even be 1, some examples of a COCO implementation require that M be at least ½N+1 and match the membership set agreement consensus model, which may ensure that so long as a majority set of members do not collude, the confidentiality of the blockchain's state is protected by the mutually trusted code that executes within TEEs. It may also ensure that so long as the network can establish a connection with VNs representing at least M+1 members, it can operate, thus ensuring resiliency even in the case when a member withdraws its VNs or its VNs are partitioned from the network.
  • In some examples, an M of N scheme may be implemented as follows. Each member listed in the blockchain's membership metadata block is represented by the member's public key, as well as a fragment of the BMK encrypted to that public key, as shown in Table 1. In some examples, the first metadata membership block is created during network bootstrap, encrypting the BMK to the initial membership set. When an additional member is added to the network, an example of COCO takes steps to adjust M and N by creating a new BMK, fragmenting it across the updated N set of members, and appending a new metadata block that includes both the previous BMK encrypted by the new BMK, as well as the updated membership list.
  • Just as before, blockchain state up to the point of a membership update may be subject to compromise by a colluding set of the previous membership set according to the blockchain's implementation of M of N. But by creating a new BMK, all blockchain state from that point forward in the blockchain's timeline may be protected by the updated membership set, including an updated M of N scheme, if the blockchain implements one.
  • To prevent rollback of the blockchain to a previous state, a signature, authentication code, or a unique identifier of the last addition to the chain can be stored in trusted non-volatile storage accessible only to the VNs. Similarly, the signature of the last addition to the blockchain may be included in all interactions with members to allow members to detect any attempts to roll back the blockchain to a previous state. In some examples, members roll over KBKs upon membership changes to protect against bugs in old code versions. In some examples, attestation, key exchange, or both is rerun after every membership version in certain circumstances, such as code version removal from the approval list of code.
  • In some examples, COCO is adapted to a model that does not require each member to have dedicated VNs. Shared VNs may be useful for development and/or testing, cost-conscious members, or as the basis for a multitenant hosted solution either by a cloud provider or by a member who acts as the hosting agent for other members. In one example, all members rely upon a single VN (or set of VNs for high availability) hosted by a single centralized party. In this example of a centralized model, all members may need to rely upon the centralized party to process transactions and to process membership updates, and unless blockchain state is streamed or exported, the centralized infrastructure may become a single point of failure for blockchain state.
  • In some examples, to accommodate multi-tenant VNs, the endorsement handler accepts member inputs as above, storing separate endorsement states per member inside the TEEs. In some examples, the endorsement handler only commits changes once quorum has been reached among the members participating in the shared VN.
  • Unlike traditional blockchain implementations, some examples of COCO VNs trust their peers, enabling highly efficient, scalable and performant transaction processing across VNs.
  • Several measures may substantially mitigate the risks associated with TEE compromise. The likelihood of TEE compromise can be reduced in several ways. One way of reducing the likelihood of TEE compromise may be accomplished as follows. Each VN is factored into two parts. The manager TEE may be responsible for private key management, cryptographic processing, and membership update logic so that the amount of code required to implement the manager TEE is bounded, and that code need not vary with each blockchain integration. This code can then be formally verified and heavily audited to further minimize the risk of compromise.
  • In such an example, the manager TEE is essentially a TEE-based hardware security module (HSM) responsible for the most trusted operations of the VN, and the worker TEE is a separate enclave that hosts the blockchain protocol code. (In some examples, the worker TEE may include a significantly larger codebase than the manager TEE, and the codebase of the worker TEE varies with each ledger that is integrated with COCO.) In such an example, the worker TEE makes requests to the manager TEE for encryption, decryption, and signing of data using the VN's private keys such that if the worker TEE is compromised, an attacker could access any plaintext data that is loaded in memory by the worker TEE—but it could not directly access the keys, independently decrypt blocks on disk or propose or approve membership changes. This example of two-TEE factoring reduces the likelihood of manager TEE compromise, and reduces the impact of a worker TEE compromise.
  • In some examples, the network can also enforce a rule that VN authorization to participate in the network is a lease which must be periodically renewed. The renewal process may require that the TEE is reset to a pristine state, and might eliminate any toehold that an attacker might be able to gain. VNs that do not renew their lease may be quarantined from the network, and thus might prevent exposure of new data added to the blockchain after quarantine takes effect.
  • The encryption and authentication functions of the KBK may be split apart into two separate keys. This split may eliminate the need for the VNs to replicate the authentication private key. In some examples, only the encryption key needs to be replicated across VNs—which may eliminate global exposure of member authentication private keys upon manager TEE compromise.
  • VNs may sample transactions sent from other VNs and to fully validate the sample synchronously before commitment. This may ensure that a VN producing bogus results could be detected quickly to drive alerts without a major performance reduction. Similarly, a separate node may asynchronously validate all transactions, also driving alerts if any problems are detected.
  • Various examples of a blockchain system leverage the properties of TEEs, and may serve as a foundation for blockchain implementations that support database-level transaction throughputs and latencies, as well as flexible confidentiality models. In some examples, many different blockchain protocols can take advantage of examples of the COCO framework to provide efficient transaction processing with blockchain and transaction confidentiality.
  • Through the specification, examples have been given in which is member has its own VN. However, in some examples, as discussed in greater detail above, multiple members may share the same VN, or even all of the members may share a single node endorsed by all of the members.
  • Not all examples include all of the features discussed herein. For instance, some examples do not use encryption.
  • FIG. 11 is a diagram illustrating an example dataflow for a process (1190) for a blockchain system. In some examples, the process of FIG. 11 is performed by a validation node. In the illustrated example, step 1191 occurs first. At step 1191, in some examples, a pre-determined type of blockchain protocol code and a pre-determined type of consensus code are stored in a trusted execution environment (TEE) of a processor.
  • As shown, step 1192 occurs next in some examples. At step 1192, in some examples, TEE attestation is used to verify that the blockchain protocol code stored in the TEE is the pre-determined type of blockchain protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code. As shown, step 1193 occurs next in some examples. At step 1193, a request to alter the pre-determined type of blockchain protocol code may be received. As shown, step 1194 occurs next in some examples. At step 1194, in some examples, a determination is made as to whether to change the pre-determined type of blockchain protocol code based on the pre-determined consensus code. The processing then proceeds to a return block, where other processing is resumed.
  • Conclusion
  • While the above Detailed Description describes certain examples of the technology, and describes the best mode contemplated, no matter how detailed the above appears in text, the technology can be practiced in many ways. Details may vary in implementation, while still being encompassed by the technology described herein. As noted above, particular terminology used when describing certain features or aspects of the technology should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the technology to the specific examples disclosed herein, unless the Detailed Description explicitly defines such terms. Accordingly, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology.

Claims (20)

We claim:
1. An apparatus for a blockchain system, comprising:
a device including at least one memory adapted to store run-time data for the device, and at least one processor that is adapted to execute processor-executable code that, in response to execution, enables the device to perform actions, including:
storing, in a trusted execution environment (TEE) of the processor, a pre-determined type of blockchain protocol code, and a pre-determined type of consensus code;
using TEE attestation to verify that the blockchain protocol code stored in the TEE is the pre-determined type of blockchain protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code;
receiving a request to alter the pre-determined type of blockchain protocol code; and
determining whether to change the pre-determined type of blockchain protocol code based on the pre-determined consensus code.
2. The apparatus of claim 1, the action further comprising:
receiving a request to alter at least one other pre-determined parameter associated with the blockchain system, wherein said at least one other pre-determined parameter includes at least one of a membership addition, a membership removal, a processor type for the processor that includes the TEE, a TEE type, a code version executing in the TEE, or a Confidential Consortium Blockchain Framework (COCO) version executing in the TEE; and
determining whether to alter said at least one other pre-determined parameter based upon the consensus code.
3. The apparatus of claim 1, the actions further comprising:
receiving a blockchain transaction; and
electing a validation node leader for the blockchain transaction based on the consensus code.
4. The apparatus of claim 3, the actions further comprising:
processing the blockchain transaction via the elected validation node leader;
directly updating, for a blockchain network, an official state of the processed blockchain based on the processing of the blockchain transaction; and
broadcasting the updated official state of the processed blockchain to the blockchain network.
5. A method for a blockchain system, comprising:
storing, in a trusted execution environment (TEE) of a processor, a pre-determined type of blockchain protocol code, and a pre-determined type of consensus code;
using TEE attestation to verify that the blockchain protocol code stored in the TEE is the pre-determined type of blockchain protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code;
receiving a request to alter the pre-determined type of blockchain protocol code; and
executing the pre-determined consensus code in the TEE of the processor to determine whether to change the pre-determined type of blockchain protocol code.
6. The method of claim 5, further comprising:
receiving a request to alter at least one other pre-determined parameter associated with the blockchain system, wherein said at least one other pre-determined parameter includes at least one of a membership addition, a membership removal, a processor type for the processor that includes the TEE, a TEE type, a code version executing in the TEE, or a Confidential Consortium Blockchain Framework (COCO) version executing in the TEE; and
determining whether to alter said at least one other pre-determined parameter based upon the consensus code.
7. The method of claim 5, wherein the TEE includes at least one protected region in the processor.
8. The method of claim 5, wherein the TEE includes two protected regions in the processor.
9. The method of claim 5, further comprising endorsing a first validation node that includes the processor.
10. The method of claim 9, wherein endorsing the first validation node includes storing a public/private key pair in the TEE of the first validation node.
11. The method of claim 9, further comprising:
discovering other validation nodes associated with a plurality of prospective members; and
receiving private keys from the other validation nodes.
12. The method of claim 11, further comprising:
receiving verification via TEE attestation that the other validation nodes store the pre-determined type of blockchain protocol code, and the pre-determined type of consensus code; and
upon TEE attestation verifying each of the validation nodes, bootstrapping a consortium network such that the prospective members become members of the consortium network, wherein bootstrapping the consortium network includes generating a blockchain master key.
13. The method of claim 5, further comprising:
receiving a blockchain transaction; and
electing a validation node leader for the blockchain transaction based on the consensus code.
14. The method of claim 13, further comprising:
performing conflict resolution associated with the blockchain transaction based on the consensus code.
15. The method of claim 13, wherein the blockchain transaction is encrypted and confidential such that only authorized parties are permitted to view the blockchain transaction.
16. The method of claim 13, further comprising:
processing the blockchain transaction via the elected validation node leader;
directly updating, for a blockchain network, an official state of the processed blockchain based on the processing of the blockchain transaction; and
broadcasting the updated official state of the processed blockchain to the blockchain network.
17. The method of claim 16, wherein processing the blockchain transaction includes executing non-deterministic code.
18. A processor-readable storage medium, having stored thereon processor-executable code that, upon execution by at least one processor, enables actions, comprising:
storing, in a trusted execution environment (TEE) of the processor, a pre-determined type of authentication protocol code, and a pre-determined type of consensus code;
using TEE attestation to verify that the authentication protocol code stored in the TEE is the pre-determined type of authentication protocol code, and to verify that the consensus code stored in the TEE is the pre-determined type of consensus code;
receiving a request to alter the pre-determined type of authentication protocol code; and
determining whether to change the pre-determined type of authentication protocol code based on the pre-determined consensus code.
19. The processor-readable storage medium of claim 18, the processor-executable code enabling, upon execution, further actions, comprising:
receiving a authentication transaction; and
electing a validation node leader for the authentication transaction based on the consensus code.
20. The processor-readable storage medium of claim 19, the processor-executable code enabling, upon execution, further actions, comprising:
processing the authentication transaction via the elected validation node leader;
directly updating, for a authentication network, an official state of the processed authentication based on the processing of the authentication transaction; and
broadcasting the updated official state of the processed authentication to the authentication network.
US15/638,203 2017-02-07 2017-06-29 Consortium blockchain network with verified blockchain and consensus protocols Abandoned US20180225661A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US15/638,203 US20180225661A1 (en) 2017-02-07 2017-06-29 Consortium blockchain network with verified blockchain and consensus protocols
PCT/US2018/016057 WO2018148068A1 (en) 2017-02-07 2018-01-31 Consortium blockchain network with verified blockchain and consensus protocols
ES18706017T ES2909088T3 (en) 2017-02-07 2018-01-31 Consortium blockchain network with verified blockchain and consensus protocols
EP18706017.3A EP3580905B1 (en) 2017-02-07 2018-01-31 Consortium blockchain network with verified blockchain and consensus protocols
CN201880010516.0A CN110268691B (en) 2017-02-07 2018-01-31 Federated blockchain networks with verified blockchain and consensus protocols

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762455981P 2017-02-07 2017-02-07
US15/638,203 US20180225661A1 (en) 2017-02-07 2017-06-29 Consortium blockchain network with verified blockchain and consensus protocols

Publications (1)

Publication Number Publication Date
US20180225661A1 true US20180225661A1 (en) 2018-08-09

Family

ID=63037427

Family Applications (4)

Application Number Title Priority Date Filing Date
US15/638,180 Active 2037-09-18 US10484346B2 (en) 2017-02-07 2017-06-29 Establishment of consortium blockchain network
US15/638,203 Abandoned US20180225661A1 (en) 2017-02-07 2017-06-29 Consortium blockchain network with verified blockchain and consensus protocols
US15/638,213 Active 2037-10-27 US10764259B2 (en) 2017-02-07 2017-06-29 Transaction processing for consortium blockchain network
US16/686,172 Active US11218457B2 (en) 2017-02-07 2019-11-17 Establishment of consortium blockchain network

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US15/638,180 Active 2037-09-18 US10484346B2 (en) 2017-02-07 2017-06-29 Establishment of consortium blockchain network

Family Applications After (2)

Application Number Title Priority Date Filing Date
US15/638,213 Active 2037-10-27 US10764259B2 (en) 2017-02-07 2017-06-29 Transaction processing for consortium blockchain network
US16/686,172 Active US11218457B2 (en) 2017-02-07 2019-11-17 Establishment of consortium blockchain network

Country Status (5)

Country Link
US (4) US10484346B2 (en)
EP (4) EP3580683A1 (en)
CN (4) CN110300973B (en)
ES (1) ES2909088T3 (en)
WO (3) WO2018148068A1 (en)

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190140846A1 (en) * 2017-11-03 2019-05-09 Microsoft Technology Licensing, Llc Provisioning trusted execution environment(s) based on chain of trust including platform
US10325079B1 (en) * 2018-12-04 2019-06-18 Capital One Services, Llc Version management platform
CN109995850A (en) * 2019-03-05 2019-07-09 深圳前海微众银行股份有限公司 A kind of transaction processing method of block catenary system and block catenary system
CN110995860A (en) * 2019-12-17 2020-04-10 江苏扬子易联智能软件有限公司 GMP/GSP quality management platform based on controlled query block chain and management method thereof
WO2020081163A1 (en) 2018-10-16 2020-04-23 Microsoft Technology Licensing, Llc Database management
WO2020081164A1 (en) 2018-10-16 2020-04-23 Microsoft Technology Licensing, Llc Database management
US20200133646A1 (en) * 2018-10-30 2020-04-30 International Business Machines Corporation Transformation of inter-organization process for execution via blockchain
US10686601B2 (en) * 2018-01-24 2020-06-16 Sensoriant, Inc. Consistency and consensus management in decentralized and distributed systems
US10708066B2 (en) * 2018-12-13 2020-07-07 Alibaba Group Holding Limited Achieving consensus among network nodes in a distributed system
US10728020B2 (en) * 2018-01-24 2020-07-28 Sensoriant, Inc. Efficient mining operations in blockchain environments with non-secure devices
US10764052B2 (en) * 2018-01-24 2020-09-01 Sensoriant, Inc. User identity and trust models in decentralized and distributed systems
WO2020220627A1 (en) * 2019-04-29 2020-11-05 清华大学 Method and device for strong cross-domain logic isolation and secure access control in internet of things scenario
CN112235360A (en) * 2020-09-26 2021-01-15 建信金融科技有限责任公司 Data sharing method, device and system based on alliance chain, electronic equipment and computer readable storage medium
US10958438B2 (en) * 2018-10-31 2021-03-23 Advanced New Technologies Co., Ltd. Method, apparatus, and electronic device for blockchain-based recordkeeping
US20210089356A1 (en) * 2018-03-26 2021-03-25 Uvue Ltd Data Processing System using Directed Acyclic Graph and Method of use thereof
US10990563B2 (en) 2019-04-11 2021-04-27 Advanced New Technologies Co., Ltd. Information read/write method and apparatus based on blockchain
US20210160059A1 (en) * 2018-04-25 2021-05-27 Siemens Aktiengesellschaft Data processing device for processing a radio signal
US11048813B2 (en) * 2018-08-29 2021-06-29 Nucleus Vision, Llc Method and system for managing consent data in a blockchain network
US11057222B2 (en) * 2017-07-26 2021-07-06 Advanced New Technologies Co., Ltd. Digital certificate management method and apparatus, and electronic device
US11144537B2 (en) 2019-09-16 2021-10-12 Bank Of America Corporation System for data consensus validation in an electronic distributed server network using a screening node
US11177938B2 (en) 2019-04-19 2021-11-16 International Business Machines Corporation Database composite endorsement
US11218315B2 (en) 2018-01-24 2022-01-04 Safeshare, Inc. System and method establishing a trust model for shared content on the internet
US20220038284A1 (en) * 2020-07-28 2022-02-03 Sensoriant, Inc. Testing and Other Data Communicated Using Trust Models In Decentralized and Distributed Systems
US11310234B2 (en) * 2017-11-16 2022-04-19 International Business Machines Corporation Securing permissioned blockchain network from pseudospoofing network attacks
US20220200985A1 (en) * 2020-12-22 2022-06-23 Red Hat, Inc. Network management using trusted execution environments
US11394544B2 (en) * 2019-01-07 2022-07-19 Aitivity Inc. Validation of blockchain activities based on proof of hardware
US11397708B2 (en) * 2017-02-17 2022-07-26 Nokia Technologies Oy Voting-consensus distributed ledger
US11410171B2 (en) 2020-07-03 2022-08-09 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain consensus method and device and electronic equipment
US11474854B2 (en) 2018-10-30 2022-10-18 International Business Machines Corporation Transformation of inter-organization process for execution via blockchain
US11654635B2 (en) 2019-04-18 2023-05-23 The Research Foundation For Suny Enhanced non-destructive testing in directed energy material processing
US20230370273A1 (en) * 2022-05-10 2023-11-16 Microsoft Technology Licensing, Llc Bootstrapping a code transparency system
US11943368B2 (en) 2017-11-03 2024-03-26 Microsoft Technology Licensing, Llc Provisioning trusted execution environment based on chain of trust including platform

Families Citing this family (120)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10817593B1 (en) 2015-12-29 2020-10-27 Wells Fargo Bank, N.A. User information gathering and distribution system
US10262164B2 (en) 2016-01-15 2019-04-16 Blockchain Asics Llc Cryptographic ASIC including circuitry-encoded transformation function
US10484346B2 (en) 2017-02-07 2019-11-19 Microsoft Technology Licensing, Llc Establishment of consortium blockchain network
LU100069B1 (en) * 2017-02-10 2018-09-27 Univ Luxembourg Improved computing apparatus
CN107018125B (en) * 2017-02-17 2019-08-09 阿里巴巴集团控股有限公司 A kind of block catenary system, date storage method and device
CN111724150B (en) * 2017-03-28 2023-11-24 创新先进技术有限公司 Service request processing method and device
TWI765019B (en) * 2017-04-11 2022-05-21 安地卡及巴布達商區塊鏈控股有限公司 Rapid distributed consensus on blockchain
CN107392040B (en) * 2017-04-28 2019-08-09 阿里巴巴集团控股有限公司 A kind of method and device of common recognition verifying
EP3622660B1 (en) * 2017-05-12 2023-08-30 Massachusetts Institute of Technology Systems and methods for crowdsourcing, analyzing, and/or matching personal data
US10581621B2 (en) * 2017-05-18 2020-03-03 International Business Machines Corporation Enhanced chaincode analytics provenance in a blockchain
CN107453896B (en) * 2017-06-27 2020-08-04 创新先进技术有限公司 Method and device for processing multiple block chain network data and server
JP2019012415A (en) * 2017-06-30 2019-01-24 株式会社bitFlyer Method for building consensus in network and nodes constituting network
US10944546B2 (en) 2017-07-07 2021-03-09 Microsoft Technology Licensing, Llc Blockchain object interface
CN107592292B (en) * 2017-07-26 2019-08-09 阿里巴巴集团控股有限公司 A kind of block chain communication method between nodes and device
US10862831B2 (en) * 2017-08-03 2020-12-08 Digital 14 Llc System, method, and computer program product providing end-to-end security of centrally accessible group membership information
US11132451B2 (en) * 2017-08-31 2021-09-28 Parity Technologies Ltd. Secret data access control systems and methods
US10567168B2 (en) * 2017-11-16 2020-02-18 International Business Machines Corporation Blockchain transaction privacy enhancement through broadcast encryption
US10819684B2 (en) * 2017-11-24 2020-10-27 International Business Machines Corporation Cognitive blockchain for internet of things
US11238449B2 (en) * 2017-12-18 2022-02-01 Nec Corporation Efficient validation of transaction policy compliance in a distributed ledger system
US10924489B2 (en) * 2018-01-19 2021-02-16 International Business Machines Corporation Building trusted public blockchain networks based on participants' digital social behavior
US20190287107A1 (en) * 2018-03-15 2019-09-19 International Business Machines Corporation Resource equity for blockchain
US10372943B1 (en) 2018-03-20 2019-08-06 Blockchain Asics Llc Cryptographic ASIC with combined transformation and one-way functions
US11615060B2 (en) * 2018-04-12 2023-03-28 ISARA Corporation Constructing a multiple entity root of trust
US10256974B1 (en) 2018-04-25 2019-04-09 Blockchain Asics Llc Cryptographic ASIC for key hierarchy enforcement
CN108667618B (en) * 2018-05-10 2020-07-03 阿里巴巴集团控股有限公司 Data processing method, device, server and system for member management of block chain
US10880072B2 (en) * 2018-06-20 2020-12-29 Verizon Patent And Licensing Inc. Systems and methods for controlled random endorsement in a blockchain network
CN110636087B (en) * 2018-06-21 2022-04-12 北京果仁宝软件技术有限责任公司 Data processing method and system based on alliance chain
US11632236B1 (en) * 2018-06-29 2023-04-18 Verisign, Inc. Establishment, management, and usage of domain name to blockchain address associations
US10721060B1 (en) * 2018-06-29 2020-07-21 Verisign, Inc. Domain name blockchain user addresses
US11836721B2 (en) * 2018-06-29 2023-12-05 Intel Corporation Protection of information in an information exchange
GB201811263D0 (en) * 2018-07-10 2018-08-29 Netmaster Solutions Ltd A method and system for managing digital using a blockchain
WO2020014512A1 (en) 2018-07-11 2020-01-16 Americorp Investments Llc Blockchain operating system
CN109063169A (en) * 2018-08-17 2018-12-21 福建省农村信用社联合社 A kind of customer data management system based on block chain
CN109167771B (en) * 2018-08-21 2020-06-05 京东数字科技控股有限公司 Authentication method, device and equipment based on alliance chain and readable storage medium
CN110868441B (en) * 2018-08-28 2021-03-16 傲为信息技术(江苏)有限公司 Block chain public link maintenance method and device, node and block chain public link
JP7051648B2 (en) * 2018-09-05 2022-04-11 株式会社日立製作所 Electronic transaction device, electronic transaction verification device, and electronic transaction method
US11405373B2 (en) * 2018-09-07 2022-08-02 Honeywell International, Inc. Blockchain-based secured multicast communications
US20200084041A1 (en) * 2018-09-07 2020-03-12 Nebulas IO Limited Automated Blockchain Protocol Update
US11151254B2 (en) 2018-09-11 2021-10-19 Amari.Ai Incorporated Secure communications gateway for trusted execution and secure communications
CN109670930A (en) * 2018-09-13 2019-04-23 深圳壹账通智能科技有限公司 Rogue device recognition methods, device, equipment and computer readable storage medium
CN109274498B (en) * 2018-09-25 2021-05-25 江西理工大学 Intelligent power grid data aggregation and monitoring method based on alliance chain
CN109274674B (en) * 2018-09-27 2021-03-23 福建福链科技有限公司 Block chain heterogeneous consensus method with high security and terminal
CN109257430B (en) * 2018-09-30 2024-04-19 北京奇虎科技有限公司 System, method and server for block chain-based internet application
JP7062571B2 (en) * 2018-10-05 2022-05-06 株式会社日立製作所 Organization management support system, organization management support method, and organization management support device
US11270017B2 (en) 2018-10-16 2022-03-08 International Business Machines Corporation Selective exchange of transaction data
US10917233B2 (en) * 2018-10-16 2021-02-09 International Business Machines Corporation Selective exchange of transaction data
CN111192142A (en) * 2018-10-25 2020-05-22 富士通株式会社 Apparatus, method and medium for information disclosure and transaction processing for federation chains
CN109472698B (en) * 2018-10-30 2021-07-02 四川大学 Public welfare supervision method and system based on block chain
CN112492006B (en) * 2018-10-31 2023-12-05 创新先进技术有限公司 Node management method and device based on block chain
US11528258B2 (en) * 2018-11-02 2022-12-13 Intel Corporation System and apparatus for data confidentiality in distributed ledger
US11227057B2 (en) 2018-11-08 2022-01-18 International Business Machines Corporation Membership access management of a database
US20200177373A1 (en) * 2018-11-14 2020-06-04 Royal Bank Of Canada System and method for storing contract data structures on permissioned distributed ledgers
CN109495246B (en) * 2018-11-20 2021-04-20 王建新 Method for verifying federated link node
US11411921B2 (en) 2018-11-23 2022-08-09 Amazon Technologies, Inc. Enabling access across private networks for a managed blockchain service
US11762815B2 (en) 2018-11-23 2023-09-19 Amazon Technologies, Inc. Multi-framework managed blockchain service
JP6873235B2 (en) 2018-11-27 2021-05-19 アドバンスド ニュー テクノロジーズ カンパニー リミテッド Asymmetric key management within the consortium blockchain network
US11102204B1 (en) * 2018-12-11 2021-08-24 Amazon Technologies, Inc. Agreement and enforcement of rules for a shared resource
US11720545B2 (en) * 2018-12-19 2023-08-08 International Business Machines Corporation Optimization of chaincode statements
CN111382458A (en) * 2018-12-28 2020-07-07 富泰华工业(深圳)有限公司 Data batch sealing method and device and computer storage medium
JP6892514B2 (en) 2018-12-28 2021-06-23 アドバンスド ニュー テクノロジーズ カンパニー リミテッド Accelerate transaction delivery in blockchain networks using transaction retransmission
WO2019072307A2 (en) 2018-12-28 2019-04-18 Alibaba Group Holding Limited Accelerating transaction deliveries in blockchain networks using acceleration nodes
CN109792382B (en) * 2018-12-28 2022-07-12 创新先进技术有限公司 Method, system and storage medium for improving block transaction speed using global acceleration node
US11283673B2 (en) * 2019-01-07 2022-03-22 International Business Machines Corporation Blockchain endorsement verification
CN110020855B (en) * 2019-01-31 2020-05-29 阿里巴巴集团控股有限公司 Method, node and storage medium for realizing privacy protection in block chain
AU2020213607A1 (en) 2019-02-01 2021-08-12 Tgrid Technologies Pty Ltd. System, method and computer readable medium for performing a transaction in relation to an identity centric dataset
JP7025365B2 (en) * 2019-03-25 2022-02-24 株式会社日立製作所 Data linkage management method, data linkage management system, and node
US11398895B2 (en) * 2019-03-26 2022-07-26 International Business Machines Corporation Information management in a decentralized database including a fast path service
US11418322B2 (en) 2019-03-26 2022-08-16 International Business Machines Corporation Information management in a decentralized database including a fast path service
US11269858B2 (en) 2019-03-26 2022-03-08 International Business Machines Corporation Information management in a decentralized database including a fast path service
JP6856772B2 (en) * 2019-04-03 2021-04-14 アドバンスド ニュー テクノロジーズ カンパニー リミテッド Processing blockchain data based on smart contract behavior executed in a reliable execution environment
JP6779389B2 (en) 2019-04-03 2020-11-04 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited Processing and storage of blockchain data in a reliable execution environment
US11108553B2 (en) 2019-04-05 2021-08-31 International Business Machines Corporation Database transaction guaranteed commitment
US10726049B2 (en) * 2019-04-17 2020-07-28 Alibaba Group Holding Limited Obtaining blockchain data in stages
CN110071802A (en) * 2019-04-24 2019-07-30 西安纸贵互联网科技有限公司 Data processing method and device suitable for block chain
CN111095899B (en) 2019-04-26 2021-12-24 创新先进技术有限公司 Distributed key management for trusted execution environments
EP3736715A1 (en) * 2019-05-10 2020-11-11 Siemens Aktiengesellschaft Managing admission to a distributed database based on a consensus process
CN111949315A (en) * 2019-05-16 2020-11-17 富士通株式会社 Management device and method for block chain account book data
CN113240519A (en) * 2019-05-30 2021-08-10 创新先进技术有限公司 Intelligent contract management method and device based on block chain and electronic equipment
CN113438068B (en) * 2019-05-31 2024-01-09 创新先进技术有限公司 Method and device for realizing dynamic encryption based on block height
CN110266659B (en) * 2019-05-31 2020-09-25 联想(北京)有限公司 Data processing method and equipment
US11283594B2 (en) * 2019-06-05 2022-03-22 International Business Machines Corporation Context data update in a blockchain network
EP3701701A4 (en) * 2019-06-05 2020-12-30 Alibaba Group Holding Limited Consensus system and method
US11151228B2 (en) 2019-06-26 2021-10-19 Advanced New Technologies Co., Ltd. Blockchain-based image transaction system, method, apparatus, and electronic device
CN111164586B (en) * 2019-06-28 2023-07-04 创新先进技术有限公司 System and method for updating data in a blockchain
US11797655B1 (en) 2019-07-18 2023-10-24 Verisign, Inc. Transferring a domain name on a secondary blockchain market and in the DNS
WO2019214756A2 (en) 2019-08-12 2019-11-14 Alibaba Group Holding Limited Blockchain-based dispute resolution
US11695543B2 (en) 2019-08-22 2023-07-04 Myndshft Technologies, Inc. Blockchain network control system and methods
WO2019228554A2 (en) 2019-08-27 2019-12-05 Alibaba Group Holding Limited System and method for blockchain-based notification
WO2019228552A2 (en) 2019-08-27 2019-12-05 Alibaba Group Holding Limited System and method for blockchain-based notification
SG11202003810RA (en) 2019-08-27 2020-05-28 Advanced New Technologies Co Ltd System and method for registering subscribable sub-states in blockchain
EP3688686A4 (en) * 2019-08-27 2020-11-11 Advanced New Technologies Co., Ltd. System and method for registering subscribable states in blockchain
CN110503433B (en) * 2019-08-28 2022-05-10 北京百度网讯科技有限公司 Method, device, equipment and medium for implementing endorsement in block chain
SG11202002712UA (en) * 2019-09-11 2020-04-29 Alibaba Group Holding Ltd Shared blockchain data storage based on error correction coding in trusted execution environments
US11432149B1 (en) 2019-10-10 2022-08-30 Wells Fargo Bank, N.A. Self-sovereign identification via digital credentials for selected identity attributes
CN111523110B (en) * 2019-11-08 2023-05-02 支付宝(杭州)信息技术有限公司 Authority query configuration method and device based on chain codes
CN110851870B (en) * 2019-11-14 2021-10-01 中国人民解放军国防科技大学 Block chain privacy protection method, system and medium based on trusted execution environment
US11811933B2 (en) 2019-11-27 2023-11-07 Visa International Service Association System and method for fair, secure n-party computation using at least one blockchain
CN110992027B (en) * 2019-11-29 2022-02-25 支付宝(杭州)信息技术有限公司 Efficient transaction method and device for realizing privacy protection in block chain
CN111126964A (en) * 2019-12-24 2020-05-08 深圳前海乐寻坊区块链科技有限公司 Method, device, equipment and storage medium for authenticating position credit based on block chain
CN111179087B (en) * 2019-12-31 2023-07-18 重庆邮电大学 Alliance chain consensus method based on grid arbitration
CN111181992B (en) * 2020-01-03 2022-02-22 平安科技(深圳)有限公司 Communication method, device, equipment and storage medium of nodes and chain codes in block chain
CN111339569B (en) * 2020-02-26 2023-05-26 百度在线网络技术(北京)有限公司 Block chain data processing method, device, electronic equipment and medium
CN111047324B (en) * 2020-03-16 2020-08-04 支付宝(杭州)信息技术有限公司 Method and apparatus for updating a set of public keys at a blockchain node
CN111563740A (en) * 2020-04-26 2020-08-21 中国工商银行股份有限公司 Transaction processing method and system of alliance chain
EP3907957A1 (en) * 2020-05-06 2021-11-10 Siemens Aktiengesellschaft A blockchain network and method for permitting access to a blockchain network
CN111600908B (en) * 2020-06-17 2021-07-13 杭州云链趣链数字科技有限公司 Data processing method, system, computer device and readable storage medium
CN111522648B (en) 2020-07-03 2020-10-09 支付宝(杭州)信息技术有限公司 Transaction processing method and device for block chain and electronic equipment
CN111737304B (en) * 2020-07-31 2021-03-02 支付宝(杭州)信息技术有限公司 Processing method, device and equipment of block chain data
CN113282462B (en) * 2020-08-28 2022-06-28 深圳市金麦粒传媒科技有限公司 Information processing method applied to block chain and big data platform
CN112114872B (en) * 2020-10-14 2023-09-26 鹏城实验室 Method, apparatus and storage medium for controlling operation of blockchain
US10958450B1 (en) * 2020-10-15 2021-03-23 ISARA Corporation Constructing a multiple-entity root certificate data block chain
US11575499B2 (en) 2020-12-02 2023-02-07 International Business Machines Corporation Self auditing blockchain
US11784826B2 (en) * 2020-12-11 2023-10-10 Visa International Service Association System, method, and computer program product for secure real-time n-party computation
CN112613006B (en) * 2020-12-18 2024-03-19 国网辽宁省电力有限公司物资分公司 Power data sharing method and device, electronic equipment and storage medium
US11750401B2 (en) 2021-05-20 2023-09-05 Verisign, Inc. Proving top level domain name control on a blockchain
US11924161B1 (en) 2021-05-20 2024-03-05 Verisign, Inc. Authorization and refusal of modification, and partial modification ability, of a network identifier
CN113067903B (en) * 2021-06-02 2021-09-24 支付宝(杭州)信息技术有限公司 Method for building block chain sub-network and block chain system
CN113556327B (en) * 2021-06-29 2022-09-20 中国人民解放军战略支援部队信息工程大学 Block chain-based false flow rule injection attack detection and prevention system and method
CN113609156B (en) * 2021-08-02 2023-12-12 北京百度网讯科技有限公司 Data query and write method and device, electronic equipment and readable storage medium
CN117455490A (en) * 2023-12-26 2024-01-26 成都边界元科技有限公司 Data element multi-center protocol mutual recognition and common recognition verification platform

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050267984A1 (en) * 2004-04-14 2005-12-01 Jose Costa-Requena Method and apparatus for interoperability and relay for WV and IMS group management services
EP2245829B1 (en) * 2008-01-18 2016-01-06 InterDigital Patent Holdings, Inc. Method for enabling machine to machine communication
US20110041182A1 (en) 2008-04-29 2011-02-17 John Stenfelt intrusion detection and notification
US8458462B1 (en) 2008-08-14 2013-06-04 Juniper Networks, Inc. Verifying integrity of network devices for secure multicast communications
CN103546420B (en) * 2012-07-09 2016-08-03 杭州华三通信技术有限公司 Method that in GET VPN, GM registers to KS and GM and KS
EP2936761B1 (en) * 2012-12-20 2019-07-24 Telefonaktiebolaget LM Ericsson (publ) Technique for enabling a client to provide a server entity
US9853819B2 (en) 2013-08-05 2017-12-26 Guardtime Ip Holdings Ltd. Blockchain-supported, node ID-augmented digital record signature method
CN103795717B (en) * 2014-01-23 2017-01-25 中国科学院计算技术研究所 Method and system for proving integrity of cloud computing platform
US20160012465A1 (en) * 2014-02-08 2016-01-14 Jeffrey A. Sharp System and method for distributing, receiving, and using funds or credits and apparatus thereof
CA2980707A1 (en) 2014-03-25 2015-10-01 Botanic Technologies, Inc. Systems and methods for executing cryptographically secure transactions using voice and natural language processing
US20160098723A1 (en) 2014-10-01 2016-04-07 The Filing Cabinet, LLC System and method for block-chain verification of goods
WO2016120826A2 (en) 2015-01-30 2016-08-04 Enrico Maim Systems and methods for managing networked commitments of secure entities
US11023968B2 (en) 2015-03-05 2021-06-01 Goldman Sachs & Co. LLC Systems and methods for updating a distributed ledger based on partial validations of transactions
WO2016154001A1 (en) 2015-03-20 2016-09-29 Rivetz Corp. Automated attestation of device integrity using the block chain
US20160283920A1 (en) 2015-03-28 2016-09-29 Justin Fisher Authentication and verification of digital data utilizing blockchain technology
WO2016164496A1 (en) 2015-04-06 2016-10-13 Bitmark, Inc. System and method for decentralized title recordation and authentication
US10515409B2 (en) 2016-03-23 2019-12-24 Domus Tower, Inc. Distributing work load of high-volume per second transactions recorded to append-only ledgers
WO2017004527A1 (en) 2015-07-02 2017-01-05 Nasdaq, Inc. Systems and methods of secure provenance for distributed transaction databases
US9871775B2 (en) 2015-08-10 2018-01-16 Cisco Technology, Inc. Group membership block chain
US10402792B2 (en) 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
CN105488665A (en) 2015-11-25 2016-04-13 布比(北京)网络技术有限公司 Decentralized transaction method
CN105488675B (en) 2015-11-25 2019-12-24 布比(北京)网络技术有限公司 Block chain distributed shared general ledger construction method
US20170156018A1 (en) * 2015-11-30 2017-06-01 Le Holdings (Beijing) Co., Ltd. Method And Electronic Device For Online Tuning Application
US9948467B2 (en) * 2015-12-21 2018-04-17 Mastercard International Incorporated Method and system for blockchain variant using digital signatures
US10475030B2 (en) 2016-02-22 2019-11-12 Bank Of America Corporation System for implementing a distributed ledger across multiple network nodes
US10762504B2 (en) 2016-02-22 2020-09-01 Bank Of America Corporation System for external secure access to process data network
CN107145768B (en) 2016-03-01 2021-02-12 华为技术有限公司 Copyright management method and system
CN105827410A (en) * 2016-03-11 2016-08-03 邓迪 Block chain transmission method and system with trusted node/satellite node construction
CA3083508C (en) * 2016-06-17 2022-03-08 Jonathan WEIMER Blockchain systems and methods for user authentication
US10749684B2 (en) 2016-09-30 2020-08-18 Entrust, Inc. Methods and apparatus for providing blockchain participant identity binding
US10291627B2 (en) 2016-10-17 2019-05-14 Arm Ltd. Blockchain mining using trusted nodes
US10540652B2 (en) 2016-11-18 2020-01-21 Intel Corporation Technology for secure partitioning and updating of a distributed digital ledger
US10586210B2 (en) 2016-11-30 2020-03-10 International Business Machines Corporation Blockchain checkpoints and certified checkpoints
CN110050474A (en) 2016-12-30 2019-07-23 英特尔公司 The type name of subobject for the composite object in Internet of Things network and block chain
US20180220292A1 (en) * 2017-01-30 2018-08-02 Sap Se Blockchain-Based Subscription Management
US10484346B2 (en) 2017-02-07 2019-11-19 Microsoft Technology Licensing, Llc Establishment of consortium blockchain network
CN107592292B (en) 2017-07-26 2019-08-09 阿里巴巴集团控股有限公司 A kind of block chain communication method between nodes and device

Cited By (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11397708B2 (en) * 2017-02-17 2022-07-26 Nokia Technologies Oy Voting-consensus distributed ledger
US11057222B2 (en) * 2017-07-26 2021-07-06 Advanced New Technologies Co., Ltd. Digital certificate management method and apparatus, and electronic device
US11070381B2 (en) * 2017-07-26 2021-07-20 Advanced New Technologies Co., Ltd. Digital certificate management method and apparatus, and electronic device
US11218328B2 (en) 2017-07-26 2022-01-04 Advanced New Technologies Co., Ltd. Digital certificate management method and apparatus, and electronic device
US11218327B2 (en) 2017-07-26 2022-01-04 Advanced New Technologies Co., Ltd. Digital certificate management method and apparatus, and electronic device
US20190140846A1 (en) * 2017-11-03 2019-05-09 Microsoft Technology Licensing, Llc Provisioning trusted execution environment(s) based on chain of trust including platform
US11943368B2 (en) 2017-11-03 2024-03-26 Microsoft Technology Licensing, Llc Provisioning trusted execution environment based on chain of trust including platform
US11310234B2 (en) * 2017-11-16 2022-04-19 International Business Machines Corporation Securing permissioned blockchain network from pseudospoofing network attacks
US10764052B2 (en) * 2018-01-24 2020-09-01 Sensoriant, Inc. User identity and trust models in decentralized and distributed systems
US10728020B2 (en) * 2018-01-24 2020-07-28 Sensoriant, Inc. Efficient mining operations in blockchain environments with non-secure devices
US11496313B2 (en) * 2018-01-24 2022-11-08 Safelishare, Inc. User identity and trust models in decentralized and distributed systems
US10686601B2 (en) * 2018-01-24 2020-06-16 Sensoriant, Inc. Consistency and consensus management in decentralized and distributed systems
US11218315B2 (en) 2018-01-24 2022-01-04 Safeshare, Inc. System and method establishing a trust model for shared content on the internet
US11875188B2 (en) * 2018-03-26 2024-01-16 Uvue Ltd Data processing system using directed acyclic graph and method of use thereof
US20210089356A1 (en) * 2018-03-26 2021-03-25 Uvue Ltd Data Processing System using Directed Acyclic Graph and Method of use thereof
US20210160059A1 (en) * 2018-04-25 2021-05-27 Siemens Aktiengesellschaft Data processing device for processing a radio signal
US11048813B2 (en) * 2018-08-29 2021-06-29 Nucleus Vision, Llc Method and system for managing consent data in a blockchain network
WO2020081164A1 (en) 2018-10-16 2020-04-23 Microsoft Technology Licensing, Llc Database management
WO2020081163A1 (en) 2018-10-16 2020-04-23 Microsoft Technology Licensing, Llc Database management
US11017113B2 (en) 2018-10-16 2021-05-25 Microsoft Technology Licensing, Llc Database management of transaction records using secure processing enclaves
US20200133646A1 (en) * 2018-10-30 2020-04-30 International Business Machines Corporation Transformation of inter-organization process for execution via blockchain
US10929113B2 (en) * 2018-10-30 2021-02-23 International Business Machines Corporation Transformation of inter-organization process for execution via blockchain
US11474854B2 (en) 2018-10-30 2022-10-18 International Business Machines Corporation Transformation of inter-organization process for execution via blockchain
US10958438B2 (en) * 2018-10-31 2021-03-23 Advanced New Technologies Co., Ltd. Method, apparatus, and electronic device for blockchain-based recordkeeping
US11258612B2 (en) 2018-10-31 2022-02-22 Advanced New Technologies Co., Ltd. Method, apparatus, and electronic device for blockchain-based recordkeeping
US10795975B2 (en) 2018-12-04 2020-10-06 Capital One Services, Llc Version management platform
US10325079B1 (en) * 2018-12-04 2019-06-18 Capital One Services, Llc Version management platform
US10771259B2 (en) 2018-12-13 2020-09-08 Alibaba Group Holding Limited Achieving consensus among network nodes in a distributed system
US10708066B2 (en) * 2018-12-13 2020-07-07 Alibaba Group Holding Limited Achieving consensus among network nodes in a distributed system
US11394544B2 (en) * 2019-01-07 2022-07-19 Aitivity Inc. Validation of blockchain activities based on proof of hardware
CN109995850A (en) * 2019-03-05 2019-07-09 深圳前海微众银行股份有限公司 A kind of transaction processing method of block catenary system and block catenary system
US10990563B2 (en) 2019-04-11 2021-04-27 Advanced New Technologies Co., Ltd. Information read/write method and apparatus based on blockchain
US11204894B2 (en) 2019-04-11 2021-12-21 Advanced New Technologies Co., Ltd. Information read/write method and apparatus based on blockchain
US11654635B2 (en) 2019-04-18 2023-05-23 The Research Foundation For Suny Enhanced non-destructive testing in directed energy material processing
US11177938B2 (en) 2019-04-19 2021-11-16 International Business Machines Corporation Database composite endorsement
WO2020220627A1 (en) * 2019-04-29 2020-11-05 清华大学 Method and device for strong cross-domain logic isolation and secure access control in internet of things scenario
US11144537B2 (en) 2019-09-16 2021-10-12 Bank Of America Corporation System for data consensus validation in an electronic distributed server network using a screening node
CN110995860A (en) * 2019-12-17 2020-04-10 江苏扬子易联智能软件有限公司 GMP/GSP quality management platform based on controlled query block chain and management method thereof
US11410171B2 (en) 2020-07-03 2022-08-09 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain consensus method and device and electronic equipment
US11522705B2 (en) * 2020-07-28 2022-12-06 Safelishare, Inc. Testing and other data communicated using trust models in decentralized and distributed systems
US20220038284A1 (en) * 2020-07-28 2022-02-03 Sensoriant, Inc. Testing and Other Data Communicated Using Trust Models In Decentralized and Distributed Systems
CN112235360A (en) * 2020-09-26 2021-01-15 建信金融科技有限责任公司 Data sharing method, device and system based on alliance chain, electronic equipment and computer readable storage medium
US11627128B2 (en) * 2020-12-22 2023-04-11 Red Hat, Inc. Network management using trusted execution environments
US20220200985A1 (en) * 2020-12-22 2022-06-23 Red Hat, Inc. Network management using trusted execution environments
US20230370273A1 (en) * 2022-05-10 2023-11-16 Microsoft Technology Licensing, Llc Bootstrapping a code transparency system

Also Published As

Publication number Publication date
US10764259B2 (en) 2020-09-01
EP3580682B1 (en) 2021-08-04
CN115618359A (en) 2023-01-17
CN110300973B (en) 2022-11-04
US20180225448A1 (en) 2018-08-09
US20200084189A1 (en) 2020-03-12
EP3917113A1 (en) 2021-12-01
EP3580905B1 (en) 2022-02-16
EP3580682A1 (en) 2019-12-18
WO2018148069A1 (en) 2018-08-16
CN110268691A (en) 2019-09-20
EP3580905A1 (en) 2019-12-18
EP3580683A1 (en) 2019-12-18
CN110249333A (en) 2019-09-17
CN110300973A (en) 2019-10-01
US10484346B2 (en) 2019-11-19
WO2018148068A1 (en) 2018-08-16
CN110249333B (en) 2023-07-28
US11218457B2 (en) 2022-01-04
WO2018148067A1 (en) 2018-08-16
ES2909088T3 (en) 2022-05-05
CN110268691B (en) 2021-10-15
US20180227275A1 (en) 2018-08-09

Similar Documents

Publication Publication Date Title
US11218457B2 (en) Establishment of consortium blockchain network
EP3616105B1 (en) Confidentiality in a consortium blockchain network
JP7194127B2 (en) Systems and methods for addressing security-related vulnerabilities arising on off-blockchain channels during network failures
US20190305938A1 (en) Threshold secret share authentication proof and secure blockchain voting with hardware security modules
US11171774B2 (en) System for synchronizing a cryptographic key state through a blockchain
US11496327B1 (en) Secure and trustworthy bridge for transferring assets across different networks
EP3607727B1 (en) Methods and devices for establishing communication between nodes in blockchain system
US11836714B2 (en) Secure and trustworthy bridge for transferring assets across networks with different data architecture
US11893577B2 (en) Cryptographic key storage system and method
US11985262B2 (en) Secure and trustworthy bridge for transferring assets across different networks
WO2024050869A1 (en) Decentralized trust-based tee state continuity protection method under public cloud

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RUSSINOVICH, MARK;COSTA, MANUEL;KERNER, MATTHEW;AND OTHERS;SIGNING DATES FROM 20170630 TO 20171010;REEL/FRAME:043849/0956

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION