Một khía cạnh quan trọng và thường bị đánh giá thấp của "không cần tin tưởng", "vượt qua bài kiểm tra bỏ đi" và "chủ quyền tự thân" là sự đơn giản của giao thức. Ngay cả khi một giao thức siêu phi tập trung với hàng trăm ngàn nút, và nó có khả năng chịu lỗi Byzantine 49%, và các nút hoàn toàn xác minh mọi thứ với các peerdas và starks an toàn với lượng tử, nếu giao thức là một mớ hỗn độn khó xử lý với hàng trăm ngàn dòng mã và năm hình thức mật mã cấp độ tiến sĩ, cuối cùng giao thức đó sẽ thất bại trong cả ba bài kiểm tra: * Nó không phải là không cần tin tưởng vì bạn phải tin tưởng một lớp nhỏ các thầy tu cao cấp, những người cho bạn biết các thuộc tính của giao thức là gì * Nó không vượt qua bài kiểm tra bỏ đi vì nếu các đội khách hàng hiện tại biến mất, rất khó cho các đội mới đạt được cùng một mức chất lượng * Nó không phải là chủ quyền tự thân vì nếu ngay cả những người kỹ thuật nhất cũng không thể kiểm tra và hiểu được nó, thì nó không hoàn toàn thuộc về bạn Nó cũng kém an toàn hơn, vì mỗi phần của giao thức, đặc biệt nếu nó có thể tương tác với các phần khác theo những cách phức tạp, mang theo rủi ro giao thức bị hỏng. Một trong những nỗi lo của tôi với sự phát triển giao thức Ethereum là chúng ta có thể quá háo hức để thêm các tính năng mới nhằm đáp ứng các nhu cầu rất cụ thể, ngay cả khi những tính năng đó làm phình to giao thức hoặc thêm toàn bộ các loại thành phần tương tác mới hoặc mật mã phức tạp như các phụ thuộc quan trọng. Điều này có thể tốt cho việc tăng cường chức năng ngắn hạn, nhưng nó rất phá hoại việc bảo tồn chủ quyền tự thân lâu dài, và tạo ra một 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 các đế chế và ý thức hệ. Vấn đề cốt lõi là nếu các thay đổi giao thức được đánh giá từ góc độ "chúng lớn như thế nào so với các thay đổi của giao thức hiện tại", thì mong muốn bảo tồn tính tương thích ngược có nghĩa là các bổ sung xảy ra thường xuyên hơn so với việc loại bỏ, và giao thức không thể tránh khỏi sẽ phình to theo thời gian. Để chống lại điều này, quy trình phát triển Ethereum cần một chức năng "đơn giản hóa" / "thu gom rác" rõ ràng. "Đơn giản hóa" có ba chỉ số: * Giảm thiểu tổng số dòng mã trong giao thức. Một giao thức lý tưởng vừa vặn trên một trang duy nhất - hoặc ít nhất là một vài trang * Tránh các phụ thuộc không cần thiết vào các thành phần kỹ thuật phức tạp về cơ bản. Ví dụ, một giao thức mà bảo mật của nó chỉ phụ thuộc vào các hàm băm (càng tốt: chỉ phụ thuộc vào một hàm băm duy nhất) thì tốt hơn một giao thức phụ thuộc vào các hàm băm và lưới. Việc thêm vào các isogenies là tồi tệ nhất, vì (xin lỗi những người thiên tài chăm chỉ thực sự đã tìm ra những thứ đó) không ai hiểu được isogenies. * Thêm nhiều _bất biến_: các thuộc tính cốt lõi mà giao thức có thể dựa vào, ví dụ EIP-6780 (loại bỏ tự hủy) đã thêm thuộc tính rằng tối đa N ô lưu trữ có thể được thay đổi mỗi ô, đơn giản hóa đáng kể việc phát triển khách hàng, và EIP-7825 (giới hạn gas theo giao dịch) đã thêm một giới hạn về chi phí xử lý một giao dịch, điều này giúp rất nhiều cho ZK-EVMs và thực thi song song. Thu gom rác có thể là từng phần, hoặc có thể là quy mô lớn. Cách tiếp cận từng phần cố gắng lấy các tính năng hiện có và tinh giản chúng để chúng đơn giản hơn và có ý nghĩa hơn. Một ví dụ là các cải cách chi phí gas ở Glamsterdam, làm cho nhiều chi phí gas trước đây là tùy ý, thay vào đó phụ thuộc vào một số tham số nhỏ rõ ràng liên quan đến tiêu thụ tài nguyên. Một thu gom rác quy mô lớn là thay thế PoW bằng PoS. Một cái khác có khả năng xảy ra như một phần của đồng thuận Lean, mở ra cơ hội để sửa chữa một số lượng lớn sai lầm cùng một lúc ( ). Một cách tiếp cận khác là "tính tương thích ngược theo kiểu Rosetta", nơi các tính năng phức tạp nhưng ít được sử dụng vẫn có thể sử dụng nhưng được "hạ cấp" khỏi việc trở thành một phần của giao thức bắt buộc và thay vào đó trở thành mã hợp đồng thông minh, vì vậy các nhà phát triển khách hàng mới không cần phải bận tâm đến chúng. Ví dụ: * Sau khi chúng tôi nâng cấp lên trừu tượng tài khoản gốc hoàn toàn, tất cả các loại giao dịch cũ có thể được nghỉ hưu, và EOAs có thể được chuyển đổi thành ví hợp đồng thông minh mà mã của chúng có thể xử lý tất cả các loại giao dịch đó * Chúng tôi có thể thay thế các precompile hiện có (trừ những cái _thực sự_ cần thiết) bằng mã EVM hoặc sau đó là mã RISC-V * Cuối cùng, chúng tôi có thể thay đổi VM từ EVM sang RISC-V (hoặc VM đơn giản hơn khác); EVM có thể được chuyển thành một hợp đồng thông minh trong VM mới. Cuối cùng, chúng tôi muốn tránh việc các nhà phát triển khách hàng cảm thấy cần phải xử lý tất cả các phiên bản cũ của giao thức Ethereum. Điều đó có thể được để lại cho các phiên bản khách hàng cũ chạy trong các container docker. Về lâu dài, tôi hy vọng rằng tốc độ thay đổi của Ethereum có thể chậm lại. Tôi nghĩ vì nhiều lý do mà cuối cùng điều đó _phải_ xảy ra. Mười lăm năm đầu tiên này nên được xem như một giai đoạn tuổi dậy thì, nơi chúng ta đã khám phá rất nhiều ý tưởng và thấy điều gì hoạt động và điều gì hữu ích và điều gì không. Chúng ta nên cố gắng tránh những phần không hữu ích trở thành gánh nặng vĩnh viễn cho giao thức Ethereum. Về cơ bản, chúng ta muốn cải thiện Ethereum theo cách trông như thế này: