Нещодавно я досліджував архітектурний дизайн протоколу Walrus і виявив дуже важливу проблему — як система витримує при масштабних збої вузлів або розділення мережі?



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

Два ключові показники для оцінки стійкості системи — цільовий час відновлення(RTO) та цільовий час відновлення даних(RPO). Ці показники мають бути чітко спроектовані, а результати тестів — відкритими та прозорими. Тільки так можна справді перевірити, чи протокол здатен витримати випробування.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 10
  • Репост
  • Поділіться
Прокоментувати
0/400
HashBanditvip
· 5год тому
Метрики ngl rto/rpo звучать добре на папері, але ще в мої дні майнінгу ми навчилися на власному досвіді, що теоретична стійкість і реальний хаос у мережі — це два дуже різні поняття... Ведмідь краще мати перевірену у бою стратегію відновлення, чесно.
Переглянути оригіналвідповісти на0
MetaEggplantvip
· 14год тому
По суті, це питання в тому, чи зможе ви витримати різкий обвал, і RTO та RPO — це дві важливі речі, які мають бути прозорими.
Переглянути оригіналвідповісти на0
GasFeeVictimvip
· 01-13 10:22
Дійсно, чи витримає Walrus цей удар, просто хвалитися без діла, потрібно дивитися на дані RTO і RPO, інакше все це — порожні слова.
Переглянути оригіналвідповісти на0
AirdropAnxietyvip
· 01-12 10:38
Чесно кажучи, більшість проектів навряд чи наважаться публічно тестувати показники RTO та RPO.
Переглянути оригіналвідповісти на0
WagmiOrRektvip
· 01-11 16:54
Чесно кажучи, показники RTO і RPO більшість проєктних команд уникають чітких відповідей, і справжніх, хто наважується публічно тестувати результати, небагато.
Переглянути оригіналвідповісти на0
ruggedSoBadLMAOvip
· 01-11 16:53
Цей хлопець справді наважується запитати, чи система виживе, якщо вузол зламається? Здається, Walrus доведеться міцно захищати свою найціннішу частину
Переглянути оригіналвідповісти на0
LiquidityHuntervip
· 01-11 16:53
Чи оприлюднені ці два показники RTO та RPO? Якщо немає даних, то це марна справа, зараз багато протоколів хваляться своєю стійкістю, але справжніх, хто насправді готовий це перевірити, небагато.
Переглянути оригіналвідповісти на0
SoliditySurvivorvip
· 01-11 16:41
Чорт, показники RTO і RPO дійсно ігноруються занадто багато, більшість проектів навіть не наважуються публічно тестувати результати...
Переглянути оригіналвідповісти на0
StableNomadvip
· 01-11 16:37
Насправді... метрики RTO/RPO — це просто театралізація безпеки, якщо їх ніхто не тестує на стрес регулярно. Це нагадує мені UST у травні — всі *заявляли*, що механізм був бездоганним, поки не сталося непередбачуване. Ведмідь краще мати історії з війни, щоб це підтвердити, а не просто теоретичні заяви про стабільність
Переглянути оригіналвідповісти на0
Liquidated_Larryvip
· 01-11 16:28
Чесно кажучи, показники RTO та RPO у більшості проектів — це лише паперові цифри, справжнього досвіду проходження екстремальних тестів навантаження дуже мало.
Переглянути оригіналвідповісти на0
Дізнатися більше
  • Закріпити