Sebastien Rousseau
צרו קשר ›

The making of the Express Transaction Credits Platform

ארכיטקטורת טוקן, תשלומים מרובי-חתימה והעברות נעולות בזמן על Ethereum ב-2018.

7 דקות קריאה
Banner for: The making of the Express Transaction Credits Platform

Giant white pillars.class="img-fluid clearfix"

סיכום מנהלים / תובנות עיקריות

  • הבעיה הבסיסית. ל-ERC-20, תקן הטוקן הדומיננטי של Ethereum ב-2018, היה פגם מבני: טוקנים שהועברו ישירות לכתובת חוזה חכם נהרסו בשקט אם לחוזה לא היה מטפל. כל פלטפורמת תשלומים שנבנתה על ERC-20 ירשה סיכון זה (Ethereum EIPs).
  • ERC-223 כפתרון. ERC-223 חייב חוזי נמענים ליישם פונקציית tokenFallback(address, uint, bytes). אם נעדרה, העסקה חזרה באופן אטומי. שום טוקן לא יכול היה ללכת לאיבוד בשקט (Ethereum EIPs GitHub).
  • חמשת פרימיטיבי החוזה של EXTC. זהות הטוקן (name, symbol, דיוק של 18 ספרות עשרוניות), היצע קבוע, העברה תואמת ERC-223, הסברה תאגידית רב-חתימות והוראות קבע נעולות בגובה בלוק.
  • מנגנון הלוואת הביטחונות. לווים נעלו טוקני EXTC ב-escrow של חוזה; החוזה שחרר את תמורת ההלוואה באופן אטומי עם קבלת הביטחונות, ללא עיכוב חיתום או אישור ועדת אשראי.
  • מה שהניסוי חשף על מגבלות Ethereum. בתפוקת mainnet של ~15 TPS ועלויות גז של $0.10–$1.00 לעסקה בשיא ינואר 2018, רשת תשלומים המעבדת אפילו נפח בקנה מידה של העברות לא הייתה ישימה כלכלית וטכנית על Ethereum הציבורי ללא תשתית Layer-2.

בעיית העיצוב: מדוע ERC-20 לא היה מספיק #

תקן ERC-20, שהוצע ב-2015 ופורמל בהצעת שיפור Ethereum 20, הגדיר את ממשק טוקן הפונגיבלי הקנוני שהפעיל את בום ה-ICO של 2017–2018. שש הפונקציות המרכזיות שלו — totalSupply, balanceOf, transfer, transferFrom, approve ו-allowance — היו מספיקות להנפקה ולמסחר פשוטים בטוקנים.

עם זאת, עבור פלטפורמת תשלומים, ל-ERC-20 היה פגם קריטי לייצור. הפונקציה transfer(address _to, uint256 _value) העבירה טוקנים לכל כתובת, כולל כתובות חוזים, מבלי להפעיל שום קוד בחוזה המקבל. לחוזה שלא תוכנת במיוחד לעקוב אחר העברות ERC-20 נכנסות לא הייתה דרך לזהות אותן. טוקנים שנשלחו כך נלכדו לצמיתות, ללא מנגנון לשחזור.

קהילת Ethereum העריכה שעשרות מיליוני דולרים בטוקני ERC-20 אבדו לצמיתות עד אמצע 2018 דרך מנגנון זה. בניית פלטפורמת תשלומים שבה העברות יכולות להיכשל בשקט ולהשמיד כספי משתמשים לא הייתה קבילה.

פתרון ERC-223: העברה אטומית עם הודעה #

ERC-223, שהוצע במעקב הבעיות של GitHub של Ethereum EIPs, התמודד עם בעיית האובדן השקט על ידי שינוי מה שנדרשת העברת טוקן לעשות. תחת ERC-223, transfer(address _to, uint256 _value, bytes _data) בדק אם כתובת הנמען מכילה קוד חוזה. אם כן, ההעברה קראה ל-_to.tokenFallback(address _from, uint256 _value, bytes _data).

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

עבור EXTC, פירוש הדבר היה:

ארכיטקטורת חוזה EXTC #

חוזה טוקן EXTC היה יישום Solidity המובנה סביב חמישה מודולים:

1. זהות הטוקן #

string public name = "Express Transaction Credits";
string public symbol = "EXTC";
uint8 public decimals = 18;

שמונה עשרה ספרות עשרוניות נתנו ל-EXTC דיוק תת-סנטי, התואם את הדרישות לשימושי מיקרו-תשלום ומיקרו-הלוואה. הסמל EXTC היה המזהה on-chain הרשום בחוזה הטוקן.

2. היצע כולל קבוע #

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

3. יתרה והעברה תואמות ERC-223 #

פונקציית ההעברה המרכזית יישמה את ממשק ERC-223 המלא. מיפויי יתרה פנימיים עקבו אחר אחזקות כל כתובת. העוזר isContract(address) הבדיל בין כתובות EOA (חשבון בבעלות חיצונית) לכתובות חוזים כדי לקבוע אם יש לקרוא ל-tokenFallback.

4. הסברות תאגידיות רב-חתימות #

זרימות עבודה של תשלומים תאגידיים דרשו אישור משותף: אף חתם יחיד לא יכול היה לבד ליזום הסברה מעל סף מוגדר. חוזה EXTC יישם סכמת רב-חתימות של שניים מתוך N:

  1. יוזם מיועד הציע העברה, תוך ציון מקבל, סכום ו-nonce.
  2. חתם-משנה אישר את ה-nonce.
  3. ההעברה בוצעה רק לאחר שתי החתימות נרשמו on-chain.

זה ביטל את סיכון נקודת הכשל הבודדת עבור חשבונות תאגידיים תוך שמירה על כל זרימת ההרשאה on-chain וניתנת לביקורת ללא מתווך של בית סליקה.

5. הוראות קבע נעולות בגובה בלוק #

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

גובה הבלוק כפרוקסי זמן היה בחירה פרגמטית ב-2018. Ethereum כוון למרווח בלוק של 15 שניות, מה שהפך את גובה הבלוק לפרוקסי מהימן סביר לשעון קיר בטווח של דקות. חותמות זמן מוחלטות (block.timestamp) היו זמינות אך רגישות למניפולציות כורים בחלון של ±900 שניות, מה שהפך את גובה הבלוק להפניה הבטוחה יותר לחוזים פיננסיים.

מנגנון ההלוואה המיידית הגובה בביטחונות #

פרימיטיב ההלוואות של EXTC היה הרכיב המורכב ביותר. העיצוב:

  1. הלווה נועל ביטחונות. הלווה קרא ל-lockCollateral(uint256 _collateralAmount), והעביר טוקני EXTC ל-escrow של חוזה ההלוואות דרך ERC-223 tokenFallback.
  2. בדיקת יחס הלוואה לערך. החוזה קרא יחס LTV שהוגדר מראש (למשל 50%) וחישב את סכום ההלוואה המקסימלי כנגד הביטחונות הנעולים.
  3. הסברת הלוואה אטומית. אם הביטחונות עמדו בסף המינימום, החוזה העביר מיד את סכום ההלוואה לכתובת הלווה. ללא תור חיתום, ללא ועדת אשראי, ללא עיכוב הסדר.
  4. החזר ושחרור. בהחזר — קרן בתוספת ריבית קבועה — החוזה שחרר את הביטחונות חזרה ללווה. אי-החזר עד ל-releaseBlock הפעיל פירוק אוטומטי: החוזה העביר את הביטחונות לכתובת המיועדת של המלווה.

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

מה הניסוי חשף #

ארכיטקטורת חוזה EXTC הייתה קוהרנטית מבחינה טכנית. ERC-223 פתר את פגם הבטיחות החמור ביותר של ERC-20. פרימיטיבי רב-החתימות ונעילת הזמן מפו ישירות לזרימות עבודה אמיתיות של תשלומים תאגידיים. מנגנון הלוואת הביטחונות הדגים שהלוואות מאובטחות יכולות להיות מאוטמטות לחלוטין ואוכפות עצמן on-chain.

שני אילוצים התגלו בפועל:

עלויות גז. בשיא ינואר 2018, מחירי הגז של Ethereum הגיעו ל-50–100 gwei, מה שהפך העברת טוקן ERC-223 בודדת לעלות $0.50–$2.00. עבור מיקרו-תשלומים או העברות של $10–$50, העמלות הללו היו מאסרות.

תפוקה. מגבלת גז הבלוק של Ethereum mainnet בתחילת 2018 הייתה כ-8 מיליון גז. העברת ERC-223 צרכה כ-50,000–80,000 גז. הרשת יכלה אפוא לעבד כ-100–160 העברות טוקן EXTC לבלוק, או כ-7–11 לשנייה במרווח הבלוק של 15 שניות. קנה מידה של רשת תשלומים — מאות או אלפי עסקאות לשנייה — לא היה ניתן להשגה על Ethereum הציבורי ללא תשתית Layer-2 שעדיין לא הייתה קיימת בצורה פרודוקטיבית.

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

