מבוא

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

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

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

שתי דרכים ליישם PVRB

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

חוזה עצמאי

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

האפשרות עם חוזה עצמאי טובה:

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

יש לזה גם חסרונות:

• מגבלות חזקות על משאבי מחשוב, נפח עסקאות ואחסון (במילים אחרות, cpu/mem/io)
• הגבלות על פעולות במסגרת החוזה (לא כל ההוראות זמינות, קשה לחבר ספריות חיצוניות)
• חוסר יכולת לארגן הודעות מהר יותר מאשר עסקאות כלולים בבלוקצ'יין

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

משולבת בקונצנזוס

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

כאשר מתארים יישומי PVRB ברמת קונצנזוס רשת, אי אפשר בשום אופן להימנע מבעיות של סופיות. סופיות היא מנגנון המשמש בהסכמות דטרמיניסטיות הנועל בלוק (והשרשרת המובילה אליו) שהוא סופי ולעולם לא ייזרק, גם אם יתרחש מזלג מקביל. למשל, בביטקוין אין מנגנון כזה - אם תפרסמו שרשרת בעלת מורכבות גדולה יותר, היא תחליף כל אחת פחות מורכבת, ללא קשר לאורך השרשראות. וב-EOS, למשל, הסופיים הם מה שנקרא Last Irreversible Blocks, המופיעים בממוצע כל 432 בלוקים (12*21 + 12*15, טרום-vote + pre-commit). תהליך זה ממתין למעשה ל-2/3 מהחתימות של יצרני בלוק (להלן BP). כאשר מופיעים מזלגות שישנים יותר מה-LIB האחרון, הם פשוט נזרקים. מנגנון זה מאפשר להבטיח שהעסקה כלולה בבלוקצ'יין ולעולם לא תוחזר לאחור, לא משנה אילו משאבים יש לתוקף. כמו כן, הבלוקים האחרונים הם בלוקים חתומים על ידי 2/3 BP ב-Hyperledger, Tendermint ושאר הסכמות מבוססות pBFT. כמו כן, הגיוני להפוך פרוטוקול להבטחת סופיות כתוספת לקונצנזוס, מכיוון שהוא יכול לעבוד באופן אסינכרוני עם ייצור ופרסום בלוקים. הנה אחד טוב מאמר לגבי סופיות באת'ריום.

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

לכן, האפשרות הטובה ביותר היא לשלב PVRB וסופיות לפרוטוקול אחד - ואז הבלוק הסופי = finalized random, וזה בדיוק מה שהיינו צריכים לקבל. כעת שחקנים יקבלו אקראי מובטח תוך N שניות, ויוכלו להיות בטוחים שאי אפשר להחזיר אותו לאחור או להפעיל אותו שוב.

האפשרות המשולבת בקונצנזוס טובה:

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

יש לזה גם חסרונות:

• קשיים בבדיקה ופיתוח - תצטרך לחקות שגיאות רשת, צמתים חסרים, מזלגות רשת קשים
• שגיאות יישום דורשות רשת קשה

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

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

משתני PVRB ובלוק.

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

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

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

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

במקרה זה, רק דרישה 1 מתקיימת, ודרישה 2 לא מתקיימת. על ידי גיבוב ערכים בלתי צפויים מהבלוק, נקבל התפלגות אחידה ואקראיות טובות. אבל ל-BP לפחות יש את האפשרות "לפרסם את החסימה או לא". לפיכך, BP יכול לבחור לפחות משתי אפשרויות אקראיות: "שלה" וזו שתתברר אם מישהו אחר יבצע את החסימה. BP יכול "לחטט" מראש מה יקרה אם הוא יפרסם בלוק, ופשוט יחליט לעשות את זה או לא. כך, כשהוא משחק, למשל, "זוגי-אי זוגי" או "אדום/שחור" ברולטה, הוא יכול לפרסם בלוק רק אם הוא רואה ניצחון. זה גם הופך את האסטרטגיה של שימוש, למשל, ב-hash בלוק "מהעתיד" בלתי ניתנת לביצוע. במקרה זה, הם אומרים כי "ייעשה שימוש אקראי, המתקבל על ידי גיבוב הנתונים הנוכחיים וה-hash של בלוק עתידי בגובה של, למשל, N + 42, כאשר N הוא גובה הבלוק הנוכחי. זה מחזק מעט את התוכנית, אבל עדיין מאפשר ל-BP, אם כי בעתיד, לבחור אם להחזיק את החסימה או לפרסם.

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

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

