## 4 Results  
In the simulation dataflow design, as shown in Figure 4, the communication process commenced with an attempt to transmit a message through the Raspberry Pi 4 (Wales, UK), intending to relay an IoT message to a specific node. Upon the node's reception of the message, all nodes that had subscribed to the same topic were notified. The blue-dotted line in the illustration symbolizes the data processing sequence. Given that MQTT operates by subscribing through a shared theme, the message is dispatched to nodes subscribed to the topic, such as nodes B, C, and D. Upon the message's arrival, it becomes apparent that only node C possesses the key assigned by node A.  
Consequently, nodes B and D cannot access the corresponding key, rendering the message unreadable and unidentifiable to these nodes. This mechanism ensures that data privacy is maintained, and only authorized nodes with the requisite key can interpret the transmitted messages, enhancing the overall security of the communication process. The experiment began by setting up a Certification Authority (CA) system that automatically generates golden keys. Once a key had been generated for each node, it was sent to the MQTT broker along with the subscription topic and the submission of the key. The four edge devices, 1111, 1112, 1113, and 1114, in Figure 5, were created by simulation. An MQTT broker server was also established to facilitate connection registration for these four nodes. The broker provided a preview, as shown in Figure 4. Four nodes suc  
Figure 4: Simulation message data transfer operation. cessfully synchronized their connections, ensuring the effective generation and distribution of keys and successful connections between nodes and broker. To maintain certificate consistency, all node codes implement a CA certificate generator. This tool simultaneously generates a public and private key, as shown in Figure 5. When sending a message from node 1111, nodes 1112 and 1113 receive the MQTT message simultaneously. However, since 1112 has the public key of 1111, it can analyze the information, while 1113 cannot, due to encryption. The system's intelligent contract screenshot in Figure 6 shows that nodes 1111 to 1114 automatically generate the CA voucher and broadcast the public key voucher. Each node encrypts the message using its private key. For instance, using blockchain technology, node 1112 generates an event record of its location and private key for intelligent contracts. With our designed architecture, we can guarantee the accurate generation and distribution of vouchers while ensuring safe and reliable communication between nodes and smart contracts. We can observe that after the node automatically generates the encryption key, it transmits it back to the broker through MQTT while the broker is registered. Figure 6 shows the result of the broker receiving the key returned from different nodes in red. The box shows four other nodes generating keys to complete the backhaul operation. We will explain the communication certificate generated by node 2. When the node opens the connection, the system immediately generates the blockchain intelligent contract number and public key information, as shown in Figure 7, No. 1. We send the message to the broker by the agent. The delivery format information is (number/key), and the node simultaneously generates the corresponding private key. Like No. 2, the data are automatically encrypted during data transmission. Figure 5: Experimental experiments 1 to 4 in total, representing the representative entity. Figure 6: The key information is automatically generated for the four nodes. In the experiment, we automatically encrypt the file to verify whether the key reaches the MQTT message exchange state. We follow the architectural environment of Figure 5. When node 1111 broadcasts the data to the broker, and if 1112 and 1113 register and subscribe at the same time for the same topic, the message sent by 1111 will be obtained by two nodes, 1112 and 1113.