Comparando mecanismos de consenso: qual é o certo para o seu blockchain?

Como um desenvolvedor experiente com anos de experiência, considero este guia um excelente recurso para compreender vários mecanismos de consenso que podem impactar significativamente o desempenho, a segurança e a confiabilidade das redes blockchain.

A tecnologia Blockchain cresceu e ampliou significativamente suas aplicações, tornando a escolha de um algoritmo de consenso adequado uma das principais decisões. Os algoritmos de consenso servem como a espinha dorsal dos sistemas blockchain, uma vez que não apenas influenciam a segurança, mas também impactam fatores como escalabilidade, velocidade de transação, uso de energia e confiança do usuário.

Por que inovar além do PoW e do PoS?

Diferente dos mecanismos de consenso convencionais, como Prova de Trabalho (PoW) e Prova de Participação (PoS), ambos apresentam certas desvantagens: o PoW é notório por sua natureza de uso intensivo de energia, enquanto o PoS pode inadvertidamente levar à centralização, permitindo uma seleção poucas partes interessadas influentes para dominar a rede. Como resultado, estão a surgir modelos de consenso inovadores que fornecem soluções mais personalizadas, adaptadas a requisitos específicos, como aumentar a velocidade em redes privadas, lidar com grandes volumes de transações ou garantir uma operação perfeita através da confiança em validadores confiáveis.

Prova de autoridade

Em termos mais simples, a Prova de Autoridade é um método baseado em confiança para confirmar transações onde a validade dos blocos é verificada por verificadores designados (ou contas aprovadas).

Mas o que torna um validador confiável e como ele mantém a rede segura?

Os validadores dependem de software para agrupar transações em blocos, reduzindo a necessidade de monitoramento contínuo de tela. No entanto, manter a segurança e a proteção dos seus computadores, muitas vezes referidos como “nós de autoridade”, é vital para manter a integridade da rede.

De forma transparente, os validadores devem divulgar as suas identidades à comunidade. Esta abertura promove a responsabilização e a confiança entre os participantes da rede. Essa transparência se alinha bem com os sistemas blockchain autorizados, onde os validadores normalmente confiam em sua reputação de credibilidade.

Como analista, eu descreveria a Prova de Autoridade como a delegação da tarefa de validação de transações a um grupo de indivíduos confiáveis, nos quais se confia sua boa reputação. Ao contrário dos métodos tradicionais que se baseiam em enigmas que consomem energia, estas autoridades são escolhidas pela sua reputação, tornando mais fácil para outros confiarem nelas. Esta abordagem acelera e optimiza o processo, mas é fundamental lembrar que a sua eficiência depende da confiança depositada nestas autoridades.

Aqui está um exemplo básico do mecanismo de consenso do PoA:

importar hashlib tempo de importação validador de classe: def __init__( self, nome, chave_privada): self.name = nome self.private_key = chave_privada  def sign_block(self, dados): return hashlib.sha256((self.private_key + data).encode). hexdigest class PoABlockchain: def __init__(self, validadores): self .chain = [] self.validators = validadores def add_block(self, dados, validador): se validador em self.validators: signed_block = { ‘dados’: dados,< br/>‘validador’: validator.name, ‘assinatura’: validator.sign_block(data), ‘timestamp’ : time.time     }  self. chain.append(signed_block)  print(f”Bloco assinado por {validator.name}: {signed_block}”)         else: print(“Validador não autorizado!”) # Inicializar validadores validator1 = Validador (“Validador1”, “chave1”) validador2 = Validador(“Validador2”, “chave2”) validadores = [validador1, validador2] # Adicionar blocos poa_chain = PoABlockchain(validadores) poa_chain.add_block( “Dados de transação 1”, validador1) poa_chain.add_block(“Dados de transação 2”, validador2)

Prova de História

Prova de História (PoH) é um mecanismo de consenso desenvolvido por Solana com o objetivo de aumentar a escalabilidade e a velocidade dos blockchains. Ao contrário dos métodos tradicionais que exigem acordo frequente entre os nós para cada transação, o PoH introduz um “calendário” verificável de eventos com hash, agindo como um relógio digital onde cada tick significa a posição de um evento em sequência. Isso torna mais simples para qualquer pessoa acompanhar e verificar a cronologia. Ao evitar check-ins constantes entre nós, este método acelera a velocidade das transações e melhora a eficiência geral e a velocidade do blockchain.

