بلاکچین در توسعه وب؛ DID، NFT و معماری امن

یک تیم بلیت رویداد را NFT می‌کند تا «جعل غیرممکن» شود؛ اما تصویر بلیت روی یک سرور عادی است، ادمین می‌تواند Metadata را عوض کند، قرارداد کلید ارتقا دارد و گیت ورودی فقط Screenshot کیف پول را می‌بیند. Blockchain اضافه شده، ولی مسئله اعتماد حل نشده است—فقط مرزهای شکست جابه‌جا شده‌اند.

بلاکچین در توسعه وب زمانی ارزش دارد که چند طرفِ با منافع متفاوت باید روی یک State مشترک توافق کنند، کاربر به قابلیت راستی‌آزمایی مستقل یا انتقال دارایی نیاز دارد و هزینه شفافیت عمومی، کلید، تراکنش و عملیات قابل قبول است. برای Login معمولی، امتیاز وفاداری داخلی یا پایگاه داده‌ای که یک سازمان مالک آن است، معماری متمرکز اغلب ساده‌تر، ارزان‌تر و قابل بازیابی‌تر است.

بلاکچین در توسعه وب چیست؟

Blockchain یک دفترکل تکثیرشده است که مشارکت‌کنندگان طبق قواعد شبکه بر ترتیب و اعتبار تغییرات آن توافق می‌کنند. Smart contract کدی است که State روی زنجیره را طبق ورودی و قواعد مشخص تغییر می‌دهد. این مدل می‌تواند قابلیت راستی‌آزمایی و انتقال بدون دیتابیس یک اپراتور واحد ایجاد کند، اما جای همه اجزای Backend را نمی‌گیرد.

یک dApp واقعی معمولاً هنوز Frontend، دامنه، RPC provider، Indexer، API، پایگاه داده Off-chain، Storage، Oracle، Analytics و تیم پشتیبانی دارد. بنابراین «روی Blockchain است» مساوی «غیرمتمرکز، همیشه‌فعال، خصوصی یا امن» نیست.

Web3 تعریف واحدی ندارد

Web3 اصطلاحی چتری برای برنامه‌هایی است که از Wallet، Token، Smart contract، شبکه همتا‌به‌همتا یا هویت قابل‌راستی‌آزمایی استفاده می‌کنند. آن را نسخه‌ای که خودکار Web2 را حذف می‌کند فرض نکنید. بسیاری از محصولات Hybrid هستند: بخشی از State روی زنجیره و بخش عمده تجربه، جست‌وجو، داده شخصی و عملیات در Web معمولی اجرا می‌شود.

آزمون ضرورت؛ چه زمانی Blockchain واقعاً لازم است؟

پیش از انتخاب شبکه یا زبان، یک Baseline متمرکز بنویسید. اگر همان Outcome با Database، امضای دیجیتال استاندارد، API یا Audit log قابل اعتماد حاصل می‌شود، تیم باید دلیل هزینه و پیچیدگی اضافه را اثبات کند.

یک قاعده مفید: اگر پاسخ «چرا Blockchain؟» فقط شفافیت، امنیت یا آینده‌نگری است، Use case هنوز تعریف نشده است. باید Actor، State، Threat، Verification و Alternative مشخص باشند.

Use-case Contract را قبل از معماری بنویسید

Actor: چه اشخاص/سازمان‌هایی می‌نویسند، می‌خوانند و تأیید می‌کنند؟
Shared state: دقیقاً چه رکورد یا حق باید مشترک باشد؟
Trust gap: کدام طرف نمی‌تواند اپراتور واحد را بپذیرد؟
Assurance: امضا چه چیزی را ثابت می‌کند و چه چیزی را نه؟
Privacy: چه چیزی عمومی، قابل هم‌بستگی یا قابل حذف است؟
Authority: چه کسی صادر، لغو، ارتقا، Pause یا بازیابی می‌کند؟
Failure: RPC، Chain، Oracle، Wallet، Key یا Storage چگونه خراب می‌شود؟
Alternative: Database/API/PKI/Passkey چه Outcomeای می‌دهد؟
Acceptance: Success، latency، cost، critical error و recovery چیست؟
Exit: داده، دارایی، کلید و کاربر چگونه مهاجرت می‌کنند؟

برای تعریف Contractهای API، Idempotency و Failure semantics از راهنمای طراحی Web API استفاده کنید؛ تراکنش زنجیره فقط یکی از Integrationهای سیستم است.

معماری dApp؛ مسیر واقعی یک درخواست

به‌جای رسم یک خط Frontend→Blockchain، مسیر کامل را ثبت کنید:

1. Browser یا Mobile app Provider کیف پول را پیدا می‌کند.
2. کاربر شبکه/Account را انتخاب و یک Message یا Transaction را می‌بیند.
3. Frontend از RPC برای Read، Estimate یا Submit استفاده می‌کند.
4. Transaction در Mempool، Block و مراحل Finality حرکت می‌کند.
5. Indexer Eventها را به Query قابل استفاده تبدیل می‌کند.
6. Backend، Session، Authorization، Notification و Reconciliation را انجام می‌دهد.
7. Metadata یا فایل از IPFS/Storage/Gateway بازیابی می‌شود.
8. Oracle یا Admin داده جهان بیرون را وارد می‌کند.

برای هر گام Owner، Trust boundary، Timeout، Retry، Idempotency، Source of truth و Recovery تعیین کنید. Retry کور تراکنش می‌تواند پرداخت یا Mint تکراری بسازد؛ Event ممکن است دیر، تکراری یا پس از Reorg تغییر وضعیت دهد.

بودجه عدم تمرکز؛ هر وابستگی را آشکار کنید

Decentralization یک کلید روشن/خاموش نیست. یک پروژه ممکن است قرارداد عمومی داشته باشد اما Domain، RPC، Upgrade key، Indexer و Metadata همه زیر کنترل یک شرکت باشند. این لزوماً بد نیست؛ مشکل وقتی است که Marketing با معماری واقعی نمی‌خواند.

DID چیست و چه چیزی نیست؟

Decentralized Identifier یا DID یک شناسه با قالب did:method:specific-id است که رفتار آن را DID Method تعیین می‌کند. استاندارد DID Core ۱.۰ کنسرسیوم W3C صریح است که بسیاری—نه همه—DID methodها از دفترکل توزیع‌شده استفاده می‌کنند. پس DID مترادف Blockchain، Wallet address یا «هویت واقعی» نیست.

DID Document معمولاً روش‌های Verification و گاهی Service endpoint را توصیف می‌کند. Controller ممکن است فرد، سازمان یا سیستم باشد؛ Subject و Controller نیز همیشه یک موجودیت نیستند. کنترل کلید فقط نشان می‌دهد دارنده فعلی می‌تواند عمل رمزنگاری تعریف‌شده را انجام دهد، نه اینکه سن، نام قانونی یا صلاحیت او چیست.

Verifiable Credential؛ نقش Issuer، Holder و Verifier

در مدل W3C Verifiable Credentials Data Model 2.0، Issuer درباره Subject ادعا صادر می‌کند، Holder آن را نگه می‌دارد و به‌صورت Presentation به Verifier می‌دهد. Verifier باید علاوه بر امضا، Schema، Issuer، Status، زمان و Policy کسب‌وکار خود را بررسی کند.

نکته مهم استاندارد: «Verifiable» بودن به معنی درست‌بودن Claim نیست. امضای معتبر نشان می‌دهد Credential/Presentation طبق روش مشخص از Issuer/Presenter آمده و دست‌کاری نشده؛ Verifier هنوز باید تصمیم بگیرد آیا Issuer برای آن Claim معتبر است و Evidence صدور کافی بوده است.

Selective Disclosure خودکار نیست

مثال «اثبات بالای ۱۸ سال بدون افشای تاریخ تولد» فقط وقتی عملی است که Issuer، قالب Credential، Cryptosuite و Presentation protocol از افشای انتخابی یا Claim مشتق‌شده پشتیبانی کنند. داشتن DID یا ذخیره Credential در Wallet به‌تنهایی این قابلیت را ایجاد نمی‌کند.

W3C VC ۲.۰ توصیه می‌کند Verifier فقط داده کاملاً لازم را درخواست کند و روش‌های Selective/Unlinkable disclosure را با توجه به حریم خصوصی انتخاب کند. در Pilot این موارد را بسنجید:

• آیا Presentation بین دو Verifier قابل هم‌بستگی است؟
• Status check به Issuer خبر می‌دهد Holder کجا Credential را استفاده کرده است؟
• Claim مشتق‌شده دقیقاً چه چیزی را اثبات می‌کند؟
• Wallet و Verifier واقعاً Suite/Profile مشترک دارند؟
• در Revocation، Expiry، Key rotation و Lost wallet چه می‌شود؟

معماری عملی DID/VC

برای گواهی دوره آموزشی، مسئله را به «ثبت NFT» تقلیل ندهید. جریان کامل چنین است:

