Tiêu đề gốc: "Những thách thức và kiến trúc tài khoản hợp đồng thông minh mô-đun"

Tác giả gốc: Rui, Nhà đầu tư của SevenX Ventures

Bản tổng hợp gốc: Luccy, Joyce, BlockBeats

Lưu ý của người biên tập:

Tài khoản hợp đồng thông minh (SCA) đang phát triển mạnh mẽ và đã thu hút nhiều doanh nhân cốt lõi trong đó có Vitalik Tuy nhiên, việc áp dụng của SCA vẫn phải đối mặt với 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ư của SevenX Ventures Rui đã chỉ ra năm thách thức lớn đối với việc áp dụng SCA, đó là tác động của thị trường, khó khăn trong việc di chuyển, vấn đề về chữ ký, chi phí gas cao và khó khăn kỹ thuật và những thách thức về Kỹ thuật sẽ được thảo luận thêm. 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.

Để tận dụng tối đa tiềm năng của SCA, cần có giải pháp Lớp 2 để 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 và là cơ chế chữ ký SCA khả thi và hiệu quả hơn về mặt chi phí, cơ chế quản lý và đồng bộ hóa SCA chuỗi chéo cũng như phát triển các giao diện thân thiện với người dùng, v.v.

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:

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ó đà phát triển và được nhiều doanh nhân cốt lõi, bao gồm cả Vitalik, ủng hộ. Mặc dù vậy, việc áp dụng SCA vẫn chưa 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 khi di chuyển từ eoa sang sca, các vấn đề về chữ ký, chi phí gas quá 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 hóa tài khoản (AA) là khả năng tùy chỉnh chức năng bằng cách sử dụ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 và sự phân mảnh này cản trở việc tích hợp AA và củng cố sự 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.

Sự xuất hiện của tính năng trừu tượng hóa tài khoản theo mô-đun là một lĩnh vực thích hợp trong xu hướng phát triển AA. 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 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, việc trừu tượng hóa tài khoản theo 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 cần phải tốn quá nhiều công sức vào việc xây dựng các tính năng.

Mô tả ngắn gọn về tính năng trừu tượng hóa 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, chuỗi chéo hoạt động và nhiều giao dịch, v.v.

Tính năng trừu tượng hóa tài khoản sử dụng tài khoản hợp đồng thông minh để cho phép xác minh và thực thi có thể lập trình. Đ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 cho phép các tính năng bổ sung như trải nghiệm người dùng được cải thiện (ví dụ: trừu tượng Gas và khóa phiên), giảm chi phí (ví dụ: giao dịch hàng loạt) và bảo mật được cải thiện (ví dụ: 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 cục bộ, Giao dịch ZKSync sử dụng một mempool duy nhất và quy trình giao dịch để hỗ trợ AA; dù đến từ EOA hay SCA đều tuân theo quy trình tương tự và Starknet đã xóa EOA, 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ự, ERC4337 giới thiệu một mempool riêng để duy trì lớp đồng thuận mà không thay đổi trường hợp hỗ trợ AA. 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 gói và SDK.

Những khó khăn trong 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à điều này năm ERC 4337 tiếp tục đẩy nó vào tầm nhìn của mọi người. 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 vấn đề nan giải này :

1. Tác động của thị trường giá xuống

Mặc dù AA có các công nghệ tiên tiến như đăng nhập liền mạch và khai thác Gas cùng các lợi thế khác, 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 đào tạo 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 Gasless của họ.

2. Trở ngại di chuyển

Đối với ví và ứng dụng đã tích lũy người dùng và tài sản. Tuy nhiên, 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 giao dịch di chuyển một lần.

3.Vấn đề về chữ ký

Bản thân hợp đồng thông minh không thể ký vào tin nhắn vì nó không có chữ ký giống như EOA Đó là loại khóa riêng. Những nỗ lực như ERC1271 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

So với EOA tiêu chuẩn, triển khai, mô phỏng và thực thi SCA Cao hơn chi phí sẽ phát sinh, đây cũng là một trong những rào cản đối với việc áp dụng. 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 hoạt động của người dùng và loại bỏ “muối” liên kết với tài khoản.

5. Các vấn đề kỹ thuật

Nhóm ERC-4337 đã thiết lập một repo đạ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 dự án thông qua tài khoản hợp đồng thông minh mô-đun Các thách thức

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.

· Phân mảnh: Giờ đây, các tính năng có thể được bật theo nhiều cách, thông qua SCA cụ thể hoặc 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.

· Bảo mật: Mặc dù việc tách rời 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 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 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 của bạn phát triển, điều quan trọng là duy trì khả năng thêm, thay thế hoặc xóa chức năng và triển khai lại mọi chức năng hiện có cập nhật một tính năng 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. 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.

Những thuật ngữ này hội tụ 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 theo mô-đun (mô-đun AA).

Tính trừu tượng hóa tài khoản theo mô-đun là một phần nhỏ của quá trình phát triển AA rộng rãi, trong đó 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 nâng cao chức năng một cách liền mạch với chi phí tối thiểu. những hạn chế.

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à các mô-đun

Cách tài khoản gọi các mô-đun để triển khai chức năng

p> p>

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 đượ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 của hợp đồng đích mà được thực hiệ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 đượ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 đại lý và cuộc gọi ủy quyền

Để đạ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 "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

An toàn là gì: An toàn là mô-đun thông minh hàng đầu Cơ sở hạ tầng tài khoản đượ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, 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ừ) Safe. Ví dụ: Biconomy đã mở rộng An toàn với 4337 gốc và 1/1 multisig khi tung ra các tài khoản hợp đồng thông minh của mình. 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ật (hợp đồng proxy): hợp đồng proxy chính (Stateful)

