معماری توضیح داده شده است

معماری پارچه Hyperledger مزایای زیر را ارائه می دهد:

• انعطاف پذیری اعتماد به کد زنجیره ای. این معماری فرضیات اعتماد برای کدهای زنجیره ای (برنامه های blockchain) را از فرضیات اعتماد برای سفارش جدا می کند. به عبارت دیگر ، سرویس سفارش ممکن است توسط یک مجموعه از گره ها (سفارش دهنده ها) ارائه شود و برخی از آنها را برای ناکامی یا نادرست تحمل کنید و تأیید کنندگان ممکن است برای هر کد زنجیره ای متفاوت باشند.
• مقیاس پذیریاز آنجا که گره های تأیید کننده مسئول کد زنجیره ای خاص برای سفارش دهندگان متعامد هستند ، ممکن است سیستم بهتر از این باشد که این توابع توسط همان گره ها انجام شود. به طور خاص ، این نتیجه می گیرد که کد های زنجیره ای مختلف تأیید کننده های جداگانه را مشخص می کنند ، که یک پارتیشن بندی از کد های زنجیره ای بین تأیید کنندگان را معرفی می کند و امکان اجرای کد زنجیره ای موازی (تأیید) را فراهم می کند. علاوه بر این ، اجرای کد زنجیره ای ، که به طور بالقوه می تواند پرهزینه باشد ، از مسیر بحرانی سرویس سفارش حذف می شود.
• محرمانه بودناین معماری استقرار کدهای زنجیره ای را که دارای الزامات محرمانه بودن با توجه به محتوا و به روزرسانی های دولتی معاملات آن هستند ، تسهیل می کند.
• مدولار اجماع. معماری مدولار است و امکان اجرای اجماع قابل استفاده را (یعنی سرویس سفارش) فراهم می کند.

قسمت اول: عناصر معماری مربوط به پارچه Hyperledger v1

گردش کار اساسی تأیید معامله

قسمت دوم: عناصر پس از V1 معماری

بازرسی لجر (هرس)

1. معماری سیستم ¶

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

1. 1معاملات

معاملات ممکن است از دو نوع باشد:

• استقرار معاملات باعث ایجاد کد جدید و برنامه به عنوان پارامتر می شود. هنگامی که یک معامله مستقر با موفقیت انجام می شود ، کد زنجیره ای "روی" blockchain نصب شده است.
• معاملات فراخوانی عملیاتی را در زمینه کد زنجیره ای که قبلاً مستقر شده است ، انجام می دهند. یک معامله فراخوانی به یک کد زنجیره ای و یکی از کارکردهای ارائه شده آن اشاره دارد. در صورت موفقیت ، کد زنجیره ای عملکرد مشخص شده را اجرا می کند - که ممکن است شامل اصلاح حالت مربوطه و بازگشت یک خروجی باشد.

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

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

1. 2blockchain datastructureces¶

1. 2. 1. حالت¶

آخرین حالت blockchain (یا ، به سادگی ، حالت) به عنوان یک فروشگاه با ارزش کلیدی نسخه (KVS) مدل شده است ، جایی که کلیدها نام و مقادیر دارای حباب های دلخواه هستند. این مدخل ها توسط کدهای زنجیره ای (برنامه ها) که از طریق قرار دادن و دریافت KVS-Operations روی blockchain اجرا می شوند ، دستکاری می شوند. دولت به طور مداوم ذخیره می شود و به روزرسانی های دولت وارد می شود. توجه کنید که KVS نسخه ای به عنوان مدل دولتی اتخاذ شده است ، یک اجرای ممکن است از KVS های واقعی ، بلکه RDBMSS یا هر راه حل دیگر استفاده کند.

More formally, state s is modeled as an element of a mapping K >(v x n) ، جایی که:

• k مجموعه ای از کلیدها است
• v مجموعه ای از مقادیر است
• N is an infinite ordered set of version numbers. Injective function next: N >n یک عنصر N را می گیرد و شماره نسخه بعدی را برمی گرداند.

هر دو V و N حاوی یک عنصر خاص ⊥ (نوع خالی) هستند که در مورد N کمترین عنصر است. در ابتدا تمام کلیدها به (⊥ ، ⊥) نقشه برداری می شوند. برای s (k) = (v ، ver) ما V را با s (k) . Value ، و ver by s (k) نشان می دهیم.

عملیات KVS به شرح زیر است:

• قرار دادن (k ، v) برای k ∈ K و V ∈ V ، حالت blockchain s را می گیرد و آن را به s "s '(k) = (v ، next (s (k))) با s تغییر می دهد.(k ') = s (k') برای همه k '! = k.
• دریافت (k) S (k) را برگردانید.

دولت توسط همسالان نگهداری می شود ، اما نه توسط سفارش دهنده ها و مشتری ها.

پارتیشن بندی دولتی. کلیدهای موجود در KV ها را می توان از نام آنها برای تعلق به یک کد زنجیره ای خاص تشخیص داد ، به این معنا که تنها معامله یک کد زنجیره ای خاص ممکن است کلیدهای متعلق به این کد زنجیره ای را تغییر دهد. در اصل ، هر کد زنجیره ای می تواند کلیدهای متعلق به سایر کد های زنجیره ای را بخواند. پشتیبانی از معاملات کد متقابل ، که وضعیت متعلق به دو یا چند کد زنجیره ای را تغییر می دهد ، یک ویژگی پس از V1 است.

