Verification and Sybil Resistance

🛡 Verification and Anti-Sybil

Because PoC can generate token rewards, a strict anti-cheat mechanism is required,

📝 Define a valid PoC event $E_{poc}$ For:

$$E_{poc} = \{ ID_A, ID_B, t, loc_{hash}, \sigma_A, \sigma_B, N \}$$

✅ Verification function $\text{Verify}(E_{poc})$ Must satisfy:

$$Verify(E_{poc}) = \begin{cases} 1(True), & \text{if } RSSI \ge \delta_{proximity} \\ & \land \ |t_{now} - t_{stamp}| \le \Delta_{validity} \\ & \land \ VerifySig(ID_A, m, \sigma_A) \\ & \land \ VerifySig(ID_B, m, \sigma_B) \\ & \land \ N \notin History_{nonce} \\ 0(False), & \text{otherwise} \end{cases}$$

🤖 Anti-Sybil mechanism (Anti-Sybil)

1. Entropy check：Real physical RSSI signals always have slight fluctuations. Nodes analyze signal variance and reject simulated connections that are "too stable."

2. Real-person liveness detection：Key actions must be performed via camera Liveness Check。

3. Graph theory analysis：Identify isolated botnet clusters (Clique).

🕵️‍♀️ ZK-SNARKs privacy protection (click to expand)

Although PoC needs to verify that "A and B are at the same location," that does not mean the "where" must be public.

Butterfly introduces ZK-SNARKs。Users only need to submit a proof $\pi$，proving that it satisfies $\text{RSSI}$and timestamp constraints, whilewithout needing topublish the raw$GPS$ coordinates on-chain.