دامنه بلاکچینی چیست؟ DNS، ENS، ریسک و Pilot

دامنه بلاکچینی چیست و چه چیزی نیست؟

اصطلاح «دامنه» در این حوزه کمی گمراه‌کننده است. در DNS، نامی مثل example.com در فضای نام جهانی DNS، زیر Registry و Registrar و رکوردهای Authoritative مدیریت می‌شود. در یک Blockchain Name System، نام در Registry/Registrar contract ثبت می‌شود و Resolver آن می‌تواند آدرس کیف پول، متن، کلید یا contenthash برگرداند. برنامه کاربر باید این سامانه و روش Resolution را بشناسد.

گزارش فنی ICANN درباره Blockchain Name Systemها نیز تأکید می‌کند که یک سامانه واحد جهانی وجود ندارد و بعضی سامانه‌ها از رشته‌هایی شبیه TLD استفاده می‌کنند که در DNS عمومی واگذار نشده‌اند. پس عبارت بازاری «پسوند دامنه بلاکچینی» را معادل پسوند DNS نگیرید.

واژه‌نامه‌ای که جلوی تصمیم اشتباه را می‌گیرد

Registry، Registrar و Resolver

Registry نگاشت مالک/کنترل‌کننده و Resolver نام را نگه می‌دارد. Registrar قواعد تخصیص، قیمت، مدت و تمدید را اجرا می‌کند. Resolver نام را به رکورد موردنیاز تبدیل می‌کند. مالک Token، مدیر رکورد و دریافت‌کننده پرداخت می‌توانند حساب‌های متفاوتی باشند؛ این جداسازی برای کسب‌وکار مفید اما نیازمند RACI روشن است.

Forward، Reverse و Primary name

Forward resolution از نام به آدرس می‌رسد. Reverse/Primary name می‌تواند از یک حساب به نام ترجیحی برگردد. تطابق دوطرفه یک سیگنال Consistency است، نه اثبات هویت قانونی یا مجوز پرداخت. یک مهاجم، حساب اشتباه یا رکورد قدیمی همچنان می‌تواند داده سازگار اما نامعتبر بسازد.

Wallet address، Identity و Authorization

آدرس کیف پول یک شناسه رمزنگاری‌شده برای حساب است. نام، نمایش آن شناسه را آسان‌تر می‌کند؛ اما نمی‌گوید پشت حساب چه شخص یا شرکتی است، چه کسی مجاز به خرید است یا آیا حساب تحریم/تقلب/مالکیت برند را نقض می‌کند. Authentication با Signature و Nonce، Authorization سمت سرور، احراز سازمان و Recovery باید جدا طراحی شوند. برای مرزبندی DID، VC، Wallet login و NFT، راهنمای کاربرد بلاکچین در توسعه وب را ببینید.

Contenthash و IPFS

Contenthash رکوردی است که به محتوای آدرس‌پذیر با Hash اشاره می‌کند؛ خود نام فایل را ذخیره یا سرو نمی‌کند. CID می‌تواند یکپارچگی بایت‌ها را نشان دهد، اما Availability را تضمین نمی‌کند. Node باید محتوا را نگه دارد و پیدا شود؛ Gateway نیز Dependency جداگانه است.

شش تصور رایج و واقعیت عملیاتی

Snapshot تاریخ‌دار: ENS و فضای نام در ۱۰ اوت ۲۰۲۶

وضعیت پروتکل‌ها، کلاینت‌ها و قیمت‌گذاری تغییر می‌کند؛ این بخش Snapshot است، نه وعده دائمی. پیش از خرید یا انتشار، مستندات همان روز و قرارداد روی شبکه را دوباره بررسی کنید.

