A method and system for large-scale meeting voting under a trusted mechanism

Abstract

The application relates to a large-scale conference voting method and system under a trusted mechanism, and relates to the technical field of voting data analysis, which comprises the following steps: acquiring terminal verification performance margin of each participating terminal and voting time limit urgency of a current voting round; calculating an adaptive verification depth coefficient of each participating terminal based on the two parameters; determining a verification strength level according to the coefficient, wherein the level at least comprises a complete, simplified and light verification scheme; each terminal generates identity verification data in the respective level, and broadcasts the identity verification data and voting data to a corresponding shard consensus group; the identity verification data of the terminals in each shard consensus group is verified and local consensus is performed, the shard results are aggregated by a root consensus chain, and a final voting result is output. The application solves the technical problems of traditional methods, such as rigid verification, unified strength, difficulty in adapting to terminal heterogeneity and time limit changes, voting delay, frequent vulnerabilities, low credibility and low efficiency.

Description

Technical Field

[0001] This application relates to the field of voting data analysis technology, and in particular to a method and system for large-scale meeting voting under a trusted mechanism. Background Technology

[0002] With the widespread adoption of remote collaborative work, online decision-making meetings, and distributed governance scenarios, large-scale meeting voting systems face severe challenges in both reliability and efficiency. Existing meeting voting systems typically employ a centralized server to collect voting data from participating terminals, perform identity verification, and compile results. This centralized architecture suffers from single points of failure, excessive reliance on trust, and performance bottlenecks. To address these issues, some solutions introduce blockchain or distributed ledger technology, using a sharding consensus mechanism to divide large-scale terminals into multiple shard consensus groups. Each group independently completes its local consensus, and the results are aggregated by the root consensus chain.

[0003] However, the above-mentioned meeting voting method based on fragmented consensus still has the following problems in practical applications: First, the verification strategy is rigid. Traditional solutions use a uniform authentication strength for all terminals, which cannot adapt to the huge differences in computing power, network status, and resource reserves among participating terminals in large-scale meetings. This causes terminals with poor performance to become bottlenecks and slow down the overall voting progress. Second, it is difficult to balance timeliness and security. A uniform verification strength will either reduce efficiency due to excessive complexity or introduce the risk of identity forgery or data tampering due to excessive simplification. Third, there is a lack of a mechanism to adaptively adjust the verification depth according to the real-time terminal performance and voting urgency, which makes it impossible to fully utilize the processing power of heterogeneous terminals while ensuring credibility. Summary of the Invention

[0004] This application provides a method and system for large-scale meeting voting under a trusted mechanism, which improves the technical problems in the prior art where the verification strategy is rigid and relies on uniform verification strength, making it difficult to simultaneously meet the performance differences of heterogeneous terminals and the timeliness requirements of voting, resulting in voting delays or frequent security vulnerabilities, and reduced credibility and efficiency of meeting voting.

[0005] This application discloses the following technical solution: Firstly, this application provides a method for large-scale meeting voting under a trusted mechanism, the method comprising: Obtain the terminal verification performance margin of each participating terminal, and obtain the voting urgency of the current voting round; For each participating terminal, an adaptive verification depth coefficient is calculated based on the terminal verification performance margin and the voting time urgency. The verification intensity level is determined based on the adaptive verification depth coefficient, wherein the verification intensity level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme; Each participating terminal generates identity verification data using its respective verification strength level, and broadcasts it to its respective consensus group along with the voting data. Each shard consensus group verifies the identity verification data of the terminals within the shard consensus group, performs local consensus based on the verification results, and the root consensus chain aggregates the shard results to output the final voting result.

[0006] Secondly, this application provides a large-scale meeting voting system under a trusted mechanism, the system comprising: The parameter acquisition module is used to obtain the terminal verification performance margin of each participating terminal and the voting urgency of the current voting round. The depth coefficient calculation module is used to calculate the adaptive verification depth coefficient of each participating terminal based on the terminal verification performance margin of each participating terminal and the voting time urgency. The level determination module is used to determine the verification intensity level based on the adaptive verification depth coefficient, wherein the verification intensity level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme. The broadcast module, deployed on each participating terminal, is used to generate identity verification data according to the aforementioned verification strength level, and broadcast it to the respective fragment consensus group along with the voting data. The consensus aggregation module is deployed in the shard consensus groups and the root consensus chain. It is used to enable each shard consensus group to verify the identity verification data of the terminals within the group, execute local consensus based on the verification results, and have the root consensus chain aggregate the shard results to output the final voting result.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application's technical solution provides a large-scale conference voting method under a trusted mechanism. First, it obtains the terminal verification performance margin of each participating terminal and the voting time urgency of the current voting round. By collecting the terminal's own performance status and the overall remaining time constraint of the conference, it provides a dual-dimensional decision-making basis for subsequent adaptive verification, thereby avoiding misjudgments caused by relying solely on a single fixed threshold. This allows the verification strategy to simultaneously consider terminal heterogeneity and voting timeliness requirements, improving the accuracy and adaptability of decision-making.

[0008] Furthermore, for each participating terminal, an adaptive verification depth coefficient is calculated based on the terminal's verification performance margin and voting timeliness urgency. By weighting and fusing the performance margin and timeliness urgency, the calculated depth coefficient can reflect the comprehensive processing capability and security requirement level of each terminal in the current meeting scenario in real time, thereby allocating differentiated verification intensity to different terminals and achieving precise terminal-level adaptation.

[0009] Furthermore, the verification strength level is determined based on the adaptive verification depth coefficient, where the verification strength level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme. Mapping continuous depth coefficients to discrete verification levels allows the terminal to select the corresponding verification scheme based on its own coefficients, maximizing verification efficiency while ensuring necessary security, and avoiding performance bottlenecks or security vulnerabilities caused by uniform verification strength.

[0010] Furthermore, each participating terminal generates identity verification data using its own determined verification strength level, and broadcasts it along with voting data to its respective segment consensus group. This allows the terminal's identity verification data and verification strength level identifier to be encapsulated and broadcast together, facilitating the segment consensus group to perform verification according to the corresponding level. This ensures the integrity and traceability of the verification data, while also enabling differentiated transmission and processing of verification strength, reducing communication and computational overhead.

[0011] Finally, each shard consensus group verifies the identity verification data of the terminals within the group, executes local consensus based on the verification results, and the root consensus chain aggregates the shard results to output the final voting result. Through a hierarchical mechanism of local consensus within shards and global aggregation by the root chain, combined with identity verification that adapts to verification strength, the credibility of large-scale meeting voting is guaranteed, while efficient parallel processing and fault tolerance are achieved, significantly improving the robustness and real-time performance of the overall system.

