三分钟速览区块链今日好文：深度洞察 tBTC 运行机制，Placeholder 揭秘「Proof of Liquidity」

真本聪手记，每次精选 5 篇加密货币最新优质文章，一起洞察加密世界，今天内容包括：

1 WBTC 正在推动 DeFi 增长吗？
2 将 BTC 引入以太坊生态，深度洞察 tBTC
3 以太坊的 Gas 费实在是太高了！
4 Placeholder 揭秘「Proof of Liquidity」
5 LongHash：如何在比特币上打造高级智能合约？

1 WBTC 正在推动 DeFi 增长吗？

比特币拥有最庞大的市值和用户群体，尽管 RSK 等二层协议试图将智能合约引入比特币中，但进展甚微，同时主打跨链的 Cosmos 交付时间未知，目前「将比特币引入以太坊」的趋势越发明显（无论手段是中心化还是去中心化），已出现的产品包括：WBTC、imBTC、sBTC、pBTC 等，Andrew Kang 曾从「去中心化」与「扩容性」两个方面，分析主流跨链锚定 BTC 项目各自的利弊，强烈推荐该文！

@JimmyRagosa

在本文中 DappRadar 从数据出发，一窥由 BitGo、Kyber Network 与 Ren 等区块链项目联合推出的 WBTC 的使用情况。

在 2020 年，WBTC 市值增长了 192%，仅五月就增长了 24%，其中最大的需求来自 MakerDAO （占比 49%），这是因为 WBTC 于 5 月 3 日成为以太坊上最大 DeFi 应用 MakerDAO 的抵押资产，此前仅有三个选择：ETH、BAT 和 USDC。

除 MakerDAO 之外的用途分别为 Set Protocol、Compound、Aave 和 Uniswap （占比均在 5% 左右）。与此同时，WBTC 在 Uniswap、Kyber 等 DEX 中的相关交易对成交量也在持续增长。

原文链接

2 将 BTC 引入以太坊生态，深度洞察 tBTC

还有 tBTC。Formal Verification 的这篇文章深度介绍了 tBTC 的运行机制和关键的开放性问题。

为了确保任何一方无法控制存款地址的私钥，tBTC 使用了基于 MPC （Multi-Party Computation，多方计算） 的门限签名作为解决方案，MPC 的关键特征之一是：对基础信息进行了同态加密处理，确保当事方自己永远都不知道基础值或在任何时候都无法看到私钥。（真本聪备注：简单地说，MPC 将私钥分割成多份，需要持有部分私钥的多个签名者共同协作才能够完成交易，而签名者彼此是无法看到私钥或单独完成资产转移的）

铸造 tBTC 的流程如下：

• 用户请求存入自己的 BTC，以便在以太坊主网上得到相同价值的 tBTC；
• Keep 网络将通过 MPC 机制从所有可用的签名者中选择 3 个签名者；
• 相关签名者必须用 1.5 倍价值的 ETH 进行抵押（150% 超额抵押），BTC 和 ETH 存款地址的私钥由这三个签名者创建；
• 随后 TDT 用于铸造 tBTC，用户可以通过退还 TDT 并赎回他们的原始资金（备注：用户在赎回时必须向相应的签名者支付费用）

关键的开放性问题：

• 签名者是否愿意获得低于 2% 的收益率（即 2% 的收益率能否激励签名者贡献资源保护整个网络，特别是在 ETH 2.0 Staking 和多个 DeFi 项目的收益率都可能高于 2% 的情况下）？签名者最终会以机构的形式出现吗 ?
• 会迫使恶意签名者再次从市场上购买 Keep （Keep 网络的原生资产，一种工作型代币，质押 Keep 才能够成为 tBTC 的签名者）吗？Keep 的流动性将如何？
• tBTC 如何应对 ETH 闪崩？或 BTC-ETH 交易对中 BTC 汇率的持续走高？
• tBTC 如何从 ETH 1.0 过渡到 2.0？它会在两个系统中（同时）有效吗 ?
• V2 版本中可能还会添加哪些抵押资产种类？如何选择和评估它们的风险 ?
• tBTC 将如何应对其他的锚定解决方案，如 Thorchain 这样不需要抵押代币的跨链流动性池？

@BitcoinMemeHub

原文链接

3 以太坊的 Gas 费实在是太高了！

大多数「Web 3」创意都需要实现 Web 级别的扩展性，然后才能够提供可行的产品。区块链和去中心化非常酷，但是没有人愿意回到拨号上网的时代。

DeFi 不同，其用户并不满意缓慢的交易速度，但他们忍受了。借出或借入资产只需要进行少量交易；流动性资金池类型的 DEX 对不常使用的 DeFi 用户也很友好。

用户将接受缓慢的交易，但不会接受昂贵的交易，这是自 3 月 12 日市场暴跌以来不可避免的现实。

