Louis:

Bnews 本次专访邀请章鱼网络创始人 Louis,Louis是机制设计和加密货币市场资深研究者,比特币早期投资者。本次专访围绕应用链、多链、Octopus2.0、DePIN 等热门话题展开。

1.您认为 Appchain 如何确保安全性?

Appchain 的安全性问题一直都是个痛点。自己做 PoS 确实能够保证安全性,但这是一个传统的思路,并且经过实践证明,独立的 PoS 是最贵的。为了维持链的基本安全可能要每年增发5%-10%的通证。这会给 Appchain 带来非常沉重的成本压力,反映在市场上就是 Token 的持续卖压。

如果使用共享安全性的机制,每年只需要增发1%-2%的代币即可保证链的安全性,而且获得的安全等级可能要远远高于独立 PoS。为什么会有这个五倍的效率提升?为什么很多应用链还没有开始使用共享安全?我认为是一个观念上的转换,多数应用类开发团队对共享安全性还是不够了解。还有一些团队认为,如果 Token 不做 Staking,就没有了价值。但未来市场会给出一个选择,就是作为应用链 Token 应该有应用价值,能够从应用层经济系统里面捕获价值。如果代币只是为了保证链的安全,而应用没有人使用,那就是一个无用的通证。

现在应用链共享安全有多个选项,包括最早的 Polkadot 的插槽拍卖、Cosmos 的复制安全和 Octopus 的租用安全。我认为租用安全最灵活、可及性最好,不需要通过全生态的支持就可以启动链,安全水平只取决于提供的通证奖励数量。一开始可能只有十几个验证人提供几百万美金的安全,但随着使用量的增长,代币的价格在增长,Incentive 的水平也会自然增长,相应的安全性也会水涨船高。

除了共享安全,现在还有另外一个思路,就是把 Appchain 当成 Rollup 来运行,锚定公链 L1 的安全,最主要是 Ethereum。这个问题比较复杂,但总体来说,应用 Rollup 技术的远远没有应用链成熟,最终它们可能会殊途同归。

2.对于 Infra 来说,Appchain 是否某种程度真正上能够做到将整个区块链互通有无?

在基础设施领域,应用链与公链的平衡问题是一直备受关注的话题。应用链并非是公链的替代品,公链也不可能完全取代应用链。因为在计算系统中,通用性和效率永远都需要平衡。

系统越通用,就越难以为特定的需求优化;反之,为某个特定需求做最优化设计,就自然会局限于这个场景,丧失一定的通用性,这就是一个基本的矛盾。因此对于一个应用来说,可能会一开始选择公链。发展到一定程度,会有特定的需求,比如费用或用户体验等方面,公链有时候就无法满足,因为公链不可能为某个特定的应用做出改变。这时应用可能会选择从公链上迁移到应用链上,通过控制自己的 Layer1 实现深度优化。一个典型的例子就是 DYDX,它的 V4 版本选用 Cosmos 作为应用链。

应用链也有自己的难题。例如安全性需要从头开始维护,而且需要跨链,否则它就会成为一个孤岛。经过多链网络技术和跨链技术的发展,我们认为,目前已经有了很好的基础设施能力,可以支持应用链的持续发展。因此我预计未来会出现大量的应用链,它们将探索很多应用领域和 Web3 应用领域。这些应用链将通过安全的、功能强大的跨链协议相互连接成为统一的网络,也就是 Cosmos 在2015年就提出的区块链互联网愿景。

3.您如何看待未来多链互联与多 Rollup 互联之间的争议?

我首先澄清一个问题,Rollup 是区块链,只是目前 Rollup 没有通过去中心化共识来出块。如果依赖中心化的排序器,就会丧失区块链的一些基本特性,例如拜占庭容错的 Liveness 和 Censorship resistance。因此,为了实现去中心化的 Rollup,就需要很多节点来充当 Sequencer ,并且这些节点应该是 Permissionless 的,最可能的方式是使用 PoS 网络。另一方面, PoS Appchain 为了获得更高的安全性,可以把区块发布到 DA layer,并把交易摘要提交给做 Settlement 的公链。

大家想想看,上述两种架构,虽然一个是 App Roll-up ,一个是 Appchain,但有什么本质性的区别吗?这就是所谓的殊途同归,殊途同归核心原因在于,在模块化区块链的世界里,Web3基础设施面临的问题相同,最佳的可用技术也一样。

4.V神之前提到市场基于 ETH2.0 提出的一些思路可能会稀释 ETH 共识,您对此怎么看?

我非常关注V神发表的博客和推特并参与了一些讨论。为什么管他叫V神呢?因为他确实非常有前瞻性。他会为未来几年的重要问题做基础工作,理清一些基本概念,并进行深入的讨论,这些都是长远的问题。

V神提出不要过载以太坊社会共识。直白地说,就是 Code is law,智能合约代码解决应用层的所有问题、处理自己的规则,不需要社会共识解决争议,尤其是不要把争议扩大到整个以太坊社区。

