Audio and video communication privacy protection method and system based on distributed ledger

Abstract

The application relates to the technical field of communication privacy, and discloses an audio and video communication privacy protection method and system based on a distributed ledger, which comprises the following steps: a three-level layered ledger architecture is constructed; a low-delay consensus mechanism is used in a real-time layer to quickly store and encrypt audio and video stream hashes, so that the communication is smooth; a privacy layer dynamically calculates privacy budget parameters based on context information, stores and stores metadata after differential privacy disturbance, and realizes the privacy protection of the metadata; and an archive layer automatically migrates and compresses historical data according to a preset strategy, and optimizes resource consumption. Meanwhile, an agent contract architecture is introduced to support the dynamic updating and gray release of smart contract logic, so that the user privacy rules can be flexibly configured and smoothly evolved. On the basis of ensuring the end-to-end encryption of audio and video content, the system real-time performance, the privacy protection strength and the operation and maintenance flexibility are synergistically improved.

Description

Technical Field

[0001] This invention relates to the field of communication privacy technology, and more specifically, to a method and system for protecting audio and video communication privacy based on distributed ledger. Background Technology

[0002] With the widespread adoption of mobile internet and real-time communication technologies, audio and video communication has become a fundamental infrastructure for social production and daily life. However, sensitive data generated during communication, including audio and video content and metadata, faces serious privacy risks. Existing privacy protection technologies mainly focus on end-to-end encryption of communication content, such as the Signal and OMEMO protocols. While these effectively prevent eavesdropping, they lack systematic protection for metadata. Metadata encompasses key information such as communication timestamps, participant identifiers, session duration, and event types. Research shows that sensitive information such as users' social relationships, behavioral patterns, and geographical locations can be inferred simply by analyzing metadata, constituting a new type of privacy threat: "metadata leakage." This threat stems from the inherent high correlation and inferability of metadata. For example, time series clustering can identify users' daily behavioral patterns, and combining this with geographical location information can reconstruct personal activity trajectories, leading to a substantial breach of privacy boundaries.

[0003] To enhance the trusted storage and policy enforcement capabilities of communication records, some research has attempted to introduce distributed ledger technology into the field of audio and video communication privacy protection. For example, some schemes write encrypted communication hashes into the blockchain to verify data integrity; others attempt to control access permissions to communication records through smart contracts. While these schemes utilize the immutability of distributed ledgers, they reveal the following insurmountable technical flaws in practical applications: First, the conflict between real-time performance and consensus efficiency is prominent. Audio and video communication has extremely strict requirements for end-to-end latency, typically below 200 milliseconds. However, existing distributed ledger solutions submit each session record to all nodes in the network for consensus verification. This verification process involves multiple rounds of message exchange and full node signature collection, leading to a significant increase in evidence storage latency. When using highly secure Byzantine fault-tolerant consensus algorithms, the latency often reaches the second level, severely disrupting communication fluency. If the consensus process is simplified to reduce latency, the system's fault tolerance is sacrificed, creating a dilemma between security and efficiency.

[0004] Second, metadata privacy protection mechanisms are lacking and cannot be quantified. Existing solutions mostly write raw metadata directly into the ledger, relying solely on hash desensitization or simple anonymization. Such methods cannot defend against on-chain analysis attacks based on statistical inference, such as inferring a user's social relationship network by associating timestamps with event types. Although some research has introduced differential privacy technology, its noise parameters are fixed and it does not dynamically adjust the protection strength based on the communication context, resulting in wasted privacy budgets or insufficient protection, and lacking real-time tracking and visualization feedback on privacy consumption.

[0005] Third, there is a lack of data lifecycle management mechanisms. The permanent nature of distributed ledgers fundamentally conflicts with the principle of data minimization required for privacy protection. Existing solutions have not established tiered storage strategies and automated archiving mechanisms, resulting in all data being stored long-term with equal resource consumption, leading to a continuous increase in storage costs. At the same time, the lack of automatic data destruction upon expiration, in compliance with regulatory requirements, creates long-term privacy risks.

[0006] Fourth, smart contract strategies are rigid and difficult to adapt to dynamic needs. Once privacy strategies are deployed and solidified in the form of smart contracts, updates require hard forks or a full network restart, a complex process with the risk of service interruption. The lack of operational mechanisms such as canary releases and version rollbacks makes it impossible to achieve smooth iteration and risk-controlled updates of the strategies.

[0007] Fifth, system integration is difficult and user migration costs are high. Most solutions require users to use dedicated communication clients, which are incompatible with mainstream platforms such as WeChat, Zoom, and Teams. Although there are attempts at plug-in solutions, the plug-in runtime environment lacks an effective security isolation mechanism, posing a risk of hijacking by host applications or malicious programs. At the same time, cross-platform implementation relies on significant differences in the underlying interfaces of the operating systems, such as compatibility issues between Android accessibility services and iOS screen recording APIs, resulting in insufficient stability and difficulty in large-scale deployment.

[0008] In summary, existing technologies exhibit significant technical bottlenecks across five dimensions: real-time evidence storage efficiency, provable protection of metadata privacy, data lifecycle management, dynamic policy evolution capabilities, and cross-platform secure integration. There is an urgent need for an innovative solution that can synergistically optimize performance and privacy, achieve quantifiable and controllable privacy protection, and possess engineering feasibility, in order to overcome the application barriers of distributed ledger technology in the field of privacy protection for real-time audio and video communication. Summary of the Invention

[0009] The purpose of this invention is to provide a method and system for protecting audio and video communication privacy based on distributed ledger, in order to solve the above-mentioned problems.

[0010] On one hand, the present invention provides a method for protecting audio and video communication privacy based on distributed ledger, comprising the following steps: During audio and video communication, the audio and video streams are encrypted end-to-end to generate encrypted audio and video streams, and the hash value of the encrypted audio and video streams is calculated. The hash value is submitted to the real-time layer of the distributed ledger, where the node cluster of the real-time layer verifies it using a low-latency consensus algorithm. Once verified, the hash value is stored in the real-time layer. The original metadata of the audio and video communication is obtained, the privacy budget parameter is dynamically calculated based on the context information, and the original metadata is subjected to differential privacy perturbation processing based on the privacy budget parameter. The perturbed metadata is submitted to the privacy layer of the distributed ledger, and the node cluster of the privacy layer verifies it using a high fault-tolerant consensus algorithm. After verification, it is stored in the privacy layer. According to the preset data lifecycle strategy, data that meets the archiving conditions is migrated from the real-time layer and the privacy layer to the archiving layer of the distributed ledger, and stored in the archiving layer using a compression algorithm; The smart contract logic is generated based on the privacy rules configured by the user. The smart contract logic is deployed on the distributed ledger through a proxy contract architecture, and the smart contract logic is dynamically updated using the proxy contract. In response to a request to access communication records, the access permission is verified through the smart contract, and access to the communication records is controlled based on the verification result.

[0011] Furthermore, dynamically calculating privacy budget parameters based on contextual information includes: Collect contextual information related to the current communication session, including user geolocation sensitivity, time sensitivity, and the closeness of the communication partner relationship; The privacy protection strength level is determined based on the context information, and the value range of the privacy budget parameter is dynamically adjusted according to the privacy protection strength level.

[0012] Furthermore, differential privacy perturbation processing of the raw metadata includes: Add noise that satisfies the differential privacy definition to time-related metadata using the Laplace mechanism; User identity identifiers are anonymized to generate anonymous identifiers that meet preset anonymity requirements; The event type information is desensitized using a combination of hash generalization and random perturbation.

[0013] Furthermore, the low-latency consensus algorithm employs a single-round voting mechanism, where a pre-selected leader node collects verification results and reaches a consensus.

[0014] Furthermore, the high fault-tolerant consensus algorithm adopts a multi-round voting mechanism, and realizes state synchronization and Byzantine fault tolerance verification between nodes through a multi-stage message exchange process of pre-preparation, preparation and submission.

[0015] Furthermore, the preset data lifecycle strategies include: Set thresholds for the retention time of data in the real-time layer and the privacy layer; When the data storage duration reaches the retention duration threshold, a data migration operation is triggered to the archiving layer; Set the maximum storage period for data in the archive layer, and perform data destruction operation after the expiration.

[0016] Furthermore, using the proxy contract to dynamically update the smart contract logic includes: Deploy a proxy contract that contains the storage unit for the logical contract address; Write the contract address corresponding to the initial smart contract logic into the storage unit; When a contract update instruction is received, the new version of the smart contract logic is deployed, and the contract address in the storage unit is updated to the address of the new version of the smart contract logic through the proxy contract; A canary release mechanism is set up during the update process to make the new version of the smart contract logic effective for a specified user group, and to decide whether to switch to a full rollout based on the operation monitoring indicators.

[0017] Furthermore, before verifying access rights via a smart contract, the following steps are also included: The client generates zero-knowledge proofs based on user identity credentials and auxiliary verification information; The zero-knowledge proof is verified by the verification node; Access to the communication records is only permitted if the zero-knowledge proof verification passes and the smart contract permission verification passes.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: Through the above steps, efficient evidence storage of audio and video communications, quantifiable privacy protection of metadata, and automated lifecycle management of data are achieved. This has the advantages of effectively reducing evidence storage delays during audio and video communications, providing quantifiable metadata privacy protection, and achieving automated management of the entire data lifecycle.

