צוות הפיתוח של כספא פרסם לאחרונה את טיוטת גרסה 0.0.1 של מפרט פרוטוקול vProg, כצעד נוסף בהתקדמות הטכנולוגית של הרשת. מדובר במסמך חדשני שמטרתו להניח את היסודות ליכולת חיבור סינכרונית מתקדמת בין תוכניות ריבוניות, תוך שימוש בגישה קריפטוגרפית חדשנית המבוססת על zk (Zero-Knowledge proofs).
מהו פרוטוקול vProg?
פרוטוקול vProg מתאר מנגנון חדשני שמאפשר לתוכניות ריבוניות, מערכות עצמאיות הנבנות על גבי כספא, לתקשר ביניהן באופן מאובטח וסינכרוני. הליבה של השיטה מבוססת על ביצוע מדוד באתר (Measured On-Site Execution), שמבטיח כי החישובים ניתנים לאימות בצורה אובייקטיבית ושקופה.
למה זה חשוב?
- יכולת פעולה הדדית (Interoperability) – vProg פותח את הדלת לחיבור בין פרויקטים שונים באקו סיסטם של כספא בצורה חלקה ובטוחה.
- אבטחה מוגברת – הודות ל־Zero-Knowledge, ניתן לאמת תהליכים מבלי לחשוף מידע רגיש.
- חדשנות טכנולוגית – מפרט זה מציב את Kaspa בחזית הפיתוח של פרוטוקולים מתקדמים בעולם הבלוקצ’יין.
פתוח לעיון הציבור
המסמך המלא של טיוטת המפרט פתוח כעת לעיון הציבור, מתוך מטרה לשתף את הקהילה בתהליך הפיתוח ולעודד הערות, ביקורות ורעיונות לשיפור.
הגישה הזו משקפת את הרוח הקהילתית של כספא, שקיפות, שיתוף פעולה, וחדשנות מונעת-קהילה.
לצפייה במסמך לחצו כאן
מידע נוסף
הפרסום המקורי שנכתב על ידי מיכאל סאטון בתרגום לעברית
(קישור לפוסט המקורי ב טוויטר)
בריינדאמפ/זרם תודעה על הארכיטקטורה והרעיונות מאחורי ויפרוגס (vProgs), על המוטיבציה ועל האיך, על הדרכים שלא הלכנו בהם והשבילים שכן טיפסנו בהם (ותמונות בונוס למיטיבי לכת)
עולם הדיפיי מלא בארכיטקטורות שונות לחוזים חכמים. רשתות מובילות כמו אית'ריום וסולנה קיבלו החלטות ארכיטקטוניות מכריעות בזמנים קדומים יחסית ובחרו בטריידאופים שונים. במקביל התפתחה בעולם מדעי המחשב חיתוך קריפטו טכנולוגיה קריפטוגרפית מרתקת שנקראת הוכחות אפס-ידע (zk). הטכנולוגיה הזו התפתחה גם באופן תיאורטי וגם באופן פרקטי (applied research/high performance), ובשנים האחרונות החזון ליצירת הוכחות אפס ידע (הידועות בהקשר שלנו גם בשם הוכחות וולידיות) במהירות רלוונטית לזמן אמת הולך ומתגשם. אגב, מלבד האקדמיה וחברות כמו starkware, הרבה מהקרדיט על התפתחות האקוסיסטם העצום הזה מגיע לקהילת אית'ריום המורחבת.
כספא כיום נמצאת בפוזיציה מיוחדת ביחס לחוזים חכמים (או במונחים היותר רחבים programmability/expressiveness). אנחנו L1 שנמצא בתנופה קדימה ופתר בעיות מהות ביחס לקיבולת (data throughput; currently 1mb ~ 3k txs per sec) ומהירות (בעודו שומר על ביזור ובטיחות). בנוסף אנחנו עדיין לא מחוייבים ארכיטקטונית להחלטות קודמות בנושא (legacy tech debts). זה מאפשר לנו את היומרה ללמוד מכל הטריידאופים השונים של אחרים, לחבר את זה עם טכנולוגיית אפס הידע המתפתחת ואמביציה של טבעת מול העיניים, ולנסות לבנות ארכיטקטורה שמנסה, וכנראה מצליחה, לרקוד על כל החתונות.
נתחיל מהשאלות הבסיסיות. למה לא חוזים חכמים בשכבת הבסיס? כי בקיבולת גבוהה זה גורר סנטרליות (=סולנה; דרישות חומרה עצומות), ובקיבולת נמוכה (=אית'ריום L1) זה פשוט לא כספא. בנוסף מנקודת מבטי אני מאמין בשכבת בסיס שמתמקדת בתפקיד המהותי שלה: סידור סופר מהיר בקונצנזוס עולמי (world-wide) של אלפי טרנזקציות/רשומות בשניה תוך שמירה על מינימליזם חישובי (התמקדות בתקינות מבנית של בלוקים ובווידוא חתימות, או אולי גם, ווידוא הוכחות וולידיות/אפס ידע). בעבר השתמשתי במונח "שמירה על האתוס של סאטושי" בהקשר הזה. אולי אתוס זו לא המילה הנכונה, אבל בהחלט מדובר בסגנון/החלטה ארכיטקטונית מהותית של הפרדת רשויות ונקיות תכנונית שגם מפחיתה את משטח התקיפה (attack surface) של שכבת הבסיס.
עוד דרך להסתכל על זה היא דרך הפריזמה של טכנולוגיית אפס ידע. לחסרי רקע בקצרה: הטכנולוגיה מאפשרת לוודא את תקינות הריצה של חישוב ארוך בעזרת הוכחה מינמלית ומכווצת (succinct). הטכנולוגיה הזו בהכרח פותרת בעיית מהות במערכות קונצנזוס. היא מאפשרת לעשרות אלפי-עד-אינסוף (n -> \inf) המשתתפים במערכת הקונצנזוס לוודא את תקינות החישוב הארוך בעזרת חישוב קצר באורך קבוע או לוגריתמי, כאשר רק המוכיח נדרש לחישוב הארוך (כפול קבוע משמעותי שנדרש ליצירת ההוכחה). זה דרמטי, ומנקודת מבטי אין מנוס מהקביעה שמערכת קונצנזוס תכנותית (programmable) שלא משתמשת באפס ידע היא בהכרח פחותה (inferior) ולא הולמת למערכת חוזים חכמים מודרנית שמפותחת ברבע השני של המאה הנוכחית [https://x.com/michaelsuttonil/status/1926391070419493182]
אוקיי אז התקבענו על אבני בניין ואקסיומות בסיסיות. (i) שכבת בסיס שיודעת לסדר מהר והרבה. (ii) אפס ידע. זה הוביל אותנו מיד (=לפני כשנה; בתחילת המאמץ התכנוני) לאיזור של רולאפים מבוססים (based rollups בשפת אית'ריום). השילוב הזה משאיר את הכוח הסידורי וזמינות הדאטה (sequencing and data availability) בידי שכבת הבסיס ומשאיר "רק" את החישוב עבור השכבות מעל. זה אומר שהשכבות השניות יורשות את הבטיחות והביזור (=e.g. censorship resistance) מהסידור והזמינות שמספקת שכבת הבסיס, ואת החישוב הן מוכיחות לה בעזרת אפס ידע (settlement). מה שיוצר מערכת שגם ממקסמת את תכונות הקיבולת הגבוהה של כספא מבחינת דאטה, וגם נמנעת מעומס חישובי וסטייט מורכב בשכבת הבסיס. האם הגענו אל המנוחה ואל הנחלה? עדיין לא. (אבל שימו לב שויפרוגס לא סוטה מהאקסיומות האלו)
נתחיל את הפרק הזה במסע בשאלה אולי מתבקשת. למה לא רולאפ יחיד (aka one fat L2). כלומר למה לא מערכת L2 יחידה וקנונית שמריצה ומוכיחה את כל הטרנזקציות שמסודרות ומוגשות לה על ידי שכבת הבסיס כמקשה אחת. את הפרדת הרשויות והנקיות הרווחנו. אנחנו מונעים משכבת הבסיס את הצורך להריץ ולשמור את מרחב הסטייט של החוזים החכמים. גם אתם זעים באי נוחות? התשובה המרכזית מבחינתי היא שעדיין כל משתתפי L2 שרוצים לעקוב אחרי הסטייט (ובשונה מהמוודאים של L1 לא יכולים להסתפק ב state commitment מכווץ) צריכים להריץ את כל המכונה הבומבסטית הזו על כל חישוביה (או לחילופין לקבל את הסטייט + הוכחות ממשתתפים אחרים, דבר שהוא לא תמיד יותר זול מחישוב מקומי).
למיטב הבנתי אית'ריום הולכת לכיוון הזה ב L1 כדי לאפשר צמתים רזים שרק צריכים לוודא הוכחות אפס ידע בלי להריץ חישובים בעצמם, אבל זה לא מייתר את כל האקוסיסטם המודולורי של רולאפים שהתפתח מעל אית'ריום. עוד דחייה (rejection) לאפשרות הזו זאת אי המודולריות שלו. הוא מקבע את כספא סביב פיתרון קנוני ופלטפורמת חוזים חכמים ספציפית. מהמשקפיים (lens) של ארכיטקט תוכנה, זה קיבעון מיותר שנראה שאפשר להימנע ממנו בעידן אפס הידע שאינהרנטית מאפשר מודולוריות של קופסאות שחורות. מהמשקפיים של מתכנני פלטפורמה פיננסית, זה מונע את ההתפתחות של ישויות אלטרואיסטיות/ ממוקדות-רווח (for profit) עצמאיות שמפתחות ויוצרות אקוסיסטם פורח.
שימו לב, מה שכן היינו מרוויחים מהאפשרות הזו זאת קומפוסביליות סינכרונית ואטומית מלאה בין חוזים חכמים (כי כולם חלק ממערכת אחת שמנה). עוד נחזור לנושא הזה.
החלופה הבאה והמתבקשת לדיון היא מספר (קבוע) כלשהו של רולאפים מבוססים. כאשר כל רולאפ בוחר לו תשתית חוזים חכמים ואפס ידע/+רשת מוכיחים מסויימת ומתכנן לעצמו את הברית (settlement covenant) בשכבת הבסיס דרך תשתית קנונית ייעודית ב L1 שמאפשרת את זה עם גמישות תכנונית מקסימלית (עיין ערך פוסטים ב kaspa research, למשל https://research.kas.pa/t/on-the-design-of-based-zk-rollups-over-kaspas-utxo-based-dag-consensus/208). פה אנחנו כבר אכן מתקרבים לויפרוגס. קונספטואלית יש פה רצף אפשרי במרחב התכנון (design space) שמייצג את המתח בין ריבונות ובין קומפוסביליות סינכרונית (synchronous composability=syncompo).
קומפוסביליות סינכרונית. syncompo זאת תכונה אידיאלית עבור מערכת קונצנזוס פיננסית, שהושגה באופן טריוויאלי באית'ריום בשנותיה הראשונות (לפני שהביקוש עלה על ההיצע מבחינת קיבולת L1). התכונה היא שחוזה חכם יכול לקרוא לכל חוזה חכם אחר כחלק מאותה טרנזקציה, לבחון את התוצאה/אפשרות של פעולה מסויימת ולקבל החלטה אטומית ואחודה לגבי הפעילות הפיננסית כולה. בשפה יותר טכנית, הוא מקבל חופש פעולה מלא בתוך הסלוט (slot) שלו בתוך סידור הטרנזקציות, ובו הוא יכול לגשת לכל מקום במרחב הסטייט ולקבל החלטה בלי שדברים אחרים "משתנים לו מתחת לרגליים". באופן כללי התכונה הזו נקראת גם קומפוסביליות אטומית. אני חושב שבעולם של מסדר גלובלי יחיד, כל קומפוסביליות סינכרונית יכולה באופן טריוויאלי לממש גם אטומיות, ולכן המונח syncompo מבטא באופן נקי ומזוקק יותר את התכונה הנחשקת. כדי להבין את החשיבות הפיננסית של התכונה הזו יותר לעומק ראו "Composability — everyone’s talking about it" במאמר של @hashdag מ 2020 https://hashdag.medium.com/in-which-well-b%D0%B5-reduced-to-a-spectrum-of-gray-c259c4d25b0e ראוי לציין כאן שהאקסיומה שאיתה פתחנו את הפרק של שכבת הבסיס כמסדר יחיד, הכרחית עבור syncompo כי בלעדיה לא קיים סלוט יחיד כזה במרחב הזמן.
ריבונות. כדי להמחיש מה זאת ריבונות, נלך לקצה השמאלי ביותר שלה – רולאפים מבוססים שמתקשרים ביניהם רק באמצעות הודעות אסינכרוניות דרך שכבת הבסיס (=הודעות שדורשות submission של הוכחת וולידיות על שכבת הבסיס; בדומה לפעולת exit של כספא מ L2 ל L1 דרך גשר קנוני). המגבלה הזו מאפשרת לכל רולאפ להיות ריבון ואוטונומי לגמרי בכל מובן. טכנולוגיות ה vm ו ה zk יכולות להיות שונות לחלוטין ואפילו לא מוכרות בין הרולאפים. הם לא מוודאים אחד את השני אלא סומכים על שכבת הבסיס שתוודא הוכחות ותתן חותמת לזהות השולח של ההודעה האסינכרונית, יהיה מודל הבטיחות שלו אשר יהיה. בנוסף הרולאפ גם ריבון ועצמאי הן מבחינת ניהול הסטייט הפנימי והעומס החישובי שלו (למשל בעזרת gas commitments שנתונות לרגולציה על ידי L1) והן מבחינת היכולת שלו לספק הוכחות ל L1 עבור ה execution שלו בלי תלות באף גורם אחר (proof liveness).
מה כמובן חסר כאן בקצה הזה? syncompo. זה לא המקום להרחיב על דינמיקות פיננסיות ידועות של פרגמנטציית נוזליות. אבל על קצה המזלג, חוסר היכולת לקבל קומפוסביליות סינכרונית בין רולאפים הופך אותם למרחבים סגורים שכל אחד מהם מנסה לספח אליו כמה שיותר אפליקציות שכבר אין ביניהם משחק סכום אפס ותחרות בריאה. רוצה לומר, הדו מימדיות של המרחב (רולאפים ובתוכם אפליקציות שמתקשרות סינכרונית בתוך הרולאפ ואסינכרונית מחוץ לגבולותיו), נועלת נוזליות ומחייבת אפליקציות להישאר במרחב מסוים גם אם הדינמיקה הפיננסית הנכונה היתה לתקשר סינכרונית עם אפליקציות מחוצה לו. אפשר לדמות רולאפים לקניונים גדולים שבתוכם יש חנויות (=אפליקציות/programs) שמשלימות אחת את השניה (למשל חנות שתיה ליד חנות אוכל). המבנה הדו מימדי הזה מגביל את חנות האוכל מלעבור לקניון אחר שבו אין חנות שתיה, גם אם החשמל בו יותר זול.
אם היינו מרדדים את כל הקניונים למימד אחד של מדרחוב עירוני שבו הכל קרוב להכל, הדינמיקה הכלכלית היתה מאזנת את עצמה באופן נכון יותר לרווחת הכלל הצרכני ולטובת בעלי העסקים הקטנים שרק רוצים להתממשק אחד עם השני.
הערה על הקשר בין ריבונות למדרגיות (scalability). למצער, המונח מדרגיות כבר איבד כל משמעות וכל אחד טוען להשגתו. אני חושב שבמובן מסוים המונח ריבונות מבטא באופן נקי את היכולת לחלק (partition) את מרחב הסטייט ומרחב החישוב בין ישויות ריבוניות שונות, ובמובן הזה הוא מאפשר לדבר על מדרגיות בגודל הסטייט הגלובלי הכולל ועל מדרגיות חישובית. עוד על כך בהמשך.
אז האם קיימת ארכיטקטורה שמשיגה גם ריבונות וגם קומפוסביליות סינכרונית. אפשר הרי להרגיש את המתח ביניהם. איך אפשר להיות ריבון ועצמאי וגם לאפשר פעולה גלובלית מסונכרת ואטומית בין ישויות ריבוניות שונות?
ארכיטקטורת ה vprogs היא ארכיטקטורה שמציעה דרך להשיג את השילוב המאתגר הנ"ל. כדי להשיג זאת נדרשים שני אלמנטים משמעותיים:
- קואורדינציית L1: שכבת הבסיס צריכה לספק מנגנונים לקואורדינציה בין ישויות ריבוניות שרוצות לתקשר ביניהן באופן סינכרוני
- ריצה מקומית של תוכניות מרוחקות (on-site execution): התוכניות (the verifiable programs) נדרשות להכיר אחת את השניה באיזשהי רמה. כלומר כדי לשמר ריבונות חישובית והוכחתית (בלא נתינת אמון, trustlessly) גם בעולם שבו הטרנזקציה נוגעת וקוראת/כותבת ממספר תוכניות שונות, לא ייתכן שכל תוכנית תהיה קופסא שחורה, אלא הכרחי שכל ישות תדע לכל הפחות להריץ חישובית גם תוכניות אחרות (ובזמני חרום גם להוכיח אותם כדי לשמר את העצמאות שלה). במובן הזה אנחנו סוטים מהקצה השמאלי של ריבונות "קופסא שחורה ואטומה" מוחלטת, אבל כן מצליחים לשמר ריבונות חישובית/מצבית/הוכחתית.
קואורדינציית L1. בבסיס פרוטוקול הויפרוגס עומד מבנה גרף תלויות חישובי שמתוחזק על ידי L1 ומתפתח בזמן אמת כתוצאה של סידור הטרנזקציות. קרי מיפוי מלא של כל הקריאות והכתיבות בין טרנזקציות vprogs (ממרחב הסטייט הגלובלי שבו כל קואורדינטת דאטה מוגדרת על ידי הזוג (prog, account)). שכבת הבסיס כמובן לא מחזיקה את הדאטה שעובר דרך החישובים האלה, אלא רק מתחזקת את המטא-מבנה שלהם. הגרף הזה נקרא הדאג החישובי (Computational DAG = CD) ויש לו שני תפקידים מרכזיים. (i) הוא מאפשר ל L1 לנטר ולעשות רגולציה של העלות החישובית הכוללת של כל פעולה קומפוסבילית על כל prog שמשתתף בה (כולל ניטור של הצורך להריץ טרנזקציות קודמות של prog אחר שכתבו אל ה account אותו עכשיו הם צריכים לקרוא; which is named the computational scope in the paper); (ii) הוא מאפשר לבנות מבנה קריפטוגרפי מחייב (בעזרת hashing של מבנה הגרף והקשתות שלו), שמאפשר למוכיח של כל פרוג לעשות פעולת ריצוף (stitching) של הוכחות מותנות לפי הגרף הזה (עבור פרטים טכניים מלאים יותר תצטרכו לקרוא את המאמר עצמו שקישור אליו יובא בהמשך).
ריצה מקומית של תוכניות מרוחקות. זה מנגנון שהעלות שלו (מערכתית) היא בכך שכל המשתתפים צריכים לדעת להריץ מקומית את שאר המשתתפים (vm-wise), כמו גם דורש שכולם יכירו את כל החוזים החכמים של כולם (כולם=כל מי שהם מעוניינים ורוצים לדבר איתו סינכרונית).
הארכיטקטורה הזו יוצרת מערכת דינמית שיכולה להתכווץ ולהתפרש לפי דינמיקות זמן אמת. כלומר היא יכולה (אם נלך לקיצון) להתכווץ לנקודות חמות (hot spots) שכולם רוצים לקרוא ולכתוב אליהם ובכך להפוך את ה CD בזמן נתון למבנה תלויות sequential שבו כולם צריכים להריץ הכל (שזה למעשה מתכנס לכך ש L1 יאכוף חסם חישובי גלובלי עבור כולם = חוסר מדרגיות, לפחות זמנית). והיא יכולה לעודד מקביליות ומקסימום חוסר תלות בין חישובים בדיוק בכדי להקטין את התלויות הנ"ל.
הדינמיקה הכלכלית ומרחב קבלת ההחלטות של מוכיחים. כאן יש נקודה מעניית ביותר שממחישה את הכוח העצום של אפס ידע בזמן אמת. כדי להמחיש את הנקודה הזו נקח שתי נקודות קיצון. נניח שכל prog במערכת שולח הוכחת אפס ידע לחישובים שלו כל שעה. נניח בנוסף שכל עשר שניות בממוצע טרנזקצייה ששייכת לפרוג רנדומלי x עושה פעולה קומפוסבילית וקוראת + כותבת לפרוג רנדומלי אחר y (וכל שאר הפעולות מקומיות). בוא נתחיל את הסימולצה מהרגע שבו כולם שלחו הוכחות. הפעולה הקומפוסבילית הראשונה לא נדרשת לחישוב עמוק אחורה. למה? כי אפשר להביא עדות למצב החשבון המרוחק הנקרא בעזרת הוכחת אפס הידע של y שלפני רגע נכנסה למערכת. הפעולה הקומפוסבילית השניה (אחרי עשרים שניות) כבר תקשר ותיצור תלות בין שני פרוגים רנדומליים אחרים. למעשה כל עשר שניות אנחנו מגרילים קשת רנדומלית במרחב ה progs. קל לדמיין שאם יש למשל 100 פרוגס במערכת, תוך כמה דקות יווצרו מספיק קשרים בין כולם ואנחנו נראה פקעת.
כלומר באיזשהו שלב, הפעולה הקומפוסבילית בין שתי תוכניות תגרום לכל אחד מהם להריץ כמעט את כל הטרנזקציות שהופיעו ברשת מאז ההוכחה האחרונה (כי x צריך להריץ את y ו y היה תלוי ב z ו z ב w וכו). לעומת זאת בקצה השני נדמיין מערכת זמן אמת שבה כל מוכיח/פרוג מספק הוכחה כל עשר שניות. במקרה כזה ההוכחות המהירות יקטמו את הפקעת עוד לפני שהיא נוצרת וכל תוכנית תצטרך להריץ רק כמות קטנה (לוגריתמית) של טרנזקציות זרות (foriegn). למיטיבי לכת, האנליזה הזו קשורה באופן ישיר לתוצאה מרתקת בתיאוריה של גרפים רנדומיים שמראה שיש סף שמעליו נוצר רכיב ענק (=פקעת של תלויות), ומתחתיו כמעט בוודאות לא נוצרת פקעת. כתבתי על כך יותר בהרחבה ב https://research.kas.pa/t/zoom-in-a-formal-backbone-model-for-the-vprog-computation-dag/407#p-641-scalability-and-phase-transitions-5 ויש עוד הרבה להרחיב מעבר.
אז מה קורא כאן? התכנון הארכיטקטוני יצר מגרש משחקים, או מרחב תמרון כלכלי, שבו למוכיחים יש אינטרס לתת הוכחות בתדירות גבוהה כדי למזער את התלויות החישוביות שבתורן יאפשרו יותר קיבולת. בנוסף יש פה גם עידוד של מתכנני חוזים ליצור דינמיקות ומערכות שהן כמה שיותר מקביליות (כי גם זה ממזער את הסקופ החישובי ב CD).
זום אאוט. חזרה רגע לאנלוגיית הקניונים. עיצוב (design) הויפרוגס משטיח את המרחב למימד אחד שבו כולם אזרחים שווי זכויות וכולם יכולים לדבר עם כולם באופן סנכרוני. מהותית, הוא יוצר מערכת שבה חווית המפתח (dev ex) היא כזאת שהוא עושה deploy לחוזה חכם/prog ל L1 והאפליקציה שלו מדברת סינכרונית עם אפליקציות אחרות במרחב ה vprogs. כן, הוא יצטרך לבחור תשתית (אני מדמיין את זה כ template שמסופק על ידי ישויות infra שונות שמגדיר את ה zkvm ואת ה prover network), אבל היא תהיה חלק לא משמעותי בחוויה שלו ושל היוזרים של האפליקציה שלו. מבחינה טכנית ותשתיתית, לא מדובר בשינוי גדול ביחס למאמצי פיתוח נוכחיים של infra אבל כן מדובר בהגשה אחרת שלהם. כלומר ה design הזה מאפשר ולכאורה שואף לשבירה של מבני רולאפ מונוליטיים לטובת תבניות prog ורשתות מוכיחים שמתקשרים ביניהם.
במובן הזה החזון של פרוטוקול ה vprogs הוא שבמחיר של עלות מסויימת עבור שכבת הבסיס (בעיקר של תחזוקת ה CD), נקבל מערכת שהיא גם מודולורית מספיק (ומעודדת אקוסיסטם פיתוחי [ואגב, גם יכולת להתקדם עם טכנולוגיות האפס ידע יותר מהר, כי קל יותר לעדכן תבניות ולתת לחוזים חדשים לרוץ עליהן]), גם מאפשרת ריבונות, וגם משטחת את המרחב ומאפשרתבעזרת קומפוסביליות סינכרונית devex ו ux שנותן חוויה של native L1 programmability.
כמה הערות נוספות: – ההשראה מסולנה. אפשר לראות ב vprogs גירסה של סולנה שהיא zk-enshrined. הקרדיט לאדם שזרק אותנו בכיוון הזה מגיע ל @CryptoAspect. [באנגלית: aspect was pivotal in throwing us in the right direction, namely, borrowing from Solana's architecture]
הסיבה שהארכיטקטורה של סולנה רלוונטית יותר מאחרות היא הגישה שלה לתוכניות progs כקופסה שחורה אטומה יחסית שמתמפה באופן טבעי לסמנטיקה הנדרשת עבור ארכיטקטורת אפס ידע (progs -> verifiable progs). בסולנה זה בא לידי ביטוי למשל בכך שכל קריאה ל prpg נפרד לא מסתמכת על קומפיילר ומבנה מסוים אלא מעבירה את כל הארגומנטים דרך סריאליזציה בינארית שמוגדרת על ידי פרוטוקול ספציפי עבור התוכנית הנקראת. זאת פילוסופיה שמתייחסת לכל תוכנית כיחידת execution עצמאית שאולי קומפלה על ידי גירסה אחרת של הקומפיילר וכו ומאפשרת לנו למשל לאמץ מנגנון מאוד דומה ל CPI (cross program invocation) עבור קריאות בין vprogs
- למה לא move למשל. בתחילת המאמץ הנוכחי חשבנו ללכת בכיוון של שפת move כהשראה עבור הקומפוזיציה בין progs. בקצרה: ראינו ש move בדיוק הפוכה במובן הזה. ה API של חוזה חכם ב move יכול להיות מתוכנת באופן מסוים של העברת משאבים רק בגלל שהקומפיילר יודע שהקוראים מחוייבים לסמנטיקה שלו (ולכן למשל אי אפשר להעתיק משאב או לזרוק drop אותו). כלומר הנחות מערכתיות שמערכת vprogs לא יכולה ולא רוצה להניח.
- קרדיט גדול מגיע ל @hus_qy שעזר לנו להתכנס מהר יותר אל הכיוון של on-site execution. בשלב מוקדם יותר אני לפחות פינטזתי על מערכת של מוניטין שבה progs שונים מתקשרים ביניהם בזמן אמת כדי לקבל תוצאות חישוביות של remote calls (שמוודאות יותר מאוחר כאשר מסופקת ההוכחה שלהן). הביקורת המרכזית של Hans היתה שעלות התקשורת בזמן אמת תהיה סופר משמעותית בקצבים של אלפי TPS ושזה יהיה צוואר בקבוק משמעותי, והוא כמובן צדק.
