Account Abstraction

Account Abstraction là gì?
Các khó khăn của EOA khi thực hiện web3 mass adoption
Lợi ích của Account Abstraction
How will account abstraction be implemented?
Curent progress
Tham khảo

Trong bài này nếu không có ghi chú đặc biệt ta sẽ mặc định là nói về Account Abstraction trong Ethereum và các hệ thống EVM-compatible blockchain tương tự.

Account Abstraction là gì?

TL,DR: Account Abstraction là một đề xuất để tăng tính linh hoạt trong quản lý và vận hành của Ethereum account bằng cách sử dụng Smart Contract Account như top-level account để trả phí và thực hiện transaction.

account-abstraction

Giống như các khái niệm mới khác trong web3, Account Abstraction là một thứ khó để định nghĩa. Tuy nhiên chúng ta có thể dễ hiểu nó hơn bằng cách trước tiên phân tách các thuật ngữ trong đó trước:

Abstraction: là một khái niệm trong khoa học máy tính, nó có nghĩa là những thông tin phức tạp về hệ thống hoặc ứng dụng được ẩn đi, thay vào đó cung cấp một giao diện dễ sử dụng cho người dùng. Do đó người dùng có thể dễ dàng thao tác mà không cần biết đến đằng sau nó có những gì hay hoạt động ra sao.
Account: đại diện cho một user trên blockchain có thể gửi và nhận transaction và tương tác on-chain với các account khác. Ethereum có 2 loại account: External Owned Account (EOA) và Smart Contract Account.
- External Owned Account (EOA): là account thông thường (như account trong MetaMask) gồm một cặp key mã hoá là private key và public key. Một EOA là active: nó có thể trực tiếp gửi transaction và trả phí gas trên mạng blockchain. Tuy nhiên nó bị giới hạn là chỉ có thể thực hiện được các thao tác cơ bản nhất của mạng blockchain như gửi nhận ETH, hay tương tác với contracts mà thôi; tự bản thân nó không có các kịch bản logic trong đó.
- Smart Contract Account: là smart contract được deploy trên Ethereum, được điều khiển bởi logic trong code của contract thay vì private key như EOA. Một contract account là passive: nó luôn cần một EOA account để có thể kích hoạt transaction, và bản thân nó mặc dù có thể lưu trữ ETH, nhưng không thể tự trả phí giao dịch. Tuy nhiên lợi thế của smart contract account là nó có thể lập trình được, do đó nó có thể triển khai được vô cùng đa dạng và linh hoạt các kịch bản khác nhau trong đó.
Wallet: là một giao diện để quản lý tài sản trong Ethereum account. Một EOA-base wallet như MetaMask sẽ yêu cầu cần có private key để xác nhận quyền giao dịch. Trong khi đó smart contract wallet thì sẽ liên kết đến một hoặc nhiều các EOA account khác, việc xác nhận quyền giao dịch có thể được tuỳ ý triển khai với những mô hình khác nhau (ví dụ kí trực tiếp, multisig,…)

Hiểu rõ các thuật ngữ trên, ta có thể đi vào định nghĩa Account Abstraction:

Account Abstraction là một đề xuất để tăng tính linh hoạt trong quản lý và vận hành của Ethereum account bằng cách sử dụng Smart Contract Account như top-level account để trả phí và thực hiện transaction.

Với account abstraction, ta có thể đa dạng hoá cách truy xuất fund bằng lập trình, thay vì chỉ đơn thuần dựa vào private key như với EOA.

Từ góc nhìn network-level, account abstraction có nghĩa là chi tiết của account được ẩn đi khỏi Ethereum protocol. Mỗi account đơn thuần là một smart contract, user có thể tự do quy định cách mà mỗi account được quản lý và vận hành.

Từ góc nhìn user-level, account abstraction có nghĩa là phần technical về việc account tương tác với Ethereum blockchain như thế nào được ẩn đi bên dưới một giao diện người dùng dễ sử dụng. Nó sẽ cải thiện được UX trong wallet design và giảm được phần lớn sự phức tạp cho người dùng khi tiếp cận với web3 application.

Như vậy với account abstraction, wallet developer có thể tạo ra một hệ thống đơn giản hoá trải nghiệm của người dùng web3 khi user có thể không cần biết hay quan tâm về các vấn đề như technical, key, sign transaction, trả phí gas,…

Việc này sẽ giúp tiến gần hơn đến web3 mass adoption.

Các khó khăn của EOA khi thực hiện web3 mass adoption

Ta hãy thử đóng vai một newbie hoàn toàn chưa biết gì về blockchain, crypto và muốn tiếp cận và sử dụng web3 application ở thời điểm hiện tại xem đang mắc phải những rào cản gì

