La gente usa este contrato todos los días http://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol y también es el contrato con la mayoría de ethereums en este momento.
También puede crear una cuenta multisig en la billetera oficial de Ethereum utilizando este código fuente de contrato.
Pero luego, cuando entro al sitio https://etherscan.io/address/0xab7c74abc0c4d48d1bdad5dcb26153fc8780f83e#code , tenemos todas estas advertencias que indican que la seguridad es baja.
Advertencia: el contrato compilado puede ser susceptible a ZeroFunctionSelector (gravedad muy baja), DelegateCallReturnValue (gravedad baja), ECRecoverMalformedInput (gravedad media), SkipEmptyStringLiteral (gravedad baja), IdentityPrecompileReturnIgnored (gravedad baja), HighOrderByteCleanStorage (gravedad alta) ), SendFailsForZeroEther (gravedad baja), DynamicAllocationInfiniteLoop (gravedad baja), CleanBytesHigherOrderBits (gravedad media/alta) Errores del compilador Solidity.
¿Cómo debo usar esto como inversionista (y programador que no ha aprendido completamente Solidity)? Por supuesto que escuché el exploit Parity que les dio a los piratas la libertad de tomar solo 30 millones de dólares.
Mi pregunta es: ¿Debería preocuparme ? ¿ Y con qué debo tener cuidado y prestar atención ?
ACTUALIZAR:
Te entiendo, pero puedo ver la solidez básica y no puedo ver ninguna función "interna" o "guardias" que parity haya puesto en acción después de su exploit.
Pero aquí tengo un análisis más profundo del simulador de remezcla de solidez que indica las vulnerabilidades de reingreso: https://imgur.com/a/d3x8J
ACTUALIZACIÓN 2:
¡Dijiste que la versión más alta del compilador es mejor, así que todos los contratos que usan ese código (que dije que es el que se usa en la billetera Ethereum) usan la versión 0.3.2! 0.3.2! Que es del 2016!
Todo el ecosistema Ethereum se encuentra en las etapas iniciales. Los errores son de esperar, pero por supuesto no deben tolerarse si se trata de grandes cantidades de dinero.
Básicamente, existen dos tipos de vulnerabilidades que pueden permitir el robo de fondos:
errores del programador
Por ejemplo, la vulnerabilidad de reingreso solía ser un lugar común. La mayoría de los desarrolladores de DApp hoy en día son conscientes de esto y no cometerán ese error.
Hoy en día la mayoría de los errores son específicos de la lógica de una determinada aplicación. La única forma de estar seguro de que no hay ninguno es mediante una verificación formal, una revisión exhaustiva del código y/o una prueba de tiempo y dinero.
errores del compilador
Estos son errores cometidos por los desarrolladores de los compiladores de Solidity. Son prácticamente imposibles de detectar para los desarrolladores de DApp o hacer algo al respecto.
Una vez que se ha compilado un contrato inteligente con un error y se ha implementado en la cadena de bloques, el error permanece. El despliegue del contrato es definitivo.
Es importante tener en cuenta que el hecho de que un compilador tenga un error no significa en absoluto que todos los contratos compilados con ese compilador tengan un error. Los errores de los compiladores solo tienen un efecto negativo en situaciones excepcionales. (de lo contrario, se habrían detectado hace mucho tiempo, antes de que se lanzara la versión del compilador que contiene el error)
No debes prestar demasiada atención a todas las advertencias que da etherscan.io. Simplemente miran qué versión del compilador se usó y brindan una lista de todos los errores conocidos para esa versión del compilador. En realidad, no hacen un análisis profundo de cada contrato. Lo más probable es que el contrato que está viendo no se haya visto afectado por esos errores.
Es una buena idea aprender Solidity al menos en un nivel básico, y solo leer el código para ver que no se cometieron errores obvios. Los errores como la vulnerabilidad de reingreso son bastante fáciles de detectar. Además de eso, debe verificar si hay errores lógicos en la programación de la aplicación específica que está viendo.
Algunos consejos generales:
Una versión superior del compilador es, en general, menos riesgosa.
Los contratos con código fuente revisado son en general menos riesgosos.
Los contratos más cortos son en general menos riesgosos.
Los contratos que han existido durante mucho tiempo, han manejado grandes cantidades de dinero y no han sido pirateados son, en general, menos riesgosos.
Desafortunadamente, no se pueden hacer garantías sobre todos los contratos.
Espero que esto ayude un poco.
Esta es una buena respuesta de @Jesse Busman, pero como puede ver, el compilador de solidity establece una posible vulnerabilidad de reingreso; sin embargo, esto es solo a través de un análisis estático y el compilador no busca modificadores. Aquí hay una función vulnerable de reingreso, pero que es segura:
function reEnterMe(uint256 etherAmt) onlyOwner {
if (balances[owner] >= etherAmt){
owner.send(etherAmt);
balances[owner] -= etherAmt;
}
}
Dado que el contrato envía ether ANTES de restarlo del mapeo de saldos [propietario], esta función se puede volver a ingresar.
Sin embargo, el modificador onlyOwner evita que CUALQUIER PERSONA, excepto el propietario, llame a este contrato, o se cancelará. Por lo tanto, esta función es relativamente segura, porque ¿quién querría volver a entrar en su propio contrato?
jonathan lindgren