Creo que esta es una pregunta muy simple, pero no pude encontrar una respuesta directa en la documentación o en Google. Soy nuevo en Solidity/Ethereum y tal vez todavía no entiendo completamente algunos conceptos básicos.
Entonces, usemos un código simple como este
contract StrangeToken {
uint256 private repurchasePrice;
mapping(address => uint256) balances;
function setPrice(uint256 price) {
repurchasePrice = price;
}
}
Cualquiera puede llamar a setPrice()la función para establecer una repurchasePricevariable. Supongamos que hay miles de usuarios y setPrice()se llama cada minuto o incluso más a menudo y el valor se establece en un número aleatorio.
La pregunta es: ¿qué tan difícil es predecir y/o influir en el valor del precio de recompra para los bloques futuros/próximos más cercanos?
Según tengo entendido, ethereum no necesariamente mantiene una secuencia de llamadas, por lo que no existe una posibilidad práctica de cronometrar la llamada, por lo que el atacante debe ser al menos un minero, no un usuario común. Pero las posibilidades de los mineros en esta zona no me quedan del todo claras.
¡Gracias!
No estoy seguro de entender completamente tu pregunta, pero creo que entiendo la esencia.
Con la función de acceso público que permite a cualquiera cambiar el número, no hay una forma obvia de predecir el próximo número confirmado porque el orden de la transacción no se establece hasta que se extrae un bloque. El ganador siempre será la transacción extraída más reciente.
Todos pueden ver a los candidatos como transacciones pendientes (con vistas algo diferentes de los pedidos debido a la latencia de la red).
Cociné un ejemplo ligeramente modificado que podría ayudar a ilustrar lo que está pasando.
pragma solidity ^0.4.13;
contract NotSoSecret {
bytes32 public secretHash;
// put some money in with a hashed secret
function deposit(bytes32 _secretHash) public payable returns(bool success) {
secretHash = _secretHash;
return true;
}
// if you know the magic word, you get the pot
function claim(bytes32 password) public returns(bool success) {
if(sha3(password) == secretHash) {
msg.sender.transfer(this.balance);
return true;
}
return false;
}
}
Parece que debería funcionar, pero no lo hará. depositacepta fondos y un hash. Parece que uno necesita saber la contraseña para reclamar el botín.
En realidad, lo que sucederá es que alguien que sepa passwordenviará una transacción claimy esa transacción no confirmada se transmitirá a la red (los mineros y los nodos completos se enterarán).
Eso animará una carrera, porque todos verán la contraseña. Entonces, cuando un atacante usa ese conocimiento para hacer su propia transacción (para reclamar la recompensa por sí mismo), tendrá (aproximadamente) 50/50 de probabilidades de éxito. ¿Por qué detenerse en un intento? El contrato podría ser bombardeado con reclamos una vez que se revele el secreto.
Espero eso ayude.
La pregunta es: ¿qué tan difícil es predecir y/o influir en el valor del precio de recompra para los bloques futuros/próximos más cercanos?
Según tengo entendido y la forma en que recibo su pregunta, la predicción del valor de repurchasePrice no tiene nada que ver con la solidez o el ethereum en sí, pero los beneficios que obtendrá un usuario al establecer el precio allí, significa que debe buscarse en un aspecto económico más que un aspecto técnico.
por lo tanto, el atacante debe ser al menos un minero, no un usuario común. Pero las posibilidades de los mineros en esta zona no me quedan del todo claras.
Desde la perspectiva de un minero, la tarea principal es encontrar un hash válido según la dificultad del tiempo de minería. Si trató de transmitir un bloque con transacciones no válidas (digamos para atacar su contrato), cuando se valide, dado que la transacción no es válida, el bloque que extrajo será rechazado.
Entonces, la forma de atacar su contrato es enviar una transacción válida pero explotando una laguna de su contrato. Entonces, lo que puede hacer es seguir las mejores prácticas para desarrollar contratos seguros. Puede consultar los enlaces: los documentos de soldadura y esta publicación escribiendo solidez segura .
El ataque DOA es un buen ejemplo de por qué debe escribir códigos de solidez seguros sin permitir que otros exploten su contrato para su beneficio.
Achala Dissanayake
Achala Dissanayake