Proponiendo dos cambios significativos a la metodología y presentación de @Walletbeat hoy: - Introducir "verificabilidad" como una dimensión separada de la calificación en sí; issue #503 - Mover las billeteras que no están en la etapa cero a una pestaña separada "Otros" similar a L2BEAT; issue #504 Algunas reflexiones a continuación 🧐

La mayoría de las cosas que Walletbeat busca se pueden evaluar de una de dos maneras: 1⃣ "Solo usa la billetera, hermano": Verifica si existe o no una función utilizando la billetera. Ejemplo: ¿resuelve direcciones ENS al enviar tokens? ¿Tiene un libro de direcciones de destinatarios de tokens en algún lugar?

2⃣ Pruebas de caja negra: Ejecuta la billetera en un entorno controlado, observa su comportamiento. - Independencia del proveedor L1: Bloquea toda la red excepto el punto final RPC de L1 - Recolección de datos: Analiza el tráfico de la red - Cliente ligero: Ejecuta con un nodo RPC engañoso y verifica si la billetera lo nota

Pero algunas características no pueden ser probadas por ninguno: - ¿Qué biblioteca criptográfica utiliza la billetera? - ¿Dónde se almacenan los materiales de la clave privada de la billetera caliente? - ¿Cómo reconstruye una billetera MPC la clave? - ¿Se revende mis datos de flujo de órdenes después de ser enviados a un servicio de simulación de transacciones?

Sería útil distinguir lo que las billeteras _afirman_ sobre estas cosas, de si estas afirmaciones son _verificables_. Por ejemplo, las afirmaciones verificables se muestran como porciones completamente verdes, las afirmaciones no verificables pueden mostrarse como verdes con contorno rojo o similar en los gráficos de pastel.

Para fines de evaluación de etapas, solo las afirmaciones verificables califican. Además, Walletbeat requiere la disponibilidad del código fuente para llegar a solo la etapa cero, por lo que cualquier billetera sin código fuente disponible se adelantaría metodológicamente con este cambio.

El beneficio son calificaciones y comparaciones más claras de las billeteras, así como una menor interdependencia entre los atributos. La licencia y disponibilidad del código fuente ya son sus propios atributos; hacer que otros atributos se pongan en rojo solo porque el código fuente no está disponible perjudica la comprensibilidad.

Pon tus pensamientos sobre esto en el problema #503:

El otro cambio es mover todas las carteras que no califican para la etapa 0 a una pestaña de "Otros", similar a lo que L2BEAT ha hecho para proyectos del tipo "ni siquiera L2s":

Razonamiento: Las billeteras que no son accesibles para la fuente no son verificables en muchos de sus atributos. Con el cambio anterior, incluso si dejáramos claras las calificaciones no verificables, la yuxtaposición de estas billeteras junto a billeteras verificables reduciría el incentivo de siquiera llegar a la etapa 0.

La Etapa 0 es el mínimo indispensable para una billetera: solo haz que tu código fuente esté disponible. Cada navegador web que la gente usa hoy en día tiene el código fuente disponible. Las billeteras son un software de mayor riesgo en comparación con los navegadores web, así que esta no es una exigencia alta.

Pon tus pensamientos sobre el problema #504:

No me gusta alargar el conjunto de problemas que aún necesitan ser abordados antes del lanzamiento, pero marcar estos problemas como bloqueadores del lanzamiento. Esto se debe a que, aunque ninguno de ellos sería técnicamente un cambio de metodología, puede parecerlo desde una perspectiva de UI/visualización. ¡Gracias por leer!