EP4237984A1 - Moteur d'accélération de réseau de machine à chaîne de blocs - Google Patents

Moteur d'accélération de réseau de machine à chaîne de blocs

Info

Publication number
EP4237984A1
EP4237984A1 EP21743337.4A EP21743337A EP4237984A1 EP 4237984 A1 EP4237984 A1 EP 4237984A1 EP 21743337 A EP21743337 A EP 21743337A EP 4237984 A1 EP4237984 A1 EP 4237984A1
Authority
EP
European Patent Office
Prior art keywords
block
transactions
hardware accelerator
packets
blockchain
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.)
Pending
Application number
EP21743337.4A
Other languages
German (de)
English (en)
Inventor
Haris Javaid
Ji Yang
Sundararajarao Mohan
Gordon John Brebner
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.)
Xilinx Inc
Original Assignee
Xilinx Inc
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
Priority claimed from US17/083,195 external-priority patent/US11743051B2/en
Priority claimed from US17/084,942 external-priority patent/US11657040B2/en
Application filed by Xilinx Inc filed Critical Xilinx Inc
Publication of EP4237984A1 publication Critical patent/EP4237984A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting 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/76—Protecting 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 in application-specific integrated circuits [ASIC] or field-programmable devices, e.g. field-programmable gate arrays [FPGA] or programmable logic devices [PLD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3236—Cryptographic 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/3239—Cryptographic 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 non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • Examples of the present disclosure generally relate to a hardware accelerator for a node in a blockchain.
  • Hyperledger Fabric is an open-source, enterprise-grade implementation platform for permissioned blockchains.
  • the transaction flow in Hyperledger Fabric follows the execute-order-validate model, where a transaction is executed first, then ordered into a block, which is finally validated and committed to the ledger (along with a state database to keep the global state of the blocks committed so far). Consequently, a Fabric network includes different types of nodes, such as peers, orderers, clients, etc., where each node has an identity provided by the Membership Service Provider (MSP).
  • MSP Membership Service Provider
  • Permissioned blockchains are blockchain networks that require access to be part of. These blockchains require transactions to be validated before they are added to the blockchain’s ledger. However, the validation process must be performed by certain nodes which often experience a bottleneck when having to validate multiple transactions. This bottleneck can limit the ability of the blockchain to quickly commit new transactions.
  • One embodiment describes a computing system that includes a processor, a memory storing a ledge of a blockchain, and a hardware accelerator.
  • hardware accelerator is configured to receive a plurality of packets corresponding to a block of transactions to be committed to the ledger, generate hashes for different components in the block of transactions, and upon determining the hashes match previously calculated hashes, generating tasks to validate the block of transactions in the hardware accelerator.
  • one of the processor or the hardware accelerator is configured to, upon determining the block of transactions is valid, commit the block of transactions to the ledger.
  • Another embodiment described herein is a computing system that includes a processor, memory storing a ledge of a blockchain, and a hardware accelerator configured to receive a block of transactions to be committed to the ledger, verify a signature of the block, validate each of the transactions in the block, and store validation results of the transactions. Further, one of the processor or the hardware accelerator is configured to commit the transactions to the ledger.
  • Another embodiment described herein is a method that includes receiving, at a hardware accelerator, a plurality of packets corresponding to a block of transactions to be committed to a ledger of a blockchain, calculating, at the hardware accelerator, hashes for different components in the block of transactions, determining, at the hardware accelerator, that the hashes match previously calculated hashes, and generating, at the hardware accelerator, tasks to validate the block of transactions.
  • Fig. 1 is a timing chart corresponding to a permissioned blockchain, according to an example.
  • Figs. 2A and 2B are block diagrams of nodes in a blockchain with a hardware accelerator, according to an example.
  • Fig. 3 illustrates an interface between a protocol processor and a block processor in the hardware accelerator, according to an example.
  • Fig. 4 is a flowchart for parsing packets to prepare data for hardware processing, according to an example.
  • Fig. 5A illustrates transmitting separate packets for each component in a block of transactions, according to an example.
  • Fig. 5B illustrates a packet for sending an individual component in a block, according to an example.
  • Fig. 6 is a block diagram of a protocol processor in a hardware accelerator, according to an example.
  • Fig. 7 is a block diagram of a block extractor in a protocol processor, according to an example.
  • Fig. 8 is a flowchart for validating transactions before committing the transactions into a blockchain ledger, according to an example.
  • Fig. 9 is a block diagram of the block processor, according to an example.
  • Fig. 10 is a block diagram of a block validate, according to an example.
  • Fig. 11 illustrates communication between registers in the hardware accelerator and a CPU, according to an example DETAILED DESCRIPTION
  • Embodiments herein describe a hardware accelerator (e.g., a network acceleration engine or a compute acceleration engine) for a blockchain machine or node.
  • the hardware accelerator parses packets containing separate components of a block of transactions to generate data to perform a validation process. That is, data transmitted using a network protocol (e.g., TCP (Transmission Control Protocol)) is typically ill suited to be used by a hardware accelerator without the packets first being processed by software.
  • TCP Transmission Control Protocol
  • the embodiments herein describe a protocol processor in the hardware accelerator that parses the packets and prepares the data so it can be consumed by downstream components in the accelerator without software intervention. These downstream components can then perform a validation operation to validate one or more transactions before those transactions are committed (i.e. , added) to a ledger of a permissioned or permissionless blockchain.
  • the blockchain may include multiple peer-nodes, each of which contains standard software running on a server or container.
  • Some peer-nodes known as validator nodes are the main bottleneck for system performance because they need to validate a block of several tens or hundreds of transactions quickly before those transactions can be committed into the blockchain ledger.
  • the hardware accelerator can validate the transactions in a fraction of the time.
  • the peer-node software gathers the validation results from the hardware accelerator and combines the results with received block data to derive the block, which is then committed to the stored ledger.
  • a node with the hardware accelerator when coupled to a networking acceleration engine, achieved more than 10x improvement in transaction commit throughput compared to a software only peer executing on a multi-core server.
  • Fig. 1 is a timing chart corresponding to a permissioned blockchain 100, according to an example. While the timing chart of the permissioned blockchain 100 in Fig. 1 specifically pertains to the Hyperledger Fabric, the embodiments herein can apply to any type of permissioned blockchain. Further, the embodiments herein may also apply to non-permissioned blockchains that perform a validation process on transactions before those transactions are committed to the ledger. Thus, the Hyperledger Fabric is provided as just one example of a suitable blockchain network that can benefit from the hardware accelerator described below.
  • the transaction flow in the blockchain 100 follows an execute-order-validate model, where a transaction is executed first, then ordered into a block, which is finally validated and committed to the ledger (along with a state database to keep the global state of the blocks committed so far). Consequently, the permissioned blockchain 100 includes different types of nodes, such as peers, orderers, clients, etc., where each node has an identity provided by the MSP. This identify can be provided in the form of a certificate.
  • the client can be any entity that submits a transaction to be committed on the blockchain 100.
  • the blockchain 100 is used by a financial institution to track money transfers, the client may submit a transaction to move funds from a first account to a second account (at the same financial institution or a different institution).
  • the client submits a transaction to be committed to the blockchain.
  • the transaction is received on multiple endorsing nodes (or peers).
  • An endorsing node both executes/endorses transactions and validates/commits blocks to the ledger.
  • Each endorsing node executes the transaction against its own state database, to compute the read-write set of the transaction (marked as E in Fig. 1 ).
  • the read set is the keys accessed and their version numbers, while the write set is the keys to be updated with their new values.
  • the endorsing nodes add their endorsement to the transaction and return the transaction to the client.
  • the client asks an ordering service to submit the transaction to a validation process.
  • the ordering service includes orderers (e.g., computing nodes) which use a consensus mechanism to establish a total order for the transactions.
  • Multiple pluggable consensus mechanisms are available, such as Raft and Apache Kafka/Zookeeper based consensus mechanisms.
  • the ordering service responds back to the client after the transaction has been accepted for inclusion into a block (step 4).
  • the ordering service then creates a block 105 of transactions from the ordered transactions.
  • the ordering service creates the block 105 from the ordered transactions when either a user-configured timeout has expired or user-configured limit on block size is reached.
  • the ordering service broadcasts it to all the endorsing and non-endorsing nodes through, e.g., a Gossip protocol at step 5.
  • Each node validates all the transactions in the block 105 and then commits the block to the ledger and state database (marked as V).
  • V ledger and state database
  • one of the nodes sends a notification to the client that the transaction has been committed or whether the transaction was marked as invalid or valid in the ledger (step 6).
  • Fig. 1 shows a validation workflow 110 of the validation phase in more detail on the right-hand side.
  • the workflow 110 shows four steps which are performed on every node that receives the block 105.
  • the node checks the syntactic structure of the block and verifies its signature, and then sends it through a pipeline of various operations which are described in more detail blow.
  • each transaction in the block is syntactically checked and its signature is verified.
  • validation system chaincode (VSCC) is run on each transaction where the endorsements are validated and the endorsement policy of the associated chaincode is evaluated. A transaction is marked as invalid if its endorsement policy is not satisfied.
  • step 3 a multi-version concurrency control (MVCC) check is performed.
  • MVCC multi-version concurrency control
  • This check ensures that there are no read-write conflicts between the valid transactions. In other words, it avoids the double-spending problem where two transactions are committed when only one transaction was intended.
  • the read set of each transaction is computed again by accessing a state database (illustrated as “statedb” in Fig. 1 ) and is compared to the read set from the endorsement phase. If these read sets are different, then some other transaction (either in this block 105 or an earlier block) has already modified the same keys, and hence this transaction is marked as invalid.
  • the block is committed to the stored ledger at the node.
  • the entire block is first written to the ledger with its transactions' valid/invalid flags. Then, the write sets of the valid transactions are committed to the state database.
  • Figs. 2A and 2B are block diagrams of nodes 200 in a blockchain with a hardware accelerator 210, according to an example.
  • the node 200 is any computing system that performs a validation process when committing transactions to a blockchain.
  • the node 200 may be an endorsing or non-endorsing node or peer as shown in Fig. 1 .
  • the node 200 is a server or other computing system.
  • the node 200A includes a CPU 205, the hardware accelerator 210, and memory 235.
  • the CPU 205 represents any number of processors that each can contain any number of processing cores.
  • the memory 235 represents volatile memory, non-volatile memory (e.g., a hard disk drive), and combinations thereof. As shown, the memory 235 stores a ledger 240 which lists the committed transactions of a blockchain.
  • the hardware accelerator 210 contains various circuit elements for performing the validation workflow 110 illustrated in Fig. 1.
  • the hardware accelerator 210 is an integrated circuit.
  • the hardware accelerator 210 is a board (e.g., a printed circuit board (PCB) such as a PCIe card) on which one or more integrated circuits are mounted.
  • the integrated circuit is a field programmable gate array (e.g., FPGA) or a system on a chip (SoC) that comprises programmable logic.
  • the various circuit blocks in the accelerator 210 are implemented in programmable logic.
  • the integrated circuit may be an application specific integrated circuit (ASIC) where the circuit blocks of the accelerator 210 are implemented only in hardened circuitry. While using an FPGA and SoC with programmable logic gives the accelerator 210 the flexibility to be reprogrammed if the validation process is changed, using an ASIC may save space.
  • ASIC application specific integrated circuit
  • the accelerator 210 includes a network interface 215 for receiving Ethernet packets containing data regarding the transactions, a protocol processor 220 for reformatting the data, a block processor 225 for performing the validation workflow, and a register map 230 (reg_map) (e.g., memory registers) which store the results of the validation.
  • the protocol processor 220, the block processor 225, and the register map 230 are discussed in more detail below.
  • these hardware blocks work together to validate a received block of transactions. That is, the network interface 215 receives multiple packets which include data corresponding to a block of transactions. Because this data may be in a format that is unsuitable for processing, the protocol processor 220 can reformat and output the data for the block processor 225 for consumption.
  • the block processor 225 performs most of the steps in the validation workflow, some of these steps may be performed by the protocol processor 220 and the register map 230.
  • the node 200A may rely on the CPU 205 to commit validated transactions to the ledger 240. That is, the accelerator 210 can store the validation results in the register map 230 which the CPU 205 can evaluate and then commit the transactions the ledger. That is, in one embodiment all the transactions are committed to the ledge but the validation flags store the information about which ones were valid and which were invalid. However, for the state database (which is discussed below), only successfully validated transactions are committed. While most of the validation is performed in the hardware accelerator 210, committing the transactions to the ledger 240 may be performed by software executing on the CPU 205.
  • Fig. 2B illustrates a node 200B that is the same as the node 200A in Fig. 2A except for the addition of a network interface card (NIC) 245.
  • the NIC 245 provides the node 200B with the ability to determine what network traffic flows through the accelerator 210 and what network traffic flows through the NIC 245.
  • all traffic related to the blockchain may be sent through the accelerator 210 while received network traffic that is not related to the blockchain is processed by the NIC 245.
  • all the network traffic received by the node 200A (whether blockchain or non-blockchain traffic) may be received at the accelerator 210.
  • the protocol processor 220 may forward the network traffic related to validation to the block processor 225 but forward all other traffic to the CPU 205.
  • the accelerator 210 receives only the network traffic related to validating transactions at the accelerator 210 while all other traffic (whether it is other types of blockchain traffic such as an endorsement request, or non-blockchain traffic) is received and processed by the NIC 245.
  • the accelerator 210 may perform all blockchain operations without the aid of the CPU 205.
  • the NIC 245 and the CPU 205 are not used to perform blockchain tasks, although the CPU 205 may be used to configure or control the accelerator 210.
  • all network traffic goes through the accelerator 210 which processes the blockchain related packets but forwards other packets to/from the CPU 205.
  • Fig. 3 illustrates an interface 300 between a protocol processor and block processor in the hardware accelerator, according to an example.
  • the interface 300 is used to transmit block data, transaction data (labeled as tx data in Fig. 3), endorsement data, read set data, and write set data to the block processor 225.
  • the protocol processor 220 receives Ethernet packets from other nodes in the blockchain (e.g., from orderers in the ordering service) that contain the information used to validate a block of transactions.
  • the protocol processor 220 then reformats/parses the data so that it can be consumed by the block processor 225.
  • Fig. 4 is a flowchart of a method 400 for parsing packets to prepare data for hardware processing, according to an example.
  • the blocks in the method 400 are discussed in parallel with the Figures below.
  • the network interface in the accelerator receives packets containing separate components of a block of transactions. Because the block is typically too large to send in a single packet (e.g., a block can be more than a megabyte), the software applications relies on the network protocol or a software driver to chunk the block into multiple packets. However, the network protocol/driver typically has no knowledge of how the data is structured in the block, and thus, data is typically transmitted in an ad hoc manner. This makes it difficult if not impossible for a hardware accelerator to then parse the received packets and reconstruct the block of transactions. However, the embodiments herein describe techniques for transmitting the block of transactions so that a hardware accelerator can parse the packets in order to reconstruct the different components in the block of transactions.
  • Fig. 5A illustrates transmitting separate packets for each component in a block 505 of transactions, according to an example.
  • a sender 515 e.g., an orderer or other peer node in the blockchain
  • packets 520 to the hardware accelerator 210 so that these packets can be accurately parsed so that the block message 505 can be reconstructed.
  • software in the sender 515 divides the block message 505 into its separate block components 510 shown here as a header, transactions (TX) 1 -5 and metadata. That is, rather than relying on a network protocol or driver to determine how to divide the data in the block message 505 into separate packets, the software on the sender 515 (which is aware of the structure of the block 505) can separate the block into its components 510.
  • Fig. 5A illustrates the sender 515 transmitting the packets 520A-520G to the hardware accelerator 210 over a network, e.g., a private or public network, such as the Internet.
  • each packet 520 includes only one of the components 510 - i.e., the packet 520A includes the header of the block 505, the packets 520B- 520F each include one of the transactions, and the packet 520G includes the metadata of the block 505.
  • the network protocol or driver may have sent a first packet that included the header and a portion of TX1 , a second packet that included the remaining data of TX1 and a portion of TX2, and so forth. This unpredictable bifurcation of the different components 510 in the block 505 may make it difficult to design a hardware accelerator 210 to parse the data so the block 505 can be reconstructed.
  • the sender 515 may remove signed certificates associated with the components 510. These certificates may be used to validate the block 505 and the transactions within the block. However, these certificates (e.g., x509 certificates) are large, which means transmitting them to the accelerator 210 requires a significant amount of bandwidth.
  • the sender 515 removes the certificates from the block 505 before forming the packets 520 that are then sent to the accelerator 210. Instead, the sender 515 can replace the certificates with an ID (e.g., an 8-bit code).
  • the sender 515 transmits the certificates separately to the accelerator 210 one time which can then store the certificates in a cache for later retrieval. In this manner, the certificates are sent once rather than repeatedly if they are associated with multiple components 510 in the block 505.
  • Fig. 5B illustrates a packet 520 for sending an individual component in a block, according to an example.
  • the 520 includes L2 and IP/IIDP data, a transport header 525, a block machine protocol header 530, and a block message payload 535.
  • the transport header 525 can include a sequence number (Seq), acknowledgement number (Ack), and control data (Ctrl).
  • the sequence number indicates where the packet is in the sequence of packets representing the block 505.
  • the acknowledgement number is used by the accelerator 210 when generating an Ack packet to transmit back to the sender 515.
  • the control data can include such information as the application level protocol failure and receiver buffer status.
  • the block machine protocol header 530 includes a message type (MsgType) and annotations.
  • the message type indicates whether the data in the payload 535 is a block header, a transaction, or metadata.
  • the annotations point out the position of important data.
  • the annotations may include a pointer that points to relevant data in the packet 520 (e.g., where certain data in the payload 535 can be found) and a locator that points to data in a cache or in a different packet (but same block).
  • a locator in the annotations is used to mark the ID for the packet 520.
  • the payload 535 can include the data corresponding to the particular component 510 being sent in the packet - i.e. , metadata from the block 505.
  • each packet 520 contains one of the components 510 of the block 505
  • this provides the advantage that the accelerator 210 can begin to process the data before receiving all the packets 520 of the block. That is, instead of waiting for software to receive all the packets and then reconstruct the block 505 for validation, the accelerator 210 can process the transactions as they come in. For example, the protocol processor can parse the packet 520B corresponding to TX1 before the packet 520C containing TX2 is received at the accelerator 210. Thus, the accelerator 210 can begin to process the transactions much sooner than a software solution where all the packets must be received before the transactions can be reconstructed and validated.
  • Fig. 6 is a block diagram of the protocol processor 220 in the hardware accelerator, according to an example.
  • the data packets 520 are received at a packet filter 610 that parses the Levels 4-7 (L4-L7) packet headers (e.g., the block machine protocol header 530) to extract the message type and the annotations.
  • the message type may include the block start, the block metadata, transaction, etc.
  • the annotations for the message payload can include position of the block header, the location of the block signatures, block ID, transaction data start, channel name, transaction ID, chaincode name, creator certificate authority (CA) ID, transaction action, transaction CA ID, contract name, contract input, endorser action, read/write set, endorser list, transaction signature, orderer CA ID, orderer signature, certificate ID, certificate public key data, state valid since information, state valid through information, and the like.
  • the packet filter 610 also identifies the sequence number in the transport header and forwards this number to a response generator 605 which transmits response packets (e.g., an acknowledgement packet) back to the sender (e.g., the orderer).
  • the packet filter 610 forwards the message type, annotations, and packet payload to a block extractor 615 which processes the message payload based on the annotations and extracts relevant data for the block processor 225.
  • the block extractor 615 also provides a message valid signal for the response generator 605 so the generator 605 can inform the sender whether the block and its transactions are valid or invalid.
  • the details of the block processor 225 are discussed in the remaining portions of the method 400 and the figures below.
  • the block extractor in the protocol processor identifies signed certificates corresponding to the packets using IDs in the packets.
  • the sender may strip the certificates from the block before transmitting the block in a plurality of packets to the hardware accelerator. This may be done since the certificates are large, and rarely change. Thus, replacing the certificates with a much smaller ID or key in the packets that refer to the certificates may save significant bandwidth and ensure that each component in the block of transactions can be sent in a single packet.
  • the block extractor may need the certificates in order to validate the block (and the transactions in the block) and to ensure the syntax of the block and transaction is correct. Thus, the block extractor may reconstruct the components, which means the block extractor identifies and retrieves the certificates.
  • Fig. 7 is a block diagram of the block extractor 615, according to an example.
  • the block extractor 615 includes a data insertor 705 that receives the packet payload and the annotations to identify the certificate (or certificates) corresponding to that payload.
  • the payload may include an ID corresponding to a certificate of the orderer that prepared the block.
  • the payload may include an ID corresponding to the client that submitted the transaction and one or more IDs corresponding to endorsing nodes that endorsed the transaction.
  • the data insertor 705 may identify multiple IDs in the payload.
  • the data insertor 705 uses the IDs to retrieve the signed certificates corresponding to the IDs. That is, when an orderer sends certificates to the accelerator, the accelerator stores those certificates (and their corresponding IDs) in the identity cache 710 so that these certificates can then be retrieved when validating a block of transactions.
  • the block extractor 615 reconstructs the separate components of the block. That is, as each payload is received, the block extractor 615 can retrieve the corresponding certificate. This is shown in Fig. 7 where the data insertor 705 transmits the retrieved certificate (or certificates) along with the other data in the payload to a data extractor 715.
  • the data extractor 715 may reconstruct the components in the block of transactions at different times. For example, during Time 1 , the data extractor 715 reconstructs the header of the block using a first received packet, at Time 2, the data extractor 715 reconstructs the first transaction in the block using a second received packet, and so forth.
  • the block extractor 615 can be pipelined so that different components in the block can be executing at different stages (e.g., different circuit modules) in the extractor 615 in parallel.
  • a hash calculator 720 calculates hashes for the separator components in the block. In one embodiment, the hash calculator 720 generates a hash for the entire block, every transaction of the block, and every endorsement of each transaction.
  • the hash calculator 720 may generate these hashes at different times. For example, the hash calculator 720 can generate a hash for a particular transaction (and hashes for all the endorsements associated with that transaction) when it receives a packet corresponding to the transaction. However, the hash calculator 720 may wait to calculate a hash for the entire block after it has received all the packets for the block.
  • a hash checker 725 determines whether the hashes calculated by the hash calculator 720 match hashes in the packets. That is, the packets transmitted by the sender may contain previously calculated hashes (or at least pointers to hashes) that can be compared to the hashes generated by the hash calculator 720. For example, the sender may calculate hashes for the block, each transaction in the block, and each endorsement in the transactions and transmit those hashes to the accelerator 210. If those hashes match the local hashes generated by the hash checker 725, this means the messages are valid and the proper syntax for the block and transactions has been followed. If the hashes do not match, the method proceeds to block 445 where the hardware accelerator indicates the received data has a syntax error. In one embodiment, the hardware accelerator sends a reply message to the sender indicated the validation process has failed.
  • the method 400 proceeds to block 430 where the hardware accelerator indicates the received data was successfully parsed.
  • the response generator 605 in Fig. 6 transmits a reply or acknowledge (ACK) message to the sender indicating the block of transactions has been successfully received and processed by the protocol processor 220.
  • ACK reply or acknowledge
  • a task generator 730 generates tasks for the block processor in order to complete the validation process.
  • the task generator 730 generates block tasks, transaction tasks, and endorser tasks.
  • the block tasks may include a block ID, block signature (e.g., the certificate of the orderer that generated the block), etc.
  • the transaction tasks may include a transaction ID, transaction signature (e.g., the certificate of the client that generated the transaction), transaction read/write sets, etc.
  • the task generator 730 generates a transaction task for each transaction in the block.
  • the task generator 730 can also generate an endorser task for each endorsement in a transaction. That is, because each transaction can receive several endorsements, the task generator 730 may generate a task for each of those endorsements.
  • the task generator 730 forwards the tasks and corresponding data to the block processor in the hardware accelerator.
  • the block processor can then validate the block, transactions, and the endorsements.
  • the protocol processor (and its circuit components illustrated in Figs. 5-7) parses the received packets to reformat the data of the block into a format that can be digested or processed by the block processor without the help of software.
  • the validation process in a blockchain can be performed entirely by hardware, thereby reducing the time and compute resources needed for this process.
  • Fig. 8 is a flowchart of a method 800 for validating transactions before committing the transactions into a blockchain ledger, according to an example.
  • the different stages in the method 800 are described in tandem with Figs. 9-11 below. Further, the stages in the method 800 correlate to the steps 1-4 of the validation workflow 110 illustrated in Fig. 1.
  • the method 800 assumes that the hardware accelerator has already received a block of transactions from, e.g., an ordering service that need to be validated before they can be committed to the ledger. Further, the method 800 assumes that the protocol processor has performed a block syntax check (e.g., “blk syntax check” in Fig. 1 ) and a transaction syntax check (e.g., “tx syntax check” in Fig. 1 ) to confirm that all the required data for performing validation has been received.
  • a block syntax check e.g., “blk syntax check” in Fig. 1
  • a transaction syntax check e.g., “tx syntax check” in Fig. 1
  • the hardware accelerator verifies the signature on a block of transactions. More specifically, the block processor receives the information shown in Fig. 3 from the protocol processor so it can perform block verification. As shown in Fig. 9, the block processor 225 includes two hardware sub-modules: block verify 905 and block validate 910.
  • the block verify 905 includes an elliptic curve digital signature algorithm (ECDSA) engine 920 for verifying that the orderer signature on the block. Put differently, the ECDSA engine 920 compares a received signature in the block to a known signature (e.g., certificate) for the orderer to ensure they match. That way, the block verify 905 can confirm that the block of transactions came from an approved node. While an ECDSA engine 920 is shown, any suitable signature algorithm engine can be used.
  • ECDSA elliptic curve digital signature algorithm
  • the block data received at the block verify 905 can also include a block number, the number of transactions in the block, and the like.
  • the hardware accelerator validates the plurality of transactions in the block.
  • this function is performed by the block validate 910. That is, while the block verify 905 ensures the block was received by a known orderer, the block validate 910 validates the individual transactions in the block. To do this, the block validate 910 receives the transaction data, endorsement data, read set data, and the write set data from the protocol processor (not shown in Fig. 9). The block validate 910 then outputs block validation data which contains validation results such as the block number, valid/invalid transaction flags, latency, and the like.
  • the block verify 905 and block validate 910 are pipelined at a block-level. That is, the block processor 225 can processes a first block of transactions at the block verify 905 (pipeline stage 1 ) while the block validate 910 processes a second block of transactions (pipeline stage 2). Put differently, the block verify 905 can use the ECDSA engine 920 to ensure an authorized orderer transmitted the first block at the same time the block validate 910 validates the individual transactions in a second block.
  • the block processor 225 also includes a block monitor 915 which gathers block-level and transaction-level statistics by monitoring signals received from the block verify 905 and the block validate 910. For example, the block monitor 915 may determine the time or latency required to validate the blocks of transactions, or the throughput of the block processor 225 (e.g., the number of blocks processed per unit of time).
  • stages 815-825 of the method 800 correspond to the pipeline stages 2a, 2b, and 2c in Fig. 10 which illustrates a more detailed view of the block validate 910 in Fig. 9.
  • the first pipeline stage 2a in the block validate 910 verifies the signature of each transaction.
  • the stage 2a includes multiple transaction verify blocks 1005 which each include an ECDSA engine 1035.
  • These engines 1035 verify the signature of the client (or creator) of the transaction. That is, the ECDSA engines 1035 ensure the transaction was signed by a known client by comparing the received signature to a signature calculated based on tx data and creator’s public key pair.
  • stage 2a can validate the client signatures for multiple transactions in parallel. It is a design choice to determine how many of the transaction verify blocks 1005 the block validate 910 includes. Having additional transaction verify blocks 1005 means stage 2a can process more transactions in parallel but at a cost of using additional space and power in the accelerator.
  • the block validate 910 verifies the endorsements of each transaction using an endorsement policy.
  • the pipeline stage 2b includes multiple transaction VSCC blocks 1010 that each includes multiple ECDSA engines 1015 (or any other type of signature verification engine) and an endorsement policy evaluator 1020.
  • the transaction VSCC blocks 1010 each verifies the endorsements of a particular transaction. To do so, the transaction VSCC blocks 1010 receive the endorsement data which includes an endorser ID and verification data. Because a client transaction may receive multiple endorsements (as shown in Fig. 1 ), each ECDSA engine 1015 can evaluate one of the endorsements in parallel.
  • the ECDSA engine 1015A can verify that the first endorsement was signed by an approved endorsing node at the same time the ECDSA engine 1015B verifies that the second endorsement was signed by an approved endorsing node.
  • the number of ECDESA engines 1015 in each block 1010 is a design choice.
  • the endorsement policy evaluator 1020 may maintain endorsement policies on a per-chaincode basis. The evaluator 1020 confirms that the transaction has received the appropriate endorsements. That is, assuming the endorsements were given by approved endorsing nodes, the evaluator 1020 confirms the transaction received endorsements from the appropriate endorsing nodes. For example, if the transaction indicates that money should be transferred between two banks, the evaluator 1020 may check to ensure the transaction received endorsements from endorsing nodes operated by both of those banks. If the transaction was endorsed by endorsing nodes for only one bank, or by a different bank not affected by the transaction, the evaluator 1020 may invalidate the transaction.
  • stage 2b include multiple transaction VSCC blocks 1010
  • the block validate 910 can verify the endorsements for multiple transactions in parallel. That is, after stage 2a verifies that the transactions were originated by approved clients, stage 2b can verify that the endorsements for the transactions are valid and satisfy one or more endorsement policies.
  • the number of transaction VSCC blocks 1010 in the block validate 910 is a design choice.
  • stage 825 the block validate 910 performs version check and commits write keys to a state database 1030.
  • stage 2c which includes a transaction MVCC write block 1025 which is communicatively coupled to the state database 1030 and the register maps (not shown in Fig. 10). Further, the register maps are optionally coupled to a CPU (not shown) in the node.
  • the transaction MVCC write block 1025 looks up read keys from the state database 1030 to perform the version check, and if confirmed, commits updated write keys of valid transactions to the database 1030.
  • the transaction MVCC write block 1025 receives the read set data (where each element contains a read key-version pair) and the write set data (where each element contains a write key-value pair) from the protocol processor.
  • the state database 1030 includes an internal lock mechanism to disallow reading of the key that is current being written (or updated).
  • the stages 2a-2c in Fig. 10 can be pipelined. That is, while Fig. 9 illustrates a block-level pipeline between the block verify 905 and the block validate 910, Fig. 10 illustrates that a transaction-level pipeline where the transactions in a particular block can be processed in parallel in the stages 2a-2c. That is, stage 2a can process a first set of transactions in a block, while stage 2b processes a second set of transactions in the same block, and stage 2c processes a third set of transactions in the same block.
  • the block validate 910 may process only transactions from the same block. That is, one stage in the block validate 910 may not be able to process transactions from a first block while a different stage processes transactions from a second block.
  • the block validate 910 stores results of performing the validation process in the registers (e.g., the register map230).
  • the register map receives block validation data from the block validate 910 which may contain block number, valid/invalid transaction flags, latency (as measured by the block monitor), and the like.
  • the validation results are written in the register map where the CPU 205 can use an AXI-lite or a PCIe interface to access the validation results.
  • new validation results cannot be written into the register map 230 until the currently stored validation results have been read out by the CPU 205.
  • Fig. 11 illustrates a system 1100 where the register map 230 in the hardware accelerator is accessible by the CPU 205, as mentioned above, the accelerator may not use the CPU 205, and can instead complete the validation process without the aid of software executing on the CPU 205.
  • the CPU (or the hardware accelerator) informs the client whether the transactions are valid or invalid. That is, the CPU can evaluate the validation results to determine whether each individual transaction in the block of transactions was validated. The client may then choose to resubmit the invalid transactions.
  • the transactions are committed to the ledger.
  • both the valid and invalid transactions are committed to the ledger, and can include valid/invalid flags to indicate whether the committed transactions are valid or not.
  • aspects disclosed herein may be embodied as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
  • a computer readable storage medium is any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus or device.
  • a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
  • a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
  • Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages.
  • the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
  • the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • LAN local area network
  • WAN wide area network
  • Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
  • These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
  • the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s).
  • the functions noted in the block may occur out of the order noted in the figures.
  • two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
  • Example 1 An integrated circuit for accelerating a validation process for a blockchain, comprising: a network interface configured to receive a plurality of packets containing a block of transactions from a node in the blockchain; a protocol processor configured to parse the plurality of packets to generate data regarding the transactions; and a block processor configured to: verify a signature of the block; validate each of the transactions in the block; and store validation results of the transactions.
  • Example 2 The integrated circuit of example 1 , wherein the integrated circuit comprises at least one of a system on a chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).
  • SoC system on a chip
  • FPGA field programmable gate array
  • ASIC application specific integrated circuit
  • Example 3 The integrated circuit of example 2, wherein the SoC or FPGA comprises programmable logic.
  • Example 4 The integrated circuit of example 2, wherein the ASIC comprises only hardened circuitry.
  • Example 5 The integrated circuit of example 1 , wherein the block processor comprises: a block verify comprising a first signature algorithm engine configured to verify that the signature of the block matches a known signature of an orderer in the blockchain; and a block validate configured to validate each of the transactions in the block.
  • Example 6 The integrated circuit of example 5, wherein the block validate comprises: a transaction verify module comprising a second signature algorithm engine configured to verify that signatures corresponding to the transactions match known signatures of clients authorized to use the blockchain; a transaction validation system chaincode (VSCC) block comprising: a third signature algorithm engine configured to verify that endorsements in the transactions were signed by known endorsing nodes in the blockchain; and an endorsement policy evaluator configured to ensure the endorsements satisfy an endorsement policy; and a transaction multi-version concurrency control (MVCC) write block configured to read and write key-value pairs associated with the transactions in a state database.
  • a transaction verify module comprising a second signature algorithm engine configured to verify that signatures corresponding to the transactions match known signatures of clients authorized to use the blockchain
  • VSCC transaction validation system chaincode
  • MVCC transaction multi-version concurrency control
  • Example 7 The integrated circuit of example 6, wherein the block validate comprises: a plurality of transaction verify modules configured to operate in parallel to verify signatures of a first set of the transactions; and a plurality of transaction VSCC blocks configured to operate in parallel to verify endorsements of a second set of the transactions, wherein the plurality of transaction verify modules form a first stage of a pipeline and the plurality of transaction VSCC blocks form a second stage of the pipeline such that the plurality of transaction verify modules processes the first set of transactions at the same time the plurality of transaction VSCC blocks processes the second set of transactions.
  • Example 8 The integrated circuit of example 7, wherein each of the plurality of transaction verify modules comprises a plurality of algorithm signature engines for verifying a set of endorsements in one of the transactions in parallel.
  • Example 9 The integrated circuit of example 2, wherein the block verify forms a first stage in a pipeline while the block validate forms a second stage in the pipeline such that the block verify can process a first block of transactions for the blockchain at the same time the block validate processes a second block of transactions for the blockchain.
  • Example 10 A method, comprising: receiving, at a hardware accelerator, a block of transactions to be committed to a ledger of a blockchain; verifying, at a hardware accelerator, a signature of the block; validating, at a hardware accelerator, each of the transactions in the block; storing, at a hardware accelerator, validation results of the transactions; and committing the transactions to the ledger and indicating whether the transactions are valid based on the validation results.
  • Example 11 The method of example 10, wherein receiving the block of transactions comprises receiving a plurality of packets comprising the block of transactions, the method further comprising: parsing, at the hardware accelerator, the plurality of packets to generate data regarding the transactions.
  • Example 12 The method of example 10, wherein validating each of the transactions in the block further comprises: verifying that the signature of the block matches a known signature of an orderer in the blockchain.
  • Example 13 The method of example 10, wherein validating each of the transactions in the block further comprises: verifying that endorsements in the transactions were signed by a known endorsing node in the blockchain; and ensuring the endorsements in the transactions satisfy an endorsement policy.
  • Example 14 An integrated circuit for accelerating a validation process for a blockchain, comprising: a data insertor configured to receive a plurality of packets corresponding to a block of transactions to be committed to a ledger of the blockchain; a hash calculator configured to generate hashes for different components in the block of transactions; a hash checker configured to determine that the hashes match previously calculated hashes; and a task generator configured to generate tasks to validate the block of transactions.
  • Example 15 The integrated circuit of example 14, wherein the integrated circuit comprises at least one of a system on a chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).
  • SoC system on a chip
  • FPGA field programmable gate array
  • ASIC application specific integrated circuit
  • Example 16 The integrated circuit of example 15, wherein the SoC or FPGA comprises programmable logic.
  • Example 17 The integrated circuit of example 15, wherein the ASIC comprises only hardened circuitry.
  • Example 18 The integrated circuit of example 14, wherein the block of transactions comprises a block header, a plurality of transactions, and metadata, wherein the block header, each of the plurality of transactions, and the metadata are sent in a separate one of the plurality of packets, wherein the plurality of packets do not contain signed certificates corresponding to the block or the plurality of transactions.
  • Example 19 The integrated circuit of example 18, further comprising: an identity cache storing local copies of the signed certificates corresponding to approved nodes in the blockchain, wherein the data insertor is configured to retrieve signed certificates corresponding to the block of transactions from the identity cache using IDs included in the plurality of packets.
  • Example 20 The integrated circuit of example 19, further comprising: a data extractor configured to reconstruct the block of transactions using data in the plurality of packets and the retrieved signed certificates, wherein the hash calculator is configured to generate the hashes using the reconstructed block of transactions, and wherein the hash checker is configured to check whether the generated hashes match the previously calculated hashes in order to ensure the block of transactions does not contain a syntax error.
  • a data extractor configured to reconstruct the block of transactions using data in the plurality of packets and the retrieved signed certificates
  • the hash calculator is configured to generate the hashes using the reconstructed block of transactions
  • the hash checker is configured to check whether the generated hashes match the previously calculated hashes in order to ensure the block of transactions does not contain a syntax error.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Des modes de réalisation de la présente invention concernent un accélérateur matériel (par exemple, un moteur d'accélération de réseau) pour une machine à chaîne de blocs ou un nœud. L'accélérateur matériel analyse des paquets contenant des composants séparés d'un bloc de transactions pour générer des données pour effectuer un processus de validation. Pour éviter la latence inhérente à l'utilisation de logiciel, les modes de réalisation de la présente invention décrivent un processeur de protocole dans l'accélérateur matériel qui analyse les paquets et prépare les données de sorte qu'elles peuvent être consommées par des composants en aval dans l'accélérateur sans intervention de logiciel. Ces composants en aval peuvent ensuite effectuer une opération de validation pour valider une ou plusieurs transactions avant que ces transactions ne soient engagées (c'est-à-dire, ajoutées) à un registre d'une chaîne de blocs autorisée.
