Cảm ơn đặc biệt Fede, Danno Ferrin, Justin Drake, Ladislaus, và Tim Beiko vì phản hồi và xem xét của họ.

Mục tiêu của Ethereum là trở thành một sổ cái toàn cầu - một nền tảng chứa tài sản và ghi chép của con người, và là lớp nền cho các ứng dụng như tài chính, quản trị và xác minh dữ liệu có giá trị cao. Để đạt được mục tiêu này, nó phải có tính mở rộng và sự chịu đựng. Kế hoạch hard fork Fusaka sẽ tăng không gian khả dụng dữ liệu L2 lên 10 lần, trong khiLộ trình đề xuất năm 2026Bao gồm cả một quy mô tương tự của việc mở rộng dữ liệu L1. Trong khi đó, 'The Merge' đã nâng cấp Ethereum lên cơ chế đồng thuận chứng minh cổ phần (PoS).Sự đa dạng của khách hàng đang tăng nhanh, ZK (Zero-Knowledge Proof) verifiability và khả năng chống lại các cuộc tấn công của máy tính lượng tử cũng đang tiến triển mạnh mẽ, và hệ sinh thái ứng dụng ngày càng phát triểnChín chắn và vững vàng.

Mục tiêu của bài viết này là nhấn mạnh một cách quan trọng nhưng thường bị đánh giá thấpSự kiên cường (và cuối cùng là khả năng mở rộ)Yếu tố:
Sự đơn giản của giao thức.

Một trong những khía cạnh được khen ngợi nhất của Bitcoin là thiết kế giao thức của nó, vô cùng thanh lịch và đơn giản:

Hệ thống là một chuỗi khối blockchain. Mỗi khối được liên kết với khối trước đó thông qua một hash. Sự hợp lệ của mỗi khối được xác minh thông qua Proof of Work (PoW), nghĩa là... bạn chỉ cần kiểm tra xem các chữ số hàng đầu của hash có phải là số không. Mỗi khối chứa các giao dịch, mà hoặc tiêu tiền được thông qua khai thác, hoặc tiêu tiền được tạo ra từ các giao dịch trước đó. Đó chỉ là cơ bản vậy.
Ngay cả một học sinh thông minh cấp 3 cũng có khả năng hiểu rõ nguyên tắc hoạt động của giao thức Bitcoin. Và một lập trình viên thậm chí có thể phát triển một ứng dụng Bitcoin như một dự án sở thích.

Giữ giao thức đơn giản mang lại một loạt các lợi ích chính, có thể làm cho Bitcoin và EthereumSự trung lập đáng tin cậyTầng cơ sở của niềm tin toàn cầu:

• Làm cho logic giao thức dễ hiểu hơn, mở rộng nhóm có thể tham gia vào nghiên cứu, phát triển và quản trị giao thức, giảm thiểu rào cản kỹ thuật và tránh sự thống trị của một 'tầng lớp quản trị công nghệ' trong giao thức.
• Đáng kể giảm chi phí phát triển cơ sở hạ tầng mới tích hợp với giao thức (như khách hàng mới, máy xác minh mới, công cụ đăng nhập mới, v.v.).
• Giảm chi phí bảo dưỡng dài hạn của giao thức.
• Giảm thiểu rủi ro của các lỗ hổng thảm họa, cho dù là trong các đặc tảng giao thức hay mã lập trình thực thi; điều này cũng làm cho việc xác minh rằng giao thức không chứa các lỗ hổng như vậy trở nên dễ dàng hơn.
• Giảm bề mặt tấn công xã hội: càng ít thành phần, càng ít nơi có thể bị khai thác và kiểm soát bởi các bên liên quan cụ thể.

