Kiến trúc và thách thức của tài khoản hợp đồng thông minh mô-đun

Giới thiệu loại coin

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 có đà và được nhiều người đam mê, bao gồm cả chính Vitalik, đón nhận. Bất chấp sự phấn khích, việc áp dụng SCA không phổ biến như EOA. Điểm mấu chốt trong số đó là những thách thức do thị trường giá xuống gây ra, mối lo ngại về di cư, vấn đề ký kết, chi phí gas và quan trọng nhất là những khó khăn về kỹ thuật.

Ưu điểm đáng kể nhất của Tóm tắt tài khoản (AA) là khả năng sử dụng mã để tùy chỉnh chức năng. Tuy nhiên, một thách thức lớn về mặt kỹ thuật là tính không tương tác của các chức năng AA và sự phân mảnh cản trở sự tích hợp và mở ra cơ hội cho nhà cung cấp bị khóa. Ngoài ra, việc đảm bảo bảo mật đồng thời nâng cấp và soạn thảo các tính năng có thể phức tạp.

Nhập Trừu tượng tài khoản mô-đun, như một tập hợp con của phong trào AA rộng hơn, cách tiếp cận đổi mới này có thể tách các tài khoản thông minh khỏi các 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 các chức năng đa dạng. Trong tương lai, nó có thể tạo ra một “cửa hàng ứng dụng” miễn phí cho các tài khoản hợp đồng thông minh, giúp ví và dApp không phải xây dựng các tính năng mà tập trung vào trải nghiệm người dùng.

Sau khi đọc bài viết này, người đọc sẽ hiểu rõ hơn về:

1. Trừu tượng tài khoản mô-đun là gì
2. Tài khoản tương tác với các mô-đun như thế nào
3. Trình tự các mô-đun gọi là gì
4. Cách tìm và xác minh các mô-đun theo cách mở

Một đánh giá ngắn gọn về AA

