Vitalik: Làm thế nào để biến Ethereum trở nên đơn giản như Bitcoin trong 5 năm

Tác giả: Vitalik Buterin; Người dịch: GaryMa Wu nói về Blockchain

Tóm tắt

Ethereum đặt mục tiêu trở thành sổ cái toàn cầu, đòi hỏi khả năng mở rộng và phục hồi. Bài viết này tập trung vào tầm quan trọng của sự đơn giản hóa giao thức và đề xuất giảm đáng kể độ phức tạp, chi phí phát triển, rủi ro lỗi và bề mặt tấn công bằng cách đơn giản hóa lớp đồng thuận (tính cuối cùng 3 khe, tổng hợp STARK) và lớp thực thi (thay thế EVM bằng RISC-V hoặc các máy ảo tương tự). Nên thực hiện quá trình chuyển đổi trơn tru hơn thông qua các chiến lược tương thích ngược (như trình thông dịch EVM trên chuỗi) và thống nhất mã xóa, định dạng tuần tự hóa (SSZ) và cấu trúc cây để đơn giản hóa hơn nữa. Mục tiêu là làm cho mã quan trọng đối với sự đồng thuận của Ethereum gần giống với sự đơn giản của Bitcoin, cải thiện khả năng phục hồi và sự tham gia, đồng thời yêu cầu một nền văn hóa coi trọng sự đơn giản và đặt ra mục tiêu về số dòng mã tối đa.

Mục tiêu của Ethereum là trở thành sổ cái toàn cầu: một nền tảng lưu trữ tài sản và hồ sơ của nền văn minh nhân loại, phục vụ cho các lĩnh vực tài chính, quản trị và xác thực dữ liệu có giá trị cao. Điều này đòi hỏi sự hỗ trợ ở hai khía cạnh: khả năng mở rộng và khả năng phục hồi. Bản hard fork Fusaka có kế hoạch tăng không gian dành cho dữ liệu L2 lên 10 lần và lộ trình hiện tại được đề xuất đến năm 2026 cũng có kế hoạch mang lại những cải tiến lớn tương tự cho lớp L1. Đồng thời, Ethereum đã hoàn tất quá trình chuyển đổi sang Proof of Stake (PoS), tính đa dạng của khách hàng đã tăng lên nhanh chóng, xác minh không kiến ​​thức (ZK) và nghiên cứu về khả năng chống lượng tử cũng đang tiến triển ổn định và hệ sinh thái ứng dụng đang ngày càng trở nên mạnh mẽ.

Bài viết này tập trung vào một yếu tố quan trọng không kém nhưng lại bị đánh giá thấp là khả năng phục hồi (và thậm chí là khả năng mở rộng):

tính đơn giản của giao thức.

Điều tuyệt vời nhất về giao thức Bitcoin là sự đơn giản thanh lịch của nó:

1. Có một chuỗi các khối, mỗi khối được kết nối với khối trước đó thông qua hàm băm.

2. Tính hợp lệ của khối được xác minh bằng Bằng chứng công việc (PoW), nhằm kiểm tra xem một vài chữ số đầu tiên của giá trị băm có bằng 0 hay không.

3. Mỗi khối chứa các giao dịch và số tiền được chi tiêu trong các giao dịch này có thể đến từ phần thưởng khai thác hoặc từ các giao dịch trước đó.

Vậy là xong! Ngay cả một học sinh trung học thông minh cũng có thể hiểu đầy đủ cách thức hoạt động của giao thức Bitcoin và một lập trình viên thậm chí có thể viết một ứng dụng khách như một dự án phụ.

Tính đơn giản của giao thức mang lại nhiều lợi thế quan trọng cho Bitcoin (và Ethereum) như một lớp cơ sở toàn cầu trung lập, đáng tin cậy:

1. Dễ hiểu : Giảm độ phức tạp của giao thức, cho phép nhiều người tham gia vào nghiên cứu, phát triển và quản lý giao thức hơn, đồng thời giảm nguy cơ thống trị của nhóm tinh hoa kỹ thuật.

2. Giảm chi phí phát triển: Việc đơn giản hóa giao thức giúp giảm đáng kể chi phí tạo cơ sở hạ tầng mới (như máy khách mới, công cụ chứng minh, công cụ dành cho nhà phát triển, v.v.).