Trong quá khứ, Ethereum đã không hoạt động tốt trong lĩnh vực này (đôi khi thậm chí là do quyết định cá nhân của tôi), điều này đã dẫn đến chi phí phát triển quá mức của chúng tôi,@vbuterin/selfdestruct”>Các rủi ro an ninh khác nhau và tính đóng cửa của văn hóa nghiên cứu và phát triển, và những nỗ lực này thường chỉ mang lại lợi nhuận ảo tưởng.
Bài viết này sẽ giải thích cách Ethereum có thể đạt được một mức độ đơn giản gần với Bitcoin trong vòng năm năm tới.

Lớp Ủy quyền Đơn giản

3-slot finality（3槽终结性）模拟图 —3sf-mini

Thiết kế tầng đồng thuận mới (trước đây được biết đến với tên gọi 'beam chain') nhằm tích hợp những kinh nghiệm mà chúng tôi đã tích luỹ trong lý thuyết đồng thuận, phát triển ZK-SNARK, kinh tế đặt cược và các lĩnh vực khác trong thập kỷ qua, để tạo ra một tầng đồng thuận Ethereum lý tưởng dài hạn. Tầng đồng thuận mới này, so với Beacon Chain hiện tại, dự kiến sẽ đạt được tính đơn giản cao hơn. Điều này đặc biệt rõ ràng trong:

• 3-khe cắm cấu trúc cuối cùng
  Bản thiết kế này loại bỏ sự phân biệt giữa 'khe cắm' và 'kỷ nguyên', việc xáo trộn ủy ban, và chi tiết cụ thể của giao thức liên quan đến các cơ chế này (như các ủy ban đồng bộ). Một phiên bản cơ bản của việc xác nhận 3 khe cắm,Chỉ cần khoảng 200 dòng mã là cần thiếtĐiều này có thể đạt được. So với giao thức Gasper hiện tại, tính cuối cùng 3 khe cũng gần như có độ bảo mật tối ưu.
• Số lượng các nhà xác thực hoạt động đã giảm
  Giúp việc lựa chọn fork đơn giản hơn và khả thi hơn.
• Giao thức tổng hợp dựa trên STARK
  Điều này có nghĩa là bất kỳ ai cũng có thể trở thành một người tổng hợp mà không cần lo lắng về việc tin tưởng vào người tổng hợp, phí quá mức cho các trường bit lặp đi lặp lại, v.v. Mặc dù việc mã hóa tổng hợp có một số độ phức tạp nhất định, điều nàyĐộ phức tạp cao được đóng gói chặt chẽRủi ro hệ thống tổng thể của giao thức thấp hơn nhiều.
• Hai điểm trên cũng có khả năng hỗ trợ một kiến trúc ngang hàng (p2p) đơn giản và mạnh mẽ hơn.
• Chúng tôi có cơ hội để suy nghĩ lại các cơ chế về việc nhập, thoát, rút tiền, chuyển đổi khóa, phạt động lượng, vv., và đơn giản hóa chúng— không chỉ là giảm số dòng mã (LoC), mà còn cung cấp các cam kết cơ chế rõ ràng hơn, như một hạn chót 'khách quan yếu' rõ ràng hơn.

Ưu điểm của tầng đồng thuận là nó khá độc lập so với việc thực thi EVM, vì vậy chúng tôi có rất nhiều không gian để tiếp tục đẩy những cải tiến này đi lên.
Thách thức hơn là: làm thế nào để đạt được sự đơn giản hóa tương tự ở tầng thực thi.

Đơn giản hóa Lớp Thực thi

Độ phức tạp của Máy Ảo Ethereum (EVM) đang ngày càng tăng, và một phần lớn của sự phức tạp này đã được chứng minh là không cần thiết (thường cũng liên quan đến các quyết định cá nhân của tôi): chúng ta có một máy ảo 256-bit đã được tối ưu quá mức cho các dạng mật mã cụ thể, mà hiện đang dần bị lạc hậu; và một số hợp đồng đã được biên soạn trước quá tập trung vào rất ít trường hợp sử dụng duy nhất.

Cố gắng từ từ sửa những vấn đề thực tế này là không khả thi.Xóa @vbuterinLệnh SELFDESTRUCT tiêu thụ một lượng năng lượng lớn, nhưng kết quả lại bị hạn chế. Cuộc tranh luận gần đây về EOF (Định dạng Đối tượng EVM) càng chứng minh sự khó khăn trong việc thực hiện các thay đổi tương tự đối với máy ảo.

Do đó, như một phương án thay thế, gần đây tôi đã đề xuất một ý tưởng cực kỳ triệt để hơn: thay vì thực hiện các thay đổi tăng dần (nhưng vẫn phá hoại) để cải thiện 1,5 lần, việc chuyển đổi trực tiếp sang một máy ảo hoàn toàn mới, mạnh mẽ hơn và đơn giản hơn, với mục tiêu đạt được 100 lần cải thiện, sẽ tốt hơn. Giống như ‘The Merge’, chúng tôi giảm số lượng các biến đổi, nhưng mỗi cái đều mang tính quyết định. Cụ thể, tôi đề xuất thay thế EVM hiện tại bằng RISC-V (hoặc một máy ảo khác sẽ được sử dụng bởi ZK prover của Ethereum). Như vậy, chúng ta sẽ đạt được:

• Cải thiện hiệu suất đáng kể: vì hợp đồng thông minh có thể chạy trực tiếp trong trình chứng minh mà không cần chi phí phải thông qua trình thông dịch. Dữ liệu súc tích cho thấy rằng hiệu suất có thể được cải thiện hơn 100 lần trong nhiều tình huống.
• Tính đơn giản tuyệt đối: so với EVM, thông số kỹ thuật RISC-VCực kỳ đơn giản. Các giải pháp thay thế khác (như Cairo) cũng ngắn gọn tương tự.
• Kế thừa những lợi ích dự kiến của EOF: như phân đoạn mã, phân tích tĩnh thân thiện hơn, giới hạn dung lượng mã lớn hơn, v.v.
• Các nhà phát triển có nhiều lựa chọn hơn: Solidity và Vyper có thể được biên dịch sang phần backend máy ảo mới. Nếu chọn RISC-V, các nhà phát triển ngôn ngữ chính có thể dễ dàng di chuyển mã của họ.
• Đáng kể giảm cần thiết cho việc biên soạn trước: có thể chỉ giữ lại một vài hoạt động đường cong elip tối ưu hóa cao (mặc dù những hoạt động này sẽ không còn tồn tại khi máy tính lượng tử trở nên phổ biến).

Một nhược điểm chính của cách tiếp cận này là, khác với EOF (có thể triển khai ngay lập tức), máy ảo ảo mới mất nhiều thời gian hơn để có lợi ích cho các nhà phát triển. Để giảm nhẹ điều này, chúng ta có thể giới thiệu một số cải tiến EVM nhỏ nhưng có giá trị cao trong tương lai ngắn.Tăng giới hạn kích thước mã hợp đồng、Tăng cường chỉ thị DUP/SWAP17-32, v.v.)

Cuối cùng, điều này sẽ mang lại cho chúng tôi một máy ảo đơn giản hóa rất nhiều. Nhưng câu hỏi lớn nhất là: vấn đề với EVM hiện tại thì sao?

Chiến lược tương thích ngược với VM chuyển tiếp

Khi đơn giản hóa một cách có ý nghĩa (hoặc thậm chí chỉ cải thiện mà không thêm phức tạp) bất kỳ phần nào của Máy Ảo Ethereum (EVM), thách thức lớn nhất là: làm thế nào để duy trì tính tương thích ngược với các ứng dụng hiện có trong khi đạt được mục tiêu.

Trước hết, điều cần rõ ràng là không có một cách duy nhất để xác định phạm vi của “Ethereum codebase” (thậm chí trong cùng một client).

Mục tiêu là giảm thiểu phạm vi của khu vực xanh càng nhiều càng tốt: tức là logic mà các nút phải chạy để tham gia vào sự nhất trí Ethereum, bao gồm tính toán trạng thái hiện tại, bằng chứng, xác minh, FOCIL (Lớp tích hợp Nhất quán Bậc nhất), xây dựng khối cơ bản, v.v.