1. Governance: چه مؤسسه‌ای Issuer معتبر است و Scope او چیست؟
2. Proofing: هویت دانشجو و نتیجه دوره چگونه تأیید می‌شود؟
3. Issuance: Schema، زبان، تاریخ، Evidence و Expiry چیست؟
4. Holding: Credential کجا نگهداری و چگونه Backup/Recover می‌شود؟
5. Presentation: Verifier چه Claim حداقلی درخواست می‌کند؟
6. Verification: Key، Status، Issuer registry و Policy چگونه بررسی می‌شوند؟
7. Lifecycle: اصلاح نام، لغو مدرک، چرخش کلید و خروج Issuer چه می‌شود؟
8. Appeal: Subject چگونه خطا را گزارش و Credential اصلاح‌شده دریافت می‌کند؟

ممکن است Blockchain برای Registry کلید یا Status مفید باشد؛ ممکن است DID Method غیرزنجیره‌ای یا PKI متداول بهتر باشد. انتخاب را با Interoperability و Threat model انجام دهید، نه با نام فناوری.

ورود با Wallet با DID/VC فرق دارد

Wallet login معمولاً اثبات کنترل یک Account و سپس ایجاد Session وب است. در Ethereum، ERC-۴۳۶۱ یا Sign-In with Ethereum قالب Message شامل Domain، URI، Chain ID، Nonce، Issued At و فیلدهای زمانی اختیاری را تعریف می‌کند. Nonce از Replay جلوگیری می‌کند و Domain/URI باید به Origin مورد انتظار Bind شود.

1) Server یک nonce یک‌بارمصرف و کوتاه‌عمر می‌سازد
2) Client پیام خوانا با domain/URI/chain/time می‌سازد
3) Wallet پیام دقیق را به کاربر نشان می‌دهد و امضا می‌کند
4) Server امضا، account type، domain، nonce، time و chain را می‌سنجد
5) nonce مصرف و session محدود با CSRF/session controls صادر می‌شود
6) تغییر account/chain، logout، expiry و recovery مدیریت می‌شود

امضای Message مجوز برداشت Token نیست، ولی کاربر نمی‌تواند هر Hex یا متن مبهمی را کورکورانه امضا کند. UI باید نوع درخواست، Domain، هدف، Resource و نتیجه را توضیح دهد. برای Accountهای قراردادی نیز Verification با EOA یکسان نیست و باید روش سازگار پیاده شود.

Wallet address هویت و Authorization کامل نیست

کنترل آدرس در لحظه امضا معمولاً نام قانونی، سن، نقش سازمانی یا صلاحیت را ثابت نمی‌کند. همچنین Authentication با Authorization فرق دارد. پس از Login هنوز باید بررسی کنید این Actor روی کدام Resource و Action حق دارد.

• Session را به Tenant/User mapping نسخه‌دار وصل کنید.
• Object-level و Function-level authorization را Server-side اعمال کنید.
• برای تغییر Wallet، Proof از قدیم و جدید یا Recovery کنترل‌شده داشته باشید.
• برای Admin فقط Wallet login را جای تمام کنترل‌های قوی نگذارید.
• قراردادهای Account abstraction/Smart wallet و Signature schemeها را در Test matrix بگنجانید.

راهنمای امنیت API و Authorization مرز Endpoint و Resource را پوشش می‌دهد؛ مقاله MFA، Passkey و بازیابی پنل نیز برای حساب‌های پرقدرت مکمل این بخش است.

NFT چیست؟ Token با Asset یکی نیست

ERC-721 یک Interface استاندارد برای ردیابی و انتقال Token غیرقابل تعویض تعریف می‌کند. Metadata extension در آن اختیاری است و tokenURI می‌تواند به JSON بیرون زنجیره اشاره کند؛ خود استاندارد حتی امکان Mutable بودن URI را در نظر می‌گیرد. ERC-1155 نیز چند نوع Token قابل‌تعویض، غیرقابل‌تعویض یا نیمه‌قابل‌تعویض را در یک Contract مدیریت می‌کند.

برای هر NFT پنج لایه را جدا کنید:

خرید Token لزوماً Copyright تصویر را منتقل نمی‌کند. License، قرارداد فروش، Terms، Jurisdiction و رابطه Issuer با Asset باید بررسی شود. عبارت «گواهی مالکیت دیجیتال» بدون بیان اینکه مالکیتِ دقیقاً چه چیزی است، می‌تواند گمراه‌کننده باشد.

Metadata و IPFS؛ Content-addressed یعنی همیشه‌دردسترس نیست

در IPFS، CID از محتوای فایل ساخته می‌شود؛ تغییر محتوا CID تازه‌ای می‌سازد و Integrity قابل بررسی است. اما مستندات رسمی IPFS درباره Persistence می‌گوید شبکه Availability دائمی را خودکار تضمین نمی‌کند. داده باید روی Nodeها Pin و هزینه نگهداری آن تأمین شود.

