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, các nhà cung cấp ví và dApp có thể thoát khỏi sự phức tạp của việc bảo trì kỹ thuật.

Người viết: Rui

Biên soạn bởi: Shenchao TechFlow

Báo cáo gốc tiếng Anh xuất bản vào tháng 9 năm 2023

giới thiệu

Việc chuyển từ Tài khoản thuộc sở hữu bên ngoài (EOA) sang Tài khoản hợp đồng thông minh (SCA) đang bùng nổ và được nhiều người đam mê, bao gồm cả chính Vitalik, ủng hộ. Bất chấp sự phấn khích, việc áp dụng SCA vẫn chưa phổ biến như EOA. Các vấn đề chính bao gồm thách thức thị trường giá xuống, lo ngại di cư, vấn đề chữ ký, chi phí khí đốt và quan trọng nhất là thách thức kỹ thuật.

Một trong những ưu điểm 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, thách thức lớn về mặt kỹ thuật là tính không tương tác của chức năng AA và sự phân mảnh này cản trở sự tích hợp và mở ra cánh cửa cho sự ràng buộc của nhà cung cấp. Ngoài ra, việc đảm bảo an ninh khi nâng cấp và kết hợp các tính năng đồng thời có thể phức tạp.

Tính trừu tượng hóa tài khoản mô-đun nổi lên như một tập hợp con của phong trào AA rộng hơn, một cách tiếp cận sáng tạo để tách tài khoản thông minh khỏi chức năng tùy chỉnh của chúng. Mục tiêu là tạo ra một cấu trúc mô-đun để phát triển các ví an toàn, tích hợp liền mạch với chức năng đa dạng. Trong tương lai, nó có thể triển khai một “cửa hàng ứng dụng” tài khoản hợp đồng thông minh miễn phí để ví và dApp không còn tập trung vào việc xây dựng chức năng mà tập trung vào trải nghiệm người dùng.

AA Mô tả ngắn gọn

EOA truyền thống đưa ra nhiều thách thức như cụm từ hạt giống, gas, chuỗi chéo và nhiều giao dịch. Chúng tôi chưa bao giờ có ý định giới thiệu sự phức tạp, nhưng thực tế là blockchain không phải là một trò chơi dễ dàng đối với số đông.

Tính năng trừu tượng hóa tài khoản tận dụng các tài khoản hợp đồng thông minh, cho phép xác minh và thực thi có thể lập trình, cho phép người dùng phê duyệt một loạt giao dịch cùng một lúc, thay vì phải ký và phát từng giao dịch, đồng thời kích hoạt nhiều chức năng hơn. Nó mang lại lợi ích cho trải nghiệm người dùng (ví dụ: trừu tượng Gas và khóa phiên), chi phí (ví dụ: giao dịch theo đợt) và bảo mật (ví dụ: phục hồi xã hội, đa chữ ký). Hiện tại, có hai cách để triển khai tính năng trừu tượng hóa tài khoản:

• Lớp giao thức: Bản thân một số giao thức cung cấp hỗ trợ trừu tượng hóa tài khoản cục bộ. Các giao dịch ZKsync, cho dù từ EOA hay SCA, đều tuân theo cùng một quy trình, sử dụng một nhóm bộ nhớ và quy trình giao dịch duy nhất để hỗ trợ AA, trong khi Starknet đã xóa EOA và tất cả các tài khoản Cả hai đều là SCA và họ có ví hợp đồng thông minh gốc như Argent.
• Lớp hợp đồng: Đối với Ethereum và L2 tương đương, ERC4337 giới thiệu một mục giao dịch riêng để hỗ trợ AA mà không thay đổi lớp đồ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 đóng gói, trong khi các dự án như Safe, Zerodev, Etherspot và Biconomy đang xây dựng các ngăn xếp và SDK.

Tình huống khó xử khi áp dụng SCA

Chủ đề Trừu tượng hóa tài khoản (AA) đã được thảo luận từ năm 2015 và được ERC4337 thu hút sự chú ý trong năm nay. Tuy nhiên, số lượng tài khoản hợp đồng thông minh được triển khai vẫn ít hơn nhiều so với EOA.

Hãy cùng tìm hiểu sâu hơn về vấn đề nan giải này:

Tác động của thị trường gấu: Mặc dù AA đã giới thiệu các lợi ích như đăng nhập liền mạch và khai thác Gas, nhưng những người hiện đang trải qua thị trường gấu chủ yếu bao gồm những người dùng EOA có học thức chứ không phải là người dùng mới, vì vậy điều này không tốt cho dApp và ví. Không khuyến khích. Mặc dù vậy, một số ứng dụng hàng đầu vẫn đang dần áp dụng AA, chẳng hạn như Cyberconnect, ứng dụng đã thúc đẩy khoảng 360.000 UserOps (giao dịch AA) chỉ trong một tháng bằng cách giới thiệu hệ thống AA và giải pháp Gas-free của họ.

Rào cản di chuyển: Đối với ví và ứng dụng đã tích lũy người dùng và tài sản, việc di chuyển 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, các sáng kiến như EIP-7377 cho phép EOA bắt đầu các giao dịch di chuyển một lần.

Vấn đề về chữ ký: 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 giúp việc ký kết như vậy trở nên khả thi, nhưng việc ký tin nhắn không hoạt động cho đến giao dịch đầu tiên, điều này đặt ra thách thức cho các ví sử dụng triển khai phản thực tế. ERC-6492 do Ambire đề xuất là phiên bản kế thừa tương thích ngược với ERC-1271 và có thể giải quyết các 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 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, đã có một số thử nghiệm, chẳng hạn như tách việc tạo tài khoản khỏi hành động của người dùng và xem xét loại bỏ muối tài khoản và kiểm tra sự tồn tại, để giảm các chi phí này.

Vấn đề nan giải về kỹ thuật: Nhóm ERC-4337 đã thiết lập một kho lưu trữ đạo đức vô hạn để cung cấp cho các nhà phát triển những cách triển khai cơ bản. Tuy nhiên, khi chúng tôi phân nhánh sang chức năng chi tiết hơn hoặc cụ thể hơn trong các trường hợp sử dụng khác nhau, việc tích hợp và giải mã sẽ trở nên khó khăn.

Trong bài viết này, chúng ta sẽ tìm hiểu sâu hơn về vấn đề thứ năm: những thách thức về mặt kỹ thuật.

Tài khoản hợp đồng thông minh mô-đun để giải quyết các vấn đề kỹ thuật

Một lời giải thích sâu hơn về những thách thức kỹ thuật như sau:

• Phân mảnh: Nhiều tính năng khác nhau hiện được kích hoạt theo nhiều cách khác nhau, cho dù thông qua SCA cụ thể hay hệ thống plug-in độc lập. Mỗi tiêu chuẩn đều tuân theo các tiêu chuẩn riêng, buộc các nhà phát triển phải quyết định nên hỗ trợ nền tảng nào. Điều này có thể dẫn đến việc khóa nền tảng hoặc nỗ lực trùng lặp.
• Bảo mật: Mặc dù tính linh hoạt giữa các tài khoản và tính năng mang lại lợi ích nhưng nó cũng có thể làm trầm trọng thêm những lo ngại về bảo mật. Các tính năng có thể được kiểm tra chung nhưng việc thiếu đánh giá độc lập có thể làm tăng nguy cơ vi phạm tài khoản.
• Khả năng nâng cấp: Khi chức năng phát triển, điều quan trọng là phải duy trì khả năng thêm, thay thế hoặc loại bỏ chức năng. Việc triển khai lại chức năng hiện có sau mỗi lần cập nhật sẽ gây ra sự phức tạp.

Để giải quyết những vấn đề này, chúng tôi cần các hợp đồng có thể nâng cấp để đảm bảo nâng cấp an toàn và hiệu quả, các lõi có thể tái sử dụng để cải thiện hiệu quả phát triển tổng thể và các giao diện được tiêu chuẩn hóa để đảm bảo rằng các tài khoản hợp đồng có thể chuyển đổi suôn sẻ giữa các giao diện người dùng 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 mô-đun (Modular AA).

AA mô-đun là một phân khúc thích hợp trong phong trào AA rộng hơn nhằm hình dung việc mô-đun hóa các tài khoản thông minh để điều chỉnh dịch vụ cho phù hợp với người dùng và cho phép các nhà phát triển nâng cao chức năng một cách liền mạch với những hạn chế tối thiểu.

