لایه 2: تأیید سریع با تسویه نهایی یکی نیست
پذیرش تراکنش، انتشار داده و تکمیل برداشت را در سراسر سامانه مقیاس‌پذیری ترسیم کنید.
مرحله‌ای را که مشاهده می‌کنید نام ببرید
تأیید سریع رابط کاربری ممکن است یعنی ترتیب‌دهنده تراکنش را پذیرفته، نه اینکه تمام شرایط تسویه بعدی تکمیل شده است. سامانه‌های لایه 2 کار را خارج از زنجیره پایه انجام می‌دهند و از سازوکارهای اضافی برای تسویه یا تأیید نتایج استفاده می‌کنند. مستندات مقیاس‌پذیری اتریوم رویکردهای خوش‌بینانه را از رویکردهای اثبات اعتبار متمایز می‌کند. معماری تعیین می‌کند ناظر در هر مرحله با اطمینان چه برداشتی می‌تواند داشته باشد.
در یادداشت پژوهشی برچسب دقیق بزنید: ارسال‌شده، پذیرفته‌شده توسط گرداننده، قرارگرفته در دسته، منتشرشده روی زنجیره پایه، تأییدشده یا پایان‌یافته از نظر دوره اعتراض، و برداشت‌شده. همه سامانه‌ها دقیقاً این مراحل را ندارند، اما ادغام آن‌ها در یک واژه «تأییدشده»، تفاوت‌های عملیاتی مهم برای صرافی‌ها و مدیران وثیقه را پنهان می‌کند.
تفاوت در راستی‌آزمایی را درک کنید
رولاپ‌های خوش‌بینانه به سازوکار اعتراض به ادعاهای وضعیت نادرست در بازه معین متکی‌اند. طراحی‌های اثبات اعتبار، شواهد رمزنگاری برای تغییرات وضعیت ارائه می‌کنند، هرچند دسترس‌پذیری داده، ارتقا و ترتیبات عملیاتی آن‌ها همچنان نیازمند بررسی است. سامانه اثبات یکی از اجزای امنیت است، نه تضمین فراگیر برای همه برنامه‌ها یا پل‌های پیرامونش.
تمرین عملی این است که بپرسید اگر گرداننده نتیجه نادرست ارسال کند، پردازش تراکنش را متوقف کند یا خدمت ضروری را ارائه ندهد چه می‌شود. مشخص کنید کدام بازیگران می‌توانند واکنش نشان دهند و چه اطلاعاتی لازم دارند. پاسخ باید از مستندات سامانه مستقر بیاید، نه از توصیف آرمانی دسته کلی آن.
تأخیر تسویه را از نقدشوندگی برداشت جدا کنید
برداشت بومی ممکن است نیازمند انتظار برای شرایط پروتکل باشد. ارائه‌دهنده نقدینگی ثالث شاید در برابر کارمزد، وجه را زودتر بدهد و عملاً مسیر خروج دیگری فراهم کند. آن مسیر مواجهه را تغییر می‌دهد؛ شرایط تسویه پروتکل زیربنایی را حذف نمی‌کند. ظرفیت می‌تواند در شرایط تنش، دقیقاً وقتی کاربران بسیاری خروج زودهنگام می‌خواهند، کاهش یابد.
تعهدی را تصور کنید که فردا روی زنجیره پایه سررسید می‌شود و دارایی‌هایی که برداشت بومی آن‌ها در سامانه فرضی چند روز طول می‌کشد. این دارایی‌ها ممکن است ارزشمند باشند، اما طبق زمان‌بندی لازم در دسترس نباشند. قیمت خروج سریع فقط برای مبلغ و زمان واقعاً اعلام‌شده شاهد مفیدی است. نباید فرض شود هنگام هجوم سراسر بازار همچنان در دسترس می‌ماند.
کنترل‌ها و زیرساخت را بررسی کنید
تمرکز ترتیب‌دهنده، کلیدهای ارتقا، شوراهای اضطراری، ارائه اثبات و انتشار داده هرکدام سطر جداگانه‌ای در مقایسه می‌خواهند. سامانه می‌تواند قواعد قوی تأیید تراکنش داشته باشد و هم‌زمان به خدمات عملیاتی متمرکز وابسته باشد. قطعی شاید بدون تغییر مالکیت بر دسترسی اثر بگذارد، اما ناتوانی در معامله همچنان می‌تواند زیان مالی ایجاد کند اگر موقعیت‌ها به تعدیل فوری نیاز داشته باشند.
بررسی کنید آیا درج اجباری یا سازوکار خروج جایگزین وجود دارد، چه کسی می‌تواند از آن استفاده کند و تأخیر عملی آن چقدر است. مسیر فرار موجود در نظریه ممکن است نیازمند کارمزد زنجیره پایه، مراحل فنی و دوره انتظار باشد. برای تمرین پژوهشی غیرفنی، این الزامات را مستند کنید، نه اینکه فرض کنید «بدون نیاز به مجوز» یعنی دسترسی بی‌زحمت یا فوری.
هزینه کل چرخه عمر را اندازه بگیرید
کارمزد پایین تراکنش ارزشمند است، اما مقایسه کامل شامل واریز، برداشت، استفاده از پل، نقدینگی مقصد و زمان عدم‌دسترسی است. راهبرد با تراکنش‌های محلی فراوان و برداشت نادر، ساختار هزینه متفاوتی از راهبردی دارد که مرتب وجه را بین شبکه‌ها جابه‌جا می‌کند. واحد مرتبط، کل روند کار است، نه یک عملیات دلخواهِ ارزان.
برای حالت عادی و حالت قطعی خط زمانی بسازید. ثبت کنید کدام موجودی در هر نقطه قابل‌خرج است و کدام فرضیات مرحله بعد را به تأخیر می‌اندازند. این کار بدون پیش‌بینی سامانه مقیاس‌پذیری موفق، تحلیل را مفید می‌کند. توان پردازش فنی، قطعیت، نقدینگی و ارزش توکن برنامه موضوعات جداگانه‌اند و نباید طوری ارائه شوند که گویی بهبود یکی خودکار همه بقیه را بهتر می‌کند.
تمرین پایانی مفید این است که یک موجودی را در سه زمان برچسب بزنید: قابل‌استفاده محلی، آماده خروج بومی و قابل‌خرج روی زنجیره مقصد. زمان‌های جداگانه شکاف نقدینگی را آشکار می‌کنند. اگر مهلتی درون یکی از این شکاف‌ها باشد، موقعیت مشکل عملیاتی تأمین وجه دارد، حتی اگر همه موجودی‌ها سرانجام درست تسویه شوند و هیچ اصل سرمایه‌ای برای همیشه از دست نرود.
انتشار داده با نگهداری همیشگی آن فرق دارد
مدل امنیت لایه دوم ممکن است به در دسترس بودن داده لازم برای بررسی وضعیت در زمان مناسب وابسته باشد. از این موضوع نمی‌توان نتیجه گرفت هر خدمت معمولی کل تاریخچه را برای همیشه در اختیار کاربر نگه می‌دارد.
نمایش تراکنش، انتشار داده، اثبات وضعیت و وجود آرشیو را جدا کنید. عضو تازه برای بازسازی وضعیت چه داده‌ای لازم دارد؟ چه کسی آن را می‌دهد و اگر یک ارائه‌دهنده متوقف شود چه می‌شود؟
برای تمرین، یک تراکنش قدیمی را در دو رابط بررسی کنید و ببینید آیا پشت هر دو همان سرویس داده قرار دارد. دو صفحه همیشه دو منبع مستقل نیست. سیاست نگهداری مستند از فرض بی‌دلیل دسترسی ابدی جلوگیری می‌کند.
مسیر خروجی را بسنجید که واقعاً استفاده می‌کنید
تأیید سریع قابل‌مشاهده، نهایی‌شدن لایه اول و امکان برداشت دارایی ممکن است در زمان‌های متفاوت برسند. رابط عادی شاید فقط یکی را نشان دهد. در هر وضعیت بپرسید کدام خطر کم شده و کدام باقی مانده است.
خروج عادی را با زمانی مقایسه کنید که ترتیب‌دهنده تراکنش‌ها یا سایت کار نمی‌کند. مسیر جایگزین هست؟ چه داده، تراکنش، کارمزد و انتظاری لازم دارد؟ حق نظری با فرایند آسان و در دسترس یکسان نیست.
فرض‌های یک راهکار لایه دوم را به دیگری منتقل نکنید. نظام اثبات، محل داده، اختیارات ارتقا و سازوکار اضطراری می‌توانند متفاوت باشند. ارزیابی باید برای نسخه و مسیر خروج مشخص باشد.