برای NFT یا مدرک:

• ipfs:// را Canonical و Gateway را Presentation layer ببینید؛
• Metadata و Media را جداگانه Content-address کنید؛
• حداقل دو Pin/Storage failure domain و Retrieval test دوره‌ای داشته باشید؛
• منبع بودجه نگهداری بعد از پایان پروژه را مشخص کنید؛
• PII یا Secret را روی شبکه عمومی Upload نکنید؛
• Mutable metadata، Freeze policy و Migration path را آشکار کنید؛
• اگر Asset حذف غیرقابل‌پیش‌بینی می‌خواهد، معماری عمومی immutable را بازنگری کنید.

کاربردهای NFT را با Alternative مقایسه کنید

اگر Portability و بازار ثانویه برای Outcome لازم نیست، Transferability می‌تواند تقلب و پشتیبانی را بیشتر کند. قابلیت فنی را منفعت قطعی تلقی نکنید.

Token gating را فقط در Frontend اجرا نکنید

پنهان‌کردن دکمه پس از balanceOf کنترل دسترسی نیست. Backend باید Session و Ownership را با Block/finality policy مشخص بررسی کند و درباره انتقال Token در میانه Session تصمیم داشته باشد.

• Contract address، Chain ID و Token ID را Allowlist کنید؛ Name/Symbol کافی نیست.
• Snapshot یا Freshness window را برای هر Action تعیین کنید.
• Transferred، borrowed، delegated، wrapped یا stolen Token را در Threat model ببینید.
• برای Content ارزشمند، URL ثابت یا فایل عمومی را «Token-gated» ننامید.
• Cache key باید Entitlement را در نظر بگیرد و پس از Revocation پاک شود.
• در Outage، Fail-open یا Fail-closed را بر اساس Risk انتخاب کنید.

Smart contract «خوداجرا» است، نه خودایمن

Contract منتشرشده می‌تواند Logic error، Access control ضعیف، External call خطرناک یا Oracle قابل دست‌کاری داشته باشد. OWASP Smart Contract Top 10:2025 دسته‌هایی مانند Access Control، Oracle Manipulation، Logic Error، Input Validation، Reentrancy، Unchecked External Call، Insecure Randomness و DoS را برجسته می‌کند.

امنیت را از Spec شروع کنید:

1. Invariantها، نقش‌ها، Asset flow و حالات شکست را بنویسید.
2. حداقل Privilege، Admin separation، Pause و Emergency path را طراحی کنید.
3. Unit، integration، invariant، fuzz و fork/replay test متناسب اجرا کنید.
4. Compiler، dependency، deploy parameters و Source verification را Pin کنید.
5. بازبینی مستقل انجام دهید؛ Audit تضمین نبود Bug نیست.
6. Canary/cap/allowlist و مقدار محدود را پیش از Scale به کار ببرید.
7. Event، Admin action، balance invariant و anomaly را Monitor کنید.
8. Incident، disclosure، pause/upgrade/migration و جبران را تمرین کنید.

راهنمای امنیت Smart Contract در ethereum.org نیز Testing، Independent review، Disaster recovery، Governance امن و کاهش Complexity را کنار هم قرار می‌دهد و Audit را Silver bullet نمی‌داند.

Immutability و Upgrade؛ هر دو Trade-off دارند

Contract غیرقابل ارتقا ریسک کلید Upgrade را کم می‌کند، اما Patchکردن Bug دشوار می‌شود. Proxy قابل ارتقا Recovery را ممکن می‌کند، اما Admin key، Storage layout، Governance و تغییر Rules را به Trust model اضافه می‌کند.

Upgradeability را در UI و Terms پنهان نکنید. کاربر باید بداند Rule، Metadata یا Utility قابل تغییر است و چه مکانیزم تأخیری/اعتراضی وجود دارد.

Oracle؛ Blockchain داده غلط را حقیقت نمی‌کند

Contract به‌طور طبیعی نمی‌داند بسته تحویل شده، دانشجو دوره را گذرانده یا کالای فیزیکی اصل است. Oracle یا Actor این Claim را وارد می‌کند. Consensus فقط توافق درباره State ورودی را ایجاد می‌کند، نه صحت جهان بیرون.

یک Oracle contract عملیاتی باید Source، Update frequency، Staleness threshold، Unit، Bounds، Aggregation، Conflict، Failure mode و Owner داشته باشد. برای رویدادهای حساس، چند منبع مستقل، Human dispute و امکان Freeze/Correction لازم است. «ردیابی شفاف زنجیره تأمین» بدون Capture قابل اعتماد در نقطه ورود، فقط تاریخچه‌ای دست‌نخورده از داده احتمالیِ غلط می‌سازد.

