گسل بیزانس

از ویکیپدیا، دانشنامه آزاد
(تغییر مسیر از تحمل گسل بیزانس )
پرش به ناوبری پرش به جستجو

خطای بیزانسی (همچنین مشکل کلیات بیزانس ، سازگاری تعاملی ، تطابق منبع ، بهمن خطا ، مشکل توافق بیزانسی ، و شکست بیزانسی [1] ) شرایط یک سیستم کامپیوتری، به‌ویژه سیستم‌های محاسباتی توزیع‌شده است، که در آن اجزا ممکن است از کار بیفتند و ناقص باشد. اطلاعاتی در مورد اینکه آیا یک جزء از کار افتاده است یا خیر. این اصطلاح نام خود را از تمثیلی گرفته است، "مسئله ژنرال های بیزانسی"، [2]برای توصیف وضعیتی ایجاد شده است که در آن، برای جلوگیری از شکست فاجعه بار سیستم، بازیگران سیستم باید روی یک استراتژی هماهنگ توافق کنند، اما برخی از این بازیگران غیرقابل اعتماد هستند.

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

قیاس [ ویرایش ]

اگر همه ژنرال ها با هماهنگی حمله کنند، نبرد پیروز می شود (سمت چپ). اگر دو ژنرال به دروغ اعلام کنند که قصد حمله دارند، اما در عوض عقب نشینی کنند، نبرد شکست خورده است (راست).

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

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

وضوح [ ویرایش ]

اگر ژنرال های وفادار (غیر خطاکار) در مورد استراتژی خود توافق اکثریت داشته باشند، می توان به تحمل خطا بیزانس دست یافت. ممکن است یک مقدار رأی پیش‌فرض به پیام‌های گمشده داده شود. برای مثال، به پیام‌های گمشده می‌توان مقدار «تهی» داد. بعلاوه، اگر توافق بر این باشد که آرای تهی در اکثریت باشد، می توان از یک استراتژی پیش فرض از پیش تعیین شده استفاده کرد (مثلاً عقب نشینی). [3]

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

خصوصیات [ ویرایش ]

گسل بیزانسی به هر گسلی گفته می شود که علائم متفاوتی را به ناظران مختلف نشان دهد. [4] شکست بیزانسی از دست دادن یک سرویس سیستم به دلیل یک خطای بیزانسی در سیستم هایی است که نیاز به توافق دارند . [5]

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

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

شکست‌های بیزانسی عمومی‌ترین و سخت‌ترین دسته شکست‌ها در میان حالت‌های شکست در نظر گرفته می‌شوند . به اصطلاح حالت خرابی fail-stop ساده ترین انتهای طیف را اشغال می کند. در حالی که حالت شکست Fail-stop به سادگی به این معنی است که تنها راه برای شکست، خرابی گره است که توسط گره‌های دیگر شناسایی می‌شود، خرابی‌های بیزانسی مستلزم هیچ محدودیتی نیست، به این معنی که گره شکست خورده می‌تواند داده‌های دلخواه تولید کند، از جمله داده‌هایی که آن را شبیه به یک عملکرد نشان می‌دهد. گره بنابراین، خرابی‌های بیزانسی می‌توانند سیستم‌های تشخیص شکست را گیج کنند، که تحمل خطا را دشوار می‌کند. علی‌رغم این قیاس، خرابی بیزانس لزوماً یک مشکل امنیتی شامل دخالت خصمانه انسانی نیست: می‌تواند صرفاً از خطاهای الکتریکی یا نرم‌افزاری ناشی شود.

اصطلاحات خطا و شکست در اینجا بر اساس تعاریف استاندارد [6] که در ابتدا توسط کمیته مشترکی در مورد "مفاهیم اساسی و اصطلاحات" ایجاد شده توسط کمیته فنی انجمن کامپیوتری IEEE در مورد محاسبات قابل اعتماد و تحمل خطا و گروه کاری IFIP در 10.4 در مورد استفاده می شود، استفاده می شود. محاسبات قابل اعتماد و تحمل خطا. [7] همچنین به قابلیت اطمینان مراجعه کنید .

