Tác giả: Tri Huyện, người sáng lập UniPass
Sau hội nghị Devcon vừa kết thúc, tài khoản trừu tượng (account abstraction) là một trong những chủ đề nóng nhất. Gần đây, các từ viết tắt như AA / EOA / SCW / 4337 thường xuyên xuất hiện trong các buổi nói chuyện, panel thảo luận và luồng thông tin.
Cùng với việc câu chuyện đang dần chuyển hướng sang "Onboarding next billion users", một số tính từ mới cũng bắt đầu được dùng để mô tả sản phẩm, ví dụ như seedless / gasless / social recovery / non-custodial.
Bạn có lẽ đã cảm thấy nhức đầu sau hai câu trên rồi đúng không? Vậy hãy để tôi cố gắng giúp mọi người làm rõ các khái niệm này nghĩa là gì.
Lưu ý trước khi đọc: Bài viết này không phải tài liệu kỹ thuật nghiêm ngặt, có thể sử dụng ngôn ngữ không hoàn toàn chính xác nhưng dễ hiểu để giải thích hoặc so sánh, rất mong mọi người lấy đây làm điểm khởi đầu để tìm hiểu sâu hơn về các công nghệ này.
EOA - Tài khoản do bên ngoài sở hữu (Externally Owned Accounts)
EOA tiếng Trung gọi là tài khoản bên ngoài, thứ quen thuộc nhất với chúng ta là địa chỉ do MetaMask tạo ra chính là EOA. Đặc điểm của nó là nguyên lý đơn giản, ví dụ quy tắc tạo địa chỉ:
Khóa riêng → Khóa công → Băm Keccak256 → 20 byte cuối → Chuỗi thập lục phân (địa chỉ EOA)
Có thể thấy quy tắc này rất trực tiếp, hoàn toàn do các phép biến đổi toán học tạo nên, địa chỉ sinh ra không có cấu trúc hay logic nội tại nào. Khi nút mạng xác minh xem giao dịch có thực sự được chủ sở hữu ủy quyền hay không cũng theo quy tắc cố định:
Chữ ký giao dịch → ec_recover → Khóa công → (sinh địa chỉ theo quy tắc trên) → So sánh với địa chỉ cần thao tác
Nếu kết quả so sánh khớp thì xác thực chữ ký thành công, tiến hành các bước tiếp theo; nếu không khớp thì bị từ chối ngay lập tức, giao dịch sẽ không được lan truyền thêm.
Một thiết lập khác của EOA là làm bên khởi tạo giao dịch và trả phí gas, ngược lại CA (tài khoản hợp đồng) chỉ có thể bị gọi bởi CA hoặc EOA khác. Nói cách khác, EOA là bộ kích hoạt giao dịch — bất kể phía sau có bao nhiêu cuộc gọi hợp đồng, giao dịch luôn phải do một EOA khởi tạo và trả đủ gas mới được thực hiện.
Cần lưu ý rằng EOA là khái niệm chỉ tồn tại trên Ethereum và các chuỗi tương thích EVM (hoặc kiểu EVM), nói chính xác thì các chuỗi phi EVM nổi bật như BTC đều không có thiết lập này.
CA - Tài khoản Hợp đồng (Contract Accounts)
CA tiếng Trung gọi là tài khoản hợp đồng (trước đây còn gọi là tài khoản nội bộ). Những thứ chúng ta thường thấy như địa chỉ hợp đồng ERC-20, hợp đồng DeFi đều có địa chỉ trông rất giống EOA — đó chính là CA.
Về thiết kế, CA là cư dân bản địa của thế giới Ethereum, EOA và ETH chỉ là bộ kích hoạt và nhiên liệu phục vụ cho logic nghiệp vụ của CA. Trên thực tế, tất cả tài sản trên Ethereum ngoại trừ ETH đều do CA đảm nhiệm, còn các logic nghiệp vụ như DeFi thì hoàn toàn do CA thực hiện. Tuy nhiên, việc CA không thể tự động thực hiện thao tác hay trả phí gas đã hạn chế năng lực của nó. Ngay từ năm 2016 đã có đề xuất muốn cho phép CA tự trả gas.
Tóm lại, CA là loại tài khoản Ethereum có logic nội tại, bên trong có thể chứa logic nghiệp vụ (hợp đồng token dùng để ghi sổ, hợp đồng staking dùng để cho vay và thanh lý), hoặc cũng có thể là logic tài khoản (ví dụ logic multisig của Gnosis Safe), và phần sau chính là khái niệm "SCW - Ví hợp đồng thông minh" mà ta sắp đề cập.
Quy tắc tạo địa chỉ CA là do tính toán sinh ra, có hai cách CREATE và CREATE2, ở đây không đi sâu. Điều cần nhớ là CA không nhất thiết phải liên hệ với khóa công, ví dụ CA do Gnosis Safe tạo có thể thiết lập nhiều khóa công tùy ý để mở tài sản tương ứng; đương nhiên CA cũng có thể không thiết lập khóa nào, mà do logic của CA khác quyết định có thể mở khóa hay không, ví dụ hợp đồng cho vay DeFi, chỉ cần trả nợ là có thể rút lại tài sản thế chấp.
SCW/A - Ví/ Tài khoản Hợp đồng Thông minh (Smart Contract Wallet/Account)
Ví hợp đồng thông minh chắc chắn là khái niệm dễ hiểu nhất theo nghĩa đen, tức là dùng CA làm địa chỉ ví, trong khi ví EOA phổ biến là dùng kết quả biến đổi khóa công làm địa chỉ.
Do có logic nội tại, ví hợp đồng thông minh có thể thực hiện nhiều chức năng mà EOA không thể, như đại diện trả gas, giao dịch hàng loạt, quản lý quyền hạn, ủy quyền ngoại tuyến, khôi phục xã hội (social recovery)...
Dưới đây là vài ví dụ minh họa tiềm năng mở rộng của ví hợp đồng thông minh:
-
Gnosis Safe tận dụng kiến trúc ví hợp đồng thông minh để triển khai logic multisig;
-
Người dùng có thể trong một giao dịch gửi nhiều token khác nhau tới nhiều địa chỉ, hoặc khi dùng Uniswap có thể hoàn tất approve và swap trong một giao dịch, nhờ đó chỉ cấp quyền vừa đủ, tránh rủi ro an ninh do cấp quyền quá mức.
-
Người dùng có thể đặt các mức độ kiểm soát khác nhau cho các tài sản khác nhau, ví dụ đặt ngưỡng cao hơn cho PFP (so với token ERC-20 thông thường), ví dụ cần một admin key do ví phần cứng quản lý mới có thể chuyển, như vậy dù môi trường sử dụng hàng ngày bị rò rỉ khóa, hacker cũng không thể chuyển tài sản giá trị cao, đạt được cân bằng giữa an toàn và tiện lợi.
-
Người dùng có thể ký một ủy quyền ngoại tuyến: "Ai gửi cho tôi 100 ETH thì có thể chuyển BAYC của tôi", như vậy không cần cấp quyền cho hợp đồng bên thứ ba, người dùng vẫn có thể hoàn tất giao dịch nguyên tử P2P với người khác.
AA - Trừu tượng hóa Tài khoản (Account Abstraction)
Trừu tượng hóa tài khoản thực ra không phải khái niệm mới, lần đầu tiên được thảo luận từ năm 2015, lúc đó Vitalik cho rằng ít nhất nên cho phép thuật toán mật mã xác minh giao dịch của Ethereum có thể thay thế được, ví dụ chuyển sang ed25519 hiệu suất tốt hơn (xem chi tiết tại đây). Có thể nói trong 7 năm qua, Vitalik và EF chưa từng ngừng thảo luận và khám phá các phương án trừu tượng hóa tài khoản, dưới đây là một link tree đã được tổng hợp giúp mọi người ôn lại lịch sử.
Vậy làm sao để hiểu trừu tượng hóa tài khoản? Tôi xin trích dẫn mô tả mục tiêu từ ERC-4337:
Đạt được mục tiêu then chốt của trừu tượng hóa tài khoản: Cho phép người dùng sử dụng ví hợp đồng thông minh chứa logic xác minh tùy chỉnh thay vì EOA làm tài khoản chính. Loại bỏ hoàn toàn nhu cầu người dùng phải sở hữu EOA (như trạng thái hiện tại của ví SC và EIP-3074 đều yêu cầu).
Có thể thấy kỳ vọng của Ethereum đối với trừu tượng hóa tài khoản là thay đổi thực trạng hầu hết mọi người đang dùng EOA, hy vọng người dùng chuyển sang SCW và hoàn toàn loại bỏ sự phụ thuộc của hệ sinh thái vào EOA. Ngoài EIP-3074 được nhắc đến, còn có một đề xuất táo bạo và xa hơn là EIP-5003, tôi cũng trích dẫn vài đoạn văn bản gốc (có lược bỏ):
EOAs... bị giới hạn theo nhiều cách thiết yếu bởi giao thức. Các tài khoản này không hỗ trợ xoay vòng khóa để bảo mật, gộp giao dịch để tiết kiệm gas, hay giao dịch được tài trợ để giảm nhu cầu giữ ether. Có vô số lợi ích khác đến từ việc có tài khoản hợp đồng hay trừu tượng hóa tài khoản, như chọn thuật toán xác thực riêng, đặt giới hạn chi tiêu, cho phép khôi phục xã hội, cho phép xoay khóa, ủy quyền khả năng một cách tùy ý và gián tiếp, và gần như bất cứ điều gì khác ta có thể tưởng tượng.
... Đề xuất EIP này cung cấp con đường không phải củng cố EOA, mà là cung cấp lối thoát khỏi chúng, một lần và mãi mãi.
Không khó để nhận ra, mục tiêu của EIP-5003 là chuyển đổi EOA thành CA một lần duy nhất, để mọi người dùng đều sử dụng SCW, giải quyết triệt để vấn đề tương thích ngược. (Sau phần giải thích thuật ngữ trên, đọc các từ viết tắt này có dễ dàng hơn chưa?)
Đến đây, mọi người hẳn đã hiểu được nguồn gốc và mục tiêu tương lai của AA. Nhưng cần nhấn mạnh rằng, khái niệm AA không riêng gì Ethereum hay EVM, nhiều chuỗi vốn dĩ đã có mức độ AA khác nhau.
Ví dụ như EOS / Polkadot / Near / Solana / Flow / Aptos… thậm chí cả BTC (đơn ký / đa ký / Taproot), các chuỗi này khi thiết kế đã biến tài khoản thành trạng thái có cấu trúc nội tại hoặc thậm chí có khả năng quản lý quyền hạn, và còn có StarkNet / CKB có khả năng trừu tượng hóa tài khoản hoàn thiện hơn.
Nói đến đây, mọi người dễ nhận thấy rằng AA của Ethereum là giải pháp cho vấn đề lịch sử do EOA bất ngờ trở nên phổ biến, nhằm khiến tầng tài khoản tiên tiến và linh hoạt hơn.
Từ phần thảo luận AA phía trên, dễ thấy ERC-4337 chỉ là một trong nhiều đề xuất theo hướng này, nhưng tại sao mỗi khi nói đến AA hay SCW mọi người lại nhắc đến nó? Hãy xem tiêu đề phụ của tài liệu này:
Một đề xuất trừu tượng hóa tài khoản hoàn toàn tránh thay đổi giao thức tầng đồng thuận, thay vào đó dựa vào cơ sở hạ tầng tầng cao hơn.
Nói cách khác, ERC-4337 là lần đầu tiên lộ trình AA chuyển từ "cách mạng bạo lực" sang "diễn biến hòa bình", không còn theo đuổi AA bằng thay đổi tầng đồng thuận, mà chuyển sang dùng giải pháp SCW ở tầng người dùng. Đồng thời, để đạt tính tương tác tốt hơn, ERC-4337 định nghĩa một số giao diện mà SCW nên triển khai, cùng khung cơ sở hạ tầng như đóng gói giao dịch meta, đại diện trả gas...
Việc ra đời của nó giúp các phương án SCW khác biệt lớn hiện nay có thể có giao diện tương tác thống nhất và dùng chung một số cơ sở hạ tầng mở được xây dựng trên hệ sinh thái, giúp các kịch bản nhanh chóng triển khai phương án SCW mình cần.
Mặt khác, việc thúc đẩy ERC-4337 giúp thúc đẩy các bên tham gia hệ sinh thái khác nâng cao khả năng tương thích với SCW, ví dụ như EIP-1271 cần cho xác minh chữ ký và một số quy tắc cấm CA tương tác được định nghĩa trong một số giao thức DeFi.
Seedless
Ở đây seed nghĩa là cụm từ khôi phục (seed phrase), chính là cụm từ mà chúng ta thường được yêu cầu sao lưu khi tạo ví. Vậy seedless nghĩa là "không cần cụm từ khôi phục", hoặc cũng có thể gọi là "không khóa riêng". Lưu ý rằng "không" ở đây không phải nghĩa đen là không có khóa, mà là người dùng không cần sao lưu cụm từ khôi phục/khóa riêng hoặc không cần biết đến sự tồn tại của chúng.
Một câu hỏi phổ biến là: Nếu người dùng không sao lưu cụm từ khôi phục, họ có còn quyền kiểm soát tài khoản không? Khi chuyển sang thiết bị mới, tài khoản có truy cập được không?
Đúng vậy, nếu chỉ đơn giản cắt chức năng sao lưu cụm từ khôi phục thì chỉ là sai lầm thiết kế sản phẩm, còn seedless hướng tới việc người dùng "không cần" biết đến sự tồn tại của cụm từ khôi phục, nhưng vẫn giữ quyền kiểm soát hoàn toàn tài khoản.
Nói cách khác, chỉ người dùng (và duy nhất người dùng) có khả năng tự phục hồi quyền kiểm soát tài khoản trên thiết bị mới, nhưng không còn phụ thuộc vào cụm từ khôi phục – một cách thức UX kém, quá geek, ví dụ như khôi phục xã hội (social recovery) sắp đề cập là một lựa chọn rất tốt.
Gasless
Ở đây gas nghĩa là phí gas, vậy gasless nghĩa là "miễn phí gas". Tương tự, gasless không phải thật sự không cần trả phí gas, mà là người dùng không cần buộc phải hiểu khái niệm gas, càng không cần mua trước các token gốc để trả gas.
Vậy ai trả gas? Có hai trường hợp:
-
Một là khi tài khoản người dùng đã có tài sản tiền mã hóa, ví dụ token kiếm được từ play-to-earn, airdrop nhận được, hoặc chuyển khoản từ người khác, miễn là các token này có giá trị và tính thanh khoản nhất định, sẽ có relayer sẵn sàng chấp nhận chúng và giúp người dùng trả gas để thu lợi nhuận.
-
Hai là tài khoản người dùng không có token có giá, ví dụ như tài khoản vừa tạo. Nếu lúc này cần tương tác trên chuỗi, bên ứng dụng có thể chọn tài trợ một lượng gas "định hướng" để giúp người dùng khởi động, từ đó giảm tỷ lệ rời bỏ người dùng; hoặc cho phép người dùng xem quảng cáo để đổi lấy một chút gas.
Hai chiến lược này đặc biệt hiệu quả trên L2 nơi chi phí gas thấp.
Social Recovery
Khôi phục xã hội là cơ chế dùng mối quan hệ xã hội giúp người dùng lấy lại quyền truy cập tài khoản khi mất khóa. Nếu bạn từng đăng nhập thiết bị mới bằng WeChat, bạn có trải nghiệm "yêu cầu hai người bạn gửi xxx vào tài khoản bạn để đăng nhập" — đó chính là hiệu ứng khôi phục xã hội muốn đạt được, chỉ khác là bên xác minh từ WeChat chuyển thành hợp đồng thông minh.
Một hiểu lầm phổ biến là gọi các giải pháp dùng tài khoản mạng xã hội để tạo/đăng nhập ví là khôi phục xã hội, đây là nhầm lẫn "mối quan hệ xã hội" với "tài khoản nền tảng xã hội". Ví hợp đồng thông minh lâu đời Argent tích hợp sẵn khả năng khôi phục xã hội, yêu cầu guardian cung cấp một địa chỉ Ethereum, để khi cần đăng nhập thiết bị mới thì cung cấp chữ ký ủy quyền. Nhưng giải pháp này tiềm ẩn giả định: guardian của bạn phải chuyên nghiệp hơn bạn trong việc quản lý tài khoản Ethereum, nếu không khi bạn cần họ ký, mà tài khoản họ cũng không truy cập được, tài khoản bạn cũng bị liên lụy. Vì vậy, cách khả thi hơn là dùng bằng chứng mật mã email (DKIM Signature) hoặc hộ chiếu điện tử — những công cụ mật mã phổ biến trong đời sống — để tăng tính thực dụng cho giải pháp khôi phục xã hội.
Non-custodial
Không lưu trữ (Non-custodial) có lẽ là khái niệm "đúng đắn về mặt chính trị" nhất và cũng bị lạm dụng nhiều nhất trong ngành crypto, vì thường mỗi bên đều có định nghĩa riêng. Dưới đây là định nghĩa của chúng tôi về non-custodial, gồm hai khía cạnh chính:
-
Nhà phát triển ví không thể tự ý thao tác tài khoản người dùng
-
Nhà phát triển ví không thể ngăn cản người dùng thao tác tài khoản của chính họ
Nếu bạn đồng tình với hai điểm này, thì việc đánh giá một ví là custodial, semi-custodial hay non-custodial có thể trực tiếp kiểm tra bằng hai quy tắc này:
Không thỏa mãn 1 → Custodial; thỏa mãn 1 nhưng không thỏa mãn 2 → Semi-custodial; thỏa mãn cả 1 và 2 → Non-custodial.
Biết được loại hình lưu trữ có tác dụng gì không? Người dùng có thể chẳng quan tâm nguyên lý đằng sau, chỉ cần dùng tốt là được! Đúng vậy, tôi cũng phần nào đồng ý với quan điểm này, ít nhất ở giai đoạn hiện tại, ngành chưa phát triển đến mức chuyển dịch nhận thức người dùng. Thực ra tôi cho rằng ba loại giải pháp phù hợp với các kịch bản khác nhau:
-
Giải pháp custodial - Phù hợp với sàn giao dịch, dịch vụ tài chính tổ chức lớn, tuân thủ mạnh. Ví dụ một số dịch vụ do Coinbase/Fireblocks cung cấp. Đặc điểm: số lượng người dùng ít, không cần xử lý tương tác tần suất cao, giá trị đơn hàng lớn, có thể chịu chi phí lớn để duy trì hệ thống phòng vệ cao.
-
Giải pháp semi-custodial - Phù hợp nhóm người dùng cá nhân cao cấp hơn. Họ hiểu rằng bên cung cấp dịch vụ có thể kiểm duyệt giao dịch của mình, và có khả năng chuẩn bị phương án dự phòng trước (ví dụ xuất khóa riêng), để khi dịch vụ bị từ chối chủ động hay bị động thì tài sản vẫn an toàn. Như vậy khi dùng thường ngày có thể hưởng tiện lợi và an toàn, trong tình huống cực đoan vẫn bảo toàn được tài sản. Lưu ý loại giải pháp này đòi hỏi rất cao về năng lực vận hành nhà cung cấp, vì số lượng người dùng cá nhân lớn, nhu cầu tương tác với các ứng dụng hàng ngày cũng cao hơn, đồng thời yêu cầu cao về tính sẵn sàng dữ liệu, vì một khi mất dữ liệu được lưu ở máy chủ có thể khiến tất cả người dùng chưa sao lưu vĩnh viễn không truy cập được tài khoản.
-
Giải pháp non-custodial - Phù hợp với kịch bản hướng tới đại chúng hóa. Nghe có vẻ phản trực giác, nhưng xét về chi phí, non-custodial là giải pháp duy nhất có thể đảm bảo an toàn và khả dụng trong kịch bản giá trị đơn hàng thấp. Nếu một ứng dụng hướng tới người dùng quy mô lớn định chọn hai giải pháp trên, phải cân nhắc xem bên kia có thể cung cấp dịch vụ đủ an toàn và khả dụng cho nhóm người dùng của mình không, nếu không, một khi nhân viên nội bộ làm điều xấu, bị hacker tấn công hay sự kiện bất khả kháng khiến dịch vụ ngừng hoạt động, tất cả người dùng của bạn sẽ bị ảnh hưởng, và hoạt động kinh doanh của bạn cũng có thể sụp đổ. Lịch sử đã chứng kiến vô số trường hợp kể cùng một câu chuyện: an ninh không phải chuyện nhỏ, chịu trách nhiệm cho người dùng là chịu trách nhiệm cho chính mình.
MPC - Tính toán An toàn Đa bên (Multi-Party Computation)
Tính toán an toàn đa bên và chứng minh không kiến thức (ZKP) có thể coi là hai "phép màu" lớn nhất hiện nay trong Web3, một khi liên quan đến chúng, dường như những việc trước đây không làm được bỗng dưng có thể làm được. Thực tế đúng là như vậy trong một số trường hợp, đặc biệt là ZKP, có thể dùng xác suất đổi lấy khả thi; MPC thì dùng cách phân tán quyền kiểm soát để đạt khả năng kiểm soát rủi ro hoặc phòng ngừa thảm họa.
MPC thực ra là một khuôn mẫu, bao gồm nhiều phương án kỹ thuật, trong ngữ cảnh Web3 hiện nay thường chỉ TSS.
TSS - Sơ đồ Chữ ký Ngưỡng (Threshold Signature Scheme)
Chữ ký ngưỡng là một giao thức chữ ký phân tán nhiều bên, bao gồm các thuật toán như tạo khóa phân tán, ký tên, và chia sẻ lại (re-sharing) các mảnh khóa riêng mà không thay đổi khóa công.
Một TSS m-n nghĩa là một khóa công tương ứng với n mảnh khóa riêng, trong đó m mảnh phối hợp ký có thể được xác thực thành công bằng khóa công. Không khó để thấy logic này tương tự đa ký (multi-sig), điểm khác biệt chủ yếu nằm ở số lượng khóa công.
Ví dụ, đa ký 2-2 giống như cửa gắn 2 ổ khóa, phải dùng hai chìa mở cả hai mới mở được cửa; TSS 2-2 giống như cửa gắn 1 ổ khóa, nhưng chìa có hai mảnh, ghép lại mới mở được. Để dễ hiểu, mô tả này không hoàn toàn chính xác, hai chìa ghép thành một thực ra phù hợp hơn với thuật toán Shamir Secret Sharing; các mảnh khóa trong TSS không gặp nhau, mà mỗi mảnh ký riêng, sau đó qua thuật toán đặc biệt có thể dùng khóa công tương ứng để xác thực.
Vậy TSS có nhất thiết là custodial hay non-custodial không? Thực ra không có liên hệ tất yếu, chủ yếu phụ thuộc vào thiết kế và lựa chọn cuối cùng của giải pháp. Giải pháp non-custodial yêu cầu người dùng có khả năng thao tác độc lập tài khoản, do đó người dùng phải nắm giữ ít nhất số mảnh khóa bằng ngưỡng, ví dụ 2-3 thì người dùng cần nắm 2 mảnh, còn giải pháp 2-2 không thể đạt non-custodial, tối đa chỉ đến semi-custodial (ví dụ ZenGo); nhưng nếu người dùng nắm nhiều mảnh khóa nhất, chắc chắn sẽ làm tăng yêu cầu năng lực người dùng, khó đạt được đại chúng hóa.
Cuối cùng
Viết đến đây thì có lẽ đã bao quát các thuật ngữ phổ biến liên quan tài khoản Web3, đếm số từ cũng gần 5k rồi. Với lượng nội dung lớn như vậy khó tránh khỏi sai sót, rất mong mọi người thẳng thắn góp ý, nếu phát hiện lỗi hay có quan điểm khác cứ tìm tôi trên Twitter ( @frank_lay2) để trao đổi, sau này có bổ sung hay cập nhật nội dung tôi cũng sẽ kịp thời thông báo trên Twitter.