真本聪备注：这一点值得商榷，312 大跌已经证明了可扩展性在极端情况下的重要性，可扩展性甚至可能是「最弱的环节」，也就是说「如果最弱环节崩溃了，即便项目在其他方面的现状提升了『10 倍』也无济于事」。

随后作者回顾了 Gas 费持续上涨的事实：以现有的 Gas 价格（25 Gwei）计算，一个将资产存入 Compound 的简单交易将花费 $ 4.00。高昂的 Gas 价格使得 DeFi 除大型用户之外的用户都无法使用，因为交易费用并不随交易尺寸扩展（备注：应该是指无论交易多少金额，其 Gas 费用都是一样的，而这显然对大型用户更加有利）。

过去一个月内，Tether 向以太坊矿工支付了 120 万美元（Gas 费用），令人担忧的是，短期内该问题似乎没有希望解决，高昂的 Gas 费用可能会持续几个月。
一些可能的结果（即可能推进以下解决方案）：

• Layer 2：多个团队在开发 Layer 2 解决方案，但 Layer 2 可能将流动性吸纳到不同的 Layer 2 通道中，这可能破坏「可组合性」；
• Gas 优化：开发者已经发现了一些技巧和捷径来降低交易的资源消耗。诸如 Zapper 之类的交易打包商将更专注于提高主流 DeFi 协议的交易效率（备注：Zapper 可在一次交易中跨多个 DeFi 协议部署 ETH 以及即将支持的 DAI，也就是说在一笔交易中与多个协议交互）；同样，像 Argent 这样的智能合同钱包，可能不得不限制它帮助用户达成的交易次数（备注：Argent 没有助记词和 Gas 费用，使用「元交易」——元交易 Meta transaction，是让用户用自己的密钥来签名发起交易，但不需要用户来支付交易手续费，而由 「中继者（relay）」 来为 TA 支付 Gas 费——来达成较低的用户使用门槛）；
• EIP 1559 提案：该提案引发诸多讨论，主要内容包括：A）将区块 Gas 上限由 800 万调整到 1600 万；B）给每个区块都设定 BASEFEE （字面意义为「基本手续费」），在同一区块中打包的交易都以 BASEFEE 作为 Gas Price，并且，BASEFEE 会根据此前区块的 GAS 利用率动态调整，如果利用率低于 50%，则降低手续费，如果利用率高于 50%，则提高手续费；然而，这些手续费并不会交给矿工，而是会被协议销毁掉（burn）；C）除了由 BASEFEE 确定的手续费以外，用户还可以自定义给矿工的小费（tip）。

原文链接

4 Placeholder 揭秘「Proof of Liquidity」

Placeholder 的这篇文章令人激动，它甚至可能具备划时代的意义，标志着投资趋势的彻底变化，本文呼应了 上篇手记 所提到的「广义挖矿」和「参与治理」的概念：这一切都标志着我们从「买入即拥有」的世界进入「贡献即拥有」的世界。

在本文中，Placeholder 指出：在标准的 PoS 系统中，Stake 用户越多，非流通代币的数量就越多。这似乎有利于代币的价格，但在许多情况下，流动性不足可能会阻碍网络增长（流动性不足将导致价格变动剧烈从而抑制网络的经济行为）。

Placeholder 提出了「Proof of Liquidity」，用户向网络提供流动性帮助网络价值增长的同时，也将获得奖励。

这回到了 Placeholder 曾提到的「用户即矿工」模式，通过「 自 愿选择加入 」的经济锁定，将用户转变为利益相关者来构建加密应用的防御性。而在另一方面，这也将打击竞争对手的市场份额。

Balancer 协议的流动性池被设计成根据设定的指数持有一篮子代币。这些池中持有的代币可在 Balancer 去中心化交易所进行交易。当用户和合同在 Balancer 上进行交易时，协议会自动调整流动性池以维持其权重。当用户将资产注入到流动池中时，您会收到该流动性池中与出资金额成比例的 ERC-20 流动性提供者（LP）代币，这些代币可用于赎回用户在流动性池中贡献的基础资产的份额。

例如，如果流动性池被设定为 25％ETH 和 75％MKR，则流动性池中的代币（ETH 和 MKR）可用于市场交易。当用户与该流动性池进行交易时，或者这些资产的价值发生变化时，Balancer 协议通过自动买卖 MKR 和 ETH 来维持（原有设定的）比率。如果你通过 ETH/MKR 向池中提供 10％的流动性资金，你将获得该流动性池 10％的 LP 代币，它可以赎回 10％的基础资产……

原文链接

5 LongHash：如何在比特币上打造高级智能合约？

在本文中，LongHash 提到了一种全新的比特币编程语言 Simplicity，它试图在保证安全性的同时让比特币脚本更加变得灵活。虽然并非图灵完备，但对那些想要搭建以太坊上现有的大部分同类应用程序的开发者来说，Simplicity 的表达能力已足够丰富。

原文链接

本期真本聪手记到此结束，下次再见！

来源链接：realsatoshi.net