Phân tích sâu về quá khứ và tương lai của lĩnh vực trừu tượng tài khoản Ethereum

Bài viết được chia thành hai phần lớn:

Phần trê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 dưới sẽ tập trung phân tích so sánh lý do thị trường phản ứng lạnh nhạt sau khi EIP4337 được ra mắt, và phân tích sâu về EIP7702 sắp được đưa vào bản nâng cấp tiếp theo của Ethereum. Đề xuất này một khi được hợp nhất, sẽ thay đổi toàn diện hình thái ứng dụng trên chuỗi.

EIP-7702 có ý nghĩa lịch sử, hãy cùng tìm hiểu chi tiết.

1. Bối cảnh trừu tượng tài khoản

1.1 Ý nghĩa trừu tượng của tài khoản

Người sáng lập Ethereum, Vitalik, đã cập nhật lộ trình ETH vào cuối năm 2023, nhưng các thiết lập về tài khoản trừu tượng vẫn không thay đổi. Hiện tại, mô hình chính đang phát triển từ EIP-4337 đến giai đoạn tiếp theo của việc chuyển đổi tài khoản EOA tự nguyện.

Kể từ khi EIP4337 ra mắt hơn một năm trước, vào ngày 1 tháng 3 năm 2023, tại WalletCon ở Denver, ( đã được công bố chính thức, ), và đã nhận được sự công nhận rộng rãi từ người dùng nhưng tỷ lệ sử dụng vẫn không cao. Trong bối cảnh thị trường mâu thuẫn này, tiến độ của EIP-7702 đã được đẩy nhanh đáng kể và đã xác định sẽ được tích hợp trong lần nâng cấp tiếp theo.

1.2 tình trạng thị trường tài khoản trừu tượng

Sau một năm rưỡi phát triển, số tài khoản 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 Ethereum chỉ có 6.764, khác xa so với số lượng địa chỉ EOA và CA. Số địa chỉ độc lập của mạng chính Ethereum đã đạt 270 triệu, có thể nói EIP4337 gần như không có sự phát triển thực chất trên mạng chính.

Tuy nhiên, điều này không ảnh hưởng đến giá trị cốt lõi của AA. Thiết kế của EIP4337 quyết định rằng nó khó giải quyết vấn đề tương thích ngược của mainnet. Với việc các loại L2 bản địa được nhúng vào AA, số lượng địa chỉ EIP4337 trên L2 đã bùng nổ, trong đó số người dùng hoạt độ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.

Do đó, không phải thiết kế EIP4337 có lỗi, 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 các giải pháp phù hợp với từng loại.

2. Tài khoản trừu tượng là gì?

Tính trừu tượng của tài khoản về cơ bản giải quyết vấn đề phân tách quyền sở hữu.

