פיתוח תוסף דפדפן לארנק קריפטו עבור EVM ו-Solana

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

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

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

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

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

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

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

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

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

שיעור הפעולות המוצלחות

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

סוג הדחיות שנעלם

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

שחזור גישה לארנק

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

עומס על תמיכת המשתמשים

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

יציבות בעת עדכונים

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

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

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

איך לבחור

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

שלבי ההטמעה: מביקורת ועד מסירה לצוות

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

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

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

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

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

מקרה בוחן: איך הסרנו סוג דחיות חוזר בחתימה

היכן הפעולות נשברו

ארנק הקריפטו שלנו כהרחבת דפדפן עבד עם שתי משפחות רשתות: תואמות EVM ו-Solana.

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

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

מה שינו

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

כעבור חודש שיעור הפעולות שלא הושלמו ירד ל-0.9% — אחת ממאה ועוד. זמן שחזור הגישה הצטמצם מ-25 דקות ל-1-2 דקות של פעולות עצמאיות. הפניות בנושא חתימה ירדו מ-40% ל-6% מכלל הפניות, וניתוחים ידניים — מכמה מאות בחודש למקרים בודדים. סוג הדחיות שגרר אחריו התכתבות ופעולות אבודות הפסיק לחזור על עצמו.

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

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

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

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

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

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

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

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

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

במה מאושרת נכונות החתימה?

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

היכן עובר גבול האחריות?

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

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

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

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

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