Vejen til Neo3: Brugervenlige kontonavne

En af de mest nyttige ting ved et blockchain-netværk er, at enhver kan oprette og eje en „konto“ ved at generere et kryptografisk tastatur. Brug af kryptografi til godkendelse betyder, at alle kan få adgang til netværksressourcer. De er altid tilgængelige globalt for alle med en internetforbindelse.

Det er en stor gevinst for at skabe lige muligheder, men tastaturer har problemer med brugervenlighed. Det mest udfordrende problem er det tilknyttede personlige ansvar. Brugere skal finde en måde at beskytte private nøgler eller tilsvarende frøord på. Hvis deres sikkerhed mislykkes, kan de miste adgang til deres aktiver eller få dem stjålet.

Et andet fremtrædende emne involverer selve de offentlige nøgler. De er normalt lange og forvirrende karakterstrenge, hvilket gør blockchain-interaktion vanskelig. De er mere udsatte for fejl end bankkontonumre eller e-mail-adresser, så utilsigtede overførsler er mere tilbøjelige til at forekomme.

Neo-udviklere arbejder på en native domænetjeneste for at forbedre dette design. Brugere vil være i stand til at kortlægge deres adresser til brugervenlige domænenavne. Dette giver indfødt kompatibilitet på protokolniveau, hvilket forbedrer tredjepartsløsninger.

Base58-kodning

Brugere af Neo og andre blockchains har sandsynligvis ikke interageret med en faktisk offentlig nøgle. De fleste brugere er i stedet fortrolige med offentlige adresser, kodede repræsentationer af disse nøgler. Disse adresser er designet til at være lidt lettere at arbejde med.

Base58-formatet aktiverede dette første skridt mod menneskelige læsbare adresser. Opfundet af Satoshi Nakamoto blev den først implementeret i Bitcoin. Ligesom Base64 konverterer den binære data til ASCII-tegn med en nøgleforskel, der har til formål at forbedre outputens læsbarhed.

Forskellen er udelukkelsen af ​​seks problematiske tegn. Fire er tegn, der kan forekomme ens i nogle skrifttyper, „0“ vs „O“ og „i“ vs „l“. De to andre er ikke-alfanumeriske tegn, normalt “+” og “/” i de fleste Base64-implementeringer.

Som et resultat er output fra Base58-kodning straks mere brugervenlig. Overvej f.eks. Den offentlige Neo3-nøgle 02f68dd3c2966a890c8968fb9f71e55ab48dc99889b179fbd6a188056fc999c1e0. Efter behandling, hvor sidste trin er Base58-kodning, er den endelige form NbnPGLE386Gc6mAqhHeumKbP37zhGPXLzH.

Der er også et par andre sidefordele. Satoshi selv kommenterede disse i Bitcoins Base58-implementering:

Neo arver også et andet træk ved Bitcoins implementering af Base58, ekstra kontrolsumtrin. Fire byte af fejlkontrolkode afledt ved hjælp af SHA-256 gør det muligt at opdage visse fejl, en fordel, der blev bemærket under modstand mod et forslag om at fjerne Base58 fra Neo3.

Forslag om alias-service

Base58 er et skridt i den rigtige retning, der hjælper med at gøre adresser hurtige at genkende. På trods af dette kan dataindtastning for transaktioner stadig være skræmmende. Selv erfarne brugere udfører ofte testoverførsler, før de føler sig sikre på at flytte en stor sum.

For at blockchain-applikationer skal være tilgængelige for masserne, kræves yderligere forbedringer. Nogle tredjepartsløsninger har udviklet sig til at imødekomme denne efterspørgsel, såsom Ethereum Name Service eller dens neo-baserede modstykke fra NEL.

Ulempen ved disse tjenester er, at de ikke er standardiserede eller indfødte i protokollen. Dette betyder, at de kun er tilgængelige i applikationer, der vælger at integrere dem.

Tilføjelsen af ​​indfødte kontrakter i Neo3 muliggør understøttelse af brugerdefineret kontonavn på protokolniveau. Hver Neo-baseret applikation ville være i stand til at understøtte disse aliasser uden afhængigheder. En naturlig løsning ville gøre hele platformen mere brugervenlig.

Diskussioner om dette krav startede først på Neo Community Assembly i 2019. Mengyu Liu, en NGD-softwareudvikler, ville senere levere den første foreslåede løsning.

Forslaget var om en tjeneste, der lod brugerne oprette og binde mindeværdige aliasser til en adresse. For at forhindre efterligning ville det linke sammen med NeoID for at kontrollere ægtheden. Disse aliasser kunne registreres, slettes og ændres gennem den oprindelige kontrakt eller tjeneste. Yderligere funktioner ville være inkluderet til konvertering mellem aliaser og adresser.

Flere fordele blev bemærket; tjenesten skal være let og have simpel økonomi. Det ville også være let at bruge for udviklere, der kunne kalde det i kontrakt via interop API.

Forslaget om alias-service opfyldte mange af de tilsigtede mål for de indledende diskussioner. Imidlertid blev tilgangen opgivet til fordel for en DNS-stil domænetjeneste.

Implementeret som en indfødt kontrakt, vil denne tjeneste give brugerne mulighed for lettere at administrere deres egne domænenavne. I den næste artikel vil vi undersøge designet af denne løsning, der i øjeblikket er under gennemgang af Neo3.