Comprender un contrato en línea sin código de bytes EVM disponible

¿Alguien podría arrojar algo de luz sobre el siguiente contrato?

https://etherscan.io/address/0x27d6c4cb2551799a143e1a3291ae002b8c8aa078#código

Estoy bastante confundido acerca de lo que está pasando aquí. ¿Por qué no aparece el "código de bytes EVM" del contrato etherscan.io? ¿O es porque se ha autodestruido o algo así?

Cualquier sugerencia sería muy apreciada.

Respuestas (1)

De hecho, falta el código fuente ya que etherscan no puede vincularlo fácilmente.

Si cambia a OPCODE View, encontrará lo siguiente:

PUSH20 0x273930d21e01ee25e4c219b63259d214872220a2
PUSH2 0x235a
GAS
SUB
CALLCODE

A juzgar por el momento en que se implementó el contrato y el código que está usando ( CALLCODE ), podemos determinar que en realidad está delegando su almacenamiento y ejecución a otro contrato.

https://etherscan.io/address/0x273930d21e01ee25e4c219b63259d214872220a2#código

Ahora tiene la ABI real y el código fuente que puede usar para crear llamadas en su contra.

En estos días, en lugar de CALLCODE, usamos DELEGATECALL para tales casos.

Espero que ayude.

¡Gracias Micky! Eso tiene mucho sentido para mí. Solo una pregunta rápida, entonces, en lugar de "arreglar" la dirección del código delegado, ¿es posible hacerla dinámica?
Entonces, lo que quiero decir es que, dado este contrato, dado que envía su funcionalidad a otro contrato, me gustaría vincularme con ese contrato y hacer un análisis. Si la dirección de "ese contrato" está codificada, entonces supongo que es factible vincular. De lo contrario, si se determina dinámicamente, supongo que no tendré forma de hacerlo.
1 - Para el análisis y el uso, piense en este contrato, como un "proxy" que solo delega llamadas al contrato maestro. En esencia, no necesita saber cuál es la "dirección del maestro" porque el niño sabe y transfiere las llamadas internamente. En este caso, está codificado de forma rígida debido a la forma en que se creó (lo más probable es que sea una Biblioteca).
2 - Hay implementaciones más avanzadas, que implementan la delegación de llamadas manualmente que PUEDEN tener un "maestro" dinámico, ya que lo almacenan en una variable, en cuyo caso puede determinar cuándo cambia. Probablemente debería leer sobre DELEGATECALL y los contratos inteligentes actualizables, así como blog.zeppelinos.org/proxy-patterns
¡Muy interesante análisis! ¿Y cómo lograron tener el ABI en lugar del código fuente en etherscan?
@rick-park si observa más de cerca la página de etherscan, dice "Contrato ABI (utiliza datos ABI del contrato 0x86018025a553d3e88b38dc5409e4b52edeb9ab83)", eso sugiere que lo detectó de alguna manera o que alguien agregó manualmente el ABI en ese contrato en un momento :). Dado que el "Contrato de escritura" se agregó hace solo unos meses, y no funciona aquí, es lógico que la interfaz ABI del contrato se haya agregado hace bastante tiempo.
Gracias Micky. No se como conseguir esto. tratare de entender mas
Comprender un contrato en línea sin código de bytes EVM disponible
RespuestasAquíPolítica de privacidad1y, 0v