Tương lai có thể của giao thức Ethereum(sáu): thịnh vượng
Trong thiết kế giao thức Ethereum có nhiều "chi tiết" quan trọng cho sự thành công của nó. Khoảng một nửa nội dung liên quan đến các loại cải tiến EVM khác nhau, phần còn lại được cấu thành từ nhiều chủ đề ngách khác nhau, đó là ý nghĩa của "thịnh vượng".
Phồn vinh: Mục tiêu then chốt
Biến EVM thành "trạng thái cuối cùng" hiệu suất cao và ổn định
Đưa trừu tượng hóa tài khoản vào giao thức, giúp tất cả người dùng tận hưởng tài khoản an toàn và tiện lợi hơn.
Tối ưu hóa chi phí giao dịch, nâng cao khả năng mở rộng trong khi giảm thiểu rủi ro
Khám phá mật mã tiên tiến, giúp Ethereum cải thiện đáng kể trong thời gian dài
Cải tiến EVM
Vấn đề gì đã được giải quyết?
Hiện tại, EVM khó khăn trong việc phân tích tĩnh, điều này khiến cho việc tạo ra các thực hiện hiệu quả, xác minh chính thức mã và mở rộng thêm trở nên khó khăn. Ngoài ra, hiệu suất của EVM thấp, khó để thực hiện nhiều thuật toán mật mã nâng cao, trừ khi được hỗ trợ rõ ràng thông qua các biên dịch trước.
Nó là gì, nó hoạt động như thế nào?
Bước đầu tiên trong lộ trình cải tiến EVM hiện tại là định dạng đối tượng EVM (EOF), dự kiến sẽ được đưa vào trong đợt hard fork tiếp theo. EOF là một loạt các EIP, xác định phiên bản mã EVM mới, với nhiều đặc điểm độc đáo, nổi bật nhất là:
Mã ( có thể thực thi, nhưng không thể đọc ) từ EVM và dữ liệu ( có thể đọc được, nhưng không thể thực thi ) được tách ra.
Cấm nhảy động, chỉ cho phép nhảy tĩnh
Mã EVM không thể quan sát thông tin liên quan đến nhiên liệu nữa.
Đã thêm cơ chế ví dụ tường minh mới
Hợp đồng kiểu cũ sẽ tiếp tục tồn tại và có thể được tạo ra, mặc dù cuối cùng có thể sẽ dần bị loại bỏ ( hoặc thậm chí có thể bị chuyển đổi bắt buộc thành mã EOF ). Hợp đồng kiểu mới sẽ được hưởng lợi từ sự cải thiện hiệu suất do EOF mang lại — trước tiên là từ mã byte hơi nhỏ hơn nhờ tính năng con chương trình, sau đó là các chức năng mới hoặc chi phí gas giảm mà đặc biệt của EOF.
Kể từ khi giới thiệu EOF, việc nâng cấp trở nên dễ dàng hơn, hiện tại sự phát triển hoàn thiện nhất là mở rộng toán học EVM ( EVM-MAX ). EVM-MAX tạo ra một tập hợp các phép toán mới chuyên biệt cho phép toán mô và đặt chúng vào một không gian bộ nhớ mới không thể truy cập thông qua các mã thao tác khác, điều này cho phép sử dụng các tối ưu hóa như phép nhân Montgomery.
Một ý tưởng mới hơn là kết hợp EVM-MAX với đặc tính SIMD (Single Instruction Multiple Data) (, SIMD như một khái niệm của Ethereum đã tồn tại từ rất lâu, được đề xuất lần đầu bởi Greg Colvin trong EIP-616. SIMD có thể được sử dụng để tăng tốc nhiều hình thức mật mã, bao gồm hàm băm, STARKs 32-bit và mật mã dựa trên lưới, sự kết hợp giữa EVM-MAX và SIMD khiến cho hai loại mở rộng hướng tới hiệu suất này trở thành cặp tự nhiên.
Trong thực tế, điều này sẽ được xử lý theo cách song song.
)# Công việc còn lại và sự cân nhắc
Hiện tại, EOF dự định sẽ được đưa vào trong lần hard fork tiếp theo. Mặc dù luôn có khả năng loại bỏ nó vào phút chót - một số chức năng đã từng bị tạm thời loại bỏ trong các hard fork trước đó, nhưng việc làm như vậy sẽ gặp rất nhiều thách thức. Việc loại bỏ EOF có nghĩa là bất kỳ nâng cấp nào cho EVM trong tương lai sẽ phải được thực hiện mà không có EOF, mặc dù điều này có thể thực hiện được, nhưng có thể sẽ khó khăn hơn.
Sự cân nhắc chính của EVM nằm ở độ phức tạp của L1 và độ phức tạp của cơ sở hạ tầng, EOF là một lượng lớn mã cần được thêm vào việc triển khai EVM, kiểm tra mã tĩnh cũng tương đối phức tạp. Tuy nhiên, đổi lại, chúng ta có thể đơn giản hóa ngôn ngữ bậc cao, đơn giản hóa việc triển khai EVM và các lợi ích khác. Có thể nói, việc ưu tiên lộ trình cải tiến liên tục của Ethereum L1 nên bao gồm và xây dựng trên EOF.
Công việc quan trọng cần thực hiện là triển khai chức năng tương tự như EVM-MAX cộng với SIMD, và tiến hành kiểm tra hiệu suất gas tiêu thụ cho các hoạt động mã hóa khác nhau.
Làm thế nào để tương tác với các phần khác của lộ trình?
L1 điều chỉnh EVM của nó để L2 cũng có thể dễ dàng thực hiện các điều chỉnh tương ứng, nếu hai bên không thực hiện điều chỉnh đồng bộ, có thể gây ra sự không tương thích, mang lại những ảnh hưởng tiêu cực. Hơn nữa, EVM-MAX và SIMD có thể giảm chi phí gas của nhiều hệ thống chứng minh, từ đó làm cho L2 hiệu quả hơn. Nó cũng làm cho việc thay thế nhiều biên dịch trước bằng mã EVM có thể thực hiện cùng một nhiệm vụ trở nên dễ dàng hơn, có thể không ảnh hưởng lớn đến hiệu suất.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) Trừu tượng hóa tài khoản
Giải quyết vấn đề gì?
Hiện tại, giao dịch chỉ có thể được xác thực bằng một cách: chữ ký ECDSA. Ban đầu, trừu tượng hóa tài khoản được thiết kế để vượt qua điều này, cho phép logic xác thực của tài khoản trở thành mã EVM tùy ý. Điều này có thể kích hoạt một loạt các ứng dụng:
Chuyển sang mật mã kháng lượng tử
Luân chuyển khóa cũ ### được coi là thực tiễn an toàn được khuyến nghị (
Ví đa chữ ký và ví phục hồi xã hội
Sử dụng một khóa để thực hiện các hoạt động có giá trị thấp, sử dụng một khóa khác ) hoặc một nhóm khóa ( để thực hiện các hoạt động có giá trị cao.
Cho phép giao thức bảo mật hoạt động mà không cần trung gian, giảm đáng kể độ phức tạp của nó và loại bỏ một điểm phụ thuộc trung ương quan trọng.
Kể từ khi khái niệm trừu tượng hóa tài khoản được đưa ra vào năm 2015, mục tiêu của nó cũng đã mở rộng bao gồm nhiều "mục tiêu tiện lợi", chẳng hạn như một tài khoản không có ETH nhưng sở hữu một số ERC20 có thể sử dụng ERC20 để thanh toán gas.
MPC) Tính toán đa phương ( là một công nghệ đã có 40 năm lịch sử, được sử dụng để chia nhỏ khóa thành nhiều phần và lưu trữ trên nhiều thiết bị, sử dụng công nghệ mật mã để tạo ra chữ ký mà không cần kết hợp trực tiếp các phần khóa này.
EIP-7702 là một đề xuất dự kiến sẽ được đưa vào trong lần phân tách cứng tiếp theo, EIP-7702 là kết quả của sự nhận thức ngày càng tăng về việc cung cấp tính tiện lợi của trừu tượng tài khoản để mang lại lợi ích cho tất cả người dùng ), bao gồm người dùng EOA (, nhằm cải thiện trải nghiệm của tất cả người dùng trong ngắn hạn và tránh việc phân tách thành hai hệ sinh thái.
Công việc này bắt đầu từ EIP-3074 và cuối cùng hình thành EIP-7702. EIP-7702 cung cấp "chức năng tiện lợi" của sự trừu tượng tài khoản cho tất cả người dùng, bao gồm cả EOA) tài khoản được sở hữu bên ngoài hiện tại, tức là tài khoản ( được kiểm soát bởi chữ ký ECDSA.
Mặc dù một số thách thức ) đặc biệt là thách thức "thuận tiện" ( có thể được giải quyết thông qua các công nghệ tiến bộ như tính toán đa bên hoặc EIP-7702, nhưng mục tiêu an toàn chính mà các đề xuất trừu tượng tài khoản ban đầu đưa ra chỉ có thể đạt được bằng cách quay ngược lại và giải quyết vấn đề gốc: cho phép mã hợp đồng thông minh kiểm soát xác thực giao dịch. Nguyên nhân đến nay chưa được thực hiện là do việc thực hiện một cách an toàn, điều này là một thách thức.
)# Nó là gì, nó hoạt động như thế nào?
Cốt lõi của trừu tượng hóa tài khoản rất đơn giản: cho phép hợp đồng thông minh khởi tạo giao dịch, không chỉ EOA. Toàn bộ sự phức tạp đến từ việc thực hiện điều này theo cách thân thiện với việc duy trì mạng lưới phi tập trung và ngăn chặn các cuộc tấn công từ chối dịch vụ.
Một thách thức chính điển hình là vấn đề thất bại đa dạng:
Nếu có 1000 hàm xác thực tài khoản phụ thuộc vào một giá trị đơn lẻ S, và giá trị hiện tại S làm cho tất cả các giao dịch trong bộ nhớ đều hợp lệ, thì một giao dịch đơn lẻ đảo ngược giá trị S có thể làm cho tất cả các giao dịch khác trong bộ nhớ không còn hiệu lực. Điều này cho phép kẻ tấn công gửi các giao dịch rác đến bộ nhớ với chi phí rất thấp, từ đó làm tắc nghẽn tài nguyên của các nút mạng.
Sau nhiều năm nỗ lực, nhằm mở rộng chức năng đồng thời hạn chế rủi ro từ chối dịch vụ ###DoS(, cuối cùng đã đưa ra giải pháp để đạt được "trừu tượng tài khoản lý tưởng": ERC-4337.
Cách hoạt động của ERC-4337 là chia việc xử lý các thao tác của người dùng thành hai giai đoạn: xác minh và thực thi. Tất cả các xác minh được xử lý trước, và tất cả các thực thi được xử lý sau. Trong bộ nhớ, chỉ khi giai đoạn xác minh của thao tác người dùng chỉ liên quan đến tài khoản của chính họ và không đọc các biến môi trường thì mới được chấp nhận. Điều này có thể ngăn chặn các cuộc tấn công từ chối dịch vụ nhiều lần. Ngoài ra, cũng thực hiện các giới hạn gas nghiêm ngặt đối với bước xác minh.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 được thiết kế như một tiêu chuẩn giao thức bổ sung )ERC(, vì vào thời điểm đó các nhà phát triển khách hàng Ethereum tập trung vào việc hợp nhất )Merge(, không có thêm năng lượng để xử lý các chức năng khác. Đó là lý do tại sao ERC-4337 sử dụng một đối tượng được gọi là thao tác người dùng, thay vì giao dịch thông thường. Tuy nhiên, gần đây chúng tôi nhận ra cần phải viết ít nhất một phần nội dung đó vào giao thức.
Hai lý do chính như sau:
EntryPoint với tính không hiệu quả vốn có của hợp đồng: mỗi gói có chi phí cố định khoảng 100,000 gas, và mỗi thao tác của người dùng tốn thêm hàng nghìn gas.
Đảm bảo tính cần thiết của thuộc tính Ethereum: như danh sách bao gồm các đảm bảo cần được chuyển đến người dùng trừu tượng tài khoản.
Ngoài ra, ERC-4337 còn mở rộng hai chức năng:
Đại lý thanh toán ) Paymasters (: cho phép một tài khoản đại diện cho một tài khoản khác thanh toán phí, điều này vi phạm quy tắc chỉ có thể truy cập tài khoản gửi tiền trong giai đoạn xác thực, do đó đã đưa ra các biện pháp xử lý đặc biệt để đảm bảo an toàn cho cơ chế đại lý thanh toán.
Giao thức ) Aggregators (: Hỗ trợ chức năng tổng hợp chữ ký, như tổng hợp BLS hoặc tổng hợp dựa trên SNARK. Điều này là cần thiết để đạt được hiệu quả dữ liệu cao nhất trên Rollup.
)# Công việc còn lại và sự cân nhắc
Hiện tại, vấn đề chính cần giải quyết là làm thế nào để hoàn toàn đưa trừu tượng tài khoản vào giao thức, gần đây giao thức trừu tượng tài khoản EIP được ưa chuộng là EIP-7701, đề xuất này thực hiện trừu tượng tài khoản trên EOF. Một tài khoản có thể sở hữu một phần mã riêng biệt để xác minh, nếu tài khoản thiết lập phần mã đó, thì phần mã đó sẽ được thực thi trong bước xác minh giao dịch từ tài khoản đó.
Điều hấp dẫn của phương pháp này là nó chỉ ra rõ ràng hai quan điểm tương đương của trừu tượng tài khoản địa phương:
Đưa EIP-4337 vào như một phần của giao thức
Một loại EOA mới, trong đó thuật toán ký là thực thi mã EVM
Nếu chúng ta bắt đầu bằng cách thiết lập ranh giới nghiêm ngặt cho độ phức tạp của mã có thể thực thi trong thời gian xác minh - không cho phép truy cập vào trạng thái bên ngoài, thậm chí giới hạn gas được thiết lập ban đầu cũng thấp đến mức không có hiệu lực đối với các ứng dụng chống lượng tử hoặc bảo vệ quyền riêng tư - thì tính an toàn của phương pháp này rất rõ ràng: chỉ cần thay thế xác minh ECDSA bằng việc thực thi mã EVM cần thời gian tương tự.
Tuy nhiên, theo thời gian, chúng ta cần nới lỏng những giới hạn này, vì việc cho phép các ứng dụng bảo vệ quyền riêng tư hoạt động mà không cần trung gian, cũng như khả năng chống lại lượng tử đều rất quan trọng. Để làm được điều này, chúng ta cần tìm cách linh hoạt hơn để giải quyết rủi ro từ chối dịch vụ ###DoS( mà không yêu cầu các bước xác thực phải cực kỳ đơn giản.
Sự cân nhắc chính dường như là "ghi nhanh một giải pháp mà ít người hài lòng" và "chờ đợi lâu hơn, có thể đạt được giải pháp lý tưởng hơn", phương pháp lý tưởng có thể là một phương pháp hỗn hợp. Một phương pháp hỗn hợp là ghi nhanh một số trường hợp sử dụng và dành nhiều thời gian hơn để khám phá các trường hợp sử dụng khác. Một phương pháp khác là triển khai trước phiên bản trừu tượng tài khoản tham vọng hơn trên L2. Tuy nhiên, thách thức mà điều này phải đối mặt là đội ngũ L2 cần phải tự tin vào công việc của đề xuất được áp dụng để sẵn sàng thực hiện, đặc biệt là để đảm bảo rằng L1 và/hoặc các L2 khác trong tương lai có thể áp dụng các giải pháp tương thích.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Một ứng dụng khác mà chúng ta cũng cần xem xét rõ ràng là tài khoản lưu trữ khóa, những tài khoản này lưu trữ trạng thái liên quan đến tài khoản trên L1 hoặc L2 chuyên dụng, nhưng có thể được sử dụng trên L1 và bất kỳ L2 tương thích nào. Để thực hiện điều này một cách hiệu quả có thể yêu cầu L2 hỗ trợ các mã thao tác như L1SLOAD hoặc REMOTESTATICCALL, nhưng điều này cũng cần sự hỗ trợ từ việc triển khai trừu tượng tài khoản trên L2 cho những thao tác này.
)# Nó tương tác như thế nào với các phần khác của lộ trình?
Danh sách bao gồm cần hỗ trợ giao dịch trừu tượng tài khoản, trong thực tế, nhu cầu về danh sách bao gồm và nhu cầu về bộ nhớ phi tập trung thực sự rất giống nhau, mặc dù đối với danh sách bao gồm thì tính linh hoạt có phần lớn hơn. Ngoài ra, việc triển khai trừu tượng tài khoản nên được thực hiện phối hợp giữa L1 và L2 càng nhiều càng tốt. Nếu trong tương lai chúng ta mong đợi hầu hết người dùng sử dụng Rollup lưu trữ khóa, thiết kế trừu tượng tài khoản nên
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
UnluckyMiner
· 1giờ trước
còn phải là evm bull nhỉ
Xem bản gốcTrả lời0
AirdropLicker
· 20giờ trước
Tạm biệt, bơm Gas đã đến.
Xem bản gốcTrả lời0
ChainWanderingPoet
· 08-05 23:23
Chi phí lại cần tối ưu hóa, BTC cũng không giải quyết được.
Triển vọng tương lai của giao thức Ethereum: Cập nhật EVM, trừu tượng hóa tài khoản và tối ưu hóa Rửa tiền
Tương lai có thể của giao thức Ethereum(sáu): thịnh vượng
Trong thiết kế giao thức Ethereum có nhiều "chi tiết" quan trọng cho sự thành công của nó. Khoảng một nửa nội dung liên quan đến các loại cải tiến EVM khác nhau, phần còn lại được cấu thành từ nhiều chủ đề ngách khác nhau, đó là ý nghĩa của "thịnh vượng".
Phồn vinh: Mục tiêu then chốt
Cải tiến EVM
Vấn đề gì đã được giải quyết?
Hiện tại, EVM khó khăn trong việc phân tích tĩnh, điều này khiến cho việc tạo ra các thực hiện hiệu quả, xác minh chính thức mã và mở rộng thêm trở nên khó khăn. Ngoài ra, hiệu suất của EVM thấp, khó để thực hiện nhiều thuật toán mật mã nâng cao, trừ khi được hỗ trợ rõ ràng thông qua các biên dịch trước.
Nó là gì, nó hoạt động như thế nào?
Bước đầu tiên trong lộ trình cải tiến EVM hiện tại là định dạng đối tượng EVM (EOF), dự kiến sẽ được đưa vào trong đợt hard fork tiếp theo. EOF là một loạt các EIP, xác định phiên bản mã EVM mới, với nhiều đặc điểm độc đáo, nổi bật nhất là:
Hợp đồng kiểu cũ sẽ tiếp tục tồn tại và có thể được tạo ra, mặc dù cuối cùng có thể sẽ dần bị loại bỏ ( hoặc thậm chí có thể bị chuyển đổi bắt buộc thành mã EOF ). Hợp đồng kiểu mới sẽ được hưởng lợi từ sự cải thiện hiệu suất do EOF mang lại — trước tiên là từ mã byte hơi nhỏ hơn nhờ tính năng con chương trình, sau đó là các chức năng mới hoặc chi phí gas giảm mà đặc biệt của EOF.
Kể từ khi giới thiệu EOF, việc nâng cấp trở nên dễ dàng hơn, hiện tại sự phát triển hoàn thiện nhất là mở rộng toán học EVM ( EVM-MAX ). EVM-MAX tạo ra một tập hợp các phép toán mới chuyên biệt cho phép toán mô và đặt chúng vào một không gian bộ nhớ mới không thể truy cập thông qua các mã thao tác khác, điều này cho phép sử dụng các tối ưu hóa như phép nhân Montgomery.
Một ý tưởng mới hơn là kết hợp EVM-MAX với đặc tính SIMD (Single Instruction Multiple Data) (, SIMD như một khái niệm của Ethereum đã tồn tại từ rất lâu, được đề xuất lần đầu bởi Greg Colvin trong EIP-616. SIMD có thể được sử dụng để tăng tốc nhiều hình thức mật mã, bao gồm hàm băm, STARKs 32-bit và mật mã dựa trên lưới, sự kết hợp giữa EVM-MAX và SIMD khiến cho hai loại mở rộng hướng tới hiệu suất này trở thành cặp tự nhiên.
Trong thực tế, điều này sẽ được xử lý theo cách song song.
)# Công việc còn lại và sự cân nhắc
Hiện tại, EOF dự định sẽ được đưa vào trong lần hard fork tiếp theo. Mặc dù luôn có khả năng loại bỏ nó vào phút chót - một số chức năng đã từng bị tạm thời loại bỏ trong các hard fork trước đó, nhưng việc làm như vậy sẽ gặp rất nhiều thách thức. Việc loại bỏ EOF có nghĩa là bất kỳ nâng cấp nào cho EVM trong tương lai sẽ phải được thực hiện mà không có EOF, mặc dù điều này có thể thực hiện được, nhưng có thể sẽ khó khăn hơn.
Sự cân nhắc chính của EVM nằm ở độ phức tạp của L1 và độ phức tạp của cơ sở hạ tầng, EOF là một lượng lớn mã cần được thêm vào việc triển khai EVM, kiểm tra mã tĩnh cũng tương đối phức tạp. Tuy nhiên, đổi lại, chúng ta có thể đơn giản hóa ngôn ngữ bậc cao, đơn giản hóa việc triển khai EVM và các lợi ích khác. Có thể nói, việc ưu tiên lộ trình cải tiến liên tục của Ethereum L1 nên bao gồm và xây dựng trên EOF.
Công việc quan trọng cần thực hiện là triển khai chức năng tương tự như EVM-MAX cộng với SIMD, và tiến hành kiểm tra hiệu suất gas tiêu thụ cho các hoạt động mã hóa khác nhau.
Làm thế nào để tương tác với các phần khác của lộ trình?
L1 điều chỉnh EVM của nó để L2 cũng có thể dễ dàng thực hiện các điều chỉnh tương ứng, nếu hai bên không thực hiện điều chỉnh đồng bộ, có thể gây ra sự không tương thích, mang lại những ảnh hưởng tiêu cực. Hơn nữa, EVM-MAX và SIMD có thể giảm chi phí gas của nhiều hệ thống chứng minh, từ đó làm cho L2 hiệu quả hơn. Nó cũng làm cho việc thay thế nhiều biên dịch trước bằng mã EVM có thể thực hiện cùng một nhiệm vụ trở nên dễ dàng hơn, có thể không ảnh hưởng lớn đến hiệu suất.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) Trừu tượng hóa tài khoản
Giải quyết vấn đề gì?
Hiện tại, giao dịch chỉ có thể được xác thực bằng một cách: chữ ký ECDSA. Ban đầu, trừu tượng hóa tài khoản được thiết kế để vượt qua điều này, cho phép logic xác thực của tài khoản trở thành mã EVM tùy ý. Điều này có thể kích hoạt một loạt các ứng dụng:
Cho phép giao thức bảo mật hoạt động mà không cần trung gian, giảm đáng kể độ phức tạp của nó và loại bỏ một điểm phụ thuộc trung ương quan trọng.
Kể từ khi khái niệm trừu tượng hóa tài khoản được đưa ra vào năm 2015, mục tiêu của nó cũng đã mở rộng bao gồm nhiều "mục tiêu tiện lợi", chẳng hạn như một tài khoản không có ETH nhưng sở hữu một số ERC20 có thể sử dụng ERC20 để thanh toán gas.
MPC) Tính toán đa phương ( là một công nghệ đã có 40 năm lịch sử, được sử dụng để chia nhỏ khóa thành nhiều phần và lưu trữ trên nhiều thiết bị, sử dụng công nghệ mật mã để tạo ra chữ ký mà không cần kết hợp trực tiếp các phần khóa này.
EIP-7702 là một đề xuất dự kiến sẽ được đưa vào trong lần phân tách cứng tiếp theo, EIP-7702 là kết quả của sự nhận thức ngày càng tăng về việc cung cấp tính tiện lợi của trừu tượng tài khoản để mang lại lợi ích cho tất cả người dùng ), bao gồm người dùng EOA (, nhằm cải thiện trải nghiệm của tất cả người dùng trong ngắn hạn và tránh việc phân tách thành hai hệ sinh thái.
Công việc này bắt đầu từ EIP-3074 và cuối cùng hình thành EIP-7702. EIP-7702 cung cấp "chức năng tiện lợi" của sự trừu tượng tài khoản cho tất cả người dùng, bao gồm cả EOA) tài khoản được sở hữu bên ngoài hiện tại, tức là tài khoản ( được kiểm soát bởi chữ ký ECDSA.
Mặc dù một số thách thức ) đặc biệt là thách thức "thuận tiện" ( có thể được giải quyết thông qua các công nghệ tiến bộ như tính toán đa bên hoặc EIP-7702, nhưng mục tiêu an toàn chính mà các đề xuất trừu tượng tài khoản ban đầu đưa ra chỉ có thể đạt được bằng cách quay ngược lại và giải quyết vấn đề gốc: cho phép mã hợp đồng thông minh kiểm soát xác thực giao dịch. Nguyên nhân đến nay chưa được thực hiện là do việc thực hiện một cách an toàn, điều này là một thách thức.
)# Nó là gì, nó hoạt động như thế nào?
Cốt lõi của trừu tượng hóa tài khoản rất đơn giản: cho phép hợp đồng thông minh khởi tạo giao dịch, không chỉ EOA. Toàn bộ sự phức tạp đến từ việc thực hiện điều này theo cách thân thiện với việc duy trì mạng lưới phi tập trung và ngăn chặn các cuộc tấn công từ chối dịch vụ.
Một thách thức chính điển hình là vấn đề thất bại đa dạng:
Nếu có 1000 hàm xác thực tài khoản phụ thuộc vào một giá trị đơn lẻ S, và giá trị hiện tại S làm cho tất cả các giao dịch trong bộ nhớ đều hợp lệ, thì một giao dịch đơn lẻ đảo ngược giá trị S có thể làm cho tất cả các giao dịch khác trong bộ nhớ không còn hiệu lực. Điều này cho phép kẻ tấn công gửi các giao dịch rác đến bộ nhớ với chi phí rất thấp, từ đó làm tắc nghẽn tài nguyên của các nút mạng.
Sau nhiều năm nỗ lực, nhằm mở rộng chức năng đồng thời hạn chế rủi ro từ chối dịch vụ ###DoS(, cuối cùng đã đưa ra giải pháp để đạt được "trừu tượng tài khoản lý tưởng": ERC-4337.
Cách hoạt động của ERC-4337 là chia việc xử lý các thao tác của người dùng thành hai giai đoạn: xác minh và thực thi. Tất cả các xác minh được xử lý trước, và tất cả các thực thi được xử lý sau. Trong bộ nhớ, chỉ khi giai đoạn xác minh của thao tác người dùng chỉ liên quan đến tài khoản của chính họ và không đọc các biến môi trường thì mới được chấp nhận. Điều này có thể ngăn chặn các cuộc tấn công từ chối dịch vụ nhiều lần. Ngoài ra, cũng thực hiện các giới hạn gas nghiêm ngặt đối với bước xác minh.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 được thiết kế như một tiêu chuẩn giao thức bổ sung )ERC(, vì vào thời điểm đó các nhà phát triển khách hàng Ethereum tập trung vào việc hợp nhất )Merge(, không có thêm năng lượng để xử lý các chức năng khác. Đó là lý do tại sao ERC-4337 sử dụng một đối tượng được gọi là thao tác người dùng, thay vì giao dịch thông thường. Tuy nhiên, gần đây chúng tôi nhận ra cần phải viết ít nhất một phần nội dung đó vào giao thức.
Hai lý do chính như sau:
Ngoài ra, ERC-4337 còn mở rộng hai chức năng:
)# Công việc còn lại và sự cân nhắc
Hiện tại, vấn đề chính cần giải quyết là làm thế nào để hoàn toàn đưa trừu tượng tài khoản vào giao thức, gần đây giao thức trừu tượng tài khoản EIP được ưa chuộng là EIP-7701, đề xuất này thực hiện trừu tượng tài khoản trên EOF. Một tài khoản có thể sở hữu một phần mã riêng biệt để xác minh, nếu tài khoản thiết lập phần mã đó, thì phần mã đó sẽ được thực thi trong bước xác minh giao dịch từ tài khoản đó.
Điều hấp dẫn của phương pháp này là nó chỉ ra rõ ràng hai quan điểm tương đương của trừu tượng tài khoản địa phương:
Nếu chúng ta bắt đầu bằng cách thiết lập ranh giới nghiêm ngặt cho độ phức tạp của mã có thể thực thi trong thời gian xác minh - không cho phép truy cập vào trạng thái bên ngoài, thậm chí giới hạn gas được thiết lập ban đầu cũng thấp đến mức không có hiệu lực đối với các ứng dụng chống lượng tử hoặc bảo vệ quyền riêng tư - thì tính an toàn của phương pháp này rất rõ ràng: chỉ cần thay thế xác minh ECDSA bằng việc thực thi mã EVM cần thời gian tương tự.
Tuy nhiên, theo thời gian, chúng ta cần nới lỏng những giới hạn này, vì việc cho phép các ứng dụng bảo vệ quyền riêng tư hoạt động mà không cần trung gian, cũng như khả năng chống lại lượng tử đều rất quan trọng. Để làm được điều này, chúng ta cần tìm cách linh hoạt hơn để giải quyết rủi ro từ chối dịch vụ ###DoS( mà không yêu cầu các bước xác thực phải cực kỳ đơn giản.
Sự cân nhắc chính dường như là "ghi nhanh một giải pháp mà ít người hài lòng" và "chờ đợi lâu hơn, có thể đạt được giải pháp lý tưởng hơn", phương pháp lý tưởng có thể là một phương pháp hỗn hợp. Một phương pháp hỗn hợp là ghi nhanh một số trường hợp sử dụng và dành nhiều thời gian hơn để khám phá các trường hợp sử dụng khác. Một phương pháp khác là triển khai trước phiên bản trừu tượng tài khoản tham vọng hơn trên L2. Tuy nhiên, thách thức mà điều này phải đối mặt là đội ngũ L2 cần phải tự tin vào công việc của đề xuất được áp dụng để sẵn sàng thực hiện, đặc biệt là để đảm bảo rằng L1 và/hoặc các L2 khác trong tương lai có thể áp dụng các giải pháp tương thích.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Một ứng dụng khác mà chúng ta cũng cần xem xét rõ ràng là tài khoản lưu trữ khóa, những tài khoản này lưu trữ trạng thái liên quan đến tài khoản trên L1 hoặc L2 chuyên dụng, nhưng có thể được sử dụng trên L1 và bất kỳ L2 tương thích nào. Để thực hiện điều này một cách hiệu quả có thể yêu cầu L2 hỗ trợ các mã thao tác như L1SLOAD hoặc REMOTESTATICCALL, nhưng điều này cũng cần sự hỗ trợ từ việc triển khai trừu tượng tài khoản trên L2 cho những thao tác này.
)# Nó tương tác như thế nào với các phần khác của lộ trình?
Danh sách bao gồm cần hỗ trợ giao dịch trừu tượng tài khoản, trong thực tế, nhu cầu về danh sách bao gồm và nhu cầu về bộ nhớ phi tập trung thực sự rất giống nhau, mặc dù đối với danh sách bao gồm thì tính linh hoạt có phần lớn hơn. Ngoài ra, việc triển khai trừu tượng tài khoản nên được thực hiện phối hợp giữa L1 và L2 càng nhiều càng tốt. Nếu trong tương lai chúng ta mong đợi hầu hết người dùng sử dụng Rollup lưu trữ khóa, thiết kế trừu tượng tài khoản nên