פיתוח מערכת גישה זמנית באמצעות NFT וחוזים חכמים

פיתוח מנוי NFT: היכן נשברת גישה זמנית

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

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

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

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

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

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

מה נותן מנוי על חוזים חכמים: אפקט במדדים

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

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

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

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

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

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

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

במה נבדלים האפשרויות

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

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

שלבי העבודה: מסכמת הגישה ועד מסירת החוזה

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

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

ערכת מסירה: חוזים, סכמות, נהלי גישה

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

הערכה נבנית בהתאם לתהליך שלכם, ולא לסכמה נוחה לנו: תארו את המשימה — נחזור עם הערכה ותוכנית מסירה.

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

מה היה לפני

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

מה שינו

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

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

מה נהיה

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

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

מה לעשות אם אסימון NFT לגישה אבד יחד עם הארנק?

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

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

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

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

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

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

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

הרשת אינה זמינה ברגע ההארכה — האם הגישה תיפסק?

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

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

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

נדון במשימה: תרחיש גישה והיקף העבודה

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

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

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