[0012] In summary, the technical solution of this application realizes the detection of participating terminal performance, adaptive grading of verification strength, and dynamic adjustment of fragmented consensus in large-scale conference voting. By obtaining terminal verification performance margin and voting timeliness urgency, calculating adaptive verification depth coefficient, determining complete verification scheme, simplified verification scheme, or lightweight verification scheme, generating and broadcasting differentiated identity verification data, and aggregating the results of fragmented consensus group local verification and root consensus chain, it effectively improves the technical problems in the prior art where the verification strategy is rigid and relies on uniform verification strength, making it difficult to simultaneously meet the performance differences of heterogeneous terminals and the requirements of voting timeliness, resulting in voting delays or frequent security vulnerabilities, and reduced credibility and efficiency of conference voting. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating a large-scale meeting voting method under a trusted mechanism, provided as an embodiment of this application; Figure 2This is a schematic diagram of the structure of a large-scale conference voting system under a trusted mechanism, provided as an embodiment of this application.

[0015] The components represented by each number in the attached diagram are described as follows: Parameter acquisition module 11, coefficient calculation module 12, level determination module 13, broadcast module 14, and consensus aggregation module 15. Detailed Implementation

[0016] This application provides a method and system for large-scale meeting voting under a trusted mechanism to solve the technical problems of existing technology verification strategies being rigid and relying on uniform verification strength, making it difficult to adapt to terminal heterogeneity and changes in voting timeliness, resulting in voting delays or frequent security vulnerabilities, and reduced credibility and efficiency of meeting voting.

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. It should be noted that the numerical values ​​in the embodiments are for illustrative purposes only and do not constitute a limitation on this application.

[0018] Example 1, as shown in the appendix Figure 1 As shown, this application provides a large-scale meeting voting method under a trusted mechanism, the method comprising the following steps: S100: Obtain the terminal verification performance margin of each participating terminal and obtain the voting time urgency of the current voting round; In this embodiment of the application, in scenarios where large-scale remote decision-making conferences require simultaneous identity verification and voting data collection for hundreds or thousands of participating terminals, in order to synchronously obtain the real-time computing resource reserves of each terminal and the remaining time window of the current voting round, and to provide a dual data foundation at both the terminal and conference levels for the subsequent calculation of the adaptive verification depth coefficient, the central scheduling node needs to issue a performance detection command to all participating terminals when the conference starts. Each terminal reports its own resource status and records the start time and maximum allowable delay of the voting round. This addresses the technical problem that traditional methods blindly adopt a uniform verification strength due to the inability to perceive the heterogeneous capabilities of terminals and the urgency of time, resulting in some terminals becoming bottlenecks due to insufficient resources and slowing down the overall progress, or the risk of identity forgery due to overly simplified verification under time pressure.

[0019] Step S100 in the method provided in this application embodiment includes: The process involves: obtaining the current CPU availability ratio and memory availability ratio of the participating terminal; obtaining the average time taken for the participating terminal to perform a basic authentication operation, recorded as the current actual authentication time, and obtaining a preset baseline authentication time; dividing the baseline authentication time by the sum of the baseline authentication time and the current actual authentication time, and using the quotient as the authentication time ratio; and weighted summing the CPU availability ratio, memory availability ratio, and authentication time ratio to obtain the terminal authentication performance margin. A detailed explanation follows: In this embodiment, terminal verification performance margin refers to a quantitative indicator that comprehensively reflects the remaining computing power and identity verification efficiency of the participating terminal. A higher value indicates that the terminal is more capable of undertaking more complex verification tasks. CPU availability percentage refers to the percentage of processor idle time relative to total computing resources at the current moment. Memory availability percentage refers to the percentage of remaining memory capacity relative to total memory capacity at the current moment. Baseline verification time refers to the reference time required to perform one basic identity verification operation under a standard test environment, measured in milliseconds.

[0020] First, in order to quantify the current remaining computing resources of the terminal in real time to determine whether it can handle additional verification load, it is necessary to read the current CPU idle time slice ratio and memory idle space ratio from the terminal operating system. This will give two basic indicators: CPU availability ratio and memory availability ratio. For example, the CPU availability ratio of a certain terminal is 35% and the memory availability ratio is 40%.

[0021] Furthermore, in order to evaluate the actual time taken by the terminal to perform a basic authentication operation and correct the deviation of the theoretical resource margin, a basic authentication operation needs to be performed and its time taken is recorded as the current actual authentication time. A preset benchmark authentication time is also obtained, which can be used to compare the single operation speed of the terminal in the real environment. For example, if the current actual authentication time is 120ms, the benchmark authentication time is 100ms.

[0022] Furthermore, in order to convert the verification time difference into a ratio with the same dimensions as the performance margin, the formula is required: Verification Time Ratio = Baseline Verification Time / (Baseline Verification Time + Current Actual Verification Time). This yields a ratio between 0 and 1, reflecting the speed of the terminal's processing relative to the baseline. For example, 100ms / (100ms + 120ms) = 0.45.

[0023] Finally, in order to integrate information from the three dimensions of processor, memory, and computing speed to obtain a single comprehensive indicator, the CPU availability ratio, memory availability ratio, and verification time ratio need to be weighted (e.g., 0.4, 0.3, 0.3) and then summed to obtain the terminal verification performance margin. This solves the problem of incomplete evaluation relying solely on a single resource indicator. For example, 0.4×35%+0.3×40%+0.3×0.45=0.14+0.12+0.135=0.395, that is, the terminal verification performance margin is 0.395.

[0024] Step S100 in the method provided in this application embodiment further includes: Obtain the preset maximum allowed verification delay time for the current voting round and the elapsed time from the start time to the current time for the current voting round; calculate the difference between the preset maximum allowed verification delay time and the elapsed time to obtain the remaining available time; divide the remaining available time by the preset maximum allowed verification delay time to obtain the voting urgency. Detailed explanation follows: In this embodiment, the urgency of voting timeliness refers to the proportion of the remaining time window for the current voting round relative to the total allowed time; the smaller the value, the more urgent the time. The preset maximum allowed verification delay time refers to the longest tolerable identity verification and consensus time set by the conference for a single round of voting, in seconds.

[0025] First, in order to establish a time constraint benchmark for voting, the preset maximum allowable verification delay time for this round of voting needs to be read from the meeting configuration, and the start time of the voting round needs to be recorded. The time consumed from the start to the current time is calculated in real time to obtain the maximum allowable total time and the time used. For example, the preset maximum allowable verification delay time is 30s, and the time consumed is 18s.

[0026] Furthermore, in order to quantify the remaining operable time window, the consumed time needs to be subtracted from the preset maximum allowed verification delay time to obtain the remaining available time, for example, 30s-18s=12s.

[0027] Finally, in order to transform the remaining window into an urgency index that can be jointly calculated with the performance margin, the remaining available time needs to be divided by the preset maximum allowable verification delay time to obtain the voting time urgency. This solves the problem that the urgency of different rounds cannot be compared horizontally based solely on the absolute remaining time. For example, 12s / 30s=0.4, which means that the remaining time window accounts for 40% of the total time.

