שלוש חברות—AWS, GCP, Azure—שולטות ב-65% משוק מחשוב הענן העולמי. הן קובעות מי מקבל גישה לתשתית, באילו מחירים, ובאילו תנאים. עבור רוב היישומים, זה מקובל. עבור הסקת AI, עיבוד גרפי, מחשוב מדעי, וכל עומס עבודה שבו מחיר, עמידות לצנזורה, או פיזור גיאוגרפי חשובים—זה לא. רשת מחשוב מבוזרת בונה שוק בין אלה שיש להם GPU/CPU פנויים לבין אלה שצריכים אותם. אנו בונים רשתות כאלה מקצה לקצה—ממודל כלכלי ועד השקת mainnet. קבלו ייעוץ על בחירת מנגנון אימות עוד היום.
האתגר הוא שבניית רשת מחשוב מבוזרת היא טכנית קשה יותר ממה שזה נראה. יש לפתור שלוש בעיות יסוד: אימות שביצוע חישוב בוצע כהלכה; הגנה מפני ספקים ולקוחות לא ישרים; ומתן ביצועים דומים לאלה של חלופות מרכזיות. צרו קשר—נעריך את הפרויקט שלכם בחינם.
כיצד לאמת חישובים ללא ביצוע חוזר?
ספק טוען שהריץ את המשימה שלכם והשיג תוצאה X. כיצד החוזה יכול לבדוק זאת מבלי לחשב מחדש? אם החוזה מחשב מחדש, אתם משלמים כפול. זו בעיית האימות המרכזית.
שלוש גישות והפשרות שלהן
ביצוע אופטימי עם תקופת ערעור. התוצאה מתקבלת כנכונה אלא אם כן יש ערעור בתוך חלון זמן (בדרך כלל 7 ימים). במקרה של ערעור, משחק אימות: שני הצדדים מצמצמים לסירוגין את המחלוקת לשלב חישוב יחיד, שמאומת על השרשרת. זו הגישה של Truebit; גרסה מותאמת משמשת ב-Arbitrum למחלוקות EVM.
פרמטרים מרכזיים: ההימור של הספק (חייב לעלות על הרווח הצפוי מרמאות), אורך חלון הערעור (פשרה בין אבטחה למהירות), מספר המאמתים במשחק. חולשה: אם לקוח וספק משתפים פעולה, או אם חלון הערעור נבחר בצורה לא נכונה עבור סוג משימה מסוים.
סביבת ביצוע מהימנה (TEE). החישוב מתרחש במבודד—Intel SGX, AMD SEV, ARM TrustZone. אימות חומרה מוכיח שקוד ספציפי בוצע בסביבה ספציפית ללא התערבות מפעיל. החוזה מאמת את הציטוט של האימות על השרשרת.
interface ITEEVerifier { // mrenclave — уникальный хэш кода в анклаве // report — подписанный Intel IAS отчёт function verifyAttestation( bytes32 mrenclave, bytes calldata report, bytes calldata signature ) external view returns (bool); } כיצד פועל אימות TEE?
המבודד יוצר ציטוט חתום, שמאומת על השרשרת באמצעות המפתח הציבורי של Intel. אם האימות עובר, החוזה בטוח שהקוד בוצע בסביבה מוגנת.משמש ב-iExec (משימות TEE), Phala Network (Phat Contracts), Marlin Protocol. חולשות: ל-Intel SGX היו מספר פגיעויות חמורות (וריאנטים של Spectre/Meltdown, SGAxe), תלות בספק החומרה, מורכבות שרשרת אספקה לאימות חומרה. TEE מהיר פי 10-50 מ-ZK בזמן אימות, אך מציע ערבויות חלשות יותר.
אימות קריפטוגרפי באמצעות הוכחות ZK. הספק מייצר הוכחת ZK שביצעו חישוב נכון על נתוני הקלט. מאמת על השרשרת בודק את ההוכחה ב-O(1) ללא קשר למורכבות החישוב. זו הגישה החזקה ביותר מבחינת ערבויות, אך היקרה ביותר מבחינת תקורה של יצירת הוכחה.
למשימות דטרמיניסטיות פשוטות (האשינג, אריתמטיקה בסיסית)—Groth16 או PLONK דרך circom. לחישובים מורכבים—zkVM (RISC Zero, SP1): הלקוח כותב תוכנית Rust, zkVM מייצר הוכחת ביצוע לכל תוכנית Rust. עלות יצירת הוכחה ב-RISC Zero: $0.01 עד $1 תלוי במורכבות המשימה, זמן 10–300 שניות.
בפועל, רוב הפרוטוקולים האחרונים משתמשים בגישה היברידית: TEE לאימות ראשוני (מהיר, זול) + ערעור אופטימי למקרים שבהם אימות TEE אינו זמין או נפגע. גישה זו מפחיתה עלות ב-30-50% לעומת סכמת ZK טהורה מבלי לאבד אבטחה.
| שיטה | מהירות | אבטחה | עלות תקורה |
|---|---|---|---|
| אופטימית | בינונית | בינונית | נמוכה |
| TEE | גבוהה | בינונית | נמוכה |
| ZK | נמוכה | גבוהה | גבוהה |
דטרמיניזם של חישובים
עבור כל שיטת אימות, החישוב חייב להיות דטרמיניסטי: קוד וקלט זהים חייבים להפיק תוצאה זהה בדיוק על כל חומרה. זה לא טריוויאלי.
בעיות: פעולות נקודה צפה מניבות תוצאות שונות על ארכיטקטורות CPU ומהדרים שונים; חישובי GPU אינם דטרמיניסטיים כברירת מחדל עקב מקביליות; ריבוי תהליכונים עם תנאי מרוץ; תלות בזמן מערכת או באקראיות.
פתרונות: חישוב ב-WebAssembly (דטרמיניסטי לפי מפרט); שימוש באריתמטיקה שלמה במקום נקודה צפה; מסגרות ML דטרמיניסטיות (זרעים קבועים, מקביליות לא דטרמיניסטית מושבתת); בידוד קונטיינרים עם סביבה קבועה (קיבוע תמונת Docker לפי SHA256).
מתי יש צורך בשכפול?
למשימות בעלות סיכון גבוה, הריצו את אותו חישוב על N ספקים ואמתו תוצאות באמצעות קונצנזוס. עם 3 ספקים וכלל רוב, הסתברות התקפה יורדת בחדות (דורש שיתוף פעולה של 2 מתוך 3).
סכמת Commitment-Reveal
ספקים מפרסמים תחילה hash של התוצאה (commitment), ולאחר שכולם הפקידו, חושפים את התוצאה. זה מונע העתקת תשובות זה מזה.
// Фаза 1: Commit function submitResultHash(bytes32 taskId, bytes32 resultHash) external { require(isTaskProvider(taskId, msg.sender), "Not assigned provider"); require(task.status == TaskStatus.Active, "Wrong status"); resultCommitments[taskId][msg.sender] = resultHash; emit ResultCommitted(taskId, msg.sender); } // Фаза 2: Reveal function revealResult(bytes32 taskId, bytes calldata result) external { bytes32 commitment = resultCommitments[taskId][msg.sender]; require(keccak256(result) == commitment, "Hash mismatch"); revealedResults[taskId][msg.sender] = result; _tryFinalize(taskId); } שכבה כלכלית
מודל הטוקן שלנו לרשת מחשוב מבוזרת כולל בדרך כלל:
| פרמטר | טווח אופייני | מטרה |
|---|---|---|
| הימור ספק | 5–100 RLC / USDC | בטחון נגד הונאה |
| קנס על הפרה | 10–50% מההימור | הרתעה |
| עמלת פרוטוקול | 1–5% | אוצר |
| עמלת מתזמן | 1–3% | שכבת התאמה |
ניואנס חשוב: הטוקן צריך לשמש לתשלום עבור חישוב (utility), לא רק לממשל. טוקני ממשל טהורים בשווקי מחשוב אינם יוצרים לחץ מספק מצד הביקוש.
זרימת עבודה מקצה לקצה
- הלקוח מעלה תמונת Docker של היישום ל-IPFS ומקבל hash תוכן.
- הלקוח יוצר משימה על השרשרת: hash יישום, hash מערך נתונים, פרמטרים, הפקדה.
- שכבת התאמה או מתזמן מקצה ספק(ים).
- הספק מוריד תמונה + נתונים, מבצע ב-TEE או בקונטיינר סטנדרטי, מייצר תוצאה + אימות/הוכחה.
- הספק מפרסם commitment על השרשרת.
- לאחר reveal וקונצנזוס, התוצאה סופית, הספק מקבל תשלום.
- הלקוח מוריד תוצאה מ-IPFS.
רכיבי רשת מחוץ לשרשרת
צומת עובד — הרכיב המרכזי עבור הספק. Daemon שמנטר את הבלוקצ'יין למשימות חדשות, מוריד ומבצע עומסי עבודה, ומפרסם תוצאות. מחסנית: Go או Rust, Docker SDK לבידוד קונטיינרים, SGX SDK למשימות TEE.
מתזמן / Core — לפרוטוקולים עם התאמה מחוץ לשרשרת. מטפל בקטלוג משימות, בחירת ספקים לפי הימור ומוניטין, ניטור פסקי זמן. ניתן לביזור באמצעות קונצנזוס BFT (קבוצת צומתי מתזמן).
אחסון תוצאות — IPFS עם pinning. הפניה ל-IPFS מאוחסנת על השרשרת. חלופה לתוצאות חסויות: תוצאה מוצפנת ב-IPFS, מפתח פענוח מועבר דרך TLS ב-TEE.
מה כלול בפיתוח מקצה לקצה
אנו מציעים מחזור מלא: מלוח לבן ועד ביקורת. תוצרים מרכזיים כוללים תיעוד ארכיטקטורה, חוזים חכמים עם קוד מקור, צומת עובד עם אינטגרציית Docker ו-TEE, סביבת בדיקות עם ספקים אמיתיים, הכשרת צוות הלקוח, ותמיכה לאחר השקה. במידת הצורך, אנו כותבים מפרטים פורמליים ומבצעים אימות פורמלי של מודולים קריטיים.
ציר זמן פיתוח והשקה
שלב עיצוב (2–3 שבועות). בחירת מנגנון אימות (TEE / אופטימי / ZK), הגדרת קטגוריות משימות, כלכלת טוקן. החלטות אלה לא ניתנות לביטול לאחר פריסה.
חוזים חכמים (6–10 שבועות). TaskRegistry, WorkerRegistry, Escrow, מודול קונצנזוס, מערכת Voucher (לחסות משימות). Foundry לבדיקות, כולל בדיקות fork עם נתוני אימות TEE אמיתיים.
צומת עובד (4–8 שבועות). Daemon ב-Go/Rust עם אינטגרציית Docker. אם TEE, אינטגרציה עם Intel DCAP attestation API. קריטי: הצומת חייב לטפל נכון בפסקי זמן, משימות תקועות, וחלוקות רשת.
בדיקות עם חומרה אמיתית (4–6 שבועות). Testnet עם צומתי עובד אמיתיים, בדיקות עומס של שכבת התאמה, אימות קנסות על עובדים לא ישרים.
ביקורת (4–8 שבועות). התמקדות בנכונות מנגנון הקונצנזוס תחת ספקים ביזנטיים, אפשרות למניפולציה במשחק הערעור, התקפות flash loan על מנגנון ההימור.
מחזור מלא מעיצוב ועד השקת mainnet לפרוטוקול MVP (מבוסס TEE, ללא ZK)—6–10 חודשים עם צוות של 3–5 מהנדסים. צירי זמן תלויים במורכבות ובצורך ב-ZK או אימות היברידי. קבלו ייעוץ—נעריך את הפרויקט שלכם ונציע מפת דרכים.