Wie behalten Ethereum-Mining-Knoten eine Zeit bei, die mit dem Netzwerk übereinstimmt?

Ethereum-Knoten (unabhängig vom Mining) müssen eine genaue Zeit haben, sonst können sie sich nicht mit Peers und dem Netzwerk verbinden ( https://github.com/ethereum/go-ethereum/wiki/Connecting-to-the -Netzwerk ).

Kleine Zeitunterschiede werden von den Knoten toleriert, aber wenn sich die Zeit eines Knotens weiter von der koordinierten UTC-Zeit (per NTP ) entfernt, verringert sich die Anzahl der Peers und schließlich hat er null Peers und wird vom Netzwerk getrennt.

Ein Bergmann M möchte eine Zeit haben, die mit dem Netzwerk übereinstimmt, damit andere Bergleute auf den Blöcken aufbauen, die M abbaut.

Blöcke müssen innerhalb einer angemessenen Unix-Zeit liegen, ansonsten ist es unwahrscheinlich, dass Miner auf Blöcken mit unangemessenen Zeitstempeln aufbauen. ( Beispiel )

BEARBEITEN: Zur Verdeutlichung ist in Ethereum die einzige Regel zu Zeitstempeln, dass der Zeitstempel größer als der vorherige Zeitstempel sein muss . Es gibt keine andere Regel : Alte Dokumente wie das Whitepaper und Wiki können 15 Minuten (900 Sekunden) erwähnen, und hier sind die Korrekturen:

Weißes Papier :

Überprüfen Sie, ob der Zeitstempel des Blocks größer ist als der des referenzierten vorherigen Blocks und weniger als 15 Minuten in der Zukunft liegt

Wiki :

Ist block.timestamp <= now + 900 und ist block.timestamp > parent.timestamp? (streng größer)

Leider wurden die veralteten, falschen Informationen von anderen wie hier und hier aufgegriffen .

Das Yellow Paper ist die formale Spezifikation und siehe Block Header Validity (Abschnitt 4.4.4, Gleichung 48).

Hier ist der Code, den ich bisher gefunden habe und der sich mit der Synchronisierungszeit befasst. Es wird pool.ntp.org:123als Zeitsynchronisierungsquelle verwendet.

Von Go Ethereum - p2p/discover/ntp.go, Zeilen 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)
    }
}

Von Go Ethereum - p2p/discover/ntp.go, Zeilen 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
}

Go Ethereum - p2p/discover/ntp.go, Zeilen 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
)

Und driftThreshold = 10 Sekunden von p2p/discover/udp.go, Zeile 57

Wenn die hartcodierte pool.ntp.org einer langen und anhaltenden DDoS- oder DNS-Cache-Poisoning unterzogen wird, werden die Ethereum-Knoten schließlich nicht mehr synchronisiert. Aber es wird lange dauern, bis die Mining-Computer um mehr als 10 Sekunden driften. Und die Ethereum-Entwickler würden bis zu diesem Zeitpunkt einen neuen Fix herausbringen.

TL;DR: Blöcke müssen innerhalb einer angemessenen Unix-Zeit sein oder sie werden zurückgewiesen.

Im gelben Papier heißt es:

timestamp: Ein skalarer Wert gleich der angemessenen Ausgabe von Unix's time() zu Beginn dieses Blocks; formal H _s .

Das Whitepaper sagt:

Der grundlegende Blockvalidierungsalgorithmus in Ethereum ist wie folgt:

• [...]
• Überprüfen Sie, ob der Zeitstempel des Blocks größer ist als der des referenzierten vorherigen Blocks und weniger als 15 Minuten in der Zukunft liegt