Contents Introduction
Currently, the semiconductor industry faces high costs and time-to-market pressure [1]. However, the production improvement is often hindered due to equipment operator’s skill such as human error proofing [2], [3], personal experiences, or implicit knowledge [4]. Moreover, it is challenging to iteratively update production parameters (e.g., recipes, equipment operational parameters—hereafter referred to as ‘operational parameters’) required to stabilize or enhance equipment performance without unintended errors. To assist in this, many equipment suppliers have started to provide online support services through edge-cloud computing to help customers prevent accidental faults. For instance, CNC controllers are directly connected to cloud service platforms, a setup that is already applied to machining centers and industrial robots [5]. The cloud-based collaboration platform operates under the assumption that all participants either agree to share information or provide data that is less critical to their business. In the realm of semiconductor manufacturing, not only are the requirements for direct data exchanges increasing both within and beyond the factory integration space, but information security is also becoming an increasingly significant challenge in this domain [6].
Blockchain technology stands out as a solution for secure information sharing [7]. Practically, blockchain technology is acknowledged for its application in various domains, including cloud computing [8], supply chain management [9], vehicular networks [10], digital healthcare [11], [12], and financial transactions [13]. As widely recognized, secure information sharing is imperative in high-quality manufacturing industries for purposes such as quality control [14], process planning [15], and part traceability [16]. As a method of implementing blockchain technology, there are research cases that propose an edge computing platform integrating the data ledger with equipment controllers. For example, Kumar et al. proposed the blockchain-edge framework [17], [18]. Isaja et al. also showed the implementations of the edge ledger in truck quality control lines and plug-and-play modular factories [19], [20]. These widespread applications emphasize blockchain’s revolutionary potential to enhance traditional systems in sectors ranging from finance to manufacturing.
Despite its broad potential, studies focused on deploying blockchain solutions for information exchange between semiconductor equipment remain notably scarce. Moreover, the challenges associated with integrating blockchain technology into the semiconductor manufacturing supply chain are anticipated to persist beyond 2025, as noted in recent forecasts [21]. This situation underscores the urgent need for focused research into the applicability and adaptability of blockchain in this critical field. Given this backdrop, this paper seeks to address the following pivotal questions:
What are the technical and practical requirements for implementing a blockchain-based operational parameter matching protocol in semiconductor manufacturing?
How can blockchain technology be effectively customized to decentralize the operational parameter matching system in semiconductor manufacturing?
The primary objective of this paper is to bridge the existing gap in the application of blockchain technology in the semiconductor manufacturing industry. This study is centered on the development and implementation of the blockchain-based parameter matching (BBPM) protocol. The protocol is designed to adopt blockchain technology, facilitating a transformative shift from traditional centralized systems to a distributed operational parameter matching system. By introducing this protocol, we aim to demonstrate a viable application of blockchain technology within the semiconductor manufacturing domain.
The remainder of this paper is organized as follows: Section II provides the background and rationale specific to the semiconductor manufacturing domain for the BBPM protocol. Section III addresses the technical modifications required to adapt blockchain technology specifically for the BBPM protocol. Section IV details the design and implementation of the BBPM protocol. Section V demonstrates and analyzes the practicality of the BBPM protocol. Finally, the conclusions of this study are summarized in section VI.
Background and Rationale
To understand the BBPM protocol in terms of the semiconductor manufacturing supply chain, it is very informative to refer to ‘Factory Integration’ in the International Roadmap for Devices and Systems (IRDS). In the context of the ‘Factory Integration’ functional area, the BBPM protocol corresponds to production equipment (PE), which includes run-to-run (R2R) control, fault detection and classification (FDC), statistical process control (SPC), fault prediction (FP), and equipment health monitoring (EHM). The interests of PE include improving wafer process quality, verifying equipment functionality, and limiting utilities and electricity consumption, among other objectives [22]. In the hierarchical layer structure, the BBPM protocol corresponds to the supervisory control and data acquisition (SCADA) level. The structure comprises four levels: equipment sensor (Level 1), SCADA (Level 2), manufacturing execution system (MES) (Level 3), and enterprise resource planning (ERP) (Level 4). Applications of PE are situated at the SCADA level [23]. Our proposal contributes to the semiconductor manufacturing supply chain by pioneering the instantiation of a blockchain application within it. A deep discussion of the semiconductor manufacturing supply chain is beyond the scope of this paper. For more details, see [24].
To detail the BBPM’s application environment specific to semiconductor manufacturing, this section discusses the following four topics.
A. Understanding the Distinct Roles of Operational Parameters
Regarding semiconductor equipment, wafer processing recipes define various processing variables essential for achieving the desired quality at each wafer processing step. Conversely, operational parameters establish settings that not only ensure equipment safety but also optimally configure the equipment according to the specific wafer processing recipes assigned. For example, in the plasma etch process, while wafer recipes specify the RF power values, operational parameters set the RF power limits. These limits are then used to verify the RF power values during the execution of the etch process. If these RF power limits are set incorrectly, the etch process might proceed without triggering alarms, even when the RF power values exceed established safety thresholds. Such oversight could lead to severe issues, compromising both equipment safety and the quality of wafer processing.
Additionally, as further examples, scanning electron microscopes include such operational parameters as accelerating voltage, collection solid angle, beam current, and spot size [25], [26], [27]. Brightness, contrast, and secondary electron intensity are prominent parameters to calibrate the operational state of helium ion microscopes [28], [29]. Ion-beam microscopes use beam voltage and the pressure of vacuum electrons [30]. These parameters, distinguished from process recipes, significantly influence the equipment’s performance.
Meanwhile, providing operational parameter settings to the equipment supplier for troubleshooting enables the supplier to conduct tests at their site, mirroring the conditions under which the semiconductor company’s equipment operated. This provides a clear advantage in quickly identifying and addressing the underlying causes of issues. However, sharing operational parameter settings with equipment suppliers is challenging due to the inclusion of the semiconductor company’s manufacturing know-how and process knowledge [31].
B. Understanding Operational Parameter Manipulation Risk
In the semiconductor manufacturing, the occurrence of tampered operational parameters can be broadly classified into two main pathways. The first scenario involves the manipulation of the operation parameter file, which serves as the ledger for operational parameters in the equipment. Some equipment allows editing of the operation parameter file using text editors or Microsoft Excel without permission checks. Careless alteration of the content of such files results in the loading of a corrupted ledger. The second scenario involves the occurrence of tampered operational parameters by authorized users. Upon completion of loading the operational parameter file depicted in Fig. 1, editing of the operational parameters stored in the equipment controller’s memory can be generally performed through the equipment’s graphical user interface (GUI). To edit operational parameters via the GUI, a permission verification process similar to that required for recipe editing at the superuser level is necessary. However, instances of tampered operational parameters can occur even at the hands of authorized users. This is not due to malicious intent but rather stems from situations where users with modification permissions make temporary alterations out of necessity and inadvertently fail to restore the original settings. Fig. 2 illustrates the typical scenario in which these situations occur.
A typical case of authorized users unintentionally altering operational parameters.
C. Rationale for Introducing the BBPM Protocol
In the event of wafer processing defects in the equipment, comparing the operational parameters of the affected equipment (hereafter referred to as suspected-OP) with those of equipment operating without defects (hereafter referred to as authentic-OP) facilitates the verification of their integrity. Suspected-OP denotes the operational parameters of equipment suspected to have process defects, whereas authentic-OP denotes the operational parameters of equipment confirmed to be operating without defects. However, manually comparing the two OPs without the aid of an automated comparison system is time-consuming and challenges the accuracy of verification. Therefore, semiconductor manufacturers often establish an in-house information system (hereafter referred to as the OP-system) to manage these operational parameters.
The OP-system must, at a minimum, provide functionality for the creation and maintenance of the operational parameter ledger (OP-ledger) and the detection of suspected-OP. The decision to implement the OP-ledger using a centralized or distributed ledger framework depends on the preferences and circumstances of the development entity. However, considering that semiconductor manufacturing is a complex process involving many pieces of equipment [32], choosing a centralized ledger may require a significant amount of data storage.
On the other hand, semiconductor equipment, as depicted in Fig. 1, already allocates the necessary memory space for operational parameter. Therefore, implementing the OP-ledger in an edge ledger format, distributed to the equipment controllers, can eliminate the need for additional data storage investment. Nonetheless, the implementation of the OP-system in a distributed ledger framework requires the existence of a protocol machine capable of creating, maintaining, and comparing distributed ledgers.
In the domain of semiconductor manufacturing, distributed edge computing solutions are being suggested by equipment manufacturers mainly for the purpose of advanced process control (APC). Despite these advancements, it is widely recognized within the domain that such systems are not yet meeting the needs of semiconductor manufacturers. This gap has led to a decrease in trust in the edge computing approaches of semiconductor manufacturers. Moreover, the necessity to develop innovative protocols presents a significant challenge, adding considerable overhead for the manufacturers. This backdrop motivates the introduction of the BBPM protocol in this paper.
D. Distinct Features as Solutions in Semiconductor Manufacturing
Blockchain is a technology that enables the creation of tamper-resistant digital ledgers in a distributed manner, thereby eliminating the need for a central authority [33], [34]. This capability is particularly crucial for the distributed OP-ledger in the BBPM network, which comprises semiconductor equipment equipped with the BBPM protocol, each piece acting as a node in the BBPM network.
As a solution for semiconductor manufacturing, the BBPM protocol treats operational parameters, rather than cryptocurrency, as its assets. Therefore, the data structure for the BBPM protocol’s transactions and blocks must be modified to accommodate these assets. Additionally, the pursuit of block mining within this protocol is not driven by the aspiration to attain economic value. Instead, its primary objective is to distribute the role of a tentative supervisor among the nodes, specifically to the mining winner. The winning node takes on the responsibility of updating the BBPM’s blockchain with the newly mined block. Consequently, block mining in the BBPM protocol does not need to be competitive.
Customizing Blockchain Components
In this section, we detail the customization of key blockchain components—transactions, blocks, and the proof of work mechanism—to specifically align with the BBPM protocol’s objectives. Our aim is to tailor these foundational elements to uniquely cater to the BBPM protocol’s requirements, thereby effectively supporting its operational goals. The necessary customizations are driven by the following specific needs:
Operational parameters management: The BBPM protocol handles operational parameters, which are used to configure semiconductor equipment, diverging from typical blockchain applications that focus on cryptocurrencies.
Does not pursue rewards: Unlike typical blockchain applications, the BBPM protocol does not need to reward processing transactions or mining blocks.
Avoiding excessive computing power: The BBPM protocol should prevent excessive computational demands so as not to compromise the wafer processing performance of semiconductor equipment equipped with the BBPM protocol.
A. Transaction
Blockchain technology is commonly used for cryptocurrencies [35]. A cryptocurrency transaction typically consists of inputs and outputs. The inputs are usually a list of digital assets that users can transfer to other users in the blockchain network. The outputs are usually the recipient digital asset accounts, which show how much digital assets will be received [36]. As mentioned above, the BBPM protocol treats operational parameters as its digital assets. These operational parameters usually specify conditions under which semiconductor equipment is expected to operate, and they are typically represented in the form of ‘tag = value.’ A tag indicates the meaning of the parameter, and the value specifies the state of the parameter. For example, ‘heater_temp_upper_limit =250’ indicates that the upper limit temperature of the heater is set to 250°C. This implies that if the heater temperature exceeds 250°C, the semiconductor equipment with an overheated heater may behave unexpectedly.
A BBPM transaction signifies a change in the state of a tag, and does not require the input-output concept necessary in transactions dealing with cryptocurrency. Therefore, the data structure of a BBPM transaction is designed to include a list of ‘tag = value’ to represent the tag to be changed and its new state.
In blockchain system, transactions must be digitally signed for authentication [37]. This is an essential feature of blockchain systems for the prevention of malicious transactions. Given the impossibility of guaranteeing complete security of the semiconductor manufacturing network from external cyber attacks, it is imperative for the BBPM protocol, functioning within this network, to implement robust measures against such threats. Should the BBPM data be compromised as a result of an external cyber attack, it could lead to significant disruptions in the wafer processing operations. Therefore, the blockchain functionality for verifying the validity and authenticity of transactions is also necessary for the BBPM protocol.
B. Block
Bitcoin is the most prominent example inherently associated with blockchain technology [38]. In Bitcoin, blocks are mined to create new coins or to execute pending transactions. The miners receive two types of rewards for their efforts: (1) new coins that are generated with each new block, and (2) the transaction fees for all the transactions included in that block [39]. Simply speaking, this reward model is essential for maintaining the Bitcoin system. It motivates participants to adhere to blockchain protocols, which necessitate considerable computing power. When reconfiguration of the operational parameters of semiconductor equipment is necessary, transactions encapsulating these updates are generated and subsequently broadcast to the BBPM network.
Each node within the network captures these incoming transactions in a memory pool. The transactions accumulated in this pool are subsequently executed through blocks, in a manner analogous to the Bitcoin system. However, a notable distinction in the BBPM protocol is that the blocks are exclusively dedicated to processing transactions, as there is no coin creation involved.
Another significant difference lies in the data structure used for managing transactions. In Bitcoin, the block utilizes a Merkle tree to encapsulate the summary of all transactions. This Merkle tree structure is particularly effective in handling significant increases in transaction volumes, as the Merkle path required to validate the inclusion of a specific transaction grows at a much slower rate [40]. In contrast, the BBPM block adopts a different approach for managing transactions.
Compared to Bitcoin, the BBPM protocol is anticipated to experience a significantly low volume of transactions. This is based on transaction activity and the number of nodes within the BBPM network. The transaction activity is not greedy, because BBPM transactions are typically required for accidental examinations of BBPM nodes, yet sometimes also for planned maintenance. A single BBPM network does not encompass all equipment in a semiconductor factory, but is instead segmented according to identical models from the same supplier, such as those operating at the same wafer processing step. This segmentation results in a limited number of nodes per network. In fact, it is even feasible for a BBPM network to be comprised of as few as a single node. Such a configuration allows for extreme flexibility in adapting to the specific needs and scales of different semiconductor manufacturing environments.
Consequently, in light of the low volume of transactions, the BBPM block is uniquely designed. They are structured to contain arrays of transactions, referred to as ‘List of TRs,’ which differs from Bitcoin’s approach of summarizing all transactions. This design results in simplifying blockchain technology, aligning well with our objective to enhance its applicability and adaptability within the semiconductor manufacturing domain.
C. Proof of Work
As previously discussed, our aim for block mining in the BBPM protocol is to decentralize the supervisory role by distributing it among the nodes that win the mining process. This strategy is driven by the dynamic nature of semiconductor manufacturing, where equipment deployment layouts change to accommodate new production plans or to maximize equipment uptime.
Blockchain technology inherently operates without centralized intermediaries, such as supervisory nodes, by selecting various leaders through consensus mechanisms [41]. Among these mechanisms, the proof of work (PoW) has emerged as a foundational consensus mechanism, largely due to its successful implementation in the Bitcoin blockchain protocol. The PoW is widely acknowledged as a decentralized consensus mechanism that probabilistically selects mining winners [42], [43], [44], [45], [46], [47]. Given these attributes, the PoW has been chosen as the consensus mechanism for the BBPM.
However, Bitcoin’s PoW is well-known to have issues with power consumption [48], [49], [50] and scalability [51], [52], [53]. To address these issues, researchers are actively investigating alternative solutions [54], [55], [56], [57], [58]. Nevertheless, the operating environment of the BBPM protocol, characterized by the low transaction volume features introduced in the preceding B. Block—specifically, non-greedy transaction activity and a limited number of nodes within a single BBPM network—is anticipated to significantly mitigate the likelihood of scalability issues becoming severe.
It remains critical, however, to ensure that the computational power expended in the PoW hash puzzle resolution process does not adversely affect wafer processing [59]. This necessitates the implementation of measures to prevent the use of excessive computing resources.
In the PoW process, nodes compete to solve a hash puzzle, with the winner being granted the right to create a new block on the blockchain. The essence of this task is to find a hash value that begins with a specified number of leading zero bytes [60], a requirement that is adjusted based on level of difficulty. A winning solution is characterized by a hash that is less than or equal to a target value, which is also determined by the current difficulty level. Hence, the computational power expended in the PoW process can be effectively managed by adjusting this difficulty level.
Consequently, it is imperative to calibrate the difficulty level of the BBPM protocol’s PoW mechanism to an optimal value. This calibration is supposed to both prevent the overconsumption of computational resources in the hash solving tasks of BBPM nodes and enable a non-deterministic distribution of the supervisory role among them. By doing so, it ensures that the process of solving hashes does not interfere with or cause damage to the wafer processing operations within the BBPM protocol.
Design and Implementation
The BBPM protocol is structured into two layers: the kernel as the lower layer and the application as the upper layer. The kernel layer encompasses processes such as network joining, transaction propagation, and block mining, while the application layer is responsible for the matching process. We refer to the software implemented to execute these layers as a ‘protocol-machine.’
In this section, to embody the ‘protocol-machine,’ we detail the algorithmic sequences for the layers’ processes, the protocol data units (PDUs) for handshaking between BBPM nodes, and the data structures required by the PDUs. Additionally, to evaluate our design, we implemented the simulation software, SimBBPM. This tool was developed in C++ within a Windows 10 environment and incorporates OpenSSL to manage cryptographic hash functions.
A. Joining the BBPM Network
In the BBPM network, the semiconductor equipment functions as a node within the BBPM network. Consequently, any equipment intending to utilize the proposed protocol is required to join the BBPM network. Broadcasting the ‘PDU_NETWORK_JOIN_REQ’ either facilitates the construction of a BBPM network or enables a new node to join an existing network. When nodes receive this PDU, they register the ‘NodeInformation’ conveyed by the PDU in their ‘NetworkNodeTable.’ Subsequently, they broadcast a ‘PDU_NETWORK_JOIN_REPLY.’ Upon receiving this reply, the recipient nodes register the ‘NodeInformation’ from the reply in their ‘NetworkNodeTable.’ As a result, either a new BBPM network is formed, or new nodes are added to the existing BBPM network.
In the BBPM network, nodes have the capability to dynamically join or leave the network, responding to their operational needs. In order to succinctly convey complex information and avoid lengthy explanations, this study employs Table and Figure. Table 1 delineates the data structure of the ‘NodeInformation.’ Fig. 3 visually illustrates the network joining process, including the PDU handshake and the algorithmic sequence involved.
The BBPM protocol implements the authentication of ‘NodeInformation’ through the following sequence of steps:
Initially, the sender computes the hash value of the NodeInformation data field intended for transmission.
This hash value is then encrypted using the sender’s private key, establishing a secure digital signature.
Subsequently, the encrypted hash value, constituting the digital signature, is transmitted to the recipients.
Upon receipt, all recipients independently recalculate the hash value of the received data field to verify its integrity.
The recipients then decrypt the received digital signature using the sender’s public key.
Finally, the recipients compare the recalculated hash value (from step 4) with the decrypted hash value (from step 5).
B. Generating Transaction and Authentication
The BBPM protocol features the ‘EVT_CONFIG_VAL_UPDATE’ event as a user interface between the protocol itself and operators of equipment equipped with the BBPM protocol. When operators reconfigure the operational parameters and wish to secure these changes in the BBPM OP-ledger, they can notify the BBPM protocol by activating ‘EVT_CONFIG_VAL_UPDATE.’
Activating ‘EVT_CONFIG_VAL_UPDATE’ prompts the BBPM protocol to generate and broadcast transactions across the BBPM network in the form of a ‘PDU_TRANSACTION.’ Table 2 delineates the data structure of the transaction. Fig. 4 visually elucidates the mechanism of ‘PDU_TRANSACTION,’ illustrating how it executes the propagation of the changes and intermediately maintains the transactions for subsequent processes.
The BBPM protocol implements transaction authentication through the following sequence of steps:
Initially, the sender computes the hash value of the transaction’s data field intended for transmission.
This hash value is then encrypted using the sender’s private key, creating a secure digital signature.
The encrypted hash value, constituting the digital signature, is transmitted to the recipients.
Upon receipt, all recipients independently recalculate the hash value of the received data field to verify its integrity.
The recipients then decrypt the received digital signature using the sender’s public key, which is retrieved from the ‘NetworkNodeTable,’ as detailed in Fig. 3.
Finally, the recipients compare the recalculated hash value (from step 4) with the decrypted hash value (from step 5) to verify the authenticity of the transaction.
C. Mining Process
In the BBPM network, all nodes act as miners, ensuring decentralized operation of the BBPM protocol. As previously mentioned, this protocol utilizes the proof of work (PoW) consensus mechanism. It is crucial to calibrate the difficulty level of the PoW to an optimal value. This optimal value is especially significant to maintain a balance between effective decentralization and the prevention of excessive computing power needed to solve the hash puzzle. Such an approach makes the BBPM protocol practicable, ensuring that it does not compromise the wafer processing performance of semiconductor equipment equipped with the BBPM protocol. The protocol uses the fixed string ‘BBPM_Puzzle’ and a variable nonce to solve the puzzle, as illustrated in Fig. 5.
In the BBPM protocol, the mining process is initiated by the ‘EVT_START_POW’ event, which can be activated in different ways:
Automatically activated by ‘PDU_TRANSACTION.’
Periodic activation via a timer-based task.
Manual activation through a user interface.
In Fig. 4, the ‘EVT_START_POW’ event is shown as being triggered by ‘PDU_TRANSACTION.’ Choosing different activation methods offers practical flexibility in a real-world environment and does not alter the essence of the BBPM protocol.
Once ‘EVT_START_POW’ is activated, BBPM nodes begin mining a block. The node that succeeds in finding the puzzle solution creates a new block, appends the block to the BBPM blockchain, and broadcasts the block across the BBPM network. Should a node receive a block during its mining process, it validates the received block. If the block proves authentic, the node halts its mining process immediately and appends the block to the BBPM blockchain. The BBPM protocol distributes and synchronizes the BBPM blockchain across each node in the BBPM network in its realm. In subsection B ‘Integral Funtionality Check,’ in section V ‘Practicality Evaluation,’ we evaluate the synchronization. The block data structure and the mining process are detailed in Table 3 and Fig. 6, respectively.
Validating blocks includes both block authentication and nonce verification. The block authentication employs the same principles and procedures as those used in transaction authentication, detailed in the subsection B. ‘Generating Transactions and Authentication.’ The nonce verification conducts the following steps to confirm whether the received block came from the mining winner or not:
Generate hash values using SHA256, taking a string that combines ‘BBPM_Puzzle’ and the nonce as an input.
Verify that the first two leading bytes of the hash value are zeros.
When a new block is appended to the BBPM blockchain, ‘memCFG’ is updated based on the transactions contained within the block. In semiconductor equipment, operational parameters are typically stored as text files, known as configuration files. Upon initial start-up, the BBPM protocol loads all configuration files into a dedicated memory storage, referred to as ‘memCFG.’ Subsequently, the protocol interacts exclusively with ‘memCFG’ rather than directly with the configuration files. Additionally, the BBPM protocol allows equipment controllers to access ‘memCFG’ when configuring the operational parameters of the equipment. This design aims to maintain coherence in operational parameters between the protocol and the equipment controllers.
Additionally, each block within the BBPM blockchain is linked to a dedicated OP-ledger, containing a unique hash value. This hash is generated from parameters stored in ‘memCFG,’ guided by a specific ‘OPCODE’ included in that block. The ‘OPCODE’ is capable of not only determining which parameters from ‘memCFG’ to include but also specifying the necessary preprocessing algorithms before hashing. It is purposefully designed to provide a broad range of options for selecting conditions under which operational parameters are matched. In this study, we utilize an ‘OPCODE’ named ‘OP_FULL_HASH,’ which directs the BBPM protocol to calculate the OP-ledger’s hash value using all available parameters in ‘memCFG.’ The exploration and enhancement of OPCODE options is a critical area for future research.
D. Matching Process
Having covered the design and implementation of processes within the kernel layer of the BBPM protocol, we will now elaborate on the design and implementation of the matching process within the application layer. This matching process, supported by underlying kernel processes, performs the operational parameter matching, which is the primary application objective of the BBPM protocol.
For the matching process, the BBPM protocol utilizes two PDUs: ‘PDU_MATCHING_REQ’ and ‘PDU_MATCHING_REPLY,’ abbreviated respectively as ‘MP_REQ’ and ‘MP_REPLY’ for brevity and ease of reference throughout this paper. Additionally, the protocol employs a special transaction type, ‘MatchTransaction,’ which is integral to the matching process.
The data structure of ‘MatchTransaction’ is detailed in Table 4, providing an in-depth view of its composition. The aforementioned PDUs are encoded using the ‘MatchTransaction’ data structure, but there is a difference in the encoding process between ‘MP_REQ’ and ‘MP_REPLY.’ The CfgHash for ‘MP_REQ’ is calculated using ‘memCFG,’ whereas for ‘MP_REPLY’, this calculation is not necessary. With CfgHash, regardless of the volume of operational parameters to be verified, the parameters are encrypted into a SHA256 hash, providing the benefit of confining the data size of ‘MP_REQ.’ The principles and procedures for ‘MatchTransaction’ authentication are the same as those for transaction or block authentication, as mentioned in the corresponding former section.
Next, we will provide an in-depth exploration of the behaviors of nodes involved in the matching process. For the convenience of explanation, the node that sends ‘MP_REQ’ and then waits for ‘MP_REPLY’ will be referred to as a ‘MatchRequester,’ and the node that receives ‘MP_REQ’ and then sends ‘MP_REPLY’ will be referred to as a ‘MatchReplier.’ The ‘MatchReplier’ verifies whether the operational parameters sent by the ‘MatchRequester’ are identical to the contents of the OP-ledger in the BBPM blockchain. Upon completing this verification, the ‘MatchReplier’ then returns the results to the ‘MatchRequester.’ To carry out this task, the ‘MatchReplier’ must locate the correct OP-ledger within the BBPM blockchain. This ledger should include the same ‘OPCODE’ as the one sent by the ‘MatchRequester.’ To accurately locate the correct OP-ledger, the ‘MatchReplier’ examines the BBPM blockchain to identify blocks containing the same ‘OPCODE’ as that of the ‘MP_REQ.’
As detailed in the subsection C. ‘Mining Process,’ each block in the BBPM blockchain is linked to its own OP-ledger. In instances where multiple blocks are detected, the block closest to the tip of the blockchain is selected. The ‘MatchReplier’ then compares MP_REQ’s CfgHash with the hash value of the selected OP-ledger and then sends the ‘MP_REPLY’ to the ‘MatchRequester’ with the comparison result, referred to as ‘MatchingResult.’ In this process, the MP_REQ’s CfgHash represents the operational parameters of the ‘MatchRequester,’ while the hash value of the selected OP-ledger represents those parameters as securely maintained by the BBPM blockchain.
The ‘MatchRequester’ tallies the number of TRUE ‘MatchingResult’ responses received through ‘MP_REPLY.’ When the count of TRUE ‘MatchingResult’ responses reaches a predetermined threshold, the ‘MatchRequester’ then determines that the ‘MatchTransaction’ is TRUE, indicating that there are no abnormal operational parameters. In this study, the threshold is set at ‘SysNode_Count – 1,’ where ‘SysNode_Count’ represents the total number of nodes participating in the BBPM network. In practical applications, the threshold for declaring a TRUE ‘MatchTransaction’ can be adjusted according to the specific usage environment and decided by the user to best fit their operational needs.
The content elucidated regarding the matching process is effectively illustrated in Fig. 7, which depicts the complex steps in a flowchart format. This visual representation simplifies the comprehension of the intricate details involved in the matching process, facilitating easier understanding.
Practicality Evaluation
A. Methodology Overview
To evaluate the BBPM Protocol’s practicality, this section demonstrates and analyzes the protocol’s behavior using the simulation software SimBBPM, as introduced in section IV. The SimBBPM simulations have been conducted on a single computer with an Intel CPU @ 2.50 GHz, 8 GB RAM, and Windows 10.
SimBBPM was specifically designed to instantiate multiple independent console applications on a single computer. Each application emulates a BBPM node, which is a piece of semiconductor equipment equipped with the BBPM protocol-machine, the software implemented to execute the BBPM protocol. The console application features a straightforward text-based user interface, where pressing a specific number activates the corresponding process of the ‘protocol-machine.’ A screenshot of the console application is displayed in Fig. 8. This evaluation is configured as follows:
Integral functionality check: We assess the integral functionality of the BBPM protocol by sequentially running the BBPM processes as detailed in section IV and analyzing the outcomes at each step. This evaluation aims to verify the algorithmic sequences of the processes, ensure proper handshaking of the PDUs, validate the data structures of ‘tag = value’ pairs in transactions and ‘List of TRs’ in blocks, and assess the impact of the difficulty level on the PoW mechanism.
Authentication and security: This evaluation focuses on the BBPM protocol’s security measures, specifically their effectiveness in preventing unauthorized access. We simulate scenarios in which unregistered nodes attempt to tamper with the OP-ledger in the BBPM blockchain by broadcasting transactions.
Parameter matching capability: We verify that the matching process accurately identifies ‘MatchingResult’ as TRUE or FALSE in the corresponding scenarios. Additionally, within the BBPM Network, we observe the impact on other nodes when a specific node transitions to the ‘MatchingResult False’ state, and we analyze which characteristics of the BBPM protocol contribute to these outcomes.
Investigation of implementation performance: Although the performance challenges of the BBPM protocol are beyond the scope of this paper, we measure the trend in elapsed time of the matching process as the number of nodes increases. This measurement helps to identify how different implementations of the BBPM protocol, exemplified by SimBBPM, influence its performance. By analyzing potential causes of these results, we lay the foundation for future research on performance issues.
B. Integral Functionality Check
For this evaluation, we instantiated three BBPM nodes, each assigned a pair of (Node ID, EqID) values: (0, 100), (1, 200), and (2, 300), respectively.
1) Network Joining Process
Building a BBPM network with these three nodes was achieved by pressing ‘1’ in the SimBBPM interface. After the SimBBPM had completed building the network, we proceeded to investigate the ‘NetworkNodeTable’ for each of the three nodes within our simulation.
We found that each table had successfully registered the equipment IDs (EqIDs) 100, 200, and 300, indicating that all three nodes were effectively part of the BBPM network. This confirms that the network joining process, as depicted in Fig. 3, operates as envisioned in our study.
Here is a detailed account of how each node in the BBPM network identified its participants: The node with EqID 100 identified the nodes with EqIDs 200 and 300 through the NodeInformation delivered by ‘PDU_NETWORK_JOIN_REPLY.’ In contrast, the node with EqID 200 identified EqID 100 using ‘PDU_NETWORK_JOIN_REQ’ and identified EqID 300 via ‘PDU_NETWORK_JOIN_REPLY.’ Meanwhile, the node with EqID 300 recognized EqID 100 through ‘PDU_NETWORK_JOIN_REQ’ and identified EqID 200 using ‘PDU_NETWORK_JOIN_REPLY.’
2) Transaction Propagation
Having one node change an operational parameter and broadcasting a transaction encapsulating this change to the BBPM network, accomplished by pressing ‘2’ on the SimBBPM.
For this test, SimBBPM provides a test-purpose OP-ledger containing ten ‘tag = value’ pairs, ranging sequentially from ‘tag(0) = default(0)’ to ‘tag(9) = default(9).’ Node 0 created and broadcast a transaction to the BBPM network to store the new setting of tag(0) in the BBPM blockchain, simulating a scenario where Node 0’s user intentionally tries to change the operational condition of their semiconductor equipment. In a similar manner, Node 1 and Node 2 each executed the same actions for their respective tags, tag(1) and tag(2).
Now, the BBPM blockchain includes three new transactions, each containing the updated settings for their respective tags. These transactions are about to be executed through the mining process. This means that the OP-ledger still maintains its default settings because the transactions have not yet been executed.
Investigating the OP-ledger after executing the mining process will allow us to discern the functional results of transaction propagation depicted in Fig. 4.
3) Mining Process
Securing the changes described in the transaction propagation into the BBPM OP-ledger is achieved by initiating the mining process, accomplished by pressing ‘3’ on the SimBBPM.
For this simulation, we opted for manual activation of the mining process to investigate the OP-ledger after the issuance of the transaction and before the execution of the mining process.
By investigating the OP-ledger, we were able to verify that it successfully transitioned from its default settings to the updated settings following the mining process. Furthermore, the most notable outcome is the synchronization of the OP-ledger across nodes in the BBPM network. These outcomes indicate that transactions with a ‘tag = value’ structure and blocks with ‘List of TRs’ structure are functioning as intended.
Consequently, this confirms that the network joining process, transaction propagation, mining process, PDU handshake control, and modifications to data structures are efficiently integrated and function in precise alignment with the comprehensive design of our study.
4) Observation of Difficulty Adjustment
This observes the behavior of the BBPM PoW based on the heuristic calibration of the difficulty level. The quantitative results of this observation are constrained by the computing power of the computer used in the simulation, yet the qualitative trends can be deemed reliable.
For computing power consumption, this study investigates the relationship between different difficulty levels and their impact on computing power of the BBPM PoW. The times observed to find a winning hash under varying conditions are summarized as follows:
Difficulty Level 1:
Finding a hash that starts with ‘
0\times 00 Difficulty Level 2:
For a hash starting with ‘
0\times 0000 Difficulty Level 3:
When the task was to find a hash beginning with ‘
0\times 000000
In the non-deterministic distribution of the supervisory role, it has been observed that mining winners are more evenly distributed at difficulty level 2 than at level 1. However, this does not undermine the sustainability of distributing the supervisory role in the BBPM network. Even if certain nodes predominantly win the mining competition, the departure of such nodes from the network would simply result in other nodes becoming winners.
Based on these observations, it can be stated that calibrating the difficulty level exerts a dominant influence on the time required for the PoW process, allowing the BBPM protocol to set the difficulty level to an optimal value tailored to its specific objectives.
C. Authentication and Security
For this evaluation, we instantiated an additional node, assigning it node ID 4, and forced it to attempt tampering with the OP-ledger managed by the BBPM network, which was established for the Integral Functionality Check. This node did not join the network but broadcast a transaction containing an arbitrary ‘tag = value.’
By observing how the network’s participating nodes responded to this unauthorized action, we confirmed that all participating nodes deemed the transaction from node 4 unacceptable because it originated from an unidentifiable node.
Consequently, this confirms that the validation mechanism embedded in the BBPM design is capable of detecting illegal access.
Furthermore, this mechanism incorporates the digital signature algorithm used in Bitcoin to leverage its proven authentication performance. However, additional research is needed to address the possibility of various illegal access scenarios that the BBPM may encounter in real-world environments.
D. Parameter Matching Capability
The BBPM network, comprising the three nodes, continues to serve in this evaluation.
1) Terminology
From the perspective of a single node, ‘A-State’ is defined as the state in which the hash generated from the operational parameters stored in ‘memCFG’-a dedicated memory storage designed specifically for these parameters-matches the hash stored in the BBPM OP-ledger. The node’s equipment controller refers to this storage when configuring the equipment. Fig. 9 illustrates data referencing between the equipment controller and the BBPM protocol-machine. ‘A-State’ is recorded as TRUE in the ‘MatchingResult.’ Conversely, ‘B-State’ occurs when the two hashes do not match, and is recorded as FALSE in the ‘MatchingResult.’ The ‘B-State’ scenario arises when a node modifies operational parameters in its ‘memCFG’ without registering the changes in the BBPM OP-ledger.
Collectively, these two states are termed the ‘Matching-State.’ Importantly, the ‘Matching-State’ is not specific to the entire BBPM network (network-specific) but is instead specific to individual nodes (node-specific). This distinction allows individual nodes to be in different ‘Matching-States’ from others within the same BBPM network.
2) Simulation Scenario
For this test, the state of SimBBPM is restored to the condition following the completion of the mining process described in subsection B. ‘Integral Functionality Check.’ To evaluate ‘A-State’ matching, we initiated the mining process by pressing ‘4’ on Node 0’s console application, thereby simulating the evaluation of ‘A-State.’ For the ‘B-State’ evaluation, we simulated accidental changes to operational parameters by first pressing ‘5’ on Node 0’s console application, followed by pressing ‘4’ to conduct the ‘B-State’ matching evaluation.
3) Simulation Results
In the conducted simulation, it was demonstrated that the BBPM protocol consistently delivered the anticipated outcomes: specifically, returning the ‘A-State’ when evaluated under the ‘A-State’ scenario and the ‘B-State’ under the ‘B-State’ scenario. These results confirm the protocol’s efficacy in distinguishing between the two operational scenarios.
Our simulations demonstrated that the BBPM protocol consistently returns the ‘A-State’ for Node 1 and Node 2, even when Node 0 inadvertently shifts to the ‘B-State.’ This is because Nodes 1 and 2 remain unaffected by accidental alterations to their operational parameters, thereby maintaining the ‘A-State.’ These findings highlight the BBPM protocol’s capability to prevent a network-wide collapse when a single node transitions to the ‘B-State,’ by managing the ‘Matching-State’ on a node-specific basis.
The fact that Nodes 1 and 2 return the ‘A-State’ can be detailed through the following algorithmic processes:
Broadcasting MP-REQ:
The matching process is initiated by pressing ‘4’ on Node 1’s console application.
Node 1 computes ‘CfgHash’ from its ‘memCFG,’ which is synchronized with the BBPM OP-ledger.
Subsequently, Node 1 broadcasts an ‘MP_REQ’ that includes the ‘CfgHash.’
Receiving MP-REQ:
Upon receiving the ‘MP_REQ,’ Nodes 0 and 2 compare the CfgHash in the ‘MP_REQ’ with the hash in the OP-ledger (When Node 2 sends the ‘MP_REQ,’ this task is performed by Nodes 0 and 1).
Despite Node 0’s accidental parameter alteration, the OP-ledger remains synchronized with ‘memCFG’ of Nodes 1 and 2. It’s important to note that Node 0 compares the hash created from Node 1’s or Node 2’s ‘memCfg,’ not its own, with the hash in the OP-ledger.
This synchronization results in Nodes 0 and 2 obtaining a TRUE ‘MatchingResult’ (When Node 2 sends the ‘MP_REQ,’ Nodes 0 and 1 perform this step).
Sending MP-REPLY:
Following the comparison, Nodes 0 and 2 send an ‘MP_REPLY,’ indicating a TRUE ‘MatchingResult,’ back to the ‘MP-REQ’ sender (When Node 2 sends the ‘MP_REQ,’ Nodes 0 and 1 are the ones sending the ‘MP_REPLY’).
Receiving MP-REPLY:
Consequently, Node 1 receives a TRUE ‘MatchingResult’ from both Nodes 0 and 2 (When Node 2 is the sender of the ‘MP_REQ,’ Node 2 receives a TRUE ‘MatchingResult’ from Nodes 0 and 1).
Returning Matching-State:
Based on the TRUE ‘MatchingResult,’ the BBPM protocol-machine of Node 1 returns the ‘A-State’ (When Node 2 sends the ‘MP_REQ,’ the protocol-machine of Node 2 returns the ‘A-State’).
In conclusion, after an in-depth evaluation and analysis of the parameter matching capability, we confirm that the matching process operates as intended by this study.
E. Investigation of Implementation Performance
As mentioned before, although the performance issues of BBPM is beyond the scope of this paper, we include an analysis of measurement data relevant to them, which should be considered for BBPM application in real-world environments. The primary concerns about BBPM’s performance originate from the software designs used to implement the BBPM protocol. This analysis establishes the foundational criteria for exploring BBPM’s performance in future research. Fig. 10 shows the trend of elapsed time for the matching process, as measured on the computer used to conduct our evaluation. This data shows that the elapsed time slightly increases with the addition of nodes, which could be attributed to the following potential causes:
Resource contention: Each additional node application may compete for the same computing resources, such as CPU, memory, and I/O.
Software overhead: The matching process might have software overhead that becomes more pronounced as the number of simulated nodes increases.
Concurrency and threading: Because SimBBPM is implemented with a multi-threaded approach, the software architecture’s ability to manage multiple threads could impact the latency of the matching process.
TCP/IP overheads: An increase in TCP/IP connections can lead to higher traffic, potentially simulating the effects of network congestion.
F. Summary
The practicality evaluation of the BBPM protocol has yielded several key findings that affirm the effectiveness and robustness of its components and processes designed for blockchain technology adoption. We confirmed the effective construction of a BBPM network during the network joining process by verifying the successful registration of the equipment IDs in the ‘NetworkNodeTable’ for each participant. The examination of the OP-ledger after the mining process verified exact updates and synchronization across the BBPM network, confirming that the tailored data structures, alongside the integration of network joining, transaction propagation, and mining processes, function as intended. Additionally, an examination of the PoW’s difficulty level revealed its significant impact on computing times, suggesting that calibrating the difficulty level can optimize the BBPM PoW’s operational intensity to meet the protocol’s requirements.
Further aspects of the protocol’s practicality were assessed through authentication and security measures, as well as through parameter matching capabilities and performance implementation investigations. The network’s ability to reject transactions from unrecognized nodes highlights its robust security protocols, ensuring that only authorized participants can engage. However, the wide variety of potential illegal access scenarios in the real world necessitates further research. The BBPM protocol also proved effective in managing the ‘Matching-State’ on a node-specific basis under prescribed conditions. This is crucial to prevent a network-wide collapse when a single node transitions to the ‘B-State.’ Furthermore, the ‘OPCODE,’ which specifies the method for matching operational parameters, requires further refinement to more effectively cover diverse matching scenarios. Lastly, the identification of architectural factors such as software overhead, concurrency, threading and network complexities guides the ongoing refinement of the BBPM protocol, aiming to enhance its efficiency and reliability for real-world applications.
These comprehensive evaluations not only underscore the BBPM protocol’s readiness for practical deployment but also highlight the need for further research to effectively adapt to the diverse real-world scenarios.
Conclusion
Despite the recognized potential of blockchain, research on its application in semiconductor equipment is notably scarce. To address this gap, this paper introduces and develops the blockchain-based parameter matching (BBPM) protocol, which is installed in semiconductor equipment. This protocol facilitates the transition from a centralized to a decentralized operational parameter system, preserving the integrity and security of operational parameters. Additionally, it autonomously adapts to changes in equipment layout without requiring a dedicated administrator for network management.
To develop the protocol, this study customizes the data structures: transactions now include a list of ‘tag = value’ pairs, and blocks contain arrays of these transactions, referred to as ‘List of TRs.’ Additionally, the difficulty level of the PoW is calibrated to avoid requiring excessive computational power. Subsequently, key algorithmic processes-the network joining process, the transaction propagation, the mining process and the matching process-are defined to realize the BBPM’s task of the operational parameter matching within the realm of blockchain technology.
The practicality evaluation demonstrates that the BBPM protocol effectively tailors and integrates blockchain components and defined processes for its adoption of blockchain technology, ensuring they operate seamlessly in alignment with BBPM’s objectives. Additionally, this paper proposes future research themes, including assessing BBPM’s performance based on its software designs, tackling various unauthorized access scenarios in the real world, and detailing the ‘OPCODE’ to cover diverse matching scenarios.
Overall, this pioneering study not only establishes foundational technology but also opens new avenues for innovation in applying blockchain technology within the semiconductor manufacturing domain.