1. Issues with Blockchain Data Indexing Solutions

Blockchain, from a technical standpoint, can be viewed as a decentralized database. In pursuit of decentralization, blockchain databases support only fundamental functionalities based on key-based read and write operations. These limitations lead to inconveniences for both blockchain-based dApps and users. One of the causes of this inconvenience lies in the indexing method used in blockchain databases. Indexing involves optimizing data within a database into structured forms, allowing for swift retrieval of requested information. Most databases used in Web2 environments support various indexing structures, making it easy to fetch the necessary data and present it to users. In contrast, blockchain databases only store transaction data and contract state and do not efficiently provide the information required by dApps. As a result, dApp developers often face the cumbersome task of further processing blockchain data to meet their needs. Let's illustrate this issue with an example.

1. 1. Example: How is Liquidity Information in Uniswap V3 Handled?

Consider a user who wants to supply liquidity to Uniswap V3. One critical factor they need to consider is the size of the liquidity pool they intend to contribute to. If a pool has low liquidity, there will be fewer swaps in that pool, resulting in lower fee earnings. Uniswap currently provides liquidity information for each pool on its website. However, the blockchain database does not offer direct indexing for this information. So, how does Uniswap retrieve and process this data?

Liquidity pools in Uniswap V3 are in a concentrated liquidity form. To determine the total liquidity, one must aggregate liquidity information available in small segments based on price. However, Uniswap does not track the entire liquidity of a pool within its contract. The "liquidity" function in the code snippet below refers to the liquidity existing around the current price tick, making it impossible to obtain complete liquidity information using this data.

Two possible solutions come to mind. First, record the total liquidity information of each pool in a separate database and update it whenever swaps, liquidity provisions, or withdrawals occur. However, this approach involves tracking a vast amount of liquidity pool data in the backend, incurring significant costs. Second, use centralized third-party solutions that provide blockchain data. While these solutions are fast and cost-effective, they come with the drawback of relying on third parties, which may compromise data accuracy and face potential disruptions due to single points of failure. In summary, the required data in Uniswap is not directly indexed in the blockchain database, necessitating additional off-chain indexing processes. However, the approaches mentioned earlier both present challenges, including "high cost" and "single-point-of-failure issues."

1. 2. The Graph's Mechanism

The Graph emerges as a solution to these issues, providing a blockchain data service that ensures accurate and secure data retrieval through a decentralized network. The Graph establishes an open data marketplace for blockchains, featuring subgraphs that define what data to index and indexers that process and store blockchain data on-demand. Let's delve into how The Graph works through the example of Uniswap V3.

Uniswap creates a subgraph to track liquidity information within V3 pools. A subgraph acts as a "code snippet" that collects and processes event information occurring within blockchain smart contracts. The following steps illustrate how liquidity information in a pool is tracked:

1. Reading events generated during pool creation and adding information to the database.
2. Capturing specified events and updating pool information when they occur. For instance, when 10 ETH is added to pool A, the liquidity of pool A increases by 10 ETH.
3. Providing organized information from the database through API endpoints.

Uniswap requests indexing for this subgraph. Indexers then start the process of collecting and processing liquidity information according to the instructions in the subgraph. Indexers store this information in a separate database and create endpoints for data retrieval. Once this process continues until the current block, and indexing is completed, Uniswap can receive information through the API provided by the indexer for the subgraph. Additionally, the indexer can receive GRT fees each time Uniswap sends a query, in addition to the GRT rewards provided through protocol inflation.

1. 3. Issues Arising from Centralized Data Platforms

If you read this far, The Graph might look similar to that of a typical third-party data platform. Therefore, certain concerns may arise:

Can data accuracy be guaranteed? If indexers were to provide incorrect data or if indexer performance were subpar, dApps relying on those indexers could suffer losses. Therefore, with centralized data providers, dApps must place their trust in the provider.

Can useful subgraphs be incentivized? Conversely, indexers must also trust dApps. Indexers usually follow block events from a few years back to create databases for subgraphs, a resource-intensive task. If a dApp were to write useless subgraphs, indexers would waste computing resources without gaining any query volume. This situation, if prolonged, could render indexers incapable of performing their tasks.

The Graph addresses these trust-related issues through specific mechanisms.

