Thiết kế tài khoản hợp đồng thông minh mô-đun: Giải quyết các thách thức kỹ thuật trong triển khai thực tế
Tuyển chọn TechFlowTuyển chọn TechFlow
Thiết kế tài khoản hợp đồng thông minh mô-đun: Giải quyết các thách thức kỹ thuật trong triển khai thực tế
Bằng cách tận dụng ngăn xếp tài khoản hợp đồng thông minh dạng mô-đun, các nhà cung cấp ví và dApp có thể thoát khỏi sự phức tạp trong bảo trì kỹ thuật.
Chuyên sâu báo cáo Web3Tác giả: Rui S (SevenX Ventures)
Biên dịch: TechFlow
Giới thiệu
Sự chuyển đổi từ tài khoản do bên ngoài sở hữu (EOA) sang tài khoản hợp đồng thông minh (SCA) đang phát triển mạnh mẽ và nhận được sự ủng hộ của nhiều người hâm mộ, bao gồm cả Vitalik. Mặc dù tạo ra sự phấn khích, việc áp dụng SCA vẫn chưa phổ biến như EOA. Các vấn đề then chốt bao gồm thách thức từ thị trường gấu, lo ngại về việc di dời, vấn đề ký tên, chi phí gas và đặc biệt là những khó khăn kỹ thuật.
Một trong những lợi thế quan trọng nhất của Trừu tượng Tài khoản (AA) là khả năng tùy chỉnh chức năng bằng mã. Tuy nhiên, một thách thức kỹ thuật lớn là tính không tương tác giữa các chức năng AA, điều này gây ra sự phân mảnh, cản trở tích hợp và mở ra nguy cơ bị khóa nhà cung cấp. Ngoài ra, đảm bảo an toàn khi nâng cấp và kết hợp chức năng cùng lúc có thể rất phức tạp.
Sự xuất hiện của Trừu tượng Tài khoản theo mô-đun là một phần nhỏ trong phong trào AA rộng lớn hơn, phương pháp đổi mới này tách biệt tài khoản thông minh khỏi các chức năng tùy chỉnh của nó. Mục tiêu là xây dựng một cấu trúc mô-đun để phát triển ví với đa dạng chức năng, tích hợp an toàn và liền mạch. Trong tương lai, nó có thể tạo ra một "cửa hàng ứng dụng" tự do cho tài khoản hợp đồng thông minh, khiến ví và dApp không còn tập trung vào việc xây dựng chức năng mà thay vào đó là trải nghiệm người dùng.
Tổng quan về AA
Các EOA truyền thống đặt ra nhiều thách thức như cụm từ khôi phục, gas, liên chuỗi và nhiều giao dịch riêng lẻ. Chúng ta chưa bao giờ định nghĩa sự phức tạp, nhưng thực tế thì blockchain không hề đơn giản đối với đại chúng.
Trừu tượng tài khoản tận dụng tài khoản hợp đồng thông minh, cho phép xác minh và thực thi lập trình được, cho phép người dùng phê duyệt một loạt giao dịch chỉ trong một lần thay vì phải ký và phát sóng từng giao dịch, đồng thời mở rộng thêm nhiều chức năng khác. Nó mang lại lợi ích cho trải nghiệm người dùng (ví dụ: trừu tượng hóa gas, khóa phiên), chi phí (ví dụ: xử lý giao dịch theo lô) và bảo mật (ví dụ: khôi phục xã hội, đa chữ ký). Hiện tại, có hai cách triển khai AA:
-
Tầng giao thức: Một số giao thức cung cấp hỗ trợ AA bản địa, ZKsync xử lý giao dịch bất kể đến từ EOA hay SCA đều theo quy trình giống nhau, sử dụng một mempool duy nhất và quy trình giao dịch để hỗ trợ AA, trong khi Starknet đã loại bỏ hoàn toàn EOA, tất cả tài khoản đều là SCA, và họ có ví hợp đồng thông minh bản địa như Argent.
-
Tầng hợp đồng: Đối với Ethereum và các L2 tương đương, ERC4337 giới thiệu một điểm đầu giao dịch riêng biệt để hỗ trợ AA mà không cần thay đổi tầng đồng thuận. Các dự án như Stackup, Alchemy, Etherspot, Biconomy, Candide và Plimico đang xây dựng cơ sở hạ tầng bundler, trong khi các dự án như Safe, Zerodev, Etherspot và Biconomy đang phát triển stack và SDK.
Khó khăn trong việc áp dụng SCA
Chủ đề Trừu tượng Tài khoản (AA) đã được thảo luận từ năm 2015 và được đẩy lên trung tâm chú ý vào năm nay nhờ ERC4337. Tuy nhiên, số lượng tài khoản hợp đồng thông minh đã triển khai vẫn còn xa mới đạt tới mức độ phổ biến của EOA.
Hãy đi sâu vào nghịch lý này:
-
Ảnh hưởng của thị trường gấu:
Mặc dù AA mang lại những lợi ích như đăng nhập liền mạch và trừu tượng hóa gas, nhưng trong bối cảnh thị trường gấu hiện tại, người dùng chủ yếu là những người dùng EOA đã được giáo dục chứ không phải người dùng mới, do đó không tạo động lực cho dApp và ví. Dù vậy, một số ứng dụng hàng đầu vẫn đang dần áp dụng AA, ví dụ như Cyberconnect thông qua hệ thống AA và giải pháp không gas của họ, đã thúc đẩy khoảng 360.000 UserOps (giao dịch AA) chỉ trong một tháng.
-
Rào cản di dời:
Đối với các ví và ứng dụng đã tích lũy người dùng và tài sản, việc di dời tài sản một cách an toàn và thuận tiện vẫn là một thách thức. Tuy nhiên, sáng kiến như EIP-7377 cho phép EOA khởi tạo giao dịch di dời một lần.
-
Vấn đề ký tên:
Bản thân hợp đồng thông minh không thể ký tin nhắn một cách tự nhiên vì nó không có khóa riêng như EOA. Những nỗ lực như ERC1271 làm cho việc ký tên trở nên khả thi, nhưng trước giao dịch đầu tiên, việc ký tin nhắn không hoạt động, điều này gây khó khăn cho các ví sử dụng triển khai phản thực tế. Trong khi đó, ERC-6492 do Ambire đề xuất là người kế nhiệm tương thích ngược với ERC-1271, có thể giải quyết vấn đề trước đó.
-
Chi phí Gas:
Việc triển khai, mô phỏng và thực thi SCA phát sinh chi phí cao hơn so với EOA tiêu chuẩn. Điều này trở thành rào cản cho việc áp dụng. Tuy nhiên, một số thử nghiệm đã được thực hiện, ví dụ như tách rời việc tạo tài khoản khỏi UserOp, hoặc cân nhắc loại bỏ salt tài khoản và kiểm tra tồn tại để giảm chi phí.
-
Khó khăn kỹ thuật:
Nhóm ERC-4337 đã xây dựng kho lưu trữ eth-infinitism, cung cấp triển khai cơ bản cho các nhà phát triển. Tuy nhiên, khi chúng ta phát triển các chức năng chi tiết hoặc chuyên biệt hơn cho các trường hợp sử dụng khác nhau, việc tích hợp và giải mã trở nên thách thức.
Trong bài viết này, chúng tôi sẽ đi sâu vào vấn đề thứ năm: Khó khăn kỹ thuật.
Tài khoản hợp đồng thông minh theo mô-đun để giải quyết khó khăn kỹ thuật
Chi tiết hơn về khó khăn kỹ thuật như sau:
-
Phân mảnh: Hiện tại, các chức năng khác nhau được kích hoạt theo nhiều cách khác nhau, dù là qua SCA cụ thể hay hệ thống plugin độc lập. Mỗi cái tuân theo tiêu chuẩn riêng, buộc các nhà phát triển phải lựa chọn nền tảng nào để hỗ trợ. Điều này có thể dẫn đến bị khóa nền tảng hoặc nỗ lực trùng lặp.
-
Bảo mật: Mặc dù sự linh hoạt giữa tài khoản và chức năng mang lại lợi ích, nhưng cũng có thể làm trầm trọng thêm các vấn đề bảo mật. Các chức năng có thể được kiểm toán tập thể, nhưng thiếu đánh giá độc lập có thể làm tăng rủi ro lỗ hổng ở cấp tài khoản.
-
Khả năng nâng cấp: Khi chức năng phát triển, việc giữ khả năng thêm, thay thế hoặc xóa chức năng là rất quan trọng. Việc triển khai lại các chức năng hiện tại mỗi lần cập nhật sẽ làm phát sinh độ phức tạp.
Để giải quyết các vấn đề này, chúng ta cần hợp đồng có thể nâng cấp để đảm bảo nâng cấp an toàn và hiệu quả, lõi có thể tái sử dụng để nâng cao hiệu quả phát triển tổng thể, và các giao diện chuẩn hóa để đảm bảo tài khoản hợp đồng có thể chuyển đổi liền mạch giữa các giao diện khác nhau.
Các thuật ngữ này hội tụ về một khái niệm chung: Xây dựng kiến trúc Trừu tượng Tài khoản theo mô-đun (Modular AA).
Modular AA là một lĩnh vực nhỏ trong phong trào AA rộng lớn hơn, hình dung việc mô-đun hóa tài khoản thông minh nhằm phục vụ người dùng một cách tùy chỉnh, và cho phép các nhà phát triển tăng cường chức năng một cách liền mạch với ít hạn chế nhất.
Tuy nhiên, trong mọi ngành, việc xây dựng và phổ biến tiêu chuẩn mới đều là một thách thức lớn. Trước khi mọi người chấp nhận giải pháp chính, giai đoạn ban đầu có thể chứng kiến nhiều giải pháp khác nhau. Tuy nhiên, đáng khích lệ là cả các nhóm SDK 4337, nhà phát triển ví, đội ngũ cơ sở hạ tầng lẫn nhà thiết kế giao thức đều đang cùng nhau thúc đẩy quá trình này.
Cấu trúc mô-đun: Tài khoản chính và mô-đun
Delegatecall và Hợp đồng Proxy
Gọi ngoài và delegatecall:
Mặc dù delegatecall tương tự call, nhưng nó không thực thi hợp đồng đích trong bối cảnh riêng của mình mà là trong trạng thái hiện tại của hợp đồng gọi. Nghĩa là mọi thay đổi trạng thái do hợp đồng đích thực hiện sẽ được áp dụng vào bộ nhớ của hợp đồng gọi.
Để đạt được cấu trúc có thể tổ hợp và nâng cấp, cần có một kiến thức cơ bản gọi là “hợp đồng proxy”.
-
Hợp đồng Proxy: Hợp đồng thông thường lưu trữ logic và trạng thái, và không thể cập nhật sau khi triển khai. Hợp đồng proxy sử dụng delegatecall để gọi một hợp đồng khác. Bằng cách tham chiếu đến triển khai hàm, nó thực thi trong trạng thái hiện tại của hợp đồng proxy.
-
Trường hợp sử dụng: Trong khi hợp đồng proxy giữ nguyên, bạn có thể triển khai triển khai mới phía sau nó. Hợp đồng proxy được dùng để nâng cấp, và chi phí triển khai cũng như duy trì trên blockchain công cộng thấp hơn.
Kiến trúc bảo mật
Safe là một cơ sở hạ tầng hàng đầu cho tài khoản thông minh mô-đun, được thiết kế để cung cấp tính bảo mật và linh hoạt đã được kiểm chứng trong thực tiễn, cho phép các nhà phát triển tạo ra các ứng dụng và ví đa dạng. Đáng chú ý, nhiều nhóm đang xây dựng dựa trên Safe hoặc lấy cảm hứng từ nó. Biconomy ra mắt tài khoản của mình bằng cách mở rộng Safe với 4337 bản địa và đa chữ ký 1/1. Safe đã triển khai hơn 164.000 hợp đồng và nắm giữ hơn 30,7 tỷ giá trị, rõ ràng là lựa chọn hàng đầu trong lĩnh vực này.
Cấu trúc của Safe
-
Hợp đồng tài khoản Safe: Hợp đồng proxy chính (có trạng thái)
Tài khoản Safe là một hợp đồng proxy vì nó sử dụng delegatecall để gọi một hợp đồng singleto. Tài khoản Safe chứa chủ sở hữu, ngưỡng và địa chỉ triển khai, được thiết lập làm các biến của proxy, từ đó định nghĩa trạng thái của nó.
-
Hợp đồng Singleto: Trung tâm tích hợp (không trạng thái)
Singleto cung cấp dịch vụ cho tài khoản Safe, tích hợp và định nghĩa các tích hợp khác nhau, bao gồm plugin, Hook, bộ xử lý hàm và bộ xác thực chữ ký.
-
Hợp đồng mô-đun: Logic và chức năng tùy chỉnh
Mô-đun rất mạnh mẽ. Là một dạng mô-đun, plugin có thể định nghĩa các chức năng khác nhau như dòng thanh toán, cơ chế khôi phục và khóa phiên, và có thể lấy dữ liệu off-chain như cầu nối giữa Web2 và Web3. Các mô-đun khác như Hook đóng vai trò bảo vệ an toàn, và bộ xử lý hàm phản hồi bất kỳ lệnh nào.
Khi chúng ta sử dụng Safe xảy ra điều gì
-
Hợp đồng có thể nâng cấp:
Mỗi khi một plugin mới được giới thiệu, cần triển khai một singleto mới. Người dùng giữ quyền tự chủ nâng cấp Safe lên phiên bản singleto mong muốn phù hợp với sở thích và yêu cầu của họ.
-
Mô-đun có thể tổ hợp và tái sử dụng:
Tính chất mô-đun của plugin cho phép các nhà phát triển xây dựng chức năng độc lập. Sau đó, họ có thể tự do lựa chọn và kết hợp các plugin này theo trường hợp sử dụng riêng, thúc đẩy phương pháp tùy chỉnh cao độ.
ERC-2535 Diamond Proxy
Về ERC2535 và Diamond Proxy
ERC2535 chuẩn hóa Diamond Proxy, một hệ thống hợp đồng thông minh mô-đun có thể nâng cấp/mở rộng sau khi triển khai và gần như không giới hạn kích thước. Cho đến nay, nhiều nhóm đã lấy cảm hứng từ nó, ví dụ như Kernel của Zerodev và thí nghiệm Soul Wallet.
Cấu trúc Diamond là gì
-
Hợp đồng Diamond: Hợp đồng proxy chính (có trạng thái) Diamond là một hợp đồng proxy, sử dụng delegatecall để gọi hàm từ triển khai của nó.
-
Hợp đồng mô-đun/plugin/facet: Logic và chức năng tùy chỉnh (không trạng thái) Mô-đun hay còn gọi là facet là một hợp đồng không trạng thái, có thể triển khai chức năng của nó vào một hoặc nhiều Diamond. Chúng là các hợp đồng độc lập, có thể chia sẻ hàm nội bộ, thư viện và biến trạng thái.
Khi chúng ta sử dụng Diamond xảy ra điều gì
-
Hợp đồng có thể nâng cấp: Diamond cung cấp phương pháp hệ thống để cô lập các plugin khác nhau và kết nối chúng lại với nhau, đồng thời trực tiếp thêm/thay thế/xóa bất kỳ plugin nào thông qua hàm diamondCut. Theo thời gian, số lượng plugin có thể thêm vào Diamond là không giới hạn.
-
Plugin mô-đun và có thể tái sử dụng: Một plugin đã triển khai có thể được sử dụng bởi bất kỳ số lượng Diamond nào, giúp giảm đáng kể chi phí triển khai.
Sự khác biệt giữa phương pháp Tài khoản Thông minh Safe và phương pháp Diamond
Có nhiều điểm tương đồng giữa kiến trúc Safe và Diamond, cả hai đều dựa vào hợp đồng proxy làm lõi và tham chiếu đến hợp đồng logic để đạt được khả năng nâng cấp và mô-đun hóa.
Tuy nhiên, điểm khác biệt chính nằm ở cách xử lý hợp đồng logic. Chi tiết hơn như sau:
-
Linh hoạt: Khi bật plugin mới, Safe cần triển khai lại hợp đồng singleto để thực hiện thay đổi trong proxy của nó. Ngược lại, Diamond thực hiện điều này trực tiếp thông qua hàm diamondCut trong proxy của nó. Sự khác biệt về phương pháp này có nghĩa là Safe giữ mức độ kiểm soát cao hơn, trong khi Diamond mang lại tính linh hoạt và mô-đun hóa mạnh mẽ hơn.
-
Bảo mật: Hiện tại, cả hai kiến trúc đều sử dụng delegatecall, có thể cho phép mã bên ngoài thao túng bộ nhớ của hợp đồng chính. Trong kiến trúc Safe, delegatecall trỏ đến một hợp đồng logic duy nhất, trong khi Diamond sử dụng delegatecall giữa nhiều hợp đồng mô-đun (plugin). Do đó, một plugin độc hại có thể ghi đè lên plugin khác, gây ra rủi ro xung đột bộ nhớ, có thể làm tổn hại đến tính toàn vẹn của proxy.
-
Chi phí: Sự linh hoạt vốn có trong phương pháp Diamond đi kèm với các vấn đề bảo mật gia tăng. Điều này làm tăng yếu tố chi phí, đòi hỏi kiểm toán toàn diện mỗi lần thêm plugin mới. Điều then chốt là đảm bảo các plugin này không can thiệp vào chức năng của nhau, đây là một thách thức đối với các doanh nghiệp vừa và nhỏ cố gắng duy trì tiêu chuẩn bảo mật mạnh mẽ.
"Phương pháp Tài khoản Thông minh Safe" và "Phương pháp Diamond" là các ví dụ về cấu trúc khác nhau liên quan đến proxy và mô-đun. Cân bằng giữa linh hoạt và bảo mật là cực kỳ quan trọng, và hai phương pháp này có tiềm năng bổ sung cho nhau trong tương lai.
Thứ tự mô-đun: Bộ xác thực, Bộ thực thi và Hook
Hãy mở rộng thảo luận bằng cách giới thiệu ERC6900 do nhóm Alchemy đề xuất, tiêu chuẩn này chịu ảnh hưởng từ Diamond và được điều chỉnh đặc biệt cho ERC-4337. Nó giải quyết thách thức mô-đun trong tài khoản thông minh bằng cách cung cấp giao diện chung và phối hợp công việc giữa các nhà phát triển plugin và ví.
Khi nói đến quy trình giao dịch AA, có ba quá trình chính: Xác thực, Thực thi và Hook. Như đã thảo luận trước đó, việc gọi mô-đun thông qua tài khoản proxy có thể quản lý các bước này. Mặc dù các dự án khác nhau có thể dùng tên gọi khác nhau, nhưng nắm vững logic cơ bản tương tự là rất quan trọng.
-
Xác thực: Đảm bảo tính xác thực và quyền hạn của người gọi đối với tài khoản.
-
Thực thi: Thực hiện bất kỳ logic tùy chỉnh nào tài khoản cho phép.
-
Hook: Là mô-đun chạy trước hoặc sau một hàm khác. Nó có thể thay đổi trạng thái hoặc khiến toàn bộ cuộc gọi bị hủy.
Việc tách biệt mô-đun theo logic khác nhau là rất quan trọng. Phương pháp chuẩn hóa nên quy định cách viết các hàm xác thực, thực thi và Hook của tài khoản hợp đồng thông minh. Dù là Safe hay ERC6900, chuẩn hóa giúp giảm nhu cầu phát triển riêng biệt cho triển khai hoặc hệ sinh thái cụ thể, đồng thời ngăn chặn tình trạng bị khóa nhà cung cấp.
Phát hiện và bảo mật mô-đun
Một giải pháp đang phát triển mạnh là tạo ra nơi cho phép người dùng phát hiện các mô-đun đã được xác minh, chúng ta có thể gọi là “registry”. Registry này giống như một “cửa hàng ứng dụng”, nhằm thúc đẩy một thị trường mô-đun đơn giản nhưng sôi động.
Giao thức Safe{Core}
Giao thức Safe{Core} là một giao thức tài khoản hợp đồng thông minh mã nguồn mở, có thể tương tác, nhằm nâng cao khả năng tiếp cận cho nhiều nhà cung cấp và nhà phát triển thông qua các tiêu chuẩn và quy tắc được định nghĩa rõ ràng, đồng thời duy trì bảo mật mạnh mẽ.
-
Tài khoản: Trong giao thức Safe{Core}, khái niệm tài khoản là linh hoạt, không bị giới hạn bởi triển khai cụ thể nào. Điều này cho phép nhiều nhà cung cấp dịch vụ tài khoản tham gia.
-
Quản lý viên: Quản lý viên đóng vai trò điều phối giữa tài khoản, registry và mô-đun. Nó cũng chịu trách nhiệm về bảo mật, hoạt động như một lớp quyền hạn.
-
Registry: Registry định nghĩa thuộc tính bảo mật và thực thi các tiêu chuẩn mô-đun như ERC6900, nhằm tạo ra môi trường "cửa hàng ứng dụng" mở cho phát hiện và bảo mật.
-
Mô-đun: Mô-đun xử lý chức năng và được cung cấp dưới nhiều kiểu ban đầu như plugin, Hook, bộ xác thực chữ ký và bộ xử lý hàm. Miễn là đáp ứng tiêu chuẩn đã định, các nhà phát triển có thể đóng góp cho nó.
Thiết kế Rhinestone
Quá trình diễn ra như sau:
-
Tạo định nghĩa mẫu: Mẫu là cấu trúc dữ liệu được định nghĩa trước để chứng minh. Các doanh nghiệp có thể tùy chỉnh mẫu theo trường hợp sử dụng cụ thể.
-
Tạo mô-đun dựa trên mẫu: Hợp đồng thông minh được đăng ký làm mô-đun, lấy bytecode và chọn ID mẫu. Dữ liệu này sau đó được lưu trữ trong registry.
-
Lấy chứng minh cho mô-đun: Người chứng minh/kiểm toán viên có thể cung cấp chứng minh cho mô-đun theo mẫu. Các chứng minh này có thể bao gồm định danh duy nhất (UID) và tham chiếu đến các chứng minh khác để liên kết. Chúng có thể lan truyền trên chuỗi và xác minh xem ngưỡng cụ thể có được đáp ứng trên chuỗi mục tiêu hay không.
-
Sử dụng bộ phân tích để thực hiện logic phức tạp: Bộ phân tích là thiết lập tùy chọn trong mẫu. Chúng có thể được gọi khi tạo mô-đun, thiết lập hoặc thu hồi chứng minh. Những bộ phân tích này cho phép nhà phát triển tích hợp logic đa dạng và phức tạp trong khi vẫn giữ cấu trúc chứng minh.
-
Truy vấn thân thiện với người dùng: Truy vấn cung cấp cách cho người dùng truy cập thông tin bảo mật từ giao diện. EIP có thể được tìm thấy tại đây.
Mặc dù mô hình này vẫn còn ở giai đoạn sơ khai, nhưng nó có tiềm năng xây dựng một tiêu chuẩn theo cách phân tán và hợp tác. Registry của họ cho phép nhà phát triển đăng ký mô-đun, kiểm toán viên xác minh độ an toàn, ví tích hợp và người dùng dễ dàng tìm thấy mô-đun và kiểm tra thông tin chứng minh. Tương lai có thể có các ứng dụng sau:
-
Người chứng minh: Các thực thể đáng tin cậy như Safe có thể hợp tác với Rhinestone như người chứng minh cho mô-đun nội bộ. Đồng thời, các người chứng minh độc lập cũng có thể tham gia.
-
Nhà phát triển mô-đun: Khi một thị trường mở hình thành, nhà phát triển mô-đun có thể thương mại hóa công việc của họ thông qua registry.
-
Người dùng: Thông qua giao diện thân thiện như ví hoặc dApp, người dùng có thể xem thông tin mô-đun và ủy thác niềm tin cho các người chứng minh khác nhau.
Khái niệm "registry mô-đun" mang lại cơ hội kiếm tiền cho nhà phát triển plugin và mô-đun. Nó cũng có thể mở đường cho "thị trường mô-đun". Một số khía cạnh có thể do nhóm Safe giám sát, trong khi những khía cạnh khác có thể biểu hiện dưới dạng thị trường phi tập trung, mời mọi người đóng góp và cung cấp hồ sơ kiểm toán minh bạch. Bằng cách áp dụng cách này, chúng ta có thể tránh bị khóa nhà cung cấp và hỗ trợ mở rộng EVM bằng cách thu hút đối tượng rộng lớn hơn thông qua trải nghiệm người dùng tốt hơn.
Mặc dù các phương pháp này đảm bảo tính an toàn của từng mô-đun riêng lẻ, nhưng tính an toàn tổng thể của tài khoản hợp đồng thông minh không tuyệt đối. Việc kết hợp các mô-đun hợp pháp và chứng minh rằng chúng không xung đột bộ nhớ có thể là một thách thức, nhấn mạnh tầm quan trọng của ví hoặc cơ sở hạ tầng AA trong việc giải quyết các vấn đề như vậy.
Tổng kết
Bằng cách tận dụng ngăn xếp tài khoản hợp đồng thông minh theo mô-đun, nhà cung cấp ví và dApp có thể thoát khỏi sự phức tạp trong bảo trì kỹ thuật. Đồng thời, các nhà phát triển mô-đun bên ngoài có cơ hội cung cấp dịch vụ chuyên biệt được cá nhân hóa theo nhu cầu. Tuy nhiên, các thách thức cần giải quyết bao gồm cân bằng giữa linh hoạt và bảo mật, thúc đẩy tiến bộ tiêu chuẩn mô-đun và thực hiện các giao diện chuẩn hóa để người dùng dễ dàng nâng cấp và sửa đổi tài khoản thông minh của họ.
Tuy nhiên, tài khoản hợp đồng thông minh (SCA) theo mô-đun chỉ là một mảnh ghép trong việc áp dụng. Để hiện thực đầy đủ tiềm năng của SCA, còn cần hỗ trợ từ tầng giao thức của các giải pháp lớp hai, cơ sở hạ tầng bundler mạnh mẽ và mempool ngang hàng, cơ chế ký SCA hiệu quả và tiết kiệm chi phí hơn, đồng bộ và quản lý SCA liên chuỗi, cũng như phát triển giao diện thân thiện với người dùng.
Chúng tôi hình dung một tương lai với sự tham gia rộng rãi, đặt ra một số câu hỏi thú vị: Khi quy trình đặt hàng SCA trở nên đủ sinh lời, cơ chế giá trị khai thác được của thợ đào (MEV) truyền thống sẽ như thế nào khi tham gia lĩnh vực này, xây dựng bundler và thu thập giá trị? Khi cơ sở hạ tầng trưởng thành, làm thế nào để Trừu tượng Tài khoản (AA) trở thành tầng cơ sở cho giao dịch "dựa trên ý định"? Hãy theo dõi, lĩnh vực này đang liên tục phát triển và thay đổi.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@SevenXVentures