Ta phải cần một cái ví, ví là gì vậy? sao không dùng user-password hay đăng nhập bằng google, facebook mà lại phải tải cái MetaMask về; rồi địa ví là cái gì vậy? sao trông loằng ngoằng thế, rồi sao lại phải lưu một dãy các từ làm gì? lưu vào đâu?
Giờ ta mất cái chuỗi kí tự này là không khôi phục được tài khoản đúng không? là mất hết tiền đúng không?
Giờ ta muốn xác thực khuôn mặt cho tiện, hay 2-factors authentication, hay limit spending thì làm thế nào? không được à?
Rồi giờ ta cần một ít ETH để có thể bắt đầu, ta phải làm thế nào?
- nhờ ai đó gửi cho một ít ETH
- Đăng ký tài khoản (lại đăng ký cái gì đấy) trên các sàn giao dịch tập trung như Binance, CoinBase, rồi add tài khoản ngân hàng, hay credit card vào để mua ETH? rồi mua ra sao? mua xong rồi thì rút về ra sao? network là cái gì? lựa chọn thế nào?
Gas là cái gì? sao gửi giao dịch phải tốn gas? là tốn tiền đúng không?
etc

Hàng chục câu hỏi tới tấp cứ như một ma trận với người dùng mới, rõ ràng là một rào cản vô cùng lớn. Tại sao không đơn giản giống như web app truyền thống:

đăng nhập bằng google, facebook
sử dụng app luôn không mất gì cả

đơn giản và dễ hiểu.

Sự ra đời của Account Abstraction cũng chính là hướng tới sự đơn giản đó, ẩn đi tất cả những phức tạp phía trên ở đằng sau hệ thống, người dùng chỉ việc tương tác với những gì dễ dàng nhất mà thôi.

Ở đây ta không nền nhầm lẫn rằng account abstraction có thể làm cho hệ thống đơn giản hơn. Nó làm cho việc tương tác của user với ứng dụng trở nên đơn giản hơn; còn về mặt kỹ thuật nó làm cho hệ thống trở nên phức tạp hơn vì nó cần thêm vào những infrastructure layer mới, và đẩy những phần phức tạp trước đây vốn thuộc về user về phía hệ thống.

Lợi ích của Account Abstraction

Quá trình abstract là “trừu tượng hoá”, có nghĩa là không có một quy chuẩn cố định quy định là làm như thế nào để tạo ra account abstraction. Ta chỉ cần hiểu đơn giản nó là smart contract, và tạo ra một thứ tương tự như account, hay ví.

Theo đó tuỳ theo ta sẽ trừu tượng hoá cái gì (what), và trừu tượng hoá ở đâu (when), ta sẽ đạt được những lợi ích khác nhau.

Có thể ví dụ như:

Signature abstraction
Fee abstraction
Nonce abstraction

Signature abstraction

Hiện tại các EOA sử dụng ECDSA làm thuật toán để sinh ra private key, public key, đồng thời cũng để sinh ra chữ ký xác thực cho giao dịch. Khi tiến hành trừu tượng hoá quá trình xác thực giao dịch, ta có thể triển khai được nhiều những kịch bản có lợi khác như:

Cryptography khác với ECDSA: như Schnorr signatures, BLS signatures, hoặc các đường cong khác và thuật toán quantum-proof như Lamport/Winternitz cũng có thể được implement.
Multisig wallet: Smart contract mặc định sẽ là multisig, có khả năng thêm/xoá các signers, có thể thực hiện nhiều scheme xác thực khác nhau như m/n.
Transaction limits: Một account có thể reject một transaction (hoặc yêu cầu thêm xác thực) nếu giá trị của nó vượt quá một limit nào đó. Nó giống như việc ngân hàng truyền thống có giới hạn giao dịch trong ngày, hay giới hạn số tiền tối đa trong một giao dịch để tránh rủi ro mất tiền cho người dùng.
Key rotation and revocation: Với smart contract account, ta có thể generate signing key mới trong trường hợp cái cũ bị thất lạc hay bị lộ. Bảo mật hơn nữa, ta có thể có những guardian có thể giúp đóng băng tài khoản lại trong khi ta tiến hành đổi key để tránh việc bị kẻ xấu nhanh tay hơn rút tiền trước. Nó giống như việc ta có thể đóng băng thẻ credit card nếu thấy có dấu hiệu bị lộ hay bị trộm đúng không?
Social recovery: Cung cấp khả năng recover cho account thông qua xác thực qua các social service khác như email, số điện thoại,…

multi-factor

