מדריך למפתחים ל-zkGalaxy

זוהי היוריסטיקה שימושית ביותר להבדיל בין גישות לתמיכה ב-zkEVM. עם זאת, zkEVMs הם תת-קבוצה של כל הדרכים האפשריות לבנות יישומי אפס ידע. למתכנת שרוצה למנף את המאפיינים הייחודיים של חישוב zk, כלומר תמציתה, אפס ידע ונכונות, ייתכן ש-zkEVM אינו הבחירה הטובה ביותר. על ידי פריסת כל סט כלי המפתחים, אני מקווה לספק מדריך שיסייע בתהליך קבלת ההחלטות סביב מחסנית zk הנכונה עבור האפליקציה שלך.

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

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

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

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

Arkworks-rs היא מערכת אקולוגית של ספריות Rust המספקת יישומים יעילים ומאובטחים של רכיבי המשנה של יישום zkSNARK. Arkworks מספקת את הממשקים הדרושים למפתחים כדי להתאים אישית את ערימת התוכנה עבור יישום zk ללא צורך ביישום מחדש של מאפיינים משותפים עם ספריות קיימות אחרות.

לפני Arkworks, הדרך היחידה ליצור אפליקציית zk חדשה הייתה לבנות הכל מאפס. היתרונות העיקריים של Arkworks-rs על פני כלים שנבנו בהתאמה אישית ומשולבים אנכית הם רמת הגמישות, הפחתה בהנדסה משוכפלת והפחתה במאמץ הביקורת. קווי הממשק ההגיוניים של Arkworks בין הרכיבים מאפשרים קצב של שדרוג שיכול לשמור על הערימה רלוונטית בתוך קצב החדשנות המהולל בטכנולוגיות zk, מבלי לאלץ צוותים לבנות הכל מחדש מאפס.

Arkworks מיועדת לפרויקטים שצריכים שליטה עדינה על כל ערימת התוכנה של zk, אבל לא רוצים לבנות את כל החלקים המיותרים מאפס. אם אתה שוקל גרסה מותאמת אישית של מעגל DSL כי, למשל, אתה מייצר אב טיפוס של מערכת הוכחה חדשה אך אינך בטוח בסכימת המחויבות או העקומה האליפטית המתאימה, arkworks תאפשר לך להחליף במהירות בין מספר אפשרויות עם ממשקים משותפים, במקום זאת. מאשר להתחיל מאפס.

על מנת ליצור הוכחה לגבי חישוב כלשהו, ​​ראשית חישוב זה חייב להתבטא בצורה שמערכת zkSNARK יכולה להבין. מספר שפות ספציפיות לתחום יצרו שפות תכנות המאפשרות למפתחי אפליקציות לבטא את החישוב שלהם בצורה כזו. אלו כוללים נואר אצטקי, של סטארקנט בקהיר, Circom, ZoKrates, ושל Aleo ליאו בין היתר. מערכת ההוכחה הבסיסית והפרטים המתמטיים בדרך כלל אינם חשופים למפתח האפליקציה.

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

בקהיר - Starkware DSL הכרחי לבניית אפליקציות ב-Starknet. קומפילציה לשפת אסמבלינג ספציפית לקהיר שניתן לפרש על ידי ה-ZkVM של קהיר.

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

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

ליאו - ליאו פותחה כשפת הבלוקצ'יין של Aleo. לאריה יש תחביר דמוי חלודה והוא יוצר במיוחד עבור מעברי מצב בתוך בלוקצ'יין.

נואר - תחביר בהשראת חלודה. ארכיטקט סביב ה-IR ולא השפה עצמה, מה שאומר שיכול להיות לה חזית שרירותית. 

כל מפתח אפליקציות שרוצה לנצל את המאפיינים הייחודיים של zk באפליקציה שלו. חלק מהשפות הללו נבדקו בקרב מיליארדי דולרים שנעו עליהן דרך רשתות כמו ZCash ו-Starknet. בעוד שחלק מהפרויקטים בהם נדון אינם מוכנים לחלוטין לשימוש בייצור, כתיבת המעגלים שלך באחת מהשפות הללו היא כרגע האסטרטגיה הטובה ביותר, אלא אם כן אתה צריך את הפקדים העדינים יותר שמספקת ערכת כלים כמו Arkworks.

המטרה העיקרית של zkEVM היא לבצע מעבר מצב Ethereum ולהוכיח את תקפותו באמצעות הוכחת אפס ידע תמציתית לנכונות. כפי שהוזכר בפוסט של ויטליק, ישנן מספר דרכים לעשות זאת עם הבדלים עדינים והחלפות מתאימות. 