Verificar o histórico envolve essencialmente estabelecer uma sequência ordenada de eventos que serve como evidência de quando ocorrências específicas ocorreram. Ao contrário da resolução de quebra-cabeças complexos, ele simplesmente garante que cada transação possa ser verificada com um registro para confirmar seu cronograma. Este método agiliza o sistema, eliminando a necessidade de verificação e reverificação constantes.

importar hashlib tempo de importação class ProofOfHistory: def __init__( self, inicial_seed=”initial”): self.seed = inicial_seed self.history = [] class ProofOfHistory: def __init__(self, inicial_seed=”initial”): self.seed = inicial_seed self.history = [] def generate_proof(self): prova = hashlib.sha256(self.seed.encode).hexdigest self.history.append(proof) # Atualize a semente para a próxima prova self.seed = prova retornar prova # Simular sequência PoH poh = ProofOfHistory para i no intervalo(5): proof = poh.generate_proof print(f”PoH Hash {i + 1}: {proof}”) time.sleep(1)  # Simulando o tempo de passagem entre as provas

Prova de Participação Delegada

Em um sistema de Prova de Participação Delegada (DPoS), uma forma de Prova de Participação é empregada, mas em vez de validadores individuais, há um sistema semelhante à democracia representativa, onde os representantes são escolhidos para apostar e verificar os tokens e transações em em nome dos seus constituintes.

Em uma configuração de Prova de Participação Delegada (DPoS), os proprietários de tokens não verificam pessoalmente as transações. Em vez disso, votaram para eleger um número limitado de indivíduos conhecidos como “representantes” ou “delegados”. Esses representantes eleitos assumem a tarefa de criar novos blocos e validar as transações dentro do sistema. Os delegados com mais votos são escolhidos para serem produtores de blocos.

Nos sistemas DPoS (Delegated Proof of Stake), os usuários têm a oportunidade de votação contínua, o que significa que podem votar frequentemente ou trocar os representantes selecionados (delegados), dependendo do seu desempenho.

A Prova de Participação Delegada funciona de forma semelhante à eleição de um grupo para gerenciar a tarefa de verificação da transação. Você possui certos tokens, que lhe permitem votar em representantes confiáveis ​​que serão responsáveis ​​pela validação das transações. Este método acelera o sistema, pois apenas algumas pessoas de confiança realizam o trabalho.

Aqui, os indivíduos que possuem tokens (como Alice, Bob e Carol) votam nos delegados, sendo a seleção influenciada pelas respectivas participações. Os dois delegados mais votados adquirem então autoridade para gerar novos blocos.

de coleções importam defaultdict # Classe de exemplo para um sistema blockchain DPoS classe DPoSBlockchain: def __init__(self):self.token_holders = defaultdict(int)  # Armazena detentores de tokens e suas participações  self.delegates = {}  # Lojas eleitas delegados self.votes = defaultdict(int)  # Armazena votos para delegados  def add_token_holder(self, titular, participação): “””Adicione um detentor de token e sua participação.””” self.token_holders[holder] = participação  def vote_for_delegate(self, titular, delegado): “””Os detentores de token votam no delegado escolhido.””” se o titular não for ele mesmo .token_holders: raise ValueError(“Titular do token não registrado.”) self.votes[delegate] += self.token_holders[holder] # Poder de voto baseado em stake def elect_delegates(self, num_delegates): “””Eleja os principais delegados com base nos votos.””” sorted_delegates = sorted(self.votes.items, key=lambda x: x[1], reverse=True) self.delegates = { delegado: votos para delegado, votos em sorted_delegates[:num_delegates]} print(f”Delegados eleitos: {self.delegates}”) def produz_block( self): “””Simular a produção de blocos por delegados eleitos.””” para delegado em self.delegates:< br/>print(f”Bloco produzido por {delegate} com {self.delegates[delegate]} votos”) # Exemplo de uso blockchain = DPoSBlockchain blockchain.add_token_holder(“Alice”, 100) blockchain.add_token_holder(“Bob”, 150) blockchain.add_token_holder(“Carol”, 200) blockchain.vote_for_delegate(“Alice”, “Delegate1”) blockchain.vote_for_delegate(“Bob”, “Delegate2”) blockchain.vote_for_delegate(“Carol”, “Delegate1”) # Eleger os 2 primeiros delegados blockchain.elect_delegates(2) blockchain.produce_block

