پارچه Hyperledger برای Dummies

پلتفرم بلاک چین برای شرکت

ظهر بخیر، خوانندگان عزیز، نام من نیکولای نفدوف است، من یک متخصص فنی در IBM هستم، در این مقاله می خواهم شما را با پلتفرم بلاک چین - Hyperledger Fabric آشنا کنم. این پلت فرم برای ساخت برنامه های کاربردی تجاری در کلاس سازمانی طراحی شده است. سطح مقاله برای خوانندگان ناآماده با دانش اولیه فناوری های IT است.

Hyperledger Fabric یک پروژه متن باز، یکی از شاخه های پروژه منبع باز Hyperledger، کنسرسیوم بنیاد لینوکس است. Hyperledger Fabric در ابتدا توسط Digital Assets و IBM راه اندازی شد. ویژگی اصلی پلتفرم Hyperledger Fabric تمرکز آن بر استفاده سازمانی است. بنابراین، این پلتفرم با در نظر گرفتن سرعت بالای تراکنش ها و هزینه پایین آنها و همچنین شناسایی همه شرکت کنندگان توسعه یافت. این مزایا از طریق جداسازی سرویس تأیید تراکنش و تشکیل بلوک های جدید رجیستری توزیع شده و همچنین استفاده از مرکز صدور گواهینامه و مجوز شرکت کنندگان حاصل می شود.

مقاله من بخشی از یک سری مقالات در مورد Hyperledger Fabric است که در آن یک پروژه سیستمی برای ثبت دانشجویان ورودی به دانشگاه را شرح می دهیم.

معماری کلی Hyperledger Fabric

Hyperledger Fabric یک شبکه بلاک چین توزیع شده متشکل از اجزای عملکردی مختلف است که بر روی گره های شبکه نصب می شوند. اجزای Hyperledger Fabric کانتینرهای Docker هستند که می‌توانند به صورت رایگان از DockerHub دانلود شوند. Hyperledger Fabric همچنین می تواند در محیط Kubernetes اجرا شود.

برای نوشتن قراردادهای هوشمند (کد زنجیره ای در زمینه Hyperledger Fabric)، از Golang استفاده کردیم (اگرچه Hyperledger Fabric امکان استفاده از زبان های دیگر را می دهد). برای توسعه یک برنامه کاربردی سفارشی، در مورد ما، از Node.js با Hyperledger Fabric SDK مربوطه استفاده کردیم.

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

معماری کلی به این صورت است:

تصویر 1. معماری عمومی پارچه هایپرلجر

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

همسالان در چندین نقش حضور دارند:

• Endorsing Peer گره ای است که اجرای تراکنش را شبیه سازی می کند (کد قرارداد هوشمند را اجرا می کند). پس از تایید و اجرای قرارداد هوشمند، گره نتایج اجرا را همراه با امضای خود به برنامه مشتری برمی گرداند.
• Ordering Service یک سرویس توزیع شده بر روی چندین گره است که برای تولید بلوک های جدید رجیستری توزیع شده و ایجاد یک صف برای اجرای تراکنش ها استفاده می شود. Ordering Service بلوک های جدیدی را به رجیستری اضافه نمی کند (این ویژگی برای بهبود عملکرد به Committing Peers منتقل شده است).
• Committing Peer گره ای است که شامل یک رجیستری توزیع شده است و بلوک های جدیدی را به رجیستری (که توسط Ordering Service ایجاد شده اند) اضافه می کند. همه همتایان متعهد حاوی یک کپی محلی از دفتر کل توزیع شده هستند. تعهد Peer تمام تراکنش‌های داخل بلوک را قبل از افزودن بلوک جدید به صورت محلی از نظر اعتبار بررسی می‌کند.

سیاست تایید خط مشی برای بررسی اعتبار یک تراکنش است. این خط مشی ها مجموعه مورد نیاز از گره ها را تعریف می کنند که قرارداد هوشمند باید بر روی آنها اجرا شود تا تراکنش معتبر شناخته شود.

رجیستری توزیع شده - Lerger - از دو بخش تشکیل شده است: WolrldState (همچنین پایگاه داده ایالتی نیز نامیده می شود) و BlockChain.

