Conference management-oriented sign-in data integrity guarantee method and system

Abstract

The invention relates to the technical field of conference data security, and discloses a conference management-oriented sign-in data integrity guarantee method and system, and the method comprises the steps: obtaining the pre-registration information of participants, and obtaining a local feature library of each sign-in terminal through an edge intelligent feature extraction and distributed cache synchronization method; an on-site rapid matching and space-time anchoring method is adopted to obtain a tamper-proof sign-in data packet; a hierarchical consensus and block chain storage method is adopted to obtain a block chain record and final confirmation; a deep learning enhanced verification and intelligent arbitration method is adopted to obtain a data verification result and a final processing decision; adopting a vector clock and an intelligent conflict resolution method to obtain globally consistent sign-in data; and adopting zero-knowledge proof and homomorphic encryption methods to obtain a privacy protection verification result. According to the invention, the integrity guarantee and privacy protection of the sign-in data in the whole life cycle from collection to verification in a multi-meeting-place distributed sign-in scene can be realized.

Description

Technical Field

[0001] This invention relates to the field of conference data security technology, and more specifically, to a method and system for ensuring the integrity of attendance data for conference management. Background Technology

[0002] With the deepening of digital transformation, meeting management systems are widely used in various meetings of government agencies, enterprises, and institutions. Attendance data serves as a crucial basis for meeting attendance management and subsequent auditing, and its integrity and reliability directly affect the standardization and effectiveness of meeting management. Traditional paper-based attendance methods suffer from low efficiency, susceptibility to forgery, and difficulty in traceability. While existing electronic attendance systems improve attendance efficiency, they still have shortcomings in ensuring data integrity.

[0003] In existing technologies, electronic check-in systems primarily use centralized databases to store check-in records, which poses risks of single points of failure and data tampering, and lacks effective anti-tampering mechanisms and reliable evidence storage capabilities. Furthermore, in multi-venue distributed check-in scenarios, data synchronization between check-in terminals suffers from consistency issues; when network delays or partitions occur, data conflicts and loss are easily generated. In addition, existing systems rely mainly on simple rule-based judgments to detect abnormal check-in behavior, making it difficult to identify complex cheating patterns and concealed abnormal behaviors.

[0004] To address the aforementioned issues, existing technologies lack a check-in data integrity assurance solution that can simultaneously meet the requirements of data tamper-proofing, distributed consistency, intelligent anomaly detection, and privacy protection. This makes it impossible to provide reliable data assurance throughout the entire lifecycle of conference management, thus hindering the in-depth development of digital transformation in conference management. Summary of the Invention

[0005] This invention provides a method and system for ensuring the integrity of check-in data in conference management, which solves the technical problems in related technologies such as the risk of tampering, difficulty in ensuring consistency, insufficient anomaly detection capabilities, and lack of privacy protection in multi-venue distributed check-in scenarios.

[0006] This invention provides a method for ensuring the integrity of sign-in data in meeting management, comprising the following steps:

[0007] S1. Collect the pre-registration information of the participants, and use edge intelligent feature extraction and distributed cache synchronization methods to obtain the local feature library of each check-in terminal;

[0008] S2. Obtain the local feature library of each check-in terminal, and use on-site fast matching and spatiotemporal anchoring methods to obtain tamper-proof check-in data packets;

[0009] S3. Obtain tamper-proof sign-in data packets, and use layered consensus and blockchain storage methods to obtain blockchain records and final confirmation;

[0010] S4. Obtain blockchain records and final confirmation, and use deep learning to enhance verification and intelligent arbitration methods to obtain data verification results and final disposal decisions;

[0011] S5. Obtain data verification results and final disposal decisions, and use vector clock and intelligent conflict resolution methods to obtain globally consistent check-in data;

[0012] S6. Obtain globally consistent sign-in data, and use zero-knowledge proof and homomorphic encryption methods to obtain privacy protection verification results.

[0013] In a preferred embodiment, S1 includes:

[0014] The pre-registration information of attendees was obtained, and data cleaning and format standardization were performed to obtain standardized identity files containing unique attendee numbers;

[0015] Obtain standardized identity profiles, collect facial images through mobile applications, evaluate the quality of the images, and obtain a facial image dataset;

[0016] A face image dataset is obtained and processed using a quality-aware adaptive feature extraction network. The feature extraction network adopts a dual-branch architecture, with the main branch being a lightweight convolutional neural network responsible for feature extraction, and the auxiliary branch being a quality assessment network responsible for predicting image quality and generating adaptive weights. The quality weights are fused and modulated with the original feature vector to obtain the face feature baseline vector.

[0017] A baseline vector of facial features is obtained, and a feature retrieval index is constructed using the Locality Sensitive Hash algorithm. This index is then synchronously distributed to each check-in terminal through a distributed caching system, resulting in a local feature library for each check-in terminal.

[0018] In a preferred embodiment, S2 includes:

[0019] Obtain the local feature library of the check-in terminal, use the check-in terminal camera to collect face images in real time, perform face alignment processing on the images, and obtain the face image to be recognized;

[0020] The system acquires the face image to be identified, uses local feature extraction and hash retrieval, calculates the cosine similarity between the query feature vector and the baseline vector, and obtains a list of candidate matching identities.

[0021] Obtain a list of candidate matching identities, use a preset similarity threshold to make an identity confirmation decision, and obtain the confirmed identities of the participants;

[0022] The system obtains the confirmed identity of the participants, collects device fingerprints and spatiotemporal information, and uses the national cryptographic SM2 elliptic curve digital signature algorithm to sign the check-in metadata, thus obtaining a tamper-proof check-in data packet.

[0023] In a preferred embodiment, S3 includes:

[0024] The anti-tampering sign-in data packet is obtained, and edge computing nodes are used to perform format integrity checks, digital signature verification, device legality verification, and timeliness verification to obtain a temporary confirmation result.

[0025] Obtain temporary confirmation results, temporarily store verified data packets using a local caching mechanism, and determine the timing of batch on-chain processing using time-triggered and capacity-triggered mechanisms to obtain a queue of data packets to be on-chain.

[0026] Obtain the queue to be uploaded to the chain, adopt the improved practical Byzantine fault-tolerant consensus algorithm, and reach consensus among the verification nodes through three stages: pre-preparation, preparation and submission. Parallel processing and fast path optimization are introduced to obtain consensus-confirmed transactions.

[0027] For transactions that have been confirmed through consensus, a Merkle tree index is constructed for the transaction, a block header is generated and the block hash is calculated, the block is written to the blockchain database, and a final confirmation message is sent to the check-in terminal through an asynchronous notification mechanism to obtain the blockchain record and final confirmation.

[0028] In a preferred embodiment, S4 includes:

[0029] Deploy a hybrid verification architecture, including a rules engine layer and a deep learning detection layer;

[0030] The rule engine layer performs time window verification, geofence verification, format integrity verification, and device legitimacy verification to obtain the basic rule verification results;

[0031] The deep learning detection layer uses an anomaly detection neural network with a network structure of a multilayer perceptron combined with a long short-term memory network. The multidimensional features of the sign-in data are encoded into feature vectors and input into the network. The network outputs the probability distribution of various anomalies, including duplicate sign-in, spatiotemporal contradictions, high frequency of anomalies, and behavioral mutation types, to obtain the anomaly pattern recognition results.

[0032] By combining the verification results of the rule engine and the deep learning detection layer, data packets that pass verification are added to the normal on-chain queue, while data packets with abnormal confidence levels exceeding a preset threshold are added to the arbitration queue, thus obtaining the off-chain verification results.

[0033] In a preferred embodiment, S4 further includes:

[0034] Arbitration smart contracts are deployed on the blockchain, and the contracts implement functions for duplicate check-in detection, spatiotemporal contradiction analysis, and anomaly frequency statistics.

[0035] Once the data for arbitration check-in is uploaded to the blockchain, the contract automatically calls the verification function, the duplicate check-in detection function queries historical records to check whether the time interval is less than the preset duplicate threshold, the spatiotemporal contradiction analysis function calculates the implicit speed to determine whether it exceeds the preset speed limit, and the abnormal frequency statistics function counts the number of check-ins by the device within the time window to determine whether it exceeds the preset frequency threshold, thus obtaining the abnormal identification result.

[0036] For sign-in records marked as abnormal, a manual review mechanism is used for verification. Based on the verification results, a correction application is submitted or the abnormality is confirmed, and a final decision is made.

[0037] In a preferred embodiment, S5 includes:

[0038] Each check-in edge node is assigned a unique node identifier, and each node maintains an N-dimensional vector clock, where N is the total number of nodes;

[0039] When a node processes a check-in event, it increments its corresponding vector clock component and appends the updated vector clock to the check-in data packet.

[0040] When a node receives a check-in data packet from another node, it merges the received vector clock with the local vector clock. The merging operation involves taking the maximum value of each component and then incrementing its corresponding component.

[0041] The Gossip protocol is used to propagate check-in data and vector clock status between nodes. Data freshness is determined by comparing vector clocks, thereby achieving state synchronization between nodes.

[0042] In a preferred embodiment, S5 further includes:

[0043] Check whether the meeting number in the new data already exists in the local check-in record, determine the causal relationship between records through the partial order relationship of vector clocks, and identify causal sequence conflicts and concurrent conflicts;

[0044] For causal sequence conflicts, a timestamp priority strategy is adopted, retaining the check-in record with the earlier timestamp;

[0045] For concurrent conflicts, an intelligent conflict resolution model is invoked for analysis. The model uses a gradient boosting decision tree algorithm. Input features include time interval, geographical distance, historical movement speed, and historical device reliability score. The output is the probability of the reasonableness of the concurrent conflict.

[0046] Based on the model's judgment results, two records are retained for reasonable concurrency, and the record with the higher credibility score is selected as the valid sign-in for abnormal concurrency, thus obtaining globally consistent sign-in data.

[0047] In a preferred embodiment, S6 includes:

[0048] The check-in data fields are classified into privacy levels to identify sensitive fields that need to be protected;

[0049] A check-in validity verification circuit is constructed using the zk-SNARKs algorithm. The public inputs of the circuit include the meeting number, the venue number, and the check-in time range. The private inputs include the identity token, the check-in timestamp, and the geographic coordinates. The circuit implements identity token constraints, time window constraints, geofence constraints, and signature constraints.

