מבוא ל- zk-SNARKs

בלוג 1חדשות מפתחיםיזם הסבר על בלוקצ’יין אירועים וכנסים לחץעלונים

הירשם לניוזלטר שלנו.

כתובת דוא”ל

אנו מכבדים את פרטיותך

HomeBlog פיתוח בלוקצ’יין

מבוא ל- zk-SNARKs

סקירה כללית של הוכחות אפס ידע וכיצד ניתן לשלב את zk-SNARK ב- Ethereum. על ידי ConsenSys 27 במרץ 2017 פורסם ב 27 במרץ 2017

גיבור בית

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

הוכחות אפס-ידע

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

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

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

תוכנית לדוגמא

נניח שלבוב ניתן חשיש H בעל ערך כלשהו, ​​והוא מעוניין לקבל הוכחה לכך שאליס יודעת את הערך שחותך ל- H. בדרך כלל אליס תוכיח זאת על ידי מתן ש לבוב, לאחר מכן בוב יחשב את החשיש ובדוק כי זה שווה ל- H.

עם זאת, נניח שאליס לא רוצה לחשוף את הערך לבוב אלא במקום זאת היא רק רוצה להוכיח שהיא יודעת את הערך. היא יכולה להשתמש ב- zk-SNARK לשם כך.

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


פונקציה C (x, w) {return (sha256 (w) == x);} שפת קוד: JavaScript (javascript)

במילים אחרות: התוכנית מקבלת חשיש ציבורי x וערך סודי w ומחזירה אמת אם החשיש של SHA – 256 של w שווה ל- x.

בתרגום הבעיה של אליס באמצעות הפונקציה C (x, w) אנו רואים שאליס צריכה ליצור הוכחה שיש לה s כך ש- C (H, s) == נכון, מבלי שתצטרך לחשוף את s. זו הבעיה הכללית ש- zk-SNARK פותרים.

הגדרה של zk-SNARK

Zk-SNARK מורכב משלושה אלגוריתמים G, P, V המוגדרים כדלקמן:

מחולל המפתחות G לוקח פרמטר סודי למבדה ותוכנית C ויוצר שני מפתחות זמינים לציבור, מפתח הוכחה pk ומפתח אימות vk. מפתחות אלה הם פרמטרים ציבוריים שיש צורך ליצור רק פעם אחת עבור תוכנית C נתונה.

המוכיח P לוקח כקלט את מקש ההוכחה pk, קלט ציבורי x ועד פרטי w. האלגוריתם מייצר הוכחה prf = P (pk, x, w) לכך שהמוכיח מכיר עד w וכי העד מספק את התוכנית.

המאמת V מחשב את V (vk, x, prf) שמחזיר true אם ההוכחה נכונה, ושקר אחרת. לפיכך פונקציה זו מחזירה אמת אם המוכיח יודע עד w המספק את C (x, w) == נכון.

שימו לב כאן לפרמטר הסודי למבדה המשמש בגנרטור. פרמטר זה לפעמים עושה את זה מסובך להשתמש ב- zk-SNARK ביישומים בעולם האמיתי. הסיבה לכך היא שכל מי שמכיר את הפרמטר הזה יכול ליצור הוכחות מזויפות. באופן ספציפי, בהינתן כל תוכנית C וקלט ציבורי x אדם שיודע למבדה יכול ליצור הוכחת fake_prf כך ש- V (vk, x, fake_prf) יעריך עד אמת ללא ידיעה על הסוד w.

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

Zk-SNARK לתוכנית הדוגמה שלנו

כיצד אליס ובוב היו משתמשים ב- zk-SNARK בפועל על מנת שאליס תוכיח שהיא יודעת את הערך הסודי בדוגמה לעיל?

ראשית, כפי שנדון לעיל נשתמש בתוכנית המוגדרת על ידי הפונקציה הבאה:

פונקציה C (x, w) {return (sha256 (w) == x); } שפת קוד: JavaScript (javascript)

הצעד הראשון הוא שבוב יפעיל את הגנרטור G על מנת ליצור את מפתח ההוכחה pk ומפתח האימות vk. ראשית, צור באופן אקראי lambda והשתמש בו כקלט:

(pk, vk) = G (C, lambda)

התמודד בזהירות עם הפרמטר למבדה, כי אם אליס תלמד את הערך של למבה היא תוכל ליצור הוכחות מזויפות. בוב ישתף את אליס ב- pk ו- vk.

