作者:Peter Pan, Đồng sáng lập và CTO của Particle Network &Faust,极客Web3
Kể từ năm 2022, trừu tượng hóa tài khoản đã là một chủ đề được thảo luận rộng rãi và khuôn khổ trừu tượng hóa tài khoản với EIP-4337 là cốt lõi dường như đã trở thành một sự đồng thuận chung trong ngành. Sự phổ biến của khái niệm ý định đã thúc đẩy sự tập trung nhiều hơn vào các thành phần tương tác người dùng ngưỡng thấp như vậy.
Tuy nhiên, EIP-4337 vẫn có những điểm đau là sự phân mảnh của các tài khoản Tài khoản thông minh và trải nghiệm người dùng trừu tượng bị phân mảnh cao của các tài khoản chuỗi chéo. **Bài viết này sử dụng các dự án như Biconomy, Safe Core và Particle Network làm ví dụ để khám phá cách thúc đẩy hơn nữa lĩnh vực trừu tượng hóa tài khoản theo khuôn khổ EIP-4337. **
Hiểu khái niệm "trừu tượng hóa tài khoản" từ góc độ trừu tượng hóa quy trình giao dịch
Về trừu tượng hóa tài khoản, Vitalik đã nhiều lần chỉ ra rằng đó là điều kiện cần thiết để hạ thấp ngưỡng của người dùng Ethereum và đạt được sự chấp nhận hàng loạt, và tầm nhìn cốt lõi của nó là cho phép người dùng tùy chỉnh phương thức xác minh chữ ký + tận hưởng thanh toán gas và bắt đầu giao dịch trên chuỗi mà không cần bất kỳ tài sản nào (thường được gọi là giao dịch không gas). Chỉ bằng cách thực hiện các điều kiện tiên quyết này, chúng tôi mới có thể tăng tỷ lệ chuyển đổi của người dùng mới của các ứng dụng Web3.
Trước đây, các đề xuất trừu tượng không phải tài khoản hoặc ví hợp đồng thông minh, mặc dù chúng có thể đạt được trải nghiệm tương tự, nhưng không linh hoạt và hiệu quả, chẳng hạn như Gnosis Safe vẫn yêu cầu địa chỉ EOA để kích hoạt giao dịch và chi phí gas cực kỳ cao.
Sự trừu tượng hóa tài khoản dự định tối ưu hóa từ lớp dưới cùng của cấu trúc tài khoản hợp đồng thông minh để mở đường cho thế hệ hệ thống tài khoản thông minh tiếp theo.
Nhưng từ đề xuất trừu tượng hóa tài khoản thực tế, chúng ta sẽ thấy rằng trọng tâm của họ không phải là chính mô hình tài khoản. Ví dụ: EIP-86, EIP-4337, EIP-6900 và các đề xuất liên quan đến trừu tượng tài khoản khác, tập trung vào tính trừu tượng / mô-đun của toàn bộ quá trình xử lý giao dịch từ khi bắt đầu đến khi nhận nút, xác minh chữ ký, thanh toán gas, v.v., không thực sự chú ý đến sự trừu tượng của cấu trúc tài khoản. Vì vậy, có vẻ thích hợp hơn khi gọi các đề xuất hiện tại là "trừu tượng giao dịch".
Nếu chúng ta hiểu những đề xuất tóm tắt tài khoản nổi tiếng đó từ góc độ "trừu tượng hóa quy trình xử lý giao dịch", chúng ta có thể dễ dàng hiểu những điểm chính của chúng: sự trừu tượng hóa giao dịch này thực sự muốn mang lại trải nghiệm của người dùng cấp Web2 vào và sử dụng sản phẩm vào hệ thống Ethereum, chẳng hạn như danh sách đen / danh sách trắng, không xác minh danh tính để bắt đầu giao dịch trong một khoảng thời gian, không có giao dịch gas, phí thanh toán tiền tệ fiat, v.v.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-036e81bcee-dd1a6f-69ad2a.webp)
Nhưng một số người sẽ hỏi: những điều này có thể được thực hiện trong ví hợp đồng thông minh trong quá khứ không? Giá trị của các sơ đồ trừu tượng như EIP-4337 là gì?
Bản chất của EIP-4337: giải pháp tối ưu cục bộ về trừu tượng hóa tài khoản trong hệ sinh thái Ethereum
Như đã đề cập trong câu hỏi trên, mặc dù ví thông minh trong quá khứ có thể đạt được các chức năng được đề cập ở trên, nhưng các phương pháp triển khai nói chung là thô và thường dựa vào các cơ sở của bên thứ ba tập trung cao. Ví dụ, trong quá khứ, kế hoạch thanh toán khí đốt là giới thiệu nút Relayer của bên thứ ba (EIP-2771). Hơn nữa, việc thiếu các tiêu chuẩn thống nhất giữa các ví thông minh khác nhau không có lợi cho việc phát triển và triển khai các thành phần hỗ trợ. **
Sự hấp dẫn cốt lõi của EIP liên quan đến các khoản trừu tượng tài khoản khác nhau là giải quyết những khiếm khuyết này trong các dự án ví khác nhau thông qua một khuôn khổ tiêu chuẩn được thiết kế cho ví hợp đồng thông minh và thúc đẩy cấu trúc tài khoản trong hệ sinh thái Ethereum từ cấu trúc chức năng cơ bản sang cấu trúc thông minh với trần cao hơn.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-c592064fab-dd1a6f-69ad2a.webp)
Ví dụ: trước sự ra đời của ERC-20 hoặc ERC-721, nhiều triển khai, chức năng và chức năng / giao diện mã thông báo được cung cấp bên ngoài không nhất quán và "không nhất quán" không có lợi cho sự phát triển của việc hỗ trợ các cơ sở của bên thứ ba và kiểm toán mã (thật khó để tưởng tượng các ứng dụng Defi sẽ phát triển như thế nào nếu không có giao thức ERC-20).
Các tiêu chuẩn triển khai giao thức / tính năng được tiêu chuẩn hóa là điều kiện tiên quyết cho các câu chuyện mô-đun và phát triển mô-đun là điều kiện tiên quyết để hầu hết mọi lĩnh vực phát triển mạnh (phân công lao động là nguyên tắc đầu tiên cho hiệu quả). **
Cuối cùng, EIP-4337 đã trở nên nổi bật.
EIP-4337 là một giải pháp tối ưu cục bộ, nhưng có một số góc độ trong khuôn khổ của nó cần được tối ưu hóa
EIP-4337 định nghĩa một bộ tiêu chuẩn giao diện, làm rõ những mô-đun nào phải có ít nhất cho ví thông minh tuân theo giao thức 4337, chức năng / giao diện nào mà mỗi mô-đun nên triển khai, chẳng hạn như Bundler, EntryPoint, Paymaster và chức năng gọi nào nên được cung cấp bên ngoài.
Sau khi làm rõ các quy tắc này, sự tương tác giữa các thành phần khác nhau rõ ràng hơn, thuận tiện để đưa các ý tưởng thiết kế mô-đun vào trừu tượng hóa tài khoản và thiết kế ví thông minh, và các nhà phát triển mô-đun ví cũng được hưởng lợi rất nhiều. **
Tất nhiên, từ góc độ người dùng thuần túy, giá trị do mô hình phát triển ví thông minh mô-đun mang lại là không rõ ràng, bởi vì mọi người không cảm thấy nhiều thay đổi trong chính ví trừu tượng tài khoản trong ngắn hạn. **Nhưng trong trung và dài hạn, các giao thức như EIP-4337 có giá trị tương tự như ERC-20 và ERC-721, đặt nền tảng cho sự phát triển lâu dài của ví trừu tượng tài khoản và là những cột mốc tạo ra kỷ nguyên.
Tuy nhiên, EIP-4337 vẫn còn nhiều vấn đề chưa được giải quyết: ** Ví dụ:
Chức năng trừu tượng hóa tài khoản không đủ plug-in và các nhà phát triển khác nhau dễ dàng phát minh lại bánh xe;
Khả năng tương thích của mô-đun tài khoản kém và toàn bộ hệ thống tài khoản cho thấy xu hướng phân mảnh của hệ sinh thái;
Hệ sinh thái trừu tượng hóa tài khoản giữa các chuỗi khác nhau bị phân mảnh cao, điều này gây khó khăn cho việc cung cấp trải nghiệm thống nhất và chất lượng cao cho người dùng cuối và nhà phát triển và đạt được UX tốt hơn.
Dưới đây, chúng tôi sẽ khám phá các giải pháp cho những vấn đề này.
Hướng tối ưu hóa 1: Chức năng plug-in trừu tượng hóa tài khoản sẽ trở thành cấu hình cơ bản
**Có thể nói rằng một trong những điểm thảo luận cốt lõi liên quan đến trừu tượng hóa tài khoản hiện nay là làm thế nào để nhận ra tốt hơn tính mô-đun của ví trừu tượng tài khoản và cắt giảm độ chi tiết của từng mô-đun thành chi tiết hơn. **
Ví dụ, Biconomy đề xuất một câu chuyện dựa trên EIP-4337 (EIP-6900 với độ chi tiết tốt hơn sẽ được giới thiệu trong tương lai) để thúc đẩy hơn nữa sự phát triển mô-đun của hệ sinh thái trừu tượng tài khoản.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0204bbbe03-dd1a6f-69ad2a.webp)
Cái gọi là plugin chức năng trừu tượng tài khoản thực sự là để làm rõ thông qua một tập hợp các giao thức các mô-đun chính liên quan đến ví hợp đồng thông minh là gì, giao diện / chức năng nào mà các mô-đun này nên triển khai và tên của các giao diện này là gì và cách gọi chúng. Các nhà phát triển bên thứ ba sau đó phát triển các thành phần với các chi tiết khác nhau theo ý tưởng của riêng họ, nhưng các thành phần này sẽ đáp ứng các yêu cầu được đặt ra trong thỏa thuận.
Phiên bản V2 của Biconomy, với EIP-4337 làm xương sống giao thức, đã phát triển các tiêu chuẩn chi tiết hơn và thêm một số giao diện không được đề cập trong 4337. Trong khi nêu rõ những chức năng mà các mô-đun như Bundler, Smart Contract Wallet và Paymaster nên có, Biconomy cho phép các nhà phát triển bên thứ ba triển khai các mô-đun có cùng đặc điểm và các phiên bản khác nhau với các chi tiết mã khác nhau, miễn là chúng tuân theo các chi tiết giao thức được nêu trước bởi Biconomy (tương thích với EIP-4337).
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8f424156ac-dd1a6f-69ad2a.webp)
Đồng thời, Biconomy cũng đưa ra khẩu hiệu "Cửa hàng mô-đun", trong khi đích thân ra mắt SDK mô-đun trừu tượng tài khoản, phần lớn các nhà phát triển được khuyến khích gửi các mô-đun trừu tượng tài khoản được thiết kế của riêng họ, mở rộng "Mô-đun như một dịch vụ", ** để tất cả các dự án ví tuân theo giao thức EIP-4337 có thể trực tiếp áp dụng các mô-đun trừu tượng tài khoản này do người ngoài viết. Khi người dùng tạo một tài khoản thông minh thông qua trang front-end, họ cũng có nhiều lựa chọn đa dạng hơn về việc sử dụng mô-đun nào.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8bb885dd87-dd1a6f-69ad2a.webp)
Mặc dù tính mô-đun thuận tiện cho việc phân công lao động, nhưng nó cũng thuận tiện cho người dùng nhanh chóng chuyển đổi hoặc thêm và xóa một số chức năng nhất định trong ví thông minh (nói thẳng ra, đó là chia độ chi tiết thành các phần tốt hơn).
Biconomy chỉ ra rằng ví hợp đồng thông minh càng mô-đun, càng ít thay đổi cần thực hiện khi cập nhật hoặc nâng cấp (không cần cập nhật hợp đồng Ví hợp đồng thông minh hiện tại của người dùng hoặc sử dụng DelegateCall, chỉ một số mô-đun bên ngoài), giúp người dùng hoặc nhà phát triển khác nhau dễ dàng thay thế một số thành phần nhất định.
Trong bản tóm tắt tài khoản mới trong tương lai của Biconomy, nó cũng sẽ đề cập đến đề xuất EIP-6900, có nhiều mô-đun hơn EIP-4337.
Hướng tối ưu hóa 2: Phân đoạn mô-đun chi tiết hơn để giải quyết vấn đề phân mảnh tài khoản
Liên quan đến đề xuất EIP-6900, ** Safe (trước đây là Gnosis Safe) thực sự đã đưa ra một sách trắng Giao thức lõi an toàn liên quan vào tháng Tám năm nay và sách được vay nhiều nhất là EIP-6900. **
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-427d430661-dd1a6f-69ad2a.webp)
**EIP-6900 chỉ ra rằng một vấn đề với sự trừu tượng hóa hiện tại của các tài khoản mô-đun là sự "phân mảnh" của các tài khoản, hoặc vấn đề của các silo. Ví dụ: mặc dù các nhà cung cấp mô-đun trừu tượng hóa tài khoản khác nhau hoặc các ứng dụng DAPP khác nhau sẽ tương thích với EIP-4337, EIP-4337 không đủ cao cho các mô-đun khác nhau và độ chi tiết tương đối thô, để lại mức độ tự do "quá cao" cho các nhà phát triển mô-đun Tài khoản thông minh (tài khoản thông minh là phần cốt lõi của việc lưu trữ thông tin người dùng và ghi lại xác minh giao dịch tùy chỉnh và logic thanh toán gas).
Bằng cách này, các bên dự án ví khác nhau có xu hướng thiết kế các mô-đun tài khoản thông minh với các thuộc tính độc đáo. ** Về lâu dài, các nhà cung cấp mô-đun trừu tượng hóa tài khoản khác phải ưu tiên những người cung cấp các mô-đun Tài khoản thông minh tương thích và từ từ tạo ra một chuỗi cung ứng thượng nguồn và hạ nguồn cố định, điều này chắc chắn sẽ dẫn đến sự phân mảnh và tách biệt hệ sinh thái mô-đun trừu tượng hóa tài khoản. ** (Giống như trong những ngày đầu của ngành công nghiệp máy tính, các nhà phát triển hệ điều hành phải xem xét nhà sản xuất phần cứng máy tính nào tương thích.)
Để giải quyết vấn đề phân mảnh sinh thái và cải thiện khả năng tương thích của các mô-đun trừu tượng hóa tài khoản được phát triển bởi các nhà cung cấp khác nhau, cách tốt nhất là tiếp tục trừu tượng hóa các tài khoản ví hợp đồng thông minh và làm cho các mô-đun chi tiết hơn.
Sau khi mượn ý tưởng của EIP-6900, sách trắng giao thức ** Safe Core đã thực hiện tối ưu hóa chi tiết hơn về Tài khoản thông minh (tài khoản ví thông minh của người dùng). Giao thức Safe Core chia các mô-đun có thể được gọi bởi mỗi tài khoản ví thông minh thành các plugin, móc, trình xác minh chữ ký, bộ xử lý chức năng và các danh mục khác. **
Mô-đun tài khoản thông minh càng nhẹ càng tốt, hợp đồng tài khoản chỉ lưu trữ dữ liệu và chức năng cơ bản nhất, và các chức năng có thể di chuyển ra bên ngoài đều được ném vào mô-đun phân chia "bộ xử lý chức năng" hoặc "plugin" để thực hiện. Điều này lặp lại cái gọi là nguyên tắc dao cạo của Occam - "không thêm các thực thể trừ khi cần thiết".
Nếu bản thân tài khoản thông minh đủ nhẹ và không liên quan đến các chi tiết quá rườm rà, tài khoản thông minh được phát triển bởi các nhà sản xuất khác nhau sẽ gần gũi hơn về cấu trúc bên trong và tương thích hơn.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0cf696a50a-dd1a6f-69ad2a.webp)
Giao thức Safe Core cũng giới thiệu một sổ đăng ký, tương tự như cửa hàng ứng dụng của iPhone, chứa tất cả các mô-đun có sẵn đã được phê duyệt. Người dùng có thể chọn mô-đun nào sẽ kích hoạt và mỗi khi mô-đun mới được kích hoạt, nó sẽ được xử lý thông qua hợp đồng Minger.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cdcab8e9d3-dd1a6f-69ad2a.webp)
Nói chung, UserOperation sẽ kích hoạt plugin plugin trước, sau đó hợp đồng Manger sẽ kiểm tra xem trạng thái của plugin có bình thường không (có bản ghi trong sổ đăng ký) và nếu bình thường, nó sẽ cho phép yêu cầu của plugin. Nếu cần, các plugin plugin gọi một số chức năng được cung cấp bởi Hook hoặc không. Các thay đổi sau đó được thực hiện đối với trạng thái của tài khoản thông minh liên quan đến UserOperation.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-6403d3e538-dd1a6f-69ad2a.webp)
Thông qua phương pháp phân mảnh mô-đun chi tiết và quy trình lập lịch trình nêu trên, Safe Core Protocol cố gắng triển khai một tập hợp giao thức tương tác mô-đun trừu tượng tài khoản nguồn mở, ý tưởng cốt lõi là làm cho Tài khoản thông minh nhẹ như tài khoản EOA, để cải thiện khả năng tương thích của các mô-đun Tài khoản thông minh được cải thiện bởi các nhà cung cấp khác nhau.
Hướng tối ưu hóa 3: Trừu tượng hóa tài khoản toàn chuỗi, để đạt được các tài khoản hợp nhất trên các chuỗi khác nhau
Nhưng ngay cả với giải pháp nói trên, vẫn còn một vấn đề lớn chưa được giải quyết: các chuỗi khác nhau và các Layer2 khác nhau đang thúc đẩy sự trừu tượng hóa tài khoản với các chi tiết khác nhau và nhiều hình thức sử dụng xung đột với EIP-4337, chẳng hạn như zkSync Era, Starknet, Flow, v.v. Điều này đã dẫn đến sự phân mảnh trong UX của ví, chẳng hạn như địa chỉ ví thông minh của người dùng trên Starknet và địa chỉ ví thông minh trên Arbitrum hoàn toàn không thể thống nhất.
Hơn nữa, trong môi trường đa chuỗi, người dùng đã triển khai độc lập Tài khoản thông minh trên các chuỗi khác nhau và dữ liệu người dùng tương ứng thường nằm rải rác trong các hợp đồng này. Nếu dữ liệu người dùng như khóa cần được cập nhật, cần phải bắt đầu giao dịch nhiều lần trong nhiều chuỗi và rất khó để đảm bảo tính nhất quán của Tài khoản thông minh.
Bản thân Vitalik trước đây đã đề xuất một tập hợp các chương trình tài khoản thông minh thống nhất và dễ quản lý toàn chuỗi, ** lược đồ này sử dụng Ethereum hoặc ZKRollup bảo mật cao làm chuỗi nguồn, triển khai hợp đồng Keystore, lưu trữ khóa toàn cầu của người dùng và sau đó tất cả các tài khoản hợp đồng thông minh của người dùng trên L2 chia sẻ khóa toàn cầu được lưu trữ trong hợp đồng Keystore.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-fad1fc1c55-dd1a6f-69ad2a.webp)
Tuy nhiên, giải pháp này cực kỳ tốn kém, tức là bất cứ khi nào khóa toàn cục được ghi trong hợp đồng Keystore trên chuỗi nguồn thay đổi, mỗi tài khoản trên chuỗi L2/target cần đồng bộ khóa mới thông qua tương tác chéo chuỗi. Tương tác chuỗi chéo giữa Ethereum và L2 quá đắt để người dùng có thể mua được. Và cần lưu ý rằng tài khoản hợp đồng thông minh khác với tài khoản EOA, vốn đã thống nhất đa chuỗi (thống nhất giữa các chuỗi EVM) vì phương thức tạo địa chỉ duy nhất của chúng, nhưng tài khoản hợp đồng thông minh hoàn toàn khác nhau và người dùng khó có được tài khoản hợp đồng thông minh có cùng địa chỉ trên các chuỗi khác nhau.
Particle Network đã đưa ra cách tiếp cận riêng cho vấn đề này. Mặc dù ý tưởng chung giống như ý tưởng của Vitalik, cũng là tách biệt lưu trữ và mã của tài khoản thông minh, Particle Network dự định sử dụng một chuỗi độc lập, Particle Network Chain, làm cơ sở dữ liệu lưu trữ toàn chuỗi của tài khoản thông minh, thông qua các giải pháp nhắn tin chuỗi chéo của bên thứ ba (LayerZero, CCIP, Axelar, Connext). v.v.) Đồng bộ hóa các thay đổi của người dùng đối với bộ nhớ tài khoản với tài khoản cục bộ trên các chuỗi khác.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-2e6d60197a-dd1a6f-69ad2a.webp)
(Trừu tượng hóa tài khoản đa chuỗi của Particle Network)
Cụ thể, hệ thống trừu tượng hóa tài khoản toàn chuỗi của Particle Network yêu cầu người dùng phải có một địa chỉ tài khoản hợp đồng thông minh thống nhất trên các chuỗi EVM khác nhau, yêu cầu triển khai một bộ Hợp đồng triển khai trên các chuỗi khác nhau;
Người dùng phải kích hoạt tạo tài khoản mới trên Particle Network Chain, sau đó Particle Chain sẽ kích hoạt Deployer Contract trên tất cả các chuỗi, đảm bảo rằng các địa chỉ tài khoản hợp đồng thông minh được tạo cho người dùng trên các chuỗi khác nhau là thống nhất hoặc người dùng có thể hoàn thành quá trình tương tác đa chuỗi thông qua hợp đồng trên Particle Chain mà không cần biết về các chuỗi khác và có thể sử dụng Unified Gas Token như một phương thức thanh toán phí thống nhất.
Việc trừu tượng hóa tài khoản toàn chuỗi cũng làm cho Hoạt động người dùng của Cross-Chain trở nên khả thi, kích hoạt giao dịch của chuỗi mục tiêu thông qua Hoạt động của người dùng của chuỗi nguồn và thanh toán Gas tương ứng, chẳng hạn như sử dụng USDC của Polygon để mua NFT trên Base.
Tuy nhiên, giải pháp Particle Network đòi hỏi mức độ hợp tác cao giữa Hợp đồng Deployer và thành phần nhắn tin chuỗi chéo để đạt được sự đồng bộ hóa của Tài khoản đa chuỗi và Lưu trữ chuỗi nguồn, thực sự có yêu cầu cao đối với oracle hoặc cầu nối thông điệp chuỗi chéo mà nó sử dụng (vấn đề này dường như tồn tại trong tất cả các sơ đồ liên quan đến khả năng tương tác toàn chuỗi).
Tuy nhiên, đồng bộ hóa tài khoản chuỗi chéo của người dùng có thể linh hoạt cấu hình kết hợp các Message Bridge khác nhau, thay vì chỉ dựa vào một Bridge nhất định, chẳng hạn như chiến lược có thể được định cấu hình là 2/3, dựa vào xác nhận của bất kỳ hai LayerZero, Axelar và Connext để xác nhận sự thay đổi của Storage trên chuỗi đích, điều này có thể giải quyết xấp xỉ vấn đề phụ thuộc một điểm này.
Khả năng tương tác liền mạch của chuỗi đầy đủ trên EVM và không EVM là một bước tiến xa hơn trong việc trừu tượng hóa các tài khoản chuỗi đầy đủ trong hệ sinh thái Ethereum
Mặc dù có các tài khoản quản lý chính và hợp nhất trên toàn chuỗi EVM, nhưng vẫn còn chỗ để tối ưu hóa trong việc trừu tượng hóa tài khoản toàn chuỗi: các chuỗi không tương thích với EVM, chẳng hạn như Aptos, Solana, Sui, v.v., không thể đảm bảo rằng địa chỉ tài khoản hợp đồng thông minh do người dùng tạo phù hợp với chuỗi EVM; Đồng thời, nếu chuỗi không phải EVM không triển khai giao thức EIP-4337 với sơ đồ tương đương, rất khó để tuân theo khái niệm trừu tượng về tài khoản toàn chuỗi do Vitalik và Particle Network đề xuất ở trên.
Ngoài ra, bản thân dự án ví tương thích EIP-4337 cũng có chỗ để cải thiện. Hầu hết các nút bundler được sử dụng bởi ví thông minh đều được chạy chính thức độc lập và thậm chí không giao tiếp với nhau và nhiều dự án ví thông minh thực sự tạo thành một chuỗi của riêng chúng, điều này mang lại rất nhiều rủi ro (khả năng chống kiểm duyệt, khả năng sử dụng). Xây dựng một giao diện front-end duy nhất thống nhất trên hầu hết các chuỗi có thể rất khó khăn. Một giải pháp là giới thiệu một thiết kế tập trung vào mục đích, thêm một lớp lên trên sự trừu tượng hóa tài khoản toàn chuỗi và coi hệ sinh thái EIP-4337 của Ethereum hoặc các cơ sở trừu tượng hóa tài khoản gốc của chuỗi khác (như zkSync) là các trường hợp cụ thể thuộc loại Bộ giải / Lò phản ứng và cách chọn Bộ giải phù hợp là một nhiệm vụ cấp cao hơn. **
Lấy Particle Network làm ví dụ, nó đề xuất triển khai Ý định trừu tượng ngắn gọn, trong khi các trừu tượng tài khoản khác nhau chỉ là một lớp các trường hợp của các giải pháp Ý định được bao gồm trong Bộ giải.
Đầu tiên, giao diện người dùng sẽ chịu trách nhiệm chuyển đổi các yêu cầu ngôn ngữ tự nhiên hoặc tương tác người dùng tùy ý thành các mô tả lập trình cụ thể, bao gồm các ràng buộc đầu vào và ràng buộc đầu ra (nói một cách thẳng thắn, đó là các điều kiện đầu vào và khoảng kết quả đầu ra đáp ứng yêu cầu của người dùng), và sau đó một hoặc nhiều Bộ giải trong mạng Bộ giải sẽ chứa các ràng buộc đầu vào và đầu ra cụ thể của Giao dịch. Chuyển tiếp đến các hợp đồng Solver được triển khai trên chuỗi (Bộ giải không chỉ có các cơ sở nút mà còn có các bộ phận hợp đồng trên chuỗi). Hợp đồng Solver sẽ truyền hướng dẫn ý định đến hợp đồng Reactor (quản lý tài khoản của người dùng trên chuỗi), sẽ gọi các mô-đun khác để hoàn thành tương tác cuối cùng.
Yêu cầu của người dùng lần đầu tiên được biết đến bởi mạng Solver, do đó người dùng không cần phải nhận thức chuỗi cơ bản hoặc xây dựng các trừu tượng tài khoản khác nhau và phần này được để lại cho Bộ giải để xây dựng một giải pháp cụ thể.
Tất nhiên, những ý tưởng này vẫn chỉ là một khuôn khổ lý thuyết và các chi tiết thực hiện đằng sau vẫn chưa được Particle Network chính thức đưa ra.
Hiện tại, rõ ràng là một thị trường Bộ giải cạnh tranh sẽ được sinh ra trong tương lai và người dùng có thể bắt đầu đấu giá để cho phép nhiều Bộ giải đưa ra các giải pháp khác nhau và thông qua hình thức giao dịch mô phỏng cục bộ, giải pháp tốt nhất có thể được chọn và Bộ giải tương ứng có thể được khuyến khích. Hình thức khuyến khích phụ thuộc vào các nhà thiết kế giao thức của Mạng giải (Particle Network dự định sử dụng mã thông báo PNT làm mã thông báo khuyến khích cho thị trường đấu giá Bộ giải của mình).
**Mục đích hiện tại về cơ bản che chắn các chi tiết phức tạp của lớp dưới và trừu tượng hóa nó thành một lớp cao hơn, ** thiết kế phân lớp như vậy với bản chất của giao thức TCP / IP là cần thiết cho trải nghiệm người dùng và trải nghiệm nhà phát triển dưới khả năng tương tác liền mạch của toàn bộ chuỗi.
Nắm bắt việc áp dụng hàng loạt trừu tượng tài khoản
Khi chúng tôi tối ưu hóa khung 4337 trong hệ sinh thái Ethereum từ mọi góc độ và cũng thúc đẩy khả năng tương tác liền mạch trên các hệ sinh thái Ethereum và không phải Ethereum, để hỗ trợ việc áp dụng trừu tượng tài khoản quy mô lớn, chúng tôi cảm thấy rằng chúng tôi vẫn cần một sản phẩm mở rộng phía cung và phía cầu. Nó có thể làm giảm việc sử dụng các sản phẩm và dịch vụ Web3 khác nhau của người dùng cuối, đồng thời tập trung vào các nhà phát triển dịch vụ và hạ thấp ngưỡng cho các nhà phát triển. **
Một trong những sản phẩm tốt nhất cho vai trò này là sản phẩm Modular Smart Wallet-as-Service của Particle Network:
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-3a8144f020-dd1a6f-69ad2a.webp)
Dịch vụ cung cấp một bộ API dễ sử dụng cho phép các nhà phát triển dễ dàng tích hợp chức năng trừu tượng hóa tài khoản mô-đun vào các ứng dụng của họ;
Các nhà phát triển có thể sử dụng dịch vụ để tạo và quản lý các tài khoản toàn chuỗi, thực hiện tương tác chuỗi chéo và sử dụng phương thức thanh toán phí thống nhất;
Một dịch vụ như vậy sẽ cung cấp cho các nhà phát triển một cách linh hoạt và thuận tiện hơn để xây dựng các ứng dụng đa chuỗi và thúc đẩy việc áp dụng rộng rãi các trừu tượng tài khoản.
Ngoài các tính năng thân thiện với nhà phát triển ở trên, tính năng quan trọng nhất là sản phẩm Ví thông minh mô-đun dưới dạng dịch vụ ** của Particle Network xây dựng một hệ sinh thái mở dựa trên điện toán chữ ký và hướng đến trường trừu tượng hóa tài khoản của nhà phát triển, ngoài việc cung cấp các mô-đun sản phẩm trừu tượng tài khoản tự phát triển, tích hợp nhiều loại sản phẩm và dịch vụ trừu tượng tài khoản khác nhau. Nó có thể nhanh chóng thúc đẩy việc áp dụng các sản phẩm và dịch vụ của các nhà phát triển khác nhau trong toàn bộ lĩnh vực trừu tượng hóa tài khoản.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-20ede5c527-dd1a6f-69ad2a.webp)
Hãy để công nghệ phục vụ nhu cầu, sau khi giải quyết các hạn chế của tất cả các góc độ của khung ERC-4337, việc cải thiện trải nghiệm nhà phát triển *** sẽ quảng bá nhiều sản phẩm hơn với ** trải nghiệm người dùng ** tuyệt vời, thúc đẩy ngành công nghiệp Web3 từ ngành tài chính thân thiện với tiền điện tử sang ngành công nghiệp tiêu dùng thân thiện với đại chúng.
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.
Tại sao sự trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố EIP-4337?
作者:Peter Pan, Đồng sáng lập và CTO của Particle Network &Faust,极客Web3
Kể từ năm 2022, trừu tượng hóa tài khoản đã là một chủ đề được thảo luận rộng rãi và khuôn khổ trừu tượng hóa tài khoản với EIP-4337 là cốt lõi dường như đã trở thành một sự đồng thuận chung trong ngành. Sự phổ biến của khái niệm ý định đã thúc đẩy sự tập trung nhiều hơn vào các thành phần tương tác người dùng ngưỡng thấp như vậy.
Tuy nhiên, EIP-4337 vẫn có những điểm đau là sự phân mảnh của các tài khoản Tài khoản thông minh và trải nghiệm người dùng trừu tượng bị phân mảnh cao của các tài khoản chuỗi chéo. **Bài viết này sử dụng các dự án như Biconomy, Safe Core và Particle Network làm ví dụ để khám phá cách thúc đẩy hơn nữa lĩnh vực trừu tượng hóa tài khoản theo khuôn khổ EIP-4337. **
Hiểu khái niệm "trừu tượng hóa tài khoản" từ góc độ trừu tượng hóa quy trình giao dịch
Về trừu tượng hóa tài khoản, Vitalik đã nhiều lần chỉ ra rằng đó là điều kiện cần thiết để hạ thấp ngưỡng của người dùng Ethereum và đạt được sự chấp nhận hàng loạt, và tầm nhìn cốt lõi của nó là cho phép người dùng tùy chỉnh phương thức xác minh chữ ký + tận hưởng thanh toán gas và bắt đầu giao dịch trên chuỗi mà không cần bất kỳ tài sản nào (thường được gọi là giao dịch không gas). Chỉ bằng cách thực hiện các điều kiện tiên quyết này, chúng tôi mới có thể tăng tỷ lệ chuyển đổi của người dùng mới của các ứng dụng Web3.
Trước đây, các đề xuất trừu tượng không phải tài khoản hoặc ví hợp đồng thông minh, mặc dù chúng có thể đạt được trải nghiệm tương tự, nhưng không linh hoạt và hiệu quả, chẳng hạn như Gnosis Safe vẫn yêu cầu địa chỉ EOA để kích hoạt giao dịch và chi phí gas cực kỳ cao.
Sự trừu tượng hóa tài khoản dự định tối ưu hóa từ lớp dưới cùng của cấu trúc tài khoản hợp đồng thông minh để mở đường cho thế hệ hệ thống tài khoản thông minh tiếp theo.
Nhưng từ đề xuất trừu tượng hóa tài khoản thực tế, chúng ta sẽ thấy rằng trọng tâm của họ không phải là chính mô hình tài khoản. Ví dụ: EIP-86, EIP-4337, EIP-6900 và các đề xuất liên quan đến trừu tượng tài khoản khác, tập trung vào tính trừu tượng / mô-đun của toàn bộ quá trình xử lý giao dịch từ khi bắt đầu đến khi nhận nút, xác minh chữ ký, thanh toán gas, v.v., không thực sự chú ý đến sự trừu tượng của cấu trúc tài khoản. Vì vậy, có vẻ thích hợp hơn khi gọi các đề xuất hiện tại là "trừu tượng giao dịch".
Nếu chúng ta hiểu những đề xuất tóm tắt tài khoản nổi tiếng đó từ góc độ "trừu tượng hóa quy trình xử lý giao dịch", chúng ta có thể dễ dàng hiểu những điểm chính của chúng: sự trừu tượng hóa giao dịch này thực sự muốn mang lại trải nghiệm của người dùng cấp Web2 vào và sử dụng sản phẩm vào hệ thống Ethereum, chẳng hạn như danh sách đen / danh sách trắng, không xác minh danh tính để bắt đầu giao dịch trong một khoảng thời gian, không có giao dịch gas, phí thanh toán tiền tệ fiat, v.v.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-036e81bcee-dd1a6f-69ad2a.webp)
Nhưng một số người sẽ hỏi: những điều này có thể được thực hiện trong ví hợp đồng thông minh trong quá khứ không? Giá trị của các sơ đồ trừu tượng như EIP-4337 là gì?
Bản chất của EIP-4337: giải pháp tối ưu cục bộ về trừu tượng hóa tài khoản trong hệ sinh thái Ethereum
Như đã đề cập trong câu hỏi trên, mặc dù ví thông minh trong quá khứ có thể đạt được các chức năng được đề cập ở trên, nhưng các phương pháp triển khai nói chung là thô và thường dựa vào các cơ sở của bên thứ ba tập trung cao. Ví dụ, trong quá khứ, kế hoạch thanh toán khí đốt là giới thiệu nút Relayer của bên thứ ba (EIP-2771). Hơn nữa, việc thiếu các tiêu chuẩn thống nhất giữa các ví thông minh khác nhau không có lợi cho việc phát triển và triển khai các thành phần hỗ trợ. **
Sự hấp dẫn cốt lõi của EIP liên quan đến các khoản trừu tượng tài khoản khác nhau là giải quyết những khiếm khuyết này trong các dự án ví khác nhau thông qua một khuôn khổ tiêu chuẩn được thiết kế cho ví hợp đồng thông minh và thúc đẩy cấu trúc tài khoản trong hệ sinh thái Ethereum từ cấu trúc chức năng cơ bản sang cấu trúc thông minh với trần cao hơn.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-c592064fab-dd1a6f-69ad2a.webp)
Ví dụ: trước sự ra đời của ERC-20 hoặc ERC-721, nhiều triển khai, chức năng và chức năng / giao diện mã thông báo được cung cấp bên ngoài không nhất quán và "không nhất quán" không có lợi cho sự phát triển của việc hỗ trợ các cơ sở của bên thứ ba và kiểm toán mã (thật khó để tưởng tượng các ứng dụng Defi sẽ phát triển như thế nào nếu không có giao thức ERC-20).
Các tiêu chuẩn triển khai giao thức / tính năng được tiêu chuẩn hóa là điều kiện tiên quyết cho các câu chuyện mô-đun và phát triển mô-đun là điều kiện tiên quyết để hầu hết mọi lĩnh vực phát triển mạnh (phân công lao động là nguyên tắc đầu tiên cho hiệu quả). **
Cuối cùng, EIP-4337 đã trở nên nổi bật.
EIP-4337 là một giải pháp tối ưu cục bộ, nhưng có một số góc độ trong khuôn khổ của nó cần được tối ưu hóa
EIP-4337 định nghĩa một bộ tiêu chuẩn giao diện, làm rõ những mô-đun nào phải có ít nhất cho ví thông minh tuân theo giao thức 4337, chức năng / giao diện nào mà mỗi mô-đun nên triển khai, chẳng hạn như Bundler, EntryPoint, Paymaster và chức năng gọi nào nên được cung cấp bên ngoài.
Sau khi làm rõ các quy tắc này, sự tương tác giữa các thành phần khác nhau rõ ràng hơn, thuận tiện để đưa các ý tưởng thiết kế mô-đun vào trừu tượng hóa tài khoản và thiết kế ví thông minh, và các nhà phát triển mô-đun ví cũng được hưởng lợi rất nhiều. **
Tất nhiên, từ góc độ người dùng thuần túy, giá trị do mô hình phát triển ví thông minh mô-đun mang lại là không rõ ràng, bởi vì mọi người không cảm thấy nhiều thay đổi trong chính ví trừu tượng tài khoản trong ngắn hạn. **Nhưng trong trung và dài hạn, các giao thức như EIP-4337 có giá trị tương tự như ERC-20 và ERC-721, đặt nền tảng cho sự phát triển lâu dài của ví trừu tượng tài khoản và là những cột mốc tạo ra kỷ nguyên.
Tuy nhiên, EIP-4337 vẫn còn nhiều vấn đề chưa được giải quyết: ** Ví dụ:
Chức năng trừu tượng hóa tài khoản không đủ plug-in và các nhà phát triển khác nhau dễ dàng phát minh lại bánh xe;
Khả năng tương thích của mô-đun tài khoản kém và toàn bộ hệ thống tài khoản cho thấy xu hướng phân mảnh của hệ sinh thái;
Hệ sinh thái trừu tượng hóa tài khoản giữa các chuỗi khác nhau bị phân mảnh cao, điều này gây khó khăn cho việc cung cấp trải nghiệm thống nhất và chất lượng cao cho người dùng cuối và nhà phát triển và đạt được UX tốt hơn.
Dưới đây, chúng tôi sẽ khám phá các giải pháp cho những vấn đề này.
Hướng tối ưu hóa 1: Chức năng plug-in trừu tượng hóa tài khoản sẽ trở thành cấu hình cơ bản
**Có thể nói rằng một trong những điểm thảo luận cốt lõi liên quan đến trừu tượng hóa tài khoản hiện nay là làm thế nào để nhận ra tốt hơn tính mô-đun của ví trừu tượng tài khoản và cắt giảm độ chi tiết của từng mô-đun thành chi tiết hơn. **
Ví dụ, Biconomy đề xuất một câu chuyện dựa trên EIP-4337 (EIP-6900 với độ chi tiết tốt hơn sẽ được giới thiệu trong tương lai) để thúc đẩy hơn nữa sự phát triển mô-đun của hệ sinh thái trừu tượng tài khoản.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0204bbbe03-dd1a6f-69ad2a.webp)
Cái gọi là plugin chức năng trừu tượng tài khoản thực sự là để làm rõ thông qua một tập hợp các giao thức các mô-đun chính liên quan đến ví hợp đồng thông minh là gì, giao diện / chức năng nào mà các mô-đun này nên triển khai và tên của các giao diện này là gì và cách gọi chúng. Các nhà phát triển bên thứ ba sau đó phát triển các thành phần với các chi tiết khác nhau theo ý tưởng của riêng họ, nhưng các thành phần này sẽ đáp ứng các yêu cầu được đặt ra trong thỏa thuận.
Phiên bản V2 của Biconomy, với EIP-4337 làm xương sống giao thức, đã phát triển các tiêu chuẩn chi tiết hơn và thêm một số giao diện không được đề cập trong 4337. Trong khi nêu rõ những chức năng mà các mô-đun như Bundler, Smart Contract Wallet và Paymaster nên có, Biconomy cho phép các nhà phát triển bên thứ ba triển khai các mô-đun có cùng đặc điểm và các phiên bản khác nhau với các chi tiết mã khác nhau, miễn là chúng tuân theo các chi tiết giao thức được nêu trước bởi Biconomy (tương thích với EIP-4337).
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8f424156ac-dd1a6f-69ad2a.webp)
Đồng thời, Biconomy cũng đưa ra khẩu hiệu "Cửa hàng mô-đun", trong khi đích thân ra mắt SDK mô-đun trừu tượng tài khoản, phần lớn các nhà phát triển được khuyến khích gửi các mô-đun trừu tượng tài khoản được thiết kế của riêng họ, mở rộng "Mô-đun như một dịch vụ", ** để tất cả các dự án ví tuân theo giao thức EIP-4337 có thể trực tiếp áp dụng các mô-đun trừu tượng tài khoản này do người ngoài viết. Khi người dùng tạo một tài khoản thông minh thông qua trang front-end, họ cũng có nhiều lựa chọn đa dạng hơn về việc sử dụng mô-đun nào.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8bb885dd87-dd1a6f-69ad2a.webp)
Mặc dù tính mô-đun thuận tiện cho việc phân công lao động, nhưng nó cũng thuận tiện cho người dùng nhanh chóng chuyển đổi hoặc thêm và xóa một số chức năng nhất định trong ví thông minh (nói thẳng ra, đó là chia độ chi tiết thành các phần tốt hơn).
Biconomy chỉ ra rằng ví hợp đồng thông minh càng mô-đun, càng ít thay đổi cần thực hiện khi cập nhật hoặc nâng cấp (không cần cập nhật hợp đồng Ví hợp đồng thông minh hiện tại của người dùng hoặc sử dụng DelegateCall, chỉ một số mô-đun bên ngoài), giúp người dùng hoặc nhà phát triển khác nhau dễ dàng thay thế một số thành phần nhất định.
Trong bản tóm tắt tài khoản mới trong tương lai của Biconomy, nó cũng sẽ đề cập đến đề xuất EIP-6900, có nhiều mô-đun hơn EIP-4337.
Hướng tối ưu hóa 2: Phân đoạn mô-đun chi tiết hơn để giải quyết vấn đề phân mảnh tài khoản
Liên quan đến đề xuất EIP-6900, ** Safe (trước đây là Gnosis Safe) thực sự đã đưa ra một sách trắng Giao thức lõi an toàn liên quan vào tháng Tám năm nay và sách được vay nhiều nhất là EIP-6900. **
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-427d430661-dd1a6f-69ad2a.webp)
**EIP-6900 chỉ ra rằng một vấn đề với sự trừu tượng hóa hiện tại của các tài khoản mô-đun là sự "phân mảnh" của các tài khoản, hoặc vấn đề của các silo. Ví dụ: mặc dù các nhà cung cấp mô-đun trừu tượng hóa tài khoản khác nhau hoặc các ứng dụng DAPP khác nhau sẽ tương thích với EIP-4337, EIP-4337 không đủ cao cho các mô-đun khác nhau và độ chi tiết tương đối thô, để lại mức độ tự do "quá cao" cho các nhà phát triển mô-đun Tài khoản thông minh (tài khoản thông minh là phần cốt lõi của việc lưu trữ thông tin người dùng và ghi lại xác minh giao dịch tùy chỉnh và logic thanh toán gas).
Bằng cách này, các bên dự án ví khác nhau có xu hướng thiết kế các mô-đun tài khoản thông minh với các thuộc tính độc đáo. ** Về lâu dài, các nhà cung cấp mô-đun trừu tượng hóa tài khoản khác phải ưu tiên những người cung cấp các mô-đun Tài khoản thông minh tương thích và từ từ tạo ra một chuỗi cung ứng thượng nguồn và hạ nguồn cố định, điều này chắc chắn sẽ dẫn đến sự phân mảnh và tách biệt hệ sinh thái mô-đun trừu tượng hóa tài khoản. ** (Giống như trong những ngày đầu của ngành công nghiệp máy tính, các nhà phát triển hệ điều hành phải xem xét nhà sản xuất phần cứng máy tính nào tương thích.)
Để giải quyết vấn đề phân mảnh sinh thái và cải thiện khả năng tương thích của các mô-đun trừu tượng hóa tài khoản được phát triển bởi các nhà cung cấp khác nhau, cách tốt nhất là tiếp tục trừu tượng hóa các tài khoản ví hợp đồng thông minh và làm cho các mô-đun chi tiết hơn.
Sau khi mượn ý tưởng của EIP-6900, sách trắng giao thức ** Safe Core đã thực hiện tối ưu hóa chi tiết hơn về Tài khoản thông minh (tài khoản ví thông minh của người dùng). Giao thức Safe Core chia các mô-đun có thể được gọi bởi mỗi tài khoản ví thông minh thành các plugin, móc, trình xác minh chữ ký, bộ xử lý chức năng và các danh mục khác. **
Mô-đun tài khoản thông minh càng nhẹ càng tốt, hợp đồng tài khoản chỉ lưu trữ dữ liệu và chức năng cơ bản nhất, và các chức năng có thể di chuyển ra bên ngoài đều được ném vào mô-đun phân chia "bộ xử lý chức năng" hoặc "plugin" để thực hiện. Điều này lặp lại cái gọi là nguyên tắc dao cạo của Occam - "không thêm các thực thể trừ khi cần thiết".
Nếu bản thân tài khoản thông minh đủ nhẹ và không liên quan đến các chi tiết quá rườm rà, tài khoản thông minh được phát triển bởi các nhà sản xuất khác nhau sẽ gần gũi hơn về cấu trúc bên trong và tương thích hơn.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0cf696a50a-dd1a6f-69ad2a.webp)
Giao thức Safe Core cũng giới thiệu một sổ đăng ký, tương tự như cửa hàng ứng dụng của iPhone, chứa tất cả các mô-đun có sẵn đã được phê duyệt. Người dùng có thể chọn mô-đun nào sẽ kích hoạt và mỗi khi mô-đun mới được kích hoạt, nó sẽ được xử lý thông qua hợp đồng Minger.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cdcab8e9d3-dd1a6f-69ad2a.webp)
Nói chung, UserOperation sẽ kích hoạt plugin plugin trước, sau đó hợp đồng Manger sẽ kiểm tra xem trạng thái của plugin có bình thường không (có bản ghi trong sổ đăng ký) và nếu bình thường, nó sẽ cho phép yêu cầu của plugin. Nếu cần, các plugin plugin gọi một số chức năng được cung cấp bởi Hook hoặc không. Các thay đổi sau đó được thực hiện đối với trạng thái của tài khoản thông minh liên quan đến UserOperation.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-6403d3e538-dd1a6f-69ad2a.webp)
Thông qua phương pháp phân mảnh mô-đun chi tiết và quy trình lập lịch trình nêu trên, Safe Core Protocol cố gắng triển khai một tập hợp giao thức tương tác mô-đun trừu tượng tài khoản nguồn mở, ý tưởng cốt lõi là làm cho Tài khoản thông minh nhẹ như tài khoản EOA, để cải thiện khả năng tương thích của các mô-đun Tài khoản thông minh được cải thiện bởi các nhà cung cấp khác nhau.
Hướng tối ưu hóa 3: Trừu tượng hóa tài khoản toàn chuỗi, để đạt được các tài khoản hợp nhất trên các chuỗi khác nhau
Nhưng ngay cả với giải pháp nói trên, vẫn còn một vấn đề lớn chưa được giải quyết: các chuỗi khác nhau và các Layer2 khác nhau đang thúc đẩy sự trừu tượng hóa tài khoản với các chi tiết khác nhau và nhiều hình thức sử dụng xung đột với EIP-4337, chẳng hạn như zkSync Era, Starknet, Flow, v.v. Điều này đã dẫn đến sự phân mảnh trong UX của ví, chẳng hạn như địa chỉ ví thông minh của người dùng trên Starknet và địa chỉ ví thông minh trên Arbitrum hoàn toàn không thể thống nhất.
Hơn nữa, trong môi trường đa chuỗi, người dùng đã triển khai độc lập Tài khoản thông minh trên các chuỗi khác nhau và dữ liệu người dùng tương ứng thường nằm rải rác trong các hợp đồng này. Nếu dữ liệu người dùng như khóa cần được cập nhật, cần phải bắt đầu giao dịch nhiều lần trong nhiều chuỗi và rất khó để đảm bảo tính nhất quán của Tài khoản thông minh.
Bản thân Vitalik trước đây đã đề xuất một tập hợp các chương trình tài khoản thông minh thống nhất và dễ quản lý toàn chuỗi, ** lược đồ này sử dụng Ethereum hoặc ZKRollup bảo mật cao làm chuỗi nguồn, triển khai hợp đồng Keystore, lưu trữ khóa toàn cầu của người dùng và sau đó tất cả các tài khoản hợp đồng thông minh của người dùng trên L2 chia sẻ khóa toàn cầu được lưu trữ trong hợp đồng Keystore.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-fad1fc1c55-dd1a6f-69ad2a.webp)
Tuy nhiên, giải pháp này cực kỳ tốn kém, tức là bất cứ khi nào khóa toàn cục được ghi trong hợp đồng Keystore trên chuỗi nguồn thay đổi, mỗi tài khoản trên chuỗi L2/target cần đồng bộ khóa mới thông qua tương tác chéo chuỗi. Tương tác chuỗi chéo giữa Ethereum và L2 quá đắt để người dùng có thể mua được. Và cần lưu ý rằng tài khoản hợp đồng thông minh khác với tài khoản EOA, vốn đã thống nhất đa chuỗi (thống nhất giữa các chuỗi EVM) vì phương thức tạo địa chỉ duy nhất của chúng, nhưng tài khoản hợp đồng thông minh hoàn toàn khác nhau và người dùng khó có được tài khoản hợp đồng thông minh có cùng địa chỉ trên các chuỗi khác nhau.
Particle Network đã đưa ra cách tiếp cận riêng cho vấn đề này. Mặc dù ý tưởng chung giống như ý tưởng của Vitalik, cũng là tách biệt lưu trữ và mã của tài khoản thông minh, Particle Network dự định sử dụng một chuỗi độc lập, Particle Network Chain, làm cơ sở dữ liệu lưu trữ toàn chuỗi của tài khoản thông minh, thông qua các giải pháp nhắn tin chuỗi chéo của bên thứ ba (LayerZero, CCIP, Axelar, Connext). v.v.) Đồng bộ hóa các thay đổi của người dùng đối với bộ nhớ tài khoản với tài khoản cục bộ trên các chuỗi khác.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-2e6d60197a-dd1a6f-69ad2a.webp)
(Trừu tượng hóa tài khoản đa chuỗi của Particle Network)
Cụ thể, hệ thống trừu tượng hóa tài khoản toàn chuỗi của Particle Network yêu cầu người dùng phải có một địa chỉ tài khoản hợp đồng thông minh thống nhất trên các chuỗi EVM khác nhau, yêu cầu triển khai một bộ Hợp đồng triển khai trên các chuỗi khác nhau;
Người dùng phải kích hoạt tạo tài khoản mới trên Particle Network Chain, sau đó Particle Chain sẽ kích hoạt Deployer Contract trên tất cả các chuỗi, đảm bảo rằng các địa chỉ tài khoản hợp đồng thông minh được tạo cho người dùng trên các chuỗi khác nhau là thống nhất hoặc người dùng có thể hoàn thành quá trình tương tác đa chuỗi thông qua hợp đồng trên Particle Chain mà không cần biết về các chuỗi khác và có thể sử dụng Unified Gas Token như một phương thức thanh toán phí thống nhất.
Việc trừu tượng hóa tài khoản toàn chuỗi cũng làm cho Hoạt động người dùng của Cross-Chain trở nên khả thi, kích hoạt giao dịch của chuỗi mục tiêu thông qua Hoạt động của người dùng của chuỗi nguồn và thanh toán Gas tương ứng, chẳng hạn như sử dụng USDC của Polygon để mua NFT trên Base.
Tuy nhiên, giải pháp Particle Network đòi hỏi mức độ hợp tác cao giữa Hợp đồng Deployer và thành phần nhắn tin chuỗi chéo để đạt được sự đồng bộ hóa của Tài khoản đa chuỗi và Lưu trữ chuỗi nguồn, thực sự có yêu cầu cao đối với oracle hoặc cầu nối thông điệp chuỗi chéo mà nó sử dụng (vấn đề này dường như tồn tại trong tất cả các sơ đồ liên quan đến khả năng tương tác toàn chuỗi).
Tuy nhiên, đồng bộ hóa tài khoản chuỗi chéo của người dùng có thể linh hoạt cấu hình kết hợp các Message Bridge khác nhau, thay vì chỉ dựa vào một Bridge nhất định, chẳng hạn như chiến lược có thể được định cấu hình là 2/3, dựa vào xác nhận của bất kỳ hai LayerZero, Axelar và Connext để xác nhận sự thay đổi của Storage trên chuỗi đích, điều này có thể giải quyết xấp xỉ vấn đề phụ thuộc một điểm này.
Khả năng tương tác liền mạch của chuỗi đầy đủ trên EVM và không EVM là một bước tiến xa hơn trong việc trừu tượng hóa các tài khoản chuỗi đầy đủ trong hệ sinh thái Ethereum
Mặc dù có các tài khoản quản lý chính và hợp nhất trên toàn chuỗi EVM, nhưng vẫn còn chỗ để tối ưu hóa trong việc trừu tượng hóa tài khoản toàn chuỗi: các chuỗi không tương thích với EVM, chẳng hạn như Aptos, Solana, Sui, v.v., không thể đảm bảo rằng địa chỉ tài khoản hợp đồng thông minh do người dùng tạo phù hợp với chuỗi EVM; Đồng thời, nếu chuỗi không phải EVM không triển khai giao thức EIP-4337 với sơ đồ tương đương, rất khó để tuân theo khái niệm trừu tượng về tài khoản toàn chuỗi do Vitalik và Particle Network đề xuất ở trên.
Ngoài ra, bản thân dự án ví tương thích EIP-4337 cũng có chỗ để cải thiện. Hầu hết các nút bundler được sử dụng bởi ví thông minh đều được chạy chính thức độc lập và thậm chí không giao tiếp với nhau và nhiều dự án ví thông minh thực sự tạo thành một chuỗi của riêng chúng, điều này mang lại rất nhiều rủi ro (khả năng chống kiểm duyệt, khả năng sử dụng). Xây dựng một giao diện front-end duy nhất thống nhất trên hầu hết các chuỗi có thể rất khó khăn. Một giải pháp là giới thiệu một thiết kế tập trung vào mục đích, thêm một lớp lên trên sự trừu tượng hóa tài khoản toàn chuỗi và coi hệ sinh thái EIP-4337 của Ethereum hoặc các cơ sở trừu tượng hóa tài khoản gốc của chuỗi khác (như zkSync) là các trường hợp cụ thể thuộc loại Bộ giải / Lò phản ứng và cách chọn Bộ giải phù hợp là một nhiệm vụ cấp cao hơn. **
Lấy Particle Network làm ví dụ, nó đề xuất triển khai Ý định trừu tượng ngắn gọn, trong khi các trừu tượng tài khoản khác nhau chỉ là một lớp các trường hợp của các giải pháp Ý định được bao gồm trong Bộ giải.
Đầu tiên, giao diện người dùng sẽ chịu trách nhiệm chuyển đổi các yêu cầu ngôn ngữ tự nhiên hoặc tương tác người dùng tùy ý thành các mô tả lập trình cụ thể, bao gồm các ràng buộc đầu vào và ràng buộc đầu ra (nói một cách thẳng thắn, đó là các điều kiện đầu vào và khoảng kết quả đầu ra đáp ứng yêu cầu của người dùng), và sau đó một hoặc nhiều Bộ giải trong mạng Bộ giải sẽ chứa các ràng buộc đầu vào và đầu ra cụ thể của Giao dịch. Chuyển tiếp đến các hợp đồng Solver được triển khai trên chuỗi (Bộ giải không chỉ có các cơ sở nút mà còn có các bộ phận hợp đồng trên chuỗi). Hợp đồng Solver sẽ truyền hướng dẫn ý định đến hợp đồng Reactor (quản lý tài khoản của người dùng trên chuỗi), sẽ gọi các mô-đun khác để hoàn thành tương tác cuối cùng.
Yêu cầu của người dùng lần đầu tiên được biết đến bởi mạng Solver, do đó người dùng không cần phải nhận thức chuỗi cơ bản hoặc xây dựng các trừu tượng tài khoản khác nhau và phần này được để lại cho Bộ giải để xây dựng một giải pháp cụ thể.
Tất nhiên, những ý tưởng này vẫn chỉ là một khuôn khổ lý thuyết và các chi tiết thực hiện đằng sau vẫn chưa được Particle Network chính thức đưa ra.
Hiện tại, rõ ràng là một thị trường Bộ giải cạnh tranh sẽ được sinh ra trong tương lai và người dùng có thể bắt đầu đấu giá để cho phép nhiều Bộ giải đưa ra các giải pháp khác nhau và thông qua hình thức giao dịch mô phỏng cục bộ, giải pháp tốt nhất có thể được chọn và Bộ giải tương ứng có thể được khuyến khích. Hình thức khuyến khích phụ thuộc vào các nhà thiết kế giao thức của Mạng giải (Particle Network dự định sử dụng mã thông báo PNT làm mã thông báo khuyến khích cho thị trường đấu giá Bộ giải của mình).
**Mục đích hiện tại về cơ bản che chắn các chi tiết phức tạp của lớp dưới và trừu tượng hóa nó thành một lớp cao hơn, ** thiết kế phân lớp như vậy với bản chất của giao thức TCP / IP là cần thiết cho trải nghiệm người dùng và trải nghiệm nhà phát triển dưới khả năng tương tác liền mạch của toàn bộ chuỗi.
Nắm bắt việc áp dụng hàng loạt trừu tượng tài khoản
Khi chúng tôi tối ưu hóa khung 4337 trong hệ sinh thái Ethereum từ mọi góc độ và cũng thúc đẩy khả năng tương tác liền mạch trên các hệ sinh thái Ethereum và không phải Ethereum, để hỗ trợ việc áp dụng trừu tượng tài khoản quy mô lớn, chúng tôi cảm thấy rằng chúng tôi vẫn cần một sản phẩm mở rộng phía cung và phía cầu. Nó có thể làm giảm việc sử dụng các sản phẩm và dịch vụ Web3 khác nhau của người dùng cuối, đồng thời tập trung vào các nhà phát triển dịch vụ và hạ thấp ngưỡng cho các nhà phát triển. **
Một trong những sản phẩm tốt nhất cho vai trò này là sản phẩm Modular Smart Wallet-as-Service của Particle Network:
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-3a8144f020-dd1a6f-69ad2a.webp)
Ngoài các tính năng thân thiện với nhà phát triển ở trên, tính năng quan trọng nhất là sản phẩm Ví thông minh mô-đun dưới dạng dịch vụ ** của Particle Network xây dựng một hệ sinh thái mở dựa trên điện toán chữ ký và hướng đến trường trừu tượng hóa tài khoản của nhà phát triển, ngoài việc cung cấp các mô-đun sản phẩm trừu tượng tài khoản tự phát triển, tích hợp nhiều loại sản phẩm và dịch vụ trừu tượng tài khoản khác nhau. Nó có thể nhanh chóng thúc đẩy việc áp dụng các sản phẩm và dịch vụ của các nhà phát triển khác nhau trong toàn bộ lĩnh vực trừu tượng hóa tài khoản.
! [Tại sao trừu tượng hóa tài khoản toàn chuỗi là mảnh ghép cuối cùng của câu đố cho EIP-4337?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-20ede5c527-dd1a6f-69ad2a.webp)
Hãy để công nghệ phục vụ nhu cầu, sau khi giải quyết các hạn chế của tất cả các góc độ của khung ERC-4337, việc cải thiện trải nghiệm nhà phát triển *** sẽ quảng bá nhiều sản phẩm hơn với ** trải nghiệm người dùng ** tuyệt vời, thúc đẩy ngành công nghiệp Web3 từ ngành tài chính thân thiện với tiền điện tử sang ngành công nghiệp tiêu dùng thân thiện với đại chúng.