פיתוח אפליקציות על Stacks (Bitcoin L2) — חוזי Clarity ו-sBTC

פיתוח Stacks: איפה נשברת החיבור עם ביטקוין

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

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

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

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

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

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

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

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

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

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

פיתוח על Stacks: השוואת אפשרויות אינטגרציה

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

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

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

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

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

מה נכלל בחבילת המסירה: קוד, סכימות, נהלים

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

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

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

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

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

מה שינו

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

מה נהיה

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

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

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

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

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

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

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

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

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

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

מה עושים אם חלק מהנתונים אסור לחשוף?

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

כיצד תוכיחו שהחוזה תקין?

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

מה יקרה לאחר מסירת הפרויקט?

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

יש לנו צוות משלנו. כיצד מחלקים את העבודה?

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

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

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

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

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