פיתוח מערכת חברות NFT: חוזים חכמים וארכיטקטורה

פיתוח NFT-membership: היכן נשברת הקצאת גישה

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

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

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

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

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

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

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

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

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

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

פורמטים של פיתוח: חוזה משלך מול פלטפורמה מוכנה

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

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

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

היכן לרוב נתקלת פלטפורמה מוכנה בתקרה

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: מועדון גישה סגורה צמצם הקצאת הרשאות ידנית

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

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

מדדים לפני ואחרי

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

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

מה לעשות אם הגישה כבר מוקצית ידנית דרך טבלאות?

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

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

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

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

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

ספקות טכניים: תפקידים, שחזור, מיגרציה

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

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

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

איך בנוי ביטול חברות?

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

אפשר להעביר טוקנים שכבר הונפקו לחוזה חדש?

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

נדון במשימה: מה לשלוח ומה נבדוק

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

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

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