פיתוח חוזה חכם לתשלום מותנה

אנו מפתחים חוזי אסקרו (Escrow) הנועלים כספים ומשחררים אותם רק כאשר מתקיימים תנאים מוגדרים מראש. ללא מתווכים, שקיפות מלאה על גבי הבלוקצ'יין. עם למעלה מ-50 פרויקטים מוצלחים, אנו יודעים שהמפתח הוא בחירת מנגנון האימות הנכון ובניית הגנות מפני התקפות אופייניות. קבלו ייעוץ — נעזור לכם לקבוע את הארכיטקטורה האופטימלית לתרחיש שלכם.

תשלום מותנה הוא אסקרו משודרג. הכספים ננעלים בחוזה ומשוחררים רק כאשר מתקיימים תנאים מוגדרים מראש. זה נשמע פשוט, אבל השטן נמצא בפרטים: מי מאמת את עמידת התנאים, מה קורה במקרה של מחלוקת, כיצד החוזה יודע על אירועים מחוץ לשרשרת? השאלה האחרונה הופכת משימה זו ללא טריוויאלית — חוזה בלוקצ'יין מבודד ואינו יכול לבדוק 'המשימה הושלמה' או 'ה-KPI הושג' בעצמו. הוא זקוק לאורקל (Oracle).

מדוע תשלום מותנה דורש אורקל?

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

כיצד לבחור מנגנון אימות?

בורר (צד שלישי מהימן)

אסקרו קלאסי: קונה, מוכר, בורר. הבורר הוא כתובת עם הזכות לקרוא ל-release() או refund(). היישום הפשוט ביותר המתאים לרוב מקרי ה-B2B. בעיה: הבורר הוא מרכזי — אם זו כתובת יחידה, זהו נקודת כשל ואמון יחידה. פתרון: השתמשו ב-multisig או ב-DAO כבורר.

אורקל (Chainlink או מותאם אישית)

לתנאים שניתן להשיג על גבי השרשרת: מחיר נכס, תוצאת אירוע, נתונים על-שרשרת מפרוטוקול אחר. Chainlink AnyAPI מאפשר לבקש כל נתוני HTTP ולספק אותם לחוזה.

// Запрос данных через Chainlink Functions
function requestVerification(bytes32 jobId, string calldata apiUrl) external {
    Chainlink.Request memory req = buildChainlinkRequest(
        jobId,
        address(this),
        this.fulfill.selector
    );
    req.add("get", apiUrl);
    req.add("path", "result.completed");
    sendChainlinkRequest(req, fee);
}

function fulfill(bytes32 requestId, bool completed) external recordChainlinkFulfillment(requestId) {
    if (completed) {
        _releaseFunds();
    }
}

לתנאים מספריים פשוטים (סף מחיר) — Chainlink Price Feeds ללא אינטגרציה נוספת.

חתימת הנמען (הוכחה קריפטוגרפית)

התנאי מאושר על ידי חתימה דיגיטלית מצד מהימן. לדוגמה, מערכת תשלומים חותמת על אישור עסקה, והחוזה מאמת את החתימה באמצעות // Запрос данных через Chainlink Functions function requestVerification(bytes32 jobId, string calldata apiUrl) external { Chainlink.Request memory req = buildChainlinkRequest( jobId, address(this), this.fulfill.selector ); req.add("get", apiUrl); req.add("path", "result.completed"); sendChainlinkRequest(req, fee); } function fulfill(bytes32 requestId, bool completed) external recordChainlinkFulfillment(requestId) { if (completed) { _releaseFunds(); } } . זה עובד ללא אורקל על-שרשרת — החתימה מכילה את כל המידע הדרוש.

function releaseWithSignature(
    uint256 paymentId,
    bytes memory signature
) external {
    bytes32 hash = keccak256(abi.encodePacked(paymentId, address(this)));
    bytes32 ethHash = hash.toEthSignedMessageHash();
    address signer = ethHash.recover(signature);
    require(signer == trustedVerifier, "Invalid signature");
    _release(paymentId);
}

אימות רב-צדדי

שילוב: 2-מתוך-3 בין קונה, מוכר ובורר. כל שניים מתוך שלושה יכולים לשחרר כספים. זה מפחית את הסיכון לקנוניה בין צד אחד לבורר.

מנגנון פתרון מחלוקות

אנו מיישמים מנגנון מחלוקות עם אחסון ראיות (גיבובי IPFS בחוזה). כל צד יכול להעלות גיבוב של טענתו, והבורר (או ה-DAO) מחליט על סמך נתונים אלה. חלון המחלוקת מוגבל — לדוגמה, 7 ימים.

מבנה חוזה בסיסי

struct Payment {
    address payer;
    address payee;
    uint256 amount;
    address token; // address(0) для ETH
    uint256 deadline; // timestamp истечения
    PaymentState state; // Pending, Released, Refunded, Disputed
    bytes32 conditionHash; // хэш условия (off-chain документ)
}

