Tài khoản thông minh trong DeFi, trò chơi, DAOs và tiếp cận người dùng

Trong DeFi, tài khoản thông minh cho phép người dùng nhóm nhiều hành động - chẳng hạn như phê duyệt, gửi tiền, sử dụng đòn bẩy và rút tiền - vào một giao dịch nguyên tử. Điều này loại bỏ các phê duyệt trung gian thường khiến người dùng dễ bị lừa đảo và tăng hiệu suất UX trong các giao thức có quy trình phức tạp, chẳng hạn như kho tùy chọn hoặc canh tác lợi nhuận sử dụng đòn bẩy. Safe, một trong những nền tảng ví hợp đồng đầu tiên, cung cấp sức mạnh cho hàng ngàn tài khoản DAO và quỹ hiện đang hưởng lợi từ các tính năng mô-đun ERC-4337. Các nhà phát triển có thể gắn các plugin để tự động hóa việc phân phối, xác định logic phê duyệt đa tầng, hoặc cho phép phục hồi xã hội mà không cần triển khai lại hợp đồng cơ sở.

Trong trò chơi, giá trị đề xuất nằm ở tính tương tác theo phiên và việc sử dụng tài sản một cách liền mạch. Người chơi có thể được cấp một tài khoản thông minh tại thời điểm gia nhập, liên kết với một email, thiết bị hoặc nhà cung cấp OAuth, và bắt đầu tương tác với các NFT trong trò chơi hoặc token có thể thay thế mà không cần chạm vào MetaMask hay biết về phí gas là gì. Nhà tài trợ trò chơi thiết lập một paymaster để chi trả phí gas, trong khi tài khoản thông minh xử lý việc ủy quyền khóa phiên để các hành động trong trò chơi có thể được thực hiện mà không làm gián đoạn người dùng. Các dự án như Immutable và Ronin đã khám phá mô hình này để giảm thiểu ma sát UX và đưa trò chơi vào các môi trường di động.

Tài khoản thông minh cũng đơn giản hóa việc tham gia DAO. Ví bỏ phiếu có thể thi hành giới hạn theo đề xuất, ngăn chặn việc ủy quyền quá mức, hoặc cấp quyền bỏ phiếu tạm thời dựa trên các chỉ số ngoại tuyến. Điều này cho phép quản trị có cấu trúc mà không phụ thuộc vào các kịch bản bên thứ ba hay tích hợp snapshot không phải gốc. Thêm vào đó, quy trình tiếp nhận được cải thiện thông qua việc tài trợ gas và tạo ví nhúng, nơi một ứng dụng có thể cung cấp một ví mới khi đăng nhập, cấp vốn cho nó, và khởi động sự tham gia của người dùng mà không cần tài trợ thủ công. ZeroDev và thirdweb đã phổ biến các quy trình này bằng cách trừu tượng hóa sự tương tác giữa bundler và paymaster thành một vài dòng mã front-end.

Khả năng kết hợp với dApps: Truy cập và phê duyệt dựa trên phiên

Khả năng kết hợp là một trong những kết quả mạnh mẽ nhất của trừu tượng hóa tài khoản. Các dApp giờ đây có thể tương tác với các tài khoản thông minh theo cách tôn trọng quyền hạn theo ngữ cảnh. Ví dụ, một nền tảng cho vay có thể yêu cầu một khóa phiên để cho phép bảo vệ thanh lý tự động, chỉ hoạt động dưới một số ngưỡng lãi suất nhất định. Một dApp staking có thể được đưa vào danh sách trắng như một hợp đồng đáng tin cậy, bỏ qua nhu cầu người dùng phải phê duyệt token mỗi lần. Những mẫu này giảm thiểu việc ký lặp lại, loại bỏ rủi ro dư thừa và cho phép các ứng dụng cấu trúc quy trình làm việc hành xử giống như phần mềm truyền thống - đã được phê duyệt trước, mượt mà và bền bỉ trước sự lạm dụng không mong muốn.

Truy cập dựa trên phiên cũng cho phép ủy quyền mà không cần từ bỏ quyền sở hữu. Một thị trường có thể nhận quyền phép ngắn hạn để liệt kê và cập nhật giá, trong khi một ứng dụng ví có thể truy cập các giới hạn chi tiêu và ghi đè khóa chỉ trong một số giờ hoặc điều kiện nhất định. Điều này cho phép các hồ sơ bảo mật lập trình mô phỏng các quyền cấp doanh nghiệp trong một khuôn khổ tự bảo quản, mở ra các trường hợp sử dụng cho các nhóm, gia đình hoặc tổ chức có nhu cầu truy cập phức tạp.

Nhà tài trợ gas (Paymasters) và quy trình tiếp nhận

Các paymaster là những người đóng vai trò quan trọng trong việc tạo điều kiện cho việc tiếp cận liền mạch. Bằng cách thanh toán phí gas thay mặt cho người dùng, họ giúp cho những người tham gia mới có thể tương tác với các ứng dụng blockchain mà không cần sở hữu ETH hoặc tìm hiểu về cơ chế phí gas. Những hợp đồng này thường được cấu hình với logic xác định khi nào và cho ai phí gas được thanh toán. Một số paymaster chỉ hoàn trả cho các hoạt động đã được đưa vào danh sách trắng; những người khác thực hiện giới hạn tỷ lệ hoặc từ chối tài trợ cho các mục đã nằm trong danh sách đen.

