Обґрунтування дизайну Елронда

Примітка. У цій статті пропонований член посилається на вузол / об'єкт у мережі, який відповідає за певний час пропозиції нового блоку, тоді як валідатори будуть визначати вузли / сутності, відповідальні за перевірку блок, висунутий заявником, таким чином ефективно «поручаючи» пропозицію.

Дві проблеми, які Елронд намагається вирішити в процесі роботи, - це збільшення пропускної здатності - досяжна за рахунок скорочення та зменшення енерговитрат - досяжна шляхом переходу від консенсусу, що ґрунтується на підтвердженні роботи, до консенсусу щодо підтвердження участі. Кожне з цих двох зубців вимагає врахування різних аспектів при проектуванні архітектури та компонентів навколо неї.

Аспект PoS потребує вирішення всіх (більшості?) Поширених проблем у системах PoS - таким чином стимулюючи раціональну поведінку. Аспект загострення потребує механізмів для досягнення угод у кожній меншій частині мережі (осколка), а також домовленості між учасниками транзакції, яка охоплює більше осколків. І все це потрібно також враховувати потенційну візантійську (змагальну) поведінку.

Перш ніж що-небудь, деталізуємо загальний підхід, коли ми говоримо про блокчейни, що базуються на доказі: усі мають тенденцію вимірювати час двома одиницями; очевидний, який називається блоковим часом (інтервал між двома послідовними блоками), але також вищий порядок, який називається епохою або епохою. З цієї точки зору інтервал, необхідний для генерації певного числа (X) блоків, є епохою (при цьому завжди ера = X * час блоку).

Знай свого ворога…

Всі блок-ланцюги PoS, що існують сьогодні або просто теоретизуються, використовують крипто-економічні стимули для того, щоб поведінка людей (як їх мережеві персони, представлені вузлами) відповідала очікуваній схемі - вузли отримують винагороду за те, що вони роблять добрі справи (для мережі), і вони отримують покарання за те, що робили погані справи. Хоча в деяких випадках цей підхід з морквою та палицею надмірно підкреслює одну сторону рівняння (тобто є випадки, коли покарання за змагальну поведінку не передбачено), більшість випадків ці дві сторони врівноважуються. Варто також зазначити, що покарання значною мірою пов'язані з часткою, яку кожен вузол блокує за попередньо визначений період (як правило, декілька епох). Протиборча поведінка за відсутності цієї заблокованої ставки, яку вузол може втратити (частково або повністю), називається «атака нічого не загрожує».

Інший тип змагальної поведінки, пов'язаний із заблокованими колами, передбачає, що вузол є частиною процесу «прийняття рішення», а потім відходить від цього процесу та отримує свою частку. Через деякий час після цих подій, використовуючи облікові дані, пов’язані з колом (тобто ключі), вузол / сутність може спробувати "підробити" іншу історію (або себе, або надавши ці дані зловмисній стороні); таким чином перетворюючи атаку в запізніле нічого, що називається нападом, як правило, його називають дальнім нападом. З цієї точки зору, посилаючись на умови, викладені в попередній статті, важливо, щоб розблокування ставок відбулося лише після завершення блоків, запропонованих або затверджених вузлом, що обговорюється.

У деяких типах дальньої атаки, що виконуються в блокчейнах, що реалізують штрафні санкції (в основному, ті, хто має цілі активності), що публікують цю альтернативну історію, може скластися враження, що деякі з вузлів не виконують своїх обов'язків і, таким чином, (несправедливо) караються. Цей тип змагальної поведінки називається атакою колючого кровотечі [SB].

Нарешті, але, безумовно, не в останню чергу, ми можемо мати ситуації, коли вузли супротивники ізолюються від мережі, які "подають" їх спотворене уявлення про реальність (наприклад, лише ретрансляції транзакцій від законних транзакцій "друзів" та цензора). Ці типи атак називаються атаками затемнення.

… Але також знайте свої слабкі сторони для протидії

Як було зазначено раніше, системи PoS повинні охоплювати кілька слабких моментів при роботі з супротивниками, дві з найважливіших:

  • Зовнішнє: DoS-ing (або іншим чином погіршує) поточного валідатора (ів) або поточного пропозиції, щоб вони не змогли спілкуватися з іншими вузлами та не могли приймати рішення. Це, очевидно, впливає на можливості життєдіяльності блокчейна, але також може вплинути на безпеку (тим самим призводить до непередбачуваних результатів).
  • Внутрішнє: Вузли (особи або особи), які вибрані на певному етапі, щоб взяти на себе одну з "офіційних" ролей для наступного кроку, можуть вести себе змагально (наприклад, пропонувати недійсні блоки, відмовитись від участі в колективному підписанні процедури тощо).