[0019] On the other hand, the present invention also provides an audio and video communication privacy protection system based on distributed ledger, comprising: The encrypted communication module is configured to perform end-to-end encryption of audio and video streams and generate hash values; The hierarchical ledger storage module includes a real-time layer node cluster, a privacy layer node cluster, and an archive layer storage unit. The real-time layer node cluster adopts a low-latency consensus algorithm, and the privacy layer node cluster adopts a high-fault-tolerant consensus algorithm. The differential privacy processing module is configured to collect context information, dynamically calculate privacy budget parameters, and perform differential privacy perturbations on metadata. The smart contract management module includes a proxy contract unit and a logic contract unit. The proxy contract unit is used to route call requests and support the dynamic replacement of logic contracts. The privacy control center module is configured to provide a user interface for configuring privacy rules, monitoring privacy budget consumption, and displaying access audit information. The plugin integration framework module is configured to provide a cross-platform runtime environment and security isolation mechanism.

[0020] Furthermore, the differential privacy processing module also includes a privacy budget tracking unit, which is configured as follows: The total privacy budget consumed by differential privacy operations in a single communication session or within a preset time period; When the cumulative consumption reaches the user's set budget threshold, the privacy protection enhancement mechanism is triggered or unnecessary metadata recording operations are suspended. The remaining privacy budget information is fed back to the privacy control center module in real time for visualization.

[0021] It should be noted that the beneficial effects of the audio and video communication privacy protection method based on distributed ledger provided by this invention are the same as those of its system, and will not be repeated here. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating a method for protecting audio and video communication privacy based on a distributed ledger, as provided in an embodiment of the present invention. Figure 2 This is a functional framework diagram of an audio and video communication privacy protection system based on distributed ledger provided in an embodiment of the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] For ease of understanding, the following explains some key terms in this embodiment: Real-time layer, privacy layer, and archive layer: These constitute different storage layers in the layered distributed ledger architecture of this application, and are used to process data with different real-time requirements, privacy sensitivity, and lifecycle requirements.

[0027] A node cluster refers to a group of computing nodes that work together in a distributed ledger network to maintain ledger data and execute consensus algorithms.

[0028] Contextual information: refers to the environment or background information related to the current audio or video communication session, such as the user's geographical location, communication time, and the relationship between the communication partners. This information can be used to dynamically adjust privacy protection strategies.

[0029] Privacy budget parameter: In differential privacy mechanisms, this parameter is used to quantify the strength of privacy protection. Its value affects the degree of data perturbation, and thus affects the balance between the level of privacy protection and data availability.

[0030] Differential privacy perturbation: a technique that protects individual privacy by adding random noise to the original data, making it impossible to infer any information about a single individual when statistically analyzing the perturbed data.

[0031] Smart contract logic: A piece of executable code deployed on a distributed ledger to automate the execution of preset rules and protocols, such as access permission verification and data processing.

[0032] Proxy contract architecture: A smart contract design pattern that uses a fixed proxy contract to call an upgradable logic contract, thereby enabling dynamic updates of the smart contract logic without modifying the proxy contract address.

[0033] Proxy contract: In a proxy contract architecture, a smart contract serves as the entry point and is responsible for forwarding call requests to the actual logic contract.

[0034] See Figure 1 As shown, this embodiment of the invention provides a method for protecting audio and video communication privacy based on distributed ledger, including: S1: During audio and video communication, the audio and video streams are first encrypted end-to-end to generate an encrypted audio and video stream, and then the hash value of this encrypted audio and video stream is calculated. Specifically, the encryption of the audio and video stream can be implemented in various ways. For example, the communicating parties can pre-agree on a shared symmetric key and use this key to encrypt real-time audio and video data. Alternatively, the sender can use the receiver's public key to perform asymmetric encryption on the audio and video stream. The encrypted audio and video stream is then used to calculate the hash value, which can be generated using various hash functions, such as MD5, SHA-1, or SHA-256. The hash value can be calculated all at once for the entire encrypted audio and video stream of the communication session, or it can be calculated periodically for each fixed time segment of the audio and video stream.

[0035] S2: Submit the hash value to the real-time layer of the distributed ledger. The node cluster in the real-time layer verifies the hash value using a low-latency consensus algorithm. Once verified, the hash value is stored in the real-time layer. The real-time layer consists of a cluster of nodes whose primary responsibility is to quickly verify and store data with high real-time requirements. This node cluster verifies the submitted hash value using a low-latency consensus algorithm. For example, a simple majority voting mechanism can be used, where verification is considered successful when more than half of the nodes in the network confirm the hash value's validity. After successful verification, the hash value is stored in the real-time layer.

[0036] S3: Obtain the raw metadata of the audio / video communication, dynamically calculate the privacy budget parameter based on the context information, and perform differential privacy perturbation processing on the raw metadata based on the privacy budget parameter. Submit the perturbed metadata to the privacy layer of the distributed ledger, where the node cluster of the privacy layer verifies it using a high-fault-tolerant consensus algorithm. After successful verification, it is stored in the privacy layer. Obtain the raw metadata of the audio / video communication. This raw metadata may include information such as communication time, participant identifiers, session duration, and event type. This data is typically obtained from the operating system or communication application interface through the communication client. To protect the privacy of this raw metadata, the privacy budget parameter is dynamically calculated based on the context information. For example, some fixed context information can be preset, such as all communications being "highly sensitive" or "lowly sensitive" by default, and a fixed privacy budget parameter can be set accordingly. Alternatively, a uniform privacy budget value can be manually set for perturbation processing of all metadata. Based on this privacy budget parameter, differential privacy perturbation processing is performed on the raw metadata. Specifically, for numerical metadata, a uniformly distributed random noise can be added; for categorical metadata, it can be randomly replaced with other categories. The perturbed metadata is then submitted to the privacy layer of the distributed ledger. This privacy layer also consists of a cluster of nodes that are verified using a highly fault-tolerant consensus algorithm. For example, a traditional Byzantine fault-tolerant algorithm can be used, ensuring state synchronization and consensus among nodes through multiple rounds of message exchange. After successful verification, the perturbed metadata is stored in this privacy layer.

[0037] S4: According to a preset data lifecycle strategy, data meeting the archiving criteria is migrated from the real-time layer and the privacy layer to the archive layer of the distributed ledger, where it is stored using a compression algorithm. This data lifecycle strategy can be set as a simple time-based rule; for example, all data can be stored in the real-time and privacy layers for a fixed period (e.g., 24 hours) before automatically triggering the migration operation. Data migration can be performed periodically by a separate management service that scans the data in the real-time and privacy layers, identifies data meeting the criteria, copies it to the archive layer, and then deletes it from the source layer. In the archive layer, data is stored using a compression algorithm; for example, standard ZIP or GZIP algorithms can be used to compress archived data to save storage space.

[0038] S5: Generates smart contract logic based on user-configured privacy rules. This smart contract logic is deployed on a distributed ledger using a proxy contract architecture, and dynamic updates to the smart contract logic are achieved through the proxy contract. The smart contract logic is generated based on user-configured privacy rules. Users can select preset privacy templates through a simple interface, such as "Allow only specified friends to access" or "Disallow access from anyone," and the corresponding smart contract code is generated based on these selections. This smart contract logic is deployed on the distributed ledger using a proxy contract architecture. This proxy contract architecture can be a simple forwarding contract that forwards all call requests to a fixed logical contract address. Dynamic updates to the smart contract logic are achieved using this proxy contract. For example, when privacy rules need to be updated, a new smart contract can be deployed, and then the logical contract address stored in the proxy contract can be manually modified to point to the new contract.

[0039] S6: In response to a request to access communication records, the smart contract verifies access permissions and controls access to the communication records based on the verification result. When a user initiates a request to view historical communication records through a client, the request is routed to the proxy contract. The smart contract will check, according to preset privacy rules, such as whether the requesting user's identity matches the owner of the communication records or whether they are on a whitelist. If the verification passes, the client is allowed to obtain the corresponding communication record data from the real-time layer, privacy layer, or archive layer; if the verification fails, access is denied.

[0040] Specifically, when user A and user B conduct an audio / video call, during the call, user A's communication client first performs end-to-end encryption on the audio and video streams, ensuring that only user A and user B can decrypt them. The encrypted audio and video streams are hashed in real time, for example, every 5 seconds. These hash values ​​are quickly submitted to the real-time layer of the distributed ledger. The node cluster in the real-time layer uses a fast consensus mechanism, such as simple majority voting, to verify and store the hash values ​​in a very short time (e.g., tens of milliseconds). Thus, the integrity of the audio and video streams is proven in real time without significantly impacting the real-time performance of the call.

