- Chủ đề
35k Phổ biến
12k Phổ biến
6k Phổ biến
15k Phổ biến
61k Phổ biến
31k Phổ biến
2k Phổ biến
112k Phổ biến
27k Phổ biến
27k Phổ biến
- Ghim
35k Phổ biến
12k Phổ biến
6k Phổ biến
15k Phổ biến
61k Phổ biến
31k Phổ biến
2k Phổ biến
112k Phổ biến
27k Phổ biến
27k Phổ biến
Triển vọng tương lai của Ethereum: Nâng cấp EVM và trừu tượng hóa tài khoản dẫn dắt sự thịnh vượng của giao thức
Tương lai có thể của giao thức Ethereum (sáu): Thịnh vượng
Tác giả: Vitalik Buterin
Có những điều rất khó để phân loại vào một danh mục 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, đó là ý nghĩa của "thịnh vượng".
Thịnh vượng: Mục tiêu chính
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. Ngoài ra, hiệu suất của EVM thấp, khó thực hiện nhiều hình thức 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 hard fork 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, 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 dần bị loại bỏ (thậm chí có thể được chuyển đổi bắt buộc sang 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 mà EOF mang lại - trước tiên là thông qua mã byte được thu nhỏ một chút nhờ vào tính năng tiểu trình, tiếp theo là các tính 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 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 toán học EVM (EVM-MAX). EVM-MAX tạo ra một tập hợp các thao tác mới chuyên dụng cho phép tính 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ã 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 tính năng nhiều dữ liệu theo một lệnh (SIMD), SIMD như một khái niệm của Ethereum đã tồn tại 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 làm cho hai kiểu mở rộng định hướng 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.
Liên kết nghiên cứu hiện tại
Công việc còn lại và sự cân nhắc
Hiện tại, EOF dự định được đưa vào trong phân tách cứng tiếp theo. Mặc dù luôn có khả năng loại bỏ nó vào phút chót - trong các phân tách cứng trước đây, một số chức năng đã bị tạm thời loại bỏ, nhưng việc làm như vậy sẽ gặp nhiều thách thức lớn. 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ù đ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à nhiều 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 trên EOF.
Một công việc quan trọng cần thực hiện là hiện thực hóa các 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 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 đ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 không tương thích, mang lại ảnh hưởng bất lợi. Ngoài ra, EVM-MAX và SIMD có thể giảm chi phí gas của nhiều hệ thống chứng minh, 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ác nhiệm vụ tương tự trở nên dễ dàng hơn, có thể không ảnh hưởng lớn đến hiệu suất.
tài khoản trừu tượng
Đã 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 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 tiếp sức, 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. Dưới đây là bảng tổng hợp các mục tiêu này:
MPC (tính toán nhiều bên) 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 kỹ thuật 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 hard fork 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 tiện ích 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 ngắn hạ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 EIP-7702. EIP-7702 cung cấp "chức 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 được sở hữu bên ngoài, tức là tài khoản được kiểm soát bởi chữ ký ECDSA) ngày nay.
Từ biểu đồ có thể thấy rằng, mặc dù một số thách thức (đặc biệt là thách thức "tiện lợi") 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 được đề xuất ban đầu cho đề xuất trừu tượng tài khoản chỉ có thể đạt được bằng cách quay ngược và giải quyết vấn đề ban đầu: 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 chưa được thực hiện cho đến nay là do việc thực hiện an toàn, điều này là một thách thức.
Nó là gì, cách hoạt động ra sao?
Cốt lõi của việc 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ỉ 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 quan trọng điển hình là vấn đề mất mát đ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ị duy nhất S, và giá trị hiện tại S khiến cho 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ể khiến 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 các giao dịch rác đến bộ nhớ với chi phí rất thấp, gây 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 việc 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 sẽ được xử lý trước, sau đó là tất cả các thực thi. Trong bộ 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 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 đa điểm thất bại. Hơn nữa, cũng áp dụng các 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 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 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ũng mở rộng hai chức năng:
Liên kết nghiên cứu hiện có