Trong quá trình onboarding, một dApp có thể gộp việc tạo một tài khoản thông minh, yêu cầu token và tương tác với dApp - tất cả dưới một thao tác người dùng duy nhất. Thirdweb và Biconomy cho phép mẫu này thông qua các pipeline bundler-paymaster được lưu trữ. Cách tiếp cận này hiện đã được áp dụng rộng rãi trong các nền tảng xã hội Web3, ứng dụng đúc NFT và trò chơi di động nơi mà sự đồng nhất trải nghiệm người dùng với Web2 là rất quan trọng. Trong mô hình này, chi phí gas có thể được trợ cấp bởi ứng dụng hoặc được tích hợp vào các động lực kinh tế đi kèm - ví dụ, thu hồi phí thông qua các giao dịch trong trò chơi hoặc giới thiệu xã hội.

Hạn chế: chi phí, an ninh, độ trưởng thành của công cụ, sự chấp nhận tiêu chuẩn

Mặc dù có những lợi ích, tài khoản thông minh lại mang đến sự phức tạp và chi phí bổ sung mới. Chi phí gas để tạo ra và tương tác với các tài khoản thông minh vẫn cao hơn so với EOAs, đặc biệt là trên mainnet. Bởi vì mỗi tài khoản thông minh là một hợp đồng đã triển khai, nó phải chịu chi phí triển khai cơ bản và tiền thuê lưu trữ. Mặc dù một số chuỗi như Base và zkSync có phí gas thấp hơn, việc áp dụng vẫn bị hạn chế bởi sự nhạy cảm với chi phí trong các trường hợp sử dụng có giá trị thấp.

An ninh vẫn là một mối quan tâm. Trong khi các tài khoản thông minh có thể nhúng các quy tắc tiên tiến, chúng cũng làm tăng bề mặt tấn công. Các người trả tiền độc hại, logic xác thực lỗi hoặc các plugin thiết kế kém có thể giới thiệu các lỗ hổng vượt qua các giả định tiêu chuẩn về hành vi ví. Hơn nữa, vì nhiều khung tài khoản thông minh sử dụng các mẫu proxy hoặc các mô-đun có thể nâng cấp, việc đảm bảo tính toàn vẹn của mã theo thời gian đòi hỏi phải có sự kiểm toán nghiêm ngặt và quản trị nâng cấp.

Công cụ, mặc dù đang cải thiện, nhưng vẫn bị phân mảnh. Các SDK khác nhau có những giả định khác nhau về tương tác với bundler, mô hình paymaster và logic khóa phiên. Vẫn chưa có tiêu chuẩn phổ quát cho các sự kiện ví, mã lỗi hoặc chiến lược dự phòng khi hợp đồng EntryPoint không thực hiện được một UserOperation. Kết quả là, các dApp phải kiểm tra logic của chúng với nhiều loại tài khoản khác nhau để đảm bảo tính tương thích. Vấn đề này càng trở nên nghiêm trọng hơn do thiếu sự chấp nhận tiêu chuẩn rộng rãi; mặc dù ERC-4337 đã hoạt động, nhưng nhiều ứng dụng và ví phổ biến vẫn chưa tích hợp nó.

Con đường phía trước: Kiến trúc tài khoản mô-đun ERC-6900

Để giải quyết sự phân mảnh và thúc đẩy khả năng tương tác, các nhà phát triển Ethereum đã đề xuất ERC-6900: một tiêu chuẩn giao diện tài khoản mô-đun. Khác với các bản dự thảo trước đó tập trung vào các triển khai cụ thể, ERC-6900 định nghĩa cách một tài khoản thông minh có thể đăng ký, kết hợp và xác minh các mô-đun. Điều này cho phép các nhà phát triển xây dựng các thành phần nhỏ, có thể tái sử dụng—chẳng hạn như bộ xác thực chữ ký, chính sách người trả phí, hoặc kiểm tra điều kiện tiên quyết—và gắn chúng vào bất kỳ tài khoản nào hỗ trợ giao diện.

Với ERC-6900, một tài khoản thông minh trở thành sự kết hợp của các plugin thay vì một hợp đồng đơn lẻ. Kiến trúc này cho phép cập nhật dễ dàng hơn, kiểm toán tốt hơn và các đánh giá bảo mật được chia sẻ. Các nhà phát triển có thể công bố các mô-đun đã được xác minh lên các danh mục và có thể được sử dụng lại trên các ví, tăng tính chuẩn hóa và giảm nỗ lực phát triển. Mô hình mô-đun cũng phù hợp với các mục tiêu UX của ví, nơi người dùng có thể muốn thêm các tính năng như xác thực hai yếu tố, phê duyệt liên hệ đáng tin cậy, hoặc chuyển nhượng có điều kiện mà không cần triển khai lại toàn bộ tài khoản của họ.

Trong dài hạn, việc chuyển sang các tài khoản thông minh mô-đun sẽ tạo điều kiện cho khả năng tương tác giữa các chuỗi. Các khung sẽ có thể dịch các mô-đun giữa Ethereum, zk-rollups, và L2 mà không cần sao chép logic. Thiết kế mô-đun này, kết hợp với sự hỗ trợ ngày càng tăng của các trình gói và kinh tế paymaster đang phát triển, chỉ ra một tương lai nơi các tài khoản thông minh trở thành mô hình ví mặc định—không phải là ngoại lệ.