2. Ensuring Fast and Secure Data Retrieval: The Graph's Approach

2. 1. GRT Utility and Participants

The Graph operates its protocol centered around GRT, a utility token compliant with the ERC-20 standard, which serves the following functions:

1. Staking: Indexers stake GRT to provide indexing and query services.
2. Delegation: Delegators allocate their GRT to existing Indexers to earn a portion of the query fees and indexing rewards.
3. Payment: Consumers (developers) pay GRT to Indexers, Curators, and Delegators for subgraph queries.
4. Reward: Indexers and Delegators receive indexing rewards in GRT.

Ecosystem participants revolve around GRT, which holds the aforementioned utilities, with each participant playing distinct roles as follows:

Developer: Participants who act as consumers within The Graph network. They create and deploy subgraphs to The Graph network, requesting indexing.

הם משתמשים בנתונים המעובדים מרשת The Graph ומשלמים עבורם באמצעות GRT.

אינדקסאים: אינדקסאים הם מפעילי צמתים ברשת The Graph, המספקים שירותי אינדקס ועיבוד שאילתות. כדי להפוך לאינדקסאי, יש להמר כמות מסוימת של GRT (נכון לעת 100,000), והאינדקסאים בוחרים תת-גרפים לאינדקס על סמך אותות האוצרים.

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

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

בתוך רשת The Graph, ל-GRT יש תפקיד ביצירת אותות לבחירת תת-גרפים טובים ואינדקסאים מצטיינים, בעוד שההכנסות והערך המוסף שנוצר מהם מחולקים כפרסי GRT למשתתפי המערכת האקולוגית. שוק הנתונים המבוזר שנוצר על ידי The Graph מעכל את דרישות האינדוקס של נתונים של dApps ואחרים, כאשר העלויות גם כן מחויבות ב-GRT. כך, רשת The Graph מספקת שירותי אינדוקס נתונים בטוחים ואיכותיים סביב הכלכלת האסימונים של GRT. אבחן עוד את התפקידים והפונקציות של אינדקסאים, אוצרים ומוסדים, משתתפי הרשת, כדי לצבור הבנה מפורטת של מנגנון הרשת.

2. 2. אינדקסאים

כפי שצוין קודם לכן, אינדקסאי ברשת The Graph הוא מפעיל צומת שבוחר ומאנדקס תת-גרפים על סמך אותות מאוצרים. כעת, יש להמר מינימום של 100,000 GRT כדי לפעול כאינדקסאי, והימור זה משמש כסוג של פיקדון, אשר עלול להיחתך אם האינדקסאי פועל בזדון. אינדקסאים מקבלים תגמולים על אינדוקס בצורה של כ-3% מהאינפלציה של הפרוטוקול (2023: 2. 7%) ועמלות GRT עבור השאילתות שהם מעבדים. כדי לקבל את האינפלציה של הפרוטוקול, אינדקסאים מייצרים הוכחת אינדוקס (POI) כראיה שהם מאנדקסים כראוי. כדי למנוע מאינדקסאים לייצר POI למרות שהם מחזירים נתונים שגויים או שאינם מאנדקסים, The Graph מיישמת מערכת סכסוכים. כל אחד ברשת יכול לערער על הנתונים שהוחזרו על ידי אינדקסאי עבור שאילתה בתוך 7 עידנים (7 ימים) וה-POI של האינדקסאי בתוך 28 עידנים (28 ימים). האדם היוזם את הסכסוך מכונה "דייג" (Fisherman). תהליך הסכסוך עוקב אחר השלבים הבאים:

1. הדייג מגיש ערר על שאילתה שגויה או POI, נועל 10,000 GRT.
2. אם מתברר שלאינדקסאי אין בעיה, ה-GRT הנעול של הדייג נשרף לחלוטין.
3. אם האינדקסאי נמצא אשם, הוא נחתך, והדייג זכאי למחצית מה-GRT שנחתך.

מנגנון זה דומה מאוד למערכת האתגר המשמשת ב-Optimistic Rollup, בהנחת התנהגות נכונה של האינדקסאי ואימוץ גישה אופטימית.

2. 3. אוצרים

(הערה: מערכת האקולוגית של The Graph עובדת באופן פעיל על רפורמה במנגנון האוצרים. אנא עקבו אחר הודעות הפורום לעדכונים אחרונים.)

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