Tuy nhiên, việc thiết lập và thúc đẩy các tiêu chuẩn mới là một thách thức lớn trong bất kỳ ngành nào. Nhiều giải pháp khác nhau có thể xuất hiện trong giai đoạn đầu trước khi mọi người chấp nhận giải pháp chính. Tuy nhiên, điều đáng khích lệ là cả SDK 4337, nhà phát triển ví, nhóm cơ sở hạ tầng và nhà thiết kế giao thức đang làm việc cùng nhau để tăng tốc quá trình này.

Cấu trúc mô-đun: tài khoản chính và mô-đun

Ủy quyền cuộc gọi và hợp đồng ủy quyền

Cuộc gọi bên ngoài và cuộc gọi đại biểu:

Mặc dù cuộc gọi ủy nhiệm tương tự như cuộc gọi, nhưng thay vì thực hiện hợp đồng mục tiêu trong ngữ cảnh riêng của nó, nó sẽ thực thi hợp đồng mục tiêu ở trạng thái hiện tại của hợp đồng cuộc gọi. Điều này có 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 cho bộ lưu trữ của hợp đồng gọi.

Để triển khai một cấu trúc có thể tổng hợp và nâng cấp, cần có kiến thức cơ bản được gọi là “hợp đồng đại lý”.

• Hợp đồng đại lý: Hợp đồng thông thường lưu trữ logic và trạng thái của chúng và không thể cập nhật sau khi triển khai. Hợp đồng proxy sử dụng một đại biểu để gọi một hợp đồng khác. Triển khai một hàm bằng tham chiếu, hàm này thực thi ở trạng thái hiện tại của hợp đồng đại lý.
• Trường hợp sử dụng: Mặc dù hợp đồng proxy vẫn giữ nguyên nhưng bạn có thể triển khai các triển khai mới đằng sau proxy. Hợp đồng proxy được sử dụng để nâng cấp và rẻ hơn khi triển khai và duy trì trên các chuỗi khối công khai.

Kiến trúc an toàn

Safe là cơ sở hạ tầng tài khoản thông minh mô-đun hàng đầu được thiết kế để cung cấp tính bảo mật và tính linh hoạt đã được chứng minh trong chiến đấu, cho phép các nhà phát triển tạo ra các ứng dụng và ví đa dạng. Điều đáng chú ý là nhiều nhóm đang xây dựng dựa trên hoặc lấy cảm hứng từ Safe. Biconomy ra mắt tài khoản của mình bằng cách mở rộng chữ ký gốc 4337 và 1/1 trên Safe. Với hơn 164.000 hợp đồng được triển khai và giá trị khóa hơn 30,7 tỷ USD, Safe chắc chắn là lựa chọn hàng đầu trong lĩnh vực này.

Cấu trúc an toàn

• Hợp đồng tài khoản an toàn: hợp đồng đại lý chính (có trạng thái)

Tài khoản An toàn là một hợp đồng proxy vì nó ủy quyền gọi một hợp đồng đơn lẻ. Tài khoản An toàn chứa chủ sở hữu, ngưỡng và địa chỉ triển khai, được đặt làm biến cho tác nhân, từ đó xác định trạng thái của nó.

• Hợp đồng Singleton: trung tâm hội nhập (không quốc tịch)

Singleton phục vụ tài khoản An toàn, tích hợp và xác định các tích hợp khác nhau, bao gồm plugin, hook, trình xử lý chức năng và trình xác thực chữ ký.

• Hợp đồng mô-đun: logic và chức năng tùy chỉnh

Các mô-đun rất mạnh mẽ. Là một loại mô-đun, các plugin có thể xác định các chức năng khác nhau như luồng thanh toán, cơ chế khôi phục và khóa phiên, đồng thời đóng vai trò là cầu nối chuỗi chéo giữa Web2 và Web3 bằng cách lấy dữ liệu ngoài chuỗi. Các mô-đun khác như Hook đóng vai trò là người bảo vệ an toàn và các trình xử lý chức năng sẽ phản hồi bất kỳ hướng dẫn nào.

Điều gì xảy ra khi chúng tôi áp dụng Safe

• Hợp đồng nâng cấp:

Bất cứ khi nào một plugin mới được giới thiệu, một singleton mới cần được triển khai. Người dùng có quyền tự chủ nâng cấp Safe lên phiên bản đơn lẻ mong muốn để phù hợp với sở thích và yêu cầu của họ.

• Các mô-đun có thể tổng hợp và tái sử dụng:

Bản 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 một cách độ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 của riêng mình, tạo điều kiện thuận lợi cho cách tiếp cận có khả năng tùy chỉnh cao.

