本文出自創投 USV ，2018 年的文章 The Myth of The Infrastructure Phase，原本的用途是作為解構 Web3 ，Crypto 世界的應對之策，雖然我現在認為 Web3 是 AI 才對，但不妨礙本文的啟發重點，請注意網路以及行動網路發展的週期性。本文由 AI 翻譯，些許編修。
Web3 社群的一個常見說法是，我們正處於基礎設施階段，現在要做的正確的事情是構建基礎設施：更好的基礎鏈，更好的鏈間互操作性，更好的用戶端，錢包和瀏覽器。理由是：首先，我們需要能夠輕鬆構建和使用在區塊鏈上運行的應用程式工具，一旦我們有了這些工具，我們就可以開始構建這些應用程式了。
但是，當我們與正在構建基礎設施的創辦人交談時，我們不斷聽到他們面臨的最大挑戰是讓開發人員在上面構建應用程式。現在，如果我們真的處於基礎設施階段，為什麼會這樣？
我們的假設是，事情實際上並非如此。我們不是處於基礎架構階段，而是處於應用程式基礎架構週期的另一個轉捩點。事實上，新技術的歷史表明，應用程式會產生基礎設施，而不是相反。並不是說我們首先構建了所有的基礎設施，一旦我們有了所需的基礎設施，我們就開始構建應用程式。恰恰相反。
為什麼這是一個議題的大一部分原因是，現在每個人都知道“平臺”通常是最大的價值機會（Facebook、亞馬遜/AWS、Twilio等都是如此） — — 所以自然會急於建立一個捕捉價值的主要平臺。 在分散式Web中可能更是如此，因為價值通常（但並非總是）在協定層而不是位於頂部的應用程式中累積。
但是，正如我們將看到的：平臺是從apps=> infrastructure=> apps => infrastructure的反覆運算迴圈演變而來的，很少是在外部真空中構建的。
First, apps inspire infrastructure. Then that infrastructure enables new apps.
首先，應用激發基礎設施的靈感。然後，該基礎結構將啟用新的應用程式。
我們在主要平台轉變的事件序列中看到的是，首先有一個突破性應用程式，然後這個突破性應用程式激發了一個階段，在這個階段中，我們構建了基礎設施，使構建類似的應用程式變得更加容易，以及允許消費者廣泛採用這些應用程式的基礎設施。有點像這樣：
例如，燈泡（應用程式）是在電網（基礎設施）出現之前發明的。你不需要電網有燈泡。但是要讓消費者廣泛採用燈泡，你確實需要電網，所以作為燈泡的突破應用程式首先出現在 1879 年，然後是 1882 年開始的電網。
另一個例子：飛機（應用程式）是在機場（基礎設施）出現之前發明的。你不需要機場來擁有飛機。但是要讓消費者廣泛使用飛機，你確實需要機場，所以作為飛機的突破性應用程式在 1903 年首次出現，並激發了一個階段，人們在 1919 年建立了航空公司，在 1928 年建立了機場，並在 1930 年建立了空中交通管制，直到有飛機之後。
網際網路也遵循相同的模式。我們從第一個應用程式開始：傳訊（1970年）和電子郵件（1972年），然後啟發基礎設施，使消費者更容易廣泛採用傳訊和電子郵件：乙太網路（1973年）、TCP / IP（1973年）和網路服務提供者（1974年）。然後是下一波應用程式，它們是入口網站（1990年的Prodigy，1991年的AOL），入口網站激勵我們構建基礎設施（1990年代初的搜尋引擎和Web瀏覽器）。然後是下一波應用程式，它們是早期的網站，如 1994 年的 Amazon.com，這引導我們構建程式設計語言（1994 年的 PHP、1995 年的 Javascript 和 Java）等基礎設施的階段，這使得構建網站變得更加容易。然後是下一波更複雜的應用程式，如Napster（1999）、Pandora（2000）、Gmail（2004）和Facebook（2004），這導致了基礎設施，使得構建更複雜的應用程式變得更加容易（NGINX 和 Ruby on Rails 在2004年，AWS 在2006年）。 迴圈還在繼續。
我們在最近的行動應用程式反覆運算中也看到了這種模式：首先，我們有一套依賴串流媒體影片的流行行動應用程式：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 中的事件順序。我們從第一個突破性應用程式開始：BTC（2008），在比特幣網路之上（作為第一個基礎設施），緊隨其後的是絲路（2011年）作為最臭名昭著的早期加密應用程式。這激發了新的基礎設施，如側鏈和驅動鏈（2015），乙太坊智慧合約和ERC20（2015）、閃電網路（2015），使構建新應用程式變得容易，以及像Coinbase（2012）和Metamask（2016）這樣的基礎設施，使消費者能夠採用這些新應用程式。然後，這種新的基礎設施支援下一波應用程式：代幣/ ICO（2017）和早期的dapps（2016年的Rouleth和vDice，2017年的CryptoKitties），它們激發了新的基礎設施：Infura（2016）和Web3js和Zeppelin（2017）。我們現在正在等待下一個大型應用程式，這將有助於指導下一波基礎設施。
The Adjacent Possible 相鄰的可能
每個主要平臺（電力、汽車、飛機、網路、行動裝置等）開發的共同主題是，我們構建了我們目前可用的工具。 在《好的想法從何而來》一書中，史蒂文·詹森將其稱為“相鄰的可能性”。換句話說，你可以打開下一個房間的門，但你不能真正跳過台階，從前廊打開後門。 很難成功構建領先於應用市場的基礎設施。
每次應用程式 => 基礎結構週期重複時，由於在之前的週期中構建的基礎結構，新應用程式成為可能。例如，YouTube可以在2005年建立，但不能在1995年建立，因為YouTube只有在2000年代初部署寬頻等基礎設施之後才有意義，這發生在eBay、亞馬遜、AskJeeves和我最喜歡的Neopets等第一批熱門網站之後的基礎設施階段。
Chris Dixon 跟Fred Wilson 在最近一集的 a16z Podcast 中談論了這個概念。Chris 有一款來自網路時代的棋盤遊戲，名為 Dot Bomb，取笑 1990 年代後期愚蠢的網路漫畫。他指出，網路時代所有“愚蠢”的想法現在都是價值數十億美元的獨角獸。現在可能的幾個應用程式=>基礎設施週期進入網路是沒有意義的，只有一兩個應用程式=>基礎設施週期。
這就是我們所說的基礎設施階段神話的關鍵所在 — — 如果我們考慮一個與使用它的應用程式分離的“基礎設施階段”，我們就有可能在投機真空中建設得太遠。 我們需要應用程式=>基礎設施=>應用程式=>基礎設施的迴圈來讓我們保持實在。
隨著每個新平臺的週期越來越多，構建和使用這些應用程式的成本會降低。在 1995 年構建 usv.com 將花費我們比今天構建的成本高出許多數量級，而創建 Web 3.0 應用程式今天花費的現金、精力和時間比 15 年後要多。
Development Frameworks Versus Investing Frameworks
發展框架與投資框架
讓我們的投資者戴上帽子，重要的是要區分解釋何時可以構建某些東西的技術框架和解釋何時可以成為良好投資的投資框架。
應用程式=>基礎設施=>應用程式=>基礎設施周期解釋了何時可以構建應用或基礎設施，但不一定解釋何時投資應用，何時投資基礎設施。
以燈泡為例。是的，它們是在電網出現之前發明的，但從投資者的角度來看，在電網到位之前，沒有人賣很多燈泡。
Wrapping Up 總結
我們遇到的一個問題是：為什麼應用程式在週期中排在第一位，而不是基礎設施排在第一位？一個原因是，在有應用程式要求您解決其基礎架構問題之前，創建基礎架構是沒有意義的。你怎麼知道你正在構建的基礎結構解決了真正的問題，直到你有了要解決的應用團隊？現在構建加密基礎設施將是一個挑戰，直到有一個突破性的加密應用程式，其他開發人員想要模仿並且需要更好的開發工具和基礎設施來做到這一點。
加密領域有一種說法，首先我們需要構建出色的工具，一旦我們有了工具，我們就可以構建應用程式。但我們希望展示的是，在其他平台轉變中，我們能夠在有很棒的工具之前構建前幾個應用程式（儘管它需要更多的現金和時間），然後這些早期的應用程式激勵我們構建工具。迴圈往復。