1. 2. 2 Ledger¶

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

Ledger توسط سرویس سفارش (به Sec 1. 3. 3 مراجعه کنید) به عنوان یک هشچین کاملاً سفارش داده شده از بلوک های معاملات (معتبر یا نامعتبر) ساخته شده است. Hashchain ترتیب کل بلوک ها را در یک دفترچه تحمیل می کند و هر بلوک شامل مجموعه ای از معاملات کاملاً سفارش داده شده است. این امر سفارش کل را در تمام معاملات تحمیل می کند.

لجر در همه همسالان و به صورت اختیاری در زیر مجموعه ای از سفارش دهندگان نگهداری می شود. در زمینه یک سفارش دهنده ، ما به Ledger به عنوان Ordererledger اشاره می کنیم ، در حالی که در زمینه یک همسالان ما به دفترچه به عنوان Peerledger اشاره می کنیم. Peerledger با سفارش دهنده متفاوت است زیرا همسالان به صورت محلی یک بیت ماسک را حفظ می کنند که معاملات معتبر را از موارد نامعتبر جدا می کند (برای اطلاعات بیشتر به بخش xx مراجعه کنید).

همسالان ممکن است Peerledger را همانطور که در بخش XX توضیح داده شده است ، هرس کنند. سفارش دهندگان برای تحمل گسل و در دسترس بودن (از Peerledger) سفارش دهنده را حفظ می کنند و ممکن است تصمیم بگیرند که در هر زمان هرس کنند ، مشروط بر اینکه خواص سرویس سفارش (به Sec 1. 3. 3 مراجعه کنید) حفظ شود.

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

1. 3گره ها

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

سه نوع گره وجود دارد:

1. مشتری یا مشتری ارائه دهنده: مشتری که یک انتقال واقعی معامله را به تأیید کنندگان ارسال می کند و پروانه های معامله را به سرویس سفارش پخش می کند.
2. همکار: گره ای که مرتکب معاملات و حفظ دولت و یک نسخه از دفترچه می شود (به SEC ، 1. 2 مراجعه کنید). علاوه بر این ، همسالان می توانند نقش ویژه ای داشته باشند.
3. Node یا سفارش دهنده سفارش دهنده: گره ای که سرویس ارتباطی را اجرا می کند که ضمانت تحویل را اجرا می کند ، مانند پخش اتمی یا کل سفارش.

انواع گره ها با جزئیات بیشتر توضیح داده می شوند.

1. 3. 1. مشتری¶

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

همانطور که در بخش 2 به تفصیل شرح داده شده است ، مشتری ها با همسالان و سرویس سفارش ارتباط برقرار می کنند.

1. 3. 2. همسالان

یک همسالان به روزرسانی های دولتی سفارش داده شده را در قالب بلوک های سرویس سفارش دریافت می کند و دولت و دفترچه را حفظ می کند.

علاوه بر این ، همسالان می توانند نقش ویژه ای از همسالان تأیید کننده یا یک تأیید کننده را به عهده بگیرند. عملکرد ویژه یک همسالان تأیید کننده با توجه به یک کد زنجیره ای خاص رخ می دهد و شامل تأیید معامله قبل از انجام آن است. هر کد زنجیره ای ممکن است یک خط مشی تأیید را مشخص کند که ممکن است به مجموعه ای از همسالان تأیید کننده اشاره کند. این خط مشی شرایط لازم و کافی را برای تأیید معامله معتبر (به طور معمول مجموعه ای از امضاهای تأیید کنندگان) تعریف می کند ، همانطور که بعداً در بخش های 2 و 3 توضیح داده شده است. به عنوان یک سیاست تأیید کد زنجیره ای سیستم مشخص شده است.

1. 3. 3. سفارش گره های خدمات (سفارش دهنده ها)

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

سرویس سفارش یک کانال ارتباطی مشترک را به مشتریان و همسالان ارائه می دهد و یک سرویس پخش برای پیام های حاوی معاملات ارائه می دهد. مشتریان به کانال متصل می شوند و ممکن است پیام هایی را از کانال پخش کنند که سپس به همه همسالان تحویل داده می شوند. این کانال از تحویل اتمی کلیه پیام ها ، یعنی ارتباط پیام با تحویل مرتبه کل و قابلیت اطمینان (خاص اجرای) پشتیبانی می کند. به عبارت دیگر ، کانال پیام های یکسانی را برای همه همسالان متصل وارد می کند و آنها را به همه همسالان در یک نظم منطقی می رساند. این ضمانت ارتباطات اتمی همچنین در زمینه سیستم های توزیع شده ، پخش سفارش کل ، پخش اتمی یا اجماع نامیده می شود. پیام های ابلاغ شده معاملات نامزد برای گنجاندن در حالت blockchain است.