• תת-גרפים עם תדירות גבוהה של שאילתות (המייצרים הכנסה משמעותית).
• תת-גרפים שלא נתקלים בשגיאות במהלך יצירת מסד הנתונים (אין שגיאות קוד).
• תת-גרפים שנוצרו באופן רשמי על ידי הפרוטוקול.

לאחר שתת-גרף מוצב ברשת, האוצרים מעריכים גורמים אלו ומאותתים ב-GRT על תת-גרפים טובים. תהליך זה מכונה "איתות" (signaling). על ידי כך, אוצרים משחקים תפקיד חשוב בהדרכת אינדקסאים לתת-גרפים בעלי ערך ואמינים, מבטיחים את השלמות והיעילות הכללית של רשת The Graph.

איתות של אוצרים עם GRT מונח, מקור: Graph Explorer

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

תמריצי GRT: אוצרים מקבלים 10% (כפוף לשינוי דרך ממשל) מעמלות השאילתות הנוצרות מהתת-גרף שהם מנהלים כפרס. פרס כל אוצר פרופורציונלי לחלקו בתת-גרף. אם תת-גרף נתקל בבעיות וצריך להציב אותו מחדש, עמלת הגירה נגרעת מה-GRT שהונח על ידי האוצר. גורמים אלו ממריצים אוצרים להמר GRT ולשלוח אותות לתת-גרפים שמייצרים הרבה שאילתות ואין בהם בעיות איכות.

מניות אוצרים של Graph: כאשר אוצר ממר GRT כדי לשלוח אות, הוא מקבל מניות באותו תת-גרף, המיוצגות כמניות אוצרים של Graph (GCS), אסימון ERC-20. מכיוון שפרוטוקול The Graph קיים כעת גם ב-L1 (Ethereum) וגם ב-L2 (Arbitrum), מנגנון האוצרים עובד באופן שונה בשתי השכבות הללו. ב-L1, מחיר ה-GCS עולה בפרופורציה לכמות ה-GRT המונחת על התת-גרף המתאים, וגרף המחירים הזה מיושם באמצעות עקומת הקשירה (bonding curve) של Bancor. ב-L2, עקומת הקשירה שטוחה (כלומר, אין עלייה אקספוננציאלית במחיר המניה). בזמן שאין סיכון חיתוך לאוצרים, נגבית עמלת פיקדון של 1% בעת המרת GRT כדי להרתיע הערכה לא נכונה של תת-גרפים. אוצרים יכולים לשרוף את ה-GCS שלהם כדי לקבל בחזרה GRT, כאשר כמות ה-GRT המוחזרת נקבעת על פי המיקום בעקומת הקשירה.

מחיר מניית תת-גרף ב-GRT (מקרה של L1), מקור: The Graph Docs

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

2. 4. מוסדים

מוסדים הם משתתפים ברשת הממנים את ה-GRT שלהם לאינדקסאים, תורמים לביטחון הרשת מבלי להפעיל ישירות צומת של Graph. מערכת זו, הדומה למבנה Delegated Proof of Stake (DPoS), מאפשרת לאנשים שאינם מפעילים צמתים להמנות את ה-GRT שלהם לאינדקסאים ולהרוויח חלק מעמלות השאילתות והפרסים.

תצורה זו מאפשרת למשתמשים רגילים ללא ידע מקצועי באינדקסאות להשתתף כמקצים ולייצר הכנסה דרך רשת The Graph. כמות השאילתות שאינדקסור יכול לעבד פרופורציונלית לסך ה-GRT המוצמד על ידו וה-GRT שהוקצה לו. יתר על כן, מספר אינדקסורים יכולים לאנדקס את אותו תת-גרף (Subgraph). באמצעות מנגנון ההחזר, קיימת מוטיבציה לאינדקסורים להחזיק בהימור ובהקצאה באופן פרופורציונלי לכמות השאילתות שהם מתכוונים לשרת.

2. 4. 1. איך להקצות (Delegate)

לוח מחוונים של אינדקסור, מקור: Graph Explorer

תוכלו להפוך למקצים על ידי ביצוע השלבים הפשוטים הבאים כדי להקצות את ה-GRT שלכם לאינדקסור:

1. גשו ל-Graph Explorer, הסייר הרשמי של The Graph, תחת הלשונית Participants (קישור).
2. לחצו על כפתור ה-'Connect' כדי לחבר את הארנק שלכם, כגון MetaMask (חלק ① בתמונה).
3. מצאו את האינדקסור שאליו ברצונכם להקצות את ה-GRT שלכם ולחצו על כפתור ה-'Delegate' כדי להמשיך בתהליך ההקצאה (חלקים ② ו-③ בתמונה).

בעוד שהקצאת GRT אינה כרוכה בסיכון חיתוך (slashing risk) עבור מקצים בהגדרות הפרוטוקול הנוכחיות, יש לשים לב כי מס של 0.5% מוטל בעת ההקצאה, וקיים תקופת המתנה של 28 יום לביטול הקצאה כדי למשוך את האסימונים שהוקצו.

2. 4. 2. איך לבחור אינדקסורים

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

לוח מחוונים של p2p.org; מקור: Graph Explorer

התמונה למעלה, נכון ל-16 בינואר, מציגה את לוח המחוונים של האינדקסור של p2p.org, שיש לו את נפח ההימור הגדול ביותר ב-GRT בשרשרת Arbitrum. האזורים העיקריים בלוח מחוונים זה שיש לשים לב אליהם סומנו כ-①, ②, ו-③.

[ ① Stake ]

באזור ①, המציג את מצב ההימור, כל אינדיקטור משמעותו היא כדלקמן:

• Owned: הכמות של GRT שהאינדקסור הימר על עצמו. נדרש מינימום של 100,000 GRT כדי לבצע אינדקסאות פעילה.
• Delegated: הכמות של GRT שהוקצתה לאינדקסור על ידי מקצים.
• Allocated/Unallocated: מציין כמה מהימור ה-GRT של האינדקסור מוקצה לתת-גרפים.
• Chart: מציג את המגמה של נפח הימור ה-GRT.

בדוגמה, האינדקסור הימר ישירות 29.1 מיליון GRT וקיבל 270.4 מיליון GRT בהקצאה. מתוך סך של 299.5 מיליון GRT, 298.23 מיליון מוקצים לתת-גרפים להפקת הכנסה, ו-1.28 מיליון נותרים ללא הקצאה.

[ ② Delegation ]

אזור ② ניתן לחלק למקטע "Delegation", המציג את מצב ההקצאה, ולמקטע "Delegation parameters", החשוב להערכת רווחיות. משמעויות האינדיקטורים במקטע Delegation הן:

• Delegation Received: הכמות של GRT שכבר הוקצתה לאינדקסור.
• Max Capacity: הכמות המקסימלית של GRT שהאינדקסור יכול לנהל. כיום, אינדקסורים יכולים לנהל עד 16 פעמים את כמות ה-GRT שהם הימרו עליה (Owned).
• Delegation Available: הכמות הנוספת של GRT שהאינדקסור יכול לקבל כעת בהקצאה. הנוסחה: (Max Capacity) - (Delegation Received) = (Delegation Available) חלה כאן. נתון ה-'Delegation Available' יכול להיות שלילי, מה שמצביע על הקצאת יתר (over-delegation) מעבר לקיבולת האינדקסור. מצב זה יכול להשפיע לרעה על הרווחיות, שכן לעיתים קרובות הדבר גורם לכך שחלק מה-GRT המוקצה לא יוקצה לאינדקסאות.

משמעויות האינדיקטורים במקטע Delegation parameters הן:

• Indexing Reward Cut: זהו החלק מהתגמולים שהאינדקסור מקבל.
• Query Fee Cut: זהו החלק מהחזרי עמלת השאילתות שהאינדקסור מקבל.
• Cooldown Remaining (מוצא משימוש): מציין את הזמן הנותר לפני שהאינדקסור יכול לשנות שוב את פרמטרי ההקצאה שלו. עליהם לחכות תקופה מסוימת לאחר כל שינוי, והם יכולים לבצע שינויים רק כאשר ה-Cooldown Remaining מגיע ל-"0 Days".
• Effective Reward Cut: האחוז מתגמולי האינדקסאות שנוצרו על ידי GRT מוקצה שהאינדקסור לוקח. אם אינדיקטור זה שלילי, הוא שקול לכך שהאינדקסור מספק תמריצים למקצים. לדוגמה, אם תגמול האינדקסאות היומי הוא 100 GRT, וההימור של האינדקסור הוא 200 GRT עם 800 GRT מוקצים (יחס של 2:8), אז 20 GRT מהתגמול נוצרים על ידי ההימור של האינדקסור, ו-80 GRT על ידי ההימור המוקצה. אם ה-Indexing Reward Cut מוגדר על 10%, האינדקסור מקבל למעשה 10 GRT, וה-90 GRT הנותרים הולכים למקצים. המקצים מקבלים יותר מהתגמולים שנוצרו על ידי ההימור שלהם; במקרה זה, מדובר ב-112.5% (90/80), או תוספת של 12.5%. מנקודת המבט של האינדקסור, הם נותנים 12.5% מהתגמולים שנוצרו על ידי ההימור המוקצה, כך שה-"Effective Reward Cut" הוא -12.5%. לפיכך, אם ה-Effective Reward Cut חיובי, האינדקסור לוקח חלק מהתגמולים שנוצרו על ידי ההימור המוקצה, ואם הוא שלילי, האינדקסור משלם חלק מהתגמולים שנוצרו על ידי ההימור שלו כתמריצים למקצים. להסבר מפורט יותר, אנא עיינו בהסבר הרלוונטי ב-Graph Academy. בדוגמה, האינדקסור לוקח 89% מסך עמלות השאילתות ו-20% מסך תגמולי האינדקסאות, מה שמצביע על כך שהם לוקחים 11.39% מהתגמולים שנוצרו על ידי הימור ה-GRT המוקצה.

[ ③ Income ]

אזור ③ מכסה את התגמולים שהרוויח האינדקסור. כל אינדיקטור מייצג את הדברים הבאים:

• Indexing Rewards: הכמות של GRT שהאינדקסור מקבל מסך תגמולי האינדקסאות.
• Delegator Rewards: הכמות של GRT שהמקצים מקבלים מסך תגמולי האינדקסאות.
• Indexing Rewards (Bold): הסכום הכולל של תגמולי האינדקסאות.
• Indexer Query Fees: הכמות של GRT שהאינדקסור מקבל מסך עמלות השאילתות.
• Delegator Query Fees: הכמות של GRT שהמקצים מקבלים מסך עמלות השאילתות.
• Query Fees: הסכום הכולל של תגמולי עמלת השאילתות.

מהדוגמה, האינדקסור קיבל סך של 9.65 מיליון GRT בתגמולי אינדקסאות ו-1.21 אלף GRT בתגמולי עמלת שאילתות, המסתכמים בתגמול כולל של 9.7 מיליון GRT.

מקור: Graph Explorer

Graph Explorer מספק תצוגה כוללת של אינדיקטורים אלו ומציג את התשואה השנתית המשוערת (Estimated APR) עבור משתמשים בעת הקצאת GRT. למרות ש-APR זה מבוסס על תגמולי אינדקסאות ואינו כולל תגמולי עמלת שאילתות, זהו אינדיקטור אמין בהתחשב בכך שרוב התגמולים ברשת The Graph מגיעים מאינדקסאות. עם זאת, חשוב לציין כי אינדיקטור זה מבוסס על נתונים יומיים וכפוף לתנודות.

לכן, ראוי לבחור אינדקסאית (indexer) תוך התחשבות בגורמים שונים כגון גודל ההימור הכולל ויחס ההאצלה של האינדקסאית, ועוד.

3. מדדי צמיחה של The Graph

3. 1. סקירה כללית

מצב הנזילות של בריכת Uniswap V3 ETH-AAVE, מקור: Uniswap

מקרה שימוש עיקרי ב-The Graph הוא אספקת מדדים עבור יישומים מבוזרים (dApps) למשתמשים. למשל, כאשר נדרש מידע על הנזילות של בריכות Uniswap V3, מבוצעות קריאות לתת-גרפים (subgraphs) שפרוסים על The Graph כדי לאחזר נתונים אלו.

רשימת אפליקציות dApps המשתמשות ב-The Graph; מקור: Graph Explorer

