פיתוח מערכת P2P מאובטחת למסחר בקריפטו

למה מסחר P2P בקריפטו נשבר בזרימת עסקאות

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

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

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

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

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

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

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

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

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

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

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

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

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

דרכי סליקה בעסקאות בקריפטו: השוואת אפשרויות

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

היכן כל מצב מתאים

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

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

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

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

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

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

מה אנחנו מוסרים לידיים: סכמות, כללי גישה, נהלים

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

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

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

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

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

מדדים לפני

בירור ידני עברו 38% מהעסקאות עם אי-התאמה, זמן החזקת כספים ממוצע באסקרו — 47 דקות, במקרי מחלוקת שעות. על כל 100 עסקאות הגיעו 14 פניות לתמיכה. צ'קים מזויפים ואישורי תשלום בשימוש חוזר נתפסו בעיני הבורר, ולא בבדיקות.

מה שינו

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

מה נהיה

שיעור הבירורים הידניים ירד מ-38% ל-11%, החזקת הכספים — מ-47 ל-12 דקות, הפניות לתמיכה — מ-14 ל-4 לכל 100 עסקאות. האוטומציה סוגרת תשע אי-התאמות מתוך עשר, תור הבוררות נבנה לפי רמת סיכון, ותרחיש אישור תשלום חוזר עבר לכללים וכבר לא תלוי בתשומת הלב של האדם.

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

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

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

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

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

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

ספקות נפוצים לגבי סליקה והגנת עסקאות

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

היכן נמצאים הכספים בזמן שעסקה שנויה במחלוקת מתנהלת?

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

האם אפשר לחבר בדיקת משתמשים משלכם?

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

איך הפלטפורמה מחזיקה מעמד מול בקשות כוזבות?

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

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

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

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

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