3. Giảm gánh nặng bảo trì: Giảm chi phí bảo trì theo thỏa thuận dài hạn. 4. Giảm nguy cơ lỗi: Giảm khả năng xảy ra lỗi nghiêm trọng trong thông số kỹ thuật và triển khai giao thức, đồng thời tạo điều kiện xác minh rằng các lỗi đó không tồn tại.

5. Giảm bề mặt tấn công: Giảm các thành phần phức tạp của giao thức và giảm nguy cơ bị tấn công bởi các nhóm lợi ích đặc biệt.

Theo truyền thống, Ethereum (và đôi khi là do quyết định cá nhân của tôi) thường không giữ được sự đơn giản, dẫn đến chi phí phát triển quá mức, rủi ro bảo mật tăng cao và văn hóa R&D khép kín, nơi mà lợi ích từ việc theo đuổi những điều phức tạp này thường chỉ là ảo tưởng. Bài viết này sẽ khám phá cách Ethereum, năm năm sau, tiếp cận sự đơn giản của Bitcoin.

Lớp đồng thuận được đơn giản hóa

Thiết kế lớp đồng thuận mới (trước đây gọi là "chuỗi đèn hiệu") nhằm mục đích tận dụng kinh nghiệm trong thập kỷ qua về lý thuyết đồng thuận, phát triển ZK-SNARK, kinh tế học staking và các lĩnh vực khác để xây dựng một lớp đồng thuận tối ưu và đơn giản hơn trong dài hạn. So với chuỗi beacon hiện tại, thiết kế mới được đơn giản hóa đáng kể: 1. Thiết kế cuối cùng 3 khe: loại bỏ các khái niệm như khe, kỷ nguyên, tổ chức lại ủy ban và các cơ chế xử lý hiệu quả liên quan (như ủy ban đồng bộ hóa). Việc triển khai cơ bản tính năng cuối cùng 3 khe cắm chỉ cần khoảng 200 dòng mã và có tính bảo mật gần như tối ưu so với Gasper.

2. Giảm số lượng trình xác thực đang hoạt động: Cho phép sử dụng các triển khai quy tắc lựa chọn nhánh đơn giản hơn và tăng cường bảo mật.

3. Giao thức tổng hợp dựa trên STARK: Bất kỳ ai cũng có thể trở thành người tổng hợp mà không cần phải tin tưởng người tổng hợp hoặc trả phí cao cho các trường bit trùng lặp. Mã hóa tổng hợp có mức độ phức tạp cao hơn, nhưng độ phức tạp của nó được đóng gói chặt chẽ và rủi ro hệ thống thấp hơn.

4. Đơn giản hóa kiến ​​trúc P2P: Các yếu tố trên có thể hỗ trợ kiến ​​trúc mạng ngang hàng đơn giản và mạnh mẽ hơn.

5. Thiết kế lại cơ chế xác minh: bao gồm nhập, thoát, rút, chuyển đổi khóa, rò rỉ không hoạt động và các cơ chế khác, đơn giản hóa số dòng mã và cung cấp các đảm bảo rõ ràng hơn (chẳng hạn như chu kỳ chủ quan yếu).

Ưu điểm của lớp đồng thuận là nó tương đối độc lập với lớp thực thi EVM, do đó có nhiều chỗ để cải tiến liên tục. Thách thức lớn hơn là đạt được sự đơn giản hóa tương tự ở cấp độ thực hiện.

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

EVM ngày càng phức tạp hơn và phần lớn sự phức tạp đó tỏ ra không cần thiết (một phần là do những quyết định kém cỏi của chính tôi): VM 256 bit đã được tối ưu hóa quá mức cho một dạng mật mã cụ thể hiện đang ngày càng lỗi thời và các bản biên dịch trước đã được tối ưu hóa cho một trường hợp sử dụng duy nhất nhưng hiếm khi được sử dụng.

Giải quyết từng vấn đề một sẽ có hiệu quả hạn chế. Ví dụ, việc xóa mã lệnh SELFDESTRUCT là một nỗ lực rất lớn nhưng lại mang lại rất ít lợi ích. Cuộc tranh luận gần đây về EOF (Định dạng đối tượng EVM) cũng cho thấy những thách thức tương tự.