###Đại lý kim cương ERC-2535

Giới thiệu về ERC2535 và Đại lý kim cương

ERC2535 tiêu chuẩn hóa Diamond Agent, một hệ thống hợp đồng thông minh dạng mô-đun có thể nâng cấp/mở rộng sau khi triển khai và hầu như không có giới hạn về kích thước. Cho đến nay, nhiều nhóm đã lấy cảm hứng từ nó, chẳng hạn như các thí nghiệm của Zerodev’s Kernel và Soul Wallet.

**Cấu trúc kim cương là gì? **

• Hợp đồng kim cương: Hợp đồng đại lý chính (Stateful) Diamond là hợp đồng ủy quyền gọi các chức năng từ việc triển khai nó thông qua các lệnh gọi đại biểu.
• Mô-đun/Plugin/Hợp đồng nhiều mặt: Logic và chức năng tùy chỉnh (không trạng thái) Một mô-đun hay còn gọi là khía cạnh 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 Kim cương. Chúng là những hợp đồng độc lập có thể chia sẻ các chức năng nội bộ, thư viện và các biến trạng thái.

**Điều gì xảy ra khi chúng tôi áp dụng Diamond? **

• Hợp đồng có thể nâng cấp: Diamond cung cấp một cách có hệ thống để tách biệt các phần bổ trợ 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ỳ phần bổ trợ nào thông qua chức năng DiamondCut. Không có giới hạn về số lượng plugin có thể được thêm vào Diamond theo thời gian.
• Trình cắm mô-đun và có thể tái sử dụng: Một trình cắm đã triển khai có thể được sử dụng bởi bất kỳ số lượng Kim cương nào, do đó giảm đáng kể chi phí triển khai.

###Sự khác biệt giữa Tài khoản Smart Smart và Phương pháp Diamond

Có nhiều điểm tương đồng giữa kiến trúc An toàn và Kim cương, cả hai đều dựa vào hợp đồng proxy làm cốt lõi và tham chiếu các hợp đồng logic để có khả năng nâng cấp và tính mô đun.

Tuy nhiên, sự khác biệt chính nằm ở việc xử lý các hợp đồng logic. Dưới đây là hướng dẫn chi tiết hơn:

• Tính linh hoạt: Khi đã bật plugin mới, Safe cần triển khai lại hợp đồng đơn lẻ để triển khai các thay đổi trong tác nhân của mình. Ngược lại, Diamond thực hiện điều này trực tiếp thông qua hàm DiamondCut trong đại biểu của nó. Sự khác biệt trong cách tiếp cận này có nghĩa là Safe duy trì 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 cao hơn.
• Bảo mật: Hiện tại, delegatecall được sử dụng trong cả hai cấu trúc, cho phép mã bên ngoài thao tác với bộ lưu trữ của hợp đồng chính. Trong kiến trúc An toàn, cuộc gọi đại biểu trỏ đến một hợp đồng logic duy nhất, trong khi Diamond sử dụng cuộc gọi đại biểu giữa nhiều hợp đồng mô-đun (plug-in). Do đó, một trình cắm thêm độc hại có thể ghi đè lên một trình cắm thêm khác, từ đó gây ra nguy cơ xung đột bộ nhớ có thể ảnh hưởng đến tính toàn vẹn của tác nhân.
• Chi phí: Tính linh hoạt vốn có trong phương pháp tiếp cận của Diamond đi kèm với mối lo ngại ngày càng tăng về bảo mật. Điều này làm tăng thêm yếu tố chi phí và yêu cầu kiểm tra toàn bộ mỗi khi thêm plugin mới. Điều quan trọng là đảm bảo các plugin này không can thiệp vào chức năng của nhau. Điều này có thể là thách thức đối với các doanh nghiệp vừa và nhỏ đang cố gắng duy trì các tiêu chuẩn bảo mật mạnh mẽ.

“Phương pháp tài khoản thông minh an toàn” và “Phương pháp kim cương” là ví dụ về các cấu trúc khác nhau liên quan đến các tác nhân và mô-đun. Làm thế nào để cân bằng giữa tính linh hoạt và bảo mật là rất quan trọng và hai cách tiếp cận này có thể sẽ bổ sung cho nhau trong tương lai.

Thứ tự module: validator, executor và Hook

