Nesses últimos dias tenho conversado novamente sobre “em quem confiar realmente na interoperabilidade”, e fiz uma revisão: uma transferência entre blockchains / transmissão de mensagens, na verdade, você não confia apenas na interface dessa ponte. Você precisa confiar na finalidade da cadeia de origem (não fazer rollback), na lógica de validação da cadeia de destino (como ela reconhece essa mensagem), no conjunto intermediário de relay / validadores / multi-assinaturas (quem tem permissão para liberar), além da implementação do contrato em si (se há permissões de atualização estranhas). O ponto mais confortável do IBC é que coloca a “prova do que aconteceu na cadeia oposta” nas regras do cliente leve, mas você ainda está confiando na concordância das duas cadeias + o cliente não estar errado, além de o relayer ser apenas um transportador que não deve agir maliciosamente ou atrasar. Recentemente, antes e depois de uma atualização / hard fork na cadeia principal, todos especulam se o projeto vai migrar ou não, mas eu estou mais interessado em: se na janela de atualização, as mensagens entre blockchains ficarem presas, atrasarem ou serem reexecutadas, esses problemas podem se amplificar. Ficar atento a esses documentos por muito tempo cansa os olhos, de qualquer forma, agora prefiro fazer menos transferências entre blockchains, do que economizar duas taxas e acabar expondo demais a confiança.

Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
  • Recompensa
  • Comentar
  • Republicar
  • Partilhar
Comentar
Adicionar um comentário
Adicionar um comentário
Nenhum comentário
  • Fixar