Khu vực màu cam không thể giảm: nếu một tính năng của lớp thực thi cụ thể (dù đó là máy ảo, trước biên soạn, hoặc cơ chế khác) được loại bỏ khỏi quy định giao thức, hoặc chức năng của nó bị thay đổi, người dùng liên quan đến việc xử lý các khối lịch sử vẫn phải giữ nó - nhưng quan trọng là, các người dùng mới (như ZK-EVMs hoặc bộ xác minh hình thức) có thể hoàn toàn bỏ qua khu vực màu cam.

Danh mục mới là khu vực màu vàng: loại mã này rất quan trọng để hiểu và phân tích trạng thái chuỗi hiện tại, và để xây dựng các khối tốt nhất, nhưng nó không phải là một phần của sự đồng thuận. Một ví dụ là Etherscan(And someBlock Builder) Hỗ trợ các hoạt động người dùng ERC-4337. Nếu chúng ta sử dụng triển khai RISC-V trên chuỗi thay thế một số hàm lớn của Ethereum (như tài khoản EOA và sự hỗ trợ của chúng cho các loại giao dịch cũ khác nhau), thì mặc dù mã đồng thuận đã được đơn giản hóa đáng kể, một số nút chuyên nghiệp vẫn có thể tiếp tục sử dụng mã nguồn gốc để phân tích các hàm này.

Quan trọng là các khu vực màu cam và màu vàng thuộc về “Gate”Phức tạp về bao bọcBất kỳ ai muốn hiểu giao thức đều có thể bỏ qua chúng, các client Ethereum cũng có thể chọn không triển khai chúng, và lỗi trong các khu vực này sẽ không gây ra nguy cơ đồng thuận. Điều này có nghĩa là độ phức tạp của mã và tác động tiêu cực do các khu vực màu cam và màu vàng mang lại ít hơn nhiều so với khu vực màu xanh.

Chuyển mã từ khu vực xanh sang khu vực vàng, phương pháp này tương tự như Apple Inc.Dịch qua lớp dịch RosettaĐể đảm bảo sự tương thích dài hạn.

Tôi đã đề xuất (mượn từ@ipsilon/eof-ethereums-gateway-to-risc-v”> Quan điểm gần đây của đội ngũ Ipsilon) Quá trình di trú máy ảo theo hình thức sau (sử dụng di trú EVM sang RISC-V như một ví dụ, nhưng cũng có thể áp dụng cho di trú EVM sang Cairo, và thậm chí di trú trong tương lai sang một máy ảo tối ưu hơn):

1. Tất cả các bản dịch mới phải được viết theo cách thức chuẩn trên chuỗi RISC-V, để hệ sinh thái có thể bắt đầu làm quen và sử dụng RISC-V như máy ảo.
2. Giới thiệu RISC-V như một lựa chọn cho việc phát triển hợp đồng song song với EVM cho các nhà phát triển. Giao thức hỗ trợ cả RISC-V và EVM một cách tự nhiên, cho phép các hợp đồng được viết bằng cả hai ngôn ngữ tương tác một cách tự do.
3. Thay thế tất cả các bản biên dịch trước (ngoại trừ các phép toán đường cong elip và KECCAK) bằng việc triển khai RISC-V. Chúng tôi loại bỏ những bản biên dịch trước này thông qua một hard fork và đồng thời thay đổi mã tại địa chỉ tương ứng (theo kiểu hard fork của DAO) để trở thành một triển khai RISC-V. Bởi vì Máy ảo RISC-V rất ngắn gọn, ngay cả việc làm này cũng giúp đơn giản hóa cấu trúc tổng thể.
4. Triển khai một trình thông dịch EVM được viết bằng RISC-V và triển khai nó như một hợp đồng thông minh trên chuỗi. Sau vài năm kể từ khi phát hành ban đầu, các hợp đồng EVM hiện có sẽ được xử lý thông qua trình thông dịch này.