Trong kiến trúc Máy ảo Ethereum(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(Contract Account). Quyền sở hữu và quyền ký của tài khoản bên ngoài thực sự thuộc về cùng một thực thể. Người nắm giữ khóa riêng không chỉ sở hữu "quyền sở hữu" của tài khoản mà còn có quyền "ký chuyển nhượng tất cả tài sản".

Điều này được xác định bởi cấu trúc giao dịch của tài khoản Ethereum. Từ cấu trúc giao dịch có thể thấy rằng giao dịch tiêu chuẩn của Ethereum không có trường From. Khi chuyển tiền, địa chỉ cụ thể nào được tiêu dùng là thông qua tham số VRS (, tức là chữ ký của người dùng ) được giải mã ra địa chỉ From.

Điều này liên quan đến các khái niệm như mã hóa bất đối xứng ECDSA và hàm ngưỡng một chiều, chúng tôi sẽ không đi sâu vào thảo luận. Tóm lại, sự an toàn ở đây được đảm bảo bởi mật mã, nhưng cũng gây ra tình trạng khó khăn hiện tại trong việc hợp nhất quyền sở hữu địa chỉ EOA.

Hiệu ứng cốt lõi của EIP4337 là thêm trường Địa chỉ Người Gửi vào trường giao dịch, từ đó đạt được sự tách biệt giữa khóa riêng và địa chỉ bị thao tác.

Nguyên nhân mà việc tách bạ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ẽ gây ra nhiều vấn đề hơn:

1. Khó bảo vệ khóa riêng: Người dùng mất khóa riêng (, mất mát, tấn công hacker, giải mã mật mã ) có nghĩa là mất tất cả tài sản.

2. Thuật toán ký duy nhất: Giao thức gốc chỉ có thể sử dụng thuật toán ký và xác minh ECDSA khi xác thực giao dịch.

3. Quyền ký quá cao: Không có đa ký nguyên sinh ( đa ký chỉ có thể được thực hiện thông qua hợp đồng thông minh ), ký đơn có thể thực hiện bất kỳ thao tác nào.

4. Phí giao dịch chỉ có thể được thanh toán bằng ETH, không hỗ trợ giao dịch hàng loạt.

5. Rò rỉ quyền riêng tư giao dịch: Giao dịch một đối một dễ dàng phân tích thông tin riêng tư của người 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, khi sử dụng bất kỳ ứng dụng nào trên Ethereum, người dùng phải sở hữu Ether ( và chịu rủi ro biến động giá ).

Thứ hai, người dùng cần xử lý logic phí phức tạp, giá Gas, giới hạn Gas, tắc nghẽn giao dịch ( thứ tự Nonce ) và các khái niệm khác quá phức tạp đối với người dùng.

Cuối cùng, mặc dù nhiều ví blockchain hoặc ứng dụng cố gắng cải thiện 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ả vẫn 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 trên.

Trong lịch sử có nhiều phương án, cuối cùng hội tụ lại thành hai hướng.

3. Sắp xếp bối cảnh đề xuất lịch sử AA

Giải pháp cho vấn đề dường như có nhiều đề xuất EIP, nhưng cuối cùng chỉ có hai ý tưởng cốt lõi. Mỗi vấn đề mà các EIP không được thông qua xem xét cuối cùng đều hội tụ thành điểm đột phá của giải pháp hiện có.

3.1 Loại tuyến đầu tiên: Chuyển đổi địa chỉ EOA thành địa chỉ CA

Vào ngày 15 tháng 11 năm 2015, xung quanh EIP-101, Vitalik đã đề xuất một cấu trúc mới với hợp đồng làm tài khoản. Thay đổi địa chỉ thành chỉ có mã và không gian lưu trữ, thay đổi hỗ trợ phí giao dịch được thanh toán bằng ERC20, thông qua hợp đồng biên dịch trước để chuyển đổi token gốc thành loại ERC20 để lưu giữ số dư ( có thể có chức năng ủy quyền tự động và nhiều chức năng khác ), đơn giản hóa các trường giao dịch chỉ còn to, startgas, data và code.

Từ bây giờ, đây là một cuộc cách mạng kiểu nhảy vọt, sẽ thay đổi đáng kể thiết kế nền tảng, cho phép mỗi địa chỉ tài khoản có "logic" mã riêng của mình ( đây chính là hiệu ứng mà EIP-7702 muốn đạt được ).

Nó cũng có thể phát sinh ra các chức năng khác, chẳng hạn như:

1. Cho phép giao dịch sử dụng nhiều thuật toán mã hóa hơn, có thể được chỉ định phương pháp xác thực và kiểm tra chữ ký bởi mã nội bộ của từng địa chỉ.

2. Có tính năng chống lại các cuộc tấn công lượng tử, vì mã có thể được nâng cấp.

3. Để Ether có các tính năng chức năng giống như hợp đồng ERC20, hiệu ứng cốt lõi là thực hiện ủy quyền trừ tiền, không cần tiêu tốn đồng tiền gốc.

4. 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 thể tiếp tục tiến hành rất đơn giản, rõ ràng là bước đi quá lớn, không tính toán chu đáo về vấn đề xung đột hash giao dịch hiện tại và nguy cơ an ninh, vì vậy đã luôn bị hoãn lại. Nhưng mỗi nguyên tắc ưu điểm đều trở thành một trong những chức năng cốt lõi của EIP4337 và EIP7702.

Sau đó còn có một loạt EIP cố gắng hoàn thiện logic này:

EIP-859: Trừu tượng 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 cốt lõi 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 kèm theo giao dịch để thực hiện việc triển khai ví hợp đồng. Thứ hai, còn đưa ra mã vận hành PAYGAS mới, ngoài việc thanh toán gas, cũng trở thành dấu phân cách giữa phần xác thực và phần thực thi trong các tham số giao dịch.

Mặc dù lúc đó không có kết quả, nhưng điều này đã trở thành một trong những logic cốt lõi của EIP7702 hiện tại. Mỗi giao dịch của EIP7702 kết hợp với cấu trúc giao dịch đặc biệt, có thể kèm theo một mã nhất định, từ đó 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à cốt lõi của cơ chế thảo luận sau này trong bài viết này EIP. Vitalik đã công bố EIP-7702 như một giải pháp thay thế cho EIP-3074. Do đó, EIP-3074 đã bị bỏ qua, EIP-7702 đã được xác định sẽ được đưa vào trong phân nhánh cứng ETH Prague/Electra(Pectra) sắp tới, nội dung chi tiết chúng ta sẽ mở rộng sau.

3.2 Lộ trình thứ hai: Để địa chỉ EOA điều khiển địa chỉ CA

EIP-3074: Thêm mã lệnh AUTH và AUTHCALL (2020-10-15)

Thêm hai OpCodes mới AUTH và AUTHCALL vào EVM, 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 của EOA thông qua hai opcode này.

Tóm lại, EOA có thể gửi một thông điệp đã ký ( giao dịch ) đến hợp đồng mà nó tin tưởng ( gọi là Invoker ). Hợp đồng Invoker này có thể sử dụng mã thao tác AUTH và AUTHCALL thay thế EOA này để phát hành giao dịch.

EIP-4337: Thực hiện trừu tượng tài khoản bằng cách sử dụng bộ nhớ giao dịch (2021-09-29)

Nó được thiết kế dựa trên cảm hứng từ MEV, giá trị cốt lõi là có thể hoàn toàn tránh thay đổi giao thức lớp đồ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ẽ đóng gói hàng loạt và giao cho việc thực hiện giao dịch hợp đồng từ góc độ thợ mỏ, về bản chất là đưa 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: Thao tác tài khoản trừu tượng thông qua người bảo lãnh (2022-06-29)

Điều này được coi là tối ưu hóa logic của EIP4337, nhằm đối phó với Bundler ác ý thông qua việc thiết lập cơ chế phạt tài chính để bảo đảm cho các endorser nhằm ngăn chặn các cuộc tấn công DoS.

3.3 Các đề xuất khác để hỗ trợ AA

EIP-2718: bao bì giao dịch mới (2020-06-13)

Đây là một đề xuất đã hoàn tất, định nghĩa một 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 các loại giao dịch khác nhau, cho phép nó chỉ cần tương thích ngược mà không cần tương thích xuôi. 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: khiến đị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 vấ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, khiến hệ thống không cho phép triển khai mã lên địa chỉ đã là địa chỉ EOA. Rủi ro này thực sự rất nhỏ, vì毕竟 đị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 hợp đồng chỉ định, nhưng với ước tính toàn bộ sức mạnh tính toán của Bitcoin, vẫn cần khoảng một năm.

3.4 Làm thế nào để hiểu quá trình phát triển trừu tượng tài khoản?

Trước tiên cần hiểu giá trị sau khi chuyển đổi sang CA.

Cơ bản cũng chính là hiệu quả thực tế của EIP-4337, nó có thể đạt được:

• Hỗ trợ nhiều thuật toán ký
• Hỗ trợ khôi phục xã hội
• Hỗ trợ token tùy chỉnh phí Gas thanh toán
• Hỗ trợ giao dịch hàng loạt
• Hỗ trợ quản lý tài khoản
• Hỗ trợ thanh toán phí gas từ bên thứ ba

Tuy nhiên, nhược điểm chính của EIP-4337 là đi ngược lại nguyên tắc động cơ con người.

Nó trông 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, thậm chí việc sử dụng CA còn có chi phí giao dịch cao hơn ( trong các tình huống 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, cho đế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í đánh giá 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 tách mềm trên chính Ethereum, sửa đổi tính toán GAS hoặc các mô-đun tiêu thụ GAS của mã hoạt động. Tuy nhiên, nếu đã phải phân tách mềm, tại sao không xem xét EIP-7702 ngay từ đầu?

4. Phân tích toàn diện EIP-7702

4.1 EIP-7702 là gì

Nó phân biệt thông qua loại giao dịch mới, cho phép EOA tạm thời có chức năng của hợp đồng thông minh trong một giao dịch duy nhất, từ đó hỗ trợ các giao dịch hàng loạt, giao dịch không Gas và quản lý quyền tùy chỉnh trong kinh doanh, mà không cần đưa vào mã lệnh EVM mới ( ảnh hưởng đến khả năng tương thích ngược ).

Nó cho phép người dùng có được hầu hết các khả năng của AA mà không cần triển khai hợp đồng thông minh, thậm chí có thể cung cấp khả năng cho bên thứ ba đại diện cho người dùng thực hiện giao dịch, và 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

Nó định nghĩa loại giao dịch mới 0x04, nội dung của TransactionPayload loại giao dịch này là kết quả của chuỗi mã hóa RLP sau đây:

rlp([ chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, điểm đến, giá trị, dữ liệu, access_list, danh sách ủy quyền, signature_y_parity, signature_r, signature_s ])

Điều quan trọng là trong đó đã 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, nó tồn tại dưới dạng danh sách hai chiều, cho thấy có thể lưu trữ nhiều thông tin hoạt động cùng một 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], ...]