Tài khoản bảo mật là một hợp đồng proxy vì lệnh gọi đại biểu là một 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 đơn lẻ: Integration Hub (không quốc tịch)

The hợp đồng singleton 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 plugin dưới dạng 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, đồ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ư Móc và Trình xử lý chức năng làm bộ phận bảo vệ an toàn có thể phản hồi bất kỳ lệnh nào.

Những thay đổi do áp dụng An toàn mang lại:

Có Nâng cấp hợp đồng: 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 Safe lên phiên bản đơn lẻ mong muốn.

Các mô-đun có thể tổng hợp và tái sử dụng: Bản chất mô-đun của các phần bổ trợ 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.

Chất kim cương ERC-2535

Giới thiệu về ERC2535, Đại lý Diamond:

ERC2535 Diamond chuẩn hóa mô hình, 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ới hầu như không giới hạn kích thước. Hiện tại, nhiều nhóm như thí nghiệm của Zerodev's Kernel và 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: Cơ quan chính Hợp đồng (Stateful)Diamond là một hợp đồng proxy sử dụng các phương thức gọi đại biểu để gọi các hàm từ quá trình triển khai nó.

Các mô-đun/Plugin/Hợp đồng khía cạnh: Logic tùy chỉnh và chức năng (Không trạng thái)Các mô-đun hay còn gọi là Khía cạnh không có trạng thái Một hợp đồng có thể triển khai chức năng của nó đối với 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 do việc sử dụng Diamond mang lại:

Có Nâng cấp Hợp đồng: Diamond cung cấp một cách có hệ thống để tách biệt các phần bổ trợ khác nhau và kết nối chúng lại với nhau, 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 cách sử dụ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 Diamond theo thời gian.

Plugin dạng mô-đun và có thể tái sử dụng: Bất kỳ số lượng Diamond nào cũng có thể sử dụng các plug-in đã triển khai, 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ó sự khác biệt giữa Safe và Diamond Kiến trúc kim cương Có nhiều điểm tương đồng, cả hai đều dựa vào hợp đồng proxy ở cốt lõi và hợp đồng logic tham chiếu để có khả năng nâng cấp và mô đun hóa.

Sự khác biệt chính giữa hai loại này là việc xử lý các hợp đồng logic. Cụ thể:

· 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ẻ (Singleton) để triển khai Thay đổi. 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, các lệnh gọi đại biểu được chuyển hướng đến một hợp đồng logic duy nhất, trong khi Diamond sử dụng các lệnh gọi đại biểu trên 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í: Trong phương pháp Diamond, tính linh hoạt và rủi ro bảo mật tồn tại cùng một lúc. Đ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 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 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ự.

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

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 mô-đun 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.

Theo logic khác nhau Tách module là rất quan trọng. 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 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.

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

Cách tìm và xác minh mô-đun theo cách mở: một giải pháp đang được tiến hành Liên quan tạo 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, 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{Core} an toàn

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 tính bảo mật của nhiều nhà cung cấp và nhà phát triển. 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ư ERC6900, nhằm tạo ra một môi trường "kho ứng dụng" mở để đạt được khả năng khám phá 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ả

Quy 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 lấy mã byte và chọn ID kiến trúc, sau đó 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/kiểm toán 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.

· Sử dụng trình phân giải để triển khai logic phức tạp: trình phân giải (cài đặt 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 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 (truy vấn) thân thiện với người dùng: 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ố mụ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 Crystal để cùng đóng vai trò là người chứng thực cho các mô-đun nội bộ By. Đồng thời, các tổ chức chứng nhận độc lập cũng có thể tham gia.

·Các nhà phát triển mô-đun: Với sự xuất hiện của các 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 cơ quan đăng ký.

· Người dùng: Việc tham gia được thực hiện 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 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 có thể đảm bảo tính bảo mật của từng mô-đun riêng lẻ nhưng tài khoản hợp đồng thông minh không phải là biện pháp 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 theo mô-đun, các nhà cung cấp ví và dApp có thể Miễn phí bản thân 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ọ.

Ngoài ra, 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 người áp dụng SCA hơn, nhưng nó cũng sẽ đặ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 thợ mỏ truyền thống có thể rút lui. Giá trị (MEV) nhập vào không gian để xây dựng gói và nắm bắt giá trị? 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.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia