- Chủ đề
122 Phổ biến
25k Phổ biến
2k Phổ biến
22k Phổ biến
11k Phổ biến
997 Phổ biến
5k Phổ biến
11k Phổ biến
151k Phổ biến
1739k Phổ biến
- Ghim
122 Phổ biến
25k Phổ biến
2k Phổ biến
22k Phổ biến
11k Phổ biến
997 Phổ biến
5k Phổ biến
11k Phổ biến
151k Phổ biến
1739k Phổ biến
Ethereum Giai đoạn The Splurge: Tối ưu hóa EVM, trừu tượng hóa tài khoản và triển vọng nâng cấp EIP-1559
Tương lai có thể của giao thức Ethereum(sáu): The Splurge
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 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ừ các 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
Đã giải quyết vấn đề gì?
Hiện nay, 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. Hơn nữa, hiệu suất của EVM thấp, khó thực hiện nhiều hình thức mật mã cấp cao, trừ khi được hỗ trợ rõ ràng thông qua các biên dịch trước.
Nó là gì, làm thế nào nó hoạt động?
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, chỉ đị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à:
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ỏ hợp đồng cũ ( và thậm chí có thể được chuyển đổi bắt buộc sang mã EOF ). Hợp đồng mới sẽ được hưởng lợi từ sự cải thiện hiệu quả mà 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 gọi hàm con, sau đó là các chức năng mới hoặc chi phí gas giảm của EOF.
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 phát triển hoàn thiện nhất là mở rộng số học 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 modulo và đặt chúng vào một không gian bộ nhớ mới không thể truy cập qua các mã lệnh 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 đã tồn tại như một khái niệm của Ethereum từ rất lâu, được đề xuất đầu tiên 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 đến 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-8930b556d169a2bc7168ddc2e611d3df.webp(
)# 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 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 - đã có những chức năng bị tạm thời loại bỏ trong các lần 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 đối với EVM trong tương lai sẽ cần được thực hiện mà không có EOF, mặc dù có thể làm được, nhưng có thể 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 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à các 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 trên EOF.
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 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 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, dẫn đến những ảnh hưởng bất lợi. Ngoài ra, EVM-MAX và SIMD có thể làm 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ã tiền biên 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-ec1638a809393a6ed42724fb08f534da.webp(
) 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 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 là 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 có 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 phải 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 thuận tiện cho 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 cả 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 thời gian ngắn và tránh việc phân chia 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 nên EIP-7702. EIP-7702 cung cấp "tính năng tiện lợi" của trừu tượng hóa tài khoản cho tất cả người dùng, bao gồm cả EOA) tài khoản bên ngoài được sở hữu ngày nay, tức là tài khoản được kiểm soát bởi chữ ký ECDSA(.
![Vitalik về tương lai có thể của Ethereum (sáu): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
)# Nó là gì, làm thế nào để hoạt động?
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, không chỉ EOA. Toàn bộ sự phức tạp đến từ việc thực hiện điều này một 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 đề nhiều thất bại:
Nếu có 1000 hàm xác minh tài khoản phụ thuộc vào một giá trị duy nhất S, và giá trị hiện tại S khiến các giao dịch trong bộ nhớ đều hợp lệ, thì một giao dịch duy nhất đả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 hợp lệ. Đ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 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 để hiện thực hóa "trừu tượng tài khoản lý tưởng": ERC-4337.
Cách hoạt động của ERC-4337 là tách biệt quá trình xử lý các thao tác của người dùng thành hai giai đoạn: xác thực và thực thi. Tất cả các xác thực được xử lý trước, sau đó tất cả các thực thi được xử lý. Trong vùng nhớ, 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, 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ụ nhiều lần. Hơn nữa, cũng có việc thực thi giới hạn gas nghiêm ngặt cho bước xác thực.
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 tính năng khác. Đó là lý do tại sao ERC-4337 sử dụng một đối tượng có tên gọi là hoạt động của 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:
(# 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, vấn đề chủ yếu cần giải quyết 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, giao thức trừu tượng hóa tài khoản EIP gần đây đượ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ể sở hữu 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 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 các giới hạn 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í mức giới hạn gas được thiết lập ban đầu cũng thấp đến mức không hiệu quả cho các ứng dụng chống lại 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ư tính kháng quantum là rất quan trọng. Để làm điều này, chúng ta cần tìm ra các cách giải quyết rủi ro từ chối dịch vụ )DoS### một cách linh hoạt hơn, 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 mà ít người hài lòng" 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 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 đầy 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 có sự tự tin vào công việc của đề xuất á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.
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, cái này