מצב הפתרונות ההדדיים של אוסף

בתור חובב מערכות אקולוגיות ממוקדות, תמיד התעניינתי בפתרונות המשפרים יכולת פעולה הדדית של רול-אפ. יתרה מכך, הסיבה היחידה שיצרתי את דוח המחקר הזה הייתה כדי לקדם בתחום זה. ואז, הבנתי שכתיבת מאמרים היא דרך מצוינת לגבש את ההבנה שלי בנושא מסוים ולעזור לאנשים להבין אותו, ועכשיו אני כאן. מסר של חשיבותה של יכולת פעולה הדדית מכיוון שכל יום בקריפטו לומד דברים חדשים, זה צריך להיראות ברור שהיום אני רואה את החזון של - בעידן שלי די מיושן. מתוך ה-POV של הפילוסופיה, אני עדיין עוקב אחר אותו חזון** - יכולת פעולה הדדית של רול-אפ היא חיונית לחלוטין לעתיד של Ethereum**, וכל המערכת האקולוגית צריכה לעבוד על פתרונות המשפרים אותה. מה-POV של הטכנולוגיה, לעומת זאת, למדתי הרבה רעיונות חדשים על הנושא הזה ושיניתי את דעתי לגבי כמה דברים. "יכולת פעולה הדדית של Rollup היא חיונית לעתיד Ethereum" כדי להבין את החומר להלן, כדאי שתהיה לך הבנה בסיסית של רכיבים ובעיית הפעולה ההדדית שלהם. אם לא, המאמר שלי היא הקדמה מצוינת. "Dr. דנקשרד או איך למדתי להפסיק לדאוג ולאהוב רולאפים" מרחבה! זה בערב של 13 בנובמבר, היום הראשון של . כמעריץ עצום של , החלטתי להשתתף ב-zkSync Connect כאירוע הראשון שלי בפסגה הזו, הראשונה בחיי. שם, פגשתי בחור, ויחד יצאנו ל"מוסיו קופי", כפי שנאמר בעמוד Luma של zkCafe. היו שניים מהם באזור הזה, ומצאנו את המקום הנכון רק לקראת הערב. Devconnect Istanbul ZkSync זה היה הרבה יותר חשוך מאשר בתמונה למעלה והיה גשם שוטף. נשארתי בקצה הגג שעליו היה מתחם האוכל ושתיתי קפה שקנינו בחינם ב- , סיפרתי לחבר החדש שלי על הרעיון שלי לפרויקט האקתון. Clave ישנם "מיני-חשבונות": חשבונות , שהלוגיקה המאמתת שלהם אינה בדיקת חתימה אלא קיומו של ה-hash של הפעולה בגשר הדואר הנכנס היחיד ב-L2 שלו. ה-hash חייב להישלח מכתובת האב שלו בשרשרת מקור ספציפית. כתובת האב היא הארנק החכם הראשי שלך בכל L2 או Ethereum L1. כדי ליצור אינטראקציה עם L2 אחר, אתה: ERC-4337 פרוס את המיני-חשבון בו והגדר את הארנק הראשי שלך ככתובת האב. כל אחד יכול לבצע את הפריסה; לפיכך, זה יכול להיות ממומן על ידי הפרוטוקול או ספק הארנק שלך. שלח את ה-hash של פעולת המשתמש שברצונך לשלוח לגשר תיבת הדואר הנכנס ב-L2 שלך והגדר את מזהה שרשרת היעד. הגיבוב הזה נצרף עם חשישים אחרים ונשלח ל-L1. החוזה החכם ב-L1 מעביר את החבילה הזו ליעד L2, וגשר תיבת הדואר הנכנס מפרק את הגיבובים כדי שחשבונות המיני יוכלו לקרוא אותם. השולח מוסיף עמלה קטנה ל-hash שלו כדי לתמרץ את יוזמי העסקאות בחוזים החכמים של הפרוטוקול. כאשר ה-hash מגיע ליעד L2, אתה שולח את פעולת המשתמש שלך ל- AA mempool ב-L2 זה. על ידי שימוש בתקן ERC-4337, איננו צריכים להטמיע מחדש את mempool המיני שלנו לחשבון וניתן לשלב את הפרוטוקול בקלות בארנקים עם בסיס קוד קיים כבר. בקיצור, התכוונתי ליצור גשר מבוסס L1 ששולח עסקאות מהארנק החכם ב-L2 שלך לכל L2 שאתה רוצה ליצור איתו אינטראקציה. בסופו של דבר כמעט יישמתי אותו בהאקתון אבל לא הצלחתי לסיים אותו בגלל ניסיון מועט ועבודה סולו. לאחר שהסביר את זה לחבר, הוא שאל אותי: למה אי אפשר פשוט לשנות את הרשת בארנק ולהשתמש בגשרי אסימונים כדי להעביר את הכספים הדרושים לרשת הדרושה? : זו בהחלט אפשרות אם משתמשים בארנק EOA. ארנקי EOA פועלים אותו דבר בכל רשתות ה-EVM וחולקים את אותה כתובת, כך שתוכל לשלוח עסקאות בכולן רק על ידי שינוי הרשת בהגדרות הארנק שלך. עניתי עם זאת, האזור עובר לחשבונות חכמים מבוססי הפשטה. חשבונות אלה מאפשרים לנו להוסיף כל פונקציונליות שאנו רוצים לארנקים שלנו באופן תוכנתי: חתימות P256 מאפשרות להשתמש כדי לחתום על עסקאות. בשבבים מאובטחים בטלפונים שלנו באמצעות התאוששות חברתית, אנו יכולים להוסיף את קרובי משפחתנו כאפוטרופוסים המורשים לשחזר את הארנקים שלנו, ולבטל ביטויי זרע לא בטוחים. טכנולוגיית Paymaster מאפשרת לנו לשלם את דמי הגז בכל אסימון או אפילו . לגרום למישהו לשלם עבורנו את העמלה כאשר מחשבים קוונטיים מתחילים לשבור סכימות חתימה קלאסיות, אנחנו יכולים פשוט לשנות את הסכימה בארנקי ה-AA שלנו לזו בטוחה לקוונטית מבלי ליצור ארנק חדש. ניתן להמשיך ברשימה זו בלי סוף, מכיוון בעצם מאפשרת לנו להשתמש בתוכנות הפעלה כרנקים מן המניין. אבל לכל זה יש מחיר: אי אפשר להעביר בקלות את הארנקים לרשת אחרת, כי מלבד העברת הכספים דרך הגשר, זה דורש פריסה מחדש של כל החשבון עם כל המפתחות, האפוטרופוסים וההגדרות. במקרים מסוימים, זה עשוי להיות מסובך מדי או אפילו בלתי אפשרי; נגיד, ב-rollups שאינם תומכים (סכימת חתימה זו עשויה להיות יקרה מדי לשימוש). שהפשטת חשבונות ב-P256 precompile זו הסיבה שעשיתי את הפרוטוקול הזה. בעיקרו של דבר, יש לך חשבונות AA בהרבה L2s. כדי לשלוח מהם עסקה, עליך לאמת את כוונתך על ידי שליחת hash שלה מהחשבון הראשי שלך ב-L2 ספציפי לאותם "מיני-חשבונות" דרך הודעות הגשר של L1. למעשה, בדרך זו, אתה לא נפטר ממספר ארנקים; אתה פשוט מעביר את כל היגיון האימות לחשבון "הורה" יחיד. פרט מעניין נוסף של פרוטוקול כזה הוא שהוא מאפשר יכולת פעולה הדדית לא רק עם L2s אלא עם כל ה-L1s (שרשרת צד) שיש להם גשרים עם Ethereum - Polygon PoS, Ronin, Gnosis ו-Avalanche הם מה שאני יכול לחשוב עליהם. עם זאת, הוא תוכנן כפרוטוקול , כך שזו רק עובדה טכנולוגית מהנה. יכולת פעולה הדדית ממוקדת בעוד שהרעיון של הפרויקט היה חכם למדי, ליישום המעשי היה חסרון משמעותי: . העיצוב כולו מסתמך על המחוברים ל-Ethereum L1. גשרי רול-אפ הם מיוחדים בכך שהם מוכיחים את מדינתם לחוזים החכמים שלהם על Ethereum כדי לרשת את הביטחון שלו. כפי שאתה אולי כבר יודע, אופטימיות ואימות ZK הן שתי הדרכים הפופולריות ביותר לעשות זאת. מהירות גשרי רול-אפ קנוניים אימות אופטימי פועל על ידי פתיחת "חלון אתגר", בדרך כלל כשבעה ימים, שבהם המתמודדים יכולים לשלוח שמצביעה על כל חלק לא חוקי באצווה העסקה. אם ההוכחה הזו תקפה, האוסף מארגן מחדש את הבלוקצ'יין שלו כדי למחוק אצווה זו. לאחר שבעה ימים ללא הוכחות הונאה, האצווה נחשבת אוטומטית לתקינה, וכל ההודעות והמשיכות מסתיימות ב-Ethereum. הוכחת הונאה כנראה שכבר הבנת את זה. בשל עיכוב של שבעה ימים בהעברת הודעות ל-L1, שליחת עסקאות צולבות שרשרת מאוסף אופטימי הוא רעיון . מַדוּעַ? ובכן, האם תחכה להחלפת ה-DEX שלך במשך שבוע? מה הולך לקרות עם המחיר עד הפעם? נורא שליחת עסקאות חוצות שרשרת האופטימי היא הרבה יותר טובה. למרות שהרצף OP Stack ממתין כמה בלוקים לפני עיבוד ההודעה כדי למזער את האפשרות של ארגון מחדש, המתנה של כמה דקות לעסקה שלך כבר מקובלת במקצת עבור כמה משימות. לאוסף יתרה מכך, קהילת Ethereum עובדת כעת על , שתגרום לכל בלוק להסתיים בנפרד, מה שהופך אותם לבלתי הפיכים עד הבלוק הבא שלהם. לאחר היישום, העברת ההודעות מ-L1 ל-L2 תימשך כ-12 שניות. סופיות של משבצת בודדת אירוח חשבונות כאלה באוסף ZK יהיה טוב יותר, אך עדיין לא שמיש במיוחד. כפי שאנו יכולים לראות מהסטטיסטיקה למטה, עידן ZKsync מסתיים בעוד 21 שעות, Linea תוך 5 שעות, בעוד 9 שעות וכו'. Starknet אבל למה זה ככה? האם יצירת הוכחה ZK אינה מהירה באשכולות רבי עוצמה? בקיצור, יש שתי בעיות: חלק מהאוסףים של ZK, כמו ZKsync Era, קובעים עיכובים בביצוע כך שלמועצת הביטחון יש זמן להחזיר כמה אצוות במקרה של באג במערכת ההוכחה שלהם. zkEVMs הם פיסות טכנולוגיה מסובכות באמת, ובשל המורכבות הזו, מניעת באגים הסתברותית על ידי שימוש במספר מערכות הוכחה בו-זמנית עדיין אינה ריאלית. למרות שאימות הוכחת ZK קל מאוד בהשוואה לחישובים שהוא מוכיח, אימותו על השרשרת הוא עדיין די יקר. בהתאם למערכת ההוכחה, זה יכול לקחת עד מיליון גז לכל אימות. אם לוקחים את מחיר הדלק הממוצע של 9 gwei ומחירי ה-ETH של היום, הוכחה בודדת עולה כ-$30 רק לאימות ב-L1. רכיבי ZK מודרניים ממזערים את ההוצאות הללו על ידי יצירת הוכחה אחת עבור אצוות רבות פעם אחת בכל פרק זמן מסוים, אך הדבר מאט את מהירות הסופיות של הגשר. יצירת אצווה והוכחה כל בלוק מרוויח $30 לבלוק או . ב-100 TPS, זה בערך 0.025 דולר לעסקה רק עבור עלויות אימות. ועלינו גם ליצור את ההוכחה ולפרסם את האצווה על השרשרת! $216,000 ליום המתנה של שעה או שעתיים לעסקה היא עדיין ארוכה מדי. מה אנחנו יכולים לעשות בנידון? קודם כל, בואו נשכח את פרויקט ההאקתון שלי בן שמונה חודשים וננסה לחסל את המודל המנטלי שכל עסקה צריכה להיות יזומה מהארנק החכם הראשי שלנו. למה אנחנו בכלל צריכים לחלוק את היגיון הארנק החכם שלנו בכל אוסף? למה שלא ניצור EOAs זמניים, נגשר על הכספים מהארנק החכם הראשי שלנו שם, נעשה איזו עבודה שאנחנו רוצים לעשות, ונגשר על מה שנשאר בחזרה? שלי (או כל ארנק חכם שאתה משתמש בו) יש חתימה מאובטחת של מובלעת והתאוששות חברתית, כך שתמיד אוכל להיות בטוח לגבי הכספים שלי שם, גם אם אאבד את הטלפון שלי. ולמי אכפת מה קורה עם החשבונות הזמניים האלה? כבר עשיתי איתם את הדברים שלי; כל הכספים נמצאים כעת ב-Clave שלי. ל-Clave עם זאת, לגישה זו יש בעיה מהותית: ההנחה שאינך יכול להשתמש באותו ארנק ברשתות אחרות על בסיס קבוע מגבילה מאוד את מספר המשימות שאתה יכול לבצע בהן. לדוגמה, אתה לא יכול: צור הפקדה בפלטפורמת מקומית מכיוון שאינך יכול להעביר אותה לרשת הראשית שלך הלוואות (עידן ZKsync במקרה זה) קבל אסימונים שאין להם מקבילה ניתנת להחלפה ברשת הראשית שלך (למשל, אם הם מוטבעים באופן מקורי ברשת זו) השתתף ב-DAO מקומי מכיוון שהקולות שלך צריכים להישאר בחשבון הזמני הזה. בעיקרו של דבר, כל מה שאתה יכול לעשות כמשתמש הוא לפזר כספים למספר נמענים מבלי לגשר בכל פעם ולקבל נזילות טובה יותר עבור החלפה לאסימון שניתן לגשר בחזרה לשרשרת הראשית שלך. לפיכך, כדי להפוך את הארנקים הללו לשימושיים, עלינו לגשת אליהם באמצעות אותם כללים שאנו משתמשים בארנקים החכמים העיקריים שלנו - מובלעות מאובטחות, התאוששות חברתית וכו'. לכן, נחזור לרעיון שלמעלה ולחוסר כדאיות שלו. עם זאת, ישנו אמצעי שיכול להעניק לחשבונות המיני האלה רק מאפייני של הארנק הראשי שלנו: פליאטיבי אפשרי שחזור אנו יוצרים את אותם מיני-חשבונות שתוארו קודם לכן אך מאפשרים מפתח אחד לשלוח מהם עסקאות ישירות. ארנק האב שלנו יכול כעת לשנות את המפתח הזה דרך הגשר מבוסס L1 או לגרום לחשבון המיני לקרוא אותו מהמצב של האב L2. בדרך זו, אם המפתח הזמני יאבד, ארנק האב יכול ליזום שינוי מפתח דרך הגשר האיטי אך האטומי מבוסס L1. אטומיות - המאפיין של פעולה שאינה מאפשרת לה להיכשל במהלך הביצוע. או שזה לא היה יזום, או שזה נעשה. גשרים מבוססי L1 הם אטומיים מכיוון שלא ניתן לאבד את ההודעה אם היא נשלחת. הזמנה, זמינות ואותנטיות מובטחות על ידי Ethereum L1. זה הרבה יותר טוב! כעת, עסקאות רגילות לוקחות זמן רק לגישור סמלי. לאחר שהאסימונים נמצאים ביעד, שליחת העסקאות היא מהירה כאילו זו השרשרת הראשית שלך. אם תאבדו את המפתח, תצטרכו להמתין בין מספר שעות לשבעה ימים, תלוי בשרשרת של ארנק האב, אך לא תשתמשו בו לעתים קרובות במיוחד, כך שההחלפה מקובלת ברוב מקרי השימוש. כמו כן, ניתן ליישם בארנקים גם היום. אפילו הכנתי , אבל הוא לא מאובטח בשום אופן או מוכן לייצור והוא נועד רק למטרות הדמיה. את היישום שלי טכניקה דומה משמשת בפלטפורמות מסחר עתידיות של Web3: אתה מאשר את האסימון בזוג (בדרך כלל USDC) לחוזה החכם ומקצה מפתח זמני להוצאה, המאוחסן בחזית הפלטפורמה. זה מאפשר למשתמשים לבצע פעולות מהירות מבלי לחתום על כל פעולה עם הארנק הראשי שלהם. אם תשנה את המכשיר שלך או תנקה את הנתונים בדפדפן שלך, תוכל פשוט להקצות מחדש את המפתח באמצעות הארנק הראשי שלך. אבל, בדיוק כמו בכל דבר בקריפטו, גם הגישה הזו אינה מושלמת. יש לו שני חסרונות: למרות שמיני-חשבונות יכולים להיות תואמי ERC-4337 ובכך לתמוך בכל התכונות שלו, כגון אצווה, מנהלי תשלום, מגבלות הוצאה וכו', תכונות אלו כבר לא עוברות בירושה מחשבון האב. למעשה, חשבון האב משמש רק כאפוטרופוס חברתי יחיד עבור החשבון המיני, אך האפוטרופוס הוא המשתמש עצמו. יש לבצע גישור אסימונים באמצעות גשרים חיצוניים. עם ייזום עסקאות צולבות, אנו יכולים לשאת את האסימונים שלנו עם המסר, ולקבל אותם כמעט 1:1 בצורה אטומית. עם זאת, עם פתרון זה, זו כבר לא אופציה, ולכן גישור חיצוני הוא האפשרות המהירה היחידה שנותרה. למרות שגשרים מודרניים , הם א) לוקחים עמלה שיכולה להיות , ב) אינם אטומיים, ואינם יורשים את מאפייני האבטחה של Ethereum. חשוב במיוחד לשים לב . יכולים להעביר כספים תוך שניות ספורות גבוהה מאוד בהעברות גדולות למאפייני האבטחה של גשרי בלוקצ'יין השימוש בגשרים חיצוניים להעברת אסימונים מקובל במידה מסוימת, בניגוד לשימוש בהם להעברת הודעות להפעלת מיני-חשבונות. הסיבה היא המקרים הגרועים ביותר שלהם, ככל הנראה עקב התקפה עליהם: הגרוע ביותר שיכול לקרות הוא שלא תקבל את האסימונים ששלחת. במקרה כזה, אתה מאבד X אסימונים שרצית לגשר ולעבור לגשר אחר. בגישור אסימונים, הגרוע ביותר שיכול לקרות הוא שניתן לגנוב את כל המיני-חשבונות שלך על ידי העברת הודעות מתחזות דרך הגשר. במקרה כזה, אתה מאבד את הארנקים שלך בכל הרשתות עם כל הערך שלהן, מלבד הראשי שלך. בהעברת הודעות חוצות-חשבונות, ככזה, הסתמכות על גשרים חיצוניים עבור גישור אסימון היא כמעט אופציה כל עוד אין דרך יעילה לגשר ביניהם בצורה אטומית באמצעות L1. זוהי למעשה האפשרות בה משתמשים משתמשים רבים המקיימים אינטראקציה עם רשתות רולאפ כיום. נניח שאנו רוצים את כל העסקאות במקום אחד, למשל, כדי להעביר אסימונים טבעיים בין חשבונות או לאמת חתימות עם קומפילציה מוקדמת ייחודית. במקרה כזה, אנו עומדים בפני הסופיות האיטית של אוסף ה-ZK של היום. נחזור קצת כדי לחשוב מה ניתן לשפר בטכניקה הקודמת. לאמת מדוע ל-Rollups יש סופיות גשר איטית? ניקח את רשימת ה-ZK כיעד מכיוון שעם אלה אופטימיים, הסיבה כבר ברורה: מערכות הוכחת ZK עבור סביבות VM מלאות הן מסובכות, במיוחד אם הסביבה אינה ידידותית ל-ZK (EVM). לכן, יש סיכוי גבוה שהם יכילו באגים. מערכות הוכחה מרובות יכולות למנוע זאת, אך הן מסובכות מאוד ליישום, ויצירת הוכחות מרובות עבור אצווה בודדת עשויה להיות איטית ויקרה מדי. כדרך לעקיפת הבעיה, צוותי רול אפ מאפשרים עיכובים בביצוע, המאפשרים להם להחזיר את השרשרת לאחור במקרה חירום. זה מה שמאט את סופיות הגשר בכמה רולאפים (למשל, עידן ZKsync). להציע את המצב החדש ו-ZK להוכיח זאת ל-L1 הן משימות די יקרות, אז כדי למזער עלויות, רצפי ה-rollup עושים זאת כל כמה שעות ולא כל בלוק. עם זאת, יש יוצא מן הכלל; , אבל א) אימות ההוכחה עדיין נעשה כל כמה שעות, כך שהוא נשאר לא מאומת, וב) Scroll הוא אחד לשימוש כיום. Scroll מציעה את המצב בערך כל דקה מהאוסףים היקרים ביותר אם ננסח את זה בצורה פשוטה יותר, הבעיות הן הוכחת עלויות ואימות עלויות. בואו נסתכל על כל בעיה ודרכים לפתור אותה. בעיקרו של דבר, המשימה שלנו היא לגרום לארנק החכם שלנו ב-Rollup לפעול במהירות עם רולאפים אחרים ללא הנחות אמון נוספות שהביאו גשרים חיצוניים. ארנקים חכמים מורכבים בדרך כלל מכמה תכונות AA רגילות - משכורות, התאוששות חברתית, מובלעות מאובטחות, מגבלות הוצאות וכו', והפעולה העיקרית שמאפשרת לנו לשלוח ממנו עסקאות בשרשרת. למה אנחנו צריכים את הפעולה העיקרית אם אנחנו רוצים להשתמש ברולאפים האחרים מהארנק שלנו? מכיוון שהוא כנראה מתארח באוסף רב-תכליתי - Arbitrum, Base, ZKsync Era - ואנחנו רוצים ליצור אינטראקציה עם משתמשים וחוזים חכמים גם באוסף הזה. במקרה הספציפי הזה, יהיה הגיוני פשוט להשתמש בגשרי אסימונים חיצוניים. פשוט החליפו את המשימה באינטראקציה למשל עם dApp באותו אוסף ועוד אחד. הרב-תכליתי הזה הוא מה שמכניס מורכבות למערכת ההוכחה של ה-rollups. אימות המצב של כל המכונה הוירטואלית עם הרבה חוזים ועסקאות חכמים שמתרחשות בכל שנייה היא משימה די גבוהה. אנו רוצים לבצע שני סוגים של משימות שדורשות קבוצה שונה לחלוטין של תכונות באוסף: עבור עסקה על שרשרת, מדובר בהכללה מהירה של L2, עמלות L2 נמוכות ופונקציונליות רחבה של VM, ועבור עסקת ריבוי רול-אפ. , זה סופיות גשר מהירה. ונבנה אוסף שיוכל להתמודד רק עם חשבונות חכמים והעברת הודעות ל-L2s האחרים? Vitalik Buterin הציע טכניקה דומה בערך בזמן של Devconnect Istanbul שנקרא "אוסף מאגר מפתחות". נדון בזה בהמשך. אבל מה אם פשוט נפטר מהמכונה הוירטואלית אוסף מפתחות הרעיון הוא ליצור אוסף ZK שיכול לאחסן רק את מפתחות החשבון ולשנות אותם באמצעות מפתח אחר. רולאפ זה דוחף את השורש של עץ מרקל המכיל את כל המפתחות הללו ל-L1. לאחר מכן, כאשר אתה רוצה לשלוח עסקה מאחד החשבונות החכמים שלך ב-L2s, אתה מייצר את הוכחת Merkle של המפתח הנוכחי שלך, והחשבון שלך מאמת אותו מול שורש מאגר המפתחות הזמין ב-L1. כעת, הוא מכיר את המפתח שלך ויכול להשתמש בו כדי לאמת את החתימות שלך. אוסף כזה הוא פשוט מאוד, וניתן ליישם בקלות מערכות הוכחה מרובות, כך שהמפתחות המאוחסנים בו הם למעשה מאובטחים כמו ה-L1. מלבד העיצוב המקורי של Vitalik, ישנם שלושה מובילים עבור אוסף מפתחות: הגישה היא לאחסן נתוני מאגר מפתחות ב-L1 אך לאפשר לעדכן אותם מאוסף zkEVM שלהם. בשביל זה, הם מציגים קומפילציה מקדימה של L1SLOAD המאפשרת קריאה זולה של אחסון L1. לאחר מכן, חשבונות AA ב-L2 אחרים יכולים לקרוא את הנתונים האלה כדי לסנכרן את התצורה שלהם - מפתחות, אפוטרופוסים וכו'. של Scroll בוחן טכניקה שבה רק שורש המצב מאוחסן ב-L1, אך תנועות מסודרות באמצעות נתוני שיחות, כך שהעץ תמיד יכול להיבנות מחדש. חשבונות ב-L2s צפויים להביא מפתחות נוכחיים באמצעות הוכחות מרקל. צוות הבסיס העיצוב דומה מאוד לזה של Base או Vitalik, אבל הוא משתמש במסגרת משלו של "מיקרו-רולאפים" עם VMs מינימליים מיוחדים. של Stackr באופן כללי, הם שונים במספר המשימות המואצלות לעיבוד מחוץ לשרשרת (במילים אחרות, כמה דברים יש ב-L2) ובפרטי היישום שלהן. אנחנו יכולים להרחיב את הרעיון הזה עוד יותר על ידי טיפול אלא גם . גם זה לא יהיה הרבה יותר קשה מבחינה חישובית; בעצם, אנחנו צריכים להתמודד רק עם המשימות האלה: לא רק במפתחות בלוגיקת החשבון החכם כולו חשבונות באוסף מאגר המפתחות חייבים להיות מסוגלים להודיע ל-L1 על כוונת העסקה שלהם. אין צורך לשמור את כל העסקה ב-L1; משהו כמו שורש של עץ מרקל עם כל הגיבובים של פעולות המשתמש יספיק. לאחר מכן, כל מה שנדרש כדי לשלוח עסקה מחשבון מיני הוא קריאת השורש מיעד L2 וביצוע הוכחה שפעולת AA מסוימת אכן התבקשה מחשבון האב. שליחת נתונים ל-L1: המשתמש חותם על ה-hash של פעולת המשתמש שהוא רוצה לבצע באוסף מסוים. מאגר המפתחות מאמת את החתימה כדי להוכיח כוונה ומוסיף את ה-hash לעץ ואז לדחוף אותו ל-L1. די בכמה סכימות חתימה, כגון , , . בדיקות חתימה: ECDSA P256 ובטוחות קוונטיות הפוך את החשבונות האחרים, שנבחרו במכוון, הנקראים "אפוטרופוסים", להצביע עבור שינוי המפתח בחשבון המשתמש. המשתמש יכול להגדיר את האפוטרופוסים והסף ולבקש מהם החלמה במקרה של אובדן מפתח. אנו יכולים גם ליישם או תוכניות אפוטרופוס חלופיות כגון , ZK-OTP או כדי להרחיב את השחזור החברתי מחוץ למשתמשי האוסף. התאוששות חברתית: שחזור מבוסס וטו ZK-Email Web Proofs במקרה שהארנק נגנב, כללי הוצאה הנשלטים על ידי אפוטרופוסים יכולים להקטין מאוד את ההפסדים הפוטנציאליים לפני שהמשתמש ישחזר את הארנק. תכונה זו מועילה גם לחיסכון כספים או, למשל, הכנת ארנקים לילדים - הורים יכולים לשלוח קצבה ולהגביל כמה ממנה ניתן להוציא כדי שהילד יוכל ללמוד לחסוך. כללי הוצאה: זה אולי נראה מיותר, אבל היכולת לאחסן קריפטו אוסף מאגר המפתחות מגדילה באופן דרמטי את האבטחה של נכסי המשתמשים על ידי אי הפרדתם למספר מיני-חשבונות. כמו כן, הוא מאפשר תכונות רבות המשפרות את חווית המשתמש: יתרות אסימונים: בתוך האוסף עשוי להציע עסקאות בחינם כדי למשוך משתמשים חדשים או לאפשר להם לשלם את העמלה עם כל אסימון ולא רק עם ETH. ניתן ליישם גם לוגיקה מסובכת יותר של Paymaster - לדוגמה, הסיקוונסר יכול לקחת תשלום מההחלפה בשרשרת אחרת כאשר הוא מגושר בחזרה לאוסף המפתחות. Paymasters: מלבד שליחת כספים מיידית בין משתמשי אוסף, העברות ישירות מועילות גם להטמעת גשרים מבוססי כוונות עם רכיבים אחרים בעלי סופיות איטית מדי כדי להשתמש ב-L1 כדי לגשר מהחשבון המיני לחשבון האב באוסף המפתחות. בדרך זו, אוסף מאגר המפתחות יכול למעשה לשמש כמרכז להעברת אסימונים בין מיני-חשבונות בעשרות L2s שונים בזול. העברות אסימונים פנימיים: מערכת כזו היא הרבה יותר פשוטה מבחינה טכנית מ-VM מלא בתוך אוסף, כך שניתן ליצור הוכחות עבור מספר מערכות הוכחה בו-זמנית, והמורכבות של הפקת ההוכחות עדיין תהיה הרבה פחות. עם זאת, אימות הוכחה הוא עדיין בעיה. כפי שחישבנו בעבר, עלות הגז שלו יכולה להגיע עד 1 מיליון גז או ~25-50$, תלוי במחיר הגז. עלות זו קבועה ואינה תלויה במספר העסקאות באצווה. המשמעות היא שאם יש מעט מדי עסקאות, העמלה עבור כל עסקה יכולה להיות גבוהה מאוד. ישנן שתי דרכים עיקריות להוזיל עלות זו: שכבה מיושרת היא EigenLayer AVS שמשתמשת באופרטורים מחדש כדי לאמת הוכחות ZK בזול. אם אינך מכיר את EigenLayer, זהו סיכום פשוט של אופן אימות ההוכחות ב-Aligned: Aligned משתמש שולח את בקשת אימות ההוכחה לרשת ומשלם את האגרה עבורה; מפעילים מיושרים, שכל אחד מהם הוא מאמת את'ריום עם ההפקדות שלהם מלוכדות, מאמתים את ההוכחה על הצמתים שלהם ומחתימים על תקפותה; כאשר 2/3 מפעילים חותמים על ההוכחה, החתימה המצטברת נשלחת ומאומתת ב-Ethereum L1. אם הוכחה לא חוקית הגיעה לסופיות, ניתן לחתוך את המאמתים שחתמו עליה על ידי אימותה בשרשרת. בדרך זו, ההוכחה מקבלת ביטחון כלכלי השווה ל-2/3 מסך ההימור של המפעילים המיושרים. לגישה זו יש חסרון ברור - Ethereum כבר לא מבטיח תוקף הוכחה. אם ה-TVL של הגשר של הרולאפ גבוה מ-2/3 מסך הימור Aligned, התקפה עליו הופכת לרווחית. ומכיוון שאנחנו מדברים על חביון סופי של 1-2 חסימות, אנחנו לא יכולים למנוע את ההתקפה בצורה אופטימית. עם זאת, זו עשויה להיות אפשרות בטוחה יחסית, כל עוד האוסף אינו גדול מדי. כשזה קורה, דרישת העסקאות כבר יכולה להפוך את אימות הוכחה L1 לכדאי. על פי המסמכים, אימות הוכחת ZK באמצעות Aligned עולה כ-3000 גז, שהוא כמעט בחינם אפילו עבור Ethereum L1. הוכחה שכבות צבירה אם לא נוח לך להכניס הנחות אמון נוספות למערכת, או שהפרוטוקול שלך כבר הפך להיות גדול מדי, אבל הדרישה שלו לעסקה לא, ישנה אלטרנטיבה. צוותי ZK ו-Rollup החלו לאחרונה לעבוד באופן פעיל על פרוטוקולי צבירה של הוכחה. אם אינך מכיר היטב את ZK, צבירת הוכחות היא כאשר הוכחת ZK מוכיחה את תקפותה של הוכחה ZK אחרת (שיכולה, בתורה, להוכיח הוכחה נוספת, וכן הלאה), ובכך "מצבירה" אותן בהוכחה היחידה בעצם להעביר את כל עלויות האימות שלהם לעלויות הוכחה. מה שנותר הוא לאמת הוכחת ZK יחידה על השרשרת ולהיות בטוח לגבי תקפותן של כל שאר ההוכחות ZK שהיא מוכיחה. פיו! אימות על שרשרת הוכחת ZK. צבירת הוכחות הגיונית כאשר עלויות האימות גבוהות יותר מהוכחת הוכחות צבירת. כלומר, הצבירה הופכת לרווחית אם עלות הפקת הוכחה לעשר הוכחות ואימותה קטנה מאימות עשר ההוכחות הללו באופן עצמאי. זה מועיל אפילו יותר ב-Ethereum L1, אשר מוגבל מאוד על ידי יכולת חישובית. בהתאם למערכת ההוכחה, הבלוק כולו יכול להכיל רק , לא כולל כל שאר הפעילויות בשרשרת. כ-100 אימותי הוכחה באופן כללי, ישנם שני סוגים של פרוטוקולי צבירת הוכחות: פרויקטים כאלה תומכים בדרך כלל בכמה מפרוטוקולי ZK הפופולריים ביותר (Groth16, Halo2, Plonky), שעליהם נבנים רוב מעגלי ה-ZK ולוקחים תשלום עבור עיבוד. ה-dApps שזקוקים להוכחות לאחר מכן חושפים את הנתונים מהפרוטוקול ומעבדים אותם בעצמם. , שנמצאת כעת בפיתוח, עושה בדיוק את זה. Aligned עובדת גם על מה שנקרא , שהיא למעשה גם מערכת צבירה הוכחה. צבירת מטרה כללית (אוניברסלית): מערכת Universal Proof Aggregation של Nebra אימות "מצב איטי" בדומה לרצף משותף באוסף אופטימי, אוסף ZK עם הערימות שלהם עובד על גשרים משותפים עם הוכחות מצב מצטברות עבור כל אוסף ZK בגשר. זה לא רק מאפשר חיבור סינכרוני בתוך הערימה א-לה רצף משותף אלא גם ממזער את העלויות לאימות הוכחה. אולי שמעתם על של Polygon או של ZKsync, שהם גשרים משותפים שעובדים על צבירה הוכחה בתוך הגשר. צבירת גשרים משותפים: AggLayer Hyperbridge היתרונות של מערכות צבירה אוניברסליות הם שהן אגנוסטיות לפרויקט ומתמחות רק בתהליך הצבירה עצמו, מה שפותח אימות די מהיר של הוכחות ועלויות נמוכות. כמו כן, סביר להניח שלא יהיו לו גלגלי אימון בגלל היעדר רכיב הגשר. גשרי אוסף מצטברים, בתורם, מועילים לאוסף מאגר המפתחות ליכולת חיבור סינכרונית עם מחסנית אוסף קיימת כבר. לדוגמה, , 13 פרויקטים נבנים כיום באמצעות Polygon CDK, ו-11 משתמשים ב-ZK Stack. כאשר כולם מתחברים לגשר צבירה הוכחה משותף, חיבור מאגר המפתחות לאחד מהם יפתח אינטראקציה חלקה עם L2s רבים מבלי לגעת אפילו ב-L1. כדי שזה יעבוד, הגשר חייב לתמוך בלוגיקת מעבר מצב שונה עבור ה-L2s שלו מכיוון שהלוגיקה של מאגר המפתחות שונה משאר ה-L2s בו. לפי L2BEAT עם זאת, גשרים אלו ניתנים לרוב לשדרוג ונשלטים על ידי ה-DAO או מועצת הביטחון שלו. ייתכן שפרויקטים של מאגר מפתחות אינם נוחים לוותר על הריבונות שלהם למפעילי הגשר שאליו הם מחוברים. כמו כן, גשרים עשויים להכניס עיכובי ביצוע כאמצעי זהירות לגלגלי אימון, בדומה לאופן שבו ZKsync Era פועל כעת, מה שבעצם הורג את כל היעילות של עיצוב מאגר המפתחות הזה. בדרך זו, אוסף מאגר מפתחות, כמו כל אוסף אוסף אחר של ZK, יכול למזער את עלויות אימות ההוכחה ואפילו לשלב זאת עם יכולת קומפוזיציה סינכרונית עם מחסנית אוסף קיימת כבר. גישור יעיל מבוסס כוונות עם אוסף של "Keystore+". כפי שצוין קודם לכן, גישור מ-L2 ל-L1 אינו הבעיה היחידה. רוב רצפי ה-Rollup מיישמים גם עיכובים להעברת הודעות מ-L1 ל-L2. הסיבה לכך היא שכאשר נוצר בלוק Ethereum, הוא עדיין לא סופי וניתן להפוך אותו בתוך ~64 הבלוקים הבאים (שני עידנים, כ-13 דקות). התארגנויות אלו מתרחשות בגלל השהיות ברשת, מה שגורם לכמה הצעות להופיע ברשת מאוחר מדי כאשר חלק מהצמתים כבר מחשיבים אותן. למרות יותר משני בלוקים , צוותי אוסף עדיין לא רוצים לקחת סיכונים הקשורים להודעות שהוחמצו ולהחיל עיכובים בגישור מ-L1. העיכובים אלה הם רק כדקה אחת בכמה רולאפים ( , ) אבל יכולים להיות עד 6 דקות, כמו ב- , או אפילו לבקש סופיות של L1, כמו ב- . שרוב הארגונים מחדש אינם עמוקים (ארגון מחדש של שבעה בלוקים אפילו הופיע בחדשות לפני שנתיים) OP Stack ZK Stack Arbitrum Linea קהילת Ethereum , שתגרום לכל בלוק להסתיים באופן עצמאי במקום פעם אחת בתקופה. אבל אנחנו יכולים לומר בוודאות שזה שיגיע ברבעון הראשון של 2025, אז תעבור לפחות שנה עד ש-SSF ייושם. עובדת באופן פעיל על Single-Slot Finality לא מתוכנן לשדרוג הבא של Pectra אם צוות המיישם את העיצוב המורחב הזה של אוסף מאגר המפתחות אינו מרגיש בנוח עם זמן אחזור עסקאות כזה, הוא יכול ליישם פתרון פליאטיבי שתואר קודם לכן. לכל מיני-חשבון יש מפתח המורשה לשלוח עסקאות או משתמש במפתח סטטי ממחסן המפתחות (לפי העיצוב המקורי של Vitalik), אך ניהול החשבון עדיין נמצא בחשבון מאגר המפתחות הראשי. לאחר הטמעת SSF ב-L1, האוסף יכול להסיר את מפתחות ההוצאה המורשים, והמשתמשים יקבלו את כל פונקציונליות ההתאמה האישית של AA ללא ירידה משמעותית במהירות. אני מסכים עם אלכס כאן; 15 שניות של חביון מקובל לחלוטין, במיוחד מכיוון שהפעולה היא אטומית לאחר סיום עסקת אוסף המפתחות ב-L1. אם אנחנו מדברים על העברות אסימונים, ארנקי נמענים יכולים אפילו ליישם סטטוס "בהמתנה" ברמת ממשק המשתמש. עם זאת, העברות אסימון צולבות עדיין מהוות בעיה. אם ניישם כספות אסימונים בתוך אוסף המפתחות, העברת האסימונים ממנו תימשך 1 עד 15 דקות, תלוי באוסף הנמענים. אם לא נעשה זאת, פיצול יתרות המשתמשים למיני-חשבונות במספר L2s יכול להוות סיכוני אבטחה ואפילו לנעול חלק מהנכסים ל-L2s לא נזילים, שגישור מהם עלול לעלות יותר מדי או לקחת יותר מדי זמן. כחלופה, אנו יכולים לשלב גשר מבוסס כוונות בתוך האוסף ולפרוס אותו בכל שאר האוסף או אפילו לעשות שימוש חוזר בתשתית קיימת, כגון פרוטוקולים תואמי . נדון בקצרה בגשרי כוונות בחלק הבא. ERC-7683 מהו גשר מבוסס כוונות? רוב הגשרים הצולבים הקיימים מבוססים על פרוטוקולי הודעות. לדוגמה, משתמשת כדי להעביר הודעות על הפקדות לרשתות היעד, תוך הסתמכות עליה כמקור האמון. כאשר אתה שולח אסימונים דרך גשרים כאלה, הם נועלים את האסימונים שלך בצד אחד ושולחים הודעה על ההפקדה שלך בצד השני, והכספת שם פותחת עבורך את כמות האסימונים המתאימה. Stargate ב-LayerZero , בתורם, אינם שולחים הודעות בין שתי רשתות. במקום זאת, כספים הנשלחים ננעלים בכספת כ"הזמנה חוצת שרשרת", ואז כל אחד יכול למלא את ההזמנה על ידי שליחת כמות האסימונים המבוקשת בשרשרת היעד. מי שימלא את ההזמנה יוכל לדרוש את האסימונים הנעולים משרשרת המקור כאשר הכספת בה מקבלת מידע על המצב הסופי של שרשרת היעד ויכול לאשר את ההעברה. גשרים מבוססי כוונות זה יכול לקרות על ידי המתנה לסופיות המטרה (גשר) של שרשרת היעד או באמצעות פרוטוקול אורקל חיצוני כלשהו. לדוגמה, כדי להביא את המצב של L2s שטרם סוכמו. Across משתמש באורקל האופטימי של UMA בתרחיש זה, Ethereum L1 משמש כמקור האמון. פרוטוקולים מסוימים, כגון Across, משתמשים במקום זאת באורקלים חיצוניים. העיצוב בפועל עשוי להיות שונה בפרויקטים קיימים; רק הרעיון הכללי מוצג. אנחנו יכולים להשתמש באותו עיצוב עבור אוסף מאגר המפתחות המורחב האלה כדי ליישם גישור דו-כיווני חסר אמון, מהיר וזול בין מאגר המפתחות לכל שאר ה-L2s. סופיות הגשר המהירה מאפשרת ה-L2s להיות כמעט בחינם מכיוון שהוכחת ההגשמה ב-L2 נמשכת דקות ספורות. להזמנות מבוססות כוונות משאר כנראה שגם הזמנות מחנות המפתחות יהיו זולות, מכיוון שניתן לספק נזילות ב-L2 מהר יחסית דרך מאגר המפתחות. בדרך זו, עיצוב אוסף מאגר מפתחות כזה יכול להפוך למרכז לגישור מבוסס כוונות, המאפשר למשתמשים לשלוח עסקאות באופן מיידי ולא תוך דקות ספורות, ולא משלמים כמעט כלום עבור גישור. צוות הרולאפ יכול גם לספק נזילות לגישור דרך מאגר המפתחות 1:1, וזה לא יעלה להם הרבה. שם ENS מאוחד לכל הרשתות תאר לעצמך שיש לך יחיד.eth שפותר לכל המיני-חשבונות שלך, לא משנה באיזו שרשרת נמצא הנמען. עיצוב זה מאפשר זאת. אֵיך? שם משתמש מכיוון שאנו כבר יודעים את הכתובת של חשבון מאגר המפתחות הראשי שלנו, אנו יכולים להשתמש וב- כדי להפוך את הכתובות של חשבונות המיני שלנו זהות בכל רשתות ה-EVM המקבילות לקוד בתים, אפילו כולל Ethereum L1. לאחר מכן, הגדרנו את הכתובת המאוחדת ב-ENS resolver, והשם שלנו עובד בכל EVM L2s. במפעלי ריבוי שרשרת CREATE2 עם זאת, ישנם שני מקרים חריגים: עבורם, נוכל ליצור כתובת מותאמת אישית לפי כללי CREATE2 שלהם ולהוסיף אותה ל-ENS עם מזהי השרשרת שלהם לפי . EVM לא שווה ערך לקוד בייט, כגון ZK Stack. ENSIP-11 ההיגיון זהה עבורם, אך במקום זאת, אנו מוסיפים את הכתובות המותאמות אישית שלהם ל-ENS לפי . לא-EVM L2s, כגון מאגר המפתחות שלנו. ENSIP-9 למרות היותה ידידותית מאוד ל-UX, גישה זו משתמשת בהרבה חישובים ואחסון יקרים ב-L1 מכיוון ששמות וכתובות מאוחסנים ב-L1 רזולורים. ניתן לפתור בעיה זו באמצעות , אבל הגעתי ללוגיקה אחרת, יעילה יותר לפתרון השרשרת: CCIP Read כל חשבון במאגר המפתחות נרשם ומתוקשר על ידי ה-namehash של שם ה-ENS שלו (רשום תחת שם ENS יחיד עם פותר מותאם אישית). כאשר תת-הדומיין שלו נפתר, חוזה הפותר בודק אם החשבון עם namehash כזה קיים באוסף ומשתמש ב-namehash כדי ליצור כתובות מיני-חשבונות מבוססות . CREATE2 כאשר אלה ייפרסו, הם יבקשו מ-L1 את נתוני מאגר המפתחות שאיתו הם נפרסו. זה יכול להיות כוונת העסקה עצמה או רק מפתח החתימה הנוכחי, תלוי ביישום מאגר המפתחות. בדרך זו, אנו מקבלים חשבונות מאגר מפתחות, שלכל אחד מהם שם ENS פותר לעצמו ולמיני-חשבונות שלו בכל אוסף. המיני-חשבונות הללו, בתורם, יסתמכו גם על שם ה-ENS הזה בעת אימות העסקה באמצעות מאגר המפתחות. השייכים ל-namehash ** מנגנוני רצף ב-"Keystore+". מכיוון שסופיות הגשר במכלול מאגר המפתחות המורחב אמורה להיות כמה בלוקים של L1, נוכל גם להיפטר לחלוטין מהסיקוונסרים המרכזיים, ולהפוך אותו לאוסף מבוסס. כפי שדיברנו בעבר, ~12 שניות של מהירות עסקה מקובלת על המשתמש הממוצע, אבל רצף מבוסס יהפוך את האוסף להרבה יותר עמיד בפני צנזורה ונקודות כשל בודדות. כדאי לקחת בחשבון שעם רצף מבוסס, עסקאות פנימיות יידרשו זמן רב כמו עסקאות חיצוניות (לא כולל זמן הגעה ל-L2). זה עשוי להיות בלתי מתקבל על הדעת עבור צוותים מסוימים, שכן רצף מרוכז הופך את כל הפעולות הפנימיות למיידיות. פתרונות הדדיות חלופיים של אוסף או: מדוע לא הזכרתי רצף משותף כתבתי את כל המאמר סביב רכיבי ZK וטכנולוגיית ZK. הסיבה לכך היא ש-rollups אופטימי לא יכול ביסודו להיות סופיות אובייקטיבית מהירה, וניתן להגיע למאפיין כזה רק באמצעות ZK. המכלולים האופטימיים של היום מבינים את המיקום החתום שלהם וחוקרים באופן פעיל את ההיתכנות של שילוב עיצובים ממוקדי תוקף בערימות שלהם, ומכאן, למשל, . השותפות האחרונה של Optimism ו-RISC Zero עיצוב אופטימי הוא מגביל ביסודו בכך שהוא לעולם לא יתמודד עם יכולת פעולה הדדית עם רכיבים אחרים. עם זאת, יכולת פעולה הדדית המערכת האקולוגית האופטימית מתפתחת במהירות. הטכנולוגיה העיקרית להפיכת מקבצים אופטימיים לפועלים זה עם זה היא . במילים פשוטות, זהו מנגנון שבו סיקוונסר יכול לבנות אצווה למספר רולאפים בו זמנית. אם עסקה כלשהי באחד מהאוסףים שצורפו אינה חוקית, ניתן לערער על האצווה כולה ולהחזיר אותה. בתוך רצף משותף זה נותן לכל הקבוצות ב"מגה אצווה" זה את התכונה האטומית - או שכל הקבוצות תקפות או שאין. זה, בתורו, מאפשר חיבור סינכרוני אטומי בתוך האצווה. Atomic - מכיוון ששום דבר באצווה אינו חוקי אם הוא חוקי, סינכרוני - מכיוון שכל העברת ההודעות נמצאות בתוך האצווה, אשר מעובדת בו זמנית על ידי כל הצמתים של האוסף שלה. הטכנולוגיה הזו הופכת בעצם את כל ה-rollups בערימה אופטימית מסוימת ל-rollup אחד גדול ומפורק. למה רק מחסנית אחת ולא כולם? כי כדי שזה יעבוד יש לחבר רולאפים לגשר בודד. לכל מחסנית יש גשר משלה, ואין דרך אמינה לבנות אצוות במספר גשרים בו זמנית. המשמעות היא שרצף משותף מאפשר ל-OP Mainnet לפעול בצורה חלקה עם Base ו-Zora אך לא עם Arbitrum או Metis, ולהיפך. איחוד כזה יוצר מצב מסוכן במערכת האקולוגית של הרולאפ. לרולאפים חדשים יש אפשרות להצטרף למחסנית הקיימת ולהשתלב איתה אבל לא עם אף אחד אחר או לבנות על גבי ZK ולהשתלב עם כל אחד מלבד המחסנית למעלה. אין ברירה כזו כעת מכיוון שרצף משותף עדיין לא זמין, וכל אוסף OP Stack או Arbitrum Orbit הוא עצמאי, עם גשר משלו. עם זאת, כאשר הם מתאחדים, הם יווצרו שני אורגניזמים מוצקים בתוך המערכת האקולוגית, כל אחד מחזיק . בערך 40% מסך ה-L2s TVL "בְּסֵדֶר. אם הם יחזיקו ברוב המוחלט של סך ה-TVL, למה שלא נפטר מז"ק ונבנה עליהם במקום?" קודם כל, סיקוונסרים משותפים הם מניע ריכוזי ענק. אם אתה מפעיל סדרת OP Mainnet, האצווה שלך לא יכללו טרנזקציות ממכלולים אחרים בערימה; אתה תרוויח פחות בעמלות ובסופו של דבר תעלה על ידי רצפים מסחריים גדולים שיכולים להתמודד עם כל הערימה באצווה שלהם. עם זאת, הבעיה הקריטית ביותר היא שבמקרה כזה, המערכת האקולוגית של הגל-אפ נעשית סגורה בתוך הרודפות אחר האינטרסים שלהן, מבקשות לבסס שליטה רבה יותר על הבירה, ומצמצמת את ההתקדמות הטכנולוגית במערכת האקולוגית. אז נצטרך להתמודד עם ריסוק של Ethereum לאזור מנותק שבו יחסי ציבור ומאבק פנים-ספציפי הם מה שחשוב, לא טכנולוגיות שמשנות את העולם בפועל. אימפריות אוליגופוליסטיות . אימפריות מנסות ללכוד וללכוד את המשתמש בתוך גן מוקף חומה; הכלים עושים את המשימה שלהם אבל אחרת משתלבים עם מערכת אקולוגית פתוחה יותר." - "בנה כלים, לא אימפריות ויטאליק בוטרין "איך צבירת גשרים משותפים ב-ZK טובים יותר מאשר רצף משותף אופטימי?" בגשרים המשותפים של ZK רולאפים, ניתן לבצע רצף באופן עצמאי משאר הרולאפים בגשר. לכל אוסף יכול להיות רצף משלו או ליישם רצף משותף. הטוענים את שורש המצב המתקבל לאחר כל רצף הקבוצות ומוכיחים אותו באמצעות ZK הם אלו שעושים צבירה. מציעים יתרה מכך, המאפיין של סופיות אובייקטיבית מהירה יחסית ב-ZK לא הופך אותם לסגורים בתוך המערכת האקולוגית שלהם, לא משנה כמה היא גדלה או כמה היא ריכוזית. כאשר ZK מפותח לרמה שבה ניתן ליצור הוכחות zkVM גדולות עבור מערכות הוכחה מרובות במהירות, כל ערימות ה-Rolup מבוססות ZK יפעלו כמעט בצורה חלקה, בדיוק כמו אוסף מאגר מפתחות תיאורטי שתואר לעיל שולח עסקאות בכל שאר ה-Rolups בעניין של L1 בלוקים. "אבל איך זה שעדיין קיימות רולאפים אופטימיים אם הם כל כך מרושעים, ויש אלטרנטיבה באוסף ZK?" בתוך הקהילה שלנו של חוקרים ואנשים טכניים מאוד, הקונצנזוס הוא ש-ZK הוא פתרון קנה המידה הטוב ביותר. ותתפלאו לגלות שעבור משתמשים ובונים רגילים, רולאפים אופטימיים טובים בהרבה מ-ZK! איך זה? : יש מערכת אקולוגית מבוססת היטב. כל הפלטפורמות יודעות מה זה Arbitrum ו-Base, ל-dApps יש תמיד נזילות גבוהה, וה-UX ריחני. נסו לתת שם לאפליקציה ב-Base, ותזכרו מיד , , , (כיום בלעדי ל-Solana), אוספי NFT שונים, ZKP2P. אפילו Mirror תמכה בתחילה רק ב-OP Stack רולפים להטבעה. נסה לתת שם לאפליקציה ב-ZKsync Era. למשתמשים את Friend.tech Farcaster Daimo Time.fun אההה… : יש שקילות Ethereum מוחלטת, כך שכל תשתית ה-Ethereum ו-EVM פורקס עובדת מהקופסה. חוץ מזה, התיעוד מגדיר ומסביר בקפדנות את כל המוזרויות והכלים של רולאפים אופטימיים. יש הרבה הדרכות, קורסים, מרתונים, קשרי מפתחים וכדומה. למפתחים מצד שני, ישנם zkEVMs בני שנה, שלא לכולם יש אפילו שקילות בתים. לכולם יש וקשיים כאשר בונים עליהם. הם לרוב מתועדים בצורה גרועה, ויש הסתמכות משמעותית על תשתית קיימת שבקושי תואמת את הרשתות. ביקורת VMs "תואמים" היא קשה ויקרה מאוד, ואין לך אפילו ChatGPT לשאול. רשימה ארוכה של הבדלים לאוסף ZK אין מערכת אקולוגית. אין אפליקציות לשימוש, אין רשתות חברתיות, אין NFTs או אסימונים פופולריים, וכל הפעילות מסתכמת בחקלאות אוויר. בקושי תמצא נזילות לזוגות שאינם בטופ 10 של המערכת האקולוגית של Ethereum, ו- מתחילה להציג אוסף ZK כשנמאס לך לגלול. למשתמשים: DefiLlama "אבל אוסף אופטימיים למעשה מנצח על ידי תאימות לתשתית קיימת. איך ז"ק רולאפים יכולים לנצח אותם בזה?" אינך צריך להציג שוויון בתים, או הידור מקדים של כדי למשוך מפתחים ופעילות לפלטפורמה שלך. רולאפים של ZK לא אמורים להיות טובים יותר בזה. במקום זאת, בסופיות וביכולת הדדית המהירה שלהם, מדרגיות אופקית מלאה, אבטחה גבוהה יותר ביסודו וביזור. זה מה שצריך לנצל בפרויקטים במערכת האקולוגית של אוסף ZK כדי להפוך אותם ליתרון במערכת האקולוגית. blake2f כתבתי את המאמר הזה כדי להרכיב תמונה מלאה של כל הטכנולוגיות הללו, כולל רולאפים של ZK, שהופיעו והתפתחו באזור בתקופה זו ולהראות כיצד ניתן להשתמש בהן כדי לפתור את הבעיה החשובה ביותר כיום בתחום – יכולת פעולה הדדית של רולאפ. עלינו לאמץ את ZK ואת היתרונות הבלתי מוגבלים שלה. עלינו להשתמש בהם לטובתנו כדי לבנות דברים שיקרבו אותנו להפוך את Web3 למקום עבור כולם בעולם. זו אולי טבלת ההשוואה הגדולה ביותר שהכנתי אי פעם. לא פלא — בשנה האחרונה, קהילת Ethereum עלתה עם הרבה רעיונות וטכנולוגיות חדשות שניתן לשלב ולתמרן בצורה גמישה כדי ליצור פתרונות חדשים לגמרי הפותרים את הבעיות הדוחקות ביותר באזור, אפילו עם טכנולוגיה קיימת. כן, אני עדיין משוכנע ש-Rollup interoperability היא הבעיה הדחופה ביותר שמונעת מאיתנו להכניס את כל העולם ל-Web3. קנה המידה כבר לא כל כך דחוף — 4844 מאפשר לנו לטפל עד אלף עסקאות בשנייה, בהשוואה לפעילות פיננסית במדינות הגדולות בעולם; מגיע בקרוב ותגדיל את זה עוד יותר. עם זאת, פיצול עדיין מהווה איום חמור על המערכת האקולוגית של Ethereum. לא משנה כמה היא תגדל, המערכת האקולוגית לא צריכה להרגיש כמו תריסר אימפריות נפרדות אלא כמנגנון אחד גדול. כל כך שונה, אבל כל כך זהה. PeerDAS אנחנו לא מוקדם, והמאמר הזה אמור להראות לכם את זה. עלינו להשתמש בכל החוזקות שלנו כדי לפתח מערכות עובדות שעוזרות למערכת האקולוגית הענקית L2 לפעול הדדית. זה אפשרי כרגע. בקרוב, אתה אמור להיות מסוגל להשתתף בכל DAO ולשלוח כל נכס ל-ENS, שהבעלים שלו נמצא כמה אלפי קילומטרים ממך. אין להחליף גבולות גיאוגרפיים בגבולות דיגיטליים. אם אהבת את העבודה הזו, מסכים עם התזה שלה, למדת משהו חדש או רוצה להפיץ את המסר הזה הלאה - שתף אותו במדיה החברתית, השאר את ההערות שלך ודיבר יותר על החשיבות של יכולת פעולה הדדית של אוסף. תודה שקראת. הערת המחבר: גרסה של מאמר זה פורסמה בעבר . כאן

מצב הפתרונות ההדדיים של אוסף

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps