¿Es Solidity block.number más seguro que la marca de tiempo?

En Solidity, algunas propiedades pueden ser block.timestampatacadas por mineros y no están (fuertemente) protegidas por el protocolo. ¿Qué tal block.numbersi un minero podría introducir un número alto al azar?

EDITAR: Estoy pensando en asegurar un juego que facilite acciones como un pago, después de que haya transcurrido un cierto período de tiempo.

Si estamos hablando de horas o días y solo queremos saber si el tiempo ha pasado o no, no creo que haya ningún beneficio de seguridad significativo al usar números de bloque en lugar de marcas de tiempo de bloque. Sin embargo, si el tiempo está destinado a dar a las personas la oportunidad de reaccionar ante algo que sucede mediante el envío de transacciones, por ejemplo, para desafiar una acción propuesta, es posible que también desee incluir un número de bloque en caso de que suceda algo extraño en la red. . Creo que está en el límite si el valor de esto vale el costo de seguridad de la complejidad adicional.
Tenga en cuenta que la block.timestampespeculación generalmente no tiene garantía. block.timestampes muy seguro en escenarios de la vida real. block.timestampes seguro para el 99% de los casos de uso. Si tiene miedo del problema de la delantera, entonces usar block.numberno lo resuelve realmente. Si tiene miedo de que los mineros se metan con su transacción, entonces tiene una vía de otros vectores de ataque que el uso block.numberno resuelve.

Respuestas (1)

El número de bloque siempre será correcto por definición: es el número x en la cadena, porque está encadenado encima de x-1.

Sin embargo, como usted dice, block.timestampse puede jugar un poco, o con la cooperación de la mayoría económica de los nodos de validación, lo que también significa que la relación block.numbercon el tiempo real se puede jugar. Entonces, si no confía en que el block.timestamp01-01-2017 será realmente aproximadamente el 01-01-2017, tampoco puede confiar en contar los bloques que se supone que se extraerán entre ahora y el 01-01-2017.

PD. Es posible que las personas puedan brindarle consejos más útiles si nos dice para qué propósito quiere estar seguro y contra qué quiere estar seguro.

No entiendo So if you don't trust that a block.timestamp of 2017-01-01 will really be approximately 2017-01-01, you can't rely on counting the blocks that are supposed to be mined between now and 2017-01-01 either.: si mi juego comienza en el bloque número 1M y debería durar 100 bloques hasta el pago, entonces podría verificar si ya llegamos al bloque 1'000'100. Estoy aquí confiando en el algoritmo de consenso de que el tiempo intermedio fue de 100 * 14 s y no solo en un solo minero.
El algoritmo de consenso evita que los bloques retrocedan o estén más adelantados que el tiempo actual. Y cualquier minero honesto puede adelantarlo en el momento adecuado. Por lo tanto, no debería estar muy lejos sin mucha colaboración minera. Si hay muchas travesuras de mineros con el tiempo, esto también afectará la reorientación, por lo que el intervalo de bloqueo no será confiable de 14 segundos.
Para mayor claridad, permítanme reformular: sin una colaboración significativa, los mineros no pueden influir en cuándo aparecerá el bloque número X en la red. Por lo tanto block.number, es significativamente más seguro que block.timestampel que puede ser manipulado (hasta cierto punto) por un solo minero. Dado que el tiempo de bloqueo no es constante, esta es, sin embargo, solo una solución viable si no se necesita el tiempo exacto. ¿Correcto?
Esto no está del todo bien. El minero puede influir en cuándo aparecerá el bloque número X en la red: puede retener los bloques que ha extraído hasta más tarde, o puede activar más mineros para que las cosas vayan más rápido durante un tiempo. (por ejemplo, si tiene un ETC de minería de fragmentos, cambiarlo a ETH temporalmente es casi gratis). Es cierto que block.timestampse puede manipular fácilmente sin costo dentro de la ventana del bloque (es decir, si extrajo 15 segundos después del último bloque, podría fingir que como 3 segundos después del último bloque), pero la precisión que pierdes con este ataque ya se pierde si estás usando la altura del bloque.
Mi sugerencia sacada de mi trasero, sin comprometerme con las matemáticas, sería que desea usar la altura del bloque (o ambos, si necesita tiempo humano) para números pequeños como 10 bloques, porque si han transcurrido menos bloques, nada la cadena de bloques puede decirle que el tiempo es confiable. Para días y semanas debe usar block.timestampsi lo que le interesa es el tiempo humano para averiguar algo a través de los canales sociales, o altura de bloque si lo que le interesa es la capacidad de enviar una transacción a través de un proceso automatizado, o ambos si le interesa ambas cosas. 100 bloques se siente un poco límite.
Muy bien, gracias por la aclaración. Por cuánto un minero realmente puede modificar la marca de tiempo es otro tema que deberíamos discutir en otro hilo. Creo que esto no es tan obvio (blanco vs papel amarillo vs geth).
@Sebastian El protocolo no tiene un límite de cuán alta puede ser la marca de tiempo, pero es poco probable que otros mineros construyan sobre ese bloque: ethereum.stackexchange.com/questions/5927/…
¿Es Solidity block.number más seguro que la marca de tiempo?
RespuestasAquíPolítica de privacidad1y, 0v