Gần đây tôi đã đề xuất một giải pháp triệt để hơn: thay vì thực hiện những thay đổi ở mức độ vừa phải (nhưng vẫn gây gián đoạn) đối với EVM để đổi lấy lợi ích gấp 1,5 lần, chúng ta có thể chuyển sang VM tốt hơn, đơn giản hơn và đạt được lợi ích gấp 100 lần. Tương tự như The Merge, chúng tôi giảm số lượng thay đổi đột ngột nhưng làm cho mỗi thay đổi có ý nghĩa hơn. Cụ thể hơn, tôi đề xuất thay thế EVM bằng RISC-V hoặc một máy ảo khác được trình chứng minh Ethereum ZK sử dụng. Điều này sẽ mang lại:

1. Hiệu quả được cải thiện đáng kể: Việc thực hiện hợp đồng thông minh (trong trình chứng minh) không yêu cầu thông dịch viên và chạy trực tiếp. Dữ liệu của Succinct cho thấy hiệu suất có thể được cải thiện hơn 100 lần trong nhiều trường hợp.

2. Cải thiện đáng kể về tính đơn giản: Đặc tả RISC-V cực kỳ đơn giản so với EVM và các giải pháp thay thế (như Cairo) cũng đơn giản không kém.

3. Động lực hỗ trợ EOF: chẳng hạn như phân vùng mã, phân tích tĩnh thân thiện hơn, giới hạn kích thước mã lớn hơn, v.v.

4. Nhiều lựa chọn hơn cho nhà phát triển: Solidity và Vyper có thể thêm chương trình phụ trợ để biên dịch sang máy ảo mới. Nếu bạn chọn RISC-V, các nhà phát triển ngôn ngữ chính thống cũng có thể dễ dàng chuyển mã của họ sang máy ảo này. 5. Xóa bỏ hầu hết biên dịch trước: có lẽ chỉ các hoạt động đường cong elip được tối ưu hóa cao mới được giữ lại (ngay cả những hoạt động này cũng sẽ biến mất sau khi máy tính lượng tử trở nên phổ biến).

Nhược điểm chính là, không giống như EOF sẵn sàng sử dụng, các lợi ích của VM mới mất nhiều thời gian hơn để các nhà phát triển có thể tận dụng. Chúng ta có thể giảm thiểu vấn đề này bằng cách triển khai các cải tiến EVM có giá trị cao trong ngắn hạn (chẳng hạn như tăng giới hạn quy mô mã hợp đồng và hỗ trợ DUP/SWAP17–32).

Điều này sẽ tạo ra một máy ảo đơn giản hơn. Thách thức cốt lõi là: làm thế nào để giải quyết EVM hiện tại?

Chiến lược tương thích ngược cho quá trình chuyển đổi máy ảo

Thách thức lớn nhất trong việc đơn giản hóa (hoặc cải thiện mà không làm tăng độ phức tạp) EVM là làm thế nào để cân bằng giữa việc triển khai mục tiêu với khả năng tương thích ngược của các ứng dụng hiện có.

Trước hết, cần phải làm rõ: cơ sở mã Ethereum (kể cả trong một máy khách duy nhất) không được định nghĩa theo một cách duy nhất.

Mục tiêu là giảm thiểukhu vực xanh: logic cần thiết để các nút tham gia vào sự đồng thuận của Ethereum, bao gồm tính toán trạng thái hiện tại, bằng chứng, xác minh, FOCIL (quy tắc lựa chọn nhánh) và xây dựng khối "bình thường".

Vùng màu camKhông thể giảm: Nếu thông số kỹ thuật giao thức xóa hoặc thay đổi chức năng của lớp thực thi (chẳng hạn như máy ảo, biên dịch trước, v.v.), thì máy khách xử lý các khối lịch sử vẫn cần giữ nguyên mã có liên quan. Nhưng khách hàng mới, ZK-EVM hoặc người chứng minh chính thức có thể hoàn toàn bỏ qua vùng màu cam.

Vùng màu vàng mới được thêm vào: Rất có giá trị để hiểu chuỗi hiện tại hoặc tối ưu hóa cấu trúc khối, nhưng không thuộc về logic đồng thuận. Ví dụ, Etherscan và một số trình xây dựng khối hỗ trợ các hoạt động của người dùng ERC-4337. Nếu chúng ta thay thế một số chức năng của Ethereum (như EOA và các loại giao dịch cũ mà nó hỗ trợ) bằng các triển khai RISC-V trên chuỗi, mã đồng thuận sẽ được đơn giản hóa đáng kể, nhưng các nút chuyên dụng có thể tiếp tục sử dụng mã gốc để phân tích cú pháp.

