עולם אחדכלכלה אחתפנקס אחד

גללו כדי לגלות
91%מתוך ⁨93⁩ בנקים מרכזיים שנסקרו בידי ⁨BIS⁩ בשנת ⁨2024⁩ בחנו מטבע דיגיטלי של בנק מרכזי (⁨CBDC⁩) לשימוש קמעונאי, סיטונאי או לשניהם. ⁨BIS Papers No 159⁩ · סקר ⁨CBDC⁩ לשנת ⁨2024⁩
למה עכשיו

הכסף הדיגיטלי הופך לריבוני. תשלומים לא יכולים להישאר במערכות מבודדות.

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

ריבונות בלי בידוד.

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

⁨01⁩ · קישוריות בין מערכות

חיבור מערכות ריבוניות

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

השאלהאיך מוסדות עצמאיים משלימים החלפה אחת?

תשלום ומסירת נכס יכולים להיסלק יחד, בעוד כל מוסד שומר על גבולות המדיניות שלו.

01

שער ⁨ISO 20022⁩

מתחילים בהודעות התשלום שמוסדות כבר משתמשים בהן.

תשלום נכנס ל־⁨Nexus⁩ דרך ⁨Torii⁩, ממשק ⁨Iroha⁩ לבקשות נכנסות. השער מאמת הודעות ⁨ISO 20022⁩ נתמכות, ובהן ⁨pacs.008⁩ ו־⁨pacs.009⁩, וממפה אותן להוראות בפנקס בהתאם למדיניות החלה.

בתוך הפרוטוקול

סטטוס ⁨pacs.002⁩ מחזיר את התוצאה לשולח. כך נוצר מסלול מוגדר למערכות מוסדיות: מהודעת תשלום מוכרת לפעולה מורשית בפנקס המשותף.

הודעות מוכרות

כוונת תשלום מוסדית מגיעה במבני ⁨pacs.008⁩ ו־⁨pacs.009⁩.

פעולה דטרמיניסטית

הודעות שאומתו ממופות להוראות ⁨Iroha⁩ מפורשות לפי המדיניות המקומית.

תגובה קנונית

סטטוס ⁨pacs.002⁩ מתעד אם הבקשה התקבלה, נדחתה או נסלקה.

אטלס הפרוטוקול

שער ⁨ISO 20022⁩

הודעות ⁨pacs.008⁩ ו־⁨pacs.009⁩ מאומתות, מבוצעות ונענות בתוצאת ⁨pacs.002⁩ דטרמיניסטית.

גשר ⁨ISO 20022⁩ מכניסת הודעה ועד סטטוס דטרמיניסטיהודעות תשלום ⁨ISO 20022⁩, כגון ⁨pacs.008⁩ ו־⁨pacs.009⁩, נכנסות דרך ⁨Torii⁩. הגשר מאמת מזהים ונתוני ייחוס, בונה פעולת פנקס אחת ומציג סטטוס דטרמיניסטי דרך נקודת קצה של ⁨ISO⁩.שפה פיננסית משותפת⁨ISO⁩הודעה⁨Torii⁩בדיקהפעולת פנקססטטוס ⁨ISO⁩ הוחזר

⁨ISO 20022⁩ מאפשר להודעות תשלום מוסדיות להתחבר לסליקה ניתנת לתכנות המבוססת על בלוקצ׳יין ולכלכלה הדיגיטלית.

עקבו אחר העסקה⁨4⁩ שלבים
  1. הודעת ⁨pacs.008⁩ או ⁨pacs.009⁩ נכנסת דרך ⁨Torii⁩.
  2. אימות הסכמה והמדיניות קובע את הפעולה המבוקשת.
  3. ⁨Iroha⁩ מבצעת את הוראת הפנקס המתאימה.
  4. סטטוס ⁨pacs.002⁩ דטרמיניסטי מוחזר לשולח.
02

מרחבי נתונים ריבוניים

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

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

בתוך הפרוטוקול

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

מדיניות מקומית

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

ועדות מאמתים מוגדרות

עומס עבודה מוגבל יכול להשתמש בוועדה משלו בלי להפוך לשרשרת נפרדת.

קישוריות מורשית בין מערכות

רק ערך וראיות שאושרו חוצים גבול של מרחב; המצב הפרטי המלא נשאר בפנים.

אטלס הפרוטוקול

מרחבי נתונים ריבוניים

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

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

סביבות פתוחות וריבוניות חולקות מנוע אחד ושומרות על גבולות שונים.

עקבו אחר העסקה⁨3⁩ שלבים
  1. מרחבים ציבוריים ומוגבלים מחילים מדיניות מקומית משלהם.
  2. בקשה שקיבלה הרשאה מפורשת מגיעה לגבול.
  3. רק ראיות וערך שאושרו חוצים את גבול המרחב.
03

עסקאות אטומיות בין מרחבי נתונים

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

עסקה אטומית (⁨AMX⁩) מציינת כל מרחב נתונים שבו היא נוגעת ואת המצב שתקרא או תשנה. כל מרחב מכין את חלקו מתמונת מצב משותפת. ⁨Nexus⁩ מקבעת את השינוי רק כאשר כל התוצאות הנדרשות תקפות.

בתוך הפרוטוקול

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

הכול או לא כלום

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

תחום מוגדר במפורש

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

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

מרחב מוגבל יכול לייצא התחייבויות למצב וראיות תקפות במקום נתונים פרטיים גולמיים.

קישוריות בין מערכות

עסקאות אטומיות בין מרחבי נתונים

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

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

שני שינויים מקומיים הופכים לתוצאה משותפת אחת.

עקבו אחר העסקה⁨5⁩ שלבים
  1. הצהרה על שני מרחבי הנתונים, קבוצות הקריאה והכתיבה ותמונת מצב אחת של הקשר ההרשאות.
  2. מכינים ⁨A₀ → A₁⁩ ו־⁨B₀ → B₁⁩; שתי הוועדות מנפיקות תעודות קוורום (⁨QC⁩) של הכנה.
  3. שולחים את שתי ההוכחות ל־⁨Nexus⁩ וממתינים עד ששני המרחבים מוכנים.
  4. מעבירים תשלום ומסירה בכיוונים מנוגדים תחת נעילה אטומית אחת.
  5. קיבוע שני צדדי העסקה עם קבלת ⁨AMX⁩ קנונית — או שחזור שני השורשים ללא מצב חלקי.
04

נתב סליקה דטרמיניסטי

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

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

בתוך הפרוטוקול

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

המרה קנונית

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

הגנות על העתודות

מצבי חוצץ מוגדרים יכולים להתריע, להגביל קצב, לחייב סליקה ב־⁨XOR⁩ בלבד או לעצור את הסליקה.

ראיות לפי נתיב

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

תשלומים

נתב סליקה דטרמיניסטי

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

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

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

עקבו אחר העסקה⁨4⁩ שלבים
  1. בודקים את הסכום, קלט האורקל, המרווח ומדיניות הנזילות.
  2. חישוב התחייבות ⁨XOR⁩ הקנונית ומקדם ההפחתה שהוחל.
  3. בדיקת חוצץ הסליקה של הנתיב ומצב המדיניות שלו.
  4. חותמים את התחייבות הנתיב ומפיקים קבלה לצורכי התאמה.
⁨02⁩ · ביצוע

הופכים כל תוצאה לניתנת לאימות

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

השאלהאיך שני הצדדים יכולים לסמוך על אותה תוצאה סופית?

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

05

ליבת ⁨Hyperledger Iroha 3⁩

מעניקים לכל מאמת משתתף את אותם כללים לביצוע עסקה.

ההחלפות שתוארו לעיל זקוקות למנוע שהמשתתפים יכולים לאמת. ⁨Hyperledger Iroha 3⁩ מספקת אותו: ⁨Torii⁩ היא נקודת הכניסה לבקשות, ⁨Kotodama⁩ מהדרת תוכניות, והמכונה הווירטואלית של ⁨Iroha⁩ ‏(⁨IVM⁩) מבצעת את ההיגיון שלהן באופן דטרמיניסטי.

בתוך הפרוטוקול

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

סביבת ביצוע שלמה טיורינג

⁨Kotodama⁩ מהדרת תוכניות לקוד בתים של ⁨IVM⁩ הבטוח להרצה אצל מאמתים, כך שכל עמית מריץ את אותו היגיון מוגבל.

מחזור חיי נתיב בזמן ריצה

ניתוב, מניפסטים וטלמטריה מסתגלים להוספה או להוצאה משימוש של נתיבים בלי לחייב שרשרת חדשה.

פנקס קנוני אחד

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

אטלס הפרוטוקול

ליבת ⁨Iroha 3⁩

קבלה דרך ⁨Torii⁩, הידור ב־⁨Kotodama⁩, ביצוע דטרמיניסטי ב־⁨IVM⁩, ניתוב לנתיב וקיבוע קנוני אחד.

כיצד ⁨Hyperledger Iroha 3⁩ מגדילה את הקיבולת של פנקס אחד שלם טיורינג⁨Torii⁩ מקבלת תעבורה ו־⁨Kotodama⁩ מהדרת תוכניות לסביבת הביצוע ⁨IVM⁩. הסביבה מנתבת עבודה למספר נתיבים, ניתן להוסיף נתיבים חדשים בזמן ריצה, ו־⁨Sumeragi⁩ יחד עם ⁨Kura⁩ מקבעים פנקס קנוני אחד.מנוע אחד. פנקס קנוני אחד.⁨Torii⁩קבלת עסקאות⁨Kotodama⁩הידור תוכניות⁨Iroha VM⁩ביצוע דטרמיניסטינתיבים⁨Sumeragi + Kura⁩ → היסטוריה מקובעת

סביבת ביצוע אחת, נתיבים רבים, פנקס אחד.

עקבו אחר העסקה⁨4⁩ שלבים
  1. ⁨Torii⁩ מקבלת בקשה חתומה.
  2. תוכניות ⁨Kotodama⁩ מהודרות לקוד בתים לביצוע דטרמיניסטי ב־⁨IVM⁩.
  3. סביבת הביצוע מנתבת את התוצאה דרך הנתיב שהוקצה לה.
  4. ⁨Sumeragi⁩ ו־⁨Kura⁩ חותמים קיבוע קנוני אחד.
06

נתיבים ופנקס מיזוג

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

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

בתוך הפרוטוקול

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

מקביליות כברירת מחדל

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

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

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

פחות גשרים מפוזרים

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

אטלס הפרוטוקול

נתיבים ופנקס מיזוג

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

נתיבים מקבילים מתמזגים בחזרה לפנקס אחדכל נתיב שומר בלוק ועדכוני מצב משלו, ואז שולח התחייבויות לפנקס מיזוג אחד, כך שקצב העיבוד גדל בלי לפצל את ההיסטוריה המשותפת.עבודה במקביל. היסטוריה אחת.נתיב ⁨01⁩נתיב ⁨02⁩נתיב ⁨03⁩מיזוג התחייבויותפנקס אחד

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

עקבו אחר העסקה⁨3⁩ שלבים
  1. עומסי עבודה עצמאיים נכנסים לנתיבי ביצוע מקבילים.
  2. כל נתיב מפיק התחייבות מאושרת למצב.
  3. פנקס המיזוג מסדר את ההתחייבויות בבלוק אחד.
07

מחזור חיי נתיב בזמן ריצה

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

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

בתוך הפרוטוקול

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

נשלט בקונצנזוס

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

בדיקות מצב נוכחי

התחייבויות לקטלוג ולמופעי הנתיבים מונעות מבקשות שהתעכבו לשנות טופולוגיה אחרת.

ניקוי מתואם

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

הרחבה

מחזור חיי נתיב בזמן ריצה

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

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

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

עקבו אחר העסקה⁨4⁩ שלבים
  1. סוקרים את הקטלוג הנוכחי וחותמים על תוכנית למחזור חיי נתיב.
  2. בודקים הרשאה, התחייבות לקטלוג, מזהה מופע ובקרות בטיחות.
  3. קיבוע עדכון הטופולוגיה ורענון ניתוב התור.
  4. הפעלת הנתיב, או הוצאתו משימוש לאחר השלמת העבודה שנותרה.
08

הקונצנזוס של ⁨Sumeragi⁩

הופכים עבודה מקבילה לתוצאה מקובעת שהמאמתים מסכימים עליה.

⁨Sumeragi⁩ הוא מנגנון הקונצנזוס שמקבע סופית בלוק מוצע. המאמתים מאשרים אותו בשני שלבים, ⁨Prepare⁩ ו־⁨Commit⁩. כל תעודת קוורום (⁨QC⁩) קושרת את ההצבעות שלהם לבלוק המדויק, לגובהו, לרשימת המאמתים הקפואה ולשינוי המצב.

בתוך הפרוטוקול

המאמתים בודקים ושומרים את הבלוק בעמידות לפני ⁨Prepare⁩, שומרים את הנעילה שלהם לפני ⁨Commit⁩, ושומרים בעמידות את החלטת ⁨Commit QC⁩ לפני החלתה. הצבעות סותרות נדחות ונרשמות כראיות; הן לעולם אינן נספרות לקוורום.

שני שלבים מאושרים

תעודות קוורום של ⁨Prepare⁩ ושל ⁨Commit⁩ מגדירות במפורש את הדרך לסופיות.

אחסון עמיד לפני חתימה

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

ראיות ניידות

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

אטלס הפרוטוקול

הקונצנזוס של ⁨Sumeragi⁩

בלוק מדויק מתקדם דרך תעודות קוורום מסוג ⁨Prepare⁩ ו־⁨Commit⁩, בעוד שהצבעות סותרות נדחות ומדווחות.

כיצד הקונצנזוס של ⁨Sumeragi⁩ משיג סופיותמוביל מציע גוף בלוק מדויק. המאמתים בודקים אותו ושומרים אותו באחסון עמיד לפני יצירת תעודת קוורום מסוג ⁨Prepare⁩. לאחר מכן הם שומרים נעילה, יוצרים תעודת קוורום מסוג ⁨Commit⁩, שומרים את ההחלטה ומחילים את הבלוק. הצבעה סותרת נדחית ומדווחת כראיה במקום להיספר.בלוק אחד. החלטה סופית אחת.מציעים את גוף הבלוק. מאשרים את ההצבעות. שומרים את ההחלטה.גובה + סבב⁨h · r⁩ · רשימת מאמתים וכוח הצבעה קבועים⁨02⁩ · אימות ואחסון01הצעה⁨b7e1…⁩גוף ומניפסטגיבוב · מטען · שורשיםמדויקגוףתקף ושמור בעמידותסתירה נדחתה · ראיות נשמרו03⁨Prepare QC⁩תקף וזמיןהושג קוורום⁨04⁩ · נעול05⁨COMMIT QC⁩החלטה עמידהחתימת ⁨BLS⁩ מצטברת⁨06⁩ · סופיההחלטה נשמרה⁨COMMIT QC⁩ ונושא מדויקגוף הבלוק המדויק הוחלשורש מצב דטרמיניסטינפתח גובה ⁨h+1⁩ההיסטוריה הקנונית מתקדמת

המאמתים מאשרים בדיוק את אותו גוף בלוק בשלבי ⁨Prepare⁩ ו־⁨Commit⁩; תעודת ⁨Commit QC⁩ הופכת לראיית סופיות ניידת.

עקבו אחר העסקה⁨6⁩ שלבים
  1. המוביל הצפוי משדר הצעה חתומה ומניפסט מטען.
  2. המאמתים משחזרים, בודקים ושומרים בעמידות את גוף הבלוק המדויק.
  3. מספר מספק של מאמתים וכוח הצבעה מאשרים את שלב ⁨Prepare⁩.
  4. המאמתים שומרים את הנעילה המדויקת באחסון עמיד לפני שחרור הצבעות ⁨Commit⁩.
  5. תעודת קוורום מסוג ⁨Commit⁩ מקבעת סופית את הבלוק המדויק הזה.
  6. ההחלטה נשמרת באחסון עמיד, גוף הבלוק המדויק מוחל ונפתח הגובה הבא.
09

הוכחות סופיות הניתנות לאימות

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

הוכחה ניידת מאגדת את כותרת הבלוק הקנונית עם הרשומה העמידה והמדויקת של קונצנזוס ⁨Sumeragi⁩. הרשומה כוללת את הקשר גובה הבלוק שהוקפא, נושא הבלוק שאושר, התחייבות לביצוע, תעודת קוורום מסוג ⁨Commit⁩ ‏(⁨QC⁩) והוכחות להחזקת מפתחות, התואמות לרשימת המאמתים.

בתוך הפרוטוקול

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

ראיות מדויקות

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

קוורום כפול

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

האמון נשאר חיצוני

רשימת מאמתים המועברת בתוך הוכחה אינה יכולה לאמת את עצמה; ההקשר הראשון שמתקבל מעוגן דרך ערוץ מהימן בלתי תלוי.

סופיות

הוכחות סופיות הניתנות לאימות

כותרת קנונית ותוצר סופיות מדויק של ⁨Sumeragi⁩ הופכים לראיות ניידות, שהמאמת בודק מול הקשר שרשרת מהימן שנקבע באופן בלתי תלוי.

הוכחות סופיות הניתנות לאימותכותרת קנונית ותוצר סופיות מדויק של ⁨Sumeragi⁩ הופכים לראיות ניידות, שהמאמת בודק מול הקשר שרשרת מהימן שנקבע באופן בלתי תלוי.

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

עקבו אחר העסקה⁨4⁩ שלבים
  1. איגוד הכותרת, הנושא המאושר, שורשי הביצוע, תעודת הקיבוע, רשימת המאמתים שהוקפאה והוכחות ההחזקה.
  2. חותמים את הארטיפקט המדויק במעטפת הוכחה ניידת של ⁨Norito⁩.
  3. קישור ההוכחה לשרשרת הצפויה ולעוגן הקשר שנקבע כמהימן בנפרד.
  4. בדיקת הקשרים המבניים, שני ספי הקוורום, סדר החותמים, החזקת המפתחות וחתימת ⁨BLS⁩ המצטברת לפני קבלת הסופיות.
⁨03⁩ · תכנות

מיישמים מדיניות בפועל

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

השאלהמי רשאי לפעול, באילו תנאים ותחת אילו מגבלות?

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

10

תוכניות ⁨Kotodama⁩

מבטאים בקוד את הכללים של שוק, תשלום או יישום.

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

