04 · כשהשימוש גדל
מה קורה כשהרבה יותר אנשים רוצים להשתמש ברשת?
כל פעולה ברשת דורשת עבודה.
מידע צריך להגיע למחשבים אחרים.
עסקאות צריכות להיבדק.
בלוקים צריכים להיבדק ולהישמר.
ובמערכות שמריצות תוכניות, גם החישובים והתוצאה שלהן צריכים להיבדק.
עכשיו דמיינו שמספר המשתמשים גדל מאוד - וכולם רוצים שהרשת תמשיך להגיב מהר.
יותר שימוש פירושו יותר עבודה למחשבים שבודקים
אם יותר אנשים שולחים עסקאות, המחשבים ברשת צריכים לקבל יותר מידע.
הם צריכים לבדוק יותר עסקאות, לעבד יותר בלוקים ולשמור את המידע שנדרש כדי להמשיך לבדוק את הפעילות הבאה.
אם יש גם Smart Contracts, חלק מהפעולות דורשות יותר חישוב ומשנות יותר מידע.
כלומר:
יותר פעילות לא נעלמת רק מפני שאנחנו רוצים שהרשת תהיה מהירה יותר.
המחשבים עדיין צריכים לעבד ולבדוק אותה.
כמה פעילות אפשר לעבד - וכמה מהר מקבלים תשובה - אלה שתי שאלות שונות
רשת יכולה להצליח להכניס הרבה פעילות לאורך זמן.
זו שאלה של Capacity / Throughput - קיבולת או תפוקה.
אבל המשתמש גם שואל:
כמה זמן עובר עד שאני רואה שהפעולה שלי נכנסה?
ו-
כמה זמן עובר עד שאני מרגיש בטוח שאפשר להסתמך עליה?
אלה שאלות קשורות - אבל הן לא אותה שאלה.
לכן כשאומרים שרשת “מהירה”, כדאי לשאול:
מה בדיוק נעשה מהיר יותר?
למה לא פשוט לתת לרשת לעשות הרבה יותר?
אפשר לנסות להגדיל את כמות הפעילות בכל בלוק.
אפשר ליצור בלוקים לעיתים קרובות יותר.
אפשר לדרוש מהמחשבים ברשת להיות חזקים יותר.
כל אחת מהאפשרויות יכולה להגדיל ביצועים.
אבל אז צריך לשאול שאלה נוספת:
מי עדיין יכול לעמוד בדרישות ולבדוק את הרשת בעצמו?
אם בדיקה עצמאית דורשת שרתים יקרים מאוד וחיבור שרק מרכזי נתונים יכולים להחזיק, פחות אנשים יוכלו להפעיל Node בעצמם.
יותר משתמשים ייאלצו להסתמך על שירותים גדולים שיבדקו עבורם.
לכן ביצועים וביזור קשורים זה לזה.
גם כשהרשת עמוסה, הכללים עדיין צריכים להישאר אמינים
רשת מהירה מאוד לא עוזרת אם אפשר לעקוף את כללי התשלום.
עדיין צריך למנוע מצב שבו מישהו מוציא כסף שאין לו, משתמש באותו כסף פעמיים או מצליח להחליף בקלות היסטוריה שכבר התקבלה.
לכן אין מספר אחד - כמו TPS - שאומר לבדו איזו רשת “טובה יותר”.
אנחנו רוצים כמה דברים יחד:
יותר פעילות.
תגובה מהירה.
אפשרות לבדוק באופן עצמאי.
וכללים שקשה לעקוף.
ויש עוד בעיה כשמנסים ליצור בלוקים מהר יותר
מידע לא עובר באינטרנט מיד.
נניח שכורה אחד מוצא בלוק חדש ומפרסם אותו.
הבלוק מתחיל להתפשט בין המחשבים ברשת.
אבל לפני שהמידע מגיע לכורה אחר, גם הכורה השני יכול למצוא בלוק חדש שממשיך מאותו עבר.
עכשיו קיימים שני בלוקים תקינים שנוצרו בלי שאחד מהם ידע על השני.
הם לא חייבים להיווצר בדיוק באותה שנייה.
מספיק שהבלוק השני נמצא לפני שהמידע על הראשון הגיע אליו.
כורה A מוצא בלוק חדש ומשדר את המידע עליו לרשת. כמה אותות כתומים מתפשטים לכיוונים שונים, ואחד מהם מתקדם לעבר כורה B. לפני שהמידע מגיע אליו, כורה B מוצא באופן עצמאי בלוק תקין נוסף שממשיך מאותה היסטוריה קודמת. שני הגילויים אינם חייבים להתרחש באותו רגע. האנימציה אינה קובעת איזה בלוק ינצח.
ככל שבלוקים נוצרים בתדירות גבוהה יותר, זה יכול לקרות לעיתים קרובות יותר
אם עוברות דקות בין בלוקים, לרוב יש הרבה זמן למידע להתפשט לפני שנוצר הבא.
אם בלוקים נוצרים פעמים רבות בשנייה, טבעי יותר שכמה כורים ימצאו בלוקים לפני ששמעו זה על זה.
ב-Bitcoin מצבים כאלה יכולים ליצור ענפים זמניים, ובסופו של דבר ענף תקין אחד נשאר השרשרת הראשית לפי העבודה המצטברת.
כלומר, חלק מהעבודה שנעשתה במקביל לא ממשיך כחלק מהשרשרת הראשית.
אז האתגר הוא לא פשוט “לעשות הכול מהר יותר”
המטרה היא לא רק לייצר עוד בלוקים.
המטרה היא לאפשר יותר פעילות ותגובה מהירה - ועדיין להשאיר את הרשת ניתנת לבדיקה על ידי משתתפים עצמאיים.
וכשבלוקים נוצרים מהר, צריך להתמודד טוב יותר עם עבודה שנעשית במקביל.
אז עולה שאלה חדשה:
מה אם לא חייבים לבחור מיד רק אחד משני בלוקים תקינים שנוצרו במקביל?
