هدف از این پست بررسی روندی است که یک تراکنش باید در شبکه هایپرلجر فبریک طی کند تا در بلاکچین ثبت شود، اما پیش از آن لازم است که این مسئله بپردازیم که چرا بلاکچین فبریک نیازی به اثبات کار ندارد (مانند بلاکچین بیت‌کوین) ندارد. با ما همراه باشید.
یکی از مهمترین تفاوت‌ها بین بلاکچینهای خصوصی و عمومی آن است که بر خلاف بلاکچینهای عمومی که هر کس می‌تواند به راحتی به آنها وارد شود در بلاکچینهای خصوصی هر یک از گره‌های شرکت‌کننده در شبکه دارای هویت مشخصی هستند. مشخص بودن هویت گره‌ها، شبکه را قادر می‌سازد که روش‌هایی را به کار گیرد که عملکرد بسیار بهتری را نسبت به بلاکچینهای عمومی از خود نشان می‌دهند. روشی که برای ثبت تراکنش در هایپرلجر فبریک استفاده می‌شود از اساس با روش‌هایی که در بلاکچینهای عمومی معروف استفاده میشوند متفاوت است. در فبریک دیگر خبری از ماینر‌ها و عمل ماینینگ نیست. برای اینکه درک کنیم چرا شبکه‌های خصوص از ماینینگ بی‌نیازند لازم است که به فلسفه استفاده از ماینینگ در بلاکچینهای عمومی رجوع کنیم. هدف بلاکچین ایجاد شبکه‌ای است که مدیریت آن بر عهده یک نهاد مرکزی نباشد بلکه به شکلی دموکراتیک، تمامی اعضای شبکه در انتخاب اینکه چه تراکنشی باید در دفتر کل ثبت شود و چه تراکنشی نباید ثبت شود دخیل باشند. برای رسیدن به این هدف اولین راه حلی که به ذهن می‌رسد رأی‌گیری است؛ به این صورت که از اعضای شبکه رأی‌گیری شود که کدام تراکنش‌ها باید در دفتر کل ثبت شوند. مشکل اینجاست که چه گونه مطمئن باشیم که یک کاربر نمی‌تواند تعداد بسیاری رأی را ارسال کند؟
برای مثال محدود کردن رأی‌های یک کاربر با آدرس آی‌پی نمی‌تواند پاسخ مناسبی به این سوال باشد، چراکه برخی کاربران به بازه‌های بسیار بزرگ آی‌پی دسترسی دارند و می‌توانند به تنهایی و بدون صرف هزینه بر شبکه مسلط شده و همواره پیروز رأی‌گیری باشند. بیت‌کوین برای اولین بار راه حل قبولی را برای حل مسئله رأی‌گیری ارائه داد که ما آنرا را با نام اثبات کار (proof of work) می‌شناسیم. در اثبات کار هر کاربر به میزان توان پردازشی‌‌اش در شبکه قدرت رأی‌دهی دارد، بنابراین همه می‌توانند که در شبکه شرکت کنند و هزینه‌ای که لازم است برای افزایش قدرت پردازشی صرف شود مانع از آن می‌شود که یک کاربر به تنهایی بتواند بر شبکه مسلط شود. رأی‌گیری در شبکه خصوصی فبریک بسیار ساده‌تر است، زیرا در فبریک هویت گره‌ها مشخص است و دیگر نیازی نیست که برای محدود کردن توان رأی‌دهی دست به دامن روش پیچیده و هزینه‌بر اثبات کار شویم و دستمان بازتر است که از روش‌هایی با کارایی بهتر استفاده کنیم.
برگردیم به موضوع اصلی پست یعنی، بررسی روند تراکنش بدون نیاز به اثبات کار. در اینجا اجزای مختلف شبکه فبریک معرفی شدند. این اجزا باید برای تایید و ثبت یک تراکنش با یکدیگر همکاری کنند. به عنوان یک سناریو نمونه، فرض کنید که در شبکه دو سازمان وجود دارند و شبکه به گونه‌ای ایجاد شده است که هر تراکنش باید توسط حداقل یک peer از هر سازمان امضا شود تا معتبر تلقی شده و در دفترکل ثبت شود.
روند ثبت یک تراکنش با ارسال درخواست از سمت یک کلاینت به سمت SDK، با هدف فراخوانی یک تابع از chaincode با پارامتر‌های مشخص آغاز می‌شود. SDK نقش رابطی را بازی می‌کند که وظیفه برقراری ارتباط بین کلاینک و شبکه فبریک را بر عهده دارد. با دریافت اطلاعات مربوط به تراکنش و گواهی‌های رمزنگاری کلاینت، SDK یک پیشنهاد تراکنش (TransactionProposal) را به همراه یک امضای یکتا ایجاد می‌کند. از آنجایی که هر تراکنش باید توسط هر دو سازمان امضا شود، پیشنهاد تراکنش برای یک peer از هر سازمان ارسال می‌شود.
هر peer پس از دریافت یک پیشنهاد تراکنش باید صحت آن را مورد بررسی قرار دهد. صحت‌سنجی یک پیشنهاد تراکنش شامل موارد زیر می‌شود:
- بررسی صحت فرمت پیشنهاد تراکنش.
- تصدیق عدم ثبت تراکنش در گذشته.
- بررسی صحت امضا.
- بررسی صلاحیت کلاینت برای انجام عملیات مد نظر پیشنهاد تراکنش.
در صورتی که از نظر peer موارد فوق صحیح باشند پیشنهاد تراکنش بر روی حالت (state) جاری chaincode اجرا می‌شود و نتایج بدست می‌آیند و بر روی chaincode اعمال نمی‌شوند (بنابراین حالت chaincode پس از این مرحله تغییری نمی‌کند) . نتایج شامل مقدار پاسخ، مجموعه خوندانی (read set) و مجموعه نوشتنی (write set) است. مجموعه خواندنی شامل مقادیری است که peer از روی حالت شبکه خوانده است و مجموعه نوشتنی شامل مقادیری است که پس از اجرای موفق تراکنش باید بر روی شبکه نوشته شوند. نتایج به همراه امضای peer به عنوان پاسخ پیشنهاد به SDK ارسال میشوند.
پس از دریافت پاسخ پیشنهادها از هر دو سازمان SDK آنها را بررسی می‌کند تا مطمئن شود که هر دو نتایج یکسانی را نتیجه می‌دهند. در این مرحله اگر هدف صرفا خواندن از بلاکچین باشد کلاینت می‌تواند پاسخ خود را از پاسخ به پیشنهادها بخواند. در غیر این صورت SDK یک تراکنش شامل پیشنهاد تراکنش و پاسخ پیشنهاد ایجاد کرده و آن را برای سرویس مرتب‌سازی (شامل ordererها( ارسال می‌کند.
سرویس مرتب‌سازی تراکنش‌های مختلف را دریافت کرده و آنها را در قالب یک بلوک قرار می‌دهد. سپس بلوک‌ها ایجاد شده به peerها ارسال میشوند. وظیفه سرویس مرتب‌سازی صرفاً مرتب کردن تراکنش‌ها است و صحت تراکنش‌ها در این سرویس مورد بررسی قرار نمی‌گیرد.
هر peer پس از دریافت یک بلوک از سرویس مرتب‌سازی بار دیگر به بررسی تراکنش‌ها می‌پردازد. برای هر تراکنش در بلوک بررسی می‌شود که مجموعه خواندنی‌اش با حالت جاری شبکه سازگار باشد (به این معنی که پس از ایجاد مجموعه خواندنی تغییری در حالت دفترکل برای متغییر‌های ذکر شده در مجموعه خواندنی رخ نداده باشد) و در صورتی سازگاری به عنوان یک تراکنش معتبر شناخته می‌شود. برای هر تراکنش معتبر مجموعه نوشتنی بر روی دفترکل اعمال می‌شود. در نهایت برای تراکنش پیامی برای کلاینت ارسال می‌شود که که ثبت شدن تراکنش در دفتر کل را به همراه معتبر یا غیرمعتبر بودن آن اعلام می‌کند.
نویسنده : امیر ضیاشهابی
