Hướng phát triển có thể của giao thức Ethereum: Phồn vinh

Nhiều "chi tiết" trong giao thức Ethereum là rất quan trọng cho sự thành công của 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 được cấu thành từ nhiều chủ đề ngách khác nhau, đó chính là ý nghĩa của "phồn thịnh".

Thịnh vượng: Mục tiêu chính

• Biến EVM thành "trạng thái cuối cùng" hiệu suất cao và ổn định
• Giới thiệu trừu tượng tài khoản vào giao thức, cho phé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 dài hạn

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à thực hiện mở rộng thêm trở nên khó khăn. Hơn nữa, hiệu quả của EVM thấp, khó có thể 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 các EIP, quy định một 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 giữa ).
• 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.
• Đã thêm một cơ chế quy trình con rõ ràng 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 dần bị loại bỏ hợp đồng kiểu cũ ( và thậm chí có thể bị chuyển đổi bắt buộc sang 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ờ tính năng tiểu chương trình, sau đó là các chức năng mới hoặc chi phí gas giảm do 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 sự phát triển hoàn thiện nhất là mở rộng toán học EVM module ( 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 thực hiện phép toán modulo, 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ã hoạt động 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 mới hơn là kết hợp EVM-MAX với đặc tính SIMD (đơn chỉ thị đa dữ liệu) (, SIMD đã tồn tại như một khái niệm của Ethereum trong một thời gian dài, đượ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 của EVM-MAX và SIMD làm cho hai loại mở rộng hướng vào hiệu suất này trở thành một cặp tự nhiên.

![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(

)# Liên kết nghiên cứu hiện có

• EOF:
• EVM-MAX:
• SIMD:

Công việc còn lại và những 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 - trước đó đã có chức năng bị tạm thời loại bỏ trong các hard fork, nhưng việc làm như vậy sẽ gặp 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 diễn ra mà không có EOF, mặc dù có thể làm được, nhưng có thể sẽ khó khăn hơn.

Sự cân nhắc chính của EVM nằm ở sự phức tạp của L1 và sự 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, 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à hiện thực hóa 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 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 đ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 hưởng tiêu cực. Ngoài ra, 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 tác 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-e607936b4195e92945aa6ebd5f969276.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 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:

• Chuyển sang mật mã kháng lượng tử
• Luân chuyển khóa cũ ### được coi là một thực hành 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 thao tác có giá trị thấp, sử dụng một khóa khác ) hoặc một tập hợp các khóa ( để thực hiện các thao tác 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 tâm quan trọng.

Kể từ khi khái niệm trừu tượng 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 có 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 hóa tài khoản là đơ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 một 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 điểm:

Nếu có 1000 hàm xác thực tài khoản phụ thuộc vào một giá trị duy nhất S, và giá trị S hiện tại khiến cho 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ể khiến 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 giao dịch rác vào 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 để đạ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à phân 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 đượ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 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ừ sự cố nhiều lần. Ngoài ra, cũng áp dụng hạn chế gas nghiêm ngặt cho 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ó 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:

1. EntryPoint với đặc điểm không hiệu quả cố hữu của hợp đồng: mỗi gói có chi phí cố định khoảng 100,000 gas, cùng với hàng nghìn gas bổ sung cho mỗi thao tác của người dùng.
2. Đả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 bảo đảm cần được chuyển đến tài khoản người dùng trừu tượng.

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 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 của người gửi trong giai đoạn xác thực, do đó đã giới thiệu xử lý đặc biệt để đảm bảo tính an toàn của 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.

![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

)# Liên kết nghiên cứu hiện có

• Bài diễn thuyết về lịch sử trừu tượng tài khoản:
• ERC-4337:
• EIP-7702:
• Mã BLSWallet ### sử dụng chức năng tổng hợp (:
• EIP-7562) viết vào giao thức tài khoản trừu tượng (:
• EIP-7701) giao thức viết dựa trên EOF tài khoản trừu tượng (:

)# 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 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, một EIP được ưa chuộng cho trừu tượng tài khoản 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ể 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ã này, 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ó rõ ràng chỉ ra hai góc nhìn tương đương của việc trừu tượng hóa tài khoản địa phương:

1. Đưa EIP-4337 vào như một phần của giao thức
2. 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 đặt ra các giới hạn nghiêm ngặt về độ phức tạp của mã có thể thực thi trong thời gian xác thực - không cho phép truy cập trạng thái bên ngoài, ngay cả giới hạn gas được thiết lập ban đầu cũng thấp đến mức vô hiệu hóa các ứng dụng chống lượng tử hoặc bảo vệ quyền riêng tư - thì độ an toàn của phương pháp này rất rõ ràng: chỉ cần thay thế xác thực 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 ra những 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 minh 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ới "chờ 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à ghi lại nhanh hơn 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. Tuy nhiên, thách thức phải đối mặt là đội ngũ L2 cần phải có sự tự tin vào công việc áp dụng đề xuất, để 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 mã vận hành như L1SLOAD hoặc REMOTESTATICCALL, nhưng điều này cũng cần sự hỗ trợ của 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 chứa 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 chứa 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 chứa thì tính linh hoạt có phần lớn hơn. Hơn nữa, việc triển khai trừu tượng tài khoản nên cố gắng điều phối 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 này.

![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(

) 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 bao gồm khối trung bình.

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:

1. Công thức hơi có khuyết điểm: nó không nhằm vào 50% khối, mà nhằm vào khoảng 50-53% khối đầy đủ, điều này phụ thuộc vào phương sai ### điều này liên quan đến cái mà các nhà toán học gọi là "bất đẳng thức trung bình số học - hình học".