[0028] For example, in a remote decision-making conference of an enterprise, there are 300 participating terminals. When the current voting round starts, the central scheduling node sends a performance probe command to all terminals. Terminal A reports that the CPU availability is 35%, the memory availability is 40%, the time taken to perform a basic authentication operation is 120ms, the baseline authentication time is 100ms, and the calculated terminal verification performance margin is 0.395. At the same time, the preset maximum allowed authentication delay time for this round is recorded as 30s, the time already consumed is 18s, the remaining available time is 12s, and the voting timeliness urgency is 0.4.

[0029] In summary, this step collects the available CPU and memory ratios of participating terminals, along with the current actual verification time. It then calculates the verification time ratio by combining this with the baseline verification time and performs a weighted sum to obtain the terminal verification performance margin. Simultaneously, it collects the preset maximum allowable verification delay and the elapsed time, calculates the remaining available time, and obtains the voting urgency. This establishes a dual adaptive decision-making basis at both the terminal and conference levels. Compared to existing technologies, this step has the following advantages: First, it achieves real-time quantitative perception of the heterogeneous computing capabilities of terminals, avoiding performance bottlenecks or insufficient security redundancy caused by a unified verification strategy. Second, it quantifies the remaining conference time window as an urgency indicator, providing a clear basis for adjusting the timeliness of subsequent verification intensity.

[0030] S200: For each participating terminal, calculate the adaptive verification depth coefficient of the participating terminal based on the terminal verification performance margin and the voting time urgency.

[0031] In this embodiment, based on the obtained terminal verification performance margin of each participating terminal and the voting time urgency of the current voting round, in order to further integrate terminal computing power and time constraints, and introduce meeting speaking activity as a dynamic adjustment factor to generate a depth coefficient that reflects the actual verification needs of each terminal, it is necessary to weight and fuse terminal verification performance margin and voting time urgency. At the same time, the speaking switching frequency within the preset observation window is monitored to calculate speaking activity and adjust the basic depth coefficient accordingly. This solves the technical problem that traditional methods cannot perceive real-time load changes and meeting interaction heat based on a single static threshold, resulting in a mismatch between verification intensity and actual terminal capabilities, delays due to excessive verification burden in high-activity phases, and security gaps due to insufficient verification in low-activity phases.

[0032] Step S200 in the method provided in this application embodiment includes: The terminal verification performance margin and the voting timeliness urgency are weighted and calculated to obtain a basic depth coefficient; the frequency of meeting speaking status changes corresponding to the current voting round within a preset observation window before the current time is obtained and recorded as the speaking switch frequency, wherein the speaking switch frequency is the total number of times different participating terminals initiate speaking requests and complete switching per unit time; a preset upper limit for speaking switch frequency is obtained, and the speaking switch frequency is divided by the upper limit for speaking switch frequency, and the quotient is recorded as speaking activity; 1 is calculated and added to the speaking activity to obtain the speaking status adjustment factor; the basic depth coefficient is divided by the speaking status adjustment factor to obtain the adaptive verification depth coefficient. Detailed explanation is as follows: In this embodiment, the adaptive verification depth coefficient is a comprehensive indicator used to determine the verification strength level that each participating terminal should adopt; a higher value indicates a stronger verification is required. The base depth coefficient is the median value obtained by weighted fusion of terminal verification performance margin and voting timeliness urgency. The speaking switching frequency refers to the total number of times different participating terminals initiate speaking requests and complete switching per unit time within a preset observation window, measured in times / second. The upper limit of speaking switching frequency refers to the maximum allowed speaking switching frequency, used for normalization; in this embodiment, it is dynamically calculated as 1 / 4 of the total number of participating terminals. Speaking activity refers to the ratio of the actual speaking switching frequency to the upper limit, ranging from 0 to 1. The speaking status adjustment factor is the sum of 1 and speaking activity, used to dynamically adjust the base depth coefficient.

[0033] First, in order to integrate the terminal's own capabilities with the meeting time constraints into a quantifiable basic indicator, the terminal's verification performance margin and the urgency of voting timeliness need to be weighted and summed. For example, if the weights are each 0.5, a basic depth coefficient can be obtained, which reflects the verification requirement level of the terminal under ideal, interference-free conditions. For example, if the terminal's verification performance margin is 0.395 and the voting timeliness is 0.4, then the basic depth coefficient = 0.5 × 0.395 + 0.5 × 0.4 = 0.3975.

[0034] Furthermore, in order to capture the impact of meeting interaction intensity on verification load in real time, it is necessary to count the total number of times different terminals initiate speaking requests and complete switching within a unit of time within a preset observation window (e.g., 30 seconds), which is recorded as the speaking switching frequency. For example, if 90 speaking switches occur within 30 seconds, then the speaking switching frequency = 90 times / 30 seconds = 3 times / second.

[0035] Furthermore, in order to normalize the speaking switching frequency to the range of 0~1 for adjustment, it is necessary to obtain the upper limit of the speaking switching frequency. In this embodiment, it is dynamically calculated based on 1 / 4 of the total number of participating terminals. For example, if a certain subgroup has 100 terminals, then the upper limit of the speaking switching frequency = 100 / 4 = 25 times / s. Dividing the actual speaking switching frequency by the upper limit, the speaking activity level can be obtained, for example, 3 ÷ 25 = 0.12.

[0036] Furthermore, in order to reduce the verification depth and alleviate the load during periods of high activity in the meeting, it is necessary to calculate 1 plus the speaking activity level to obtain a speaking status adjustment factor, for example, 1+0.12=1.12; if the meeting is very active, the adjustment factor is greater than 1, making the final coefficient smaller, thereby selecting a lighter verification scheme and solving the problem of latency caused by the competition for verification computing resources during periods of high activity.

[0037] Finally, in order to obtain an adaptive verification depth coefficient that integrates terminal capabilities, time window, and meeting popularity, the basic depth coefficient needs to be divided by the speaking status adjustment factor, for example, 0.3975÷1.12≈0.355, to obtain the final coefficient for subsequent judgment of verification intensity level.

[0038] For example, in a remote decision-making conference of an enterprise, there are 300 participating terminals. Terminal A has a terminal verification performance margin of 0.395, a voting urgency of 0.4 in the current voting round, and a weighted base depth coefficient of 0.3975. A preset observation window of 30 seconds is set. Within this window, 90 speech switching events are observed, with a switching frequency of 3 times / second. Assuming the number of terminals is 300, the upper limit for the speaking switching frequency is 75 times / second. The speaking activity level is 3 / 75 = 0.04, and the speaking status adjustment factor is 1.04. The final adaptive verification depth coefficient is approximately 0.3975 / 1.04 ≈ 0.382.

[0039] In summary, this step obtains a basic depth coefficient by weighting and fusing terminal verification performance margin with voting timeliness urgency. Then, it introduces a normalized speaking frequency to represent speaking activity, constructing a speaking status adjustment factor to dynamically correct the basic depth coefficient, ultimately yielding an adaptive verification depth coefficient. Compared to existing technologies, this step has the following advantages: First, it incorporates meeting interaction heat into verification depth adjustment, automatically reducing verification intensity during high-activity periods to alleviate resource competition, and appropriately increasing verification intensity during low-activity periods to enhance security. Second, it achieves triple dynamic adaptation to terminal capabilities, time windows, and meeting speaking frequency, providing a reliable basis for the accurate determination of subsequent differentiated verification intensity levels.