[0050] The proof generator executes a proof algorithm to generate a zero-knowledge proof file, and the verifier uses a verification key to verify the proof, thus obtaining a privacy-protected data proof.

[0051] The Paillier homomorphic encryption algorithm is used to encrypt the check-in data. The statistical nodes directly perform addition operations on the ciphertext, and the key management center decrypts it to obtain the aggregated statistical results and the privacy protection verification results.

[0052] In a preferred embodiment, a sign-in data integrity assurance system for conference management is used to perform the steps of the aforementioned sign-in data integrity assurance method for conference management, including:

[0053] The edge intelligent feature extraction module is used to obtain the pre-registration information of the participants. It uses edge intelligent feature extraction and distributed cache synchronization methods to obtain the local feature library of each check-in terminal.

[0054] The on-site rapid matching module is used to obtain the local feature library of each check-in terminal, and uses on-site rapid matching and spatiotemporal anchoring methods to obtain tamper-proof check-in data packets;

[0055] The layered consensus storage module is used to obtain tamper-proof sign-in data packets. It adopts layered consensus and blockchain storage methods to obtain blockchain records and final confirmation.

[0056] The intelligent verification and arbitration module is used to obtain blockchain records and final confirmation. It adopts deep learning-enhanced verification and intelligent arbitration methods to obtain data verification results and final disposal decisions.

[0057] The conflict resolution module is used to obtain data verification results and final disposal decisions. It adopts vector clock and intelligent conflict resolution methods to obtain globally consistent check-in data.

[0058] The privacy protection verification module is used to obtain globally consistent check-in data and uses zero-knowledge proof and homomorphic encryption methods to obtain privacy protection verification results.

[0059] The beneficial effects of this invention are as follows:

[0060] Face images are processed by a quality-aware adaptive feature extraction network. A dual-branch architecture is used to extract feature vectors and evaluate image quality simultaneously. A fast retrieval index is built by combining the locality-sensitive hashing algorithm, which achieves robust feature extraction and fast matching for images of different quality. Through a hierarchical consensus mechanism and blockchain storage, an improved practical Byzantine fault-tolerant consensus algorithm is used to achieve tamper-proof storage of check-in data, providing a reliable evidence storage capability for check-in data.

[0061] By employing deep learning to enhance verification and intelligent arbitration methods, a multilayer perceptron combined with a long short-term memory network is used to identify complex anomaly patterns, and on-chain automatic arbitration is achieved through smart contracts. By using vector clocks and intelligent conflict resolution methods, a gradient boosting decision tree algorithm is used to determine the rationality of concurrent conflicts, achieving global consistency of multi-venue distributed check-in data. Through zero-knowledge proofs and homomorphic encryption methods, the verifiability and statistical analysis capabilities of check-in data are achieved while protecting the privacy of attendees. Attached Figure Description

[0062] Figure 1 This is a flowchart of a method for ensuring the integrity of sign-in data in meeting management according to the present invention;

[0063] Figure 2 This is a flowchart of a method for ensuring the integrity of sign-in data for meeting management according to the present invention. Detailed Implementation

[0064] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0065] At least one embodiment of the present invention discloses a method for ensuring the integrity of check-in data for meeting management, such as... Figures 1 to 2 As shown, it includes the following steps:

[0066] S1. Collect the pre-registration information of the participants, and use edge intelligent feature extraction and distributed cache synchronization methods to obtain the local feature library of each check-in terminal;

[0067] S11. Obtain standardized identity profiles by fusing multi-source data to obtain pre-registration information of attendees;

[0068] Based on the participant registration data from the conference management system, pre-registration records containing basic information such as name, ID number, mobile phone number, work unit, and conference category are obtained. Data cleaning and format standardization are performed to convert identity information from different sources into a unified standard JSON format, resulting in a standardized identity file containing a unique participant number. Specifically, spaces and special characters are removed from the name field; the ID number undergoes format validation and checksum verification; and the mobile phone number undergoes location identification and validity checks. The validated fields are combined to generate a 16-digit unique participant number composed of the conference number, registration number, and timestamp. This participant number is then used as the primary key and associated with the identity file for storage.

[0069] S12. Obtain standardized identity profiles by collecting facial image datasets using mobile biometric data.

[0070] Based on the participant ID and mobile phone number in the standardized identity profile, electronic invitations containing unique QR codes are sent to participants via SMS or email. A mobile application is used to scan the QR code and log in, establishing a binding relationship between the participant and the system and granting them authorized biometric data collection permissions. A face capture module is integrated into the mobile application. Participants are guided to face the phone camera in a well-lit environment. A real-time face detection algorithm identifies the face region and determines the face pose angle. When a face is detected in the center of the frame and the angle deviation is less than 15 degrees, a shot is captured, resulting in an RGB face image with a resolution of 640 x 480 pixels. The quality of the captured face images is evaluated, checking image sharpness, illumination uniformity, and occlusion. The Laplacian operator is used to calculate the image sharpness index, grayscale histograms are used to analyze illumination distribution, and facial landmark detection is used to identify occluded areas. Images with quality scores higher than a preset acceptable threshold are saved in JPEG format, resulting in a face image dataset that meets the feature extraction requirements.

[0071] S13. Obtain the face image dataset and use quality-aware adaptive feature extraction to obtain the face feature baseline vector;

[0072] Based on a facial image dataset, the inconsistent quality of facial images collected during the pre-registration stage, including uneven lighting, blurring, and occlusion, leads to insufficient stability in feature extraction. Therefore, a quality-aware adaptive feature extraction network is employed to process the images, obtaining robust facial feature baseline vectors. The feature extraction network deployed on edge computing nodes adopts a dual-branch architecture: the main branch is a lightweight convolutional neural network responsible for feature extraction, while the auxiliary branch is a quality assessment network responsible for predicting image quality and generating adaptive weights, thus achieving quality-aware feature extraction capabilities.

[0073] The face image is input into the feature extraction network. The image first passes through a preprocessing layer to normalize its size to 112x112 pixels and its pixel values ​​to the range of 0 to 1. Then, it is simultaneously input into the main branch and auxiliary branches for parallel processing. The main branch adopts an improved MobileNetV3 architecture, achieving parameter compression through depthwise separable convolutions and linear bottleneck layers. A channel attention module is inserted after multiple convolutional layers. This attention module compresses the spatial dimension through global average pooling and then passes through two fully connected layers to learn the importance weights of each channel. Each channel of the feature map is weighted to enhance key features and suppress redundant features, resulting in a more discriminative intermediate feature representation. The final fully connected layer of the main branch outputs a 128-dimensional original face feature vector, with each dimension ranging from -1 to +1 (floating-point numbers), providing the initial feature representation.

[0074] The auxiliary branch employs a lightweight quality assessment network. The network structure consists of three convolutional layers and two fully connected layers. The convolutional layers extract image sharpness and texture features as well as illumination distribution features. The fully connected layers map the features to a quality score. The network is trained using supervised learning, with training data consisting of manually labeled face images of varying quality levels. The network learns to predict quality indicators such as image sharpness, illumination uniformity, and occlusion. The network outputs a quality score between 0 and 1, with higher scores indicating better image quality and more reliable features, thus yielding image quality weights.

[0075] The quality weights are fused with the original feature vectors using a weighted modulation mechanism. For high-quality images, the original features remain unchanged, while for low-quality images, the feature vectors are softened to reduce their confidence in subsequent matching. Specifically, each dimension of the feature vector is multiplied by the square root of the quality weight. The square root function smooths the impact of the quality weights, avoiding over-penalization of medium-quality images, resulting in a quality-aware modulated feature vector. The modulated feature vector is then L2-norm normalized, standardizing the vector length to 1, yielding a unit feature vector suitable for cosine similarity calculation. This vector serves as the facial feature benchmark for attendees, along with the corresponding quality score, which is associated with the attendee's ID and stored in the feature benchmark database, resulting in an enhanced facial feature benchmark database containing the attendee's ID, a 128-dimensional feature vector, and a quality score. During subsequent check-in matching, the system dynamically adjusts the matching threshold based on the quality score of the feature benchmark. A strict threshold is used for high-quality benchmarks to ensure accuracy, while the threshold is appropriately relaxed for low-quality benchmarks to improve recall, resulting in an adaptive matching strategy.

[0076] S14. Obtain the facial feature benchmark library and use Local Sensitive Hash Index to obtain a fast retrieval data structure;

[0077] Based on the 128-dimensional feature vectors of all attendees stored in the facial feature benchmark database, a feature retrieval index is constructed using the Locality Sensitive Hashing (LSH) algorithm, resulting in a data structure that supports fast approximate nearest neighbor search. Specifically, multiple sets of random projection vectors are generated, each containing 128 random numbers following a standard normal distribution. The facial feature vector and the random projection vector are then multiplied by a dot product. A binary hash code is generated based on the sign of the dot product result. Each random projection generates a 1-bit hash code, resulting in a 32-bit binary hash fingerprint through 32 sets of random projections. After converting the feature vectors of all attendees into 32-bit hash fingerprints, a hash table is used for storage. The key of the hash table is the hash fingerprint, and the value is a list of attendee numbers with the same or similar hash fingerprints, resulting in an index structure based on hash fingerprint binning. When face matching is required during on-site check-in, the hash fingerprint of the face to be identified is first calculated. Then, the hash table is searched for buckets with a Hamming distance less than a preset similarity threshold. Only the candidate feature vectors within the bucket are subjected to precise cosine similarity calculation, achieving a fast retrieval capability with matching time controlled within 100 milliseconds.

[0078] S15. Obtain the fast retrieval data structure by using distributed caching to synchronously obtain the local feature library of each check-in terminal;

[0079] Based on the facial feature benchmark library and fast retrieval data structure generated by edge computing nodes, a distributed caching system synchronously distributes data to the check-in terminal devices in each venue, enabling local feature matching capabilities at each terminal. 24 hours before the conference, the edge computing nodes package the feature benchmark library and hash index data into binary files and push them to each check-in terminal via LAN or the internet. Upon receiving the data packets, the check-in terminals perform integrity verification, calculate the hash value of the data packets using the SHA256 algorithm, and compare it with the hash digest provided by the edge nodes. If the verification passes, the data is decompressed and loaded into memory, resulting in a local feature matching engine that supports offline operation. For newly added or changed attendees during the conference, the edge nodes employ an incremental update mechanism, pushing only the changed feature data and the updated hash index differential file. The check-in terminals dynamically update their local caches upon receiving the incremental data, ensuring a feature library that is always up-to-date.

