EIP-7503: חורי תולעת אפס ידע עבור עסקאות Ethereum פרטיות

EIP-7503: Zero-Knowledge Wormholes היא הצעה לשיפור Ethereum (EIP) המציגה מנגנון לביצוע העברות לשמירה על הפרטיות ב-Ethereum. בעוד שראינו מאמצים רבים להפוך העברות בשרשרת לפרטיות, כולל מערבלי מטבעות קריפטוגרפיים כמו Tornado Cash, EIP-7503 הוא פתרון שכבת פרוטוקול שהופך את Ethereum לפרטי כברירת מחדל .

זהו שיקול חשוב: גישות של שכבת יישומים לפרטיות כמו Tornado Cash הן "הצטרפות", שלעתים קרובות יש לה השלכות שליליות על המשתמשים. יישומים ממוקדי פרטיות גם רגישים יותר לצנזורה; לדוגמה, משתמשים רבים (במיוחד אזרחי ארה"ב) לא הצליחו ליצור אינטראקציה עם Tornado Cash לאחר שהמשרד לבקרת נכסים זרים (OFAC) הכניס את כתובות החוזה של הפרוטוקול לרשימה השחורה ב-2022 .

למרות הסנקציות של OFAC, Tornado Cash עדיין פועל מכמה סיבות:

1. חוזי הליבה המיישמים את פונקציונליות ערבוב הנכסים של Tornado Cash אינם ניתנים לשינוי ומאוחסנים לצמיתות בשרשרת. מאז העיקרית tornado.cash האתר ירד למצב לא מקוון, פרויקטים עצמאיים עשו שימוש חוזר בקוד חוזה מהיישום המקורי של Tornado Cash כדי ליצור גרסאות חדשות כמו טורנדו קאש נובה .
2. פרוטוקול Tornado Cash הוא לרוב "בלתי ניתן לשליטה". צוות ההקמה של טורנדו קאש הסיר את הבקרות הניהוליות לאחר מכן ביצוע שדרוג חירום לתקן באג שיאפשר לתוקפים ליצור הוכחות תקפות להפקדות מזויפות ולרוקן כספים (הופקדו באופן לגיטימי). לפיכך, צוות המייסדים לא יכול היה להפעיל באופן חד צדדי מתג הרג וללחוץ עליו "לכבות" את הפרוטוקול למרות מעצר בשנת 2023 .

הגורמים שהוזכרו לעיל פירושם שאנשים עדיין מסוגלים להשתמש ב- Tornado Cash היום, גם אם ניתוחים מראים שיצרני בלוקים ב-Ethereum מבטלים עסקאות המתקשרות עם החוזים של הפרוטוקול . עם זאת, בדיוק כמו בימי הסנקציות שלפני OFAC, לא כל עסקה שניתבה דרך פרוטוקול המיקסר של Tornado Cash הייתה לגיטימית. לשם המחשה, מאמר מאת Arkham Intelligence מציע שלפחות שתי התקפות בעלות פרופיל גבוה בשנת 2023 (הניצול של אוילר פיננסים ב-197 מיליון דולר ומשיכת השטיח של אנוביס DAO של 60 מיליון דולר) מומנו על ידי כספים שנמשכו מטורנדו קאש, או השתמשו במיקסר להלבנת גנוב. כספים והסתרת העברות יוצאות.

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

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

בואו לצלול פנימה!

הגדרת הבמה: מדוע עלינו לדאוג לפרטיות ברשת?

כאשר אנו מדברים על "עסקאות פרטיות" או "עסקאות אנונימיות" בהקשר של תשלומים אלקטרוניים עמית לעמית (P2P), אנו מתארים שתי איכויות: חוסר מעקב וחוסר קישוריות . שתי האיכויות נקבעות על ידי ניקולס ואן סברהגן במאמר הלבן של CryptoNote :

• בלתי ניתנת למעקב : עסקה אינה ניתנת לאיתור אם לא ניתן לזהות את השולח בצורה מהימנה על ידי צופה חיצוני. נניח שאליס ידידה עם בוב וקרול ואליס תקבל שני אסימונים באמצעות העברה - חוסר מעקב אומר שאף אחד לא יכול לדעת מי (בוב או קרול) שלח אסימונים לאליס.

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

  
  

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

לשם השוואה, פרוטוקולים המתמקדים בפרטיות כמו Monero , Zcash , Liquid Network ו- Aztec v1 מציעים גרסאות של עסקאות "ממוגנות" או "סודיות" ומבטיחים ניתוק קישור של עסקאות. קשה לקשר עסקה מוגנת או חסויה לנמען ספציפי מכיוון שפרטי כתובתו של הנמען (כמו גם כמות וסוג האסימון המועבר) נשמרים בסוד. כתובות התגנבות הן גישה נוספת לשימור ניתוק הקישור: משתמשים יוצרים כתובת ארעית (קצרת מועד) להפקדה, וחוסמים ניסיונות לקשר שתי העברות לאותה כתובת.

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

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

להלן כמה דוגמאות לאופן שבו אנשים יכולים לממש את זכויותיהם לפרטיות (פיננסית):

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

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

עדיף שיהיה, ולא צריך, מאשר צריך, ולא יהיה. - פרנץ קפקא

פתרון בעיית הפרטיות של Ethereum עם EIP-7503

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

• פרטיות פירושה שניתן לעקוב אחר הפעולות הסודיות שלך לזהותך הציבורית, אך פרטי הפעולות שלך מוסתרים. נניח שאתה שולח אימייל מוצפן באמצעות כלי PGP ( Pretty Good Privacy ): שרתי הדואר יודעים ששלחת מייל לגורם אחר (ניתן לזהות), אך אינם יכולים לקרוא את תוכן המייל. זו פעולה סודית כי אף אחד אחר לא יודע ששלחת מייל, מלבד הנמען.

• אנונימיות פירושה שהפעולות הציבוריות שלך מנותקות מהזהות הציבורית שלך. אם להשתמש בדוגמה הקודמת: שירות דוא"ל אנונימי היפותטי עמית לעמית יכול לטשטש את המקור והיעד של דוא"ל מוצפן, תוך שמירה על רישום ציבורי של כל המיילים המנותבים דרך הרשת. זוהי פעולה ציבורית מאחר והרשומה של מישהו ששולח מייל גלוי לכל משתתף ברשת, אך כתובות המייל הן מחרוזות hash ( 0xdeadbeef ) ולא שמות ( [email protected] ).

  
  

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

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

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

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

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

EIP-7503 הוא מאמץ לתקן חלק מהבעיות שתוארו קודם לכן, במיוחד חוסר האנונימיות של שולחי העסקאות. ההצעה מציגה אמצעי עבור כתובות להרוס בכוונה את Ether (ETH) על ידי שליחת כספים לכתובת שאינה ניתנת להוצאה , ויצירת הוכחה ZK-SNARK לאימות הפקדה לכתובת שאינה ניתנת להוצאה. אם ההוכחה הזו עוברת את האימות, כמות של אסימוני ETH (שווה ליתרת הכתובת הבלתי ניתנת לבזבז) מוטבעת לכתובת חדשה לבחירתו של המשתמש - תוך שבירת הקישור בין כתובות השליחה והקבלה הכרוכות בהעברת הכספים.

EIP-7503 שואל רעיונות מפרוטוקולי פרטיות קיימים כדי להפעיל עסקאות שומרות פרטיות ב-Ethereum. לדוגמה, ההצעה מקשה על מעקב אחר כספים שהתקבלו בעסקת הטבעה למקור מסוים על ידי הפיכת כל הסט של כתובות Ethereum עם יתרת ETH ואפס עסקאות יוצאות לסט אנונימי . אתה לא יכול לזהות בקלות את הכתובת A האחראית לשריפת ה-ETH שכתובת B נטבעה מחדש בעסקה הבאה: A יכולה להיות אחת ממיליוני הכתובות שיש להן יתרה שאינה אפס אך לא יזמו עסקת Ethereum.

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

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

EIP-7503 גם שואל מפרוטוקולים אחרים המתמקדים בפרטיות כמו Zcash ו- Aztec v1 על ידי שימוש בהוכחות קריפטוגרפיות כדי לאמת עסקאות מבלי לחשוף פרטי עסקה. אימות עסקאות באופן שומר פרטיות מבטיח ש-Ethereum יכול לתמוך בבטחה בהעברות פרטיות מבלי לערער את מודל האבטחה הקיים שתלוי ברשת המבוזרת של צמתים שתבצע מחדש כל עסקה כדי לאשר את נכונותה. נחקור פרטים על האופן שבו EIP-7503 משתמש ב-ZK-SNARKs מתחת למכסה המנוע כדי לתמוך בביצוע מאובטח של העברות פרטיות ב-Ethereum בסעיפים הבאים (בין היתר).

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

סקירה כללית של EIP-7503: Zero-Knowledge Wormholes

ברמה גבוהה, EIP-7503 פועל באופן הבא:

1. משתמשים "שורפים" את ה-ETH על ידי שליחתו לכתובת שהיתרה שלה אינה ניתנת לבזבז

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

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

תקן האסימון המקורי של ERC-20 אינו מציין פונקציות לצמצום היצע של אסימון, מה שאומר שלאסימונים ישנים יותר כמו WETH (Ether עטוף) אין דרך להבטיח שמשתמשים מוציאים נכסים עטופים מהמחזור לפני משיכת ההפקדה המקורית. עם זאת, שליחת אסימוני WETH לכתובת האפס הופכת אותם לבלתי ניתנים להוצאתם ומדמה הפחתה באספקת ה-WETH במחזור בכל פעם ש-ETH נסוג מחוזה העטיפה של WETH. אם אתה תוהה כיצד WETH שומר על יחס של 1:1 עם ETH מקורי, הנה התשובה שלך.

EIP-7503 עושה שימוש במנגנון דומה כדי לאפשר למשתמשים לצרוב אסימוני ETH ואסימוני מנטה לכתובת אחרת ב-Ethereum עם טוויסט קטן. במקום לבקש ממשתמשים לשלוח כספים לכתובת צריבה אחת, EIP-7503 דורש מהמשתמשים ליצור כתובת צריבה ייחודית עבור כל עסקה לפני הטביעת ETH לכתובת אחרת.

2. משתמשים יוצרים הוכחה פרטית לצריבה או "קבלת צריבה" שמוכיחה שהם שרפו כמות כלשהי של ETH בעסקה קודמת על ידי שליחתו לכתובת צריבה

שליחת כספים לכתובת צריבה (שנוצרה על פי מפרט EIP-7503) היא המקבילה לזריקת מזומנים לחור תולעת - לעולם לא ניתן לשחזר אותו. אבל אתה יכול להוכיח ידע על משהו שנשלח לחור התולעת באמצעות ZK-SNARK ( Z ero- K nowledge Succinct A rgument of K nowledge); מכאן המונח "חורי תולעת אפס ידע".

הוכחת השריפה היא פרטית מכיוון שמשתמש רק צריך להוכיח שהוא שלח אסימונים לכתובת A שאין לבזבז אותה מבלי לחשוף את A בטקסט רגיל. יצירת הוכחת צריבה דורשת הוכחה שכתובת הצריבה באמת בלתי ניתנת לבזבז. מַדוּעַ? בקשה למשתמשים לשרוף ETH מקורי לפני הטבעת אסימוני ETH חדשים לכתובת הנמען מבטיחה שוויון (בערך ובניתוק) של שני סוגי הנכסים, אם המשתמשים יכולים מאוחר יותר למשוך כספים מכתובת הצריבה, הצמד 1:1 בין ETH מקורי לנטבע אסימוני ETH יפסיקו להתקיים.

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

EIP-7503 מציג סוג עסקה חדש ב-EVM (Ethereum Virtual Machine) שמקבל הוכחת שריפה ונמען כקלט ומטביע אסימוני ETH חדשים לכתובת השליחה אם ההוכחה מאומתת בהצלחה. כדי למנוע טבעת ETH פעמיים עבור אותה עסקת צריבה, ערך "בטל" מיוחד מצורף לכל הוכחת שריפה כדי לעקוב אחר השימוש בכתובת.

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

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

• יצירת הכתובת שלא ניתן לבזבז
• יצירת הוכחות צריבה פרטיות
• אימות של הוכחות צריבה פרטיות
• טביעת ETH למקבלי העברות פרטיות

יצירת הכתובת שלא ניתן לבזבז

כתובת Ethereum רגילה היא 20 הבתים הראשונים של ה-hash Keccak256 של המפתח הציבורי שנוצר מהמפתח הפרטי של החשבון (המפתח הפרטי הוא מספר שלם שנוצר מביטוי מנמוניק או סיד). גם מפתחות פרטיים וגם מפתחות ציבוריים נוצרים באמצעות אלגוריתם החתימה הדיגיטלית של עקומה אליפטית (ECDSA). ECDSA הוא נושא מורכב ("מורכב" הוא לשון הרע המועדף עליי ל"יש הרבה מתמטיקה"), אבל הנה כמה משאבים - מדורגים מהמתחילים למומחה בנושא:

• פריימר (קל יחסית להבנה) בקריפטוגרפיה של עקומה אליפטית (בלוג Cloudflare)
• אלגוריתם חתימה דיגיטלית עקומה אליפטית (ויקיפדיה)
• אלגוריתם חתימה דיגיטלית עקומה אליפטית (וויקי ביטקוין)
• ECDSA: חתימות עקומה אליפטיות (קריפטוגרפיה מעשית למפתחים)

המפתח הציבורי נגזר על ידי הכפלת המפתח הפרטי (הנקרא סוד או בקיצור s ) בערך "מחולל" מיוחד G כדי לייצר ערך חדש בצורת pubKey = privKey * G . הכתובת נוצרת על ידי הפעלת המפתח הציבורי דרך פונקציית ה-hash Keccak256 ולקיחת 20 הבתים הראשונים של מחרוזת ה-hash. בסימון פסאודו-מתמטי, הפעולה נראית כך: A = K(s * G) , כאשר A היא הכתובת, s הוא המפתח הסודי או הפרטי, ו- G היא נקודת המחולל בעקומה האליפטית.

הכתובת, המפתח הציבורי והמפתח הפרטי משרתים מטרות שונות מאוד:

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

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

כיצד נדע אם היתרה של כתובת A אינה ניתנת לבזבז? אנו יכולים להתחיל בבחירה אקראית של ערך אקראי של 20 בתים עבור A וניצול מאפיין מיוחד של פונקציות גיבוב קריפטוגרפי** המכונה התנגדות קדם תמונה . במילים פשוטות, התנגדות לפני תמונה פירושה שאיננו יכולים למצוא ערך x כך ש- H(x) (ה-hash של x ) זהה ל- A אם A נבחר באקראי. בסימון פסאודו-מתמטי, טענה זו היא בצורה: H(x) ≠ A .

A היא התמונה של ה-hash (הפלט של פונקציית ה-hash) ו- x היא התמונה המוקדמת של פונקציית ה-hash (הקלט לפונקציית ה-hash). מציאת הערך של x עבור H(x) = A קשה בגלל (א) המספר העצום של מספרים שלמים אפשריים (ב) האופן שבו תשומות עוברות מניפולציה על ידי פונקציית Hash כדי לייצר פלט. לפיכך הדרך היחידה שבה אתה יכול "לנחש" ערך עבור x שמביא ל- A היא אם יש לך כמות עצומה של כוח מחשוב ומספיק זמן בידיים שלך כדי לעבור מספר עצום של חישובים כדי למצוא H(x) = A .

אמנם זה לא מחלקה Cryptography 101 שלך, אבל ההסבר הקודם לוכד תכונה מרכזית של מערכות הצפנה מודרניות. תכונת התנגדות הקדם-תמונה של פונקציות גיבוב ממלאת גם תפקיד מפתח ב-EIP-7503: אם A הוא ערך אקראי של 20 בתים, יש לנו ביטחון סביר שמשתמש לא יכול לגזור את המפתח הפרטי s אין לו דרך להוציא כספים מהכתובת. כלומר, אי אפשר לחשב A = H(h(s * G) , כאשר A היא כתובת הצריבה, s הוא המפתח הפרטי או הסוד, ו- G היא נקודת המחולל (הערה קטנה: k(s * G) שווה ל- x מהפסקה הקודמת).

אבל, האסטרטגיה הזו לא לגמרי חסינת תקלות. לדוגמה, כיצד נוכל לקבוע ש- A הוא באמת אקראי ואינו תוצאה של חישוב s * G ? אם משתמש בוחר ב- A באופן עצמאי, עלינו לסמוך על המשתמש או לבנות נהלים מורכבים לאימות ש- A נבחר באקראי; אם אנחנו בוחרים A , אנחנו לא צריכים לסמוך על משתמש - אבל יש סבירות לא מבוטלת שמישהו עלול להצליח ולנחש נכון x . מכיוון ש- x = s * G , ידע זה עשוי לאפשר למשתמש לגזור את s המפתח הפרטי ולהוציא מהכתובת כביכול בלתי ניתנת לבזבז.

זה ללא ספק לא אופטימלי ומדגיש את הצורך במנגנון מאובטח יותר ליצירת כתובות שלא ניתן לבזבז. למרבה המזל, לפונקציות גיבוב קריפטוגרפיות יש תכונה נוספת שאנו יכולים לנצל: התנגדות להתנגשות . במילים פשוטות, התנגדות התנגשות פירושה שאינך יכול למצוא H(x) = H(y) , כאשר x ו- y הם תשומות שונות - כלומר, חישוב הגיבובים עבור ערכי קלט שונים אינו יכול "להתנגש" ולהניב את אותה תוצאה.

התנגדות להתנגשות חשובה למניעת זיוף (בין היתר): לשני אנשים שמקבלים שני כניסות שונות תמיד יהיו מחרוזות גיבוב שונות ואחד לא יכול לטעון שהוא בעל הקלט הידוע רק לאדם השני. גרסה נוספת של התנגדות התנגשות היא שאינך יכול למצוא H1(x) = H2(x) , כאשר H1 ו- H2 הם ממשפחות שונות של פונקציות גיבוב. במילים אחרות, חישוב ה-hash של x באמצעות אלגוריתמי גיבוב שונים אינו יכול "להתנגש" ולהגיע לאותו פלט.

כדי להבין מדוע זה אפשרי, נמציא דוגמה מתוכננת כדי להסביר כיצד פועלות פונקציות ה-hash בשלב הבא.

Interlude: פונקציות גיבוב קריפטוגרפיות עבור noobs

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

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

הקוד של Blue Party ידוע בתור אלגוריתם האותיות הכפולות, בעוד Red Party משתמש בגרסה הנקראת אלגוריתם האותיות המשולשות. הקוד פשוט מאוד: אנו מחליפים אלפבית במספרים בעת כתיבת הודעות - כל מספר במחרוזת ההודעה מתייחס לאות במיקום מסוים באלפבית. סיביות "ההצפנה" מגיעות מהאופן שבו אנו בוחרים מספרים לייצוג אלפבית:

• בקוד ה- Blue Party "אות כפולה", אנו מחלקים כל מספר בשניים ומשתמשים במספר המתקבל (n) כדי למצוא את האות במיקום ה-n של האלפבית. לדוגמה, אנו יכולים להצפין את "BOY" כ- 4-30-50 : 4/2 = 2 ("B" היא האות השנייה באלפבית); 30/2 = 15 ("O" היא האות ה-15 באלפבית); 50/2 הוא 25 ("Y" היא האות ה-25 באלפבית).
• בקוד המפלגה האדומה "אות משולשת", אנו מחלקים כל מספר בשלוש ומשתמשים במספר המתקבל (n) כדי למצוא את האות במיקום ה-n של האלפבית. לדוגמה, אנו יכולים להצפין את "BOY" כ- 6-45-=75 : 6/3 = 2 ("B" היא האות השנייה באלפבית); 45/3 = 15 ("O" היא האות ה-15 באלפבית); 75/3 = 25 ("Y" היא האות ה-25 באלפבית).

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

כאשר "BOY" מוצפן באמצעות אלגוריתם "אות כפול" של Blue Party ואלגוריתם "אות משולשת" של מפלגת Red Party, התוצאות שונות מאוד ( 4-30-50 ו- 6-45-75 , בהתאמה). חבר במפלגה הכחולה אינו יכול ליצור 6-45-75 , אלא שהוא משתמש באלגוריתם ההצפנה של המפלגה האדומה; גם חבר במפלגה האדומה לא יכול להפיק 4-30-50 כמחרוזת הודעות, אלא שהוא משתמש באלגוריתם ההצפנה של המפלגה הכחולה. מכיוון שכל צד שומר על פרטי אלגוריתם ההצפנה, אנו יודעים שחבר מפלגה מתחרה אינו יכול לפענח הודעה שלא נועדה עבורו.

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

אנו יכולים לנצל את ההתנגדות להתנגשות של פונקציות גיבוב כדי ליצור כתובות בלתי ניתנות להוצאה מוכח לשריפת נכסים כנדרש על ידי EIP-7503. ראשית, אנו מבקשים מהמשתמשים לבחור ערך סודי s (המפתח הפרטי לחשבון Ethereum), לחשב את ה-hash Keccak256 של s * G כדי לגזור את המפתח הציבורי, ולגבש את המפתח הציבורי כדי לגזור כתובת A . לאחר מכן אנו מבקשים מהמשתמש ליצור כתובת B חדשה על ידי גיבוב הערך הסודי s עם פונקציית גיבוב שונה המסומנת כ- H ולקחת את 20 הבתים הראשונים של הפלט ככתובת.

המטרה שלנו? אנחנו רוצים לסיים עם K(x) ≠ H(x) , כאשר K מייצג את פונקציית ה-hash Keccak256 ו- H מייצגת פונקציית hash ממשפחה אחרת של פונקציות hash. מטעמי ביצועים, אנו רוצים ש- H יהיה "ידידותי ל-ZK" (כלומר, אימות התוצאה של H(x) בתוך מעגל צריך להיות זול ומהיר).

אנחנו לא יכולים לדעת את המפתח הציבורי עבור B כי הכתובת נוצרה באופן אקראי במקום לחשב את ה-hash Keccak256 של s * G (מפתח פרטי כפול מחולל), מה שאומר שגם המפתח הפרטי עבור B אינו ניתן לדעת. אם אנחנו לא יודעים את המפתח הפרטי של B , לא נוכל לייצר חתימות חוקיות להודעה שמוציאה את היתרה של B. עם תהליך אקראי מוכח ליצירת כתובות שלא ניתן לבזבז, יש לנו כעת דרך למשתמשים לצרוב ETH לפני הטביעה מחדש של נכסים.

יצירת הוכחת השריפה הפרטית

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

מכיוון שאנו רוצים להימנע מהדלפת מידע על השתתפותו של משתמש בפרוטוקול הפרטיות, אנו מאפשרים למשתמשים במקום זאת ליצור הוכחת אפס ידע המוכיחה את הידע של s (הערך הסודי שפורץ לגזירת כתובת הצריבה) מבלי לשחרר s באופן ציבורי. הוכחת אפס הידע קובעת את ידיעת המשתמש על כתובת B שנגזרת מהתוצאה של H(s) : מכיוון ש- s נבחרה בסתר, אדם אחר אינו יכול לחשב ערך שונה H(x) כך ש- H(s) = H(s) . זה נובע מתכונת ההתנגדות להתנגשות של פונקציות גיבוב שתוארו קודם לכן.

הסתרת s מונעת משחקנים זדוניים לממש פיקדון של משתמש על ידי הגשת הוכחה המאשרת את הידע על הסוד (המשמש ליצירת כתובת שאינה ניתנת לבזבז) למאמת EIP-7503. סעיף זה מפרט מדוע אנו מסוגלים ליצור הוכחה של אפס ידע שמוכיחה H(s) = A מבלי לדרוש מהמאמת לחשב H(s) באופן עצמאי. אבל אתה יכול לקרוא את תוכניות האריתמטיקה הריבועית של Vitalik: Zero To Hero ואת המאמר שלי על ZK-EVMs כדי לקבל רקע על שימוש ב-ZK-SNARKs כדי להוכיח את תקפותו של חישוב מבלי לחשוף את התשומות.

אנו מתארים את הוכחת אפס הידע המאמתת העברת כספים של משתמש לכתובת שאינה ניתנת לבזבז (המכונה כתובת צריבה ) כ"הוכחה לצריבה" או "קבלת צריבה". הוכחת השריפה מוכיחה את ההצהרות הבאות:

• המשתמש מכיר כתובת A ואת הערך הסודי s שהועבר לגיבוב כדי לגזור את A (כלומר, H(s) = A ). זהו בדיקה שאין לבזבז את הכתובת על ידי אישור ש- A היא תוצאה של גיבוב s עם פונקציית hash (ידידותית ל-ZK) השונה מפונקציית ה-hash Keccak256 המשמשת ליצירת כתובות Ethereum שניתן לבזבז.

• לכתובת A יש יתרת ETH חיובית השווה או גדולה מ- b ( b ≥ b' ). זוהי בדיקה שהסכום שמשתמש מנסה להטביע לכתובת המקבל זהה לסכום שהופקד בכתובת הבלתי ניתנת לבזבז.

  
  

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

הוכחת מרקל מורכבת מהעלים של ה-Markle Patricia Trie (MPT) הנדרשים כדי לחשב את הנתיב מהעלה שאנו מנסים להוכיח (הכתובת A ) לשורש ה-Markle Trie (השורש הטרי הוא גם חלק מה מרקל הוכחה). אנו זקוקים להוכחה לכך ששורש המצב - המשמש לאימות הוכחת Merkle - הוא גם קנוני, ולכן אנו דורשים מהמשתמש להעביר כותרת בלוק B כקלט נוסף למעגל. קבוצת מידע זו מאפשרת למאמת מוגבל במשאבים לוודא ביעילות שהכללת כתובת A במצב מנסה ולאמת את היתרה b של A .

הערה *: מפרט EIP-7503 ממליץ לגזור את הוכחת Merkle הנדרשת כדי להוכיח הכללת כתובת הצריבה ב-State ניסיון ולאמת את יתרת הכתובת באמצעות שיטת* eth_getProof JSON-RPC שהוצגה ב- EIP-1186 .

יצירת ביטולים עבור כתובות

קלט נוסף למעגל ZK-SNARK שמייצר הוכחת הפקדה לכתובת שאינה ניתנת לבזבז הוא מבטל . ה-nullifier הוא ערך שמונע ממשתמש להשתמש באותה הוכחת צריבה כדי להטביע ETH פעמיים . ללא ביטול, שום דבר לא מונע ממשתמש נבון לעשות שימוש חוזר בהוכחת צריבה כדי למשוך ETH מספר פעמים: מנקודת המבט של צומת המעבד העברות פרטיות מסוג EIP-7503, המשיכות הללו תקפות מכיוון שהיתרה של הכתובת הבלתי ניתנת לבזבז לעולם אינה מצטמצמת ( זה רק יכול להגדיל).

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

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

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

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

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

נוכל לפתור בעיה זו על ידי מציאת מנגנון מאובטח יותר ליצירת מבטלים. האסטרטגיה שאומצה במפרט ה-EIP-7503 הנוכחי היא להשתמש באותה פונקציית hash (ידידותית ל-ZK) כדי ליצור מבטל N על ידי גיבוב כתובת הצריבה עם הערך הסודי s . בסימון פסאודו-מתמטי, זה נראה כך: N = H(A,s) , כאשר A היא הכתובת הבלתי ניתנת להוצאה ו- s הוא הערך הסודי שיצר את A בתחילה.

הערך הסודי s מתואר כמלח במקרה זה. ערך המלח הזה מגדיל בעצם את הקושי לחלץ מידע על כתובות צריבה ממבטלים: אם s היה ידוע, צופה יכול לבצע התקפת כוח גס ולהריץ את כל השילובים האפשריים של hash(burnaddress,secret) המייצרים מבטל N המאוחסן ב- שַׁרשֶׁרֶת. אבל s נשמר בסוד על ידי המשתמש, ובכך מבטל למעשה את האפשרות למצוא את כתובת הצריבה המתאימה עבור מבטל משומש.

אימות הוכחת השריפה הפרטית

כעת, כשאנו יודעים אילו הצהרות הוכחת השריפה מנסה להוכיח, יש לנו מושג הוגן כיצד עובד אימות הוכחה. עבור ההצהרה הראשונה ( h(s) = A ), המאמת צריך "להבין" את ההיגיון של פונקציית ה-hash המשמשת ליצירת הכתובת A - כך שהוא יודע ש- H(s) אכן שווה ל-A. קידוד ההיגיון של פונקציית ה-hash במעגל המאמת אוכף גם את הדרישה שלא ניתן ליצור A עם פונקציית ה-hash Keccak256.

עבור ההצהרה השנייה ( ל-A יש יתרה חיובית b של ETH), על המאמת לאמת הוכחת Merkle המוכיחה את הכללת A במצב של Ethereum ומאמתת את נתוני החשבון. מאמת המעגל גם בודק שכותרת הבלוק B היא מהשרשרת הקנונית - לפני חילוץ שורש המצב - על ידי קריאה ל- BLOCKHASH opcode עם הקלט block.blockHash(blockNumber) , כאשר blockNumber מתייחס לכותרת הבלוק B. אם B הוא חלק משרשרת Ethereum הקנונית, ה- hash המוחזר על ידי ה-opcode BLOCKHASH צריך להתאים ל-hash של כותרת הבלוק B.

בנוסף, מעגל המאמת מאמת את המבטל הכלול בהוכחת ה-ZK-SNARK של המשתמש ומאשר שלא נעשה שימוש בעבר במבטל. ההתנגדות להתנגשות של פונקציות גיבוב ממלאת תפקיד תומך כאן על ידי מניעת ניסיונות ליצור שני גיבובים שונים של מבטל N1 ו- N2 עבור אותה שילוב burn address <> secret value . אם משתמש יכול ליצור מבטלים שונים עבור אותה כתובת, הוא יכול להטביע ETH כפול - ללא קשר אם ה-Sparse Merkle Tree מאחסן מבטל עבור כתובת זו או לא.

כדי להבטיח שניתן לאמת הוכחות-של-צריבה על-ידי מציעי בלוק, EIP-7503 מציע שינוי ב-EVM כדי ליישם אימות תמיכה של הוכחות ZK-SNARK. המחברים של EIP-7503 בדקו את הכדאיות של יישום אימות בתוך EVM של הוכחות צריבה על ידי יצירת גרסה התומכת ב-EIP7503 של ה-EVM באמצעות מסגרת Polaris EVM . אתה יכול לבקר במאגר GitHub המוקדש לפרויקט לפרטים נוספים על עיצוב הפרוטוקול.

הטבעת ETH לכתובת הנמען

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

למרות שה-EIP-7503 מספק הכחשה סבירה, מומלץ למשתמשים להימנע מתשלום עבור עסקאות טביעה עם כספים מאותה כתובת ששלחה את ETH לכתובת הצריבה. אם אליס שולחת ETH לכתובת 0xm00la שאינה ניתנת לבזבז ומאוחר יותר תשלח עסקה בתשלום עבור אותו כמות של ETH כדי להיטבע לחשבון נפרד, בוב לא צריך להיות ג'ימי ניוטרון כדי לקשר את אליס לעסקת הצריבה המקורית.

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

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

למרבה המזל, אנו יכולים לדרוש מהוכחת השריפה להתייחס לכתובת המשיכה ב' ולאכוף כלל של הטופס: "עסקת טביעה יכולה רק להטביע ETH לכתובת שחולצה מהוכחת השריפה". השוויון בין הכתובת המועברת כקלט ציבורי למעגל ZK-SNARK לבין הכתובת שצוינה בעסקת ההטבעה נבדקת על ידי המאמת. כך, כל משתמש בטוח שאף אחד לא יכול לאסוף את עסקת נושא ההוכחה שלו מה-mmpool ולגנוב את המשיכה שלו.

למה EIP-7503? המקרה להעברות פרטיות ב-Ethereum

העברות ותשלומים פרטיים

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

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

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

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

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

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

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

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

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

אנו יכולים לראות כיצד העברות פרטיות בסגנון EIP7503 יכולות להועיל בתרחישים אחרים:

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

ניתן להשתמש ב-EIP-7503 גם מסיבות שאינן קשורות לפרטיות :

1. נכון לעכשיו, מרכזיות מרכזיות (CEXes) חייבות ליצור כתובת ייחודית כדי לקבל פיקדון ממשתמש וצריכות לשלוח עסקאות המעבירות יתרות של כל כתובת לארנק קר אחד או יותר כחלק מתהליכי אבטחה תפעוליים. עם EIP-7503, מפעיל CEX יכול ליצור כתובת צריבה אחת שמקבלת הפקדות מקבוצה של משתמשים וליצור הוכחת צריבה המושכת את כל ההפקדות שנצברו בכתובת הצריבה לארנק הקר בעסקה אחת. הפחתה במספר העסקאות הנדרשות לאיחוד פיקדונות CEX בארנק קר מיטיבה עם מפעיל ה-CEX (עלויות תפעול מופחתות) והרשת (מספר נמוך יותר של עסקאות בשרשרת).
2. כל ישות שמעבדת כמות משמעותית של תשלומים על השרשרת יכולה למנף את EIP-7503 כדי לשפר את היעילות התפעולית - כך ש-CEXs אינם הנהנים היחידים. סוחרים, ארגוני צדקה ומסילות תשלומים מקוריות קריפטו הן כמה דוגמאות לארגונים המשתמשים ב-EIP-7503 כדי להפחית את התקורה התפעולית על ידי צבירת הפקדות בכתובות צריבה ופיזור עלויות העסקאות על פני מספר הפקדות. להיבט זה של EIP-7503 יש את תופעת הלוואי הרצויה של יצירת תמריצים פיננסיים להצטרף למערך האנונימיות ומגביר את הפרטיות הכוללת של חשבונות המבצעים העברות פרטיות.

איזון בין פרטיות לבין עמידה בתקנות

EIP-7503 מספק נתיב פשוט לעבר עיגון פרטיות העסקאות ב-Ethereum מבלי לדרוש שינויים נרחבים בפרוטוקול. בפרט, EIP-7503 יאפשר ל-Ethereum להציע פרטיות עסקה מבלי להתמודד עם בעיות בהתמודדות עם בלוקצ'יין אחרים ממוקדי פרטיות כמו Zcash ו-Monero.

למרות שכתבתי בעבר להגנת מטבעות הפרטיות , לא צריך הרבה כדי לראות שמטבעות פרטיות כמו ZEC (Zcash) ו-MNR (Monero) אינם יכולים להשיג את המטרה של הכנסת כסף מבוזר, פרטי ושמיש לכלכלה העולמית . עם לחצים רגולטוריים המאלצים את הבורסות למחוק מטבעות פרטיות, לבעלים יהיה יותר ויותר קשה לנצל את הפרטיות שמציעים Zcash, Monero ופרוטוקולים אחרים שנועדו במפורש להסתיר מידע עסקה בהקשרים של העולם האמיתי. קטע זה מתוך הספרWhy Privacy Coins Haven't Taken Off של Haseeb Qureshi מספק היכרות טובה עם האתגרים העומדים בפני פרויקטי פרטיות "הארדקור" כיום:

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

לובי קריפטו גדלו; חלקים עצומים של קמעונאות ומוסדות רבים מחזיקים כעת ב-BTC ו-ETH. אבל מעט מאוד מוסדות מוכנים לבוא להגנת מטבעות הפרטיות. במקום לאפשר לכל הענף להיות מוכתם, רבים מסתפקים בלאפשר למטבעות הפרטיות להפוך לכבש הקורבן. - Haseeb Qureshi ( למה מטבעות הפרטיות לא המריא )

EIP-7503 מרגיש כאילו הוא הגיע בדיוק ברגע הנכון באבולוציה של Ethereum: עם יותר משתמשים מכל בלוקצ'יין והרבה מאוד השקעות מוסדיות, Ethereum פחות צפוי לסבול את אותו גורל כמו פרויקטים אחרים שניסו לספק פונקציונליות של תשלומים פרטיים בעבר. האם כמה בורסות יגבילו את המסחר ב-Ether אם אסימוני ETH שהוטבעו באופן פרטי יתחילו להסתובב? אוּלַי. אבל תריסר בורסות אחרות ישמחו לקחת על עצמה את האחריות הזו - כך נראה שיש אפקטי רשת חזקים .

למה אני אומר שה-EIP-7503 הגיע בזמן הנכון? הייתה תקופה בהיסטוריה של Ethereum שבה תמיכה בפרטיות בשכבת הבסיס הייתה משהו שכולם הרגישו שצריך לעשות מיד . אבל אחרים בקהילה הצביעו (בצדק) על מקרי הקצה הפוטנציאליים הקשורים לקידום Ethereum כ"טכנולוגיית פרטיות". הנה קטעים מתוך שרשור ישן בפורום Ethereum Magicians שדנים בצורך בפרטיות מוגברת ב-Ethereum:

האינטואיציות של גריפית' היו נכונות בעיקר בשנים הבאות, כאשר מטבעות קריפטוגרפיים רבים המוגדרים כברירת מחדל עומדים בפני הסיכוי להפוך למטבעות שוליים בשימוש רק על ידי סייפרפאנקים קשוחים (קבוצה המונה פחות מ-0.00001% מאוכלוסיית העולם). לשם השוואה, הערך והנמצא בכל מקום של Ether (ETH) רק עלו עד לנקודה שבה "דחיפה לכיוון טכנולוגיית הפרטיות" על ידי אימוץ EIP-7503 היא פחות מסוכנת מאשר לפני חמש שנים.

אם מיישמים שדרוג לתמיכה בהעברות פרטיות - אולי כדי למנוע לכידה רגולטורית הפוכה או למזער את המורכבות של שכבת הבסיס. חלופה מתאימה היא להעביר את האחריות ליישום EIP-7503 ל-Ethereum L2s ו-L3s. בהתחשב במפת הדרכים הממוקדת ב-Ethereum, יישום EIP-7503 באוסף הגיוני ועדיין שומר על המטרה של עיגון הפרטיות ב-Ethereum (למשל, בדומה לאוסף המטמיע ERC-4337 להפשטת חשבונות מקוריים).

גישה זו ליישום EIP-7503 קלה יותר מכיוון שלכל רשת L2 יש כבר חוזה גשר שיוצר ETH עבור משתמשים ב-L2. עם מנגנון להטבעת אסימוני ETH במקום, רול-אפים צריכים להוסיף רק רכיבים לאחסון מבטלים בשרשרת ויצירת/אימות הוכחות-צריבה כדי לתמוך בהעברות פרטיות בסגנון EIP7503. דוגמה לשרשרת שכבה 2 (L2) עם תוכניות לשילוב EIP-7503 בתשתית שלה היא Taiko כמתואר בבקשה להערה זו (RFC).

כאן, אנו רואים כי פרוטוקול כמו Taiko יכול להציע פרטיות עסקה - מבלי לבצע חילופים נרחבים לתשתית שלו - על ידי אימוץ EIP-7503. יש לכך יתרון מרכזי עבור צוותי פרוטוקול שאינם רוצים לבנות L2 ממוקד פרטיות בקנה מידה מלא (a la Aztec v2 ) אך רוצים לספק חוסר מעקב וחוסר קישוריות בסיסיים למשתמשים. כדאי לקרוא את ההצעה של צוות Nethermind ליישם EIP-7503 ב- Taiko כדי לקבל מושג כיצד ניתן ליישם EIP-7503 על ידי Ethereum L2.

EIP-7503 מאזנת גם את הצורך בפרטיות עם ציות לרגולציה, שמתיישרת עם המטרה של תנועת "פרטיות 2.0" של Ethereum: שמירה על פרטיות המשתמש, תוך הבטחה של שחקנים רעים שלא יוכלו לנצל תשתית פרטיות למטרות מרושעות. לפי יישום של EIP-7503 המתואר ב-Ethereum Research, אוסף שמאמצים את EIP-7503 יכול למנוע חזרה של בעיית Tornado Cash על ידי חסימה סלקטיבית של האקרים ורמאים ידועים מלהלבין כספים באמצעות העברות פרטיות.

כדי להשיג מאפיין זה, אנו דורשים מהמשתמשים להעביר רשימה של כתובות ברשימה שחורה ( blacklist[] ) כקלט למעגל שיוצר הוכחות ZK-SNARK לעסקאות צריבה. המעגל בודק שהכתובת של המשתמש המקבל ETH אינה חלק מהכתובות המאוחסנות ברשימה השחורה בעת יצירת הוכחת צריבה - העברה לכתובת ברשימה השחורה תיכשל אוטומטית מכיוון שהמעגל לא יכול ליצור הוכחה אם הקלט אינו עומד בכל תנאי התוקף.

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

ניהול שכר פרטי לארגונים ברשת

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

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

כיצד חברי DAO ישמרו על מנהלי דין וחשבון אם תשלומי תורמים/קבלנים פרטיים יושמו? זה תלוי ברמת הפרטיות ש-DAO מחפש ואיזו רמת הסתרה שחברי DAO יכולים לסבול. לדוגמה, כדי להוכיח כי AliceDAO אכן שילמה 20 ETH לאליס עבור עבודת DAO וכי הכסף לא שימש למטרות חלופיות, אליס יכולה לספק הוכחה שמראה שהיא יצרה את הכתובת הבלתי ניתנת לבזבז.

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

הפחתת התלות במערבלי מטבעות קריפטוגרפיים

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

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

מיקסרים כמו Tornado Cash גם יוצרים בעיה עם יציבות: אסימונים שנשלפים מבריכת ערבוב יכולים להפוך ל"נגועים" ובלתי אפשריים לשימוש או להחליף 1:1 באסימונים "נקיים" שלא עברו במיקסר. יש שרשור נהדר ב-Reddit שדן בבעיית הכספים המזוהמים ביתר פירוט, אותו אני ממליץ לקרוא. הנה כמה מהתגובות היותר מאירות מהשרשור הזה:

יכולות להיות לכך השלכות בעולם האמיתי: לדוגמה, אנשים בעלי פרופיל גבוה בקהילת Ethereum מצאו את עצמם לא מסוגלים לקיים אינטראקציה עם כמה ממשקי Dapp לאחר שהארנקים שלהם נשלחו כמויות לא רצויות של ETH ממאגר Tornado Cash. EIP-7503 מתואר כ"מערבל ללא חוזים" ועוקף את הבעיות האמורות על ידי שימוש בהעברות EOA ל-EOA רגילות לשריפת ETH והכנסת טביעה ישירה כדי להקל על משיכות ממאגר האנונימיות (לעומת שימוש בחוזה חכם).

יתרון נוסף של מיקסר ללא חוזים הוא גודל ערכת האנונימיות. עם Tornado Cash (ופרוטוקולים דומים כמו Railgun ), מערך האנונימיות קטן יותר - בקורלציה למספר המשתתפים - ומתכווץ עם הזמן. לעומת זאת, EIP-7503 הופך את כל סט הכתובות הניתנות לבזבז ולא ניתן לבזבז ב-Ethereum לסט אנונימיות. בהתחשב במרחב הכתובות הגדול, ניתן לומר בוודאות שלמחקני השרשרת שרוצים לדעת מאיפה הגיע ה-ETH שנשלח אל מקבל ההעברה הפרטית, עבודה קשה לפניהם.

האם יש חסרונות ביישום EIP-7503?

להלן כמה חסרונות פוטנציאליים של יישום EIP-7503:

בעיות עמידה ברגולציה

בעוד שניתוחים קודמים מצביעים על כך שסביר להניח ש-Ethereum לא יסבול את אותו גורל כמו Monero ו-Zcash אם יתחיל לתמוך בהעברות פרטיות, אי אפשר לחזות בפועל מה יקרה אם EIP-7503 יופעל. הנה תגובה של משתתף בשרשור הקוסמים של Ethereum שדנה בהשלכות על הרגולטורים:

בעוד פתרון פרטיות מקורי עבור Ethereum, הקהילה מתחילה להכיר בחשיבות ההליכה על החבל הדק בין פרטיות/אנונימיות וציות לרגולציה לאחר הנשורת מהסנקציות המכוונות לטורנדו קאש. רעיון זה משפיע במיוחד על העיצוב של דור חדש של פרוטוקולי פרטיות כמו Privacy Pools ו- Nocturne :

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

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

  
  

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

זה אפשרי (תיאורטית) לשפר את EIP-7503 על ידי הוספת גאדג'ט הרשימה השחורה שתואר קודם לכן, אבל זה עשוי לפתוח תיבת פנדורה של בעיות:

• מי זוכה לשמור על רשימת הכתובות ברשימה השחורה? האם אנו מבקשים מ-OFAC לספק רשימה של כתובות ברשימה השחורה ולהסתכן בכך שממשלה תחליט מי יבצע עסקה פרטית ב-Ethereum? האם אנו מסתכנים בהפעלת מזלג שנוי במחלוקת אם קבוצה של מאמתים מסרבת לצנזר העברות מחשבון אחד או יותר הרשומים ברישום blacklistedAddresses ?
• אם EIP-7503 מיושם על ידי אוסף, האם ה-DAO אחראי על תחזוקת רישום blacklistedAddresses ? או שמא צוות המייסדים מתקשר לשירותים של חברות פורנזיות כמו Chainalysis, Elliptic ו-TRM Labs כדי לספק מידע לגבי הכתובות שיש להגביל מלקבל העברות פרטיות? אילו בעיות יכולות להופיע אם חברה למטרות רווח מחליטה מה קורה בשכבת הבסיס של רולאפ?
• אם אוסף מחליט להסיר הרשאות אדמיניסטרטיביות ולהפוך את החוזים המאמתים/החוזים לבלתי ניתנים לשדרוג, כיצד הוא מבטיח ששחקנים גרועים לא יתחילו להעביר כספים דרך הפרוטוקול? האם ניתן לטפל בסינון סלקטיבי של עסקאות מנצלים ידועים בשכבות העליונות של המחסנית (למשל, ברמת הרצף או המאמת)? מה הלוגיסטיקה הכרוכה?

אלו הן רק כמה שאלות שצריך לענות עליהן לפני ש-Ethereum (או Ethereum L2s) יאמצו את EIP-7503. קריפטו עדיין במים לא ידועים, אבל זה עוזר לבצע הרבה Murphyjitsu , במחשבה על מקרים פוטנציאליים פוטנציאליים מראש, בעת קבלת החלטות שיש להן השלכות משמעותיות על הישרדותו ארוכת הטווח של הפרוטוקול.

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

ריכוזיות פוטנציאלית הקשורה לאסימוני ERC-20

הטמעת EIP-7503 דורשת שדרוג ל-EVM כדי לתמוך בסוג עסקה חדש המקבל קבלה צריבה ומזכה את יתרת הנמען עם ETH שנצרבה בעסקה הקודמת. לקוחות ביצוע יצטרכו גם לשדרג כדי לתמוך ב-Sparse Merkle Tree (SMT) לאחסון מבטלים וליישם מעגלים מחוץ לשרשרת להפקה ואימות של הוכחות-לצריבה בשם המשתמשים.

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

בעוד שחוזה ERC-20 מפשט את היישום של EIP-7503, גישה זו מציגה מחדש את בעיית הריכוזיות והצנזורה. אנחנו יכולים להפוך את האסימון ERC-20 לבלתי ניתן לשדרוג ובלתי ניתן לשליטה כמו Wrapped Ether (WETH) כדי לחסל וקטורים של ריכוזיות, אבל זה לא יכול לעזור בבעיות כמו חילופי הסרת האסימון.

כמו כן, עלינו לשים לב שקל יותר לזיהוי פלילי על השרשרת לזהות חשבונות המקיימים אינטראקציה עם חוזה ה-ERC-20 ולמקם את הכתובות הללו ברשימה שחורה - אם הרגולטורים מחליטים ללכת אחרי מטבעות קריפטוגרפיים בעלי תודעת פרטיות יותר שמסתובבים ב-Ethereum. מכיוון שזו הבעיה ש-EIP-7503 תוכנן לפתור, ייתכן שיהיה קשה לראות כיצד ההצעה ליצור "אסימון ERC-20 פרטי" היא שיפור.

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

תקורה מוגדלת של מו"פ

EIP-7503 מגיע עם דרישה לבנות, לבדוק, לבקר ולתחזק תשתית קריפטוגרפית מורכבת ומתקדמת הנדרשת לתמיכה בעסקאות אנונימיות ופרטיות. לפחות, התיאור של Nethermind של יישום L2 של EIP-7503 ושל Nobitex Labs' EIP-7503 Chain proof-of-concept, שניהם מצביעים על כמות הגונה של מאמץ הנדסי ילך ליצירת מעגלי ZK-SNARK להפקה ואימות של הוכחות EIP-7503 .

חשוב גם לציין שפרימיטיבים קריפטוגרפיים כמו ZK-SNARKs עדיין לא עברו בדיקות קרב מספיק כדי שמפתחי פרוטוקולים יוכלו ליישם אותם בביטחון מוחלט. לשם המחשה, Zcash תיקן באג שיאפשר למשתמש לא ישר לספק הוכחות מזויפות לבעלות על נכסים ולהטביע כמות אינסופית של אסימונים בשנת 2018. דיברתי גם על הבריחה הצרה של צוות Tornado Cash מניצול פוטנציאלי ב-2019.

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

תחום מורכב נוסף נובע מהדרישה מהמאמת EIP-7503 לאמת את כותרת הבלוק B הכלולה בהוכחה שנוצרה על ידי המשתמש. ה-EVM מאחסן גיבוב של 128-256 הבלוקים האחרונים, כך שהמאמת על השרשרת לא יכול לאמת ללא אמון כותרות בלוק מטווח ארוך יותר.

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

EIP-210 אינו הכרחי לחלוטין מכיוון שלמשתמשים יש לפחות שעה אחת ( 14 seconds * 256 blocks ) ליצור ולהגיש הוכחה שניתן לאמת באמצעות EVM. ובכל זאת, מתן חופש למשתמשים לעכב את פדיון ההפקדות הנשלחות לכתובת צריבה משפר את ה-UX והופך את תהליך המשיכה לעמיד יותר בפני יצירת אשכולות וטכניקות ניתוח דומות.

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

צמצום מערכי האנונימיות

בזמן הפעלת EIP-7503, האנונימיות שהוגדרה למשתמש שטבע ETH בבלוק מס' 11000 תכלול את כל EOAs של Ethereum עם יתרת ETH חיובית ואפס עסקאות יוצאות. זה חיוני למאפיין אי-המעקב של עסקאות אנונימיות: אם עסקה שורפת ETH, אי אפשר לזהות אותה כעסקת צריבה מכיוון שכתובת שלא ניתן לבזבז נראית כמו כתובת Ethereum רגילה.

עם זאת, מספר הכתובות שבהן יתרת החשבון נשארת סטטית ולא נשלחות עסקאות יקטן עד לנקודה שבה רק כתובות צריבה יהוו את ערכת האנונימיות. לפיכך, מערך האנונימיות מתחיל להיראות כמו ערכות האנונימיות של מיקסרים מבוססי חוזים כמו Tornado Cash וכלי פרטיות מהדור החדש כמו Privacy Pools ו-Railgun (מה שמרמז על הפחתה הדרגתית בהבטחות הפרטיות של EIP-7503).

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

למרות הפחתת מערך האנונימיות, EIP-7503 עדיין שימושי עבור ההכחשה הסבירה שהוא מציע. נניח שמישהו יוצר סערה ב-crypto-Twitter ומאשים את אליס בשריפת ETH בכוונה (על ידי שליחה לכתובת שאינה ניתנת לבזבז) מתוך כוונה למשוך כספים לכתובת חדשה מאוחר יותר. לאליס יש הכחשה מתקבלת על הדעת והיא יכולה להתמודד עם הטענה בטענה:

• "שלחתי את ETH לכתובת בטעות. האם אתה יכול להוכיח שלא טעיתי בהקלדת הכתובת ב-MetaMask?”
• "יש לי את המפתח הפרטי של הכתובת אבל אני לא יכול לשתף אותו. לא היית מבקש את המפתח הפרטי שלי עכשיו, נכון?"
• "יש לי את המפתח הפרטי לכתובת, אבל איבדתי אותו. אתה יכול להוכיח שלא איבדתי את המפתח הפרטי שלי?"

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

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

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

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

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

הערה : הטכניקה השנייה היא הרחבה מוצעת ל-EIP-7503 ונראה שאינה ריאלית עם העיצוב הנוכחי. למשתמשים לפצל משיכות, יש צורך בתכונה לפיצול מבטלים כך nullifier 1 מעניק את הזכות להטביע חלק מהיתרה של כתובת הצריבה, nullifier 2 מעניק את הזכות להטביע חלק נוסף מהיתרה וכו'.

מַסְקָנָה

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

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

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

אם נהניתם לקרוא את המאמר הזה, שקול לשתף אותו עם מישהו שעשוי למצוא אותו אינפורמטיבי והירשם לניוזלטר מחקר 2077 לצלילות עמוקות יותר על הצעות שיוצאות מהאקולוגית של EIP. אנו נמשיך להתמקד בפתרונות פרטיות ב-Ethereum ונתכנן לשחרר צלילה עמוקה ב- ERC-5564 (תקן להפקת כתובות חמקנות ושליחת עסקאות כתובות חמקנות ב-Ethereum).

הישארו מעודכנים!

הערת המחבר: מאמר זה מתפרסם גם כאן .