יום ראשון, 24 במרץ 2024

468 Crypto With Arik from Fireblocks


פודקאסט מספר 468 של רברס עם פלטפורמה - הוקלט ב-19 במרץ 2024, רגע לפני פורים. הפעם הקודמת הייתה לפני סוכות, והרבה דברים קרו מאז. רובם רעים מאוד, אבל היה גם כנס מאוד מוצלח. מנסים לחזור לשגרה - ומקווים לחזרתם של כולם לשגרה מבורכת במהרה.
אורי ורן מארחים את אריק מחברת Fireblocks - אחרי המון פגישות לאורך המון שנים בכנסים ועוד, שחקן מאוד משמעותי בקהילה שלנו - כדי לדבר קצת על קריפטו, נושא שאיכשהו לא זכור שממש נגענו בו לעומק לאורך כמעט 470 פרקים [היה קצת בפרק עם בנצי מ-eToro - פרק 436 How to reach retirement as a software developer with Bentzy Lupu], ולהיכנס לחלק מהאיזורים המאוד מעניינים של Crypto Currencies: אלגוריתמים ועוד נושאים טכנולוגיים שאריק מביא - מילים כמו MPC ו-CMP ועוד.

02:04 על אריק ו-Fireblocks

(רן) ולפני הכל - אריק: כמה מילים עליך ועל מה אתה עושה היום?
  • (אריק) כן, אז היום, כמו שאמרת, אני בעצם סמנכ”ל טכנולוגיה ב-Fireblocks, מוביל את המחקר הטכנולוגי.
    • אני ממר”מניק - בוגר אופק של חיל האוויר בעברי.
    •  ומאז מספר מקומות - מספר שנים בעולמות ה-AI ב-HiredScore,   באזורים של AI for Recruiting.
    • ובשנתיים וחצי האחרונות בערך צללתי לעולם הזה של Blockchain ו-Crypto Currencies - היום אפשר לדבר על ההבדלה.
      • אם פעם הם כזה “הגיעו לעולם שלנו ביחד”, אז היום אפשר גם להבדיל בין ה-Asset Class - בעצם הסוג החדש של נכסים דיגיטליים, לבין ממש הטכנולוגיות-Blockchain שיושבות מתחתיהם.
(רן) ספוילר - אנחנו לא נלמד היום איך להרוויח כסף בביטקוין . . . 
(אורי) אה, לא?
(רן) אולי קצת . . . . אבל אנחנו כן נלמד דברים ועל נושאים טכנולוגיים מרתקים שנמצאים בתחום.
אז אתה עובד היום ב-Fireblocks - כמה מילים על Fireblocks?
  • (אריק) כן, אז Fireblocks זו חברת טכנולוגיה, קודם כל.
  • אנחנו בונים תשתית טכנולוגית, שמעליה חברות וארגונים - הרבה מהם ארגונים פיננסיים, אבל לא רק - הם בונים ברגע שהם רוצים להשתמש בעולמות ה-Blockchain.
    • אפשר להסתכל על זה קצת בצורה דומה ל-AWS - כשאתה בונה אפליקציית Web, אז הם נותנים לך את כל הכלים שאתה צריך כדי לבנות אפליקציה.
      • לא רק Web, מן הסתם, המון המון use-cases שונים - אבל יש כזה את המרכז: ה-Compute שהם נותנים לך, שרתים . . .  
      • מזה הכל התחיל, אבל זה התרחב לכל השירותים.
    • ו-Fireblocks זה סיפור די דומה בעולם שלנו.
  • התחלנו מלפתור איזושהי בעיה מרכזית שיש ללקוחות ברגע שהם משתמשים בכל עולמות ה-Blockchain, מה שקשור לאיך הם מתנהלים עם הארנק שלהם.
    • והמשכנו ללתת להם מענה לכל הצרכים השונים שעולים ברגע שאתה בונה “מערכת אמיתית”.
  • אנחנו משרתים ארגונים, כלומר - זה לא מוצר-ארנק לאנשים, זה לא משהו שאתה מחזיק את הביטקוין שלך בתוכו, אלא ארגונים מכל הסוגים.
    • זה החל מסטארטאפים וממשיך לכל מיני חברות טכנולוגיות שבונות בעולמות האלה, Brand-ים שעושים כל מיני דברים עם NFTs וכל מיני דברים אחרים ששמעתם עליהם.
    • וממשיך כל הדרך גם לבנקים - או בנקים מרכזיים אפילו - שעושים כל מיני דברים בעולמות ה-Blockchain.
      • כלומר ממש שחקנים פיננסיים כבדים גם בחלק מהזמן.
(רן) כן, אז אתם רוצים להיות - או אולי כבר - “ה-AWS של עולם ה-Crypto Currency”…
  • (אריק) כמו בכל תחום, יש איזה מישהו שמתכנן להיות “ה-AWS של התחום” הזה, אז אנחנו לגמרי שחקן באזור הזה.
(רן) יפה, יפה, מקום טוב.

04:45 המפתחות של הצוללות

(רן) סבבה, אז בואו עכשיו ניכנס לנושא אחד מאוד ספציפי ומעניין של איך מטפלים או איך מייצרים ואיך מטפלים במפתחות קריפטוגרפיים שהם חלק מלב העניין - וזה, ככה, הביא אותך גם להרפתקה שהגיעה עד ל-Blackhat בזמנו, ונגיע גם לסיפור הזה.
אז בואו נדבר על מה היא בעצם הבעיה שאיתה התמודדת.
(רן) כן, סוג-של “לייצר כספת”, אבל גם כזו שלא נאבדת ו...
(אורי) ... ושלא מאבדים את המפתח לכספת . . . 
(רן) כן, אבל מיילא זה המפתח שלך באופן אישי, ואולי הפסדת כמה עשרות מיליוני דולרים [מה זה בינינו…] - אבל אם אתה עובד בארגון, ואתה הולך להפסיד את הכסף של הלקוחות שלך, אז אתה באמת בצרות.
  • (אריק) בדיוק - זו הופכת להיות בעיה הרבה יותר גדולה.
  • ובאמת, אחד הדברים המעניינים ש-Fireblocks זיהתה בתחום הזה, זה שהרבה מהפתרונות באותו זמן, הפתרונות לנושא הזה של “רגע, איך אני מאבטח את המפתח שלי”?
    • רק כדי שכולם יבינו - ברגע שיש לך את המפתח בעולם ה-Blockchain - שווה שנאמר - אתה יכול לעשות הכל בשם ה-Account.
      • בעצם, כל החשבון הוא שלך. אין שום דבר באמצע.
      • כלומר, יש צעד מאוד קצר בין “יש לי את המפתח” לבין “אני עושה עם הכסף מה שאני רוצה”.