Trusted sessions: Nó giúp ta tránh việc mỗi lần đều cần ký thủ công mọi giao dịch trên ứng dụng, thay vào đó ta có thể tạo một “session key” để cho phép ứng dụng có thể tự động thực hiện một số giao dịch nhất định trong một khoảng thời gian nhất định. Nó sẽ rất có ích với các ứng dụng như blockchain game để giúp tăng trải nghiệm liên tục cho người dùng. Ta cũng hoàn toàn có thể triển khai các logic litmit khác trên các session keys này.

trusted-session

Automatic payments: Ta có thể cho phép các bên cung cấp dịch vụ rút tiền từ account của ta theo thời gian và số lượng cụ thể. Nó giống như việc ta trả tiền hàng tháng subscription cho các dịch vụ như Netflix, Spotify vậy.

Fee abstraction

Hiện tại các EOA trực tiếp gửi giao dịch và trả phí gas bằng ETH. Với việc trừu tượng hoá việc trả phí, ta có thể triển khai nhiều cách trả phí khác nhau cho người dùng:

Non-ETH gas payments: Linh hoạt trong trả phí gas bằng ERC-20 token, không nhất thiết user phải có ETH trong tài khoản nữa.

ethless-transaction

Gas-sponsoring hay Gasless transaction: các hệ thống, hoặc các nhà tài trợ có thể thay user trả phí giao dịch. Điều này sẽ rất có lợi để các ứng dụng thu hút những newbie vào sử dụng khi họ không cần biết chút gì về gas, web3, crypto hay blockchain gì cả.

gasless-transaction

Nonce abstraction

EOA account lưu trữ một giá trị nonce - là số lượng transaction mà account đó đã thực hiện. Mỗi lần thực hiện một transaction, nonce bắt buộc tăng lên 1. Điều này để nhằm giải quyết bài toán replaying transaction giống nhau để chiếm đoạt tiền (đọc thêm tại replaying attack). Tuy nhiên nonce của EOA hoạt động theo FIFO, tức first in first out; đây là một cách hoạt động không hiệu quả về mặt performance, vì transaction trước buộc phải hoàn thành thì transaction sau mới có thể được thực hiện. Do đó nếu transaction trước bị tắc (có thể do trả phí gas quá thấp), thì các transaction sau sẽ phải chờ đợi rất lâu, hoặc bị reject.

Nonce abstraction cho phép ta có thể tạo ra được các mô hình replay protection tuỳ chỉnh (thay vì bắt buộc hệ thống nonce phải theo thứ tự như trong Ethereum). Ví dụ ta có thể có một mô hình nonce cho phép thực hiện song song nhiều transaction, nó sẽ giúp giảm tắc nghẽn transaction như bên trên đi rất nhiều.

nonce-abstraction

Tuy nhiên việc implement nonce abstraction sẽ rất khó trong thực tế và nó có khả năng gây ra những breaking change ảnh hưởng tới bảo mật của cả hệ thống (như tính duy nhất của transaction hash).

Đây chính là lúc ta cần đến batched transactions.

Vì smart contract có thể thực hiện được nhiều transaction cùng một lúc (thực tế là gom vào trong cùng 1 transaction), nên ta sẽ không cần một cơ chế phức tạp để thay đổi thiết kế của nonce làm gì, đơn giản cứ gom vào làm một rồi thực hiện một lần là xong.

Ví dụ ta có 2 transaction A và B như sau:

tx A: approve cho Uniswap dùng token của mình
tx B: tiến hành swap trên Uniswap

bằng việc sử dụng transaction batching, ta có thể gom cả A và B trong cùng một hàm khác, rồi thực hiện hàm đó một lần mà thôi. Kết quả là vừa nhanh hơn, lại giảm được gas, cool?

batched-transaction

How will account abstraction be implemented?

Đến đây thì ta đã có thể nắm được account abstraction là gì và nó mang lại những lợi ích gì bằng cách nào. Tuy nhiên ta chưa thực sự biết được là làm thế nào để ta có thể thực sự tạo ra được các bản thực thi thực tế của account abstraction; hay nói cách khác về mặt kỹ thuật thì ta implement account abstraction như thế nào?

Trong phần này ta sẽ đi qua vài mô hình triển khai account abstraction phổ biến đã được đề xuất.

EIP-2771: account abstraction sử dụng meta-transactions

EIP-2771 đề xuất concept sử dụng meta-transaction để một bên thứ 3 có thể tiến hành trả phí gas cho giao dịch. Đề xuất này không làm thay đổi Ethereum protocol. Ý tường là transaction sẽ được kí và gửi tới một Forwarder contract. Forwarder là một trusted entity trên mạng lưới, nó sẽ validate transaction trước khi chuyển nó đến gas relay. Hoạt động này diễn ra off-chain và không phát sinh chi phí. Gas relay sẽ tiếp tục đưa transaction qua cho Recipient contract, trả phí gas cần thiết để transaction có thể thực thi trên Ethereum. Transaction sẽ được thực thi nếu Recipient biết và trust Forwarder. Đây chính là mô hình gasless-transaction.

