- Chủ đề
8k Phổ biến
103k Phổ biến
19k Phổ biến
5k Phổ biến
29k Phổ biến
16k Phổ biến
23k Phổ biến
14k Phổ biến
3k Phổ biến
13k Phổ biến
- Ghim
8k Phổ biến
103k Phổ biến
19k Phổ biến
5k Phổ biến
29k Phổ biến
16k Phổ biến
23k Phổ biến
14k Phổ biến
3k Phổ biến
13k Phổ biến
Con đường thịnh vượng của giao thức Ethereum: Cải tiến EVM, trừu tượng hóa tài khoản và Gas đa chiều
Tương lai có thể của giao thức Ethereum (sáu): Phần thịnh vượng
Có những điều rất khó để phân loại vào một loại duy nhất, trong thiết kế giao thức Ethereum, có nhiều "chi tiết" rất quan trọng cho sự thành công của Ethereum. 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 được cấu thành từ nhiều chủ đề ngách khác nhau, đó chính là ý nghĩa của "thịnh vượng".
Phồn vinh: Mục tiêu chính
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 làm cho 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ã cao cấp, trừ khi được hỗ trợ rõ ràng thông qua các biên dịch trước.
Nó là gì, 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 hard fork tiếp theo. EOF là một loạt EIP, xác đị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 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ỏ (thậm chí có thể buộc phải chuyển đổi sang mã EOF). Hợp đồng mới sẽ được hưởng lợi từ việc nâng cao hiệu suất mà EOF mang lại.
Sau khi giới thiệu EOF, việc nâng cấp tiếp theo 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 của mô-đun EVM (EVM-MAX). EVM-MAX tạo ra một tập hợp các lệnh 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 bằng các mã lệnh khác, điều này làm cho việc sử dụng các tối ưu hóa như nhân Montgomery trở nên khả thi.
Một ý tưởng khá mới là kết hợp EVM-MAX với đặc điểm SIMD (đơn chỉ thị, đa dữ liệu), SIMD như một khái niệm của Ethereum đã tồn tại từ rất lâu, được Greg Colvin đưa ra 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 đến hiệu suất này trở thành một cặp tự nhiên.
Liên kết nghiên cứu hiện có
Công việc còn lại và sự cân nhắc
Hiện tại, EOF dự kiến sẽ được đưa vào trong hard fork tiếp theo. Mặc dù luôn có khả năng loại bỏ nó vào phút chót, nhưng việc nà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 trong tương lai cho EVM 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 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, việc 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à nhiều lợi ích khác. Có thể nói, lộ trình ưu tiên cải tiến liên tục Ethereum L1 nên bao gồm và xây dựng dựa 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à thực hiện kiểm tra hiệu suất tiêu thụ gas cho 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 mình để L2 cũng có thể dễ dàng đ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ể xảy ra không tương thích, gây ra 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 trở nên 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 nhiều đến hiệu suất.
Trừu tượng tài khoản
Vấn đề gì đã được giải quyết?
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 nhằm vượt qua điều này, cho phép logic xác thực của tài khoản là mã EVM tùy ý. Điều này có thể kích hoạt một loạt các ứng dụ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", ví dụ, một tài khoản không có ETH nhưng có một số ERC20 có thể sử dụng ERC20 để thanh toán gas.
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 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ụ.
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.
Cách hoạt động của ERC-4337 là chia quá trình xử lý thao tác của người dùng thành hai giai đoạn: xác thực và thực hiện. Tất cả các xác thực đều được xử lý trước, và tất cả các thực hiện được xử lý sau. Trong bộ nhớ tạm, chỉ khi giai đoạn xác thực 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ì nó mới được chấp nhận. Điều này giúp ngăn chặn các cuộc tấn công từ chối dịch vụ đa lần. Hơn nữa, cũng áp dụng giới hạn gas nghiêm ngặt cho các bước xác thực.
Liên kết nghiên cứu hiện có
Công việc còn lại và sự cân nhắc
Hiện tại, điều cần giải quyết chính là làm thế nào để đưa hoàn toàn trừu tượng hóa tài khoản vào giao thức. Gần đây, giao thức trừu tượng hóa tài khoản đượ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 các giao dịch từ tài khoản đó.
Sự cân nhắc chính dường như là "viết nhanh một giải pháp mà ít người hài lòng" so với "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 kết hợp. Một phương pháp kết hợp là viết nhanh hơn cho 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 đầy tham vọng hơn trên L2 trước.
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ù danh sách bao gồm có một chút linh hoạt hơn. Hơn nữa, việc triển khai trừu tượng tài khoản nên được điều phối càng nhiều càng tốt giữa L1 và L2. 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 dựa trên điều đó.
Cải tiến EIP-1559
Nó giải quyết vấn đề gì?
EIP-1559 đã được kích hoạt trên Ethereum vào năm 2021, cải thiện đáng kể thời gian trung bình bao gồm khối.
Tuy nhiên, việc thực hiện EIP-1559 hiện tại không hoàn hảo ở nhiều khía cạnh:
Công thức dành cho blobs ở phía sau (EIP-4844) được thiết kế đặc biệt để giải quyết vấn đề đầu tiên, tổng thể cũng đơn giản hơn. Tuy nhiên, EIP-1559 bản thân nó và EIP-4844 đều không cố gắng giải quyết vấn đề thứ hai.
Ngoài ra, còn có những điểm yếu khác trong việc định giá tài nguyên Ethereum không liên quan đến EIP-1559, nhưng có thể được giải quyết thông qua việc điều chỉnh EIP-1559. Một trong những vấn đề chính là sự khác biệt giữa trường hợp trung bình và trường hợp tồi tệ nhất: giá tài nguyên trong Ethereum phải được thiết lập để có thể xử lý trường hợp tồi tệ nhất, tức là toàn bộ gas tiêu thụ của một khối chiếm dụng một tài nguyên, nhưng việc sử dụng trung bình thực tế thấp hơn nhiều so với điều này, dẫn đến sự kém hiệu quả.
Gas đa chiều là gì, nó hoạt động như thế nào?
Giải pháp để giải quyết những vấn đề không hiệu quả này là Gas đa chiều: thiết lập giá cả và hạn chế khác nhau cho các tài nguyên khác nhau. Khái niệm này về mặt kỹ thuật độc lập với EIP-1559, nhưng sự tồn tại của EIP-1559 làm cho việc thực hiện giải pháp này dễ dàng hơn. Nếu không có EIP-1559, việc tối ưu hóa đóng gói một khối chứa nhiều ràng buộc tài nguyên sẽ là một vấn đề ba lô đa chiều phức tạp. Nhưng với EIP-1559, hầu hết các khối sẽ không đạt công suất tối đa trên bất kỳ tài nguyên nào, do đó thuật toán đơn giản "chấp nhận bất kỳ giao dịch nào trả đủ phí" là đủ.
Hiện tại chúng tôi đã có Gas đa chiều cho việc thực thi và khối dữ liệu; về nguyên tắc, chúng tôi có thể mở rộng nó ra nhiều chiều hơn: như calldata (dữ liệu giao dịch), đọc / ghi trạng thái, và mở rộng kích thước trạng thái.
EIP-7706 đã giới thiệu một chiều gas mới, dành riêng cho calldata. Đồng thời, nó cũng đơn giản hóa cơ chế Gas đa chiều bằng cách thống nhất ba loại gas vào một khung (theo phong cách EIP-4844), qua đó cũng giải quyết được những thiếu sót về mặt toán học của EIP-1559. EIP-7623 là một giải pháp chính xác hơn, giải quyết vấn đề tài nguyên trong trường hợp trung bình và trường hợp tồi tệ nhất, hạn chế nghiêm ngặt calldata tối đa mà không đưa ra một chiều mới hoàn toàn.
Liên kết nghiên cứu hiện có