אסימוני SPL של Solana: יצירה עם Transfer Hook ו-Mint

טוקן SPL: היכן נשברים ההנפקה, האמיסיה וההעברות

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

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

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

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

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

מה נותן טוקן SPL מנוהל: הנפקה, תפקידים, העברות

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

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

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

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

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

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

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

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

אפשרויות הנפקה: הרחבות מול תוכנית כללים נפרדת

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

הרחבות מערך הבסיס מול תוכנית משלנו

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

מתי מספיקות מגבלות ברמת האמיסיה

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

איך מתבצעת הטמעה: מביקורת דרישות ועד מסירה

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

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

סכמת תפקידים וגבולות אמון

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

קונפיגורציות, תפקידים ותיעוד למסירה

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

קונפיגורציות ותקנוני תחזוקה

• דרכון הטוקן: כתובת mint, מספר הספרות העשרוניות, היקף האמיסיה, המחזיק הנוכחי של mint authority ו-freeze authority, סימן של Transfer Hook מופעל.
• מדיניות גישה: אילו כתובות יכולות להנפיק, לשרוף ולשנות מטא-נתונים, ואילו רק להעביר; כללי החלפת authority ואישור פעולות.
• הגדרות Transfer Hook: כתובת תוכנית המטפל, אילו בדיקות מבוצעות בהעברה נכנסת ויוצאת, מה קורה כשבדיקה נכשלת.
• תקנון תחזוקה: תדירות רוטציית המפתחות, סדר עדכון המטא-נתונים, תנאים ונוהל לניתוק ה-hook.
• תיאור סביבות: רשת בדיקה ורשת ראשית, התאמת כתובות ורשימות גורמים מורשים ביניהן.
• יומן שינויים: מה, בידי מי ועל איזה בסיס השתנה בקונפיגורציה, כדי שהחזרה אחורה תהיה משוחזרת.

תיעוד למפתחי אינטגרציה

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

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

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

מה היה לפני ומה השתנה אחרי

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

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

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

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

היכן שהמדד לא השתנה

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

במה מגבלות אמיסיה שונות מה-hook של העברות?

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

למי יישארו מפתחות המנהל?

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

איך נבדק הקוד לפני פרסום?

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

האם אפשר לשנות כללים אחרי ההשקה?

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

מה כלול בתמיכה אחרי ההשקה?

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

בואו נדבר על המשימה: מה להכין לשיחה

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

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

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