*Ghi chú của biên tập viên: Tài khoản hợp đồng thông minh (SCA) đang đạt được động lực và được hỗ trợ bởi nhiều doanh nhân cốt lõi, bao gồm cả Vitalik, nhưng vẫn còn nhiều thách thức đối với việc áp dụng SCA. Trừu tượng hóa tài khoản (AA) có lợi thế là sử dụng tùy chỉnh mã, nhưng tính không tương tác của nó giới thiệu các vấn đề tích hợp và khóa nhà cung cấp. Trừu tượng hóa tài khoản mô-đun nhằm mục đích tạo ra một cấu trúc mô-đun để phát triển ví linh hoạt, an toàn và được tích hợp liền mạch. *
Rui, một nhà đầu tư tại SevenX Ventures >, đã xác định năm thách thức hàng đầu để áp dụng SCA - tác động của thị trường gấu, khó khăn di chuyển, vấn đề chữ ký, chi phí khí đốt cao và thách thức kỹ thuật - và thảo luận thêm về chúng. Ngoài ra, 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ỏ của những thách thức áp dụng.
Để nhận ra tiềm năng đầy đủ của SCA, các giải pháp Lớp 2 là cần thiết để 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 hiệu quả và khả thi hơn, đồng bộ hóa và quản lý SCA chuỗi chéo và phát triển giao diện thân thiện với người dùng.
Điều gì sẽ xảy ra tiếp theo trong tương lai, khi những thách thức hiện tại được giải quyết và nhiều người áp dụng SCA? Rui cũng hỏi một số câu hỏi thú vị. BlockBeats biên soạn văn bản gốc như sau:
Sự 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 đạt được đà và đã được hỗ trợ bởi 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 gấu, khó khăn trong việc di chuyển EOA sang SCA, các vấn đề về chữ ký, chi phí khí đốt cao và quan trọng nhất là những thách thức phát triển.
Ư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, tính không tương tác của chức năng AA là một thách thức lớn, vì sự phân mảnh này cản trở sự tích hợp AA và củng cố khóa nhà cung cấp. Ngoài ra, nó cũng là một thách thức quan trọng để đảm bảo an ninh trong khi có thể nâng cấp và sáng tác.
Sự xuất hiện của trừu tượng hóa tài khoản mô-đun là một thị trường ngách trong xu hướng AA, một cách tiếp cận sáng tạo tách biệt các tài khoản thông minh khỏi các tính 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 nhiều tính năng, bảo mật và tích hợp liền mạch. Trong tương lai, trừu tượng hóa tài khoản mô-đun sẽ cho phép một tài khoản hợp đồng thông minh miễn phí "cửa hàng ứng dụng", 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 thay vì phải tốn quá nhiều công sức xây dựng các tính năng.
Tóm tắt tài khoản ngắn gọn (AA)
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
EOA truyền thống mang lại nhiều thách thức cho việc mọi người tiếp xúc với blockchain, chẳng hạn như cụm từ hạt giống, phí gas, hoạt động chuỗi chéo và nhiều giao dịch.
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à giao dịch 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 các giao dịch cùng một lúc, thay vì phải ký và phát sóng từng giao dịch. Trừu tượng hóa tài khoản cũng có thể kích hoạt nhiều tính năng hơn như cải thiện trải nghiệm người dùng (ví dụ: trừu tượng hóa gas và khóa phiên), giảm chi phí (ví dụ: giao dịch hàng loạt) và cải thiện bảo mật (ví dụ: khôi phục xã hội, đa chữ ký). Hiện tại, có hai cách để trừu tượng hóa tài khoản:
· Lớp giao thức: Một số giao thức nguyên bản 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 mempool duy nhất và luồng giao dịch để hỗ trợ AA, cả từ EOA và SCA đều tuân theo cùng một quy trình, trong khi Starknet đã loại bỏ EOA, tất cả các tài khoản đều là SCA và chúng có ví hợp đồng thông minh gốc như Argent.
· Lớp hợp đồng: Đối với Ethereum và các L2 tương tự, ERC4337 đã giới thiệu một mempool riêng để hỗ trợ AA mà không thay đổi lớp đồng thuận. Những nơi như Stackup, Alchemy, Etherspot, Biconomy, Candide và Plimico đang xây dựng cơ sở hạ tầng gói, trong khi những thứ như Safe, Zerodev, Etherspot và Biconomy đang xây dựng các gói và SDK.
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à đã được ERC 4337 nâng cao hơn nữa 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 chưa thấp bằng EOA.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Hãy đi sâu vào vấn đề nan giải này:
Tác động của thị trường gấu
Mặc dù có những lợi thế của AA như đăng nhập liền mạch và trừu tượng hóa gas, trong thị trường gấu hiện tại, nơi tất cả người dùng đều là người dùng EOA được đào tạo và không có nhiều người dùng mới, không có động lực nào để dApp và ví á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 không có gas.
Trở ngại di cư
Đối với ví và ứng dụng đã tích lũy được 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, một sơ đồ như EIP-7377 cho phép EOA bắt đầu giao dịch di chuyển một lần.
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ư thế ERC1271 làm cho điều nà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í được triển khai với các đối trọng. ERC-6492, được đề xuất bởi Ambire, là sự kế thừa tương thích ngược với ERC-1271 và có thể giải quyết vấn đề trước đó.
Chi phí gas
Chi phí triển khai, mô phỏng và thực thi SCA cao hơn so với EOA tiêu chuẩn cũng là một rào cản đối với 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 hành động của người dùng, loại bỏ "muối" được liên kết với tài khoản và hơn thế nữa.
Vấn đề kỹ thuật
Nhóm ERC-4337 đã xây dựng một repo eth-infinitism cung cấp triển khai cơ bản cho các nhà phát triển. Tuy nhiên, khi các nhà phát triển mở rộng quy mô sang các tính năng chi tiết và 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ã phải đối mặt với nhiều thách thức hơn. Trong bài viết này, chúng ta sẽ đi sâu vào những thách thức kỹ thuật.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Giải quyết các thách thức kỹ thuật với các tài khoản hợp đồng thông minh mô-đun
Các thách thức kỹ thuật có thể được xây dựng thêm thành ba khía cạnh: phân mảnh, bảo mật và khả năng nâng cấp.
· Phân mảnh: Các tính năng hiện 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 plug-in độ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 của mình, khiến các nhà phát triển quyết định nền tảng và nhà cung cấp dịch vụ nào sẽ hỗ trợ. Điều này có thể dẫn đến nền tảng (nhà cung cấp) tiềm năng bị khóa hoặc công việc dư thừa.
· Bảo mật: Mặc dù việc tách các tài khoản và chức năng mang lại lợi ích của tính linh hoạt, nhưng nó cũng có thể làm cho các vấn đề bảo mật nghiêm trọng hơn. Vì tất cả các tính năng có thể được xem xét cùng nhau, việc thiếu đánh giá độc lập có thể làm tăng nguy cơ lỗ hổng tài khoản.
· Khả năng nâng cấp: Khi tài khoản của bạ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 các tính năng và mỗi bản cập nhật triển khai lại các tính năng hiện có đều 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ả, lõi có thể tái sử dụng để cải thiện hiệu quả phát triển tổng thể và giao diện được tiêu chuẩn hóa để đảm bảo 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ụ trên một khái niệm chung: xây dựng kiến trúc trừu tượng hóa tài khoản mô-đun (Modular AA).
Trừu tượng hóa tài khoản mô-đun là một phân khu của sự phát triển AA rộng lớn hơn, hình dung việc mô-đun hóa các tài khoản thông minh để cung cấp các dịch vụ tùy chỉnh cho người dùng và cho phép các nhà phát triển liên tục nâng cao chức năng với các ràng buộc 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 công nghiệp nào là một thách thức rất lớn. Cho đến khi mọi người chấp nhận cùng một tiêu chuẩn, nhiều giải pháp khác nhau có thể xuất hiện trong giai đoạn đầu. Thật đáng khích lệ khi thấy rằng những người làm việc để tinh chỉnh và thúc đẩy sự 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, đang làm việc cùng nhau để đẩy nhanh 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 hàm
Ủy quyền cuộc gọi và hợp đồng proxy
Cuộc gọi bên ngoài và cuộc gọi ủy nhiệm:
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
Giới thiệu về cuộc gọi đại diện
Mặc dù "cuộc gọi được ủy quyền" tương tự như "cuộc gọi", nhưng nó không được thực hiện trong bối cảnh hợp đồng đích, mà trong bối cảnh 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à 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.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Hợp đồng proxy và ủy quyền cuộc gọi
** Để đạt được một cấu trúc có thể kết hợp và nâng cấp, một khái niệm cơ bản về "hợp đồng đại lý" cần phải được giới thiệu. **
Hợp đồng proxy: Một hợp đồng thông thường lưu trữ logic và trạng thái của nó và không thể được cập nhật sau khi triển khai. Hợp đồng proxy được triển khai sang hợp đồng khác bằng cách sử dụng cuộc gọi đại diện. Thực hiện chức năng bằng cách tham chiếu để thực hiện nó 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 vẫn giữ nguyên, bạn có thể triển khai một triển khai mới phía sau nhà môi giới. Hợp đồng proxy có thể nâng cấp và ít tốn kém hơn để triển khai và duy trì trên các blockchain công khai.
Kiến trúc an toàn! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Kiến trúc an toàn
An toàn là gì: An toàn 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 thực chiến, đồng thời nó 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 ứng dụng dựa trên (hoặc lấy cảm hứng từ) An toàn. Ví dụ: Biconomy đã mở rộng Safe với 4337 gốc và đa chữ ký 1/1 khi ra mắt tài khoản hợp đồng thông minh của mình. Chứng kiến việc triển khai hơn 164.000 hợp đồng và thu về hơn 30,7 tỷ đô la giá trị, Safe chắc chắn là một nhà lãnh đạo trong không gian của nó.
Cấu trúc của Safe bao gồm hợp đồng tài khoản an toàn, hợp đồng singleton và hợp đồng mô-đun.
Hợp đồng proxy: Stateful
Tài khoản bảo mật là một hợp đồng proxy vì cuộc gọi được ủy quyền là một hợp đồng singleton. Tài khoản bảo mật chứa các biến trong đó chủ sở hữu, ngưỡng và địa chỉ triển khai đều được đặt làm tác nhân và trạng thái của chúng được xác định dựa trên các biến này.
单例合约(singleton contract):Integration Hub(无状态)
Hợp đồng singleton phục vụ các 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ý.
Mô-đun: Logic và chức năng tùy chỉnh
Hợp đồng mô-đun rất mạnh mẽ. Các plugin dưới dạng các loại mô-đun 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 và có thể hoạt động như một 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, chẳng hạn như Hooks và Function Handlers làm nhân viên bảo vệ, có thể đáp ứng bất kỳ lệnh nào.
Những thay đổi đã thay đổi kể từ khi áp dụng An toàn:
Hợp đồng có thể 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 giữ quyền tự chủ để nâng cấp An toàn lên phiên bản singleton mong muốn.
Các mô-đun có thể kết hợp, có thể 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 các tính 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 theo trường hợp sử dụng của họ, dẫn đến một cách tiếp cận có thể tùy chỉnh cao.
ERC-2535 Kim cương 代理
**! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
Giới thiệu về ERC2535, Đại lý kim cương:
ERC2535 mô hình Diamond được tiêu chuẩn hóa, một hệ thống hợp đồng thông minh mô-đun có thể được nâng cấp / mở rộng quy mô sau khi triển khai mà hầu như không có giới hạn về kích thước. Hiện tại, nhiều đội như Kernel của Zerodev và các thí nghiệm của Soul Wallet đã đượ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 (Stateful) Diamond là một hợp đồng proxy sử dụng phương thức gọi được ủy quyền để gọi một hàm từ việc thực hiện 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 hàm nội tại, thư viện và các biến trạng thái.
Thay đổi với Kim cương:
Hợp đồng có thể nâng cấp: Diamond cung cấp một cách có hệ thống để cô lập các plugin khác nhau và kết nối chúng lại với nhau, chia sẻ dữ liệu giữa chúng và cũng có thể thêm / thay thế / xóa bất kỳ plugin nào trực tiếp bằng tính năng diamondCut. Theo thời gian, sẽ không có giới hạn về số lượng plugin có thể được thêm vào Diamond.
Các plugin mô-đun và có thể tái sử dụng: Các plugin được triển khai có thể được sử dụng bởi bất kỳ số lượng Kim cương nào, giúp 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 Kim cương:
Có rất nhiều điểm tương đồng giữa kiến trúc Safe và Diamond, cả hai đều dựa trên các hợp đồng proxy cốt lõi của chúng và các hợp đồng logic tham chiếu cho khả năng nâng cấp và 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: Với một plugin mới được bật, Safe cần triển khai lại hợp đồng singleton của mình để thực hiện các thay đổi trong proxy của nó. Ngược lại, Diamond đạt được điều này trực tiếp thông qua chức năng diamondCut trong hợp đồng proxy của nó. Sự khác biệt trong cách tiếp cận có nghĩa là Safe vẫn giữ được 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.
· An toàn: Hiện đang được sử dụng trong cả hai cấu trúc, nó cho phép mã bên ngoài thao tác lưu trữ hợp đồng chính. Trong kiến trúc Safe, các cuộc gọi đại diện trỏ đến một hợp đồng logic duy nhất, trong khi Diamond sử dụng các cuộc gọi đại diện trên nhiều hợp đồng-plugin mô-đun. Do đó, một plugin độc hại có thể ghi đè lên một plugin khác, gây ra nguy cơ xung đột lưu trữ và ảnh hưởng đến tính toàn vẹn của proxy.
· Chi phí: Trong cách tiếp cận Kim cương, tính linh hoạt và bảo mật kết hợp với nhau. Điều này làm tăng chi phí và mỗi khi một plugin mới được thêm vào, nó cần phải được kiểm tra đầy đủ. Đ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, một mục đích đầy thách thức, đặc biệt là đối với các doanh nghiệp vừa và nhỏ đang đấu tranh để 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à những 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. Cân bằng 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, Người thực thi và Hook
Hãy thảo luận thêm về điều này bằng cách giới thiệu ERC6900, một tiêu chuẩn lấy cảm hứng từ Kim cương từ nhóm của Alchemy được thiết kế riêng cho ERC-4337. Nó giải quyết những thách thức của mô-đun tài khoản thông minh bằng cách cung cấp một 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 quá trình giao dịch của AA, có ba quy trình chính: xác nhận, thực hiện và chốt. Như chúng ta đã thảo luận trước đó, tất cả các bước này đều có thể được quản lý bằng cách sử dụng mô-đun gọi 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 logic cơ bản của sự tương đồng.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
Tên của 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 của người gọi tài khoản.
Thực thi (UTOR): Thực thi bất kỳ logic tùy chỉnh nào mà tài khoản cho phép.
Hook: Hoạt động như một mô-đun 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 hoàn tác toàn bộ cuộc gọi.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Điều quan trọng là phải tách các mô-đun theo các logic khác nhau. Cách tiếp cận tiêu chuẩn nên chỉ định cách viết các chức năng xác thực, thực hiện và chốt cho các tài khoản hợp đồng thông minh. Cho dù đó là An toàn hay ERC6900, tiêu chuẩn hóa giúp giảm nhu cầu về các nỗ lực phát triển độc đáo cụ thể cho các triển khai hoặc hệ sinh thái nhất định và ngăn chặn sự khóa chặt của nhà cung cấp.
Khám phá và bảo mật mô-đun
Cách tìm và xác thực 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 khu vực cho phép người dùng khám phá các mô-đun có thể kiểm chứng, có thể được gọi là "sổ đăng ký". Sổ đăng ký hoạt động giống như một "cửa hàng ứng dụng" 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.
Safe{Core} 协议
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
Giao thức Safe{Core} là một giao thức mã nguồn mở, có thể tương tác cho các tài khoản hợp đồng thông minh được thiết kế để tăng cường 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ì 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õ.
· 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 một 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à điều phối viên giữa các tài khoản, cơ quan đăng ký và mô-đun. Nó cũng chăm sóc bảo mật như một lớp cấp phép.
· Registry: Registry 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 để tạo môi trường "cửa hàng ứng dụng" mở cho khả năng khám phá và bảo mật.
· Mô-đun: Các mô-đun xử lý chức năng và có nhiều loại ban đầu, bao gồm plugin, móc, trình xác thực chữ ký và trình xử lý chức năng. Các nhà phát triển có thể tham gia miễn là họ đáp ứng các tiêu chí đã thiết lập.
Rhinestone 设计
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
Quá trình diễn ra như sau:
· Tạo lược đồ: Lược đồ cung cấp cấu trúc dữ liệu được xác định trước. Mọi người có thể điều chỉnh nó để phù hợp với trường hợp sử dụng cụ thể của họ.
· Tạo các mô-đun dựa trên lược đồ: Hợp đồng thông minh được đăng ký dưới dạng mô-đun nhận mã byte và chọn ID lược đồ và dữ liệu được lưu trữ trong sổ đăng ký.
· Có được chứng thực của mô-đun: Người chứng minh / kiểm toán viên có thể cung cấp bằng chứng về mô-đun dựa trên kiến trúc. Các chứng thực này có thể bao gồm một mã định danh duy nhất (UID) và tham chiếu đến các chứng thực khác được sử dụng cho liên kết. Họ 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.
· Thực hiện logic phức tạp với trình phân giải: Trình phân tích cú pháp (tùy chọn) 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 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ác cấu trúc 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.
Mặc dù mô hình vẫn đang trong 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. Sổ đăng ký cho phép các nhà phát triển đăng ký mô-đun của họ, kiểm toán viên xác minh tính bảo mật của họ, ví để tích hợp và cho phép người dùng dễ dàng tìm thấy các mô-đun và xác minh thông tin chứng thực của họ. Một số cách sử 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 Rhinestone như một người chứng minh 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 một 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 sổ đăng ký.
· Người dùng: Tham gia thông qua giao diện thân thiện với người dùng, chẳng hạn như ví hoặc dApp, cho phép người dùng kiểm tra thông tin mô-đun và ủy thác niềm tin cho các nhà chứng minh khác nhau.
Khái niệm "đăng ký mô-đun" mở ra những cách để các nhà phát triển plugin và mô-đun kiếm tiền. Nó có thể tiếp tục mở đường cho một "thị trường mô-đun". Một số khía cạnh có thể được giám sát bởi nhóm An toàn, trong khi những khía cạnh khác có thể biểu hiện như một thị trường phi tập trung mời mọi người đóng góp và cung cấp một dấu vết kiểm toán minh bạch. Kết hợp điều này sẽ tránh được sự khóa chặt 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 tính bảo mật của các mô-đun riêng lẻ, nhưng các tài khoản hợp đồng thông minh không phải là hoàn hảo khi nói đến bảo mật rộng hơn. Có thể là một thách thức khi kết 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ữ, điều này làm nổi 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 đề đó.
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ể được giải phóng khỏi sự phức tạp của 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 đạ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ọ.
Ngoài ra, Tài khoản hợp đồng thông minh mô-đun (SCA) chỉ là một phần nhỏ của câu đố áp dụng. Để nhận ra tiềm năng đầy đủ của SCA, các giải pháp Lớp 2 là cần thiết để 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ế ký SCA hiệu quả và khả thi hơn, cơ chế 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.
Trong tương lai, sẽ có nhiều SCA được áp dụng hơn, nhưng nó cũng sẽ đặt ra một số câu hỏi thú vị: làm thế nào các cơ chế giá trị có thể trích xuất của thợ mỏ truyền thống (MEV) tham gia vào không gian để xây dựng các gói và nắm bắt giá trị khi dòng lệnh SCA trở nên đủ lợi nhuận và làm thế nào trừu tượng hóa tài khoản (AA) sẽ đóng vai trò là lớp cơ sở cho các giao dịch "dựa trên mục đích" khi cơ sở hạ tầng trưởng thành?
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Một cái nhìn chuyên sâu về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức
作者:Rui,Nhà đầu tư của SevenX Ventures
编译:Luccy,Joyce,BlockBeats
Rui, một nhà đầu tư tại SevenX Ventures >, đã xác định năm thách thức hàng đầu để áp dụng SCA - tác động của thị trường gấu, khó khăn di chuyển, vấn đề chữ ký, chi phí khí đốt cao và thách thức kỹ thuật - và thảo luận thêm về chúng. Ngoài ra, 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ỏ của những thách thức áp dụng.
Sự 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 đạt được đà và đã được hỗ trợ bởi 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 gấu, khó khăn trong việc di chuyển EOA sang SCA, các vấn đề về chữ ký, chi phí khí đốt cao và quan trọng nhất là những thách thức phát triển.
Ư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, tính không tương tác của chức năng AA là một thách thức lớn, vì sự phân mảnh này cản trở sự tích hợp AA và củng cố khóa nhà cung cấp. Ngoài ra, nó cũng là một thách thức quan trọng để đảm bảo an ninh trong khi có thể nâng cấp và sáng tác.
Sự xuất hiện của trừu tượng hóa tài khoản mô-đun là một thị trường ngách trong xu hướng AA, một cách tiếp cận sáng tạo tách biệt các tài khoản thông minh khỏi các tính 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 nhiều tính năng, bảo mật và tích hợp liền mạch. Trong tương lai, trừu tượng hóa tài khoản mô-đun sẽ cho phép một tài khoản hợp đồng thông minh miễn phí "cửa hàng ứng dụng", 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 thay vì phải tốn quá nhiều công sức xây dựng các tính năng.
Tóm tắt tài khoản ngắn gọn (AA)
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
EOA truyền thống mang lại nhiều thách thức cho việc mọi người tiếp xúc với blockchain, chẳng hạn như cụm từ hạt giống, phí gas, hoạt động chuỗi chéo và nhiều giao dịch.
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à giao dịch 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 các giao dịch cùng một lúc, thay vì phải ký và phát sóng từng giao dịch. Trừu tượng hóa tài khoản cũng có thể kích hoạt nhiều tính năng hơn như cải thiện trải nghiệm người dùng (ví dụ: trừu tượng hóa gas và khóa phiên), giảm chi phí (ví dụ: giao dịch hàng loạt) và cải thiện bảo mật (ví dụ: khôi phục xã hội, đa chữ ký). Hiện tại, có hai cách để trừu tượng hóa tài khoản:
· Lớp giao thức: Một số giao thức nguyên bản 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 mempool duy nhất và luồng giao dịch để hỗ trợ AA, cả từ EOA và SCA đều tuân theo cùng một quy trình, trong khi Starknet đã loại bỏ EOA, tất cả các tài khoản đều là SCA và chúng có ví hợp đồng thông minh gốc như Argent.
· Lớp hợp đồng: Đối với Ethereum và các L2 tương tự, ERC4337 đã giới thiệu một mempool riêng để hỗ trợ AA mà không thay đổi lớp đồng thuận. Những nơi như Stackup, Alchemy, Etherspot, Biconomy, Candide và Plimico đang xây dựng cơ sở hạ tầng gói, trong khi những thứ như Safe, Zerodev, Etherspot và Biconomy đang xây dựng các gói và SDK.
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à đã được ERC 4337 nâng cao hơn nữa 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 chưa thấp bằng EOA.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Hãy đi sâu vào vấn đề nan giải này:
Mặc dù có những lợi thế của AA như đăng nhập liền mạch và trừu tượng hóa gas, trong thị trường gấu hiện tại, nơi tất cả người dùng đều là người dùng EOA được đào tạo và không có nhiều người dùng mới, không có động lực nào để dApp và ví á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 không có gas.
Đối với ví và ứng dụng đã tích lũy được 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, một sơ đồ như EIP-7377 cho phép EOA bắt đầu giao dịch di chuyển một lần.
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ư thế ERC1271 làm cho điều nà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í được triển khai với các đối trọng. ERC-6492, được đề xuất bởi Ambire, là sự kế thừa tương thích ngược với ERC-1271 và có thể giải quyết vấn đề trước đó.
Chi phí triển khai, mô phỏng và thực thi SCA cao hơn so với EOA tiêu chuẩn cũng là một rào cản đối với 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 hành động của người dùng, loại bỏ "muối" được liên kết với tài khoản và hơn thế nữa.
Nhóm ERC-4337 đã xây dựng một repo eth-infinitism cung cấp triển khai cơ bản cho các nhà phát triển. Tuy nhiên, khi các nhà phát triển mở rộng quy mô sang các tính năng chi tiết và 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ã phải đối mặt với nhiều thách thức hơn. Trong bài viết này, chúng ta sẽ đi sâu vào những thách thức kỹ thuật.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Giải quyết các thách thức kỹ thuật với các tài khoản hợp đồng thông minh mô-đun
Các thách thức kỹ thuật có thể được xây dựng thêm thành ba khía cạnh: phân mảnh, bảo mật và khả năng nâng cấp.
· Phân mảnh: Các tính năng hiện 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 plug-in độ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 của mình, khiến các nhà phát triển quyết định nền tảng và nhà cung cấp dịch vụ nào sẽ hỗ trợ. Điều này có thể dẫn đến nền tảng (nhà cung cấp) tiềm năng bị khóa hoặc công việc dư thừa.
· Bảo mật: Mặc dù việc tách các tài khoản và chức năng mang lại lợi ích của tính linh hoạt, nhưng nó cũng có thể làm cho các vấn đề bảo mật nghiêm trọng hơn. Vì tất cả các tính năng có thể được xem xét cùng nhau, việc thiếu đánh giá độc lập có thể làm tăng nguy cơ lỗ hổng tài khoản.
· Khả năng nâng cấp: Khi tài khoản của bạ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 các tính năng và mỗi bản cập nhật triển khai lại các tính năng hiện có đều 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ả, lõi có thể tái sử dụng để cải thiện hiệu quả phát triển tổng thể và giao diện được tiêu chuẩn hóa để đảm bảo 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ụ trên một khái niệm chung: xây dựng kiến trúc trừu tượng hóa tài khoản mô-đun (Modular AA).
Trừu tượng hóa tài khoản mô-đun là một phân khu của sự phát triển AA rộng lớn hơn, hình dung việc mô-đun hóa các tài khoản thông minh để cung cấp các dịch vụ tùy chỉnh cho người dùng và cho phép các nhà phát triển liên tục nâng cao chức năng với các ràng buộc 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 công nghiệp nào là một thách thức rất lớn. Cho đến khi mọi người chấp nhận cùng một tiêu chuẩn, nhiều giải pháp khác nhau có thể xuất hiện trong giai đoạn đầu. Thật đáng khích lệ khi thấy rằng những người làm việc để tinh chỉnh và thúc đẩy sự 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, đang làm việc cùng nhau để đẩy nhanh 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 hàm
Ủy quyền cuộc gọi và hợp đồng proxy
Cuộc gọi bên ngoài và cuộc gọi ủy nhiệm:
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
Giới thiệu về cuộc gọi đại diện
Mặc dù "cuộc gọi được ủy quyền" tương tự như "cuộc gọi", nhưng nó không được thực hiện trong bối cảnh hợp đồng đích, mà trong bối cảnh 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à 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.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Hợp đồng proxy và ủy quyền cuộc gọi
** Để đạt được một cấu trúc có thể kết hợp và nâng cấp, một khái niệm cơ bản về "hợp đồng đại lý" cần phải được giới thiệu. **
Hợp đồng proxy: Một hợp đồng thông thường lưu trữ logic và trạng thái của nó và không thể được cập nhật sau khi triển khai. Hợp đồng proxy được triển khai sang hợp đồng khác bằng cách sử dụng cuộc gọi đại diện. Thực hiện chức năng bằng cách tham chiếu để thực hiện nó 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 vẫn giữ nguyên, bạn có thể triển khai một triển khai mới phía sau nhà môi giới. Hợp đồng proxy có thể nâng cấp và ít tốn kém hơn để triển khai và duy trì trên các blockchain công khai.
Kiến trúc an toàn! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Kiến trúc an toàn
An toàn là gì: An toàn 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 thực chiến, đồng thời nó 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 ứng dụng dựa trên (hoặc lấy cảm hứng từ) An toàn. Ví dụ: Biconomy đã mở rộng Safe với 4337 gốc và đa chữ ký 1/1 khi ra mắt tài khoản hợp đồng thông minh của mình. Chứng kiến việc triển khai hơn 164.000 hợp đồng và thu về hơn 30,7 tỷ đô la giá trị, Safe chắc chắn là một nhà lãnh đạo trong không gian của nó.
Cấu trúc của Safe bao gồm hợp đồng tài khoản an toàn, hợp đồng singleton và hợp đồng mô-đun.
Hợp đồng proxy: Stateful
Tài khoản bảo mật là một hợp đồng proxy vì cuộc gọi được ủy quyền là một hợp đồng singleton. Tài khoản bảo mật chứa các biến trong đó chủ sở hữu, ngưỡng và địa chỉ triển khai đều được đặt làm tác nhân và trạng thái của chúng được xác định dựa trên các biến này.
单例合约(singleton contract):Integration Hub(无状态)
Hợp đồng singleton phục vụ các 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ý.
Mô-đun: Logic và chức năng tùy chỉnh
Hợp đồng mô-đun rất mạnh mẽ. Các plugin dưới dạng các loại mô-đun 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 và có thể hoạt động như một 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, chẳng hạn như Hooks và Function Handlers làm nhân viên bảo vệ, có thể đáp ứng bất kỳ lệnh nào.
Những thay đổi đã thay đổi kể từ khi áp dụng An toàn:
Hợp đồng có thể 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 giữ quyền tự chủ để nâng cấp An toàn lên phiên bản singleton mong muốn.
Các mô-đun có thể kết hợp, có thể 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 các tính 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 theo trường hợp sử dụng của họ, dẫn đến một cách tiếp cận có thể tùy chỉnh cao.
ERC-2535 Kim cương 代理
**! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
Giới thiệu về ERC2535, Đại lý kim cương:
ERC2535 mô hình Diamond được tiêu chuẩn hóa, một hệ thống hợp đồng thông minh mô-đun có thể được nâng cấp / mở rộng quy mô sau khi triển khai mà hầu như không có giới hạn về kích thước. Hiện tại, nhiều đội như Kernel của Zerodev và các thí nghiệm của Soul Wallet đã đượ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 (Stateful) Diamond là một hợp đồng proxy sử dụng phương thức gọi được ủy quyền để gọi một hàm từ việc thực hiện 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 hàm nội tại, thư viện và các biến trạng thái.
Thay đổi với Kim cương:
Hợp đồng có thể nâng cấp: Diamond cung cấp một cách có hệ thống để cô lập các plugin khác nhau và kết nối chúng lại với nhau, chia sẻ dữ liệu giữa chúng và cũng có thể thêm / thay thế / xóa bất kỳ plugin nào trực tiếp bằng tính năng diamondCut. Theo thời gian, sẽ không có giới hạn về số lượng plugin có thể được thêm vào Diamond.
Các plugin mô-đun và có thể tái sử dụng: Các plugin được triển khai có thể được sử dụng bởi bất kỳ số lượng Kim cương nào, giúp 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 Kim cương:
Có rất nhiều điểm tương đồng giữa kiến trúc Safe và Diamond, cả hai đều dựa trên các hợp đồng proxy cốt lõi của chúng và các hợp đồng logic tham chiếu cho khả năng nâng cấp và 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: Với một plugin mới được bật, Safe cần triển khai lại hợp đồng singleton của mình để thực hiện các thay đổi trong proxy của nó. Ngược lại, Diamond đạt được điều này trực tiếp thông qua chức năng diamondCut trong hợp đồng proxy của nó. Sự khác biệt trong cách tiếp cận có nghĩa là Safe vẫn giữ được 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.
· An toàn: Hiện đang được sử dụng trong cả hai cấu trúc, nó cho phép mã bên ngoài thao tác lưu trữ hợp đồng chính. Trong kiến trúc Safe, các cuộc gọi đại diện trỏ đến một hợp đồng logic duy nhất, trong khi Diamond sử dụng các cuộc gọi đại diện trên nhiều hợp đồng-plugin mô-đun. Do đó, một plugin độc hại có thể ghi đè lên một plugin khác, gây ra nguy cơ xung đột lưu trữ và ảnh hưởng đến tính toàn vẹn của proxy.
· Chi phí: Trong cách tiếp cận Kim cương, tính linh hoạt và bảo mật kết hợp với nhau. Điều này làm tăng chi phí và mỗi khi một plugin mới được thêm vào, nó cần phải được kiểm tra đầy đủ. Đ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, một mục đích đầy thách thức, đặc biệt là đối với các doanh nghiệp vừa và nhỏ đang đấu tranh để 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à những 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. Cân bằng 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, Người thực thi và Hook
Hãy thảo luận thêm về điều này bằng cách giới thiệu ERC6900, một tiêu chuẩn lấy cảm hứng từ Kim cương từ nhóm của Alchemy được thiết kế riêng cho ERC-4337. Nó giải quyết những thách thức của mô-đun tài khoản thông minh bằng cách cung cấp một 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 quá trình giao dịch của AA, có ba quy trình chính: xác nhận, thực hiện và chốt. Như chúng ta đã thảo luận trước đó, tất cả các bước này đều có thể được quản lý bằng cách sử dụng mô-đun gọi 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 logic cơ bản của sự tương đồng.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
Tên của 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 của người gọi tài khoản.
Thực thi (UTOR): Thực thi bất kỳ logic tùy chỉnh nào mà tài khoản cho phép.
Hook: Hoạt động như một mô-đun 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 hoàn tác toàn bộ cuộc gọi.
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Điều quan trọng là phải tách các mô-đun theo các logic khác nhau. Cách tiếp cận tiêu chuẩn nên chỉ định cách viết các chức năng xác thực, thực hiện và chốt cho các tài khoản hợp đồng thông minh. Cho dù đó là An toàn hay ERC6900, tiêu chuẩn hóa giúp giảm nhu cầu về các nỗ lực phát triển độc đáo cụ thể cho các triển khai hoặc hệ sinh thái nhất định và ngăn chặn sự khóa chặt của nhà cung cấp.
Khám phá và bảo mật mô-đun
Cách tìm và xác thực 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 khu vực cho phép người dùng khám phá các mô-đun có thể kiểm chứng, có thể được gọi là "sổ đăng ký". Sổ đăng ký hoạt động giống như một "cửa hàng ứng dụng" 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.
Safe{Core} 协议
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
Giao thức Safe{Core} là một giao thức mã nguồn mở, có thể tương tác cho các tài khoản hợp đồng thông minh được thiết kế để tăng cường 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ì 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õ.
· 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 một 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à điều phối viên giữa các tài khoản, cơ quan đăng ký và mô-đun. Nó cũng chăm sóc bảo mật như một lớp cấp phép.
· Registry: Registry 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 để tạo môi trường "cửa hàng ứng dụng" mở cho khả năng khám phá và bảo mật.
· Mô-đun: Các mô-đun xử lý chức năng và có nhiều loại ban đầu, bao gồm plugin, móc, trình xác thực chữ ký và trình xử lý chức năng. Các nhà phát triển có thể tham gia miễn là họ đáp ứng các tiêu chí đã thiết lập.
Rhinestone 设计
! [Một cái nhìn sâu sắc về kiến trúc tài khoản hợp đồng thông minh mô-đun và những thách thức] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
Quá trình diễn ra như sau:
· Tạo lược đồ: Lược đồ cung cấp cấu trúc dữ liệu được xác định trước. Mọi người có thể điều chỉnh nó để phù hợp với trường hợp sử dụng cụ thể của họ.
· Tạo các mô-đun dựa trên lược đồ: Hợp đồng thông minh được đăng ký dưới dạng mô-đun nhận mã byte và chọn ID lược đồ và dữ liệu được lưu trữ trong sổ đăng ký.
· Có được chứng thực của mô-đun: Người chứng minh / kiểm toán viên có thể cung cấp bằng chứng về mô-đun dựa trên kiến trúc. Các chứng thực này có thể bao gồm một mã định danh duy nhất (UID) và tham chiếu đến các chứng thực khác được sử dụng cho liên kết. Họ 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.
· Thực hiện logic phức tạp với trình phân giải: Trình phân tích cú pháp (tùy chọn) 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 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ác cấu trúc 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.
Mặc dù mô hình vẫn đang trong 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. Sổ đăng ký cho phép các nhà phát triển đăng ký mô-đun của họ, kiểm toán viên xác minh tính bảo mật của họ, ví để tích hợp và cho phép người dùng dễ dàng tìm thấy các mô-đun và xác minh thông tin chứng thực của họ. Một số cách sử 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 Rhinestone như một người chứng minh 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 một 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 sổ đăng ký.
· Người dùng: Tham gia thông qua giao diện thân thiện với người dùng, chẳng hạn như ví hoặc dApp, cho phép người dùng kiểm tra thông tin mô-đun và ủy thác niềm tin cho các nhà chứng minh khác nhau.
Khái niệm "đăng ký mô-đun" mở ra những cách để các nhà phát triển plugin và mô-đun kiếm tiền. Nó có thể tiếp tục mở đường cho một "thị trường mô-đun". Một số khía cạnh có thể được giám sát bởi nhóm An toàn, trong khi những khía cạnh khác có thể biểu hiện như một thị trường phi tập trung mời mọi người đóng góp và cung cấp một dấu vết kiểm toán minh bạch. Kết hợp điều này sẽ tránh được sự khóa chặt 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 tính bảo mật của các mô-đun riêng lẻ, nhưng các tài khoản hợp đồng thông minh không phải là hoàn hảo khi nói đến bảo mật rộng hơn. Có thể là một thách thức khi kết 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ữ, điều này làm nổi 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 đề đó.
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ể được giải phóng khỏi sự phức tạp của 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 đạ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ọ.
Ngoài ra, Tài khoản hợp đồng thông minh mô-đun (SCA) chỉ là một phần nhỏ của câu đố áp dụng. Để nhận ra tiềm năng đầy đủ của SCA, các giải pháp Lớp 2 là cần thiết để 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ế ký SCA hiệu quả và khả thi hơn, cơ chế 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.
Trong tương lai, sẽ có nhiều SCA được áp dụng hơn, nhưng nó cũng sẽ đặt ra một số câu hỏi thú vị: làm thế nào các cơ chế giá trị có thể trích xuất của thợ mỏ truyền thống (MEV) tham gia vào không gian để xây dựng các gói và nắm bắt giá trị khi dòng lệnh SCA trở nên đủ lợi nhuận và làm thế nào trừu tượng hóa tài khoản (AA) sẽ đóng vai trò là lớp cơ sở cho các giao dịch "dựa trên mục đích" khi cơ sở hạ tầng trưởng thành?