בתוך הפרוטוקול

המהדר מתרגם את התוכניות לקוד בתים של המכונה הווירטואלית של ⁨Iroha⁩ ‏(⁨IVM⁩). המאמתים מבצעים את אותו היגיון במסגרת מגבלות סביבת הביצוע וגוזרים את אותו שינוי מצב.

קוד מקור ברמה גבוהה

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

אותו פלט בכל מקום

ההידור מכוון למודל ביצוע אחד, המשותף לכל המאמתים.

מדיניות ומוצרים

אותו מודל תכנות יכול לבטא היגיון שוק, אוטומציה ובקרות.

אטלס הפרוטוקול

⁨Kotodama + IVM⁩

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

תהליך ההידור של ⁨Kotodama⁩תוכנית מקור קצרה ב־⁨Kotodama⁩ מתקמפלת לפלט ⁨IVM⁩ דטרמיניסטי. סביבת היעד היא ⁨IVM⁩, הביצוע נשאר תחום וכל מאמת מקבל את אותם בתי פלט.כותבים את הכללים. משחזרים את התוצאה.⁨policy.ko⁩קוד מקור ⁨Kotodama⁩הידור⁨IVM⁩קוד בתיםאותה תוצאה בכל צומת

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

עקבו אחר העסקה⁨3⁩ שלבים
  1. קוד מקור קריא ב־⁨Kotodama⁩ מהודר לקוד בתים של ⁨IVM⁩.
  2. הביצוע צורך תקציב מחזורים מוגבל.
  3. כל מאמת גוזר את אותו שינוי מצב.
11

הוראות מיוחדות של ⁨Iroha⁩

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

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

בתוך הפרוטוקול

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

פעולות מובנות

פעולות נפוצות בפנקס הן חלק מהפלטפורמה עצמה.

פיתוח מוצרים מהיר יותר

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

ביקורת פשוטה יותר

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

אטלס הפרוטוקול

הוראות מיוחדות של ⁨Iroha⁩

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

הוראות מיוחדות של ⁨Iroha⁩ כשינויי מצב מובניםאצווה חתומה ומסודרת רושמת הגדרת נכס, מנפיקה מאה יחידות, מעבירה שלושים יחידות, מעניקה הרשאה ושורפת עשר יחידות. כל הוראה בעלת טיפוס מוגדר עוברת בדיקות הרשאה ומדיניות, מכינה עדכון דטרמיניסטי בפנקס ותורמת למצב סופי מקובע אחד.חמש הוראות. שינוי מצב אחד.פעולות מובנות, המוחלות לפי הסדר.אצוות ⁨ISI⁩ חתומההרשאה ומדיניות בכל שלבמצב פנקס בהכנהלפי סדר · כשל מבטל את כל ההשפעות שהוכנורישום נכס⁨iroha.register⁩רשום⁨CREDIT#CBDC⁩היצע ⁨0⁩הנפקת ⁨100⁩⁨iroha.mint⁩הונפקו ⁨+100⁩היצע ⁨100⁩מנפיק ⁨100⁩העברת ⁨30⁩⁨iroha.transfer⁩הועברו ⁨30⁩מנפיק ⁨70⁩מקבל ⁨30⁩ · היצע ⁨100⁩הענקת גישה⁨iroha.grant⁩מורשההרשאה ⁨+1⁩היתרות ללא שינוישריפת ⁨10⁩⁨iroha.burn⁩נשרפו ⁨10⁩היצע ⁨90⁩מנפיק ⁨60⁩המצב קובעאצוות ⁨ISI⁩ מסודרתהיצע ⁨90⁩ · מנפיק ⁨60⁩ · מקבל ⁨30⁩ · הרשאה ⁨+1⁩

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

עקבו אחר העסקה⁨5⁩ שלבים
  1. רושמים ⁨CREDIT#CBDC⁩ עם היצע אפס.
  2. מנפיקים ⁨100⁩ יחידות למנפיק לאחר בדיקות הרשאה ומדיניות.
  3. מעבירים ⁨30⁩ יחידות למקבל בלי לשנות את ההיצע הכולל.
  4. מעניקים הרשאה אחת בלי לשנות יתרות.
  5. שריפת ⁨10⁩ יחידות של המנפיק וקיבוע היצע סופי של ⁨90⁩.
12

מניפסטים של יכולות

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

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

בתוך הפרוטוקול

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

הרשאות מזעריות

ההרשאה תחומה למרחבי נתונים, תוכניות, מתודות, נכסים ותפקידים מוגדרים.

מגבלות דטרמיניסטיות

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

איסור גובר

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

מדיניות

מניפסטים של יכולות

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

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

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

