برای بررسی آینده Web3 باید از شعار «جایگزین شدن کل وب» فاصله گرفت و سراغ محصول رفت. کاربر برای انجام یک کار مشخص وارد سایت می‌شود: خرید، ثبت سفارش، انتشار محتوا یا همکاری با دیگران. اگر اتصال کیف پول و امضای پیام این کار را دشوارتر کند، توضیح درباره غیرمتمرکز بودن شبکه به‌تنهایی او را نگه نمی‌دارد. بلاکچین زمانی ارزش بررسی دارد که مشکل اعتماد میان چند طرف را حل کند و هزینه این انتخاب برای کاربر و تیم قابل قبول باشد.
این مقاله، با بازبینی منابع در ۹ اکتبر ۲۰۲۶، وضعیت Web3 را از زاویه طراحی محصول و معماری وب بررسی می‌کند. منظور از بحران در اینجا فاصله میان وعده‌های محصول و تجربه استفاده است؛ برای اعلام سقوط کل صنعت یا پیش‌بینی قیمت دارایی‌ها به داده‌های دیگری نیاز داریم. می‌توان یک پروژه کم‌فایده را نقد کرد و هم‌زمان درباره کاربرد محدود یک فناوری جدی بود. این دو ارزیابی باید جداگانه انجام شوند.
Web3 دقیقاً به چه چیزی اشاره می‌کند؟
تعریف واحد و مورد توافقی برای Web3 وجود ندارد. در کاربرد رایج مرتبط با اتریوم، این اصطلاح به برنامه‌هایی اشاره می‌کند که بخشی از وضعیت و قواعد خود را روی شبکه بلاکچین نگه می‌دارند. مالکیت دارایی دیجیتال، اجرای قواعد قرارداد و مشارکت کاربران در تصمیم‌گیری از ایده‌های مطرح در این حوزه‌اند. معرفی Web3 در وب‌سایت اتریوم همین ایده‌ها و محدودیت‌های دسترسی، آموزش و زیرساخت را توضیح می‌دهد. این منبع دیدگاه یک اکوسیستم را بیان می‌کند، نه اثبات برتری همه محصولات آن.
برای فهم یک محصول، اجزای آن را روی کاغذ بنویسید. رابط در مرورگر اجرا می‌شود، فایل‌ها جایی نگهداری می‌شوند، درخواست‌ها از یک مسیر به شبکه می‌رسند و قرارداد بخشی از قواعد را اجرا می‌کند. داشتن قرارداد روی شبکه، استقلال همه این اجزا را تضمین نمی‌کند. اگر رابط فقط از یک دامنه قابل دسترسی باشد یا برنامه تنها به یک ارائه‌دهنده اتصال وابسته بماند، همان بخش همچنان نقطه توقف دارد. ارزیابی معماری با شمردن این وابستگی‌ها شروع می‌شود.
چرا وعده مالکیت برای ساخت محصول کافی نیست؟
فرض کنید یک تیم می‌خواهد سامانه عضویت برای یک انجمن بسازد. عضو انتظار دارد وارد حساب شود، اعتبار عضویت را ببیند و در صورت بروز مشکل با پشتیبانی تماس بگیرد. تیم پیشنهاد می‌دهد عضویت با یک توکن مشخص شود. پیش از انتخاب فناوری باید روشن شود که انتقال عضویت میان افراد واقعاً مجاز است، چه کسی اطلاعات اشتباه را اصلاح می‌کند و اعتبار این عضویت خارج از همان انجمن چه معنایی دارد. اگر همه تصمیم‌ها همچنان به مدیر انجمن وابسته باشند، داشتن توکن بخش کوچکی از مسئله را حل کرده است.
این مثال فرضی نشان می‌دهد واژه مالکیت باید به رفتار مشخص ترجمه شود. صاحب دارایی چه اختیاری دارد؟ می‌تواند آن را منتقل کند، به برنامه دیگری ببرد یا بدون اجازه تیم از آن استفاده کند؟ کدام محدودیت‌ها در قرارداد نوشته شده و کدام‌ها در شرایط استفاده محصول آمده‌اند؟ پاسخ مبهم به این سؤال‌ها بعداً در رابط و پشتیبانی خودش را نشان می‌دهد. تیم محصول باید این رفتارها را پیش از طراحی صفحه خرید یا عضویت مشخص کند.
کیف پول و امضا بخشی از تجربه کاربر هستند
در یک برنامه مبتنی بر کیف پول، اتصال، امضای پیام و ارسال تراکنش کارهای متفاوتی هستند. رابط باید تفاوت آن‌ها را روشن کند. درخواست امضا با متن ناخوانا یا پیام خطای کلی باعث می‌شود کاربر نداند چه اجازه‌ای می‌دهد و پس از شکست عملیات چه کاری باید انجام دهد. حتی وقتی زیرساخت درست کار می‌کند، تجربه مبهم اعتماد به محصول را کم می‌کند. صفحه تأیید باید عمل مورد درخواست، مقصد و پیامد آن را با زبان قابل فهم نشان دهد.
سناریوهای شکست را از ابتدا بنویسید: کاربر درخواست را رد می‌کند، کیف پول در شبکه دیگری است، تراکنش هنوز تأیید نشده یا ارتباط برنامه قطع می‌شود. هرکدام پیام و اقدام بعدی متفاوتی می‌خواهند. نشان دادن دوباره دکمه ارسال بدون توضیح وضعیت قبلی می‌تواند کاربر را به تکرار ناخواسته عملیات سوق دهد. تیم طراحی باید حالت انتظار و شکست را همان‌قدر جدی بگیرد که صفحه موفقیت را طراحی می‌کند. این کار به همکاری نزدیک طراح و توسعه‌دهنده نیاز دارد.
هزینه کمتر، همه مسئله مقیاس را حل نمی‌کند
برای بررسی هزینه، تعداد عملیات لازم برای یک کار کامل را حساب کنید. یک فرایند که ظاهراً ساده است ممکن است به دریافت داده، امضا، تأیید مجوز و ثبت تراکنش نیاز داشته باشد. کارمزد تنها هزینه این مسیر نیست؛ انتظار کاربر، نگهداری زیرساخت و رسیدگی پشتیبانی هم هزینه دارند. بدون تعریف سناریو و شبکه، اعلام یک عدد ثابت برای «هزینه استفاده از Web3» گمراه‌کننده است. نتیجه باید با شرایط همان محصول و زمان اندازه‌گیری گزارش شود.
مستندات مقیاس‌پذیری اتریوم مسیرهای مختلف افزایش ظرفیت، از جمله راهکارهای لایه دوم را معرفی می‌کند. هنگام انتخاب این مسیر، محل اجرای عملیات و شیوه ارتباط با شبکه پایه باید فهمیده شود. یک شبکه با هزینه مناسب ممکن است برای نیاز یک برنامه انتخاب خوبی باشد؛ این انتخاب را نمی‌توان بدون بررسی وابستگی‌ها به همه برنامه‌ها تعمیم داد. انتقال میان شبکه‌ها نیز تجربه و ریسک جداگانه دارد. نام لایه دوم جای توضیح معماری را نمی‌گیرد.
غیرمتمرکز بودن را جزءبه‌جزء بررسی کنید
فهرست وابستگی‌های محصول را به رابط، داده، اتصال شبکه و کنترل قرارداد تقسیم کنید. برای هر قسمت بنویسید چه کسی آن را اداره می‌کند و در صورت توقف چه جایگزینی وجود دارد. استفاده از یک سرویس مدیریت‌شده لزوماً انتخاب بدی نیست؛ ممکن است برای تیم کوچک منطقی باشد. ادعای محصول باید با همین انتخاب سازگار بماند. اگر قطع یک سرویس دسترسی همه کاربران را متوقف می‌کند، نمی‌توان درباره استقلال کامل تجربه استفاده صحبت کرد.
در بررسی قرارداد نیز تنها نام فناوری کافی نیست. مشخص کنید چه کسی اجازه تغییر قواعد را دارد، آیا عملیات قابل توقف است و کاربران از این اختیارات چگونه مطلع می‌شوند. این پرسش‌ها بخشی از بررسی طراحی هستند و پاسخشان برای هر پروژه متفاوت است. سند معماری باید وضعیت فعلی را توضیح دهد؛ برنامه احتمالی تیم برای کاهش وابستگی در آینده نباید به‌جای قابلیت موجود معرفی شود. همین شفافیت به کاربر و شریک تجاری کمک می‌کند انتظار درستی داشته باشند.
IPFS به‌تنهایی نگهداری همیشگی فایل را تضمین نمی‌کند
در IPFS، شناسایی محتوا و در دسترس نگه داشتن آن دو موضوع جدا هستند. مستندات ماندگاری داده در IPFS توضیح می‌دهد که برای حفظ محتوا باید آن را روی گره‌ها یا سرویس‌های مناسب نگه داشت؛ پین کردن یکی از ابزارهای این کار است. بنابراین درج شناسه محتوا در قرارداد، جای برنامه نگهداری فایل را نمی‌گیرد. تیم باید بداند چه کسی نسخه فایل را نگه می‌دارد و هزینه نگهداری از کجا تأمین می‌شود.
مثلاً برای یک گواهی دیجیتال فرضی، ثبت شناسه فایل بدون نگهداری خود فایل تجربه کاملی ایجاد نمی‌کند. اگر دریافت فایل بعداً ممکن نباشد، کاربر با یک ارجاع روبه‌رو می‌شود که برای او استفاده‌ای ندارد. در طراحی چنین سامانه‌ای، نسخه پشتیبان، مسیر بازیابی و مسئول پاسخ‌گویی را تعریف کنید. محتوای قابل مشاهده عمومی هم باید پیش از انتشار بررسی شود. گذاشتن اطلاعات خصوصی در یک مسیر عمومی را نمی‌توان صرفاً با تغییر رابط پنهان کرد.
امنیت قرارداد و پل را جداگانه ببینید
قرارداد هوشمند قواعد نوشته‌شده را اجرا می‌کند؛ درست بودن این قواعد و سازگاری آن‌ها با نیاز محصول باید بررسی شود. یک تصمیم اشتباه در طراحی مجوزها یا مسیر تغییر قرارداد ممکن است فراتر از رابط اثر بگذارد. گزارش ارزیابی امنیتی نیز باید با نسخه قرارداد و محدوده بررسی تطبیق داده شود. وجود گزارش برای یک بخش، گواهی سلامت تمام سامانه نیست. در تصمیم محصول، مسئولیت رسیدگی به رخداد و مسیر اطلاع‌رسانی را از ابتدا مشخص کنید.
وقتی دارایی یا پیام میان شبکه‌ها جابه‌جا می‌شود، سازوکار پل هم وارد محدوده بررسی می‌شود. مستندات پل‌های اتریوم ریسک‌هایی مثل خطای قرارداد و تفاوت فرض‌های اعتماد را شرح می‌دهد. برای تیم محصول، نتیجه عملی این است که انتقال را یک مرحله مستقل با وضعیت، توضیح و پشتیبانی مشخص طراحی کند. کاربر باید بداند عملیات در کدام مرحله قرار دارد؛ یک نوار انتظار مبهم برای فرایندی چندمرحله‌ای کافی نیست.
چه زمانی بلاکچین ارزش بررسی دارد؟
یک نقطه شروع مناسب، نیاز چند طرف به ثبت وضعیت مشترک و قابل بررسی است؛ به‌ویژه وقتی نمی‌خواهند همه اختیار ثبت و تغییر داده را به یک طرف بدهند. با این حال، ابتدا گزینه‌های ساده‌تر را مقایسه کنید. پایگاه داده، امضای دیجیتال یا ثبت رویداد قابل ممیزی شاید همان نیاز را با هزینه کمتر پاسخ دهند. این‌ها پیشنهاد طراحی برای بررسی اولیه‌اند و نتیجه قطعی برای همه پروژه‌ها نیستند. تصمیم به شرایط اعتماد و اختیار طرف‌ها وابسته است.
برای یک فروشگاه معمولی، اتصال کیف پول ممکن است مرحله اضافی بسازد، در حالی که مسئله اصلی موجودی و ارسال سفارش است. برای سامانه‌ای با چند سازمان مستقل، بررسی یک دفتر ثبت مشترک می‌تواند معنا داشته باشد. فرق این دو مثال در مسئله و رابطه طرف‌هاست. انتخاب فناوری را پس از نوشتن سناریو انجام دهید. برای جدا کردن بحث ابزار از نتیجه محصول، مقاله Rust و آینده ابزارهای توسعه وب نیز همین نوع پرسش درباره نیاز و محدودیت ابزار را دنبال می‌کند.
یک مسیر عملی برای ارزیابی تیم
یک جریان کوچک و کامل انتخاب کنید؛ مثلاً ثبت یک درخواست و مشاهده نتیجه آن. نسخه ساده بدون بلاکچین را کنار طرح پیشنهادی قرار دهید. زمان انجام کار، تعداد مراحل، نقاط شکست و مسئولیت پشتیبانی را مقایسه کنید. سناریوی قطع ارائه‌دهنده و گم شدن دسترسی کاربر را نیز روی کاغذ بررسی کنید. تا زمانی که مزیت مشخصی در این مقایسه پیدا نشده، افزودن توکن یا قرارداد به نقشه محصول تصمیم زودهنگامی است.
کار فنی را با تغییر ظاهر ابزار اشتباه نگیرید. همان‌طور که در مقاله سازوکار و محدودیت‌های Vapor Mode در Vue بحث شده، شناخت محدوده و اندازه‌گیری در پروژه واقعی از تکیه بر نام فناوری مفیدتر است. برای Web3 نیز یک یادداشت تصمیم بنویسید: مسئله اعتماد چیست، کدام جزء روی شبکه قرار می‌گیرد، چه وابستگی‌هایی باقی می‌ماند و چه مشاهده‌ای باعث توقف طرح می‌شود. این سند به تیم اجازه می‌دهد بدون وابستگی به شعار اولیه، تصمیم خود را اصلاح کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!