Vitalik Buterin Kêu Gọi Đơn Giản Hóa và "Thu Gom Rác" Trong Phát Triển Giao Thức Ethereum

Tin tức từ PANews ngày 18 tháng 1, Vitalik Buterin đã đăng bài trên nền tảng X, nêu rõ một khía cạnh quan trọng nhưng lâu nay bị đánh giá thấp của tính "không cần tin tưởng", "thoát khỏi kiểm tra" và "tự chủ cá nhân" là tính đơn giản của giao thức. Dù một giao thức có hàng chục nghìn nút, khả năng chịu lỗi Byzantine lên đến 49%, và các nút hoàn toàn xác minh mọi thứ thông qua peerDAS và STARKs chống lượng tử, nhưng nếu giao thức đó là một khối mã hỗn loạn gồm hàng chục nghìn dòng mã và năm loại mật mã cấp tiến sĩ, thì giao thức đó cuối cùng sẽ thất bại trong cả ba bài kiểm tra: - Nó không có tính không cần tin tưởng, vì người dùng phải tin tưởng một nhóm nhỏ các chuyên gia cao cấp để biết các thuộc tính của giao thức. - Nó không thể vượt qua bài kiểm tra "thoát khỏi", vì nếu đội ngũ hiện tại rời đi, các nhóm mới sẽ rất khó đạt được chất lượng tương đương. - Nó không có tính tự chủ, vì ngay cả những người có kỹ năng công nghệ cao nhất cũng không thể kiểm tra và hiểu được nó, do đó giao thức không hoàn toàn thuộc về người dùng. Đồng thời, tính an toàn của nó cũng thấp, vì mỗi phần của giao thức, đặc biệt là khi nó có thể tương tác theo cách phức tạp với các phần khác, đều tiềm ẩn nguy cơ giao thức sụp đổ. Một mối lo ngại của tôi trong việc phát triển giao thức Ethereum là chúng ta có thể quá vội vàng thêm các tính năng mới để đáp ứng các nhu cầu rất cụ thể, ngay cả khi các tính năng đó làm cho giao thức trở nên cồng kềnh, hoặc thêm các thành phần tương tác mới hoặc các thuật toán mật mã phức tạp làm phụ thuộc quan trọng. Điều này có thể mang lại lợi ích về mặt chức năng trong ngắn hạn, nhưng lại gây tổn hại nghiêm trọng đến việc duy trì tự chủ lâu dài và xây dựng một siêu cấu trúc phi tập trung tồn tại hàng trăm năm vượt qua sự thăng trầm của đế chế và ý thức hệ. Vấn đề cốt lõi là, nếu đánh giá các thay đổi giao thức dựa trên "mức độ thay đổi so với giao thức hiện tại", thì mong muốn duy trì tính tương thích ngược sẽ khiến số lần thêm vào nhiều hơn số lần loại bỏ, và giao thức không thể tránh khỏi việc trở nên cồng kềnh theo thời gian. Để đối phó với tình trạng này, quy trình phát triển Ethereum cần có một chức năng "đơn giản hóa" hoặc "thu gom rác" rõ ràng. "Đơn giản hóa" có ba tiêu chí đo lường: 1. Tối thiểu hóa tổng số dòng mã của giao thức. 2. Tránh phụ thuộc không cần thiết vào các thành phần kỹ thuật phức tạp. 3. Thêm nhiều bất biến hơn: các thuộc tính cốt lõi mà giao thức có thể dựa vào, ví dụ như EIP-6780 (loại bỏ selfdestruct) đã thêm thuộc tính mỗi khối chỉ có thể thay đổi tối đa N ô lưu trữ, điều này đã đơn giản hóa đáng kể việc phát triển client. Việc "thu gom rác" có thể là từng phần hoặc quy mô lớn. Phương pháp từng phần cố gắng đơn giản hóa các chức năng hiện có để chúng trở nên gọn nhẹ và hợp lý hơn. Một ví dụ về thu gom rác quy mô lớn là thay thế PoW bằng PoS. Một cách tiếp cận khác là "tương thích ngược kiểu Rosetta", tức là các chức năng phức tạp nhưng ít được sử dụng vẫn có thể tồn tại, nhưng được "giảm cấp" thành mã hợp đồng thông minh, thay vì là một phần bắt buộc của giao thức, như vậy các nhà phát triển client mới sẽ không cần phải xử lý chúng. Ví dụ, sau khi nâng cấp lên hoàn toàn trừu tượng hóa tài khoản, tất cả các loại giao dịch cũ có thể bị loại bỏ; thay thế các hợp đồng tiền biên dịch hiện tại bằng mã EVM hoặc RISC-V; cuối cùng thay đổi máy ảo từ EVM sang RISC-V. Cuối cùng, hy vọng rằng các nhà phát triển client sẽ không còn phải xử lý tất cả các phiên bản cũ của giao thức Ethereum. Về lâu dài, tốc độ thay đổi của Ethereum có thể được giảm bớt, và chúng ta nên nỗ lực để tránh những phần không cần thiết trở thành gánh nặng vĩnh viễn của giao thức Ethereum.