(רן) כן, במילים אחרות - המפתח הוא Single Point of Failure באיזושהי צורה.
  • (אריק) לגמרי, Single Point of Failure, כן - שאנחנו לא אוהבים, 
    • בטח כשה-Single Point of Failure הזה יכול, תוך שניות, להיות מנוצל כדי לקחת הכל - שזה יכול להיות גם מיליארדים.
  • עכשיו, הפתרונות באותו זמן היו באמת ברעיון הזה - הרעיון האוטומטי של אנשים, זה “בוא נשים אותו בכספת”, נכון?
    • הייתה אפילו חברה שהשכירה בונקרים בשוויץ - שמו בתוכם כספות, סגרו את הבונקרים, ופעם בחודש הבן אדם היה מגיע לכספת ועושה את הפעולה שאתה רוצה מול הארנק שנמצא בתוך הכספת, שנמצא בתוך הבונקר . . .
    • שזה נחמד - אם לקחת ביטקוין ואתה רוצה להחזיק אותו עכשיו ל-20 שנה, אולי זה שימושי.
    • אבל ברגע שאתה חברה פיננסית, אתה עושה פעולות פיננסיות כל הזמן - לפעמים עשר פעמים ביום, לפעמים מאה פעמים ביום, ולפעמים עשרת אלפים פעמים בשנייה, נכון?
      • כאילו Visa - שישים אלף טרנזקציות, TPS, טרנזקציות בשנייה.
    • אז בעצם זה לא עובד ל-Use Case הזה.
  • ו-Fireblocks הייתה חברה שבאה ואמרה “אנחנו רוצים פתרון שהוא מאובטח ברמה של ‘הכספת הזאת, שנמצאת באמצע בונקר’ - אבל אנחנו רוצים שהוא יהיה שמיש כל הזמן, בתוך ארגון”.
    • כלומר, באמת ה-Single Point of Failure זו בעיה, במיוחד כש-Single Point of Failure מקושר גם הרבה פעמים לאיזה בן אדם, שיכול לקחת את הכסף.
    • וכמובן שה-Temptation עולה ברגע שהסכומים עולים.
    • וזה בעצם הבעיה שבאנו לפתור.

08:20 חישוב בשיתוף פעולה

(רן) בסדר גמור. עכשיו, אני מניח שלא כולם מכירים את ביטקוין לעומק, אבל אחד הדברים שכולם יודעים על ביטקוין - או על כל המטבעות הקריפטוגרפיים, סליחה, בואו נכליל, נעשה אבסטרקציה לבעיה - זה שהם מורכבים מחישוב מבוזר, חישוב שנוצר על ידי שיתוף פעולה. זאת אומרת, צד אחד עושה חישוב, צד נוסף עושה חישוב נוסף - ובסופו של דבר, התוצאה של החישובים האלה - אפשר באמצעותה לייצר טרנזקציות של Crypto Currency.
אבל בסיפור הזה יש גם כמה בעיות. אוקיי? אז לזה אנחנו קראנו, או הולכים לקרוא לו, Multi-Party Computation או MPC, נכון? ואתם הייתם צריכים להתמודד עם זה . . .
  • (אריק) כן, אז בדיוק - Multi-Party Computation זה דווקא כאילו הסוג-של-הפתרון שלנו לבעיה.
  • אז הבעיה בעצם היא שיש לי את המפתח, יש את ה... כמו שאמרתי, יש רשת - רשת כלשהי, Blockchain כלשהו.
    • בסוף, הרשת הזאת, היא לא עושה פעולות בעצמה, כן?
    • מה שקורה על הרשת, זה בעצם שטרנזקציות מגיעות אליה - והטרנזקציות צריכות להיות חתומות, חתומות קריפטוגרפית.
    • ואת החתימה הזאת - יש באמת Private Public Key Signature שם, כן? כאילו יש איזשהו מפתח פרטי, אני חותם איתו, זה תקף לרוב על ה-Public Address  שלי, שזה המפתח הפומבי שמקושר אליו
      • ואז כל בן אדם ברשת ה-Blockchain יכול לוודא שהטרנזקציה הזאת, שיוצאת מה-Public Key הזה, נחתמה על ידי ה-Private Key התואם - ונחתמה בפרוטוקול הרלוונטי לאותו Blockchain, כן?
      • לBlockchain-ים שונים יש פרוטוקולים שונים, אבל יש כמה שהם העיקריים.
  • עכשיו, אני רוצה לייצר את החתימה הזאת - ושכל אחד יוודא חתימה וידע שהיא תקינה - אבל אני לא רוצה להחזיק מפתח אחד, אני רוצה לפתור את ה-Single Point Of Failure, וכאן נכנס MPC.
    • כשהרעיון ב-MPC בעצם, הוא במקום שיהיה מפתח פרטי אחד - יהיו מספר חלקים למפתח.
    • אנחנו סוג-של-נפצל רגע את המפתח לכמה חלקים . . .
    • (רן) Sharding!
    • (אריק) בדיוק. . . . אנחנו נעשה איזה Sharding כזה
      • או אם היינו ממש מפצלים מפתח בודד אז זה Secret Sharing - כשאנחנו בעצם מפצלים סוד כלשהו לכמה חלקים.
      • ואז אנחנו נרצה לעשות את הפעולה בצורה מבוזרת - שיהיו כמה שחקנים שצריכים לעשות פעולה כלשהי.
    • אבל אנחנו רוצים לעשות את זה בצורה מאוד מאוד מדויקת - כי אם הייתי עושה את זה כמו שאמרתי עכשיו,
      • אז היה לי מפתח במקום אחד, שכמובן מישהו היה יכול לגנוב כבר אז, ואז פיצלתי אותו - אז זה לא מנגנון טוב עבורנו.
    • אנחנו רוצים משהו יותר Secure, אז אנחנו אומרים “בוא מראש נייצר את המפתח בצורה מבוזרת, כשהוא מעולם לא היה מפתח בודד”.
    • יש פה איזה קצת “קסם קריפטוגרפי” כזה . . .
    • (אורי) הוא כן מפתח בודד - אבל הוא מורכב מכמה חלקים.
    • (אריק) יש מפתח תיאורטי בודד, שמעולם לא היה שלם - אבל יש X שחקנים שמכילים חלקי-מפתח, שאם הם היו מחברים אותו, אז הוא היה מייצר את המפתח הזה.
      • אבל אף אחד מעולם לא ראה את החיבור הזה.
    • (רן) זה מזכיר לי, אתה יודע . . . אני מדמיין את נאום ה- I have a Dream - אין מישהו אחד שהחזיק בכל החלום ביחד, אבל כולם ביחד מגשימים את החלום.
    • (אריק) יפה מאוד . . . הרעיון שנכנס לי זה There is no Spoon” - אתה רואה כף, אבל אין כף. אין מפתח באמת.

