譯者 | 李睿

審校 | 重樓

51CTO讀者成長(zhǎng)計(jì)劃社群招募，咨詢小助手（微信號(hào)：CTOjishuzhan）

對(duì)于開發(fā)Web3應(yīng)用程序的開發(fā)者來說，通常知道讓用戶登錄Web3很困難。即使承諾用戶真正擁有自己的數(shù)據(jù)，進(jìn)行近乎免費(fèi)的全球支付，并使用無審查的系統(tǒng)，創(chuàng)建和使用數(shù)字錢包的過程還是非常困難。

幸運(yùn)的是，還有更好的方法。帳戶抽象（Account Abstraction）承諾簡(jiǎn)化流程，使用戶登錄更加無縫和簡(jiǎn)單。流量（Flow）是一個(gè)去中心化的、公共的、第一層區(qū)塊鏈，旨在為用戶構(gòu)建Web3體驗(yàn)而設(shè)計(jì)，它使用帳戶抽象將混合托管模型與無數(shù)字錢包登錄相結(jié)合，從而創(chuàng)建了一個(gè)像傳統(tǒng)應(yīng)用程序一樣簡(jiǎn)單和直接的登錄。

以下深入了解一下混合托管和無錢包登錄是如何協(xié)同工作的，例如在架構(gòu)、代碼，以及可以期待的進(jìn)展等方面。

一、為什么登錄Web3如此困難

數(shù)字錢包帶來了Web3的所有好處，包括保證沒有人可以控制你的資產(chǎn)。沒有中間人，例如銀行從用戶的錢中抽取一定比例的費(fèi)用，也沒有第三方規(guī)定用戶能做什么。然而，因?yàn)榇蠖鄶?shù)錢包都是“自我托管”的(只有用戶自己可以訪問)，用戶需要管理自己的密鑰。如果出錯(cuò)，不會(huì)得到其他人的幫助和支持。

這意味著用戶必須安全地保存密鑰。不要將它們以明文形式存儲(chǔ)在自己的電腦上，它們可能會(huì)被黑客竊取。也不要把密鑰寫在別人能看到的地方。Web3沒有重置密碼，如果丟失它們，可能會(huì)失去一切。因此可以看到Web3登錄問題所在。

除了面臨自我托管的挑戰(zhàn)之外，用戶還需要了解代幣和支付。例如，如何支付交易費(fèi)用？需要什么代幣?如何從法定貨幣轉(zhuǎn)向代幣?一旦有了代幣，將如何轉(zhuǎn)移它們?如果在發(fā)送代幣的時(shí)候出錯(cuò)，那么它們可能永遠(yuǎn)消失了。因此，可以再次了解這一切有多困難。

考慮到所有這些障礙，因此很容易理解為什么許多用戶沒有完成登錄Web3應(yīng)用程序的第一步。

二、托管錢包出色的用戶體驗(yàn)，但缺乏所有權(quán)

開發(fā)人員試圖用托管數(shù)字錢包來解決這個(gè)問題。這些錢包為用戶管理密鑰，有很多好處。

注冊(cè)很容易。用戶可以像使用傳統(tǒng)服務(wù)一樣使用電子郵件和密碼，其余的由數(shù)字錢包提供商負(fù)責(zé)。如果用戶丟失了登錄憑證，其密鑰仍然可以在提供商的服務(wù)器上訪問，用戶也可以簡(jiǎn)單地請(qǐng)求重置密碼。由于錢包軟件運(yùn)行在他們的服務(wù)器上，供應(yīng)商甚至可以支付交易費(fèi)用。用戶不需要理解代幣、資金和轉(zhuǎn)賬。

但正如Web3所說：“不是你的密鑰，就不是你的錢!”雖然托管數(shù)字錢包解決了許多登錄問題，但錢包提供商最終擁有密鑰。而現(xiàn)在回到了想要擺脫的問題：一個(gè)中心化的實(shí)體可以阻止用戶使用自己的代幣，可以隨心所欲地關(guān)閉用戶的賬戶，或者取走用戶的資金。

如果你能兩全其美，那不是很好嗎?

三、拯救賬戶抽象

帳戶抽象解決了區(qū)塊鏈網(wǎng)絡(luò)的一個(gè)基本問題：外部擁有的帳戶和合同帳戶之間的區(qū)別。