עקבו אחר העסקה⁨4⁩ שלבים
  1. מזהים את החשבון האוניברסלי ואת המניפסט הפעיל של חשבון היעד.
  2. בדיקת מרחב הנתונים, התוכנית, המתודה, הנכס והתפקיד המבוקשים.
  3. בדיקת תקופת הבקשה והסכום הנוכחי מול תקרת המניפסט.
  4. סורקים כללי איסור תואמים, ואז מחזירים הרשאה מותרת או דחייה מובנית.
13

אוטומציה על השרשרת

מריצים פעולה מורשית כשהאירוע הרשום שלה מתרחש.

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

בתוך הפרוטוקול

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

תזמון מובנה ברשת

תהליכים מתוזמנים ומונחי אירועים אינם תלויים בבוט נפרד או בשירות ⁨cron⁩.

מסנן מדויק אחד

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

ביצוע תחום

הרשאות, חזרות, דלק או מחזורים, גז ועומק ביצוע מגבילים את העבודה האוטומטית.

אטלס הפרוטוקול

אוטומציה על השרשרת

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

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

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

עקבו אחר העסקה⁨5⁩ שלבים
  1. בוחרים טריגר עם מסנן לבלוק מאושר אחד ומדויק.
  2. האירוע התואם טוען את התוכנית הרשומה שלו, את ההרשאה ואת מספר החזרות שנותרו.
  3. בדיקת המסנן, מצב ההפעלה, ההרשאה ומגבלות הביצוע.
  4. מכינים את שינוי המצב ומפחיתים חזרה אחת מהמכסה במקרה של הצלחה.
  5. ⁨TriggerCompleted⁩ מתעד את מזהה הטריגר, גיבוב הביצוע, השלב והתוצאה.
14

מקודד ⁨Norito⁩

נותנים לכל משתתף דרך חד־משמעית לקרוא את אותם נתונים.

תוכניות, הוראות והוכחות זקוקות לפורמט נתונים משותף. ⁨Norito⁩ מקודדת ערכים בעלי טיפוס מוגדר בסדר שדות קבוע. כותרת ⁨NRT0⁩ בת ⁨40⁩ בתים מציינת את הגרסה, הסכמה הצפויה, מצב הדחיסה, האורך, סכום הביקורת והמבנה.

בתוך הפרוטוקול

הקורא בודק את השדות האלה ואת סכום הביקורת ⁨CRC64-XZ⁩ לשלמות הנתונים לפני שחזור הערך. עם אותה סכמה ומבנה לא־דחוס מפורש, אותו ערך מפיק אותם בתים. דחיסה אופציונלית שומרת על התוכן המפוענח; הבתים הדחוסים עשויים להשתנות בין מימושים.

מסגרות הקשורות לסכמה

גיבוב סכמה בן ⁨16⁩ בתים קושר את המטען לטיפוס שהמפענח מצפה לקבל.

אימות בהזרמה

הקורא צורך את המטען המוצהר, ואז מאמת את סכום הביקורת ⁨CRC64-XZ⁩ לשלמותו.

שחזור מדויק

סדר שדות קנוני וכללי מבנה מפורשים מסירים עמימות מתהליך הקידוד והפענוח.

אטלס הפרוטוקול

מקודד ⁨Norito⁩

ערך מטיפוס מוגדר הופך למסגרת ⁨NRT0⁩ הקשורה לסכמה, עובר קורא מקטעים ובדיקות פורמט ושלמות ומשוחזר במדויק.

קידוד ושחזור קנוניים ב־⁨Norito⁩רשומת העברה בעלת טיפוס מוגדר הופכת למטען קנוני במסגרת ⁨NRT0⁩ עם כותרת בת ⁨40⁩ בתים. קורא זרם בודק את הגרסה, דגלי המבנה, גיבוב הסכמה, האורך המוצהר וסכום הביקורת ⁨CRC64-XZ⁩ לפני שחזור אותו ערך מטיפוס מוגדר.

ערך מטיפוס מוגדר הופך למסגרת ⁨NRT0⁩ מאומתת ומשוחזר באופן חד־משמעי.

עקבו אחר העסקה⁨5⁩ שלבים
  1. שדות מסודרים מקודדים למטען קנוני אחד.
  2. הוספת כותרת ⁨NRT0⁩ עם סכמה, אורך, סכום ביקורת, דחיסה ומטא־נתונים של המבנה.
  3. הקורא מקבל את הכותרת ואת המטען במקטעים.
  4. חתימת הזיהוי, הגרסה, דגלי המבנה, הסכמה, האורך המוצהר ו־⁨CRC64-XZ⁩ נבדקים לפי הסדר.
  5. משחזרים את הערך המקורי, מטיפוס מוגדר, מתוך המטען המאומת.
15

⁨SoraNet + SoraFS⁩

