بلاک چین های مدولار: ردیابی اجرا، داده و تسویه حساب

یک بلاک چین ماژولار به جای اینکه از یک سیستم بخواهد هر وظیفه ای را انجام دهد، مسئولیت ها را بین اجزا تقسیم می کند. این می تواند توصیف شبکه را ساده به نظر برساند: اجرا در اینجا اتفاق می افتد، داده ها به آنجا می روند و تسویه در جای دیگری رخ می دهد. سوال مهم این است که هر جزء در واقع چه چیزی را تضمین می کند.

این مقاله نقش‌های معماری را مقایسه می‌کند، نه قیمت‌های نمادین یا رتبه‌بندی پروژه‌ها. طراحی ماژولار به طور خودکار به معنی ریسک کمتر، بازده سرمایه گذاری بالاتر یا امنیت یکسان در بین اجراها نیست.

قبل از مقایسه سیستم ها، مشاغل را از هم جدا کنید

Execution قوانین تراکنش را اعمال می کند و یک تغییر حالت پیشنهادی را محاسبه می کند. در دسترس بودن داده ها به این موضوع مربوط می شود که آیا اطلاعات مورد نیاز برای تأیید سیستم در دسترس بوده است یا خیر. حل و فصل مربوط به نحوه پذیرش تعهدات رمزنگاری‌شده درباره وضعیت زنجیره (state commitments)، اثبات‌ها یا اعتراض‌ها تحت یک پروتکل خاص است. اجماع، ترتیب مورد توافق یا سابقه پذیرفته شده را در یک سیستم تعیین می کند.

این نقش ها می توانند همپوشانی داشته باشند یا به روش های مختلف توزیع شوند. برچسب های پروژه کافی نیستند: یک شبکه ممکن است خود را ماژولار بنامد در حالی که کنترل قابل توجهی را در یک ترتیب دهنده، کلید ارتقا یا کمیته داده حفظ می کند. نقشه وابستگی واقعی را ترسیم کنید نه اینکه فرض کنید همه شبکه های مدولار یک مدل اعتماد مشترک دارند.

اسناد در دسترس بودن داده‌های اتریوم توضیح می‌دهد که چرا تأیید به دسترسی به داده‌های تراکنش بستگی دارد و چرا کلاینت‌ها و جمع‌آوری‌های سبک به تضمین‌های مناسب نیاز دارند. دسترسی به داده ها سؤالی متفاوت از اینکه آیا یک محاسبات اجرا شده صحیح است یا خیر است.

یک معامله فرضی را دنبال کنید

تصور کنید کاربر یک تراکنش را به یک شبکه اجرایی ارسال می کند. یک ترتیب دهنده آن را در یک دسته قرار می دهد. این سیستم با استفاده از لایه داده انتخابی خود، داده های مورد نیاز را در دسترس قرار می دهد و یک تعهد حالت را با مکانیسم تأیید مورد نیاز طراحی خود، به یک لایه تسویه ارائه می کند.

کاربر ممکن است قبل از اینکه هر مرحله به وضعیت نهایی خود برسد، تأیید اولیه را ببیند. معنی هر وضعیت را یادداشت کنید: دریافت، سفارش، اجرا، داده های منتشر شده، اثبات پذیرفته شدن یا تکمیل پنجره اعتراض. اولین تصدیق را به عنوان تسویه نهایی برچسب نزنید مگر اینکه پروتکل آن تفسیر را پشتیبانی کند.

این مثال به جای تجویز یک توالی جهانی، نقش ها را توصیف می کند. مجموعه های مختلف و سیستم های مدولار ممکن است مراحل را با هم ترکیب کنند یا از ترتیبات اثبات و نهایی متفاوتی استفاده کنند.

بپرسید وقتی یک جزء از کار می افتد چه اتفاقی می افتد

اگر یک ترتیب‌دهنده متوقف شود، آیا کاربران می‌توانند تراکنش‌ها را به روش دیگری ارسال کنند و تحت چه شرایطی؟ اگر یک سرویس داده اطلاعاتی را پنهان کند، چه کسی آن را شناسایی می کند و کاربران چه چیزی را می توانند تأیید کنند؟ اگر یک لایه تسویه شلوغ باشد، تعهدات یا برداشت ها چگونه تحت تأثیر قرار می گیرند؟

به این سؤالات از اسناد فعلی، از جمله رویه های اضطراری و کنترل های اداری پاسخ دهید. بازگشتی که در یک نقشه راه توضیح داده شده است لزوما عملیاتی نیست. شبکه‌ای که به نمایش موجودی‌ها ادامه می‌دهد ممکن است همچنان توانایی پذیرش تراکنش‌ها یا برداشت کامل را کاهش دهد.

وابستگی های پل را جداگانه بررسی کنید. توکنی که در دو شبکه ظاهر می شود به این معنی نیست که مسیر انتقال تمام ویژگی های امنیتی هر دو زنجیره را به ارث می برد.

هزینه کامل و تجربه کاربر را مقایسه کنید

کارمزد اجرای کم تنها بخشی از هزینه تراکنش است. انتشار داده ها، تسویه حساب، پل زدن و عملیات برداشت ممکن است هزینه یا تاخیر اضافه کند. اقدامات معادل را در یک دوره مشابه مقایسه کنید و توضیح دهید که چه کسی کدام هزینه را پرداخت می کند.

مسیر کامل مربوط به کاربر را اندازه گیری کنید: ورود، اجرا، تایید، برداشت و بازگشت به دارایی یا شبکه مورد نظر. معیاری که فقط یک مرحله را پوشش می دهد نباید به عنوان قیمت کل یک سفر رفت و برگشت ارائه شود. صرفه جویی در هزینه نیز می تواند با تقاضا و شرایط لایه داده متفاوت باشد.

از چک لیست وابستگی استفاده کنید

برای هر سیستم، قوانین اجرای رکورد، مرجع سفارش، مکان داده ها، مکانیسم تأیید، مقصد تسویه حساب، کنترل های ارتقاء و روش خروج. علامت گذاری کنید که کدام ادعاها واقعی هستند و کدام برنامه ریزی شده است. منابع و تاریخ بررسی شده را اضافه کنید، زیرا تنظیمات معماری ممکن است تغییر کند.

برای یک مشکل مرتبط اما متمایز، مقایسه پیام زنجیره‌ای متقابل را بخوانید: دستورالعمل‌های بین زنجیره‌ها را دنبال می‌کند، در حالی که این راهنما از تقسیم کار در یک معماری پیروی می‌کند.

طراحی مهندسی یک پروتکل و حقوق اقتصادی نشانه آن سؤالات پژوهشی جداگانه ای هستند. ابزار توکن و در دسترس بودن واقعی بازار را به طور مستقل از طریق اسناد رسمی و صفحه بازارهای OrangeX بررسی کنید، به جای اینکه ادعای مقیاس بندی را به عنوان نتیجه معاملاتی تلقی کنید.