פיתוח אינסקריפציות Ordinals וקולקציות NFT על Bitcoin

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

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

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

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

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

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

מה נותן שכב אינדוקסציה ומטא-נתונים משלך

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

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

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

שיעור חוסר הסנכרון

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

סוג תקלות שנסלל באינדוקסציה חוזרת

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

יכולת חיזוי של ההנפקה בשיאים

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

גישות לפיתוח Ordinals: השוואת מצבי הנפקה

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

היכן הגבול בין ויטרינה משלך להיבריד

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

מתי הנפקה באצוות הכרחית

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

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

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

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

קריטריוני מוכנות: נתונים והנפקה

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

קריטריוני מוכנות: ויטרינה ומסירה

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

מארז האספקה: קונפיגורציות, סכימות ותקנונים

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

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

מה חושפות הקונפיגורציות

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

מה חושפים התקנונים

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

מקרה בוחן: קולקציה של 10,000 אינסקריפציות — מדדים לפני ואחרי

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

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

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

אילו מדידות נדגמו ואיך

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

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

במה נבדלת אינסקריפציה מטוקן בתקן BRC-20?

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

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

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

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

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

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

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

האם אפשר להחליף את סכימת המטא-נתונים לאחר ההנפקה?

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

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

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

איך מעבירים קולקציה לפלטפורמה אחרת?

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

איך בודקים תקינות לפני מכירה ציבורית?

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

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

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

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

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