פיתוח בורסות ופלטפורמות מסחר: CEX, DEX ומאגדי נזילות

מדוע פיתוח בורסה דורש מומחיות עמוקה בתחום

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

ספר הזמנות (Order Book) לעומת AMM: היכן רוב הפרויקטים נשברים

בורסות מרכזיות (CEX) בנויות סביב ספר הזמנות + מנוע התאמה. בורסות מבוזרות (DEX) משתמשות גם בספר הזמנות (dYdX על StarkEx, Serum/OpenBook על Solana) או ב-AMM עם נזילות מרוכזת (Uniswap v3/v4, Curve, Balancer). טעות קלאסית בפיתוח CEX היא יישום מנוע ההתאמה על גבי מסד נתונים רלציוני עם טרנזקציות לכל התאמה. PostgreSQL מתמודד עם ~500 RPS ללא מאמץ מיוחד, אבל בעומסי שיא של 5,000–10,000 הזמנות בשנייה, הוא הופך לסיוט של deadlocks. הארכיטקטורה הנכונה: ספר הזמנות בזיכרון (Redis Sorted Sets או מבנה C++/Rust מותאם), כתיבה אסינכרונית של התאמות ל-PostgreSQL דרך תור (Kafka/RabbitMQ), ושירות סליקה נפרד שמעדכן סופית את היתרות.

עבור DEX, הבעיה הכואבת ביותר היא התקפות סנדוויץ' ו-MEV. מאגר עם AMM פשוט מסוג xy=k ללא הגנה מפני החלקה הופך למטרה עבור בוטים של MEV תוך שעות מההשקה. Uniswap v2 איבדה מאות מיליוני דולרים מנזילות משתמשים. פתרונות: אינטגרציה עם Flashbots Protect, מנגנון commit-reveal להזמנות, או מעבר ל-TWAMM (Time-Weighted AMM) לעסקאות גדולות.

נזילות מרוכזת והפסד בלתי-קבוע (Impermanent Loss)

Uniswap v3 הציגה נזילות מרוכזת – ספקי נזילות (LPs) בוחרים טווח מחירים שבו הם מספקים נזילות. יעילות ההון גדלה פי 4,000 בהשוואה ל-v2 עבור זוגות יציבים. אבל יישום נכון של מנגנון זה אינו טריוויאלי. חוזה הנזילות של Uniswap v3 משתמש בחשבונאות מבוססת-ticks: מרחב המחירים מחולק ל-ticks בדידים (tick = log₁.0001(price)), כל tick מאחסן צמיחת עמלות מצטברת ודלתא נזילות. בעת יצירת פוזיציה, מחושבים ה-ticks התחתון והעליון, והחוזה מחשב מחדש את כל הפוזיציות הפעילות בכל החלפה (swap). פריסת האחסון (storage layout) היא קריטית כאן – אריזה שגויה של משתנים ב-slots מוסיפה בקלות 40–60% לעלות הגז של החלפה.

יישמנו fork של Uniswap v3 עבור לקוח על Polygon עם מערכת דרגות עמלות מותאמת אישית. הגרסה הראשונית צרכה 180k גז להחלפה על פני 2 ticks. לאחר אריזת משתנים ב-slots ב-Tick.Info ו-inlining של מספר קריאות פנימיות, זה ירד ל-112k גז. זה הפחית את עלויות הגז ב-38% וחסך ללקוח עלויות משמעותיות בעמלות מדי חודש. הטכניקות שיושמו מתוארות ב-Uniswap v3 Whitepaper ומאושרות על ידי ניסיון הביקורת שלנו.

כיצד מנוע התאמה מספק ביצועים

מנוע התאמה ברמת production בנוי לפי הסכמה הבאה:

• שכבת קליטת הזמנות – שער WebSocket (Go או Rust), מקבל הזמנות, מאמת חתימה, בודק יתרה דרך Redis, ומכניס אותן לתור. זמן השהיה ברמה זו חייב להיות <1ms.
• ליבת ההתאמה – לולאת אירועים חד-חוטית (מבטלת תנאי מרוץ ללא mutexes). בזיכרון אנו מחזיקים שני Sorted Sets עבור כל מכשיר מסחר: הצעות קנייה (bids) ומכירה (asks). התאמת FIFO להזמנות limit, ו-immediate-or-cancel להזמנות market. תפוקה עם יישום Rust נכון – 500k–1M התאמות בשנייה על ליבה אחת.
• שירות סליקה – קורא התאמות מ-Kafka, מעדכן אטומית יתרות ב-PostgreSQL (UPDATE accounts SET balance = balance - $1 WHERE id = $2 AND balance >= $1). נעילת אופטימית (optimistic locking) באמצעות versioning של שורות.
• צינור משיכות – שירות נפרד עם ארכיטקטורת ארנק קר/חם. הארנק החם מחזיק 5–10% מסך הפיקדונות, השאר באחסון קר עם multi-sig (Gnosis Safe או HSM מותאם). משיכות אוטומטיות רק מהארנק החם, סכומים גדולים דורשים אישור ידני.

כיצד תהליך פיתוח הבורסה שלנו מבטיח אמינות

חוזים חכמים ואופטימיזציית גז

