Ethereum nhằm trở thành sổ cái toàn cầu, cần tính mở rộng và độ bền. Bài viết này tập trung vào tầm quan trọng của sự đơn giản trong giao thức, đề xuất giảm đáng kể độ phức tạp bằng cách đơn giản hóa lớp đồng thuận (tính cuối cùng 3-slot, STARK tổng hợp) và lớp thực thi (thay thế EVM bằng RISC-V hoặc máy ảo tương tự), giảm chi phí phát triển, rủi ro lỗi và bề mặt tấn công. Đề xuất chuyển tiếp mượt mà thông qua 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ã sửa lỗi, định dạng tuần tự (SSZ) và cấu trúc cây để đơn giản hóa thêm. Mục tiêu là đưa mã chính của đồng thuận Ethereum gần với sự đơn giản của Bitcoin, nâng cao độ bền và sự tham gia, cần coi trọng sự đơn giản về mặt văn hóa và thiết lập mục tiêu tối đa số dòng mã.
Mục tiêu của Ethereum là trở thành sổ cái toàn cầu: nền tảng lưu trữ tài sản và ghi chép 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ị, chứng nhận dữ liệu có giá trị cao, v.v. Điều này cần sự hỗ trợ từ hai khía cạnh: khả năng mở rộng và độ bền. Kế hoạch phân tách cứng Fusaka sẽ tăng gấp 10 lần không gian có sẵn cho dữ liệu L2, trong khi lộ trình dự kiến vào năm 2026 cũng lên kế hoạch mang lại sự cải thiện lớn tương tự cho lớp L1. Trong khi đó, Ethereum đã hoàn thành việc chuyển đổi sang chứng minh cổ phần (PoS), sự đa dạng của các khách hàng đang tăng nhanh, nghiên cứu xác minh không tri thức (ZK), khả năng kháng quantum cũng đang tiến triển vững chắc, hệ sinh thái ứng dụng ngày càng kiên cố.
Bài viết này nhằm tập trung vào một yếu tố quan trọng nhưng thường bị đánh giá thấp khác của độ bền (thậm chí là khả năng mở rộng): sự đơn giản của giao thức.
Điều ấn tượng nhất của giao thức Bitcoin là sự đơn giản thanh lịch của nó:
Có một chuỗi được cấu thành từ các khối, mỗi khối được liên kết với khối trước đó thông qua hàm băm.
Tính hợp lệ của khối được xác minh thông qua chứng minh công việc (PoW), tức là kiểm tra xem vài chữ số đầu của giá trị băm có phải là số không.
Mỗi khối chứa giao dịch, đồng tiền được sử dụng trong giao dịch đến từ phần thưởng khai thác hoặc từ đầu ra giao dịch trước đó.
Chỉ có vậy thôi! Ngay cả một học sinh trung học thông minh cũng có thể hoàn toàn hiểu 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 khách hàng như một dự án nghiệp dư.
Sự đơn giản của giao thức đã mang lại nhiều lợi thế quan trọng cho Bitcoin (và Ethereum) trở thành nền tảng toàn cầu đáng tin cậy và trung lập.
Dễ hiểu: Giảm độ phức tạp của giao thức, cho phép nhiều người tham gia nghiên cứu, phát triển và quản trị giao thức, giảm thiểu rủi ro do tầng lớp tinh hoa công nghệ thống trị.
Giảm chi phí phát triển: Đơn giản hóa giao thức làm giảm đáng kể chi phí tạo ra cơ sở hạ tầng mới (như khách hàng mới, trình chứng minh, công cụ phát triển, v.v.).
Giảm bớt gánh nặng bảo trì: Giảm chi phí bảo trì hợp đồng dài hạn.
Giảm thiểu rủi ro sai sót: Giảm khả năng xảy ra lỗi thảm khốc trong đặc tả và thực hiện giao thức, đồng thời dễ dàng xác minh rằng không có lỗi như vậy.
Thu hẹp bề mặt tấn công: Giảm bớt các thành phần phức tạp của giao thức, giảm rủi ro bị các nhóm lợi ích đặc biệt tấn công.
Trong lịch sử, Ethereum (đôi khi 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á cao, tăng rủi ro an ninh và tính chất khép kín trong văn hóa nghiên cứu và phát triển, trong khi lợi ích của sự phức tạp mà nó theo đuổi thường được chứng minh là hão huyền. Bài viết này sẽ khám phá Ethereum sau năm năm sẽ tiến gần đến sự đơn giản của Bitcoin như thế nào.
Lớp đồng thuận đơn giản
Thiết kế lớp đồng thuận mới (trong lịch sử được gọi là "chuỗi tín hiệu") nhằm mục đích tận dụng kinh nghiệm trong mười năm qua về lý thuyết đồng thuận, phát triển ZK-SNARK, kinh tế đặt cọc, v.v., để xây dựng một lớp đồng thuận tối ưu lâu dài và đơn giản hơn. So với chuỗi tín hiệu hiện tại, thiết kế mới đơn giản hóa đáng kể:
Thiết kế cuối cùng 3-slot: loại bỏ các khái niệm như slot, epoch, tái cấu trúc ủy ban, cùng với các cơ chế xử lý hiệu quả liên quan (như ủy ban đồng bộ). Việc triển khai cơ bản của tính cuối cùng 3-slot chỉ cần khoảng 200 dòng mã, và so với Gasper, độ an toàn gần như là tối ưu.
Giảm số lượng người xác thực hoạt động: Cho phép sử dụng quy tắc chọn nhánh đơn giản hơn để tăng cường tính bảo mật.
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, 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 lĩnh vực lặp lại. Độ phức tạp của mật mã tổng hợp khá cao, nhưng độ phức tạp của nó được đóng gói cao và rủi ro hệ thống thấp.
Đơn giản hóa kiến trúc P2P: Các yếu tố trên có thể hỗ trợ một kiến trúc mạng điểm-điểm đơn giản hơn và vững chắc hơn.
Thiết kế lại cơ chế xác thực: bao gồm các cơ chế như tham gia, rời bỏ, rút tiền, chuyển đổi khóa, rò rỉ không hoạt động, đơn giản hóa số lượng dòng mã và cung cấp các đảm bảo rõ ràng hơn (như chu kỳ chủ quan yếu).
Lợi thế 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ó không gian lớn để cải tiến liên tục. Thách thức lớn hơn là làm thế nào để đạt được sự đơn giản tương tự trong lớp thực thi.
Lớp thực thi đơn giản
Sự phức tạp của EVM ngày càng gia tăng, và nhiều yếu tố phức tạp đã được chứng minh là không cần thiết (một phần do quyết định sai lầm của cá nhân tôi): máy ảo 256 bit đã tối ưu hóa quá mức cho các hình thức mật mã cụ thể giờ đã dần trở nên lỗi thời, các bản biên soạn trước (precompiles) đượ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 có hiệu quả hạn chế. Ví dụ, việc loại bỏ mã vận hành SELFDESTRUCT tốn rất nhiều nỗ lực nhưng chỉ mang lại lợi ích 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 kế hoạch táo bạo hơn: thay vì thực hiện những thay đổi ở quy mô trung bình (nhưng vẫn có tính phá hoại) đối với EVM để đổi lấy lợi nhuận gấp 1,5 lần, tốt hơn là chuyển sang một máy ảo tốt hơn và đơn giản hơn để đạt được lợi nhuận gấp 100 lần. Tương tự như "Hợp nhất" (The Merge), chúng tôi giảm bớt số lần thay đổi mang tính phá hoại, nhưng làm cho mỗi lần thay đổi trở nên có ý nghĩa hơn. Cụ thể, tôi đề xuất thay thế EVM bằng RISC-V, hoặc một máy ảo khác được sử dụng bởi trình xác minh ZK của Ethereum. Điều này sẽ mang lại:
Hiệu suất được nâng cao đáng kể: Việc thực hiện hợp đồng thông minh (trong bộ chứng minh) không cần chi phí của trình thông dịch, mà chạy trực tiếp. Dữ liệu của Succinct cho thấy hiệu suất có thể tăng hơn 100 lần trong nhiều tình huống.
Cải tiến đơn giản hóa đáng kể: Tiêu chuẩn RISC-V đơn giản hơn rất nhiều so với EVM, và các giải pháp thay thế (như Cairo) cũng rất đơn giản.
Động lực hỗ trợ EOF: 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.
Nhiều lựa chọn cho các nhà phát triển hơn: Solidity và Vyper có thể thêm backend để biên dịch sang máy ảo mới. Nếu chọn RISC-V, các nhà phát triển ngôn ngữ chính cũng có thể dễ dàng chuyển mã sang máy ảo đó.
Loại bỏ hầu hết các thao tác biên dịch trước: có thể chỉ giữ lại các thao tác đường cong ellip tối ưu hóa cao (sẽ biến mất ngay cả những điều này sau khi máy tính lượng tử trở nên phổ biến).
Nhược điểm chính là, khác với EOF đã sẵn sàng, lợi ích của máy ảo mới cần một khoảng thời gian dài hơn để mang lại lợi ích cho các nhà phát triển. Chúng ta có thể giảm bớt vấn đề này bằng cách thực hiện các cải tiến EVM có giá trị cao trong ngắn hạn (như tăng giới hạn kích thước mã hợp đồng, hỗ trợ DUP/SWAP17–32).
Điều này sẽ mang lại một máy ảo đơn giản hơn. Thách thức cốt lõi là: làm thế nào để xử lý EVM hiện có?
Chiến lược tương thích ngược cho 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 đạt được mục tiêu và tính tương thích ngược với các ứng dụng hiện có.
Trước tiên cần phải làm rõ: kho mã Ethereum (ngay cả trong một khách hàng đơn lẻ) không chỉ có một cách định nghĩa.
Mục tiêu là thu hẹp khu vực xanh càng nhiều càng tốt: Logic cần thiết cho nút tham gia đồng thuận Ethereum, bao gồm tính toán trạng thái hiện tại, chứng minh, xác minh, FOCIL (quy tắc lựa chọn phân nhánh) và xây dựng khối "thông thường".
Khu vực màu cam không thể giảm: Nếu quy định giao thức loại bỏ hoặc thay đổi một chức năng lớp thực thi nào đó (chẳng hạn như máy ảo, biên dịch trước, v.v.), thì khách hàng xử lý các khối lịch sử vẫn cần giữ lại mã liên quan. Tuy nhiên, khách hàng mới, ZK-EVM hoặc trình chứng minh hình thức có thể hoàn toàn bỏ qua khu vực màu cam.
Khu vực màu vàng mới: rất có giá trị cho việc hiểu chuỗi hiện tại hoặc tối ưu hóa xây dựng khối, nhưng không thuộc về logic đồng thuận. Ví dụ, Etherscan và một số nhà xây dựng khối hỗ trợ các thao tác 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 việ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.
Sự phức tạp của khu vực màu cam và màu vàng là sự đóng gói phức tạp, những người hiểu giao thức có thể bỏ qua những phần này, Ethereum có thể bỏ qua chúng, lỗi trong các khu vực này sẽ không gây ra rủi ro đồng thuận. Do đó, độ phức tạp mã của khu vực màu cam và màu vàng ít nguy hiểm hơn nhiều so với độ phức tạp của khu vực màu xanh lá.
Ý tưởng di chuyển mã từ khu vực xanh sang khu vực vàng giống như chiến lược của Apple thông qua lớp dịch Rosetta để đảm bảo khả năng tương thích lâu dài.
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 máy ảo sau đây (lấy EVM sang RISC-V làm ví dụ, nhưng cũng có thể áp dụng cho EVM sang Cairo hoặc RISC-V sang máy ảo tốt hơn):
Yêu cầu cung cấp triển khai RISC-V trên chuỗi mới: Để hệ sinh thái dần thích ứng với máy ảo RISC-V.
Giới thiệu RISC-V như một tùy chọn cho nhà phát triển: Giao thức hỗ trợ cả RISC-V và EVM, hợp đồng của hai máy ảo có thể tương tác tự do.
Thay thế hầu hết các biên dịch trước: Ngoại trừ các thao tác đường cong elliptic và KECCAK (vì cần tốc độ tối đa), thay thế các biên dịch khác bằng RISC-V. Loại bỏ biên dịch trước thông qua hard fork, đồng thời thay đổi mã của địa chỉ đó (tương tự như hard fork DAO) từ trống thành thực hiện RISC-V. Máy ảo RISC-V cực kỳ đơn giản, ngay cả khi dừng lại ở đây cũng làm đơn giản hóa rõ rệt giao thức.
Triển khai trình thông dịch EVM trong RISC-V: như là hợp đồng thông minh được đưa lên chuỗi (bởi vì cần có bộ chứng ZK). Sau vài năm phát hành ban đầu, các hợp đồng EVM hiện có chạy thông qua trình thông dịch này.
Sau khi hoàn thành bước 4, nhiều "triển khai EVM" vẫn sẽ được sử dụng để tối ưu hóa xây dựng khối, công cụ 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 tiêu chuẩn đồng thuận chính. Đồng thuận Ethereum sẽ "hiểu một cách bản địa" chỉ RISC-V.
Đơn giản hóa thông qua các thành phần giao thức chia sẻ
Cách thứ ba để giảm tổng độ phức tạp của giao thức (cũng là cách dễ bị đánh giá thấp nhất) là chia sẻ tiêu chuẩn thống nhất càng nhiều càng tốt ở các phần khác nhau của ngăn xếp giao thức. Việc các giao thức khác nhau thực hiện cùng một việc trong các tình huống khác nhau thường không có lợi, nhưng mô hình này vẫn thường xuất hiện, chủ yếu là do các phần khác nhau của lộ trình giao thức thiếu sự giao tiếp. 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 chia sẻ các thành phần.
Mã xóa thống nhất
Chúng tôi cần mã sửa lỗi trong ba tình huống:
Lấy mẫu khả năng dữ liệu: Khách hàng xác minh rằng khối đã được phát hành.
Truyền phát P2P nhanh hơn: Các nút có thể chấp nhận khối sau khi nhận n/2 đoạn, đạt được sự cân bằng giữa độ trễ và sự dư thừa.
Lưu trữ lịch sử phân tán: Dữ liệu lịch sử của Ethereum được lưu trữ theo phân đoạn, mỗi nhóm n/2 đoạn có thể phục hồi các đoạn còn lại, giảm rủi ro mất mát đoạn đơn lẻ.
Nếu sử dụng cùng một mã sửa chữa trong ba kịch bản (dù là Reed-Solomon, mã tuyến tính ngẫu nhiên, v.v.), sẽ đạt được các lợi thế sau:
Giảm thiểu số lượng mã: Giảm tổng số dòng mã.
Tăng cường hiệu quả: Nếu nút tải xuống một phần của đoạn trong một cảnh, dữ liệu này có thể được sử dụng cho các cảnh khác.
Đảm bảo tính khả thi: Tất cả các đoạn của các kịch bản đều có thể được xác minh dựa trên gốc.
Nếu sử dụng mã sửa lỗi khác nhau, ít nhất cần đảm bảo tính tương thích, chẳng hạn như mã Reed-Solomon cho lấy mẫu khả dụng dữ liệu theo chiều ngang hoạt động trong cùng một miền với mã tuyến tính ngẫu nhiên dọc.
Định dạng tuần tự hóa thống nhất
Định dạng tuần tự của Ethereum hiện chỉ được cố định một phần, vì dữ liệu có thể được tuần tự hóa lại và phát sóng theo bất kỳ định dạng nào. Ngoại lệ là băm chữ ký giao dịch, cần phải định dạng tiêu chuẩn để thực hiện băm. Trong tương lai, mức độ cố định của định dạng tuần tự sẽ được nâng cao hơn nữa vì các lý do sau:
Trừu tượng hóa tài khoản hoàn toàn (EIP-7701): Nội dung giao dịch đầy đủ có thể nhìn thấy đối với máy ảo.
Giới hạn Gas cao hơn: Dữ liệu lớp thực thi cần được đưa vào khối dữ liệu (blobs).
Tại thời điểm đó, chúng ta có cơ hội thống nhất định dạng tuần tự của ba lớp Ethereum: lớp thực thi, lớp đồng thuận, ABI gọi hợp đồng thông minh.
Tôi đề nghị sử dụng SSZ vì SSZ:
Dễ dàng giải mã: Bao gồm trong hợp đồng thông minh (do nó dựa trên thiết kế 4 byte và ít trường hợp ngoại lệ).
Đã được sử dụng rộng rãi ở tầng đồng thuận.
Tương tự cao với ABI hiện có: Công cụ thích ứng tương đối đơn giản.
Đã có nỗ lực chuyển đổi hoàn toàn sang SSZ, chúng ta nên xem xét và tiếp tục những nỗ lực này khi lập kế hoạch cho các 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 khác có sẵn), cây Merkle Patricia thập phân sẽ trở thành nút cổ chai lớn nhất trong việc chứng minh việc thực thi khối, ngay cả trong trường hợp trung bình. Di chuyển sang cây nhị phân dựa trên hàm băm tốt hơn sẽ nâng cao hiệu quả của bộ chứng minh một cách đáng kể, đồng thời giảm chi phí dữ liệu trong các tình huống như khách hàng nhẹ.
Trong quá trình di chuyển, cần đả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ẽ cho phép lớp đồng thuận của Ethereum và lớp thực thi có thể truy cập và phân tích thông qua cùng một mã.
Từ bây giờ đến tương lai
Đơn giản hóa có nhiều điểm tương đồng với phi tập trung, cả hai đều là mục tiêu bên trên của tính linh hoạt. Việc nhấn mạnh rõ ràng vào sự đơn giản hóa đòi hỏi một sự chuyển đổi văn hóa nhất định. Lợi ích của nó thường khó định lượng, trong khi chi phí của những nỗ lực bổ sung và việc từ bỏ một số tính năng hấp dẫn lại dễ dàng nhận thấy. Tuy nhiên, theo thời gian, lợi ích sẽ càng trở nên rõ ràng hơn - Bitcoin chính là một ví dụ điển hình.
Tôi đề xuất noi gương tinygrad, đặt ra một mục tiêu rõ ràng về số dòng mã tối đa cho quy chuẩn dài hạn của Ethereum, nhằm đưa mã quan trọng cho đồ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ử của Ethereum sẽ tiếp tục tồn tại, nhưng nên được đặt ngoài con đường quan trọng của đồng thuận. Đồng thời, chúng ta nên giữ vững quan điểm chọn lựa giải pháp đơn giản hơn, ưu tiên lựa chọn đóng gói sự phức tạp thay vì sự phức tạp hệ thống, và thực hiện các lựa chọn thiết kế cung cấp thuộc tính rõ ràng và đảm bảo.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Vitalik Blog: Làm thế nào để Ethereum trong 5 năm tới trở nên đơn giản như Bitcoin
Tác giả | Vitalik Buterin
Biên dịch | GaryMa Ngô nói về blockchain
Liên kết gốc:
Tóm tắt
Ethereum nhằm trở thành sổ cái toàn cầu, cần tính mở rộng và độ bền. Bài viết này tập trung vào tầm quan trọng của sự đơn giản trong giao thức, đề xuất giảm đáng kể độ phức tạp bằng cách đơn giản hóa lớp đồng thuận (tính cuối cùng 3-slot, STARK tổng hợp) và lớp thực thi (thay thế EVM bằng RISC-V hoặc máy ảo tương tự), giảm chi phí phát triển, rủi ro lỗi và bề mặt tấn công. Đề xuất chuyển tiếp mượt mà thông qua 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ã sửa lỗi, định dạng tuần tự (SSZ) và cấu trúc cây để đơn giản hóa thêm. Mục tiêu là đưa mã chính của đồng thuận Ethereum gần với sự đơn giản của Bitcoin, nâng cao độ bền và sự tham gia, cần coi trọng sự đơn giản về mặt văn hóa và thiết lập mục tiêu tối đa số dòng mã.
Mục tiêu của Ethereum là trở thành sổ cái toàn cầu: nền tảng lưu trữ tài sản và ghi chép 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ị, chứng nhận dữ liệu có giá trị cao, v.v. Điều này cần sự hỗ trợ từ hai khía cạnh: khả năng mở rộng và độ bền. Kế hoạch phân tách cứng Fusaka sẽ tăng gấp 10 lần không gian có sẵn cho dữ liệu L2, trong khi lộ trình dự kiến vào năm 2026 cũng lên kế hoạch mang lại sự cải thiện lớn tương tự cho lớp L1. Trong khi đó, Ethereum đã hoàn thành việc chuyển đổi sang chứng minh cổ phần (PoS), sự đa dạng của các khách hàng đang tăng nhanh, nghiên cứu xác minh không tri thức (ZK), khả năng kháng quantum cũng đang tiến triển vững chắc, hệ sinh thái ứng dụng ngày càng kiên cố.
Bài viết này nhằm tập trung vào một yếu tố quan trọng nhưng thường bị đánh giá thấp khác của độ bền (thậm chí là khả năng mở rộng): sự đơn giản của giao thức.
Điều ấn tượng nhất của giao thức Bitcoin là sự đơn giản thanh lịch của nó:
Có một chuỗi được cấu thành từ các khối, mỗi khối được liên kết với khối trước đó thông qua hàm băm.
Tính hợp lệ của khối được xác minh thông qua chứng minh công việc (PoW), tức là kiểm tra xem vài chữ số đầu của giá trị băm có phải là số không.
Mỗi khối chứa giao dịch, đồng tiền được sử dụng trong giao dịch đến từ phần thưởng khai thác hoặc từ đầu ra giao dịch trước đó.
Chỉ có vậy thôi! Ngay cả một học sinh trung học thông minh cũng có thể hoàn toàn hiểu 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 khách hàng như một dự án nghiệp dư.
Sự đơn giản của giao thức đã mang lại nhiều lợi thế quan trọng cho Bitcoin (và Ethereum) trở thành nền tảng toàn cầu đáng tin cậy và trung lập.
Dễ hiểu: Giảm độ phức tạp của giao thức, cho phép nhiều người tham gia nghiên cứu, phát triển và quản trị giao thức, giảm thiểu rủi ro do tầng lớp tinh hoa công nghệ thống trị.
Giảm chi phí phát triển: Đơn giản hóa giao thức làm giảm đáng kể chi phí tạo ra cơ sở hạ tầng mới (như khách hàng mới, trình chứng minh, công cụ phát triển, v.v.).
Giảm bớt gánh nặng bảo trì: Giảm chi phí bảo trì hợp đồng dài hạn.
Giảm thiểu rủi ro sai sót: Giảm khả năng xảy ra lỗi thảm khốc trong đặc tả và thực hiện giao thức, đồng thời dễ dàng xác minh rằng không có lỗi như vậy.
Thu hẹp bề mặt tấn công: Giảm bớt các thành phần phức tạp của giao thức, giảm rủi ro bị các nhóm lợi ích đặc biệt tấn công.
Trong lịch sử, Ethereum (đôi khi 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á cao, tăng rủi ro an ninh và tính chất khép kín trong văn hóa nghiên cứu và phát triển, trong khi lợi ích của sự phức tạp mà nó theo đuổi thường được chứng minh là hão huyền. Bài viết này sẽ khám phá Ethereum sau năm năm sẽ tiến gần đến sự đơn giản của Bitcoin như thế nào.
Lớp đồng thuận đơn giản
Thiết kế lớp đồng thuận mới (trong lịch sử được gọi là "chuỗi tín hiệu") nhằm mục đích tận dụng kinh nghiệm trong mười năm qua về lý thuyết đồng thuận, phát triển ZK-SNARK, kinh tế đặt cọc, v.v., để xây dựng một lớp đồng thuận tối ưu lâu dài và đơn giản hơn. So với chuỗi tín hiệu hiện tại, thiết kế mới đơn giản hóa đáng kể:
Thiết kế cuối cùng 3-slot: loại bỏ các khái niệm như slot, epoch, tái cấu trúc ủy ban, cùng với các cơ chế xử lý hiệu quả liên quan (như ủy ban đồng bộ). Việc triển khai cơ bản của tính cuối cùng 3-slot chỉ cần khoảng 200 dòng mã, và so với Gasper, độ an toàn gần như là tối ưu.
Giảm số lượng người xác thực hoạt động: Cho phép sử dụng quy tắc chọn nhánh đơn giản hơn để tăng cường tính bảo mật.
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, 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 lĩnh vực lặp lại. Độ phức tạp của mật mã tổng hợp khá cao, nhưng độ phức tạp của nó được đóng gói cao và rủi ro hệ thống thấp.
Đơn giản hóa kiến trúc P2P: Các yếu tố trên có thể hỗ trợ một kiến trúc mạng điểm-điểm đơn giản hơn và vững chắc hơn.
Thiết kế lại cơ chế xác thực: bao gồm các cơ chế như tham gia, rời bỏ, rút tiền, chuyển đổi khóa, rò rỉ không hoạt động, đơn giản hóa số lượng dòng mã và cung cấp các đảm bảo rõ ràng hơn (như chu kỳ chủ quan yếu).
Lợi thế 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ó không gian lớn để cải tiến liên tục. Thách thức lớn hơn là làm thế nào để đạt được sự đơn giản tương tự trong lớp thực thi.
Lớp thực thi đơn giản
Sự phức tạp của EVM ngày càng gia tăng, và nhiều yếu tố phức tạp đã được chứng minh là không cần thiết (một phần do quyết định sai lầm của cá nhân tôi): máy ảo 256 bit đã tối ưu hóa quá mức cho các hình thức mật mã cụ thể giờ đã dần trở nên lỗi thời, các bản biên soạn trước (precompiles) đượ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 có hiệu quả hạn chế. Ví dụ, việc loại bỏ mã vận hành SELFDESTRUCT tốn rất nhiều nỗ lực nhưng chỉ mang lại lợi ích 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 kế hoạch táo bạo hơn: thay vì thực hiện những thay đổi ở quy mô trung bình (nhưng vẫn có tính phá hoại) đối với EVM để đổi lấy lợi nhuận gấp 1,5 lần, tốt hơn là chuyển sang một máy ảo tốt hơn và đơn giản hơn để đạt được lợi nhuận gấp 100 lần. Tương tự như "Hợp nhất" (The Merge), chúng tôi giảm bớt số lần thay đổi mang tính phá hoại, nhưng làm cho mỗi lần thay đổi trở nên có ý nghĩa hơn. Cụ thể, tôi đề xuất thay thế EVM bằng RISC-V, hoặc một máy ảo khác được sử dụng bởi trình xác minh ZK của Ethereum. Điều này sẽ mang lại:
Hiệu suất được nâng cao đáng kể: Việc thực hiện hợp đồng thông minh (trong bộ chứng minh) không cần chi phí của trình thông dịch, mà chạy trực tiếp. Dữ liệu của Succinct cho thấy hiệu suất có thể tăng hơn 100 lần trong nhiều tình huống.
Cải tiến đơn giản hóa đáng kể: Tiêu chuẩn RISC-V đơn giản hơn rất nhiều so với EVM, và các giải pháp thay thế (như Cairo) cũng rất đơn giản.
Động lực hỗ trợ EOF: 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.
Nhiều lựa chọn cho các nhà phát triển hơn: Solidity và Vyper có thể thêm backend để biên dịch sang máy ảo mới. Nếu chọn RISC-V, các nhà phát triển ngôn ngữ chính cũng có thể dễ dàng chuyển mã sang máy ảo đó.
Loại bỏ hầu hết các thao tác biên dịch trước: có thể chỉ giữ lại các thao tác đường cong ellip tối ưu hóa cao (sẽ biến mất ngay cả những điều này sau khi máy tính lượng tử trở nên phổ biến).
Nhược điểm chính là, khác với EOF đã sẵn sàng, lợi ích của máy ảo mới cần một khoảng thời gian dài hơn để mang lại lợi ích cho các nhà phát triển. Chúng ta có thể giảm bớt vấn đề này bằng cách thực hiện các cải tiến EVM có giá trị cao trong ngắn hạn (như tăng giới hạn kích thước mã hợp đồng, hỗ trợ DUP/SWAP17–32).
Điều này sẽ mang lại một máy ảo đơn giản hơn. Thách thức cốt lõi là: làm thế nào để xử lý EVM hiện có?
Chiến lược tương thích ngược cho 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 đạt được mục tiêu và tính tương thích ngược với các ứng dụng hiện có.
Trước tiên cần phải làm rõ: kho mã Ethereum (ngay cả trong một khách hàng đơn lẻ) không chỉ có một cách định nghĩa.
Mục tiêu là thu hẹp khu vực xanh càng nhiều càng tốt: Logic cần thiết cho nút tham gia đồng thuận Ethereum, bao gồm tính toán trạng thái hiện tại, chứng minh, xác minh, FOCIL (quy tắc lựa chọn phân nhánh) và xây dựng khối "thông thường".
Khu vực màu cam không thể giảm: Nếu quy định giao thức loại bỏ hoặc thay đổi một chức năng lớp thực thi nào đó (chẳng hạn như máy ảo, biên dịch trước, v.v.), thì khách hàng xử lý các khối lịch sử vẫn cần giữ lại mã liên quan. Tuy nhiên, khách hàng mới, ZK-EVM hoặc trình chứng minh hình thức có thể hoàn toàn bỏ qua khu vực màu cam.
Khu vực màu vàng mới: rất có giá trị cho việc hiểu chuỗi hiện tại hoặc tối ưu hóa xây dựng khối, nhưng không thuộc về logic đồng thuận. Ví dụ, Etherscan và một số nhà xây dựng khối hỗ trợ các thao tác 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 việ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.
Sự phức tạp của khu vực màu cam và màu vàng là sự đóng gói phức tạp, những người hiểu giao thức có thể bỏ qua những phần này, Ethereum có thể bỏ qua chúng, lỗi trong các khu vực này sẽ không gây ra rủi ro đồng thuận. Do đó, độ phức tạp mã của khu vực màu cam và màu vàng ít nguy hiểm hơn nhiều so với độ phức tạp của khu vực màu xanh lá.
Ý tưởng di chuyển mã từ khu vực xanh sang khu vực vàng giống như chiến lược của Apple thông qua lớp dịch Rosetta để đảm bảo khả năng tương thích lâu dài.
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 máy ảo sau đây (lấy EVM sang RISC-V làm ví dụ, nhưng cũng có thể áp dụng cho EVM sang Cairo hoặc RISC-V sang máy ảo tốt hơn):
Yêu cầu cung cấp triển khai RISC-V trên chuỗi mới: Để hệ sinh thái dần thích ứng với máy ảo RISC-V.
Giới thiệu RISC-V như một tùy chọn cho nhà phát triển: Giao thức hỗ trợ cả RISC-V và EVM, hợp đồng của hai máy ảo có thể tương tác tự do.
Thay thế hầu hết các biên dịch trước: Ngoại trừ các thao tác đường cong elliptic và KECCAK (vì cần tốc độ tối đa), thay thế các biên dịch khác bằng RISC-V. Loại bỏ biên dịch trước thông qua hard fork, đồng thời thay đổi mã của địa chỉ đó (tương tự như hard fork DAO) từ trống thành thực hiện RISC-V. Máy ảo RISC-V cực kỳ đơn giản, ngay cả khi dừng lại ở đây cũng làm đơn giản hóa rõ rệt giao thức.
Triển khai trình thông dịch EVM trong RISC-V: như là hợp đồng thông minh được đưa lên chuỗi (bởi vì cần có bộ chứng ZK). Sau vài năm phát hành ban đầu, các hợp đồng EVM hiện có chạy thông qua trình thông dịch này.
Sau khi hoàn thành bước 4, nhiều "triển khai EVM" vẫn sẽ được sử dụng để tối ưu hóa xây dựng khối, công cụ 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 tiêu chuẩn đồng thuận chính. Đồng thuận Ethereum sẽ "hiểu một cách bản địa" chỉ RISC-V.
Đơn giản hóa thông qua các thành phần giao thức chia sẻ
Cách thứ ba để giảm tổng độ phức tạp của giao thức (cũng là cách dễ bị đánh giá thấp nhất) là chia sẻ tiêu chuẩn thống nhất càng nhiều càng tốt ở các phần khác nhau của ngăn xếp giao thức. Việc các giao thức khác nhau thực hiện cùng một việc trong các tình huống khác nhau thường không có lợi, nhưng mô hình này vẫn thường xuất hiện, chủ yếu là do các phần khác nhau của lộ trình giao thức thiếu sự giao tiếp. 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 chia sẻ các thành phần.
Mã xóa thống nhất
Chúng tôi cần mã sửa lỗi trong ba tình huống:
Lấy mẫu khả năng dữ liệu: Khách hàng xác minh rằng khối đã được phát hành.
Truyền phát P2P nhanh hơn: Các nút có thể chấp nhận khối sau khi nhận n/2 đoạn, đạt được sự cân bằng giữa độ trễ và sự dư thừa.
Lưu trữ lịch sử phân tán: Dữ liệu lịch sử của Ethereum được lưu trữ theo phân đoạn, mỗi nhóm n/2 đoạn có thể phục hồi các đoạn còn lại, giảm rủi ro mất mát đoạn đơn lẻ.
Nếu sử dụng cùng một mã sửa chữa trong ba kịch bản (dù là Reed-Solomon, mã tuyến tính ngẫu nhiên, v.v.), sẽ đạt được các lợi thế sau:
Giảm thiểu số lượng mã: Giảm tổng số dòng mã.
Tăng cường hiệu quả: Nếu nút tải xuống một phần của đoạn trong một cảnh, dữ liệu này có thể được sử dụng cho các cảnh khác.
Đảm bảo tính khả thi: Tất cả các đoạn của các kịch bản đều có thể được xác minh dựa trên gốc.
Nếu sử dụng mã sửa lỗi khác nhau, ít nhất cần đảm bảo tính tương thích, chẳng hạn như mã Reed-Solomon cho lấy mẫu khả dụng dữ liệu theo chiều ngang hoạt động trong cùng một miền với mã tuyến tính ngẫu nhiên dọc.
Định dạng tuần tự hóa thống nhất
Định dạng tuần tự của Ethereum hiện chỉ được cố định một phần, vì dữ liệu có thể được tuần tự hóa lại và phát sóng theo bất kỳ định dạng nào. Ngoại lệ là băm chữ ký giao dịch, cần phải định dạng tiêu chuẩn để thực hiện băm. Trong tương lai, mức độ cố định của định dạng tuần tự sẽ được nâng cao hơn nữa vì các lý do sau:
Trừu tượng hóa tài khoản hoàn toàn (EIP-7701): Nội dung giao dịch đầy đủ có thể nhìn thấy đối với máy ảo.
Giới hạn Gas cao hơn: Dữ liệu lớp thực thi cần được đưa vào khối dữ liệu (blobs).
Tại thời điểm đó, chúng ta có cơ hội thống nhất định dạng tuần tự của ba lớp Ethereum: lớp thực thi, lớp đồng thuận, ABI gọi hợp đồng thông minh.
Tôi đề nghị sử dụng SSZ vì SSZ:
Dễ dàng giải mã: Bao gồm trong hợp đồng thông minh (do nó dựa trên thiết kế 4 byte và ít trường hợp ngoại lệ).
Đã được sử dụng rộng rãi ở tầng đồng thuận.
Tương tự cao với ABI hiện có: Công cụ thích ứng tương đối đơn giản.
Đã có nỗ lực chuyển đổi hoàn toàn sang SSZ, chúng ta nên xem xét và tiếp tục những nỗ lực này khi lập kế hoạch cho các 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 khác có sẵn), cây Merkle Patricia thập phân sẽ trở thành nút cổ chai lớn nhất trong việc chứng minh việc thực thi khối, ngay cả trong trường hợp trung bình. Di chuyển sang cây nhị phân dựa trên hàm băm tốt hơn sẽ nâng cao hiệu quả của bộ chứng minh một cách đáng kể, đồng thời giảm chi phí dữ liệu trong các tình huống như khách hàng nhẹ.
Trong quá trình di chuyển, cần đả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ẽ cho phép lớp đồng thuận của Ethereum và lớp thực thi có thể truy cập và phân tích thông qua cùng một mã.
Từ bây giờ đến tương lai
Đơn giản hóa có nhiều điểm tương đồng với phi tập trung, cả hai đều là mục tiêu bên trên của tính linh hoạt. Việc nhấn mạnh rõ ràng vào sự đơn giản hóa đòi hỏi một sự chuyển đổi văn hóa nhất định. Lợi ích của nó thường khó định lượng, trong khi chi phí của những nỗ lực bổ sung và việc từ bỏ một số tính năng hấp dẫn lại dễ dàng nhận thấy. Tuy nhiên, theo thời gian, lợi ích sẽ càng trở nên rõ ràng hơn - Bitcoin chính là một ví dụ điển hình.
Tôi đề xuất noi gương tinygrad, đặt ra một mục tiêu rõ ràng về số dòng mã tối đa cho quy chuẩn dài hạn của Ethereum, nhằm đưa mã quan trọng cho đồ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ử của Ethereum sẽ tiếp tục tồn tại, nhưng nên được đặt ngoài con đường quan trọng của đồng thuận. Đồng thời, chúng ta nên giữ vững quan điểm chọn lựa giải pháp đơn giản hơn, ưu tiên lựa chọn đóng gói sự phức tạp thay vì sự phức tạp hệ thống, và thực hiện các lựa chọn thiết kế cung cấp thuộc tính rõ ràng và đảm bảo.