پارتیشن بندی (کانال های سرویس سفارش). سرویس سفارش ممکن است از کانال های چندگانه شبیه به مباحث سیستم پیام رسانی انتشار/اشتراک (Pub/Sub) پشتیبانی کند. مشتریان می توانند به یک کانال معین متصل شوند و سپس می توانند پیام ارسال کنند و پیام هایی را که وارد می شوند به دست آورند. کانال ها را می توان به عنوان پارتیشن ها تصور کرد - مشتریانی که به یک کانال وصل می شوند از وجود کانال های دیگر بی خبر هستند ، اما مشتری ها ممکن است به چندین کانال متصل شوند. حتی اگر برخی از پیاده سازی های خدمات سفارش دهنده شامل پارچه هایپلدرگر از چندین کانال پشتیبانی می کنند ، برای سادگی در ارائه ، در بقیه این سند ، فرض می کنیم سرویس سفارش شامل یک کانال/موضوع واحد است.

سفارش API خدمات. همسالان از طریق رابط ارائه شده توسط سرویس سفارش ، به کانال ارائه شده توسط سرویس سفارش وصل می شوند. API سرویس سفارش شامل دو عملیات اساسی (به طور کلی رویدادهای ناهمزمان) است:

TODO بخشی از API را برای واکشی بلوک های خاص تحت شماره های توالی مشخص شده مشتری/همکار اضافه می کند.

• Broadcast (Blob): مشتری این کار را برای پخش یک حباب پیام دلخواه برای انتشار از طریق کانال فراخوانی می کند. این همچنین هنگام ارسال درخواست به یک سرویس ، در متن BFT نیز درخواست (Blob) نامیده می شود.
• تحویل (SEQNO ، PREVHASH ، Blob): سرویس سفارش این کار را به همسالان فرا می خواند تا پیام را با شماره توالی عدد صحیح غیر منفی مشخص شده (SEQNO) و هش از Blob که اخیراً تحویل داده شده است (PrevHash) تحویل دهد. به عبارت دیگر ، این یک رویداد خروجی از سرویس سفارش است. تحویل () نیز گاهی اوقات در سیستم های زیر میخانه () در سیستم های زیر میخانه یا متعهد () در سیستم های BFT نامیده می شود.

دفترچه و تشکیل بلوک. دفترچه (همچنین به Sec. 1. 2. 2 مراجعه کنید) شامل تمام خروجی داده ها توسط سرویس سفارش است. به طور خلاصه ، این یک توالی از وقایع تحویل (Seqno ، Prevhash ، Blob) است که با توجه به محاسبه Prevhash که قبلاً شرح داده شده است ، زنجیره هش را تشکیل می دهند.

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

در ادامه، برای سهولت ارائه، ویژگی های خدمات سفارش (بقیه این بخش) را تعریف می کنیم و گردش کار تأیید تراکنش (بخش 2) را با فرض یک لکه در هر رویداد تحویل توضیح می دهیم. اینها به راحتی به بلوک ها تعمیم داده می شوند، با این فرض که یک رویداد تحویل برای یک بلوک مطابق با ترتیبی از رویدادهای تحویل فردی برای هر لکه در یک بلوک، مطابق با ترتیب قطعی ذکر شده در بالا، حباب ها در یک بلوک است.

سفارش املاک خدمات

ضمانت های سرویس سفارش (یا کانال پخش اتمی) مشخص می کند که برای یک پیام پخش شده چه اتفاقی می افتد و چه روابطی بین پیام های ارسال شده وجود دارد. این تضمین ها به شرح زیر است:

ایمنی (ضمانت های سازگاری): تا زمانی که همتاها برای مدت زمان کافی به کانال متصل باشند (می توانند قطع یا خراب شوند، اما دوباره راه اندازی می شوند و دوباره وصل می شوند)، یک سری یکسان از ارسال ها را مشاهده خواهند کرد (seqno، prevhash، blob)پیام ها. این بدان معناست که خروجی ها (رویدادهای deliver()) به یک ترتیب در همه همتایان و با توجه به شماره دنباله رخ می دهند و محتوای یکسانی (blob و prevhash) برای همان شماره دنباله دارند. توجه داشته باشید که این فقط یک دستور منطقی است و تحویل (seqno، prevhash، blob) در یک همتا لازم نیست در هیچ رابطه بلادرنگی برای تحویل (seqno، prevhash، blob) که همان پیام را در همتای دیگر خروجی می دهد، رخ دهد. به عبارت دیگر، با توجه به یک seqno خاص، هیچ دو همتای درستی مقادیر مختلف prevhash یا blob را ارائه نمی دهند. علاوه بر این، هیچ حباب مقداری تحویل داده نمی شود مگر اینکه برخی از مشتریان (همتایان) در واقع پخش (blob) نامیده شوند و ترجیحاً هر حباب پخش شده فقط یک بار تحویل داده شود.

علاوه بر این، رویداد deliver() حاوی هش رمزنگاری داده ها در رویداد deliver() قبلی (prevhash) است. وقتی سرویس سفارش دهنده ضمانت های پخش اتمی را اجرا می کند، prevhash هش رمزنگاری پارامترهای رویداد deliver() با شماره دنباله seqno-1 است. این یک زنجیره هش در میان رویدادهای deliver() ایجاد می کند، که برای کمک به تأیید صحت خروجی سرویس سفارش، همانطور که در بخش های 4 و 5 بعد بحث شد، استفاده می شود. در مورد ویژه اولین رویداد deliver()، prevhash یک مقدار پیش فرض دارد.