PVRB ו-commit-reveve.

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

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

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

PVRB וחתימות דטרמיניסטיות.

יש דרך נוספת לאלץ את ה-RP לספק מספר פסאודו אקראי שהוא לא יכול להשפיע עליו אם הוא מסופק עם "תמונה מוקדמת" - זו חתימה דטרמיניסטית. חתימה כזו היא, למשל, RSA, ואינה ECS. אם ל-RP יש זוג מפתחות: RSA ו-ECC, והוא חותם על ערך מסוים עם המפתח הפרטי שלו, אז במקרה של RSA הוא יקבל חתימה ONE AND ONLY ONE, ובמקרה של ECS הוא יכול ליצור כל מספר של חתימות חוקיות שונות. הסיבה לכך היא שבעת יצירת חתימת ECS, נעשה שימוש במספר אקראי, הנבחר על ידי החותם, וניתן לבחור אותו בכל דרך, מה שנותן לחתום את האפשרות לבחור אחת ממספר חתימות. במקרה של RSA: "ערך קלט אחד" + "זוג מפתחות אחד" = "חתימה אחת". אי אפשר לחזות איזו חתימה יקבל RP אחר, ולכן ניתן לארגן PVRB עם חתימות דטרמיניסטיות על ידי שילוב חתימות RSA של מספר משתתפים שחתמו על אותו ערך. לדוגמה, האקראי הקודם. תכנית זו חוסכת משאבים רבים, כי חתימות הן גם אישור להתנהגות הנכונה לפי הפרוטוקול וגם מקור לאקראיות.

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

PVRB ותוכניות שיתוף סודיות

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

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

• כל משתתף יוצר אקראי משלו ומחלק ממנו שיתופים למשתתפים אחרים
• כל משתתף חושף את חלקו בסודות המשתתפים האחרים
• אם למשתתף יש יותר מ-M מניות, ניתן לחשב את המספר של משתתף זה, והוא יהיה ייחודי, ללא קשר לקבוצת המשתתפים שנחשפו
• השילוב של אקראיות שנחשפו הוא ה-PVRB הרצוי

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

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

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

PVRB וחתימות סף

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

השילוב של חתימות דטרמיניסטיות וסכמות סף איפשר לפתח סכימה נוחה ומבטיחה מאוד ליישום PVRB – אלו חתימות סף דטרמיניסטיות. כאן מאמר על השימושים השונים בחתימות הסף, והנה עוד אחד טוב longread מ-Dash.

המאמר האחרון מתאר חתימות BLS (BLS מייצג Boneh-Lynn-Shacham, כאן מאמר), בעלי איכות חשובה מאוד ונוחה במיוחד למתכנתים - מפתחות ציבוריים, סודיים, ציבוריים וחתימות BLS ניתן לשלב זה עם זה באמצעות פעולות מתמטיות פשוטות, בעוד שהשילובים שלהם נשארים מפתחות וחתימות תקפים, מה שמאפשר לצבור בקלות רבים חתימות לאחד ומפתחות ציבוריים רבים לאחד. הם גם דטרמיניסטיים ומייצרים את אותה תוצאה עבור אותם נתוני קלט. בשל איכות זו, שילובים של חתימות BLS הם בעצמם מפתחות תקפים, המאפשרת יישום של אופציה שבה M מתוך N משתתפים מייצרים חתימה אחת ויחידה שהיא דטרמיניסטית, ניתנת לאימות ציבורית ובלתי ניתנת לחיזוי עד לפתיחתה על ידי ה-Mth משתתף .

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

אז אם אתה בונה PVRB על הבלוקצ'יין שלך, סביר להניח שתסיים עם ערכת חתימות הסף של BLS, מספר פרויקטים כבר משתמשים בה. לדוגמה, DFinity (כאן אמת מידה המיישמת את המעגל, ו כאן יישום לדוגמה של שיתוף סודי שניתן לאימות), או Keep.network (הנה המגדלור האקראי שלהם נייר צהוב, אבל דוגמה חוזה חכם המשרת את הפרוטוקול).

יישום PVRB

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

אפרט את הגורמים שתצטרך לקחת בחשבון בעת ​​בחירת PVRB איכותי:

