Phân tích sâu về quá khứ và tương lai của trừu tượng hóa tài khoản Ethereum
Lời mở đầu
Bài viết được chia thành hai phần lớn:
Phần đầu tiên bắt đầu từ đề xuất AA đầu tiên vào năm 2015, hệ thống đã tổng hợp nội dung các đề xuất EIP chính cho đến nay, thảo luận về quá trình phát triển của các đề xuất AA trong lịch sử, và đánh giá tổng thể các phương án.
Phần thứ hai tập trung so sánh phản ứng của thị trường sau khi EIP4337 được phát hành, đồng thời phân tích sâu về EIP7702 sẽ được đưa vào nâng cấp phiên bản tiếp theo của Ethereum. Đề xuất này một khi được hợp nhất, sẽ hoàn toàn thay đổi hình thức ứng dụng trên chuỗi.
EIP-7702 có ý nghĩa lịch sử, hãy cùng nhau tìm hiểu sâu hơn.
1. Bối cảnh trừu tượng hóa tài khoản
1.1 Ý nghĩa của trừu tượng hóa tài khoản
Người sáng lập Ethereum Vitalik đã cập nhật lại lộ trình phát triển ETH vào cuối năm 2023, nhưng vị trí của trừu tượng hóa tài khoản vẫn không thay đổi. Mô hình chính hiện tại đang chuyển từ EIP-4337 sang giai đoạn tiếp theo "chuyển đổi tài khoản EOA tự nguyện".
1.2 Thị trường hiện tại của trừu tượng hóa tài khoản
Sau một năm rưỡi phát triển, tổng số địa chỉ của EIP4337 trên các chuỗi chính chỉ có 12 triệu, trong đó số địa chỉ hoạt động trên mạng chính của Ethereum chỉ có 6,764, chênh lệch rất lớn với số lượng địa chỉ EOA và CA. Số lượng địa chỉ độc lập trên mạng chính của Ethereum đã đạt 270 triệu, có thể nói EIP4337 phát triển chậm trên mạng chính.
Tuy nhiên, điều này không ảnh hưởng đến giá trị bản chất của AA. Thiết kế của EIP4337 đã định sẵn rằng nó khó có thể tương thích tốt với nhau trên mạng chính. Với việc các loại chuỗi L2 phổ biến tích hợp AA bản địa, số lượng địa chỉ của EIP4337 đã bùng nổ trên L2, chẳng hạn như số lượng người dùng hàng tháng của chuỗi Base và Polygon lần lượt đạt 1 triệu và 3 triệu vào tháng 7, thể hiện sự không tồi.
Vì vậy, thiết kế của EIP4337 không phải là sai lầm, nó có nhiều ưu điểm. Tình trạng hiện tại xuất phát từ sự khác biệt giữa mạng chính và L2, chúng cần những giải pháp phù hợp với nhau.
2. Tài khoản trừu tượng hóa là gì?
Trừu tượng hóa tài khoản về bản chất là giải quyết vấn đề phân tách quyền sở hữu.
Trong kiến trúc EVM có hai loại tài khoản: tài khoản bên ngoài ( EOA ) và tài khoản hợp đồng ( CA ). Trong tài khoản bên ngoài, quyền sở hữu và quyền ký đều thuộc về cùng một thực thể. Người sở hữu khóa riêng không chỉ sở hữu "quyền sở hữu tài khoản", mà còn có quyền "ký chuyển nhượng tất cả tài sản".
Đây là do cấu trúc giao dịch của tài khoản Ethereum quyết định. Từ cấu trúc giao dịch có thể thấy rằng, giao dịch tiêu chuẩn thực sự không có trường From. Khi chuyển tiền, địa chỉ tiêu thụ cụ thể được suy diễn ngược từ tham số VRS ( tức là chữ ký của người dùng ).
Và hiệu ứng cốt lõi của EIP4337 chính là việc thêm Địa chỉ Sender vào trường giao dịch, từ đó đạt được sự tách biệt giữa khóa riêng và địa chỉ được thao tác.
Lý do sự phân tách quyền sở hữu lại quan trọng như vậy là do thiết kế tài khoản bên ngoài (EOA) sẽ phát sinh ra nhiều vấn đề:
Khó bảo vệ khóa riêng: Mất khóa riêng có nghĩa là mất tất cả tài sản.
Thuật toán ký duy nhất: Giao thức gốc xác thực giao dịch chỉ có thể sử dụng thuật toán ECDSA.
Quyền ký quá cao: không có chức năng đa ký nguyên bản, chỉ cần ký đơn có thể thực hiện bất kỳ thao tác nào.
Phí giao dịch chỉ có thể thanh toán bằng ETH, không hỗ trợ giao dịch hàng loạt.
Quyền riêng tư giao dịch dễ bị rò rỉ: giao dịch một đối một dễ phân tích thông tin người nắm giữ tài khoản.
Những hạn chế này khiến người dùng bình thường khó sử dụng Ethereum:
Đầu tiên, người dùng phải nắm giữ Ether và chịu rủi ro biến động giá.
Thứ hai, người dùng cần xử lý các logic phí phức tạp, như giá Gas, giới hạn Gas, và các khái niệm tắc nghẽn giao dịch.
Cuối cùng, ví hoặc ứng dụng blockchain cố gắng nâng cao trải nghiệm người dùng thông qua tối ưu hóa sản phẩm, nhưng hiệu quả rất hạn chế.
Do đó, giải pháp nằm ở việc thực hiện trừu tượng hóa tài khoản, tách rời quyền sở hữu (Owner) và quyền ký (Signer), từ đó dần dần giải quyết các vấn đề đã nêu.
Trong lịch sử có nhiều phương án, cuối cùng được tổng kết thành hai hướng.
3. Sắp xếp bối cảnh các đề xuất lịch sử AA
Giải pháp cho vấn đề dường như có nhiều đề xuất EIP, nhưng về bản chất chỉ có hai hướng đi chính. Mỗi vấn đề mà EIP chưa được thông qua đều tập trung vào điểm đột phá của các phương án hiện tại.
3.1 Lộ trình đầu tiên: Chuyển đổi địa chỉ EOA thành địa chỉ CA
Ngay từ tháng 11 năm 2015, Vitalik đã đề xuất một cấu trúc mới cho tài khoản bằng cách sử dụng hợp đồng trong EIP-101. Địa chỉ được thay đổi chỉ còn mã và không gian lưu trữ, hỗ trợ thanh toán phí giao dịch ERC20, thông qua hợp đồng biên soạn trước để chuyển đổi token gốc thành số dư tương tự ERC20, và đơn giản hóa các trường giao dịch thành to, startgas, data và code.
Giải pháp này có thể được coi là một cuộc cách mạng lớn, sẽ thay đổi đáng kể thiết kế cơ sở, khiến mỗi địa chỉ tài khoản đều có "logic" của riêng mình ( chính là hiệu ứng mà EIP-7702 muốn đạt được ).
Nó còn có thể phát sinh các chức năng khác, chẳng hạn như:
Hãy để giao dịch sử dụng nhiều thuật toán mã hóa hơn, do các địa chỉ bên trong Code chỉ định phương pháp xác thực và xác minh.
Có tính kháng tấn công lượng tử, vì mã có thể nâng cấp.
Cho phép Ether có chức năng tương tự như hợp đồng ERC20, chẳng hạn như ủy quyền tự động.
Nâng cao không gian tùy chỉnh của tài khoản, tương thích phục hồi xã hội, hỗ trợ SBT, khôi phục khóa, v.v.
Lý do không tiếp tục thúc đẩy là do bước đi quá lớn, không xem xét đầy đủ vấn đề xung đột hash giao dịch hiện tại và những rủi ro về an ninh, nhưng từng nguyên lý ưu điểm đã trở thành một trong những chức năng cốt lõi của EIP4337 và EIP7702 sau này.
Sau đó còn một loạt các EIP cố gắng hoàn thiện logic này:
EIP-859: trừu tượng hóa tài khoản chuỗi chính (2018-01-30)
Cố gắng giải quyết vấn đề triển khai Code. Chức năng chính là, nếu hợp đồng của bên giao dịch chưa được triển khai, thì sử dụng tham số code đi kèm với giao dịch để thực hiện việc triển khai ví hợp đồng. Cũng đề xuất mã thao tác PAYGAS mới, ngoài việc thanh toán gas, còn là dấu phân cách giữa phần xác minh và phần thực thi trong tham số giao dịch.
Mặc dù không thành công vào thời điểm đó, nhưng điều này đã trở thành một trong những logic cốt lõi của EIP7702. Mỗi giao dịch của EIP7702 kết hợp cấu trúc giao dịch đặc biệt, có thể đính kèm một mã nhất định, cho phép địa chỉ EOA có khả năng hợp đồng trong giao dịch này.
EIP-7702: thiết lập mã tài khoản EOA (2024-05-07)
Đây là EIP cốt lõi được thảo luận trong bài viết này, được Vitalik đề xuất như một giải pháp thay thế cho EIP-3074. EIP-3074 đã bị loại bỏ, EIP-7702 sẽ được đưa vào phân tách cứng ETH Prague/Electra(Pectra) sắp tới.
3.2 Lộ trình thứ hai: Để địa chỉ EOA điều khiển địa chỉ CA
EIP-3074: Thêm mã thao tác AUTH và AUTHCALL (2020-10-15)
Thêm hai OpCode mới vào EVM: AUTH và AUTHCALL, cho phép EOA ủy quyền cho hợp đồng gọi các hợp đồng khác thay mặt cho danh tính EOA thông qua hai opcode này.
Tóm lại, EOA có thể gửi các giao dịch đã ký ( tới hợp đồng mà mình tin tưởng ) được gọi là Invoker (, hợp đồng Invoker này có thể sử dụng mã vận hành AUTH và AUTHCALL thay cho EOA để phát hành giao dịch.
EIP-4337: Thực hiện trừu tượng hóa tài khoản bằng bộ nhớ giao dịch )2021-09-29(
Được thiết kế dựa trên cảm hứng từ MEV, giá trị cốt lõi là hoàn toàn tránh thay đổi giao thức tầng đồng thuận.
EIP4337 đề xuất một đối tượng giao dịch mới là UserOperation, người dùng gửi đối tượng này vào pool bộ nhớ, từ đó các bundlers sẽ gộp chúng lại từ góc độ thợ mỏ để thực hiện giao dịch hợp đồng, về bản chất là đưa các giao dịch cơ sở và hoạt động tài khoản lên tầng hợp đồng để thực hiện.
EIP-5189: Thực hiện trừu tượng hóa tài khoản thông qua người ủng hộ )2022-06-29(
Đây là tối ưu hóa logic của EIP4337, thông qua việc thiết lập cơ chế hỗ trợ phạt tài chính để ngăn chặn các cuộc tấn công DoS gây tắc nghẽn của Bundler độc hại.
) 3.3 Các đề xuất khác hỗ trợ trừu tượng hóa tài khoản
EIP-2718: bao bì giao dịch mới ###2020-06-13(
Đây là một đề xuất đã được hoàn tất, định nghĩa loại giao dịch mới như một phong bì cho các loại giao dịch mới trong tương lai.
Kết quả cuối cùng là, khi giới thiệu loại giao dịch mới, thông qua mã hóa cụ thể để phân biệt loại giao dịch, chỉ cần tương thích ngược, không cần tương thích tiến. Ví dụ phổ biến nhất là EIP1559, nó phân biệt phí giao dịch, sử dụng mã hóa loại giao dịch mới, mà không ảnh hưởng đến loại giao dịch legacy ban đầu.
EIP-3607: làm cho địa chỉ EOA không thể triển khai hợp đồng )2021-06-10(
Đây là giải pháp bổ sung trên đường AA, được sử dụng để ngăn chặn xung đột giữa địa chỉ triển khai hợp đồng và địa chỉ EOA. Nó sẽ kiểm soát phương pháp tạo hợp đồng, không cho phép triển khai mã lên địa chỉ đã là địa chỉ EOA. Rủi ro này thật ra rất nhỏ, địa chỉ Ethereum dài 160 bit, mặc dù có phương pháp sử dụng khóa riêng để va chạm ra khóa riêng của địa chỉ hợp đồng cụ thể, nhưng ước tính cần một năm thời gian với toàn bộ sức mạnh tính toán của Bitcoin.
) 3.4 Làm thế nào để hiểu quá trình phát triển của trừu tượng hóa tài khoản?
Đầu tiên cần hiểu giá trị chuyển đổi sang CA, cơ bản chính là hiệu ứng thực tế của EIP-4337:
Hỗ trợ giao dịch hàng loạt
Hỗ trợ phục hồi xã hội
Hỗ trợ xác thực chữ ký tùy chỉnh
Không cần thanh toán phí bằng token gốc
Quản lý quyền chi tiết hơn
Khả năng nâng cấp
Tuy nhiên, nhược điểm cốt lõi của EIP-4337 là đi ngược lại với nguyên tắc động lực con người.
Có vẻ tốt hơn, nhưng lại rơi vào vòng lặp chết của sự phát triển thị trường: nhiều Dapp vẫn chưa tương thích, người dùng không muốn sử dụng địa chỉ CA, việc sử dụng CA lại có chi phí giao dịch cao hơn ### trong các trường hợp chuyển khoản thông thường, phí giao dịch gấp đôi (, quá phụ thuộc vào khả năng tương thích của chính Dapp.
Vì vậy, đến nay vẫn chưa được phổ biến trên mạng chính của Ethereum.
Chi phí là tiêu chí quan trọng nhất của người dùng, phải giảm chi phí.
Nhưng để thực sự giảm GAS, cần phải thực hiện nâng cấp phân nhánh mềm cho bản thân Ethereum, sửa đổi cách tính GAS hoặc các mô-đun tiêu thụ GAS của mã hoạt động. Nếu đã muốn phân nhánh mềm, tại sao không xem xét EIP-7702 ngay từ đầu.
![Phân tích sâu về quá khứ và tương lai của trừu tượng hóa tài khoản Ethereum])https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
4. Phân tích toàn diện EIP-7702
) 4.1 EIP-7702 là gì
Nó cho phép EOA có chức năng hợp đồng thông minh tạm thời trong một giao dịch thông qua loại giao dịch mới, hỗ trợ giao dịch hàng loạt, giao dịch không Gas và quản lý quyền tùy chỉnh, và không cần đưa vào mã opCode EVM mới ### ảnh hưởng đến khả năng tương thích ngược (.
Người dùng không cần triển khai hợp đồng thông minh, vẫn có thể nhận được hầu hết khả năng AA, thậm chí có thể cung cấp khả năng cho bên thứ ba thay mặt người dùng khởi xướng giao dịch mà không cần người dùng cung cấp khóa riêng, chỉ cần ký thông tin ủy quyền.
) 4.2 cấu trúc dữ liệu
Định nghĩa loại giao dịch mới 0x04, TransactionPayload là kết quả của chuỗi RLP mã hóa của những nội dung sau:
Điều quan trọng là đã thêm đối tượng authorization_list, lưu trữ mã mà người ký muốn thực hiện trong EOA của họ. Người dùng ký giao dịch đồng thời cũng ký mã hợp đồng sẽ được thực hiện, tồn tại dưới dạng danh sách hai chiều, có thể lưu trữ nhiều thông tin thao tác cùng lúc, thực hiện các thao tác hàng loạt.
Khi bắt đầu thực hiện giao dịch, đối với mỗi tuple [chain_id, address, nonce, y_parity, r, s] trong authorization_list:
Khôi phục địa chỉ người ký từ chữ ký r, s bằng ecrecover.
Xác minh chuỗi ID### ngăn chặn việc phát lại chuỗi phân nhánh(.
Xác minh xem mã của người ký authority có trống hoặc đã được ủy quyền hay không.
Xác minh nonce của signer authority ) để ngăn chặn việc phát lại chữ ký authority (.
Thiết lập mã signer authority thành 0xef0100 || address) bỏ qua chính sách chống va chạm EIP3607(.
Tăng nonce authority signer ) để ngăn chặn replay chữ ký cục bộ (.
Thêm tài khoản người ký authority vào danh sách địa chỉ đã truy cập ) chuyển đổi địa chỉ nóng, giảm phí gas lưu trữ truy vấn (.
)# 4.3.2 Giai đoạn thực hiện các thao tác
"Phiên bản "mới" chỉ thay đổi hành vi triển khai mã.
Không còn đặt account_code thành contract_code, mà thay vào đó là truy xuất mã được chỉ định bởi address từ authorization_list và đặt thành account_code.
Khi thực thi mã ủy quyền, tải mã từ trường địa chỉ của authorization_list, thực hiện trong ngữ cảnh tài khoản của người ký.
Điều này có nghĩa là mã hợp đồng của người dùng thực sự được lưu trữ tại địa chỉ cụ thể trên chuỗi, chứ không được bao gồm trực tiếp trong giao dịch.
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.
11 thích
Phần thưởng
11
7
Chia sẻ
Bình luận
0/400
LiquidationWizard
· 07-25 01:53
Chết tiệt, 7702 lại đang làm cái quái gì vậy?
Xem bản gốcTrả lời0
GasWaster
· 07-24 18:03
Ôi lại một EIP nữa... tôi đã tiêu 2 ETH cho các giao dịch không thành công năm ngoái và giờ họ nói với tôi điều này?
Xem bản gốcTrả lời0
EntryPositionAnalyst
· 07-24 15:19
AA không lâu sau lại trở nên hot
Xem bản gốcTrả lời0
MetaMuskRat
· 07-22 06:03
Lại bắt đầu thổi AA, chắc chắn là rượu cũ trong chai mới của Blockchain.
EIP-7702 sẽ tái cấu trúc hệ sinh thái Ethereum, trừu tượng hóa tài khoản bước vào kỷ nguyên mới
Phân tích sâu về quá khứ và tương lai của trừu tượng hóa tài khoản Ethereum
Lời mở đầu
Bài viết được chia thành hai phần lớn:
Phần đầu tiên bắt đầu từ đề xuất AA đầu tiên vào năm 2015, hệ thống đã tổng hợp nội dung các đề xuất EIP chính cho đến nay, thảo luận về quá trình phát triển của các đề xuất AA trong lịch sử, và đánh giá tổng thể các phương án.
Phần thứ hai tập trung so sánh phản ứng của thị trường sau khi EIP4337 được phát hành, đồng thời phân tích sâu về EIP7702 sẽ được đưa vào nâng cấp phiên bản tiếp theo của Ethereum. Đề xuất này một khi được hợp nhất, sẽ hoàn toàn thay đổi hình thức ứng dụng trên chuỗi.
EIP-7702 có ý nghĩa lịch sử, hãy cùng nhau tìm hiểu sâu hơn.
1. Bối cảnh trừu tượng hóa tài khoản
1.1 Ý nghĩa của trừu tượng hóa tài khoản
Người sáng lập Ethereum Vitalik đã cập nhật lại lộ trình phát triển ETH vào cuối năm 2023, nhưng vị trí của trừu tượng hóa tài khoản vẫn không thay đổi. Mô hình chính hiện tại đang chuyển từ EIP-4337 sang giai đoạn tiếp theo "chuyển đổi tài khoản EOA tự nguyện".
1.2 Thị trường hiện tại của trừu tượng hóa tài khoản
Sau một năm rưỡi phát triển, tổng số địa chỉ của EIP4337 trên các chuỗi chính chỉ có 12 triệu, trong đó số địa chỉ hoạt động trên mạng chính của Ethereum chỉ có 6,764, chênh lệch rất lớn với số lượng địa chỉ EOA và CA. Số lượng địa chỉ độc lập trên mạng chính của Ethereum đã đạt 270 triệu, có thể nói EIP4337 phát triển chậm trên mạng chính.
Tuy nhiên, điều này không ảnh hưởng đến giá trị bản chất của AA. Thiết kế của EIP4337 đã định sẵn rằng nó khó có thể tương thích tốt với nhau trên mạng chính. Với việc các loại chuỗi L2 phổ biến tích hợp AA bản địa, số lượng địa chỉ của EIP4337 đã bùng nổ trên L2, chẳng hạn như số lượng người dùng hàng tháng của chuỗi Base và Polygon lần lượt đạt 1 triệu và 3 triệu vào tháng 7, thể hiện sự không tồi.
Vì vậy, thiết kế của EIP4337 không phải là sai lầm, nó có nhiều ưu điểm. Tình trạng hiện tại xuất phát từ sự khác biệt giữa mạng chính và L2, chúng cần những giải pháp phù hợp với nhau.
2. Tài khoản trừu tượng hóa là gì?
Trừu tượng hóa tài khoản về bản chất là giải quyết vấn đề phân tách quyền sở hữu.
Trong kiến trúc EVM có hai loại tài khoản: tài khoản bên ngoài ( EOA ) và tài khoản hợp đồng ( CA ). Trong tài khoản bên ngoài, quyền sở hữu và quyền ký đều thuộc về cùng một thực thể. Người sở hữu khóa riêng không chỉ sở hữu "quyền sở hữu tài khoản", mà còn có quyền "ký chuyển nhượng tất cả tài sản".
Đây là do cấu trúc giao dịch của tài khoản Ethereum quyết định. Từ cấu trúc giao dịch có thể thấy rằng, giao dịch tiêu chuẩn thực sự không có trường From. Khi chuyển tiền, địa chỉ tiêu thụ cụ thể được suy diễn ngược từ tham số VRS ( tức là chữ ký của người dùng ).
Và hiệu ứng cốt lõi của EIP4337 chính là việc thêm Địa chỉ Sender vào trường giao dịch, từ đó đạt được sự tách biệt giữa khóa riêng và địa chỉ được thao tác.
Lý do sự phân tách quyền sở hữu lại quan trọng như vậy là do thiết kế tài khoản bên ngoài (EOA) sẽ phát sinh ra nhiều vấn đề:
Khó bảo vệ khóa riêng: Mất khóa riêng có nghĩa là mất tất cả tài sản.
Thuật toán ký duy nhất: Giao thức gốc xác thực giao dịch chỉ có thể sử dụng thuật toán ECDSA.
Quyền ký quá cao: không có chức năng đa ký nguyên bản, chỉ cần ký đơn có thể thực hiện bất kỳ thao tác nào.
Phí giao dịch chỉ có thể thanh toán bằng ETH, không hỗ trợ giao dịch hàng loạt.
Quyền riêng tư giao dịch dễ bị rò rỉ: giao dịch một đối một dễ phân tích thông tin người nắm giữ tài khoản.
Những hạn chế này khiến người dùng bình thường khó sử dụng Ethereum:
Đầu tiên, người dùng phải nắm giữ Ether và chịu rủi ro biến động giá.
Thứ hai, người dùng cần xử lý các logic phí phức tạp, như giá Gas, giới hạn Gas, và các khái niệm tắc nghẽn giao dịch.
Cuối cùng, ví hoặc ứng dụng blockchain cố gắng nâng cao trải nghiệm người dùng thông qua tối ưu hóa sản phẩm, nhưng hiệu quả rất hạn chế.
Do đó, giải pháp nằm ở việc thực hiện trừu tượng hóa tài khoản, tách rời quyền sở hữu (Owner) và quyền ký (Signer), từ đó dần dần giải quyết các vấn đề đã nêu.
Trong lịch sử có nhiều phương án, cuối cùng được tổng kết thành hai hướng.
3. Sắp xếp bối cảnh các đề xuất lịch sử AA
Giải pháp cho vấn đề dường như có nhiều đề xuất EIP, nhưng về bản chất chỉ có hai hướng đi chính. Mỗi vấn đề mà EIP chưa được thông qua đều tập trung vào điểm đột phá của các phương án hiện tại.
3.1 Lộ trình đầu tiên: Chuyển đổi địa chỉ EOA thành địa chỉ CA
Ngay từ tháng 11 năm 2015, Vitalik đã đề xuất một cấu trúc mới cho tài khoản bằng cách sử dụng hợp đồng trong EIP-101. Địa chỉ được thay đổi chỉ còn mã và không gian lưu trữ, hỗ trợ thanh toán phí giao dịch ERC20, thông qua hợp đồng biên soạn trước để chuyển đổi token gốc thành số dư tương tự ERC20, và đơn giản hóa các trường giao dịch thành to, startgas, data và code.
Giải pháp này có thể được coi là một cuộc cách mạng lớn, sẽ thay đổi đáng kể thiết kế cơ sở, khiến mỗi địa chỉ tài khoản đều có "logic" của riêng mình ( chính là hiệu ứng mà EIP-7702 muốn đạt được ).
Nó còn có thể phát sinh các chức năng khác, chẳng hạn như:
Hãy để giao dịch sử dụng nhiều thuật toán mã hóa hơn, do các địa chỉ bên trong Code chỉ định phương pháp xác thực và xác minh.
Có tính kháng tấn công lượng tử, vì mã có thể nâng cấp.
Cho phép Ether có chức năng tương tự như hợp đồng ERC20, chẳng hạn như ủy quyền tự động.
Nâng cao không gian tùy chỉnh của tài khoản, tương thích phục hồi xã hội, hỗ trợ SBT, khôi phục khóa, v.v.
Lý do không tiếp tục thúc đẩy là do bước đi quá lớn, không xem xét đầy đủ vấn đề xung đột hash giao dịch hiện tại và những rủi ro về an ninh, nhưng từng nguyên lý ưu điểm đã trở thành một trong những chức năng cốt lõi của EIP4337 và EIP7702 sau này.
Sau đó còn một loạt các EIP cố gắng hoàn thiện logic này:
EIP-859: trừu tượng hóa tài khoản chuỗi chính (2018-01-30)
Cố gắng giải quyết vấn đề triển khai Code. Chức năng chính là, nếu hợp đồng của bên giao dịch chưa được triển khai, thì sử dụng tham số code đi kèm với giao dịch để thực hiện việc triển khai ví hợp đồng. Cũng đề xuất mã thao tác PAYGAS mới, ngoài việc thanh toán gas, còn là dấu phân cách giữa phần xác minh và phần thực thi trong tham số giao dịch.
Mặc dù không thành công vào thời điểm đó, nhưng điều này đã trở thành một trong những logic cốt lõi của EIP7702. Mỗi giao dịch của EIP7702 kết hợp cấu trúc giao dịch đặc biệt, có thể đính kèm một mã nhất định, cho phép địa chỉ EOA có khả năng hợp đồng trong giao dịch này.
EIP-7702: thiết lập mã tài khoản EOA (2024-05-07)
Đây là EIP cốt lõi được thảo luận trong bài viết này, được Vitalik đề xuất như một giải pháp thay thế cho EIP-3074. EIP-3074 đã bị loại bỏ, EIP-7702 sẽ được đưa vào phân tách cứng ETH Prague/Electra(Pectra) sắp tới.
3.2 Lộ trình thứ hai: Để địa chỉ EOA điều khiển địa chỉ CA
EIP-3074: Thêm mã thao tác AUTH và AUTHCALL (2020-10-15)
Thêm hai OpCode mới vào EVM: AUTH và AUTHCALL, cho phép EOA ủy quyền cho hợp đồng gọi các hợp đồng khác thay mặt cho danh tính EOA thông qua hai opcode này.
Tóm lại, EOA có thể gửi các giao dịch đã ký ( tới hợp đồng mà mình tin tưởng ) được gọi là Invoker (, hợp đồng Invoker này có thể sử dụng mã vận hành AUTH và AUTHCALL thay cho EOA để phát hành giao dịch.
EIP-4337: Thực hiện trừu tượng hóa tài khoản bằng bộ nhớ giao dịch )2021-09-29(
Được thiết kế dựa trên cảm hứng từ MEV, giá trị cốt lõi là hoàn toàn tránh thay đổi giao thức tầng đồng thuận.
EIP4337 đề xuất một đối tượng giao dịch mới là UserOperation, người dùng gửi đối tượng này vào pool bộ nhớ, từ đó các bundlers sẽ gộp chúng lại từ góc độ thợ mỏ để thực hiện giao dịch hợp đồng, về bản chất là đưa các giao dịch cơ sở và hoạt động tài khoản lên tầng hợp đồng để thực hiện.
EIP-5189: Thực hiện trừu tượng hóa tài khoản thông qua người ủng hộ )2022-06-29(
Đây là tối ưu hóa logic của EIP4337, thông qua việc thiết lập cơ chế hỗ trợ phạt tài chính để ngăn chặn các cuộc tấn công DoS gây tắc nghẽn của Bundler độc hại.
) 3.3 Các đề xuất khác hỗ trợ trừu tượng hóa tài khoản
EIP-2718: bao bì giao dịch mới ###2020-06-13(
Đây là một đề xuất đã được hoàn tất, định nghĩa loại giao dịch mới như một phong bì cho các loại giao dịch mới trong tương lai.
Kết quả cuối cùng là, khi giới thiệu loại giao dịch mới, thông qua mã hóa cụ thể để phân biệt loại giao dịch, chỉ cần tương thích ngược, không cần tương thích tiến. Ví dụ phổ biến nhất là EIP1559, nó phân biệt phí giao dịch, sử dụng mã hóa loại giao dịch mới, mà không ảnh hưởng đến loại giao dịch legacy ban đầu.
EIP-3607: làm cho địa chỉ EOA không thể triển khai hợp đồng )2021-06-10(
Đây là giải pháp bổ sung trên đường AA, được sử dụng để ngăn chặn xung đột giữa địa chỉ triển khai hợp đồng và địa chỉ EOA. Nó sẽ kiểm soát phương pháp tạo hợp đồng, không cho phép triển khai mã lên địa chỉ đã là địa chỉ EOA. Rủi ro này thật ra rất nhỏ, địa chỉ Ethereum dài 160 bit, mặc dù có phương pháp sử dụng khóa riêng để va chạm ra khóa riêng của địa chỉ hợp đồng cụ thể, nhưng ước tính cần một năm thời gian với toàn bộ sức mạnh tính toán của Bitcoin.
) 3.4 Làm thế nào để hiểu quá trình phát triển của trừu tượng hóa tài khoản?
Đầu tiên cần hiểu giá trị chuyển đổi sang CA, cơ bản chính là hiệu ứng thực tế của EIP-4337:
Tuy nhiên, nhược điểm cốt lõi của EIP-4337 là đi ngược lại với nguyên tắc động lực con người.
Có vẻ tốt hơn, nhưng lại rơi vào vòng lặp chết của sự phát triển thị trường: nhiều Dapp vẫn chưa tương thích, người dùng không muốn sử dụng địa chỉ CA, việc sử dụng CA lại có chi phí giao dịch cao hơn ### trong các trường hợp chuyển khoản thông thường, phí giao dịch gấp đôi (, quá phụ thuộc vào khả năng tương thích của chính Dapp.
Vì vậy, đến nay vẫn chưa được phổ biến trên mạng chính của Ethereum.
Chi phí là tiêu chí quan trọng nhất của người dùng, phải giảm chi phí.
Nhưng để thực sự giảm GAS, cần phải thực hiện nâng cấp phân nhánh mềm cho bản thân Ethereum, sửa đổi cách tính GAS hoặc các mô-đun tiêu thụ GAS của mã hoạt động. Nếu đã muốn phân nhánh mềm, tại sao không xem xét EIP-7702 ngay từ đầu.
![Phân tích sâu về quá khứ và tương lai của trừu tượng hóa tài khoản Ethereum])https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
4. Phân tích toàn diện EIP-7702
) 4.1 EIP-7702 là gì
Nó cho phép EOA có chức năng hợp đồng thông minh tạm thời trong một giao dịch thông qua loại giao dịch mới, hỗ trợ giao dịch hàng loạt, giao dịch không Gas và quản lý quyền tùy chỉnh, và không cần đưa vào mã opCode EVM mới ### ảnh hưởng đến khả năng tương thích ngược (.
Người dùng không cần triển khai hợp đồng thông minh, vẫn có thể nhận được hầu hết khả năng AA, thậm chí có thể cung cấp khả năng cho bên thứ ba thay mặt người dùng khởi xướng giao dịch mà không cần người dùng cung cấp khóa riêng, chỉ cần ký thông tin ủy quyền.
) 4.2 cấu trúc dữ liệu
Định nghĩa loại giao dịch mới 0x04, TransactionPayload là kết quả của chuỗi RLP mã hóa của những nội dung sau:
rlp###[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s](
Điều quan trọng là đã thêm đối tượng authorization_list, lưu trữ mã mà người ký muốn thực hiện trong EOA của họ. Người dùng ký giao dịch đồng thời cũng ký mã hợp đồng sẽ được thực hiện, tồn tại dưới dạng danh sách hai chiều, có thể lưu trữ nhiều thông tin thao tác cùng lúc, thực hiện các thao tác hàng loạt.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
) 4.3 vòng đời giao dịch
4.3.1 Giai đoạn xác thực
Khi bắt đầu thực hiện giao dịch, đối với mỗi tuple [chain_id, address, nonce, y_parity, r, s] trong authorization_list:
)# 4.3.2 Giai đoạn thực hiện các thao tác
"Phiên bản "mới" chỉ thay đổi hành vi triển khai mã.
Không còn đặt account_code thành contract_code, mà thay vào đó là truy xuất mã được chỉ định bởi address từ authorization_list và đặt thành account_code.
Khi thực thi mã ủy quyền, tải mã từ trường địa chỉ của authorization_list, thực hiện trong ngữ cảnh tài khoản của người ký.
Điều này có nghĩa là mã hợp đồng của người dùng thực sự được lưu trữ tại địa chỉ cụ thể trên chuỗi, chứ không được bao gồm trực tiếp trong giao dịch.