زنده بودن (ضمانت تحویل): ضمانت های زنده بودن سرویس سفارش توسط اجرای سرویس سفارش مشخص می شود. تضمین های دقیق ممکن است به مدل خطای شبکه و گره بستگی داشته باشد.

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

به طور خلاصه ، سرویس سفارش ویژگی های زیر را تضمین می کند:

• توافق. برای هر دو رویداد در همسالان صحیح (SEQNO ، PREVHASH0 ، BlOB0) و تحویل (SEQNO ، PREVHASH1 ، BlOB1) با همان SEQNO ، PREVHASH0 == PREVHASH1 و BLOB0 == Blob1 ؛
• یکپارچگی هاشچین. برای هر دو رویداد در همسالان صحیح (SEQNO-1 ، PREVHASH0 ، BlOB0) و تحویل (Seqno ، Prevhash ، Blob) ، PrevHash = Hash (Seqno-1 || PrevHash0 || Blob0).
• No skipping . If an ordering service outputs deliver(seqno, prevhash, blob) at a correct peer p , such that seqno>0 ، سپس P در حال حاضر تحویل رویداد (Seqno-1 ، PrevHash0 ، Blob0) را تحویل داده است.
• بدون خلقتهر رویدادی (Seqno ، Prevhash ، Blob) در یک همسالان صحیح باید قبل از یک رویداد پخش (Blob) در برخی از همسالان (احتمالاً مجزا) انجام شود.
• بدون تکثیر (اختیاری ، اما در عین حال مطلوب). برای هر دو رویداد پخش شده (Blob) و پخش (Blob ') ، هنگامی که دو رویداد (SEQNO0 ، PREVHASH0 ، BLOB) ارائه می دهند و تحویل (SEQNO1 ، PREVHASH1 ، Blob') در همسالان صحیح و Blob == Blob 'رخ می دهد ، سپس SEQNO0 == SEQNO1 و PREVHASH0 == PREVHASH1.
• زندگیاگر یک مشتری صحیح از یک رویداد پخش (Blob) فراخوانی کند ، هر یک از همسالان صحیح "در نهایت" یک رویداد را ارائه می دهد ( *، *، Blob) ، جایی که *یک مقدار دلخواه را نشان می دهد.

2. گردش کار اساسی تأیید معاملات

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

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

2. 1مشتری یک معامله ایجاد می کند و آن را برای تأیید همسالان مورد نظر خود ارسال می کند.

برای فراخوانی یک معامله ، مشتری یک پیام پیشنهادی را به مجموعه ای از همسالان تأیید کننده مورد نظر خود ارسال می کند (احتمالاً در همان زمان نیست - به بخش های 2. 1. 2 و 2. 3 مراجعه کنید). مجموعه ای از همسالان تأیید شده برای یک کادوی زنجیره ای معین از طریق همسالان در دسترس مشتری قرار می گیرد ، که به نوبه خود مجموعه ای از همسالان تأیید را از خط مشی تأیید می داند (بخش 3 را ببینید). به عنوان مثال ، معامله می تواند برای همه تأیید کنندگان یک کادوی زنجیره ای معین ارسال شود. گفته می شود ، برخی از تأیید کنندگان می توانند آفلاین باشند ، برخی دیگر ممکن است اعتراض کنند و تصمیم بگیرند که معامله را تأیید کنند. مشتری ارسال کننده سعی می کند بیان خط مشی را با تأیید کنندگان موجود برآورده کند.

در ادامه ، ما ابتدا جزئیات پیام را ارائه می دهیم و سپس در مورد الگوهای احتمالی تعامل بین ارسال مشتری و تأیید کنندگان بحث می کنیم.

2. 1. 1. قالب پیام را پیشنهاد دهید

قالب یک پیام پیشنهادی در جایی است که TX یک استدلال اختیاری اجباری و لنگر است که در زیر توضیح داده شده است.

• ClientID شناسه مشتری ارسال کننده است ،
• chaincodeid به کد زنجیره ای که معامله مربوط به آن است اشاره دارد ،
• txpayload بار پرداختی است که شامل معامله ارسالی شده است ،
• Timestamp یک عدد صحیح در حال افزایش (برای هر معامله جدید) است که توسط مشتری نگهداری می شود ،
• ClientSig در سایر زمینه های TX امضاء مشتری است.

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

