Nesses últimos dias, tenho conversado novamente sobre “em quem confiar realmente na interoperabilidade”, e fiz uma revisão: uma transferência entre blockchains/mensagem, na essência, você não confia apenas na interface da 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 sua mensagem), na cadeia intermediária de relay/validadores/multisig (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 é colocar “como provar o que aconteceu na cadeia oposta” nas regras do cliente leve, mas ainda assim você está confiando na concordância das duas cadeias + que o cliente não tenha erro, além de o relayer ser apenas um carregador de mensagens, sem fazer mal ou atrasar. Recentemente, antes e depois de uma atualização/hard fork na cadeia principal, as pessoas especulam se os projetos vão migrar ou não, mas eu estou mais preocupado com: se a janela de atualização faz com que as mensagens entre blockchains fiquem presas, atrasadas ou possam ser reexecutadas, esses problemas podem se amplificar. Ficar de olho nesses documentos por muito tempo cansa os olhos, de qualquer forma, atualmente prefiro fazer menos transferências entre blockchains, do que arriscar confiar demais e acabar pagando duas vezes na taxa para economizar passos.

Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
  • Recompensa
  • Comentário
  • Repostar
  • Compartilhar
Comentário
Adicionar um comentário
Adicionar um comentário
Sem comentários
  • Marcar