• ENS تولیدی: مستندات فعلی Registrar دامنه‌های ‎.eth ثبت/تمدید، Commit–Reveal و Grace period ۹۰روزه را توضیح می‌دهد. از دست‌دادن کلید یا تمدیدنکردن می‌تواند کنترل نام را از بین ببرد؛ «مالکیت ابدی» توصیف دقیقی نیست.
• ENSv2: ENS Labs در فوریه ۲۰۲۶ اعلام کرد نسخه جدید روی Ethereum L1 خواهد بود. در توضیح رسمی معماری ENSv2، ارتقا برای «ماه‌های آینده» توصیف شده و App آلفا روی Sepolia بوده است. تا تاریخ این Snapshot، در منابع رسمی بررسی‌شده تأیید صریحی برای Launch تولیدی پیدا نشد؛ بنابراین Ruleهای پیشنهادی ENSv2 را به قرارداد تولیدی فعلی تعمیم ندهید.
• مرورگر: راهنمای رسمی وب‌سایت غیرمتمرکز ENS می‌گوید مرورگرهای اصلی به‌طور Native نام‌های .eth را باز نمی‌کنند و روش‌هایی مثل مرورگر سازگار، Extension یا Gateway لازم است.
• DNS: Registry رسمی IANA Special-Use Domain Names، alt. را طبق RFC ۹۴۷۶ فهرست می‌کند. این موضوع .eth را به TLD واگذارشده یا Special-use در DNS جهانی تبدیل نمی‌کند.

نتیجه مدیریتی ساده است: در Purchase memo، «Current production behavior»، «Proposal/Governance vote»، «Testnet/Alpha» و «Announced future» را چهار ستون جدا کنید. نسخه‌ای که هنوز Launch نشده، مبنای SLA یا مدل هزینه امروز نیست.

Resolution دقیقاً چگونه اتفاق می‌افتد؟

Input: pay.brand.eth
  → Client تشخیص می‌دهد این نام را می‌شناسد یا نه
  → Library/RPC شبکه و Registry درست را پیدا می‌کند
  → Registry: Controller/Resolver نام چیست؟
  → Resolver: رکورد خواسته‌شده برای Coin/Chain چیست؟
  → UI آدرس، Chain، Asset و Source را نمایش می‌دهد
  → کاربر مقصد را تأیید می‌کند
  → Wallet تراکنش را Sign و Broadcast می‌کند
  → Backend نتیجه، Finality و Reconciliation را ثبت می‌کند

هر پیکان یک Failure mode دارد: RPC قطع یا ناسازگار، Resolver اشتباه، رکورد قدیمی، Coin type نادرست، Client بدون پشتیبانی، Chain اشتباه، Signature فیشینگ یا Reorg. بنابراین «نام حل شد» پایان کنترل نیست؛ فقط ورودی مرحله Confirmation است.

Use caseهای معتبر؛ از مسئله شروع کنید، نه از پسوند

Alias پرداخت

نام خوانا می‌تواند اصطکاک Copy/Paste آدرس را کم کند، به‌شرط آنکه Product آدرس Resolution‌شده، Chain و Asset را نشان دهد و پرداخت‌های بزرگ/دوره‌ای Address book تأییدشده داشته باشند. برای طراحی کامل Refund، Finality و Reconciliation، مقاله روش‌های پرداخت فروشگاه و رمزارز دامنه مسئولیت این مقاله را تکمیل می‌کند.

Profile و رکوردهای عمومی

نام می‌تواند Avatar، URL یا رکوردهای متنی را در اکوسیستم سازگار نمایش دهد. این داده‌ها عمومی، قابل هم‌بستگی و گاهی تغییرپذیرند. اطلاعات شخصی، Token دسترسی، ایمیل خصوصی یا Secret را در رکورد عمومی نگذارید. هزینه و Retention داده را با بودجه و برنامه حریم خصوصی بسنجید.

ورود به dApp

نام فقط Label حساب است. Login امن نیازمند پیام امضاشده با Domain، URI، Chain ID، Nonce یک‌بارمصرف، زمان انقضا و Session policy است؛ مجوز نقش‌ها سمت سرور باقی می‌ماند. MFA، Recovery و Break-glass حساب‌های مدیریتی را طبق راهنمای MFA و Passkey جدا اجرا کنید.

Subname برای اعضا یا مشتریان

نامی مثل ali.community.eth ممکن است برای عضویت، Profile یا Entitlement مناسب باشد. اما دارنده Parent، قواعد Registry، انقضا و قابلیت Revoke/Transfer بر دوام Subname اثر دارند. پیش از صدور، قرارداد حقوق، Recovery، خروج داده و پایان همکاری را بنویسید.

Pointer وب غیرمتمرکز

Resolver می‌تواند Contenthash را به IPFS/IPNS یا سامانه سازگار اشاره دهد. این الگو برای Landing static، Documentation snapshot یا Artifact امضاشده ممکن است مناسب باشد؛ اما Checkout، Login، Search پویا، API و مدیریت سفارش همچنان زیرساخت Backend و عملیات می‌خواهند.

«مالکیت» را به شش حق قابل آزمون تجزیه کنید

عبارت «مالکیت واقعی» بدون تعریف حقوق عملیاتی بی‌معناست. در Due diligence، این شش مورد را مستقل ثبت کنید:

1. حق Transfer: چه حسابی می‌تواند نام یا Token را انتقال دهد؟
2. حق Record update: چه کسی Resolver، Address و Contenthash را تغییر می‌دهد؟
3. حق Renewal: مدت، Grace period، Premium و Payment asset چیست؟
4. حق Subname: Parent یا Registry فرزند چه اختیار Revoke/Expire/Upgrade دارد؟
5. حق Protocol change: Governance، Admin key، Upgradeability و Emergency control کجاست؟
6. حق قانونی: قرارداد Provider، علامت تجاری، صلاحیت قضایی و مسیر اختلاف چیست؟

کنترل Private key فقط یکی از این حقوق است. اگر نام در Wallet تک‌امضایی کارمند نگه‌داری شود، خروج کارمند یا گم‌شدن Seed می‌تواند دارایی نام و همه رکوردهایش را گروگان بگیرد. برای نام سازمانی، Custody policy، Multisig یا Account abstraction ارزیابی‌شده، نقش‌های جدا و Recovery drill لازم است.

نام خوانا را چگونه برای پرداخت امن کنیم؟

پیش از تراکنش

• نام را با UTS/Normalization همان پروتکل Canonicalize کنید؛ رشته نمایش‌داده‌شده و رشته Resolution‌شده را ثبت کنید.
• Chain، Asset/Coin type و Contract شبکه را صریح نمایش دهید؛ از «Crypto address» مبهم پرهیز کنید.
• آدرس نهایی را کامل یا با امکان Copy/Inspect نشان دهید؛ فقط Avatar یا نام کافی نیست.
• Forward/Reverse match را Signal بگیرید، نه مجوز خودکار.
• برای نخستین پرداخت یا تغییر رکورد، تأیید Out-of-band و انتقال آزمایشی کوچک بخواهید.

حین و بعد از تراکنش

• Intent شامل Order/Invoice، Amount، Recipient، Chain و Asset را پیش از Signature Freeze کنید.
• اگر رکورد میان Quote و Sign عوض شد، تراکنش را Abort و دوباره تأیید کنید.
• Address book تأییدشده را با Version و Last-verified نگه دارید؛ Cache بی‌انتها نداشته باشید.
• Tx hash را با Invoice نگاشت کنید و Pending، Confirmed، Failed، Reorged و Refunded را جدا نگه دارید.
• Callback مرورگر را مدرک تسویه ندانید؛ Backend از منبع معتبر وضعیت را Reconcile کند.

if namespace != approved_namespace: STOP
if chain_id != invoice.chain_id: STOP
if resolved_address != previewed_address: STOP
if record_version_changed: REQUIRE_RECONFIRMATION
if amount > threshold and contact_not_verified: STOP

اگر نام بلاکچینی در Checkout استفاده می‌شود، کنترل‌های State machine، Idempotency و Verify مقاله اتصال امن درگاه پرداخت را نیز اجرا کنید؛ تفاوت Rail پرداخت، اصول تطبیق سفارش را حذف نمی‌کند.

وب‌سایت ENS و IPFS: Integrity با Availability یکی نیست

در معماری رایج، Resolver نام یک Contenthash می‌دهد و Client/Gateway محتوای متناظر را از IPFS می‌گیرد. طبق مستندات رسمی Persistence در IPFS، داشتن CID تضمین نمی‌کند محتوا همیشه در شبکه قابل دریافت باشد؛ Nodeها ممکن است Cache را پاک کنند و Pinning/Storage sponsorship لازم است.

برای دارایی حیاتی، CID، Size، MIME، Build commit، Signature، Pin locations و تاریخ آخرین Fetch را در Release manifest ثبت کنید. Probe باید از شبکه‌ها و Resolverهای واقعی کاربران اجرا شود، نه فقط Node توسعه‌دهنده.

ماتریس سازگاری را با نام محصول نسازید؛ با مسیر Resolution بسازید

نتیجه تست را با تاریخ، Device، OS، App version، Network، Resolver، Chain و Outcome ذخیره کنید. عبارت «Chrome پشتیبانی می‌کند» بدون نسخه و روش Resolution سند قابل اتکا نیست.

Name Collision؛ یک Label، دو پاسخ

Name collision زمانی رخ می‌دهد که رشته‌ای در دو فضای نام یا Context متفاوت به مقصدهای متفاوت Resolve شود. کاربری که brand.example را در Wallet وارد می‌کند ممکن است نتیجه سامانه A را ببیند، اما Browser/Resolver سازمانی همان رشته را در DNS یا سامانه B جست‌وجو کند. گزارش ICANN درباره فضای نام جایگزین این Fragmentation، نتیجه پیش‌بینی‌ناپذیر و هزینه پشتیبانی/امنیت را توضیح می‌دهد.

این ریسک فقط نظری نیست. ICANN Name Collision برخورد را مسئله‌ای برای Stability و Security نام‌گذاری می‌داند. نبود یک Label در Root امروز نیز تضمین نمی‌کند هر Client در آینده همان معنا را بدهد. خرید یک نام در سامانه خصوصی یا بلاکچینی، حق رزرو جهانی آن رشته را ایجاد نمی‌کند.

کنترل‌های سازمانی Collision

• Namespace و Resolver مجاز را در Configuration و Telemetry صریح کنید.
• در UI فقط Label را نشان ندهید؛ Context مانند ENS / Ethereum را نمایش دهید.
• از Search suffix، Resolver عمومی ناشناخته و Split-horizon hack برای کاربر عمومی پرهیز کنید.
• رشته‌های استفاده‌شده در شبکه داخلی، Certificate، ایمیل و DNS عمومی را Inventory کنید.
• برای هر Resolution، نتیجه، Source و Chain را Audit log کنید؛ داده حساس را Hash/Redact کنید.
• اگر Ambiguity دیده شد، Fail closed و کاربر را به نام DNS رسمی هدایت کنید.

نام بلاکچینی «هویت خودمختار» را خودکار نمی‌سازد

Profileهای عمومی همچنین Graph ارتباطی می‌سازند: آدرس‌ها، Avatar، URL و فعالیت‌ها می‌توانند به هم پیوند بخورند. «On-chain» را مترادف Private نگیرید؛ Data minimization را پیش از انتشار اجرا کنید.

نام، برند و حقوق اختلاف

ثبت یک Label مشابه علامت تجاری لزوماً حق قانونی ایجاد نمی‌کند و ثبت علامت نیز الزاماً Recovery فنی نام را تضمین نمی‌کند. هر Namespace ممکن است قرارداد Provider، DAO policy، Court response یا مسیر اختلاف متفاوتی داشته باشد. پیش از نام عمومی:

• علامت‌ها، نام تجاری و دامنه‌های DNS مرتبط را با مشاور واجدصلاحیت بررسی کنید.
• Terms، Eligibility، Governing law، Suspension، Takedown، Dispute و Appeal را Snapshot کنید.
• ثبت‌کننده، Beneficial owner، Controller و هزینه تمدید را در Asset register بنویسید.
• از ادعای «Official» فقط پس از Verification در کانال DNS/وب رسمی استفاده کنید.
• Impersonation و Confusableها را مانیتور کنید؛ صرف خرید دفاعی همه Variantها ممکن یا کافی نیست.

برای حاکمیت Registrar، Renewal، Portfolio و Incident دامنه عمومی، راهنمای انتخاب و ثبت امن دامنه را مبنا قرار دهید.

معماری پیشنهادی: DNS اصلی، نام بلاکچینی اختیاری

Public web / SEO / Email / TLS
  canonical: example.ir or example.com
  authoritative DNS + DNSSEC + HTTPS + CDN

Optional Web3 layer
  brand.eth → verified wallet records / contenthash / profile
  official DNS page → network + contract + full addresses
  wallet/dApp → approved resolver → confirmation → transaction

Fallback
  unsupported client / gateway / RPC / incident
  → canonical DNS page + status + manual verified address

این الگو Reach را از Capability جدا می‌کند. دامنه DNS مالک صفحه Canonical، Help، Status، ایمیل و Announcement است. نام بلاکچینی یک Alias برای کاربران واجد شرایط است و از همان صفحه رسمی تأیید می‌شود. در سایت غیرمتمرکز نیز rel=canonical به نسخه اصلی کمک می‌کند Duplicate/Fragmentation محتوایی نسازید.

Baseline امنیت DNS را حذف نکنید

DNSSEC، Lock، MFA Registrar، Change control و Monitoring همچنان لازم‌اند. نام بلاکچینی نقص DNS، TLS، ایمیل یا حساب Registrar را درمان نمی‌کند. Runbook کامل این لایه در مدیریت DNS، DNSSEC و TTL آمده است.

انتخاب TLD عمومی را مستقل نگه دارید

برای بازار ایران، اعتماد کاربر، تمدید، ایمیل، Universal Acceptance و حقوق، انتخاب .ir، .com یا gTLD تصمیم جداگانه‌ای است. راهنمای انتخاب بهترین پسوند دامنه این Intent را پوشش می‌دهد؛ نام بلاکچینی جای آن را نمی‌گیرد.

چه زمانی دامنه بلاکچینی مناسب است؟

Gate: اگر همان Outcome با QR، Address book، Link تأییدشده یا Subdomain DNS با هزینه و ریسک کمتر حاصل می‌شود، Baseline ساده‌تر را انتخاب کنید. «Web3 بودن» Outcome نیست.

Scorecard انتخاب Namespace یا Provider

امتیاز کمتر از حد بحرانی در Security، Recovery، Eligibility یا Exit را با مجموع بالا جبران نکنید؛ این‌ها Knockout هستند. ادعای Vendor را با Contract، Transaction و Test client راستی‌آزمایی کنید.

نسخه ایران: پیش از خرید و Launch چه چیزهایی را بررسی کنیم؟

• Eligibility و Terms: ثبت‌نام، Wallet، RPC، Gateway، Marketplace، Custody و Support ممکن است محدودیت جغرافیایی یا تغییر Terms داشته باشند. وضعیت همان روز را بررسی و مستند کنید؛ راه دورزدن محدودیت طراحی نکنید.
• پرداخت و Gas: هزینه فقط Registration نیست؛ Gas، تمدید، Swap، برداشت، Custody، حسابداری و Incident نیز TCO هستند. Low/likely/high بسازید.
• شبکه: دسترسی ISPها، Mobile/Desktop، DNS/Proxy سازمانی، RPC و Gateway را از داخل و خارج ایران اندازه بگیرید. نتیجه یک اپراتور را عمومی نکنید.
• فارسی و Unicode: نیم‌فاصله، حروف عربی/فارسی ی/ک، ارقام، RTL/BiDi و Confusableها را در ثبت، نمایش، Copy و Search تست کنید. نام ASCII ساده معمولاً Recovery و Support آسان‌تری دارد.
• حقوق و مالیات: نوع دارایی، پرداخت، درآمد، Custody، علامت و تعهد مشتری را با متخصص حقوقی/مالی مرتبط بررسی کنید؛ این مقاله حکم حقوقی یا مالیاتی نیست.
• پشتیبانی: Runbook فارسی، صفحه وضعیت روی DNS عمومی، کانال Escalation و Export مستقل از Provider داشته باشید.