• txpayload = ، کجا
  • عملیات نشان دهنده عملکرد کد زنجیره ای (عملکرد) و آرگومان ها است ،
  • ابرداده ویژگی های مربوط به دعوت را نشان می دهد.

  برای معامله مستقر ، TxPayload از سه قسمت تشکیل شده است

  • txpayload = ، کجا
    • منبع کد منبع کد زنجیره را نشان می دهد ،
    • ابرداده ویژگی های مربوط به کد زنجیره ای و کاربرد را نشان می دهد ،
    • خط مشی ها شامل سیاست های مربوط به کد زنجیره ای است که برای همه همسالان مانند خط مشی تأیید قابل دسترسی است. توجه داشته باشید که خط مشی های تأیید در یک معامله مستقر با TxPayload ارائه نمی شود ، اما بار TXPAYLE از استقرار شامل شناسه سیاست تأیید و پارامترهای آن است (به بخش 3 مراجعه کنید).

    Anchor حاوی وابستگی های نسخه Read یا به طور خاص جفت های کلیدی است (به عنوان مثال ، Anchor زیر مجموعه KXN است) ، که درخواست پیشنهادی برای نسخه های مشخص شده از کلیدها در KVS را به آن متصل یا "لنگر" می کند (به بخش 1. 2 مراجعه کنید). اگر مشتری استدلال لنگر را مشخص کند ، یک تأیید کننده فقط با شماره نسخه نسخه کلیدهای مربوطه در لنگر محلی KVS خود ، معامله را تأیید می کند (برای اطلاعات بیشتر به بخش 2. 2 مراجعه کنید).

    هش رمزنگاری TX توسط همه گره ها به عنوان یک شناسه معامله منحصر به فرد TID استفاده می شود (یعنی TID = هش (TX)). مشتری در حافظه مرتب می شود و منتظر پاسخ از همسالان تأیید می شود.

    2. 1. 2. الگوهای پیام

    مشتری در مورد توالی تعامل با تأیید کنندگان تصمیم می گیرد. به عنوان مثال ، مشتری معمولاً (به عنوان مثال ، بدون آرگومان لنگر) را به یک تأیید کننده واحد ارسال می کند ، که سپس وابستگی های نسخه (لنگر) را تولید می کند که مشتری بعداً می تواند از آن به عنوان استدلال پیام پیشنهادی خود به سایر تأیید کنندگان استفاده کند. به عنوان نمونه دیگر ، مشتری می تواند مستقیماً (بدون لنگر) را به همه تأیید کنندگان مورد نظر خود ارسال کند. الگوهای مختلف ارتباطی امکان پذیر است و مشتری برای تصمیم گیری در مورد آن ها رایگان است (همچنین به بخش 2. 3 مراجعه کنید).

    2. 2تأیید کننده همسالان یک معامله را شبیه سازی می کند و امضای تأیید را تولید می کند

    در هنگام دریافت پیام از مشتری ، EPID تأیید کننده ابتدا به مشتری امضای مشتری تأیید می کند و سپس یک معامله را شبیه سازی می کند. اگر مشتری لنگر را مشخص کند ، تأیید همسالان فقط با شماره نسخه های خوانده شده (به عنوان مثال ، خواندن همانطور که در زیر تعریف شده است) از کلیدهای مربوطه در KVS محلی خود با آن شماره های نسخه های مشخص شده توسط Anchor مطابقت دارد.

    شبیه سازی یک معامله شامل تأیید همسالان به طور آزمایشی معامله (TXPAYLOAD) ، با استناد به کد زنجیره ای که معامله به آن (ChainCodeID) و کپی از وضعیتی که همسالان تأیید کننده در آن در اختیار دارند ، استفاده می کند.

    در نتیجه اجرای ، تأیید کننده همسالان ، وابستگی های نسخه (خواندن) و به روزرسانی های حالت (Writeset) را محاسبه می کند ، همچنین به نام MVCC+اطلاعات postimage به زبان DB نامیده می شود.

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

    • با توجه به دولت قبل از تأیید همسالان ، معامله ای را انجام می دهد ، برای هر K Key که توسط معامله خوانده می شود ، جفت (k ، s (k) . version) به خواندن اضافه می شود.
    • علاوه بر این ، برای هر کلید K اصلاح شده توسط معامله به مقدار جدید V '، جفت (K ، V') به Writeset اضافه می شود. از طرف دیگر ، V 'می تواند دلتای مقدار جدید به مقدار قبلی (S (k) . Value) باشد.

    اگر مشتری لنگر را در پیام پیشنهادی مشخص کند ، لنگرگاه مشخص شده مشتری باید با تأیید همسالان هنگام شبیه سازی معامله ، با تأیید همسالان تولید شود.

    سپس ، همسالان به صورت داخلی (و احتمالاً TX) به بخشی از منطق خود (همسالان) که یک معامله را تأیید می کند ، پیش می رود ، که از آن به عنوان منطق تأیید کننده یاد می شود. به طور پیش فرض ، تأیید منطق در یک همسالان ، تروپوس را می پذیرد و به سادگی تروپوس را امضا می کند. با این حال ، تأیید منطق ممکن است عملکرد خودسرانه را تفسیر کند ، به عنوان مثال ، با سیستم های میراث با Tran-Proposal و TX به عنوان ورودی تعامل داشته باشد تا تصمیم بگیرد که آیا یک معامله را تأیید می کند یا خیر.

    اگر تأیید منطق تصمیم به تأیید یک معامله بگیرد ، پیام را به مشتری ارسال کننده (tx. clientid) ارسال می کند ، جایی که:

    جایی که txcontentblob اطلاعات خاص زنجیره ای/معامله است. هدف این است که از TxContentBlob به عنوان برخی از بازنمایی TX استفاده شود (به عنوان مثال ، txcontentblob = tx. txpayload).

    Epsig امضای همسالان تأیید کننده در Tran-Proposal است

    در غیر این صورت ، در صورتی که منطق تأیید از تأیید معامله امتناع ورزد ، یک تأیید کننده می تواند پیام (با ارزش معامله ، معتبر ، رد شده) را به مشتری ارسال کننده ارسال کند.

    توجه کنید که یک تأیید کننده وضعیت خود را در این مرحله تغییر نمی دهد ، به روزرسانی های تولید شده توسط شبیه سازی معامله در زمینه تأیید بر دولت تأثیر نمی گذارد!

    2. 3مشتری ارسال کننده تأیید را برای یک معامله جمع می کند و آن را از طریق سفارش سرویس پخش می کند

    مشتری ارسال کننده منتظر می ماند تا پیام ها و امضاهای "کافی" را در بیانیه های (تأیید شده توسط معاملات ، TID ، *، *) دریافت کند تا نتیجه بگیرد که پیشنهاد معامله تأیید شده است. همانطور که در بخش 2. 1. 2 بحث شده است ، این ممکن است یک یا چند سفر دور از تعامل با تأیید کنندگان را شامل شود.

    تعداد دقیق "کافی" به خط مشی تأیید کد زنجیره ای بستگی دارد (همچنین به بخش 3 مراجعه کنید). اگر خط مشی تأیید رضایت داشته باشد ، معامله تأیید شده است. توجه داشته باشید که هنوز مرتکب نشده است. مجموعه پیام های تأیید شده توسط معامله شده از تأیید همسالان که نشان می دهد معامله تأیید شده است ، تأیید می شود و با تأیید مشخص می شود.

    اگر مشتری ارسال کننده نتواند تأیید را برای پیشنهاد معامله جمع کند ، این معامله را با گزینه ای برای امتحان مجدد بعداً رها می کند.

    برای معامله با تأیید معتبر ، اکنون استفاده از سرویس سفارش را شروع می کنیم. مشتری ارسال کننده سرویس سفارش را با استفاده از پخش (Blob) ، که در آن حباب = تأیید است ، فراخوانی می کند. اگر مشتری توانایی فراخوانی سرویس سفارش را مستقیم نداشته باشد ، ممکن است پخش خود را از طریق برخی از همسالان مورد نظر خود ارائه دهد. به چنین همسالان باید به مشتری اعتماد کرد که هیچ پیامی را از تأیید حذف نکند یا در غیر این صورت ممکن است معامله نامعتبر تلقی شود. توجه کنید که ، با این حال ، یک همکار پروکسی ممکن است تأیید معتبری را ایجاد نکند.

    2. 4سرویس سفارش معاملات را به همسایگان ارائه می دهد

    هنگامی که یک رویداد تحویل (SEQNO ، PrevHash ، Blob) رخ می دهد و یک همسالان تمام به روزرسانی های حالت را برای حباب ها با شماره توالی پایین تر از Seqno اعمال کرده است ، یک همسالان موارد زیر را انجام می دهد:

    • این بررسی می کند که blob. endorsement با توجه به سیاست کد زنجیره ای (blob. tran-proposal. chaincodeid) که به آن اشاره دارد ، معتبر است.
    • در یک مورد معمولی ، همچنین تأیید می کند که وابستگی ها (blob. endorsement. tran-proposal. readset) در عین حال نقض نشده است. در موارد استفاده پیچیده تر ، زمینه های تروپوزال در تأیید ممکن است متفاوت باشد و در این مورد سیاست تأیید (بخش 3) نحوه تکامل دولت را مشخص می کند.

    تأیید وابستگی ها می تواند به روش های مختلف ، با توجه به خاصیت سازگاری یا "ضمانت انزوا" که برای به روزرسانی های دولت انتخاب شده است ، اجرا شود. Serializability یک ضمانت جداسازی پیش فرض است ، مگر اینکه خط مشی تأیید CHAINCODE یک مورد متفاوت را مشخص کند. با نیاز به نسخه مرتبط با هر کلید در خواندن ، می توان Serializability را فراهم کرد تا با نسخه کلید در ایالت برابر باشد و رد معاملات را که این نیاز را برآورده نمی کند ، رد کند.

    • اگر تمام این چک ها تصویب شود ، معامله معتبر یا متعهد تلقی می شود. در این حالت ، همسالان معامله را با 1 در Bitmask of Peerledger نشان می دهد ، blob. endorsement. tran-proposal. writeset را به حالت blockchain اعمال می کند (اگر پروانه های tran یکسان هستند ، در غیر این صورت منطق سیاست تأیید کننده عملکردی را تعریف می کند که حباب می گیرد. تایید ).
    • اگر تأیید سیاست تأیید Blob. endorsement انجام شود ، معامله نامعتبر است و همسالان معامله را با 0 در Bitmask از Peerledger نشان می دهد. توجه به این نکته حائز اهمیت است که معاملات نامعتبر حالت را تغییر نمی دهد.

    توجه داشته باشید که این کافی است که همه همسالان (صحیح) پس از پردازش یک رویداد تحویل (بلوک) با یک شماره دنباله معین ، وضعیت مشابهی داشته باشند. یعنی ، با ضمانت خدمات سفارش ، همه همسالان صحیح یک توالی یکسان از رویدادهای تحویل (SEQNO ، Prevhash ، Blob) دریافت می کنند. از آنجا که ارزیابی سیاست تأیید و ارزیابی وابستگی های نسخه در خواندن قطعی است ، همه همسالان صحیح نیز به این نتیجه می رسند که آیا معامله موجود در حباب معتبر است یا خیر. از این رو ، همه همسالان مرتکب همان دنباله معاملات می شوند و وضعیت خود را به همان روش به روز می کنند.

    

    شکل 1. تصویر یک جریان معامله احتمالی (مسیر معمول).

    3. سیاست های تأیید

    3. 1مشخصات سیاست تأیید ¶

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

    برای تضمین ویژگی های blockchain و امنیت ، مجموعه ای از سیاست های تأیید باید مجموعه ای از سیاستهای اثبات شده با مجموعه محدودی از کارکردها باشد تا از زمان اجرای محدود (خاتمه) ، تعیین کننده ، عملکرد و امنیت اطمینان حاصل شود.

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

    3. 2ارزیابی معاملات در برابر سیاست تأیید

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

    به طور رسمی سیاست تأیید یک محمول در مورد تأیید است و به طور بالقوه بیان می کند که به درست یا نادرست ارزیابی می شود. برای معاملات مستقر ، تأیید مطابق با یک سیاست در سطح سیستم (به عنوان مثال ، از کد زنجیره ای سیستم) بدست می آید.

    محمول سیاست تأیید به متغیرهای خاصی اشاره دارد. به طور بالقوه ممکن است به:

    1. کلیدها یا هویت مربوط به کد زنجیره ای (که در ابرداده کد زنجیره ای یافت می شود) ، به عنوان مثال ، مجموعه ای از تأیید کنندگان.
    2. ابرداده های بیشتر کد زنجیره ای.
    3. عناصر تأیید و تأیید. tran-proposal ؛
    4. و به طور بالقوه بیشتر

    لیست فوق با افزایش بیان و پیچیدگی سفارش داده می شود ، یعنی پشتیبانی از سیاست هایی که فقط به کلیدها و هویت گره ها اشاره دارند ، نسبتاً ساده خواهد بود.

    ارزیابی پیش بینی سیاست تأیید باید قطعی باشد. تأیید باید توسط هر یک از همسالان به صورت محلی ارزیابی شود به گونه ای که یک همکار نیازی به تعامل با سایر همسالان ندارد ، اما همه همسالان صحیح سیاست تأیید را به همان روش ارزیابی می کنند.

    3. 3مثال سیاست های تأیید

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

    فرض کنید کد زنجیره ای مجموعه Emororser E = را مشخص می کند. برخی از سیاست های مثال:

    • یک امضای معتبر از همان تروپوس از همه اعضای E.
    • امضای معتبر از هر عضو واحد E.
    • امضاهای معتبر در همان پروپوزال از تأیید همسالان با توجه به شرایط (آلیس یا باب) و (هر دو مورد: چارلی ، دیو ، حوا ، فرانک ، جورج).
    • Valid signatures on the same tran-proposal by any 5 out of the 7 endorsers. (More generally, for chaincode with n>3F تأیید کنندگان ، امضاهای معتبر توسط هر 2F+1 از طرف N و یا توسط هر گروه بیش از (N+F)/2 تأیید کننده.)
    • فرض کنید واگذاری "سهام" یا "وزن" به تأیید کنندگان وجود دارد ، مانند این که سهم کل 100 است: این سیاست به امضاهای معتبر از مجموعه ای نیاز دارد که اکثریت سهام را دارد (یعنی گروهی با سهام ترکیبی به شدتبیش از 50) ، مانند هر X متفاوت از جورج ، یا. و غیره
    • واگذاری سهام در شرط مثال قبلی می تواند استاتیک باشد (در ابرداده کد زنجیره ای ثابت) یا پویا (به عنوان مثال ، بستگی به وضعیت کد زنجیره ای و در طول اجرای آن اصلاح می شود).
    • امضاهای معتبر از (آلیس یا باب) در Tran-Proposal1 و امضاهای معتبر از (هر دو از: چارلی ، دیو ، حوا ، فرانک ، جورج) در Tran-Proposal2 ، جایی که Tran-proposal1 و tran-proposal2 فقط در همسالان تأیید شده خود متفاوت هستندو به روزرسانی های دولتی

    این سیاست ها چقدر مفید هستند ، به برنامه ، به مقاومت مورد نظر راه حل در برابر خرابی یا رفتار نادرست تأیید کنندگان و سایر خصوصیات دیگر بستگی دارد.

    4 (پس از V1). ویراستار لجر و Peerledger (هرس) معتبر

    4. 1Ledger معتبر (Vledger)

    برای حفظ انتزاع یک دفترچه که فقط شامل معاملات معتبر و متعهد است (که به عنوان مثال در بیت کوین ظاهر می شود) ، همسالان ممکن است علاوه بر دولت و دفترچه ، دفترچه معتبر (یا Vledger) را حفظ کنند. این یک زنجیره هش است که با فیلتر کردن معاملات نامعتبر از دفترچه گرفته شده است.

    ساخت بلوک های Vledger (که در اینجا VBLOCKS نامیده می شود) به شرح زیر است. از آنجا که بلوک های Peerledger ممکن است حاوی معاملات نامعتبر باشد (یعنی معاملات با تأیید نامعتبر یا با وابستگی به نسخه نامعتبر) ، چنین معاملات قبل از معامله از یک بلوک به یک VBLOCK توسط همسالان فیلتر می شوند. هر همسالان این کار را به خودی خود انجام می دهد (به عنوان مثال ، با استفاده از bitmask مرتبط با Peerledger). VBLOCK به عنوان بلوک بدون معاملات نامعتبر تعریف شده است ، که فیلتر شده اند. چنین Vblocks ذاتاً از نظر اندازه پویا و ممکن است خالی باشد. نمونه ای از ساخت و ساز VBlock در شکل زیر آورده شده است.

    

    شکل 2. تصویر سازند بلوک لجر معتبر (VBLOCK) از بلوک های لجر (Peerledger).

    Vblocks توسط هر یک از همسالان به یک زنجیره هش زنجیر می شوند. به طور خاص ، هر بلوک از یک دفترچه معتبر شامل:

    • هش VBlock قبلی.
    • شماره Vblock.
    • لیست سفارش داده شده از کلیه معاملات معتبر که توسط همسالان انجام شده است از آخرین VBLOCK محاسبه شده است (یعنی لیست معاملات معتبر در یک بلوک مربوطه).
    • هش بلوک مربوطه (در Peerledger) که Vblock فعلی از آن گرفته می شود.

    تمام این اطلاعات توسط یک همسالان به هم پیوسته و هشدار داده می شود و هش از Vblock را در دفترچه معتبر تولید می کند.

    4. 2Peerledger Checkpointing¶ ¶

    دفترچه شامل معاملات نامعتبر است ، که لزوماً برای همیشه ثبت نشده است. با این حال ، همسالان نمی توانند به سادگی بلوک های همسایه را دور بیندازند و از این طریق PEERLEDGER را پس از ایجاد VBLOCKS مربوطه ، هرس کنند. یعنی ، در این حالت ، اگر یک همسالان جدید به شبکه بپیوندد ، سایر همسالان نمی توانند بلوک های دور ریخته شده (مربوط به Peerledger) را به همسالان پیوسته منتقل کنند ، و نه به همسایه پیوستن به اعتبار VBlocks خود را متقاعد کنند.

    برای تسهیل هرس PeerLedger، این سند مکانیزم ایست بازرسی را توصیف می کند. این مکانیسم اعتبار vBlocks را در سراسر شبکه همتا تعیین می کند و به vBlock های دارای نقطه چک اجازه می دهد تا بلوک های دور انداخته شده PeerLedger را جایگزین کنند. این به نوبه خود فضای ذخیره سازی را کاهش می دهد، زیرا نیازی به ذخیره تراکنش های نامعتبر نیست. همچنین کار بازسازی حالت را برای همتایان جدیدی که به شبکه می پیوندند کاهش می دهد (زیرا آنها نیازی به تأیید اعتبار تراکنش های فردی در هنگام بازسازی وضعیت با پخش مجدد PeerLedger ندارند، بلکه ممکن است به سادگی به روزرسانی های وضعیت موجود در دفتر کل معتبر را دوباره پخش کنند).

    4. 2. 1. پروتکل نقطه بازرسی¶

    چک پوینت به صورت دوره ای توسط همتایان هر بلوک CHK انجام می شود، جایی که CHK یک پارامتر قابل تنظیم است. برای شروع یک چک پوینت، همتایان پیام (به عنوان مثال، شایعات) را برای سایر همتایان ارسال می کنند، که در آن blockno شماره بلاک فعلی و blocknohash هش مربوطه آن است، stateHash هش آخرین وضعیت است (مثلاً یک هش Merkle) پس از تأیید اعتبار. بلوک blockno و peerSig امضای همتا در (CHECKPOINT, blocknohash, blockno, stateHash) است که به دفتر معتبر اشاره دارد.

    یک همتا پیام های CHECKPOINT را جمع آوری می کند تا زمانی که پیام های امضا شده کافی با blockno، blocknohash و stateHash منطبق را برای ایجاد یک چک پوینت معتبر به دست آورد (به بخش 4. 2. 2 مراجعه کنید).

    پس از ایجاد یک چک پوینت معتبر برای بلوک شماره blockno با blocknohash، یک همتا:

    • if blockno>latestValidCheckpoint. blockno، سپس یک همتا آخرینValidCheckpoint=(blocknohash, blockno) را اختصاص می دهد،
    • مجموعه ای از امضاهای همتا مربوطه را که یک نقطه بازرسی معتبر را تشکیل می دهند در مجموعه latestValidCheckpointProof ذخیره می کند.
    • وضعیت مربوط به stateHash را در latestValidCheckpointedState ذخیره می کند.
    • (به صورت اختیاری) PeerLedger خود را تا بلوک شماره blockno (شامل) هرس می کند.

    4. 2. 2. پست های بازرسی معتبر

    واضح است که پروتکل نقطه بازرسی سؤالات زیر را مطرح می کند: چه زمانی یک همتا می تواند «PeerLedger» خود را هرس کند؟چند پیام «نقطه بازرسی» «به اندازه کافی زیاد» است؟. این توسط یک خط مشی اعتبار نقطه بازرسی، با (حداقل) دو رویکرد ممکن، که ممکن است با هم ترکیب شوند، تعریف می شود: