פיתוח טוקנים לא ניתנים להעברה (SBT) במפתח מלא

תארו לעצמכם: משתמש עובר KYC בפלטפורמת DeFi, מקבל תעודת NFT, ואז מוכר אותה. האימות הופך לחסר משמעות — הפלטפורמה לא יכולה לסמוך על אישורים שמועברים בחופשיות. טוקנים מקושרי נשמה (SBT) פותרים זאת על ידי קישור קבוע של מוניטין, הישגים או סטטוס משפטי לכתובת אחת. אף אחד לא יכול להעביר או למכור אותם — רק לבעלים ולמנפיק יש שליטה. עם ניסיון רב בפיתוח טוקנים מקושרי נשמה, אנו מבטיחים חוזי ERC-5192 חזקים.

הגישה הטיפוסית היא לקחת ERC-721 ולחסום העברות. אבל זה יישום נאיבי. בפועל, נדרשת תמיכה בביטול, הוכחות פרטיות באמצעות ZK-SBT, ואינטגרציה עם אורקלים לאימות סטטוס. שגיאות ארכיטקטורה מובילות לפרצות: טוקנים נתקעים לצמיתות בחוזה או שנתוני בעלים דולפים. אנו פותרים בעיות אלה בשלב התכנון באמצעות אימות פורמלי של חוזים.

כיצד ליישם ביטול SBT מבלי לפגוע במוניטין?

ביטול הוא תכונה קריטית לאימותים עם תקופות תפוגה (לדוגמה, KYC). היישום דורש מספר שלבים:

1. הגדירו את תפקיד המנפיק והוסיפו משנה onlyIssuer.
2. צרו mapping(uint256 => bool) public revoked;
3. יישמו פונקציית revoke עם בדיקות הרשאות.
4. הוסיפו פונקציית isValid שבודקת קיום, דגל ביטול ותפוגה.

mapping(uint256 => bool) public revoked;

function revoke(uint256 tokenId) external onlyIssuer {
    revoked[tokenId] = true;
    emit Revoked(tokenId);
}

function isValid(uint256 tokenId) public view returns (bool) {
    return _exists(tokenId) && !revoked[tokenId] && !_isExpired(tokenId);
}

חשוב: ביטול לא הורס את הטוקן, רק הופך אותו ללא תקף. זה שומר על היסטוריה למטרות ביקורת.

מדוע ERC-5192 הוא התקן הבסיסי ל-Soulbound?

ERC-5192 (Minimal Soulbound NFT) הוא EIP סופי המגדיר את אירוע mapping(uint256 => bool) public revoked; function revoke(uint256 tokenId) external onlyIssuer { revoked[tokenId] = true; emit Revoked(tokenId); } function isValid(uint256 tokenId) public view returns (bool) { return _exists(tokenId) && !revoked[tokenId] && !_isExpired(tokenId); } ואת פונקציית Locked. הוא תואם ל-OpenZeppelin וקל לשילוב. ERC-5192 מקצר את זמן הביקורת פי 2 בהשוואה לחוזים מותאמים אישית, מכיוון ששגיאות גישה נפוצות כבר סגורות. הנה דוגמה לחוזה:

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

interface IERC5192 {
    event Locked(uint256 tokenId);
    event Unlocked(uint256 tokenId);
    function locked(uint256 tokenId) external view returns (bool);
}

contract SoulboundToken is ERC721, IERC5192 {
    mapping(uint256 => bool) private _locked;

    function locked(uint256 tokenId) external view override returns (bool) {
        return _locked[tokenId];
    }

    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 tokenId,
        uint256 batchSize
    ) internal override {
        require(
            from == address(0) || to == address(0),
            "SBT: Token is non-transferable"
        );
        super._beforeTokenTransfer(from, to, tokenId, batchSize);
    }

    function mint(address to, uint256 tokenId) external onlyOwner {
        _locked[tokenId] = true;
        _mint(to, tokenId);
        emit Locked(tokenId);
    }
}

בהשוואה ליישום מותאם אישית, ERC-5192 מספק ממשק תקני שמפשט אינטגרציה עם ארנקים ומרקט-פלייסים. פיתוח לפי התקן עובר ביקורות עם פחות פרצות — שגיאות גישה נפוצות כבר סגורות.

השוואה בין ERC-5192 ל-ERC-721 מותאם אישית

מה כלול בפיתוח SBT Turnkey?

אנו מכינים תיעוד לחוזה החכם ומספקים גישה למאגר פרטי עם בדיקות. חוזה SBT בסיסי מ-$5,000; פיתוח מלא Turnkey מ-$15,000.

איזה מטא-דאטה לאחסן ב-SBT?

שדות טיפוסיים: מנפיק (כתובת מנפיק), תאריך (תאריך הנפקה), תפוגה (תאריך תפוגה), הוכחה (קישור אימות). לתעודות חינוכיות — courseName, grade. ל-KYC — רמת אימות. כל הנתונים מאוחסנים ב-tokenURI בפורמט JSON, נגישים רק לבעלים.

{ "issuer": "0x...",
  "date": "2023-10-01",
  "expiry": "2024-10-01",
  "type": "KYC",
  "level": "advanced" }

ZK-SBT: פרטיות על גבי Soulbound

SBT ציבוריים חושפים את כל אישורי הבעלים. לסודיות, אנו משתמשים בהוכחות אפס ידע. הבעלים מוכיח possession של SBT מסוג מסוים מבלי לחשוף את הכתובת או טוקנים אחרים. יישומים: Sismo Protocol, Polygon ID. שימוש ב-ZK-SBT מפחית את הסיכון לדליפת נתונים פי 10 בהשוואה למודל הציבורי.

Claim: "У меня есть SBT верификации KYC от Persona"
ZK Proof: доказывает факт без раскрытия адреса или других SBT

מקרי שימוש

• תעודות חינוכיות: מנפיק, תאריך, שם קורס, ציון.
• השתתפות ב-DAO: הוכחת השתתפות עם dao_address, proposal_id, vote.
• אימות KYC/AML: מנפיק (Persona, Jumio), תפוגה, רמה.
• הישגים: 1000 המשתמשים הראשונים, ספק נזילות > שנה.
• POAPs — אירועים וכנסים (טכנית ניתנים להעברה, אבל ברוחם Soulbound).

הקונספט של טוקנים מקושרי נשמה הוצע על ידי ויטליק בוטרין, גלן וייל ופוג'ה אולהבר במאמר Decentralized Society.

אנו עובדים עם פרויקטי Web3 למעלה מ-5 שנים, ויישמנו יותר מ-20 חוזים חכמים ל-DeFi, NFT ו-SBT. כל חוזה עובר אימות פורמלי (Slither, Mythril) וביקורת ל-reentrancy ועמידות ל-MEV. אנו מספקים ערבות אבטחה ל-6 חודשים לאחר הביקורת.

צרו קשר — נבחן את הפרויקט שלכם תוך יום אחד ונציע ארכיטקטורה עם אופטימיזציות גז והתאמה לעתיד. פיתוח חוזה SBT בסיסי אורך 1 עד 2 ימים; עם פרטיות וביטול — 1-2 שבועות. הזמינו פיתוח פתרון SBT היום כדי להשיג יתרון תחרותי.