11:38 היה מפתח?

(רן) אבל רגע, בוא נעצור אותך שנייה לפני שאתה דוהר קדימה. אוקיי, אז הייתה לך בעיה של Single Point Of Failure, ועכשיו יש לך בעיה של Distributed Single Point Of Failure  . . . זאת אומרת, מספיק שכל אחד מהשחקנים האלה פתאום נכשל, מאיזושהי סיבה - איבד את המפתח או whatever - אז איבדת שבריר מהמפתח, דהיינו - אין לך יותר מפתח . . .
  • (אריק) נכון. אז דיברנו קודם על יצירת החלקים של המפתח בצורה מבוזרת בעצם - צריך לומר שגם החתימה קורית בצורה מבוזרת.
    • ואני רק אסביר את זה לשנייה, לפני שאני ניגש לבעיה שאתה מתאר.
    • בעצם, כשאנחנו רוצים לחתום על טרנזקציה עכשיו, הדרך הנאיבית שהיינו עושים את זה הייתה שהיינו אומרים לכולם “תחברו את המפתח ותחתמו”.
      • אבל כמובן שזה לא טוב לנו - כי אז המפתח נחשף.
    • אז אנחנו בעצם מייצרים איזשהו פרוטוקול, שהוא פרוטוקול אינטראקטיבי בין השחקנים השונים, שיודע לחתום על טרנזקציה בלי להוציא את המפתח הפרטי - כל אחד מהחלק שלו.
      • אנחנו לא ניכנס ממש לקריפטוגרפיה שמייצרת את זה, אבל כל אחד חותם מהצד שלו על איזה חלקים מהטרנזקציה בצורה משותפת, וזה יוצא חתימה תקינה שכל אחד ב-Blockchain יוודא אותה.
  • ואז באמת עולה השאלה, רגע, איך אנחנו מתמודדים עם החלקים?
(רן) אם יש כישלון אחד בודד, לצורך העניין, בשרשרת הזאת - אז התנתקה שרשרת . . . 
  • (אריק) נכון. אז בעצם מה שאפשר לעשות - MPC זה כזה איזה שם כולל, ויש כמה - הוא מדבר על כל סוג של חישוב שאתה רוצה לעשות בצורה מבוזרת.
  • בתוך העולם הזה יש את העולם של TSS, שזה בעצם Threshold Signatures - שהוא מדבר על זה שאתה יכול לייצר חתימה עם X מפתחות, “T out of N” בדרך כלל מתארים את זה.
    • כלומר, אני יכול לבחור X חלקים של מפתח - ואני יכול גם לייצר סכמות.
    • אני יכול לומר סכמה של 2 מ-2, 3 מ-3, 2 מ-3, 5 מ-10 - אפשר לייצר כל מיני סכמות.
  • אז אם אני רוצה להימנע ממצב שמפתח בודד - שחלק מפתח אחד יאבד, אז זה יימנע חתימה - אני יכול לעשות את זה.
    • לא בהכרח אני רוצה - כלומר, יש איזה Design Principles שעכשיו אני צריך להכיל על הדבר הזה.
  • אבל מעבר לזה יש שאלה, אולי אפילו יותר קשה - מה יקרה אם אחד השחקנים הוא Compromised, הוא ינסה לרמות את האחרים?
    • ו-MPC, בבסיס שלו - כלומר, אם אנחנו מדברים על הכי-הכי Simple-MPC - הוא מה שנקרא “Honest But Curious”, אנחנו מניחים שכולם מוגנים.
      • ברגע שאנחנו הופכים את זה ל-Secure-MPC, אנחנו בעצם יוצרים פרוטוקול מורכב יותר וקשה יותר.
    • אבל ב-Secure-MPC, כל אחד מהשחקנים לא סומך על השחקנים האחרים.
    • כלומר, מספיק שיש בן אדם אחד שהוא מקיים פרוטוקול תקין - ואז אנחנו בעצם בסדר.
      • בניגוד ל”מספיק בן אדם אחד שעושה פעולה רעה”, כן?
(אורי) המודל הזה של-MPC, הוא לא ספציפית נכון לקריפטו, נכון? כשהסברת את זה, זה נשמע לי מוכר ממנגנונים של הצפנה, שעושים את אותו הדבר. נגיד, אנחנו השתמשנו בזה, כדי להימנע מדרישות של האיחוד האירופי, ש-Data  צריך להיות באיחוד האירופי, אז אמרנו, “אוקיי, אנחנו מצפינים את ה-Data, הוא יושב בארצות הברית - אבל מספיק שיש לך חלק מפתח אחד שיושב באירופה, ואי אפשר לעשות Decryption” . . .
  • (אריק) כן, אז הרבה פעמים - אני לא יודע בדיוק מה מיממשתם שם, אבל הרבה פעמים, כשעושים דברים כאלה, אז עושים יותר, כאילו, Secret Sharing - ה-Shamir Secret Sharing, למשל - כי פחות מעניין אותך העניין של “האם היה מפתח או לא היה מפתח”, אתה פשוט רוצה לפצל אותו כדי שזה יהיה בחלקים שונים.
    • אז יכול להיות שזה היה כזה, אבל יכול להיות שזה באמת היה MPC.
  • ה-MPC הומצא, אני חושב, בשנות ה-80 בערך - אבל בתכלס לא היה בו שימוש מהותי עד עולמות ה-Blockchain.
    • כלומר, ה-Killer Use Case של MPC הגיע בעצם בהגנה על ארנקים - זה היה המקום הראשון שבו זה התפוצץ.
    • היום כל האנשים שהיו מעורבים בהולדת ה-MPC והפיתוח שלו עובדים בחברות שקשורות לעולמות ה-Blockchain, כי שם ממש קורה ה-Innovation.
      • הרבה אנשים לא מבינים את זה, אבל כל העולם של קריפטוגרפיה מתקדמת - ו-MPC נכנס לקטגוריה הזאת, ויש עוד תחומים בעולם הזה - הם היו שקטים למדי במשך הרבה מאוד שנים, זה היה תחום לא מאוד סקסי.
      • ומאז שה-Blockchain נכנס, ההתקדמות שם היא מטאורית - זה קצת כמו מה שאנחנו רואים עם LLM-ים ו- AI.
    • יש התקדמות גם בעולמות ה-MPC, ה-Zero Knowledge Proof, ה-Fully homomorphic encryption (FHE)  . .  
      • יש כזה אוסף של עולמות שהם היו תיאורטיים ונחמדים, וגיקים של הנושא התלהבו מהם - אבל אף אחד לא השתמש בהם פרקטית.
      • והיום הם כולם מתקדמים ממש בצורה מטורפת - ויוצרים יכולות שגם כמתכנתים אנחנו יכולים להעריך אותם כאיזה Building Block בתוך משהו שאתה בונה.
      • ועדיין, זה לא קיים כמעט מחוץ לעולמות ה-Blockchain - אבל אני חושב שזה יקרה.
      • אנשים יכירו את הדברים האלה, שיכולים לעשות דברים שהם מרגישים באמת כמו קסם לפעמים - ואז יבינו, “רגע, גם במערכת שלי אני יכול להרוויח מהיכולת לעשות חישוב בצורה שאני לא חושף את המידע שאני עושה עליו חישוב, או חישוב שהוא מבוזר” או כל מיני דברים כאלה.
      • אז זה משהו שהוא מתפתח.

17:48 אז כמה Uncompromised צריך?

(רן) אז בוא נעשה רגע Recap: אמרנו, בתור התחלה יש לנו את “בעיית הכספת בשווייץ” - זאת אומרת, אנחנו לא רוצים שתיהיה ואנחנו לא יכולים לייצר כזאת כספת, זה לא Agile-י . . . אבל אנחנו רוצים כן את הביטחון שהיא נותנת, את האבטחה שהיא נותנת, של אי אפשר פשוט לבוא למישהו ולשדוד ממנו את המפתח, או שהוא לא יכול לאבד אותו. אז בתור התחלה נפצל את המפתח, ונדאג לזה שלא באמת היה קיים איזשהו מפתח במקום אחד, אלא המפתח נוצר על ידי שיתוף פעולה.
אבל אז נתקלנו בבעיה של “אוקיי, אבל מה קורה אם אחד מהשחקנים נכשל?” - ואתה אומר, אוקיי, גם לזה יש פתרון: מספיק X מתוך Y, מספיק ש-9 מתוך 10 השחקנים, יש להם את המפתח, זה בסדר. אבל זה השתמש בנקודת ההנחה שכולם משתפים פעולה וכולם טובים וכולם “בעדינו” - מה קורה אם אחד מהם הוא Evil או Compromised, או כל דבר כזה - וגם בזה אתה מטפל.
  • (אריק) כן.
(רן) אוקיי - ואז אני אשאל אותך את השאלה . . .  כמה מתוכם צריכים, גם פה יש את הסימטריה הזאת, של כמה מתוכם צריכים להיות Uncompromised כדי שזה יעבוד? האם מספיק שנגיד חמישה מתוך עשרה הם Uncompromised וגם לא איבדו את החלק שלהם של המפתח, כדי שזה יעבוד, או ש . . . זאת אומרת, איך מטפלים בסיפור הזה?
  • (אריק) כן, אז באמת כל מה שתיארת נכון, ויש בעצם . . . מתחיל לזה Design Space, של איך אתה רוצה לתכנן את ה-MPC שלך.
  • וזה רק החלק הראשון, ה-MPC - אנחנו ניגש עוד לעוד חלקים בעצם ב-Funnel - אבל ברגע שעשית Secure-MPC, אז אמרנו באמת - שחקנים הם שמוודאים שאחרים הם Honest, ואתה בעצם לא יכול לייצר חתימה לא טובה כל עוד יש מספיק שחקנים שהם כן Honest - ואנחנו גם לא חייבים לפצל את המפתח להמון.
  • כלומר, ברגע שאנחנו בונים מערכת גדולה מעל הדבר הזה -
    • אז נגיד במקרה של Fireblocks - אני יכול לדבר על חלק מהדברים - אז חלק מהמפתח יושב אצלנו, וחלק מהמפתח יושב אצל הלקוח, ואתה רוצה לייצר איזה מצב שאנחנו לא יכולים לחתום בשם הלקוח.
      • כי אנחנו ספק טכנולוגיה - אנחנו לא בנק, אנחנו רוצים לתת להם טכנולוגיה לעבוד, אז אנחנו לא רוצים להיות במצב שאנחנו יכולים לייצר חתימות בלעדיהם.
      • ומצד שני, אנחנו גם לא רוצים להיות במצב שאם הם - שהם לא בהכרח חברת Security ב-Level שלנו - אם הם יאבדו את החלק - לא יאבדו, יותר אם מישהו יגנוב את החלק-מפתח שלהם - אנחנו לא רוצים שהוא יוכל לחתום.
  • אז שוב, אפשר פה לעשות איזה Design - זה לא בהכרח אפילו דורש לעשות T-out of N, הרבה פעמים זה יכול להיות גם N-out of N, כשאני מטפל בבעיית העיבוד חלקי-מפתח, בכל מיני Backup-ים שונים וכל מיני דברים כאלה.
  • אז השאלה בעצם היא מה אנחנו מקבלים בתוך הדבר הזה - כשפיצלנו את המפתח, פתאום אם אתה רוצה לגנוב את המפתח, אז אתה צריך לפרוץ לא רק ל-Laptop של הלקוח, שיכול להיות שהוא לא שמור כל כך טוב.
    • אלא אתה צריך לפרוץ גם לשרתים של Fireblocks - כי אנחנו לא נחתום על משהו שהוא Malicious.
  • ואז אנחנו מתחילים כזה להתרחק, כן? אנחנו אומרים, אוקיי, אז יש לנו פרוטוקול MPC - שהוא כבר יציב, הוא בודק את עצמו
    • אבל אז יש את החלק של המפתח - צריך לאחסן גם אותו, נכון? צריך לשמור עליו.
  • אז אתה נכנס לכל מיני טכנולוגיות של Key Management Systems וכאלה, נכון? HSMs, Secure Enclave, כל מיני דברים כאלה.
    • אבל אם אנחנו רוצים ללכת עוד יותר קדימה בהקשר של הטכנולוגיה - כי זה לא רק מפתח, יש פה איזו פעולה.
    • אז איך אנחנו יודעים שהפעולה - אנחנו רוצים לאשר אותה?
    • כלומר, זה בסדר שכל החלקים משתפים פעולה - אבל יש איזו שאלה בכלל האם זאת פעולה שהיא טובה?
      • אולי הפעולה שכולנו כרגע חותמים עליה ביחד זה גנבת-הכסף? . . . 

