Certa vez adicionei todo mundo a um grupo de conversa antes de verificar quem ainda estaria disponível quando o trabalho de fato começasse.
Esse pequeno erro mudou a forma como eu interpretei o design do challenger da @BabylonLabs_io.
Um Trustless Bitcoin Vault não espera até que surja uma disputa para decidir quem pode participar. Os claimers e challengers são definidos quando o cofre é criado, porque o processo de disputa por circuito embaralhado funciona entre partes predeterminadas.
Isso torna o grafo de transações previsível.
Mas também transforma a segurança em uma lista de participantes escolhida antes que condições futuras sejam conhecidas.
O risco oculto não é se a BABY tem challengers.
É se os challengers corretos ainda estão ativos quando finalmente forem necessários.
Um conjunto de Universal Challengers estático e versionado pode reduzir a incerteza e impedir que atores aleatórios entrem em caminhos críticos. Mas se a associação não for permissionless, com que rapidez a BABY pode substituir um operador que fique lento, subfinanciado ou indisponível? E o que acontece com cofres mais antigos quando uma infraestrutura de monitoramento mais forte avança para uma versão mais nova do registro?
Alguma associação fixa é razoável. Participação totalmente aberta pode gerar spam, responsabilidade pouco clara e falhas de coordenação.
Ainda assim, selecionar previamente os defensores desloca parte da segurança da Babylon da criptografia para a disponibilidade de longo prazo. O sistema de provas pode continuar correto enquanto os participantes esperados para ativá-lo lentamente forem desaparecendo.
Eu não acho que isso quebre a BABY.
Estou observando se a Babylon consegue manter uma estrutura fixa de disputa sem permitir que a lista de participantes de ontem se torne um gargalo de disponibilidade de amanhã.
@BabylonLabs_io $BABY #baby
Esse pequeno erro mudou a forma como eu interpretei o design do challenger da @BabylonLabs_io.
Um Trustless Bitcoin Vault não espera até que surja uma disputa para decidir quem pode participar. Os claimers e challengers são definidos quando o cofre é criado, porque o processo de disputa por circuito embaralhado funciona entre partes predeterminadas.
Isso torna o grafo de transações previsível.
Mas também transforma a segurança em uma lista de participantes escolhida antes que condições futuras sejam conhecidas.
O risco oculto não é se a BABY tem challengers.
É se os challengers corretos ainda estão ativos quando finalmente forem necessários.
Um conjunto de Universal Challengers estático e versionado pode reduzir a incerteza e impedir que atores aleatórios entrem em caminhos críticos. Mas se a associação não for permissionless, com que rapidez a BABY pode substituir um operador que fique lento, subfinanciado ou indisponível? E o que acontece com cofres mais antigos quando uma infraestrutura de monitoramento mais forte avança para uma versão mais nova do registro?
Alguma associação fixa é razoável. Participação totalmente aberta pode gerar spam, responsabilidade pouco clara e falhas de coordenação.
Ainda assim, selecionar previamente os defensores desloca parte da segurança da Babylon da criptografia para a disponibilidade de longo prazo. O sistema de provas pode continuar correto enquanto os participantes esperados para ativá-lo lentamente forem desaparecendo.
Eu não acho que isso quebre a BABY.
Estou observando se a Babylon consegue manter uma estrutura fixa de disputa sem permitir que a lista de participantes de ontem se torne um gargalo de disponibilidade de amanhã.
@BabylonLabs_io $BABY #baby