Độ phức tạp trong các vùng màu cam và vàng là độ phức tạp đóng gói. Những người hiểu giao thức có thể bỏ qua những phần này và việc triển khai Ethereum có thể bỏ qua chúng. Lỗi trong những lĩnh vực này sẽ không gây ra rủi ro về sự đồng thuận. Do đó, độ phức tạp của mã trong vùng màu cam và vàng ít gây hại hơn nhiều so với độ phức tạp trong vùng màu xanh lá cây.

Ý tưởng di chuyển mã từ vùng màu xanh lá cây sang vùng màu vàng tương tự như chiến lược của Apple nhằm đảm bảo khả năng tương thích ngược lâu dài thông qua lớp dịch Rosetta.

Lấy cảm hứng từ bài viết gần đây của nhóm Ipsilon, tôi đề xuất quy trình thay đổi máy ảo sau (lấy EVM sang RISC-V làm ví dụ, nhưng cũng có thể sử dụng cho EVM sang Cairo hoặc RISC-V sang máy ảo tốt hơn):

1. Yêu cầu biên dịch trước mới để cung cấp triển khai RISC-V trên chuỗi: Để hệ sinh thái dần thích ứng với máy ảo RISC-V.

2. Giới thiệu RISC-V như một tùy chọn dành cho nhà phát triển: Giao thức hỗ trợ cả RISC-V và EVM, và các hợp đồng của hai máy ảo có thể tương tác tự do.

3. Thay thế hầu hết các biên dịch trước: Ngoại trừ các phép toán đường cong elip và KECCAK (vì cần tốc độ cực cao), hãy thay thế các biên dịch trước khác bằng các triển khai RISC-V. Bản biên dịch trước đã được xóa thông qua một hard fork và mã tại địa chỉ đó (tương tự như fork DAO) đã được thay đổi từ không có gì thành một bản triển khai RISC-V. Máy ảo RISC-V cực kỳ đơn giản và việc dừng lại ở đây chỉ đơn giản hóa giao thức mà thôi.

4. Triển khai trình thông dịch EVM trong RISC-V: Trên chuỗi như một hợp đồng thông minh (đã thực hiện do yêu cầu về trình chứng minh ZK). Nhiều năm sau khi phát hành lần đầu, các hợp đồng EVM hiện tại sẽ được chạy thông qua trình thông dịch này.

Sau khi hoàn tất bước 4, nhiều "triển khai EVM" vẫn sẽ được sử dụng để tối ưu hóa việc xây dựng khối, công cụ dành cho nhà phát triển và phân tích chuỗi, nhưng sẽ không còn là một phần của thông số kỹ thuật đồng thuận chính. Sự đồng thuận của Ethereum "bản chất" chỉ hiểu được RISC-V.

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

Cách thứ ba để giảm độ phức tạp tổng thể của giao thức (và cũng là cách bị đánh giá thấp nhất) là chia sẻ các tiêu chuẩn thống nhất ở 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, việc các giao thức khác nhau thực hiện cùng một việc trong các bối cảnh khác nhau sẽ không có ích, nhưng tình trạng này vẫn xảy ra thường xuyên, chủ yếu là do thiếu sự giao tiếp giữa các phần khác nhau của lộ trình giao thức. Sau đây là một số ví dụ cụ thể về việc đơn giản hóa Ethereum thông qua các thành phần được chia sẻ.

Mã xóa thống nhất

Chúng ta cần mã xóa trong ba trường hợp:

1. Lấy mẫu tính khả dụng của dữ liệu: Máy khách xác minh rằng khối đã được công bố.

2. Phát sóng P2P nhanh hơn: Một nút có thể chấp nhận một khối sau khi nhận được n/2 phân đoạn, đạt được sự cân bằng giữa độ trễ và tính dự phòng.

3. Lưu trữ lịch sử phân tán: Dữ liệu lịch sử Ethereum được lưu trữ trong các phân đoạn và mỗi nhóm n/2 phân đoạn có thể khôi phục các phân đoạn còn lại, giúp giảm nguy cơ mất một phân đoạn duy nhất.

Nếu cùng một mã xóa (cho dù là Reed-Solomon, mã tuyến tính ngẫu nhiên, v.v.) được sử dụng trong ba trường hợp, sẽ thu được những lợi thế sau:

1. Giảm thiểu số lượng mã : Giảm tổng số dòng mã.

