API לבלוקצ׳יין: קריאה, סימולציה ועסקה חתומה

פורסם 06/05/2026 · עודכן 31/10/2026 · ממשקי API ואינטגרציות · 4 דקות קריאה · מאת Cyber Intelligence Embassy

בקצרה

API מספק גישה לצומת או לשירות עם מגבלות ותלויות משלו. ב־Ethereum שאילתה או הדמיית מצב שונות מפרסום עסקה. הדוגמאות מתארות Ethereum, לא כל בלוקצ׳יין.

במאמר זה

לקריאה ולשליחה יש תוצאות שונות

ב־Ethereum, eth_call מבצע קריאה בלי ליצור עסקה בשרשרת; ספק RPC עדיין עשוי לגבות תשלום שירות. eth_sendRawTransaction מגיש עסקה חתומה מראש. קבלת מזהה אינה מוכיחה הכללה או הצלחה. יש לבדוק קבלה, סטטוס, בלוק וסופיות מתאימה לרשת.

שליטה בתלויות ובשגיאות

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

בקרות להגדרה

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

מקורות

בדיקה עריכתית: 31 באוקטובר 2026.

הפרדת עסקאות שהוגשו, נכללו ופורשו.

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

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

האם גיבוב שהוחזר פירושו שהפעולה הסתיימה?

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

מקור ראשוני: Ethereum — JSON-RPC and transaction receipts. שיטה קשורה: קריאת המדריך המעשי.

מכסות ומגבלות API

המגבלות משפיעות על קיבולת, ניסיונות וחלוקה בין לקוחות.

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

מקרה קבלה שניתן לשחזר

דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.

הצגת נתוני המקרה

{
    "http_status": 429,
    "retry_after_seconds": 30,
    "workers": 20,
    "retry_budget": 3,
    "retry_budget_scope": "per_worker_retries_excluding_initial_request",
    "scheduling_example": {
        "response_received_at_seconds": 0,
        "illustrative_retry_seconds": [
            30,
            31,
            32,
            33,
            34
        ],
        "workers_per_second": 4,
        "alternative_deadline_seconds": 25,
        "total_attempts_if_all_retries_used": 80
    }
}

החלטה צפויה

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

עשרים לקוחות: לפזר ולספור ניסיונות

דוגמה בדויה: 20 עובדים מקבלים בזמן +0 s תגובת 429 עם Retry-After: 30. הזמנים מציגים פיזור אפשרי ואינם מבטיחים קיבולת שרת. לכל עובד 3 ניסיונות חוזרים בנוסף לבקשה הראשונה.

מדיניות	חישוב או תזמון	השפעה
ניסיון חוזר בו־זמני	20 × 1 = 20 @ +30 s	המתנה של 30 שניות מכבדת את ההשהיה, אך כל 20 הבקשות חוזרות יחד והעומס עלול לחזור.
ניסיון חוזר מפוזר	4 × 5 = 20 @ +30…+34 s	ארבע בקשות בשנייה במשך חמש שניות מפזרות 20 ניסיונות בלי להפחית את מספרם. לוח הזמנים להמחשה אינו מחליף מדיניות השהיה גדלה עם שונות אקראית.
מועד סיום אחרי 25 שניות	25 s < 30 s → 0	אם הזמן שנותר קצר מ־30 השניות הנדרשות, עצרו או דחו בהתאם לחוזה. אל תקצרו את ההמתנה כדי לעמוד במועד.
תקציב מרבי	20 × (1 + 3) = 80	ניצול כל הניסיונות נותן 20 בקשות ראשונות ועוד 60 חזרות: 80 בקשות. התקרה אינה מבטיחה הצלחה או חזרה בטוחה.

נוהל בדיקה

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

AWS — Timeouts, retries, and backoff with jitter

האם 429 מוכיח שכתיבה קודמת לא בוצעה?

לא. הפעולה ללא תשובה דורשת התאמה נפרדת; תשובה לניסיון אחר אינה מוכיחה את מצבה.

מקור ראשוני: IETF — RFC 6585, HTTP 429. שיטה קשורה: קריאת המדריך המעשי.

API: למנוע ניסיונות מוכפלים בין שכבות

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

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

האם שלושה ניסיונות לשכבה הם שלושה בסך הכול?

לא. ארבע שכבות בדיוניות עם שלושה ניסיונות כוללים נותנות עד 3⁴ = 81 קריאות אחרונות.

האם פקיעת משימה מבטלת השפעה מרוחקת?

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

מקור ראשוני: AWS — Timeouts, retries, and backoff with jitter. שיטה קשורה: קריאת המדריך המעשי.