פיתוח הרחבת ארנק קריפטו לדפדפן

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

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

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

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

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

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

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

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

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

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

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

מהירות חתימת העסקאות

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

זמן הוצאת עדכוני הארנק

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

זמן שחזור הגישה ושיעור הפעולות הידניות

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

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

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

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

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

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

סדר השלבים

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

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

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

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

כל חפץ נמסר למאגרים ולאחסונים שלכם — בלי תלות בחשבונות שלנו ובלי חלקים סגורים שאי אפשר למסור לצוות אחר.

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

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

מה היה

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

מה שינינו ומה נהיה

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

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

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

במה שונה אחסון מקומי של מפתחות מאחסון בצד השרת?

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

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

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

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

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

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

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

איך מוסיפים רשת חדשה אחרי השחרור?

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

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

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

איך עוברים ביקורת קוד והמסירה לצוות?

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

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

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

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

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