برای کسب‌وکار ایرانی، بزرگ‌ترین ریسک معمولاً خود Contract نیست؛ زنجیره Dependency از Wallet و RPC تا Gateway، پرداخت، Support و دسترسی است. Pilot باید همین زنجیره را End-to-end بسنجد.

Pilot شش‌هفته‌ای؛ قبل از پول واقعی، Resolution را Shadow کنید

هفته ۱: قرارداد مسئله و Baseline

Cohort، Job، Baseline، خطاهای فعلی Copy/Paste، Outcome، Guardrail و Owner را ثبت کنید. نمونه: «کاهش خطای ورود آدرس برای ۵۰ کاربر حرفه‌ای، بدون افزایش Wrong-network near miss».

هفته ۲: معماری و Threat model

Namespace/Chain/Contracts، Resolver path، Key custody، Providerها، Data map، Legal gate و Fallback را رسم کنید. Collision، Record compromise، Lost key، Expiry و Gateway outage را روی میز اجرا کنید.

هفته ۳: Shadow resolution

نام را بدون اجازه ارسال پول Resolve کنید؛ نتیجه را کنار آدرس دستی مقایسه و Mismatch، Latency و Unsupported client را ثبت کنید. هیچ Action خودکار از خروجی Shadow ساخته نشود.

هفته ۴: Cohort بسته و مبلغ محدود

با Testnet یا سقف مالی کوچک، Preview، Chain/Asset label، Address confirmation، Test transfer و Reconciliation را بسنجید. Support در لحظه حاضر باشد.

هفته ۵: Failure injection و Recovery drill

RPC timeout، رکورد تغییرکرده، Name expiry نزدیک، Gateway down، Client unsupported و Key recovery را شبیه‌سازی کنید. Fail-safe و DNS fallback باید بدون توضیح شفاهی تیم کار کند.

هفته ۶: Investment gate

فقط اگر Outcome افزایشی، Error budget، Support load، Eligibility و TCO پذیرفتنی‌اند، Cohort را تدریجی افزایش دهید. نتیجه «ادامه ندادن» نیز خروجی موفق Pilot است.

پنج Runbook که باید پیش از Launch آماده باشند

۱. Key یا Account کنترل‌کننده گم/مشکوک شد

1. ارسال و تغییر رکورد را Freeze و Incident commander تعیین کنید.
2. Ownership/Controller/Resolver و Transactionهای اخیر را از منبع مستقل Snapshot کنید.
3. Recovery/Multisig را طبق Policy اجرا کنید؛ Seed را در تیکت یا پیام‌رسان نفرستید.
4. کنترل را به Account سالم منتقل، نقش‌های قدیمی را Revoke و مانیتور کنید.
5. صفحه DNS رسمی را به‌روزرسانی و Post-incident review ثبت کنید.

۲. Resolver یا آدرس مقصد تغییر غیرمنتظره داشت

1. پرداخت به نام را Fail closed کنید.
2. Chain، Block، Contract، Resolver و Record history را ثبت کنید.
3. تغییر مجاز، خطای Deployment یا Compromise را تفکیک کنید.
4. رکورد تأییدشده را با Approval دو نفره برگردانید.
5. Address bookها و کاربران اثرپذیرفته را اطلاع دهید؛ پرداخت‌ها را Reconcile کنید.

۳. نام نزدیک انقضا یا منقضی شد

1. وضعیت Registrar/Contract و Grace period فعلی را مستقیم بررسی کنید.
2. تمام Aliasها را موقتاً به DNS رسمی هدایت و تراکنش جدید را متوقف کنید.
3. Renewal را از حساب سازمانی با Evidence انجام دهید.
4. Resolution را در Clientهای کلیدی دوباره تست کنید.
5. هشدارهای ۹۰/۶۰/۳۰/۱۴/۷/۱روزه و Backup owner را اصلاح کنید.

۴. Collision یا پاسخ مبهم دیده شد