هشدار [ ویرایش ]

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

تعریف رسمی [ ویرایش ]

تنظیم: [8] با توجه به سیستمی از n جزء، که t از آنها ناصادق هستند، و با فرض تنها کانال نقطه به نقطه بین همه اجزا.

هر زمان که یک جزء A سعی می کند مقدار x را پخش کند ، سایر مؤلفه ها اجازه دارند با یکدیگر بحث کنند و سازگاری پخش A را تأیید کنند و در نهایت بر روی یک مقدار مشترک y مستقر شوند.

ویژگی: گفته می شود که سیستم در برابر خطاهای بیزانسی مقاومت می کند اگر یک جزء A بتواند مقدار x را پخش کند و سپس:

  1. اگر A صادق باشد، تمام اجزای صادق بر روی مقدار x توافق دارند .
  2. در هر صورت، همه اجزای صادق بر روی یک مقدار y توافق دارند .

انواع: این مشکل در هر دو مورد ارتباطات همزمان و ناهمزمان بررسی شده است.

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

همچنین می‌توان آن را در یک مشکل «واقع‌بینانه‌تر» که در آن اجزای معیوب با هم تبانی نمی‌کنند و سعی می‌کنند دیگران را به خطا بکشانند، کاهش داد. در این تنظیمات است که الگوریتم های عملی ابداع شده است.

تاریخچه [ ویرایش ]

مشکل به دست آوردن اجماع بیزانس توسط رابرت شوستاک تصور و رسمیت یافت که آن را مسئله سازگاری تعاملی نامید . این کار در سال 1978 در چارچوب پروژه SIFT [9] تحت حمایت ناسا در آزمایشگاه علوم کامپیوتر در SRI International انجام شد. SIFT (برای تحمل خطاهای پیاده‌سازی شده نرم‌افزار) فرزند مغز جان ونسلی بود و بر اساس ایده استفاده از رایانه‌های چندمنظوره بود که از طریق پیام‌های زوجی ارتباط برقرار می‌کردند تا به اجماع برسند، حتی اگر برخی از رایانه‌ها معیوب باشند. .

در ابتدای پروژه، مشخص نبود که در مجموع به چند کامپیوتر نیاز بود تا تضمین کند که توطئه n کامپیوتر معیوب نمی تواند تلاش های آنهایی را که به درستی کار می کنند برای رسیدن به اجماع "خنثی کند". شوستاک نشان داد که حداقل 3 n+ 1 مورد نیاز است و یک پروتکل پیام رسانی دو دور 3 n+1 ابداع کرد که برای n =1 کار می کند. همکار او مارشال پیز الگوریتم را برای هر n> 0 تعمیم داد و ثابت کرد که 3 n +1 هم لازم و هم کافی است. این نتایج، همراه با اثبات بعدی توسط لزلی لامپورت مبنی بر کفایت 3 n با استفاده از امضای دیجیتال، در مقاله اولیه منتشر شد.دستیابی به توافق در صورت وجود خطا. [10] نویسندگان جایزه Edsger W. Dijkstra در سال 2005 را برای این مقاله دریافت کردند.

لمپورت برای سهولت درک مسئله سازگاری تعاملی، تمثیلی رنگارنگ ابداع کرد که در آن گروهی از ژنرال های ارتش طرحی را برای حمله به یک شهر تدوین می کنند. در نسخه اصلی خود، داستان ژنرال ها را به عنوان فرماندهان ارتش آلبانی معرفی می کرد. به پیشنهاد جک گلدبرگ برای اثبات هر گونه تخلف احتمالی در آینده، نام تغییر کرد و در نهایت به " بیزانسی " تبدیل شد. [11] این فرمول مسئله، همراه با برخی نتایج اضافی، توسط همان نویسندگان در مقاله 1982 خود، "مشکل ژنرال های بیزانس" ارائه شده است. [3]