הרעיונות שהגיעו לייצור #

כמה דפוסי עיצוב מ-EXTC אומתו על ידי פיתוח מאוחר יותר:

העברת טוקן אטומית עם הודעה למקבל — המאפיין המרכזי של ERC-223 — הפכה לבסיס ל-ERC-777 (2019), שהרחיב את מודל ההודעות ואוחר שולב בפרוטוקולי הלוואות DeFi. דפוס tokenFallback מופיע לאורך כל ארכיטקטורת DeFi המודרנית.

הרשאה רב-חתימות להסברות תאגידיות — הדפוס של דרישת מספר חתימות on-chain לפני ביצוע — הפך למודל הסטנדרטי לניהול אוצר DAO ופתרונות משמורת מוסדיים. Gnosis Safe, שהושק ב-2018, הפופולרי דפוס זה בקנה מידה.

הלוואות מיידיות גובות ביטחונות ללא מתווכים — המנגנון של נעילת ביטחונות ב-escrow ושחרור תמורות ההלוואה באופן אטומי — הוא העיצוב הבסיסי של פרוטוקולי הלוואות DeFi כגון Compound (2018) ו-Aave (2020).

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

הניסוי EXTC לא הגיע לקנה מידה ייצורי. התשתית הדרושה כדי להפוך את העיצוב לחיוני לקחה עוד שלוש עד חמש שנים להבשיל. שאלות העיצוב שהוא שאל היו הנכונות ל-2018.

שאלות נפוצות #

מדוע ERC-223 אף פעם לא אומץ כתקן הטוקן הדומיננטי למרות תיקון פגם ERC-20?

ERC-223 דרש מחוזי נמענים ליישם tokenFallback, תוך שבירת תאימות לאחור עם אלפי החוזים שכבר נפרסו עבור טוקני ERC-20. מערכת האקולוגית הקיימת של ERC-20 הייתה גדולה מדי להגירה. הצעות מאוחרות — בולטות ERC-777 ו-ERC-1363 — התמודדו עם אותה הבעיה עם פשרות תאימות שונות, אך ERC-20 נשאר דומיננטי דרך שילוב של אפקטי רשת והכנסת דפוסי טוקן עטוף שהימנעו מתרחיש האובדן השקט.

מה קרה לטוקן ולפלטפורמת EXTC?

EXTC היה הוכחת קונספט ופרויקט מחקר מוקדם מ-2018. שוק ה-ICO הרחב יותר ושוק טוקני התשלום התכווצו בחדות במהלך 2018–2019 כשמגבלות הסקיילביליות של Ethereum ואי-הוודאות הרגולטורית הפכו ברורות. הרעיונות המוטמעים בעיצוב EXTC הופיעו מחדש בפרוטוקולים מאוחרים יותר שהיה להם גישה לתשתית Layer-2, כלים טובים יותר ומסגרות רגולטוריות ברורות יותר.

כיצד מודל הלוואת הביטחונות של EXTC משווה לפרוטוקולי DeFi מודרניים כמו Aave?

המנגנון המרכזי זהה: נעל ביטחונות, קבל הלוואה בגודל לפי יחס LTV, החזר או עמוד בפני פירוק. ההבדלים הם: (1) פרוטוקולי DeFi מודרניים משתמשים בהזנות מחיר oracle ל-LTV דינמי במקום יחסים קבועים; (2) הם משתמשים בריבית אלגוריתמית המגיבה לניצול המאגר; (3) הם פועלים ברשתות Layer-2 עם עלויות גז נמוכות פי 10–100 מ-mainnet 2018; (4) Aave ו-Compound עברו ביקורות אבטחה פורמליות והחזיקו מיליארדי דולרים בנזילות, ומספקים אימות אמפירי שהמודל הבסיסי תקין.

מהן היו מגבלות גרסת Solidity בתחילת 2018?

חוזה EXTC נכתב עבור Solidity 0.4.x, הגרסה הדומיננטית בתחילת 2018. Solidity 0.4 חסר מאפייני בטיחות רבים שהוצגו בגרסאות מאוחרות יותר: בדיקת הצפת מספרים שלמים (נוספה אוטומטית ב-0.8.0), require/revert עם הודעות שגיאה (מוגבל ב-0.4) וחשיפת פונקציה מפורשת (ברירת המחדל הייתה public ב-0.4). החוזה הסתמך על ספריית SafeMath של OpenZeppelin להגנה מפני הצפה — דפוס נפוץ לפני שהמהדר אכף זאת באופן מקורי.

הפניות #

נסקר לאחרונה .

נסקר לאחרונה .