[0040] S300: Determine the verification strength level based on the adaptive verification depth coefficient, wherein the verification strength level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme.

[0041] In this embodiment of the application, in the scenario where the adaptive verification depth coefficient of each participating terminal has been obtained, in order to map the continuous depth coefficient to discrete verification strength levels and ensure that the verification threshold can be dynamically adjusted according to the overall terminal performance and historical consensus achievement, it is necessary to obtain the complete verification threshold and the lightweight verification threshold, compare the depth coefficient with the threshold, and determine whether the terminal adopts the complete verification scheme, the simplified verification scheme, or the lightweight verification scheme. This solves the technical problem that the traditional method of using a fixed threshold cannot adapt to changes in terminal performance distribution and historical consensus performance, resulting in a large number of terminals being assigned to mismatched verification levels, either excessively consuming resources or leaving security vulnerabilities.

[0042] Step S300 in the method provided in this application embodiment includes: The system obtains a full verification threshold and a lightweight verification threshold, wherein the full verification threshold is greater than the lightweight verification threshold. When the adaptive verification depth coefficient is greater than or equal to the full verification threshold, the terminal is determined to use a full verification scheme, which includes Merkle tree proof, digital signature generation, and hash commitment calculation. When the adaptive verification depth coefficient is less than the full verification threshold but greater than or equal to the lightweight verification threshold, the terminal is determined to use a simplified verification scheme, which includes digital signature generation and hash commitment calculation. When the adaptive verification depth coefficient is less than the lightweight verification threshold, the terminal is determined to use a lightweight verification scheme, which only includes hash commitment calculation. A detailed explanation follows: In this embodiment, the complete verification threshold refers to the lower limit of the adaptive depth coefficient for determining the highest strength verification scheme the terminal should use. The lightweight verification threshold refers to the upper limit of the adaptive depth coefficient for determining the lowest strength verification scheme the terminal should use. A complete verification scheme refers to an authentication method that includes three operations: Merkle tree proof, digital signature generation, and hash commitment calculation. A simplified verification scheme refers to an authentication method that includes two operations: digital signature generation and hash commitment calculation. A lightweight verification scheme refers to an authentication method that only includes hash commitment calculation. Merkle tree proof refers to a cryptographic method that proves the existence of certain data in a dataset by constructing a Merkle tree and providing a verification path. Digital signature generation refers to the operation of signing data using a private key to verify the integrity and authenticity of the data source. Hash commitment calculation refers to the operation of performing a one-way hash function on the data to generate a fixed-length digest as the basis for verification.

[0043] First, to determine the appropriate verification strength level for the current terminal, the adaptive verification depth coefficient needs to be compared with two pre-calculated thresholds. If the depth coefficient is greater than or equal to the full verification threshold, the full verification scheme is used; if the depth coefficient is less than the full verification threshold but greater than or equal to the lightweight verification threshold, the simplified verification scheme is used; if the depth coefficient is less than the lightweight verification threshold, the lightweight verification scheme is used. Through this three-stage comparison, continuous coefficients can be accurately mapped to discrete verification levels.

[0044] Furthermore, the complete verification scheme includes three operations: Merkle tree proof, digital signature generation, and hash commitment calculation, suitable for terminals with high security requirements or high capabilities. For example, if the terminal's adaptive verification depth coefficient is 0.85, which is greater than the complete verification threshold of 0.80, then Merkle tree proof, digital signature generation, and hash commitment calculation must be performed simultaneously to provide the most comprehensive identity trust guarantee.

[0045] Furthermore, the simplified verification scheme only includes digital signature generation and hash commitment calculation, omitting Merkle tree proofs, making it suitable for terminals with medium security requirements or medium capabilities. For example, with a depth coefficient of 0.60, which falls between 0.80 and 0.40, only digital signatures and hash commitments are needed, eliminating the computational overhead of tree structure proofs.

[0046] Finally, the lightweight verification scheme only includes hash commitment calculation, making it suitable for terminals with low security requirements or limited capabilities and time constraints. For example, if the depth factor is 0.30, which is less than the lightweight verification threshold of 0.40, then only one hash commitment calculation is performed, greatly reducing the computational and communication load.

[0047] Step S300 in the method provided in this application embodiment further includes: Obtain the terminal verification performance margin of each participating terminal in the current voting round, and calculate the arithmetic mean of the verification performance margins of all participating terminals as the average performance margin; obtain the tiered verification confirmation achievement rate, wherein the tiered verification confirmation achievement rate is the average ratio of the number of participating terminals that have passed verification in each fragment consensus group in the previous voting round to the total number of participating terminals that should participate; multiply the average performance margin by the tiered verification confirmation achievement rate to obtain the full verification threshold; multiply the full verification threshold by the lightweight scaling factor to obtain the lightweight verification threshold. Detailed explanation follows: In this embodiment, the average performance margin refers to the arithmetic mean of the terminal verification performance margins of all participating terminals in the current voting round. The tiered verification confirmation achievement rate refers to the average ratio of the number of verifications passed within each consensus group in the previous voting round to the total number of participants. In this embodiment, if the current round is the first round of voting, this value is preset to 0.8. The lightweight proportional coefficient is a preset constant, which is 0.5 in this embodiment.

[0048] First, to assess the average capability level of all conference terminals, the arithmetic mean of the terminal verification performance margins of all participating terminals in the current round needs to be calculated to obtain the average performance margin. For example, the average performance margin of 300 terminals is 0.58.

[0049] Furthermore, in order to incorporate the credibility of historical consensus into the current threshold setting, the global average verification pass rate of the previous round needs to be obtained as the tiered verification confirmation achievement rate, which is preset to 0.8 for the first round. The higher the tiered verification confirmation achievement rate, the higher the threshold can be, and vice versa.

[0050] Furthermore, to obtain the complete verification threshold that distinguishes high security requirements, the average performance margin needs to be multiplied by the aforementioned achievement rate, i.e., complete verification threshold = average performance margin × tiered verification confirmation achievement rate. For example, 0.58 × 0.8 = 0.464.

[0051] Finally, to obtain the lightweight validation threshold, the full validation threshold needs to be multiplied by the lightweight scaling factor to obtain the lightweight threshold, for example, 0.464 × 0.5 = 0.232.

[0052] For example, in a remote decision-making conference of an enterprise, there are 300 participating terminals. The current round is the first round of voting. The tiered verification confirmation achievement rate is preset to 0.8, and the arithmetic mean of the performance margin of all terminals is 0.58. Then, the full verification threshold = 0.58 × 0.8 = 0.464, the lightweight proportional coefficient is taken as 0.5, and the lightweight verification threshold = 0.464 × 0.5 = 0.232. The adaptive verification depth coefficient of terminal A is 0.382, which is greater than or equal to the lightweight threshold of 0.232 and less than the full threshold of 0.464. Therefore, terminal A is assigned a simplified verification scheme, which requires the generation of a digital signature and a hash commitment.