Sau khi hoàn thành bước 4, vẫn sẽ có nhiều ‘EVM implementations’ tiếp tục được sử dụng để tối ưu hóa xây dựng khối, công cụ phát triển và phân tích trên chuỗi, nhưng chúng sẽ không còn là một phần của các đặc tả đồng thuận chính. Lúc đó, đồng thuận Ethereum sẽ ‘tự nhiên’ chỉ hiểu RISC-V.

Đơn giản hóa bằng cách chia sẻ các thành phần giao thức

Phương pháp đơn giản hóa thứ ba, và có lẽ là phương pháp bị đánh giá thấp nhất, là chia sẻ một tiêu chuẩn thống nhất trên các phần khác nhau của ngăn xếp giao thức càng nhiều càng tốt. Thông thường, không có lý do gì để sử dụng các giao thức khác nhau cho cùng một mục đích trong các tình huống khác nhau, nhưng tình huống này vẫn diễn ra thường xuyên trong thực tế, chủ yếu do thiếu giao tiếp giữa các phần khác nhau của lộ trình giao thức. Dưới đây là một số ví dụ cụ thể về việc đơn giản hóa Ethereum thông qua việc 'tối đa hóa việc chia sẻ thành phần'.

Mã xóa thống nhất

Chúng ta cần sửa mã xóa trong ba tình huống:

• Kiểm tra sẵn sàng dữ liệu - Khách hàng xác minh xem khối đã được xuất bản
• Phát sóng P2P nhanh hơn - Các nút có thể chấp nhận các khối sau khi nhận được n/2 trong số n khối, do đó thiết lập sự cân bằng lý tưởng giữa việc giảm độ trễ và dư thừa.
• Lưu trữ Lịch sử Phân phối - Mỗi phần lịch sử của Ethereum được lưu trữ trong nhiều khối, vì vậy (i) những khối này có thể được xác minh độc lập, và (ii) một nửa số khối trong mỗi nhóm có thể khôi phục nửa còn lại, giảm thiểu đáng kể nguy cơ mất mát của bất kỳ khối nào.

Nếu chúng tôi sử dụng cùng một mã xóa (dù đó là mã Reed-Solomon, mã tuyến tính ngẫu nhiên, hoặc mã khác) trong ba trường hợp sử dụng, chúng tôi sẽ đạt được một số lợi ích quan trọng:

1. Giảm tổng số dòng code
2. Nâng cao hiệu quả vì nếu mỗi nút phải tải về các phần khác nhau của một khối cho một trường hợp sử dụng (thay vì toàn bộ khối), dữ liệu có thể được sử dụng cho một trường hợp khác
3. Đảm bảo tính xác thực: Tất cả ba khối trong ngữ cảnh có thể được xác minh dựa trên gốc

Nếu thực sự cần mã sửa lỗi khác nhau, ‘tương thích’ ít nhất cũng nên được đảm bảo: ví dụ, trong kịch bản DAS, Reed-Solomon được sử dụng theo chiều ngang và mã tuyến tính ngẫu nhiên được sử dụng theo chiều dọc, nhưng cả hai đều dựa trên cùng một trường toán học.

Một định dạng chuỗi hóa thống nhất

Hiện tại, định dạng chuỗi hóa của Ethereum nói cách khác chỉ là “bán chuẩn” mà thôi, vì dữ liệu có thể được chuỗi hóa lại và phát sóng dưới bất kỳ định dạng nào. Điều duy nhất phải tuân thủ là băm chữ ký giao dịch, nơi cần có một định dạng chuẩn cho việc tính toán băm.
Nhưng tiêu chuẩn hóa định dạng tuần tự trong tương lai sẽ được cải thiện thêm, với hai lý do:

• Tính năng Tóm Tắt Tài Khoản Toàn Diện (EIP-7701): Máy ảo sẽ có thể xem nội dung giao dịch toàn bộ
• Tăng giới hạn gas: Dữ liệu khối thực thi cần được đóng gói thành blob

