Propondo duas mudanças significativas na metodologia e exibição do @Walletbeat hoje: - Introduzir "verificabilidade" como uma dimensão separada da classificação em si; issue #503 - Mover carteiras que não estão no estágio zero para uma aba separada "Outros" semelhante ao L2BEAT; issue #504 Algumas reflexões abaixo 🧐

A maioria das coisas que o Walletbeat procura pode ser avaliada de uma das duas maneiras: 1⃣ "Basta usar a carteira, mano": Verifique se uma funcionalidade existe ou não usando a carteira. Exemplo: resolve endereços ENS ao enviar tokens? Tem um livro de endereços de destinatários de tokens em algum lugar?

2⃣ Testes de caixa-preta: Execute a carteira em um ambiente controlado, observe seu comportamento. - Independência do provedor L1: Bloqueie toda a rede, exceto o endpoint RPC L1 - Coleta de dados: Analise o tráfego da rede - Cliente leve: Execute com um nó RPC desonesto e veja se a carteira percebe

Mas algumas funcionalidades não podem ser testadas por nenhum dos dois: - Qual biblioteca criptográfica o wallet utiliza? - Onde é armazenado o material da chave privada da hot wallet? - Como é que uma wallet MPC reconstrói a chave? - Os meus dados de fluxo de ordens são revendidos após serem enviados para um serviço de simulação de transações?

Seria útil distinguir o que as carteiras _afirmam_ sobre estas coisas, do que essas afirmações são _verificáveis_. Por exemplo, as afirmações verificáveis são mostradas como fatias totalmente verdes, enquanto as afirmações não verificáveis podem ser mostradas como verdes com contorno vermelho ou algo semelhante nos gráficos de fatias.

Para fins de avaliação de estágio, apenas as reivindicações verificáveis qualificam. Além disso, o Walletbeat requer a disponibilidade do código-fonte para chegar apenas ao estágio zero, portanto, qualquer carteira sem código-fonte disponível ficaria "à frente" em termos de metodologia com esta mudança.

O benefício é classificações e comparações de carteiras mais claras, bem como menos interdependência entre os atributos. A licença e a disponibilidade do código-fonte já são seus próprios atributos; ter outros atributos a ficarem vermelhos apenas porque o código-fonte não está disponível prejudica a compreensibilidade.

Coloque os seus pensamentos sobre isso na questão #503:

A outra alteração é mover todas as carteiras que não qualificam para o estágio 0 para uma aba "Outros", semelhante ao que a L2BEAT fez para projetos do tipo "nem mesmo L2s":

Justificação: As carteiras que não estão disponíveis como fonte não são verificáveis em muitos dos seus atributos. Com a alteração acima, mesmo que tornássemos as classificações não verificáveis claras, a justaposição dessas carteiras ao lado de carteiras verificáveis diminuiria o incentivo de sequer chegar ao estágio 0.

O Estágio 0 é o mínimo necessário para uma carteira: basta tornar o seu código-fonte disponível. Todos os navegadores da web que as pessoas usam hoje são de código-fonte disponível. As carteiras são um software ainda mais crítico em comparação com os navegadores da web, portanto, esta não é uma exigência elevada.

Coloque os seus pensamentos sobre a questão #504:

Não gosto de alongar o conjunto de questões que ainda precisam ser abordadas antes do lançamento, mas marcar essas questões como bloqueadores de lançamento. Isso porque, embora nenhuma delas seja tecnicamente uma mudança de metodologia, pode parecer uma do ponto de vista da interface/visualização. Obrigado por ler!