先建应用还是先搭平台？加密世界发展中鸡和蛋问题的终极解答

2016年 8 月份，联合广场基金 USV 分析师 Joel Monegro 发表了一篇名为「胖协议」的文章，指出在分布式网络中，价值通常在协议层，而非构建于协议层之上的应用程序。这篇文章被众多区块链投资人奉若圭臬，也推动了大量投资流向区块链基础设施项目。但是，如果只关注基础设施建设，而忽视应用的开发，对整个分布式网络生态系统的发展并无益处。联合广场基金两位员工 Dani Grant、Nick Grossman 刚刚发表了一篇文章，通过大量例子，旗帜鲜明的指出：新技术的历史表明，应该先有应用程序，因为应用程序会催生基础设施。他们还提出了「应用程序=>基础设施=>应用程序=>基础设施」迭代循环周期，指明开发者应该遵循这样的周期，把握住这个循环周期中的不同机会。链闻 ChainNews 获得了联合广场基金授权，翻译了这篇文章，发表中文版本，希望借此帮助读者理顺「应用程序和基础设孰先孰后」这个一直困扰加密世界的蛋生鸡、鸡生蛋难题。不过需要读者注意，作者在文章中也特别指明：文章中提出的循环周期模型解释了什么时候可以开发搭建应用程序或基础设施，这是从开发者和项目建设者的视角着眼，这一理论并不解释什么时候投资应用程序、什么时候投资基础设施。

Web 3.0 社区的一个常见说法是，我们正处于基础设施阶段，现在应该做的是构建基础设施：我们需要更好的基础链、更好的链间互操作性、更好的客户端、钱包和浏览器。

这种说法背后的思路是：首先我们需要工具，以便轻松构建和使用在区块链上运行的应用程序，一旦拥有了这些工具，我们就可以开始构建应用程序了。

但当我们与正在构建基础设施的创始人交流时，我们不断听到他们说，自己面临的最大的挑战，就是让开发人员在其基础设施顶层构建应用程序。

如果我们现在真的处于应该兴建基础设施的阶段，为什么会出现这样的情况呢？

我们只好据此假设：事情并不是按原有构想那样发展的。我们目前并不处在基础设施阶段，而是处于应用程序-基础设施周期的另一个转折点。

事实上，新技术的历史表明，应用程序会催生基础设施，而不是反之。我们并不是必须先得建立所有的基础设施，在有了需要的基础设施后才开始构建应用程序。

情况恰恰相反。

这一点居然值得讨论，其中一个重要原因在于，现在人人都知道「平台」通常是最大的价值机会，尤其对 Facebook、Amazon/AWS、Twilio 等而言，确实如此。因此，人们自然会急于建立一个重要的平台来攫取价值。在分布式网络中，这一点可能尤其正确。因为在分布式网络中，价值通常 不过并不总是 在协议层，而非位于顶层的应用程序中累积。

但是，正如我们将会看到的那样，平台是从这样一个迭代周期中演化而来：应用程序=>基础设施=>应用程序=>基础设施。平台极少在外部真空中构建。

首先，应用程序赋予了基础设施灵感。接着，基础设施为新的应用程序带来赋能。

我们在最重要的平台看到的变迁模式是，首先出现一个突破性的应用程序，然后该应用激发了一个构建基础设施的新的阶段，令人们更容易在其基础上构建类似的应用程序，便于消费者广泛采用这些应用。

情况有点像下图这样的发展模式：

应用程序和基础设施是在响应周期里不断演进，而不是相互独立、各自为政。

打比方说，灯泡 应用程序 是在有电网 基础设施 之前发明的。不是非得有电网才能安灯泡。但要让消费者广泛接受灯泡，你确实需要电网，所以突破性的应用，也就是灯泡，在 1879 年率先诞生，而后电网于 1882 年开始逐步发展。

再举一个例子：飞机 应用程序 是机场 基础设施 出现之前发明的。 飞机并不是非得有机场才行。但是为了广大消费者接受飞机，确实得有机场配套，所以作为突破性应用的飞机在 1903 年首先出现，激励人们在 1919 年开始建立航空公司，1928 年建造机场，到了 1930 年开始出现空中交通管制——这些基础设施都出现在飞机之后。

有时候你需要的基础设施无非是一片海滩和一些备件而已。

互联网也遵循同样的模式。

先说首批应用程序：即时短信 1970 年 和电子邮件 1972 年，它们促成了便于消费者广泛采用短信和电子邮件的基础设施，即以太网 1973 年、TCP/IP 1973 年 和互联网服务提供商1974 年。

接着是下一波应用程序浪潮，也就是门户网站 1990 年的 Prodigy，1991 年的 AOL，它们进而启发我们建构了新的基础设施 1990 年代初的搜索引擎和网络浏览器。

再接下来的应用程序浪潮中，出现的是像亚马逊 1994 年 这样的早期网站，激励我们搭建编程语言 1994 年的 PHP，1995 年的 Javascript 和 Java 等基础设施，以简化网站构建。

往后是下一波更复杂的应用，如 Napster 1999 年、Pandora 2000 年、Gmail 2004 年 和 Facebook 2004 年，而这催生的是可以更轻松地构建复杂应用的基础设施 2004 年有 NGINX 和 Ruby on Rails，2006 年出现了 AWS。

这样的周期还在继续。

我们在最新的移动应用中也看到了这种模式：首先出现了一系列非常依赖流媒体视频的流行移动应用，如 Snapchat 2011 年、Periscope 2014 年、Meerkat 2015 年 和 Instagram Stories 2016 年。现在，我们看到一些公司正在建设基础设施，以便移动应用程序轻松添加视频：Ziggeo 2014 年、Agora.io 2014 年、Mux 2017 年、Twilio Video API 2017 年 和 Cloudflare Stream 2018 年。

这个周期也合理地解释了 Web 3.0 事件的顺序。

我们从第一个突破性的应用程序开始说起：比特币出现于 2008 年，这激发了一些便于开发应用的新基础设施，如以太坊智能合约 2015 年；以及便于消费者广泛采用这些新应用的基础设施，如 Coinbase 2012 年 和 Metamask 2016 年。

这一新的基础设施催生了下一波应用：代币/ICO 2017 年 和早期的 DApp 2016 年是 Rouleth 和 vDice，2017 年有加密猫，而这又进而激发出了新的基础设施，如 Infura 2014 年 和 Web3js、Zeppelin 和 ERC20 2017 年。

目前，我们正在等待下一批重大的应用程序来引导下一波基础设施建设。

邻近的可能

开发每个重要平台 电力、汽车、飞机、网络、移动设备等 的共同主题是，我们构建的是当下能为我们自己所用的工具。在《好点子从何而来》 Where Do Good Ideas Come From 一书中，史蒂文·约翰逊 Steven Johnson 将其称为「相邻可能」。

换句话说，你可以打开通往隔壁房间的大门，但是你不能在前门那里越过台阶，打开后院的大门。如果构建的基础设施远远超前于应用程序市场，这样很难成功。

每当应用程序=>基础设施这个周期再现，新的应用程序就会成为可能，这是因为在之前的循环中已构建了基础设施。例如，YouTube 可以在 2005 年建成，但在 1995 年显然没法实现，因为只有在 2000 年代初宽带等基础设施部署之后 YouTube 才有意义，而宽带能应运而生，原因在于 eBay、亚马逊、AskJeeves 和 Neopets 等受欢迎的网站诞生，催生了之后的基础设施阶段。

区块链投资基金 a16z crypto 的 Chris Dixon 和 Fred Wilson 在最近一期的博客节目中，谈到了这个理念。

Chris 有一款来自互联网泡沫时代的棋盘游戏，叫「dot Bomb」，游戏嘲笑了 20 世纪 90 年代末那批愚蠢的互联网公司。他指出，网络时代所有「愚蠢」的想法现在都演化成了价值 10 亿美元的独角兽公司。现在可能出现的情况是，出现多个应用程序=>基础设施循环，而只有一两个应用程序=>基础设施周期没有多少意义。

这就是我们所谓的「基础设施阶段迷思」的关键所在。

如果我们在考虑一个「基础设施阶段」的时候，完全将它与要使用它的应用程序割裂开来，就有可能面临在抽象的真空中布局、步伐过于超前的风险。我们需要「应用程序=>基础设施=>应用程序=>基础设施」这样的循环，来保持步伐的稳健。

随着每个新平台的周期越来越长，构建和使用这些应用程序的成本越来越低。如果是在 1995 年建设 usv.com 这个网站，花费的成本会比如今多出很多个数量级；而如果是在 15 年后创建 Web 3.0 应用，花费的金钱、精力和时间都会比现在少很多。

开发框架VS投资框架

站在我们投资者的立场上想想就知道，区分技术框架和投资框架是很重要的，前者解释了何时可以构建什么，后者解释了何时适合投资什么。

应用程序=>基础设施=>应用程序=>基础设施这个循环解释了什么时候可以构建应用程序或基础设施，但并不一定能解释什么时候投资应用程序、什么时候投资基础设施。

让我们以灯泡为例。是的，灯泡是在电网出现之前发明的，但从投资者的角度来看，在电网建成之前，没有人卖出很多灯泡。

让我做一个总结

我们先前遇到的一个问题是：为什么应用程序在周期中首先出现，而不是基础设施？

一个原因是，除非出现了应用程序，召唤你解决其基础设施问题，否则凭空创建基础设施是没有意义的。在没有一个相关的应用程序团队之前，如何能知道你正在构建的基础设施能解决一个真正的问题？所以说，现在构建加密基础设施将是一大挑战，只有等到有一天，出现一个突破性的加密应用程序令其他开发人员争相效仿，并呼唤更好的开发工具和基础设施来实现这一目标，双脚才能踏到实处。

在加密领域中有这样一种说法，首先我们需要构建出色的工具，一旦有了工具，就可以构建应用程序。

但我们希望指出的是，从其他平台的变迁来看，我们可以在出色的工具出现之前，先尝试开发几个应用程序，尽管这需要更多的资金和时间，然后，这些早期的应用程序将激发我们构建工具。

这个循环将不断重复。