[0080] S2. Obtain the local feature library of each check-in terminal, and use on-site fast matching and spatiotemporal anchoring methods to obtain tamper-proof check-in data packets;

[0081] S21. Obtain the local feature library of the check-in terminal by collecting the face image to be identified on-site;

[0082] Based on the local feature library loaded on the check-in terminals at each venue, when attendees arrive at the check-in point to check in, the high-definition camera equipped on the check-in terminal captures facial images in real time to obtain the facial images to be identified for identity matching. After the face capture module of the check-in terminal is activated, the camera captures a video stream at a rate of 30 frames per second. For each frame, a face detection algorithm is run to identify the face location. An MTCNN detector based on a cascaded convolutional neural network is used. This detector gradually and accurately locates the face region through three stages: coarse screening, fine screening, and key point localization, obtaining detection results including the coordinates of the face bounding box and the positions of 5 key points. When a face is detected and the area of ​​the face bounding box occupies a proportion of the image area greater than a preset coverage threshold, it is determined to be a valid face and a snapshot is triggered. The current frame is extracted from the video stream as the face image to be identified. The image is then processed for face alignment. Based on the positions of key points such as the eyes and the tip of the nose, an affine transformation is performed to correct the face to a standard pose, resulting in an aligned face image with a normalized size of 112 by 112 pixels.

[0083] S22. Obtain the face image to be identified and use local feature extraction and hash retrieval to obtain a list of candidate matching identities;

[0084] Based on the face image to be identified, the local feature extraction module of the check-in terminal calls a pre-loaded lightweight face recognition model, using the same MobileNetV3 network structure as the pre-registration stage, to extract feature vectors from the face to be identified, obtaining a 128-dimensional query feature vector. The query feature vector is input into the local Local Sensitive Hash Index (LSI) system. First, a 32-bit hash fingerprint of the query feature is calculated, using the same random projection vector or learned hash function as when the feature benchmark library was built, to obtain the hash code to be matched. The hash table searches for all buckets whose Hamming distance to the query hash code is less than a preset retrieval threshold. This threshold is typically set to 3 to 5, allowing 3 to 5 different bits in the hash code, resulting in a set of candidate buckets containing potential matching targets. Feature benchmark vectors corresponding to all participant numbers are extracted from the candidate buckets, and the cosine similarity between the query feature vector and the benchmark vector is calculated for each. The similarity calculation formula is the dot product of the two vectors divided by their respective L2 norms. Since the vectors have been normalized to unit vectors, the similarity is simply the dot product of the two vectors, resulting in a similarity score for each candidate identity. Sort the similarity scores from high to low, select the top 5 candidates with the highest scores as the matching results, and obtain a list of candidate matching identities containing the conference number and matching similarity.

[0085] S23. Obtain a list of candidate matching identities and use a similarity threshold to determine the confirmed identities of the attendees;

