#bedrock $BR Recentemente, passei por uma situação bem constrangedora. Um protocolo DeFi anunciou que ia fazer uma atualização de contrato e exigiu que os usuários migrassem manualmente a liquidez. Segui o tutorial, mas na parte de autorização deu ruim, e após queimar uma taxa de gas, a migração falhou. Tentei de novo e falhei novamente. No final, perguntei na comunidade e descobri que não era um caso isolado, era um problema de compatibilidade da atualização do contrato. Depois de mais de meia hora de tentativas, consegui resolver, e desde então, fiquei mais cauteloso com a expressão "atualização de protocolo".$ETH
Depois, olhei a documentação de @Bedrock e fui checar o mecanismo de atualização do contrato.
Na arquitetura do Bedrock 2.0, a lógica de emissão dos contratos principais, como uniBTC e brBTC, não pode ser trocada a torto e a direito. Os direitos de atualização estão nas mãos de um multi-sig e, além disso, o multi-sig não é só da Bedrock. Cada atualização precisa da assinatura de várias partes independentes para ser executada. Embora esse mecanismo não elimine completamente o risco de "mau comportamento da equipe do projeto", pelo menos ele eleva a barreira. Uma pessoa não decide sozinha; precisa do consenso de um grupo.
O que me chamou ainda mais a atenção é que, no Bedrock, em vez de tornar muitos parâmetros substituíveis, eles são configuráveis. O que isso significa? Alguns protocolos precisam trocar todo o contrato só para alterar um parâmetro de rendimento, o que é arriscado e complexo. Desde o início, o Bedrock projetou parâmetros comuns, como taxas, distribuição de incentivos, pesos de pools, como itens configuráveis, que podem ser ajustados através de votação de governança, sem precisar mexer no contrato principal. Isso garante flexibilidade e reduz a exposição ao risco de uma atualização.
Fiz uma olhada nos relatórios de auditoria históricos. Os contratos principais do Bedrock passaram por auditorias cruzadas de várias empresas, incluindo SlowMist e CertiK. Auditoria não garante que não haja vulnerabilidades, mas várias rodadas de auditoria pelo menos mostram que a equipe não está sendo negligente com a segurança.$BTC
Outro detalhe é o tempo de bloqueio para atualizações do contrato do Bedrock. Qualquer atualização não urgente, uma vez acionada, terá um atraso antes de entrar em vigor. Essa janela dá tempo para a comunidade reagir. Se uma proposta de atualização gerar controvérsia, a comunidade pode identificar problemas e levantar objeções nesse período. Esse tipo de design não é raro no espaço DeFi, mas na verdade, poucos projetos o implementam rigorosamente.
Depois, olhei a documentação de @Bedrock e fui checar o mecanismo de atualização do contrato.
Na arquitetura do Bedrock 2.0, a lógica de emissão dos contratos principais, como uniBTC e brBTC, não pode ser trocada a torto e a direito. Os direitos de atualização estão nas mãos de um multi-sig e, além disso, o multi-sig não é só da Bedrock. Cada atualização precisa da assinatura de várias partes independentes para ser executada. Embora esse mecanismo não elimine completamente o risco de "mau comportamento da equipe do projeto", pelo menos ele eleva a barreira. Uma pessoa não decide sozinha; precisa do consenso de um grupo.
O que me chamou ainda mais a atenção é que, no Bedrock, em vez de tornar muitos parâmetros substituíveis, eles são configuráveis. O que isso significa? Alguns protocolos precisam trocar todo o contrato só para alterar um parâmetro de rendimento, o que é arriscado e complexo. Desde o início, o Bedrock projetou parâmetros comuns, como taxas, distribuição de incentivos, pesos de pools, como itens configuráveis, que podem ser ajustados através de votação de governança, sem precisar mexer no contrato principal. Isso garante flexibilidade e reduz a exposição ao risco de uma atualização.
Fiz uma olhada nos relatórios de auditoria históricos. Os contratos principais do Bedrock passaram por auditorias cruzadas de várias empresas, incluindo SlowMist e CertiK. Auditoria não garante que não haja vulnerabilidades, mas várias rodadas de auditoria pelo menos mostram que a equipe não está sendo negligente com a segurança.$BTC
Outro detalhe é o tempo de bloqueio para atualizações do contrato do Bedrock. Qualquer atualização não urgente, uma vez acionada, terá um atraso antes de entrar em vigor. Essa janela dá tempo para a comunidade reagir. Se uma proposta de atualização gerar controvérsia, a comunidade pode identificar problemas e levantar objeções nesse período. Esse tipo de design não é raro no espaço DeFi, mas na verdade, poucos projetos o implementam rigorosamente.