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