ההבדל הטכני העיקרי בין כל אלה הוא בדיוק היכן בערימת השפה מומר החישוב לצורה (אריתמטיזציה) שניתן להשתמש בה במערכת הוכחה. בחלק מה-zkEVMs, זה קורה בשפות ברמה גבוהה (Solidity, Vyper, Yul), בעוד שגישות אחרות מנסות להוכיח את ה-EVM עד לרמת ה-opcode. הפערים בין הגישות הללו כוסו לעומק בפוסט של ויטליק, אבל אסכם את זה במשפט אחד: ככל שההמרה/החשבון מתרחשת בערימה נמוכה יותר, כך גדל עונש הביצועים.

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

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

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

ההטמעות של zkEVM של היום משתמשות באסטרטגיות שונות כדי למתן את ההשפעה של בעיה זו... לדוגמה, zkSync קורעת את הפעולות היקרות יותר (בעיקר קומפילציות קדם קריפטוגרפיות כמו hashes ו-ECDSA) ממעגל הוכחת הביצוע הראשי למעגלים נפרדים שמצטברים יחד ב- סוף באמצעות רקורסיה של סנרק. zkSync נקטו בגישה זו לאחר שהבינו שרוב העלויות שלהם נובעות מכמה הוראות מורכבות.

בבסיס, הסיבה לכך שהוכחת מערך הוראות שווה יותר ל-EVM הוא יקר יותר היא שה-EVM לא תוכנן עבור חישובי zk. נטישת ה-EVM מוקדם יותר בערימה מאפשרת ל-zkEVMs לפעול על ערכות הוראות מותאמות יותר עבור zk, ובכך זולות יותר להוכחה.

הלקוחות האידיאליים עבור zkEVM הם יישומי חוזים חכמים שצריכים עסקאות זולות בסדרי גודל ממה שזמין ב-L1 Ethereum. למפתחים אלה אין בהכרח את המומחיות או רוחב הפס כדי לכתוב יישומי zk מאפס. לכן, הם מעדיפים לכתוב את האפליקציות שלהם בשפות ברמה גבוהה יותר שהם מכירים, כמו Solidity. 

קנה מידה של Ethereum הוא כיום היישום המבוקש ביותר של טכנולוגיית zk.

zkEVM הוא פתרון קנה המידה של Ethereum שמפחית ללא חיכוך את בעיית הגודש המגבילה מפתחי L1 dApp.

המטרה של zkEVM היא לתמוך בחוויית מפתח הקרובה ככל האפשר לפיתוח Ethereum הנוכחי. תמיכת Solidity מלאה פירושה שצוותים לא צריכים לבנות ולתחזק מספר בסיסי קוד. זה קצת לא מעשי לעשות את זה בצורה מושלמת מכיוון ש-zkEVMs צריכים להחליף תאימות כלשהי כדי להיות מסוגלים לייצר הוכחות בגודל סביר בפרק זמן סביר.

ההבדל העיקרי בין zkSync ל-Scroll הוא היכן/מתי בערימה הם מבצעים אריתמטיזציה - כלומר היכן הם ממירים מבני EVM רגילים לייצוג ידידותי ל-SNARK. עבור zkSync, זה קורה כאשר הם ממירים את קוד הביטים של YUL לסט הוראות zk מותאם אישית משלהם. עבור Scroll, זה קורה בסוף, כאשר מעקב הביצוע בפועל נוצר עם קודי EVM בפועל.

אז, עבור zkSync, הכל זהה לאינטראקציה עם ה-EVM עד שנוצר קוד byte zk. עבור Scroll, הכל זהה עד שקוד הביט בפועל מבוצע. זהו הבדל עדין, אשר מחליף ביצועים עבור תמיכה. לדוגמה, zkSync לא יתמוך בכלי EVM bytecode כמו באגים מחוץ לקופסה, מכיוון שזהו bytecode שונה לחלוטין. בעוד של-Scroll יהיה יותר קושי להוציא ביצועים טובים ממערכת הוראות, זה לא תוכנן עבור zk. יש יתרונות וחסרונות לשתי האסטרטגיות ובסופו של דבר יש הרבה גורמים אקסוגניים שישפיעו על הצלחתן היחסית.

??? למרות שמו, LLVM אינו VM (מכונה וירטואלית). LLVM הוא שם של קבוצה של כלי מהדר המעוגן על ידי ייצוג ביניים (IR) שהוא אגנוסטי לשפה.

=nil; קרן (על השם, זה א בדיחה של הזרקת SQL אם אתה תוהה) בונה מהדר שיכול להמיר כל שפת חזית LLVM לייצוג ביניים שניתן להוכיח בתוך SNARK. ה-zkLLVM מתוכנן כהרחבה לתשתית ה-LLVM הקיימת, שרשרת כלים בתקן תעשייתי התומך בשפות רבות ברמה גבוהה כמו Rust, C, C++ וכו'.

