Yellow Paper eq 221: Warum und wie entspricht der Absender einer signierten Transaktion der Adresse des Unterzeichners?

Ethereum Yellow Paper: Siehe Gleichung 220 und 221.

Geben Sie hier die Bildbeschreibung ein

In Gleichung 220 erhalten wir die Transaktion, die an das Netzwerk gesendet werden kann und durch eine 256-Bit-Transaktions-ID verfolgt wird. Seine ganz rechten 160 Bits sind gleich S(T) , was als Senderfunktion S der Transaktion definiert ist.

Meine Frage bezieht sich auf Gleichung 221, die eine Aussage über Folgendes ist:

Die Behauptung, dass der Absender einer signierten Transaktion gleich der Adresse des Unterzeichners ist, sollte selbstverständlich sein

[F] Warum und wie ist der Absender einer signierten Transaktion ( S(T) on the eq. 220) gleich der Adresse des Unterzeichners ( A(pr)) ? Gibt es eine gut erklärte Dokumentation zu diesem Thema?

Könnten wir die folgende Aussage abschließen:

B96...255(KEC(ECDSARECOVER(h(T),Tw,Tr,Ts))) == B96...255((KEC(ECDSAPUBKEY(pr)))

Vielen Dank für Ihre wertvolle Zeit und Hilfe.

Antworten (1)

Dies ist als Trick zur Wiederherstellung öffentlicher Schlüssel von ECDSA bekannt, siehe https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work how elliptic curve Mathe funktioniert.

Eine Ethereum-Signatur hat drei Parameter r, sund v. Wenn Sie r, sund die ECDSA-Gleichung verwenden, haben Sie zwei Kandidaten für den öffentlichen Schlüssel. Wenn Sie dann verwenden v, können Sie disambiguieren und genau wissen, welcher der öffentliche Schlüssel des Unterzeichners ist.

Sobald Sie den öffentlichen Schlüssel haben, können Sie die Adresse mit den letzten 20 Bytes von berechnen keccak256(publicKey).

Ich bin wirklich verwirrt :( wofür steht S(T)steht, ist es die Ethereum-Adresse des Absenders, was eigentlich die 160-Bit sind, die wir in Gl. 215 erhalten? KEC( ECDSARECOVER(h(T),Tw,Tr,Ts)) == KEC(ECDSAPUBKEY(pr))Sie konnten also auf meiner aktualisierten Frage sehen?@Ismael
T ist eine Transaktion, S(T) ist eine Funktion, die den Absender der Transaktion T zurückgibt.
Ganz klar, also ECDSARECOVER(h(T),Tw,Tr,Ts))ist der öffentliche Schlüssel des Unterzeichners und daraus können wir die 160-Bit-Ethereum-Adresse des Unterzeichners erhalten, richtig? @Ismael.
Die Gleichung ohne KEC ist nicht immer wahr, wir haben Adressen mit 20 Bytes und öffentliche Schlüssel mit 64 Bytes, also gibt es mehrere öffentliche Schlüssel, die auf dieselbe Adresse abgebildet werden.
Wie können mehrere öffentliche Schlüssel derselben Adresse zugeordnet werden? Sollte nicht KEC(somePublicKey)für jeden öffentlichen Schlüssel ein eindeutiger Wert generiert werden? @Ismael
Aa Ich verstehe, KEC(somePublicKeykann einen eindeutigen Wert generieren, aber die 160 Bit ganz rechts könnten gleich sein, was zu derselben Adresse führt. Insgesamt sollte das richtig sein B96...255(KEC(ECDSARECOVER(h(T),Tw,Tr,Ts))) == B96...255((KEC(ECDSAPUBKEY(pr))), oder? @Ismael
Ja, das ist richtig, KEC=KECCAK256 ist eine Hash-Funktion, die nur Bits der Eingabe verschlüsselt und immer 256 Bit zurückgibt, aber sie kann keine Eindeutigkeit garantieren.
Was meinen Sie mit "Eindeutigkeit kann nicht garantiert werden", basierend auf den richtigsten 160 Bits seiner Ausgabe? @Ismael
Siehe hier en.wikipedia.org/wiki/Hash_function . Eine Hash-Funktion ist wie ein Fingerabdruck der Eingabedaten, sie kann nicht garantieren, dass sie für jede Eingabedaten eine andere Ausgabe erzeugt. Wenn die Ausgabe beispielsweise 32 Bytes groß ist, haben Sie 2 ^ (32 * 8) verschiedene Ausgaben, aber wenn Sie Daten eingeben, die 64 Bytes sind, haben Sie 2 ^ (64 * 8) verschiedene Eingaben. Aufgrund des Dirichlet-Prinzips haben mindestens zwei Eingaben die gleiche Ausgabe (dies wird als Hash-Kollision bezeichnet).
Diese Absprachen können also auch auf Ethereumt stattfinden, richtig? wobei mehrere öffentliche Schlüssel mit derselben Ethereum-Adresse @Ismael verknüpft sein können