BlockChain زنجیره ای از بلوک ها است که سوابق تمام تغییراتی که در اشیاء رجیستری توزیع شده رخ داده است را ذخیره می کند.

WolrldState یک جزء دفتر کل توزیع شده است که مقادیر فعلی (لبه برش) همه اشیاء دفتر کل توزیع شده را ذخیره می کند.

WorldState یک پایگاه داده است، در نسخه اصلی - LevelDB یا پیچیده تر - CouchDB، که شامل جفت های کلید-مقدار است، به عنوان مثال: نام - ایوان، نام خانوادگی - ایوانوف، تاریخ ثبت نام در سیستم - 12.12.21/17.12.1961/XNUMX ، تاریخ تولد - XNUMX/XNUMX/XNUMX و غیره. WorldState و رجیستری توزیع شده باید بین همه شرکت کنندگان در یک کانال مشخص سازگار باشد.

از آنجایی که Hyperledger Fabric شبکه ای است که همه شرکت کنندگان در آن شناخته شده و احراز هویت شده اند، از یک مرجع صدور گواهینامه اختصاصی - CA (مرجع صدور گواهینامه) استفاده می کند. CA بر اساس استاندارد X.509 و زیرساخت کلید عمومی - PKI عمل می کند.

سرویس عضویت سرویسی است که از طریق آن اعضا تأیید می کنند که یک شی به سازمان یا کانال خاصی تعلق دارد.

تراکنش - در بیشتر موارد، نوشتن داده های جدید در یک رجیستری توزیع شده است.
همچنین معاملاتی برای ایجاد کانال یا قراردادهای هوشمند وجود دارد. تراکنش توسط برنامه کاربر آغاز می شود و با یک رکورد در دفتر کل توزیع شده به پایان می رسد.

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

سناریوی اجرای تراکنش معمولی

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

به عنوان بخشی از پروژه داخلی خود، شبکه Hyperledger Fabric را ایجاد کردیم که برای ثبت نام و حسابداری برای دانشجویانی که وارد دانشگاه می شوند طراحی شده است. شبکه ما متشکل از دو سازمان متعلق به دانشگاه A و دانشگاه B است. هر سازمان شامل یک برنامه مشتری و همچنین تعهد و تایید همتای خود است. ما همچنین از خدمات مشترک خدمات سفارش، خدمات عضویت و مرجع صدور گواهی استفاده می کنیم.

1) شروع معامله

یک برنامه کاربری با استفاده از Hyperledger Fabric SDK، درخواست تراکنش را آغاز می کند و درخواست را به گره هایی با قراردادهای هوشمند ارسال می کند. درخواست می تواند تغییر یا خواندن از یک رجیستری توزیع شده (Ledger) باشد. اگر نمونه ای از پیکربندی سیستم تست خود را برای حسابداری برای دانشجویان دانشگاه در نظر بگیریم، برنامه مشتری درخواست تراکنش را به گره های دانشگاه A و B ارسال می کند که در سیاست تایید قرارداد هوشمند نامیده می شود. گره A گره ای است که در دانشگاهی قرار دارد که دانشجوی ورودی را ثبت می کند و گره B گرهی است که در دانشگاه دیگری قرار دارد. برای اینکه یک تراکنش در یک رجیستری توزیع شده ذخیره شود، لازم است که تمام گره هایی که طبق منطق تجاری باید تراکنش را تایید کنند، قراردادهای هوشمند را با نتیجه یکسان با موفقیت اجرا کنند. گره یک برنامه کاربر، با استفاده از ابزار Hyperledger Fabric SDK، خط مشی تاییدیه را دریافت می کند و یاد می گیرد که درخواست تراکنش را به کدام گره ها ارسال کند. این یک درخواست برای فراخوانی یک قرارداد هوشمند خاص (عملکرد کد زنجیره ای) برای خواندن یا نوشتن داده های خاص در یک رجیستری توزیع شده است. از لحاظ فنی، سرویس گیرنده SDK از تابع مربوطه استفاده می کند، که API آن یک شی خاص با پارامترهای تراکنش ارسال می کند، و همچنین یک امضای کلاینت اضافه می کند و این داده ها را از طریق بافر پروتکل روی gRPC به گره های مناسب (تایید همتایان) ارسال می کند.