امنیت Frontend و Wallet بخشی از امنیت دارایی است

حتی Contract امن می‌تواند با Frontend آلوده، DNS hijack، Dependency مخرب یا Prompt امضای مبهم کاربران را به تراکنش خطرناک هدایت کند.

• Provider تزریقی را Trust کامل نکنید؛ Chain/Account change را مدیریت کنید.
• Domain، Contract، Function، Recipient، Amount، Token approval و Deadline را Preview کنید.
• از Unlimited approval پیش‌فرض پرهیز و Scope/Expiry حداقلی کنید.
• Transaction simulation را Signal بدانید، نه ضمانت.
• CSP، dependency lock، build provenance و Secret boundary را اجرا کنید.
• آدرس را فقط با چند کاراکتر ابتدا/انتها تأیید نکنید؛ Context و Address book بدهید.
• برای عملیات پرارزش Confirmation مستقل و Delay/Limit طراحی کنید.
• Revocation/approval cleanup و صفحه رسمی Contract address داشته باشید.

برای آزمون مسیر کامل Frontend، API، Authorization و Business logic، راهنمای تست نفوذ وب‌اپلیکیشن را در Scope قرار دهید؛ Contract audit جای Pentest سامانه را نمی‌گیرد.

کلید و Recovery؛ «کاربر مالک است» مسئولیت عملیاتی می‌سازد

Self-custody کنترل را افزایش می‌دهد، اما گم‌شدن Seed، فیشینگ، سرقت گوشی، فوت کاربر یا خطای امضا را نیز به تجربه محصول می‌آورد. از کاربر تازه‌کار انتظار مدیریت امن کلید بدون راهنما و Recovery نداشته باشید.

Recovery policy باید پیش از Launch، با کاربر واقعی و سناریوی حمله آزموده شود. Backup code روی همان دستگاه یا Support agent با اختیار نامحدود Recovery قابل اتکا نیست.

حریم خصوصی؛ دفترکل عمومی حافظه مشترک است

نام مستعار مساوی ناشناس نیست. Address و Transaction graph می‌توانند با داده Exchange، Analytics، Social profile یا رفتار زمانی هم‌بسته شوند. قرار دادن نام، ایمیل، شماره ملی، فایل Credential یا حتی Hash ساده یک مقدار کم‌دامنه روی زنجیره می‌تواند آسیب ماندگار بسازد.

• PII را Off-chain، رمزگذاری‌شده و دارای Retention نگه دارید.
• Hash را حذف‌شده یا ناشناس فرض نکنید؛ Salt/entropy و Dictionary attack را بسنجید.
• On-chain pointer را حداقلی و Purpose-bound کنید.
• Address reuse و Cross-context correlation را در UX کاهش دهید.
• Analytics و RPC leakage شامل IP، Address و درخواست‌ها را Data map کنید.
• Selective disclosure و Status check را برای Unlinkability واقعی Test کنید.
• حق اصلاح/حذف و تعارض با Immutability را پیش از جمع‌آوری حل کنید.

برای Scope، جریان داده، Vendor، Retention و Risk evidence از راهنمای بودجه و حاکمیت حریم خصوصی استفاده کنید.

UX تراکنش؛ Pending یک Spinner ساده نیست

کاربر ایرانی ممکن است با Wallet موبایل، شبکه ناپایدار، زبان انگلیسی Wallet، قیمت متغیر Fee و محدودیت Provider روبه‌رو باشد. State machine را دقیق نمایش دهید:

draft → wallet_requested → user_rejected
      → signed → submitted → pending
      → included → confirmations → final
      → replaced | dropped | reverted | reorged
      → reconciled | needs_support

Hash تراکنش را نشان دهید، اما Explorer تنها مسیر Support نباشد. Fee estimate، Network، Token/Amount، نتیجه قابل انتظار و برگشت‌پذیری را پیش از امضا روشن کنید. برای Rejected/Timeout/Replacement/Revert پیام عملی بنویسید و از عبارت عمومی «خطایی رخ داد» دوری کنید.

دسترس‌پذیری و فارسی در dApp

• Wallet modal با Keyboard، Focus، Screen reader و Zoom کار کند.
• Address و Hash در RTL به‌هم نریزد؛ بخش فنی را با dir="ltr" و Label روشن نشان دهید.
• مقدار، Decimal، Fee و واحد Token را قابل مقایسه و بدون گردکردن گمراه‌کننده نمایش دهید.
• تاریخ شمسی/میلادی و UTC/منطقه زمانی را صریح کنید.
• رنگ تنها نشانه Success/Pending/Failed نباشد.
• امضا و Transaction را در فارسی ساده توضیح دهید، اما متن استاندارد امضا را دست‌کاری نکنید.
• برای کاربری که Wallet ندارد، مسیر آموزش یا Alternative متناسب داشته باشید.