مثالها [ ویرایش ]

چندین نمونه از شکست های بیزانسی که رخ داده است در دو مقاله ژورنالی معادل آورده شده است. [4] [5] این و نمونه های دیگر در صفحات وب ناسا DASHlink توضیح داده شده است. [12]

خطاهای بیزانسی به ندرت و در نقاط نامنظم در طول آزمایش استقامت برای زیردریایی های کلاس ویرجینیا که به تازگی ساخته شده اند ، حداقل تا سال 2005 (زمانی که مسائل به طور عمومی گزارش شد) مشاهده شد. [13]

پیاده سازی ها [ ویرایش ]

یک نمونه از BFT در حال استفاده، بیت کوین است ، یک سیستم نقدی دیجیتال همتا به همتا. [14] شبکه بیت کوین به طور موازی برای تولید یک بلاک چین با اثبات کار کار می کند که به سیستم اجازه می دهد بر شکست های بیزانسی غلبه کند و به یک دید جهانی منسجم از وضعیت سیستم برسد.

برخی از سیستم‌های هواپیما، مانند سیستم مدیریت اطلاعات هواپیما بوئینگ 777 (از طریق شبکه ARINC 659 SAFEbus )، سیستم کنترل پرواز بوئینگ 777 و سیستم‌های کنترل پرواز بوئینگ 787 از تحمل خطای بیزانسی استفاده می‌کنند. از آنجایی که اینها سیستم‌های بلادرنگ هستند، راه‌حل‌های تحمل خطای بیزانسی آن‌ها باید تأخیر بسیار کمی داشته باشند. به عنوان مثال، SAFEbus می تواند تحمل خطای بیزانسی را در حدود یک میکروثانیه تأخیر اضافه شده به دست آورد. [15] [16] [17] اژدهای SpaceX تحمل گسل بیزانس را در طراحی خود در نظر می گیرد . [18]

مکانیسم های تحمل خطا بیزانسی از اجزایی استفاده می کند که یک پیام دریافتی (یا فقط امضای آن) را برای سایر گیرندگان آن پیام دریافتی تکرار می کند. همه این مکانیسم ها این فرض را ایجاد می کنند که عمل تکرار یک پیام مانع از انتشار علائم بیزانسی می شود. برای سیستم‌هایی که دارای درجه بالایی از امنیت یا اهمیت حیاتی هستند، این فرضیات باید در سطح قابل قبولی از پوشش خطا صادق باشند . هنگام ارائه اثبات از طریق آزمایش، یک مشکل ایجاد طیف وسیعی از سیگنال‌ها با علائم بیزانسی است. [19] چنین آزمایشی احتمالاً به انژکتورهای خطای تخصصی نیاز دارد. [20] [21]

راه حل ها [ ویرایش ]

