Сравнение механизмов консенсуса: какой из них подходит для вашего блокчейна?

Как опытный разработчик с многолетним опытом за плечами, я считаю это руководство отличным ресурсом для понимания различных механизмов консенсуса, которые могут существенно повлиять на производительность, безопасность и надежность сетей блокчейнов.

Технология блокчейн значительно выросла и расширила сферу своего применения, что делает выбор подходящего алгоритма консенсуса одним из ключевых решений. Алгоритмы консенсуса служат основой систем блокчейна, поскольку они не только влияют на безопасность, но и влияют на такие факторы, как масштабируемость, скорость транзакций, потребление энергии и доверие пользователей.

Зачем внедрять инновации помимо PoW и PoS?

В отличие от традиционных механизмов консенсуса, таких как Proof of Work (PoW) и Proof of Stake (PoS), оба из которых имеют определенные недостатки: PoW известен своей энергоемкой природой, в то время как PoS может непреднамеренно привести к централизации, позволяя выбирать мало влиятельных заинтересованных сторон, способных доминировать в сети. В результате возникают инновационные модели консенсуса, которые предоставляют более индивидуальные решения, адаптированные к конкретным требованиям, таким как повышение скорости в частных сетях, обработка больших объемов транзакций или обеспечение бесперебойной работы за счет использования надежных валидаторов.

Подтверждение полномочий

Проще говоря, Proof-of-Authority — это основанный на доверии метод подтверждения транзакций, при котором достоверность блоков проверяется назначенными верификаторами (или утвержденными учетными записями).

Но что делает валидаторов надежными и как они обеспечивают безопасность сети?

Валидаторы полагаются на программное обеспечение для объединения транзакций в блоки, что снижает необходимость постоянного мониторинга экрана. Тем не менее, поддержание безопасности и защиты их компьютеров, часто называемых «авторитетными узлами», жизненно важно для поддержания целостности сети.

Валидаторы должны прозрачно раскрывать свою личность сообществу. Такая открытость способствует подотчетности и доверию между участниками сети. Такая прозрачность хорошо сочетается с разрешенными системами блокчейна, где валидаторы обычно полагаются на свою репутацию в плане надежности.

Как аналитик, я бы описал Proof of Authority как делегирование задачи проверки транзакций группе надежных людей, которым доверяют за их хорошую репутацию. В отличие от традиционных методов, основанных на энергозатратных загадках, эти авторитеты выбираются за их репутацию, что позволяет другим доверять им. Такой подход ускоряет и оптимизирует процесс, но важно помнить, что его эффективность зависит от доверия к этим органам власти.

Вот базовый пример механизма консенсуса PoA:

