Ao analisar recentemente os dados da rede Acurast, é difícil não reparar logo de cara nos 335 mil celulares e na cobertura de mais de 175 países.
Mas, pensando melhor, o que realmente me interessa não é “quantos são”, e sim outra questão: esses celulares são reais?
Não estou sendo crítico só por criticar. Quando uma rede DePIN envolve incentivos por poder computacional, não dá para ignorar emuladores, dispositivos falsos em massa e sinais de atividade online falsificados. Se até um script pode se passar por dezenas de celulares e continuar recebendo recompensas, por mais impressionantes que sejam os dados dos nós, no fim eles podem não passar de números sem capacidade computacional real.
A forma como a Acurast lida com este problema é mais rigorosa do que eu imaginava inicialmente.
Quando um telemóvel entra na rede, tem de passar pela Google Key Attestation do Android ou pela Apple App Attest do iPhone. Em termos simples, um módulo de segurança protegido por hardware, integrado no telemóvel, emite uma prova que confirma que o dispositivo é um telemóvel real, que o sistema não foi adulterado e que não tem root nem jailbreak. As tarefas dos programadores só podem ser enviadas para execução no dispositivo depois de passarem esta verificação.
No entanto, o verdadeiro ponto-chave não é «verificar uma vez no momento do registo».
As chaves de atestação usadas por alguns dispositivos mais antigos podem ser partilhadas por telemóveis do mesmo lote ou até do mesmo modelo. Se a chave do fabricante for comprometida, os atacantes podem fazer com que um servidor ou emulador se faça passar por um telemóvel real, ou até criar muitos dispositivos com a mesma identidade. À primeira vista, as provas destes dispositivos continuam a ter um formato válido. Se a rede não continuar a verificar se as chaves foram revogadas, é difícil detetar o problema.
Por isso, a Acurast verifica continuamente as provas dos dispositivos. Os dispositivos associados a chaves revogadas pela Google ou pela Apple são removidos do conjunto de Processors, deixam de poder receber tarefas de computação e também deixam de poder receber as recompensas correspondentes.
Este mecanismo não está isento de custos.
Se uma chave partilhada por um lote de telemóveis antigos for revogada, alguns dispositivos de utilizadores legítimos também poderão ser afetados. Os utilizadores podem tentar repor as definições de fábrica, instalar uma versão oficial mais recente do sistema e bloquear o Bootloader antes de voltarem a ligar-se à rede, mas não há garantia de que isso resolva o problema. A Acurast também não pode simplesmente criar uma lista de permissões para dispositivos que «parecem estar em ordem», porque, se aceitar provas revogadas, os dispositivos falsificados também poderão entrar na rede.
Na verdade, acho importante falar abertamente sobre estas imperfeições. O verdadeiro valor de um mecanismo de segurança não está em afirmar que nunca terá problemas, mas em saber se, depois de detetar um risco, está disposto a sacrificar parte do número de nós que aparenta ter para continuar a garantir que a capacidade de computação da rede é real.
Isto também está relacionado com o sistema de incentivos do $ACU. Para receber recompensas, um Compute Provider deve fornecer dispositivos reais e capacidade de computação real, em vez de executar um script que apenas comunica que está online. Quanto menos nós falsos houver, mais fiável será a capacidade de computação adquirida pelos programadores e maior será a probabilidade de as recompensas da rede chegarem a quem realmente fornece recursos.
Quando comecei a acompanhar o DePIN, também tendia a comparar primeiro quem tinha mais nós. Agora acho que dezenas de milhares de dispositivos que podem ser verificados continuamente talvez sejam mais valiosos do que milhões de contas cuja autenticidade não pode ser comprovada.
Entre o número de nós e a fiabilidade dos nós, qual deles valorizas mais?
Este artigo reflete apenas a minha observação e partilha sobre os mecanismos do projeto e não constitui qualquer recomendação de investimento.