ארנק קריפטו בתווית לבנה: פיתוח מקצה לקצה

ארנק קריפטו White-label: היכן נשברות הרכבות מוכנות

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

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

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

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

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

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

מה נותנת ליבה מוכנה: מהירות השקה ואמינות מפתחות

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

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

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

ארנק קריפטו White-label, fork של קוד או פיתוח עצמאי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: ארנק לרשת שותפים — מדדים לפני ואחרי

איך זה נראה לפני העבודה מחדש

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

חיבור שותף נעשה בעריכת קוד ובהרכבה נפרדת — עד שלושה שבועות לכל אחד. שיעור הפעולות שהיה צריך להשלים ידנית הגיע ל-4% בשיא היומי, וההתאוששות לאחר כשל בצומת ארכה שעות.

מה שינו בארכיטקטורה

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

מה הראו המדדים

• שיעור הפעולות המוצלחות: היה כ-96%, הפך ל-99.9% על אותו היקף.
• זמן חיבור רשת חדשה: שלושה שבועות → יומיים, בלי שחרור ארנק.
• רשתות נתמכות: אחת → שש בממשק אחד.
• פעולות שנסגרו ידנית: 4% → 0.3% מהזרימה היומית.
• התאוששות לאחר כשל בצומת: שעות → דקות, קבלת הבקשות לא נעצרת.

במה מודל קסטודיאלי שונה ממודל לא-קסטודיאלי?

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

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

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

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

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

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

אחסון מפתחות, ביקורת ועדכונים: ספקות טכניים

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

כיצד מתבצעת ביקורת אבטחה חיצונית?

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

מה עם עדכונים והגירה לרשת אחרת?

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

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

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

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

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

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