防止社会共识过载是未雨绸缪。目前好像没有重要的以太坊项目依赖社会共识来解决的争议。因为依赖社会共识本身就是不好的设计,协议本身应该是自洽的。V神提出的问题和观点非常重要,且具有一定的前瞻性。

5.你在赛道切入方向基于什么样的想法?

一些 Web3 的应用更适合在应用链上运行。我们一直关注着非 DeFi 应用,因为 DeFi 通常依赖于共享流动性,以及与其他协议的组合。非 DeFi 应用,例如链游、创作者经济,以及最近兴起的 DePIN,我们都非常关注。尤其是 DePIN,我们认为是还没有充分探索的领域。它的基本思想是通过协议发行代币,然后通过众包的方式,无需许可参与,来建立服务网络。使用者通过协议使用网络服务,服务提供者和整个网络都受益,这样就可以跳过公司的组织形式。DePIN是否能够成立,取决于协议能否协调散在的服务提供者,形成可靠的服务网络;通过协议协调是否比由中心化的公司来协调、构建和运营网络更有效率,这些问题尚无答案,需要具体分析具体情况。

DePIN 正在计算存储、无线通讯、能源网络、传感器网络等领域进行探索。我们希望章鱼网络为 DePIN 的应用链做一些特定的服务,如代币经济的设计,或者提供通用模块,帮助早期项目更快地构建网络、形成服务能力。

6.在整个行业 Token 这块,您觉得如何平衡项目方、市场和 VC 之间的关系?

首先我要说的是关于 Token 本身的定义和在 Web3 中的位置,这个问题目前还存在很激烈的争议。在我的观点中虽然加密协议网络可以有多种 Token,但基本上都会有一个主要的原生 Token 或治理 Token。原生 Token 实际上是加密协议网络的所有权凭证。

所有权主要包含两个方面的权利。一方面是收益权,也就是通过加密网络的运行,内置的价值捕获机制将使这些 Token 增值。另一方面是治理权,即通过原生 Token 或其衍生 Token,社区可以加权决定协议网络的演进方向。有人可能会说,如果这样定义 Token,它就是证券。我个人认为这是无法避免的。监管需要随着 Web3 经济现象而进化。几年前赫斯特·皮尔斯的安全港提议为 Token 发行方提供豁免期,以适应新的所有权分配机制。如果为了适应现有的监管扭曲 Web3 Token 经济实质,恐怕未来的弯路会越走越大。

假设我们同意 Token 是加密协议网络的所有权凭证,那么在协议设计时,就必须考虑到网络中有不同类型的利益相关者,即不同角色的参与者,在他们当中通常只有一种角色是长期的网络所有者,即 Owner 角色。例如在双边市场型的 Web3 网络中,服务提供商应该是 Owner,例如去中心化 B2C 网络,商家应该是 Owner;去中心化的打车链,则司机应该是 Owner;去中心化创作者经济网络,则创作者应该是 Owner。确定 Owner 的目的是在协议中尽可能多地把 Token 发给 Owner。

除了 Owner 之外,通常网络还需要其他类型的贡献者才能运行,例如开发者、项目方、社区和机构投资者等等。如果有了 Owner 的概念,我认为其他贡献方的 Token 奖励都应该被视为构建加密协议网络所必需的成本。对其他贡献方的激励设计的思路是:如何用最少的 Token 换取足够多的贡献,以满足早期构建和冷启动的需求。例如在应用链安全是一种成本,应该考虑如何尽量降低安全成本,同时获得足够的安全性。如果 Owner 概念出错,那么就会产生很大的问题,例如一个打车应用链使用独立的 PoS,每年增发10%的 Token 给验证人,最终很可能验证人的治理权超过了司机的治理权。

总之,如果我们将 Token 视为加密协议网络的所有权凭证,那么在协议设计之前,要确定所有者角色。将其他贡献者,包括团队和投资者,视为供应商。

7.现在很多 DePIN 项目的经济学参考了 Helium 的双代币 Burn-Mint 模型,引入 Data Credits 或者其他积分,目前看来是相对健康的,可以聊聊这种模型的潜在风险吗?

你提到的 BME 模型是一种燃烧铸造均衡模型,其优势主要有两点,一是法币计价降低了交易成本,二是协议收入 Burn 和协议成本 Mint 分开,非常清晰,方便各类角色进行评估和参与。

BME 模型也存在两个潜在的风险。首先 Burn 依赖价格预言机,因此面临预言机攻击风险,第二点是关于均衡。当 Token 价格下降,Service Provider 收益降低,运营效率低的 Provider 会首先退出。然后,运行效率高的 Provider 分到更多的 Token,从而达到盈亏平衡。相当于是在 Token 价格下降的时候淘汰了低效的 Service Provider,完成系统的新陈代谢。然而需要注意的是,如果大量 Service Provider 退出,可能会损害网络的服务能力,让系统走入死亡螺旋。

免责声明:本文仅供参考,不得被用作法律、税务、投资、理财或任何其他建议。