چندین راه‌حل اولیه توسط لامپورت، شوستاک و پیز در سال 1982 شرح داده شد . [3] آنها با ذکر این نکته شروع کردند که مشکل ژنرال‌ها را می‌توان به حل یک مشکل «فرمانده و ستوان‌ها» تقلیل داد که در آن ستوان‌های وفادار باید همه به طور هماهنگ عمل کنند و آنها عمل باید مطابق با آنچه فرمانده دستور داده است در مورد وفاداری فرمانده باشد:

  • یک راه‌حل سناریوهایی را در نظر می‌گیرد که در آن پیام‌ها ممکن است جعل شوند، اما تا زمانی که تعداد ژنرال‌های بی‌وفا کمتر از یک سوم ژنرال‌ها باشد ، نسبت به تقصیر بیزانسی قابل تحمل هستند . عدم امکان برخورد با یک سوم یا بیشتر خائنان در نهایت به اثبات این می رسد که اگر فرمانده خائن باشد مشکل یک فرمانده و دو ستوان قابل حل نیست. برای دیدن این موضوع، فرض کنید ما یک فرمانده خائن A و دو ستوان B و C داریم: وقتی A به B می گوید حمله کنید و C عقب نشینی کنید و B و C برای یکدیگر پیام ارسال می کنند و پیام A را ارسال می کنند، نه B و نه C نمی توانند بفهمید که چه کسی خائن است، زیرا لزوماً A نیست - ستوان دیگر می توانست پیام را ظاهراً از A جعل کند. می توان نشان داد که اگر n تعداد ژنرال ها در کل باشد، وt تعداد خائنان در آن n است، سپس تنها زمانی که n > 3 t و ارتباط همزمان باشد (تاخیر محدود) راه حل هایی برای مشکل وجود دارد. [22]
  • راه حل دوم به امضای پیام غیرقابل جعل نیاز دارد. برای سیستم‌های حیاتی امنیتی ، امضای دیجیتال (در سیستم‌های رایانه‌ای مدرن، این ممکن است در عمل با استفاده از رمزنگاری کلید عمومی به دست آید ) می‌تواند تحمل خطای بیزانسی را در حضور تعداد خودسرانه ژنرال‌های خائن فراهم کند. با این حال، برای سیستم‌های حیاتی ایمنی (که در آن «امنیت» به تهدیدات هوشمند می‌پردازد در حالی که «ایمنی» به خطرات ذاتی یک فعالیت یا مأموریت می‌پردازد)، کدهای ساده تشخیص خطا، مانند CRC‌ها .، پوشش ضعیف تر اما اغلب کافی را با هزینه بسیار کمتر ارائه می دهد. این در مورد گسل های بیزانسی و غیر بیزانسی صادق است. علاوه بر این، گاهی اوقات اقدامات امنیتی ایمنی را تضعیف می کند و بالعکس. بنابراین، روش‌های امضای دیجیتال رمزنگاری انتخاب خوبی برای سیستم‌های حیاتی ایمنی نیستند، مگر اینکه تهدید امنیتی خاصی نیز وجود داشته باشد. [23] در حالی که کدهای تشخیص خطا، مانند CRC ها، بهتر از تکنیک های رمزنگاری هستند، هیچ یک پوشش کافی برای الکترونیک فعال در سیستم های حیاتی ایمنی ارائه نمی دهند. این در سناریوی CRC شرودینگر نشان داده شده است که در آن یک پیام محافظت شده با CRC با یک بیت معیوب بیزانسی داده های متفاوتی را به ناظران مختلف ارائه می دهد و هر ناظر یک CRC معتبر می بیند. [4] [5]
  • همچنین تنوعی در دو راه‌حل اول ارائه شده است که در برخی موقعیت‌ها که در آن همه ژنرال‌ها نمی‌توانند مستقیماً با یکدیگر ارتباط برقرار کنند، رفتار متحمل به خطای بیزانس را مجاز می‌کند.

چندین معماری سیستم طراحی شد. 1980 که تحمل گسل بیزانسی را اجرا کرد. اینها عبارتند از: Draper's FTMP، [24] MMFCS Honeywell، [25] و SRI's SIFT. [9]

راه حل های پیشرفته [ ویرایش ]

در سال 1999، میگل کاسترو و باربارا لیسکوف الگوریتم "تحمل خطای عملی بیزانسی" (PBFT) را معرفی کردند، [26] که همانندسازی ماشین حالت بیزانسی با کارایی بالا را فراهم می‌کند و هزاران درخواست در ثانیه را با افزایش تاخیر زیر میلی‌ثانیه‌ای پردازش می‌کند.