2. Cải thiện hiệu quả: Nếu một nút tải xuống một phần các đoạn mã cho một cảnh nhất định, dữ liệu này có thể được sử dụng cho các cảnh khác. 3. Đảm bảo khả năng xác minh: Tất cả các phân đoạn cảnh có thể được xác minh so với gốc.

Nếu sử dụng các mã xóa khác nhau, ít nhất phải đảm bảo tính tương thích, ví dụ, mã Reed-Solomon ngang để lấy mẫu dữ liệu khả dụng và mã tuyến tính ngẫu nhiên dọc hoạt động trong cùng một miền.

Định dạng tuần tự hóa thống nhất

Định dạng tuần tự hóa của Ethereum hiện chỉ được củng cố một phần, vì dữ liệu có thể được tuần tự hóa lại và phát ở bất kỳ định dạng nào. Ngoại lệ là hàm băm chữ ký giao dịch, cần phải được băm theo định dạng chuẩn. Trong tương lai, việc củng cố định dạng tuần tự hóa sẽ được cải thiện hơn nữa vì những lý do sau: 1. Trừu tượng hóa toàn bộ tài khoản (EIP-7701): Toàn bộ nội dung của giao dịch đều có thể nhìn thấy được trên máy ảo.

2. Giới hạn Gas cao hơn: Dữ liệu lớp thực thi phải được đặt trong các khối dữ liệu (blob).

Khi đó, chúng ta sẽ có cơ hội thống nhất các định dạng tuần tự hóa của ba cấp độ Ethereum: lớp thực thi, lớp đồng thuận và lệnh gọi hợp đồng thông minh ABI.

Tôi đề xuất sử dụng  SSZvì SSZ:

1. Dễ giải mã: được bao gồm trong các hợp đồng thông minh (do thiết kế dựa trên 4 byte và ít trường hợp ngoại lệ).

2. Nó đã được sử dụng rộng rãi trong lớp đồng thuận.

3. Rất giống với ABI hiện tại: việc điều chỉnh công cụ tương đối đơn giản.

Đang có những nỗ lực nhằm di chuyển hoàn toàn sang SSZ và chúng ta nên cân nhắc và tiếp tục những nỗ lực này khi lập kế hoạch nâng cấp trong tương lai.

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

Nếu di chuyển từ EVM sang RISC-V (hoặc máy ảo tối thiểu tùy chọn khác), cây Merkle Patricia thập lục phân sẽ trở thành nút thắt cổ chai lớn nhất đối với việc thực thi khối chứng minh, ngay cả trong trường hợp trung bình. Việc di chuyển sang cây nhị phân dựa trên hàm băm tốt hơn sẽ cải thiện đáng kể hiệu quả của trình chứng minh đồng thời giảm chi phí dữ liệu trong các tình huống như máy khách nhẹ.

Khi di chuyển, bạn phải đảm bảo rằng lớp đồng thuận sử dụng cùng một cấu trúc cây. Điều này sẽ làm cho lớp đồng thuận và lớp thực thi của Ethereum có thể truy cập và phân tích được thông qua cùng một mã.

Từ hiện tại đến tương lai

Sự đơn giản tương tự như phân cấp theo nhiều cách và cả hai đều hướng đến mục tiêu phục hồi. Việc đề cao tính đơn giản một cách rõ ràng đòi hỏi một sự thay đổi văn hóa nhất định. Lợi ích thường khó định lượng, trong khi chi phí cho nỗ lực bổ sung và từ bỏ một số tính năng thú vị lại có thể thấy ngay lập tức. Tuy nhiên, theo thời gian, những lợi ích ngày càng trở nên đáng kể hơn - ví dụ hoàn hảo nhất chính là Bitcoin.

Tôi đề xuất làm theo tinygrad và đặt ra mục tiêu rõ ràng về số dòng mã tối đacho thông số kỹ thuật dài hạn của Ethereum, đưa mã quan trọng đối với sự đồng thuận của Ethereum gần với sự đơn giản của Bitcoin. Mã xử lý các quy tắc lịch sử của Ethereum sẽ tiếp tục tồn tại nhưng phải được đặt bên ngoài đường dẫn quan trọng của sự đồng thuận. Đồng thời, chúng ta nên duy trì triết lý lựa chọn giải pháp đơn giản hơn, ưu tiên sự phức tạp của việc đóng gói hơn là sự phức tạp của hệ thống và đưa ra những lựa chọn thiết kế cung cấp các thuộc tính và đảm bảo rõ ràng.