Якщо ви пам’ятаєте з попередньої статті, було описано три типи шардингів - мережа, транзакція та стан. Ми вирішили зробити загострення штатів, і, як відповідь на ці дві окреслені проблеми, ми створили два поняття, які ми назвали Безпечним доказом ставки та Адаптивним Шардінгом.

Новий підхід до змагальної поведінки завдяки надійній адаптивності

Інтуїція кожного говорить про те, що чим довше заздалегідь противник знає про вузол-пропонувач та / або вузли валідатора - починаючи від ідентичності вузла, але, можливо, також і їх "мережевих координат" - тим більше шкоди цьому противнику може завдати вузол (і, за рахунок розширення , до мережі). Ще гірший сценарій - якщо, заздалегідь дізнавшись, хто буде відповідати за певну пропозицію блоку, супротивник може домовитись із зазначеним пропонувальником (або валідатором), щоб вони запропонували (або затвердили) недійсні блоки (наприклад, дозволяючи подвійний витрачати або карбувати монети з повітря - не на відміну від того, що сьогодні роблять центральні банки :-D). Як результат, бажано дізнатися роль вузла для конкретного кроку (блоку) якомога менше заздалегідь.

Щоб вирішити цю головоломку, ми застосували такий підхід: ми використовуємо поточний підпис блоку як джерело випадковості і, виходячи з цього, вибираємо / поточний пропонувач і b / поточний набір валідатора. Один із способів цього досягти - це те, що кожен, хто має право, виконує перевірену випадкову функцію (VRF) на поточному хеші блоку і придумує випадкове число (і доказ того, що випадкове число було правильно сформовано вибраним VRF).

Упорядковані випадкові числа (скажімо, низькі до високих), а перший (виробник найменшого числа) є пропонувачем, наступний N - валідаторами. Таким чином, хоча заявник може вибрати певний блок, він не зможе сказати, хто з інших учасників консенсусу отримає, можливо, менший випадковий номер на наступному кроці.

Щоб зробити завдання ще більш складним для візантійських вузлів, ми також розробили процес, коли час від часу (скажімо, кожна епоха) частина вузлів осколка перерозподіляється на різні осколки, без того, щоб хтось із мережі мав змогу заздалегідь сказати, що вузол буде перепризначений і, крім того, до якого фрагменту він буде переміщений. Процес перепризначення може знову бути результатом запуску VRF.

Особливість, яку ми використовували при розробці механізмів морквяної палички, полягає в тому, що окрім винагороди та нарізки кожного вузла буде рейтинг, який відображає вигляд мережі на поведінку зазначеного вузла. Гра за правилами збільшить (до обмеження) рейтинг вузла, а змагальна поведінка знизить його.

Цей рейтинг буде поєднуватися зі ставкою вузла при обчисленні ймовірностей, пов’язаних зі ставками, тобто, врешті-решт, вага на ставку користувача. Позитивні рейтинги будуть діяти так, ніби доля вузла більша від фактичної ставки, тоді як негативні оцінки матимуть такий же ефект, як і зниження ставки вузла. На реальну винагороду та покарання також може вплинути цей рейтинг (таким чином, позитивна поведінка виграє б вузолю більше, в перспективі, ніж негативному, якщо припустити, що з цього ж колу слід починати)

Винос

На закінчення - ми вирішили побудувати цю нову блокчейн-архітектуру шляхом пошуку оптимальних (на нашу думку) механізмів, за допомогою яких ми:

  • Інтенсифікуйте гарну поведінку - попросивши суб’єктів, які хочуть «грати», «покласти свої гроші туди, де є рот», при цьому приносячи винагороду за участь у механізмі консенсусу
  • Звести до мінімуму можливість упередженості певних рішень та впливу учасників нападів шляхом прийняття деяких рішень (призначення шара, групових виборів та виборів лідерів) на основі джерела випадковості (підписи блоків та вузлів).
  • Усуньте (або принаймні різко зменшіть ймовірність) змови шляхом переміщення вузлів в осколках час від часу, а також змінивши ролі всередині осколка

Список літератури

[SB] https://eprint.iacr.org/2018/248.pdf, "Напади на кровотечу"
на блокчейн з підтвердженням участі »
[LRA] https://blog.cosmos.network/consensus-compare-casper-vs-tendermint-6df154ad56ae "Порівнювання консенсусу: Casper vs. Tendermint"

Для отримання додаткової інформації відвідайте нас:

  • Офіційний веб-сайт: www.elrond.com
  • Елронд Гітхуб: https://github.com/ElrondNetwork
  • Біла книга: https://elrond.com/files/Elrond_Whitepaper_EN.pdf
  • Twitter: https://twitter.com/elrondnetwork