[0053] In summary, this step dynamically generates a complete verification threshold by calculating the average performance margin and combining it with the achievement rate of the previous round of hierarchical verification. This threshold is then multiplied by a lightweight proportionality coefficient to obtain a lightweight verification threshold. Finally, an adaptive depth coefficient is compared with the two thresholds to assign a complete, simplified, or lightweight verification scheme to each terminal. Compared with existing technologies, this step has the following advantages: First, the threshold value is dynamically adjusted according to the overall terminal performance and historical consensus credibility, avoiding mismatches caused by fixed thresholds. Second, the verification scheme is hierarchically refined and the cryptographic operations included in each scheme are clearly defined, allowing terminals to selectively execute schemes based on their own capabilities, achieving a balance between security and efficiency. Third, the introduction of average performance margin and historical achievement rate enhances the adaptability and objectivity of threshold setting.

[0054] S400: Each participating terminal generates identity verification data using its respective verification strength level, and broadcasts it to its respective shard consensus group along with the voting data.

[0055] In this embodiment of the application, in a scenario where a verification strength level has been determined for each participating terminal, in order for the terminal to generate corresponding identity verification data according to the assigned level and submit the data and voting results to the respective fragment consensus group, it is necessary to construct identity verification data containing identity credential proof and voting data integrity check code according to the verification strength level, and combine it with voting data and verification strength level identifier to form a voting message for broadcast. This solves the technical problem in traditional methods where all terminals use the same format of identity credentials, resulting in verification data redundancy and the consensus group being unable to distinguish verification levels and having to perform the highest strength verification on all data, causing a waste of computing and communication resources.

[0056] Step S400 in the method provided in this application embodiment includes: Based on the verification strength level of the participating terminal, identity verification data is obtained, wherein the identity verification data includes at least the terminal's identity credential proof and a verification code for the integrity of the voting data; the participating terminal combines the identity verification data, the voting data, and the verification strength level identifier into a voting message and broadcasts it to its respective shard consensus group. A detailed explanation follows: In this embodiment, authentication data refers to a set of information used to prove the legitimacy of the terminal's identity and ensure the integrity of the voting data. Identity credential verification refers to a digital credential that uniquely identifies the terminal, such as a public key certificate or a temporary session key identifier. The integrity check code for the voting data refers to a fixed-length digest obtained by calculating a hash function on the voting data, used to verify whether the voting data has been tampered with during transmission.

[0057] First, to generate authentication data that conforms to the authentication strength level assigned to the terminal, identity credential proofs and integrity check codes containing corresponding content must be constructed according to different authentication strength levels. For a full authentication scheme, a Merkle tree proof is required; for a simplified authentication scheme, a digital signature and hash commitment are required; for a lightweight authentication scheme, only a hash commitment is required. This results in differentiated, non-redundant authentication data. For example, if terminal A is assigned a simplified authentication scheme, its authentication data includes a digital signature value and a hash digest of the voting data.

[0058] Furthermore, in order to submit the identity verification data along with the voting content and verification level information, the identity verification data, voting data, and verification strength level identifier need to be combined into a complete voting message. The verification strength level identifier is an enumerated value, such as 00 for lightweight, 01 for simplified, and 10 for complete, which facilitates the consensus group to quickly identify the verification method and solves the problem that the consensus group needs to traverse and parse the data format to determine the verification strength.

[0059] Finally, in order for the sharded consensus group to receive the voting information from the terminal, the combined voting message needs to be sent to all consensus nodes in the sharded consensus group via multicast or broadcast protocol to ensure that each consensus node receives the same copy of the message, thereby achieving redundancy, fault tolerance, and parallel verification.

[0060] For example, using the previous data, terminal A is assigned a simplified verification scheme. Terminal A generates its own digital signature value and a hash commitment of the voting data, combines them into authentication data, and then encapsulates it with the voting content and a simplified strength level identifier 01 into a network message, which is then broadcast to the three consensus nodes of its respective shard consensus group. Upon receiving the message, each consensus node can quickly invoke the simplified verification logic to perform verification based on the identifier 01.

[0061] In summary, this step generates identity verification data containing proof of identity credentials and integrity check codes based on the verification strength level, and encapsulates it together with voting data and the strength level identifier into a voting message for broadcast, thus realizing the construction and transmission of differentiated verification data. Compared with existing technologies, this step has the following advantages: First, the identity verification data strictly matches the allocation level, avoiding redundant information and reducing communication overhead; second, the explicit carrying of the verification strength level identifier allows the consensus group to select the corresponding verification process without parsing, reducing computational overhead; third, the broadcast mechanism ensures redundant distribution of data within the fragment, providing a reliable foundation for subsequent local consensus.

[0062] S500: Each shard consensus group verifies the identity verification data of the terminals within the shard consensus group, performs local consensus based on the verification results, aggregates the shard results by the root consensus chain, and outputs the final voting result.

[0063] In this embodiment, in a scenario where the shard consensus group has received authentication and voting data from all member terminals, to improve local consensus efficiency and handle anomalies while ensuring security, the shard consensus group needs to perform corresponding verifications based on the verification strength levels declared by each terminal, calculate the pass rate and compare it with the consensus threshold. If it passes, it is submitted directly; if it fails, the lightweight verification terminal is upgraded step by step to improve credibility. If it is still insufficient after upgrading all terminals to full verification, cross-group cross-verification is triggered. Finally, the root consensus chain aggregates all shard results to solve the technical problems of traditional methods, such as lack of refined remedial measures when local consensus fails, lightweight terminals becoming security bottlenecks, and the inability to collaboratively verify cross-shard data leading to overall consensus stagnation.

[0064] Step S500 in the method provided in this application embodiment includes: The sharded consensus group verifies the identity verification data according to the verification strength level, and counts the number of participating terminals that pass verification; it obtains the total number of participating terminals that should participate in the voting within the sharded consensus group, and divides the number of participating terminals that have passed verification by the total number of participating terminals that should participate in the voting within the group to obtain the local verification pass rate; when the local verification pass rate is greater than or equal to the consensus achievement threshold, the voting data of all participating terminals that have passed verification are submitted to the root consensus chain; when the local verification pass rate is less than the consensus achievement threshold, the status of the identity verification data within the sharded consensus group is counted, and participating terminals that have passed verification but whose verification strength level is a lightweight verification scheme are marked as downgraded verification terminals; the downgraded verification terminals are upgraded for verification, and the local verification pass rate is repeatedly obtained until... The local verification pass rate is greater than or equal to the consensus threshold. The upgrade verification includes upgrading the lightweight verification scheme to the simplified verification scheme and upgrading the simplified verification scheme to the complete verification scheme. When all participating terminals in the sharded consensus group that should participate in the voting use the complete verification scheme and the local verification pass rate is less than the consensus threshold, the number of participating terminals that have passed the complete verification scheme and the number of participating terminals that have not passed the complete verification scheme are jointly counted into the sharded consensus data block. The identity verification data of the participating terminals that have not passed the complete verification scheme are submitted to the root consensus chain for cross-group cross-validation. If multiple sharded consensus groups fail the consistency check on the same terminal that has not passed verification, the voting data of that terminal is treated as abstention and included in the final voting result. Detailed explanation follows: In this embodiment, a sharded consensus group refers to an independent consensus unit composed of some participating terminals and corresponding consensus nodes, responsible for authenticating members within the group and achieving local consensus. The consensus threshold refers to the percentage threshold for triggering successful local consensus, set to 0.67 in this embodiment. A downgraded authentication terminal refers to a terminal whose authentication has passed but whose authentication strength level is a lightweight authentication scheme; due to its lower security level, it may be required to upgrade later. Upgraded authentication refers to the process of requiring the terminal to regenerate authentication data with a higher strength level, including upgrading from lightweight to simplified or from simplified to complete. Cross-group cross-verification refers to the root consensus chain sending the authentication data of a terminal to multiple sharded consensus groups, with each group independently verifying and providing feedback. Consistency verification refers to each sharded consensus group comparing the authentication conclusions of the same terminal; if multiple groups fail to pass the verification, the terminal is considered untrustworthy.