پیش از Scale، Flow اتصال، امضا، لغو، تغییر شبکه، بازیابی و Support را با کاربر هدف در تست کاربردپذیری مشاهده کنید؛ Completion در Testnet لزوماً فهم و اعتماد کاربر را ثابت نمی‌کند.

Performance، Availability و Finality

Latency فقط Block time نیست. Wallet interaction، RPC queue، inclusion، confirmation policy، Indexer lag، Gateway و Backend reconciliation جمع می‌شوند. برای Read و Write بودجه جدا بسازید.

Cache را Finality-aware و Reorg-aware کنید. UI نباید صرف دریافت Tx hash، خرید یا حق را نهایی اعلام کند. تعداد Confirmation/Finality بر اساس شبکه، ارزش و Threat model تعیین می‌شود؛ عدد ثابت جهانی ندارد.

Observability بدون نشت داده

Correlation ID را میان Intent داخلی، Session، Transaction hash، Event و Reconciliation نگه دارید، اما Seed، Private key، امضای قابل Replay یا PII را Log نکنید. Dashboard باید Contract version، Chain ID، RPC provider، Block، Function، outcome، revert reason، latency، gas/fee و business outcome را به هم وصل کند.

Alert فقط روی «Node down» کافی نیست. افزایش User rejection، Wrong-chain، Simulation mismatch، Revert، Indexer lag، Admin action، Oracle staleness، Pin retrieval failure و Entitlement mismatch را نیز پایش کنید.

هزینه واقعی Web3؛ Gas فقط یک ردیف است

TCO شامل Discovery، Contract design، Audit، Testnet/Mainnet deployment، RPC، Node، Indexer، Storage/Pinning، Wallet integration، Support، Key operations، Monitoring، Compliance، Incident، Upgrade و Exit است. هزینه فرصت UX و نرخ ریزش در Wallet onboarding را نیز حساب کنید.

TCO = setup + contract/security + infra/provider
    + per-transaction fees + support/recovery
    + compliance/risk reserve + change/upgrade + exit

Cost per accepted outcome = TCO relevant period
                          / successful, final, valid business outcomes

Cost per transaction بدون حذف Revert، Duplicate، Fraud و Support misleading است. برای ساخت Cost register، Actual-vs-Forecast و Exit trigger از مقاله هزینه‌های پنهان و TCO سایت استفاده کنید.

ملاحظات حقوقی و عملیاتی برای ایران

این مقاله مشاوره حقوقی یا سرمایه‌گذاری نیست. کاربرد Token ممکن است فقط یک بلیت فنی باشد یا با پرداخت، نگهداری دارایی، تبلیغ سرمایه‌گذاری، بازار ثانویه، جمع‌آوری سرمایه، مالیات، حمایت مصرف‌کننده، AML/KYB، داده شخصی و انتقال برون‌مرزی تلاقی کند. عنوان «Utility» به‌تنهایی ماهیت حقوقی را تعیین نمی‌کند.

• کاربرد، Flow پول/دارایی، Custody، طرف‌های قرارداد و قلمرو کاربر را مستند کنید.
• وضعیت حقوقی و شرایط Provider را در تاریخ تصمیم با متخصص محلی بررسی کنید.
• Eligibility استفاده از RPC، Wallet service، Cloud، Marketplace و پرداخت را فرض نکنید.
• تحریم، محدودیت حساب، ارز، پرداخت، شبکه و خروج Provider را سناریویی مدیریت کنید.
• قیمت Token را وعده سود یا ارزش پایدار معرفی نکنید.
• برای Refund، خطای شبکه، انتقال اشتباه، از دست‌رفتن کلید و شکایت مسیر فارسی داشته باشید.
• ریال/تومان، Decimal Token، تاریخ شمسی/میلادی و مالیات را Source-of-truth کنید.

اگر Use case شما پرداخت رمزارزی فروشگاه است، تحلیل Portfolio، Refund، Reconciliation، نوسان و ریسک حقوقی را در راهنمای روش‌های پرداخت فروشگاه جداگانه انجام دهید.

Vendor و Network Scorecard

به رتبه‌بندی ثابت «بهترین Blockchain» تکیه نکنید. Score را با Workload، Risk، Tooling، تیم، کاربران ایران و Exit evidence در تاریخ تصمیم ثبت کنید.

Test matrix از Contract تا تجربه کاربر