外部擁有的帳戶(EOA)是由用戶使用私鑰控制的帳戶，這些是在上面談到的傳統(tǒng)的Web3錢包。外部擁有的帳戶(EOA)有一個(gè)公共地址，并通過區(qū)塊鏈發(fā)起交易(例如發(fā)送代幣)。

合約賬戶(也只是一個(gè)智能合約)是一個(gè)部署在鏈上并由網(wǎng)絡(luò)節(jié)點(diǎn)執(zhí)行的程序。合同賬戶不會(huì)啟動(dòng)交易。與其相反，它們用自己的動(dòng)作響應(yīng)交易。它們沒有私鑰，由自己的代碼控制。這種類型的賬戶可以說是擁有應(yīng)用程序托管。

帳戶抽象將應(yīng)用程序托管和自我托管結(jié)合到一個(gè)新的用戶體驗(yàn)(UX)中，為用戶提供兩者的好處：控制他們的錢包，同時(shí)抽象錢包(區(qū)塊鏈)。

在流量上，帳戶抽象是使用混合托管的無錢包登錄的基礎(chǔ)。

四、混合托管讓你兩全其美

無錢包登錄允許開發(fā)人員為用戶創(chuàng)造近乎無縫的登錄體驗(yàn)。

混合托管模型使用帳戶抽象來允許帳戶委托，其中子帳戶通過Capability將控制權(quán)委托給父帳戶，在本質(zhì)上允許一個(gè)帳戶控制另一個(gè)帳戶。

現(xiàn)在，自我托管帳戶可以是父帳戶，為應(yīng)用程序帳戶授予權(quán)限，而應(yīng)用程序帳戶現(xiàn)在是子帳戶。有了這樣的設(shè)置，應(yīng)用程序帳戶可以協(xié)同工作，應(yīng)用程序可以這樣工作：

應(yīng)用程序?yàn)橛脩魟?chuàng)建錢包。這里沒有登錄的障礙——沒有密鑰管理，沒有簽名交易，也不了解區(qū)塊鏈。用戶可以使用應(yīng)用程序購買和出售資產(chǎn)，而無需了解或關(guān)心技術(shù)細(xì)節(jié)。用戶的應(yīng)用程序甚至可以補(bǔ)貼交易費(fèi)用，或者讓他們用美元等法定貨幣為賬戶提供資金。這一切對(duì)用戶來說都是不可見的。

一旦用戶帶著自己的錢包管理賬戶回來，其應(yīng)用程序可以授權(quán)訪問用戶的賬戶。一旦鏈接，用戶就擁有了混合托管權(quán)力——他們的錢包管理著他們的主賬戶(現(xiàn)在是“父賬戶”)，這個(gè)主賬戶維護(hù)著對(duì)應(yīng)用程序創(chuàng)建的賬戶(現(xiàn)在是“子賬戶”)的訪問。

由于用戶的主賬戶現(xiàn)在可以訪問應(yīng)用程序創(chuàng)建的賬戶，他們可以將應(yīng)用程序資產(chǎn)帶到錢包管理的賬戶所在的任何地方。他們可以在市場(chǎng)上交易應(yīng)用資產(chǎn)，或者與朋友分享。然而，與此同時(shí)，由于應(yīng)用程序也可以訪問帳戶，它仍然可以為代表他們的行為提供無縫的用戶體驗(yàn)。

使用這種混合托管模型，用戶可以立即體驗(yàn)應(yīng)用程序，障礙最小，并且沒有風(fēng)險(xiǎn)。在此之后，如果他們?cè)敢猓梢宰约嚎刂谱晕彝泄苜~戶，享受它帶來的所有真正的所有權(quán)和自我主權(quán)。

五、混合保管和賬戶抽象的技術(shù)細(xì)節(jié)

1.創(chuàng)建賬戶

這一切是如何運(yùn)作的呢?

在以太坊和許多其他區(qū)塊鏈網(wǎng)絡(luò)上，EOA是從公鑰創(chuàng)建的。該密鑰被散列，該散列的前160位成為該密鑰控制的帳戶的地址。這使得帳戶創(chuàng)建獨(dú)立于網(wǎng)絡(luò)，但不可撤銷地將帳戶與該密鑰綁定在一起。

流量使用一個(gè)特定的鏈上函數(shù)來創(chuàng)建帳戶地址。然后，用戶可以向流量帳戶添加任意數(shù)量的密鑰，并根據(jù)每個(gè)密鑰的保管人添加和刪除訪問權(quán)限。這意味著需要一個(gè)交易來創(chuàng)建一個(gè)新地址。所以用戶不能離線創(chuàng)建賬戶，但這也使流量帳戶的所有權(quán)更加靈活。

