פיתוח טוקן ERC-1155 (מולטי-טוקן)

פיתוח ERC-1155: היכן נשבר רישום הנכסים

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

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

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

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

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

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

מה נותן מרשם אחיד לנכסים מסוגים שונים

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

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

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

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

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

פורמטים של מימוש: פיתוח ERC-1155 או חוזים נפרדים

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

כיצד אנו בוחרים פורמט חוזה

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

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

שלבי יישום: מביקורת נכסים ועד מסירה

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

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

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

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

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

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

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

ארטיפקטי מסירה: חוזים, תפקידים, תקנונים

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

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

מקרה בוחן: שלושה סוגי נכסים במרשם אחד

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

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

שיעור הפעולות שנדרשו להתאמה ידנית של שני מקורות עמד על 100%: השרשרת והטבלה התפצלו כבר ביום השני-שלישי, ואי אפשר היה לבדוק אחרת את הצירוף «היתר גישה ופריט אצל אותו בעלים».

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

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

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

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

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

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

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

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

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

מגבלות התקן וספקות טכניים אופייניים

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

כיצד להפריד בין הרשאות של מחלקות?

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

כיצד להגביל העברות לפי סטטוס הנכס?

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

כיצד לוודא שהלוגיקה נכונה לפני ההשקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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