מאפשרים ליישומים לאחזר תוכן ולאמת את מה שהתקבל.

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

בתוך הפרוטוקול

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

מסלול ממסרים נבחר

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

אחזור הקשור למניפסט

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

מאמתים, ואז מוסרים

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

אטלס הפרוטוקול

⁨SoraNet + SoraFS⁩

בקשת תוכן מוסווית עוברת במסלול ⁨SoraNet⁩ נבחר בן שלוש תחנות. ⁨SoraFS⁩ מאתרת את המניפסט, מאחזרת ומאמתת מקטעים ממספר ספקים, משחזרת את המטען ומחזירה את האובייקט המאומת בצירוף ראיות לאחזור.

תעבורה ב־⁨SoraNet⁩ ואחזור ב־⁨SoraFS⁩בקשה הממוענת לפי תוכן הופכת למפתח מוסווה, עוברת במסלול ⁨SoraNet⁩ נבחר בן שלוש תחנות ומגיעה ל־⁨SoraFS⁩. ‏⁨SoraFS⁩ מאתרת את המניפסט, מאחזרת מקטעים ממספר ספקים, מאמתת כל מקטע, משחזרת את המטען ומחזירה את האובייקט המאומת בצירוף ראיות לאחזור.

⁨SoraNet⁩ בוחרת את מסלול הממסרים. ⁨SoraFS⁩ מאחזרת, מאמתת ומשחזרת את התוכן.

עקבו אחר העסקה⁨8⁩ שלבים
  1. בקשה הממוענת לפי תוכן הופכת למפתח מוסווה.
  2. תפקיד, גרסה ומדיניות תעבורה מחמירה קובעים את מסלול ⁨SoraNet⁩.
  3. הבקשה עוברת דרך ממסרי כניסה, ביניים ויציאה.
  4. ⁨SoraFS⁩ מאתרת את המניפסט ואת ערכי הגיבוב הצפויים של המקטעים.
  5. ספקים מתאימים מחזירים מקטעים לחוצץ שחזור מסודר.
  6. כל מקטע והמטען המלא תואמים להתחייבויות שבמניפסט.
  7. האובייקט המאומת וראיות האחזור חוזרים דרך המסלול הנבחר.
  8. המסירה מושלמת; כל תשלום מורשה בפנקס נשאר פעולה נפרדת שניתן לשלב.
⁨04⁩ · כלכלת סוכנים

מרחיבים את הכלכלה לסוכני ⁨AI⁩

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

השאלההאם סוכן תוכנה מורשה יכול להשתתף?

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

16

כלכלה משותפת לסוכני ⁨AI⁩

שימוש עתידי אפשרי · ⁨Iroha⁩ מספקת את אבני הבניין לחשבונות, נכסים, מדיניות וסליקה. מודלי ⁨AI⁩ פועלים מחוץ לפרוטוקול.

מרחיבים את דפוס ההחלפה לכלכלת שירותים אפשרית: סוכני ⁨AI⁩ יוכלו לשלם על שירותים לפי אותם כללי חשבון, הרשאות וסליקה.

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

בתוך הפרוטוקול

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

תוכניות ⁨Kotodama⁩ הפועלות במכונה הווירטואלית של ⁨Iroha⁩ ‏(⁨IVM⁩), יחד עם טריגרים על השרשרת, יכולות לבצע אוטומטית תשלומים, תנאי מסירה, משימות חוזרות וקבלות. עסקה אטומית יכולה לגרום לתשלום ולמסירת נכס להצליח או להתבטל יחד בין מרחבי נתונים. רשומות ⁨Norito⁩ קנוניות וסופיות ⁨Sumeragi⁩ יכולות לספק היסטוריה הניתנת לביקורת של הפעולות שאושרו ונסלקו.

זהו שימוש עתידי אפשרי באבני הבניין של ⁨Iroha⁩ לכלכלה, לאוטומציה ולמדיניות. הפרוטוקול אינו מריץ מודלי ⁨AI⁩, אינו קובע אם חשבון נשלט בידי ⁨AI⁩ ואינו מעניק לשום סוכן עצמאות בלתי מוגבלת.

ערך קריא למכונה

חשבונות מורשים יכולים ליצור ולהחליף נכסים בני־חליפין, ⁨NFT⁩ וזכויות לשירותים.

החלפה אטומית

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

הרשאות שנקבעות בידי אדם

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

שימוש עתידי אפשרי

כלכלה משותפת לסוכני ⁨AI⁩

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

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

כלכלת שירותים אפשרית המבוססת על חשבונות, נכסים וכללים שבני אדם מגדירים.