Cảnh quan SCA

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 trên thực tế, 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 tài khoản hợp đồng thông minh cho phép xác thực và thực thi có thể lập trình, trong đó người dùng có thể phê duyệt một loạt giao dịch trong một lần, thay vì ký và phát từng giao dịch cũng như triển khai nhiều tính năng khác. Nó giới thiệu những lợi ích cho trải nghiệm người dùng (ví dụ. trừu tượng khí 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 để đạt được sự trừu tượng hóa tài khoản:

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

👉 Nếu bạn chưa quen với AA hoặc ERC4337, hãy xem nghiên cứu trước đây của SevenX tại đây.

Vấn đề nan giải của việc á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à nó tiếp tục được chú ý bởi ERC4337 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 kém so với EOA.

Hãy cùng đi sâu vào vấn đề nan giải này:

1. 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 thị trường gấu hiện hành chủ yếu bao gồm những người dùng EOA có trình độ học vấn hơn là những người mới, do đó không có động lực cho dApps và ví. Ngay cả khi nói rằng, các ứng dụng hàng đầu vẫn đang trên đường áp dụng AA, chẳng hạn như Cyberconnect đã thu hút khoảng 360.000 UserOps (giao dịch AA) chỉ riêng mỗi tháng bằng cách giới thiệu hệ thống AA và giải pháp không dùng gas của họ.
2. Trở ngại di cư:
   Đối với các ví và ứng dụng đã tích lũy người dùng và tài sản được lưu trữ trong EOA, 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 giao dịch di chuyển một lần.
3. Vấn đề ký kết:
   Bản thân hợp đồng thông minh đương nhiên không thể ký tin nhắn vì nó không có khóa riêng như EOA. Những nỗ lực như ERC1271 có thể thực hiện được nhưng việc ký tin nhắn sẽ không hoạt động cho đến giao dịch đầu tiên, điều này đặt ra thách thức đối với các ví sử dụng triển khai phản thực tế. Và ERC-6492 do Ambire đề xuất là phiên bản kế thừa tương thích ngược với ERC-1271 có khả năng giải quyết vấn đề trước đó.
4. Chi phí gas:
   Việc triển khai, mô phỏng và thực thi SCA phải chịu chi phí cao hơn so với EOA tiêu chuẩn. Điều này trở thành một rào cản cho việc áp dụng. Tuy nhiên, một số thử nghiệm đã được tiến hành, chẳng hạn như tách việc tạo tài khoản khỏi hoạt động của người dùng và loại bỏ muối tài khoản cũng như kiểm tra sự tồn tại đang được xem xét để giảm các chi phí này.
5. Khó khăn về kỹ thuật:
   Nhóm ERC-4337 đã thiết lập kho lưu trữ đạo đức vô hạn để cung cấp cho các nhà phát triển cách triển khai cơ bản. Tuy nhiên, khi chúng tôi phân nhánh sang các chức năng có sắc thái hoặc cụ thể 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 khó khăn.

Trong bài viết này, chúng ta sẽ đi sâu vào vấn đề số 5: những khó khăn về mặt kỹ thuật.

🤔️

Tài khoản hợp đồng thông minh mô-đun để giải quyết những khó khăn về kỹ thuật

Để giải thích rõ hơn về những khó khăn kỹ thuật:

1. Phân mảnh:
   Các tính năng hiện được kích hoạt theo nhiều cách khác nhau, dù là bằng SCA cụ thể hay thông qua hệ thống plugin độc lập. Mỗi tiêu chuẩn đều tuân theo tiêu chuẩn của nó, buộc các nhà phát triển phải quyết định nên xác nhận nền tảng nào. Điều này dẫn đến khả năng bị khóa nền tảng hoặc nỗ lực dư thừa.
2. Bảo vệ:
   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ó thể làm tăng thêm mối 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 các đánh giá độc lập có thể làm tăng nguy cơ xảy ra lỗ hổng tài khoản.
3. Khả năng nâng cấp:
   Khi các tính 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ỏ các chức năng. Việc triển khai lại các tính năng hiện có sau mỗi bản cập nhật sẽ gây ra sự phức tạp.

Để điều hướng các vùng nước 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 để nâng cao 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 các tài khoản hợp đồng có thể chuyển đổi suôn sẻ 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 duy nhất: 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 lớn hơn, dự kiến mô-đun hóa các tài khoản thông minh để tùy chỉnh chúng cho người dùng và trao quyền cho các nhà phát triển cải tiến liền mạch các tính năng với những hạn chế tối thiểu.

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

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

Tài khoản gọi các mô-đun như thế nào để thực hiện các chức năng

Cuộc gọi đại biểu và hợp đồng ủy quyền

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

Giới thiệu về đại biểuCall

Mặc dù cuộc gọi ủy quyền 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ó thực hiện nó trong bối cảnh trạng thái hiện tại của hợp đồng gọi. Điều này có nghĩa là bất kỳ thay đổi trạng thái nào do hợp đồng đích thực hiện đều được thực hiện đối với bộ lưu trữ của hợp đồng gọi.

Hợp đồng proxy và delegateCall

Để hiện thực hóa 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 proxy”.

1. Hợp đồng proxy: Hợp đồng thông thường lưu trữ logic và trạng thái của nó, không thể cập nhật sau khi triển khai. Một hợp đồng proxy sử dụng cuộc gọi đại biểu đến một hợp đồng khác. Bằng cách tham khảo chức năng triển khai, nó sẽ thực thi chức năng đó ở trạng thái hiện tại của hợp đồng proxy.
2. Các trường hợp sử dụng: Mặc dù hợp đồng proxy không thay đổi nhưng bạn có thể triển khai cách 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

Kiến trúc an toàn

Điều gì là 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 thử nghiệm trong chiến đấu, nó trao quyền cho 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 An toàn với 4337 gốc và 1/1 chữ ký. Chứng kiến việc triển khai hơn 164.000 hợp đồng và đạt giá trị vượt quá 30,7 tỷ đồng, Safe chắc chắn là sản phẩm hàng đầu trong không gian.

Cấu trúc của What's Safe

1. Hợp đồng tài khoản an toàn: Hợp đồng proxy chính (Stateful)
   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 đều được đặt làm biến của proxy, từ đó xác định trạng thái của nó.
2. Hợp đồng Singleton: Trung tâm tích hợp (Không quốc tịch)
   Singleton phục vụ tài khoản An toàn, đồng thời 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ý.
3. Hợp đồng mô-đun: Logic và tính năng tùy chỉnh:
   Các mô-đun rất mạnh mẽ. Các plugin dưới dạng mô-đun có thể xác định các tính 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 có thể đóng vai trò là cầu nối giữa web2 và web3 bằng cách tìm nạp 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à Trình xử lý chức năng phản hồi mọi hướng dẫn.

Điều gì xảy ra khi chúng tôi áp dụng An toàn:

1. Hợp đồng có thể nâng cấp:
   Việc triển khai một singleton mới là cần thiết bất cứ khi nào các plugin mới được giới thiệu. Người dùng có quyền tự chủ nâng cấp An toàn của họ 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ọ.
2. 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 tạo ra các 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 dựa trên trường hợp sử dụng của mình, thúc đẩy cách tiếp cận có khả năng tùy biến cao.

Proxy kim cương ERC-2535

Kiến trúc kim cương ERC2535

Giới thiệu về ERC2535, Proxy kim cương:

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

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

1. Hợp đồng kim cương: Hợp đồng proxy chính (Trạng thái) Kim cương là một hợp đồng proxy gọi các chức năng từ quá trình triển khai của nó bằng cách sử dụng delegatecall.
2. Hợp đồng Mô-đun/ Plugin/ Khía cạnh: Logic và tính năng tùy chỉnh (Không trạng thái) 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 các tính năng của nó cho một hoặc nhiều viên kim cương. Chúng là các hợp đồng độc lập, riêng biệt 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:

1. 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 plugin khác nhau và kết nối chúng với nhau cũng như chia sẻ dữ liệu giữa chúng, đồng thời trực tiếp thêm/thay thế/xóa bất kỳ plugin nào bằng chức năng DiamondCut. Không có giới hạn về số lượng plugin có thể được thêm vào kim cương theo thời gian.
2. 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 kim cương nào để giảm đáng kể chi phí triển khai.

Sự khác biệt giữa Tài khoản thông minh an toàn và Phương pháp tiếp cận kim cương:

Có rất 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 để đạt được khả năng nâng cấp và tính mô đun hóa.

Tuy nhiên, sự khác biệt chính nằm ở việc xử lý các hợp đồng logic. Đây là một cái nhìn gần hơn:

1. Uyển chuyển:
   Trong bối cảnh kích hoạt các plugin mới, Safe yêu cầu triển khai lại hợp đồng Singleton để thực hiện thay đổi trong Proxy của mình. Ngược lại, Diamond đạt được điều này trực tiếp thông qua chức năng DiamondCut trong Proxy của nó. Sự khác biệt trong cách tiếp cận này có nghĩa là An toàn duy trì mức độ kiểm soát cao hơn, trong khi Diamond giới thiệu tính linh hoạt và mô đun nâng cao.
2. Bảo vệ:
   delegatecall, hiện được sử dụng trong cả hai cấu trúc, có thể cho phép mã bên ngoài thao tác việc lưu trữ 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 trên nhiều hợp đồng mô-đun- plugin. Do đó, một plugin độc hại có khả năng ghi đè lên một plugin 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 Proxy.
3. Trị giá:
   Tính linh hoạt vốn có trong phương pháp Diamond đi đôi với những lo ngại về bảo mật ngày càng tăng. Điều này làm tăng hệ số chi phí, đòi hỏi phải kiểm tra toàn diện mỗi khi bổ sung một plugin mới. Điều quan trọng là đảm bảo rằng các plugin này không can thiệp vào chức năng của nhau, điều này gây ra thách thức, đặc biệt đố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 tiếp cận Tài khoản thông minh an toàn” và “Phương pháp tiếp cận kim cương” đóng vai trò là ví dụ về các cấu trúc riêng biệt liên quan đến proxy 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 phương pháp này có thể bổ sung cho nhau trong tương lai.

Trình tự các mô-đun: Trình xác thực, Trình thực thi và Hook

Trình tự các mô-đun gọi là gì

Hãy mở rộng cuộc thảo luận của chúng ta bằng cách giới thiệu ERC6900, một tiêu chuẩn do nhóm Alchemy đề xuất, lấy cảm hứng từ Diamond và được thiết kế 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 các giao diện chung và phối hợp nỗ lự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 thực, thực thi và hook. Tất cả các bước này có thể được quản lý bằng cách sử dụng tài khoản proxy để gọi các mô-đun, như chúng ta đã thảo luận trước đó. 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 được logic cơ bản tương tự.

Tên chức năng trong thiết kế khác nhau

1. Xác thực: Đảm bảo tính xác thực và quyền hạn của người gọi đến tài khoản.
2. Thực thi: Thực hiện bất kỳ logic tùy chỉnh nào mà tài khoản cho phép.
3. Hook: Hoạt động như một module chạy trước hoặc sau một chức năng 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.

ERC6900

Điều quan trọng là phải tách các mô-đun dựa trên logic khác. Một cách tiếp cận được tiêu chuẩn hóa sẽ chỉ ra cách viết các chức năng xác thực, thực thi và hook cho các 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 biệt dành riêng cho các hoạt động triển khai hoặc hệ sinh thái nhất định, đồng thời ngăn chặn sự khóa chặt của nhà cung cấp.

Mô-đun khám phá và bảo mật

Cách tìm và xác minh các mô-đun theo cách mở

Một giải pháp đang được đà phát triể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ể xác minh được mà chúng tôi có thể gọi là “đăng ký”. Cơ quan đăng ký này hoạt động giống như một “App Store” và nhằm mục đích thúc đẩy một thị trường mô-đun đơn giản hóa nhưng phát triển mạnh.

Giao thức{Core} an toàn

Giao thức{Core} an toàn

Giao thức{Core} an toàn là giao thức nguồn mở, có thể tương tác dành cho tài khoản hợp đồng thông minh, được thiết kế để nâng cao khả năng truy cập cho nhiều nhà cung cấp và nhà phát triển khác nhau trong khi vẫn duy trì tính bảo mật mạnh mẽ thông qua các tiêu chuẩn và quy tắc được xác định rõ ràng.

1. Tài khoản: Trong Giao thức{Core} an toàn, khái niệm tài khoản rất linh hoạt và không bị ràng buộc vớ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 đa dạng tham gia.
2. 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 như lớp cấp phép.
3. Cơ quan đă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 như ERC6900 cho Mô-đun, nhằm tạo ra một môi trường “cửa hàng ứng dụng” mở cho cả khả năng khám phá và tính an toàn.
4. Mô-đun: Mô-đun xử lý các chức năng và có 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. Chúng được mở để các nhà phát triển đóng góp, miễn là họ đáp ứng các tiêu chuẩn đã được thiết lập.

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

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

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

1. 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 cần thiết để chứng thực. Nó có thể được các doanh nghiệp tùy chỉnh để phù hợp với các trường hợp sử dụng cụ thể của họ.
2. Tạo mô-đun dựa trên lược đồ: Hợp đồng thông minh được đăng ký dưới dạng mô-đun, lấy mã byte và chọn ID lược đồ. Dữ liệu này sau đó được lưu trữ trong sổ đăng ký.
3. Đạt được chứng thực cho một mô-đun: Người chứng thực/người kiểm tra có thể cung cấp chứng thực cho các mô-đun trên cơ sở lược đồ. Những chứng thực này có thể bao gồm một mã định danh duy nhất (UID) và các tham chiếu đến các chứng thực khác để tạo chuỗi. Chúng có thể lan truyền khắp các chuỗi và xác minh xem các ngưỡng cụ thể có được đáp ứng trên chuỗi đích hay không.
4. Triển khai Logic phức tạp với Bộ phân giải: Bộ phân giải, được đặt tùy chọn trong lược đồ, sẽ phát huy tác dụng. Chúng có thể được gọi trong quá trình tạo mô-đun, thiết lập chứng thực và thu hồi. Các trình phân giải 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 chứng thực.
5. Truy cập truy vấn thân thiện với người dùng: Truy vấn cung cấp phương tiện để người dùng truy cập thông tin bảo mật từ giao diện người dùng. Tìm EIP này tại đây.

Mặc dù lược đồ này đang ở 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 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, người kiểm tra xác minh tính bảo mật và ví để tích hợp, đồng thời cho phép người dùng dễ dàng xác định vị trí các mô-đun và xác minh thông tin chứng thực của họ. Một số ứng dụng trong tương lai có thể là:

1. Người chứng thực: Các thực thể đáng tin cậy, như Safe, có thể cộng tác với Crystal với tư cách là người chứng thực cho các mô-đun nội bộ. Đồng thời, những người chứng thực độc lập có thể tham gia.
2. Nhà phát triển mô-đun: Khi thị trường mở hình thành, các nhà phát triển mô-đun có thể kiếm tiền từ công việc của họ thông qua cơ quan đăng ký.
3. Người dùng: Tương tác thông qua các giao diện thân thiện với người dùng, chẳng hạn như ví hoặc dApp, người dùng có thể kiểm tra thông tin mô-đun và ủy quyền tin cậy cho những người chứng thực khác nhau.

Khái niệm “Đăng ký mô-đun” mở ra con đường kiếm tiền cho các nhà phát triển plugin và mô-đun. Nó có thể mở đường hơn nữa cho “Thị trường mô-đun”. Một số khía cạnh có thể được nhóm của 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 đóng góp và hồ sơ kiểm toán minh bạch cho tất cả mọi người. Bằng cách kết hợp điều 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 thêm trải nghiệm người dùng nâng cao để thu hút nhiều đối tượng hơn.

Mặc dù các phương pháp này đảm bảo sự an toàn của một mô-đun duy nhất, nhưng tính bảo mật rộng hơn của các tài khoản hợp đồng thông minh không phải là điều hoàn hảo. Việc kết hợp các mô-đun hợp pháp và bằng chứng cho thấy 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 cơ sở hạ tầng ví hoặc AA trong việc giải quyết những mối lo ngại như vậy.

Bớt tư tưởng

Bằng cách sử 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ể được giải phóng khỏi sự phức tạp của việc bảo trì công nghệ. Trong khi đó, 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 biệt phù hợp với nhu cầu cá nhân. Tuy nhiên, những thách thức cần 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 các tiêu chuẩn mô-đun phát triển và triển khai các giao diện tiêu chuẩn hóa giú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ỉ đại diện cho một phần của vấn đề áp dụng. Để nhận ra đầy đủ tiềm năng của SCA, cần có sự hỗ trợ bổ sung ở lớp giao thức từ các giải pháp Lớp 2, do đó, cơ sở hạ tầng gói mạnh mẽ và bộ nhớ ngang hàng, cơ chế ký SCA khả thi và hiệu quả hơn về mặt chi phí, quản lý và đồng bộ hóa SCA chuỗi chéo và phát triển giao diện thân thiện với người dùng.

Nhìn về phía trước, chúng tôi hình dung ra một tương lai nơi sự tham gia rộng rãi, đặt ra những câu hỏi hấp dẫn: Một khi luồng đơn đặ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 người khai thác truyền thống sẽ tham gia vào lĩnh vực này để 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 Tóm tắt tài khoản (AA) có thể đóng vai trò là lớp nền tảng cho các giao dịch “dựa trên mục đích”? Giữ nguyên; cảnh quan đang phát triển từng phút.

Phần quan trọng

1. Sách trắng an toàn: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Tài liệu kim cương giả: https://docs.rhinestone.wtf/
3. Tài liệu nhị phân: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [SevenX Ventures ]. Mọi bản quyền thuộc về tác giả gốc [SevenX Ventures]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.