Bài viết này là bản gốc của nhóm nghiên cứu SevenX và chỉ dành cho mục đích giao tiếp và học tập chứ không phải là bất kỳ tài liệu tham khảo đầu tư nào. Nếu cần trích dẫn xin vui lòng ghi nguồn.
Báo cáo gốc bằng tiếng Anh được xuất bản trên nền tảng Mirror của SevenX vào tháng 9 năm 2023.Để biết thêm nội dung nghiên cứu đầu tư của Trung Quốc, vui lòng theo dõi tài khoản công khai [SevenXVentures].
Cảm ơn Lukas, người đồng sáng lập Safe, Noam, trưởng bộ phận kỹ thuật tại Alchemy, Kurt và Konrad, người đồng sáng lập Crystal và nhà đầu tư Arnav từ HashKey Capital.
Lưu ý của biên tập viên: Tài khoản hợp đồng thông minh (SCA) đang phát triển mạnh mẽ và được nhiều doanh nhân cốt lõi hỗ trợ, trong đó có Vitalik. Tuy nhiên, việc áp dụng SCA vẫn gặp nhiều thách thức. Tính năng Trừu tượng hóa Tài khoản (AA) có lợi thế là tùy chỉnh chức năng bằng cách sử dụng mã, nhưng khả năng không tương tác của nó mang lại các vấn đề về tích hợp và khóa nhà cung cấp. Việc trừu tượng hóa tài khoản theo mô-đun nhằm mục đích tạo ra một cấu trúc mô-đun để phát triển ví với chức năng đa dạng, bảo mật và tích hợp liền mạch.
Nhà đầu tư Rui của SevenX Ventures đã chỉ ra năm thách thức lớn đối với việc áp dụng SCA, đó là chịu tác động của thị trường, khó khăn trong việc di chuyển, các vấn đề về chữ ký, chi phí gas cao và khó khăn kỹ thuật, đồng thời thảo luận thêm về các vấn đề kỹ thuật. Hơn nữa, một phân tích về kiến trúc của các tài khoản hợp đồng thông minh mô-đun chỉ ra rằng SCA mô-đun chỉ là một phần nhỏ trong vấn đề áp dụng.
Để nhận ra đầy đủ tiềm năng của SCA, các giải pháp Lớp 2 được yêu cầu cung cấp hỗ trợ lớp giao thức bổ sung, cơ sở hạ tầng gói mạnh mẽ và nhóm bộ nhớ ngang hàng, cơ chế 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à cơ chế quản lý và phát triển Giao diện thân thiện với người dùng và hơn thế nữa.
Trong tương lai, khi những thách thức hiện tại dần được giải quyết và ngày càng có nhiều người áp dụng SCA, điều gì sẽ xảy ra tiếp theo? Rui cũng đưa ra một số câu hỏi thú vị về vấn đề này. BlockBeats biên dịch văn bản gốc như sau:
Quá trình chuyển đổi 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 đà phát triển và nhận được sự hỗ trợ từ nhiều doanh nhân cốt lõi, bao gồm cả Vitalik. Mặc dù vậy, việc áp dụng SCA không phổ biến như EOA. Các vấn đề chính bao gồm tác động của thị trường giá xuống, khó khăn trong việc di chuyển từ eoa sang sca, các vấn đề về chữ ký, chi phí gas cao và các vấn đề phát triển quan trọng nhất.
Ưu điểm đáng kể 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, khả năng không tương tác của chức năng AA đặt ra những thách thức lớn, sự phân mảnh này có thể cản trở việc tích hợp AA và củng cố khả năng ràng buộc của nhà cung cấp. Ngoài ra, việc đảm bảo an ninh trong khi có thể nâng cấp và tổng hợp cũng là một thách thức quan trọng.
Một lĩnh vực thích hợp trong xu hướng phát triển AA là sự xuất hiện của tính năng trừu tượng hóa tài khoản theo mô-đun, một cách tiếp cận sáng tạo giúp 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 ví với chức năng đa dạng, bảo mật và tích hợp liền mạch. Trong tương lai, tính năng trừu tượng hóa tài khoản mô-đun 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í, cho phép ví và dApp tập trung vào việc cải thiện trải nghiệm người dùng mà không tốn quá nhiều năng lượng vào việc xây dựng các chức năng.
Giới thiệu ngắn gọn về Trừu tượng tài khoản (AA)
Trong quá trình mọi người tiếp xúc với blockchain, EOA truyền thống đã mang đến nhiều thách thức, chẳng hạn như từ ghi nhớ, phí gas, hoạt động xuyên chuỗi và nhiều giao dịch.
Việc 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 thực và thực thi có thể lập trình. Điều này có nghĩa là người dùng sẽ có thể 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. Việc trừu tượng hóa tài khoản cũng có thể đạt được nhiều chức năng hơn, chẳng hạn như cải thiện trải nghiệm người dùng (chẳng hạn như trừu tượng hóa Gas và khóa phiên), giảm chi phí (chẳng hạn như giao dịch hàng loạt) và cải thiện tính bảo mật (chẳng hạn như khôi phục 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: 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 sử dụng một nhóm bộ nhớ và quy trình giao dịch duy nhất để hỗ trợ AA; cho dù đó là từ EOA hay SCA, chúng đều tuân theo cùng một quy trình 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 gốc như Argent.
Lớp hợp đồng: Đối với Ethereum và L2 tương tự, ERC 4337 giới thiệu một mempool riêng để hỗ trợ AA mà không thay đổi lớp đồng thuận. Các công ty như Stackup, Alchemy, Etherspot, Biconomy, Candide và Plimico đang xây dựng cơ sở hạ tầng gói, trong khi các công ty như Safe, Zerodev, Etherspot và Biconomy đang xây dựng các gói và SDK.
Những vấn đề nan giải 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à tiếp tục được chú ý trong năm nay bởi ERC 4337. 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:
1. Tác động của thị trường giá xuống
Mặc dù AA có những lợi thế như đăng nhập liền mạch và khai thác Gas, nhưng trong thị trường gấu hiện tại, tất cả người dùng đều là người dùng EOA có hiểu biết và không có nhiều người dùng mới, vì vậy dApps và ví không có động cơ để áp dụng SCA. Mặc dù vậy, một số dApp hàng đầu đang dần áp dụng AA, chẳng hạn như Cyberconnect, đã 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ọ.
2. Rào cản di cư
Đố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 chương trình như EIP-7377 cho phép EOA bắt đầu các giao dịch di chuyển một lần.
3. Vấn đề chữ ký
Bản thân hợp đồng thông minh không thể ký tin nhắn vì nó không có khóa riêng như EOA. Những nỗ lực như ERC 1271 giúp điều này trở nên khả thi, nhưng chữ ký tin nhắn không hoạt động trước giao dịch đầu tiên, điều này một lần nữa đặ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 đó.
4. Chi phí gas
Một trong những rào cản đối với việc áp dụng là chi phí triển khai, mô phỏng và thực thi SCA cao hơn so với EOA tiêu chuẩn. Tuy nhiên, một số thử nghiệm đã được thực hiện, 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à loại bỏ"salt"Chờ đợi.
5. Vấn đề kỹ thuật
Nhóm ERC-4337 đã thiết lập kho lưu trữ đạo đức vô hạn để cung cấp cách triển khai cơ bản cho các nhà phát triển. Tuy nhiên, việc tích hợp và giải mã sẽ gặp nhiều thách thức hơn khi các nhà phát triển mở rộng quy mô sang các chức năng cụ thể và sắc thái hơn cho các trường hợp sử dụng khác nhau. Trong bài viết này, chúng ta sẽ xem xét kỹ hơn một thách thức kỹ thuật.
Giải quyết các thách thức kỹ thuật với tài khoản hợp đồng thông minh mô-đun
Những thách thức về mặt kỹ thuật có thể được trình bày chi tiết hơn thành ba khía cạnh: phân mảnh, bảo mật và khả năng mở rộng.
Sự phân mảnh
Giờ đây, các tính năng có thể được kích hoạt theo nhiều cách khác nhau, cho dù thông qua SCA cụ thể hay thông qua hệ thống trình cắm độc lập. Mỗi nền tảng và nhà cung cấp dịch vụ 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 và nhà cung cấp dịch vụ nào. Điều này có thể dẫn đến việc nền tảng (nhà cung cấp) bị khóa hoặc công việc dư thừa.
sự an toàn
Mặc dù việc tách các tài khoản và chức năng mang lại lợi thế về tính linh hoạt nhưng nó cũng có thể khiến vấn đề bảo mật trở nên tồi tệ hơn. Vì tất cả các tính năng có thể được xem xét cùng nhau nên việc thiếu đánh giá độc lập có thể làm tăng nguy cơ xảy ra lỗ hổng tài khoản.
Khả năng nâng cấp
Khi tài khoản phát triển, điều quan trọng là phải duy trì khả năng thêm, thay thế hoặc xóa chức năng và mỗi bản cập nhật triển khai lại chức năng hiện có 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 (mô-đun AA).
Tính năng trừu tượng hóa tài khoản theo mô-đun là một phân khu trong phạm vi phát triển AA rộng rãi nhằm hình dung việc mô-đun hóa các tài khoản thông minh để tùy chỉnh dịch vụ cho 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 trong bất kỳ ngành nào cũng là một thách thức rất lớn. Nhiều giải pháp khác nhau có thể xuất hiện trong giai đoạn đầu cho đến khi mọi người chấp nhận cùng một tiêu chuẩn. Thật đáng khích lệ khi thấy những người đang nỗ lực tinh chỉnh và thúc đẩy tính năng trừu tượng hóa tài khoản, cho dù đó là SDK 4337, ví, nhóm cơ sở hạ tầng hay nhà thiết kế lớp giao thức, cùng nhau làm việc để tăng tốc quá trình này.
Cấu trúc mô-đun: tài khoản chính và mô-đun
Cách tài khoản gọi mô-đun để triển khai 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ề cuộc gọi đại biểu
Mặc dù cuộc gọi ủy nhiệm tương tự như sự gọi, nó không được thực thi trong bối cảnh của hợp đồng đích mà 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 được thực hiện bởi hợp đồng đích sẽ thay đổi việc lưu trữ hợp đồng gọi.
Hợp đồng proxy và cuộc gọi đại biểu
Để đạt được một cấu trúc có thể kết hợp và nâng cấp được, cần phải đưa ra khái niệm cơ bản về “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 lệnh gọi đại biểu để triển khai sang hợp đồng khác. Thực hiện chức năng bằng cách tham chiếu, thực thi nó ở 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 hoạt động triển khai mới đằng sau proxy. Hợp đồng proxy cho phép khả năng nâng cấp và rẻ hơn khi triển khai cũng như 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ế để mang lại tính bảo mật và tính linh hoạt đã được thử nghiệm 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. Nhiều nhóm đang xây dựng các ứng dụng dựa trên (hoặc lấy cảm hứng từ) Safe. Ví dụ: khi Biconomy ra mắt tài khoản hợp đồng thông minh, nó đã sử dụng chữ ký gốc 4337 và 1/1 để mở rộng An toàn. 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à công ty dẫn đầu trong lĩnh vực của mình.
Cấu trúc của Safe bao gồm hợp đồng tài khoản bảo mật, hợp đồng đơn lẻ và hợp đồng mô-đun.
Hợp đồng tài khoản bảo đảm (hợp đồng ủy quyền): hợp đồng đại lý chính (Stateful)
Tài khoản bảo mật là hợp đồng proxy vì lệnh gọi đại biểu là hợp đồng đơn lẻ. Tài khoản bảo mật chứa các biến dành cho chủ sở hữu, ngưỡng và địa chỉ triển khai, tất cả đều được đặt thành tác nhân và trạng thái của nó được xác định dựa trên các biến này.
Hợp đồng Singleton: Trung tâm tích hợp (không quốc tịch)
Hợp đồng đơn lẻ phục vụ tài khoản An toàn và xác định các tích hợp hợp đồng mô-đun 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 (mô-đun): logic và chức năng tùy chỉnh
Hợp đồng mô-đun rất mạnh mẽ. Các plug-in, dưới dạng mô-đun, có thể xác định các chức năng khác nhau, chẳng hạn 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 lấy dữ liệu ngoài chuỗi. Các mô-đun khác như Hook và Function Handler với tư cách là nhân viên bảo vệ có thể phản hồi bất kỳ lệnh nào.
Những thay đổi mang lại khi áp dụng An toàn:
Hợp đồng có thể nâng cấp: Các đơn vị mới cần được triển khai bất cứ khi nào một plugin mới được giới thiệu. Người dùng giữ quyền tự chủ nâng cấp Safe lên phiên bản đơn lẻ mong muốn.
Các mô-đun có thể tổng hợp, tái sử dụng: Bản chất mô-đun của các plugin cho phép các nhà phát triển phát triển chức năng một cách độc lập. Họ có thể tự do lựa chọn và kết hợp các plugin này tùy theo trường hợp sử dụng của mình, dẫn đến cách tiếp cận có khả năng tùy biến cao.
Đại lý kim cương ERC-2535
Về ERC 2535, Đại lý kim cương:
Mô hình Diamond được tiêu chuẩn hóa ERC 2535, 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ới hầu như không giới hạn kích thước. Hiện tại, các thử nghiệm của nhiều nhóm như Kernel và Soul Wallet của Zerodev đều được lấy cảm hứng từ cấu trúc Diamond.
Cấu trúc kim cương là gì:
Hợp đồng kim cương: Hợp đồng proxy chính (Trạng thái) Diamond là hợp đồng proxy sử dụng các phương thức gọi đại biểu để gọi các chức năng từ quá trình triển khai nó.
Mô-đun/Plugin/Hợp đồng khía cạnh: 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à 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ó cho một hoặc nhiều 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.
Những thay đổi mang lại khi á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 với nhau, chia sẻ dữ liệu giữa chúng và cũng trực tiếp thêm/thay thế/xóa bất kỳ phần bổ trợ nào bằng chức năng DiamondCut. Theo thời gian, sẽ không có giới hạn về số lượng plugin có thể thêm vào Diamond.
Trình cắm mô-đun và có thể tái sử dụng: Các 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 Safe Smart và phương thức 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.
Sự khác biệt chính giữa hai là việc xử lý các hợp đồng logic. Đặc biệt:
Tính linh hoạt: Khi bật các plugin mới, Safe cần triển khai lại hợp đồng đơn lẻ để thực hiện các thay đổi trong proxy của mình. Ngược lại, Diamond thực hiện điều này trực tiếp thông qua chức năng DiamondCut trong hợp đồng ủy quyền 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 giới thiệu tính linh hoạt và mô đun nâng cao.
Bảo mật: Hiện được sử dụng trong hai cấu trúc 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, lệnh gọi đại biểu trỏ đến một hợp đồng logic duy nhất, trong khi Diamond sử dụng lệnh gọi đại biểu trong nhiều plugin-hợp đồng mô-đun. 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ớ và ảnh hưởng đến tính toàn vẹn của tác nhân.
Chi phí: Với phương pháp Diamond, tính linh hoạt đi kèm với mối lo ngại về an toàn. Điều này làm tăng thêm chi phí và yêu cầu đánh giá đầy đủ mỗi khi thêm plugin mới. Điều quan trọng là đảm bảo rằng các plug-in này không can thiệp vào chức năng của nhau, một nhiệm vụ có thể là 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 cao.
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 sẽ tiếp tục phát triển và bổ sung cho nhau trong tương lai.
Thứ tự mô-đun: Trình xác thực, Trình thực thi và Hook
Hãy thảo luận sâu hơn bằng cách giới thiệu ERC-6900, 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 các thách thức của việc mô-đun hóa 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à kết nối. Như chúng ta đã thảo luận trước đó, tất 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 được logic cơ bản tương tự.
Tên chức năng trong các thiết kế khác nhau
Trình xác thực: Đảm bảo tính xác thực và quyền hạn của người gọi tài khoản.
Ngườ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: 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 hoàn tác toàn bộ cuộc gọi.
ERC 6900
Điều quan trọng là phải tách các mô-đun dựa trên logic khác nhau. 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 minh, thực thi và kết nối cho các tài khoản hợp đồng thông minh. Cho dù đó là An toàn hay ERC-6900, 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ự ràng buộc của nhà cung cấp.
Phát hiện và bảo mật mô-đun
Cách tìm và xác minh các mô-đun theo cách mở: Một giải pháp nâng cao liên quan đến việc tạo một khu vực cho phép người dùng khám phá các mô-đun có thể xác minh được, gọi đó là đăng ký. Cơ quan đăng ký hoạt động giống 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 phát triển mạnh.
Giao thức Safe{Core}
Giao thức Safe{Core} là giao thức mã nguồn mở, có khả năng tương tác dành cho các tài khoản hợp đồng thông minh được thiết kế nhằm nâng cao khả năng truy cập cho nhiều nhà cung cấp và nhà phát triển 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.
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ị 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 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 hoạt động như một lớp cấp phép chịu trách nhiệm về bảo mật.
Trung tâm đăng ký: Trung tâm đăng ký xác định các thuộc tính bảo mật và triển khai các tiêu chuẩn mô-đun như ERC 6900, nhằm tạo ra một môi trường kho ứng dụng mở để đạt được khả năng phát hiện và bảo mật.
Mô-đun: Mô-đun xử lý 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. Các nhà phát triển có thể tham gia 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 đồ (schema): Lược đồ cung cấp các cấu trúc dữ liệu được xác định trước. Mọi người có thể tùy chỉnh nó để phù hợp với trường hợp sử dụng cụ thể của họ.
Tạo mô-đun dựa trên kiến trúc: Hợp đồng thông minh được đăng ký dưới dạng mô-đun sẽ lấy mã byte và chọn ID kiến trúc, đồng thời dữ liệu sẽ được lưu trữ trong sổ đăng ký.
Đạt được chứng thực của các mô-đun: Người chứng nhận/đánh giá viên có thể cung cấp chứng thực cho các mô-đun dựa trên kiến trúc. 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 được sử dụng để liên kết. Chúng có thể lan truyền qua các chuỗi và xác minh rằng chuỗi mục tiêu đáp ứng các ngưỡng nhất định.
Triển khai logic phức tạp bằng cách sử dụng trình phân giải: Trình phân giải (cài đặt tùy chọn) sẽ hoạt động. 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 tích hợp logic phức tạp và đa dạng trong khi vẫn duy trì cấu trúc chứng minh.
Truy cập truy vấn thân thiện với người dùng (truy vấn): Truy vấn cung cấp cho người dùng cách truy cập thông tin an toàn từ giao diện người dùng.
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 các tiêu chuẩn theo cách phi tập trung và hợp tác. Cơ quan đăng ký 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 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à:
Người chứng thực: Một thực thể đáng tin cậy như Safe có thể làm việc với Crystal để đóng vai trò là người chứng thực cho các mô-đun nội bộ. Đồng thời, các tổ chức chứng nhận độc lập cũng có thể tham gia.
Nhà phát triển mô-đun: Với sự hình thành của thị trường mở, 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 đăng ký.
Người dùng: Tham gia thông qua giao diện thân thiện với người dùng như ví hoặc dApp, nơi 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 minh khác nhau.
Khái niệm đăng ký mô-đun mở ra những con đường sinh lợi 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 An toàn giám sát, trong khi những khía cạnh khác có thể xuất 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. Việc tích hợp điều này sẽ tránh được sự khóa chặt của nhà cung cấp và hỗ trợ 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 bảo mật các mô-đun riêng lẻ nhưng tài khoản hợp đồng thông minh không thể an toàn khi nói đến bảo mật rộng hơn. Việc tích hợp với các mô-đun tuân thủ 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, điều này nêu bật 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 được cá nhân hóa. 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 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ọ.
Hơn nữa, tài khoản hợp đồng thông minh mô-đun (SCA) chỉ là một phần nhỏ trong vấn đề áp dụng. Để nhận ra đầy đủ tiềm năng của SCA, các giải pháp Lớp 2 được yêu cầu cung cấp hỗ trợ lớp giao thức bổ sung, chẳng hạn như cơ sở hạ tầng gói mạnh mẽ và nhóm bộ nhớ ngang hàng, cơ chế chữ ký SCA khả thi và hiệu quả hơn về mặt chi phí, SCA chuỗi chéo cơ chế đồng bộ hóa và quản lý, và Phát triển giao diện thân thiện với người dùng.
Trong tương lai, sẽ có nhiều việc áp dụng SCA hơn, nhưng nó cũng đặt ra một số câu hỏi thú vị: 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 thợ mỏ truyền thống sẽ xâm nhập vào không gian để xây dựng các gói và nhận được giá trị như thế nào? Khi cơ sở hạ tầng hoàn thiện, làm thế nào tính năng Trừu tượng tài khoản (AA) có thể đóng vai trò là lớp cơ sở cho các giao dịch dựa trên mục đích? Chúng ta hãy đợi và xem.