• חוזק קריפטוגרפי. ה-PVRB שלך חייב להיות בלתי משוחד לחלוטין, ללא יכולת לשלוט בביט אחד. בחלק מהסכמות זה לא המקרה, אז התקשר לקריפטוגרף
• בעיית "השחקן האחרון".. ה-PVRB שלך חייב להיות עמיד בפני התקפות שבהן תוקף השולט ב-RPs אחד או יותר יכול לבחור אחת משתי תוצאות.
• בעיית חבלה בפרוטוקול. ה-PVRB שלך חייב להיות עמיד בפני התקפות שבהן תוקף השולט ב-RPs אחד או יותר מחליט אם להיות אקראי או לא וניתן להבטיח אותו או עם הסתברות נתונה להשפיע על זה
• בעיה במספר ההודעות. ה-RPs שלך צריכים לשלוח מינימום הודעות לבלוקצ'יין ולהימנע ככל האפשר מפעולות סינכרוניות כמו מצבים כמו "שלחתי קצת מידע, אני מחכה לתגובה ממשתף ספציפי". ברשתות p2p, במיוחד מפוזרות גיאוגרפית, לא צריך לסמוך על תגובה מהירה
• בעיית המורכבות החישובית. אימות של כל שלב של PVRB on-chain צריך להיות קל ביותר, מכיוון שהוא מבוצע על ידי כל הלקוחות המלאים של הרשת. אם ההטמעה מתבצעת באמצעות חוזה חכם, הרי שדרישות המהירות הן מאוד מחמירות
• בעיית הנגישות והחיות. ה-PVRB שלך צריך לשאוף להיות עמיד במצבים שבהם חלק מהרשת הופך לא זמין למשך תקופה מסוימת וחלק מה-RP פשוט מפסיק לעבוד
• הבעיה של הגדרה מהימנה והפצת מפתח ראשונית. אם ה-PVRB שלך משתמש בהגדרה הראשית של הפרוטוקול, אז זה סיפור גדול ורציני נפרד. כאן דוגמה. אם המשתתפים חייבים לספר זה לזה את המפתחות שלהם לפני תחילת הפרוטוקול, זו גם בעיה אם הרכב המשתתפים משתנה
• בעיות פיתוח. זמינות ספריות בשפות הנדרשות, אבטחתן וביצועיהן, פרסום, מבחנים מורכבים וכו'.

לדוגמה, לחתימות סף BLS יש בעיה משמעותית - לפני תחילת העבודה, על המשתתפים לחלק מפתחות זה לזה, ולארגן קבוצה שבתוכה הסף יעבוד. המשמעות היא שלפחות סבב החלפה אחד ברשת מבוזרת יאלץ להמתין, ובהינתן שהראנד שנוצר, למשל, נחוץ במשחקים, כמעט בזמן אמת, המשמעות היא שחבלה בפרוטוקול אפשרית בשלב זה. והיתרונות של ערכת הסף אובדים. בעיה זו כבר פשוטה יותר מהקודמות, אך עדיין מצריכה פיתוח נוהל נפרד ליצירת קבוצות סף, אשר יצטרכו להיות מוגן כלכלית, באמצעות הפקדות ומשיכת כספים (קיצוץ) ממשתתפים שאינם פועלים לפי ההוראות. נוהל. כמו כן, אימות BLS עם רמת אבטחה מקובלת פשוט לא מתאים, למשל, לעסקת EOS או Ethereum סטנדרטית - פשוט אין מספיק זמן לאימות. קוד החוזה הוא WebAssembly או EVM, המבוצע על ידי מכונה וירטואלית. פונקציות קריפטוגרפיות אינן מיושמות באופן מקורי (עדיין), ועובדות לאט פי עשרות מונים מספריות קריפטוגרפיות קונבנציונליות. פרוטוקולים רבים אינם עומדים בדרישות רק על סמך נפח מפתח, למשל 1024 ו-2048 סיביות עבור RSA, גדול פי 4-8 מחתימת העסקה הסטנדרטית בביטקוין ובאת'ריום.

גם נוכחותם של יישומים בשפות תכנות שונות משחקת תפקיד - מהם מעטים, במיוחד עבור פרוטוקולים חדשים. האפשרות עם אינטגרציה לקונצנזוס מחייבת כתיבת פרוטוקול בשפת הפלטפורמה, כך שתצטרכו לחפש קוד ב-Go for geth, ב-Rust for Parity, ב-C++ עבור EOS. כולם יצטרכו לחפש קוד JavaScript, ומכיוון ש-JavaScript והקריפטוגרפיה אינם חברים קרובים במיוחד, WebAssembly תעזור, שכעת בהחלט מתיימרת להיות תקן האינטרנט החשוב הבא.

מסקנה

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

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

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

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

מקור: www.habr.com