[0065] First, to obtain the verification pass rate of the current shard group, the shard consensus group performs the corresponding verification operation based on the verification strength level declared by each terminal: for lightweight schemes, only hash commitments are verified; for simplified schemes, digital signatures and hash commitments are verified; and for complete schemes, Merkle tree proofs are additionally verified. The total number of terminals that have passed verification is counted and divided by the total number of terminals that should participate in the vote within the group to obtain the verification pass rate within the current shard, i.e., the local verification pass rate. For example, if a shard group has 100 terminals and 85 have passed verification, the pass rate is 0.85.

[0066] Furthermore, if the pass rate is greater than or equal to the consensus threshold of 0.67, then the local consensus is successful, and the voting data of all verified terminals are submitted to the root consensus chain, which aggregates the data and outputs the final result.

[0067] Furthermore, if the pass rate is less than 0.67, terminals that have passed verification but use a lightweight verification scheme need to be identified and marked as downgraded verification terminals. Upgrade verification commands are issued to these terminals, requiring them to upgrade their verification scheme from lightweight to simplified, or from simplified to complete. If an upgraded verification terminal fails to submit upgraded identity verification data within a preset response time, its voting data is treated as abstention, and it will no longer participate in subsequent consensus. After the upgrade, the identity verification data is rebroadcast, and the shard group again calculates and compares the pass rate. This process is repeated until the pass rate reaches the target or the maximum number of upgrades is reached; in this embodiment, the maximum number of cycles is set to 3. If, after reaching the maximum number of cycles, the local verification pass rate is still less than the consensus threshold, and there are terminals that have not yet upgraded to a complete verification scheme, these terminals are considered to have failed verification, their voting data is treated as abstention, and only the data of terminals that have passed verification is submitted to the root consensus chain. Through this mechanism, the security level can be gradually improved and the number of valid votes increased without discarding terminals.

[0068] Furthermore, if all terminals have adopted the full verification scheme after the cyclical upgrade, but the pass rate is still less than the consensus threshold, it indicates that some terminals cannot pass even with full verification. The number of terminals that have passed full verification and the number of terminals that have failed are included in the sharded consensus data block, and the identity verification data of the terminals that failed are submitted to the root consensus chain.

[0069] Finally, the root consensus chain distributes the authentication data of failed terminals to multiple shard consensus groups for cross-group verification. In this embodiment, "multiple" refers to more than half of the shard groups. If more than half of the shard groups fail the consistency verification for a terminal, the terminal's voting data is treated as an abstention and included in the final voting result; if more than half of the shard groups pass the consistency verification for a terminal, the terminal's identity is confirmed as valid, and its voting data is included in the final voting result. This design avoids misjudgment by a single shard group and improves the credibility of the final vote.

[0070] For example, a remote decision-making conference in an enterprise has 300 participating terminals. A certain shard group has 100 terminals. Terminal A uses a simplified verification scheme and passes verification. Another 30 lightweight verification terminals have 25 passes and 5 fail. The remaining 69 terminals have 65 passes and 4 fail. The initial total number of passes = 1 (Terminal A) + 25 + 65 = 91, with a pass rate of 0.91, which is greater than the consensus threshold of 0.67. No upgrade is needed; the voting data of the 91 passing terminals is directly submitted to the root consensus chain. In another scenario, if the initial pass rate is only 0.60, with 26 lightweight verification results, then these 26 lightweight but verified terminals need to be marked as level-verification terminals. They need to be upgraded to the simplified scheme and re-verified. Assuming all pass after the upgrade, the total number of passes increases to 91, with a pass rate of 0.91, satisfying the threshold. If the upgrade is still insufficient and all terminals are fully verified, cross-group verification will be initiated. The root consensus chain will send the identity data of the terminals that failed to pass to other shard groups. If more than half of the shard groups determine that the verification failed, the verification will be abstained.

[0071] In summary, this step achieves a fault-tolerant consensus process from local to overall by verifying consensus groups according to their verification strength levels, calculating local pass rates, comparing them with consensus thresholds, iteratively upgrading lightweight terminals, and finally cross-group verification. Compared with existing technologies, this step has the following advantages: First, the introduction of a tiered upgrade verification mechanism avoids the failure of the entire consensus due to the low security level of some terminals, thus improving the voting participation rate; second, cross-group verification solves the problem of potential misjudgment by a single shard group, enhancing the fairness and credibility of the final result.

[0072] The embodiments of this application, through the specific implementation methods described above, achieve the following technical effects: This application proposes a large-scale meeting voting method under a trusted mechanism. First, a central scheduling node obtains the terminal verification performance margin of each participating terminal and the voting timeliness urgency of the current voting round. Then, based on the terminal verification performance margin and voting timeliness urgency, an adaptive verification depth coefficient is calculated for each terminal, and a complete verification scheme, a simplified verification scheme, or a lightweight verification scheme is determined according to this coefficient. Next, each participating terminal generates identity verification data according to the determined verification strength level and broadcasts it along with the voting data to its respective shard consensus group. Finally, each shard consensus group verifies the identity verification data of the terminals within the group and performs local consensus. The root consensus chain aggregates the shard results and outputs the final voting result. This method solves the problems of rigidity and difficulty in adapting to terminal heterogeneity and voting timeliness changes caused by traditional verification strategies, such as adaptive adjustment of verification strength, introduction of dynamic correction of speaking activity, and intra-shard upgrade verification and cross-group cross-verification, leading to voting delays or frequent security vulnerabilities, and reduced credibility and efficiency of meeting voting.