EIP-2938: thay đổi Ethereum protocol để support account abstraction

EIP-2938 đề xuất thay đổi Ethereum protocol và thêm một loại transaction mới: AA_TX_TYPE, sẽ bao gồm 3 trường: nonce, target và data, trong đó nonce vẫn có vai trò là transaction counter, target là địa chỉ của entry point contract và data là dữ liệu bytecode truyền cho EVM. Để thực hiện transaction, hai OPCODE mới sẽ được thêm vào EVM: NONCE và PAYGAS. NONCE opcode sẽ track transaction sequence và PAYGAS sẽ tính toán và rút lượng gas cần thiết để thực hiện transaction từ contract balance. Những feature mới này sẽ cho phép Ethereum có thể native support smart contract wallet.

Hiện tại EIP này đang không được triển khai vì nó làm thay đổi Ethereum protocol. Cộng đồng đang ủng hộ hơn với đề xuất EIP-4337 vì không yêu cầu phải thay đổi Ethereum protocol.

EIP-3074: upgrade EOA thành account abstraction

EIP-3074 nhằm mục đích upgrade EOA trở thành programmable account, bằng cách cho phép nó delegate quyền điều khiển tới một smart contract. Theo đó smart contract có thể ký giao dịch khởi nguồn từ EOA. Bằng cách này thì các feature như gas-sponsoring hay batched transaction có thể được triển khai. Để thực hiện được việc này, ta cần thêm vào EVM hai OPCODE: AUTH và AUTHCALL. Một khi được uỷ quyền bởi user thông qua AUTH, contract được uỷ quyền (gọi là invoker) có thể gửi transaction dưới danh nghĩa của user (tức msg.sender là user) thông qua AUTHCALL.

Có EIP-5003 là bản mở rộng của EIP-3074 thêm vào một OPCODE nữa là AUTH_USURP để upgrade vĩnh viễn một EOA thành một smart contract account. Tuy nhiên hiện tại EIP này cũng đang không được triển khai vì nó làm thay đổi Ethereum protocol.

EIP-4337: account abstraction mà không làm thay đổi Ethereum protocol

EIP-4337 đề xuất ERC-4337, có thể coi là tiến đầu tiên tới việc tạo native smart contract wallet một cách decentralized mà không làm thay đổi Ethereum Protocol. Thay vì việc thay đổi consensus layer để support smart contract wallet, một hệ thống riêng biệt được thêm vào để hỗ trợ giao thức giao dịch thông thường. Hệ thống này được xây dựng quanh một object được gọi là UserOperation, thực hiện đóng gói những action kèm chữ ký của user. Các UserOperation này sau đó sẽ được broadcast tới một hệ thống mempool riêng biệt, với những validator riêng biệt để chúng được đóng gói lại thành các bundle. Bundle transaction gồm hàng loạt các UserOperation khác nhau sẽ được đưa vào trong Ethereum giống như một transaction thông thường bởi các validator của mạng Ethereum.

ERC-4337 cũng thay đổi cách mà các smart contract wallet hoạt động. Thay vì mỗi wallet đều implement lại những logic phức tạp chung để đảm bảo security cho ví, những function đó được đưa hẳn ra ngoài và giao nhiệm vụ cho một trusted contract có tên là EntryPoint. EntryPoin sẽ handle các hoạt động như trả phí, và thực hiện EVM code. Do đó wallete developer sẽ chỉ cần tập trung vào việc cung cấp các trải nghiệm người dùng tốt nhất mà thôi.

ERC-4337 EntryPoint cũng đã được deploy lên Ethereum Mainnet vào 1st March 2023 tại đây.

ERC-4337 wallets

Curent progress

Đã có nhiều smart contract wallet trên thị trường, song sẽ cần rất nhiều các bản upgrade nữa để chúng thực sự trở nên decentralized và permissionless. Trong số đó EIP-4337 được xem là đề xuất tốt nhất vì nó không yêu cầu sự thay đổi nào trong Ethereum protocol, do đó nó có thể nhanh chóng được implement. Các đề xuất khác cần phải thay đổi Ethereum protocol hiện tại thì đang không được phát triển tích cực lắm, do đó có thể sẽ cần thời gian dài nữa mới thấy các sản phẩm triển khai các đề xuất này xuất hiện.

Account Abstraction