Tolerância prática a falhas bizantinas

Em termos mais simples, a Tolerância Prática a Falhas Bizantinas (PBFT) é um método usado para chegar a um acordo entre os nós de uma rede, mesmo quando alguns desses nós podem falhar ou agir desonestamente. Isso o torna robusto contra vários tipos de problemas.

Em um sistema distribuído, os componentes podem causar confusão ou conflito intencionalmente, disseminando dados contraditórios devido a falhas ou erros de programação, e isso é conhecido como tolerância a falhas bizantinas.

Em essência, a tolerância a falhas bizantinas (BFT) desempenha um papel crucial tanto em blockchains quanto em sistemas distribuídos, pois oferece uma estrutura para garantir a confiabilidade do sistema, mesmo quando alguns participantes podem ser não confiáveis ​​ou maliciosos.

Tolerância a falhas bizantinas (BFT) significa essencialmente que o sistema pode continuar operando sem problemas mesmo quando alguns participantes o interrompem intencionalmente ou agem desonestamente, ou quando algumas peças funcionam mal. É semelhante a um grupo de pessoas tentando tomar uma decisão. Mesmo que alguns indivíduos mintam ou se recusem a participar, desde que a maioria concorde, a decisão é considerada confiável.

Mecanismo:

Inicialmente, na Tolerância Probabilística a Falhas Bizantinas (PBFT), presume-se que do número total de nós, aproximadamente um terço mais um nó poderia potencialmente agir de forma maliciosa. Isto implica que se houver ‘n’ nós, em torno de ‘f’ nós serão considerados possivelmente maliciosos, com ‘f’ sendo menor que n/3 + 1.

O PBFT alcança consenso por meio de um processo de comunicação de três fases entre os nós: Processo de pré-preparação → Fase de preparação → Fase de confirmação.

class PBFTNode: def __init__(self, nome): self.name = nome self.messages = [] def send_message(self, message, nodes): para nó em nós: se node.name != self.name: node.receive_message(message, self.name) def recebe_message(self, message, sender): self.messages.append((sender, message)) print(f”{self.name} recebeu mensagem de {sender}: {message}”) # Inicializar nós node_A = PBFTNode(“Node_A”) node_B = PBFTNode(“Node_B”) node_C = PBFTNode(“Node_C”) # Simular mensagem passando nós = [node_A, node_B, node_C] node_A.send_message(“Proposta de bloqueio”, nós) node_B.send_message(“Proposta de bloqueio”, nós) node_C.send_message(“Proposta de bloqueio”, nós)

Modelos de consenso híbridos

Combinando elementos de vários métodos de consenso, como Prova de Trabalho (PoW) e Prova de Participação (PoS), ou Prova de Autoridade (PoA) e Prova de Participação, os modelos de consenso híbridos funcionam para alcançar um equilíbrio de segurança, velocidade e descentralização.

Em essência, os modelos de consenso híbrido combinam os aspectos mais fortes de vários sistemas, aumentando a segurança, a velocidade e a adaptabilidade. Para ilustrar, vamos considerar um cenário de blockchain onde um método é empregado para verificação de transações enquanto outro garante segurança. Essa abordagem combinada permite que o sistema processe mais transações com eficiência e dificulta a penetração de ameaças potenciais.

Existem muitas combinações possíveis de consenso híbrido e aqui estão algumas das principais:

• Prova de Trabalho + Prova de Participação (PoW + PoS): Frequentemente usado para proteger a camada base com PoW enquanto usa PoS para validar transações, como em Decred e Kadena. Esta configuração fornece a segurança do PoW e a eficiência do PoS.
• Prova de aposta + tolerância a falhas bizantinas (PoS + BFT): Os validadores de PoS cuidam da aposta, enquanto o BFT garante a finalidade da transação. Cosmos e Algorand usam variações desta abordagem para garantir consenso mesmo com nós não confiáveis ​​ou maliciosos.
• Prova de autoridade + tolerância prática a falhas bizantinas (PoA + PBFT): Este modelo combina o consenso baseado em validador do PoA com a tolerância do PBFT a falhas e ataques. Hyperledger Fabric e VeChain utilizam este modelo, permitindo uma configuração de blockchain permitida e de alta velocidade.

importar hashlib importar aleatoriamente classe HybridBlockchain: def __init__( self, validadores): self.chain = [] self.validators = validadores def prova_de_trabalho(self, dados, dificuldade=”000″): nonce = 0 enquanto Verdadeiro: hash_result = hashlib.sha256((dados + str(nonce)).encode).hexdigest se hash_result.startswith(dificuldade): retornar nonce, hash_result nonce += 1 def add_block(self, dados): nonce, hash_result = self.proof_of_work(data) validator = random.choice(self.validators) block = { ‘dados’: dados, ‘nonce’: nonce, ‘hash’: hash_result, ‘validator’: validador, ‘status’: ‘Aprovado’ se validador em self.validators else ‘ Rejeitado’         } self.chain.append(block)< br/>print(f”Bloco adicionado pelo validador {validador}: {block}”) # Inicializar validadores validadores = [“Validador1”, “Validador2”, “Validator3”] # Adicionar blocos com PoW + PoS híbrido hybrid_chain = HybridBlockchain(validators) hybrid_chain.add_block(“Dados de transação 1”) hybrid_chain.add_block(“Dados de transação 2”)

Escolha o mecanismo de consenso mais adequado para sua aplicação:

Mecanismo de consenso	Recurso principal	Caso de uso	Escalabilidade e segurança
Prova de Autoridade (PoA)	Validadores confiáveis ​​com identidades predefinidas.	Redes de consórcios privados/blockchain.	Alto e alto
Prova de História (PoH)	Carimbo de tempo para comprovar a ordem dos eventos.	Alto rendimento, por exemplo, blockchain Solana.	Muito alto e médio
Prova de Participação Delegada (DPoS)	Votação em delegados confiáveis ​​para validar blocos.	Blockchain público com necessidades de escalabilidade.	Alto e Médio
Tolerância prática a falhas bizantinas (PBFT)	Resiliência contra nós defeituosos usando quorum.	Blockchains permitidos com confiabilidade.	Médio e muito alto
Modelos de consenso híbridos	Combina recursos de vários tipos de consenso.	Vários, dependendo das necessidades específicas.	Muito alto e alto

Conclusão

Ao compreender essas estratégias de consenso inovadoras, os desenvolvedores podem elevar a funcionalidade, a segurança e a credibilidade de seus projetos. Ao fornecer demonstrações concretas de codificação, este manual permite que você teste PoA, PoH, DPoS, PBFT e modelos mistos para descobrir uma correspondência adequada para seu sistema blockchain. Para expandir ainda mais seus conhecimentos, mergulhe em materiais de aprendizagem avançados, como Cosmos SDK, Tendermint e Hyperledger Fabric.

Boa codificação e continue aprendendo!!

• ADA PREVISÃO. ADA criptomoeda

• BLUR PREVISÃO. BLUR criptomoeda

• Polícia usa canhões de água contra manifestantes pró-UE na Geórgia (VÍDEOS)

• Putin avalia a parceria com a China nos assuntos mundiais

• MNT PREVISÃO. MNT criptomoeda

• Rússia testa míssil ultrassecreto com capacidade nuclear (VÍDEO)

• A chave da paz de hoje é escondida nesta cúpula de 80 anos?

• Otan não faz parte das negociações de paz na Ucrânia – Secretário -Geral

• USD VES PREVISÃO

• RON PREVISÃO. RON criptomoeda

2024-11-16 09:09