20:15 שלב הראבק ו-Secure Enclave

(רן) כן, הבנתי - זאת אומרת, אתה רוצה להכניס פה “ראבק” מה שקוראים - זאת אומרת, Role-Based Access Control (RBAC), הידוע בכינויו “ראבק” . . .
  • (אריק) לא הכרתי את המינוח, אבל אני אוהב את זה מאוד . . .
(רן) כן, אז אתה אומר, אוקיי - “אני רוצה לאפשר לו להעביר 50 Bitcoins, אני לא רוצה לאפשר לו להעביר 50 אלף Bitcoins” . . . או “אני לא רוצה לאפשר לו למשוך - אני רוצה רק לאפשר לו להפקיד”, או בקיצור, “לעשות פעולה X, לא לעשות פעולה Y”.
  • (אריק) כן, בדיוק.
  • וברור לנו שבארגון - ושוב, כאן אנחנו מתחילים ללכת להבדל בין “ארגון" לבין “בן אדם”, כן?
    • בן אדם - יש לו ארנק שלו, והוא יכול לבזבז כסף.
    • אבל אם אתה בארגון - זה שמותר לך לעשות איזו פעולה כלשהי, ששולחת 10 דולר לכתובת ספציפית במקרה ספציפי, לא אומר שיש לך את המפתחות לכספת של הבנק . . .
    • כלומר, יש פה אנשים, יש פה תפקידים, יש פה תהליכים, יש פה דברים שמותר, אסור, מגבלות וכאלה.
(רן) כן, כמו שבבנק מנהל הסניף יכול לחתום עד כך וכך, ופקיד עד כך וכך, וכו’.
  • (אריק) נכון. אז כאן, אנחנו רוצים בעצם להוסיף איזשהו Policy, נכון? אנחנו רוצים להוסיף איזשהו משהו, שאתה בודק אותו אפילו לפני שאתה מתחיל חתימה.
    • אולי אסור לחתום - כ-Fireblocks, אנחנו לא נחתום על משהו שלא עובר Policy.
(רן) כן, אבל זה לא נשמע לי כמו אתגר כזה מסובך, סליחה . . . זאת אומרת, כאילו, נכון - יש פה מה למממש: אתה שם Database, אתה מגדיר הרשאות וזה, אבל למה זה כזה מסובך?
  • (אריק) אז אוקיי, אז זה לא מסובך - ובהינתן אחד משני דברים: או שאנחנו לא מדברים על הרבה כסף, או שאנחנו מדברים על הרבה כסף, אבל זה שאתה תשיג את ה-Secret לא מאפשר לך אשכרה לעשות איתו משהו מיידי.
  • ברגע שאתה ארגון שמנהל על ה-Blockchain מיליארד דולר, ויש לך איש DevOps
    • אז אם הוא יכול פשוט ב...אתה יודע, כי יש לו הרשאות - כן, יש Role-based Permissions, אבל יש לו Root לשרת, יש לו Root ל-KMS, יש לו ניהול של ה-AWS, יש לו את כל הדברים האלה - בתכל’ס הוא יכול לעשות מה שהוא רוצה . . . 
    • ואם אתה מתחיל לפרק ארגון מורכב כזה, אתה תמצא את עצמך עם הרבה אנשים שיכולים לעשות מה שהם רוצים - ואתה מקווה שאחד מהם לא אשכרה ירצה לעשות את זה . . 
      • וזה לא משהו שאפשר לעשות
      • (אורי) . . . כי אי אפשר לסמוך עליו . . 
      • (אריק) בדיוק, כי אפשר להסתמך על זה - ואני חושב שקצת זה מה שהיה קורה פעם, לפני שחברות כמונו התחילו לקום.
    • היה איזו בורסה, היה בה המון כסף - ואז הם אמרו “נגנב לנו המפתח!”, וכל בן אדם שהיה לקוח שלהם חשב לעצמו “רגע, רגע . . .  נגנב להם המפתח - או שהם גנבו את המפתח? אני קצת לא בטוח מה קרה פה” . . .
    • אבל אנחנו רוצים לייצר איזו תשתית שהיא טובה וחזקה מספיק, ככה שאם אנחנו רגע מדברים ממש בהערכת סיכונים - גם Root בשרת לא ייתן לך לקחת את הכסף.
(רן) כן, זאת אומרת, אתה רוצה לייצר RBAC - אבל אתה לא רוצה שלאף אחד תהיה את האפשרות לשנות את ה-RBAC הזה, מבלי שבאמת התכוונת לתת לו את זה. 
  • (אריק) כן, כן.