[0086] Based on the similarity scores of each candidate identity in the candidate matching identity list, a preset similarity judgment threshold is used to make an identity confirmation decision, resulting in the final identified attendee identity. Specifically, the first candidate with the highest similarity in the candidate list is checked. If its similarity score is greater than a preset high confidence threshold (set based on the model's performance on the validation set to ensure a false recognition rate of less than one in ten thousand), the first candidate is directly determined to be a successfully matched identity, and the confirmed attendee number and corresponding identity profile information are obtained. If the similarity score of the first candidate is between the high confidence threshold and the low confidence threshold, the similarity difference between the first candidate and the second candidate is further checked. If the difference is greater than a preset discrimination threshold, it indicates that the first candidate is significantly better than other candidates, and it is still determined to be a successfully matched attendee identity; if the difference is less than the discrimination threshold, it indicates that there are multiple similar candidates that are difficult to distinguish, and the system prompts the sign-in personnel to perform secondary verification by manually entering the last four digits of their mobile phone number or ID card number to assist in confirmation, thus obtaining the accurate identity after secondary verification. If the similarity score of the first candidate is lower than the low confidence threshold, it is determined that no pre-registered identity has been matched. The system prompts the person checking in to contact the conference affairs team for on-site registration, resulting in an abnormal check-in record that needs to be manually processed.

[0087] S24. The identity of confirmed participants is obtained by using device fingerprints and spatiotemporal information to obtain check-in metadata;

[0088] Based on the confirmed participant identity information, including participant number and identity file, the check-in terminal further collects device fingerprints and spatiotemporal information to obtain check-in metadata for data integrity assurance. The check-in terminal reads its own hardware information, including the MAC address of the network interface, device serial number, operating system version, and application version number. This information is concatenated and then used to calculate a 32-byte device fingerprint using the SM3 national cryptographic hash algorithm. This device fingerprint uniquely identifies the check-in terminal device and is used to trace the source of the check-in data. The check-in terminal's positioning module activates dual-mode positioning functionality using both the BeiDou Navigation Satellite System and the GPS Global Positioning System. It receives satellite signals and calculates the current geographical location, obtaining three-dimensional coordinates including latitude, longitude, and altitude. Positioning accuracy can reach within 5 meters in open environments, and can maintain 10-meter accuracy indoors or in obstructed environments with assisted positioning technology, obtaining the geographical location data of the check-in point. The check-in terminal obtains standard UTC (Coordinated Universal Time) from the NTP (Network Time Protocol) server and uses the SNTP (Simple Network Time Protocol) for time synchronization, ensuring that the clock error of each check-in terminal is controlled within 50 milliseconds, obtaining a current timestamp with millisecond-level accuracy. The information such as the participant number, device fingerprint, geographic coordinates, timestamp, venue number, and check-in type is organized into a structured JSON format to obtain check-in metadata containing complete check-in elements.

[0089] S25. Obtain the sign-in metadata by digitally signing it using the national cryptographic algorithm to obtain a tamper-proof sign-in data packet;

[0090] Based on the check-in metadata, the check-in terminal uses the national cryptographic SM2 elliptic curve digital signature algorithm to sign the metadata, resulting in a check-in data packet with tamper-proof protection. The security chip of the check-in terminal has a pre-installed public-private key pair for the SM2 algorithm. The private key is stored in the protected storage area of ​​the security chip, inaccessible to any external program. The public key is associated with the device fingerprint and registered with the central management platform during system initialization, obtaining a verifiable device identity credential. The check-in metadata is serialized into a byte stream, and the digest value of the metadata is calculated using the SM3 hash algorithm, resulting in a 32-byte message digest. Then, the signature interface of the security chip is called, taking the message digest and private key as input, to perform the SM2 signature operation, resulting in a 64-byte digital signature containing two components: an R value and an S value. The original check-in metadata, digital signature, device public key, and signature timestamp are encapsulated into a check-in data packet, and the fields are organized using the TLV tag-length-value encoding format to obtain a self-describing data structure. An integrity check code is calculated for the check-in data packet, and a 4-byte check code is generated using the CRC32 cyclic redundancy check algorithm and appended to the end of the data packet, resulting in a check-in data packet capable of detecting transmission errors.

[0091] S3. Obtain tamper-proof sign-in data packets, and use layered consensus and blockchain storage methods to obtain blockchain records and final confirmation;

[0092] S31. Obtain temporary confirmation results by quickly verifying edge nodes to obtain tamper-proof sign-in data packets;

[0093] Based on the check-in data packet generated by the check-in terminal, a fast verification service deployed on edge computing nodes performs preliminary verification of the data packet to obtain a provisional confirmation result for rapid completion of the check-in process. The check-in terminal sends the check-in data packet to the nearest edge computing node via a local area network or wireless network. Upon receiving the data packet, the edge node first performs a format integrity check, verifying whether the TLV encoding structure of the data packet conforms to the specification, checking whether the labels and lengths of each field match, calculating the CRC32 checksum and comparing it with the checksum in the data packet to obtain the format verification result. If the format verification passes, the edge node further performs digital signature verification, extracting the device public key and digital signature from the data packet, and using the SM2 verification algorithm to verify the digest of the check-in metadata, confirming that the data packet was indeed generated by the check-in terminal holding the corresponding private key and that the data has not been tampered with, thus obtaining the signature verification result. The edge node queries its local cache to check whether the device public key corresponding to the device fingerprint has been registered, confirming that the check-in terminal is a legitimate and authorized device, thus obtaining the device legitimacy verification result. The edge node checks whether the timestamp in the check-in data packet is within a reasonable range. It compares the timestamp of the data packet with the current time of the edge node. If the absolute value of the time difference is less than a preset time window, such as 5 minutes, the timestamp is deemed valid, and the timeliness verification result is obtained.

[0094] Once format verification, signature verification, device legitimacy verification, and timeliness verification all pass, the edge node generates a temporary confirmation message containing the hash identifier of the check-in data packet and the confirmation status. The confirmation message is then signed using the edge node's private key using the SM2 algorithm, resulting in a verifiable temporary confirmation result. This temporary confirmation message is returned to the check-in terminal via the network. Upon receiving the confirmation, the check-in terminal displays a successful check-in message and records the check-in completion time, providing a fast check-in experience for the user. The entire process, from data packet transmission to confirmation receipt, is typically completed within 500 milliseconds. If any verification step fails, the edge node generates a failure response message containing the failure reason code and error description, which is returned to the check-in terminal. The check-in terminal then prompts the user to re-check in or contact event organizers based on the error type, ensuring a user-friendly handling of any abnormal situations.

[0095] S32. Obtain the temporary confirmation result by using the edge node data cache to obtain the queue to be uploaded to the chain;

[0096] Based on the temporary confirmation results generated by the edge nodes, for verified check-in data packets, the edge nodes use a local caching mechanism to temporarily store the data packets in a queue to be uploaded to the blockchain, thus preparing the data for batch uploading. The edge nodes maintain a first-in, first-out (FIFO) data queue, stored on the edge nodes' persistent storage devices, managed using a high-performance key-value database such as RocksDB, ensuring data is not lost even after a node restart. Verified check-in data packets are inserted into the tail of the queue in arrival order, each packet is assigned an incrementing sequence number, and its enqueue timestamp is recorded, resulting in an ordered stream of data to be processed. The edge nodes monitor the queue status and use both time-triggered and capacity-triggered mechanisms to determine when to initiate batch uploading operations. Specifically, the batch interval is set to 10 seconds and the batch capacity to 100 records. When the number of accumulated data packets in the queue reaches 100 or 10 seconds have passed since the last batch uploading, the batch packaging process is triggered, resulting in an uploading strategy that balances real-time performance and efficiency.

[0097] During batch packaging, edge nodes retrieve a set of data packets to be uploaded to the blockchain from the head of the queue. They preprocess these packets, extracting key fields such as participant number, timestamp, and venue number to construct an index for the batch data, obtaining metadata for easy subsequent querying. The edge nodes calculate a hash digest of the entire batch of data packets, serialize all packets, concatenate them into a byte stream, and use the SM3 algorithm to calculate a batch digest, obtaining a hash value representing the integrity of the batch. Finally, the edge nodes encapsulate the batch data packets, index information, batch digest, and edge node signature into an on-chain transaction, encoding it using the blockchain network's transaction format to obtain the transaction data to be submitted to the blockchain network.

[0098] S33. Obtain transactions from the queue to be uploaded to the blockchain that have been confirmed by the improved PBFT consensus;

[0099] Based on the on-chain transaction data generated by edge nodes, the improved Practical Byzantine Fault Tolerance (PBFT) consensus algorithm is used to reach consensus among the validator nodes of the blockchain network, resulting in a legally confirmed transaction. The blockchain network consists of a consortium blockchain architecture composed of multiple validator nodes. Each validator node is operated by different entities such as the conference organizer, regulatory authorities, and third-party auditing institutions to ensure the decentralization and trustworthiness of the network. Edge nodes broadcast on-chain transactions to the blockchain network, which are received by the master node of the current round. The master node performs preliminary verification on the transaction, including format checks, signature verification, and replay checks. After successful verification, the master node packages the transaction into a pre-prepared message, which includes the view number, sequence number, transaction data, and master node signature, thus obtaining a message ready to enter the consensus process.

[0100] The master node broadcasts the pre-preparation message to all verification nodes. Each verification node performs independent verification upon receiving the message, checking whether the view number matches the local view number. Figure 1 The process begins with a check of the sequence number to ensure it's within the valid range, verification of the master node's signature, and verification of the transaction data's integrity, resulting in a local verification result. If verification passes, the validating node broadcasts a preparation message to all other validating nodes. This message includes the view number, sequence number, transaction summary, and node signature, signifying the node's acceptance of the transaction. Each validating node collects preparation messages from other nodes. When it receives preparation messages from more than two-thirds of the total number of nodes, it considers the transaction ready and enters the commit phase, achieving consensus in the preparation phase. Next, the validating node broadcasts a commit message to all nodes. This message includes the view number, sequence number, and node signature, signifying the node's commitment to execute the transaction. Each validating node collects commit messages. When it receives commit messages from more than two-thirds of the total number of nodes, it executes the transaction, writing the transaction data to its local blockchain ledger, thus obtaining final confirmation of the transaction.

[0101] The improved PBFT algorithm introduces parallel processing and fast path optimization on top of the standard PBFT. Specifically, the master node can handle the consensus process of multiple transactions simultaneously, with pre-preparation, preparation, and commit messages for different transactions propagating in parallel. Each validator node maintains a consensus state machine with multiple sequence numbers, resulting in improved consensus throughput. For cases with high validator node consistency, a fast path mechanism is adopted, merging the pre-preparation and preparation phases. The master node directly requests commit in the pre-preparation message; if all nodes agree, the preparation phase is skipped, and the commit phase is initiated directly, reducing consensus latency. The master node employs an adaptive batch size strategy, dynamically adjusting the number of transactions packaged in a batch based on the current network load and transaction arrival rate. When the load is high, the batch size is increased to reduce the number of consensus rounds; when the load is low, the batch size is decreased to reduce latency, achieving adaptive performance optimization.

[0102] S34. Transactions that have obtained consensus confirmation are recorded on the blockchain through block construction and chain storage.

[0103] Based on consensus-confirmed transactions, validator nodes use a block-building algorithm to organize the transactions into blocks and add them to the blockchain, resulting in an immutable chain-like storage structure. Validator nodes retrieve a batch of transactions from the consensus-confirmed transaction queue; the number of transactions is determined by the block size limit, typically containing 10 to 100 on-chain transactions. Each on-chain transaction contains multiple sign-in data packets, resulting in the transaction set of the block. Validator nodes construct a Merkle tree index for the transactions within the block, using the hash value of each transaction as a leaf node of the Merkle tree. They pair up the nodes and calculate the parent node's hash value, which is equal to the SM3 hash of the concatenation of the two child node hash values. This process is recursively performed upwards until a unique Merkle root hash is generated, resulting in a compact proof structure for the block's transactions.

[0104] Validator nodes construct the block header, which contains several key fields: a version number identifying the blockchain protocol version; a preceding block hash pointing to the hash value of the previous block on the chain to establish a chained connection between blocks; a Merkle root hash, the root node hash of the Merkle tree of the current block's transactions; a timestamp recording the block generation time; a difficulty target and a random number field, which are typically not used or set to fixed values ​​in consortium blockchains; and a block height recording the block's sequence number on the chain, resulting in the complete block header structure. Validator nodes use the SM3 algorithm to calculate the hash value of the block header, which serves as the unique identifier for the current block and is referenced by the block header of the next block, establishing a chained dependency relationship between blocks. Validator nodes package the block header and transaction data into a complete block and write it to their local blockchain database, using a key-value database such as LevelDB or RocksDB for storage. The block hash serves as the key, and the block data as the value. Simultaneously, the block height index and transaction hash index are updated, resulting in a storage structure that supports efficient queries.

[0105] After a block is successfully written, the validator node broadcasts the block addition result to the blockchain network. Other validator nodes receive the new block and verify it, checking if the hash of the preceding block matches the local tail block, verifying if the Merkle root matches the transactions within the block, and checking the signatures and formats of the transactions within the block. If the verification is successful, the block is appended to the local blockchain, resulting in a distributed ledger synchronized by multiple nodes. In the event of a fork due to network latency, nodes adopt the longest chain principle, selecting the chain with the largest block height as the main chain. Blocks on the shorter chain are rolled back, and the transactions on those chains re-enter the consensus queue, resulting in a final, consistent blockchain state.

[0106] S35. Obtain the final confirmation from the check-in terminal by using asynchronous confirmation notification to obtain the blockchain record;

[0107] Based on the check-in records already stored on the blockchain, the verification node uses an asynchronous notification mechanism to send a final confirmation message to the edge nodes and check-in terminals, obtaining a reliable credential for the check-in data being uploaded to the blockchain. After a block is successfully added to the blockchain, the verification node extracts the edge node identifiers corresponding to each transaction uploaded to the blockchain from the block, generates a confirmation message containing the block hash, block height, transaction index, and Merkel proof path, and signs the confirmation message with the verification node's private key using the SM2 algorithm to obtain a verifiable credential for uploading to the blockchain. The verification node sends the confirmation message to the corresponding edge node via the network. After receiving the confirmation message, the edge node verifies the signature validity, extracts the transaction index from the confirmation message, finds the corresponding check-in data packet from the queue to be uploaded to the blockchain, updates the status of the data packet from pending confirmation to uploaded to the blockchain, and records the block hash and Merkel proof, obtaining complete traceability information for the check-in data.

[0108] Edge nodes further push final confirmation notifications to the check-in terminals. For terminals still online, the notification is pushed via real-time communication. Upon receiving the notification, the terminal records the on-chain confirmation information in its local log, thus completing the check-in transaction loop. For offline check-in terminals, the edge nodes cache the confirmation information, waiting for the terminal to actively retrieve it upon its next connection, providing a delayed but reliable confirmation mechanism. Check-in terminals can query the blockchain network to verify the existence and integrity of the check-in record based on the block hash and Merkel proof. Any participant or auditor holding a Merkel proof can independently verify that the check-in record has not been tampered with, ensuring decentralized trust.

[0109] S4. Obtain blockchain records and final confirmation, and use deep learning to enhance verification and intelligent arbitration methods to obtain data verification results and final disposal decisions;

[0110] S41. Obtain the off-chain verification results by using deep learning to enhance the verification of the queue to be uploaded to the chain.

[0111] Based on the check-in data packets in the queue waiting to be uploaded to the blockchain at edge nodes, a deep learning-enhanced off-chain pre-verification mechanism is adopted for data quality inspection because traditional rule engines struggle to identify complex anomaly patterns and covert cheating behaviors. This results in verification results that quickly filter out anomalous data. A hybrid verification architecture is deployed on the edge nodes, comprising a rule engine layer and a deep learning detection layer. The rule engine layer is responsible for basic rule verification, while the deep learning detection layer is responsible for identifying complex anomaly patterns. These two layers work together to achieve comprehensive data verification, resulting in multi-layered verification capabilities.

[0112] Edge nodes read data packets to be uploaded to the blockchain one by one, first performing rapid basic verification through the rule engine layer. The rule engine loads a pre-compiled set of verification rules, which includes multi-dimensional verification logic such as time window verification, geofence verification, format integrity verification, and device legitimacy verification. The rules are written in declarative syntax, supporting flexible updates and providing configurable basic verification capabilities. The rule engine extracts key fields from the data packets, including meeting number, timestamp, geographic coordinates, venue number, and device fingerprint, as input facts, and executes various verification rules. It checks whether the timestamp is within the valid meeting check-in period, whether the geographic coordinates are within the venue fence area using point-to-center distance comparison or ray casting, whether required fields are complete and their data types conform to specifications, and whether the device fingerprint is in the authorized whitelist, thus obtaining the basic rule verification results.

[0113] For data packets that pass the basic rule verification, they are further input into a deep learning detection layer for anomaly pattern recognition. The deep learning detection layer employs an anomaly detection neural network, with a network structure combining a multilayer perceptron and a long short-term memory network, used to capture the temporal patterns and contextual relationships of check-in behavior. The multidimensional features of the check-in data packets are encoded, including the historical check-in frequency of attendees, the spatiotemporal interval between the current check-in and the previous check-in, the historical reliability score of the equipment, and the real-time check-in density of the venue. These features are concatenated into a fixed-length feature vector to obtain the input representation for anomaly detection.

[0114] The anomaly detection network is trained using supervised learning. Training data includes historical attendance records and their labeled anomaly types. The network learns the discrimination boundary between normal and abnormal attendance patterns. The multilayer perceptron portion of the network extracts a nonlinear combination of feature vectors through three fully connected layers. ReLU activation functions are used between each layer to introduce nonlinear transformation capabilities. The long short-term memory (LSTM) network analyzes the temporal attendance behavior of attendees, capturing long-term dependencies through forgetting, input, and output gate mechanisms. This identifies anomalous temporal patterns such as multiple attendances within a short period or sudden attendance after a long period of absence, yielding temporal anomaly features. The network's output layer is a multi-classifier, using a softmax function to output the probability distribution of various anomalies, including repeated attendance, spatiotemporal inconsistencies, high-frequency anomalies, and behavioral mutations. The network selects the category with the highest probability as the prediction result and outputs an anomaly confidence score, thus obtaining the anomaly pattern recognition result.

[0115] Edge nodes combine the verification results of the rule engine and the deep learning detection layer. For data packets deemed normal by both layers, they are marked as verified and added to the normal on-chain queue, resulting in high-quality on-chain candidate data. For data packets deemed abnormal by the rule engine or whose anomaly confidence level exceeds a preset threshold by the deep learning detection layer, they are marked as suspected abnormal and given an anomaly type label and confidence score. These data packets are then added to a separate arbitration queue and submitted to the chain, but marked as requiring further review, resulting in a tiered verification strategy. Edge nodes statistically analyze the off-chain verification results, recording the verification pass rate, the distribution of various anomalies, and the detection accuracy of the deep learning model, generating verification logs for a traceable record of the verification process. The deep learning model is periodically incrementally trained using new labeled data to continuously optimize its anomaly detection capabilities, adapt to emerging cheating patterns, and achieve continuously evolving verification capabilities.

[0116] S42. Obtain off-chain verification results by loading on-chain arbitration rules using a smart contract;

[0117] Based on suspected abnormal data packets generated from off-chain verification, deep arbitration verification is performed using blockchain smart contracts. First, arbitration rules need to be deployed and loaded onto the blockchain to obtain on-chain executable verification logic. Smart contract developers use smart contract programming languages ​​such as Solidity or Go to write arbitration contract code. The contract code implements complex verification logic such as duplicate check-in detection, spatiotemporal contradiction analysis, and anomaly frequency statistics. The contract code is compiled into bytecode, resulting in a contract program that can run on the blockchain virtual machine. The blockchain administrator deploys the contract bytecode to the blockchain via transactions. After the contract deployment transaction is confirmed through consensus, the contract is assigned a unique contract address. Each verification node loads the contract code in its local blockchain virtual machine, resulting in a distributed execution smart contract instance.

[0118] The arbitration smart contract defines several verification functions. The duplicate check-in detection function takes the meeting number and timestamp as input, queries the blockchain history for all check-in records for that meeting number, and checks for multiple records with time intervals less than a preset duplicate threshold (typically set to 30 minutes). If such records exist, they are considered duplicate check-ins, resulting in the duplicate detection logic. The spatiotemporal contradiction analysis function takes the timestamps and geographical coordinates of two check-in records, calculates the distance between the two locations using the spherical distance formula based on the Earth's radius and the difference between latitude and longitude, and simultaneously calculates the time interval between the two timestamps. It determines whether the distance can be traveled within a given time interval, setting a reasonable speed threshold based on normal human movement speed and vehicle speed. If the actual speed exceeds the threshold, it is considered a spatiotemporal contradiction, resulting in the physical reachability detection logic. The abnormal frequency statistics function takes the device fingerprint and time window, counts the number of check-ins processed by the device within the time window, and determines an abnormally high frequency if the number exceeds the upper limit of normal processing capacity, resulting in the device behavior anomaly detection logic.

[0119] The smart contract also defines a data access interface for querying historical attendance records stored on the blockchain. The interface function receives query conditions such as meeting number, time range, and venue number, traverses the blockchain's blocks and transactions, extracts attendance data packets matching the query conditions, and uses indexing to accelerate the query process, thus achieving the ability to retrieve historical data. The smart contract also defines an event publishing mechanism. When an anomaly is detected, the contract broadcasts an anomaly alert through the event mechanism. The event includes the anomaly type, the identifier of the involved attendance record, and a detailed description of the anomaly. Blockchain nodes listen for contract events and push the alert to the monitoring system, obtaining real-time anomaly notification capabilities.

[0120] S43. Obtain the anomaly identification results by automatically executing the on-chain arbitration rules using the contract.

[0121] Based on an arbitration smart contract deployed on the blockchain, when check-in data marked as pending arbitration is uploaded to the chain, the contract automatically triggers the execution verification logic to obtain an anomaly identification result. When processing transactions containing check-in data pending arbitration, the blockchain verification node identifies the arbitration marker in the transaction, automatically calls the verification function of the arbitration smart contract, and takes the check-in data packet pending arbitration as input to obtain a contract execution request. The smart contract's duplicate check-in detection function is called. This function extracts the participant number and timestamp from the check-in data packet, queries the blockchain history through the contract's data access interface, and retrieves all check-in records for that participant number within a preset time window before and after the current timestamp, obtaining a candidate duplicate record set. The contract function iterates through the candidate set, calculates the time interval between each historical record and the current record, and if a record with a time interval less than 30 minutes is found, the current check-in is determined to be a duplicate check-in. The contract generates a duplicate check-in anomaly flag and appends it to the verification result field of the data packet, obtaining the duplicate determination result.

[0122] The smart contract's spatiotemporal discrepancy analysis function is invoked. This function queries the most recent check-in record for the given meeting number, extracts the timestamp and geographic coordinates of the previous check-in, and calculates the time interval and spatial distance between the previous and current check-ins. The time interval is equal to the difference between the two timestamps, and the spatial distance is calculated using the Haversine formula to obtain the shortest distance on a sphere, thus yielding the spatiotemporal difference data. The contract function calculates the implicit speed, which is equal to the spatial distance divided by the time interval. It then checks if the implicit speed exceeds a preset reasonable speed limit, typically set at 120 km / h to cover high-speed rail and other rapid transportation. If the implicit speed exceeds this limit, a spatiotemporal discrepancy is identified, and the contract generates a spatiotemporal anomaly flag, resulting in a physical consistency determination. The smart contract's abnormal frequency statistics function is also invoked. This function extracts the device fingerprint of the check-in data packet and queries the number of check-in records processed by the device in the last 10 minutes. If the number exceeds a preset frequency threshold (e.g., 50 times), considering the processing capacity of a normal check-in terminal during peak hours, it is determined to be abnormally high-frequency. The contract generates a frequency anomaly flag, resulting in a device behavior determination.

[0123] The contract summarizes the judgment results of various verification functions to generate a comprehensive verification report. The report includes the conclusion of whether the verification passed or failed, the specific type of failure, a detailed description of the failure, and relevant evidence data, resulting in a structured verification result. The contract writes the verification result to the blockchain as an additional attribute of the check-in data packet. Simultaneously, it broadcasts the verification result through an event mechanism. Blockchain nodes, upon receiving an event, push the failure record to the monitoring interface of the meeting management system, resulting in real-time failure alerts. For data packets that pass verification, the contract marks them as verified. For data packets with failures, the contract marks them as affected but retains the original data and verification result, without deleting or modifying the original record, ensuring the integrity of audit traceability and providing an evidence-preserving failure handling strategy.

[0124] S44. The results of anomaly identification are obtained through a manual review mechanism to arrive at the final decision-making process.

[0125] Based on the anomaly identification results generated by the smart contract, attendance records marked as abnormal are subject to further manual review for judgment, leading to a final decision. The conference management system's monitoring interface displays real-time anomaly alarms broadcast by the smart contract. Upon seeing an alarm, monitoring personnel can view the anomaly details. The system retrieves complete information about the abnormal attendance records from the blockchain, including attendee identity, attendance time and location, anomaly type, and the smart contract's judgment basis, resulting in anomaly cases to be reviewed. Monitoring personnel conduct targeted checks based on the anomaly type. For duplicate attendance anomalies, investigators contact attendees to confirm whether multiple attendances were indeed made, checking for system misjudgments or reasonable attendance at different venues, thus confirming duplicate attendance. For spatiotemporal inconsistencies, investigators analyze attendees' movement paths, considering the possibility of special transportation methods such as helicopters or data collection errors, and, if necessary, retrieve other evidence such as surveillance footage or access control records for corroboration, thus confirming spatiotemporal inconsistencies.

[0126] For abnormal frequency anomalies, investigators check the operation logs of the check-in terminal devices to analyze whether there are duplicate submissions caused by equipment malfunctions or whether there is indeed human-induced mass forgery of check-ins, thus obtaining a verification conclusion of abnormal frequency. Based on the verification conclusion, investigators make a decision on how to handle the situation. If it is confirmed to be a misjudgment, investigators submit a correction application in the conference management system. The application includes the anomaly record identifier and the reason for correction. After the system administrator approves it, a correction transaction is submitted to the blockchain, calling the correction function of the smart contract to change the anomaly mark to a corrected state and attach a correction explanation, resulting in an update of the anomaly record's status. If it is confirmed to be a genuine anomaly, investigators handle it according to the conference management regulations, which may include revoking the check-in record, recording the violation, notifying the relevant responsible persons, recording the processing results in the conference management system, and simultaneously submitting a confirmation transaction for the anomaly to the blockchain. The smart contract solidifies the anomaly status and adds a manual confirmation tag, resulting in the final handling of the anomaly record.

[0127] S5. Obtain data verification results and final disposal decisions, and use vector clock and intelligent conflict resolution methods to obtain globally consistent check-in data;

[0128] S51. Obtain the causal tracking mechanism by initializing the check-in nodes of each venue using a vector clock.

[0129] Based on the check-in edge nodes deployed at each venue, a vector clock algorithm is used to establish a distributed time-series tracing mechanism for each node, thus obtaining a data synchronization foundation that supports causal consistency. During system initialization, each check-in edge node in the blockchain network is assigned a unique node identifier. The node identifier can be a public key hash or a pre-assigned sequence number. Assuming there are N nodes in the network, the node identifiers are numbered from 0 to N minus 1, resulting in the node's global number. Each node maintains an N-dimensional vector clock locally. Each component of the vector corresponds to a node, and the component value is an integer representing the logical time of the corresponding node observed by that node. Upon system startup, the vector clocks of all nodes are initialized to a zero vector, resulting in the initial time-series state.

[0130] When a node processes a check-in event, it increments its corresponding vector clock component. Specifically, after processing a check-in event, node i increments the i-th component of its vector clock by 1, leaving other components unchanged, thus obtaining an updated local vector clock. The node appends the updated vector clock to the check-in data packet. The vector clock serves as the timing metadata of the data packet and propagates along with the data, resulting in check-in data carrying causal information. When a node receives a check-in data packet from another node, it extracts the vector clock from the packet and merges it with its local vector clock. The merging operation involves taking the maximum value of the two corresponding components of each vector clock and then incrementing its own corresponding component, resulting in a merged vector clock reflecting causal relationships. Through the maintenance and merging of vector clocks, the system can trace causal relationships between events, determine whether two events have causal dependencies or are concurrent events, and obtain partial order relationships of events in a distributed environment.

[0131] S52. The causal tracing mechanism uses the Gossip protocol to propagate state synchronization between nodes.

[0132] Based on the vector clocks maintained by each node, the Gossip protocol is used to propagate check-in data and vector clock states among nodes, achieving eventual consistent distributed data synchronization. Each check-in node periodically initiates a Gossip round, with the round interval set to 2 to 5 seconds. At the start of each round, the node randomly selects a fixed number of nodes from all other nodes as Gossip targets, typically 3 to 5, thus obtaining the communication objects for this round. The node sends a Gossip message to the selected Gossip targets. The message contains the set of check-in data packets recently processed by the node, the node's current vector clock, and a summary of the set of globally known check-in personnel identities, thus providing the propagation carrier for the node's state.

[0133] After receiving a message, the Gossip target node first compares the vector clock in the message with its local vector clock. This comparison determines whether the data in the message is locally known. Specifically, if all components of the message's vector clock are less than or equal to the corresponding components of the local vector clock, the data in the message is known and can be ignored. If at least one component of the message's vector clock is greater than the corresponding component of the local vector clock, the message contains new data and needs processing, resulting in a data freshness assessment. For messages containing new data, the target node extracts the sign-in data packets from the message, checks the signature and format validity of the data packets, and merges the data packets into its local sign-in record set after successful verification. Simultaneously, the local vector clock is updated to the merged result of the local vector clock and the message vector clock, achieving incremental data synchronization.

[0134] The target node examines the global check-in participant identity set digest in the message. This digest is represented using a Bloom filter or a hash set. The node compares the digest with its local identity set, identifying identities it possesses but the message sender lacks, or identities the message sender possesses but its local set lacks, thus performing data discrepancy analysis. The node replies to the message sender with a Gossip response message, containing the missing check-in data packets and its current vector clock, achieving bidirectional data exchange. Upon receiving the response, the message sender also performs vector clock comparison and data merging, resulting in a symmetrical synchronization process. After multiple Gossip rounds, all nodes in the network gradually converge to a consistent data state, with each node possessing all check-in data and the vector clock reflecting the global event order, ensuring eventual consistency.

[0135] S53. The state synchronization between nodes is obtained by using intelligent conflict detection and predictive resolution to achieve concurrent sign-in identification and conflict resolution.

[0136] Based on the synchronized check-in data using the Gossip protocol, traditional conflict detection methods, relying solely on timestamps and vector clocks, struggle to accurately assess the rationality of complex concurrent scenarios. Therefore, an intelligent conflict detection and predictive resolution algorithm is employed to identify concurrent or conflicting check-in records, revealing anomalies requiring special handling. When merging check-in data from other nodes, a node checks if the participant number in the new data already exists in its local check-in record. If it does, it may indicate a duplicate or conflicting check-in, thus identifying conflict candidates.

[0137] The node extracts multiple check-in records involved in potential conflicts, first performing causal relationship analysis using vector clocks. By comparing the vector clocks associated with these records, the causal relationship between the records is determined through the partial order of the vector clocks. If the vector clock of one record is less than or equal to that of another record in all components, then the former is causally preceding the latter; the former may be a normal check-in, while the latter is a duplicate check-in, resulting in a conflict in the causal sequence. If the vector clocks of two records do not satisfy a total order relationship, meaning each has at least one component greater than the other, then the two records are concurrent events, indicating check-ins occurring simultaneously in different venues, thus obtaining concurrent conflict candidates.

[0138] For causal sequence conflicts, nodes employ a timestamp-first strategy, retaining earlier timestamp check-in records as valid and marking later timestamp records as duplicate check-ins, thus obtaining the causal conflict resolution result. For concurrent conflicts, since simple rules are insufficient to determine the rationality of concurrent check-ins, nodes invoke an intelligent conflict resolution model for in-depth analysis. The intelligent conflict resolution model uses a gradient boosting decision tree algorithm. The model is trained using historical conflict cases and their manual judgment results, learning to distinguish between reasonable and abnormal concurrency, thereby obtaining the predictive ability for conflict resolution.

[0139] The nodes input the features of concurrent conflict records into the intelligent resolution model. These features include multi-dimensional information such as the time interval between the two records, geographical distance, historical movement speed of attendees, traffic connections between venues, differences in check-in types, and historical reliability scores of equipment. These features are encoded into feature vectors, which become the model input. The gradient boosting decision tree of the intelligent resolution model uses ensemble learning of multiple decision trees. Each tree is trained based on the prediction residuals of the previous tree, and the gradient descent method is used to optimize the loss function, gradually improving prediction accuracy. The model outputs the probability of the reasonableness of the concurrent conflict. A high probability indicates that the concurrency is reasonable and both records should be retained, while a low probability indicates that the concurrency is abnormal and only one record should be retained, thus obtaining the conflict reasonableness assessment.

[0140] For records deemed reasonable concurrency by the model, nodes retain two records and mark them as concurrent events, recording the attendance trajectories of participants in different venues to achieve coexistence of concurrent records. For records deemed abnormal concurrency by the model, nodes further calculate the credibility score of the two records. The credibility score comprehensively considers factors such as the quality of historical data from the device, the matching degree between the attendance time and the meeting agenda, and the positioning accuracy of the geographical location. A weighted summation method is used to calculate the comprehensive score, and the record with the higher credibility score is selected as the valid attendance. The other record is marked as a suspected anomaly, resulting in credibility-based conflict resolution. Nodes record the conflict detection and resolution results in their local logs, including the conflict type, the intelligent model's judgment result, and the final handling decision. Simultaneously, the conflict resolution decision is propagated to other nodes via the Gossip protocol. Other nodes adopt the same intelligent resolution model and strategy, ultimately achieving consensus across the entire network on conflict handling, resulting in the convergence of distributed conflict resolution. The intelligent resolution model is periodically incrementally trained using new conflict cases to continuously optimize its judgment capabilities, adapt to changes in meeting scenarios, and achieve continuously evolving conflict resolution capabilities.

[0141] S54. Obtain concurrent sign-in recognition by using network partition detection to obtain isolation status perception;

[0142] Based on the communication status of the Gossip protocol, a network partition detection algorithm is used to identify network isolation and obtain the connectivity awareness of nodes. Each node records the successful communication with other nodes during the Gossip protocol operation, maintaining a neighbor reachability table. This table records the timestamp of the last successful communication with each neighbor node, providing a reachability view of the nodes. Nodes periodically check the neighbor reachability table. If a neighbor node fails to communicate successfully in multiple consecutive Gossip rounds (e.g., five consecutive rounds of timeout or failure), the node determines that the neighbor is currently unreachable and marks it as a suspected fault, thus obtaining neighbor fault detection.

[0143] The node further analyzes the distribution pattern of unreachable neighbors. If only a few neighbors are unreachable while most are reachable, it is determined that the problem lies with the neighboring node itself or a localized network issue, thus identifying a localized fault. If a large number of neighbors are unreachable simultaneously, for example, more than half of the neighbors are out of contact, the node determines that a network partition may have occurred, and the node may be in a minority partition or isolated state, thus obtaining a network partition detection result. The node records the network partition state locally and enters partition mode. In partition mode, the node continues to process check-in requests for the local meeting room, and the check-in data is stored in the local cache. It does not attempt to synchronize with the out-of-connection nodes, thus obtaining local autonomy during the partition period. The node periodically attempts to re-establish communication with out-of-connection neighbors, sending probe messages at regular intervals, such as every 30 seconds, to check whether the network has recovered, thus obtaining a network recovery detection mechanism.

[0144] When a node detects network recovery—that is, previously disconnected neighbors become accessible again—the node exits partition mode and enters the partition recovery process, initiating a data merging process to achieve partition healing. The node exchanges vector clocks and sign-in data with the restored neighbors, identifies the sign-in records processed independently during the partitioning period, and uses vector clocks and conflict detection algorithms to merge and resolve conflicts of concurrent data during the partitioning period, achieving data consistency restoration after the partition. The node records the partition event and recovery process in an audit log, including the partition occurrence time, duration, number of sign-ins processed during the partitioning period, and conflict resolution status after recovery, obtaining a traceable record of the partition.

[0145] S6. Obtain globally consistent sign-in data, and use zero-knowledge proof and homomorphic encryption methods to obtain privacy protection verification results;

[0146] S61. Obtain globally consistent sign-in data and classify privacy data by identifying sensitive fields;

[0147] Based on the globally consistent storage of check-in data on the blockchain, a privacy protection requirement analysis is used to identify sensitive fields, resulting in a classification of privacy data requiring protection. The check-in data package contains multiple fields, including attendees' names, ID numbers, mobile phone numbers, and facial feature vectors, which are considered sensitive personal information. Check-in timestamps, venue numbers, and check-in types are considered business metadata, leading to a privacy level classification for each field. In accordance with privacy protection regulations such as the Personal Information Protection Law and the Data Security Law, as well as the conference organizer's privacy policy, different protection levels are defined for each field. High-sensitivity fields, such as ID numbers and facial features, require the highest level of protection; medium-sensitivity fields, such as names and mobile phone numbers, require a medium level of protection; and low-sensitivity fields, such as check-in times and venue numbers, can be disclosed in certain scenarios, resulting in a tiered privacy protection strategy.

[0148] The system design aims to protect privacy by disclosing attendance statistics, such as total attendance, attendance distribution across venues, and attendance time trends, without revealing the identity information of specific attendees, thus achieving a balance between statistical usability and privacy protection. For internal auditing and regulatory inquiries, sufficient verification capabilities are required to validate attendance data integrity and query specific records, while still protecting the privacy of unrelated personnel, resulting in fine-grained access control requirements. Based on these privacy protection goals, the design employs zero-knowledge proof technology for privacy-preserving verification and homomorphic encryption technology for privacy-preserving statistics, leading to the selection of a privacy protection solution.

[0149] S62. A verifiable computation scheme is obtained by constructing a zero-knowledge proof circuit for the classification of privacy data.

[0150] Based on the identified sensitive privacy fields, a verification circuit is constructed using zero-knowledge proof technology, resulting in a scheme to prove data validity without disclosing the original data. The zk-SNARKs algorithm is chosen as the implementation framework for zero-knowledge proof, as it can generate concise proof documents and has a short verification time, resulting in an efficient proof system. A check-in validity verification circuit is designed. The public inputs of the circuit include the meeting number, venue number, and check-in time range; the private inputs include the attendee's identity token, check-in timestamp, and geographical coordinates. The circuit outputs a Boolean value indicating whether the check-in is valid, thus defining the input and output of the verification circuit.

[0151] The circuit internally implements several constraints. The first constraint verifies the correctness of the identity token format, checking that the token length is 256 bits and that the token is generated by the SM3 hash algorithm. The validity of the token is verified by recalculating the hash within the circuit, resulting in the identity token constraint. The second constraint verifies that the check-in timestamp is within the valid check-in period of the meeting, checking that the timestamp is greater than the check-in start time and less than the check-in end time. This time comparison is implemented in the circuit using an arithmetic comparison gate, resulting in the time window constraint. The third constraint verifies that the geographical coordinates are within the venue's geofence. The distance between the coordinates and the center point of the geofence is calculated, involving square root operations, which are implemented in the circuit using polynomial approximation or a lookup table. The distance is checked to be less than the geofence radius, resulting in the geofence constraint. The fourth constraint verifies the validity of the digital signature of the check-in data packet. The SM2 signature verification algorithm is implemented in the circuit, including elliptic curve point operations and hash calculations, verifying that the signature matches the data packet, resulting in the signature constraint.

[0152] The above constraints are combined to form a complete verification circuit, represented using arithmetic circuits, including addition gates, multiplication gates, and constant gates. All constraints are converted into polynomial equations, resulting in the algebraic representation of the circuit. Using the trusted setup phase of zk-SNARKs, a proof key and a verification key are generated. Trusted setup is performed by multiple parties, ensuring system security by guaranteeing at least one party's honesty, resulting in a key pair. The proof generator obtains the proof key and private input, executes the proof algorithm, and substitutes the private input into the verification circuit to calculate the circuit's satisfaction, generating a concise proof file. The proof file size is fixed at several hundred bytes, resulting in a zero-knowledge proof. The proof file, along with the public input, is submitted to the verifier. The verifier uses the verification key and public input to verify the proof. The verification algorithm runs in milliseconds, outputting either a pass or fail result, demonstrating rapid verification capability.

[0153] S63. Obtain a verifiable computation scheme by using proof generation and on-chain verification to obtain privacy-protected data proofs;

[0154] Based on the constructed zero-knowledge proof circuit and key pair, a privacy-preserving check-in proof is generated and verified in the actual check-in process, resulting in a practical privacy protection mechanism. After participants complete check-in, the check-in terminal or edge node, acting as the proof generator, prepares the input data for the zero-knowledge proof. Public inputs include the current meeting number, the check-in venue number, and the check-in time range specified by the meeting. Private inputs include the participant's identity token, actual check-in timestamp, check-in geographic coordinates, facial feature vector, and digital signature, resulting in the proof input. The proof generator calls the zero-knowledge proof library, passing the proof key and input data to the proof algorithm. The proof algorithm executes the circuit evaluation and proof generation process. The computation involves a large number of elliptic curve operations and polynomial calculations. In a performance-optimized implementation, generating a proof takes several seconds to tens of seconds, resulting in a zero-knowledge proof file.

[0155] The proof generator packages the zero-knowledge proof file and public input as part of the attendance credential, storing or transmitting it accordingly. The proof file is only a few hundred bytes in size and contains no sensitive information, thus providing a privacy-protected attendance credential. When an external auditor or regulatory body needs to verify the validity of an attendance record, the auditor requests the attendance credential. The system returns the zero-knowledge proof file and public input. The auditor uses the publicly available verification key to execute the verification algorithm, which completes within milliseconds, outputting a pass or fail result. The auditor confirms the attendance validity but cannot obtain any identity information of the attendees, thus gaining privacy-protected auditing capabilities.

[0156] To enhance credibility, the verification process of zero-knowledge proofs can be executed on the blockchain. The verification algorithm is implemented as a smart contract. The contract receives the zero-knowledge proof file and public input as parameters, executes the verification logic, and writes the verification result to the blockchain as an immutable record, thus gaining credibility through on-chain verification. Since the computational cost of zero-knowledge proof verification is relatively small, the gas cost of on-chain execution is acceptable. Furthermore, the verification result can be queried and reviewed by anyone, resulting in a transparent and auditable verification process. For batch verification scenarios, aggregated zero-knowledge proof technology is used, combining multiple proofs into a single proof. The size and verification time of the aggregated proof are independent of the number of proofs, only slightly larger than a single proof, thus improving the efficiency of batch verification.

[0157] S64. To obtain the check-in statistics, homomorphic encryption is used to calculate the privacy-protected statistical results.

[0158] Based on the statistical needs of conference management, homomorphic encryption technology is used to perform privacy-preserving statistical calculations on attendance data, obtaining aggregated results that do not disclose individual data. Conference management personnel need to collect aggregated information such as the number of attendees at each venue, the attendance distribution of different attendee categories, and attendance trends over different time periods, but they should not access the identity data of individual attendees, leading to a conflict between statistical needs and privacy protection. The Paillier homomorphic encryption algorithm is adopted as the technical basis for privacy-preserving statistics. The Paillier algorithm supports additive homomorphism, meaning that the ciphertext obtained by adding two ciphertexts equals the sum of the two plaintexts after decryption, demonstrating the additive homomorphic property.

[0159] The system employs homomorphic encryption for key generation and management. A trusted key management center generates Paillier public-private key pairs. The public key is distributed to each check-in node for encryption, while the private key is securely stored by the key management center for final decryption, resulting in a key-separated security architecture. When processing check-in data, each check-in node encrypts the values ​​to be counted. For example, each check-in record is marked with the value 1, encrypted using the Paillier public key to obtain ciphertext. This ciphertext, instead of plaintext, is uploaded to the statistics node, resulting in encrypted statistical units. The statistics node collects the encrypted data from each check-in node, directly performs addition on the ciphertext, and due to the homomorphic property of Paillier addition, the sum of the ciphertext equals the sum of the plaintext. After encryption, the statistics node calculates the total number of ciphertext check-ins for each venue, obtaining the encrypted statistical result.

[0160] The statistical nodes submit the encrypted statistical results to the key management center. The key management center uses its private key to decrypt the results to obtain the plaintext statistical values, i.e., the actual number of attendees at each venue. The plaintext statistical results are then returned to the authorized event administrators, resulting in a privacy-preserving statistical process. Throughout the entire statistical process, the statistical nodes and intermediate links cannot access any individual's attendance data; they can only see the encrypted ciphertext. Only the key management center, holding the private key, can decrypt the data, but only the aggregated results are decrypted, without accessing individual data, thus achieving end-to-end privacy protection. For more complex statistical needs, such as weighted summation or mean calculation, scalar multiplication homomorphism and division operations are used. Paillier supports scalar multiplication of ciphertext and plaintext, enabling complex statistics through a combination of addition and scalar multiplication, thus providing extended statistical capabilities.

[0161] In one embodiment of the present invention, to verify the practical application effect of the method of the present invention, a digital transformation working conference held by a provincial government department is used as an example. The conference lasted for 3 days, with 1 main venue and 5 branch venues, and 1,200 participants including provincial and municipal government officials, enterprise representatives, and technical experts.

[0162] Twenty days prior to the conference, the organizing committee initiated pre-registration for attendees. The conference management system collected basic information such as attendees' names, ID numbers, work units, and contact information, receiving 1200 pre-registration requests. After pre-registration, the system sent each attendee an electronic invitation containing a unique QR code. Attendees scanned the code using a mobile application to capture their facial images, resulting in 1200 collected images. Edge computing nodes employed a quality-aware adaptive feature extraction network to process the images. A dual-branch architecture simultaneously extracted feature vectors and evaluated image quality, generating an enhanced facial feature benchmark library with quality scores. A fast retrieval index was then constructed using a locality-sensitive hashing algorithm.

[0163] One day before the conference, the organizing committee deployed 12 check-in terminals in the main venue and five parallel venues, with two terminals in each venue to distribute the flow of people. The system synchronized the feature benchmark library and hash index to the local cache of each check-in terminal. Check-in began at 8:00 AM on the first day of the conference. Attendees arrived at the check-in points one after another and completed facial recognition at the check-in terminals. The terminals completed feature matching and identity verification within 100 milliseconds, and the display screen indicated successful check-in and announced the attendee's name. The entire check-in process took an average of 3 seconds.

[0164] Table 1 shows a sample of the check-in data collected by the main venue check-in terminal from 8:00 AM to 9:00 AM on the first day of the conference:

[0165] Table 1, Example of Check-in Data

[0166]

[0167] After the check-in data is collected, the edge nodes quickly verify the data packets and return a temporary confirmation within 500 milliseconds, completing the check-in process for the check-in terminal. The edge nodes add the verified check-in data to the queue to be uploaded to the blockchain, packaging and uploading it in batches every 10 seconds or when 100 records are accumulated. The blockchain network consists of 7 verification nodes, employing a modified PBFT consensus algorithm with a consensus time controlled within 2 seconds. Successfully written check-in data forms an immutable record on the blockchain. The edge nodes' deep learning detection layer identifies abnormal patterns in the check-in data, capturing temporal anomalies through a multilayer perceptron and a long short-term memory network.

[0168] On the first day of the conference, 1180 attendance records were collected, achieving a completion rate of 98.3%. 20 attendees were unable to attend due to unforeseen circumstances. The system's deep learning anomaly detection network and smart contracts automatically verified the attendance data, identifying 3 duplicate attendance records and 2 records with spatiotemporal inconsistencies. Conference monitoring personnel manually reviewed these 5 anomaly records, confirming that 3 were legitimate multiple entries by attendees at different times, and 2 were system misjudgments that have been corrected, resulting in an actual anomaly rate of 0%. Attendance nodes in each venue synchronized data via vector clocks and the Gossip protocol. An intelligent conflict resolution model assessed the reasonableness of concurrent attendance, ensuring global data consistency.

[0169] Table 2 shows the overall attendance statistics for the three days of the conference:

[0170] Table 2, Check-in Statistics

[0171]

[0172] Following the meeting, the auditing firm audited the integrity of the attendance data. The system employed zero-knowledge proof technology to protect attendee privacy based on globally consistent attendance data, and simultaneously extracted all attendance records from the blockchain for verification. The audit report showed that all 3,503 attendance records had complete digital signatures and blockchain storage proofs, achieving a data integrity score of 100, with no data tampering or loss detected. The audit report provided reliable data support for the meeting's compliance with regulations.

[0173] In this conference application, the method of the present invention achieves quality-aware feature extraction and fast matching of check-in data with an average time of 3 seconds, reliable blockchain storage under a layered consensus mechanism, anomaly detection and intelligent arbitration enhanced by deep learning, global data consistency guaranteed by vector clock, and privacy protection verification by zero-knowledge proof. It significantly improves the digitalization level and data credibility of conference management and meets the strict requirements of government conferences for the integrity of check-in data.

[0174] Through the above specific implementation methods and application examples, the attendance data integrity assurance method for conference management provided by this invention systematically solves the data integrity assurance problem in multi-venue distributed attendance scenarios by organically integrating innovative technologies such as quality-aware adaptive feature extraction, hierarchical consensus mechanism, deep learning-enhanced verification and intelligent arbitration, vector clock and intelligent conflict resolution, and zero-knowledge proof privacy protection. It achieves secure and reliable attendance data throughout its entire lifecycle from collection to verification, providing solid technical support for the digital transformation of conference management.

[0175] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for ensuring the integrity of sign-in data in meeting management, characterized in that, Includes the following steps: S1. Collect the pre-registration information of the participants, and use edge intelligent feature extraction and distributed cache synchronization methods to obtain the local feature library of each check-in terminal; S2. Obtain the local feature library of each check-in terminal, and use on-site fast matching and spatiotemporal anchoring methods to obtain tamper-proof check-in data packets; S3. Obtain tamper-proof sign-in data packets, and use layered consensus and blockchain storage methods to obtain blockchain records and final confirmation; S4. Obtain blockchain records and final confirmation, and use deep learning to enhance verification and intelligent arbitration methods to obtain data verification results and final disposal decisions; S5. Obtain data verification results and final disposal decisions, and use vector clock and intelligent conflict resolution methods to obtain globally consistent check-in data; S6. Obtain globally consistent sign-in data, and use zero-knowledge proof and homomorphic encryption methods to obtain privacy protection verification results.

2. The method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, S1 includes: The pre-registration information of attendees was obtained, and data cleaning and format standardization were performed to obtain standardized identity files containing unique attendee numbers; Obtain standardized identity profiles, collect facial images through mobile applications, evaluate the quality of the images, and obtain a facial image dataset; A face image dataset is obtained and processed using a quality-aware adaptive feature extraction network. The feature extraction network adopts a dual-branch architecture, with the main branch being a lightweight convolutional neural network responsible for feature extraction, and the auxiliary branch being a quality assessment network responsible for predicting image quality and generating adaptive weights. The quality weights are fused and modulated with the original feature vector to obtain the face feature baseline vector. A baseline vector of facial features is obtained, and a feature retrieval index is constructed using the Locality Sensitive Hash algorithm. This index is then synchronously distributed to each check-in terminal through a distributed caching system, resulting in a local feature library for each check-in terminal.

3. The method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, S2 includes: Obtain the local feature library of the check-in terminal, use the check-in terminal camera to collect face images in real time, perform face alignment processing on the images, and obtain the face image to be recognized; The system acquires the face image to be identified, uses local feature extraction and hash retrieval, calculates the cosine similarity between the query feature vector and the baseline vector, and obtains a list of candidate matching identities. Obtain a list of candidate matching identities, use a preset similarity threshold to make an identity confirmation decision, and obtain the confirmed identities of the participants; The system obtains the confirmed identity of the participants, collects device fingerprints and spatiotemporal information, and uses the national cryptographic SM2 elliptic curve digital signature algorithm to sign the check-in metadata, thus obtaining a tamper-proof check-in data packet.

4. A method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, S3 includes: The anti-tampering sign-in data packet is obtained, and edge computing nodes are used to perform format integrity checks, digital signature verification, device legality verification, and timeliness verification to obtain a temporary confirmation result. Obtain temporary confirmation results, temporarily store verified data packets using a local caching mechanism, and determine the timing of batch on-chain processing using time-triggered and capacity-triggered mechanisms to obtain a queue of data packets to be on-chain. Obtain the queue to be uploaded to the chain, adopt the improved practical Byzantine fault-tolerant consensus algorithm, and reach consensus among the verification nodes through three stages: pre-preparation, preparation and submission. Parallel processing and fast path optimization are introduced to obtain consensus-confirmed transactions. For transactions that have been confirmed through consensus, a Merkle tree index is constructed for the transaction, a block header is generated and the block hash is calculated, the block is written to the blockchain database, and a final confirmation message is sent to the check-in terminal through an asynchronous notification mechanism to obtain the blockchain record and final confirmation.

5. A method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, S4 includes: Deploy a hybrid verification architecture, including a rules engine layer and a deep learning detection layer; The rule engine layer performs time window verification, geofence verification, format integrity verification, and device legitimacy verification to obtain the basic rule verification results; The deep learning detection layer uses an anomaly detection neural network with a network structure of a multilayer perceptron combined with a long short-term memory network. The multidimensional features of the sign-in data are encoded into feature vectors and input into the network. The network outputs the probability distribution of various anomalies, including duplicate sign-in, spatiotemporal contradictions, high frequency of anomalies, and behavioral mutation types, to obtain the anomaly pattern recognition results. By combining the verification results of the rule engine and the deep learning detection layer, data packets that pass verification are added to the normal on-chain queue, while data packets with abnormal confidence levels exceeding a preset threshold are added to the arbitration queue, thus obtaining the off-chain verification results.

6. A method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, S4 further includes: Arbitration smart contracts are deployed on the blockchain, and the contracts implement functions for duplicate check-in detection, spatiotemporal contradiction analysis, and anomaly frequency statistics. Once the data for arbitration check-in is uploaded to the blockchain, the contract automatically calls the verification function, the duplicate check-in detection function queries historical records to check whether the time interval is less than the preset duplicate threshold, the spatiotemporal contradiction analysis function calculates the implicit speed to determine whether it exceeds the preset speed limit, and the abnormal frequency statistics function counts the number of check-ins by the device within the time window to determine whether it exceeds the preset frequency threshold, thus obtaining the abnormal identification result. For sign-in records marked as abnormal, a manual review mechanism is used for verification. Based on the verification results, a correction application is submitted or the abnormality is confirmed, and a final decision is made.

7. A method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, S5 includes: Each check-in edge node is assigned a unique node identifier, and each node maintains an N-dimensional vector clock, where N is the total number of nodes; When a node processes a check-in event, it increments its corresponding vector clock component and appends the updated vector clock to the check-in data packet. When a node receives a check-in data packet from another node, it merges the received vector clock with the local vector clock. The merging operation involves taking the maximum value of each component and then incrementing its corresponding component. The Gossip protocol is used to propagate check-in data and vector clock status between nodes. Data freshness is determined by comparing vector clocks, thereby achieving state synchronization between nodes.

8. A method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, The S5 also includes: Check whether the meeting number in the new data already exists in the local check-in record, determine the causal relationship between records through the partial order relationship of vector clocks, and identify causal sequence conflicts and concurrent conflicts; For causal sequence conflicts, a timestamp priority strategy is adopted, retaining the check-in record with the earlier timestamp; For concurrent conflicts, an intelligent conflict resolution model is invoked for analysis. The model uses a gradient boosting decision tree algorithm. Input features include time interval, geographical distance, historical movement speed, and historical device reliability score. The output is the probability of the reasonableness of the concurrent conflict. Based on the model's judgment results, two records are retained for reasonable concurrency, and the record with the higher credibility score is selected as the valid sign-in for abnormal concurrency, thus obtaining globally consistent sign-in data.

9. A method for ensuring the integrity of check-in data for meeting management according to claim 1, characterized in that, S6 includes: The check-in data fields are classified into privacy levels to identify sensitive fields that need to be protected; A check-in validity verification circuit is constructed using the zk-SNARKs algorithm. The public inputs of the circuit include the meeting number, the venue number, and the check-in time range. The private inputs include the identity token, the check-in timestamp, and the geographic coordinates. The circuit implements identity token constraints, time window constraints, geofence constraints, and signature constraints. The proof generator executes a proof algorithm to generate a zero-knowledge proof file, and the verifier uses a verification key to verify the proof, thus obtaining a privacy-protected data proof. The Paillier homomorphic encryption algorithm is used to encrypt the check-in data. The statistical nodes directly perform addition operations on the ciphertext, and the key management center decrypts it to obtain the aggregated statistical results and the privacy protection verification results.

10. A system for ensuring the integrity of sign-in data for conference management, used to execute the steps of a method for ensuring the integrity of sign-in data for conference management as described in any one of claims 1-9, characterized in that, include: The edge intelligent feature extraction module is used to obtain the pre-registration information of the participants. It uses edge intelligent feature extraction and distributed cache synchronization methods to obtain the local feature library of each check-in terminal. The on-site rapid matching module is used to obtain the local feature library of each check-in terminal, and uses on-site rapid matching and spatiotemporal anchoring methods to obtain tamper-proof check-in data packets; The layered consensus storage module is used to obtain tamper-proof sign-in data packets. It adopts layered consensus and blockchain storage methods to obtain blockchain records and final confirmation. The intelligent verification and arbitration module is used to obtain blockchain records and final confirmation. It adopts deep learning-enhanced verification and intelligent arbitration methods to obtain data verification results and final disposal decisions. The conflict resolution module is used to obtain data verification results and final disposal decisions. It adopts vector clock and intelligent conflict resolution methods to obtain globally consistent check-in data. The privacy protection verification module is used to obtain globally consistent check-in data and uses zero-knowledge proof and homomorphic encryption methods to obtain privacy protection verification results.

Images