bản tóm tắt
Ethereum hướng tới mục tiêu trở thành sổ cái toàn cầu, đòi hỏi 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ự). Nên thực hiện chuyển đổi suôn sẻ thông qua các chiến lược tương thích ngược (như trình thông dịch EVM 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 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: mở rộng và khả năng phục hồi. Hard fork Fusaka được lên kế hoạch sẽ tăng không gian dành cho dữ liệu L2 lên 10 lần và lộ trình năm 2026 hiện đang được đề xuất 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 Bằng chứng cổ phần(PoS), tính đa dạng máy trạm đã 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 thường bị đánh giá thấp về khả năng phục hồi (và 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 tinh tế 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), kiểm tra xem một vài chữ số đầu tiên của giá trị băm có bằng không hay không.
3. Mỗi khối chứa các giao dịch và số tiền được chi cho 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 thôi! 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 máy trạm như một dự án phụ. Tính đơn giản của giao thức mang lại một số lợi thế quan trọng cho Bitcoin(và Ethereum) như một lớp cơ sở toàn cầu đáng tin cậy, trung lập:
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 trị giao thức hơn, đồng thời giảm rủi ro bị nhóm tinh hoa kỹ thuật thống trị.
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 trạm, Prover, công cụ dành cho nhà phát triển, v.v. mới).
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 rủi ro 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 rủi ro bị tấn công bởi các nhóm lợi ích đặc biệt.
Lịch sử, Ethereum(và đôi khi là do quyết định của riêng 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 phát triển khép kín, tất cả đều nhằm theo đuổi sự phức tạp mà thường chỉ mang lại lợi nhuận ả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.
Đơn giản hóa lớp đồng thuận
Thiết kế lớp đồng thuận mới (lịch sử gọi là "Beacon Chain") nhằm mục đích tận dụng kinh nghiệm của thập kỷ qua về 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 để 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 Beacon Chain hiện tại, thiết kế mới được đơn giản hóa đáng kể:
1. Thiết kế tính 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 triển khai quy tắc lựa chọn fork đơ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 vào 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 phức tạp hơn, nhưng tính 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. Kiến trúc P2P đơn giản hóa: 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 đả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 hiện
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 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 loại bỏ mã lệnh SELFDESTRUCT là một nỗ lực rất lớn nhưng chỉ mang lại lợi nhuận nhỏ. 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 cách tiếp cận triệt để hơn: thay vì thực hiện những thay đổi có quy mô vừa phải (nhưng vẫn gây gián đoạn) đối với EVM để đổi lấy lợi nhuận 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 nhuận 100 lần. Tương tự như The Merge, chúng tôi giảm số lượng thay đổi gây gián đoạn nhưng làm cho lần 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 Prover Ethereum ZK sử dụng. Điều này sẽ dẫn đến:
1. Hiệu quả được cải thiện đáng kể: Việc thực hiện hợp đồng thông minh (trong Prover) 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. Tính đơn giản được cải thiện đáng kể: Đặ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 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 có sẵn, lợi nhuận 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 thêm độ phức tạp) EVM là cân bằng giữa mục tiêu triển khai với khả năng tương thích ngược cho các ứng dụng hiện có.
Trước hết, chúng ta hãy làm rõ: không chỉ có một cách để định nghĩa cơ sở mã Ethereum(ngay cả trong một máy trạm duy nhất).
Mục tiêu là giảm thiểu vùng xanh : logic cần thiết để nút tham gia vào sự đồng thuận Ethereum, bao gồm tính toán trạng thái hiện tại, bằng chứng, xác thực, FOCIL (quy tắc lựa chọn fork ) và xây dựng khối "bình thường".
Không thể giảm vùng màu cam : 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 trạm xử lý các khối lịch sử vẫn phải giữ nguyên mã có liên quan. Nhưng máy trạm mới, ZK-EVM hoặc Prover chính thức có thể hoàn toàn bỏ qua vùng màu cam.
Các 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 việc xây dựng khối, nhưng không phải là một phần của 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 Ethereum nhất định (như EOA và các loại giao dịch cũ mà nó hỗ trợ) bằng các triển khai RISC-V Chuỗi , mã đồng thuận sẽ được đơn giản hóa đáng kể, nhưng 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 vùng màu cam và vàng là độ phức tạp của quá trình đóng gói . Những người hiểu giao thức có thể bỏ qua những phần này, việc triển khai Ethereum có thể bỏ qua chúng và các lỗi trong những phần này sẽ không gây ra rủi ro đồ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 đội ngũ Ipsilon, tôi đề xuất quy trình thay đổi VM 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 VM 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 Chuỗi: Cho phép 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 (do nhu cầu 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 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: Chuỗi như một hợp đồng thông minh (đã thực hiện do nhu cầu về Prover 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 bước 4 hoàn tất, 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 nữa. Sự đồng thuận Ethereum"bản chất" chỉ hiểu được RISC-V.
Đơn giản hóa thông qua các thành phần giao thức được chia sẻ
Cách thứ ba để giảm độ phức tạp chung 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 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, 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ã hóa 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 trạm xác minh rằng khối đã được công bố.
2. Phát sóng P2P nhanh hơn: 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 rủi ro mất một phân đoạn duy nhất.
Nếu sử dụng cùng một mã xóa (có thể là Reed-Solomon, mã tuyến tính ngẫu nhiên, v.v.) trong cả 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 nút tải xuống một phần đoạn mã cho một cảnh, dữ liệu này có thể được sử dụng trong các cảnh khác.
3. Đảm bảo khả năng xác minh: Tất cả các đoạn của cảnh đều có thể xác minh được 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, định dạng tuần tự hóa sẽ trở nên cố định hơn vì những lý do sau:
1. Trừu tượng hóa tài khoản(EIP-7701): Toàn bộ nội dung của giao dịch sẽ hiển thị trên máy ảo.
2. Giới hạn gas cao hơn: Dữ liệu lớp thực thi cần đượ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 lớ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 SSZ vì 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 có: việc điều chỉnh công cụ tương đối đơn giản.
Có những nỗ lực để 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ột số 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 lớn nhất đối với việc thực thi khối bằng chứng, 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ả Prover đồng thời giảm chi phí dữ liệu trong các tình huống như máy trạm 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ừ bây giờ đến tương lai
Sự đơn giản có nhiều điểm tương đồng với phi tập trung và cả hai đều hướng tới 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 nhuận 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, lợi nhuận trở nên đáng kể hơn — Bitcoin chính là ví dụ hoàn hảo về điều này.
Tôi đề xuất làm theo TinyGrad và đặt ra mục tiêu dòng mã tối đa rõ ràng cho các thông số kỹ thuật dài hạn Ethereum, đưa mã quan trọng đối với sự đồng thuận Ethereum gần với sự đơn giản của Bitcoin . Mã xử lý các quy tắc lịch sử 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.
Chào mừng bạn tham gia cộng đồng chính thức BlockBeats :
Nhóm đăng ký Telegram: https://t.me/theblockbeats
Nhóm Telegram: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