Lúc đó, chúng tôi có cơ hội để thống nhất các giải pháp serialization cần thiết cho ba khía cạnh hiện tại: 1) lớp thực thi; 2) lớp đồng thuận; 3) gọi hợp đồng thông minh ABI.

Tôi đề xuất áp dụng SSZ(Simple Serialize), vì SSZ có những ưu điểm sau:

• Dễ giải mã: bao gồm bên trong hợp đồng thông minh (dựa trên thiết kế 4 byte, vài trường hợp ranh giới)
• Phổ biến trong sự đồng thuận
• Rất giống với ABI hiện có: chi phí di cư công cụ thấp

Hiện tại đã có thêm các thành phần đượcDi trúĐến SSZCông việcKhi lập kế hoạch cho việc nâng cấp trong tương lai, chúng ta nên xem xét và tận dụng đầy đủ những phát triển này.

Một cấu trúc cây thống nhất

Khi chúng ta di dời từ EVM sang RISC-V (hoặc bất kỳ VM tối giản nào khác), cây Merkle Patricia thập lục phân sẽ trở thành rào cản lớn nhất trong việc chứng minh thực thi khối, ngay cả trong các trường hợp trung bình. Di dời sang một hàm bămCây nhị phân, sẽ cải thiện đáng kể hiệu suất của bộ xác minh và giảm chi phí dữ liệu của các nút nhẹ và các tình huống khác.

Khi hoàn thành việc di trú cấu trúc cây, chúng ta cũng nên đảm bảo rằng tầng đồng thuận sử dụng cùng cấu trúc cây để đảm bảo rằng toàn bộ Ethereum - cả hai tầng đồng thuận và thực thi - có thể được truy cập và phân tích bằng cùng một bộ mã.

Từ bây giờ đến tương lai

Đơn giản hóa và phi tập trung có nhiều điểm tương đồng. Cả hai đều là những yêu cầu thượng nguồn cần thiết để đạt được mục tiêu cao hơn là khả năng phục hồi của hệ thống. Nhấn mạnh sự đơn giản hóa rõ ràng đòi hỏi một sự thay đổi văn hóa. Lợi ích của việc đơn giản hóa thường khó thấy trong giai đoạn đầu, nhưng chi phí cơ hội và khối lượng công việc bổ sung của việc từ chối những "tính năng mới sáng bóng" đó là rõ ràng ngay lập tức. Tuy nhiên, theo thời gian, giá trị dài hạn của việc đơn giản hóa ngày càng trở nên rõ ràng — bản thân Bitcoin là một ví dụ tuyệt vời.

Tôi đề xuất chúng taHọc hỏi từ cách tiếp cận của tinygradĐể đặt mục tiêu rõ ràng về số dòng mã cho đặc tả dài hạn của Ethereum, mục tiêu là làm cho mã quyết định của Ethereum gần như mô phỏng phong cách tối giản của Bitcoin. Mã xử lý các quy tắc lịch sử của Ethereum vẫn sẽ tồn tại nhưng nên được cô lập khỏi đường dẫn quyết định quan trọng của hệ thống. Đồng thời, chúng ta nên hình thành một nguyên lý thiết kế phổ quát: chọn các giải pháp đơn giản hơn khi có thể, ưu tiên tích hợp phức tạp hơn so với phức tạp hệ thống, và hướng đến các quyết định thiết kế cung cấp các thuộc tính và cam kết rõ ràng có thể xác minh.

Miễn trừ trách nhiệm:

1. Bài viết này được sao chép từ [vitalik]. Tất cả bản quyền thuộc về tác giả gốc [ vitalikTất cả. Nếu bạn có bất kỳ ý kiến phản đối nào về việc tái bản này, vui lòng liên hệHọc cửaNhóm sẽ xử lý nó đúng thời điểm.
2. Khuyến nghị: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Đội ngũ Gate Learn dịch bài viết sang các ngôn ngữ khác. Việc sao chép, phân phối hoặc đạo văn bản dịch là cấm trừ khi có quy định khác.