檢查該區塊的時間戳是否大於前一個區塊的時間戳並且距離未來不到 2 小時？
我正在閱讀乙太坊的白皮書。而在Mining Section，我不明白以下句子的“未來不到 2 小時”這部分：
檢查區塊的時間戳是否大於前一個區塊的時間戳，並且距離未來不到 2 小時。
而且，這裡還有一個我不明白的註釋：
2. 從技術上講，前 11 個區塊的中位數。
只是為了補充羅布的答案……
我在不同的地方將這個“2小時”描述為不同的時間長度，所以我會加一點鹽。（例如，這裡是 900 秒，也就是 15 分鐘。）
請注意，在黃皮書中，沒有這個強加的時間限制。唯一的規定是目前時間戳大於父塊的時間戳。
4.4.4. 塊頭驗證
(48) Hs > P(H) Hs
此外，從 Geth 程式碼來看，目前尚不清楚是否施加了接近此限制的任何內容。（相關程式碼
verifyHeader()在consensus.go。）似乎強加的只是允許網路中不同節點之間的時鐘漂移，這裡只允許 15 秒的差異。（巧合地類似於塊時間？不確定。）
如果一個新區塊的時間戳與目前時間相比大於 15 秒（不是父區塊的時間戳——我們在這裡沒有提及區塊時間），那麼它會被暫時標記為無效。一旦目前時間在此未來時間戳的 15 秒內，它將被標記為有效（並允許導入）。
因此，如果礦工故意創建一個帶有錯誤未來時間戳的區塊，該時間戳比這更遠，它將被標記為無效（儘管只是暫時的）。這種臨時無效將使其他礦工有機會使用真實時間戳探勘他們自己版本的區塊，從而使作弊礦工的區塊（實際上）永久無效。
（相關：“ #15629在確定未來塊時放寬要求”。）
- 從技術上講，是前 11 個區塊的中位數。
不確定這一點。
礦工
timeStamp用每個發現的區塊記錄一個區塊。如果不參考我們不想要的準確的外部時間源，觀察者無法確認或反駁這個值。時間戳有兩種檢查方式。首先，時鐘不應該跳到未來太遠，因為由於區塊發現的可預測速度，這極不可能。有關實際含義和實現細節的有趣討論，請參見下面的連結。
其次，時鐘不能倒轉，因此新區塊的時間戳應該總是在鏈中前一個區塊的時間戳之後。
這裡有一個關於乙太坊時間戳的有趣執行緒：合約可以安全地依賴 block.timestamp 嗎？
希望能幫助到你。