Twee belangrijke wijzigingen in de methodologie en weergave van @Walletbeat voorstellen vandaag: - "Verifieerbaarheid" introduceren als een aparte dimensie van de beoordeling zelf; issue #503 - Niet-stage-nul wallets verplaatsen naar een aparte "Overige" tab, vergelijkbaar met L2BEAT; issue #504 Enkele gedachten hieronder 🧐

De meeste dingen waar Walletbeat naar kijkt, kunnen op een van de twee manieren worden geëvalueerd: 1⃣ "Gebruik gewoon de wallet, bro": Controleer of een functie bestaat of niet door de wallet te gebruiken. Voorbeeld: lost het ENS-adressen op bij het verzenden van tokens? Heeft het ergens een adresboek voor tokenontvangers?

2⃣ Black-box testen: Voer de wallet uit in een gecontroleerde omgeving, observeer het gedrag. - Onafhankelijkheid van L1-provider: Blokkeer alle netwerken behalve het L1 RPC-eindpunt - Gegevensverzameling: Analyseer het netwerkverkeer - Lichtgewicht client: Voer uit met een leugenachtige RPC-knooppunt en kijk of de wallet het opmerkt

Maar sommige functies kunnen door geen van beiden worden getest: - Welke cryptografische bibliotheek gebruikt de wallet? - Waar worden de privé-sleutels van de hot wallet opgeslagen? - Hoe reconstructeert een MPC-wallet de sleutel? - Worden mijn orderflowgegevens doorverkocht nadat ze naar een transactie-simulatieservice zijn gestuurd?

Het zou nuttig zijn om te onderscheiden wat wallets _beweren_ over deze zaken, van de vraag of deze beweringen _verifieerbaar_ zijn. Bijvoorbeeld, verifieerbare beweringen worden weergegeven als volledig groene segmenten, niet-verifieerbare beweringen kunnen worden weergegeven als groen met een rode rand of iets dergelijks op de taartdiagrammen.

Voor evaluatiedoeleinden van de fase komen alleen verifieerbare claims in aanmerking. Bovendien vereist Walletbeat dat de broncode beschikbaar is om slechts naar fase nul te gaan, dus elke wallet zonder beschikbare broncode zou "vooruit" gaan qua methodologie met deze wijziging.

Het voordeel is duidelijkere beoordelingen en vergelijkingen van wallets, evenals minder onderlinge afhankelijkheid tussen de attributen. Licenties voor de broncode en beschikbaarheid zijn al hun eigen attributen; andere attributen rood laten worden alleen omdat de bron niet beschikbaar is, schaadt de begrijpelijkheid.

Plaats je gedachten hierover op probleem #503:

De andere wijziging is om alle wallets die niet kwalificeren voor fase 0 naar een "Overige" tabblad te verplaatsen, vergelijkbaar met wat L2BEAT heeft gedaan voor projecten van het type "niet eens L2s":

Reden: Portemonnees die niet beschikbaar zijn als bron zijn op veel van hun eigenschappen niet verifieerbaar. Met de bovenstaande wijziging, zelfs als we onverifieerbare beoordelingen duidelijk maakten, zou de juxtapositie van deze portemonnees naast verifieerbare portemonnees de prikkel verlagen om zelfs fase 0 te bereiken.

Fase 0 is het absolute minimum voor een wallet: maak gewoon je broncode beschikbaar. Elke webbrowser die mensen vandaag de dag gebruiken, is bronbeschikbaar. Wallets zijn zelfs software met hogere inzet in vergelijking met webbrowsers, dus dit is geen hoge lat.

Plaats je gedachten over probleem #504:

Ik houd er niet van om de set van problemen die nog moeten worden aangepakt voor de lancering te verlengen, maar ik markeer deze problemen als lancering blokkades. Dit komt omdat, hoewel geen van beide technisch een methodologieverandering zou zijn, het vanuit een UI/weergaveperspectief als een verandering kan aanvoelen. Bedankt voor het lezen!