Hãy mở rộng cuộc thảo luận của chúng ta bằng cách giới thiệu tiêu chuẩn do nhóm Alchemy đề xuất, ERC6900, được lấy cảm hứng từ Diamond và được điều chỉnh riêng cho ERC-4337. Nó giải quyết thách thức về tính mô-đun trong tài khoản thông minh bằng cách cung cấp giao diện chung và điều phối 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 của AA, có ba quy trình chính: Xác minh, Thực thi và Hook. Như chúng ta đã thảo luận trước đó, các bước này có thể được quản lý bằng cách gọi mô-đun bằng tài khoản proxy. Mặc dù các dự án khác nhau có thể sử dụng các tên khác nhau nhưng điều quan trọng là phải nắm bắt được logic cơ bản tương tự.

• Xác minh: Đảm bảo tính xác thực và quyền hạn của tài khoản người gọi.
• Thực thi: Thực thi bất kỳ logic tùy chỉnh nào được tài khoản cho phép. *Hook: là một module chạy trước hoặc sau một hàm khác. Nó có thể sửa đổi trạng thái hoặc khiến toàn bộ cuộc gọi bị hủy.

Việc tách các mô-đun dựa trên logic khác nhau là rất quan trọng. Một cách tiếp cận được tiêu chuẩn hóa sẽ chỉ định cách viết các chức năng xác minh, thực thi và xác minh tài khoản hợp đồng thông minh. Cho dù đó là An toàn hay ERC6900, việc tiêu chuẩn hóa sẽ giúp giảm nhu cầu nỗ lực phát triển riêng cho một hệ sinh thái hoặc triển khai cụ thể, đồng thời ngăn chặn sự ràng buộc của nhà cung cấp.

Phát hiện và bảo mật mô-đun

Một giải pháp đang bùng nổ liên quan đến việc tạo ra một nơi cho phép người dùng khám phá các mô-đun có thể kiểm chứng được, cái mà chúng tôi có thể gọi là “sổ đăng ký”. Cơ quan đăng ký này tương tự như một “cửa hàng ứng dụng” và được thiết kế để thúc đẩy một thị trường mô-đun đơn giản nhưng thịnh vượng.

Giao thức an toàn{Core}

Giao thức Safe{Core} là giao thức tài khoản hợp đồng thông minh có khả năng tương tác, mã nguồn mở, được thiết kế để tăng khả năng truy cập 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 xác định rõ ràng, đồng thời duy trì tính 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 rất linh hoạt và không bị hạn chế bởi việc triển khai cụ thể. Điều này cho phép các nhà cung cấp dịch vụ tài khoản khác nhau tham gia.
• Người quản lý: Người quản lý đóng vai trò là người điều phối giữa các tài khoản, cơ quan đăng ký 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.
• Sổ đăng ký: Cơ quan đăng ký xác định các 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ột môi trường “cửa hàng ứng dụng” mở để khám phá và bảo mật.
• Mô-đun: Mô-đun xử lý chức năng và được cung cấp ở nhiều loại ban đầu khác nhau, bao gồm plugin, Hook, trình xác thực chữ ký và trình xử lý hàm. Các nhà phát triển có thể đóng góp cho nó miễn là họ đáp ứng được các tiêu chuẩn đã được thiết lập.

Thiết kế kim cương giả

Quá trình diễn ra như sau:

• Tạo định nghĩa lược đồ: lược đồ đóng vai trò là cấu trúc dữ liệu được xác định trước để chứng minh. Doanh nghiệp có thể tùy chỉnh mẫu dựa trên trường hợp sử dụng cụ thể của họ.
• Tạo mô-đun dựa trên mẫu: hợp đồng thông minh được đăng ký dưới dạng mô-đun, lấy mã byte và chọn ID mẫu. Dữ liệu này sau đó được lưu trữ trong sổ đăng ký.
• Lấy chứng chỉ của mô-đun: Người chứng minh/kiểm tra viên có thể cung cấp chứng chỉ cho mô-đun theo sơ đồ. Các chứng chỉ này có thể bao gồm số nhận dạng duy nhất (UID) và tham chiếu đến các chứng chỉ khác để liên kết. Chúng có thể được truyền bá trên chuỗi và xác minh rằng các ngưỡng nhất định được đáp ứng trên chuỗi mục tiêu.
• Sử dụng trình phân tích cú pháp để triển khai logic phức tạp: các trình phân tích cú pháp được đặt tùy chọn trong mẫu. Chúng có thể được gọi trong quá trình tạo mô-đun, thiết lập bằng chứng và phân tích. Các trình phân tích cú pháp này cho phép các nhà phát triển kết hợp logic phức tạp và đa dạng trong khi vẫn duy trì cấu trúc của bằng chứng.
• Truy cập truy vấn thân thiện với người dùng: Truy vấn cung cấp cách để người dùng truy cập thông tin bảo mật từ giao diện người dùng. EIP có thể được tìm thấy ở đây.

