חוזים חכמים להצבעה ריבועית עבור DAO ו-DeFi

הצבעה ריבועית פותרת בעיה יסודית של הצבעה משוקללת לפי אסימונים: לווייתן עם פי 1000 אסימונים יש פי 1000 השפעה. אנו מתכננים מערכות שבהן כוח ההצבעה פרופורציונלי לשורש הריבועי של המשאב המושקע. 100 נקודות הצבעה נותנות 10 יחידות כוח הצבעה. 900 נקודות — 30. כדי לקבל את אותו כוח כמו 9 אנשים עם נקודה אחת כל אחד, צריך להשקיע 81 נקודות. מתמטיקה: השפעה = √נקודות. זה הופך את זה ללא כדאי כלכלית עבור משתתף יחיד לשלוט לעומת קואליציה רחבה. הניסיון שלנו — 5+ שנים בפיתוח בלוקצ'יין, מעל 10 מערכות הצבעה מיושמות. אנו מבטיחים ביקורת קוד והגנה מפני התקפות.

כיצד הצבעה ריבועית פותרת את בעיית שליטת הווייתנים

בהצבעה רגילה, למחזיק 10,000 אסימונים יש פי 100 יותר השפעה ממחזיק 100 אסימונים. QV משנה זאת: עם נקודות פרופורציונליות ליתרה, כוח ההצבעה שונה פי √100 = 10. עבור DAOs עם חלוקת אסימונים לא אחידה, זה משפר משמעותית את ההוגנות.

QV הוצעה על ידי כלכלנים אריק פוזנר וגלן וייל בספר Radical Markets. ההיגיון מאחורי המנגנון: בהצבעה רגילה, אדם אחד = קול אחד, אך עוצמת ההעדפה אינה נשקלת. מי שדואג מאוד לתוצאה ומי שאדיש имеют משקל זהה. QV מאפשרת לבטא עוצמה דרך מספר הנקודות המושקעות — קרוב יותר להעדפות כלכליות אמיתיות.

דוגמה: 100 אנשים מעדיפים מעט אפשרות A. 10 אנשים רוצים מאוד אפשרות B. בהצבעה רגילה, A מנצחת. ב-QV, אם כל אחד מ-10 משקיע 100 נקודות על B (כוח = 10 × √100 = 100), הם יכולים לגבור על קואליציה של 100 שכל אחד משקיע נקודה אחת (כוח = 100 × √1 = 100). בשיווי משקל, התוצאה הרצויה בעוצמה רבה יותר מנצחת.

מערכות נקודות הצבעה

מודל Voice Credits

תוכנית סטנדרטית: כל משתתף מקבל תקציב קבוע של נקודות קול לכל סבב הצבעה. הנקודות אינן ניתנות להעברה ופגות בכל סבב.

contract QuadraticVoting {
    struct VotingRound {
        uint256 startTime;
        uint256 endTime;
        mapping(uint256 => int256) optionVotes; // optionId => суммарные голоса (sqrt-взвешенные)
    }

    uint256 public constant CREDITS_PER_ROUND = 100;

    // Потраченные кредиты участника в текущем раунде
    mapping(address => mapping(uint256 => uint256)) public creditsSpent;

    function vote(
        uint256 roundId,
        uint256 optionId,
        uint256 credits, // credits to spend on this option
        bool support
    ) external {
        VotingRound storage round = rounds[roundId];
        require(block.timestamp >= round.startTime && block.timestamp < round.endTime, "Round inactive");

        uint256 totalSpent = creditsSpent[msg.sender][roundId] + credits;
        require(totalSpent <= CREDITS_PER_ROUND, "Exceeds budget");

        // QV: голосовая сила = sqrt(credits)
        uint256 votes = sqrt(credits);
        creditsSpent[msg.sender][roundId] = totalSpent;

        if (support) {
            round.optionVotes[optionId] += int256(votes);
        } else {
            round.optionVotes[optionId] -= int256(votes);
        }

        emit VoteCast(msg.sender, roundId, optionId, credits, votes, support);
    }

    // Integer square root (Babylonian method)
    function sqrt(uint256 x) internal pure returns (uint256 y) {
        if (x == 0) return 0;
        uint256 z = (x + 1) / 2;
        y = x;
        while (z < y) {
            y = z;
            z = (x / z + z) / 2;
        }
    }
}

נקודות משוקללות לפי אסימונים

