¿Cómo mantienen los nodos de minería de Ethereum un tiempo consistente con la red?

Los nodos de Ethereum (independientemente de la minería) deben tener una hora precisa; de lo contrario, no podrán conectarse a sus pares ni a la red ( https://github.com/ethereum/go-ethereum/wiki/Connecting-to-the -red ).

Los nodos toleran pequeñas diferencias en el tiempo, pero a medida que el tiempo de un nodo se aleja más de la hora UTC coordinada (por NTP ), su número de pares se reducirá y eventualmente tendrá cero pares y se desconectará de la red.

Un minero M quiere tener un tiempo consistente con la red, para que otros mineros construyan sobre los bloques que M extrae.

Los bloques deben estar dentro de un tiempo razonable de Unix; de lo contrario, es poco probable que los mineros se basen en bloques con marcas de tiempo irrazonables. ( Ejemplo )

EDITAR: Para mayor claridad, en Ethereum, la única regla sobre las marcas de tiempo es que la marca de tiempo debe ser mayor que la marca de tiempo anterior . No hay otra regla : los documentos antiguos, como el libro blanco y la wiki , pueden mencionar 15 minutos (900 segundos), y aquí están las correcciones:

Libro blanco :

Verifique que la marca de tiempo del bloque sea mayor que la del bloque anterior al que se hace referencia y menos de 15 minutos en el futuro

wiki :

¿Es block.timestamp <= now + 900 y es block.timestamp > parent.timestamp? (estrictamente mayor)

Desafortunadamente, la información incorrecta y desactualizada ha sido recogida por otros, como aquí y aquí .

El papel amarillo es la especificación formal y ver Validez de encabezado de bloque (sección 4.4.4, ecuación 48).

Aquí está el código que he encontrado hasta ahora que se ocupa de la sincronización del tiempo. Se utiliza pool.ntp.org:123como fuente de sincronización de tiempo.

De Go Ethereum - p2p/discover/ntp.go, líneas 48-65 :

func checkClockDrift() {
    drift, err := sntpDrift(ntpChecks)
    if err != nil {
        return
    }
    if drift < -driftThreshold || drift > driftThreshold {
        warning := fmt.Sprintf("System clock seems off by %v, which can prevent network connectivity", drift)
        howtofix := fmt.Sprintf("Please enable network time synchronisation in system settings")
        separator := strings.Repeat("-", len(warning))

        glog.V(logger.Warn).Info(separator)
        glog.V(logger.Warn).Info(warning)
        glog.V(logger.Warn).Info(howtofix)
        glog.V(logger.Warn).Info(separator)
    } else {
        glog.V(logger.Debug).Infof("Sanity NTP check reported %v drift, all ok", drift)
    }
}

De Go Ethereum - p2p/discover/ntp.go, líneas 73-127 :

func sntpDrift(measurements int) (time.Duration, error) {
    // Resolve the address of the NTP server
    addr, err := net.ResolveUDPAddr("udp", ntpPool+":123")
    if err != nil {
        return 0, err
    }
    // Construct the time request (empty package with only 2 fields set):
    //   Bits 3-5: Protocol version, 3
    //   Bits 6-8: Mode of operation, client, 3
    request := make([]byte, 48)
    request[0] = 3<<3 | 3

    // Execute each of the measurements
    drifts := []time.Duration{}
    ...
    // Calculate average drif (drop two extremities to avoid outliers)
    sort.Sort(durationSlice(drifts))

    drift := time.Duration(0)
    for i := 1; i < len(drifts)-1; i++ {
        drift += drifts[i]
    }
    return drift / time.Duration(measurements), nil
}

Vaya a Ethereum - p2p/discover/ntp.go, líneas 33-36 :

const (
    ntpPool   = "pool.ntp.org" // ntpPool is the NTP server to query for the current time
    ntpChecks = 3              // Number of measurements to do against the NTP server
)

Y driftThreshold = 10 segundos desde p2p/discover/udp.go, línea 57

Si el pool.ntp.org codificado de forma rígida se somete a un envenenamiento de caché de DNS o DDoS prolongado y sostenido, los nodos de Ethereum eventualmente no se sincronizarán. Pero las computadoras de minería tardarán mucho tiempo en desviarse más de 10 segundos. Y los desarrolladores de Ethereum tendrían una nueva solución para ese momento.

TL; DR: los bloques deben estar dentro de un tiempo razonable de Unix o serán rechazados.

El papel amarillo dice:

marca de tiempo: un valor escalar igual a la salida razonable de time() de Unix al inicio de este bloque; formalmente _Hs .

El libro blanco dice:

El algoritmo básico de validación de bloques en Ethereum es el siguiente:

• [...]
• Verifique que la marca de tiempo del bloque sea mayor que la del bloque anterior al que se hace referencia y menos de 15 minutos en el futuro