EP21743337.4A 2020-10-28 2021-06-22 Moteur d'accélération de réseau de machine à chaîne de blocs Pending EP4237984A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/083,195 US11743051B2 (en) 2020-10-28 2020-10-28 Blockchain machine compute acceleration engine with a block verify and a block validate
US17/084,942 US11657040B2 (en) 2020-10-30 2020-10-30 Blockchain machine network acceleration engine
PCT/US2021/038528 WO2022093335A1 (fr) 2020-10-28 2021-06-22 Moteur d'accélération de réseau de machine à chaîne de blocs

Publications (1)

Publication Number Publication Date
EP4237984A1 true EP4237984A1 (fr) 2023-09-06

Family

ID=76972009

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21743337.4A Pending EP4237984A1 (fr) 2020-10-28 2021-06-22 Moteur d'accélération de réseau de machine à chaîne de blocs

Country Status (4)

Country Link
EP (1) EP4237984A1 (fr)
JP (1) JP2023547817A (fr)
KR (1) KR20230097062A (fr)
WO (1) WO2022093335A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10761877B2 (en) * 2017-07-21 2020-09-01 Intel Corporation Apparatuses, methods, and systems for blockchain transaction acceleration
US10928847B2 (en) * 2018-09-29 2021-02-23 Intel Corporation Apparatuses and methods for frequency scaling a message scheduler data path of a hashing accelerator

