מדוע הוכחות באפס ידיעה נתקעות בסכימה
פיתוח ZK-SNARK כמעט לעולם אינו נתקע בבחירת העקומה או הספרייה — הוא נתקע בסכימת האילוצים. כל פעולה אריתמטית, כל בדיקת טווח, כל גישה לזיכרון הופכות לאילוצים, ומספרם הוא שקובע את כל השאר: כמה זיכרון יצרוך ייצור המפתחות, כמה זמן ייקח ייצור ההוכחה אצל הלקוח וכמה תעלה האימות ברשת. סכימה שנבנתה "איך שיצא" עובדת בבדיקות ומתפרקת בנפחים אמיתיים.
התמונה הטיפוסית נראית כך: הלוגיקה מועברת לסכימה אחד לאחד מהקוד הרגיל, בלי פירוק לרכיבים לשימוש חוזר. הסכימה מתנפחת פי כמה, זמן ייצור ההוכחה גדל משניות לעשרות שניות, והאימות מפסיק להיכנס לגז סביר.
משם מתחיל טלאי אחר טלאי: חלק מהבדיקות מוציאים אל מחוץ לסכימה, תוך מתן אמון בנתוני הקלט — וזה כבר חור במודל האבטחה, לא אופטימיזציה.
השליטה אובדת בשלושה מקומות. הראשון — גבולות הסכימה: לא ברור מה בדיוק מוכח ומה מתקבל כאמון. השני — תקציב האילוצים: אין מספר יעד שאליו מתכנסת האופטימיזציה, ולכן אין במה למדוד את ה"שיפורים". השלישי — עלות האימות: היא נקבעת בחוזה אחרונה, כשכבר מאוחר לשנות את הארכיטקטורה.
מפרקים כיצד זה נסגר: תכנון הסכימה מזמן היעד של ייצור ההוכחה ומעלות האימות, ולא מנוחות העברת הקוד.
מה מספקת סכמת הוכחות שתוכננה כראוי
סכמה שתוכננה כראוי היא לא "מתמטיקה יפה", אלא מדדים קונקרטיים שהלקוח רואה בפרודקשן.
מספר האילוצים (constraints) במעגל האריתמטי קובע ישירות את זמן יצירת ההוכחה ואת גודל המפתחות: פירוק מוצלח של החישוב והוצאת פעולות כבדות אל מחוץ לסכמה מקצרים את המעגל פי כמה, והפרובר מתחיל לעמוד בחלון זמן צפוי במקום "תלוי במזל עם החומרה".
נושא נפרד הוא העומס על הווריפיקטור. אם אימות ההוכחה יקר, לא ניתן להטמיע אותו בזול בחוזה חכם או באפליקציית לקוח. אנחנו מתכננים את הסכמה כך שהאימות יישאר קומפקטי וזול מבחינת gas, והצד המאמת לא יגרור אחריו חישובים כבדים.
הגדרה מהימנה (trusted setup) היא המקור הנפוץ ביותר לפגיעויות נסתרות. טעות בטקס או אחסון לא מאובטח של "פסולת רעילה" מבטלים את כל מערכת ההוכחות.
אנחנו סוגרים את סוג הסיכונים הזה ברמה הארכיטקטונית: או שאנחנו משתמשים בסכמות שקופות ללא הגדרה מהימנה, או שבונים טקס רב-צדדי עם תרומות ניתנות לאימות ומפרסמים ארטיפקטים לבדיקה עצמאית.
האפקט המעשי — עלות צפויה של ההוכחה בצד המשתמש והפחתת סיכונים בצד הפרוטוקול. את הסכמה אנחנו בונים על Circom ובודקים בתרחישים אמיתיים לפני שהיא יוצאת לביקורת — כך מספר איטרציות העבודה מחדש יורד, ולא עולה לקראת השחרור.
השוואת גישות: היכן כל מצב הוכחה מתאים
בחירת מצב ההוכחה קובעת לא רק את עלות הבדיקה, אלא גם אילו דרישות אמון אתם מקבלים כבר בהתחלה. הגדרה שקופה מסירה את הטקס בהשתתפות מספר צדדים, אך דורשת סכמות שבהן הפרמטרים נגזרים מאקראיות ציבורית — אחרת האמון באתחול הופך לחלק ממודל האיומים.
סכמות אוניברסליות מספקות קו בדיקה אחד לסוגים שונים של טענות, בעוד שסכמות ייעודיות למשימה מנצחות בגודל ההוכחה ובזמן הייצור, אך כבולות ללוגיקה ספציפית.
ההפרדה בין הוכחה מחוץ לשרשרת (off-chain) לבין אימות על השרשרת (on-chain) עוסקת בשאלה היכן מתבצע החישוב והיכן מתבצעת רק הבדיקה. החלק הכבד מחושב מחוץ לרשת, ואל השרשרת עוברים הוכחה קומפקטית וקריאה למאמת; נכונותו של הגבול הזה משפיעה גם על עלות הגז וגם על מה שנכנס בפועל למצב הציבורי.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הגדרה שקופה | יש צורך בשחזור פרמטרים ללא טקס; יכולת ביקורת חשובה יותר מגודל הוכחה מינימלי | ההוכחות גדולות יותר, הייצור אורך יותר; לא כל סכמה תומכת במצב כזה |
| הגדרה מהימנה | נדרשים קומפקטיות מקסימלית ומהירות אימות על השרשרת | אמון באתחול; יש צורך בפרוטוקול טקס ובחפציו |
| סכמה אוניברסלית | מספר סוגי טענות על קו אחד, שינויים תכופים בלוגיקה | תקורה גבוהה יותר על הבדיקה בהשוואה לסכמה ייעודית |
| סכמה ייעודית למשימה | לוגיקה יציבה אחת, שבה חשובים גודל ההוכחה וזמן הייצור | השימוש החוזר מוגבל; שינוי הסכמה דורש בנייה מחדש ובדיקה חוזרת |
| הוכחה מחוץ לשרשרת | חישובים כבדים, נתוני קלט פרטיים | יש צורך בתשתית ייצור ובשליטה עליה; השהיה עד הכניסה לרשת |
| אימות על השרשרת | בדיקה ציבורית של התוצאה, אינטגרציה עם חוזים | עלות גז על האימות; מגבלות על גודל ופורמט ההוכחה |
בפועל משלבים בין המצבים: הגדרה שקופה לקווים בני ביקורת, סכמה ייעודית במקום שבו ההוכחה עוברת לשרשרת באופן קבוע. נבחן איזו קבוצה מתאימה ללוגיקה שלכם ולדרישות האמון שלכם.
שלבי פיתוח ZK-SNARK: מביקורת המשימה ועד למסירה
פיתוח ZK-SNARK אינו "לכתוב מעגל ולהרכיב", אלא רצף שבו טעות בשלב מוקדם מאפסת את כל העבודה: הצהרה שנוסחה באופן שגוי מייצרת סכימה שמוכיחה לא את מה שצריך, ואילוצים מיותרים במעגל מנפחים את זמן יצירת ההוכחה בסדר גודל. להלן המסלול שבו הולכת הצוות שלנו.
- ניתוח ההצהרה. מקבעים מה בדיוק מוכיחים ומה נשאר פרטי: אילו קלטים ציבוריים, אילו נסתרים, אילו תנאים חייבים להתקיים. בפלט — רישום פורמלי של ההצהרה ורשימת מקרי קצה שהסכימה מחויבת לסנן.
- תכנון הסכימה. בוחרים אריתמטיקת שדה, מפרקים את החישוב לאילוצים, מעריכים את מספרם. כאן גם מחליטים היכן להסתפק בלי הוכחה — כל פעולה מיותרת בתוך המעגל מכפילה את עלות היצירה.
- מימוש המעגלים. כותבים את הסכימה בשפה ייעודית שנבחרה, מכסים בבדיקות על קלטים תקינים ועל קלטים כוזבים בבירור. המטרה — שעד כוזב לא יעבור בדיקה באופן עקבי, ולא "בדרך כלל לא יעבור".
- הגדרת פרמטרים. מקיימים טקס יצירת פרמטרים מהימנים ומתארים את ההליך כך שניתן יהיה לשחזרו ולבדוק אותו באופן בלתי תלוי.
- יצירה ובדיקה של הוכחות. מודדים את זמן היצירה ואת גודל ההוכחה, בודקים את האימות בצד הצרכן — בחוזה, בבקאנד או בלקוח. אם הבדיקה אינה נכנסת למגבלות הפלטפורמה, חוזרים לשלב 2.
- ביקורת ומסירה. מוסרים את הסכימה והמעגלים לביקורת חיצונית, מתקנים את ההערות, מוסרים את המאגר, הפרמטרים, הבדיקות והתיעוד על ההצהרה והליך ההגדרה.
מסלול כזה שומר על צפיות: אתם רואים מראש את עלות ההוכחה ואת הנקודה שאליה תחזרו אם היא תפסיק להתאים. תארו את המשימה — נחזור עם הערכה לכל שלב ותוכנית עבודה.
תוצרי פלט: סכמות, מעגלים, מפתחות ותקנות
פיתוח ZK-SNARK אינו מסתיים בהדגמת אב טיפוס, אלא בסט תוצרי פלט שלפיהם ניתן להרכיב, לבדוק ולתחזק את המערכת בלעדינו. להלן מה שנשאר אצל הלקוח לאחר המסירה.
- תיאור הטענה. הצגה פורמלית של מה שהסכמה מוכיחה, עם גבולות מפורשים: אילו קלטים ציבוריים, אילו פרטיים, ואילו תנאים נחשבים להפרה. זהו מסמך שממנו יוצאים בכל שינוי לוגי.
- קוד המקור של המעגלים. קוד מקור קריא של הסכמות ומעגלי האילוצים, ולא רק תוצרי פלט מורכבים: מהם ניתן לראות כיצד הטענה מפורקת לפעולות, וניתן לתקן את הלוגיקה בלי לכתוב הכול מחדש מאפס.
- פרמטרי הגדרה. קבצי ההגדרה המהימנה והנוהל ליצירתם: מי השתתף, כיצד נבדקה התקינות, ומה יש לעשות במקרה של פגיעה. בלי שלב זה ההוכחות אינן תקפות.
- מאמת. קוד אימות ההוכחות, המוטמע במערכת שלכם — חוזה חכם או שירות — עם בדיקות להוכחות תקינות ולהוכחות כוזבות במכוון.
- סט בדיקות. וקטורים עם זוגות ייחוס של "הוכחה — תוצאת אימות", כולל מקרים שליליים: זיוף, שימוש חוזר, וחריגה מגבולות הקלט.
- תיעוד. תרשים האינטראקציה בין הרכיבים, דרישות הסביבה, סדר ההרכבה והפריסה, ומגבלות ידועות של המבנה הנבחר.
- תקנון עדכון. כללים לשינוי הסכמה: מתי נדרשת הגדרה חדשה, כיצד לשמור על תאימות של הוכחות ישנות, ומי מאשר את המעבר לגרסה חדשה.
סט כזה מאפשר להעביר את התחזוקה לצוות שלכם או לקבלן חיצוני בלי הנדסה לאחור. תארו את המשימה — נחזור עם הערכה ותוכנית לכל תוצר פלט.
קייס: איך סכימה של מיליון אילוצים הפכה לניתנת לניהול
מה היה לפני
הלקוח הגיע עם סכימת הוכחה עובדת להעברה פרטית: הלוגיקה נכונה, הבדיקות המקומיות עוברות, אבל בסביבת הייצור יצירת ההוכחה נתקלה בתקרה. הסכימה תפחה לכ-4.2 מיליון אילוצים — כל בדיקת טווח חדשה ושרשרת האש הוסיפו אריתמטיקה, לא לוגיקה.
ההוכחה נבנתה במשך 40+ שניות, בחלק ממכשירי המשתמשים התהליך קרס בגלל זיכרון, ורק כ-82% מהניסיונות הגיעו לאימות. עבור המוצר זה означало נשירה בשלב האחרון וטיפולים ידניים בתקריות.
מה שינו
המהנדסים שלנו התחילו לא מהקוד, אלא מפרופיילינג של הסכימה: הוציאו את התפלגות האילוצים לפי בלוקים וראו שכמעט שליש מהאריתמטיקה נובעת מבדיקות חוזרות שאפשר להוציא ל"שערים" משותפים ולעשות בהם שימוש חוזר.
כתבו מחדש את שרשרת האש בגרסה חסכונית יותר, חלק מהפעולות הכבדות הועברו מחוץ לסכימה, והותירו בפנים רק את מה שבאמת דורש הוכחה.
במקביל הפרידו בין המסלולים: ההוכחה והאימות קיבלו פרופילי משאבים נפרדים, ופרמטרי ההגדרה המהימנה תועדו וקובעו כך שהתוצאה תשחזר אצל הלקוח בלי "קסם".
הצעד המרכזי — סט רגרסיה של וקטורי בדיקה: כל אופטימיזציה נבדקה להתאמה של התוצאה עם הסכימה המקורית, אחרת החיסכון באילוצים היה שובר את הנכונות.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| מספר האילוצים | ~4.2 מיליון | ~1.6 מיליון |
| זמן ההוכחה | 40+ שניות | 9–11 שניות |
| שיעור האימותים המוצלחים | ~82% | ~99.6% |
הסכימה הפסיקה להיתקל בתקרת זיכרון במכשירים חלשים, הנשירה בשלב הסופי כמעט נעלמה, וזמן ההוכחה נכנס לחלון נוח למשתמש. הלקוח אישר את התוצאה על הסטנד שלו: המדדים שוחזרו ללא שינויים, וסט וקטורי בדיקת הרגרסיה עבר במלואו.
בנפרד הועבר דוח פרופיילינג ויומן אופטימיזציות — כדי שהצוות יבין איזה מרווח באילוצים נותר לפיצ'רים עתידיים.
במה שונה הגדרה מהימנה מהגדרה שקופה?
הגדרה מהימנה (trusted setup) היא שלב של יצירת פרמטרים של סכמה, שבו נוצרת כמות אקראית סודית. אם היא לא תושמד, לבעליה תהיה אפשרות לזייף הוכחות: ליצור הוכחה תקפה לטענה שקרית ואף אחד לא ישים לב לכך.
בדיוק משום כך הפרמטרים נוצרים לא על ידי אדם אחד, אלא באמצעות טקס — פרוטוקול רב-סבבי, שבו כל משתתף תורם את חלקו באקראיות ומשמיד אותו. די בכך שלפחות משתתף אחד ימחק ביושר את fragment שלו — ואז לא ניתן לשחזר את הסוד.
הסיכונים של הגדרה מהימנה אינם נעלמים לחלוטין, אלא נדחקים הצידה. נשארת שאלת האמון במארגני הטקס: כמה משתתפים בלתי תלויים היו, האם פורסמו אישורי השמדה, האם ניתן לאמת את הפרמטרים הסופיים.
ככל שיש פחות משתתפים וככל שהשקיפות של התהליך חלשה יותר, כך מחיר הטעות גבוה יותר — פגיעה בסכמה מבטלת את הערך של כל ההוכחות שנבנו עליה.
הגדרה שקופה מסירה את מחלקת הסיכונים הזו: הפרמטרים נגזרים מנתונים ציבוריים, וסוד שאפשר לאבד או לגנוב פשוט אינו קיים. המחיר של זה — גודל הוכחה גדול יותר ועומס חישובי גבוה יותר על היצירה והאימות.
הסכמה מוצדקת במקום שבו מחיר האמון גבוה ממחיר הביצועים: מרשמים ציבוריים, גשרים, מערכות הצבעה, כל תרחיש שבו הצד המאמת לא צריך לסמוך על אף אחד.
הבחירה המעשית תלויה במשימה. אם ההוכחות נבדקות בתוך מעגל סגור, והצדדים קשורים בחוזה, הגדרה מהימנה עם טקס שבוצע כראוי נותנת הוכחות קומפקטיות ומהירות. אם האימות ציבורי והצדדים אינם סומכים זה על זה, סכמה שקופה מסירה את השאלה "מה אם אצל המארגנים נשאר סוד".
אנחנו מנתחים את הבחירה הזו בשלב תכנון הסכמה — לפני שנכתבת שורת הקוד הראשונה, מפני שהחלפת סוג ההגדרה כותבת מחדש את כל שרשרת ההוכחה.
ספקות טכניים לפני תחילת העבודה
לפני תחילת העבודה כמעט כל צוות שואל את אותה קבוצת שאלות: האם סכמת ההוכחות תשתלב במוצר הנוכחי, מה לעשות עם חוזים שכבר פועלים, האם האימות יעמוד בעומס עסקאות אמיתי ומי מתחזק את הסכמה לאחר השחרור. להלן תשובות ענייניות, בלי מילים כלליות.
האם סכמת ההוכחות תואמת את הסטאק הנוכחי שלנו?
הסכמה והמאמת אינם כבולים לבלוקצ'יין מסוים — הם מהודרים עבור סביבת היעד ומתחברים כחוזה או מודול רגיל. אנו בודקים תאימות בשלב התכנון: אילו עקומות ופונקציות האש תומכת בהן הרשת שלכם, האם קיימות ספריות אימות מוכנות, והאם גודל ההוכחה נכנס במגבלות ה-gas. אם הרשת אינה תומכת בפרימיטיבים הנדרשים, נציע סכמה חלופית לפני תחילת העבודה, ולא אחריה.
מה עם מיגרציה של פתרון שכבר פרוס?
המיגרציה מתבצעת בשלבים: המאמת החדש נפרס במקביל לישן, והתעבורה מועברת לאחר בדיקה בעומס ניסויי. המצב ומפתחות האמון מועברים לפי נוהל שתואר מראש, וחזרה לגרסה הקודמת נשארת זמינה לאורך כל המעבר. אנו מתעדים נקודות אל-חזור ומחזיקים תוכנית חזרה בתיעוד.
האם האימות יעמוד בעומס אמיתי?
עלות אימות ההוכחה נמוכה בסדרי גודל מעלות החישוב עצמו, ולכן צוואר הבקבוק הוא בדרך כלל לא המאמת, אלא יצירת ההוכחות בצד הלקוח. אנו מבצעים פרופיילינג לשני החלקים על פרופיל עסקאות ריאלי, מודדים את זמן היצירה והאימות, וקובעים היכן נדרש באצ'ינג או העברת חישובים. התוצאה — תחזית תפוקה לפני ההשקה, ולא אחריה.
מי מתחזק את הסכמה לאחר השחרור?
הסכמה היא קוד ופרמטרי אמון, והם דורשים ניהול גרסאות ועדכון עם שינוי הלוגיקה. אנו מוסרים את קוד המקור של הסכמה, סקריפטי הבנייה, תיאור טקס ההגדרה והוראות עדכון. מכאן — או שהצוות שלכם מבצע תחזוקה לפי התיעוד הזה, או שאנו נשארים בתמיכה עם נוהל תגובה לאירועים.
אם אחת מהשאלות נתקלת במאפיינים הייחודיים של המוצר שלכם — תארו את המשימה, ונחזור עם הערכה ותוכנית עבודה.
נדון במשימה שלכם ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית עבודה לפיתוח ZK-SNARK, אנחנו זקוקים למינימום של נתוני פתיחה — משם המהנדסים ינתחו בעצמם את הסכמה, המגבלות וישלימו את החסר. ככל שהתרחיש מתואר בצורה מדויקת יותר, כך יהיו פחות הנחות באומדן והלוחות זמנים בתחילת הפרויקט יהיו ריאליסטיים יותר.
להתחלה מספיק:
- תיאור המשימה: מה בדיוק מוכיחים — בעלות על נתונים, נכונות חישוב, עובדה מבלי לחשוף את הסכום;
- היכן מאומתת ההוכחה: שירות נפרד, חוזה חכם, מאמת מחוץ לשרשרת;
- דרישות לפרטיות: אילו קלטים נשארים חסויים, אילו מפורסמים;
- עומס צפוי: כמה הוכחות בשנייה וזמן יצירה מותר;
- סביבת יעד: רשת, לקוחות, מגבלות משאבים של המאמת;
- מגבלות הפרויקט: לוחות זמנים, דרישות רגולטוריות, קוד וסכמות קיימים;
- מי בצד שלכם מקבל החלטות בנוגע לסכמה ומאשר את הקבלה.
זה מספיק כדי לחזור עם הערכת עומס עבודה, אפשרויות לסכמה ותוכנית עבודה לפי שלבים — מתכנון המעגלים ועד ביקורת והשקה. אם חלק מהנתונים עדיין לא מוגדרים, נתעד את ההנחות במפורש ונחדד אותן כבר בדיון הראשון.
תארו את המשימה בצורה הנוחה לכם — נחזור עם הערכה ותוכנית, ללא התחייבות מצדכם.