轉自公號：老雅痞
本文探討Web2 如何過度到Web3 生態系統的問題，以及身份如何在其中發揮重要作用。
我認為Web3 將會持續存在一段時間。我所說的Web3 是指優先考慮用戶選擇和所有權的哲學、概念和技術，並可用於建立去中心化的服務。區塊鏈（如Ethereum、Solana）、代幣、協議（如IPFS、TheGraph、Lit）、服務（如ENS、Filecoin）、dApps和用戶的密鑰構成了Web3（我在這裡並沒有列出一份詳盡的清單）。
我不清楚它會有多成功，而且我認為今天的一切都不會如此。但我認為它會成功。我相信它已經在某些方面取得了成功。
我還認為Web3 不是”唯一”存在的網絡。它將與Web2 共存，至少在若干年（幾十年）內。我不是唯一這麼認為的人。
在那之後，也許會出現另一種範式。作為一名開發人員，尤其是為其他開發人員構建產品的開發人員，我花了很多時間思考這意味著什麼。我認為以書面形式分享我的想法可能會很有趣。
這篇文章主要是為：
-
構建與 Web3 服務對話的 Web2 應用的開發人員
-
構建希望被 Web2 應用程序使用的 Web3 服務的開發人員
在這篇文章中，我鏈接了以太坊的文檔和概念，因為我對這些最熟悉，而且它是當今最大的開發者平台。類似的事情也適用於其他許多鏈。
使用 Web3 結構的 Web2 應用程序
Web2 應用程序可以通過Web3 構造增強用戶的體驗。
——Shopify正在潛心研究”tokengated commerce”，根據用戶的NFTs來定制購物體驗。這裡有一篇關於這個問題的非常清晰、深入的文章。代幣化商務是一個美妙的想法。你所擁有的東西說明了你喜歡的很多東西。根據你的NFTs定制購物體驗感覺很自然。 （
https://help.shopify.com/zh-CN/manual/products/digital-service-product/nfts）
——Twitter和Stripe正在合作，允許加密貨幣支付，使內容創作者很容易用加密貨幣獲得報酬。 （
https://stripe.com/blog/expanding-global-payouts-with-crypto）
——Reddit正在區塊鏈的基礎上建立其社區積分系統。 （
https://www.reddit.com/community-points/）
這些都是面向消費者的大型平台。他們沒有成為dApps，但他們正在涉足Web 3。
這對開發者意味著什麼？
開發者將需要弄清楚如何整合Web2 和Web3 的世界。我們已經開始看到這種情況以不同的方式出現，但創建開發者工具和基礎設施的公司正在探索和實施Web3 的整合。
-
Stripe正在建設 Web3 支付基礎設施（https://stripe.com/use-cases/crypto）
-
Auth0宣布支持Ethereum的登錄方式（https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/）
-
谷歌云正在組建一個 Web3 團隊
模式：這些建立Web2 開發基礎設施的大公司現在正在創建一些組件，使Web2 應用程序開發人員能夠輕鬆地與Web3 概念（NFTs、加密貨幣、ENS等）集成，而不需要全身心投入（即建立一個dApp）。
他們正在Web2和Web3世界之間建立一座橋樑。他們的橋接是關於允許Web2的開發者與Web3的結構進行互動，這也是這篇文章的重點。
橋接的另一個方面是讓Web2的數據對Web3的開發者可用。如果這篇文章引起開發者的興趣，我可能會就此再寫一篇博文。
Web3 的信任模式
Web3的理念是去中心化。每個用戶都擁有他們的數據，他們的$代幣，等等。
Web3 的信任模型依賴於非對稱密碼學，其中信任的來源是用戶的私鑰。
雖然有一些委託的用例，但用戶通常不會選擇第三方作為信任代表，而委託將是用戶的選擇。
為使Web2 和Web3 之間的橋樑存在，關於用戶地址所有權的信任必須在兩個方向流動。
身份是橋樑的結構
歸根結底，在Web3 的背景下，用戶的地址是他們的”身份”。這代表了他們是誰。所以，他們可能有許多這樣那樣的身份，每一個都是他們在不同背景下呈現的獨立”身份”。
溝通Web2 和Web3 的世界意味著解決橋樑兩邊的身份問題，並使開發者能夠輕鬆地在此基礎上構建。
當然，在搭建橋樑時，Web 3的原則不應受到影響。我們可能需要調整Web3 身份協議（如OIDC：
https://openid.net/connect/、OAuth 2：https://oauth.net/2/）和標準的工作方式，以適應Web 3的需求和理念。
一切從地址開始
一個Web3 地址有一個相關的私鑰和公鑰。
地址的數量正在快速增長：
Ethereum Addresses（https://etherscan.io/chart/address）
但活躍地址的數量增長較慢：
活躍的以太坊地址https://etherscan.io/chart/active-address
從上面的圖表中，我們可以推斷出，積極使用以太坊地址的互聯網用戶的比例很低。 Metamask兩個月前說他們有3000萬月活躍用戶。但是，那些不擁有地址的用戶呢？
要讓Web3 獲得海量用戶的長期採用，必須有一條鋪設好的道路讓大眾用戶採用它。不是每個人都對加密世界有興趣。一種允許用戶繼續使用他們習慣的模式（如用Facebook、Google、Twitter等大平台登錄），並且只有在他們後來想知道區塊鏈（和密鑰）時才會意識到的方法是非常有價值的。
雖然地址的數量增長極快，但所有互聯網用戶中相對較小的群體才擁有他們的私鑰：要么離線創建密鑰對，要么通過硬件錢包。更多的是以”託管錢包”的形式存在，由服務機構來管理鑰匙。像Binance或Coinbase這樣的中心化交易所是最常見的例子。
雖然從Web3 /去中心化的角度來看，這可能並不”純粹”，但它是非常積極的。它把Web 3的一些想法帶到了大眾中。
從開發者的角度來看，連接Web2 和Web3 世界意味著託管服務必須將區塊鏈地址與用戶賬戶相關聯，安全地管理密鑰，並提供控制（至少對其他內部開發團隊而言）以管理錢包的互動。
像magic.link、bitski和venly這樣的服務正在幫助Web2連接Web3世界，為典型的Web2登錄機制創建密鑰對，並為開發人員提供API和UI來管理這些私鑰。
一旦用戶控制了一個私鑰，這就是樂趣的開始:)
用我的私鑰登錄
讓我們看一下一個相對簡單的場景，看看它在Web2和Web3應用程序中是如何工作的。用戶：
-
在一個應用程序上識別。
-
將他們的頭像更改為{input A} 並保存。
-
意識到他們在#2中犯了一個錯誤。
-
將他們的頭像更改為{input B} 並保存。
一個Web3應用程序（dApp）允許用戶”連接”他們的一個地址。這種操作本質上是給瀏覽器提供用戶的區塊鏈地址。除了區塊鍊和其他去中心化的服務之外，沒有任何”後端”。通常情況下，需要在Web3組件上驗證用戶的操作需要來自用戶私鑰的簽名信息。
Web 3 案例
有了Web2協議，用戶不必在每次操作時都採取行動來證明自己的身份。用戶通常只需登錄一次，客戶端/瀏覽器就會存儲一個憑證，並在隨後的請求中發送給後台，後台用它來驗證用戶的身份。
Web 2 案例
上面的圖是過度簡化的，以表達觀點
Web2的用戶體驗更好。銜接Web2世界和Web3世界需要保持與Web2類似的用戶體驗，當調用區塊鏈（或任何其他Web3原生服務）時，證明用戶控制了私鑰並打算執行每個具體操作。
作為Web2應用程序的一部分，開發人員如何將地址與用戶賬戶聯繫起來？
上一節提到的服務已經將私鑰與用戶賬戶關聯起來。但是，那些沒有的服務呢？如果用戶使用Metamask、Argent、Trezor或任何其他類型的錢包呢？
這就是用以太坊登錄解決的問題（
https://eips.ethereum.org/EIPS/eip-4361）。它允許用戶與一個服務建立一個會話（在Web2的意義上），使用他們的私鑰作為證明地址所有權的憑證。
圖片來源：https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/
如果這聽起來很有趣，你應該關注@signinwitheth和@SpruceID 。
而一旦Web2應用知道用戶的區塊鏈地址是事實，這就開啟了一個可能性的世界。
潛在的使用案例
一旦用戶的Web3身份被知曉，Web2的開發者自然會想進一步發展。這將意味著：
-
讀/寫與地址有關的公開可用數據（如鍊上數據），並將其用於業務邏輯。我們把這些稱為”不需要用戶認證的操作”。
-
讀/寫需要認證的數據（如存儲在去中心化存儲中的用戶的私人視頻或進行鏈上交易）。讓我們把這些稱為”需要用戶認證的操作”。
讓我們詳細看看每一項，以了解它如何運作。
不需要用戶認證的操作
這是最簡單的情況。開發人員將能夠調用任何需要地址且不需要認證的API。我想到的一些用例是：
-
讀取ENS（https://ens.domains/） 或Unstoppable Domains（https://unstoppabledomains.com/） 以獲取配置文件數據並顯示它，如果用戶選擇擁有它，這將為“全球公共用戶名和配置文件圖片”打開可能性。
-
通過獲取用戶的POAPs並根據這些POAPs（https://poap.xyz/）限制對資源的訪問，實現令牌門禁。
-
將資產轉移到一個用戶的鏈上地址。
-
下一步，如果他們成為主流，使用像人類證明這樣的服務來避免假的用戶賬戶。
請注意，還有其他方法可以通過可數字驗證的證書來實現其中的一些目標，而且這些方法不需要公共數據。但這是另一篇文章的故事…
需要用戶認證的操作
哦，事情開始變得很棘手:) 我們都已經習慣了這樣的對話框。
如果你想讓Web2應用訪問你的Gmail數據，你要用Google登錄，然後得到一個對話框，同意你希望的Web2應用訪問的賬戶中的資源。
這對Web 3服務應該如何操作？如果你的Web2應用程序想要讀取存在於兩個不同的Web3服務中的數據。
-
你應該同時”登錄”它們嗎？
-
還是只同意向他們倆授予應用程序權限？
-
每種情況下的用戶體驗是怎樣的？
在Web2應用程序的背景下，一個由認證服務器（在前面的例子中是谷歌）發出的令牌被用來訪問Gmail的API（Gmail是”資源服務器”）。 Web 2應用程序代表用戶向API進行多次調用時發送該令牌。在Web3服務的情況下，這應該如何操作？
-
用戶應該為每次與Web3服務的互動簽署一份協議嗎？這不是最好的用戶體驗…
-
他們應該把權限委託給應用程序嗎？如何委託？
-
Web3服務需要如何適應這些授權情況？
Spruce公司的開發者已經開始思考如何解決這一挑戰。我認為這是向前邁出的積極一步。我們需要了解用例和實際場景，以將這些案例概括為所有開發人員的可重複模式/指南。
我想這是未來挑戰的一個重要部分。
總結
我很想知道你對此有什麼看法，因為我正在積極思考並努力弄清這些東西。作為我的團隊在Auth0Lab的工作的一部分，我們正在探索如何在Web2和Web3的世界中架起橋樑，而不是僅僅在一個應用程序的背景下，而是在為所有開發人員提供工具的背景下。