תוכנית חלופית: נקודות פרופורציונליות ליתרת האסימונים (כמו ב-Gitcoin Grants). מחזיק 1000 אסימונים מקבל 1000 נקודות. אבל כוח ההצבעה הוא עדיין √ של הנקודות המושקעות. זה נותן למשתתפים עשירים יותר נקודות, אך לא השפעה לינארית.

השוואה: עם נקודות פרופורציונליות ליתרה ויתרה של 10,000 מול 100 (הפרש פי 100) — כוח ההצבעה שונה פי √100 = 10, לא פי 100. זה טוב משמעותית מהשיטה המשוקללת הרגילה.

QV עם ייצוג (Delegated QV)

משתתף יכול להאציל את הנקודות שלו למשתתף אחר. הנציג מצביע עם מאגר נקודות, אך פונקציית השורש הריבועי מוחלת על סך הנקודות המושקעות בכל אפשרות מכל בעלים מקורי.

ניואנס חשוב: צבירת נקודות מהנציגים חייבת לשמר מידע על המקור. סיכום פשוט של נקודות במאגר הנציג מאבד את תכונת ה-QV.

// Правильная агрегация: каждый delegation entry отдельно
struct Delegation {
    address delegator;
    uint256 credits;
}

// Голосование делегата: применяет QV к каждому делегированию отдельно
function voteAsDelegate(
    uint256 roundId,
    uint256 optionId,
    Delegation[] calldata delegations
) external {
    int256 totalVotes = 0;
    for (uint i = 0; i < delegations.length; i++) {
        require(
            delegatedCredits[delegations[i].delegator][msg.sender][roundId] >= delegations[i].credits,
            "Insufficient delegated credits"
        );
        totalVotes += int256(sqrt(delegations[i].credits));
    }
    rounds[roundId].optionVotes[optionId] += totalVotes;
}

מדוע התקפת סייביל קריטית עבור QV וכיצד אנו מונעים אותה

QV נשברת לחלוטין ללא הגנת סייביל. משתתף אחד עם 100 נקודות מקבל כוח 10. מאה משתתפים עם נקודה אחת כל אחד מקבלים כוח כולל 100. על ידי פיצול זהות למספר כתובות, תוקף מכפיל את כוחו ב-√N.

Proof of Humanity

זהות ייחודית רשומה ב-Proof of Humanity או Worldcoin מקבלת הקצאת נקודה אחת. סייביל בלתי אפשרי — יצירת אלף אנשים אמיתיים אינה מעשית.

אינטגרציה דרך בדיקה על-השרשרת:

interface IProofOfHumanity {
    function isRegistered(address _submissionID) external view returns (bool);
}

contract QVWithPoH {
    IProofOfHumanity public poh;

    function registerForRound(uint256 roundId) external {
        require(poh.isRegistered(msg.sender), "Not registered in PoH");
        require(!registeredForRound[roundId][msg.sender], "Already registered");
        registeredForRound[roundId][msg.sender] = true;
        creditsBalance[roundId][msg.sender] = CREDITS_PER_ROUND;
    }
}

בעיה עם PoH: כיסוי מוגבל, רישום לוקח זמן, ניתן לערעור. עבור DAO עם קהל גלובלי — חסם כניסה.

Worldcoin World ID

פתרון יותר סקלבילי. סריקת קשתית → הוכחת ZK לייחודיות. אימות על-השרשרת דרך פרוטוקול semaphore ללא חשיפת נתונים אישיים.

import "@worldcoin/world-id-contracts/src/interfaces/IWorldID.sol";
import { ByteHasher } from "@worldcoin/world-id-contracts/src/helpers/ByteHasher.sol";

contract QVWithWorldID {
    using ByteHasher for bytes;

    IWorldID internal worldId;
    uint256 internal groupId = 1; // Orb-verified
    uint256 internal externalNullifierHash;

    function registerWithWorldID(
        address signal,
        uint256 root,
        uint256 nullifierHash,
        uint256[8] calldata proof
    ) external {
        // Верифицирует ZK proof уникальности
        worldId.verifyProof(
            root,
            groupId,
            abi.encodePacked(signal).hashToField(),
            nullifierHash,
            externalNullifierHash,
            proof
        );
        require(!nullifierUsed[nullifierHash], "Already registered");
        nullifierUsed[nullifierHash] = true;
        // выдать кредиты
    }
}

אנטי-סייביל מבוסס הימור (Stake)