enum PaymentState {
    Pending,
    Released,
    Refunded,
    Disputed
}

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

כיצד ליישם תשלום מותנה: 5 שלבים

1. ניתוח תרחיש. זיהוי משתתפים, תנאי ומנגנון אימות. לדוגמה, תשלום KPI דורש אורקל; פרילנס דורש בורר.
2. עיצוב חוזה. בחירת התבנית (בורר, אורקל, חתימה) והגדרת פרמטרים: מועד סיום, טוקן, סכום.
3. יישום. כתיבת קוד Solidity באמצעות Foundry או Hardhat. כולל בדיקות עם כיסוי של >95%.
4. ביקורת אבטחה. בדיקת reentrancy, מניפולציית אורקל, front-running. שימוש ב-Slither ו-Echidna.
5. פריסה וניטור. פריסה ל-testnet, הרצת בדיקות אינטגרציה, ולאחר מכן mainnet.

מקרים אופייניים והמאפיינים שלהם

מהניסיון שלנו:

• תשלום פרילנס. תנאי: אישור לקוח. בורר: DAO או multisig. תקופה: 14-30 ימים. מאפיינים: נדרש מנגנון מחלוקות עם אחסון ראיות.
• אופציית DeFi. תנאי: הגעה לרמת מחיר. אורקל: Chainlink Price Feed. תקופה: מועד פקיעת אופציה. מאפיינים: סיכון מניפולציית אורקל — הלוואת פלאש יכולה לשנות מחיר זמנית. פתרון: TWAP במקום מחיר ספוט. בפלטפורמת אופציות DeFi עדכנית, החלפנו אורקלי מחיר ספוט ב-Chainlink TWAP. זה הפחית את הסיכון למניפולציית מחיר ביותר מ-90% והוריד עלויות תפעול ב-30%.
• תשלום ספק עם KPI. תנאי: נתונים על-שרשרת (TVL, נפח עסקאות). אורקל: The Graph + אורקל מותאם אישית. תקופה: רבעונית. מאפיינים: נתונים מ-The Graph הם pull, לא push — החוזה מבקש אותם דרך Chainlink.
• הישגי גיימינג. תנאי: אירוע על-שרשרת בחוזה משחק. אימות: קריאה ישירה מחוזה המשחק.

כיצד להתגונן מפני התקפות?

Reentrancy בשחרור. function releaseWithSignature( uint256 paymentId, bytes memory signature ) external { bytes32 hash = keccak256(abi.encodePacked(paymentId, address(this))); bytes32 ethHash = hash.toEthSignedMessageHash(); address signer = ethHash.recover(signature); require(signer == trustedVerifier, "Invalid signature"); _release(paymentId); } מעביר ETH או טוקנים. אם הנמען הוא חוזה, הוא יכול לקרוא ל-struct Payment { address payer; address payee; uint256 amount; address token; // address(0) для ETH uint256 deadline; // timestamp истечения PaymentState state; // Pending, Released, Refunded, Disputed bytes32 conditionHash; // хэш условия (off-chain документ) } enum PaymentState { Pending, Released, Refunded, Disputed } שוב. הגנה: deadline מ-OpenZeppelin + תבנית checks-effects-interactions (שנו מצב תחילה, לאחר מכן העבר).

מניפולציית אורקל. תוקף משתמש בהלוואת פלאש כדי לתמרן את המחיר ב-DEX בבלוק אחד — האורקל קורא את המחיר המנוהל → התנאי מתקיים → כספים משוחררים. לתנאי מחיר: השתמשו רק ב-Chainlink עם TWAP, לא במחיר ספוט של DEX.

Front-running במימוש. בוטים של MEV רואים עסקת מימוש ב-mempool ומכניסים את העסקה שלהם לפניה. עבור אסקרו זה בדרך כלל לא קריטי (הנמען ידוע מראש), אך בתבניות מכירה פומבית נדרש מנגנון commit-reveal.

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

מה כלול בתוצרים

• ביקורת דרישות וחידוד לתרחיש העסקי שלכם.
• קוד מקור של חוזה חכם ב-Solidity (Foundry/Hardhat) עם בדיקות יחידה ואינטגרציה (כיסוי >95%).
• תיעוד API ודיאגרמות אינטראקציה.
• פריסה ל-testnet (Sepolia, Goerli), סבב בדיקות מלא.
• הוראות תפעול ותחזוקה.
• סקירת קוד על ידי המהנדס הבכיר שלנו (ניסיון רב בבלוקצ'יין).

אנו תומכים בפרויקטים לאחר הפריסה: ניטור, שדרוגי חוזה במידת הצורך. נבחן את הפרויקט שלכם תוך 24 שעות. צרו קשר לייעוץ. הזמינו פיתוח — נדון בפרטים. קבלו ייעוץ לקביעת הארכיטקטורה והערכת תקציב.

לוחות זמנים

לוח הזמנים המדויק נקבע לאחר ניתוח התרחיש שלכם.