Trong việc nâng cấp Pectra, đã xuất hiện vấn đề tranh chấp quản trị phức tạp nhất. Khi EIP3074 được đưa vào nâng cấp Pectra, đã gây ra cuộc tranh luận lớn, đặc biệt là từ đội ngũ ERC4337 phản đối.
EIP3074 đang gặp khó khăn, quy trình quản trị không thể tiếp tục. Cho đến khi Vitalik đề xuất EIP7702 kết thúc những nghi ngờ của đội ERC4337 đối với EIP3074.
GCC Research phát hiện ra rằng vấn đề quản trị liên quan đến EIP3074 và ERC7702 trong việc nâng cấp Pectra ít được thảo luận trong thế giới tiếng Trung. Tuy nhiên, vấn đề quản trị này cũng phản ánh những vấn đề sâu sắc trong quản trị Ethereum, tức là trong bối cảnh code is law, ai có thể kiểm soát nội dung cụ thể của code. Vấn đề quản trị của EIP3074 và ERC7702 có thể cho chúng ta một góc nhìn tốt để quan sát quy trình quản trị thực sự bên trong Ethereum.
Kết luận cuối cùng của bài viết này được trích dẫn từ bài bình luận của ZeroDev, bài viết chỉ ra rằng hệ thống quản trị Ethereum là mô hình VVRC, bất kỳ đề xuất nào cần phải phù hợp với giá trị Ethereum (Value) trước tiên, sau đó đề xuất đó nên phản ánh trong tầm nhìn được thiết kế bởi Vitalik (Vision), cuối cùng đề xuất nên được phản ánh trong lộ trình (Roadmap), cuối cùng các nhà phát triển cốt lõi sẽ thảo luận và đưa nó vào thực hiện trong khách hàng (Client).
Các EIP2537 được giới thiệu bởi GCC Research trong bài viết trước chỉ có các vấn đề triển khai ở cấp độ khách hàng dẫn đến sự chậm trễ cuối cùng trong việc tham gia hard fork, trong khi EIP3074 không được đưa vào hard fork do các vấn đề về Tầm nhìn và Lộ trình, và các nhà phát triển cốt lõi Ethereum đã trực tiếp chọn EIP7702 được viết bởi Vitalik làm đề xuất trừu tượng hóa tài khoản cuối cùng.
Tóm tắt nội dung đề xuất
Trước khi giới thiệu các quy trình quản lý cụ thể, chúng ta cần giới thiệu một cách ngắn gọn về nội dung cụ thể của EIP3074, EIP7702 và ERC4337 mà bài viết đề cập.
EIP3074 là một đề xuất ở tầng thực thi, việc thực hiện đề xuất này cần nâng cấp phần mềm nút. Mục tiêu cốt lõi của EIP3074 là thực hiện chức năng tài trợ gas và giao dịch hàng loạt. Tài trợ gas được hiểu là người dùng có thể sử dụng bất kỳ mã thông báo nào để thanh toán phí gas, hoặc người dùng có thể thanh toán phí gas ngoại tuyến. Tuy nhiên, cần lưu ý rằng, so với các đề xuất trừu tượng tài khoản khác cho phép thay đổi thuật toán xác minh chữ ký, EIP3074 không cho phép người dùng sử dụng bất kỳ thuật toán chữ ký nào ngoài secp256k1. Nói cách khác, EIP3074 không phải là một đề xuất đáp ứng tất cả các chức năng trừu tượng tài khoản. Đây cũng là một điểm mà EIP3074 bị chỉ trích nhiều.
Để đạt được mục tiêu dự kiến, EIP3074 đã giới thiệu hai mã thao tác, lần lượt là AUTH và AUTHCALL. Trong đó, mã thao tác AUTH có thể thông qua việc xác minh chữ ký, khi xác minh chữ ký thành công, mã thao tác này sẽ cấu hình địa chỉ authorized trong ngữ cảnh EVM hiện tại là địa chỉ của người ký. Khi cấu hình địa chỉ authorized trong ngữ cảnh, AUTHCALL có thể sử dụng địa chỉ authorized làm msg.sender để thực hiện giao dịch. Theo một cách nào đó, người dùng có thể ủy quyền tài khoản của mình cho một hợp đồng thông minh thông qua chữ ký trong một giao dịch. Chúng tôi thường gọi hợp đồng thông minh được người dùng ủy quyền này là hợp đồng invoker.
Nội dung chữ ký cụ thể của người dùng là gì? Người dùng cần ký vào nội dung sau:
Địa chỉ invoker trong nội dung trên đề cập đến địa chỉ hợp đồng invoker mà người dùng muốn ủy quyền, EVM sẽ kiểm tra xem nội dung chữ ký của người dùng có khớp với hợp đồng thực sự kiểm tra chữ ký hay không, nhằm tránh việc nội dung chữ ký AUTH của người dùng bị các hợp đồng khác sử dụng.
Mặt khác, nonce là một định danh ngăn các giao dịch được phát lại. Tuy nhiên, cần lưu ý rằng opcode AUTH sẽ xác minh xem nonce trong chữ ký có phù hợp với nonce của EOA hiện được ký hay không và về mặt lý thuyết miễn là người dùng không sử dụng tài khoản EOA để bắt đầu giao dịch để tăng giá trị nonce, thì chữ ký AUTH do người dùng cấp luôn có thể được sử dụng bởi hợp đồng invoker. Đây là một lỗ hổng bảo mật rất lớn và có nghĩa là người dùng sử dụng EIP3074 phải tin tưởng nhà cung cấp dịch vụ chuyển tiếp có được chữ ký. Nếu nhà cung cấp dịch vụ chuyển tiếp có được chữ ký của người dùng là độc hại, nhà cung cấp dịch vụ có thể phát lại chữ ký AUTH của người dùng tại một số điểm để đánh cắp tài sản của người dùng.
Một vấn đề bảo mật khác là trường cam kết. Trường cam kết được sử dụng để đảm bảo một số hoạt động nhất định và người dùng có thể tinh chỉnh kiểm soát quyền chữ ký của họ trong cam kết, chẳng hạn như viết một số nội dung trong cam kết để ngăn nội dung chữ ký của họ được sử dụng để chuyển ETH. Trong tài liệu EIP3074, người đề xuất đưa ra một loạt các ví dụ về việc sử dụng trường cam kết. Nhưng vấn đề là vai trò của cam kết phụ thuộc hoàn toàn vào định nghĩa hợp đồng thông minh và về cơ bản là một nội dung tùy chọn. Các hợp đồng thông minh khác nhau có thể phân tích nội dung trong cam kết hoàn toàn không nhất quán và một số hợp đồng thậm chí có thể không đọc nội dung của cam kết. Nếu bạn muốn sử dụng EIP3074 một cách an toàn, bạn chỉ cần tự mình xem lại hợp đồng thông minh.
Cuối cùng, chúng ta hãy xem xét tác động của EIP3074 đối với mempool giao dịch Ethereum hiện tại. Với sự ra đời của EIP3074, hacker có thể sử dụng một số lượng lớn tài khoản để bắt đầu giao dịch, sau đó sử dụng các giao dịch EIP3074 để rút ETH trong các tài khoản đó cùng một lúc khi giao dịch sắp được đóng gói, điều này sẽ khiến tất cả các giao dịch đã khởi tạo trước đó không thành công. Kiểu tấn công này có thể có tác động đáng kể đến các nút lớp thực thi và về cơ bản là một cuộc tấn công DoS. Tuy nhiên, cần lưu ý rằng EIP7702 được sử dụng để thay thế EIP3074 cũng có vấn đề này, nhưng EIP7702 đưa ra một số hạn chế để tránh vấn đề này, chúng ta sẽ thảo luận sau.
Ngoài vấn đề mà EIP3074 đã được giới thiệu ở trên, tác giả của ERC4337 là Yova đã nêu thêm nhiều ý kiến phản đối trong bài viết "Implications of EIP-3074 inclusion". Nói một cách đơn giản, các ý kiến này chủ yếu bao gồm:
Rủi ro tập trung. Do thuộc tính đặc biệt của chữ ký AUTH, người dùng phải hoàn toàn tin tưởng vào nhà cung cấp dịch vụ trung gian EIP3074 và hạ tầng cơ sở. Đồng thời, hạ tầng cơ sở được xây dựng bởi các giao thức trừu tượng hóa tài khoản như ERC4337 hiện tại hoàn toàn không tương thích với EIP3074.
An toàn của người dùng. Như đã đề cập ở trên, EIP3074 không có phương pháp kiểm soát quyền truy cập được thiết kế đồng nhất, và thiết kế nonce chữ ký cũng có những nguy cơ an ninh, rất có thể dẫn đến sự xuất hiện của các vấn đề an ninh nghiêm trọng.
Chức năng trừu tượng tài khoản chưa hoàn chỉnh. So với các đề xuất trừu tượng tài khoản khác, EIP3074 không hoàn chỉnh, không thể thực hiện các chức năng như thay đổi thuật toán chữ ký của người dùng.
Vấn đề trải nghiệm người dùng. Khi người dùng cần ủy quyền tài khoản của mình cho hợp đồng thông minh, họ cần thực hiện một chữ ký AUTH, sau đó phát hành cuộc gọi chứa chữ ký AUTH lên chuỗi. Người dùng cần thực hiện hai lần chữ ký.
EIP7702 là một đề xuất được Vitalik đưa ra nhằm thay thế EIP3074. Đề xuất này không giới thiệu mã lệnh EVM mới, mà thay vào đó giới thiệu một loại giao dịch mới, được gọi là SET_CODE_TX_TYPE. Khi người dùng khởi xướng một giao dịch loại EIP7702, người dùng có thể thêm chức năng hợp đồng thông minh cho EOA của mình trong khi vẫn giữ lại các chức năng cơ bản của EOA. Nói một cách đơn giản, người dùng có thể tiếp tục sử dụng ví như MetaMask để khởi xướng giao dịch hoặc cho phép những người dùng khác gọi địa chỉ EOA dưới dạng hợp đồng thông minh.
Chúng tôi sẽ giới thiệu chức năng của EIP7702 thông qua một ví dụ đơn giản về giao dịch hàng loạt. Người dùng có thể sử dụng EIP7702 để ủy quyền địa chỉ EOA của mình cho một hợp đồng thông minh có thể thực hiện các cuộc gọi hàng loạt, sau đó người dùng có thể trực tiếp gọi địa chỉ EOA của mình theo cách hợp đồng thông minh để thực hiện giao dịch hàng loạt.
Về mặt triển khai kỹ thuật, so với các giao dịch truyền thống, EIP7702 giới thiệu danh sách ủy quyền \ _list các loại giao dịch, đó là [[chuỗi \ _id, địa chỉ, nonce, y \ _parity, r, s], ...]. trong đó address là địa chỉ hợp đồng thông minh mà người dùng muốn ủy quyền và nonce là giá trị nonce hiện tại của người dùng. Các y_parity, r và s còn lại là kết quả của chữ ký của người dùng. Trong quy trình thực thi cụ thể, trước tiên chúng ta sẽ lặp lại từng mục trong ủy quyền \ _list để xử lý và phương pháp xử lý là khôi phục địa chỉ EOA thông qua các tham số chữ ký như y \ _parity, sau đó trỏ địa chỉ EOA đến hợp đồng thông minh với địa chỉ địa chỉ. Sau đó, địa chỉ EOA có thể chấp nhận cuộc gọi để phát chức năng của hợp đồng.
Ưu điểm của EIP7702 là rõ ràng và lợi thế cốt lõi của EIP7702 về cơ bản là cho phép EOA có chức năng của một hợp đồng thông minh. Điều này phù hợp với các quy tắc trừu tượng hóa tài khoản cơ bản như ERC4337, có nghĩa là EIP7702 có thể tận dụng tất cả cơ sở hạ tầng hiện có trong miền trừu tượng hóa tài khoản hiện tại để khám phá và tái sử dụng cơ sở hạ tầng hiện có, chẳng hạn như EIP7702 có thể trực tiếp sử dụng cơ sở hạ tầng ERC4337. EntryPoint v0.8 với sự hỗ trợ cho các cuộc gọi EIP7702 hiện có sẵn trong ERC4337. Từ góc độ tái sử dụng cơ sở hạ tầng hiện có, EIP7702 có cùng mức độ không vui chơi như ERC4337.
Tất nhiên, EIP7702 thực sự cũng không hoàn toàn khắc phục được các vấn đề xuất hiện trong EIP3074. Phần lớn các vấn đề trong EIP3074 vẫn tồn tại. EIP7702 yêu cầu các hợp đồng tài khoản phải có triển khai an toàn, trong khi chính giao thức không đảm bảo an toàn nào. Ở giai đoạn đầu được đề xuất, có một số nhà phát triển đã đề xuất chuẩn hóa nonce chữ ký để tránh các cuộc tấn công replay có thể xảy ra, nhưng cuối cùng EIP7702 cũng không chấp nhận những đề xuất này. Vì vậy, nếu người dùng muốn sử dụng EIP7702 một cách an toàn, thì người dùng cần tự kiểm tra tính an toàn của hợp đồng.
Đồng thời, EIP7702 cũng tạo ra hàng loạt vấn đề cho tầng lớp điều hành. Ở trên, chúng tôi đã mô tả một cách khả thi để khai thác EIP3074 để thực hiện các cuộc tấn công DoS vào các nhóm bộ nhớ lớp thực thi. Phương pháp này cũng có hiệu quả trong EIP7702. Do đó, EIP7702 khuyến nghị rằng tất cả các địa chỉ EOA sử dụng EIP7702 chỉ nên có một giao dịch đang chờ xử lý trong mempool để tránh các cuộc tấn công DoS quy mô lớn.
Tóm lại, vấn đề lớn nhất của EIP3074 là EIP3074 không thực hiện đầy đủ chức năng trừu tượng hóa tài khoản, trong khi EIP7702 đã thực hiện đầy đủ chức năng trừu tượng hóa tài khoản. Và chính tác giả của ERC4337 đã định nghĩa "trừu tượng hóa tài khoản đầy đủ" bao gồm những nội dung gì. Đọc đến đây, độc giả sẽ hiểu tại sao EIP3074 bị đội ngũ ERC4337 phản đối và cuối cùng bị EIP7702 thay thế. Chúng tôi sẽ giới thiệu toàn bộ quy trình quản trị và thảo luận trong phần sau.
Quy trình quản lý của EIP3074 và EIP7702
EIP3074 đã được đề cập rất sớm trong cuộc họp các nhà phát triển cốt lõi của Ethereum. Vào ngày 2 tháng 4 năm 2021, trong cuộc họp #109, các nhà phát triển cốt lõi của Ethereum đã có một cuộc thảo luận đơn giản về EIP3074. Kết quả thảo luận rất đơn giản:
Alexey đã nêu ra rằng nội dung chữ ký EIP3074 có nguy cơ an ninh, có thể gây ra tổn thất nghiêm trọng cho người dùng, đề xuất EIP3074 cần quy định rõ hơn về nội dung cụ thể của chữ ký AUTH, đề xuất này đã nhận được sự ủng hộ từ Martin.
James đã chỉ ra rằng EIP3074 có thể mang lại lỗ hổng tiềm ẩn ở lớp thực thi, chẳng hạn như tấn công DoS, và đề xuất EIP3074 nên đưa ra phân tích mối đe dọa bằng văn bản.
Alexey và Martin phàn nàn rằng chất lượng tài liệu EIP3074 bình thường, đã tốn rất nhiều thời gian để đọc và hiểu.
Martin cho rằng cốt lõi của EIP3074 là sự hợp tác và thực hiện với các ứng dụng, đặc biệt là các nhà phát triển ví, tác giả của EIP3074 cho biết đã có một loạt các cuộc trao đổi với các nhà phát triển ứng dụng.
Điều thú vị là, Vitalik trong hội nghị này cho rằng Ethereum cần một giải pháp kỹ thuật để tạo ra nhiều cuộc gọi từ một giao dịch được thiết kế cho EOA. Mặc dù EIP3074 có những vấn đề an ninh tiềm ẩn, nhưng EIP3074 đã đề xuất một giải pháp kỹ thuật khả thi, các nhà phát triển cần tiến lên dựa trên EIP3074.
Rõ ràng, do EIP3074 có vấn đề về an ninh, cuộc họp này đã không đưa EIP3074 vào nâng cấp London.
Vào ngày 11 tháng 6 năm 2021, trong cuộc họp #115, các nhà phát triển EIP3074 đã nộp báo cáo về các vấn đề kiểm toán an ninh, cuộc họp chủ yếu thảo luận về các vấn đề an ninh của EIP3074. Một kết luận đơn giản là hợp đồng invoker của EIP3074 rất quan trọng trong hệ thống, vì vậy liệu có cần quản lý hợp đồng invoker hay không là một câu hỏi. Các nhà phát triển EIP3074 mong muốn thực hiện chứng minh hình thức cho hợp đồng invoker nhằm tăng cường an ninh.
Tất nhiên, còn có một số thảo luận về việc có một số hợp đồng sử dụng msg.sender == tx.origin để xác định địa chỉ gọi có phải là EOA hay không. Khi EIP3074 được đưa vào, những xác định này sẽ không còn hiệu lực, nhưng kết luận là sự mất hiệu lực của những xác định này sẽ không tạo ra vấn đề an toàn nghiêm trọng. Nói một cách ngắn gọn, cuộc họp lần này chủ yếu là để người đề xuất EIP3074 giới thiệu kết quả kiểm toán an toàn của 3074 đến các nhà phát triển cốt lõi. Kết luận cuối cùng của cuộc họp là 3074 cần xem xét vấn đề hợp đồng invoker, khuyến nghị không nên đưa vào hard fork London.
Trong cuộc họp #116 ngày 25 tháng 6 năm 2021, tác giả chính của ERC4337, Yova, đã đệ trình tài liệu "A case for a simpler alternative to EIP 3074". Tài liệu này chỉ ra rằng EIP3074 có nhiều vấn đề về an toàn, đề xuất sửa đổi một số nội dung, chẳng hạn như giới hạn nội dung của trường commit trong chữ ký, yêu cầu trường commit phải có dạng {nonce,to,gas,calldata,value,chainid}. Sau khi sử dụng mô hình chữ ký này, EIP3074 chỉ có thể được sử dụng để thực hiện một số giao dịch cụ thể nhằm đảm bảo an toàn cho giao dịch.
Tác giả của EIP3074 trong cuộc họp này đã phản hồi về tài liệu mà Yova đã nộp:
Hy vọng sẽ đưa địa chỉ hợp đồng invoker vào tiêu chuẩn EIP, sau đó các nhà phát triển cốt lõi của Ethereum sẽ viết một hợp đồng invoker an toàn để tránh các vấn đề về bảo mật.
Về nội dung commit trong chữ ký, các nhà phát triển EIP3074 cho rằng đây hoàn toàn là vấn đề của người dùng và phần mềm ví, không cần phải quy định trong EIP.
Vitalik đã đưa ra ba điểm sau trong hội nghị này:
EIP3074 vẫn sử dụng phương pháp ký secp256k1 truyền thống không thể đạt được tính năng chống lại lượng tử.
EIP3074 không có tính tương thích trong tương lai, việc sử dụng EIP3074 cũng không thể biến một EOA thành tài khoản hợp đồng thông minh.
EIP3074 có vòng đời hữu hạn. 3074 giới thiệu hai mã lệnh trước AUTH và AUTHCALL, nhưng theo lộ trình trừu tượng hóa tài khoản, trong tương lai tất cả các ví trên Ethereum có thể là ví thông minh, mã lệnh trước EIP3074 sẽ bị loại bỏ trong tương lai.
Trong cuộc họp #131 vào ngày 4 tháng 2 năm 2022, các nhà phát triển đã thảo luận về các loại EIP nên được bao gồm trong bản nâng cấp ShangHai. EIP3074 đã được đưa vào phạm vi thảo luận, nhưng các nhà phát triển chỉ đơn giản là đồng bộ hóa các động thái phát triển của EIP3074. Đáng chú ý, trước khi cuộc họp bắt đầu, nethermind đã viết bài "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337", trong đó không có ý kiến phản đối nào đối với EIP3074.
Trong Cuộc họp #167 vào ngày 3 tháng 8 năm 2023, các nhà phát triển cốt lõi đã đề cập đến EIP3074 trong khi thảo luận về một EIP5806 khác. EIP5806 là hợp đồng cho phép EOA gọi các hợp đồng bên ngoài bằng cách sử dụng các cuộc gọi deleGate.io trong quá trình giao dịch. Đề án này có phần giống với EIP7702. Tuy nhiên, tính bảo mật của giải pháp này cũng đã bị các nhà phát triển cốt lõi đặt câu hỏi, với Ansgar lưu ý rằng trong quá khứ EIP3074 không thể được đưa vào hard fork do các vấn đề bảo mật có thể xảy ra, EIP5806 là một cách tiếp cận tích cực hơn.
Trong cuộc họp #182 vào ngày 29 tháng 2 năm 2024, các nhà phát triển đã thảo luận chi tiết về việc liệu EIP3074 có nên được đưa vào nâng cấp Pectra hay không. Vitalik đã đề xuất rằng bất kỳ tiêu chuẩn trừu tượng tài khoản nào cũng cần phải có ba chức năng sau:
Thay đổi khóa
Khóa từ bỏ
Có thể tương thích với chữ ký kháng lượng tử
Vitalik chỉ ra rằng EIP5806 có thể là một lựa chọn tốt hơn EIP3074. Andrew cho rằng EIP3074 so với EIP5806 thì tổng quát hơn, vì vậy đề xuất sử dụng EIP3074. Vitalik đã phản bác lại Andrew, cho rằng trong tương lai tất cả các ví có thể đều là ví hợp đồng thông minh, và khi điều này xảy ra, mã lệnh tiền tệ được giới thiệu bởi EIP3074 sẽ không còn hiệu lực. Yoav, với tư cách là tác giả của ERC4337, đã có một bài phát biểu dài trong cuộc họp này, nội dung bài phát biểu chủ yếu bao gồm:
EIP3074 có thể dẫn đến cuộc tấn công DoS vào bộ nhớ của Ethereum, trong khi ERC4337 đã thực hiện nhiều nghiên cứu về phần này và đưa ra một số quy tắc để tránh tấn công.
EIP3074 yêu cầu người dùng ký hai lần khi thực hiện giao dịch hàng loạt, điều này là không hợp lý.
EIP3074 yêu cầu sử dụng các trung gian tập trung
Yova có xu hướng sử dụng EIP5806 như một giải pháp trừu tượng hóa tài khoản.
Bên trong Cuộc họp # 183 vào ngày 14 tháng 3 năm 2024, các nhà phát triển cốt lõi đã mời Dan Finlay của MetaMask thảo luận về suy nghĩ của ví về EIP3074. Dan ủng hộ EIP3074, lưu ý rằng MetaMask cũng sẽ hỗ trợ thử nghiệm của EIP3074. MetaMask tin rằng EIP3074 có thể cho phép EOA tận hưởng đầy đủ chức năng trừu tượng hóa tài khoản. Về mặt bảo mật, EIP3074 cung cấp giải pháp cho các nhà cung cấp dịch vụ ví, đó là tách khóa nóng và lạnh. Nhà cung cấp dịch vụ ví có thể giữ chữ ký EIP3074 của EOA để bắt đầu giao dịch và người dùng có thể sử dụng khóa riêng nóng trong các giao dịch thông thường, nhưng khóa riêng lạnh có thể được giữ trong ví phần cứng của người dùng và khi phát hiện trường hợp khẩn cấp, người dùng có thể sử dụng khóa riêng lạnh trong ví lạnh để bắt đầu giao dịch thu hồi chữ ký của EIP3074. Giải pháp tách khóa riêng nóng và lạnh này mang lại sự linh hoạt cho các nhà cung cấp ví.
Vitalik chỉ ra rằng trong EIP3074, các nhà thiết kế ví phải thiết kế logic ủy quyền nghiêm ngặt để tránh lạm dụng chữ ký EIP3074 của người dùng. Thật thú vị, khi thảo luận về khả năng thêm chức năng EIP3074 của MetaMask, Vitalik đã chỉ ra rằng L2 có thể được sử dụng như một giải pháp chuyển tiếp, tức là, bất kỳ thay đổi lớp thực thi mới nào cũng nên được thực hiện trước trong L2, vì L2 có kinh phí hạn chế và có thể gây ra tổn thất nghiêm trọng ngay cả khi có sự cố.
Dror Tiros trong cuộc thảo luận đã chỉ ra rằng cách tốt nhất để đảm bảo an toàn cho EIP3074 là để Ethereum chính thức cung cấp hợp đồng invoker. Tuy nhiên, Dan Finlay phản đối ý kiến về việc chính thức cung cấp hợp đồng, Dan cho rằng hợp đồng invoker nên hoàn toàn do người dùng quyết định, và thị trường cuối cùng sẽ chọn ra hợp đồng invoker an toàn nhất.
Ansgar vẫn kiên quyết rằng EIP3074 chỉ một chữ ký nên tương ứng với một giao dịch, nhà cung cấp ví không nên tái sử dụng chữ ký của người dùng để khởi tạo giao dịch, nhưng Dan Finlay cũng đã bày tỏ ý kiến phản đối. Dan Finlay cho rằng EIP3074 nên được ký bởi ví lạnh, sau đó nhà cung cấp ví có thể tái sử dụng chữ ký đó để trực tiếp khởi tạo giao dịch cho người dùng, nếu mỗi lần đều yêu cầu người dùng ký lại, có thể dẫn đến việc khóa lạnh bị sử dụng nhiều lần. Điều này không phù hợp với tư tưởng tách biệt khóa lạnh và khóa nóng.
Trong cuộc họp lần này, các nhà phát triển cốt lõi đã thảo luận về một chủ đề quan trọng khác là danh sách bao gồm. Danh sách bao gồm là một phương tiện để tăng cường tính chống kiểm duyệt của Ethereum. Nói một cách đơn giản, danh sách bao gồm cho phép một số giao dịch được cam kết sẽ được bao gồm trực tiếp trong khối tiếp theo. Nhưng các nhà phát triển cốt lõi chỉ ra rằng EIP3074 mâu thuẫn với danh sách bao gồm.
Tại Cuộc họp #185 vào ngày 11 tháng 4 năm 2024, hầu hết các triển khai của khách hàng đã đồng ý tham gia EIP3074 hard fork Petra, nhưng Geth phản đối với lý do EIP3074 có thể gây ra vấn đề với cây Verkle. Danno vẫn chống lại nó, vì EIP3074 có thể được sử dụng lại cho chữ ký. Yoav cũng phản đối, đề xuất một cách để tấn công mempool bằng cách sử dụng các giao dịch EIP3074 và blob. Nói một cách đơn giản, kẻ tấn công có thể bắt đầu một số lượng lớn các giao dịch blob có chứa một lượng lớn dữ liệu và sau đó sử dụng EIP3074 để làm mất hiệu lực tất cả chúng.
Nói ngắn gọn, trong cuộc họp lần này, tất cả các nhà phát triển khách hàng đều đồng ý rằng EIP3074 sẽ được đưa vào bản nâng cấp cuối cùng.
Trong cuộc họp #187 vào ngày 9 tháng 5 năm 2024, các nhà phát triển cốt lõi lần đầu tiên thảo luận về vấn đề thay thế EIP3074 bằng EIP7702. EIP7702 đã hoàn thành trong vòng 90 phút trước khi cuộc họp các nhà phát triển cốt lõi bắt đầu. Trong cuộc họp, các nhà phát triển cốt lõi đã công nhận EIP7702 là một tiêu chuẩn vượt trội hơn EIP3074. Cuộc họp này không có tiếng nói phản đối nào đối với EIP7702, chỉ có một số nhà nghiên cứu cho rằng EIP7702 cũng có thuộc tính không thể thu hồi tương tự như EIP3074, có thể dẫn đến vấn đề an toàn tài chính.
Trong cuộc họp Meeting #188 vào ngày 23 tháng 5 năm 2024, các nhà phát triển cốt lõi đã thảo luận về khả năng thay thế EIP7702 cho EIP3074. Kết luận cuối cùng của cuộc họp là sử dụng EIP7702 để thay thế EIP3074 như tiêu chuẩn trừu tượng tài khoản trong phân nhánh cứng Pectra. Vitalik chỉ ra rằng EIP7702 cũng có một số tính chất không thể thu hồi tương tự như EIP3074, những thuộc tính này đã được thảo luận nhiều trong cuộc thảo luận về EIP3074. Điều thú vị là có nhiều đại diện của ERC4337 tham gia phát biểu trong cuộc họp.
Thực tế, cuộc thảo luận về việc EIP3074 bị EIP7702 thay thế đã được thảo luận rộng rãi trước 188 cuộc họp các nhà phát triển cốt lõi, và kết quả thảo luận tại thời điểm đó là 3074 sẽ bị thay thế, vì vậy trong cuộc họp các nhà phát triển cốt lõi không có nhiều tranh cãi.
Lộ trình và phán quyết
Cơ sở hạ tầng cốt lõi của tài khoản trừu tượng Zerodev đã công bố một bài viết thú vị sau khi biết rằng EIP3074 sẽ bị thay thế, bài viết có tiêu đề là "Những suy ngẫm về quản trị Ethereum sau cuộc chiến 3074". Kết luận của bài viết là EIP7702 là một đề xuất tốt, có thể mang lại lợi ích cho tất cả người dùng. Tuy nhiên, quy trình quản trị thay thế EIP3074 bằng EIP7702 không phải là tốt nhất, lý do bao gồm:
EIP3074 đã trải qua một quá trình thảo luận lâu dài, trong phần trên chúng tôi đã giới thiệu nhiều lần thảo luận về EIP3074 trong cuộc họp của các nhà phát triển cốt lõi.
Sau khi EIP3074 được xác định sẽ được đưa vào nâng cấp Pectra, nó đã nhận được nhiều phản đối từ cộng đồng ERC4337. Tất nhiên, như đã đề cập ở trên, chúng tôi đã chỉ ra rằng yova, nhà phát triển cốt lõi của ERC4337, đã nhiều lần bày tỏ sự phản đối của mình đối với EIP3074 trong các cuộc họp của các nhà phát triển cốt lõi.
Zerodev cho rằng con đường quản trị tốt nhất nên là trong quá trình thảo luận dài lâu giữa các nhà phát triển cốt lõi của EIP3074, cộng đồng ERC4337 nên tham gia rộng rãi và bày tỏ ý kiến của mình.
Các nhà phát triển EIP3074 cho rằng ERC4337 nên chịu trách nhiệm về thất bại trong quản trị. Bởi vì EIP3074 đã tích cực tham gia vào quản trị trong những năm qua và đã nhiều lần trao đổi với nhà phát triển cốt lõi của ERC4337 là yova.
Cộng đồng ERC4337 cho rằng EIP3074 nên chịu trách nhiệm chính về sự thất bại trong quản trị. Các thành viên của cộng đồng ERC4337 cho rằng Yova, với tư cách là nhà phát triển cốt lõi của ERC4337, đã bày tỏ ý kiến phản đối EIP3074 trong nhiều cuộc họp của các nhà phát triển cốt lõi, nhưng các nhà phát triển cốt lõi dường như không lắng nghe ý kiến. Phần lớn các thành viên trong cộng đồng ERC4337 không quan tâm đến các diễn biến quản trị của EIP3074, hầu hết các thành viên đều cho rằng EIP3074 là một tiêu chuẩn đã chết. Cộng đồng ERC4337 cũng cho rằng các nhà phát triển cốt lõi không tích cực giao tiếp với cộng đồng ERC4337.
EIP3074 và ERC4337 đều cho rằng họ đã thực hiện công việc quản trị đúng đắn, trong khi đối phương nên chịu trách nhiệm chính về sự thất bại trong quản trị. Rõ ràng, trong quá trình quản trị lần này có một nguyên nhân sâu xa hơn đang hoạt động.
Nói một cách đơn giản, lý do sâu xa hơn thực sự là lộ trình của Ethereum. Lộ trình Ethereum có quyền lực cao hơn các cuộc họp của các nhà phát triển cốt lõi. Lộ trình trừu tượng tài khoản thì lấy ERC4337 làm trung tâm. EIP7702 hoàn toàn tương thích với tiêu chuẩn ERC4337, nhưng EIP3074 không hoàn toàn tương thích với tiêu chuẩn ERC4337. Vì vậy, từ góc độ lộ trình của Ethereum, việc EIP3074 bị thay thế là điều chắc chắn sẽ xảy ra.
Tất nhiên, lộ trình Ethereum đều là sự thể hiện tầm nhìn tương lai của Ethereum từ cá nhân Vitalik. Khi có những tranh cãi nghiêm trọng trong quá trình quản trị, Vitalik, với tư cách là người định nghĩa lộ trình, sẽ có quyền quyết định cuối cùng. Chính quyết định của Vitalik đã dẫn đến việc EIP3074 bị thay thế.
Mô hình quản trị của Ethereum là mô hình values ⇒ vision ⇒ roadmaps ⇒ clients, hoặc còn gọi là mô hình VVRC. Quy trình quản trị của nó như sau:
giá trị giá trị, đặc biệt là giá trị của cộng đồng, giá trị của cộng đồng Ethereum bao gồm phi tập trung, chống kiểm duyệt, v.v.
vision tầm nhìn, thực ra chính là suy nghĩ của Vitalik về tương lai của Ethereum.
roadmaps lộ trình, các nhà nghiên cứu đưa ra một số cân nhắc về chi tiết kỹ thuật dựa trên tầm nhìn để đưa ra lộ trình thực hiện tương đối đầy đủ.
clients Khách hàng thực hiện, các nhà phát triển cốt lõi của khách hàng sử dụng các công cụ như hội nghị các nhà phát triển cốt lõi để thảo luận về lộ trình, và hiện thực hóa các yêu cầu trong lộ trình.
Quy trình trên mới thực sự là quy trình quản trị của Ethereum. Chúng ta có thể thấy rằng tầm nhìn cá nhân của Vitalik nằm ở phần đáy của mô hình quản trị Ethereum, vì vậy một khi có tranh luận nghiêm trọng xuất hiện trong việc thực hiện khách hàng, ý kiến cá nhân của Vitalik sẽ được quyết định cuối cùng.
>
> Tài liệu tham khảo
>
>
\u003e Giới thiệu ZeroDev
>
>
> null
>
>
>
>
>
> Giới thiệu ZeroDev
>
>
> null
>
>
>
>
>
>Ghi chú về lộ trình Trừu tượng hóa tài khoản - HackMD
>
>
> # Ghi chú về lộ trình Trừu tượng Tài khoản *Lời cảm ơn đặc biệt đến Vitalik và đội ngũ AA vì phản hồi
>
>
>
>
>
>
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Chiến tranh quản trị Ethereum: EIP3074, ERC4337 và EIP7702
Tác giả: shew
Tóm tắt
Trong việc nâng cấp Pectra, đã xuất hiện vấn đề tranh chấp quản trị phức tạp nhất. Khi EIP3074 được đưa vào nâng cấp Pectra, đã gây ra cuộc tranh luận lớn, đặc biệt là từ đội ngũ ERC4337 phản đối.
EIP3074 đang gặp khó khăn, quy trình quản trị không thể tiếp tục. Cho đến khi Vitalik đề xuất EIP7702 kết thúc những nghi ngờ của đội ERC4337 đối với EIP3074.
GCC Research phát hiện ra rằng vấn đề quản trị liên quan đến EIP3074 và ERC7702 trong việc nâng cấp Pectra ít được thảo luận trong thế giới tiếng Trung. Tuy nhiên, vấn đề quản trị này cũng phản ánh những vấn đề sâu sắc trong quản trị Ethereum, tức là trong bối cảnh code is law, ai có thể kiểm soát nội dung cụ thể của code. Vấn đề quản trị của EIP3074 và ERC7702 có thể cho chúng ta một góc nhìn tốt để quan sát quy trình quản trị thực sự bên trong Ethereum.
Kết luận cuối cùng của bài viết này được trích dẫn từ bài bình luận của ZeroDev, bài viết chỉ ra rằng hệ thống quản trị Ethereum là mô hình VVRC, bất kỳ đề xuất nào cần phải phù hợp với giá trị Ethereum (Value) trước tiên, sau đó đề xuất đó nên phản ánh trong tầm nhìn được thiết kế bởi Vitalik (Vision), cuối cùng đề xuất nên được phản ánh trong lộ trình (Roadmap), cuối cùng các nhà phát triển cốt lõi sẽ thảo luận và đưa nó vào thực hiện trong khách hàng (Client).
Các EIP2537 được giới thiệu bởi GCC Research trong bài viết trước chỉ có các vấn đề triển khai ở cấp độ khách hàng dẫn đến sự chậm trễ cuối cùng trong việc tham gia hard fork, trong khi EIP3074 không được đưa vào hard fork do các vấn đề về Tầm nhìn và Lộ trình, và các nhà phát triển cốt lõi Ethereum đã trực tiếp chọn EIP7702 được viết bởi Vitalik làm đề xuất trừu tượng hóa tài khoản cuối cùng.
Tóm tắt nội dung đề xuất
Trước khi giới thiệu các quy trình quản lý cụ thể, chúng ta cần giới thiệu một cách ngắn gọn về nội dung cụ thể của EIP3074, EIP7702 và ERC4337 mà bài viết đề cập.
EIP3074 là một đề xuất ở tầng thực thi, việc thực hiện đề xuất này cần nâng cấp phần mềm nút. Mục tiêu cốt lõi của EIP3074 là thực hiện chức năng tài trợ gas và giao dịch hàng loạt. Tài trợ gas được hiểu là người dùng có thể sử dụng bất kỳ mã thông báo nào để thanh toán phí gas, hoặc người dùng có thể thanh toán phí gas ngoại tuyến. Tuy nhiên, cần lưu ý rằng, so với các đề xuất trừu tượng tài khoản khác cho phép thay đổi thuật toán xác minh chữ ký, EIP3074 không cho phép người dùng sử dụng bất kỳ thuật toán chữ ký nào ngoài secp256k1. Nói cách khác, EIP3074 không phải là một đề xuất đáp ứng tất cả các chức năng trừu tượng tài khoản. Đây cũng là một điểm mà EIP3074 bị chỉ trích nhiều.
Để đạt được mục tiêu dự kiến, EIP3074 đã giới thiệu hai mã thao tác, lần lượt là AUTH và AUTHCALL. Trong đó, mã thao tác AUTH có thể thông qua việc xác minh chữ ký, khi xác minh chữ ký thành công, mã thao tác này sẽ cấu hình địa chỉ authorized trong ngữ cảnh EVM hiện tại là địa chỉ của người ký. Khi cấu hình địa chỉ authorized trong ngữ cảnh, AUTHCALL có thể sử dụng địa chỉ authorized làm msg.sender để thực hiện giao dịch. Theo một cách nào đó, người dùng có thể ủy quyền tài khoản của mình cho một hợp đồng thông minh thông qua chữ ký trong một giao dịch. Chúng tôi thường gọi hợp đồng thông minh được người dùng ủy quyền này là hợp đồng invoker.
Nội dung chữ ký cụ thể của người dùng là gì? Người dùng cần ký vào nội dung sau:
Địa chỉ invoker trong nội dung trên đề cập đến địa chỉ hợp đồng invoker mà người dùng muốn ủy quyền, EVM sẽ kiểm tra xem nội dung chữ ký của người dùng có khớp với hợp đồng thực sự kiểm tra chữ ký hay không, nhằm tránh việc nội dung chữ ký AUTH của người dùng bị các hợp đồng khác sử dụng.
Mặt khác, nonce là một định danh ngăn các giao dịch được phát lại. Tuy nhiên, cần lưu ý rằng opcode AUTH sẽ xác minh xem nonce trong chữ ký có phù hợp với nonce của EOA hiện được ký hay không và về mặt lý thuyết miễn là người dùng không sử dụng tài khoản EOA để bắt đầu giao dịch để tăng giá trị nonce, thì chữ ký AUTH do người dùng cấp luôn có thể được sử dụng bởi hợp đồng invoker. Đây là một lỗ hổng bảo mật rất lớn và có nghĩa là người dùng sử dụng EIP3074 phải tin tưởng nhà cung cấp dịch vụ chuyển tiếp có được chữ ký. Nếu nhà cung cấp dịch vụ chuyển tiếp có được chữ ký của người dùng là độc hại, nhà cung cấp dịch vụ có thể phát lại chữ ký AUTH của người dùng tại một số điểm để đánh cắp tài sản của người dùng.
Một vấn đề bảo mật khác là trường cam kết. Trường cam kết được sử dụng để đảm bảo một số hoạt động nhất định và người dùng có thể tinh chỉnh kiểm soát quyền chữ ký của họ trong cam kết, chẳng hạn như viết một số nội dung trong cam kết để ngăn nội dung chữ ký của họ được sử dụng để chuyển ETH. Trong tài liệu EIP3074, người đề xuất đưa ra một loạt các ví dụ về việc sử dụng trường cam kết. Nhưng vấn đề là vai trò của cam kết phụ thuộc hoàn toàn vào định nghĩa hợp đồng thông minh và về cơ bản là một nội dung tùy chọn. Các hợp đồng thông minh khác nhau có thể phân tích nội dung trong cam kết hoàn toàn không nhất quán và một số hợp đồng thậm chí có thể không đọc nội dung của cam kết. Nếu bạn muốn sử dụng EIP3074 một cách an toàn, bạn chỉ cần tự mình xem lại hợp đồng thông minh.
Cuối cùng, chúng ta hãy xem xét tác động của EIP3074 đối với mempool giao dịch Ethereum hiện tại. Với sự ra đời của EIP3074, hacker có thể sử dụng một số lượng lớn tài khoản để bắt đầu giao dịch, sau đó sử dụng các giao dịch EIP3074 để rút ETH trong các tài khoản đó cùng một lúc khi giao dịch sắp được đóng gói, điều này sẽ khiến tất cả các giao dịch đã khởi tạo trước đó không thành công. Kiểu tấn công này có thể có tác động đáng kể đến các nút lớp thực thi và về cơ bản là một cuộc tấn công DoS. Tuy nhiên, cần lưu ý rằng EIP7702 được sử dụng để thay thế EIP3074 cũng có vấn đề này, nhưng EIP7702 đưa ra một số hạn chế để tránh vấn đề này, chúng ta sẽ thảo luận sau.
Ngoài vấn đề mà EIP3074 đã được giới thiệu ở trên, tác giả của ERC4337 là Yova đã nêu thêm nhiều ý kiến phản đối trong bài viết "Implications of EIP-3074 inclusion". Nói một cách đơn giản, các ý kiến này chủ yếu bao gồm:
EIP7702 là một đề xuất được Vitalik đưa ra nhằm thay thế EIP3074. Đề xuất này không giới thiệu mã lệnh EVM mới, mà thay vào đó giới thiệu một loại giao dịch mới, được gọi là SET_CODE_TX_TYPE. Khi người dùng khởi xướng một giao dịch loại EIP7702, người dùng có thể thêm chức năng hợp đồng thông minh cho EOA của mình trong khi vẫn giữ lại các chức năng cơ bản của EOA. Nói một cách đơn giản, người dùng có thể tiếp tục sử dụng ví như MetaMask để khởi xướng giao dịch hoặc cho phép những người dùng khác gọi địa chỉ EOA dưới dạng hợp đồng thông minh.
Chúng tôi sẽ giới thiệu chức năng của EIP7702 thông qua một ví dụ đơn giản về giao dịch hàng loạt. Người dùng có thể sử dụng EIP7702 để ủy quyền địa chỉ EOA của mình cho một hợp đồng thông minh có thể thực hiện các cuộc gọi hàng loạt, sau đó người dùng có thể trực tiếp gọi địa chỉ EOA của mình theo cách hợp đồng thông minh để thực hiện giao dịch hàng loạt.
Về mặt triển khai kỹ thuật, so với các giao dịch truyền thống, EIP7702 giới thiệu danh sách ủy quyền \ _list các loại giao dịch, đó là [[chuỗi \ _id, địa chỉ, nonce, y \ _parity, r, s], ...]. trong đó address là địa chỉ hợp đồng thông minh mà người dùng muốn ủy quyền và nonce là giá trị nonce hiện tại của người dùng. Các y_parity, r và s còn lại là kết quả của chữ ký của người dùng. Trong quy trình thực thi cụ thể, trước tiên chúng ta sẽ lặp lại từng mục trong ủy quyền \ _list để xử lý và phương pháp xử lý là khôi phục địa chỉ EOA thông qua các tham số chữ ký như y \ _parity, sau đó trỏ địa chỉ EOA đến hợp đồng thông minh với địa chỉ địa chỉ. Sau đó, địa chỉ EOA có thể chấp nhận cuộc gọi để phát chức năng của hợp đồng.
Ưu điểm của EIP7702 là rõ ràng và lợi thế cốt lõi của EIP7702 về cơ bản là cho phép EOA có chức năng của một hợp đồng thông minh. Điều này phù hợp với các quy tắc trừu tượng hóa tài khoản cơ bản như ERC4337, có nghĩa là EIP7702 có thể tận dụng tất cả cơ sở hạ tầng hiện có trong miền trừu tượng hóa tài khoản hiện tại để khám phá và tái sử dụng cơ sở hạ tầng hiện có, chẳng hạn như EIP7702 có thể trực tiếp sử dụng cơ sở hạ tầng ERC4337. EntryPoint v0.8 với sự hỗ trợ cho các cuộc gọi EIP7702 hiện có sẵn trong ERC4337. Từ góc độ tái sử dụng cơ sở hạ tầng hiện có, EIP7702 có cùng mức độ không vui chơi như ERC4337.
Tất nhiên, EIP7702 thực sự cũng không hoàn toàn khắc phục được các vấn đề xuất hiện trong EIP3074. Phần lớn các vấn đề trong EIP3074 vẫn tồn tại. EIP7702 yêu cầu các hợp đồng tài khoản phải có triển khai an toàn, trong khi chính giao thức không đảm bảo an toàn nào. Ở giai đoạn đầu được đề xuất, có một số nhà phát triển đã đề xuất chuẩn hóa nonce chữ ký để tránh các cuộc tấn công replay có thể xảy ra, nhưng cuối cùng EIP7702 cũng không chấp nhận những đề xuất này. Vì vậy, nếu người dùng muốn sử dụng EIP7702 một cách an toàn, thì người dùng cần tự kiểm tra tính an toàn của hợp đồng.
Đồng thời, EIP7702 cũng tạo ra hàng loạt vấn đề cho tầng lớp điều hành. Ở trên, chúng tôi đã mô tả một cách khả thi để khai thác EIP3074 để thực hiện các cuộc tấn công DoS vào các nhóm bộ nhớ lớp thực thi. Phương pháp này cũng có hiệu quả trong EIP7702. Do đó, EIP7702 khuyến nghị rằng tất cả các địa chỉ EOA sử dụng EIP7702 chỉ nên có một giao dịch đang chờ xử lý trong mempool để tránh các cuộc tấn công DoS quy mô lớn.
Tóm lại, vấn đề lớn nhất của EIP3074 là EIP3074 không thực hiện đầy đủ chức năng trừu tượng hóa tài khoản, trong khi EIP7702 đã thực hiện đầy đủ chức năng trừu tượng hóa tài khoản. Và chính tác giả của ERC4337 đã định nghĩa "trừu tượng hóa tài khoản đầy đủ" bao gồm những nội dung gì. Đọc đến đây, độc giả sẽ hiểu tại sao EIP3074 bị đội ngũ ERC4337 phản đối và cuối cùng bị EIP7702 thay thế. Chúng tôi sẽ giới thiệu toàn bộ quy trình quản trị và thảo luận trong phần sau.
Quy trình quản lý của EIP3074 và EIP7702
EIP3074 đã được đề cập rất sớm trong cuộc họp các nhà phát triển cốt lõi của Ethereum. Vào ngày 2 tháng 4 năm 2021, trong cuộc họp #109, các nhà phát triển cốt lõi của Ethereum đã có một cuộc thảo luận đơn giản về EIP3074. Kết quả thảo luận rất đơn giản:
Điều thú vị là, Vitalik trong hội nghị này cho rằng Ethereum cần một giải pháp kỹ thuật để tạo ra nhiều cuộc gọi từ một giao dịch được thiết kế cho EOA. Mặc dù EIP3074 có những vấn đề an ninh tiềm ẩn, nhưng EIP3074 đã đề xuất một giải pháp kỹ thuật khả thi, các nhà phát triển cần tiến lên dựa trên EIP3074.
Rõ ràng, do EIP3074 có vấn đề về an ninh, cuộc họp này đã không đưa EIP3074 vào nâng cấp London.
Vào ngày 11 tháng 6 năm 2021, trong cuộc họp #115, các nhà phát triển EIP3074 đã nộp báo cáo về các vấn đề kiểm toán an ninh, cuộc họp chủ yếu thảo luận về các vấn đề an ninh của EIP3074. Một kết luận đơn giản là hợp đồng invoker của EIP3074 rất quan trọng trong hệ thống, vì vậy liệu có cần quản lý hợp đồng invoker hay không là một câu hỏi. Các nhà phát triển EIP3074 mong muốn thực hiện chứng minh hình thức cho hợp đồng invoker nhằm tăng cường an ninh.
Tất nhiên, còn có một số thảo luận về việc có một số hợp đồng sử dụng msg.sender == tx.origin để xác định địa chỉ gọi có phải là EOA hay không. Khi EIP3074 được đưa vào, những xác định này sẽ không còn hiệu lực, nhưng kết luận là sự mất hiệu lực của những xác định này sẽ không tạo ra vấn đề an toàn nghiêm trọng. Nói một cách ngắn gọn, cuộc họp lần này chủ yếu là để người đề xuất EIP3074 giới thiệu kết quả kiểm toán an toàn của 3074 đến các nhà phát triển cốt lõi. Kết luận cuối cùng của cuộc họp là 3074 cần xem xét vấn đề hợp đồng invoker, khuyến nghị không nên đưa vào hard fork London.
Trong cuộc họp #116 ngày 25 tháng 6 năm 2021, tác giả chính của ERC4337, Yova, đã đệ trình tài liệu "A case for a simpler alternative to EIP 3074". Tài liệu này chỉ ra rằng EIP3074 có nhiều vấn đề về an toàn, đề xuất sửa đổi một số nội dung, chẳng hạn như giới hạn nội dung của trường commit trong chữ ký, yêu cầu trường commit phải có dạng {nonce,to,gas,calldata,value,chainid}. Sau khi sử dụng mô hình chữ ký này, EIP3074 chỉ có thể được sử dụng để thực hiện một số giao dịch cụ thể nhằm đảm bảo an toàn cho giao dịch.
Tác giả của EIP3074 trong cuộc họp này đã phản hồi về tài liệu mà Yova đã nộp:
Vitalik đã đưa ra ba điểm sau trong hội nghị này:
Trong cuộc họp #131 vào ngày 4 tháng 2 năm 2022, các nhà phát triển đã thảo luận về các loại EIP nên được bao gồm trong bản nâng cấp ShangHai. EIP3074 đã được đưa vào phạm vi thảo luận, nhưng các nhà phát triển chỉ đơn giản là đồng bộ hóa các động thái phát triển của EIP3074. Đáng chú ý, trước khi cuộc họp bắt đầu, nethermind đã viết bài "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337", trong đó không có ý kiến phản đối nào đối với EIP3074.
Trong Cuộc họp #167 vào ngày 3 tháng 8 năm 2023, các nhà phát triển cốt lõi đã đề cập đến EIP3074 trong khi thảo luận về một EIP5806 khác. EIP5806 là hợp đồng cho phép EOA gọi các hợp đồng bên ngoài bằng cách sử dụng các cuộc gọi deleGate.io trong quá trình giao dịch. Đề án này có phần giống với EIP7702. Tuy nhiên, tính bảo mật của giải pháp này cũng đã bị các nhà phát triển cốt lõi đặt câu hỏi, với Ansgar lưu ý rằng trong quá khứ EIP3074 không thể được đưa vào hard fork do các vấn đề bảo mật có thể xảy ra, EIP5806 là một cách tiếp cận tích cực hơn.
Trong cuộc họp #182 vào ngày 29 tháng 2 năm 2024, các nhà phát triển đã thảo luận chi tiết về việc liệu EIP3074 có nên được đưa vào nâng cấp Pectra hay không. Vitalik đã đề xuất rằng bất kỳ tiêu chuẩn trừu tượng tài khoản nào cũng cần phải có ba chức năng sau:
Vitalik chỉ ra rằng EIP5806 có thể là một lựa chọn tốt hơn EIP3074. Andrew cho rằng EIP3074 so với EIP5806 thì tổng quát hơn, vì vậy đề xuất sử dụng EIP3074. Vitalik đã phản bác lại Andrew, cho rằng trong tương lai tất cả các ví có thể đều là ví hợp đồng thông minh, và khi điều này xảy ra, mã lệnh tiền tệ được giới thiệu bởi EIP3074 sẽ không còn hiệu lực. Yoav, với tư cách là tác giả của ERC4337, đã có một bài phát biểu dài trong cuộc họp này, nội dung bài phát biểu chủ yếu bao gồm:
Yova có xu hướng sử dụng EIP5806 như một giải pháp trừu tượng hóa tài khoản.
Bên trong Cuộc họp # 183 vào ngày 14 tháng 3 năm 2024, các nhà phát triển cốt lõi đã mời Dan Finlay của MetaMask thảo luận về suy nghĩ của ví về EIP3074. Dan ủng hộ EIP3074, lưu ý rằng MetaMask cũng sẽ hỗ trợ thử nghiệm của EIP3074. MetaMask tin rằng EIP3074 có thể cho phép EOA tận hưởng đầy đủ chức năng trừu tượng hóa tài khoản. Về mặt bảo mật, EIP3074 cung cấp giải pháp cho các nhà cung cấp dịch vụ ví, đó là tách khóa nóng và lạnh. Nhà cung cấp dịch vụ ví có thể giữ chữ ký EIP3074 của EOA để bắt đầu giao dịch và người dùng có thể sử dụng khóa riêng nóng trong các giao dịch thông thường, nhưng khóa riêng lạnh có thể được giữ trong ví phần cứng của người dùng và khi phát hiện trường hợp khẩn cấp, người dùng có thể sử dụng khóa riêng lạnh trong ví lạnh để bắt đầu giao dịch thu hồi chữ ký của EIP3074. Giải pháp tách khóa riêng nóng và lạnh này mang lại sự linh hoạt cho các nhà cung cấp ví.
Vitalik chỉ ra rằng trong EIP3074, các nhà thiết kế ví phải thiết kế logic ủy quyền nghiêm ngặt để tránh lạm dụng chữ ký EIP3074 của người dùng. Thật thú vị, khi thảo luận về khả năng thêm chức năng EIP3074 của MetaMask, Vitalik đã chỉ ra rằng L2 có thể được sử dụng như một giải pháp chuyển tiếp, tức là, bất kỳ thay đổi lớp thực thi mới nào cũng nên được thực hiện trước trong L2, vì L2 có kinh phí hạn chế và có thể gây ra tổn thất nghiêm trọng ngay cả khi có sự cố.
Dror Tiros trong cuộc thảo luận đã chỉ ra rằng cách tốt nhất để đảm bảo an toàn cho EIP3074 là để Ethereum chính thức cung cấp hợp đồng invoker. Tuy nhiên, Dan Finlay phản đối ý kiến về việc chính thức cung cấp hợp đồng, Dan cho rằng hợp đồng invoker nên hoàn toàn do người dùng quyết định, và thị trường cuối cùng sẽ chọn ra hợp đồng invoker an toàn nhất.
Ansgar vẫn kiên quyết rằng EIP3074 chỉ một chữ ký nên tương ứng với một giao dịch, nhà cung cấp ví không nên tái sử dụng chữ ký của người dùng để khởi tạo giao dịch, nhưng Dan Finlay cũng đã bày tỏ ý kiến phản đối. Dan Finlay cho rằng EIP3074 nên được ký bởi ví lạnh, sau đó nhà cung cấp ví có thể tái sử dụng chữ ký đó để trực tiếp khởi tạo giao dịch cho người dùng, nếu mỗi lần đều yêu cầu người dùng ký lại, có thể dẫn đến việc khóa lạnh bị sử dụng nhiều lần. Điều này không phù hợp với tư tưởng tách biệt khóa lạnh và khóa nóng.
Trong cuộc họp lần này, các nhà phát triển cốt lõi đã thảo luận về một chủ đề quan trọng khác là danh sách bao gồm. Danh sách bao gồm là một phương tiện để tăng cường tính chống kiểm duyệt của Ethereum. Nói một cách đơn giản, danh sách bao gồm cho phép một số giao dịch được cam kết sẽ được bao gồm trực tiếp trong khối tiếp theo. Nhưng các nhà phát triển cốt lõi chỉ ra rằng EIP3074 mâu thuẫn với danh sách bao gồm.
Tại Cuộc họp #185 vào ngày 11 tháng 4 năm 2024, hầu hết các triển khai của khách hàng đã đồng ý tham gia EIP3074 hard fork Petra, nhưng Geth phản đối với lý do EIP3074 có thể gây ra vấn đề với cây Verkle. Danno vẫn chống lại nó, vì EIP3074 có thể được sử dụng lại cho chữ ký. Yoav cũng phản đối, đề xuất một cách để tấn công mempool bằng cách sử dụng các giao dịch EIP3074 và blob. Nói một cách đơn giản, kẻ tấn công có thể bắt đầu một số lượng lớn các giao dịch blob có chứa một lượng lớn dữ liệu và sau đó sử dụng EIP3074 để làm mất hiệu lực tất cả chúng.
Nói ngắn gọn, trong cuộc họp lần này, tất cả các nhà phát triển khách hàng đều đồng ý rằng EIP3074 sẽ được đưa vào bản nâng cấp cuối cùng.
Trong cuộc họp #187 vào ngày 9 tháng 5 năm 2024, các nhà phát triển cốt lõi lần đầu tiên thảo luận về vấn đề thay thế EIP3074 bằng EIP7702. EIP7702 đã hoàn thành trong vòng 90 phút trước khi cuộc họp các nhà phát triển cốt lõi bắt đầu. Trong cuộc họp, các nhà phát triển cốt lõi đã công nhận EIP7702 là một tiêu chuẩn vượt trội hơn EIP3074. Cuộc họp này không có tiếng nói phản đối nào đối với EIP7702, chỉ có một số nhà nghiên cứu cho rằng EIP7702 cũng có thuộc tính không thể thu hồi tương tự như EIP3074, có thể dẫn đến vấn đề an toàn tài chính.
Trong cuộc họp Meeting #188 vào ngày 23 tháng 5 năm 2024, các nhà phát triển cốt lõi đã thảo luận về khả năng thay thế EIP7702 cho EIP3074. Kết luận cuối cùng của cuộc họp là sử dụng EIP7702 để thay thế EIP3074 như tiêu chuẩn trừu tượng tài khoản trong phân nhánh cứng Pectra. Vitalik chỉ ra rằng EIP7702 cũng có một số tính chất không thể thu hồi tương tự như EIP3074, những thuộc tính này đã được thảo luận nhiều trong cuộc thảo luận về EIP3074. Điều thú vị là có nhiều đại diện của ERC4337 tham gia phát biểu trong cuộc họp.
Thực tế, cuộc thảo luận về việc EIP3074 bị EIP7702 thay thế đã được thảo luận rộng rãi trước 188 cuộc họp các nhà phát triển cốt lõi, và kết quả thảo luận tại thời điểm đó là 3074 sẽ bị thay thế, vì vậy trong cuộc họp các nhà phát triển cốt lõi không có nhiều tranh cãi.
Lộ trình và phán quyết
Cơ sở hạ tầng cốt lõi của tài khoản trừu tượng Zerodev đã công bố một bài viết thú vị sau khi biết rằng EIP3074 sẽ bị thay thế, bài viết có tiêu đề là "Những suy ngẫm về quản trị Ethereum sau cuộc chiến 3074". Kết luận của bài viết là EIP7702 là một đề xuất tốt, có thể mang lại lợi ích cho tất cả người dùng. Tuy nhiên, quy trình quản trị thay thế EIP3074 bằng EIP7702 không phải là tốt nhất, lý do bao gồm:
Zerodev cho rằng con đường quản trị tốt nhất nên là trong quá trình thảo luận dài lâu giữa các nhà phát triển cốt lõi của EIP3074, cộng đồng ERC4337 nên tham gia rộng rãi và bày tỏ ý kiến của mình.
Các nhà phát triển EIP3074 cho rằng ERC4337 nên chịu trách nhiệm về thất bại trong quản trị. Bởi vì EIP3074 đã tích cực tham gia vào quản trị trong những năm qua và đã nhiều lần trao đổi với nhà phát triển cốt lõi của ERC4337 là yova.
Cộng đồng ERC4337 cho rằng EIP3074 nên chịu trách nhiệm chính về sự thất bại trong quản trị. Các thành viên của cộng đồng ERC4337 cho rằng Yova, với tư cách là nhà phát triển cốt lõi của ERC4337, đã bày tỏ ý kiến phản đối EIP3074 trong nhiều cuộc họp của các nhà phát triển cốt lõi, nhưng các nhà phát triển cốt lõi dường như không lắng nghe ý kiến. Phần lớn các thành viên trong cộng đồng ERC4337 không quan tâm đến các diễn biến quản trị của EIP3074, hầu hết các thành viên đều cho rằng EIP3074 là một tiêu chuẩn đã chết. Cộng đồng ERC4337 cũng cho rằng các nhà phát triển cốt lõi không tích cực giao tiếp với cộng đồng ERC4337.
EIP3074 và ERC4337 đều cho rằng họ đã thực hiện công việc quản trị đúng đắn, trong khi đối phương nên chịu trách nhiệm chính về sự thất bại trong quản trị. Rõ ràng, trong quá trình quản trị lần này có một nguyên nhân sâu xa hơn đang hoạt động.
Nói một cách đơn giản, lý do sâu xa hơn thực sự là lộ trình của Ethereum. Lộ trình Ethereum có quyền lực cao hơn các cuộc họp của các nhà phát triển cốt lõi. Lộ trình trừu tượng tài khoản thì lấy ERC4337 làm trung tâm. EIP7702 hoàn toàn tương thích với tiêu chuẩn ERC4337, nhưng EIP3074 không hoàn toàn tương thích với tiêu chuẩn ERC4337. Vì vậy, từ góc độ lộ trình của Ethereum, việc EIP3074 bị thay thế là điều chắc chắn sẽ xảy ra.
Tất nhiên, lộ trình Ethereum đều là sự thể hiện tầm nhìn tương lai của Ethereum từ cá nhân Vitalik. Khi có những tranh cãi nghiêm trọng trong quá trình quản trị, Vitalik, với tư cách là người định nghĩa lộ trình, sẽ có quyền quyết định cuối cùng. Chính quyết định của Vitalik đã dẫn đến việc EIP3074 bị thay thế.
Mô hình quản trị của Ethereum là mô hình values ⇒ vision ⇒ roadmaps ⇒ clients, hoặc còn gọi là mô hình VVRC. Quy trình quản trị của nó như sau:
Quy trình trên mới thực sự là quy trình quản trị của Ethereum. Chúng ta có thể thấy rằng tầm nhìn cá nhân của Vitalik nằm ở phần đáy của mô hình quản trị Ethereum, vì vậy một khi có tranh luận nghiêm trọng xuất hiện trong việc thực hiện khách hàng, ý kiến cá nhân của Vitalik sẽ được quyết định cuối cùng.
> > Tài liệu tham khảo > > \u003e Giới thiệu ZeroDev > > > null > > >
> > > Giới thiệu ZeroDev > > > null > > > > > >Ghi chú về lộ trình Trừu tượng hóa tài khoản - HackMD > > > # Ghi chú về lộ trình Trừu tượng Tài khoản *Lời cảm ơn đặc biệt đến Vitalik và đội ngũ AA vì phản hồi > > > > > >