O Arbitrum voltou a impulsionar o Stylus, o que, em princípio, é uma novidade técnica positiva que merece atenção: contratos escritos em Rust e C/C++ podem interoperar na mesma cadeia com aplicações EVM, além de abrir espaço para custos mais baixos em cenários com uso intensivo de computação. Mas a controvérsia na comunidade não está no Stylus em si, e sim na «nova autoridade de aprovação de contratos» que o acompanha.
A questão central é: quem tem o poder de aprovar ou rejeitar a entrada de contratos em operação? Os critérios de aprovação são transparentes? É possível recorrer após uma rejeição? A autorização tem prazo de validade? Se o acesso ficar nas mãos de um pequeno grupo de carteiras com múltiplas assinaturas ou da equipe, a «implantação sem permissão» pode acabar se tornando «implantação mediante autorização», criando uma barreira injusta para grandes projetos e equipes anônimas.
É compreensível haver auditorias de segurança e isolamento de riscos, mas poderes temporários precisam ter limites claros, divulgação on-chain, bloqueio temporal e mecanismos de saída. Caso contrário, uma atualização técnica poderá também reescrever o compromisso do Arbitrum com a abertura.$ARB #Arbitrum #Stylus #Layer2
A questão central é: quem tem o poder de aprovar ou rejeitar a entrada de contratos em operação? Os critérios de aprovação são transparentes? É possível recorrer após uma rejeição? A autorização tem prazo de validade? Se o acesso ficar nas mãos de um pequeno grupo de carteiras com múltiplas assinaturas ou da equipe, a «implantação sem permissão» pode acabar se tornando «implantação mediante autorização», criando uma barreira injusta para grandes projetos e equipes anônimas.
É compreensível haver auditorias de segurança e isolamento de riscos, mas poderes temporários precisam ter limites claros, divulgação on-chain, bloqueio temporal e mecanismos de saída. Caso contrário, uma atualização técnica poderá também reescrever o compromisso do Arbitrum com a abertura.$ARB #Arbitrum #Stylus #Layer2