עקבו אחר העסקה⁨8⁩ שלבים
  1. חשבון קונה מבקש נתונים, כוח מחשוב, אחסון או שירות אחר הניתן לקריאה ממוכנת.
  2. החשבון עובר בדיקות הרשאה, יתרה ומגבלת הוצאה.
  3. חשבון ספק מורשה רושם או מנפיק את נכס השירות.
  4. תשלום ומסירת נכס נכנסים לעסקה אטומית אחת החוצה מרחבי נתונים.
  5. הערך עובר לספק בזמן שזכות השירות עוברת לקונה.
  6. שני הצדדים מקבעים יחד, או ששניהם חוזרים למצב הקודם באופן גלוי.
  7. טריגר על השרשרת מפיק קבלות קנוניות לביקורת של המפעילים.
  8. חשבון שלישי בעל הרשאה יכול לרכוש את הנכס או להחליף אותו בהתאם למדיניות שלו.
⁨05⁩ · פרטיות

מגינים על הנתונים שמאחורי העסקה

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

השאלהמה צריך להוכיח, ומה יכול להישאר פרטי?

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

17

מסלול ההוכחה של ⁨FASTPQ⁩

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

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

בתוך הפרוטוקול

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

עקבות פרטיות

ביצוע רגיש נשאר בתוך מרחב הנתונים שבו נוצר.

התחייבות ציבורית

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

קבלה מאומתת

הוכחה נדרשת יכולה לעבור או להיכשל בכלל הקבלה הציבורי לפני ההכנסה לתור.

אטלס הפרוטוקול

מסלול ההוכחה של ⁨FASTPQ⁩

התחייבויות לעקבות פרטיות הופכות לקלט ציבורי להוכחה ולהחלטה מאומתת, בלי לחשוף את העקבות.

מסלול ההוכחה של ⁨FASTPQ⁩⁨FASTPQ⁩ פועל על עקבות שורות ועמודות בורר, יוצר התחייבויות באמצעות ⁨Poseidon2⁩ ונתיבי מצב, ומאמת מול קלט ציבורי כגון מזהה מרחב נתונים, משבצת ושורשים.ביצוע פרטי. אימות ציבורי.עקבות פרטיות⁨Poseidon2⁩התחייבותהוכחהמאומתקלט ציבורימרחב · משבצת · שורשים

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

עקבו אחר העסקה⁨3⁩ שלבים
  1. עקבת ביצוע פרטית נשארת בתוך מרחב הנתונים שלה.
  2. מפרסמים התחייבות וקלט להוכחה בזמן שהעקבות נשארות מקומיות.
  3. האימות מכריע בשאלת הקבלה בלי לחשוף את העקבות.
18

קבלה באמצעות הוכחות פרטיות

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

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

בתוך הפרוטוקול

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

שורשים הקשורים למניפסט

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

מסלול קבלה אחד

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

חסימה בעת כשל

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

פרטיות

קבלה באמצעות הוכחות פרטיות

נתיב פרטי מוכיח את ההתחייבות שלו מול שורש מאושר, בלי לחשוף את הפעילות הריבונית שבבסיסה.

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

המצב המוגן נשאר מקומי; הקבלה מותנית בראיות מאושרות.

עקבו אחר העסקה⁨4⁩ שלבים
  1. מנתבים את העסקה לנתיב שלה וטוענים את מרשם ההתחייבויות העדכני.
  2. מתאימים את ההוכחה המצורפת למזהה התחייבות רשום.
  3. מאמתים את העדות ובוחנים את דרישת התאימות של הנתיב.
  4. קבלת ראיות תקפות ודחייה גלויה של המסלול שבו חסרה הוכחה.
19

זמינות נתונים והוכחות

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

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

בתוך הפרוטוקול

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

היסטוריה הניתנת לשחזור

נתונים מעוגנים צריכים להישאר ניתנים לשחזור זמן רב לאחר כתיבתם.

הוכחות המגובות באחזור

בדיקות זמינות משאירות את האמון מעוגן בנתונים עצמם.

רשומות לטווח ארוך

המערך הטכנולוגי מיועד למערכות שבהן הרשומות חייבות להישאר שימושיות במשך שנים.

אטלס הפרוטוקול

זמינות נתונים

נתונים המחולקים למקטעים נדגמים, שורדים אובדן חלקי ומשוחזרים מן המקטעים שנותרו.

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

מסלולי דגימה ושחזור שומרים על שלמות הזיכרון של הרשת.

עקבו אחר העסקה⁨3⁩ שלבים
  1. נתונים מעוגנים מקודדים לשברים הניתנים לשחזור.
  2. המאמתים דוגמים מקטעים כדי לבדוק זמינות, גם כשחלק מהמקטעים חסרים.
  3. כמות המקטעים שנותרה מספיקה לשחזור הנתונים המקוריים.