עבור DAOs מוכווני DeFi: דרישה להימור אסימונים כדי להשתתף. יצירת חשבונות סייביל רבים הופכת ליקרה. שילוב עם QV: ההימור קובע נקודות בסיס, אך כוח ההצבעה הוא עדיין √ של המושקע.

ארכיטקטורת מערכת מלאה

רכיבים על-השרשרת

• QuadraticVoting.sol: חוזה ליבה עם נקודות ולוגיקת הצבעה
• IdentityRegistry.sol: מקשר כתובות לזהויות מאומתות (PoH/Worldcoin)
• VotingRoundFactory.sol: יוצר סבבים עם פרמטרים (משך, אפשרויות, הקצאת נקודות)

רכיבים מחוץ לשרשרת

אינטגרציית Snapshot: רוב ה-DAOs משתמשים ב-Snapshot להצבעת QV מחוץ לשרשרת — חינם וללא הגבלת משתתפים. Snapshot תומך באסטרטגיית QV.

מחשבון תוצאות: שירות מחוץ לשרשרת לחישובי QF מורכבים, עם פרסום על-השרשרת לאחר מכן.

חזית (Frontend): ממשק שבו המשתתף רואה את תקציב הנקודות שלו, מחוונים לחלוקה בין אפשרויות, תצוגה מקדימה חיה של כוח ההצבעה לכל החלטה.

מגבלות ומבט כנה

QV אינה פותרת את כל בעיות הממשל. נקודות חלשות:

• קשירת קשר (Collusion): קבוצת משתתפים יכולה לתאם חלוקת נקודות כדי למקסם השפעה כוללת. זה קשה יותר מאשר בהצבעה רגילה אך לא בלתי אפשרי. MACI (Minimum Anti-Collusion Infrastructure) מטפל בכך עם קריפטוגרפיית ZK.
• בורות רציונלית: רוב המשתתפים לא ישקיעו זמן בלימוד 20 הצעות בסבב. QV מפחיתה את עלות הבורות אך לא מבטלת אותה.
• אסטרטגיה אופטימלית: האסטרטגיה האופטימלית מתמטית עבור משתתף אינה ברורה. זה עשוי להפחית השתתפות מחברים לא טכניים.

QV מתאימה יותר לקבוצות אפשרויות מוגבלות (בחירת עדיפויות, חלוקת מענקים) מאשר להחלטות פרוטוקול בינאריות של כן/לא.

מה כלול בעבודה

• ביקורת מבנה הממשל הנוכחי והגדרת הבעיה
• עיצוב ארכיטקטורת חוזים חכמים (Solidity/Foundry או Rust/Anchor)
• יישום חוזי QV ליבה עם נקודות קול וספירה ריבועית
• אינטגרציית הגנת סייביל (PoH, Worldcoin, או מבוסס הימור)
• פיתוח חזית (React/viem/RainbowKit) עם ויזואליזציית השפעה
• בדיקות יחידה ואינטגרציה (Foundry/Tenderly)
• פריסה והגדרת סבב הצבעה
• תיעוד משתמש ומנהל
• תמיכה לאחר שחרור למשך חודש

כיצד אנו מפתחים מערכת הצבעה ריבועית: שלב אחר שלב

1. אנליטיקה (2-3 ימים): סקירת תהליכים קיימים, זיהוי נקודות כאב ודרישות הצבעה.
2. עיצוב (3-5 ימים): יצירת ארכיטקטורת חוזים חכמים, בחירת שיטות הגנת סייביל ופלטפורמה.
3. פיתוח (14-30 ימים): כתיבת חוזי Solidity, אינטגרציית PoH/Worldcoin, פיתוח חזית.
4. בדיקות (5-7 ימים): הרצת בדיקות יחידה ואינטגרציה, שימוש ב-Slither ו-Mythril לניתוח סטטי.
5. פריסה (1-2 ימים): פריסת חוזים ל-mainnet, הגדרת סבב הצבעה.
6. תמיכה לאחר שחרור: חודש ניטור ותיקונים.

ציר זמן: מ-3 שבועות (QV בסיסית ללא אנטי-סייביל) עד 12 שבועות (מוצר מלא עם PoH/Worldcoin וייצוג). העלות מחושבת באופן פרטני — השקעה בהצבעה הוגנת מחזירה את עצמה דרך הפחתת קונפליקטים והגברת פעילות הקהילה.

קבלו ייעוץ על יישום הצבעה ריבועית ב-DAO שלכם. המהנדסים שלנו יציעו את הפתרון האופטימלי למשימות שלכם. צרו קשר כדי לדון בפרטים.