Чи можливо зробити лідера анонімним?
Кожен мембер ради валідаторів хай вважає себе повноцінним лідером. Приймати рішення буде смарт-контракт, на основі рейтингу лідерів (не відомого нікому з валідаторів).
If the leader (primary) is compromised in PBFT, the protocol includes a mechanism called View Change to replace the faulty leader and maintain the integrity of the system. Here’s how it works:
⸻
🔴 Detecting a Compromised Leader
A leader is considered compromised if it:
• Proposes conflicting blocks to different nodes (double signing).
• Sends invalid or manipulated transactions.
• Fails to propose blocks or is unresponsive (causing delays in consensus).
• Colludes with malicious nodes to disrupt consensus.
Nodes detect a compromised leader when:
• They receive inconsistent messages (e.g., different blocks for the same sequence number).
• The leader fails to propose a block within a reasonable time (timeout mechanism).
• The leader consistently disagrees with the majority without a valid reason.
⸻
🔄 View Change Process (Leader Replacement)
When a supermajority (at least ⌊(n-1)/3⌋ + 1 nodes) agree that the leader is faulty, they initiate a View Change:
1. Request View Change
• Honest nodes send a View Change message to indicate that the leader is faulty.
• This message includes the latest valid state of the blockchain to ensure continuity.
2. Electing a New Leader
• A new leader is selected deterministically using a round-robin method or a predefined ordering.
• The new leader collects View Change messages and prepares a new state.
3. New View Announcement
• The new leader broadcasts a New View message, proving it has received sufficient View Change requests.
• Nodes verify that the new leader is acting correctly before accepting it.
4. Resuming Consensus
• The protocol resumes normal operation with the new leader.
• The old, compromised leader is ignored unless it recovers and re-establishes trust.
⸻
🔐 Mitigation Strategies Against Leader Compromise
1. Randomized Leader Election
• Instead of round-robin selection, some PBFT variations use randomization (e.g., VRF-based selection) to prevent predictable leader targeting.
2. Threshold Cryptography
• Ensures that a leader cannot act maliciously without majority approval.
3. Slashing & Reputation Mechanisms
• Malicious leaders may be penalized (slashed) in economic-based PBFT variants.
4. Backup Leaders
• Predefined backup leaders can step in immediately to prevent long delays.
⸻
✅ Final Takeaway
If the leader is compromised, PBFT’s View Change mechanism ensures that a new leader is elected, preventing system failure. This process is designed to tolerate up to (n-1)/3 Byzantine nodes while maintaining correctness and safety.
Можна відкрити картку, зка буде пов’язана з USDC рахунком:
* Best exchange rate for USDT/UAH
*
* registration for individuals aged 21 and up
* integration with Huobi, WhiteBit, or Weld Wallet
* limit of 100,000 UAH/month
https://weld.money/r.weld/d3fdafe6fa
а шо, ні цікаво що там та як воно пеацює?
вибачаюсь, не так зрозумів
Іноді здається, що тебе використовують. Назаповняв там їм купу формочек з приватними даними. Зарееструвався. А потім зрозумілось що потрібної мені функції в інтерфейсі немає. Чи зарегівся — а там лише одна кнопка [To be continued...]
Знайшов на інший сервіс.
Якщо дивитись з крапки зору кінцевого користувача інтерфейсу:
— Да що ви мене постійно оце все питаєте? Самі щось придумайте... параметри якись я повинен вигадувати... Розбиратися в вашій версії таксономії класів та категорій. Мені лише треба одну-дві функції викликати. Добре якщо є якись тести з мокапами... А якщо ні? То треба буде роздуплятись в якомусь лісі дерев классів до параметрів потрібної функції.
А був там якийсь тип Required? Тобто, всі параметри за замовчуванням, але ліш деякі Required. Якщо дивитись з крапки зору кінцевого користувача інтерфейсу:
— Да що ви мене постійно оце все питаєте? Самі щось придумайте... параметри якись я повинен вигадувати... Розбиратися в вашій версії таксономії класів та категорій. Мені лише треба одну-дві функції викликати. Добре якщо є якись тести з мокапами... А якщо ні? То треба буде роздуплятись в якомусь лісі дерев классів до параметрів потрібної функції.
А я вважаю, що й до особистого кабінету можна пускати гостя в ридонлі моде. Але не завжди. Залежить від конкретного сервісу.
так, краще зробити константою:
retries = OPTIMAL_RETRIES_COUNT
Чи застосовували інструменти для аналізу коду в цьому проєкті? Він ще живий?
Оце так знахідка! Чи можна дізнатись подробиці? Стек, об’єм codebase?
I noticed you seem to be a duck-typing hater. If that’s the case, I’d love to hear how you manage to avoid it in your very big projects? 😊 (It’s a built-in feature of TS, duck-typing cannot be just turned off with some flag or directive)
надуманная проблема
Помилки з undefined та null — одні з найчастіших. Чи не є практика завжди додавати дефолтні значення змінним рішенням цих проблем? Може така практика привести до виникнення помилок іншого роду?
Your comments feel a bit off to me, and I’d prefer not to continue the conversation this way. It might be worth exploring ways to refine your communication skills in the future.
ні «нужную», а нову версію. В новому коді неможна використовувати deprecated функціонал. Від цього старого коду девелопери будудь збавлятись поступово, тільки тоді, коли протестовані усі зміни функціоналу, на який може вплинути зміна коду.
I find your conversation style a bit unsuitable, and I’d prefer not to continue the discussion with you. I’d appreciate it if we could stop here. Perhaps focusing on refining your communication approach could help in the future. Thank you for understanding!
во всех тех же местах что и ранее буде викликатись deprecated функція. А новий функціонал буде викликати нову функцію.
Дякую за ґрунтовний коментар! Ви підняли важливі аспекти, особливо щодо ReturnType + typeof, складних структур даних та динамічних змін об’єктів.
Щодо простих прикладів (add, age)
Вони наведені саме для ілюстрації базових принципів type inference. Очевидно, що в реальних проєктах ситуація складніша, і там іноді доводиться експортувати типи явно, особливо при роботі з глибоко вкладеними структурами. Але суть статті в тому, щоб не дублювати зайві декларації, коли TypeScript уже справляється сам.
Щодо складних об’єктів
Ви абсолютно праві: у випадку вкладених структур, особливо коли вони змінюються, корисно явно визначати типи. Я згоден, що в масштабних проєктах без цього може бути важко.
Щодо тестів
Так, у тестах і підготовчих блоках (наприклад, beforeEach) явне визначення типів може бути необхідним, особливо якщо працюєте з об’єктами, що змінюються під час тестування. Це хороший кейс.