1. Client/Network/Resolver/Namespace دقیق را ثبت کنید.
2. از Auto-fallback میان سامانه‌ها جلوگیری کنید.
3. نام و Context کامل را در UI نشان دهید و پرداخت را متوقف کنید.
4. Route امن DNS را منتشر و Scope کاربرهای اثرپذیرفته را مشخص کنید.
5. در صورت تکرار، Namespace را از Product خارج یا نام را تغییر دهید.

۵. IPFS/Gateway در دسترس نیست

1. CID را از چند Node و Gateway مستقل Fetch کنید تا Persistence از Gateway جدا شود.
2. Pin status و Provider billing/eligibility را بررسی کنید.
3. اگر محتوا موجود است، Gateway/Route ثانویه را فعال کنید.
4. اگر محتوا گم شده، Artifact امضاشده را از Backup Re-pin و Contenthash را با Approval تغییر دهید.
5. DNS mirror/Status را فعال و Availability probe را اصلاح کنید.

چک‌لیست Go/No-go

• مسئله، Cohort، Baseline، Outcome و Counterfactual مشخص‌اند.
• Namespace، Chain، Registry، Registrar، Resolver و Record type ثبت شده‌اند.
• Current production از Alpha/Proposal/Future جدا شده است.
• حق Transfer، Update، Renewal، Subname، Governance و حقوق قانونی روشن است.
• Key custody، Role separation، Recovery و Drill تأیید شده‌اند.
• نام DNS رسمی، HTTPS، ایمیل، SEO و Status page حفظ شده‌اند.
• Browser/Wallet/dApp/Gateway/Corporate network با نسخه و تاریخ تست شده‌اند.
• Name collision، Unicode/RTL و Confusableها آزموده شده‌اند.
• پرداخت، Chain/Asset preview، Address confirmation و Reconciliation دارند.
• IPFS حداقل دو Pin، Probe و DNS fallback دارد.
• Privacy، Legal، Eligibility، Terms و ایران Evidence دارند.
• TCO شامل Registration، Renewal، Gas، Provider، People، Support، Risk و Exit است.
• KPI، Guardrail، Stop criteria و پنج Runbook تمرین شده‌اند.

سؤالات متداول دامنه بلاکچینی

آیا دامنه بلاکچینی جای دامنه .ir یا .com را می‌گیرد؟

برای اغلب کسب‌وکارها خیر. DNS عمومی همچنان مسیر استاندارد وب، ایمیل، TLS، SEO و دسترسی مرورگر است. نام بلاکچینی را به‌عنوان Alias اختیاری برای Wallet، dApp یا Contenthash با Fallback نگه دارید.

آیا خرید دامنه بلاکچینی مالکیت دائمی می‌دهد؟

قواعد Namespace تعیین‌کننده‌اند. ENS تولیدی ثبت و تمدید مدت‌دار و Grace period دارد؛ Key، Controller، Parent، قرارداد و Governance نیز بر کنترل اثر دارند. پیش از خرید، حقوق عملیاتی و Renewal را مستقیم بررسی کنید.

آیا ارسال رمزارز به نام ENS امن‌تر از آدرس است؟

خواناتر است، اما خودبه‌خود امن‌تر نیست. Resolver خراب یا رکورد تغییرکرده، Network/Asset اشتباه، نام مشابه و Cache قدیمی خطر می‌سازند. آدرس نهایی، Chain و Asset را نشان دهید و برای مقصد جدید تأیید مستقل و انتقال کوچک داشته باشید.

آیا وب‌سایت روی IPFS هرگز قطع نمی‌شود؟

خیر. CID یکپارچگی محتوا را کمک می‌کند، نه ماندگاری و دسترسی همیشگی را. Pinning روی چند Node/Provider، Gatewayهای مستقل، Probe و نسخه DNS/CDN لازم‌اند.

کسب‌وکار ایرانی از کجا شروع کند؟

از Shadow resolution بدون پول واقعی شروع کنید؛ سپس Cohort کوچک، سقف مالی پایین، DNS fallback، تست شبکه/Provider داخل ایران، کنترل Key و Runbook را اجرا کنید. اگر Eligibility، Recovery یا Reconciliation مبهم است، Launch نکنید.