אליס תשחק כעת את תפקיד המוכיח. היא צריכה להוכיח שהיא יודעת את הערך s שמתחבר לחשיש הידוע H. היא מפעילה את האלגוריתם המוכיח P בעזרת התשומות pk, H ו- s כדי ליצור את PRF ההוכחה:

prf = P (pk, H, s)

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

מפתחות הוכחה ואימות לשימוש חוזר

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

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

מי שסומך על כך שהקבוצה לא רימה, יכול להשתמש במקשים אלה לאינטראקציות עתידיות.

zk-SNARK באת’ריום

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

דוגמה: עסקאות חסויות

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

מיפוי (כתובת => uint256) יתרות; שפת קוד: JavaScript (javascript)

אנו הולכים לשמור על אותה הליבה הבסיסית, למעט להחליף איזון עם האזן של איזון:

מיפוי (כתובת => bytes32) balanceHashes; שפת קוד: JavaScript (javascript)

אנחנו לא מתכוונים להסתיר את שולח או מקבל העסקאות. אבל אנחנו נסתיר את היתרות והסכומים שנשלחו. לעיתים מכונה נכס זה עסקאות חסויות.

נשתמש בשני zk-SNARK כדי לשלוח אסימונים מחשבון אחד למשנהו. הוכחה אחת נוצרת על ידי השולח ואחת על ידי המקבל.

בדרך כלל בחוזה סמלי לעסקה בערך גודל כדי להיות תקף עלינו לאמת את הדברים הבאים:

יתרות [fromAddress] >= ערך

ה- zk-SNARK שלנו צריכים להוכיח שזה מתקיים, כמו גם שהחשיפות המעודכנות תואמות את היתרות המעודכנות.

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

להלן התוכנית בה נשתמש עבור השולח zk-SNARK, כאשר כמו קודם x מייצג את הקלט הציבורי, ו- w מייצג את הקלט הפרטי.

function senderFunction (x, w) {return (w.senderBalanceBefore > ערך && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} שפת קוד: JavaScript (javascript)

התוכנית בה משתמש המקלט נמצאת להלן:

פונקציית מקלט פונקציה (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} שפת קוד: JavaScript (javascript)

התוכניות בודקות כי יתרת השליחה גדולה מהערך הנשלח, כמו כן בודקות כי כל הגיבובים תואמים. קבוצה מהימנה של אנשים תיצור את מפתחות ההוכחה והאימות עבור ה- zk-SNARK שלנו. בואו נקרא להם confTxSenderPk, confTxSenderVk, confTxReceiverPk ו- confTxReceiverVk.

השימוש ב- zk-SNARK בחוזה סמלי ייראה בערך כך:

העברת פונקציות (כתובת _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, bytes zkProofSender, bytes zkProofReceiver) {bytes32 hashSenderBalanceBefore = balanceHashes [msg.sender]; bytes32 hashReceiverBalanceBefore = balanceHashes [_to]; bool senderProofIsCorrect = zksnarkverify (confTxSenderVk, [hashSenderBalanceBefore, hashSenderBalanceAfter, hashValue], zkProofSender); bool receiverProofIsCorrect = zksnarkverify (confTxReceiverVk, [hashReceiverBalanceBefore, hashReceiverBalanceAfter, hashValue], zkProofReceiver); אם (senderProofIsCorrect && receiverProofIsCorrect) {balanceHashes [msg.sender] = hashSenderBalanceAfter; balanceHashes [_to] = hashReceiverBalanceAfter; }} שפת קוד: JavaScript (javascript)

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

פרטים

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

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

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

כיצד לבנות מוצר מצליח של בלוקצ’יין

כיצד להגדיר ולהפעיל צומת אתריוםוובינר

כיצד להגדיר ולהפעיל צומת אתריום

כיצד לבנות ממשק API משלך של Ethereumוובינר

כיצד לבנות ממשק API משלך של Ethereum

כיצד ליצור אסימון חברתיוובינר

כיצד ליצור אסימון חברתי

שימוש בכלי אבטחה בפיתוח חוזים חכםוובינר

שימוש בכלי אבטחה בפיתוח חוזים חכם

העתיד של נכסים דיגיטליים של פיננסים ו- DeFiוובינר

עתיד האוצר: נכסים דיגיטליים ו- DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map