עמלה ברשת הביטקוין אינה אחוז מהסכום המועבר, אלא תשלום עבור מקום בבלוק: היא נגזרת ממשקל העסקה בבתים וירטואליים (vB) כפול תעריף שנמדד בסאטושי לכל vB. מאגר העסקאות הממתינות בכל צומת, ה-Mempool, הוא שמכתיב איזה תעריף מספיק כדי להיכנס לבלוק הקרוב, ומנגנוני RBF ו-CPFP מאפשרים לתקן תעריף שנבחר נמוך מדי לאחר שהעסקה כבר שודרה.
למה נגבית עמלה ברשת הביטקוין
הפרוטוקול אינו גובה תשלום עבור עצם ההעברה של ערך. מה שהעסקה משלמת עליו הוא משאב מוגבל אחד: מקום בבלוק. כל בלוק חסום ב-4,000,000 יחידות משקל (weight units), השקולות למיליון בתים וירטואליים, ובלוק חדש נמצא בממוצע אחת לעשר דקות. כאשר נפח העסקאות המשודרות עולה על מה שנכנס לבלוקים, נוצר תור, והתעריף הוא הכלי היחיד שמסדר אותו.
מרחב הבלוק כמשאב מוגבל
אין גורם מרכזי שמפרסם מחירון עמלות. כל שולח מצרף לעסקה תעריף לפי בחירתו, וכל כורה מרכיב את הבלוק שלו כרצונו. ההרכבה המקובלת ממיינת את העסקאות הממתינות לפי תעריף לכל vB – ולא לפי גובה העמלה המוחלט – משום שהמשאב הנדיר הוא המשקל, לא מספר העסקאות. עסקה קלה שמשלמת תעריף גבוה תיכנס לפני עסקה כבדה שמשלמת יותר סאטושי בסך הכול אך פחות עבור כל בית וירטואלי. זו הסיבה שכל דיון בעמלות ברשת הביטקוין הוא בהכרח דיון ביחידת מידה, ולא בסכום.
העמלה כרכיב בתגמול הכורה
תגמול הכורה מורכב משני חלקים: מענק הבלוק, שנוצר יש מאין בעסקת ה-coinbase, וסכום העמלות של כל העסקאות שנכללו באותו בלוק. מענק הבלוק נחצה אחת ל-210,000 בלוקים, כארבע שנים, עד שכמות המטבעות תתקרב לתקרה של 21 מיליון. ככל שהמענק קטן, משקלן היחסי של העמלות בתגמול הכולל גדל, ולכן העמלות אינן תוספת טכנית שולית אלא חלק ממנגנון האבטחה ארוך הטווח של הרשת. הסבר מסודר על אופן חלוקת התגמול ועל תפקיד הכורים מופיע בעמוד כריית ביטקוין.
איך נמדד גודל העסקה: בתים, weight units ו-vB
עד להפעלת SegWit בשנת 2017 הוגבל הבלוק במיליון בתים של ייצוג סדרתי. SegWit הפריד את נתוני החתימה (witness) משאר גוף העסקה והחליף את מגבלת הגודל במגבלת משקל. השינוי הזה הוא שהוליד את שתי היחידות שמשמשות היום בכל חישוב עמלה: יחידת משקל ובית וירטואלי.
נוסחת המשקל ואיך מגיעים ל-vB
המשקל מחושב לפי weight = base size × 3 + total size, כאשר base size הוא הייצוג הסדרתי ללא נתוני החתימה, ו-total size כולל אותם. קיימת ניסוח שקול ונוח יותר: כל בית שאינו נתון חתימה נספר כארבע יחידות משקל, וכל בית של נתוני חתימה נספר כיחידה אחת בלבד. מכאן ההנחה בשיעור 75 אחוז שניתנת לנתוני החתימה. הגודל הווירטואלי מתקבל מחלוקת המשקל בארבע ועיגול כלפי מעלה: vsize = ceil(weight / 4).
דוגמה מלאה: עסקת SegWit מסוג P2WPKH עם קלט אחד ושני פלטים. החלק שאינו נתוני חתימה מונה 113 בתים – עשרה בתים של תקורה קבועה, 41 בתים לקלט ו-31 בתים לכל אחד משני הפלטים. נתוני החתימה מוסיפים 110 בתים, מהם 108 לחתימה ולמפתח הציבורי ושניים לסמני ה-marker וה-flag. המשקל הוא 113 כפול 3 ועוד 223, כלומר 562 יחידות, והגודל הווירטואלי הוא 562 חלקי ארבע – 140.5, שמעוגל ל-141 vB. אותה עסקה בדיוק, אילו נבנתה במבנה Legacy ללא הפרדת witness, הייתה נספרת במלוא 226 הבתים שלה.
העמלה אינה שדה בתוך העסקה
נקודה טכנית שנוטים לפספס: העמלה אינה נרשמת בשום שדה של העסקה. היא ההפרש בין סכום הקלטים לסכום הפלטים, וכל צומת מחשב אותה בעצמו בעת האימות. מכאן נובעת תוצאה חשובה: כל שארית שלא הופנתה לפלט עודף (change) נחשבת אוטומטית לעמלה. תקלה בבניית פלט העודף עלולה להוביל לתשלום עמלה גדול בסדרי גודל מהמתוכנן, ואין דרך לבטל זאת לאחר האישור.
מה זה Mempool ואיך הוא מתרוקן
Mempool הוא מאגר הזיכרון של עסקאות שנבדקו ואומתו אך טרם נכללו בבלוק. חשוב להדגיש שאין Mempool אחד: כל צומת ברשת מחזיק מאגר משלו, שנבנה מהעסקאות שהגיעו אליו בפועל ולפי כללי המדיניות המקומיים שלו. שני צמתים שנמצאים במרחק כמה קפיצות רשת זה מזה יראו תמונות שונות במקצת, במיוחד בשניות הראשונות לאחר שידור. מה שמוצג באתרי ניטור הוא תצפית של צומת מסוים אחד, לא מצב אובייקטיבי של הרשת כולה.
המאגר מתרוקן בשתי דרכים. הראשונה היא בלוק חדש, שמסיר ממנו את כל העסקאות שנכללו בו – עד מיליון vB בכל פעם. השנייה היא מדיניות מקומית: בתוכנת הצומת הנפוצה מוגדרת תקרת זיכרון של 300 מגה-בייט כברירת מחדל, וכשהמאגר מתמלא נדחות ממנו החבילות בעלות התעריף הנמוך ביותר, בעוד סף הכניסה הדינמי עולה בהתאם. במקביל קיימת רצפת תעריף להעברה (minrelaytxfee) של סאטושי אחד לכל vB, ועסקאות שממתינות מעל 336 שעות, כלומר שבועיים, נמחקות מהמאגר בברירת המחדל.
עסקה שנמחקה מהמאגר של צומת מסוים אינה מבוטלת. היא פשוט אינה מוכרת עוד לאותו צומת, ולא נוצר שום שינוי במצב הרשת. כל עוד היא חתומה ותקפה אפשר לשדר אותה מחדש, והיא תתקבל אם התעריף שלה עומד בסף הנוכחי. ארנקים רבים מבצעים שידור חוזר אוטומטי בדיוק מהסיבה הזו.
דפוסי עומס ומה משפיע עליהם
מציאת בלוק היא תהליך הסתברותי. עשר דקות הן ממוצע ולא קצב קבוע, ולכן בפועל מתרחשים גם רצפים של שלושה בלוקים בתוך דקות ספורות וגם פערים של ארבעים דקות ויותר. פער ארוך מצטבר לתור: העסקאות ממשיכות להישלח בקצב קבוע בזמן שאין בלוקים שיפנו מקום, ולכן הסף הנדרש עולה. כשנמצאים לאחר מכן כמה בלוקים ברצף, התור מתקצר במהירות והסף יורד. קושי הכרייה מותאם אחת ל-2016 בלוקים כדי לייצב את הקצב הממוצע, אך ההתאמה הזו פועלת על פני שבועיים ואינה מרככת תנודות קצרות.
גורמים נוספים שמשפיעים על נפח המאגר: גלי עסקאות מרוכזות מגורמים גדולים שמעבירים כמויות רבות בבת אחת, שימושים שמכניסים כמויות נתונים גדולות דרך נתוני החתימה ובכך תופסים משקל רב, ומחזוריות יומית ושבועית שנובעת מפעילות אנושית. מה שמשותף לכל אלה הוא שאין בהם קביעות: תעריף שהספיק אתמול אינו בהכרח מספיק היום, וזו בדיוק הסיבה שאין טעם לצטט מספר עמלה קבוע.
תעריף sat/vB ובחירת עדיפות
סאטושי הוא היחידה הקטנה ביותר במערכת: 100,000,000 סאטושי במטבע אחד. התעריף נמדד בסאטושי לכל בית וירטואלי, והעמלה הסופית היא מכפלה פשוטה – עמלה = vsize × תעריף. לצורך הדגמה בלבד: עסקה של 141 vB בתעריף של 20 sat/vB תשלם 2,820 סאטושי, ואותה עסקה בדיוק בתעריף של 4 sat/vB תשלם 564 סאטושי. הסכום המועבר אינו נכנס לחישוב הזה בשום שלב.
איך ארנקים מציעים "מהיר", "רגיל" ו"איטי"
שלוש הרמות שמופיעות בממשקי ארנקים הן הערכה סטטיסטית ולא התחייבות. נהוגות שתי גישות. הראשונה היא הערכה היסטורית, שבודקת איזה תעריף הספיק בפועל כדי להתאשר בתוך מספר בלוקים נתון בעבר הקרוב – זו הגישה של הפונקציה estimatesmartfee בתוכנת הצומת. השנייה היא הערכה מבוססת מצב, שסורקת את תוכן ה-Mempool ברגע זה ומחשבת היכן ייפול קו החיתוך אם הבלוקים הבאים ייבנו מהעסקאות הממתינות כרגע. הגישה הראשונה שמרנית ומגיבה לאט לשינויים; השנייה מגיבה מהר אך אינה יודעת דבר על עסקאות שיגיעו בדקות הקרובות.
שתי מגבלות מעשיות תוחמות את הבחירה מלמטה. תעריף נמוך מרצפת ההעברה כלל לא יופץ ברשת, כך שהעסקה לא תגיע לכורים מלכתחילה. בנוסף, פלט שערכו נמוך מסף האבק (dust) נחשב לא תקני ולא יועבר: 546 סאטושי בפלט P2PKH, 294 בפלט P2WPKH ו-330 בפלט P2TR. הסף נגזר מהעלות הצפויה של הוצאת אותו פלט בעתיד, ולכן הוא נמוך יותר במבנים קלים יותר.
מחשבון עמלה: sat/vB מול גודל העסקה
העמלה נגזרת ממשקל העסקה בבתים וירטואליים (vB) כפול התעריף שנבחר בסאטושי לבית. מבנה הכתובת משנה את המשקל:
| סוג עסקה (קלט אחד, שני פלטים) | משקל משוער | ב-10 sat/vB | ב-50 sat/vB |
|---|---|---|---|
| Legacy (P2PKH) | ~226 vB | 2,260 סאטושי | 11,300 סאטושי |
| SegWit (P2WPKH) | ~141 vB | 1,410 סאטושי | 7,050 סאטושי |
| Taproot (P2TR) | ~154 vB | 1,540 סאטושי | 7,700 סאטושי |
לטאפרוט הקלט הקל ביותר (~57.5 vB מול ~68 vB ב-SegWit), אך הפלט שלו כבד יותר (~43 vB מול ~31 vB). לכן היתרון שלו גדל ככל שהעסקה מאגדת יותר קלטים.
העמלה אינה תלויה בסכום המועבר אלא במקום שהעסקה תופסת בבלוק.
המחשבון מדגים חישוב טכני בלבד, אינו מציג תעריפים חיים ואינו המלצה לפעולה.
איך מבנה הכתובת משנה את המשקל
המשקל של עסקה נקבע כמעט לחלוטין מהרכיבים שלה: כמה קלטים, כמה פלטים ומאיזה סוג. סוג הכתובת ביטקוין קובע כמה בתים תופס כל רכיב, וההפרשים בין המבנים אינם זניחים. הטבלה הבאה מפרקת את החישוב לרכיביו, וממנה אפשר להרכיב כל צירוף.
| רכיב | Legacy (P2PKH) | SegWit עטוף (P2SH-P2WPKH) | SegWit מקורי (P2WPKH) | Taproot (P2TR, מסלול מפתח) |
|---|---|---|---|---|
| קלט בודד | 148 vB | כ-91 vB | כ-68 vB | כ-57.5 vB |
| פלט בודד | 34 vB | 32 vB | 31 vB | 43 vB |
| תקורה קבועה לעסקה | 10 vB | 10.5 vB | 10.5 vB | 10.5 vB |
| קידומת הכתובת | הספרה 1 | הספרה 3 | bc1q | bc1p |
| נתוני חתימה בהנחה | אין | יש | יש | יש |
הנתונים מניחים חתימה באורך 72 בתים ומספר קלטים ופלטים קטן מ-253, מצב שבו מוני הרכיבים תופסים בית אחד בלבד. מספרים "טיפוסיים" שמופיעים בטבלאות השוואה מתייחסים תמיד להרכב מסוים של קלטים ופלטים, ולכן פירוק לרכיבים מדויק יותר מכל מספר יחיד. חתימה באורך 71 בתים, שכיחה אף היא, מורידה כמחצית בית וירטואלי מכל קלט.
קלטים כבדים יותר מפלטים
ההבדל המרכזי שמסביר את רוב ההפרשים בפועל: כל קלט נוסף מוסיף עשרות בתים וירטואליים, ואילו כל פלט נוסף מוסיף כשלושים בלבד. הסיבה היא שקלט נושא הפניה לעסקה קודמת באורך 36 בתים ובנוסף חתימה ומפתח ציבורי, בעוד פלט נושא רק סכום וסקריפט נעילה קצר. מכאן שעסקה שמאחדת עשרה קלטים קטנים כבדה בהרבה מעסקה שמפצלת סכום לעשרה פלטים. מי שמחזיק יחידות UTXO רבות וקטנות ישלם משקל גבוה יותר בכל העברה עתידית, ללא קשר לתעריף שיבחר.
נקודה שנוטים לבלבל בין חלקיה: פלט Taproot כבד מפלט SegWit מקורי – 43 בתים וירטואליים לעומת 31 – אך קלט Taproot במסלול המפתח הוא הקל מכל המבנים. כלומר החיסכון במשקל אינו מתממש ברגע קבלת היחידה אלא ברגע הוצאתה. השוואה נכונה בין מבנים חייבת אפוא להביט על מחזור החיים המלא של היחידה, ולא על צד אחד שלו.
איחוד קלטים ואיגוד פלטים
שני דפוסים נפוצים משנים את המשקל באופן מהותי. הראשון הוא איחוד (consolidation): מיזוג של יחידות קטנות רבות ליחידה אחת גדולה בעסקה אחת. הפעולה משלמת משקל גבוה פעם אחת, ובתמורה מקטינה את מספר הקלטים בכל העברה שתבוא אחריה. הדפוס השני הוא איגוד (batching): גוף ששולח תשלומים רבים מרכז אותם לעסקה אחת עם פלטים רבים, ובכך משלם תקורה קבועה אחת במקום עשרות תקורות נפרדות. שתי הפעולות אינן משנות את התעריף כלל – הן משנות את מספר הבתים הווירטואליים שעליהם משלמים.
RBF ו-CPFP: שינוי עדיפות אחרי השידור
עסקה ששודרה בתעריף נמוך מדי אינה נעולה במקומה. אין בפרוטוקול מושג של "ביטול" עסקה משודרת, אך שני מנגנונים מאפשרים לשנות בפועל את מיקומה בסדר העדיפויות. שניהם פועלים בשכבת המדיניות של הצמתים, לא בשכבת הקונצנזוס.
RBF – החלפה בתשלום גבוה יותר
Replace-by-Fee מאפשר לשדר גרסה חדשה של אותה עסקה, שמשתמשת באותם קלטים אך משלמת תעריף גבוה יותר. מכיוון ששתי הגרסאות מוציאות את אותן יחידות בדיוק, רק אחת מהן יכולה להיכלל בבלוק, והכפילות נפתרת מאליה ברגע האישור. באופן היסטורי האיתות על נכונות להחלפה נעשה בשדה nSequence: ערך קטן מ-0xfffffffe בקלט אחד לפחות סימן שהעסקה ניתנת להחלפה, לפי BIP125. בגרסאות מאוחרות יותר של תוכנת הצומת המקובלת שונתה ברירת המחדל להחלפה מלאה, שאינה תלויה כלל באיתות מוקדם, ולכן היעדר איתות אינו ערובה לסופיות.
כללי ההחלפה המרכזיים: הגרסה החדשה חייבת לשלם עמלה מוחלטת גבוהה מסכום העמלות של כל העסקאות שהיא מחליפה, ובנוסף לכסות את עלות התעבורה של עצמה לפי incrementalrelayfee; אסור לה להוסיף קלטים שטרם אושרו ולא הופיעו בגרסה הקודמת; ואין באפשרותה לדחוק יותר ממאה עסקאות. מגבלה מעשית חשובה: ההחלפה מבוצעת רק בארנק ששולט במפתחות של הקלטים. מקבל התשלום אינו יכול להפעיל RBF על עסקה נכנסת.
CPFP – ילד משלם עבור הורה
Child Pays For Parent פועל מהכיוון ההפוך. במקום להחליף את העסקה התקועה, מוציאים אחד מפלטיה שטרם אושרו בעסקה חדשה שמשלמת תעריף גבוה במיוחד. מנגנון בחירת העסקאות מודד תעריף של חבילה שלמה (ancestor feerate) ולא של עסקה בודדת, ולכן כלילת עסקת הילד מחייבת את הכורה לכלול גם את ההורה. המשקל של השתיים מחושב יחד, ומכאן שהילד נדרש לשאת את החוסר של ההורה בנוסף למשקל של עצמו – ככל שההורה כבד יותר, כך התעריף שהילד צריך לשלם גבוה יותר.
היתרון המרכזי של CPFP הוא זמינותו גם למקבל התשלום, שאין לו שליטה על העסקה המקורית. מגבלות המדיניות רלוונטיות כאן: ברירת המחדל מגבילה שרשרת של 25 עסקאות אב ו-101 קילו-vB, ומגבלה מקבילה חלה בכיוון הצאצאים. מנגנון קרוב, פלטי עוגן (anchor outputs), משמש ערוצי תשלום ברשת לייטנינג נטוורק, שבהם עסקת הסגירה נחתמת מראש בזמן שבו התעריף העתידי אינו ידוע, והתאמת התעריף נעשית רק ברגע הפרסום באמצעות עסקת ילד.
| היבט | RBF | CPFP |
|---|---|---|
| מי יכול להפעיל | השולח בלבד, מחזיק המפתחות של הקלטים | כל מי שאוחז בפלט שטרם אושר, כולל המקבל |
| גורל העסקה המקורית | מוחלפת ונעלמת מהמאגר | נשארת ומתאשרת יחד עם הילד |
| תוספת משקל לרשת | אין – עסקה אחת מחליפה אחרת | יש – משקל עסקת הילד נוסף לחשבון |
| תנאי מקדים | מדיניות ההחלפה של הצמתים המעבירים | פלט זמין להוצאה בעסקה התקועה |
| מגבלה מרכזית | עמלה מוחלטת גבוהה יותר וכיסוי עלות התעבורה | שרשרת של עד 25 עסקאות ו-101 קילו-vB |
שאלות נפוצות
מה קורה לעסקה שנשארת ב-Mempool ואינה נכנסת לבלוק?
היא ממתינה, ולא מתרחש שום שינוי ביתרות. היחידות שהעסקה מוציאה נותרות שייכות לשולח עד לאישור בבלוק. אם התעריף נמוך מדי לאורך זמן, הצמתים ידחו אותה מהמאגר בבוא העת: בברירת המחדל לאחר 336 שעות, או מוקדם יותר אם המאגר מתמלא וסף הכניסה הדינמי עולה מעל התעריף שלה. לאחר מכן אפשר לשדר את אותן יחידות בעסקה חדשה. כל עוד היא נמצאת במאגר, הדרכים לזרז אותה הן RBF או CPFP.
האם תעריף גבוה מבטיח אישור בבלוק הבא?
לא. תעריף גבוה ממקם את העסקה גבוה בסדר העדיפויות של כורים שמשתמשים בהרכבה הסטנדרטית, וזה כל מה שהוא עושה. עדיין ייתכן שהבלוק הבא ייבנה על ידי גורם שמיישם מדיניות שונה, שהבלוק יימצא רק לאחר זמן ארוך מהממוצע, או שגל של עסקאות בתעריף גבוה עוד יותר ייכנס למאגר בינתיים. התעריף משפיע על מיקום בתור, לא על עיתוי מציאת הבלוק, שהוא הסתברותי מטבעו.
האם סכום ההעברה משפיע על גובה העמלה?
לא באופן ישיר. העמלה תלויה במשקל העסקה בלבד. העברה של סכום גדול מאוד שמורכבת מקלט יחיד יכולה להיות זולה יותר מהעברה של סכום זעום שמורכבת מעשרים קלטים קטנים. הקשר העקיף היחיד הוא שסכומים גדולים מורכבים לעיתים ממספר רב של יחידות UTXO, וכל יחידה כזו מוסיפה קלט ולכן מוסיפה משקל.
מה ההבדל בין sat/vB לבין sat/byte?
בעסקאות Legacy, שאין בהן נתוני witness כלל, שתי המידות זהות. בעסקאות SegWit ו-Taproot הן נבדלות: המונה sat/vB מתבסס על המשקל חלקי ארבע ולכן כבר מגלם את ההנחה שניתנת לנתוני החתימה, בעוד ספירת בתים גולמיים תיתן מספר בתים גדול יותר ותעריף אפקטיבי נמוך יותר לאותה עמלה. כלי ניטור ורוב הארנקים מציגים היום sat/vB, וזו גם היחידה שבה נמדדים סף ההעברה המינימלי וסף הכניסה הדינמי למאגר.
החומר בעמוד זה הסברי-טכני בלבד, ונועד להבהיר את אופן פעולתו של מנגנון העמלות ברשת הביטקוין. אין בו הנחיה מעשית, והוא אינו המלצה לפעולה מכל סוג.
להרחבה בנושאים קרובים: מדריך ביטקוין המלא · לייטנינג נטוורק · כריית ביטקוין · כתובת ביטקוין