[0041] Meanwhile, the communication client obtains the raw metadata of the call, including the call start time, call duration, and participant identifiers. To protect this metadata, a fixed privacy budget parameter is calculated based on preset context information, such as the default medium sensitivity for all communications. Based on this privacy budget parameter, the raw metadata undergoes differential privacy perturbation. For example, random noise is added to the call duration, and simple anonymization is applied to the participant identifiers. The perturbed metadata is then submitted to the privacy layer of the distributed ledger. The node cluster of the privacy layer employs a highly fault-tolerant consensus algorithm, such as using multiple rounds of message exchange to ensure the secure storage and consistency of metadata even if some nodes fail or engage in malicious behavior.

[0042] When a call ends and a period of time has elapsed, such as 24 hours, the call's hash value and the perturbed metadata meet the archiving conditions in the preset data lifecycle policy. A background management service detects that this data has reached the retention time threshold and triggers a data migration operation. This data is migrated from the real-time and privacy layers to the archive layer of the distributed ledger, where it is stored using the GZIP compression algorithm to reduce long-term storage costs.

[0043] User A configures privacy rules via a client before or after a call, such as "only allow user C to access my call logs". Smart contract logic is generated based on this rule and deployed on a distributed ledger using a proxy contract architecture. This proxy contract serves as the entry point for user A's communication log access permissions. If user A later decides to modify the rules, such as "allowing user C and user D to access", new smart contract logic is generated, and the proxy contract updates the logic contract address to the new version's address, thus achieving dynamic updates of the privacy rules without service interruption.

[0044] When user C attempts to access the call log between user A and user B, their access request is sent to the proxy contract. The smart contract verifies user C's access rights based on the privacy rules configured by user A. If the verification passes, the smart contract authorizes user C to retrieve the hash value and perturbed metadata of the call from the archiving layer. If user C does not have the necessary permissions, the access request is denied.

[0045] By submitting the hash values ​​of audio and video streams to the real-time layer and employing a low-latency consensus algorithm, this application effectively resolves the contradiction between real-time performance and consensus efficiency in existing technologies. For example, in the above example, the hash values ​​of audio and video streams can be quickly stored, while existing solutions typically require submitting all communication records to all network nodes for time-consuming consensus verification, resulting in compromised communication fluency. The layered storage and differentiated consensus mechanism of this application enable high-real-time data to be quickly uploaded to the blockchain while ensuring data integrity.

[0046] Secondly, this application significantly improves the quantification and effectiveness of metadata privacy protection by acquiring the original metadata, dynamically calculating the privacy budget parameters, and performing differential privacy perturbation processing. In the example above, the perturbed metadata is stored in the privacy layer, effectively resisting on-chain analysis attacks based on statistical inference. Compared to existing solutions that rely solely on hash desensitization or simple anonymization, this application's differential privacy mechanism provides provable privacy protection strength and avoids wasting or insufficiently protecting the privacy budget by dynamically adjusting the privacy budget parameters.

[0047] Furthermore, this application introduces a data lifecycle strategy and a tiered storage architecture, resolving the conflict between the "permanent existence" of distributed ledgers and the "data minimization" of privacy protection. In the example above, data is migrated to the archiving layer and compressed for storage after reaching the archiving criteria, effectively reducing storage costs and providing a foundation for subsequent data destruction. Existing technologies typically store all data on a single ledger for extended periods, leading to continuously rising storage costs and a lack of automatic data destruction capabilities upon expiration.

[0048] Furthermore, by using a proxy contract architecture to dynamically update smart contract logic, this application overcomes the shortcomings of existing smart contract strategies, such as rigidity and difficulty in adapting to dynamic needs. In the example above, user A can smoothly update their privacy rules without performing complex hard forks or a full network restart. This dynamic update capability, combined with mechanisms such as canary releases, enables privacy strategies to iterate flexibly, improving maintainability and adaptability.

[0049] In summary, this embodiment utilizes innovative technologies such as layered distributed ledger, dynamic differential privacy, data lifecycle management, and proxy contract architecture to synergistically optimize the real-time performance and privacy protection of audio and video communication. It achieves quantifiable and controllable privacy protection and provides flexible policy management capabilities, thereby overcoming the bottlenecks of existing technologies in multiple dimensions.

[0050] This application further proposes a step for dynamically calculating privacy budget parameters based on context information, including: collecting context information related to the current communication session, the context information including user geolocation sensitivity, time sensitivity, and the closeness of the communication object relationship; determining the privacy protection strength level based on the context information, and dynamically adjusting the value range of the privacy budget parameters according to the privacy protection strength level.

[0051] Contextual information refers to data relevant to the current audio / video communication session that reflects the communication environment and characteristics of the participants. This information can be obtained from various sources, such as geolocation data from user device sensors, time information from system clocks, and analysis of communication relationships through user address books, social network relationships, or historical communication records. User geolocation sensitivity refers to a user's level of concern about the disclosure of their geolocation information, which can be determined by the user's preset privacy preferences or inferred from the type of geolocation (e.g., home address, workplace, public place). Time sensitivity refers to a user's level of concern about the disclosure of the time of communication; for example, communications during non-working hours or during specific sensitive events may have higher time sensitivity. Communication relationship intimacy refers to the closeness or level of trust between the communicating parties, such as relatives, friends, colleagues, or strangers. Privacy protection strength level is a quantification or classification of the required level of privacy protection; it can be a discrete level (e.g., low, medium, high) or a continuous numerical value, used to guide adjustments to privacy budget parameters. Dynamically adjusting the range of privacy budget parameters refers to modifying the allowed range or specific values ​​of privacy budget parameters (such as ε and δ) in a differential privacy mechanism in real time based on a determined level of privacy protection, to adapt to different privacy protection needs. For example, when stronger privacy protection is required, the range of privacy budget parameters will be limited to a smaller range, thus introducing more noise; conversely, when the privacy protection requirement is lower, the range of privacy budget parameters can be appropriately widened to maximize data availability while ensuring a certain level of privacy.

[0052] This application's solution first collects multi-dimensional contextual information related to the current communication session, such as the user's geographical location sensitivity, time sensitivity, and the intimacy of the communication partner's relationship. This information provides a comprehensive and detailed insight into the privacy requirements of the current communication scenario. Subsequently, a comprehensive evaluation is performed based on this multi-dimensional contextual information to determine an appropriate level of privacy protection. For example, when a user is in a geographical location marked as highly sensitive, the communication occurs during a sensitive time period, and the intimacy of the communication partner's relationship is low, it is determined that the current communication requires extremely high privacy protection. Once the privacy protection level is determined, the range of values ​​for the privacy budget parameter is dynamically adjusted according to that level. This means that for scenarios requiring high privacy protection, the privacy budget parameter (such as the ε value) in the differential privacy mechanism will be set within a small range, thereby introducing more noise when performing differential privacy perturbation processing on the original metadata, providing stronger privacy guarantees; conversely, in scenarios with lower privacy requirements, the range of values ​​for the privacy budget parameter can be appropriately widened, allowing for smaller perturbations, in order to maximize data availability while ensuring a certain level of privacy. Through this refined and adaptive adjustment mechanism, the solution proposed in this application can overcome the limitations of static privacy budgets, enabling privacy protection strategies to flexibly adapt to the ever-changing privacy needs during audio and video communication, thereby achieving an optimal balance between privacy protection and data utility in different scenarios.

[0053] Specifically, during an audio / video communication, the following contextual information is first collected: User location sensitivity may be obtained through the user's device's location service; for example, if the user is currently located in their preset "home" area, location sensitivity is marked as "high." Time sensitivity may be determined based on the time period of the communication; for example, if the communication occurs at 2 AM, time sensitivity is marked as "high." The intimacy of the communication partner's relationship may be determined by analyzing the address book or social relationship chain; for example, if the communication partner is an unknown number not marked in the address book, the intimacy is marked as "low." Based on this contextual information, a privacy protection strength level is comprehensively judged and determined. For example, when the user's location sensitivity is "high," time sensitivity is "high," and the communication partner's relationship intimacy is "low," the privacy protection strength level may be set to "extremely high." Subsequently, based on the "extremely high" privacy protection strength level, the value range of the privacy budget parameter is dynamically adjusted. For example, the privacy budget parameter ε required for differential privacy perturbation processing can be limited to a range of [0.1, 0.5] to ensure strong perturbation of metadata, thereby providing maximum privacy protection. Conversely, if the context information indicates low privacy sensitivity, such as a user communicating with colleagues during work hours, the privacy protection strength level might be set to "medium," and the range of the privacy budget parameter ε adjusted to [1.0, 2.0] to allow the metadata to retain more usable information while ensuring privacy.

[0054] In some embodiments described above, this application proposes differential privacy perturbation processing of raw metadata during audio and video communication by collecting contextual information and dynamically calculating privacy budget parameters. However, raw metadata typically contains various types of information, such as timestamps, user identities, and event types. These different types of data have varying sensitivities to privacy breaches and require different privacy protection technologies. Using a single or indiscriminate perturbation strategy may result in insufficient protection of certain sensitive information or unnecessary damage to data usability, making it difficult to achieve the optimal balance between privacy protection strength and data usability.

[0055] In response, this application further proposes differential privacy perturbation processing for the original metadata, including: adding noise that meets the definition of differential privacy to time-related metadata using the Laplace mechanism; anonymizing user identity identifiers to generate anonymous identifiers that meet the preset anonymity requirements; and desensitizing event type information by combining hash generalization and random perturbation.