• Unit/Property: Role، arithmetic، invariant و edge case؛
• Fuzz: ورودی، ترتیب Call و State غیرمنتظره؛
• Integration: Wallet، RPC، Contract، Indexer، Storage و Backend؛
• Fork/Replay: State واقع‌گرایانه و Upgrade/migration؛
• Adversarial: Reentrancy، permission، oracle، signature/replay و Frontend compromise؛
• Failure: RPC outage، dropped/replaced Tx، Reorg، stale oracle و missing metadata؛
• Privacy: Address correlation، Log، RPC leakage، status phone-home و PII؛
• UX/A11y: mobile wallet، keyboard، RTL، rejection، wrong chain و recovery؛
• Economics: fee spike، spam، DoS، support load و cost/outcome؛
• Exit: Provider switch، rebuild index، repin، key rotation و contract migration.

Pilot؛ قبل از Mainnet Scale چه چیزی را ثابت کنیم؟

Testnet برای Functional test مفید است، اما Fee behavior، Liquidity، adversary و رفتار کاربر Mainnet را کامل بازنمایی نمی‌کند. Pilot را مرحله‌ای کنید:

1. Baseline متمرکز و Counterfactual را اندازه بگیرید.
2. Prototype بدون دارایی واقعی و با User test اجرا کنید.
3. Contract و عملیات را با Threat model و Independent review کامل کنید.
4. Internal pilot با Account/amount/volume cap و Kill switch اجرا کنید.
5. Limited live cohort با Monitoring، Support و Incident owner راه بیندازید.
6. فقط با عبور هم‌زمان Outcome، Security، Privacy، UX، Cost و Recovery Scale کنید.

Runbookهای ضروری

RPC یا Indexer قطع شده است

Read و Write را جدا تشخیص دهید، از Retry تکراری Transaction جلوگیری کنید، Provider دوم را با Health معنایی فعال کنید، Stale state را در UI اعلام و پس از بازیابی Eventها را از Checkpoint Reconcile کنید.

کلید Admin یا Issuer مشکوک شده است

Privilege/issuance را متوقف، Signerها را طبق Policy تعویض، Credential/Contract impact را مشخص، Event و Access log را حفظ و کاربران/Verifierهای متأثر را از کانال معتبر مطلع کنید. Rotation بدون آزمون قبلی را هنگام حادثه اختراع نکنید.

Bug قرارداد یا Oracle پیدا شده است

Cap/Pause را طبق Runbook اجرا، Exposure و State را Snapshot، Advisory هماهنگ منتشر، Fix/Migration را Independent review و Reconciliation/جبران را با Evidence انجام دهید. Audit قبلی را دلیل نادیده‌گرفتن گزارش ندانید.

Metadata یا فایل NFT در دسترس نیست

CID را از چند Gateway/Node بررسی، Pin replica را بازیابی، علت بودجه/Provider/GC را مشخص و Integrity را پیش از Restore تأیید کنید. اگر URI قابل تغییر است، تغییر و اختیار آن را شفاف ثبت کنید.

Credential غلط یا لغوشده پذیرفته شده است

Verifier policy، Issuer trust، Status freshness و Cache را Freeze کنید؛ تصمیم‌های متأثر را شناسایی، Appeal/Correction را فعال و علت را میان Issuance، Signature، Status یا Validation تفکیک کنید.

RACI حداقلی

برنامه اجرایی ۳۰/۶۰/۹۰روزه

روز ۱ تا ۳۰: Need و Trust map

• Actor/State/Trust/Threat و Alternative متمرکز را ثبت کنید.
• داده عمومی، PII، کلید، Asset و طرف‌های حقوقی را Map کنید.
• یک Capability انتخاب کنید؛ DID، VC، Wallet login و NFT را مخلوط نکنید.
• Acceptance، Hard fail، Owner و Stop criteria بنویسید.

روز ۳۱ تا ۶۰: Prototype و Evidence

• مسیر Wallet/VC/Transaction را بدون دارایی واقعی Prototype کنید.
• Architecture، dependency و decentralization budget را مستند کنید.
• Golden flow و Failure/Adversarial/Privacy test corpus بسازید.
• کاربر فارسی را برای Sign، Fee، Recovery و Error مشاهده کنید.
• TCO و Cost per accepted outcome را با سناریوی بد بسنجید.

روز ۶۱ تا ۹۰: Limited live و تصمیم

• Independent review و رفع یافته‌ها را کامل کنید.
• Key compromise، RPC outage، Bug و Metadata loss را تمرین کنید.
• Live cohort را با Cap، Alert، Support و Kill switch محدود کنید.
• Outcome را با Baseline مقایسه و هزینه/ریسک واقعی را ثبت کنید.
• Scale، Iterate، Centralize یا Stop را با شواهد Gate تصمیم بگیرید.