בין ה-dApps הבולטים שפרסו תת-גרפים על The Graph נמנים Vela Exchange, Ether.fi, Snapshot, Dolomite ועוד. להלן תיאור קצר שלהם.

Vela Exchange: פלטפורמת מסחר דצנטרלית לחוזים קבועים (perpetuals) המשתמשת ב-The Graph לאינדקסציה ושאילתות נתונים אודות פעילויות מסחר כגון עמדות פתוחות, הפקדות, משיכות וכיוצא בזה.

Ether.fi: פלטפורמת הימור נזיל (liquid staking) מבוזרת המשתמשת ב-The Graph למעקב אחר אירועים מחוזה הפרוטוקול ולהפיכתם לניתנים לשאילתה.

Snapshot: כלי הצבעה וממשל דצנטרלי המשתמש ב-The Graph לגישה לנתוני הצבעה והצעות.

Dolomite: פרוטוקול שוק כספים (money market) וממיר (DEX) מבוזר המשתמש ב-The Graph לאינדקסציה של מצב הפרוטוקול.

השירותים של The Graph מנוצלים גם על ידי לוחות בקרה שונים (dashboards), כאשר דוגמה בולטת היא DefiLlama, שירות לוח בקרה בולט בתחום ה-DeFi. רבות מה-dApps מספקות את מידע ה-TVL/נפח שלהן בצורה של תת-גרף ל-DefiLlama.

מגמת מספר תת-הגרפים הפעילים חודשית; מקור: לוח הבקרה של Mannan Inamdar

The Graph התבסס כפלטפורמת אינדקסציה של נתונים אמינה על בסיס טכנולוגיה כזו. עד כה, היא טיפלה בהצלחה בלמעלה מטריליון שאילתות. נכון לינואר 2024, כ-1,700 תת-גרפים מייצרים שאילתות באופן פעיל בפלטפורמה. מעורבות ושימוש מתמשכים אלו מדגישים את התפקיד המשמעותי של The Graph במערכת האקולוגית המבוזרת, תוך מתן שירותי נתונים חיוניים למגוון רחב של יישומים ופלטפורמות.

מגמת מספרי ההאצלות השבועיות; מקור: לוח הבקרה של Mannan Inamdar

מספר ההאצלות (delegations) ב-The Graph חווה עלייה משמעותית החל מהרבעון השלישי של שנת 2023. על פי ציוץ מ-The Graph, העלייה הזו ניתנת ברובה לקמפיין האצלת GRT שבוצע דרך Coinbase Wallet. קמפיין זה שילב בהצלחה למעלה מ-30,000 מאצילים (delegators) חדשים ברשת של The Graph. העובדה שהמספר הכולל של ההאצלות השבועיות ברשת שמר על רמה מסוימת גם לאחר הקמפיין מצביעה על עלייה משמעותית במספר משתתפי הרשת. ניתן לראות מגמת צמיחה זו בפירוט רב יותר בדוחות הרבעוניים של The Graph לרבעון השלישי של 2023 שפורסמו על ידי Messari.

בעוד שה-Curators ראו צמיחה מתונה של 5%, מספר המאצילים (Delegators) קפץ ב-247% ברבעון השלישי של 2023. עלייה זו במספר המאצילים מ-11,500 ברבעון השני של 2023 לכמעט 40,000 ברבעון השלישי של 2023 הונעה על ידי קמפיין Coinbase Earn. לפני סוף הרבעון השלישי של 2023, כ-25,000 מאצילים חדשים מקורם בהשתתפות בקמפיין Coinbase Earn. משתתפים חדשים אלו הוסיפו כ-6.2 מיליון GRT בהאצלה עד לסוף הרבעון השלישי של 2023 ושולמו להם כ-4.3 מיליון GRT דרך הקמפיין. בעוד שברבעון השלישי של 2023 היו 114 מאצילים על Arbitrum, הרבעון השלישי של 2023 ראה עלייה מסיבית ללמעלה מ-28,000 מאצילים על Arbitrum, עם הימור כולל של למעלה מ-800 מיליון GRT. במקביל, מאצילים על Ethereum נשארו יציבים על 11,500 ברבעון השלישי של 2023, עם הימור כולל של 1.1 מיליארד GRT.

— "Mihai Grigore, The Graph Quarterly Reports Q3 2023, Messari"

