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

היא הצעה לשיפור Ethereum (EIP) המציגה מנגנון לביצוע העברות לשמירה על הפרטיות ב-Ethereum. בעוד שראינו מאמצים רבים להפוך העברות בשרשרת לפרטיות, כולל מערבלי מטבעות קריפטוגרפיים כמו Tornado Cash, EIP-7503 הוא פתרון שכבת פרוטוקול שהופך את Ethereum . EIP-7503: Zero-Knowledge Wormholes לפרטי כברירת מחדל זהו שיקול חשוב: גישות של שכבת יישומים לפרטיות כמו Tornado Cash הן "הצטרפות", שלעתים קרובות יש לה השלכות שליליות על המשתמשים. יישומים ממוקדי פרטיות גם רגישים יותר לצנזורה; לדוגמה, משתמשים רבים (במיוחד אזרחי ארה"ב) לא הצליחו ליצור אינטראקציה עם Tornado Cash לאחר שהמשרד לבקרת נכסים זרים (OFAC) . הכניס את כתובות החוזה של הפרוטוקול לרשימה השחורה ב-2022 למרות הסנקציות של OFAC, Tornado Cash עדיין פועל מכמה סיבות: חוזי הליבה המיישמים את פונקציונליות ערבוב הנכסים של Tornado Cash אינם ניתנים לשינוי ומאוחסנים לצמיתות בשרשרת. מאז העיקרית האתר ירד למצב לא מקוון, פרויקטים עצמאיים עשו שימוש חוזר בקוד חוזה מהיישום המקורי של Tornado Cash כדי ליצור גרסאות חדשות כמו . tornado.cash טורנדו קאש נובה פרוטוקול Tornado Cash הוא לרוב "בלתי ניתן לשליטה". צוות ההקמה של טורנדו קאש הסיר את הבקרות הניהוליות לאחר מכן לתקן באג שיאפשר לתוקפים ליצור הוכחות תקפות להפקדות מזויפות ולרוקן כספים (הופקדו באופן לגיטימי). לפיכך, צוות המייסדים לא יכול היה להפעיל באופן חד צדדי מתג הרג וללחוץ עליו "לכבות" את הפרוטוקול למרות . ביצוע שדרוג חירום מעצר בשנת 2023 הגורמים שהוזכרו לעיל פירושם שאנשים עדיין מסוגלים להשתמש ב- Tornado Cash היום, גם אם ניתוחים מראים שיצרני בלוקים ב-Ethereum . עם זאת, בדיוק כמו בימי הסנקציות שלפני OFAC, לא כל עסקה שניתבה דרך פרוטוקול המיקסר של Tornado Cash הייתה לגיטימית. לשם המחשה, מציע שלפחות שתי התקפות בעלות פרופיל גבוה בשנת 2023 (הניצול של אוילר פיננסים ב-197 מיליון דולר ומשיכת השטיח של אנוביס DAO של 60 מיליון דולר) מומנו על ידי כספים שנמשכו מטורנדו קאש, או השתמשו במיקסר להלבנת גנוב. כספים והסתרת העברות יוצאות. מבטלים עסקאות המתקשרות עם החוזים של הפרוטוקול מאמר מאת Arkham Intelligence בהתחשב בכך שטורנדו קאש לא פתר את הבעיה של שחקנים גרועים המנצלים לרעה את הפרטיות ברשת, מדוע שנרצה ליישם תכונה לביצוע העברות פרטיות ברמת הפרוטוקול? זה לא ? למה בכלל יש צורך בעסקאות פרטיות מלכתחילה? האם בלוקצ'יין כמו 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 alice@gmail.com Ethereum אינו פרטי מכיוון שה-blockchain שומר רישום עבור כל עסקה, כולל כמה הועבר ואיזה פעולות בשרשרת ביצעה העסקה. גם Ethereum אינו אנונימי, מכיוון שמידע על חשבונות שמבצעים עסקאות בבלוקצ'יין (מזוהה על ידי ) הוא ציבורי. אתה לא יכול להשתמש בשם אמיתי כמו "אליס הופקינס" עבור חשבון Ethereum שלך, אבל שימוש באותה כתובת עבור כל עסקה מאפשר לזיהוי פלילי בלוקצ'יין לתאם עסקאות לזהות שלך בעולם האמיתי - באמצעות טכניקות כמו , . כתובות ניטור כתובות IP קיבוץ כתובות וגרף ניתוח Ethereum מתואר אפוא במדויק כשם ואינו יכול להבטיח אנונימיות או פרטיות. וזה רע עבור פלטפורמה שצפויה להפוך לשכבת ההתנחלות עבור האינטרנט של הערך העתידי. לצורך ההקשר, הבנקים כבר מספקים רמה מסוימת של פרטיות למשתמשים על ידי אחסון נתונים פיננסיים במאגרי מידע מרכזיים עם מנגנוני בקרת גישה קפדניים למניעת גישה בלתי מורשית. בדוי זוהי "פסאודו-פרטיות" שכן לבנק ולספק תשתית מסד הנתונים יש גישה למידע זה ויכולים לעשות איתו מה שהם רוצים (למשל, להקפיא תשלומים למדינות מסוימות כדי לעמוד בסנקציות המבוססות על ניתוח יעד ההעברה). אבל במקרה קלאסי של "לבחור בין השטן לים הכחול העמוק", סביר להניח שהאדם הממוצע יבחר פרטיות על פני חוסר פרטיות, מה שפוסל פתיחת חשבון Ethereum וכל פעולה בשרשרת גלויה לעולם. קצת רבים זיהו את הבעיה הזו, במיוחד משום שהיא מרחיקה משתמשים מטכנולוגיות מבוזרות כמו Ethereum לפתרונות ריכוזיים המציעים הבטחות פרטיות מעט טובות יותר על חשבון התנגדות לצנזורה ושקיפות (בין היתר). לדוגמה, של ויטאליק מספק טיעון נהדר לחשיבות הפרטיות לסיכויי אימוץ המוני של Ethereum: שלושת המעברים ללא השלישי [מעבר להעברות שומרות הפרטיות], Ethereum נכשל מכיוון שכל העסקאות (ו-POAPs וכו') זמינות באופן פומבי עבור כל אדם, פשוטו כמשמעו, היא הקרבת פרטיות גבוהה מדי עבור משתמשים רבים, וכולם עוברים לפתרונות ריכוזיים אשר לפחות קצת להסתיר את הנתונים שלך. - ויטליק בוטרין הוא מאמץ לתקן חלק מהבעיות שתוארו קודם לכן, במיוחד חוסר האנונימיות של שולחי העסקאות. ההצעה מציגה אמצעי עבור כתובות להרוס בכוונה את Ether (ETH) על ידי שליחת כספים , ויצירת הוכחה ZK-SNARK לאימות הפקדה לכתובת שאינה ניתנת להוצאה. אם ההוכחה הזו עוברת את האימות, כמות של אסימוני ETH (שווה ליתרת הכתובת הבלתי ניתנת לבזבז) מוטבעת לכתובת חדשה לבחירתו של המשתמש - תוך שבירת הקישור בין כתובות השליחה והקבלה הכרוכות בהעברת הכספים. EIP-7503 לכתובת שאינה ניתנת להוצאה EIP-7503 שואל רעיונות מפרוטוקולי פרטיות קיימים כדי להפעיל עסקאות שומרות פרטיות ב-Ethereum. לדוגמה, ההצעה מקשה על מעקב אחר כספים שהתקבלו בעסקת הטבעה למקור מסוים על ידי הפיכת כל הסט של כתובות Ethereum עם יתרת ETH ואפס עסקאות יוצאות . אתה לא יכול לזהות בקלות את הכתובת האחראית לשריפת ה-ETH שכתובת נטבעה מחדש בעסקה הבאה: יכולה להיות אחת ממיליוני הכתובות שיש להן יתרה שאינה אפס אך לא יזמו עסקת Ethereum. לסט אנונימי A B A הדבר דומה לרעיון של ערבוב כספים ממקורות שונים למאגר אחד ולאפשר למפקידים למשוך כספים מהמאגר באמצעות כתובת אחרת. עם זאת, 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 מיליון דולר. פרט לכמה משתמשים אומללים ששולחים כספים לכתובת האפס בטעות, הרוב המכריע של המשתמשים ששולחים אסימונים שנשלחים לכתובת האפס (שדורש להגדיר את כתובת האפס בתור הנמען) או לוקחים את האסימונים האלה בכוונה. מחוץ למחזור. יוצרים חוזה אינו מציין פונקציות לצמצום היצע של אסימון, מה שאומר שלאסימונים ישנים יותר כמו WETH (Ether עטוף) אין דרך להבטיח שמשתמשים מוציאים נכסים עטופים מהמחזור לפני משיכת ההפקדה המקורית. עם זאת, שליחת אסימוני WETH לכתובת האפס הופכת אותם לבלתי ניתנים להוצאתם ומדמה הפחתה באספקת ה-WETH במחזור בכל פעם ש-ETH נסוג מחוזה העטיפה של WETH. אם אתה תוהה כיצד WETH שומר על יחס של 1:1 עם ETH מקורי, הנה התשובה שלך. תקן האסימון המקורי של ERC-20 EIP-7503 עושה שימוש במנגנון דומה כדי לאפשר למשתמשים לצרוב אסימוני ETH ואסימוני מנטה לכתובת אחרת ב-Ethereum עם טוויסט קטן. במקום לבקש ממשתמשים לשלוח כספים לכתובת צריבה אחת, EIP-7503 דורש מהמשתמשים ליצור כתובת צריבה ייחודית עבור כל עסקה לפני הטביעת ETH לכתובת אחרת. 2. משתמשים יוצרים הוכחה פרטית לצריבה או "קבלת צריבה" שמוכיחה שהם שרפו כמות כלשהי של ETH בעסקה קודמת על ידי שליחתו לכתובת צריבה שליחת כספים לכתובת צריבה (שנוצרה על פי מפרט EIP-7503) היא המקבילה לזריקת מזומנים לחור תולעת - לעולם לא ניתן לשחזר אותו. אבל אתה להוכיח ידע על משהו שנשלח לחור התולעת באמצעות ZK-SNARK ( ero- nowledge rgument of nowledge); מכאן המונח "חורי תולעת אפס ידע". יכול Z K Succinct A K הוכחת השריפה היא פרטית מכיוון שמשתמש רק צריך להוכיח שהוא שלח אסימונים לכתובת שאין לבזבז אותה מבלי לחשוף בטקסט רגיל. יצירת הוכחת צריבה דורשת הוכחה שכתובת הצריבה באמת בלתי ניתנת לבזבז. מַדוּעַ? בקשה למשתמשים לשרוף ETH מקורי לפני הטבעת אסימוני ETH חדשים לכתובת הנמען מבטיחה שוויון (בערך ובניתוק) של שני סוגי הנכסים, אם המשתמשים יכולים מאוחר יותר למשוך כספים מכתובת הצריבה, הצמד 1:1 בין ETH מקורי לנטבע אסימוני ETH יפסיקו להתקיים. A את A 3. משתמשים מטביעים אסימוני ETH על ידי שליחת הוכחה פרטית לצריבה לצומת מלא שמזכה משתמש בסכום שווה ערך לפיקדון שהועבר לכתובת הצריבה EIP-7503 מציג סוג עסקה חדש ב-EVM (Ethereum Virtual Machine) שמקבל הוכחת שריפה ונמען כקלט ומטביע אסימוני ETH חדשים לכתובת השליחה אם ההוכחה מאומתת בהצלחה. כדי למנוע טבעת ETH פעמיים עבור אותה עסקת צריבה, ערך "בטל" מיוחד מצורף לכל הוכחת שריפה כדי לעקוב אחר השימוש בכתובת. אם ה-ETH שנשלח לכתובת שלא ניתן לבזבז מוטבע מחדש בהצלחה, המבטל מונע ממשתמש לא ישר ליצור הוכחה חוקית חדשה לצריבה עבור כספים שנשלחו קודם לכן לכתובת (כלומר, התקפות כפולה). חשוב לציין, המבטל מזהה כתובת בשימוש מבלי להדליף מידע על הכתובת בטקסט רגיל. עם ההקדמה הזו ברמה גבוהה, אנחנו יכולים כעת לצלול לפרטים ברמה הנמוכה של היישום של EIP-7503. הסעיפים הבאים ידונו בפרטי מפתח של יישום EIP-7503 כגון: יצירת הכתובת שלא ניתן לבזבז יצירת הוכחות צריבה פרטיות אימות של הוכחות צריבה פרטיות טביעת ETH למקבלי העברות פרטיות יצירת הכתובת שלא ניתן לבזבז כתובת Ethereum רגילה היא 20 הבתים הראשונים של ה-hash Keccak256 של שנוצר של החשבון (המפתח הפרטי הוא מספר שלם שנוצר מביטוי מנמוניק או סיד). גם מפתחות פרטיים וגם מפתחות ציבוריים נוצרים באמצעות (ECDSA). ECDSA הוא נושא מורכב ("מורכב" הוא לשון הרע המועדף עליי ל"יש הרבה מתמטיקה"), אבל הנה כמה משאבים - מדורגים מהמתחילים למומחה בנושא: המפתח הציבורי מהמפתח הפרטי אלגוריתם החתימה הדיגיטלית של עקומה אליפטית (בלוג Cloudflare) פריימר (קל יחסית להבנה) בקריפטוגרפיה של עקומה אליפטית (ויקיפדיה) אלגוריתם חתימה דיגיטלית עקומה אליפטית (וויקי ביטקוין) אלגוריתם חתימה דיגיטלית עקומה אליפטית (קריפטוגרפיה מעשית למפתחים) ECDSA: חתימות עקומה אליפטיות המפתח הציבורי נגזר על ידי הכפלת המפתח הפרטי (הנקרא סוד או בקיצור ) בערך "מחולל" מיוחד כדי לייצר ערך חדש בצורת . נוצרת על ידי הפעלת המפתח הציבורי דרך פונקציית ה-hash Keccak256 ולקיחת 20 הבתים הראשונים של מחרוזת ה-hash. בסימון פסאודו-מתמטי, הפעולה נראית כך: , כאשר היא הכתובת, הוא המפתח הסודי או הפרטי, ו- היא נקודת המחולל בעקומה האליפטית. s G pubKey = privKey * G הכתובת A = K(s * G) A s G הכתובת, המפתח הציבורי והמפתח הפרטי משרתים מטרות שונות מאוד: הכתובת משותפת לציבור ומזהה את החשבון שמקבל כספים שהועברו בעסקה. המפתח הפרטי משמש לחתימה על הודעה המורה לרשת להעביר אסימונים מחוץ ליתרת כתובת ויש לשמור בסוד. המפתח הציבורי מאפשר לוודא שחתימה של עסקה נוצרה על ידי המפתח הפרטי המתאים. הפריט האחרון ברשימה מצביע על פרט עדין: אפשר להוציא כספים שנשלחו לכתובת רק אם אתה שולט במפתח הפרטי - כלומר אתה מכיר את המפתח הפרטי ששימש ליצירת המפתח הציבורי, שממנו הכתובת נגזרה. אם אינך יודע את המפתח הפרטי של כתובת, או שהמפתח הפרטי נשלט על ידי מישהו אחר, אינך יכול להוציא כספים מכתובת זו. כיצד נדע אם היתרה של כתובת אינה ניתנת לבזבז? אנו יכולים להתחיל בבחירה אקראית של ערך אקראי של 20 בתים עבור וניצול מאפיין מיוחד של פונקציות גיבוב קריפטוגרפי** המכונה . במילים פשוטות, התנגדות לפני תמונה פירושה שאיננו יכולים למצוא ערך כך ש- (ה-hash של ) זהה ל- אם נבחר באקראי. בסימון פסאודו-מתמטי, טענה זו היא בצורה: . A A התנגדות קדם תמונה x H(x) x A A H(x) ≠ A היא של ה-hash (הפלט של פונקציית ה-hash) ו- היא התמונה המוקדמת של פונקציית ה-hash (הקלט לפונקציית ה-hash). מציאת הערך של עבור קשה בגלל (א) המספר העצום של מספרים שלמים אפשריים (ב) האופן שבו תשומות עוברות מניפולציה על ידי פונקציית Hash כדי לייצר פלט. לפיכך הדרך היחידה שבה אתה יכול "לנחש" ערך עבור שמביא ל- היא אם יש לך כמות עצומה של כוח מחשוב ומספיק זמן בידיים שלך כדי לעבור מספר עצום של חישובים כדי למצוא . A התמונה x x H(x) = A x A H(x) = A אמנם זה לא מחלקה Cryptography 101 שלך, אבל ההסבר הקודם לוכד תכונה מרכזית של מערכות הצפנה מודרניות. תכונת התנגדות הקדם-תמונה של פונקציות גיבוב ממלאת גם תפקיד מפתח ב-EIP-7503: אם הוא ערך אקראי של 20 בתים, יש לנו ביטחון סביר שמשתמש לא יכול לגזור את המפתח הפרטי אין לו דרך להוציא כספים מהכתובת. כלומר, אי אפשר לחשב , כאשר היא כתובת הצריבה, הוא המפתח הפרטי או הסוד, ו- היא נקודת המחולל (הערה קטנה: שווה ל- מהפסקה הקודמת). A 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 התנגדות להתנגשות חשובה למניעת זיוף (בין היתר): לשני אנשים שמקבלים שני כניסות שונות תמיד יהיו מחרוזות גיבוב שונות ואחד לא יכול לטעון שהוא בעל הקלט הידוע רק לאדם השני. גרסה נוספת של התנגדות התנגשות היא שאינך יכול למצוא , כאשר ו- הם ממשפחות שונות של פונקציות גיבוב. במילים אחרות, חישוב ה-hash של באמצעות אלגוריתמי גיבוב שונים אינו יכול "להתנגש" ולהגיע לאותו פלט. H1(x) = H2(x) H1 H2 x כדי להבין מדוע זה אפשרי, נמציא דוגמה מתוכננת כדי להסביר כיצד פועלות פונקציות ה-hash בשלב הבא. Interlude: פונקציות גיבוב קריפטוגרפיות עבור noobs נשתמש בדוגמה מתוכננת כדי להסביר כיצד פועלות פונקציות גיבוב קריפטוגרפיות וכיצד מובטחות מאפיינים חשובים כמו ועמידות בפני . הסבר זה מפשט מושגים מסוימים למען הקיצור והנגישות, עם זאת (קרא מאמר על פונקציות גיבוב אם אתה קריפטוגרף שאפתן): התנגדות להתנגשות התקפות טרום-תמונה אליס, בוב, שריל ומקס שייכים למפלגות פוליטיות יריבות: אליס ובוב הם חברים במפלגה הכחולה, בעוד שריל ומקס שייכים למפלגה האדומה. סוכני המפלגה הכחולה ואנשי המפלגה האדומה רוצים לחלוק מידע בינם לבין עצמם מבלי להדליף פרטים רגישים לחברי המפלגה היריבה ולהמציא באופן עצמאי קודים שונים להצפנת הודעות. הקוד של Blue Party ידוע בתור אלגוריתם האותיות הכפולות, בעוד Red Party משתמש בגרסה הנקראת אלגוריתם האותיות המשולשות. הקוד פשוט מאוד: אנו מחליפים אלפבית במספרים בעת כתיבת הודעות - כל מספר במחרוזת ההודעה מתייחס לאות במיקום מסוים באלפבית. סיביות "ההצפנה" מגיעות מהאופן שבו אנו בוחרים מספרים לייצוג אלפבית: בקוד ה- Blue Party "אות כפולה", אנו מחלקים כל מספר בשניים ומשתמשים במספר המתקבל (n) כדי למצוא את האות במיקום ה-n של האלפבית. לדוגמה, אנו יכולים להצפין את "BOY" כ- : 4/2 = 2 ("B" היא האות השנייה באלפבית); 30/2 = 15 ("O" היא האות ה-15 באלפבית); 50/2 הוא 25 ("Y" היא האות ה-25 באלפבית). 4-30-50 בקוד המפלגה האדומה "אות משולשת", אנו מחלקים כל מספר בשלוש ומשתמשים במספר המתקבל (n) כדי למצוא את האות במיקום ה-n של האלפבית. לדוגמה, אנו יכולים להצפין את "BOY" כ- : 6/3 = 2 ("B" היא האות השנייה באלפבית); 45/3 = 15 ("O" היא האות ה-15 באלפבית); 75/3 = 25 ("Y" היא האות ה-25 באלפבית). 6-45-=75 דוגמה זו משתמשת בהצפנה עבור אותה הודעה, אך אנו יכולים לצפות שאנשי המפלגה הכחולה והמפלגה האדומה יחליפו הודעות שונות בפועל (למשל, "מקס הוא אידיוט" (אליס → בוב) ו"חברי המפלגה הכחולה הם מפסידים" ( שריל → מקס) וכו'). עם זאת, הצפנת אותה הודעה עם קודים שונים שימושית להסבר התנגדות התנגשות בפונקציות גיבוב קריפטוגרפיות: כאשר "BOY" מוצפן באמצעות אלגוריתם "אות כפול" של Blue Party ואלגוריתם "אות משולשת" של מפלגת Red Party, התוצאות שונות מאוד ( ו- , בהתאמה). חבר במפלגה הכחולה אינו יכול ליצור , אלא שהוא משתמש באלגוריתם ההצפנה של המפלגה האדומה; גם חבר במפלגה האדומה לא יכול להפיק כמחרוזת הודעות, אלא שהוא משתמש באלגוריתם ההצפנה של המפלגה הכחולה. מכיוון שכל צד שומר על פרטי אלגוריתם ההצפנה, אנו יודעים שחבר מפלגה מתחרה אינו יכול לפענח הודעה שלא נועדה עבורו. 4-30-50 6-45-75 6-45-75 4-30-50 פונקציות גיבוב קריפטוגרפיות שונות מאלגוריתמי הצפנה: פונקציות גיבוב הן ואין להן דרך לגזור תשומות מהפלט, בעוד שלאלגוריתמי הצפנה כמו אלו מהדוגמה יש לפענוח הקלטים לפונקציית ההצפנה. אבל לפונקציות גיבוב ואלגוריתמי הצפנה יש קווי דמיון, במיוחד בתחום ההתנגדות להתנגשות. בדיוק כמו שלא הצלחנו למצוא את אותו פלט (הודעה מוצפנת) עבור קלט בודד באמצעות אלגוריתמי הצפנה שונים, איננו יכולים למצוא את אותו פלט (hash) עבור קלט בודד באמצעות פונקציות hash שונות. חד-כיווניות מפתח אנו יכולים לנצל את ההתנגדות להתנגשות של פונקציות גיבוב כדי ליצור כתובות בלתי ניתנות לשריפת נכסים כנדרש על ידי EIP-7503. ראשית, אנו מבקשים מהמשתמשים לבחור ערך סודי (המפתח הפרטי לחשבון Ethereum), לחשב את ה-hash Keccak256 של כדי לגזור את המפתח הציבורי, ולגבש את המפתח הציבורי כדי לגזור כתובת . לאחר מכן אנו מבקשים מהמשתמש ליצור כתובת חדשה על ידי גיבוב הערך הסודי עם פונקציית גיבוב שונה המסומנת כ- ולקחת את 20 הבתים הראשונים של הפלט ככתובת. להוצאה מוכח s s * G A B s H המטרה שלנו? אנחנו רוצים לסיים עם , כאשר מייצג את פונקציית ה-hash Keccak256 ו- מייצגת פונקציית hash ממשפחה אחרת של פונקציות hash. מטעמי ביצועים, אנו רוצים ש- יהיה "ידידותי ל-ZK" (כלומר, אימות התוצאה של בתוך מעגל צריך להיות זול ומהיר). K(x) ≠ H(x) K H H H(x) אנחנו לא יכולים לדעת את המפתח הציבורי עבור כי הכתובת נוצרה באופן אקראי במקום לחשב את ה-hash Keccak256 של (מפתח פרטי כפול מחולל), מה שאומר שגם המפתח הפרטי עבור אינו ניתן לדעת. אם אנחנו לא יודעים את המפתח הפרטי של , לא נוכל לייצר חתימות חוקיות להודעה שמוציאה את היתרה של עם תהליך אקראי מוכח ליצירת כתובות שלא ניתן לבזבז, יש לנו כעת דרך למשתמשים לצרוב ETH לפני הטביעה מחדש של נכסים. B s * G B B B. יצירת הוכחת השריפה הפרטית כיצד אנו מוכיחים שמשתמש מסוים שלח את ETH לכתובת שאינה ניתנת לבזבז שאינה ניתנת לבזבז נוצרה על ידי אותו משתמש? הבדיקה הראשונה נחוצה כדי להימנע מהטבעה מזויפת של ETH (אנחנו לא מטביעים אסימוני ETH חדשים אלא אם כן יש לנו הוכחה שמשתמש שרף ETH בעבר), אבל הבדיקה השנייה חשובה גם היא: אנחנו צריכים לדעת שכתובת נוצרה על ידי משתמש - אחרת, נדרוש פיסת מידע (למשל, ה-hash של עסקת הצריבה) כדי לאשר שמשתמש אינו מנסה לתבוע הפקדה של אדם אחר. והכתובת מכיוון שאנו רוצים להימנע מהדלפת מידע על השתתפותו של משתמש בפרוטוקול הפרטיות, אנו מאפשרים למשתמשים במקום זאת ליצור המוכיחה את הידע של (הערך הסודי שפורץ לגזירת כתובת הצריבה) מבלי לשחרר באופן ציבורי. הוכחת אפס הידע קובעת את ידיעת המשתמש על כתובת שנגזרת מהתוצאה של : מכיוון ש- נבחרה בסתר, אדם אחר אינו יכול לחשב ערך שונה כך ש- . זה נובע מתכונת ההתנגדות להתנגשות של פונקציות גיבוב שתוארו קודם לכן. הוכחת אפס ידע s s B H(s) s H(x) H(s) = H(s) הסתרת מונעת משחקנים זדוניים לממש פיקדון של משתמש על ידי הגשת הוכחה המאשרת את הידע על (המשמש ליצירת כתובת שאינה ניתנת לבזבז) למאמת EIP-7503. סעיף זה מפרט מדוע אנו מסוגלים ליצור הוכחה של אפס ידע שמוכיחה מבלי לדרוש מהמאמת לחשב באופן עצמאי. אבל אתה יכול לקרוא ואת כדי לקבל רקע על שימוש ב-ZK-SNARKs כדי להוכיח את תקפותו של חישוב מבלי לחשוף את התשומות. s הסוד H(s) = A H(s) את תוכניות האריתמטיקה הריבועית של Vitalik: Zero To Hero המאמר שלי על ZK-EVMs אנו מתארים את הוכחת אפס הידע המאמתת העברת כספים של משתמש לכתובת שאינה ניתנת לבזבז (המכונה ) כ"הוכחה לצריבה" או "קבלת צריבה". הוכחת השריפה מוכיחה את ההצהרות הבאות: כתובת צריבה המשתמש מכיר כתובת ואת הערך הסודי שהועבר לגיבוב כדי לגזור את (כלומר, ). זהו בדיקה שאין לבזבז את הכתובת על ידי אישור ש- היא תוצאה של גיבוב עם פונקציית hash (ידידותית ל-ZK) השונה מפונקציית ה-hash Keccak256 המשמשת ליצירת כתובות Ethereum שניתן לבזבז. A s A H(s) = A A s לכתובת יש יתרת ETH חיובית השווה או גדולה מ- ( ). זוהי בדיקה שהסכום שמשתמש מנסה להטביע לכתובת המקבל זהה לסכום שהופקד בכתובת הבלתי ניתנת לבזבז. A b b ≥ b' בעוד שהוכחת מס' 1 היא פשוטה יחסית, הוכחת מס' 2 דורשת הצהרת דברים מסוימים לגבי מצבו של Ethereum. בפרט, עלינו להוכיח כי (א) הכתובת הבלתי ניתנת לבזבז קיימת במשפט של Ethereum ו-(ב) היתרה הנטענת של הכתובת הבלתי ניתנת להוצאה תואמת את היתרה הקשורה לכתובת במשפט המדינה. זה מחייב העברת לכתובת כקלט למעגל שיוצר את הוכחת הצריבה. הקנוני הוכחת מרקל A הוכחת מרקל מורכבת מהעלים של ה-Markle Patricia Trie (MPT) הנדרשים כדי לחשב את הנתיב מהעלה שאנו מנסים להוכיח (הכתובת ) לשורש ה-Markle Trie (השורש הטרי הוא גם חלק מה מרקל הוכחה). אנו זקוקים להוכחה לכך ששורש המצב - המשמש לאימות הוכחת Merkle - הוא גם קנוני, ולכן אנו דורשים מהמשתמש להעביר כותרת בלוק כקלט נוסף למעגל. קבוצת מידע זו מאפשרת למאמת מוגבל במשאבים לוודא ביעילות שהכללת כתובת במצב מנסה ולאמת את היתרה של . A 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 אימות הוכחת השריפה הפרטית כעת, כשאנו יודעים אילו הצהרות הוכחת השריפה מנסה להוכיח, יש לנו מושג הוגן כיצד עובד אימות הוכחה. עבור ההצהרה הראשונה ( ), המאמת צריך "להבין" את ההיגיון של פונקציית ה-hash המשמשת ליצירת הכתובת - כך שהוא יודע ש- אכן שווה קידוד ההיגיון של פונקציית ה-hash במעגל המאמת אוכף גם את הדרישה שלא ניתן ליצור עם פונקציית ה-hash Keccak256. h(s) = A A H(s) ל-A. A עבור ההצהרה השנייה ( יש יתרה חיובית של ETH), על המאמת לאמת הוכחת Merkle המוכיחה את הכללת במצב של Ethereum ומאמתת את נתוני החשבון. מאמת המעגל גם בודק שכותרת הבלוק היא מהשרשרת הקנונית - לפני חילוץ שורש המצב - על ידי קריאה ל- opcode עם הקלט , כאשר מתייחס לכותרת הבלוק אם הוא חלק משרשרת Ethereum הקנונית, ה- המוחזר על ידי ה-opcode צריך להתאים ל-hash של כותרת הבלוק ל-A b A B BLOCKHASH block.blockHash(blockNumber) blockNumber B. B hash BLOCKHASH B. בנוסף, מעגל המאמת מאמת את המבטל הכלול בהוכחת ה-ZK-SNARK של המשתמש ומאשר שלא נעשה שימוש בעבר במבטל. ההתנגדות להתנגשות של פונקציות גיבוב ממלאת תפקיד תומך כאן על ידי מניעת ניסיונות ליצור שני גיבובים שונים של מבטל ו- עבור אותה שילוב . אם משתמש יכול ליצור מבטלים שונים עבור אותה כתובת, הוא יכול להטביע ETH כפול - ללא קשר אם ה-Sparse Merkle Tree מאחסן מבטל עבור כתובת זו או לא. N1 N2 burn address <> secret value כדי להבטיח שניתן לאמת הוכחות-של-צריבה על-ידי מציעי בלוק, EIP-7503 מציע שינוי ב-EVM כדי ליישם אימות תמיכה של הוכחות ZK-SNARK. המחברים של EIP-7503 בדקו את הכדאיות של יישום אימות בתוך EVM של הוכחות צריבה על ידי יצירת גרסה התומכת ב-EIP7503 של ה-EVM באמצעות מסגרת . אתה יכול לבקר המוקדש לפרויקט לפרטים נוספים על עיצוב הפרוטוקול. Polaris EVM במאגר GitHub הטבעת ETH לכתובת הנמען EIP-7503 מציג סוג עסקה חדש שמטביע ETH עבור משתמש שמוכיח בהצלחה שהוא הפקיד סכום מוגדר לכתובת שלא ניתן לבזבז. שולח העסקה מגיש הוכחה ZK-SNARK (לצד ביטול), והרשת מבצעת מעבר מצב שמעדכן את יתרת כתובת המשיכה (לאחר אימות הוכחת השריפה). למרות שה-EIP-7503 מספק הכחשה סבירה, מומלץ למשתמשים להימנע מתשלום עבור עסקאות טביעה עם כספים מאותה כתובת ששלחה את ETH לכתובת הצריבה. אם אליס שולחת ETH לכתובת שאינה ניתנת לבזבז ומאוחר יותר תשלח עסקה בתשלום עבור אותו כמות של ETH כדי להיטבע לחשבון נפרד, בוב לא צריך להיות ג'ימי ניוטרון כדי לקשר את אליס לעסקת הצריבה המקורית. 0xm00la הסעיפים הקודמים לא מזכירים את זה, אבל אנחנו צריכים שהמשתמשים יכללו את הכתובת השנייה (שתקבל ETH מעסקת ההטבעה) כקלט ציבורי למעגל המוכיח ZK-SNARK. זה מונע מקרים פוטנציאליים פוטנציאליים ממשתמשים ישרים לקבל חזית בזמן שעסקאות ההטבעה ממתינות ב-mempool. B נזכיר שהמאמת לא בודק את זהות הכתובת השולחת ונמנע בכוונה מדרישה לדעת אם אותה כתובת ששרפה את ה-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 גם מסיבות : שאינן קשורות לפרטיות נכון לעכשיו, מרכזיות מרכזיות (CEXes) חייבות ליצור כתובת ייחודית כדי לקבל פיקדון ממשתמש וצריכות לשלוח עסקאות המעבירות יתרות של כל כתובת לארנק קר אחד או יותר כחלק מתהליכי אבטחה תפעוליים. עם EIP-7503, מפעיל CEX יכול ליצור כתובת צריבה אחת שמקבלת הפקדות מקבוצה של משתמשים וליצור הוכחת צריבה המושכת את כל ההפקדות שנצברו בכתובת הצריבה לארנק הקר בעסקה אחת. הפחתה במספר העסקאות הנדרשות לאיחוד פיקדונות CEX בארנק קר מיטיבה עם מפעיל ה-CEX (עלויות תפעול מופחתות) והרשת (מספר נמוך יותר של עסקאות בשרשרת). כל ישות שמעבדת כמות משמעותית של תשלומים על השרשרת יכולה למנף את EIP-7503 כדי לשפר את היעילות התפעולית - כך ש-CEXs אינם הנהנים היחידים. סוחרים, ארגוני צדקה ומסילות תשלומים מקוריות קריפטו הן כמה דוגמאות לארגונים המשתמשים ב-EIP-7503 כדי להפחית את התקורה התפעולית על ידי צבירת הפקדות בכתובות צריבה ופיזור עלויות העסקאות על פני מספר הפקדות. להיבט זה של EIP-7503 יש את תופעת הלוואי הרצויה של יצירת תמריצים פיננסיים להצטרף למערך האנונימיות ומגביר את הפרטיות הכוללת של חשבונות המבצעים העברות פרטיות. איזון בין פרטיות לבין עמידה בתקנות EIP-7503 מספק נתיב פשוט לעבר עיגון פרטיות העסקאות ב-Ethereum מבלי לדרוש שינויים נרחבים בפרוטוקול. בפרט, EIP-7503 יאפשר ל-Ethereum להציע פרטיות עסקה מבלי להתמודד עם בעיות בהתמודדות עם בלוקצ'יין אחרים ממוקדי פרטיות כמו Zcash ו-Monero. למרות , לא צריך הרבה כדי לראות שמטבעות פרטיות כמו ZEC (Zcash) ו-MNR (Monero) אינם יכולים להשיג את המטרה של הכנסת כסף מבוזר, פרטי לכלכלה העולמית . עם לחצים רגולטוריים המאלצים את הבורסות למחוק מטבעות פרטיות, לבעלים יהיה יותר ויותר קשה לנצל את הפרטיות שמציעים Zcash, Monero ופרוטוקולים אחרים שנועדו במפורש להסתיר מידע עסקה בהקשרים של העולם האמיתי. קטע זה מתוך הספר של Haseeb Qureshi מספק היכרות טובה עם האתגרים העומדים בפני פרויקטי פרטיות "הארדקור" כיום: שכתבתי בעבר להגנת מטבעות הפרטיות ושמיש Why Privacy Coins Haven't Taken Off מטבעות פרטיות תמיד היו היעד הראשון לאינקוויזיציות רגולטוריות. כאשר הרגולטורים מואשמים "לא רק לעמוד שם, לעשות משהו", הבוגימן הקל ביותר הוא מטבעות פרטיות צללים. בצד הרגולטורי, ראינו שלל מחיקות מטבעות פרטיות בדרום , , . . ממשלות מנסות ללא הרף להדק את החבל על מטבעות הפרטיות (ראו , ). קוריאה יפן בריטניה וארה"ב כאן כאן וכאן לובי קריפטו גדלו; חלקים עצומים של קמעונאות ומוסדות רבים מחזיקים כעת ב-BTC ו-ETH. אבל מעט מאוד מוסדות מוכנים לבוא להגנת מטבעות הפרטיות. במקום לאפשר לכל הענף להיות מוכתם, רבים מסתפקים בלאפשר למטבעות הפרטיות להפוך לכבש הקורבן. - Haseeb Qureshi ( ) למה מטבעות הפרטיות לא המריא EIP-7503 מרגיש כאילו הוא הגיע ברגע הנכון באבולוציה של Ethereum: עם יותר משתמשים מכל בלוקצ'יין והרבה מאוד השקעות מוסדיות, Ethereum פחות צפוי לסבול את אותו גורל כמו פרויקטים אחרים שניסו לספק פונקציונליות של תשלומים פרטיים בעבר. האם כמה בורסות יגבילו את המסחר ב-Ether אם אסימוני ETH שהוטבעו באופן פרטי יתחילו להסתובב? אוּלַי. אבל תריסר בורסות אחרות ישמחו לקחת על עצמה את האחריות הזו - כך נראה שיש . בדיוק אפקטי רשת חזקים למה אני אומר שה-EIP-7503 הגיע בזמן הנכון? הייתה תקופה בהיסטוריה של Ethereum שבה תמיכה בפרטיות בשכבת הבסיס הייתה משהו שכולם הרגישו שצריך לעשות . אבל אחרים בקהילה הצביעו (בצדק) על מקרי הקצה הפוטנציאליים הקשורים לקידום Ethereum כ"טכנולוגיית פרטיות". הנה קטעים מתוך שדנים בצורך בפרטיות מוגברת ב-Ethereum: מיד שרשור ישן בפורום Ethereum Magicians האינטואיציות של גריפית' היו נכונות בעיקר בשנים הבאות, כאשר מטבעות קריפטוגרפיים רבים המוגדרים כברירת מחדל עומדים בפני הסיכוי להפוך למטבעות שוליים בשימוש רק על ידי סייפרפאנקים קשוחים (קבוצה המונה פחות מ-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 בתשתית שלה היא כמתואר בבקשה להערה זו (RFC). גשר Taiko כאן, אנו רואים כי פרוטוקול כמו Taiko יכול להציע פרטיות עסקה - מבלי לבצע חילופים נרחבים לתשתית שלו - על ידי אימוץ EIP-7503. יש לכך יתרון מרכזי עבור צוותי פרוטוקול שאינם רוצים לבנות L2 ממוקד פרטיות בקנה מידה מלא (a la ) אך רוצים לספק חוסר מעקב וחוסר קישוריות בסיסיים למשתמשים. כדאי לקרוא כדי לקבל מושג כיצד ניתן ליישם EIP-7503 על ידי Ethereum L2. Aztec v2 את ההצעה של צוות Nethermind ליישם EIP-7503 ב- Taiko EIP-7503 מאזנת גם את הצורך בפרטיות עם ציות לרגולציה, שמתיישרת עם המטרה של תנועת "פרטיות 2.0" של Ethereum: שמירה על פרטיות המשתמש, תוך הבטחה של שחקנים רעים שלא יוכלו לנצל תשתית פרטיות למטרות מרושעות. לפי המתואר ב-Ethereum Research, אוסף שמאמצים את EIP-7503 יכול למנוע חזרה של בעיית Tornado Cash על ידי חסימה סלקטיבית של האקרים ורמאים ידועים מלהלבין כספים באמצעות העברות פרטיות. יישום של EIP-7503 כדי להשיג מאפיין זה, אנו דורשים מהמשתמשים להעביר רשימה של כתובות ברשימה שחורה ( ) כקלט למעגל שיוצר הוכחות ZK-SNARK לעסקאות צריבה. המעגל בודק שהכתובת של המשתמש המקבל ETH אינה חלק מהכתובות המאוחסנות ברשימה השחורה בעת יצירת הוכחת צריבה - העברה לכתובת ברשימה השחורה תיכשל אוטומטית מכיוון שהמעגל לא יכול ליצור הוכחה אם הקלט אינו עומד בכל תנאי התוקף. blacklist[] שמירה על רישום של כתובות ברשימה השחורה מציגה מידה של ריכוזיות וקטורי צנזורה פוטנציאליים. אבל אם נקבל את זה שהרגולציה העצמית הבסיסית מונעת על ידי קהילה טובה יותר מאשר רגולציה ריכוזית מלמעלה למטה, ייתכן שיהיה צורך בגאדג'טים כאלה כדי להבטיח עמידה בתקנות. ניהול שכר פרטי לארגונים ברשת שקיפות היא אחת מאבני היסוד של DAOs (ארגונים אוטונומיים מבוזרים): בניגוד לארגונים מסורתיים שבהם פרטי התגמול הפיננסי מוסתרים ממשקיעים ומבעלי עניין, תשלומי תורמים ב-DAO מתועדים באופן פומבי ברשת. נתיב ביקורת על השרשרת הזה מספק מידה משמעותית של אחריות ומפחית מאוד את אסימטריית המידע שעלולה לגרום לניהול כושל פיננסי על ידי מנהלי DAO. עם זאת, ה-DAOs בהכרח יתבגרו ויתחילו לפעול כמו תאגידים (לטוב ולרע) - ובשלב זה דברים כמו שמירה על פרטיות של פיצוי התורמים עשויים להפוך לרצויים. EIP-7503 מספק את התשתית ש-DAOs צריכים כדי להתחיל לבצע תשלומים פרטיים לתורמי ליבה, מפתחים וקבלנים עצמאיים. בכל המקרים, הנמען צריך רק ליצור כתובת צריבה כדי לקבל תשלומים ולמשוך לכתובת הבחירה שלו. כיצד חברי DAO ישמרו על מנהלי דין וחשבון אם תשלומי תורמים/קבלנים פרטיים יושמו? זה תלוי ברמת הפרטיות ש-DAO מחפש ואיזו רמת הסתרה שחברי DAO יכולים לסבול. לדוגמה, כדי להוכיח כי AliceDAO אכן שילמה 20 ETH לאליס עבור עבודת DAO וכי הכסף לא שימש למטרות חלופיות, אליס יכולה לספק הוכחה שמראה שהיא יצרה את הכתובת הבלתי ניתנת לבזבז. לדוגמה, אליס עשויה לחשוף את הפרטי המשמש ליצירת הכתובת הבלתי ניתנת לבזבז. מכיוון שהכתובת הבלתי ניתנת לבזבז מתבטלת לאחר פעולת ההטבעה, אליס יכולה לחשוף מבלי להיתקל בסיכון כלשהו. מאמת צד שלישי יגזור את הכתובת הבלתי ניתנת לבזבז על ידי hashing באמצעות אותה פונקציית hash קריפטוגרפית שבה השתמשה אליס בתחילה וישווה את שתי הכתובות. אם הם תואמים, המאמת יודע שלליס הייתה גישה לכתובת הצריבה בזמן שליחת העסקה. עם זאת, הוא אינו יודע באיזו כתובת אליס השתמשה כדי לקבל את אסימוני ה-ETH המוטבעים (שמירה על פרטיותה של אליס במידה מסוימת). המפתח s s הפחתת התלות במערבלי מטבעות קריפטוגרפיים השימוש במיקסר כמו Tornado Cash כדי לשבור קישורים בין כתובות ארנק הוא בעייתי מכיוון שהוא יוצר סוג של . זכור כי מיקסרים מספקים אנונימיות על ידי ערבוב כספים שהופקדו על ידי משתמשים שונים לקרן אחת שכל אחד יכול למשוך ממנה לספק מידע אחר מלבד ראיות לאימות הפקדה היסטורית. אשמה-על-אסוציאציה מבלי ככל שפורסים יותר כספים במאגר פרטיות, כך קשה יותר לצופה חיצוני להסיק מי הבעלים של מה; אם שחקנים רעים יצטרפו למאגר, משתתפים כנים עשויים לסייע ללא כוונה לפושעים להלבין כסף על ידי תרומה למערך האנונימיות של הפרוטוקול. זו כנראה הסיבה התרחבו (ועדיין מתרחבות) לכתובות שקיימו אינטראקציה עם Tornado Cash, גם אם הכתובות הללו אינן קשורות לשחקנים רעים ידועים (למשל, כנופיות דיוג, האקרים בחסות מדינת לאום ומנצלי כובע שחור). שהסנקציות של OFAC מיקסרים כמו Tornado Cash גם יוצרים בעיה עם יציבות: אסימונים שנשלפים מבריכת ערבוב יכולים להפוך ל"נגועים" ובלתי אפשריים לשימוש או להחליף 1:1 באסימונים "נקיים" שלא עברו במיקסר. יש שדן בבעיית הכספים המזוהמים ביתר פירוט, אותו אני ממליץ לקרוא. הנה כמה מהתגובות היותר מאירות מהשרשור הזה: שרשור נהדר ב-Reddit יכולות להיות לכך השלכות בעולם האמיתי: לדוגמה, אנשים בעלי פרופיל גבוה בקהילת Ethereum לאחר שהארנקים שלהם נשלחו כמויות לא רצויות של ETH ממאגר Tornado Cash. EIP-7503 מתואר כ"מערבל ללא חוזים" ועוקף את הבעיות האמורות על ידי שימוש בהעברות EOA ל-EOA רגילות לשריפת ETH והכנסת טביעה ישירה כדי להקל על משיכות ממאגר האנונימיות (לעומת שימוש בחוזה חכם). מצאו את עצמם לא מסוגלים לקיים אינטראקציה עם כמה ממשקי Dapp יתרון נוסף של מיקסר ללא חוזים הוא גודל ערכת האנונימיות. עם Tornado Cash (ופרוטוקולים דומים כמו ), מערך האנונימיות קטן יותר - בקורלציה למספר המשתתפים - ומתכווץ עם הזמן. לעומת זאת, EIP-7503 הופך את כל סט הכתובות ב-Ethereum לסט אנונימיות. בהתחשב במרחב הכתובות הגדול, ניתן לומר בוודאות שלמחקני השרשרת שרוצים לדעת מאיפה הגיע ה-ETH שנשלח אל מקבל ההעברה הפרטית, עבודה קשה לפניהם. Railgun הניתנות לבזבז ולא ניתן לבזבז האם יש חסרונות ביישום 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 אחראי על תחזוקת רישום ? או שמא צוות המייסדים מתקשר לשירותים של חברות פורנזיות כמו Chainalysis, Elliptic ו-TRM Labs כדי לספק מידע לגבי הכתובות שיש להגביל מלקבל העברות פרטיות? אילו בעיות יכולות להופיע אם חברה למטרות רווח מחליטה מה קורה בשכבת הבסיס של רולאפ? blacklistedAddresses אם אוסף מחליט להסיר הרשאות אדמיניסטרטיביות ולהפוך את החוזים המאמתים/החוזים לבלתי ניתנים לשדרוג, כיצד הוא מבטיח ששחקנים גרועים לא יתחילו להעביר כספים דרך הפרוטוקול? האם ניתן לטפל בסינון סלקטיבי של עסקאות מנצלים ידועים בשכבות העליונות של המחסנית (למשל, ברמת הרצף או המאמת)? מה הלוגיסטיקה הכרוכה? אלו הן רק כמה שאלות שצריך לענות עליהן לפני ש-Ethereum (או Ethereum L2s) יאמצו את EIP-7503. קריפטו עדיין במים לא ידועים, אבל זה עוזר לבצע הרבה , במחשבה על מקרים פוטנציאליים פוטנציאליים מראש, בעת קבלת החלטות שיש להן השלכות משמעותיות על הישרדותו ארוכת הטווח של הפרוטוקול. Murphyjitsu חוסר המזל מכביד ביותר על אלה שמצפים רק למזל טוב. - סנקה ריכוזיות פוטנציאלית הקשורה לאסימוני ERC-20 הטמעת EIP-7503 דורשת שדרוג ל-EVM כדי לתמוך בסוג עסקה חדש המקבל קבלה צריבה ומזכה את יתרת הנמען עם ETH שנצרבה בעסקה הקודמת. לקוחות ביצוע יצטרכו גם לשדרג כדי לתמוך ב-Sparse Merkle Tree (SMT) לאחסון מבטלים וליישם מעגלים מחוץ לשרשרת להפקה ואימות של הוכחות-לצריבה בשם המשתמשים. מתוך הכרה בכך שדרוג עשוי להיות בלתי אפשרי, למחברי EIP-7503 יש . משתמשים שומרים על אותה זרימת עבודה שתוארה בסעיפים הקודמים (שליחת כספים לכתובת שאינה ניתנת להוצאה ויצירת ביטול), אך מטביעים אסימוני ERC-20 לאחר שליחת הוכחת שריפה במקום קבלת אסימוני ETH. חוזה ERC-20 משתלב עם חוזה אימות מיוחד של EIP-7503 המאמת הוכחות צריבה על השרשרת (חוזה 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 מגיע עם דרישה לבנות, לבדוק, לבקר ולתחזק תשתית קריפטוגרפית מורכבת ומתקדמת הנדרשת לתמיכה בעסקאות אנונימיות ופרטיות. לפחות, ושל Nobitex Labs' שניהם מצביעים על כמות הגונה של מאמץ הנדסי ילך ליצירת מעגלי ZK-SNARK להפקה ואימות של הוכחות EIP-7503 . התיאור של Nethermind של יישום L2 של EIP-7503 EIP-7503 Chain proof-of-concept, חשוב גם לציין שפרימיטיבים קריפטוגרפיים כמו ZK-SNARKs עדיין לא עברו בדיקות קרב מספיק כדי שמפתחי פרוטוקולים יוכלו ליישם אותם בביטחון מוחלט. לשם המחשה, Zcash תיקן באג שיאפשר למשתמש לא ישר לספק הוכחות מזויפות לבעלות על נכסים בשנת 2018. דיברתי גם על ב-2019. ולהטביע כמות אינסופית של אסימונים הבריחה הצרה של צוות Tornado Cash מניצול פוטנציאלי לבאג ביישום של EIP-7503 על Ethereum תהיה השפעה לא טריוויאלית. לדוגמה, משתמש שמגלה בטעות פגם המאפשר לעקוף בדיקות קריטיות שבוצעו על ידי המעגל המאמת הוכחת צריבה (למשל, איזון כתובות צריבה ושימוש במבטלים) עלול לנצל את הידע כדי להטביע כמויות אינסופיות של אתר ו להרוס את שווי השוק של ETH. תחום מורכב נוסף נובע מהדרישה מהמאמת EIP-7503 לאמת את כותרת הבלוק הכלולה בהוכחה שנוצרה על ידי המשתמש. ה-EVM מאחסן גיבוב של 128-256 הבלוקים האחרונים, כך שהמאמת על השרשרת לא יכול לאמת ללא אמון כותרות בלוק מטווח ארוך יותר. B כדי לאמת את שורש המצב מבלוקים ישנים יותר, יהיה צורך ליישם . EIP-210 מציע ליצור חוזה חכם ברמת המערכת המאחסן גיבובים היסטוריים של בלוק ולשנות מחדש את קוד כדי לאפשר ללקוחות לקרוא את החוזה. את EIP-210 BLOCKHASH EIP-210 אינו הכרחי לחלוטין מכיוון שלמשתמשים יש לפחות שעה אחת ( ) ליצור ולהגיש הוכחה שניתן לאמת באמצעות EVM. ובכל זאת, מתן חופש למשתמשים לעכב את פדיון ההפקדות הנשלחות לכתובת צריבה משפר את ה-UX והופך את תהליך המשיכה לעמיד יותר בפני יצירת אשכולות וטכניקות ניתוח דומות. 14 seconds * 256 blocks חלופה היא לשלב חוזה אורקל המחייב שחקנים (בתמריצים) להגיש כותרות בלוק היסטורי לחוזה על שרשרת. זה קל יותר ליישום מאשר יצירת חוזה חכם ברמת המערכת ועיבוד מחדש של 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 ונתכנן לשחרר צלילה עמוקה ב- (תקן להפקת כתובות חמקנות ושליחת עסקאות כתובות חמקנות ב-Ethereum). ERC-5564 הישארו מעודכנים! הערת המחבר: מאמר זה מתפרסם גם . כאן