ShadowBlock: Dynamic Anonymous Blocklisting

• ShadowBlock is an efficient dynamic anonymous blocklisting scheme that restricts malicious activities using cryptographic primitives like PRFs, RSA accumulators, and zkSNARKs.
• Its design enables rapid proof generation, constant-time user updates, and batch verification, ensuring scalability in both single-chain and cross-chain identity management.
• The protocol balances privacy, unforgeability, and dynamism, making it a practical solution for real-time digital platforms facing high blocklist churn and large user bases.

ShadowBlock is an efficient dynamic anonymous blocklisting scheme constructed to restrict malicious user activities such as online harassment or abuse on digital platforms, while preserving user identity privacy. Traditional blocklists either compromise privacy or are inefficient for dynamic/large-scale use. ShadowBlock realizes blocklistability, anonymity, non-frameability, and strong dynamism by combining pseudorandom functions (PRFs), dynamic RSA accumulators, and aggregation-capable zero-knowledge proofs. Its architecture supports privacy-preserving authentication and rapid incremental updates, and it is applicable to both single-chain and cross-chain identity management scenarios (Deng et al., 22 Dec 2025).

1. System Model, Goals, and Threat Assumptions

ShadowBlock defines three core participants: Identity Providers (IDPs), users, and Service Providers (SPs). The IDP issues long-term secret keys and system parameters. Users receive unique keys and public parameters. The SP maintains the blocklist in the form of an RSA accumulator and verifies user proofs of non-membership.

The system goals are:

• Blocklistability: Only users whose pseudonyms are not present in the blocklist can authenticate.
• Unforgeability (Non-frameability): Adversaries cannot cause unblocked users to be rejected or blocked users to be accepted.
• Anonymity/Unlinkability: The authentication proofs leak no information identifying the user or session.
• Dynamism: Users can efficiently update proofs under blocklist changes in sublinear time.

The threat model permits asynchronous networks and an honest-but-curious SP, while the adversary cannot corrupt the IDP or SP but can observe all public updates. All schemes rely on standard cryptographic assumptions for RSA, PRF security, and SNARKs.

2. Cryptographic Primitives and Architectural Building Blocks

ShadowBlock integrates three principal cryptographic elements:

• Pseudorandom Functions (PRFs): For each user with secret $k$, the PRF $\mathsf{PRF}_k(x)$ generates unlinkable, pseudo-random session tags for arbitrary nonces $x$. No polynomially-bounded algorithm can distinguish PRF outputs from random with non-negligible advantage.
• RSA Dynamic Accumulators: The blocklist is aggregated into a one-way accumulator over modulus $N=pq$.
  • Add/Del/Verify operations: SP can add and remove elements via modular exponentiation with public exponent $e$ and generator $g \in \mathbb{Z}_N^*$.
• zkSNARKs (e.g., Groth16): Compact zero-knowledge proofs are used for non-membership verification and support aggregation for batch verification.

Blocklist representation separates public nonces and accumulator tags, enabling efficient on-chain storage and privacy-preserving proof generation.

3. Core Protocol Workflow and Aggregation Techniques

User authentication proceeds by constructing non-membership proofs over the current blocklist:

• Proof Generation (ProveNonMem): A user computes $tag = \mathsf{PRF}_k(nonce)$ and a commitment $C = nonce^e \pmod N$, then constructs a zkSNARK circuit demonstrating both correctness of $tag$ w.r.t. $k$ and that $tag$ is not in the current accumulator set (enforced via $\mathcal{A}(X)\cdot tag^{-e} \equiv g\!\!\mod N$).
• Verification (VerifyNonMem): The SP checks correctness of commitments and verifies the SNARK.

For batch settings, ShadowBlock employs aggregated commitments $C_{\mathsf{agg}} = \prod_{i=1}^n nonce_i^e \pmod N$ and a single SNARK covering all instances, resulting in $O(1)$ total verification cost.

Incremental updates are realized via the linearity of the accumulator and SNARK circuits, enabling reuse and delta-updating of proofs after blocklist changes, with complexity $O(1)$ per operation.

4. Security and Privacy Properties

ShadowBlock achieves three formally sketched properties:

• Blocklistability: Proved via an experiment in which adversaries cannot produce a convincing non-membership proof for a truly blocklisted tag, as this would require inverting either the SNARK, accumulator soundness, or PRF security.
• Anonymity/Unlinkability: A challenge experiment shows that the combination of pseudorandom tags, SNARK zero-knowledge, and commitment hiding nullifies user/session inference by adversaries.
• Non-frameability: It is infeasible for adversaries to create a proof that wrongfully incriminates an honest user without breaking the underlying PRF or proof system.

5. Performance Benchmarks and Resource Analysis

Empirical evaluation on client (Intel i5-8259U) and server (Xeon Platinum 8480C) hardware demonstrates the following:

Metric	ShadowBlock	SNARKBlock	BLAC/MaskAuct	ALPACA
ProofGen	~0.3 s	0.5–1.1 s	>1 s	6–17 s
Verify	~10 ms	50–200 ms	>1 s	400 ms
Proof Size	~1 KB	Linear	Exponential	~2 KB
Storage	$n$+1 words	$2n$+1	$2n$+1	$n$+1
Update	~0.3 s	~0.5 s	~1 s	7–17 s

Dynamism is maximized, with $O(1)$ user update costs and on-chain storage requiring only the nonces and a single accumulator. This suggests ShadowBlock is practical for platforms with frequent blocklist churn and large user bases (Deng et al., 22 Dec 2025).

6. Applications: Cross-chain Identity Management

ShadowBlock facilitates privacy-preserving identity blocklisting in cross-chain distributed identity (DID) environments:

• Each supported blockchain maintains a local DID module.
• A relay chain stores the global accumulator, updated by a consensus committee.
• Blocklisted pseudonyms are added/removed on the relay; users obtain the latest accumulator for proof.
• Aggregated zero-knowledge proofs allow $O(1)$ batch verification for multi-chain requests.
• Session tags derived from the PRF for each authentication event maintain unlinkability across chains and instances.

Key optimizations include incremental proof update and batch verification. Coordination between chains for accumulator synchronization and data availability emerges as a practical challenge in decentralized deployments.

7. Limitations and Directions for Extension

A plausible implication is that, while ShadowBlock achieves constant-time proof update and verification under ideal cryptographic primitives, challenges remain for distributed committee robustness and on-chain liveness in fully decentralized environments. The design may be extended to more complex identity-attribution models and broader adversarial scenarios—as well as adapted for other forms of revocation or exclusion lists in distributed authentication. In scenarios demanding high churn or throughput, further protocol engineering to optimize accumulator operations or SNARK efficiency may be warranted (Deng et al., 22 Dec 2025).