3. 2. התרחבות ל-Arbitrum

במקור מבוססת על רשת Ethereum, The Graph נתקלה באתגרים עקב עומס רב ברשת ועלייה בעמלות טרנזקציות, מה שעלול היה להוביל לאי-יעילויות ברשת של The Graph. כדי להתמודד עם בעיות אלו, The Graph יזמה התרחבות ל-Arbitrum, פתרון סקיילינג שכבה 2 עבור Ethereum. באפריל 2023, The Graph הקצתה 5% מתגמולי האינדקסציה של הרשת לשרשור Arbitrum (ציוץ רלוונטי). לאחר מכן, הועלתה הצעה GIP-0052 להגדיל את חלק תגמולי האינדקסציה המוקצים לשרשור Arbitrum עד ל-95% (בסופו של דבר זה יעבור ל-100%). הצעה זו נדונה בקהילה ועברה שלושה סבבי הצבעה של מועצת הממשל, מה שהוביל להגדלה מדורגת של הקצאת תגמולי האינדקסציה לשרשור Arbitrum. מהלך אסטרטגי זה נועד לנצל את יכולות עיבוד הטרנזקציות היעילות והחסכוניות של Arbitrum, ובכך לשפר את הפונקציונליות והביצועים הכלליים של רשת The Graph.

פרטי GIP-0052

• GGP-0029: Increase L2 Rewards to 25%
• GGP-0030: Increase L2 Rewards to 50%
• GGP-0033: Increase L2 rewards to 95%

מגמת תגמולי האינדקסציה החודשיים למאצילים; מקור: לוח הבקרה של Realchoubey

הקצאת תגמולי האינדקסציה ל-Arbitrum הנ"ל יושמה במרווחים. בספטמבר 2023, ההקצאה הותאמה ל-25% ו-50%, ובדצמבר 2023, לאחר הצבעת המועצה, היא עלתה עוד יותר ל-95%. כפי שניתן לראות מהגרף המסופק, תגמולי האינדקסציה שחולקו למאצילים בשרשור Arbitrum החלו לעלות באופן משמעותי החל מספטמבר, תוך הצגת מגמת עלייה מתמשכת. הוביל זה לכך שמספר רב של אינדקסאים, אוצרים (curators) ומאצילים עברו לשרשור Arbitrum. כיום, התפלגות השתתפות הרשת בין Ethereum ל-Arbitrum בתוך רשת The Graph מודגמת בטבלה הבאה.

4. לסיכום

The Graph הוא פרוטוקול רשת מבוזר המורכב מאינדקסאים, אוצרים ומאצילים, המאפשר אחזור מאובטח ומדויק של נתוני בלוקצ'יין. הוא התבסס כמשאב העיקרי עבור יישומים מבוזרים (dApps) הדורשים אינדקסציית נתונים, תוך עיבוד מוצלח של למעלה מטריליון שאילתות. יתר על כן, הוא מיקם את עצמו כפרוטוקול תשתית נתונים מוביל במערכת האקולוגית של הבלוקצ'יין, מציג יציבות תוך התפתחות מתמדת לשיפור היכולת הקנה (scalability).

עם המגמה האחרונה להשקת שרשורים מודולריים, ישנה עלייה בהופעת רשתות ומוצרי בלוקצ'יין חדשים. דבר זה טבעי מוביל לציפייה לביקוש מוגבר לשירותי אינדקסציית הנתונים המסופקים על ידי The Graph. בתגובה לנסיבות משתנות ובמטרה להציע שירותי אינדקסציה בביצועים גבוהים יותר תוך הרחבת הנגישות לנתוני בלוקצ'יין, The Graph חשפה את מפת הדרכים האחרונה שלה בנובמבר 2023, לאחר ההתרחבות ל-Arbitrum בשנה שעברה.

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

הפניות The Graph Docs Graph Explorer Juan Defago, Evaluating an Indexers Effective Cut, The Graph Academy Mannan Inandar, The Graph Ecosystem Overview Mihai Grigore, The Graph Quarterly Reports Q3 2023, Messari Pablo, GIP-0052 pcarranzav, gips/0052-timeline-and-requirements-for-l2-rewards. md The Graph Council snapshot Realchoubey, Graph Network - Revenue Dashboard The Graph tweet