מדוע טוקן BRC-20 מאבד נתונים בעת אינדוקס
BRC-20 אינו פרוטוקול נפרד עם קונצנזוס משלו, אלא תוספת מעל Ordinals: היתרות אינן נשמרות בשום מקום ברשת, אותן מחשב האינדקסר, תוך פענוח האינסקריפציות בבלוקים. זהו שורש הבעיה — הרשת מתעדת רשומות, ואילו מצב הטוקן קיים רק במערכת החשבונאות של מי שקורא את הרשומות הללו.
כשל טיפוסי נראה כך: האינסקריפציות בבלוקים במקומן, העסקאות מאושרות, אך יתרות המחזיקים אינן תואמות את הנגלה בפענוח בלתי תלוי. הסיבות שלוש. הראשונה — הפעלה מחדש של האינדוקס מנקודת ביקורת שגויה או מעבר מלא על ההיסטוריה בעת קטיעה: חלק מהבלוקים מעובדים פעמיים, וחלק מדולגים.
השנייה — פרשנות שונה לרשומות ordinals: JSON לא תקין, הנפקה חוזרת עם אותו טיקר, אינסקריפציה על פלט "תלוי" — אינדקסר אחד מחשיב אותן כתקפות, אחר פוסל אותן, והנפקת BRC-20 מפסיקה להסתדר.
השלישית — העברה בשני שלבים: תחילה אינסקריפציה להעברה, לאחר מכן קישור לפלט; אם מתחשבים רק בשלב הראשון, הטוקן נתקע בין כתובות.
באופן נפרד פוגעת רה-ארגון של הבלוקצ'יין: בעת ביטול ענף, האינדקסר חייב להסיר את ההשפעה של הבלוקים שבוטלו ולשחזר אותם מחדש. בלעדי זאת, הפער בין החשבונאות לרשת נשאר במסד הנתונים לנצח ורק הולך וגדל — כל פעולה עוקבת מחושבת ממצב שגוי.
מה שהופך כשל כזה לשקט הוא היעדר התאמה: כל עוד אף אחד אינו משווה את תוצאת האינדקסר לפענוח בלתי תלוי לפי גבהים, השגיאה אינה מתגלה עד לרגע המשיכה או הרישום למסחר.
הדבר נסגר באמצעות התאמת דלתא לכל בלוק, אינדוקס מחדש משוחזר מנקודת ביקורת, ופרשנות קנונית אחידה לרשומות — בהמשך נפרט כיצד זה בנוי אצלנו בהנפקה.
האפקט של ההשקה: זמן ההנפקה, דיוק החשבונאות, מחלקת כשלים
לאחר הנפקה שתוכננה כהלכה, לוחות הזמנים משתנים פי כמה. תיוג אצוות סאטושי, יצירת האינסקריפציות וחתימת הסדרה מתבצעים במעבר משוחזר אחד במקום פעולות ידניות בארנק — מהגדרת המשימה ועד לעסקה המאושרת הראשונה חולפים ימים, ולא שבועות. הנפקה חוזרת מתבצעת לפי אותו תרחיש עם פרמטרים משתנים.
מהירות האישור של הפעולות מפסיקה להיות תלויה במזל. המהנדסים מחשבים את שיעור העמלה לפי העומס בתור, מפצלים את ההנפקה לחבילות ומשאירים מרווח לבנייה מחדש של השרשרת, ולכן העסקאות נכנסות לבלוק באופן צפוי — בלי שליחה ידנית חוזרת ובלי איבוד מקום בתוך הסדרה.
את דיוק החשבונאות מחזיק אינדקסר עצמי: הוא מרכיב את המצב מהבלוקים של Ordinals ומשווה אותו להנפקה עד היחידה האחרונה. שיעור ההתאמות הנעשות ביד יורד כמעט לאפס — הפער צף ועולה בעת פענוח הבלוק, ולא בדוחות בפני המחזיקים.
נעלמת מחלקת כשלים שלמה: כפילויות של אינסקריפציות, אובדן יתרה בעודף, הפרת הסדר בתוך הסדרה, נזק לסאטושי המתויגים בעת העברה. חלק מהן לא נתפס כלל בעבר והתגלה רק בניסיון למכור את הנכס.
עמידות האינדוקס — קו מתאר נפרד. בנייה מחדש של השרשרת, מסירה חוזרת ובקשות מקבילות מעובדות באופן אידמפוטנטי, ולכן היתרות והיסטוריית הפעולות משוחזרות בלי התערבות ידנית ובלי עצירת השירות.
דרכים להנפקת טוקן BRC-20: השוואת גישות
BRC-20 אינו חוזה חכם, אלא רשומה בנתוני האינסקריפציה של Ordinals, שאותה מפרש האינדקסר. הטוקן עצמו אינו קיים ברשת: היתרות, מגבלות הטביעה וההעברות נקבעות על ידי אותה לוגיקת פענוח שאליה מסתכלים הארנקים, הפלטפורמות והבורסות. לכן הבחירה בדרך ההנפקה היא בראש ובראשונה בחירה במי שמחשב את מצב הטוקן ולפי אילו כללים.
מצבי ההנפקה נקבעים באותה רמה: דיפלוי עם טביעה פתוחה, טביעה עם הגבלה לפעולה אחת ותקרה כוללת, הנפקה עם העברה לאחר מכן.
למגבלות החשבונאות, שמהן תלויה התאימות לשירותים חיצוניים, שייכים הסדר של האינסקריפציות בתוך הבלוק, טביעות בו-זמניות לאותה מגבלה, רשומות לא תקינות וחוזרות, וכן בנייה מחדש של השרשרת — האינדקס חייב לבטל כראוי פעולות שכבר נספרו.
השוואת גישות ההנפקה
| אפשרות | מתי מתאימה | במה מגבילה |
|---|---|---|
| כלי מוכן | השקה מהירה, מצב הנפקה סטנדרטי, בדיקת ביקוש | את כללי החשבונאות קובעת הפלטפורמה, אין אינדקס יתרות משלנו, טביעות וצילומי יתרות לא סטנדרטיים אינם זמינים |
| מעטפת על אינדקסר פתוח | יש צורך בכללי טביעה משלנו ובממשק יתרות משלנו | לוגיקת פענוח הבלוקים זרה, מהירות האינדוקס מחדש לאחר כשל מוגבלת |
| אינדקסר עצמי | מצבי הנפקה לא סטנדרטיים, צילומי יתרות להפצות, דרישות לחסינות מפני כשלים | זמן ארוך יותר, נדרש תמיכה מתמדת בעת שינוי התקן וכללי הפלטפורמות |
אינדקסר עצמי מוצדק במקומות שבהם יש צורך לשנות את כללי הטביעה והחשבונאות בהתאם למשימה, ולא להתאים את המשימה לפלטפורמה זרה.
שלבי העבודה: אבחון המשימה, תכנית ההנפקה, בדיקה, מסירה
את סדר העבודה אנו בונים כך שכל שלב עוקב יישען על תוצאה קבועה של השלב הקודם. בכניסה — בחינת המשימה: סוג הטוקן, לוגיקת ההנפקה, מי מחזיק במפתחות, אילו מגבלות על העמלה ועל היקף הרשומות.
זה מסיר את הסיכון העיקרי של ההנפקה — אי-הפיכות: רשומה בבלוקצ'יין אינה מתבטלת, ולכן טעות בפרמטרים או בכתובת הנמען מתוקנת רק בהנפקה חדשה.
- אבחון המשימה. אנו מנתחים את חלוקת הנתחים, המגבלות לפעולה אחת, מספר הרשומות העתידיות ואת מי שמאשר את ההנפקה. בתוצאה — מפת סיכונים ודרישות לארנקים ולהרשאות.
- תכנית ההנפקה. אנו קובעים את ההיקף הכולל, צעד ההנפקה, כללי השחרור וכתובת הרזרבה. את התכנית מתאמים לפני הרשומה הראשונה — לאחר ההנפקה אי אפשר לשנותה.
- הגדרת ההנפקה. אנו מרכיבים את הרשומות, קובעים את סדר הכניסות ואת מרווח העמלה, כדי שההנפקה לא תיתקע בתור בעומס שיא על הרשת.
- בדיקה ברשת בדיקה. אנו מריצים מחזור מלא: הנפקה, העברה, הפעלת המגבלות, שחזור הארנק מגיבוי. בנפרד אנו מתאימים את האינדוקס — היתרות בארנק הפנימי ובאקספלוררים של צד שלישי חייבות להיות זהות עד לרשומה.
- קבלה לפי רשימת בדיקה. אנו בודקים כל סעיף מול התוצאה הצפויה, וסוגרים פערים לפני המסירה, ולא אחריה.
- מסירת השליטה. אנו מוסרים הרשאות ותכנית חתימה, הוראות למשמרת תורנית ותקנון פעולה בעת שינוי עמלות או מגבלות.
לאחר המסירה אנו נשארים בקשר לתקופת הליווי — תיקונים בתכנית ההנפקה נדונים בנפרד ומוכנסים רק באישור.
חבילת המסירה: תצורות, תכניות חשבונאות, תקנונים
חבילת המסירה אינה תיקייה עם קבצים "ליתר ביטחון", אלא מכלול של חפצי עבודה שלפיהם הצוות שלכם יוכל להנפיק טוקן בעצמו, לקרוא את מצבו ולתחזק אותו בלי המעורבות שלנו.
אנו מקבעים את המערכת לרגע המסירה: מה פרוס, היכן מאוחסנים המפתחות, כיצד נקבעת היתרה ומה לעשות בעת אי-התאמה בין הצמתים.
- תצורות של הצומת והאינדוקס — פרמטרי העבודה של סנכרון, אחסון בלוקים ופענוח האינסקריפציות, עם ציון אילו ערכים שונו ומדוע דווקא כך.
- תכניות זרימות החשבונאות — המסלול מההנפקה ועד הזיכוי לכתובת: היכן נוצרת ההעברה, כיצד מחושבת היתרה, ובאיזה רגע היתרה הופכת לסופית.
- מדיניות הגישה למפתחות — הפרדת תפקידי ההנפקה, הטביעה וחתימת ההעברות, ספי ריבוי החתימות, סדר הרוטציה ושמירת הגיבויים.
- תקנון התפעול — בדיקות מתוכננות, תגובה לרה-ארגון של השרשרת, שליחה חוזרת ואי-התאמה בין אינדקסים, חלונות תחזוקה וסדר הוצאת הצומת מפעולה.
- הוראות לצוות — תרחישים שלב אחר שלב: הנפקת האצווה הבאה, הוספת טוקן, ביטול פעולה כושלת, שחזור מגיבוי.
- דוח בדיקות עומס ויומן תצפיות — מה נבדק ובאיזה עומס, אילו צווארי בקבוק נותרו וכיצד לעקוב אחריהם.
מקרה בוחן: כיצד החשבונאות של הנכס הפסיקה לסתור את הרשת
הלקוח הגיע לא עם בקשה "להנפיק טוקן", אלא עם בעיה: החשבונאות של הנכס שהונפק סתרה את מצב הרשת. האינסקריפציות יצרו טוקנים, ואילו המרשם הפנימי חי בנפרד — הנפקות אושרו ביד, חלק מההעברות בין כתובות נרשמו מהזיכרון, והפער צף רק בניסיון למשוך את הנכס לכתובת חיצונית.
את הפער הסרנו כמחלקה. הקמנו אינדקסר שבונה מחדש את מצב הנכס ישירות מהבלוקים של Bitcoin Ordinals, ותלינו עליו התאמת יתרות יומית מול יומן ההנפקה. לכל אצווה הוקצה מזהה, ולכן שליחה חוזרת אינה יוצרת כפילות — הפעולה פשוט נחתכת לפי סימן בלתי משתנה.
את ההנפקה העברנו לקו מתאר אוטומטי: הכנת האצווה, החתימה, האישור ברשת והרישום בחשבונאות מתבצעים בתרחיש אחד עם בדיקות לפני השליחה. המהנדס רואה את הפער לפני שהעסקה יצאה, ולא שבוע לאחר מכן בייצוא.
התוצאה במספרים
- התאמה יומית: 5–6 שעות של השוואה ידנית — 20 דקות לפענוח חריגים.
- שיעור הפעולות שעובדו ביד: 40% — 3% (רק מקרים לא שגרתיים).
- פערי יתרות שהתגלו בדיעבד: 5–7 בחודש — אפס ברבעון תצפית.
- הנפקת אצוות נכס: יום עבודה — 15 דקות מההכנה ועד האישור.
- שחזור החשבונאות מאפס לפי השרשרת: יממה — 40 דקות של חישוב מחדש אוטומטי.
אוטומציה של ההנפקה נתנה את העיקר: המרשם חדל להיות מציאות נפרדת החיה חיים משל עצמה. אפשר להפעיל מחדש את ההתאמה בכל רגע ולקבל את אותו מצב — זו בדיוק ההבטחה שהחשבונאות תואמת את הרשת, ולא את זיכרון המפעיל.
שירות מוכן או אינדקסר עצמי: מה לבחור?
שירות מוכן מכסה את התרחיש הסטנדרטי: Ordinals מתייג את האינסקריפציות, ואינדקסר ציבורי מחשב את יתרות BRC-20 לפי כללי התקן — דיפלוי, טביעה, העברה. ההתחלה אורכת ימים, ולא נדרשת תשתית משל עצמכם. הגבולות מתחילים במקום שבו הלוגיקה שלכם סוטה מהסטנדרטית.
התאמה אישית של הלוגיקה — הסיבה הראשונה לעבור לפתרון עצמי. תמונת מצב של יתרות בגובה בלוק קבוע להפצה, כללי חשבונאות נפרדים למכניקת משחק, סינון רק לפי המבחרים שלכם, עדכון מצב בלי השהיה של שירות ציבורי — אינדקסר מוכן אינו מספק את כל אלה, ופתרונות עוקפים נתקעים באי-שלמות הנתונים.
הטיעון השני — הרחבה של החשבונאות. שירות ציבורי מגביל את תדירות הבקשות ואינו מבטיח את שלמות הדגימה: בעומס שיא אתם רואים לא את כל זרם ההעברות ואת זה אתם מגלים בדיעבד.
צומת עצמאי מסיר את הבעיה — אתם מקבלים כל בלוק בעצמכם, מפענחים את האינסקריפציות במסנן שלכם ושומרים את המצב במסד הנתונים שלכם.
מחיר הפתרון — עותק מלא של הבלוקצ'יין, זמן לסנכרון ופענוח חוזר של ההיסטוריה, וליווי. בתמורה — תוצאה דטרמיניסטית, אפשרות לשחזר את המצב מאפס לאחר שינוי כללי החשבונאות, ועצמאות מזמינותו ומגבלותיו של שירות זר.
לכן בהתחלה בדרך כלל מספיק שירות, ואילו אינדקסר וצומת עצמאיים מוצדקים עם גידול בהיקפים או בלוגיקה לא סטנדרטית. לעתים קרובות אנו מרכיבים היבריד: צומת כמקור עיקרי, ושירות כקו מתאר שני להתאמה ולתפיסת פערים.
שאלות טכניות נפוצות בנוגע להנפקה ולחשבונאות של הנכס
ספקות הנדסיים בנוגע ל-BRC-20 נוגעים בדרך כלל לא להנפקה עצמה, אלא לאופן שבו הנכס יתנהג תחת עומס ומה ניתן לעשות איתו לאחר ההשקה. ארבע שאלות: העומס על הרשת בעת הטביעה, אחסון מפתחות החתימה, התנהגות החשבונאות בעת עיכובי אישור ותיקונים לאחר הדיפלוי.
התשובות להלן עוסקות באופן שבו זה בנוי במימוש, ולא בתאוריה. BRC-20 הוא אינסקריפציות בבלוקים של ביטקוין, ולכן כל מה שנוגע לתור העסקאות ולסופיות פועל בדיוק באותו אופן כמו בהעברות רגילות.
עד כמה ההנפקה מעמיסה על הרשת ומה עם העמלות בזמן הטביעה?
טביעה, העברה ומכירה הן עסקאות רגילות המתחרות על מקום בבלוק. בשעות של התלהבות שיעור העמלה עולה, ופעולות זולות תלויות בתור. לכן את הטביעה מבצעים באצוות עם תקרת שיעור וכלל החלפה: בקשה שלא שולמה די הצורך מוחלפת או מבוטלת, ואילו האינסקריפציות שכבר הונפקו אינן נפגעות.
כיצד מוגנים המפתחות שחותמים על האינסקריפציות?
מפתחות החתימה אינם מאוחסנים בשרת ואינם מגיעים למאגר הקוד. התפקידים מופרדים: מפתח נפרד להנפקה, מפתח נפרד לתשלום העמלה, מפתח נפרד לשינוי כללי החשבונאות. פעולות קריטיות מתבצעות תחת כמה חתימות, כדי שדליפה בודדת לא תיתן שליטה על ההנפקה, ויומן החתימה מאפשר לנתח כל פעולה בדיעבד.
מה קורה לחשבונאות אם האישור מתעכב או שהבלוק בוטל?
יתרות מחושבות לפי בלוקים מאושרים. כל עוד העסקה בתור, היא מוצגת כ"בטיפול" ואינה נכנסת לחשבונאות — לא נוצרים פערים בין יתרת המשתמש למצב הרשת. לאחר ביטול השרשרת, הפעולות מהבלוק שבוטל מחושבות מחדש, ואין זיכוי כפול.
האם אפשר לשפר את הטוקן לאחר ההשקה?
הטיקר, ההיצע הכולל והמגבלה לפעולה אחת רשומים באינסקריפציה הראשונה ואינם משתנים — רק הנפקת טיקר חדש. את השאר ניתן לתקן: כללי החשבונאות באינדקסר, לוגיקת ההפצה, הממשק, הדיווח. הליווי כולל ניטור של תור העסקאות שאינן מאושרות ושל פערים בין אינדקסרים בעת שינויים בתקן.
נדון במשימה: הכנה להערכה ולתכנית ההנפקה
כדי לחזור עם הערכה ותכנית עבודה, ולא עם מילים כלליות, נדרשים נתוני פתיחה על הפרויקט. להלן — המערך המזערי שמסיר את רוב השאלות בשלב החישוב. אם חלק מהנתונים עדיין אין, סמנו זאת במפורש: עבורם נכניס הנחות לתכנית ההנפקה.
- פרמטרי ההנפקה: טיקר, היקף כולל, מספר הספרות, מגבלה לכתובת וכללי הטביעה.
- לוגיקת ההפצה: נתחי הצוות והקהילה, האם נדרשים וסטינגים וחשיפת כתובות.
- עומס צפוי: סדר הגודל של מספר המשתתפים בטביעה ותדירות שיא של עסקאות — מכך תלויות אסטרטגיית העמלות וחלוקת ההנפקה לשלבים.
- תשתית: אינדקסר עצמי או חיצוני, האם נדרשת אינטגרציה עם ארנקים ופלטפורמות מסחר.
- אבטחה: מי מחזיק במפתחות המנפיק, האם נדרש קו מתאר של ריבוי חתימות ומי מאשר את ההנפקה.
- תאימות וגילוי: דרישות התחום השיפוטי שלכם והאם נדרשת תיעוד ציבורי על הטוקן.
- קריטריוני קבלה: מה נחשב להנפקה מוצלחת — טביעה מאושרת, אינדקסר עובד, דוח עסקאות.
- לוחות זמנים ותפקידים: תאריך השקה, איש הקשר הטכני שלכם וסדר אישור ההחלטות.
עם המערך הזה נחזור עם הערכת מאמץ, תכנית הנפקה לפי שלבים ותכנית עבודה עם נקודות ביקורת. כדי לדון במשימה מספיק לתאר אותה בצורה חופשית — ננתח את צווארי הבקבוק ונסכים על ההתחלה.