הבעיה: רזולוציה סטנדרטית לא יכולה לעמוד בעומס
דמיינו DApp עם 100,000 משתמשים יומיים. כל קריאה ל-provider.resolveName() פוגעת בצומת RPC. ללא שמירה במטמון, תגיעו במהירות למגבלות בקשות—רמות טיפוסיות של Infura/Alchemy מאפשרות 100,000 בקשות ביום. בשיא של 10,000 משתמשים בו-זמנית, רזולוציה יכולה לקחת עד 500 אלפיות השנייה לכל שם, ועיבוד אצווה של רשימה של 1000 כתובות ברצף באמצעות ethers לוקח 2–5 דקות. זה לא מקובל עבור יישומים בזמן אמת. יתר על כן, עליכם לתמוך בכתובות מרובות-רשתות (ETH, BSC, Polygon), לטפל בדומיינים עם תווים כלליים (ENSIP-10), ובנתונים מחוץ לשרשרת באמצעות CCIP-Read (EIP-3668). ספריות סטנדרטיות אינן מותאמות לתרחישים אלה.
אנו מפתחים פותרי ENS מותאמים אישית הפותרים בעיות אלה. הצוות שלנו השלים למעלה מ-30 פרויקטים שבהם פרסנו אינטגרציית ENS חזקה תחת עומסים גבוהים. שמירה במטמון מפחיתה את זמן הרזולוציה ל-1–5 אלפיות השנייה, ועיבוד אצווה של 1000 כתובות מסתיים תוך 2 שניות. עלויות ספק RPC יורדות בעד 40%, וחוסכות עד $500 בחודש בקנה מידה. ב-200,000 בקשות ביום, החיסכון מגיע ל-$6,000 בשנה. עם למעלה מ-30 פרויקטים מוצלחים ומומחי בלוקצ'יין מוסמכים, אנו מבטיחים זמן רזולוציה מתחת ל-10 אלפיות השנייה ומספקים אחריות 100% שביעות רצון על כל הפריסות.
תהליך רזולוציית ENS
שרשרת החיפוש המלאה של ENS כוללת: נורמליזציה של שם (UTS-46), חישוב namehash (keccak256), שאילתה לרישום ENS עבור כתובת הפותר, בדיקת תמיכה בתווים כלליים (ENSIP-10), שאילתה לפותר עם coinType, ואם הפותר מחזיר OffchainLookup (EIP-3668), ביצוע CCIP-Read. כל שלב יכול להיות צוואר בקבוק. השירות המותאם אישית שלנו מטפל בכל השרשרת, תוך שמירה על תוצאות ביניים במטמון.
שירות פותר מותאם אישית עם שמירה במטמון
עבור מערכות ייצור, אנו מיישמים שירות רזולוציה מותאם אישית עם שמירה במטמון מבוזר (Redis + מטמון בזיכרון). דוגמה ב-TypeScript באמצעות viem (v2.x) ו-node-cache:
לחצו להרחבת דוגמת קוד
import { createPublicClient, http, normalize } from "viem";
import { mainnet } from "viem/chains";
import NodeCache from "node-cache";
class ENSResolutionService {
private client = createPublicClient({ chain: mainnet, transport: http(RPC_URL) });
private cache = new NodeCache({ stdTTL: 300 }); // 5 минут TTL
async resolveName(name: string): Promise<string | null> {
const normalized = normalize(name);
const cacheKey = `addr:${normalized}`;
const cached = this.cache.get<string>(cacheKey);
if (cached !== undefined) return cached;
try {
const address = await this.client.getEnsAddress({ name: normalized });
this.cache.set(cacheKey, address ?? null);
return address;
} catch (e) {
return null;
}
}
async lookupAddress(address: `0x${string}`): Promise<string | null> {
const cacheKey = `name:${address.toLowerCase()}`;
const cached = this.cache.get<string>(cacheKey);
if (cached !== undefined) return cached;
const name = await this.client.getEnsName({ address });
this.cache.set(cacheKey, name ?? null);
return name;
}
async batchLookup(addresses: `0x${string}`[]): Promise<Map<string, string | null>> {
const results = new Map<string, string | null>();
const uncached: `0x${string}`[] = [];
for (const addr of addresses) {
const cached = this.cache.get<string>(`name:${addr.toLowerCase()}`);
if (cached !== undefined) {
results.set(addr, cached);
} else {
uncached.push(addr);
}
}
await Promise.allSettled(
uncached.map(async (addr) => {
const name = await this.lookupAddress(addr);
results.set(addr, name);
})
);
return results;
}
}קוד זה משתלב בקלות בכל backend. מטמון עם TTL של 5 דקות מפחית את עומס ה-RPC פי עשרה. עבור סביבות מבוזרות, אנו משתמשים ב-Redis עם אותו TTL. לתרחישים מורכבים, אנו מפתחים גם פותרי Solidity הניתנים לפריסה כחוזים מותאמים אישית. פותר ה-ENS המותאם אישית שלנו תומך ברזולוציית תווים כלליים של ENSIP-10, בטיפול ב-CCIP-Read, בכתובות מרובות-רשתות, בשמירת ENS במטמון, והוא בנוי עם Solidity ומשולב עם Web3 באמצעות ethers ו-viem.
כיצד ליישם כתובות מרובות-רשתות?
ENS תומך באחסון כתובות עבור בלוקצ'יין שונים באמצעות coinType (SLIP-44). לדוגמה, ETH = 60, BTC = 0, SOL = 501, MATIC = 966. השירות שלנו מאפשר לכם לאחזר כתובות עבור כל coinType עם פונקציה אחת:
const COIN_TYPES = { ETH: 60, BTC: 0, SOL: 501, MATIC: 966, ARB: 9001 };
async function getMultiChainAddresses(name: string) {
const resolver = await provider.getResolver(name);
if (!resolver) return null;
const eth = await resolver.getAddress(COIN_TYPES.ETH);
const btc = await resolver.getAddress(COIN_TYPES.BTC);
const sol = await resolver.getAddress(COIN_TYPES.SOL);
return { eth, btc, sol };
}ניתן להוסיף כל coinType, כולל MATIC, ARB, OP. אנו מספקים ממשק אחיד לעבודה עם מספר רשתות.
כיצד לטפל ב-CCIP-Read בפותר מותאם אישית?
CCIP-Read (EIP-3668) מאפשר לפותר להחזיר קישור לנתונים מחוץ לשרשרת במקום כתובת. הלקוח חייב לבצע בקשת HTTP לאותו קישור ולאמת את החתימה. בשירות שלנו, אנו מטפלים ב-OffchainLookup באופן אוטומטי: לאחר קבלת השגיאה, אנו מחלצים את ה-URL והנתונים, מורידים אותם, מאמתים את החתימה (אם נדרש), ושומרים את התוצאה במטמון. ראו EIP-3668 לפרטים. עבור פותרי תווים כלליים (ENSIP-10), יש לנו תמיכה מלאה—ראו תיעוד ENSIP-10.
שיפורי מהירות עם שירות מותאם אישית
קחו מקרה אמיתי: יישום לקוח פותר שמות עבור 10,000 משתמשים בעומס. עם ethers ברצף—כ-50 שניות. עם השירות המותאם אישית שלנו המשתמש במטמון ובבקשות מקבילות—2 שניות. שיפור של פי 25. זה מושג על ידי שמירת שמות מבוקשים תדיר במטמון, עיבוד אצווה מקביל באמצעות Promise.allSettled, והימנעות מקריאות RPC כפולות עבור כתובות ידועות. כל אלפית שנייה חשובה בעומס שיא, ולכן אנו מייעלים את השירות לביצועים מקסימליים. השירות המותאם אישית שלנו מהיר פי 25 משימוש ב-ethers ברצף לרזולוציית אצווה.
יתרונות של שירות מותאם אישית על פני ספריות
ספריות מוכנות (ethers, viem) עובדות בדפדפן, אך ב-backend ללא שמירה במטמון, הן ממהרות למצות את מגבלות ה-RPC. שירות מותאם אישית נותן שליטה מלאה על שמירה במטמון, תמיכה בתווים כלליים, רזולוציית אצווה מקבילה, ונקודת אינטגרציה אחת למספר רשתות. הנה השוואה:
לחצו לראות טבלת השוואה
| קריטריון | ethers/viem | שירות מותאם אישית |
|---|---|---|
| שמירה במטמון | לא (או ידני) | מובנה עם TTL |
| רזולוציית אצווה | רצף | מקביל |
| תווים כלליים (ENSIP-10) | חלקי | תמיכה מלאה |
| מרובה-רשתות | ETH בלבד | כל coinType |
| זמני פסק זמן | ברירת מחדל | תצורה גמישה |
השירות המותאם אישית שלנו מעבד בקשות אצווה פי 5–10 מהר יותר מאשר ethers/viem.
כיצד ליישם רזולוציית ENS מותאמת אישית ב-4 שלבים
- ניתוח ארכיטקטורה: הערכת העומס הנוכחי שלכם, צרכי השמירה במטמון ודרישות הרשתות. (0.5 יום)
- עיצוב השירות: עיצוב API, סכימת שמירה במטמון וטיפול בשגיאות. (יום אחד)
- יישום הליבה: בניית הפותר עם שמירה במטמון, תמיכה מרובת-רשתות ותמיכה ב-CCIP-Read. (2-3 ימים)
- אינטגרציה ובדיקות: אינטגרציה עם ה-backend שלכם, ביצוע בדיקות עומס ופריסת ניטור. (1-2 ימים)
שלבי פיתוח של שירות רזולוציה מותאם אישית
| שלב | משך | תוצאה |
|---|---|---|
| ניתוח ארכיטקטורה | 0.5 יום | מפרט טכני עם מדדים |
| עיצוב השירות | יום אחד | תיעוד API, סכימת שמירה במטמון |
| יישום הליבה | 2–3 ימים | פותר עובד עם בדיקות |
| אינטגרציית backend | 1–2 ימים | נקודת קצה מוכנה |
| ניטור ואופטימיזציה | יום אחד | לוח מחוונים, התראות, בדיקות עומס |
מה כלול בעבודה
- תיעוד API של הפותר—מפרט REST או JSON-RPC עם דוגמאות בקשות
- פריסת השירות על התשתית שלכם (Docker, Kubernetes, Lambda) עם ניטור והתראות
- אינטגרציה עם backend קיים—התאמה ל-fastify, express, serverless
- הדרכת צוות—סדנה על שימוש בפותר ופתרון בעיות
- תמיכה טכנית—חודש אחד לאחר הפריסה
לוח זמנים ועלות
פיתוח שירות רזולוציה מותאם אישית עם שמירה במטמון ותמיכה מרובת-רשתות אורך 3 עד 5 ימי עבודה. אינטגרציה ל-backend קיים אורכת עוד 1–2 ימים. העלות מחושבת באופן פרטני לפי היקף העבודה. עלות פרויקט טיפוסית נעה בין $5,000 ל-$15,000, עם החזר השקעה תוך 3–6 חודשים. קבלו ייעוץ לפרויקט שלכם—נעריך את הארכיטקטורה ונציע אופטימיזציה. צרו קשר לניתוח האינטגרציה הנוכחית שלכם עם ENS: נזהה צווארי בקבוק ונאיץ את הרזולוציה.