(רן) אוקיי, אז איך עושים את זה? זאת אומרת, נשמע כמו עוד מפתח! עוד שכבה של אותו סיפור . . . אבל אז שוב יש לך את הבעיה, של “מי מנהל את המפתח האחרון?” . . . 
  • (אריק)  נכון . . .
  • אז בעצם, מה שהכנסנו זה ברגע שנכנסנו לעולם הזה, Fireblocks נכנסה לעולם הזה של MPC, Secure MPC וכל הדבר הזה, אז התחילה להוסיף עוד שכבות - וזה בעצם סוג של “ללכת אחורה ב-Funnel” הזה של התהליך, עד לשלב שאנחנו יכולים לומר שהפעולה כבר לא תסכן את הכסף.
    • וכל מה שנמצא בדרך - למשל, Policy Management - אם הוא כן פעולה שתסכן את הכסף, וכמובן ש-Policy Management זה כן - אז אנחנו מכניסים את זה למשהו שנקרא Secure Enclave [וואו, איזה פלאשבק לאינטל 2010 . . . ]. 
      • כלומר, אנחנו בעצם רצים בסביבה שהיא “מיוחדת” - אנחנו לא רצים פשוט ככה “בתוך השרת”, כי אם נרוץ בתוך השרת, יש הרבה אנשים שיכולים לשנות.
      • אנחנו רוצים לרוץ בצורה שאי אפשר לשנות את הקוד, שאי אפשר לשנות את הזיכרון, שאי אפשר, כאילו בעצם . . .  יש המון - אי אפשר לקרוא את הזיכרון, כי שם נמצא המפתח. אי אפשר לעשות הרבה דברים שאתה בעצם רוצה למנוע.
      • ויש טכנולוגיות בדברים האלה - כלומר, כל הטכנולוגיות האלה של Secure Compute, אלו טכנולוגיות שנבנו בדיוק לדבר הזה, ומאפשרות לך להריץ קוד בסביבה שהיא מנותקת [פיזית, ברמת ה-Hardware]
      • בוא נגיד שהיא רואה אפילו את ה-Operating System בתור “אויב” . . .
  • (רן)  כן, זאת אומרת, “סביבה” - למה את מתכוון? לחומרה?
    • (אריק) אז כן - זה ממש ברמת החומרה.
    • יש כמובן גם אופציות ב-Cloud שהן יותר מבוססות Cloud ועושות את זה ברמת אבסטרקציה גבוהה יותר
    • אבל אם אנחנו הולכים למחמירים - ואנחנו מהמחמירים - אז בעצם זה משהו שהוא ברמת החומרה.
    • אפשר לחשוב על זה כעל חלק בזיכרון שהוא ממש מנותק ממערכת ההפעלה - כלומר, ה-CPU יכול לגשת אליה, אבל הוא ניגש אליה דרך . . . לפעמים זה אפילו איזה Chip-הצפנה בדרך, ואף אחד מחוץ למה שאמור לרוץ ב-Secure Enclave הזה לא רץ ב-Secure Enclave הזה, לא נוגע ב-Secure Enclave הזה.
      • בטכנולוגיות הטובות ביותר, אפילו אם תנסה לקרוא את מה שרשום על הדיסק - אז הוא מוצפן, אז אתה לא יכול לקרוא את זה.
      • כלומר, זה ממש אמור להיות מוגן ברמה הכי גבוהה. 

25:04 זמן טוב לדבר על Blackhat - ו-CMP

