- Chủ đề
52k Phổ biến
21k Phổ biến
64k Phổ biến
31k Phổ biến
4k Phổ biến
99k Phổ biến
29k Phổ biến
28k Phổ biến
7k Phổ biến
18k Phổ biến
- Ghim
52k Phổ biến
21k Phổ biến
64k Phổ biến
31k Phổ biến
4k Phổ biến
99k Phổ biến
29k Phổ biến
28k Phổ biến
7k Phổ biến
18k Phổ biến
Ethereum lộ trình tương lai: Nâng cấp EVM, trừu tượng hóa tài khoản và cải tiến 1559
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 rất cần thiết cho sự thành công của nó. Trên thực tế, 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 bao gồm nhiều chủ đề ngách khác nhau, đó là ý nghĩa của "thịnh vượng".
Thịnh vượng: Mục tiêu quan trọng
Cải tiến EVM
Đã giải quyết vấn đề gì?
Hiện tại, EVM khó khăn trong việc phân tích tĩnh, điều này khiến việc tạo ra các triển khai 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ó khăn trong việc thực hiện nhiều hình thức mật mã tiên tiến, 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 phân nhánh cứng tiếp theo. EOF là một loạt EIP, quy định một phiên bản mã EVM mới, với nhiều đặc điểm độc đáo, đáng chú ý 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 dần bị loại bỏ hợp đồng kiểu cũ ( và thậm chí có thể bị buộc chuyển đổi thành mã EOF ). Hợp đồng kiểu mới sẽ được hưởng lợi từ việc nâng cao hiệu suất do EOF mang lại - trước tiên là thông qua mã byte hơi nhỏ hơn nhờ vào tính năng con, sau đó là các chức năng mới hoặc chi phí gas giảm đặc trưng của EOF.
Sau khi giới thiệu EOF, việc nâng cấp thêm trở nên dễ dàng hơn, hiện tại phát triển hoàn thiện nhất là mở rộng số học của mô-đun EVM (EVM-MAX). EVM-MAX tạo ra một tập hợp các thao tác mới chuyên biệt cho phép tính 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 việc sử dụng các tối ưu hóa như phép nhân Montgomery.
Một ý tưởng khá mới là kết hợp EVM-MAX với đặc điểm 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 EIP-616 của Greg Colvin. 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 một cặp tự nhiên.
Một thiết kế tổng hợp EIP sẽ bắt đầu từ EIP-6690, sau đó:
for i in range)count(: mem[z_start + z_skip * count] = op) mem[x_start + x_skip * count], mem[y_start + y_skip * count] (
Trong thực tế, điều này sẽ được xử lý theo cách song song.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# 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 đợt hard fork kế tiếp. Mặc dù luôn có khả năng loại bỏ nó vào phút chót - trong các đợt hard fork trước đây, một số chức năng đã bị tạm thời loại bỏ, nhưng việc thực hiện điều này sẽ gặp rất nhiều thách thức. Việc loại bỏ EOF có nghĩa là mọi nâng cấp trong tương lai đối với EVM sẽ phải diễn ra mà không có EOF, mặc dù điều đó 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 là độ 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 thực hiện 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ữ cấp cao, đơn giản hóa việc thực hiện EVM và những lợi ích khác. Có thể nói, lộ trình ưu tiên cho việc cải tiến liên tục L1 của Ethereum nên bao gồm và xây dựng dựa trên EOF.
Một công việc quan trọng cần thực hiện là triển khai các chức năng tương tự như EVM-MAX kết hợp với SIMD, và tiến hành kiểm tra hiệu suất tiêu tốn gas của các thao tác 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 và mang lại những ảnh hưởng bất lợi. 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 mã 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 quả.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Trừu tượng 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 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 cho bất kỳ mã EVM nào. Đ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 và loại bỏ một điểm phụ thuộc trung tâm quan trọng.
Kể từ khi ý tưởng 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.
)# Nó là gì, hoạt động như thế nào?
Cốt lõi của trừu tượng tài khoản rất đơn giản: cho phép hợp đồng thông minh khởi xướng giao dịch, chứ không chỉ là 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 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 tài khoản có hàm xác thực phụ thuộc vào một giá trị duy nhất S, và giá trị S hiện tại khiến 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ớ trở nên không hợp lệ. Điều này cho phép kẻ tấn công gửi 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 trong khi hạn chế rủi ro từ chối dịch vụ ###DoS(, cuối cùng đã đưa ra giải pháp để thực hiện "trừu tượng tài khoản lý tưởng": ERC-4337.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Cách thức hoạt động của ERC-4337 là chia quá trình 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 sẽ được xử lý trước, tất cả các thực thi sẽ đượ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 gây thất bại kép. Hơn nữa, cũng có sự áp đặt hạn chế gas nghiêm ngặt đối với các bước xác minh.
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ó đủ 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 rằng 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 hóa tài khoản vào giao thức, gần đây, EIP trừu tượng hóa tài khoản viết vào giao thức được ưa chuộng là EIP-7701, đề xuất này thực hiện trừu tượng hóa tài khoản trên EOF. Một tài khoản có thể có một phần mã riêng biệt để xác thực, 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 thực của 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 góc nhìn tương đương về trừu tượng tài khoản địa phương:
Nếu chúng ta bắt đầu từ việc đặt ra 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 đặt ra từ đầ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 mất 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 và 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 ra cách linh hoạt hơn để giải quyết các rủi ro từ việc từ chối dịch vụ )DoS### mà không yêu cầu các bước xác minh phải cực kỳ đơn giản.
Sự cân nhắc chính dường như là "viết nhanh một giải pháp ít người hài lòng" và "chờ đợi lâu hơn, có thể nhận đượ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à viết 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 phiên bản trừu tượng tài khoản tham vọng hơn trên L2 trước tiên. 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 thông qua để 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.
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 giao thức như L1SLOAD hoặc REMOTESTATI.