אחת הסיבות העיקריות שאנו משתמשים בבלוקצ'יין היא חוסר אמון. נכס זה מבטיח לאפשר לנו גישה ריבונית עצמית לעושר ולנתונים שלנו. לרוב, בלוקצ'יין כמו Ethereum קיימו את ההבטחה הזו - הנכסים שלנו הם באמת שלנו.
עם זאת, יש הנחות שעשינו מטעמי נוחות. תחום אחד כזה הוא בשימוש שלנו בשרתי RPC (Remote Procedure Call) מרכזיים. משתמשים בדרך כלל ניגשים ל-Ethereum דרך ספקים מרכזיים כמו אלכימיה. חברות אלו מפעילות צמתים בעלי ביצועים גבוהים בשרתי ענן כך שאחרות יוכלו לגשת בקלות לנתוני השרשרת. כאשר ארנק שואל את יתרות האסימונים שלו או בודק אם עסקה ממתינה נכללה בחסימה, הוא כמעט תמיד עושה זאת דרך אחד מהספקים המרכזיים הללו.
הבעיה עם המערכת הקיימת היא שהמשתמשים צריכים לסמוך על הספקים, ואין דרך לאמת את נכונות השאילתות שלהם.
זן הליוס, לקוח Ethereum light מבוסס חלודה שפיתחנו המספק גישה חסרת אמון לחלוטין ל-Ethereum. Helios - המשתמשת בפרוטוקול לקוח הקל של Ethereum, המתאפשר על ידי המעבר האחרון ל הוכחה לבעלות - ממירה נתונים מספק RPC מרכזי לא מהימן ל-RPC מקומי בטוח שניתן לאמת. Helios פועלת יחד עם RPCs מרכזיים כדי לאפשר לאמת את האותנטיות שלהם מבלי להפעיל צומת מלא.
הפשרה בין ניידות וביזור היא נקודת כאב נפוצה, אך הלקוח שלנו - שעליו הפכנו לציבור לרשות הציבור להתבסס עליו ועוד - מסתנכרן תוך כשתי שניות, אינו דורש אחסון ומאפשר למשתמשים לגשת לנתוני שרשרת מאובטחים מ- כל מכשיר (כולל טלפונים ניידים ותוספות לדפדפן). אבל מה הם המלכודות הפוטנציאליות של הסתמכות על תשתית ריכוזית? אנו מכסים כיצד הם עשויים להופיע בפוסט הזה, עוברים על החלטות העיצוב שלנו, ומתארים גם כמה רעיונות שאחרים יכולים לתרום ל- קוד.
המלכודות של תשתית ריכוזית: יצורים תיאורטיים ב"יער האפל" של האתריום
יצור (תיאורטי) אורב ב יער אפל. זה לא צד את הטרף שלו ב-Ethereum mempool, אלא טומן את המלכודות שלו על ידי חיקוי תשתית מרכזית שעליה הגענו לסמוך. המשתמשים שנקלעו למלכודת הזו לא עושים שום שגיאה: הם מבקרים בבורסה המבוזרת האהובה עליהם, מגדירים סובלנות סבירה להחלקה, וקונים ומוכרים אסימונים כרגיל... הם עושים הכל נכון, אבל עדיין נופלים קורבן לסוג חדש של מתקפת כריכים, מלכודת שהוגדרה בקפידה ממש בכניסה ליער האפל של Ethereum: ספקי RPC.
לפני שנרחיב, הבה נבחן כיצד פועלות עסקאות בבורסות מבוזרות. כאשר משתמשים שולחים עסקת החלפה, הם מספקים מספר פרמטרים לחוזה החכם - אילו אסימונים להחליף, סכום ההחלפה, והכי חשוב, המספר המינימלי של אסימונים שמשתמש צריך לקבל כדי שהעסקה תעבור. פרמטר אחרון זה מציין שההחלפה חייבת לעמוד ב"פלט מינימלי" או לחזור. זה מכונה לעתים קרובות "סובלנות החלקה", מכיוון שהוא קובע למעשה את שינוי המחיר המקסימלי שיכול להתרחש בין מועד שליחת העסקה לממפול ועד שהיא נכללת בבלוק. אם פרמטר זה מוגדר נמוך מדי, המשתמש מקבל את האפשרות לקבל פחות אסימונים. מצב זה יכול להוביל גם להתקפת סנדוויץ', שבה תוקף למעשה מכניס את ההצעה בין שתי החלפות זדוניות. ההחלפות מעלות את מחיר הספוט ומאלצות את המסחר של המשתמש להתבצע במחיר פחות נוח. לאחר מכן התוקף מוכר מיד כדי לגבות רווח קטן.
כל עוד פרמטר התפוקה המינימלי הזה מוגדר ליד השווי ההוגן, אתה בטוח מפני התקפות סנדוויץ'. אבל מה אם ספק ה-RPC שלך לא מספק הצעת מחיר מדויקת מהחוזה החכם של החליפין המבוזר? לאחר מכן ניתן להערים על משתמש לחתום על עסקת החלפה עם פרמטר פלט מינימלי נמוך יותר, וכדי להחמיר את המצב, שולח את העסקה ישירות לספק RPC הזדוני. במקום לשדר את העסקה הזו לממפול הציבורי, שבו עשרות בוטים מתחרים על ביצוע מתקפת הסנדוויץ', הספק יכול לעכב זאת ולשלוח את חבילת עסקאות התקיפה ישירות ל-Flashbots, ולהבטיח את הרווחים לעצמם.
הסיבה העיקרית להתקפה זו היא לסמוך על מישהו אחר שיביא את מצב הבלוקצ'יין. משתמשים מנוסים פתרו באופן מסורתי את הבעיה הזו על ידי הפעלת צמתי Ethereum משלהם - מאמץ עתיר זמן ומשאבים שלכל הפחות דורש מכונה מקוונת כל הזמן, מאות גיגה-בייט של אחסון, ובערך יום לסנכרון מאפס. תהליך זה בהחלט קל יותר ממה שהיה פעם; קבוצות כמו Ethereum על ARM עבדו ללא לאות כדי לאפשר להפעיל צמתים על חומרה בעלות נמוכה (כגון Raspberry Pi עם כונן קשיח חיצוני קשור אליו). אבל אפילו עם הדרישות המינימליות יחסית הללו, הפעלת צומת עדיין קשה לרוב המשתמשים, במיוחד עבור אלה המשתמשים במכשירים ניידים.
חשוב לציין שהתקפות מרכזיות של ספקי RPC, למרות שהן סבירות לחלוטין, הן בדרך כלל התקפות דיוג פשוטות - וזה שאנחנו מתארים עדיין לא קרה. למרות שהרקורדים של ספקים גדולים יותר כמו Alchemy נותנים לנו סיבה מועטה לפקפק בהם, כדאי לעשות מחקר נוסף לפני הוספת ספקי RPC לא מוכרים לארנק שלך.
היכרות עם Helios: גישה חסרת אמון לחלוטין ל-Ethereum
על ידי הצגת פרוטוקול הלקוח הקל שלו (התאפשר הודות למעבר האחרון להוכחת הימור), Ethereum פתחה אפשרויות חדשות ומרגשות לאינטראקציה מהירה עם הבלוקצ'יין ולאימות נקודות קצה RPC עם דרישות חומרה מינימליות. בחודש שחלפו מאז המיזוג, ראינו יבול חדש של לקוחות אור צצים ללא תלות זה בזה (לודסטאר, הילה, והמבוסס על JavaScript Kevlar) שנקטו גישות שונות בשירות של אותה מטרה: גישה יעילה וחסרת אמון, ללא שימוש בצומת מלא.
הפתרון שלנו, Helios, הוא לקוח Ethereum light המסונכרן תוך כשתי שניות, אינו דורש אחסון ומספק גישה חסרת אמון לחלוטין ל-Ethereum. כמו כל לקוחות Ethereum, Helios מורכב משכבת ביצוע ושכבת קונצנזוס. שלא כמו רוב הלקוחות האחרים, Helios מחבר היטב את שתי השכבות כך שמשתמשים צריכים רק להתקין ולהריץ תוכנה אחת. (אריגון מתקדם גם בכיוון זה, על ידי הוספת לקוח אור שכבת קונצנזוס המובנה ישירות בצומת הארכיון שלהם).
אז איך זה עובד? שכבת הקונצנזוס של Helios משתמשת ב-blockhash של שרשרת משואה ידועה בעבר וחיבור ל-RPC לא מהימן כדי לסנכרן באופן אימות עם הבלוק הנוכחי. שכבת הביצוע של Helios משתמשת בלוקי שרשרת משואות מאומתים אלה יחד עם RPC שכבת ביצוע לא מהימנה כדי להוכיח מידע שרירותי על מצב השרשרת כגון יתרות חשבון, אחסון חוזים, קבלות עסקאות ותוצאות שיחות חוזים חכמות. רכיבים אלה פועלים יחד כדי לשרת את המשתמשים RPC חסר אמון לחלוטין, ללא צורך בהפעלת צומת מלא.
... ברובד הקונצנזוס
לקוח האור של שכבת הקונצנזוס מתאים ללקוח האור של שרשרת המשואות מפרט, ועושה שימוש בוועדות הסנכרון של רשת המשואות (הוצגו לקראת המיזוג במזלג הקשיח של אלטאיר). ועדת הסנכרון היא תת-קבוצה שנבחרה באקראי של 512 מאמתים המשרתים למשך ~27 שעות.
כאשר מאמת נמצא בוועדת סנכרון, הם חותמים על כל כותרת בלוק שרשרת משואה שהם רואים. אם יותר משני שלישים מהוועדה חותמים על כותרת בלוק נתון, סביר מאוד שהגוש נמצא בשרשרת המשואות הקנונית. אם הליוס מכיר את ההרכב של ועדת הסנכרון הנוכחית, הוא יכול לעקוב בביטחון אחר ראש הרשת על ידי בקשה מ-RPC לא מהימן לחתימה האחרונה של ועדת הסנכרון.
תודה ל-BLS חֲתִימָה צבירה, נדרשת רק בדיקה בודדת כדי לאמת את הכותרת החדשה. אם החתימה תקפה ונחתמה על ידי יותר משני שלישים מהוועדה, ניתן להניח שהגוש נכלל בשרשרת (כמובן שניתן לארגן אותו מחדש מחוץ לשרשרת, אך סופיות בלוק המעקב יכולה לספק ערבויות מחמירות יותר).
עם זאת, יש חלק ברור שחסר באסטרטגיה הזו: איך למצוא את ועדת הסנכרון הנוכחית. זה מתחיל ברכישת שורש אמון שנקרא מחסום סובייקטיביות חלש. אל תתנו לשם להפחיד אתכם - זה רק אומר בלוקשש ישן שאנחנו יכולים להבטיח שנכלל בשרשרת בשלב מסוים בעבר. יש איזו מתמטיקה מעניינת מאחורי כמה בדיוק יכול להיות המחסום; ניתוח המקרה הגרוע ביותר מצביע על כשבועיים, בעוד שהערכות מעשיות יותר מצביעות על חודשים רבים.
אם המחסום ישן מדי, יש התקפות תיאורטיות שיכולים להערים על צמתים לעקוב אחר השרשרת הלא נכונה. רכישת נקודת ביקורת סובייקטיביות חלשה היא מחוץ לתחום עבור הפרוטוקול. הגישה שלנו עם Helios מספקת נקודת ביקורת ראשונית המקודדת בבסיס הקוד (שניתן לעקוף בקלות); לאחר מכן, הוא שומר את הבלוק-האש האחרון שהושלם באופן מקומי כדי להשתמש בו כנקודת ביקורת בעתיד, בכל פעם שהצומת יסונכרן.
בצורה נוחה, ניתן לגיבוב בלוקים של שרשרת משואה כדי לייצר בלוקים ייחודיים של משואה. זה אומר שקל לבקש מהצומת בלוק משואה מלא, ואז להוכיח שתוכן הבלוק תקף על ידי גיבוב שלו והשוואה לבלוק-האש ידוע. Helios משתמש במאפיין זה כדי להביא ולהוכיח שדות מסוימים בתוך בלוק נקודת ביקורת הסובייקטיביות החלשה, כולל שני שדות חשובים מאוד: ועדת הסנכרון הנוכחית וועדת הסנכרון הבאה. באופן קריטי, מנגנון זה מאפשר ללקוחות קלים להתקדם קדימה בהיסטוריה של הבלוקצ'יין.
כעת, כשיש לנו נקודת ביקורת סובייקטיבית חלשה, אנו יכולים להביא ולאמת את ועדות הסנכרון הנוכחיות והבאות. אם ראש השרשרת הנוכחי נמצא באותה תקופת ועדת סנכרון כמו המחסום, אז אנחנו מתחילים מיד לאמת בלוקים חדשים עם כותרות ועדת הסנכרון החתומות. אם המחסום שלנו נמצא מאחורי כמה ועדות סנכרון, אנחנו יכולים:
- השתמש בוועדת הסנכרון הבאה אחרי המחסום שלנו כדי להביא ולאמת חסימה שמקורה בוועדת סנכרון אחת בעתיד.
- השתמש בבלוק החדש הזה כדי להביא את ועדת הסנכרון הבאה החדשה.
- אם עדיין מאחור, חזור לשלב 1.
כל איטרציה של תהליך זה מאפשרת לנו להריץ קדימה לאורך 27 שעות מההיסטוריה של הרשת, להתחיל עם כל blockhash בעבר, ולסנכרן עם blockhash הנוכחי.
...בשכבת הביצוע
המטרה של לקוח שכבת הביצוע הקלה היא לקחת כותרות של בלוק משואה המאומתות על ידי שכבת הקונצנזוס, ולהשתמש בהן יחד עם RPC שכבת ביצוע לא מהימנה כדי לספק נתוני שכבת ביצוע מאומתים. לאחר מכן ניתן לגשת לנתונים אלו דרך שרת RPC שמתארח באופן מקומי על ידי Helios.
הנה דוגמה פשוטה לאיסוף יתרת חשבון, החל מהסבר מהיר על האופן שבו המצב מאוחסן ב-Ethereum. כל חשבון מכיל כמה שדות, כגון hash קוד החוזה, nonce, hash אחסון ויתרה. חשבונות אלה מאוחסנים בקובץ גדול, שונה עץ מרקל-פטרישיה נקרא עץ המדינה. אם אנחנו יודעים את השורש של עץ המדינה, נוכל לאמת מרקל הוכחות כדי להוכיח את קיומו (או החרגה) של חשבון כלשהו בתוך העץ. למעשה בלתי אפשרי לזייף הוכחות אלו.
להליוס יש שורש מצב מאומת משכבת הקונצנזוס. באמצעות השורש הזה ו בקשות להוכחת merkle לשכבת הביצוע הלא מהימנה RPC, Helios יכולה לאמת באופן מקומי את כל הנתונים המאוחסנים ב-Ethereum.
אנו מיישמים טכניקות שונות לאימות כל מיני נתונים המשמשים את שכבת הביצוע; בשימוש יחד, אלה מאפשרים לנו לאמת את כל הנתונים שאוחזרו מה-RPC הלא מהימן. בעוד ש-RPC לא מהימן יכול למנוע גישה לנתונים, הוא כבר לא יכול להגיש לנו תוצאות שגויות.
שימוש בהליוס בטבע
ההחלפה בין ניידות וביזור היא נקודת כאב נפוצה - אך מכיוון שהליוס קלה כל כך, משתמשים יכולים לגשת לנתוני שרשרת מאובטחת מכל מכשיר (כולל טלפונים ניידים והרחבות דפדפן). היכולת להפעיל את Helios בכל מקום מאפשרת ליותר אנשים לגשת לנתוני Ethereum חסרי אמון, ללא קשר לחומרה שלהם. המשמעות היא שמשתמשים יכולים להשתמש בהליוס כספק ה-RPC שלהם ב-MetaMask, ולגשת ללא אמון ל-dapps ללא כל שינויים אחרים.
יתרה מכך, התמיכה של Rust ב-WebAssembly מאפשרת בקלות למפתחי אפליקציות להטמיע את Helios בתוך יישומי Javascript (כמו ארנקים ו-dapps). האינטגרציות הללו יהפכו את Ethereum לבטוח יותר ויפחיתו את הצורך שלנו לתת אמון בתשתית מרכזית.
אנחנו לא יכולים לחכות לראות מה הקהילה תמציא. אבל בינתיים, יש המון דרכים לתרום להליוס - אם אינך מעוניין לתרום לבסיס הקוד, תוכל גם לבנות תוכנה המשלבת את הליוס כדי לנצל את היתרונות שלה. אלה רק כמה מהרעיונות שאנחנו מתלהבים מהם:
- תמיכה באחזור נתוני לקוח קלים ישירות מרשת P2P ולא דרך RPC
- יישם כמה משיטות ה-RPC החסרות
- בנה גרסה של Helios שמתחברת ל-WebAssembly
- שלב את Helios ישירות בתוכנת הארנק
- בנה לוח מחוונים אינטרנטי כדי להציג את יתרות האסימונים שלך שמביאה נתונים מהליוס המוטמעים באתר באמצעות WebAssembly
- הטמעת ה-API של המנוע כך שניתן לחבר את שכבת הקונצנזוס של Helios לצומת מלא של שכבת ביצוע קיימת
בדוק את בסיס הקוד כדי להתחיל - אנו מברכים על דיווחי הבאגים, בקשות התכונות והקוד שלך. ואם אתה בונה עוד משהו, שתף אותנו בו טויטר, מברק, או Farcaster @a16zcrypto.
***
הדעות המובעות כאן הן אלה של אנשי AH Capital Management, LLC ("a16z") המצוטטות ואינן הדעות של a16z או החברות הקשורות לה. מידע מסוים הכלול כאן התקבל ממקורות צד שלישי, כולל מחברות פורטפוליו של קרנות המנוהלות על ידי a16z. למרות שנלקחה ממקורות האמינים כאמינים, a16z לא אימתה מידע כזה באופן עצמאי ואינה מציגה מצגים לגבי הדיוק הנוכחי או המתמשך של המידע או התאמתו למצב נתון. בנוסף, תוכן זה עשוי לכלול פרסומות של צד שלישי; a16z לא סקרה פרסומות כאלה ואינה תומכת בתוכן פרסומי כלשהו הכלול בהן.
תוכן זה מסופק למטרות מידע בלבד, ואין להסתמך עליו כייעוץ משפטי, עסקי, השקעות או מס. עליך להתייעץ עם היועצים שלך באשר לעניינים אלה. הפניות לניירות ערך או לנכסים דיגיטליים כלשהם נועדו למטרות המחשה בלבד, ואינן מהוות המלצת השקעה או הצעה לספק שירותי ייעוץ השקעות. יתר על כן, תוכן זה אינו מכוון ואינו מיועד לשימוש על ידי משקיעים או משקיעים פוטנציאליים כלשהם, ואין להסתמך עליו בשום פנים ואופן בעת קבלת החלטה להשקיע בקרן כלשהי המנוהלת על ידי a16z. (הצעה להשקעה בקרן a16z תתבצע רק על ידי מזכר ההנפקה הפרטית, הסכם המנוי ותיעוד רלוונטי אחר של כל קרן כזו ויש לקרוא אותה במלואה). המתוארים אינם מייצגים את כל ההשקעות בכלי רכב המנוהלים על ידי a16z, ואין כל ודאות שההשקעות יהיו רווחיות או שלהשקעות אחרות שיבוצעו בעתיד יהיו מאפיינים או תוצאות דומות. רשימה של השקעות שבוצעו על ידי קרנות המנוהלות על ידי אנדריסן הורוביץ (למעט השקעות שעבורן המנפיק לא נתן אישור ל-a16z לחשוף בפומבי וכן השקעות בלתי מוקדמות בנכסים דיגיטליים הנסחרים בבורסה) זמינה בכתובת https://a16z.com/investments /.
תרשימים וגרפים המסופקים בתוכן הם למטרות מידע בלבד ואין להסתמך עליהם בעת קבלת החלטת השקעה כלשהי. ביצועי העבר אינם מעידים על תוצאות עתידיות. התוכן מדבר רק לתאריך המצוין. כל תחזיות, אומדנים, תחזיות, יעדים, סיכויים ו/או דעות המובעות בחומרים אלו כפופים לשינויים ללא הודעה מוקדמת ועשויים להיות שונים או מנוגדים לדעות שהובעו על ידי אחרים. אנא ראה https://a16z.com/disclosures למידע חשוב נוסף
