|
|
Geplaatst op 17-10-2025 09:01:55
|
|
|
|
Base58, Base58Check, Bech32 en Bech32m zijn veelgebruikte coderingsformaten in blockchaintechnologie, voornamelijk bedoeld om de leesbaarheid te verbeteren, fouten te verminderen en dataintegriteit te waarborgen. Deze vier codes hebben hun eigen voordelen in het waarborgen van beveiliging, compatibiliteit en foutcorrectiemogelijkheden, en zijn belangrijke hoekstenen van moderne blockchain-adressystemen.
Base58
"Base58" is een coderingsmethode uitgevonden door Satoshi Nakamoto, die is aangepast van een bekende coderingsmethode "Base64". De Base64-tekenset bevat: alle cijfers en hoofd- en kleine letters, evenals twee symbolen ("+" en "/"); In totaal 64 personages. Satoshi Nakamoto verwijderde het getal 0, de hoofdletters I en O, de kleine letter l en het symbool, en het werd Base58.
Tekenset: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
Base58Check
In vergelijking met Base58 heeft Base58Check-codering slechts één extra checksumberekening. Zoals hieronder getoond:
Base58Check lost de problemen op van foutgevoeligheid, moeilijk te herkennen en niet-geverifieerd in traditionele coderingsmethoden, en biedt een veilige, compacte, mensvriendelijke en foutdetecterende representatiemethode voor sleutelgegevens in de blockchain (zoals adressen en privésleutels). Hoewel het nu geleidelijk wordt vervangen door de meer geavanceerde Bech32/Bech32m (voor SegWit-adressen), speelde het een cruciale rol in het vroege Bitcoin-ecosysteem.
Bech32
"Bech32" is een coderingsmethode gedefinieerd door BIP 0173, geschreven door Pieter Wuille en Greg Maxwell. Deze codering vindt echter ook zijn oorsprong: "Bech" verwijst naar "BCH", een cyclisch foutcorrectie-coderingsalgoritme dat respectievelijk in 1959 en 1960 door drie wiskundigen werd uitgevonden (de naam BCH komt van de namen van deze drie wiskundigen). "32" betekent dat de tekenset van de coderingsmethode slechts 32 tekens heeft: kleine letters en cijfers, exclusief de cijfers "1", de letters "b", "i" en "o".
Aan het begin van BIP 0173 wijzen de auteurs op de ongewenste aspecten van Base58:
- Base58 gebruikt zowel grote als kleine letters Engels, waardoor de gegevens in QR-codes worden ingevoerd niet in de kleinere "numeriek alfabet"-modus, maar alleen in de grotere "byte data"-modus.
- Het gebruik van zowel hoes als hoes maakt het ook moeilijk om te transcriberen, typen en lezen op het telefoontoetsenbord.
- De checksum vereiste twee opeenvolgende SHA256-bewerkingen, die traag waren en geen mogelijkheid hadden om de verkeerde locatie te lokaliseren.
- De meeste lokaliseerbare foutcoderingsmethoden werken alleen als de tekenset van priemmacht is, en 58 geen priemmacht is.
- Base58 is complexer te decoderen en trager om te decoderen.
Als gevolg hiervan gebruikt de nieuwe aanpak van Bech32 alleen kleine letters en cijfers; Wanneer nodig, bijvoorbeeld bij het tekenen van een QR-code, kunnen deze letters allemaal worden vervangen door hoofdletters voor een compactere weergave. Kleinere QR-codes, omdat Bech32-adressen enkelvoudig zijn, kun je ze als QR-codes coderen met alfanumerieke modus. Dit betekent dat je een compactere QR-code kunt maken omdat Base58 hoofd- en kleine letters vereist (wat betekent dat je geen alfanumerieke modus kunt gebruiken), terwijl Bech32 dat niet doet. Zoals hieronder getoond:
Zoals je kunt zien, ondanks het Bech32-adresBevat meer tekens, maar de mogelijkheid om alfanumerieke patronen te gebruiken betekent dat QR-codes in totaal minder data gebruiken。
Tegelijkertijd kan Bech32 fouten lokaliseren: het kan niet alleen vinden dat je een kopieerfout hebt gemaakt, maar ook aangeven welke bits je verkeerd hebt gekopieerd (dit vermogen om fouten te vinden is veel beter dan Base58).
In feite heeft het BCH-algoritme ook een "foutcorrectie"-functie: het kan niet alleen aangeven welke bits je verkeerd hebt gekopieerd, maar ook welke tekens het moet zijn. De auteurs van BIP 0173 vonden echter de inherente gevaren ervan: enerzijds verzwakt het versterken van foutcorrectie het vermogen om fouten te lokaliseren; Aan de andere kant, als de gebruiker te veel vertrouwt op de foutcorrectiemogelijkheden van de software, kan de software de foutieve gegevens die door de gebruiker zijn ingevoerd corrigeren tot een "geldig maar nutteloos" stuk data - hoewel het geldig is als een stuk BCH-gecodeerde gegevens; Het is echter mogelijk dat het herstelde Bitcoin-script niet onder controle ligt van de ontvanger, of zelfs van iemand anders. Dit is extreem gevaarlijk. Daarom waarschuwt BIP 0173: "Naast het herinneren van gebruikers aan welke bits mogelijk verkeerd zijn gekopieerd, mag de software geen foutcorrectiemogelijkheden implementeren (correctiesuggesties geven)." ”
Daarnaast volgt Bech32 het patroon dat wordt gevonden in Base58-codering:
1. Bech32-gegevens beginnen met een alinea "data met betekenis (hrp)", vergelijkbaar met het voorvoegsel in Base58, wat kan aangeven om wat voor soort data het gaat.
HRP kan veel meer dan 32 tekens gebruiken; Bech32 gebruikt ook het getal "1" als scheider om de HRP te scheiden van de data die daadwerkelijk gedecoderd moet worden.
Naast Bitcoin zijn er veel andere projecten die ook Bech32 hebben overgenomen; HRP wordt gebruikt om gegevens te onderscheiden van verschillende items. Hier is een lijst van geregistreerde HRP's, wat erg interessant is (maar alleen interessant).
2. Bech32 ontwierp ook een checksum die de laatste 6 tekens van de gecodeerde data inneemt.
Bech32m
"Bech32m" is een coderingsmethode gedefinieerd door BIP 0350. Verbinden:De hyperlink-login is zichtbaar.Het werd voorgesteld omdat ontwikkelaars een kwetsbaarheid in Bech32-code ontdekten:
Wanneer het laatste teken "p" is, veroorzaakt het invoegen of verwijderen van een willekeurig aantal "q" voor dat teken geen checksumfout (de gegevens worden nog steeds als geldig beschouwd), danHet controlesommechanisme verliest volledig zijn functieFins.
Als je geen gestandaardiseerd Bitcoin-script toevoegt, kan dit probleem eenvoudig worden opgelost: zowel het P2WPKH-adres als het P2WSH-adres hebben een bepaalde lengte, voeg gewoon de lengtecontrole toe. Aangezien we in de toekomst ook nieuwe gestandaardiseerde scripts zullen toevoegen, kan de adreslengte veranderen, dus is het noodzakelijk dit probleem op te lossen.
Bech32m lost dit probleem op door een parameter in de Bech32-checksumgenerator te wijzigen.
Momenteel wordt Bech32m alleen gebruikt om adressen te coderen voor "P2TR"-scripts die worden toegevoegd met de "Taproot"-upgrade. Het kan in de toekomst worden gebruikt in de adrescodering van andere gestandaardiseerde scripts.
Referentie:
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar. |
Vorig:tiktok, Douyin het pakket vangt en het Frida-script vernietigt, dat de locatie van de SO-bestandspatch kan vindenVolgend:Introductie tot Bitcoin-adrestypes Legacy, Nested SegWit, Native SegWit en Taproot
|
