Da Ethereum-Adressen keine Prüfsummen haben , sollten ICAP-Adressen (die eine Prüfsumme haben) vermehrt werden?
Oder gibt es andere Optionen, die für die Verbreitung von Ethereum-Adressen mit Prüfsumme besser geeignet sind?
Wäre zum Beispiel dieser Ethereum Improvement Proposal (EIP) oder ein anderer besser geeignet (z. B. eine HD-Wallet )?
# code from EIP linked above
def checksum_encode(addr): # Takes a 20-byte binary address as input
o = ''
v = utils.big_endian_to_int(utils.sha3(addr))
for i, c in enumerate(addr.encode('hex')):
if c in '0123456789':
o += c
else:
o += c.upper() if (v & (2**(255 - i))) else c.lower()
return '0x'+o
Geeignet ist Gegenstand der Diskussion, daher werde ich versuchen, mich an Fakten und den aktuellen (schnelllebigen) Stand der Umsetzung zu halten.
Im Allgemeinen waren ICAP-Adressen, die mit XE... beginnen, früher der gewünschte Weg, um einen sicheren Adressmechanismus zu implementieren. Derzeit bieten nur der C++-Client und der JavaScript-Client die ICAP-Implementierung an. Eine breitere Akzeptanz von ICAP-Adressformaten und Client-Kompatibilität könnte nach dem Homestead-Fork in anderen Clients eingeführt werden.
So plant Geth ab Version 1.4.1 eine rudimentäre ICAP-Unterstützung.
Zuletzt wurde Vitaliks Idee der Hex-Prüfsummencodierung experimentell in der JavaScript-API und der Ethereum DApp Wallet implementiert .
Es besteht Verwirrung darüber, warum es noch einen weiteren Standard für die Adressprüfsumme geben muss. Kritiker geben an, dass die mit Prüfsummen codierten Hex-Adressen nicht sofort als von normalen Hex-Adressen unterscheidbar erkennbar sind und die zusätzliche Sicherheitsebene daher nur auf Softwareebene und nicht auf Benutzerebene erscheint.
Daher sollte die Implementierung und Verwendung von ICAP die am besten geeignete Option sein, da es mehr Sicherheit für die Benutzer bietet und derzeit das am weitesten verbreitete Adressformat mit aktivierter Prüfsumme ist, auch wenn es nicht von allen Clients unterstützt wird. Noch.