Also Published As

Publication number Publication date
WO2022093335A1 (fr) 2022-05-05
JP2023547817A (ja) 2023-11-14
KR20230097062A (ko) 2023-06-30

Similar Documents

Publication Publication Date Title
US11196542B2 (en) Checkpointing for increasing efficiency of a blockchain
US10938567B2 (en) Parallel-chain architecture for blockchain systems
US11334439B2 (en) Checkpointing for increasing efficiency of a blockchain
US10901957B2 (en) Checkpointing for increasing efficiency of a blockchain
US20210326867A1 (en) Fork-Tolerant Consensus Protocol
US20190354518A1 (en) Chain mesh network for decentralized transaction systems
US11249947B2 (en) Distributed digital ledger transaction network for flexible, lazy deletion of data stored within an authenticated data structure
US20230104717A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
US20200028667A1 (en) Blockchain-Based Unexpected Data Detection
US12118556B2 (en) Database configuration for asset transfers
US20180308091A1 (en) Fairness preserving byzantine agreements
US20200396072A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
CN109493203A (zh) 一种数据核算方法、装置及存储介质
US11953984B1 (en) Systems and methods for blockchain repair assurance tokens
US20190268153A1 (en) Event execution using a blockchain approach
US20200394162A1 (en) Operation management method for distributed ledger system, operation management system for distributed ledger system, and operation management program for distributed ledger system
CN115186304B (zh) 一种基于区块链的交易数据校验方法和系统
US11743051B2 (en) Blockchain machine compute acceleration engine with a block verify and a block validate
WO2020256998A1 (fr) Réseau de transactions de grand livre numérique distribué évolutif, sécurisé, efficace et adaptable
US20220343323A1 (en) Method and apparatus maintaining private data with consortium blockchain
US11657040B2 (en) Blockchain machine network acceleration engine
EP4237984A1 (fr) Moteur d'accélération de réseau de machine à chaîne de blocs
US20230370521A1 (en) Blockchain machine broadcast protocol with loss recovery
US20230342151A1 (en) Blockchain machine compute acceleration engine with out-of-order support
Ye et al. Specular: Towards Secure, Trust-minimized Optimistic Blockchain Execution

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230526

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)