[0073] Example 2, as shown in the appendix Figure 2 As shown, based on the inventive concept of a large-scale meeting voting method under a trusted mechanism provided in Embodiment 1, this application also provides a large-scale meeting voting system under a trusted mechanism, specifically including: The parameter acquisition module 11 is used to acquire the terminal verification performance margin of each participating terminal and the voting urgency of the current voting round. The coefficient calculation module 12 is used to calculate the adaptive verification depth coefficient of the participating terminal based on the terminal verification performance margin of each participating terminal and the voting time urgency. The level determination module 13 is used to determine the verification intensity level based on the adaptive verification depth coefficient, wherein the verification intensity level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme. Broadcast module 14, deployed on each participating terminal, is used to generate identity verification data according to the verification strength level and broadcast it to the corresponding consensus group along with the voting data; The consensus aggregation module 15 is deployed in the shard consensus group and the root consensus chain. It is used to enable each shard consensus group to verify the identity verification data of the terminals in the group, execute local consensus based on the verification results, and aggregate the shard results by the root consensus chain to output the final voting result.

[0074] In one embodiment, the parameter acquisition module 11 is further configured to: acquire the current available ratio of the central processing unit and the available ratio of memory of the participating terminal; The average time taken for the participating terminal to perform one basic identity verification operation is obtained and recorded as the current actual verification time. A preset baseline verification time is also obtained. Divide the baseline verification time by the sum of the baseline verification time and the current actual verification time, and use the quotient as the verification time ratio; The terminal verification performance margin is obtained by weighted summing of the processor availability ratio, the memory availability ratio, and the verification time ratio.

[0075] Furthermore, the parameter acquisition module 11 is also used to: acquire the preset maximum allowable verification delay time of the current voting round and the time consumed from the start time to the current time of the current voting round; Calculate the difference between the preset maximum allowed verification delay and the consumed time to obtain the remaining available time; Divide the remaining available time by the preset maximum allowed verification delay time to obtain the voting urgency.

[0076] In one embodiment, the coefficient calculation module 12 is further configured to: perform a weighted calculation on the terminal verification performance margin and the voting timeliness urgency to obtain a basic depth coefficient; The frequency of changes in the meeting speaking status corresponding to the current voting round within the preset observation window before the current time is obtained and recorded as the speaking switching frequency. The speaking switching frequency is the total number of times different participating terminals initiate speaking requests and complete switching within a unit of time. Obtain the preset upper limit of the speaking switching frequency, divide the speaking switching frequency by the upper limit of the speaking switching frequency, and record the quotient as the speaking activity level; Calculate 1 plus the aforementioned speaking activity level to obtain the speaking status adjustment factor; Divide the base depth coefficient by the speech state adjustment factor to obtain the adaptive verification depth coefficient.

[0077] In one embodiment, the level determination module 13 is further configured to: obtain a full verification threshold and a lightweight verification threshold, wherein the full verification threshold is greater than the lightweight verification threshold; When the adaptive verification depth coefficient is greater than or equal to the full verification threshold, it is determined that the terminal adopts the full verification scheme, wherein the full verification scheme includes Merkle tree proof, digital signature generation and hash commitment calculation; When the adaptive verification depth coefficient is less than the full verification threshold and greater than or equal to the lightweight verification threshold, it is determined that the terminal adopts a simplified verification scheme, which includes digital signature generation and hash commitment calculation. When the adaptive verification depth coefficient is less than the lightweight verification threshold, it is determined that the terminal adopts a lightweight verification scheme, which only includes hash commitment calculation.

[0078] Furthermore, the grade determination module 13 is also used to: obtain the terminal verification performance margin of each participating terminal in the current voting round, and calculate the arithmetic mean of the verification performance margins of all participating terminals as the average performance margin. Obtain the tiered verification confirmation achievement rate, wherein the tiered verification confirmation achievement rate is the average of the ratios of the number of participating terminals that have passed verification in each consensus group of the previous voting round to the total number of participating terminals that should participate. Multiply the average performance margin by the tiered verification confirmation achievement rate to obtain the complete verification threshold; Multiply the full verification threshold by the lightweight scaling factor to obtain the lightweight verification threshold.

[0079] In one embodiment, the broadcast module 14 is further configured to: obtain identity verification data based on the verification strength level of the participating terminal, wherein the identity verification data includes at least the terminal's identity credential proof and the integrity check code of the voting data; The participating terminal combines the identity verification data, the voting data, and the verification strength level identifier into a voting message, which is then broadcast to its respective shard consensus group.

[0080] In one embodiment, the consensus aggregation module 15 is further configured to: the sharded consensus group verifyes the identity verification data according to the verification strength level, and counts the number of participating terminals that have passed the verification; Obtain the total number of participating terminals that should participate in the voting within the segment consensus group, and divide the number of participating terminals that have passed verification by the total number of participating terminals that should participate in the voting within the group to obtain the local verification pass rate; When the local verification pass rate is greater than or equal to the consensus threshold, the voting data of all verified participating terminals are submitted to the root consensus chain. When the local verification pass rate is less than the consensus achievement threshold, the status of the identity verification data in the fragment consensus group is statistically analyzed, and the participating terminal that has passed the verification but whose verification strength level is a lightweight verification scheme is marked as a downgraded verification terminal. The downgraded verification terminal is upgraded and verified, and the local verification pass rate is repeatedly obtained until the local verification pass rate is greater than or equal to the consensus achievement threshold. The upgrade verification includes upgrading the lightweight verification scheme to the simplified verification scheme and upgrading the simplified verification scheme to the complete verification scheme. When all participating terminals in the shard consensus group that should participate in the voting adopt the complete verification scheme and the local verification pass rate is less than the consensus achievement threshold, the number of participating terminals that have passed the complete verification scheme and the number of participating terminals that have not passed the complete verification scheme are jointly included in the shard consensus data block. The identity verification data of the participating terminals that have not passed the complete verification scheme are submitted to the root consensus chain for cross-group cross-verification. If multiple shard consensus groups fail the consistency verification of the same terminal that has not passed verification, the voting data of that terminal is treated as abstention and included in the final voting result.

[0081] This application provides a large-scale conference voting system under a trusted mechanism that enables intelligent voting management in scenarios such as remote enterprise decision-making, online government meetings, and distributed autonomous organization voting. This management process involves real-time perception of terminal performance margin, adaptive grading of verification strength, and dynamic aggregation of sharded consensus. The system can be integrated into a conference center server or sharded consensus nodes, effectively improving the credibility and efficiency of voting in heterogeneous terminal environments, reducing verification latency and security vulnerability risks, and providing reliable data support for the adaptive adjustment of the voting mechanism.

[0082] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

Claims

1. A large-scale meeting voting method under a trusted mechanism, characterized in that, The method includes: Obtain the terminal verification performance margin of each participating terminal, and obtain the voting urgency of the current voting round; For each participating terminal, an adaptive verification depth coefficient is calculated based on the terminal verification performance margin and the voting time urgency. The verification intensity level is determined based on the adaptive verification depth coefficient, wherein the verification intensity level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme; Each participating terminal generates identity verification data using its respective verification strength level, and broadcasts it to its respective consensus group along with the voting data. Each shard consensus group verifies the identity verification data of the terminals within the shard consensus group, performs local consensus based on the verification results, and the root consensus chain aggregates the shard results to output the final voting result.

