Verstehen Sie einen Online-Vertrag ohne verfügbaren EVM-Bytecode

Könnte jemand etwas Licht auf den folgenden Vertrag werfen?

https://etherscan.io/address/0x27d6c4cb2551799a143e1a3291ae002b8c8aa078#code

Ich bin ziemlich verwirrt darüber, was hier vor sich geht. Warum wird der "EVM-Bytecode" des Vertrags nicht auf angezeigt etherscan.io? Oder weil es selbst zerstört wurde oder so?

Jeder Vorschlag wäre sehr willkommen.

Antworten (1)

Der Quellcode fehlt tatsächlich, da Etherscan ihn nicht einfach einbinden kann.

Wenn Sie zu OPCODE View wechseln, werden Sie Folgendes finden:

PUSH20 0x273930d21e01ee25e4c219b63259d214872220a2
PUSH2 0x235a
GAS
SUB
CALLCODE

Dem Zeitpunkt der Bereitstellung des Vertrags und dem verwendeten Code (CALLCODE) nach zu urteilen, können wir feststellen, dass er seine Speicherung und Ausführung tatsächlich an einen anderen Vertrag delegiert.

https://etherscan.io/address/0x273930d21e01ee25e4c219b63259d214872220a2#code

Jetzt haben Sie die eigentliche ABI und den Quellcode, den Sie verwenden können, um Aufrufe dagegen zu erstellen.

Heute verwenden wir für solche Fälle statt CALLCODE DELEGATECALL.

Hoffentlich hilft das.

Danke Micky! Das ergibt für mich sehr viel Sinn. Nur eine kurze Frage: Anstatt die delegierte Codeadresse zu "reparieren", ist es möglich, sie dynamisch zu machen?
Was ich also meine, ist, dass ich angesichts dieses Vertrags, da er seine Funktionalität an einen anderen Vertrag weiterleitet, eine Verknüpfung mit diesem Vertrag herstellen und eine Analyse durchführen möchte. Wenn die Adresse "dieses Vertrags" fest codiert ist, ist es wahrscheinlich möglich, sie zu verknüpfen. Andernfalls, wenn es dynamisch bestimmt wird, habe ich wahrscheinlich keine Möglichkeit, dies zu tun.
1 - Stellen Sie sich diesen Vertrag für die Analyse und Verwendung als "Proxy" vor, der nur Anrufe an den Mastervertrag delegiert. Im Grunde brauchen Sie nicht wirklich zu wissen, was die "Master-Adresse" ist, weil das Kind Anrufe kennt und intern weiterleitet. In diesem Fall ist es aufgrund der Art und Weise, wie es erstellt wurde, fest codiert (höchstwahrscheinlich eine Bibliothek).
2 - Es gibt fortgeschrittenere Implementierungen, die die Anrufdelegierung manuell implementieren und einen dynamischen "Master" haben KÖNNEN, da sie diesen in einer Variablen speichern. In diesem Fall können Sie bestimmen, wann er sich ändert. Sie sollten sich wahrscheinlich über DELEGATECALL und aktualisierbare Smart Contracts sowie über blog.zeppelinos.org/proxy-patterns informieren
Sehr interessante Analyse! Und wie ist es ihnen gelungen, die ABI statt des Quellcodes auf Etherscan zu haben?
@rick-park Wenn Sie sich die Etherscan-Seite genauer ansehen, steht dort "Contract ABI (Uses ABI Data From Contract 0x86018025a553d3e88b38dc5409e4b52edeb9ab83)", was darauf hindeutet, dass es entweder irgendwie erkannt wurde oder jemand die ABI zu diesem Vertrag an einem Punkt manuell hinzugefügt hat :). Da der "Write Contract" erst vor ein paar Monaten hinzugefügt wurde und hier nicht funktioniert, liegt es nahe, dass die ABI-Schnittstelle des Vertrags vor einiger Zeit hinzugefügt wurde.
Danke Micky. Ich weiß nicht, wie man das bekommt. Ich werde versuchen, mehr zu verstehen