משתמש שרוצה להוכיח חישוב כלשהו פשוט יישם את החישוב הזה ב-C++. ה-zkLLVM לוקח את קוד המקור ברמה גבוהה שנתמך על ידי מהדר clang שונה שלהם (כיום C++) ומייצר ייצוג ביניים כלשהו של המעגל. בשלב זה, המעגל מוכן להוכחה, אך ייתכן שהמשתמש ירצה להוכיח את המעגל על ​​סמך כמה כניסות דינמיות. כדי לטפל בקלט דינמי, ל-zkLLVM יש רכיב נוסף המכונה המקצה, אשר יוצר טבלת הקצאה עם כל התשומות והעדים מעובדים מראש במלואם ומוכנים להוכחה לצד המעגל.

2 הרכיבים האלה הם כל מה שצריך כדי ליצור הוכחה. משתמש יכול באופן תיאורטי ליצור הוכחה בעצמו, אבל מכיוון שזו משימה חישובית מעט מיוחדת, ייתכן שהוא ירצה לשלם למישהו אחר, שיש לו את החומרה, שיעשה זאת עבורו. עבור מנגנון גילוי של צד נגדי זה, =nil; הקרן גם הקימה 'שוק הוכחה' שבו מוכיחים מתחרים כדי להוכיח חישוב עבור משתמשים שישלמו להם על כך. דינמיקה זו של השוק החופשי תוביל למוכיחים לייעל את משימות ההוכחה היקרות ביותר.

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

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

zkVM מתאר את קבוצת העל של כל המכונות הוירטואליות של zk, בעוד zkEVM הוא סוג ספציפי של zkVM, שהיה שווה לדון בו כנושא נפרד בגלל שכיחותו כיום. ישנם כמה פרויקטים אחרים שעובדים על בניית zkVMs מוכללים יותר המבוססים על ISAs מלבד ה-crypto VMs המותאמים אישית.

במקום להוכיח את ה-EVM, המערכת יכולה להוכיח ארכיטקטורת ערכת הוראות אחרת (ISA), כגון RISC-V או WASM ב-VM חדש. שני פרויקטים שעובדים על ה-zkVMs המוכללים הללו הם RISC Zero ו-zkWASM. בואו נצלול קצת ל-RISC Zero כאן כדי להדגים איך האסטרטגיה הזו עובדת וכמה מהיתרונות/חסרונות שלה. 

RISC Zero מסוגל להוכיח כל חישוב שמבוצע על ארכיטקטורת RISC-V. RISC-V הוא תקן ארכיטקטורת ערכות הוראות (ISA) בקוד פתוח שצובר פופולריות. הפילוסופיה של RISC (Reduced Instruction Set Computer) היא לבנות ערכת הוראות פשוטה ביותר עם מורכבות מינימלית. המשמעות היא שהמפתחים בשכבות הגבוהות יותר בערימה בסופו של דבר לוקחים על עצמם עומס גדול יותר בהטמעת הוראות באמצעות ארכיטקטורה זו תוך ביצוע יישום החומרה לפשוט יותר.

פילוסופיה זו חלה גם על מחשוב כללי, שבבי ARM מינפו ערכות הוראות בסגנון RISC והחלו לשלוט בשוק השבבים הניידים. מסתבר שלערכות ההוראות הפשוטות יותר יש גם יעילות גדולה יותר באנרגיה ובאזור המות.

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

מנקודת מבט של מפתחים, השימוש ב-RISC Zero לטיפול בהוכחות zk דומה בדומה לשימוש בפונקציות AWS Lambda לטיפול בארכיטקטורת שרת אחורי. מפתחים מקיימים אינטראקציה עם RISC Zero או AWS Lambda פשוט על ידי כתיבת קוד והשירות מטפל בכל המורכבות האחורית.

עבור RISC Zero, מפתחים כותבים Rust או C++ (בסופו של דבר כל דבר שמכוון ל-RISC-V). לאחר מכן המערכת לוקחת את קובץ ה-ELF שנוצר במהלך ההידור ומשתמשת בו כקוד הקלט עבור מעגל ה-VM. מפתחים פשוט קוראים ל-prove שמחזירה קבלה (המכילה את הוכחת zk של מעקב הביצוע) שכל אחד יכול לקרוא לו 'verify' מכל מקום. מנקודת מבטו של המפתח, אין צורך להבין איך zk עובד, המערכת הבסיסית מטפלת בכל המורכבות הזו.

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

לדוגמה, ניתן לעשות שימוש חוזר במעגלים של Tornado Cash עבור א אפליקציית Airdrop פרטית או אפליקציה להצבעה פרטית. Manta ו-Semaphore בונים ערכת כלים שלמה של גאדג'טים מעגלים נפוצים כמו זה, שניתן להשתמש בהם בחוזי Solidity עם מעט או ללא הבנה במתמטיקה הבסיסית של zk moon.

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

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

אני מקווה ששכנעתי אותך, מפתח התוכנה הסקרן, שתוכל להתחיל להשתמש ב-zk באפליקציות שלך עוד היום. פריצה שמחה 🙂

Disclosures: Blockchain Capital הוא משקיע בכמה מהפרוטוקולים שהוזכרו לעיל.

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