چک‌لیست پیش از انتشار Web3

• مسئله Trust و State مشترک بدون واژه‌های تبلیغاتی تعریف شده است.
• Alternative متمرکز و هزینه فرصت مقایسه شده است.
• مرز DID، VC، Wallet login و NFT برای تیم روشن است.
• هیچ PII/Secret/Seed ناخواسته روی زنجیره یا IPFS عمومی نیست.
• Issuer/Verifier/Contract/Oracle/Admin authority ثبت شده است.
• Token، Metadata، License، Utility و حق فیزیکی جدا مستندند.
• Nonce/domain/time/session و Authorization سمت سرور آزموده شده‌اند.
• Invariant، Access control، Upgrade/Pause و Oracle تست شده‌اند.
• Contract audit همراه با Frontend/API/Pentest و Monitoring است.
• Pinning، Retrieval، RPC، Indexer و Reconciliation fallback دارند.
• Wallet/Key recovery و Support برای کاربر واقعی قابل اجراست.
• UX فارسی، RTL، Accessibility، Fee و Stateهای Failure تست شده‌اند.
• Scope حقوقی، Provider eligibility و شرایط ایران تاریخ‌دار است.
• TCO، Cost/outcome، Stop rule، Incident و Exit drill ثبت شده‌اند.

جمع‌بندی؛ قابلیت قابل اثبات بسازید، نه برچسب Web3

بلاکچین وقتی ابزار مناسبی است که Trust gap مشخص، State مشترک و نیاز واقعی به راستی‌آزمایی یا انتقال مستقل وجود داشته باشد. DID می‌تواند بدون Blockchain کار کند؛ VC امضا را قابل بررسی می‌کند اما حقیقت Claim را نه؛ Wallet login فقط کنترل Account را نشان می‌دهد؛ و NFT رکورد Token است، نه خودکارِ فایل، Copyright یا خدمت پایدار.

یک Capability محدود را با Alternative متمرکز مقایسه کنید. معماری کامل Off-chain و On-chain، حقوق و حریم خصوصی، Security و Recovery، UX و TCO را در Pilot بسنجید. اگر ارزش افزوده فقط در Pitch دیده می‌شود و در Outcome قابل اندازه‌گیری نیست، حذف Blockchain می‌تواند بهترین تصمیم معماری باشد.

سوالات متداول

آیا هر اپلیکیشن Web3 باید از بلاکچین استفاده کند؟

خیر. Web3 تعریف واحدی ندارد و بعضی قابلیت‌های هویت یا Peer-to-peer بدون Blockchain ممکن‌اند. Blockchain زمانی توجیه دارد که چند طرف مستقل به State مشترک، انتقال یا راستی‌آزمایی بدون اپراتور واحد نیاز دارند و هزینه و شفافیت آن را می‌پذیرند.

آیا DID همان آدرس کیف پول است؟

خیر. DID شناسه‌ای مطابق یک DID Method است و بسیاری، نه همه، Methodها از DLT استفاده می‌کنند. آدرس Wallet ممکن است در یک روش یا Login نقش داشته باشد، اما به‌تنهایی نام قانونی، سن یا صلاحیت صاحب را ثابت نمی‌کند.

آیا Verifiable Credential درست‌بودن مدرک را تضمین می‌کند؟

اعتبارسنجی رمزنگاری نشان می‌دهد Credential از Issuer مورد اشاره آمده، دست‌کاری نشده و Status آن طبق روش بررسی شده است. Verifier هنوز باید اعتبار Issuer، روش Proofing، تازگی و کفایت Claim برای تصمیم خود را ارزیابی کند.

آیا مالک NFT صاحب حق کپی‌رایت تصویر است؟

نه به‌طور خودکار. ERC-۷۲۱ مالک Token ID را ثبت می‌کند؛ حقوق تکثیر، استفاده تجاری، اثر مشتق یا علامت تجاری به License، قرارداد و قانون وابسته است. Metadata و فایل نیز ممکن است Off-chain، Mutable یا در دسترس‌ناپایدار باشند.

اولین قدم برای یک کسب‌وکار ایرانی چیست؟

یک Use case کوچک انتخاب و Actor/State/Trust gap را بنویسید؛ Baseline متمرکز را بسنجید؛ داده، حقوق، Provider eligibility و Scope حقوقی را تاریخ‌دار بررسی کنید؛ سپس Prototype بدون دارایی واقعی را با کاربر فارسی، Failure و Recovery تست کنید.