پس از PBFT، چندین پروتکل BFT برای بهبود استحکام و عملکرد آن معرفی شد. به عنوان مثال، Q/U، [27] HQ، [28] Zyzzyva، [29] و ABsTRACTs، [30] به مسائل مربوط به عملکرد و هزینه پرداختند. در حالی که پروتکل های دیگر، مانند Aardvark [31] و RBFT، [32] به مسائل استحکام آن پرداختند. علاوه بر این، Adapt [33] سعی کرد از پروتکل های BFT موجود، از طریق سوئیچینگ بین آنها به روشی تطبیقی، برای بهبود استحکام و عملکرد سیستم با تغییر شرایط اساسی استفاده کند. علاوه بر این، پروتکل‌های BFT معرفی شدند که از اجزای قابل اعتماد برای کاهش تعداد کپی‌ها استفاده می‌کنند، مانند A2M-PBFT-EA [34] و MinBFT.[35]

با انگیزه PBFT، Tendermint BFT [36] برای شبکه های ناهمزمان جزئی معرفی شد و عمدتاً برای اثبات سهام بلاک چین استفاده می شود.

در حالی که تحمل گسل های بیزانسی یک ویژگی ایده آل است، حداقل به چهار حوزه اداری مستقل نیاز دارد. برای کاهش محدودیت، Scalar DL برای تحقق الگوریتم "تشخیص عیب بیزانسی عملی" [37] معرفی شد که خطاهای بیزانسی را تنها با دو حوزه اداری در یک سیستم پایگاه داده تراکنشی شناسایی می کند.

همچنین ببینید [ ویرایش ]

منابع [ ویرایش ]

  1. Kirrmann, Hubert (nd). "محاسبات تحمل پذیر خطا در اتوماسیون صنعتی" (PDF) . سوئیس: مرکز تحقیقات ABB. پ. 94. بایگانی شده از نسخه اصلی (PDF) در 2014-03-26 . بازیابی شده در 2015-03-02 .
  2. ^ لامپورت، ال . شوستک، ر. Pease, M. (1982). "مشکل ژنرال های بیزانس" (PDF) . تراکنش های ACM در زبان ها و سیستم های برنامه نویسی . 4 (3): 382-401. CiteSeerX 10.1.1.64.2312 . doi : 10.1145/357172.357176 . بایگانی شده (PDF) از نسخه اصلی در 13 ژوئن 2018.  
  3. ^ a b c Lamport، L. شوستک، ر. Pease, M. (1982). "مشکل ژنرال های بیزانس" (PDF) . تراکنش های ACM در زبان ها و سیستم های برنامه نویسی . 4 (3): 387-389. CiteSeerX 10.1.1.64.2312 . doi : 10.1145/357172.357176 . بایگانی شده از نسخه اصلی (PDF) در 7 فوریه 2017.  
  4. ^ a b c Driscoll، K.; هال، بی. پائولیچ، ام. زومستگ، پی. Sivencrona، H. (2004). "ژنرال های واقعی بیزانس". بیست و سومین کنفرانس سیستم های اویونیک دیجیتال (IEEE Cat. No.04CH37576) . ص 6.D.4–61–11. doi : 10.1109/DASC.2004.1390734 . شابک 978-0-7803-8539-9. S2CID  15549497 .
  5. ^ a b c Driscoll, Kevin; هال، برندان؛ سیونکرونا، هاکان؛ زومستگ، فیل (2003). "تحمل گسل بیزانسی، از نظریه تا واقعیت". ایمنی کامپیوتر، قابلیت اطمینان و امنیت . نکات سخنرانی در علوم کامپیوتر. جلد 2788. صص 235-248. doi : 10.1007/978-3-540-39878-3_19 . شابک 978-3-540-20126-7. ISSN  0302-9743 . S2CID  12690337 .
  6. آویزینیس، ا. لاپری، جی.-سی. راندل، برایان ؛ Landwehr, C. (2004). "مفاهیم اساسی و طبقه بندی محاسبات قابل اعتماد و ایمن". تراکنش های IEEE در محاسبات قابل اعتماد و ایمن . 1 (1): 11-33. doi : 10.1109/TDSC.2004.2 . hdl : 1903/6459 . ISSN 1545-5971 . S2CID 215753451 .  
  7. «محاسبات قابل اعتماد و تحمل خطا» . بایگانی شده از نسخه اصلی در 2015-04-02 . بازیابی شده در 2015-03-02 .
  8. ماتیاس فیتزی (2002). "مدل های ارتباطی و امنیت عمومی در توافقنامه بیزانس" (PDF) . ETH زوریخ .
  9. ^ a b "SIFT: طراحی و تجزیه و تحلیل یک کامپیوتر مقاوم در برابر خطا برای کنترل هواپیما". قابلیت اطمینان میکروالکترونیک 19 (3): 190. 1979. doi : 10.1016/0026-2714(79)90211-7 . ISSN 0026-2714 . 
  10. ^ پیز، مارشال؛ شوستاک، رابرت؛ لمپورت، لزلی (آوریل 1980). «دستیابی به توافق در صورت وجود خطا». مجله انجمن ماشین های محاسباتی . 27 (2): 228-234. CiteSeerX 10.1.1.68.4044 . doi : 10.1145/322186.322188 . S2CID 6429068 .  
  11. لامپورت، لزلی (19-12-2016). "مشکل ژنرال های بیزانسی" . تراکنش های ACM در زبان ها و سیستم های برنامه نویسی . SRI International . بازبینی شده در 18 مارس 2019 .
  12. دریسکول، کوین (11-12-2012). "شکست های واقعی سیستم" . DASHlink _ ناسا . بایگانی شده از نسخه اصلی در 2015-04-02 . بازیابی شده در 2015-03-02 .
  13. ^ والتر، سی. الیس، پی. LaValley، B. (2005). "سرویس پلتفرم قابل اعتماد: معماری سرویس متحمل خطا مبتنی بر مالکیت". نهمین سمپوزیوم بین المللی IEEE در مهندسی سیستم های با اطمینان بالا (HASE'05) . صص 34-43. doi : 10.1109/HASE.2005.23 . شابک 978-0-7695-2377-4. S2CID  21468069 .
  14. «بیت کوین - پول منبع باز P2P» . bitcoin.org _ بازیابی شده 2019-08-18 .
  15. ^ M., Paulitsch; Driscoll, K. (9 ژانویه 2015). "فصل 48: اتوبوس SAFE" . در زوراوسکی، ریچارد (ویرایشگر). کتابچه راهنمای فناوری ارتباطات صنعتی، ویرایش دوم . مطبوعات CRC. صص 48-1-48-26. شابک 978-1-4822-0733-0.
  16. ^ توماس آ. هنزینگر; کریستف ام. کرش (26 سپتامبر 2001). نرم افزار جاسازی شده: اولین کارگاه بین المللی، EMSOFT 2001، شهر تاهو، CA، ایالات متحده آمریکا، 8-10 اکتبر 2001. مجموعه مقالات (PDF) . Springer Science & Business Media. ص 307–. شابک  978-3-540-42673-8. بایگانی شده (PDF) از نسخه اصلی در 2015-09-22 . بازیابی شده در 2015-03-05 .
  17. ^ Yeh, YC (2001). "اویونیک حیاتی ایمنی برای سیستم کنترل پرواز اولیه 777". DASC بیستم بیستمین کنفرانس سیستم های اویونیک دیجیتال (Cat. No.01CH37219) . جلد 1. صفحات 1C2/1–1C2/11. doi : 10.1109/DASC.2001.963311 . شابک 978-0-7803-7034-0. S2CID  61489128 .
  18. «ELC: درس‌های آموخته‌شده SpaceX [LWN.net]» . بایگانی شده از نسخه اصلی در 2016-08-05 . بازیابی شده در 2016-07-21 .
  19. ^ نانیا، تی. گوسن، HA (1989). "مدل گسل سخت افزاری بیزانس". تراکنش های IEEE در طراحی مدارها و سیستم های یکپارچه به کمک کامپیوتر . 8 (11): 1226-1231. doi : 10.1109/43.41508 . ISSN 0278-0070 . 
  20. مارتینز، رولاندو؛ گاندی، راجیف؛ نراسیمهان، پریا; پرتت، سویلا; کاسمیرو، آنتونیو؛ کروتز، دیگو؛ ورسیمو، پائولو (2013). "تجارب با تزریق خطا در یک پروتکل تحمل خطا بیزانس". Middleware 2013 . نکات سخنرانی در علوم کامپیوتر. جلد 8275. صص 41-61. doi : 10.1007/978-3-642-45065-5_3 . شابک 978-3-642-45064-8. ISSN  0302-9743 .
  21. ثبت اختراع ایالات متحده 7475318 ، کوین آر. دریسکول، "روش آزمایش محدوده ورودی حساس فیلترهای بیزانسی"، صادر شده در 06-01-2009، اختصاص یافته به شرکت هانیول اینترنشنال. 
  22. ^ فلدمن، پی. میکالی، س (1997). "یک پروتکل احتمالی بهینه برای توافق بیزانس همزمان" (PDF) . SIAM J. Comput . 26 (4): 873-933. doi : 10.1137/s0097539790187084 . بایگانی شده (PDF) از نسخه اصلی در 2016-03-05 . بازیابی شده در 14-06-2012 .
  23. ^ پاولیچ، م. موریس، جی. هال، بی. دریسکول، ک. لاترونیکو، ای. کوپمن، پی (2005). "پوشش و استفاده از کدهای افزونگی چرخه ای در سیستم های فوق العاده قابل اعتماد". 2005 کنفرانس بین المللی سیستم ها و شبکه های قابل اعتماد (DSN'05) . صص 346-355. doi : 10.1109/DSN.2005.31 . شابک 978-0-7695-2282-1. S2CID  14096385 .
  24. ^ هاپکینز، آلبرت ال. لالا، جینرایان اچ. اسمیت، تی باسیل (1987). "تکامل محاسبات تحمل پذیر خطا در آزمایشگاه چارلز استارک دریپر، 1955-1985". تکامل محاسبات تحمل‌پذیر خطا . محاسبات قابل اعتماد و سیستم های مقاوم در برابر خطا. جلد 1. صص 121-140. doi : 10.1007/978-3-7091-8871-2_6 . شابک 978-3-7091-8873-6. ISSN  0932-5581 .
  25. ^ دریسکول، کوین؛ پاپادوپولوس، گرگوری؛ نلسون، اسکات؛ هارتمن، گری؛ Ramohalli، Gautham (1984)، سیستم کنترل پرواز چند ریزپردازنده (گزارش فنی)، پایگاه نیروی هوایی رایت-پترسون، OH: AFWAL/FIGL فرماندهی سیستم های نیروی هوایی ایالات متحده، AFWAL-TR-84-3076
  26. ^ کاسترو، م. لیسکوف، بی (2002). "تحمل عملی خطای بیزانس و بازیابی فعال". معاملات ACM در سیستم های کامپیوتری . انجمن ماشین های محاسباتی . 20 (4): 398-461. CiteSeerX 10.1.1.127.6130 . doi : 10.1145/571637.571640 . S2CID 18793794 .  
  27. عبدالملک، م. گانگر، جی. آهنگ خوب.؛ رایتر، ام. ویلی، جی (2005). "خدمات تحمل پذیر خطای بیزانس با مقیاس پذیری خطا". بررسی سیستم عامل ACM SIGOPS . انجمن ماشین های محاسباتی . 39 (5): 59. doi : 10.1145/1095809.1095817 .
  28. ^ کاولینگ، جیمز؛ مایرز، دانیل؛ لیسکوف، باربارا ؛ رودریگز، رودریگو؛ شریرا، لیوبا (2006). تکرار HQ: یک پروتکل حد نصاب ترکیبی برای تحمل خطای بیزانس . مجموعه مقالات هفتمین سمپوزیوم USENIX در زمینه طراحی و پیاده سازی سیستم های عامل. صص 177-190. شابک 1-931971-47-1.
  29. کوتلا، راماکریشنا؛ آلویسی، لورنزو؛ داهلین، مایک؛ کلمنت، آلن؛ وانگ، ادموند (دسامبر 2009). "Zyzzyva: حدس و گمان تحمل گسل بیزانس". معاملات ACM در سیستم های کامپیوتری . انجمن ماشین های محاسباتی . 27 (4): 1-39. doi : 10.1145/1658357.1658358 .
  30. گرراوی، راشید؛ کنژویچ، نیکولا؛ ووکولیچ، مارکو؛ کوما، ویوین (2010). پروتکل های بعدی 700 BFT . مجموعه مقالات پنجمین کنفرانس اروپایی سیستم های کامپیوتری. EuroSys. بایگانی شده از نسخه اصلی در 2011-10-02 . بازیابی شده در 2011-10-04 .
  31. ^ کلمنت، ا. وونگ، ای. الویسی، ل. داهلین، م. Marchetti، M. (22-24 آوریل، 2009). ساختن سیستم های متحمل گسل بیزانسی با گسل های بیزانسی (PDF) . سمپوزیوم طراحی و پیاده سازی سیستم های شبکه ای. USENIX . بایگانی شده (PDF) از نسخه اصلی در 2010-12-25 . بازیابی شده در 2010-02-17 .
  32. ^ Aublin, P.-L.; بن مختار، س. Quéma, V. (8–11 ژوئیه 2013). RBFT: تحمل گسل بیزانسی اضافی . سی و سومین کنفرانس بین المللی IEEE در مورد سیستم های محاسباتی توزیع شده. کنفرانس بین المللی سیستم های محاسباتی توزیع شده . بایگانی شده از نسخه اصلی در 5 آگوست 2013.
  33. ^ بهسون، ج. گررویی، آر. Shoker, A. (2015-05-01). "ساخت پروتکل های BFT واقعا تطبیقی" . سمپوزیوم پردازش موازی و توزیع شده (IPDPS)، 2015 بین المللی IEEE : 904-913. doi : 10.1109/IPDPS.2015.21 . شابک 978-1-4799-8649-1. S2CID  16310807 .
  34. ^ چون، بیونگ-گون؛ مانیاتیس، پتروس؛ شنکر، اسکات؛ کوبیاتوویچ، جان (2007-01-01). "حافظه فقط ضمیمه تایید شده: چسبیدن دشمنان به حرف خود". مجموعه مقالات بیست و یکمین سمپوزیوم ACM SIGOPS در مورد اصول سیستم عامل . SOSP '07. نیویورک، نیویورک، ایالات متحده آمریکا: ACM: 189–204. doi : 10.1145/1294261.1294280 . شابک 9781595935915. S2CID  6685352 .
  35. ^ ورونز، جی اس. کوریا، ام. بسانی، ع. ریه، LC; Verissimo، P. (2013-01-01). "تحمل گسل بیزانسی کارآمد". معاملات IEEE در رایانه ها 62 (1): 16-30. CiteSeerX 10.1.1.408.9972 . doi : 10.1109/TC.2011.221 . ISSN 0018-9340 . S2CID 8157723 .   
  36. ^ بوچمن، ای. کوون، جی. میلوسویچ، ز. (2018). "آخرین شایعات در مورد اجماع BFT". arXiv : 1807.04938 [ cs.DC ].
  37. ^ یامادا، هیرویوکی؛ Nemoto، ژوئن (2022-03-01). "Scalar DL: تشخیص خطای بیزانسی مقیاس پذیر و عملی برای سیستم های پایگاه داده تراکنش" . مجموعه مقالات VLDB Endowment . 15 (7): 1324–1336. doi : 10.14778/3523210.3523212 . ISSN 2150-8097 . 

پیوندهای خارجی [ ویرایش ]