ייעוץ בבחירת בלוקצ'יין לפרויקט

מדוע הפרויקט נתקע בשלב בחירת הבלוקצ'יין

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

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

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

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

שורש הבעיה הוא שההחלטות מתקבלות בחלקים, בלי קריטריונים לבחירת הרשת.

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

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

מה נותנת בחירת בלוקצ'יין מבוססת לפרויקט

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

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

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

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

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

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

השוואת אפשרויות: רשת ציבורית, מתאר סגור, היברידי

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

חלופות טכניות

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

שלבי העבודה: מאיסוף הדרישות ועד מסירת הסכמות

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

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

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

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

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

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

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

אם במהלך הביקורת מתברר שהמשימה נפתרת בלי בלוקצ'יין — נאמר זאת ישירות כבר בשלב השני.

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

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

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

מקרה בוחן: הסרנו אי-סנכרון נתונים בין המשתתפים

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

היכן נוצר אי-הסנכרון

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

מה שינו

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

מה קרה בסוף

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

במה שונה רשת קונסורציום ממתאר סגור?

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

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

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

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

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

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

התלבטויות בנוגע לאינטגרציה, גישה והרחבה

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

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

מה קורה כשנפח הפעולות גדל?

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

מה יקרה בכשל של צומת בודד?

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

האם אפשר להעביר נתונים לרשת אחרת?

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

נדון במשימה ונחזור עם אומדן ותוכנית עבודה

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

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

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

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