2. The method for large-scale meeting voting under a trusted mechanism according to claim 1, characterized in that, The process of obtaining the terminal verification performance margin for each participating terminal includes: Obtain the current CPU availability ratio and memory availability ratio of the participating terminal; The average time taken for the participating terminal to perform one basic identity verification operation is obtained and recorded as the current actual verification time. A preset baseline verification time is also obtained. Divide the baseline verification time by the sum of the baseline verification time and the current actual verification time, and use the quotient as the verification time ratio; The terminal verification performance margin is obtained by weighted summing of the processor availability ratio, the memory availability ratio, and the verification time ratio.

3. The method for large-scale meeting voting under a trusted mechanism according to claim 1, characterized in that, The process of obtaining the urgency of the voting time for the current voting round includes: Get the preset maximum allowed verification delay time for the current voting round and the time elapsed from the start time to the current time for the current voting round; Calculate the difference between the preset maximum allowed verification delay and the consumed time to obtain the remaining available time; Divide the remaining available time by the preset maximum allowed verification delay time to obtain the voting urgency.

4. The method for large-scale meeting voting under a trusted mechanism according to claim 1, characterized in that, For each participating terminal, based on the terminal verification performance margin and the voting time urgency, an adaptive verification depth coefficient for the participating terminal is calculated, including: The basic depth coefficient is obtained by weighting the terminal verification performance margin and the voting timeliness urgency. The frequency of changes in the meeting speaking status corresponding to the current voting round within the preset observation window before the current time is obtained and recorded as the speaking switching frequency. The speaking switching frequency is the total number of times different participating terminals initiate speaking requests and complete switching within a unit of time. Obtain the preset upper limit of the speaking switching frequency, divide the speaking switching frequency by the upper limit of the speaking switching frequency, and record the quotient as the speaking activity level; Calculate 1 plus the aforementioned speaking activity level to obtain the speaking status adjustment factor; Divide the base depth coefficient by the speech state adjustment factor to obtain the adaptive verification depth coefficient.

5. The method for large-scale meeting voting under a trusted mechanism according to claim 1, characterized in that, The step of determining the verification strength level based on the adaptive verification depth coefficient, wherein the verification strength level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme, including: Obtain the full verification threshold and the lightweight verification threshold, wherein the full verification threshold is greater than the lightweight verification threshold; When the adaptive verification depth coefficient is greater than or equal to the full verification threshold, it is determined that the terminal adopts the full verification scheme, wherein the full verification scheme includes Merkle tree proof, digital signature generation and hash commitment calculation; When the adaptive verification depth coefficient is less than the full verification threshold and greater than or equal to the lightweight verification threshold, it is determined that the terminal adopts a simplified verification scheme, which includes digital signature generation and hash commitment calculation. When the adaptive verification depth coefficient is less than the lightweight verification threshold, it is determined that the terminal adopts a lightweight verification scheme, which only includes hash commitment calculation.

6. The method for large-scale meeting voting under a trusted mechanism according to claim 5, characterized in that, The process of obtaining the full verification threshold and the lightweight verification threshold includes: Obtain the terminal verification performance margin of each participating terminal in the current voting round, and calculate the arithmetic mean of the verification performance margins of all participating terminals as the average performance margin. Obtain the tiered verification confirmation achievement rate, wherein the tiered verification confirmation achievement rate is the average of the ratios of the number of participating terminals that have passed verification in each consensus group of the previous voting round to the total number of participating terminals that should participate. Multiply the average performance margin by the tiered verification confirmation achievement rate to obtain the complete verification threshold; Multiply the full verification threshold by the lightweight scaling factor to obtain the lightweight verification threshold.

7. The method for large-scale meeting voting under a trusted mechanism according to claim 1, characterized in that, Each participating terminal generates identity verification data using its respective verification strength level, and broadcasts it along with voting data to its respective shard consensus group, including: Based on the verification strength level of the participating terminal, identity verification data is obtained, wherein the identity verification data includes at least the terminal's identity credential proof and the integrity check code of the voting data; The participating terminal combines the identity verification data, the voting data, and the verification strength level identifier into a voting message, which is then broadcast to its respective shard consensus group.

8. The method for large-scale meeting voting under a trusted mechanism according to claim 1, characterized in that, Each shard consensus group verifies the identity verification data of the terminals within its shard consensus group, performs local consensus based on the verification results, aggregates the shard results by the root consensus chain, and outputs the final voting result, including: The shard consensus group verifies the identity verification data according to the verification strength level and counts the number of participating terminals that pass the verification. Obtain the total number of participating terminals that should participate in the voting within the segment consensus group, and divide the number of participating terminals that have passed verification by the total number of participating terminals that should participate in the voting within the group to obtain the local verification pass rate; When the local verification pass rate is greater than or equal to the consensus threshold, the voting data of all verified participating terminals are submitted to the root consensus chain. When the local verification pass rate is less than the consensus achievement threshold, the status of the identity verification data in the fragment consensus group is statistically analyzed, and the participating terminal that has passed the verification but whose verification strength level is a lightweight verification scheme is marked as a downgraded verification terminal. The downgraded verification terminal is upgraded and verified, and the local verification pass rate is repeatedly obtained until the local verification pass rate is greater than or equal to the consensus achievement threshold. The upgrade verification includes upgrading the lightweight verification scheme to the simplified verification scheme and upgrading the simplified verification scheme to the complete verification scheme. When all participating terminals in the shard consensus group that should participate in the voting adopt the complete verification scheme and the local verification pass rate is less than the consensus achievement threshold, the number of participating terminals that have passed the complete verification scheme and the number of participating terminals that have not passed the complete verification scheme are jointly included in the shard consensus data block. The identity verification data of the participating terminals that have not passed the complete verification scheme are submitted to the root consensus chain for cross-group cross-verification. If multiple shard consensus groups fail the consistency verification of the same terminal that has not passed verification, the voting data of that terminal is treated as abstention and included in the final voting result.

9. A large-scale meeting voting system based on a trusted mechanism, characterized in that, The system is used to execute the large-scale conference voting method under the trusted mechanism described in any one of claims 1-8, and the system comprises: The parameter acquisition module is used to obtain the terminal verification performance margin of each participating terminal and the voting urgency of the current voting round. The coefficient calculation module is used to calculate the adaptive verification depth coefficient of each participating terminal based on the terminal verification performance margin and the voting time urgency of each participating terminal. The level determination module is used to determine the verification intensity level based on the adaptive verification depth coefficient, wherein the verification intensity level includes at least a complete verification scheme, a simplified verification scheme, and a lightweight verification scheme. The broadcast module, deployed on each participating terminal, is used to generate identity verification data according to the aforementioned verification strength level, and broadcast it to the respective fragment consensus group along with the voting data. The consensus aggregation module is deployed in the shard consensus groups and the root consensus chain. It is used to enable each shard consensus group to verify the identity verification data of the terminals within the group, execute local consensus based on the verification results, and have the root consensus chain aggregate the shard results to output the final voting result.

Images