Tương lai có thể của giao thức Ethereum ( sáu ): thịnh vượng

Tác giả: Vitalik Buterin

Có nhiều thứ 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. Trê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 vinh".

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
• Đưa trừu tượng hóa 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 và giảm 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ó thực hiện phân tích tĩnh, điều này làm cho việc tạo ra các thực hiện 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ó có thể 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 việ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 các 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à:

• Sự tách biệt giữa mã (có thể thực thi, nhưng không thể đọc từ EVM) và dữ liệu (có thể đọc, nhưng không thể thực thi)
• Cấm chuyển hướng động, chỉ cho phép chuyển hướng tĩnh
• Mã EVM không thể quan sát thông tin liên quan đến nhiên liệu nữa.
• Đã thêm một cơ chế ví dụ rõ ràng mới

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ẽ từ từ bị loại bỏ (thậm chí có thể bị chuyển đổi bắt buộc sang mã EOF). Hợp đồng mới sẽ hưởng lợi từ việc cải thiện hiệu suất mà EOF mang lại------đầu tiên là thông qua mã byte được thu nhỏ một chút nhờ vào tính năng tiểu thủ tục, sau đó là những tính năng mới hoặc chi phí gas giảm mà EOF đặc biệt cung cấp.

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 module EVM (EVM-MAX). EVM-MAX tạo ra một tập hợp các thao tác mới chuyên biệt cho phép toán mô 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ã vận hành khác, điều này cho phép 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 tương đối mới là kết hợp EVM-MAX với tính năng đa dữ liệu một lệnh (SIMD), SIMD với tư cách là một khái niệm của Ethereum đã tồn tại từ rất lâu, được đề xuất đầu tiên 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 khiến cho hai loại mở rộng hướng tới 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 đó:

• Cho phép (i) bất kỳ số lẻ nào hoặc (ii) bất kỳ lũy thừa của 2 nào có giá trị tối đa là 2768 làm mô-đun
• Đối với mỗi mã thao tác EVM-MAX (cộng, trừ, nhân), thêm một phiên bản không còn sử dụng 3 hằng số x, y, z mà sử dụng 7 hằng số: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Trong mã Python, chức năng của những mã thao tác này tương tự như:

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ó thể thêm XOR, AND, OR, NOT và SHIFT (bao gồm cả vòng và không vòng), ít nhất là cho số mũ 2. Đồng thời thêm ISZERO (đẩy đầu ra vào ngăn xếp chính EVM), điều này sẽ đủ mạnh để thực hiện mật mã đường elip, mật mã miền nhỏ (như Poseidon, Circle STARKs), hàm băm truyền thống (như SHA256, KECCAK, BLAKE) và mật mã dựa trên lưới. Các nâng cấp EVM khác cũng có thể được thực hiện, nhưng cho đến nay chưa được quan tâm nhiều.

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

• EOF:
• EVM-MAX:
• SIMD:

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------trong các hard fork trước đó đã có chức năng bị tạm thời loại bỏ, 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 trong tương lai đối với EVM đều cần thực hiện 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 là độ phức tạp L1 và độ phức tạp cơ sở 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, kiểm tra mã tĩnh cũng tương đối phức tạp. Tuy nhiên, như một sự trao đổi, chúng ta có thể đơn giản hóa ngôn ngữ cao cấp, đơn giản hóa việc triển khai EVM và những 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à hiện thực hóa 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 hoạt động 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, mang lại 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 hiệu quả hơn. Nó cũng làm cho việc thay thế nhiều tiền biên chế 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.

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 đượ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:

• Chuyển sang mật mã chống lượng tử
• Luân phiên khóa cũ (được coi là 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 cho các hoạt động có giá trị thấp, sử dụng một khóa khác (hoặc một nhóm khóa) cho các hoạt động 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ó đã 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 để trả gas. Dưới đây là biểu đồ tổng hợp các mục tiêu này:

MPC (tính toán đa phần) là một công nghệ đã có 40 năm lịch sử, dùng để chia nhỏ khóa thành nhiều phần và lưu trữ trên nhiều thiết bị khác nhau, sử dụng công nghệ mật mã để tạo ra 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 đư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 hóa 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 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 do bên ngoài sở hữu, tức là tài khoản được kiểm soát bởi chữ ký ECDSA) hiện 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 về "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 tài khoản ban đầu đưa ra chỉ có thể đạt được bằng cách hồi tố 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 cho đến nay chưa được thực hiện là do việc triển khai an toàn, điều này là một thách thức.

Nó là gì, nó hoạt động như thế nào?

Cốt lõi của trừu tượng 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ộ độ 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 chính đ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 đều 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 đơ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 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 tính 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ý 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ì thao tác đó 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ác bước xác minh cũng được áp dụng 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. Đó là lý do tại sao ERC-4337 sử dụng các đố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 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 như là sự kém hiệu quả vốn có 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 đã được tạo ra cần chuyển giao đến người dùng trừu tượng tài khoản.

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 một 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 vào tài khoản của người gửi trong giai đoạn xác thực, do đó đã đưa ra các biện pháp đặc biệt để đảm bảo tính an toàn của cơ chế đại lý thanh toán.
• Bộ tổng hợp (Aggregators): Hỗ trợ chức năng tổng hợp chữ ký, chẳng hạn 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.

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

• Bài phát biểu 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 (trừu tượng hóa tài khoản trong giao thức):
• EIP-7701 (giao thức viết tài khoản trừu tượng dựa trên EOF):

còn lại