JOVANA
Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
Back to the library
區塊鏈 1991

如何為一份數位文件蓋上時間戳

斯圖爾特·哈伯 與 W. 斯科特·斯托內塔

把每條記錄的雜湊鏈向前一條,誰都無法偷偷改寫過去。

Choose your version
In depth · the introduction

當任何人都能在電腦上悄悄改掉日期、甚至連那個蓋戳的服務方自己都可能作弊時,你要如何證明一份數位文件在某一天就已經存在?

核心想法

一份紙質文件,可以靠墨水、紙張、汙漬來判定日期——這些物理線索,事後很難偽造。一份數位文件卻什麼都沒有:複製它、編輯它、把時鐘一改,便不留痕跡。哈伯與斯托內塔的洞見在於:你必須為資料本身蓋戳,而不是為它所棲身的介質蓋戳。

他們的妙招是:當你想給一份文件蓋戳時,你並不把它交出去。你算出它的一小段密碼學「指紋」——也就是雜湊——只把這段指紋發出去。服務方簽下一張小小的證書,說明它在何時收到了你的指紋;而最關鍵的是,它把剛剛為你前一位客戶簽發的那張證書的指紋,也摺了進來。於是每一張證書,都被焊死在它的前一張上。要偽造任何一條記錄的日期,偽造者就得把其後的每一條記錄統統重做一遍——而別人手裡早已握著這些記錄的副本。過去,就此被鎖定。

它是如何誕生的

1980 年代末,斯圖爾特·哈伯與斯科特·斯托內塔是紐澤西州貝爾通信研究院(Bellcore)的研究員。斯托內塔一直在為一個非常實際的問題發愁:當科學走向電子實驗記錄本,一位研究者——比方說,在一場專利糾紛裡——又該如何證明自己究竟知道了什麼、在什麼時候知道,倘若那些記錄不過是一份可隨意編輯的文件?誠實的答案是:你證明不了,至少不可靠。

身為密碼學家的哈伯看出,這個補救之道必須來自數學,而不是來自對某個權威時鐘的信任。兩人一同構造了一套方案,讓信任來自結構本身。他們於 1991 年發表了它,又創立了一家名為 Surety 的公司去出售它;而為了讓自己的鏈無法被改寫,他們開始把每一週所有蓋戳的一個彙總指紋,作為一則小小的廣告,登在《紐約時報》上。自 1995 年起,它每週如期刊出。

它為何重要

這,就是雜湊鏈——每一條區塊鏈在結構上的心臟。許多年後,比特幣那位匿名作者,正是直接建立在這一想法之上,並引用了哈伯與斯托內塔的論文。一條區塊鏈,歸根結底,恰恰就是他們的構造:每個區塊都雜湊它的前一個,於是關於過去的記錄無法被悄然編輯。比特幣所添的,是讓一群沒有中央權威、互不相識的陌生人就這條鏈達成一致的辦法;但那道防篡改的脊梁,早已在這裡——在一篇 1991 年、從頭到尾根本沒提過錢的密碼學論文裡。

一個可以想像的畫面

想像一本有人見證的日記,每一條新的記載,都必須先用本人的筆跡,把上一條記載結尾的幾個字抄下來作為開頭。現在,你試著往中間塞進一頁偽造的。它的結尾,對不上下一頁真頁早已抄下的那幾個字——而那一頁的結尾,又對不上再下一頁,如此一路下去。要偽造一頁,你就得把這本日記其後的全部內容重寫一遍,而每一位見證人手裡,都攥著一份影印件。這條把指紋一路向前抄錄的鏈,正是哈伯與斯托內塔用雜湊所造出來的東西。

一條由五張時間戳證書組成的可互動鏈,每張都顯示它的時間、客戶,以及前一張證書的彩色指紋。滑桿可把其中一張證書重蓋到另一份偽造文件上;它的指紋隨之改變,它之後的每一張證書都變紅、斷裂。

它的位置

這篇論文,立在「信任」這件事歷史的一個樞紐上。在它之前,為一條記錄定日期,意味著信任一位公證人、一家銀行,或一座政府的時鐘。哈伯與斯托內塔則展示了:一個共同體,如何能用一種自我核驗的結構,去替換那份信任。這條線索一路向前——穿過 Surety 登在報紙上的雜湊,穿過程式設計師每天都在用的 Git 那防篡改的提交歷史,再穿過比特幣以及其後的種種區塊鏈——它們當中的每一個,都安放在這條 1991 年「用雜湊把記錄鏈接起來」的想法之上。

The original document
Original source text

摘要——為資料、而非介質蓋戳

Stuart A. Haber, W. Scott Stornetta · Bellcore, 445 South Street, Morristown, N.J. · Journal of Cryptology 3 (1991): 99–111
The prospect of a world in which all text, audio, picture, and video documents are in digital form on easily modifiable media raises the issue of how to certify when a document was created or last changed.
The problem is to time-stamp the data, not the medium.
We propose computationally practical procedures for digital time-stamping of such documents so that it is infeasible for a user either to back-date or to forward-date his document, even with the collusion of a time-stamping service. Our procedures maintain complete privacy of the documents themselves, and require no record-keeping by the time-stamping service.

導言——為日期作證

§1 · Introduction
In many situations there is a need to certify the date a document was created or last modified.
[Paper documents can be dated by forensic signs in the medium; digital data has no such physical trace. A digital time-stamping scheme must instead bind the date to the bits of the document, while revealing nothing about the document's contents — the service should never need to see the document, only a hash of it.]

鏈接式解法(雜湊鏈)

§4 · A first solution — linking
A client computes a hash y = h(D) of the document D and sends only y to the time-stamping service (TSS). For the n-th request the TSS issues a signed certificate that records the sequence number, the time, the client's identifier, and the hash — together with linking information that ties this certificate to the previous one.
[In our notation the certificate is C(n) = (n, t(n), ID(n), y(n); L(n)), where the linking information L(n) = (t(n−1), ID(n−1), y(n−1), H(L(n−1))) carries a hash of the previous certificate's link. The hash values of documents submitted to the service are thereby chained together in a linear list into which nothing can feasibly be inserted or substituted, and from which nothing can feasibly be deleted.]
Anyone challenging the time on a certificate can ask its issuer to produce the certificates of the clients who came just before and just after; the temporal order is enforced by the chain itself, so the service cannot back-date a document without rewriting every certificate that followed.

分散式信任(隨機見證人解法)

§5 · A second solution — distributed trust
[In the random-witness solution, several members of the client pool must date and sign the hash value; their signatures form a composite certification that the time-stamp request was witnessed. These witnesses are chosen by a pseudorandom generator seeded with the hash of the document itself, which makes it infeasible to deliberately choose which clients will and will not act as witnesses — so no single service need be trusted.]
Stuart A. Haber · W. Scott Stornetta · Bellcore · 1991