$SUI O TPS de pico explica quantas operações o sistema consegue processar, mas há outra questão que preocupa mais os usuários: como recuperar os BTC depositados? No artigo anterior, falei sobre a finalidade do financiamento da Hashi e os compromissos de capital. Desta vez, consultei os documentos de design para analisar o processo de retirada. Depois de ler, não vou interpretar «os BTC continuam na rede Bitcoin» como «o usuário pode transferi-los sozinho a qualquer momento».
A distinção fundamental é que a rede em que o ativo está e quem pode autorizar o seu gasto são questões diferentes. De acordo com os User Flows da Hashi, o usuário deposita BTC num endereço Bitcoin exclusivo e, após a confirmação, recebe hBTC na Sui. Os gastos normais usam uma estrutura 2-de-2: uma parte é o comitê MPC da Hashi e a outra é o Guardian. O MPC realiza a assinatura através da colaboração de várias partes, enquanto o Guardian oferece uma segunda camada de verificação. O fato de o usuário solicitar uma retirada não significa que tenha uma chave que lhe permita transferir BTC diretamente, contornando o protocolo.
O objetivo dessa verificação é restringir a liberação dos ativos em situações anormais, como vulnerabilidades ou atividades maliciosas. Mas as medidas de segurança também podem afetar a rapidez das retiradas. A documentação do Limiter especifica que as retiradas estão sujeitas a uma capacidade máxima e a um limite que é reabastecido continuamente; se a capacidade for insuficiente, é necessário esperar. Uma solicitação individual que ultrapasse a capacidade máxima será ignorada até que o limite aumente, e o usuário também pode cancelar a solicitação de acordo com as regras. Em geral, as solicitações são processadas por ordem de chegada, mas isso não é uma garantia estrita. Portanto, se uma retirada demorar muito, a espera na fila, por si só, não prova que os fundos foram roubados; da mesma forma, a existência de proteções não garante que os fundos chegarão imediatamente. É preciso considerar em conjunto a configuração dos limites, a fila e a execução efetiva.
Há também uma via de recuperação que merece uma explicação à parte. A documentação do Address Scheme especifica que, além dos gastos normais, o script permite que o comitê MPC gaste os fundos separadamente após um bloqueio temporal relativo de 60 dias, contado a partir da confirmação da UTXO. Uma UTXO pode ser entendida como uma saída na blockchain que ainda não foi gasta. Esse mecanismo oferece uma via alternativa de recuperação em situações como a perda da chave do Guardian. A contagem começa quando essa saída é confirmada, não quando o usuário envia o pedido de retirada. Isso também não transfere o direito de recuperação para cada usuário, nem constitui uma promessa de serviço de que «todas as retiradas demoram no máximo 60 dias».
Por isso, para avaliar se a Hashi cumpre o que promete, não basta observar quantos BTC podem ser depositados. Também é preciso analisar se as retiradas normais funcionam sem problemas, como os parâmetros de limitação são divulgados e como são verificadas a recuperação e a transferência de responsabilidades do comitê caso o Guardian deixe de funcionar. Uma verificação de segurança que acrescenta uma etapa e o controle unilateral integral por parte do usuário são dois arranjos diferentes; para saber se é adequada a determinado tipo de fundos, é preciso levar em conta todas essas condições de saída.
Esta análise baseia-se nos documentos de design atualmente públicos, cuja página ainda indica Testnet; não é possível afirmar, com base neles, que a mainnet já esteja operando amplamente com os mesmos parâmetros. O anúncio de 8 de outubro fala de um lançamento gradual ao longo deste mês; será necessário voltar a verificar as informações com base na implementação efetiva e nos registros reais de retiradas. A demonstração de 40,6 milhões de TPS e os compromissos de capital superiores a 500 milhões de dólares não substituem essa etapa. A nova conclusão, por ora, é que a validação do valor da Hashi depende tanto de saber se as operações conseguem entrar quanto de saber se os ativos conseguem sair de acordo com as regras, em condições normais e anormais. Fontes: User Flows, Guardian, Limiter e Address Scheme da Mysten Labs para a Hashi; a imagem que acompanha o texto é uma ilustração do mecanismo.
A distinção fundamental é que a rede em que o ativo está e quem pode autorizar o seu gasto são questões diferentes. De acordo com os User Flows da Hashi, o usuário deposita BTC num endereço Bitcoin exclusivo e, após a confirmação, recebe hBTC na Sui. Os gastos normais usam uma estrutura 2-de-2: uma parte é o comitê MPC da Hashi e a outra é o Guardian. O MPC realiza a assinatura através da colaboração de várias partes, enquanto o Guardian oferece uma segunda camada de verificação. O fato de o usuário solicitar uma retirada não significa que tenha uma chave que lhe permita transferir BTC diretamente, contornando o protocolo.
O objetivo dessa verificação é restringir a liberação dos ativos em situações anormais, como vulnerabilidades ou atividades maliciosas. Mas as medidas de segurança também podem afetar a rapidez das retiradas. A documentação do Limiter especifica que as retiradas estão sujeitas a uma capacidade máxima e a um limite que é reabastecido continuamente; se a capacidade for insuficiente, é necessário esperar. Uma solicitação individual que ultrapasse a capacidade máxima será ignorada até que o limite aumente, e o usuário também pode cancelar a solicitação de acordo com as regras. Em geral, as solicitações são processadas por ordem de chegada, mas isso não é uma garantia estrita. Portanto, se uma retirada demorar muito, a espera na fila, por si só, não prova que os fundos foram roubados; da mesma forma, a existência de proteções não garante que os fundos chegarão imediatamente. É preciso considerar em conjunto a configuração dos limites, a fila e a execução efetiva.
Há também uma via de recuperação que merece uma explicação à parte. A documentação do Address Scheme especifica que, além dos gastos normais, o script permite que o comitê MPC gaste os fundos separadamente após um bloqueio temporal relativo de 60 dias, contado a partir da confirmação da UTXO. Uma UTXO pode ser entendida como uma saída na blockchain que ainda não foi gasta. Esse mecanismo oferece uma via alternativa de recuperação em situações como a perda da chave do Guardian. A contagem começa quando essa saída é confirmada, não quando o usuário envia o pedido de retirada. Isso também não transfere o direito de recuperação para cada usuário, nem constitui uma promessa de serviço de que «todas as retiradas demoram no máximo 60 dias».
Por isso, para avaliar se a Hashi cumpre o que promete, não basta observar quantos BTC podem ser depositados. Também é preciso analisar se as retiradas normais funcionam sem problemas, como os parâmetros de limitação são divulgados e como são verificadas a recuperação e a transferência de responsabilidades do comitê caso o Guardian deixe de funcionar. Uma verificação de segurança que acrescenta uma etapa e o controle unilateral integral por parte do usuário são dois arranjos diferentes; para saber se é adequada a determinado tipo de fundos, é preciso levar em conta todas essas condições de saída.
Esta análise baseia-se nos documentos de design atualmente públicos, cuja página ainda indica Testnet; não é possível afirmar, com base neles, que a mainnet já esteja operando amplamente com os mesmos parâmetros. O anúncio de 8 de outubro fala de um lançamento gradual ao longo deste mês; será necessário voltar a verificar as informações com base na implementação efetiva e nos registros reais de retiradas. A demonstração de 40,6 milhões de TPS e os compromissos de capital superiores a 500 milhões de dólares não substituem essa etapa. A nova conclusão, por ora, é que a validação do valor da Hashi depende tanto de saber se as operações conseguem entrar quanto de saber se os ativos conseguem sair de acordo com as regras, em condições normais e anormais. Fontes: User Flows, Guardian, Limiter e Address Scheme da Mysten Labs para a Hashi; a imagem que acompanha o texto é uma ilustração do mecanismo.