用戶可以在GitHub上看到一個(gè)完整的帳戶創(chuàng)建示例，先看看這里的關(guān)鍵部分：

JavaScript

1 userPrivateKey := examples.RandomPrivateKey()
2 userPublicKey := flow.NewAccountKey().
3  FromPrivateKey(userPrivateKey).
4  SetHashAlgo(crypto.SHA3_256).
5 SetWeight(flow.AccountKeyWeightThreshold)
6
7 serviceAccountAddress, serviceAccountKey, serviceSigner :=
8  examples.ServiceAccount(flowClient)
9
10 createAccountTx, _ := templates.CreateAccount(
11  []*flow.AccountKey{userPublicKey},
12  nil,
13  serviceAccountAddress
14 )
15
16 createAccountTx.SetProposalKey(
17  serviceAccountAddress,
18  serviceAccountKey.Index,
19  serviceAccountKey.SequenceNumber
20 )
21
22 createAccountTx.SetReferenceBlockID(
23  examples.GetReferenceBlockId(flowClient)
24 )
25
26 createAccountTx.SetPayer(serviceAccountAddress)
27
28_ = createAccountTx.SignEnvelope(
29  serviceAccountAddress,
30  serviceAccountKey.Index,
31  serviceSigner
32 )
33_ = flowClient.SendTransaction(ctx, *createAccountTx)

首先，用戶創(chuàng)建一個(gè)密鑰對(duì)。這是很基本的事項(xiàng)。

因?yàn)樵诹髁可希脩敉ㄟ^發(fā)送帳戶創(chuàng)建交易來創(chuàng)建帳戶，所以需要一個(gè)現(xiàn)有帳戶來發(fā)送這一交易。這是ServiceAccount的工作。

createAccountTx接收用戶的公鑰，以便稍后控制新帳戶，但是ServiceAccount(為交易簽名并付款)處理其余的工作。在用戶的應(yīng)用程序中，將擁有這個(gè)服務(wù)帳戶，這樣就可以代表用戶簽署帳戶創(chuàng)建交易，也為帳戶創(chuàng)建提供資金。

2.混合托管

回到混合托管模式。應(yīng)用程序可以為用戶創(chuàng)建應(yīng)用程序帳戶，并將它們鏈接到其應(yīng)用程序控制的公鑰。然后，應(yīng)用程序可以處理用戶的交易和資產(chǎn)，甚至贊助他們的交易費(fèi)用，就像任何托管賬戶一樣。

稍后，當(dāng)用戶決定深入Web3生態(tài)系統(tǒng)并獲得自己的錢包時(shí)，可以創(chuàng)建并保存指向應(yīng)用程序托管帳戶的AuthAccount Capability的鏈接，并將控制權(quán)委托給用戶的錢包管理帳戶。

用戶可以在無錢包登錄示例中看到這樣的示例，其中應(yīng)用程序執(zhí)行多重簽名交易，將用戶的帳戶鏈接到無錢包的登錄，dapp托管的帳戶到簽名用戶的錢包管理帳戶。

六、結(jié)語

需要強(qiáng)調(diào)的是，在應(yīng)用程序創(chuàng)建的帳戶上授權(quán)訪問是通過帳戶上的鏈接Capability完成的，然后將其提供給用戶。對(duì)于區(qū)塊鏈帳戶來說，這種帳戶委托機(jī)制是全新的，它之所以成為可能，是因?yàn)槎嗄陙砹髁吭膸舫橄蟆＿@種語言API賬戶鏈接功能對(duì)于流量上的賬戶來說是一個(gè)巨大的優(yōu)勢(shì)，此外還有許多其他功能——m-of-n多重簽名、賬戶密鑰更新等等，這些功能現(xiàn)在才開始在其他鏈上實(shí)現(xiàn)，它們都是新生的、非本地的賬戶抽象實(shí)現(xiàn)。

帳戶抽象是一個(gè)強(qiáng)大的特性。在流量上，它支持混合托管模型，允許用戶在注冊(cè)時(shí)享受托管帳戶的好處，同時(shí)允許他們隨時(shí)將帳戶納入自我托管。這是一種全新的顯著改進(jìn)的用戶體驗(yàn)，有望為Web3帶來數(shù)百萬用戶。

原文鏈接：https://dzone.com/articles/solving-web3-onboarding-with-account-abstraction-a