Contratos inteligentes y la falta de seguridad inherente al confiar en el código de bytes compilado

Se compilan contratos inteligentes en la cadena de bloques. ¿Existe algún sistema para verificar que todos los contratos públicos de dapp hagan lo que se proponen hacer?

es decir, esto podría hacerse mediante la compilación de contratos de código abierto y la verificación de las firmas hash del contrato, o en el caso de d-apps públicas pero de código cerrado, potencialmente descompilar el código de bytes compilado y verificar las rutas de código/llamadas a funciones, aunque este es un territorio mucho más turbio .

Consulte, por ejemplo , https://etherscan.io/address/0xf97e0a5b616dffc913e72455fde9ea8bbe946a2b#code , que es el algoritmo de "combinación de genes" de CryptoKitties. Mientras que el resto de CryptoKitties es de código abierto, este módulo de código en particular es de código cerrado. Sin embargo, se ha realizado ingeniería inversa: aquí hay una publicación de blog al respecto, https://medium.com/@sean.soria/cryptokitties-mixgenes-function-69207883fc80 . Si bien esta es una función de código pequeño, parece existir la posibilidad de que se inicie una dapp, proponiendo y pareciendo a primera vista ser de código abierto, pero de hecho contiene una bomba de tiempo oculta, por ejemplo, para transferir el saldo de Ether a la cuenta de un mal actor en una fecha futura codificada.

¿Necesitamos que se establezca algún marco o servicio mediante el cual todo el código de contrato inteligente publicado pueda validarse hasta cierto punto?

Respuestas (2)

esto podría hacerse mediante la compilación de contratos de código abierto y la verificación de las firmas hash del contrato

Eso es más o menos lo que Etherscan ya hace. ¿Conoce las capacidades de Etherscan aquí? ¿Estás proponiendo algo más de lo que ya hace Etherscan?

Para los contratos inteligentes que no tienen un código fuente publicado, simplemente no confíes en ellos. (O confíe en ellos si es capaz de auditar el código de bytes directamente, lo que diría que muy pocas personas pueden hacer).

Bien, acabo de encontrar etherscan.io/verifyContract . Esto es parte del camino allí. Pero tome el ejemplo de CryptoKitties: innumerables miles claramente confían en el código de contrato no publicado (de hecho, ni siquiera saben qué significan "código de byte" y "compilación"). Esto es un problema eh..
¡Supongo que estoy proponiendo algo para resaltar siempre que haya un código no verificable en la cadena de bloques!
Si alguien confía en un contrato sin leer el código fuente, realmente no importa si ese código está disponible o no. (La disponibilidad del código no hace que el contrato sea más confiable). Etherscan es el estándar de facto para encontrar el código fuente que acompaña a un contrato, así que creo que ya tenemos la herramienta que necesitamos aquí. El resto se trata solo de la educación del usuario, y eso va a ser una gran batalla cuesta arriba. :-)
Etherscan no ayuda cuando la fuente no está disponible. ¿Sería posible lanzar una ICO con una bomba de tiempo oculta y hacer que los usuarios compren antes de que un profesional de seguridad audite el código? Estoy pensando que podría existir un servicio que monitoree de manera proactiva la cadena de bloques en busca de fuentes no verificables (o hashes que no coincidan), podría usar Etherscan, pero Etherscan no crea conciencia de manera proactiva con alertas.
Si alguien quiere ver el código, puede hacerlo y, si no está allí, sabe que no se publicó (en Etherscan). ¿Cómo sería una versión "proactiva"? ¿ Decirle a la gente sobre la falta de código fuente antes de que lo busquen?
Sí, exactamente, porque obviamente la mayoría de los usuarios no saben nada sobre cómo verificar el código fuente. Piense en la alerta de seguridad en las barras de direcciones del navegador si el certificado de un sitio es sospechoso. Ver mi comentario anterior; "¿Sería posible lanzar una ICO con una bomba de tiempo oculta y hacer que los usuarios compren antes de que un profesional de seguridad audite el código?"
Si un usuario no está mirando el código fuente, no importa si se ha publicado o no. Si están mirando el código fuente, entonces no necesitan nada "proactivo". (Verán que falta el código fuente tan pronto como intenten leerlo). Por lo tanto, no estoy seguro de qué grupo de personas recibe ayuda de algo que aparece en cualquier lugar que no sea donde se supone que debe estar el código fuente.

[E]sto podría hacerse compilando contratos de código abierto y verificando las firmas hash del contrato, o en el caso de d-apps públicas pero de código cerrado, potencialmente descompilando el código de bytes compilado y verificando las rutas de código/llamadas a funciones, aunque esto es mucho territorio más turbio.

Si usa el compilador solcque compila el código de solidez, puede compilar el código fuente que el editor del contrato afirma que representa un contrato en la cadena de bloques. Debe usar el compilador con la bandera --bin-runtimepara obtener el código que se colocará en la cadena de bloques si compila y publica el código fuente en cuestión. Eche un vistazo a esta respuesta: solc bin vs. bin-runtime

Luego puede comparar el código binario que solcdevuelve con el código devuelto por la llamada en geth eth.getCode(contractaddress)(esta llamada devuelve el binario que está almacenado en la dirección contractaddress. Este es el código EVM del contrato colocado en la cadena de bloques). El código binario de estas dos operaciones debe coincidir.

Como dices, también puedes familiarizarte con el código de la máquina virtual que compilan los contratos de Ethereum y que se llama EVM. Si lo hace, podrá leer el contenido de los contratos directamente desde la cadena de bloques. El Libro Amarillo es un buen recurso si desea aprender EVM.

Contratos inteligentes y la falta de seguridad inherente al confiar en el código de bytes compilado
RespuestasAquíPolítica de privacidad1y, 0v