[0056] Specifically, the Laplace mechanism is used to add noise that meets the definition of differential privacy for time-related metadata. The Laplace mechanism is a commonly used differential privacy technique. Its core idea is to add random noise following a Laplace distribution to the original data to obscure the precise value of individual data points, thereby protecting individual privacy in a statistical sense. This mechanism can precisely control the strength of privacy protection by adjusting the scale parameter of the noise, ensuring that even if an attacker possesses all information except for the target individual's data, they cannot infer the target individual's specific data with a high probability. This can be achieved by generating random numbers conforming to a Laplace distribution using a random number generator and directly superimposing them onto numerical metadata such as timestamps; or by pre-calculating the scale parameter of the Laplace distribution based on privacy budget and data sensitivity, and then generating and adding noise according to this parameter. User identity identifiers are anonymized to generate anonymous identifiers that meet preset anonymity requirements. Anonymization aims to convert information that directly identifies an individual into a form that cannot be directly associated with a specific individual. This approach effectively reduces the risk of identity leakage while preserving the analytical value of the data to a certain extent. Anonymization can be achieved using various techniques. For example, the original user ID can be converted into a pseudo-random string using a one-way hash function, serving as a new anonymous identifier. Alternatively, more advanced anonymization models such as K-anonymity and L-diversity can be used to obfuscate individual data with data from other K-1 individuals, making it impossible for attackers to distinguish specific individuals and thus meeting the preset anonymity requirements. For event type information, a combination of hash generalization and random perturbation can be used for desensitization. Event type information is usually categorical data, and directly adding numerical noise may not be suitable. Hash generalization refers to mapping specific event types to broader categories or hash values, thereby reducing their specificity. For example, specific event types such as "video call started" and "voice call ended" can be uniformly mapped to the generalized category of "communication event." Building on this, random perturbation—that is, randomly changing the generalized event type with a certain probability—further increases the uncertainty of the data, making it difficult for attackers to accurately infer the original event type. This combined approach effectively protects privacy while preserving the approximate statistical characteristics of event types. For example, a perturbation probability can be set so that the generalized event type has a small probability of being replaced by other random generalized event types.

[0057] During audio and video communication, after obtaining the original metadata and dynamically calculating the privacy budget parameters based on context information, this application's solution refines the perturbation processing into specific strategies for time-related metadata, user identity identifiers, and event type information to achieve refined privacy protection for different types of sensitive metadata. Specifically, for time-related metadata, since it is usually numerical, a Laplace mechanism is used to add noise that meets the differential privacy definition, effectively obscuring precise time points. Simultaneously, by adjusting the noise scale, quantitative protection of time sensitivity is ensured while meeting the overall privacy budget. For user identity identifiers, which are directly associated with individuals, anonymization is employed to generate anonymous identifiers that meet preset anonymity requirements, fundamentally severing the direct link between identity and behavior, and greatly reducing the risk of identity leakage. For event type information, as categorical data, hash generalization is used to classify it into a broader category. Combined with random perturbation, the specific event details are further obscured, making it difficult for attackers to infer users' specific behavioral patterns from event types. These three mechanisms work together to provide customized differential privacy perturbation schemes tailored to the characteristics of different sensitive attributes in metadata. This ensures that, under a dynamic privacy budget, the original metadata can obtain comprehensive and efficient privacy protection before being submitted to the privacy layer of the distributed ledger, thus effectively solving the problem that a single perturbation strategy cannot meet the privacy protection needs of different data types.

[0058] The following example illustrates how differential privacy perturbation of raw metadata in audio and video communications can be performed: If the raw metadata contains a communication start timestamp (e.g., Unix timestamp 1678886400), a user identifier (e.g., "user_id_A1B2C3"), and an event type (e.g., "video conference started"), firstly, for the communication start timestamp, a random noise value (e.g., +120 seconds) conforming to the dynamically calculated privacy budget parameter (e.g., ε=0.1) can be generated using a Laplace mechanism. This noise value is then added to the original timestamp to obtain the perturbed timestamp (1678886400 + 120 = 1678886520). Secondly, for the user identifier "user_id_A1B2C3", a pre-defined anonymization algorithm can be used. For example, it can be processed by a secure hash function (such as SHA-256) through one-way hashing, and a portion of the hash value can be extracted as the anonymous identifier. Alternatively, it can be replaced with a pre-generated anonymous ID (e.g., "anon_user_XYZ") without any original identity information through a mapping table to meet the pre-defined anonymity requirements. Finally, for the event type "video conference started", it can first be hashed and generalized to map it to a more general category, such as "communication event". Subsequently, a random perturbation mechanism can be introduced, for example, randomly replacing "communication event" with other generalized categories, such as "system event" or "file transfer event" with a 5% probability, thereby further obscuring the precise semantics of the original event. Through the above processing, sensitive information in the original metadata receives multi-dimensional and granular privacy protection before being submitted to the privacy layer of the distributed ledger.

[0059] Through the above technical solutions, this application provides customized differential privacy perturbation strategies for different types of sensitive information in the raw metadata of audio and video communications. Specifically, a Laplace mechanism is used to add noise to time-related metadata, which can effectively obscure precise time points while maintaining the statistical characteristics of time series; user identity identifiers are anonymized, fundamentally severing the direct link between identity and behavior, greatly reducing the risk of identity leakage; and a combination of hash generalization and random perturbation is used for event type information, which protects the privacy of specific events while preserving the macroscopic statistical value of the events. This multi-dimensional and refined perturbation processing enables a more effective balance between privacy protection strength and data availability by dynamically adjusting privacy budget parameters, avoiding the privacy leakage risk or excessive loss of data value that may be caused by single or coarse perturbations, thereby significantly improving the overall privacy protection level of audio and video communication metadata.

[0060] This application further proposes that the low-latency consensus algorithm adopts a single-round voting mechanism, in which a pre-selected leader node collects the verification results and reaches a consensus.

[0061] The low-latency consensus algorithm is designed to quickly achieve a consistent state in a distributed system. Its core objective is to minimize the time overhead of the consensus process while ensuring data consistency and system reliability. This algorithm can be a consensus protocol that optimizes message passing and verification steps, for example, by reducing network round trips or processing verification tasks in parallel to shorten consensus time; or it can be a consensus mechanism designed for specific application scenarios (such as high throughput and low latency), for example, allowing for a certain degree of sacrifice in decentralization in exchange for higher efficiency. The single-round voting mechanism is a simplified voting method for the consensus process. Its characteristic is that consensus is mainly achieved through one or a very small number of message exchanges and voting processes, rather than traditional multi-round complex interactions. For example, in the consensus process, nodes only need to vote once, and then a specific role (such as a leader) summarizes the voting results and announces consensus; or through pre-set rules or conditions, most nodes can complete verification and submit votes within a voting cycle after receiving a proposal, thereby quickly forming consensus. The pre-selected leader node refers to one or more nodes in the distributed system that are pre-designated or selected through a specific election mechanism, responsible for coordinating the consensus process, collecting votes, and deciding the final proposal or verification result. For example, the leader node can be pre-configured or dynamically elected through polling, random selection, or based on metrics such as node performance and reputation. Alternatively, it can be the master node in a master-slave architecture, responsible for receiving verification results from all participants and making the final consensus decision. Collecting verification results means the leader node receives verification feedback from each participating node regarding the proposal or transaction. For example, the leader node can receive verification messages from other nodes through network broadcasting, peer-to-peer communication, or a dedicated aggregation service; or the leader node can maintain a verification status table recording the verification status (e.g., agree, reject, pending) of each participating node for a specific proposal. Rapidly reaching consensus means that within a very short time, a majority or all nodes in the distributed system reach an agreement on a certain data or state. For example, the consensus process can be accelerated by optimizing network topology, reducing message transmission paths, and employing efficient data structures or algorithms; it can also be achieved by utilizing hardware acceleration, parallel computing, and other technologies to improve consensus efficiency at the computation and communication levels.

[0062] This application's solution constructs an efficient consensus process by combining a low-latency consensus algorithm with a single-round voting mechanism and introducing a pre-selected leader node. During audio and video communication, when the hash value of the encrypted audio and video stream is submitted to the real-time layer, the pre-selected leader node coordinates the real-time layer node cluster for verification. Upon receiving the hash value, each node quickly verifies it and sends its verification result to the leader node in the form of a single-round vote. After collecting a sufficient number of verification results, the leader node can immediately determine whether the hash value has passed verification and reach a consensus, thereby storing the hash value in the real-time layer. This mechanism avoids the complex interactions and waiting times of traditional multi-round consensus algorithms, significantly shortening the consensus time and ensuring that the hash value of audio and video communication data can be recorded and confirmed with extremely low latency.

[0063] Specifically, the real-time layer node cluster consists of N nodes, one of which is pre-designated as the leader node. When a hash value of an encrypted audio / video stream is generated during audio / video communication, this hash value is broadcast to all N nodes in the real-time layer. Each node, upon receiving the hash value, immediately performs a preliminary verification, such as checking the hash value's format, length, and whether it conforms to a preset encryption standard. After verification, each node sends its verification result (e.g., "valid" or "invalid") directly to the pre-selected leader node. Upon receiving verification results from a majority of nodes (e.g., more than two-thirds of the nodes), if the majority result indicates the hash value is valid, the leader node immediately declares consensus reached and submits the hash value to the real-time layer for storage. The entire process involves only one major vote and result aggregation, thus achieving millisecond-level consensus latency.

[0064] By employing the above technical solution and adopting a single-round voting mechanism with a pre-selected leader node, the number of message exchanges and verification steps in the consensus process is greatly simplified. The leader node can efficiently collect verification results from other nodes and quickly make consensus decisions, thereby significantly reducing the latency of verifying and storing audio and video stream hash values ​​at the real-time layer. This ensures that the real-time requirements of audio and video communication are met, avoids stuttering or interruptions caused by consensus delays, and improves the user's smooth experience of audio and video communication in a distributed ledger environment.

[0065] In other embodiments, this application proposes a privacy protection method for audio and video communication based on a distributed ledger. During audio and video communication, the audio and video streams are end-to-end encrypted to generate encrypted audio and video streams, and a hash value of the encrypted audio and video streams is calculated. The hash value is submitted to the real-time layer of the distributed ledger, where a cluster of nodes in the real-time layer verifies it using a low-latency consensus algorithm. After successful verification, the hash value is stored in the real-time layer. The original metadata of the audio and video communication is obtained, and a privacy budget parameter is dynamically calculated based on context information. Differential privacy perturbation processing is applied to the original metadata based on the privacy budget parameter, and the perturbed metadata is submitted to the privacy protection method of the distributed ledger. The privacy layer is verified by a cluster of nodes using a highly fault-tolerant consensus algorithm. Once verified, the data is stored in the privacy layer. According to a preset data lifecycle strategy, data meeting archiving conditions is migrated from the real-time layer and the privacy layer to the archive layer of the distributed ledger, where it is stored using a compression algorithm. Smart contract logic is generated based on user-configured privacy rules, deployed on the distributed ledger through a proxy contract architecture, and dynamically updated using the proxy contract. In response to access requests for communication records, access permissions are verified through the smart contract, and access to the communication records is controlled based on the verification result. In some of the above embodiments, the encrypted stream hash value of audio and video communication is submitted to the real-time layer of the distributed ledger, where it is verified and stored by a cluster of nodes using a low-latency consensus algorithm. However, for the privacy layer storing sensitive metadata processed by differential privacy perturbation, simply pursuing a low-latency consensus mechanism may be insufficient to cope with complex network environments and potential malicious node attacks, potentially affecting the integrity and reliability of privacy data.

[0066] In response, this application further proposes that the high fault-tolerant consensus algorithm adopts a multi-round voting mechanism and realizes state synchronization and Byzantine fault tolerance verification between nodes through a multi-stage message exchange process of pre-preparation, preparation and submission.

[0067] Highly fault-tolerant consensus algorithms aim to ensure data consistency and normal operation in a distributed system even when some nodes fail or behave abnormally (including malicious behavior). Their core lies in using redundancy, voting, and verification mechanisms to resist various failure modes. For example, the Practical Byzantine Fault Tolerance (PBFT) algorithm or its variants, or a Byzantine fault-tolerant algorithm based on Proof-of-Stake (PoS), can be used. Multi-round voting mechanisms are a method of reaching consensus through multiple interaction phases, providing stronger security and consistency guarantees compared to single-round voting mechanisms. In multi-round voting, nodes exchange and confirm messages multiple times to ensure that all honest nodes agree on the proposed data. For example, this can include a proposal phase, a pre-voting phase, and a voting phase, or a more complex pre-preparation, preparation, and commit phase. The multi-stage message exchange process of pre-preparation, preparation, and commit is a typical process for implementing Byzantine fault-tolerant consensus. Specifically, in the pre-preparation phase, the master node (or proposing node) broadcasts a pre-preparation message containing pending requests to all replica nodes. This phase aims to ensure that all replica nodes receive the same sequence of requests. In the preparation phase, upon receiving a pre-preparation message, a replica node verifies its validity and broadcasts a preparation message to all other replica nodes, indicating its readiness to accept the request. This phase ensures that all honest nodes agree on the order of requests. In the commit phase, once a replica node has received a sufficient number of preparation messages, it broadcasts a commit message to all other replica nodes, indicating its readiness to execute the request and update its state. This phase ensures that all honest nodes will eventually execute the same request and update to the same state. Inter-node state synchronization refers to ensuring that all nodes participating in consensus in the distributed ledger have the same and up-to-date data replicas and ledger state. Through a multi-phase message exchange process, nodes can mutually confirm and synchronize their understanding of transaction order and ledger updates, thereby avoiding forks and data inconsistencies. Byzantine fault tolerance verification refers to the system's ability to guarantee its correctness and consistency even when some nodes experience arbitrary failures (including malicious data tampering, sending false messages, or denial of service). Multi-round voting mechanisms and multi-stage message exchange processes prevent malicious behavior by a minority of Byzantine nodes by requiring a majority of honest nodes to reach a consensus, ensuring that the final submitted data is confirmed by a majority of nodes.

[0068] This application's solution employs a highly fault-tolerant consensus algorithm and implements a multi-round voting mechanism. Through a multi-stage message exchange process involving pre-preparation, preparation, and submission, it ensures extremely high integrity and consistency of the perturbed metadata stored in the privacy layer of the distributed ledger. During audio and video communication, when the metadata processed by differential privacy perturbation is submitted to the privacy layer, the node cluster of the privacy layer initiates this multi-stage consensus process. First, a master node initiates a pre-preparation message, broadcasting the perturbed metadata to be written to all other replica nodes. Upon receiving the pre-preparation message, these replica nodes verify its legitimacy and send preparation messages to other nodes, indicating that they are ready to accept the metadata. When each node collects a sufficient number of preparation messages, it enters the submission phase, sends a submission message, and finally writes the perturbed metadata to its local ledger replica. This interconnected multi-stage message exchange process ensures that even in the event of failure or malicious behavior by some nodes (i.e., Byzantine fault), a majority of honest nodes can achieve eventual consistency in the writing order and content of the metadata, thereby achieving synchronization of the state between nodes. This mechanism significantly enhances the reliability and tamper-proof capability of privacy layer data, provides robust security for sensitive metadata that has undergone privacy processing, and effectively addresses the shortcomings of low-latency consensus algorithms when facing high fault tolerance requirements.

[0069] In one specific implementation, when the raw metadata of audio and video communication, after differential privacy perturbation processing—for example, a data packet containing an anonymous user ID and obfuscated event types—is submitted to the privacy layer of the distributed ledger, it is treated as a transaction awaiting confirmation. A designated master node in the privacy layer first encapsulates the data packet in a pre-preparation message and broadcasts it to all other replica nodes. For example, the master node can assign a sequence number and view number to the message to ensure its uniqueness and order. Replica nodes receiving the pre-preparation message verify its legitimacy, such as checking the master node's signature and whether the sequence number matches expectations. Once verification is successful, each replica node generates a preparation message containing its confirmation information for the data packet and broadcasts it to all other nodes. When a replica node collects a sufficient number of preparation messages from different nodes (e.g., more than two-thirds), it considers the data packet to have reached agreement during the preparation phase. Subsequently, the node generates a commit message and broadcasts it to all nodes again. Finally, when each node has collected a sufficient number of commit messages, it will write the perturbed metadata into its local distributed ledger copy, completing a highly fault-tolerant consensus process.

[0070] Through the above technical solution, the privacy layer of the distributed ledger can employ a highly fault-tolerant consensus algorithm. Through multi-round voting mechanisms and a multi-stage message exchange process involving pre-preparation, preparation, and commit, it effectively resists Byzantine faults, ensuring high consistency and tamper-proofness of metadata processed by differential privacy perturbations during storage. This significantly improves the security and reliability of the privacy layer data, guaranteeing the integrity of privacy metadata even in the event of malicious behavior or failure in some nodes, avoiding the risk of data tampering or loss. Compared to consensus mechanisms that only pursue low latency, this solution provides more robust protection for sensitive privacy data, thereby enhancing the robustness and credibility of the entire audio and video communication privacy protection method.

[0071] In other embodiments, this application proposes a distributed ledger-based method for protecting the privacy of audio and video communications. This method uses a real-time layer, a privacy layer, and an archiving layer to store and manage the hash values ​​and perturbation metadata of audio and video streams in a layered manner, and utilizes smart contracts to control access. However, in practical applications, without clear management of the data lifecycle, the data in the real-time and privacy layers may grow indefinitely, leading to wasted storage resources, decreased query efficiency, and an increased risk of old data leakage, making it difficult to effectively balance the needs of data availability and long-term privacy protection.

[0072] In response, this application further proposes a preset data lifecycle strategy, which includes: setting a retention duration threshold for data in the real-time layer and the privacy layer; triggering a data migration operation to the archive layer when the data storage duration reaches the retention duration threshold; setting a maximum storage period for data in the archive layer, and performing a data destruction operation after the expiration.