Mặc dù mô hình này vẫn còn ở giai đoạn đầu nhưng nó có tiềm năng thiết lập một tiêu chuẩn theo cách thức phi tập trung và hợp tác. Cơ quan đăng ký của họ cho phép các nhà phát triển đăng ký mô-đun, kiểm toán viên xác minh tính bảo mật, tích hợp ví và người dùng dễ dàng tìm thấy mô-đun cũng như xác minh thông tin chứng thực của họ. Có thể có những mục đích sử dụng sau trong tương lai:

• Người chứng nhận: Các thực thể đáng tin cậy, chẳng hạn như Safe, có thể hợp tác với Crystal với tư cách là người chứng nhận cho các mô-đun nội bộ. Đồng thời, những người chứng minh độc lập cũng có thể tham gia.
• Các nhà phát triển mô-đun: Với việc hình thành một thị trường mở, các nhà phát triển mô-đun có thể thương mại hóa công việc của mình thông qua cơ quan đăng ký.
• Người dùng: Thông qua các giao diện thân thiện với người dùng như ví hoặc dApps, người dùng có thể xem thông tin mô-đun và ủy quyền tin cậy cho những người chứng minh khác nhau.

Khái niệm “đăng ký mô-đun” mang lại cơ hội lợi nhuận cho các nhà phát triển plugin và mô-đun. Nó cũng có thể mở đường cho một “thị trường mô-đun”. Một số khía cạnh này có thể được nhóm An toàn giám sát, trong khi những khía cạnh khác có thể tự 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 quy trình kiểm tra minh bạch. Bằng cách thực hiện phương pháp này, chúng tôi có thể tránh được sự ràng buộc của nhà cung cấp và hỗ trợ việc mở rộng EVM bằng cách cung cấp trải nghiệm người dùng tốt hơn để thu hút nhiều đối tượng hơn.

Mặc dù các phương pháp này đảm bảo tính bảo mật của từng mô-đun riêng lẻ nhưng tính bảo mật tổng thể của tài khoản hợp đồng thông minh không hoàn toàn đáng tin cậy. Việc kết hợp các mô-đun hợp pháp và chứng minh rằng chúng không có xung đột lưu trữ 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óm tắt

Bằng cách tận dụng ngăn xếp tài khoản hợp đồng thông minh mô-đun, các nhà cung cấp ví và dApp có thể thoát khỏi sự phức tạp của việc 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 các dịch vụ chuyên nghiệp phù hợp với nhu cầu cá nhân. Tuy nhiên, những thách thức cần được giải quyết bao gồm việc đạt được sự cân bằng giữa tính linh hoạt và bảo mật, thúc đẩy sự tiến bộ của các tiêu chuẩn mô-đun và triển khai các giao diện được tiêu chuẩn hóa cho phép 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 mô-đun (SCA) chỉ là một phần của vấn đề áp dụng. Để nhận ra đầy đủ tiềm năng của SCA, cũng cần có sự hỗ trợ lớp giao thức từ các giải pháp lớp thứ hai, cũng như cơ sở hạ tầng gói mạnh mẽ và nhóm bộ nhớ ngang hàng, cơ chế ký SCA khả thi và hiệu quả hơn về mặt chi phí, đồng bộ hóa SCA chuỗi chéo và quản lý, cũng như phát triển các 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, điều này đặt ra một số câu hỏi thú vị: Một khi quy trình đặt hàng SCA trở nên đủ lợi nhuận, các cơ chế giá trị có thể trích xuất (MEV) của máy khai thác truyền thống sẽ xâm nhập vào không gian, xây dựng các gói và nắm bắt giá trị như thế nào? Khi cơ sở hạ tầng hoàn thiện, làm thế nào việc trừu tượng hóa tài khoản (AA) có thể trở thành lớp cơ bản cho các giao dịch “dựa trên mục đích”? Hãy theo dõi vì khu vực này không ngừng phát triển.