הגירת DEX ל-StarkNet: מפיתוח חוזי Cairo ועד אימות

פריסת חוזים חכמים ב-StarkNet: היכן נשברות בורסות מבוזרות (DEX)

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

הבעיות מתחילות מאוחר יותר: מחלקת החוזה (contract class) אינה מאומתת בסייר (explorer), מכיוון שה-hash של הארטיפקט הבנוי אינו תואם לזה שנפרס, ובלי אימות חוזים המשתמשים והאגרגטורים אינם רואים את קוד המקור ואינם נותנים אמון בבריכה (pool).

נקודת כשל שנייה — לוגיקת ה-AMM בעת הגירת DEX. העברת המתמטיקה ממודל EVM ל-Cairo שוברת את החישובים במקומות שבהם קודם הכל הסתדר: עיגול בעת חילוק, סדר הפעולות עם נקודה קבועה (fixed point), עבודה עם טיפוסי felt במקום מספרים שלמים רגילים.

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

השלישית — טרנזקציות ש"תלויות". הפריסה יוצאת לרשת, אך אינה מסתיימת (finalized): מגבלת ה-gas לחישובי Cairo הוגדרה באופן שגוי, התור של הסיקוונסר (sequencer) לא נלקח בחשבון, לא הוגדרו ניסיונות חוזרים (retries) עבור סטטוס PENDING. בסופו של דבר הצוות מבזבז זמן על הפעלה מחדש ידנית, וחלק מהמחלקות נשארות במצב לא מוגדר.

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

מה מביאה העברת DEX ל-StarkNet: מהירות ועלות

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

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

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

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

מה משתנה במספרים

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

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

אפשרויות מיגרציה: העברה מלאה, היברידי, פרוקסי

העברת DEX ל-StarkNet אינה "לשכתב את החוזים ולפרוס אותם". Cairo שונה מ-Solidity במודל החישוב וניהול המצב, ולכן לא ניתן simplement להעתיק את אותה בריכת נזילות: לוגיקת AMM, אורקלים וחישוב עמלות נכתבים מחדש עבור סביבת ההרצה החדשה. מבחירת הסכמה תלוי כמה זמן הבורסה תפעל בשתי רשתות בו-זמנית וכיצד יתנהג הנזילות בתקופת המעבר.

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

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

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

שלבי העבודה: מביקורת ה-DEX הנוכחי ועד לאימות

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

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

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

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

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

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

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

מקרה בוחן: העברת DEX עם אובדן של 0.3% נזילות

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

מה עשינו

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

התוצאה

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

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

במה שונה פריסת חוזים חכמים ב-StarkNet מ-EVM?

ההבדל המרכזי הוא מודל ההרצה. EVM מחשבת כל פעולה בכל הצמתים, ולכן מחיר הגז עולה באופן ליניארי ממורכבות הלוגיקה. StarkNet מריצה את התוכנית off-chain, ובשכבת L1 שולחת הוכחת נכונות: האימות עולה בערך אותו דבר ללא תלות בכמות החישובים שבתוכה.

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

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

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

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

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

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

ספקות טכניים נפוצים בעת העברת DEX

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

אילו סיכונים נושאים חוזי פרוקסי בעת שדרוגים?

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

כיצד מובטחת אבטחת המפתחות וביקורת החוזים?

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

נדון במשימת ההגירה שלכם של DEX ל-StarkNet

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

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

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

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

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