- Chủ đề
51k Phổ biến
21k Phổ biến
63k Phổ biến
31k Phổ biến
4k Phổ biến
98k Phổ biến
29k Phổ biến
28k Phổ biến
7k Phổ biến
18k Phổ biến
- Ghim
51k Phổ biến
21k Phổ biến
63k Phổ biến
31k Phổ biến
4k Phổ biến
98k Phổ biến
29k Phổ biến
28k Phổ biến
7k Phổ biến
18k Phổ biến
Triển vọng tương lai của giao thức Ethereum: Tối ưu hóa EVM và trừu tượng hóa tài khoản dẫn dắt sự thịnh vượng
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" 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 "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ó thực hiện 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, EVM có hiệu suất thấp, khó 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, xác đị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ẽ từ từ bị loại bỏ hợp đồng kiểu cũ ( và thậm chí có thể buộc chuyển đổi sang mã EOF ). Hợp đồng kiểu mới sẽ hưởng lợi từ sự cải thiện 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 đặc điểm con gọi, sau đó là các tính năng mới hoặc giảm chi phí gas đặc thù 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 sự 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 thực hiện phép toán mô-đun, 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ã 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 khá mới là kết hợp EVM-MAX với đặc tính SIMD (Single Instruction Multiple Data) (. SIMD, như một khái niệm trong Ethereum, đã tồn tại 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 lattice. Sự kết hợp giữa EVM-MAX và SIMD khiến cho hai hình thức mở rộng hướng đến 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 đó:
python 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.
)# 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 hard fork 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 hard fork trước đây đã có các tính năng bị loại bỏ tạm thời, nhưng việc làm như vậy sẽ phải đối mặt với 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ẽ phải diễn ra mà không có EOF, mặc dù 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 mã lớn 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, ưu tiên cho 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à triển khai chức năng tương tự như EVM-MAX cộng với SIMD, và tiến hành kiểm tra chuẩn mức 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 tiến hành điều chỉnh đồng bộ, có thể gây ra sự 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, từ đó làm cho L2 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 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 hóa 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:
Cho phép giao thức riêng 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 ương quan trọng.
Kể từ khi khái niệm trừu tượng hóa tài khoản được đề xuất 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ầ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 công nghệ mật mã để tạo chữ ký mà không cần trực tiếp kết hợp các phần khóa này.
EIP-7702 là một đề xuất dự kiến sẽ được giới thiệu 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 sự tiện lợi cho trừu tượng hóa tài khoản nhằm 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 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 ngày nay, tức là tài khoản ( được kiểm soát bởi chữ ký ECDSA.
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 mà đề xuất trừu tượng hóa tài khoản ban đầu đưa ra chỉ có thể được thực hiện bằng cách truy ngược và giải quyết vấn đề gốc: 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.
![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ì, nó 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 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 sự cố:
Nếu có 1000 hàm xác thực tài khoản đều 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 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ớ 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 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 đồng thời 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 hóa 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 minh và thực thi. Tất cả các xác minh được xử lý trước, 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 của 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 thất bại nhiều lần. Hơn nữa, các bước xác minh cũng phải tuân thủ các giới hạn gas nghiêm ngặt.
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 client 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. Đây là lý do tại sao ERC-4337 sử dụng một đối tượng gọi là thao tác 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:
(# 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 trừu tượng hóa tài khoản hoàn toàn vào giao thức, gần đây EIP 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 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 khía cạnh tương đương của trừu tượng tài khoản địa phương:
Nếu chúng ta bắt đầu bằng cách đặt ra 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 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ả đố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 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 tiếp sức, cũng như khả năng chống lại lượng tử là 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ỳ ngắn.