импортировать хэш-библиотеку время импорта Валидатор класса: def __init__( self, name, Private_key): self.name = name self.private_key = Private_key  def Sign_block(self, data): return hashlib.sha256((self.private_key + data).encode).hexdigest класс PoABlockchain: def __init__(self, валидаторы): self.chain = [] self.validators = валидаторы def add_block(self, data, validator): if валидатор в self.validators: signed_block = { ‘data’: данные, ‘validator’: validator.name, ‘подпись’: validator.sign_block(data), ‘timestamp’: time.time  self. Chain.append(signed_block)  print(f”Блок, подписанный {validator.name}: {signed_block}”)         else: print(“Валидатор не авторизован!”) # Инициализировать валидаторы validator1 = Валидатор(«Валидатор1», «ключ1») валидатор2 = Валидатор(«Валидатор2», «ключ2») валидаторы = [валидатор1, валидатор2 ] # Добавить блоки poa_chain = PoABlockchain(валидаторы) poa_chain.add_block(“Данные транзакции 1”, валидатор1) poa_chain.add_block(“Данные транзакции 2”, валидатор2)

Доказательство истории

Доказательство истории (PoH) — это механизм консенсуса, разработанный Соланой с целью повышения масштабируемости и скорости блокчейнов. В отличие от традиционных методов, которые требуют частого согласования между узлами для каждой транзакции, PoH вводит проверяемый «календарь» хешированных событий, действующий как цифровые часы, где каждый такт обозначает последовательность событий. Это позволяет каждому легко отслеживать и проверять хронологию. Избегая постоянных проверок между узлами, этот метод ускоряет скорость транзакций и повышает общую эффективность и скорость блокчейна.

Проверка истории по существу предполагает установление упорядоченной последовательности событий, которая служит доказательством того, когда произошли определенные события. В отличие от решения сложных головоломок, он просто гарантирует, что каждую транзакцию можно будет сверить с журналом, чтобы подтвердить ее временную шкалу. Этот метод оптимизирует систему, устраняя необходимость постоянной проверки и повторной проверки.

импортировать хеш-библиотеку время импорта класс ProofOfHistory: def __init__( self, Initial_seed=»initial»): self.seed = Initial_seed self.history = [] класс ProofOfHistory: def __init__(self, Initial_seed=»initial»): self.seed = Initial_seed self.history = [] defgenerate_proof(self): proof = hashlib.sha256(self.seed.encode).hexdigest self.history.append(proof) # Обновите начальное число для следующего доказательства self.seed =proof returnproof # Имитировать последовательность PoH тьфу = ProofOfHistory для i в диапазоне (5): proof = poh.generate_proof print(f”PoH Hash {i + 1}: {proof}”) time.sleep(1)  # Имитация прохождения времени между доказательствами

Делегированное подтверждение доли

В системе делегированного доказательства доли (DPoS) используется форма доказательства доли, но вместо отдельных валидаторов существует система, похожая на представительную демократию, где представители выбираются для ставок и проверки токенов и транзакций на от имени своих избирателей.

В настройке делегированного доказательства доли (DPoS) владельцы токенов не проверяют транзакции лично. Вместо этого они отдали свои голоса за избрание ограниченного числа лиц, известных как «представители» или «делегаты». Эти избранные представители берут на себя задачу создания новых блоков и проверки транзакций внутри системы. Делегаты, набравшие наибольшее количество голосов, выбираются в качестве производителей блоков.

В системах DPoS (Delegated Proof of Stake) пользователи имеют возможность непрерывного голосования, что означает, что они могут часто голосовать или менять выбранных представителей (делегатов) в зависимости от их результатов.

Делегированное подтверждение доли действует аналогично выбору группы для управления задачей проверки транзакций. У вас есть определенные токены, которые позволяют вам отдать свой голос за надежных представителей, которые будут отвечать за проверку транзакций. Этот метод ускоряет работу системы, поскольку работу выполняют лишь несколько доверенных лиц.

Здесь люди, владеющие токенами (например, Алиса, Боб и Кэрол), отдают свои голоса за делегатов, причем на выбор влияют их соответствующие ставки. Затем два делегата, набравшие наибольшее количество голосов, получают право генерировать новые блоки.

из коллекций import defaultdict # Пример класса для системы блокчейна DPoS class DPoSBlockchain: def __init__(self):self.token_holders = defaultdict(int)  # Сохраняет держателей токенов и их доли  self.delegates = {}  # Избранные магазины делегаты self.votes = defaultdict(int)  # Сохраняет голоса делегатов  def add_token_holder(self, Holder, Stake): «»»Добавьте держателя токена и его долю.»» self.token_holders[holder] = ставка  def voice_for_delegate(self, Holder, Delegate): «»»Владельцы токенов голосуют за выбранного делегата.»»» если держатель не сам .token_holders: raise ValueError(«Владелец токена не зарегистрирован.») self.votes[delegate] += self.token_holders[держатель] # Число голосов, основанное на ставка def elect_delegates(self, num_delegates): “””Выберите лучших делегатов на основе голосов.””” sorted_delegates = sorted(self.votes.items, key=lambda x: x[1],verse=True) self.delegates = { делегат: голосует за делегат, голоса в sorted_delegates[:num_delegates] print(f”Избранные делегаты: {self.delegates}”) def Produce_block(self): “””Имитировать создание блоков избранными делегатами.””” для делегата в self.delegates: print(f»Блок создан пользователем {delegate} с голосами {self.delegates[delegate]}») # Пример использования blockchain = DPoSBlockchain blockchain.add_token_holder(“Алиса”, 100) blockchain.add_token_holder(«Боб», 150) blockchain.add_token_holder(«Кэрол», 200) blockchain.vote_for_delegate(“Алиса”, «Делегат1») blockchain.vote_for_delegate(«Боб», «Делегат2») blockchain.vote_for_delegate(«Кэрол», «Делегат1») # Выбрать 2 лучших делегаты blockchain.elect_delegates(2) blockchain.produce_block

Практическая византийская отказоустойчивость

Проще говоря, Практическая византийская отказоустойчивость (PBFT) — это метод, используемый для достижения согласия между узлами в сети, даже когда некоторые из этих узлов могут выйти из строя или действовать нечестно. Это делает его устойчивым к различным типам проблем.

В распределенной системе компоненты могут намеренно вызывать путаницу или конфликты, распространяя противоречивые данные из-за недостатков или ошибок программирования, и это известно как византийская отказоустойчивость.

По сути, византийская отказоустойчивость (BFT) играет решающую роль как в блокчейнах, так и в распределенных системах, поскольку она предлагает структуру, обеспечивающую надежность системы, даже если некоторые участники могут быть ненадежными или злонамеренными.

Византийская отказоустойчивость (BFT) по сути означает, что система может продолжать бесперебойно работать, даже если некоторые участники намеренно нарушают ее работу или действуют нечестно, или когда некоторые части выходят из строя. Это похоже на группу людей, пытающихся принять решение. Даже если несколько человек лгут или отказываются участвовать, при условии согласия большинства решение считается надежным.

Механизм:

Изначально в Probabilistic Byzantine Fault Tolerance (PBFT) делается предположение, что из общего числа узлов примерно одна треть плюс один узел потенциально могут действовать злонамеренно. Это означает, что если есть узлы «n», узлы вокруг «f» будут считаться потенциально вредоносными, при этом «f» будет меньше n/3 + 1.

PBFT достигает консенсуса посредством трехэтапного процесса связи между узлами: процесс предварительной подготовки → этап подготовки → этап фиксации.

класс PBFTNode: def __init__(self, name): self.name = name self.messages = [] def send_message(self, message, nodes): для узла в узлах: if node.name != self.name: node.receive_message(message, self.name) def take_message(self, message, отправитель): self.messages.append((sender, message)) print(f»{self.name} получил сообщение от {sender}: {message}”) # Инициализировать узлы node_A = PBFTNode(“Node_A”) node_B = PBFTNode(«Node_B») node_C = PBFTNode(«Node_C») # Имитировать сообщение передача nodes = [node_A, node_B, node_C] node_A.send_message(“Блокировать предложение”, узлы) node_B.send_message(«Блокировать предложение», узлы) node_C.send_message(«Блокировать предложение», узлы)

Гибридные консенсусные модели

Сочетая элементы различных методов консенсуса, таких как Proof-of-Work (PoW) и Proof-of-Stake (PoS) или Proof-of-Authority (PoA) и Proof-of-Stake, гибридные модели консенсуса работают для достижения баланса безопасность, скорость и децентрализация.

По сути, модели гибридного консенсуса сочетают в себе самые сильные стороны различных систем, повышая безопасность, скорость и адаптивность. Для иллюстрации давайте рассмотрим сценарий блокчейна, где один метод используется для проверки транзакции, а другой обеспечивает безопасность. Такой смешанный подход позволяет системе эффективно обрабатывать больше транзакций и затрудняет проникновение потенциальных угроз.

Существует множество возможных комбинаций гибридного консенсуса, и вот некоторые из них:

• Доказательство работы + Доказательство доли (PoW + PoS): Часто используется для защиты базового уровня с помощью PoW при использовании PoS для проверки транзакций, как в Decred и Kadena. Эта настройка обеспечивает как безопасность PoW, так и эффективность PoS.
• Доказательство доли + византийская отказоустойчивость (PoS + BFT): Валидаторы PoS обрабатывают ставки, а BFT гарантирует завершенность транзакции. Cosmos и Algorand используют варианты этого подхода, чтобы обеспечить консенсус даже с ненадежными или вредоносными узлами.
• Доказательство полномочий + практическая византийская отказоустойчивость (PoA + PBFT): Эта модель сочетает в себе консенсус PoA на основе валидатора с устойчивостью PBFT к ошибкам и атакам. Hyperledger Fabric и VeChain используют эту модель, обеспечивая высокоскоростную и разрешенную настройку блокчейна.

импортировать хеш-библиотеку импортировать случайный класс HybridBlockchain: def __init__( self, валидаторы): self.chain = [] self.validators = валидаторы defproof_of_work(self, data, трудности=”000″): nonce = 0 в то время как True:< br/> hash_result = hashlib.sha256((data + str(nonce)).encode).hexdigest if hash_result.startswith(сложность): вернуть nonce, hash_result nonce += 1 def add_block(self, data): nonce, hash_result = self.proof_of_work(data) validator = random.choice( self.validators) block = { ‘data’: данные, ‘nonce’: nonce, ‘hash’: hash_result, ‘валидатор’: валидатор, ‘статус’: ‘Одобрено’, если валидатор в self.validators, иначе ‘ Отклонено’ self.chain.append(block) print(f «Блок добавлен валидатором {validator}: {block}») # Инициализировать валидаторы validators = [“Validator1”, “Validator2”, “Validator3”] # Добавить блоки с гибридным PoW + PoS hybrid_chain = HybridBlockchain(валидаторы) hybrid_chain.add_block(“Данные транзакции 1”) hybrid_chain.add_block(“Данные транзакции 2”)

Выберите механизм консенсуса, наиболее подходящий для вашего приложения:

Механизм консенсуса	Ключевая особенность	Сценарий использования	Масштабируемость и безопасность
Подтверждение полномочий (PoA)	Доверенные валидаторы с заранее определенными идентификаторами.	Частные/блокчейн-консорциумные сети.	Высокий и высокий
Доказательство истории (PoH)	Временные метки, подтверждающие порядок событий.	Высокая пропускная способность, например, блокчейн Solana.	Очень высокий и средний
Делегированное доказательство доли (DPoS)	Голосование за доверенных делегатов для проверки блоков.	Публичный блокчейн с потребностями в масштабируемости.	Высокий и средний
Практическая византийская отказоустойчивость (PBFT)	Устойчивость к неисправным узлам с использованием кворума.	Разрешенные и надежные блокчейны.	Средний и очень высокий
Гибридные консенсусные модели	Сочетает в себе функции нескольких типов консенсуса.	Разные, в зависимости от конкретных потребностей.	Очень высокий и высокий

Заключение

Используя эти новаторские стратегии консенсуса, разработчики могут повысить функциональность, безопасность и надежность своего проекта. Предоставляя конкретные демонстрации кодирования, это руководство дает вам возможность протестировать PoA, PoH, DPoS, PBFT и смешанные модели, чтобы найти подходящее соответствие для вашей системы блокчейна. Чтобы еще больше расширить свои знания, изучите расширенные учебные материалы, такие как Cosmos SDK, Tendermint и Hyperledger Fabric.

Приятного кодирования и продолжайте учиться!!

Смотрите также

• Прогноз цен на Hamster Kombat на 2024–2030 годы: достигнет ли HMSTR 10 долларов к 2030 году?
• Перспективы рынка криптовалюты HIVE: прогнозы цены Hive
• Прогноз цены XRP на 15 января 2025 года
• 10 лучших альткойнов стоимостью менее 1 доллара, в которые можно инвестировать в 2025 году
• Перспективы рынка криптовалюты BTC: прогнозы цены биткоина
• Dogecoin (DOGE) удерживает решающий уровень и ожидает ралли на 25%
• Встряска Трампа в Комиссии по ценным бумагам и биржам: криптореволюция на горизонте?
• 10 лучших альткоинов с низкой капитализацией, в которые стоит инвестировать в 2025 году
• Перспективы рынка криптовалюты MINA: прогнозы цены Mina Protocol
• Прогноз рынка криптовалют: почему 2025 год может начаться хорошо, но закончиться проблемами

2024-11-16 09:09