[0073] The preset data lifecycle strategy refers to a set of predefined rules and processes used to manage the entire lifecycle of data from creation to destruction. Its purpose is to ensure the reasonable flow of data between different storage tiers and its eventual secure and compliant processing. This strategy can be configured by system administrators based on regulatory requirements, business needs, or user privacy preferences, for example, through configuration files, database records, or smart contract parameters. Setting the data retention time threshold in the real-time and privacy layers refers to the maximum storage time limit set for data in the real-time and privacy layers of the distributed ledger. Once data has been stored in this layer for more than this threshold, it is considered no longer needed for real-time or frequent access, thus triggering subsequent processing. This threshold can be set according to the sensitivity of the data, access frequency requirements, or compliance requirements; for example, it can be set to several hours, several days, or several weeks. Triggering a data migration operation to the archive layer means that when data meets the preset retention time threshold condition, the process of automatically moving data from the real-time or privacy layer to the archive layer is executed. This operation aims to transfer inactive but still necessary data to the lower-cost and more efficient archive storage. Migration operations can be triggered by scheduled tasks, event listeners, or smart contracts, ensuring data integrity and security during the migration process. Setting the maximum storage period for data in the archiving tier refers to the final storage time limit set for data in the distributed ledger's archiving tier. This period defines the total time data is allowed to exist in the system; data exceeding this period is considered expired and needs to be destroyed. This period is typically determined based on laws and regulations, industry standards, or internal corporate policies; for example, it can be set to months, years, or even decades. Automated data destruction refers to the automatic initiation and completion of a permanent deletion process for data without manual intervention when it reaches its maximum storage period in the archiving tier. This operation aims to ensure that sensitive data is thoroughly removed after fulfilling its purpose, meeting privacy and compliance requirements. Data destruction can employ various technologies, such as encrypted erasure, secure deletion algorithms, or physical destruction of storage media.

[0074] This application's solution provides fine-grained control over the storage and management of audio and video communication-related data in a distributed ledger by introducing a pre-defined data lifecycle strategy. Specifically, this strategy first sets clear retention duration thresholds for data in the real-time and privacy layers. After the hash values ​​of encrypted audio and video streams generated during audio and video communication and the metadata processed with differential privacy perturbations are stored in the real-time and privacy layers respectively, the storage duration of this data is continuously monitored. Once the storage duration of any data item reaches the pre-defined threshold, a data migration operation is automatically triggered according to the strategy, transferring this data from the active real-time and privacy layers to the lower-cost archive layer, primarily used for long-term storage. After the data is migrated to the archive layer, the strategy further sets the maximum storage period for the data in the archive layer. The storage time of data in the archive layer will continue to be tracked, and once the data reaches its maximum storage period, a data destruction operation is automatically performed to ensure that the data is completely and irreversibly deleted. Through this phased and automated management mechanism, this solution effectively solves the problem of unlimited data growth in a distributed ledger, optimizes storage resource utilization, and strengthens long-term privacy protection capabilities.

[0075] As a specific implementation, the retention threshold for the hash value of encrypted audio and video streams generated during audio and video communication in the real-time layer can be set to 7 days, while the retention threshold for metadata processed by differential privacy perturbation in the privacy layer can be set to 30 days. When the hash value in the real-time layer is stored for more than 7 days, or the metadata in the privacy layer is stored for more than 30 days, a migration procedure will be automatically triggered. For example, a background service or smart contract can periodically check the timestamps of data in each layer. Once expired data is found, it is packaged, encrypted, and transmitted to the archive layer. In the archive layer, the maximum storage period for all archived data can be set to 5 years. When a piece of data in the archive layer has been stored for 5 years, the data destruction module will be automatically invoked to perform encrypted erasure of the data, for example, by overwriting random data multiple times to ensure that the original data cannot be recovered.

[0076] In other embodiments, this application proposes a privacy protection method for audio and video communication based on a distributed ledger. During audio and video communication, the method performs end-to-end encryption on the audio and video streams to generate encrypted audio and video streams, and calculates the hash value of the encrypted audio and video streams. The hash value is submitted to the real-time layer of the distributed ledger, where it is verified by a low-latency consensus algorithm used by the node cluster of the real-time layer. After successful verification, the hash value is stored in the real-time layer. Simultaneously, the original metadata of the audio and video communication is obtained, and a privacy budget parameter is dynamically calculated based on context information. Differential privacy perturbation processing is applied to the original metadata based on the privacy budget parameter. The perturbed metadata is then submitted to the privacy layer of the distributed ledger, where it is verified by a high-fault-tolerant consensus algorithm used by the node cluster of the privacy layer. After successful verification, the metadata is stored in the privacy layer. According to a preset data lifecycle strategy, data meeting archiving conditions is migrated from the real-time layer and the privacy layer to the archiving layer of the distributed ledger, where it is stored using a compression algorithm. Smart contract logic is generated based on user-configured privacy rules. This smart contract logic is deployed on the distributed ledger using a proxy contract architecture, and the proxy contract is used to dynamically update the smart contract logic. In response to a request to access communication records, access permissions are verified through the smart contract, and access to the communication records is controlled based on the verification result.

[0077] In some embodiments described above, this application proposes generating smart contract logic based on user-configured privacy rules, deploying this smart contract logic on a distributed ledger through a proxy contract architecture, and using the proxy contract to dynamically update the smart contract logic. However, in practical applications, updating smart contracts may involve complex logical changes. If the new version of the contract has potential defects or compatibility issues, a direct full update may lead to system instability, service interruption, or abnormal data processing, thereby affecting the privacy protection effect of audio and video communication and the user experience.

[0078] To address this, this application further proposes using the proxy contract to dynamically update the smart contract logic, including: deploying a proxy contract containing a storage unit for the logic contract address; writing the contract address corresponding to the initial smart contract logic into the storage unit; when a contract update instruction is received, deploying the new version of the smart contract logic, and updating the contract address in the storage unit to the address of the new version of the smart contract logic through the proxy contract; setting a canary release mechanism during the update process to make the new version of the smart contract logic effective for a specified user group, and deciding whether to switch to a full version based on the operation monitoring indicators.

[0079] Specifically, deploying a proxy contract containing a storage unit for the logical contract address refers to deploying a special smart contract on a distributed ledger. This contract itself does not contain business logic, but rather a variable used to store the address of the actual business logic contract. All calls to this proxy contract are forwarded to the logical contract address stored internally for execution. This design allows the underlying logical contract to be updated without changing the proxy contract address (i.e., the user interaction address), thus achieving smart contract upgradeability. For example, the proxy contract can adopt a "transparent proxy pattern," where the proxy contract forwards calls to the logical contract via the `delegatecall` instruction, or a "generic upgradeable proxy pattern," where the upgrade logic itself is also contained within the logical contract.

[0080] Writing the contract address corresponding to the initial smart contract logic into the storage unit is a crucial step in the proxy contract initialization process. After the proxy contract is deployed, it needs to specify the logic contract to which it should initially forward call requests. This logic contract contains the privacy rules and access control logic required when the system starts. For example, the address of the initial logic contract can be received as a parameter in the proxy contract's constructor and stored in a specific state variable within the proxy contract, or this can be accomplished by calling a specific initialization function of the proxy contract.

[0081] When a contract update instruction is received, the core operation of a smart contract upgrade is to deploy the new version of the smart contract logic and update the contract address in the storage unit to the address of the new version of the smart contract logic through the proxy contract. When it is necessary to update the functionality of a smart contract or fix a vulnerability, a new smart contract (the new logic contract) is first deployed. Then, an authorized entity (such as an administrator or multisignature wallet) sends an update instruction to the proxy contract. This instruction modifies the logic contract address stored internally in the proxy contract, making it point to the newly deployed logic contract. For example, the proxy contract may contain an `upgradeTo(address newImplementation)` function, which can only be called by authorized addresses to update the stored logic contract address to `newImplementation`.

[0082] Setting up a canary release mechanism during the update process, allowing the new smart contract logic to take effect on a designated user group, and then deciding whether to switch to a full rollout based on operational monitoring metrics, is a software release strategy aimed at gradually introducing the new version's functionality into the production environment, rather than releasing it all at once. In the smart contract field, this means that the new logic contract will not immediately take effect on all users, but will first take effect on a small group of users or transactions under specific conditions to observe its operation and potential problems. For example, the proxy contract can maintain a user whitelist or user group list. When it receives a call request, the proxy contract determines whether to forward it to the old or new logic contract based on the caller's identity or specific parameters of the request. Alternatively, the proxy contract can introduce a "version switching" parameter, such as a percentage threshold. When a call request arrives, it determines whether to route the request to the new logic contract based on a random number or a specific hash value. Operational monitoring metrics can include the new contract's transaction success rate, gas consumption, error logs, user feedback, etc.

[0083] This application's solution separates the logic and state of smart contracts through a proxy contract architecture, allowing the business logic of smart contracts to be updated independently of their deployment address. When a smart contract logic needs to be updated, the new version of the smart contract logic is deployed first, and then user requests are routed to the new logic through the proxy contract. To ensure the smoothness and security of the update process, this application introduces a canary release mechanism. During the canary release phase, the proxy contract routes a portion of user or specific types of requests to the new version of the smart contract logic according to preset rules (e.g., a privacy protection strength level determined based on contextual information such as user identity, geographical location, time sensitivity, or the closeness of the communication partner's relationship), while the remaining requests are still handled by the old version of the logic. During this period, the operation status of the new version of the smart contract logic is continuously monitored, including operational monitoring indicators such as transaction success rate, resource consumption, and error logs. If the new version of the logic performs stably and as expected during the canary release, a full switch can be decided, routing all user requests to the new version of the smart contract logic. If problems are found, a rollback to the old version of the logic can be performed in a timely manner to avoid impacting the entire system. This mechanism works in conjunction with the real-time, privacy, and archiving layers of the distributed ledger to ensure that, based on the dynamic adjustment of privacy budget parameters and differential privacy perturbation processing, the privacy rules and access control logic of smart contracts can be iterated and optimized securely and flexibly, thereby continuously and effectively protecting the privacy of audio and video communications.

[0084] Specifically, when an audio / video communication privacy protection system needs to update its access control smart contract to adapt to new data compliance requirements, the system first deploys a proxy contract named `PrivacyProxy`, which contains a storage unit named `implementationAddress`. During initial deployment, `implementationAddress` is set to the address of the `PrivacyLogicV1` contract, which contains the current privacy access rules. When new compliance requirements are released, the development team writes and deploys a `PrivacyLogicV2` contract, which contains the updated privacy access rules. For secure updates, the system administrator sends an update command to the `PrivacyProxy` contract, triggering a canary release mechanism. For example, the `PrivacyProxy` contract can maintain a `grayReleaseUsers` list or a `grayReleasePercentage` variable. When a user requests access to communication records, the `PrivacyProxy` contract checks the requesting user's identity. If the user is in the `grayReleaseUsers` list, or if the value calculated using a certain hash algorithm falls within the `grayReleasePercentage` range, `PrivacyProxy` will `delegatecall` the request to the `PrivacyLogicV2` contract for execution. For other users, the request will still be `delegatecall`ed to the `PrivacyLogicV1` contract. During this period, the system will continuously monitor the operation of `PrivacyLogicV2`, for example, by analyzing its transaction success rate, gas consumption, and any abnormal behavior through on-chain event logs. If `PrivacyLogicV2` runs stably among the specified user group and all operational monitoring metrics are normal, the system administrator will send an instruction to the `PrivacyProxy` contract again to permanently update `implementationAddress` to the address of `PrivacyLogicV2`, thereby completing the full switchover. If `PrivacyLogicV2` encounters problems during a canary release, the system administrator can immediately roll back and redirect `implementationAddress` to `PrivacyLogicV1`, thus avoiding potential risks.

[0085] Through the aforementioned technical solutions, this application significantly enhances the flexibility and robustness of the distributed ledger-based audio and video communication privacy protection method. The introduction of a canary release mechanism ensures that updates to smart contract logic are no longer high-risk full replacements, but rather can be carried out gradually and in a controlled manner. This greatly reduces the risk of system instability, service interruptions, or privacy data leaks due to defects in the new contract version, ensuring the continuity and reliability of audio and video communication privacy protection services. Simultaneously, the decision-making mechanism combined with operational monitoring indicators enables the system to dynamically adjust its update strategy based on actual operational results, improving the efficiency and security of smart contract iteration. This dynamic update capability allows the system to better adapt to constantly changing privacy regulations, security threats, and business needs, thereby continuously providing users with efficient and secure audio and video communication privacy protection.

[0086] In other embodiments, this application proposes a privacy protection method for audio and video communication based on a distributed ledger. This method involves end-to-end encryption of the audio and video stream during communication, generating an encrypted audio and video stream, and calculating the hash value of the encrypted audio and video stream. The hash value is then submitted to the real-time layer of the distributed ledger, where a cluster of nodes verifies it using a low-latency consensus algorithm. Upon successful verification, the hash value is stored in the real-time layer. The method also involves acquiring the original metadata of the audio and video communication, dynamically calculating a privacy budget parameter based on context information, and performing differential privacy perturbation processing on the original metadata based on the privacy budget parameter. Finally, the perturbed metadata is submitted to the privacy protection method of the distributed ledger. The private layer is verified by the node cluster of the privacy layer using a highly fault-tolerant consensus algorithm. Once verified, the data is stored in the privacy layer. According to a preset data lifecycle strategy, data meeting archiving conditions is migrated from the real-time layer and the privacy layer to the archive layer of the distributed ledger, where it is stored using a compression algorithm. Smart contract logic is generated based on user-configured privacy rules, deployed on the distributed ledger through a proxy contract architecture, and dynamically updated using the proxy contract. In response to access requests for communication records, access permissions are verified through the smart contract, and access to the communication records is controlled based on the verification result.

[0087] In some of the embodiments described above in this application, although access permissions to communication records are strictly controlled through smart contracts, traditional permission verification mechanisms may still pose a risk of leakage of user identity information or access intent when users submit identity credentials for verification. This direct authentication method cannot fully meet users' privacy needs during the access process itself in certain scenarios with extremely high privacy requirements.

[0088] In response, this application further proposes that before verifying access permissions through a smart contract, the following steps are also included: the client generates a zero-knowledge proof based on the user's identity credentials and auxiliary verification information; the verification node verifies the zero-knowledge proof; and access to the communication records is only allowed when the zero-knowledge proof is verified and the smart contract permission verification is passed.

[0089] In this context, the client-generated zero-knowledge proof based on user identity credentials and auxiliary verification information refers to the client using cryptographic protocols to prove to the verification node that it has legitimate access to communication records without revealing its specific identity credentials or auxiliary verification information. This significantly enhances the privacy of the access process. The client can utilize zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) technology to encode user identity credentials (such as private key signatures and digital certificates) and auxiliary verification information (such as specific attributes and roles) into a mathematical problem, generating a concise, non-interactive proof. This proof can be verified quickly without revealing any original data about the credentials and auxiliary information. Alternatively, the client can employ zk-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge) technology, which features post-quantum security and higher efficiency in proof generation and verification, making it particularly suitable for large-scale computation.

[0090] Verification of zero-knowledge proofs by verification nodes refers to one or more specific nodes in a distributed ledger network receiving and verifying zero-knowledge proofs submitted by clients. Its role is to confirm the validity of the zero-knowledge proofs generated by the client, thereby indirectly confirming the client's access rights without directly processing or storing the client's sensitive identity information. Verification nodes can have built-in zero-knowledge proof verifiers. When receiving a zero-knowledge proof submitted by a client, the verifier performs mathematical verification on the proof according to preset public parameters and verification algorithms. For example, for zk-SNARKs, the verifier performs elliptic curve pairing operations to check the validity of the proof. Alternatively, verification nodes can integrate dedicated Hardware Security Modules (HSMs) or Trusted Execution Environments (TEEs) to perform the zero-knowledge proof verification process, thereby improving verification efficiency and enhancing security.

[0091] Access to the communication records is only permitted when both the zero-knowledge proof verification and the smart contract permission verification pass. This dual verification mechanism combines the privacy protection features of zero-knowledge proofs with the decentralized permission management capabilities of smart contracts. It ensures the highest level of security and privacy for accessing communication records. The zero-knowledge proof guarantees the privacy of the requester's identity, while the smart contract ensures that the access request conforms to preset business logic and permission rules. Both are indispensable and together constitute a robust access control barrier. After the zero-knowledge proof verification passes, the verification node can send a signal with the verification result to the smart contract management module. Upon receiving this signal, the smart contract management module executes its own permission verification logic. Access authorization to the communication records is only triggered when both verification results are "passed". Alternatively, the smart contract itself can be designed to receive and verify zero-knowledge proofs. In this case, the client directly submits the zero-knowledge proof to the smart contract, which contains the verification logic for the zero-knowledge proof and, upon successful verification, further executes its preset permission verification.

[0092] In this application's method for protecting audio and video communication privacy, a zero-knowledge proof mechanism is introduced to further enhance the privacy and security of the communication record access process. When responding to a request to access communication records, instead of directly submitting user identity credentials to the smart contract for permission verification, the client first generates a zero-knowledge proof based on its user identity credentials and auxiliary verification information. This zero-knowledge proof demonstrates to the verification node that the client has access rights without revealing any specific content about the user identity credentials or auxiliary verification information. Subsequently, a dedicated verification node rigorously verifies this zero-knowledge proof to confirm its validity. Only when the zero-knowledge proof passes verification, indicating that the requester is indeed qualified to access and their identity information is protected by privacy, will the system further initiate the smart contract's permission verification process. The smart contract will perform a final permission judgment on the access request based on preset privacy rules and business logic. Ultimately, only when both the zero-knowledge proof and the smart contract's permission verification successfully pass will the system allow access to the communication records. This dual-verification mechanism combines the identity privacy protection capabilities of zero-knowledge proofs with the decentralized permission management capabilities of smart contracts, constructing a more secure and privacy-friendly communication record access control system. It not only ensures that only authorized users can access the data, but more importantly, it protects users' sensitive identity information during the verification process, effectively addressing the identity leakage risks that traditional permission verification may bring, thus achieving a higher level of privacy protection in a distributed ledger environment.

[0093] Specifically, when user A wishes to access a segment of encrypted communication records stored on the distributed ledger, their client application first collects user A's digital identity credentials (e.g., a digital certificate issued by an authoritative institution or its DID private key signature in the distributed identity system) and auxiliary verification information (e.g., the level of intimacy between user A and communication partner B, whether the access time is within the allowed range, etc.). The client uses a pre-compiled zero-knowledge proof circuit, such as a zk-SNARKs circuit based on the Groth16 protocol, to take this sensitive information as private input and generate a concise zero-knowledge proof that does not contain any original identity data. The client then submits this zero-knowledge proof to one or more verification nodes in the distributed ledger network. These verification nodes, which may run on a dedicated verification server cluster or be part of the distributed ledger's consensus nodes, perform a fast mathematical verification of the received zero-knowledge proof using a pre-defined public verification key and verification algorithm. If the zero-knowledge proof verification passes, the verification node sends an authorization signal to the smart contract management module, along with an anonymized request identifier. Upon receiving this signal, the smart contract management module invokes the smart contract deployed on the distributed ledger. The smart contract verifies the permissions of anonymous request identifiers according to preset privacy rules (e.g., access is only allowed to the communication participants or their authorized third parties, and must meet specific time windows or geographical location restrictions). For example, the smart contract checks whether the anonymous request identifier is associated with an authorized communication participant or whether it meets specific access conditions. Only when both the zero-knowledge proof verification and the smart contract permission verification are successful will the system authorize user A's client to access the communication record and provide a decryption key or directly transmit encrypted data for the client to decrypt.

[0094] By introducing a zero-knowledge proof mechanism when accessing communication records using the above technical solution, users can prove to the system that they have legitimate access rights without directly exposing their identity credentials and auxiliary verification information. This significantly improves the privacy of the access process and effectively avoids the risk of identity information leakage that may exist in traditional permission verification. At the same time, combined with the permission verification of smart contracts, a dual and multi-dimensional security barrier is formed, ensuring that only truly authorized requests that meet privacy protection requirements can successfully access communication records. Thus, in a distributed ledger environment, this provides more rigorous and privacy-friendly access control for audio and video communication records, enhancing users' trust and control over data privacy.

[0095] See Figure 2 As shown, this embodiment of the invention provides an audio and video communication privacy protection system based on distributed ledger, including: The encrypted communication module is configured to perform end-to-end encryption of audio and video streams and generate hash values; The hierarchical ledger storage module includes a real-time layer node cluster, a privacy layer node cluster, and an archive layer storage unit. The real-time layer node cluster adopts a low-latency consensus algorithm, while the privacy layer node cluster adopts a high-fault-tolerant consensus algorithm. The differential privacy processing module is configured to collect context information, dynamically calculate privacy budget parameters, and perform differential privacy perturbations on metadata. The smart contract management module includes a proxy contract unit and a logic contract unit. The proxy contract unit is used to route call requests and supports the dynamic replacement of logic contracts. The privacy control center module is configured to provide a user interface for configuring privacy rules, monitoring privacy budget consumption, and displaying access audit information. The plugin integration framework module is configured to provide a cross-platform runtime environment and security isolation mechanism.

[0096] In some embodiments of this application, the differential privacy processing module further includes a privacy budget tracking unit, which is configured as follows: The total privacy budget consumed by differential privacy operations in a single communication session or within a preset time period; When the cumulative consumption reaches the user's set budget threshold, the privacy protection enhancement mechanism is triggered or unnecessary metadata recording operations are suspended. The remaining privacy budget information is fed back to the privacy control center module in real time for visualization.

[0097] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for protecting the privacy of audio and video communication based on distributed ledger, characterized in that, Includes the following steps: During audio and video communication, the audio and video streams are encrypted end-to-end to generate encrypted audio and video streams, and the hash value of the encrypted audio and video streams is calculated. The hash value is submitted to the real-time layer of the distributed ledger, where the node cluster of the real-time layer verifies it using a low-latency consensus algorithm. Once verified, the hash value is stored in the real-time layer. The original metadata of the audio and video communication is obtained, the privacy budget parameter is dynamically calculated based on the context information, and the original metadata is subjected to differential privacy perturbation processing based on the privacy budget parameter. The perturbed metadata is submitted to the privacy layer of the distributed ledger, and the node cluster of the privacy layer verifies it using a high fault-tolerant consensus algorithm. After verification, it is stored in the privacy layer. According to the preset data lifecycle strategy, data that meets the archiving conditions is migrated from the real-time layer and the privacy layer to the archiving layer of the distributed ledger, and stored in the archiving layer using a compression algorithm; The smart contract logic is generated based on the privacy rules configured by the user. The smart contract logic is deployed on the distributed ledger through a proxy contract architecture, and the smart contract logic is dynamically updated using the proxy contract. In response to a request to access communication records, the access permission is verified through the smart contract, and access to the communication records is controlled based on the verification result.

2. The method for protecting audio and video communication privacy based on distributed ledger according to claim 1, characterized in that, The privacy budget parameters are dynamically calculated based on contextual information, including: Collect contextual information related to the current communication session, including user geolocation sensitivity, time sensitivity, and the closeness of the communication partner relationship; The privacy protection strength level is determined based on the context information, and the value range of the privacy budget parameter is dynamically adjusted according to the privacy protection strength level.

3. The method for protecting audio and video communication privacy based on distributed ledger according to claim 2, characterized in that, Differential privacy perturbation of raw metadata includes: Add noise that satisfies the differential privacy definition to time-related metadata using the Laplace mechanism; User identity identifiers are anonymized to generate anonymous identifiers that meet preset anonymity requirements; The event type information is desensitized using a combination of hash generalization and random perturbation.

4. The method for protecting audio and video communication privacy based on distributed ledger according to claim 3, characterized in that, The low-latency consensus algorithm employs a single-round voting mechanism, where a pre-selected leader node collects verification results and reaches a consensus.

5. The method for protecting audio and video communication privacy based on distributed ledger according to claim 4, characterized in that, The high fault-tolerant consensus algorithm adopts a multi-round voting mechanism and realizes inter-node state synchronization and Byzantine fault tolerance verification through a multi-stage message exchange process of pre-preparation, preparation and submission.

6. The method for protecting audio and video communication privacy based on distributed ledger according to claim 5, characterized in that, The preset data lifecycle strategies include: Set thresholds for the retention time of data in the real-time layer and the privacy layer; When the data storage duration reaches the retention duration threshold, a data migration operation is triggered to the archiving layer; Set the maximum storage period for data in the archive layer, and perform data destruction operation after the expiration.

7. The method for protecting audio and video communication privacy based on distributed ledger according to claim 6, characterized in that, The dynamic updating of the smart contract logic using the proxy contract includes: Deploy a proxy contract that contains the storage unit for the logical contract address; Write the contract address corresponding to the initial smart contract logic into the storage unit; When a contract update instruction is received, the new version of the smart contract logic is deployed, and the contract address in the storage unit is updated to the address of the new version of the smart contract logic through the proxy contract; A canary release mechanism is set up during the update process to make the new version of the smart contract logic effective for a specified user group, and to decide whether to switch to a full rollout based on the operation monitoring indicators.

8. The method for protecting audio and video communication privacy based on distributed ledger according to claim 7, characterized in that, Before verifying access rights via a smart contract, the following is also included: The client generates zero-knowledge proofs based on user identity credentials and auxiliary verification information; The zero-knowledge proof is verified by the verification node; Access to the communication records is only permitted if the zero-knowledge proof verification passes and the smart contract permission verification passes.

9. A distributed ledger-based audio and video communication privacy protection system, used to implement the distributed ledger-based audio and video communication privacy protection method according to any one of claims 1-8, characterized in that, include: The encrypted communication module is configured to perform end-to-end encryption of audio and video streams and generate hash values; The hierarchical ledger storage module includes a real-time layer node cluster, a privacy layer node cluster, and an archive layer storage unit. The real-time layer node cluster adopts a low-latency consensus algorithm, and the privacy layer node cluster adopts a high-fault-tolerant consensus algorithm. The differential privacy processing module is configured to collect context information, dynamically calculate privacy budget parameters, and perform differential privacy perturbations on metadata. The smart contract management module includes a proxy contract unit and a logic contract unit. The proxy contract unit is used to route call requests and support the dynamic replacement of logic contracts. The privacy control center module is configured to provide a user interface for configuring privacy rules, monitoring privacy budget consumption, and displaying access audit information. The plugin integration framework module is configured to provide a cross-platform runtime environment and security isolation mechanism.

10. The audio and video communication privacy protection system based on distributed ledger according to claim 9, characterized in that, The differential privacy processing module also includes a privacy budget tracking unit, which is configured as follows: The total privacy budget consumed by differential privacy operations in a single communication session or within a preset time period; When the cumulative consumption reaches the user's set budget threshold, the privacy protection enhancement mechanism is triggered or unnecessary metadata recording operations are suspended. The remaining privacy budget information is fed back to the privacy control center module in real time for visualization.

Images