تصویر 2. شروع یک معامله

2) اجرای قرارداد هوشمند

گره ها (Endosing Peers)، پس از دریافت درخواست برای انجام تراکنش، امضای مشتری را بررسی می کنند و اگر همه چیز درست است، یک شی را با داده های درخواست می گیرند و شبیه سازی اجرای یک قرارداد هوشمند (عملکرد کد زنجیره ای) را با آن اجرا می کنند. این داده ها یک قرارداد هوشمند منطق تجاری یک معامله، مجموعه ای از شرایط و دستورالعمل ها است (در مورد ما، این تأیید یک دانش آموز است، آیا این یک دانش آموز جدید است یا قبلاً ثبت نام کرده است، تأیید سن و غیره). برای اجرای قرارداد هوشمند، به داده های WorldState نیز نیاز دارید. در نتیجه شبیه‌سازی یک قرارداد هوشمند بر روی همتای Endorsing، دو مجموعه داده به دست می‌آید – Read Set و Write Set. Read Set and Write Set مقادیر اصلی و جدید WorldState هستند. (جدید - به معنای به دست آمده در طول شبیه سازی یک قرارداد هوشمند).

تصویر 3. اجرای قرارداد هوشمند

3) برگرداندن داده ها به برنامه مشتری

پس از انجام شبیه‌سازی قرارداد هوشمند، Endorsing Peers داده‌های اصلی و نتیجه شبیه‌سازی و همچنین مجموعه RW را که توسط گواهینامه آنها امضا شده است را به برنامه مشتری برمی‌گرداند. در این مرحله هیچ تغییری در رجیستری توزیع شده رخ نمی دهد. اپلیکیشن کلاینت امضای Endorsing Peer را بررسی می‌کند، و همچنین داده‌های تراکنش اصلی ارسال شده و داده‌های بازگردانده شده را مقایسه می‌کند (یعنی بررسی می‌کند که آیا داده‌های اصلی که تراکنش شبیه‌سازی شده است، تحریف شده‌اند). اگر تراکنش فقط برای خواندن داده ها از رجیستری بود، برنامه مشتری بر این اساس مجموعه Read لازم را دریافت می کند و این معمولاً تراکنش را بدون تغییر رجیستری توزیع شده با موفقیت تکمیل می کند. در مورد تراکنش‌هایی که باید داده‌ها را در رجیستری تغییر دهد، برنامه مشتری همچنین اجرای سیاست تایید را بررسی می‌کند. این امکان وجود دارد که یک برنامه مشتری نتیجه اجرای سیاست تایید را بررسی نکند، اما پلت فرم Hyperledger Fabric در این مورد امکان بررسی سیاست های گره ها (Committing Peers) را در مرحله افزودن تراکنش به رجیستری فراهم می کند.

تصویر 4. برگرداندن داده ها به برنامه مشتری

4) ارسال مجموعه های RW به Ordering Peers

برنامه مشتری تراکنش را به همراه داده های همراه به سرویس سفارش ارسال می کند. این شامل مجموعه RW، تأیید امضای همتایان، و شناسه کانال است.

سرویس سفارش – بر اساس نام، وظیفه اصلی این سرویس ترتیب تراکنش های ورودی به ترتیب صحیح است. و همچنین تشکیل یک بلوک جدید از رجیستری توزیع شده و تحویل تضمینی بلوک های تولید شده جدید به تمام گره های Commiting، در نتیجه ثبات داده ها در تمام گره های حاوی رجیستری توزیع شده (Committing peers) تضمین می شود. در عین حال خود سرویس Ordering به هیچ وجه رجیستری را تغییر نمی دهد. Ordering Service جزء حیاتی سیستم است، بنابراین خوشه ای از چندین گره است. سرویس سفارش تراکنش را از نظر اعتبار بررسی نمی کند، فقط یک تراکنش با یک شناسه کانال خاص را می پذیرد، تراکنش های دریافتی را به ترتیب خاصی ترتیب می دهد و بلوک های جدیدی از رجیستری توزیع شده را از آنها تشکیل می دهد. یک سرویس سفارش می تواند چندین کانال را به طور همزمان ارائه دهد. سرویس سفارش شامل یک خوشه کافکا است که صف تراکنش صحیح (غیرقابل تغییر) را حفظ می کند (نقطه 7 را ببینید).

