O que acontece com um pagamento Rayls se os validadores travarem durante a transferência?
Criei o Axyl, o cliente de consenso do Rayls, a partir do código-fonte, executei 4 validadores no meu laptop e os derrubei durante pagamentos em andamento.
Um validador fora do ar: 240 de 240 pagamentos foram liquidados. A pausa mais longa foi de 2,58 s.
Dois validadores fora do ar: a cadeia parou até eles voltarem. Um nó ainda aceitou meu pagamento em 15 ms, sem nenhum erro, e ele foi liquidado 41 s depois. Todos os 45 pagamentos enviados durante essas interrupções foram liquidados, entre 8 e 69 s após o envio.
O mesmo nonce enviado a dois validadores, 24 vezes: ambos retornaram um hash, mas só um pagamento foi liquidado. Sem gasto duplo.
Então, nessa configuração, o sistema trava, mas não cria uma bifurcação. A lição para os aplicativos: receber um hash não significa que o pagamento foi efetuado.
Na testnet pública, 150 pagamentos tiveram uma mediana de 2,44 s entre o envio e o recebimento da confirmação, conforme observado por um único cliente. Isso inclui cerca de 0,4 s de ida e volta pela rede.
Limitações: um laptop, apenas falhas por travamento, amostras pequenas, nenhum pagamento na mainnet. Um validador reiniciado divergiu em um teste inicial e confuso. Não consegui reproduzir o problema e o relatei em particular à Rayls.
Dados e código: https://github.com/anshxft/rayls-axyl-failure-tests
Isto não é aconselhamento financeiro.+
Criei o Axyl, o cliente de consenso do Rayls, a partir do código-fonte, executei 4 validadores no meu laptop e os derrubei durante pagamentos em andamento.
Um validador fora do ar: 240 de 240 pagamentos foram liquidados. A pausa mais longa foi de 2,58 s.
Dois validadores fora do ar: a cadeia parou até eles voltarem. Um nó ainda aceitou meu pagamento em 15 ms, sem nenhum erro, e ele foi liquidado 41 s depois. Todos os 45 pagamentos enviados durante essas interrupções foram liquidados, entre 8 e 69 s após o envio.
O mesmo nonce enviado a dois validadores, 24 vezes: ambos retornaram um hash, mas só um pagamento foi liquidado. Sem gasto duplo.
Então, nessa configuração, o sistema trava, mas não cria uma bifurcação. A lição para os aplicativos: receber um hash não significa que o pagamento foi efetuado.
Na testnet pública, 150 pagamentos tiveram uma mediana de 2,44 s entre o envio e o recebimento da confirmação, conforme observado por um único cliente. Isso inclui cerca de 0,4 s de ida e volta pela rede.
Limitações: um laptop, apenas falhas por travamento, amostras pequenas, nenhum pagamento na mainnet. Um validador reiniciado divergiu em um teste inicial e confuso. Não consegui reproduzir o problema e o relatei em particular à Rayls.
Dados e código: https://github.com/anshxft/rayls-axyl-failure-tests
Isto não é aconselhamento financeiro.+