(רן) אוקיי, עכשיו זה זמן טוב לדבר על Blackhat? יש לנו מספיק Context? אז למי שלא מכיר, רק שנייה - Blackhat זה כנס שנתי מאוד מאוד גדול שקורה עדיין ב-Vegas? כן . . .  זה, אני חושב, הכנס מספר אחת בעולם ה-Security . . .
(אורי) שתיים, שתיים . . . 
(רן) אוקיי, אחרי רברסים . . . ושם ניתן דגש גם על טכנולוגיות להגנה - אבל גם על דרכים לפריצה, זאת אומרת, כדי שנכיר את מה שנקרא “להכיר את האויב” [גם ברברסים! ד”ש לג’וזף]. הכינוי “Blackhat” ”זה מין כינוי כזה לפורצים
אז באת - אתה והצוות - והצגתם איזושהי תגלית - ספר לנו עליה קצת.
  • (אריק) כן, אז קודם כל: אורן וניקוס - אני רוצה לתת להם את הקרדיט, הם עשו עבודה מדהימה.
  • אז בעצם בתוך כל המנגנון הזה, אנחנו מסתכלים על כל המערכת הזאת ואנחנו חוקרים את התחומים האלה - זה מה שאנחנו עושים כחברה.
  • כמו שהפרוטוקול MPC שלנו זה משהו שאנחנו בעצם כתבנו, שחררנו . . .
  • אז בעצם אנחנו חוקרים את הנושא הזה, ובשלב מסוים אנחנו אומרים “רגע, אלגוריתם MPC, הוא בעצם מדבר באמת על זה שאף אחד לא סומך על אף אחד, וגם אם אתה תשתלט על אחד מהשחקנים, אתה לא אמור להיות מסוגל לעשות שום דבר”.
    • ואנחנו רוצים למצוא - אולי כן אפשר?
    • אז חקרנו אלגוריתמים שונים בתעשייה - ובעצם מצאנו בשני אלגוריתמים, שהם היו אלגוריתמים המובילים בתחום.
    •  בעצם CMP היה טיפה פחות מוכר, או קצת חדש יותר - היו כמה אלגוריתמים מובילים, ביניהם GG ו-Lindell 
      • אלו שני אלגוריתמים מאוד מוכרים, שהרבה מאוד חברות, גם בתחום שלנו, השתמשו בהם.
    • ומה שבעצם אנחנו מצאנו זה שבאלגוריתמים האלה,  אם אתה עושה “משחק" כלשהו - והיתה שם, שוב, עבודה מתמטית-קריפטוגרפית יפיפייה של ניקוס - אם אתה עושה “משחק” כלשהו, אתה בעצם - במידה ותשתלט על אחד השחקנים - אתה תוכל לאט לאט “לדלות את הסוד” מהשחקנים האחרים.
      • זה משהו שאסור שיהיה קיים באלגוריתם MPC - אנחנו מניחים שאף אחד לא מספר שום דבר לאף אחד אחר, זה כל הבסיס לדבר הזה.
    • מה שבאמת הצגנו בBlackhat [הנה השקפים - Small Leaks, Billions Of Dollars: Practical Cryptographic Exploits That Undermine Leading Crypto Wallets] ו-DEFCON [לזה יש ההקלטה - EF CON 31 - Small Leaks, Billions Of Dollars - Nikolaos Makriyannis, Oren Yomtov
      • זה כזה השילוב היפה ב-Vegas: שני כנסים שמגיעים אחד אחרי השני . . .
    • זה . .  אני חושב שזה היה ארבע התקפות בסופו של דבר, שתוקפות מספר פרוטוקולים שונים בהכי-קיצוני שלהם, בחתימה אחת
      • או יותר מזה - בסיבוב הראשון, בתוך החתימה הראשונה, כי MPC זה לרוב מורכב מסיבובים - אתה מסוגל להוציא מפתח, בעצם, משחקן אחר.
    • וככל שהאלגוריתם שונה ואחר, אז זה יכול לקחת יותר חתימות - בחלק מאופציות ממש הרבה חתימות - אבל בעצם הצלחנו סוג-של-לשבור אלגוריתמים מסוימים של MPC.
  • שוב, זה אלגוריתם שלנו - שהיה חשוף לזה, אבל זה כמו כל דבר ב-Security, כן? אנחנו מוצאים את החולשה הבאה, הראינו גם את הפתרונות לדברים האלה, ולאט לאט כל התעשייה מתקדמת ומוצאת פתרונות טובים וחדשים יותר.
    • כן ראינו, בעצם, שחברות גם מאמצות את הפתרונות שהבאנו לזה וגם בעצם עוברות לאלגוריתמים קצת  חדשים יותר בחלק מהמקומות
      • נוטשות אלגוריתמים שכבר הוכחו כלא טובים, בחלקם,  ועוברים לדברים אחרים.


28:19 לתכנת אלגוריתמים קריפטוגרפיים

(רן)  אז אחד מהאתגרים בלהתעסק בעולם הזה של קריפטו זה באמת האתגרים האלגוריתמיים. כמו שאמרת,
שגיאה אלגוריתמית, אולי, בתכנון של הפרוטוקול - לא שזה קל לתכנן כזה פרוטוקול - אבל עם הזמן מגלים בעיות אלגוריתמיות ומשפרים את הפרוטוקול, משפרים את האלגוריתם ופותרים אותם.
אבל בהינתן פרוטוקול - ובוא נניח שהוא מושלם - לבוא ולקח את הפרוטוקול הזה ולתכנת אותו, זה עולם ומלואו, אוקיי? זה לא פשוט . . . צריך לדעת איך לעשות את זה - ולכם יש הרבה מאוד ניסיון בזה.
אז אולי ב . . . אין לנו הרבה זמן, אבל בדקות האחרונות שנשארו לנו, אולי כמה למידות שלכם, של מה זה אומר לקחת איזשהו Whitepaper, לקחת איזשהו פרוטוקול קריפטוגרפי - ולתכנת אותו, “לשים אותו על שרתים”.
  • (אריק) כן, אז אני חושב שבאמת אחד הדברים ש... יש הרבה מאוד תובנות בתחום הזה, ואני חושב שאחד הדברים שחשוב להבין - וזה כזה סוג של לקח שבאמת נכתב ב . .  אולי “דם” זו לא המילה הנכונה, אבל מאמר אקדמי הוא לא Spec, אוקיי? 
    • והרבה אנשים קוראים מאמר, וזה קצת מרגיש כאילו זה Spec - כי בעצם מתארים שם פעולות
      • לרוב זה Pseudo-code כזה - כמתכנת אפילו אתה סוג-של-מבין מה קורה
    • אבל יש המון דברים מתחת לפני השטח, שאלא אם כן באמת יש לך את המקצועיות והידע איך לקרוא מאמר כזה, אתה פשוט תניח שהן לא הנחות נכונות, כלומר שמשמיטים שם דברים.
    • בסוף, מאמר אקדמי זה מאמר - המטרה . . . 
  • (אורי) . . . הוא לא יביא את “מקרי הקצה” - הוא יביא את ההוכחה האקדמית שמשהו קורה, אבל . . .
  • (אריק) אז לפעמים לגמרי, לפעמים זה מאוד תלוי מה המטרה של המאמר.
    • לפעמים המטרה של המאמר זה לתת פרוטוקול מלא, לפעמים המטרה שלו זה שבכלל פשוט יש לו רעיון אחד חדשני, אבל הוא יודע שבשביל הרעיון הזה, הוא צריך לעטוף אותו בהמון דברים, אז הוא “עושה את העטיפה שצריך” כדי שהמאמר יתקבל לכנס הנכון . . . .
    • ואז אתה קורא את זה, ואתה מניח שאם מה שקראת זה מה שיש אז הכל בסדר - אבל הוא בעצם מניח  שקראת עוד ארבעה מאמרים אחרים לפני זה כשתממש את זה, כן? . . . 
    • אז זה למשל משהו שממש יכול להיות מהותי.
  • מעבר לזה, הרבה פעמים בכלל המאמר מתייחס לאיזו סיטואציה בעולם, אוקיי?
    • כלומר, הוא מניח שזה משחק חד-פעמי, אוקיי?
    • זה מאמר - הכל Secure, הכל טוב, הכל מעניין, הכל מוכח - כל עוד אתה משחק את זה פעם אחת. 
      • אבל אם תשחק את זה הרבה פעמים, אז כבר שום דבר פה לא עובד . . . 
    • זה לא בהכרח יהיה כתוב בצורה הברורה שאתה מניח - כלומר, יש איזה הנחות של איך המערכת עובדת.
      • האם אתה עושה Input Validation לפני האלגוריתם הזה? יכול להיות שהוא מניח את זה, יכול להיות שהוא לא מניח את זה . . . .
    • כלומר, יש פה עולם שלם של בכלל איך אתה נכנס לדבר הזה.
    • אז זה למשל איזור אחד.
  • אני חושב שאיזור אחר שהוא גם מעניין . . . 
(רן) כן, זאת אומרת לדעת “איך לקרוא” את המאמר, או במילים אחרות: “כבדהו וחשדהו”, זאת אומרת - יכול מאוד להיות שהנקודות שם מאוד נכונות, אבל אתה צריך לדעת שאם איך לך את “התלמוד שמבאר אותו”, אתה לא תדע להבין את המשמעות העמוקה יותר שלו.
  • (אריק) נכון - ואתה לא תדע להבין את הדברים שלא צוינו בעצם.
  • ולפעמים, גם זה קצת מצריק לומר את זה, אבל במאמרים . . . 
(אורי) לרוב, כל מה שיש מסביב ולא מצוין - זה החיים, “החיים עצמם”, מה שנקרא . . . .
  • (אריק) נכון, לגמרי, לגמרי . . .  והרבה גם ממה שפורסם ב-Blackhat - חלק מהדברים היו שם, כלומר המאמר היה בסדר, אבל ברגע שהשתמשת בו בעולם האמיתי זה לא עבד טוב.
    • כלומר - הייתה בעיה, שצוינה בצורה מסוימת או שלא צוינה בצורה מסוימת - אבל ראינו שהרבה בעצם לא יודעים לפתור אותה.
  • דבר נוסף שהוא מאוד חשוב - דיברנו על Secure Enclave, דיברנו על כל הטכנולוגיה שאתה שם, על MPC, על  כל הדברים האלה.
    • אבל נגיד שיש שאלה של Supply Chain Attacks, כן? כלומר, אתה כותב קוד ואתה, מכיוון שאין לך הרבה זמן, אתה דוחף פנימה איזה 15 ספריות שונות, שעכשיו נמצאות בתוך ה-Secure Enclave שלך . . . 
    • אז זה נחמד שאתה מאוד Secure מהתקפות מבחוץ - אבל מה אם יש לך Malware בתוך הקוד שנכנס, כן?
    • כלומר, יש הרבה דברים שמבחינת ה-Security, פשוט  Security Practices בסיסיים, הם . . .
      • שוב, ברגע שאתה שוב מתעסק במשהו כל כך מורכב, אתה צריך להקשיח אותם מאוד.
    • ה-MPC שלך מקבל Input - מה אתה עושה עם ה-Input הזה? עד כמה אתה רגיש למישהו שמשחק עם ה-Input בצורה שהיא לא צפויה, כדי להתחיל לייצר התנהגות אחרת?
    • כלומר, יש ממש הרבה דברים שאתה צריך לגעת בהם כשאתה מתכנן את המערכת הזאת
      • היא ממש דורשת כזה “איזורי Expert” - אתה צריך להיות Expert בקריפטוגרפיה, אתה צריך להיות Expert ב-Blockchain, אתה צריך להיות Expert ב-Security.
      • או לאסוף את כמות האנשים האלה שבעצם מסוגלים לאסוף את כל הדברים האלה למשהו קוהרנטי,  שגם עובד טוב ביחד
      • כי יכול להיות איש Security מדהים ואיש קריפטוגרפיה מדהים - אבל בדיוק בתווך ביניהם, זה איפה שהכל מתפרק.
    • וגם זה דברים, שבעצם במאמר שלנו - במאמר וההרצאה ב-Blackhat - ממש נגענו במקום הזה.
      • כלומר, בנקודה הזאת, שבה “הקריפטוגרפיה פוגשת את העולם האמיתי”.

33:15 ובחזרה ל-Fireblocks

(רן) אוקיי, אז נסכם - אז Fireblocks, אתה אומר - התחלתם בבעיה הנקודתית הזאת, של איך להחזיק מפתח, איך  להחזיק מפתח בצורה שהיא Secure, ואחר כך להוסיף על זה הרשאות וכו’, וגם אמרת, לא נכנסנו לשם, אבל שאתם הרחבתם את השירותים שלכם מעבר לזה, לזה לא היה לנו זמן להיכנס פה.
ואז צללנו קצת פנימה, לתוך עולם הבעיות האפשרי - ואיך אפשר, ככה ממש על קצה המזלג, לפתור אותן. 
זזה היה סופר-מרתק!
ספר לנו אולי עוד קצת על החברה - אתם כרגע מגייסים? מחפשים? איפה אתם נמצאים בכלל? אמרת? . . .
(רן) איפה זה תל אביב? . . . .
  • (אריק) תל אביב בואכה רכבות למיניהן . . . .
  • כמובן מגייסים  . . . Fireblocks, לא דיברנו על זה בכלל, אבל יש לנו כבר הרבה לקוחות
    • חברה שהיא מאוד מצליחה.
    • אני חושב שעד היום איבטחנו משהו כמו 4 טריליון דולר במערכת - כלומר, אנחנו מתעסקים באמת בכסף מהותי, בעיות מהותיות של לקוחות אמיתיים.
  • וגם כל מיני אנשים - אני יודע שהרבה אנשים כזה,  “Blockchain” זה משהו שהם כזה לא בטוחים “כמה קורה שם משהו מעניין”.
    •  אנחנו באמת עובדים עם החברות הטובות בעולם - חלקן פומביות לגבי הדברים שהן עושות ב-Blockchain,  חלקן עוד לא פומביות.
    • אבל גם בכל השנים האלה, שמאוד יכול להיות שלא - בתור “טכנולוגים” - לא התעסקתם ב-Blockchain, כי זה היה נשמע כמו משהו שכבר “עבר, קרה ולא מעניין” . . . .
      • הרבה חברות בנו בזמן הזה - בין אם זה חברות שבונות טכנולוגיה כמונו, ובין אם זה חברות מוצר.
    • המנכ״ל של Shopify, ה-Founder של Shopify, טובי (Tobias Lütke)- לפני איזה חצי שנה הוא היה בכנס, והוא אמר “אנחנו בונים דברים טובים בקריפטו כרגע. כרגע זה לא נשמע מגניב - עוד מעט זה יהיה מגניב, ואתם תשמעו על זה אז”. [Crypto Conversations | The future of the digital economy with Brian Armstrong & Tobi Lütke]
      • ואני חושב שזה מייצג מאוד את התעשייה - הרבה טכנולוגיה נבנתה פה ונבנית פה, ולאט לאט היא תצא לעולם, בקצב שהרגולציה ופשוט הטבע של האנשים יאפשרו לה.
    • (רן) כן, בעקומת ה-Hype, אנחנו עכשיו במדרון המתון העולה  . . . 
    • (אריק) נכון, לגמרי.
(רן) אוקיי - ואם אני לא מבין, כלומר - אם אני מפתח, אבל מעולם לא עברתי בעולם הקריפטו ואני לא מכיר, יש לי מה לחפש אצלכם?
  • (אריק) חלק קטן מאוד ממה שאנחנו עושים בחברה זה האזורים האלה של הקריפטוגרפיה.
    • מעל זה, יש שכבות על גבי שכבות של מוצר - מאוד חדשני שפותר בעיות ללקוחות.
    • כלומר, כל הדברים הרגילים שאנחנו מכירים - כשיש להם איזה “Flavor”, כאילו גם “Flavor FinTech-י”
      • אנחנו היום הרבה יותר חברת פינטק מאשר סייבר . . . 
      • זה התחיל מאוד Security-oriented, וזה עבר לפשוט לאפשר לבנות . . . 
    • אנחנו, המטרה שלנו זה שכל עסק שרוצה לבנות - ואנחנו מאמינים שכל העסקים יגעו בעולם ה-Blockchain בעתיד - יוכל לעשות את זה, בלי להתעסק בכל הדברים שדיברנו.
      • כלומר, שהם פשוט יקבלו מוצר טוב שהם עובדים איתו, הוא עובד כמו שצריך, הוא בטוח - והוא גם Easy to Use.
    • אז זה לגמרי לבנות מוצר טכנולוגי לאנשים.

(רן) אוקיי, אריק, תודה רבה! היה לי ממש כיף, להתראות.


 האזנה נעימה ותודה רבה לעופר פורר על התמלול!