Проєктування протоколу анонімного голосування: розбір технічної реалізації та архітектурних рівнів

Вітання спільноті DOU! Хочу поділитися досвідом проєктування та технічної реалізації архітектури The Development Matrix Protocol — рішення, яке розроблялося для забезпечення анонімного голосування в децентралізованих системах із захистом від Sybil-атак.

Головне інженерне завдання, яке стояло перед нами: дозволити системі перевірити, що користувач є унікальною живою людиною і має право голосу, але при цьому забезпечити повну анонімність і не збирати жодних персональних даних (KYC). Нижче наведено детальний розбір реалізованої нами 4-рівневої архітектури:

Рівень 1. Identity Layer (Інтеграція з Proof-of-Personhood)

Замість збору паспортних даних, на першому рівні система інтегрується з децентралізованими Web3-графами:

• Gitcoin Passport: використовується для аналізу історії та оцінки «ваги» акаунта, що дозволяє автоматично відсікати прості скрипти.
• World ID: застосовується для криптографічної перевірки унікальності користувача (на основі zero-knowledge інструментів) без передачі біометричних даних у мережу.

Рівень 2. Local Device Layer (Генерація ZK-proof на стороні клієнта)

Для забезпечення приватності всі обчислення перенесені на сторону користувача (Client-Side):

• Безпосередньо в браузері або мобільному застосунку генерується ZK-SNARK (Zero-Knowledge Proof).
• Паралельно створюється унікальний криптографічний нуліфікатор (Nullifier).
• Результат: В мережу для верифікації відправляється лише математичний доказ. Приватні ключі та ідентифікатори користувача ніколи не залишають його пристрій.

Рівень 3. On-Chain EVM Smart Contract (Верифікація та захист від повторного голосування)

Смартконтракт в EVM-сумісній мережі приймає ZK-доказ та нуліфікатор для виконання двох завдань:

1. On-Chain верифікація: Контракт перевіряє валідність математичного ZK-доказу. Якщо перевірка успішна — голос зараховується.
2. Контроль Single-Use Nullifier: Контракт зберігає використані нуліфікатори у сховищі (storage). При спробі повторного відправлення голосу з тим самим нуліфікатором транзакція відхиляється. Зв’язати нуліфікатор з початковим ID користувача неможливо.

Рівень 4. Output Layer (Алгоритм розподілу голосів)

На фінальному етапі обробки даних застосовується алгоритм квадратичного зважування (Quadratic Weighting за формулою N²). Це інженерний інструмент, де вартість кожного наступного голосу за одне й те саме рішення зростає експоненціально, що робить масові маніпуляції бюджетами чи голосами економічно нерентабельними.

Поточні технічні виклики

Наразі основна точка оптимізації — зниження часу генерації ZK-доказів на Рівні 2 для мобільних пристроїв, щоб покращити UX. Буду радий почути фідбек колег: які бібліотеки (наприклад, snarkjs/circom) ви використовуєте для клієнтського ZK і як оптимізуєте витрати газу на верифікацію on-chain?