עבור DEX מבוסס EVM (Ethereum, Arbitrum, Optimism, Polygon), כל הנתיב הקריטי חי ב-Solidity. חוזים עיקריים: Pool, Factory, Router, PositionManager (לדמוי v3), ו-Quoter לחישובים off-chain. טעויות אופייניות שאנו רואים בביקורות:

Reentrancy דרך callback. Uniswap v3 משתמשת ב-flash swap עם callback (uniswapV3SwapCallback). אם ל-router שלך חסר guard מסוג nonReentrant ואתה לא בודק msg.sender == pool, החוזה מתרוקן דרך קריאה מקוננת. זה לא היפותטי – כמה forks של v3 איבדו כספים בדרך זו.

מניפולציית אורקל ב-AMM. אם החוזה שלך משתמש במחיר הספוט מהמאגר לחישוב בטחונות, הוא חשוף ל-front-running. נכון: TWAP מעל 30+ דקות (Uniswap v3 OracleLib) או אורקל חיצוני (Chainlink).

לולאות בלתי מוגבלות בטווח נזילות. אם החלפה חוצה ticks רבים ברצף (השפעת מחיר 80%+), הגז עשוי לחרוג ממגבלת הבלוק. יש צורך ב-MAX_TICKS_CROSSED עם מילוי חלקי והחזרת היתרה.

עבור Solana DEX (מסגרת Anchor, Rust), הארכיטקטורה שונה מהותית: מודל מבוסס-חשבונות, Program Derived Addresses (PDA) במקום אחסון, ו-Cross-Program Invocations במקום קריאות פנימיות. התפוקה של Solana (~3,000–4,000 TPS לעומת 15–30 ב-Ethereum mainnet) מאפשרת בניית ספרי הזמנות on-chain – בדיוק מה ש-Phoenix DEX עושה.

הנעת נזילות ואינטגרציה עם אגרגטורים

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

• Liquidity Bootstrapping Pool (LBP) – המחיר ההתחלתי גבוה, משקלי הנכסים משתנים דינמית, מה שיוצר לחץ מכירה והפצת אסימונים שוויונית. מיושם ב-Balancer v2.
• Initial Liquidity Offering דרך Uniswap v3 – הוספת נזילות בטווח צר סביב המחיר ההתחלתי, ואז הרחבה הדרגתית ככל שהנפח גדל. דורש ניהול נזילות אקטיבי או אינטגרציה עם Arrakis/Gamma.
• אינטגרציה עם 1inch, Paraswap, Li.Fi – אגרגטורים מביאים תנועה אך דורשים עמידה בתקנים: למאגר חייב להיות getAmountsOut תקין, תמיכה ב-ERC-20 approval/permit, וללא hooks מותאמים להעברה ששוברים את הניתוב של האגרגטור.

תהליך הפיתוח ותוצרים

האנליטיקה והעיצוב מתחילים בבחירת המודל הארכיטקטוני: CEX עם אחסון נאמנות (custodial), DEX לא-נאמנותי (non-custodial), או היברידי (ספר הזמנות off-chain + סליקה on-chain, כמו dYdX v3). החלטה זו קובעת הכל – עומס רגולטורי, מחסן טכנולוגי, צוות.

הפיתוח מתקדם בשכבות: תחילה חוזים חכמים עם כיסוי מלא ב-Foundry (fuzzing, בדיקות invariant), לאחר מכן שירותי backend, אחר כך שכבת אינטגרציה, ולבסוף frontend. הבדיקות כוללות fork testing על mainnet דרך Foundry – אנו משחזרים תנאי נזילות אמיתיים, לא סינתטיים.

ביקורת (Audit) היא חובה לפני פריסה ל-mainnet. עבור חוזי DEX, לפחות חברה אחת עם סקירה ידנית (Trail of Bits, Spearbit, תחרות Code4rena). עבור אחסון נאמנות של CEX, ביקורת של תהליכי אחסון מפתחות. אנו מבטיחים שכל החוזים עוברים אימות פורמלי ובדיקות fuzzing (Echidna, Foundry invariant).

לוחות זמנים משוערים

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

מלכודות שיש להימנע מהן בהשקה

• שכחת אורקל מחירים ב-AMM. ניתן לתמרן את מחיר הספוט עם flash loan בטרנזקציה אחת. אם פרוטוקול ההלוואות שלך משתמש במחיר הספוט מהמאגר שלו, זו באג.
• ארנק חם ללא מגבלות. CEX ללא מגבלות יומיות על משיכות אוטומטיות הוא הזמנה לתוקפים. פשרה של מפתח אחד צריכה לאבד לכל היותר 10% מסך הכספים.
• היעדר circuit breaker. ירידת מחיר של 40% ב-5 דקות צריכה לעצור פירוקים אוטומטיים או משיכות עד לבדיקה ידנית. ללא זה, ספירלת פירוק מפולת (cascading liquidation) הורסת את כל ה-TVL.
• טיפול שגוי בעשרוניות. USDC משתמש ב-6 עשרוניות, WBTC – ב-8, רוב האסימונים – ב-18. ערבוב ללא נורמליזציה מוביל לאובדן דיוק או לגלישה. ל-Solidity אין float; אנו עובדים עם נקודה קבועה באמצעות FullMath (mulDiv עם הגנה מפני גלישה).

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