schnorr & Taproot

两项旨在改善比特币签名过程的新提议即将出台。

在本文中,会以最通俗易懂的形式解释 schnorrTaproot 这两种技术。

先来介绍其背景信息:

要使用比特币,用户必须证明拥有特定UTXO的私钥。

为了证明所有权,比特币钱包同时使用交易数据和私钥来创建加密签名。

该签名用于证明事务的合法性,而无需公开其所关联的私钥。

换句话说,用户可以花费比特币,而不用担心有人会看到私钥,从而偷走资金。

签名技术在隐私和可扩展性等方面仍然有改进的空间,借此引入 Schnorr, MASTTaproot

以上阐述了单个签名在使用比特币时的应用。

显然也存在多签名事务,花费资金需要使用一组特定数量的私有密钥来构造签名,

另外还有时间锁,在指定的时间到期之前不能花费资金。

这些条件是由redemption脚本定义的,它们本质上是向事务添加额外规则的代码,并且可以增加验证过程的复杂性。

举个例子,脚本中可能包含一个条件,要求Alice等待一周才能使用她的比特币。

更复杂的脚本可能包含两个条件,要求Alice必须等待一个星期,以及她的丈夫Bob提供一个签名才能使用比特币。

目前,当发送比特币时,这些脚本以一长串随机数的形式提交给区块链,称为哈希。

对于脚本中的所有条件,一个哈希就像一个指纹,直到比特币的所有者把它们花光,整个脚本的信息才被揭露,以允许第三方验证所有权。

对于脚本,主要存在两个问题:

  • 脚本的复杂度以及事务的数据大小,是事务费用增加的主要因素
  • 当脚本的条件被公开时,即使那些没有被满足的条件也会被暴露

在上面的例子中,如果Alice在没有Bob签名的情况下等待了一周才发送资金,验证者可以看到等待Bob签名也是一种选择——这就暴露了Alice使用的是多签名钱包。

如果签名技术可以“升级”,Merkelized抽象语法树结构更加优化,使得只有被满足的脚本条件才会在比特币被花费之后披露出来,这通过将哈希嵌套在一个默克尔树的哈希中来实现。

以上面的多条件场景为例——Alice必须等待一周才能签署事务,并且Bob必须提供签名。

对于MAST,如果Alice等了一周才签名,但没有与Bob联合签名,验证过程将只显示已完成的条件是时间锁,没有人会知道Alice 使用的是多签名钱包。

MAST嵌套哈希加强了事务的隐私性,而 Schnorr签名通过为复杂脚本提供更大的隐私性和效率来改进MAST。

Schnorr签名有两个主要优点: 签名聚合隐藏密钥对

 

Schnorr允许将多个签名和公钥组合成一个签名或公钥,使其与单签名事务难以区分,这称为阈值签名和阈值公钥。

如果Alice和Bob一起在事务上签名,验证者无法知道其有多个签名。

Schnorr还将允许对公钥和私钥进行修饰以进行伪装。事务、脚本或签名没有任何变化—只有键的可视方式发生了变化。
以Aaron van Wirdum为例,他的处理方法如下:

1)私钥和对应的公钥同时乘以2

2)[私钥x 2]和[公钥x 2]仍然对应,[私钥x 2]仍然可以对可以用[公钥x 2]验证的消息进行签名

如果脚本要求Alice和Bob等上一周才能花费比特币,那么如果双方都同意的话,更快地进行交易是不是更有意义呢?

使用Taproot,事务可以包含一个脚本条件,参与者在其中执行此操作,可以令合作结束,这只是Taproot的第一个好处。

Taproot基于阈值签名使协作结束看起来像单个签名事务。

然而,使用这些资金通常还有其他条件,但不会显示这些条件,而是将它们组合成一个单独的脚本。

然后,使用Schnorr技术对该脚本进行哈希并用于隐藏阈值签名。

与前面的[公钥x 2]不同,它看起来更像[阈值公钥x脚本],其中未被满足的条件修改阈值公钥。

验证者仍然将其视为具有普通旧签名的普通旧密钥。然而,如果未达到协作关闭的条件,验证者会看到公钥被调整。为了防止拒绝该事务,将原始的阈值公钥和脚本暴露出来,以证明其与事务的关联。那么所有那些未满足的条件都被公开了。

Taproot 可以解决这个问题。
主节点不使用脚本修改阈值公钥,而是使用MAST结构的Merkle根,即 [阈值公钥x Merkle根]。

因此,像MAST一样,花费比特币时只需要披露被满足的花费条件。

Taproot和Schnorr尚未在比特币上激活。

目前,这两项功能都集中在一个由多个比特币核心贡献者支持的提案中,Schnorr作为一个软分叉协议升级正在开发中。

Leave a Reply

Your email address will not be published.

当前无网络链接