تصویر 5. ارسال مجموعه های RW به Ordering Peers

5) ارسال بلوک های تولید شده به Committing Peer

بلوک های تولید شده در Ordering Service به تمام گره های شبکه منتقل می شوند (پخش می شوند). هر گره با دریافت یک بلوک جدید، آن را برای انطباق با خط‌مشی تأیید بررسی می‌کند، بررسی می‌کند که همه همتایان تأییدکننده در نتیجه شبیه‌سازی قرارداد هوشمند، نتیجه یکسانی (مجموعه نوشتن) را دریافت کرده‌اند، و همچنین بررسی می‌کند که آیا مقادیر اصلی دارای چنین هستند یا خیر. از لحظه شروع تراکنش تغییر کرد (یعنی Read Set - داده های خوانده شده توسط قرارداد هوشمند از WorldState). اگر همه شرایط رعایت شود، معامله به عنوان معتبر علامت گذاری می شود، در غیر این صورت، تراکنش وضعیت نامعتبر را دریافت می کند.

تصویر 6. ارسال بلوک های تولید شده به Committing Peer

6) اضافه کردن یک بلوک به رجیستری

هر گره یک تراکنش را به نسخه محلی خود از رجیستری توزیع شده اضافه می کند، و اگر تراکنش معتبر باشد، مجموعه Write به WorldState (وضعیت فعلی) اعمال می شود و بر این اساس، مقادیر جدیدی از اشیاء تحت تأثیر قرار می گیرند. معامله نوشته شده است. اگر یک تراکنش توکنی دریافت کرد که معتبر نیست (به عنوان مثال، دو تراکنش با اشیاء مشابه در یک بلوک اتفاق افتاده است، یکی از تراکنش‌ها نامعتبر خواهد بود، زیرا مقادیر اصلی قبلاً توسط دیگری تغییر کرده است. معامله). این تراکنش نیز با یک توکن نامعتبر به دفتر کل توزیع شده اضافه می شود، اما مجموعه Write این تراکنش برای WorldState فعلی اعمال نمی شود و بر این اساس، اشیاء شرکت کننده در تراکنش را تغییر نمی دهد. پس از این، یک اعلان به اپلیکیشن کاربر مبنی بر اضافه شدن دائم تراکنش به رجیستری توزیع شده و همچنین وضعیت تراکنش، یعنی معتبر بودن یا نبودن تراکنش ارسال می شود...

تصویر 7. افزودن یک بلوک به رجیستری

خدمات سفارش

سرویس سفارش شامل یک خوشه کافکا با گره‌های ZooKeeper و گره‌های خدمات سفارش (OSN) است که بین مشتریان خدمات سفارش‌دهنده و خوشه کافکا قرار دارند. خوشه کافکا یک پلت فرم مدیریت جریان (پیام) توزیع شده و متحمل خطا است. هر کانال (موضوع) در کافکا یک دنباله تغییر ناپذیر از رکوردها است که فقط از افزودن یک رکورد جدید پشتیبانی می کند (حذف یک رکورد موجود امکان پذیر نیست). تصویری از ساختار موضوع در زیر نشان داده شده است. این ویژگی کافکا است که برای ساخت یک پلتفرم بلاک چین استفاده می شود.

برگرفته از kafka.apache.org

• تصویر 8. ساختار موضوع خدمات سفارش*

لینک های مفید

یوتیوب – ساخت یک بلاک چین برای تجارت با پروژه Hyperledger
Hyperledger Fabric Docs
پارچه Hyperledger: یک سیستم عامل توزیع شده برای بلاک چین های مجاز

تقدیر و تشکر

مایلم از همکارانم در تهیه این مقاله تشکر و قدردانی کنم:
نیکولای مارین
ایگور خاپوف
دیمیتری گورباچف
الکساندر زمتسوف
اکاترینا گوسوا

منبع: www.habr.com