Phản tư về quản trị Ethereum: Vì sao mọi người bất mãn với sự kiện EIP-3074?
Tuyển chọn TechFlowTuyển chọn TechFlow
Phản tư về quản trị Ethereum: Vì sao mọi người bất mãn với sự kiện EIP-3074?
Sự kiện EIP-3074/EIP-7702 của Ethereum đã vạch ra tính phức tạp trong cấu trúc quản trị của nó: ngoài quy trình quản trị chính thức, lộ trình không chính thức do các nhà nghiên cứu đề xuất cũng có ảnh hưởng lớn.
Chuyên sâu báo cáo Web3Tác giả: Bu Lu Shuo
Bài viết này trình bày suy nghĩ của tôi về sự kiện EIP-3047 gần đây, xin cảm ơn Vitalik và Yoav đã rà soát nội dung.
Nếu bạn chưa rõ về sự việc này, dưới đây là phần tóm tắt ngắn:
Mới đây, đề xuất EIP-3074 đã nhận được tín hiệu xanh từ các nhà phát triển cốt lõi, dự kiến sẽ được triển khai trong đợt hard fork sắp tới của Ethereum mang tên Pectra. Đề xuất này nhằm mục đích giúp người dùng tài khoản thông thường trên Ethereum (EOA) cũng có thể tận hưởng nhiều tiện ích từ tính năng trừu tượng hóa tài khoản (Account Abstraction, viết tắt phổ biến là AA).
Tuy nhiên sau đó, cộng đồng ERC-4337, đặc biệt là những người soạn thảo đề xuất này, đã phản đối mạnh mẽ EIP-3074, lý do chủ yếu là EIP-3047 có thể làm gia tăng rủi ro tập trung hóa, và không phù hợp với lộ trình trừu tượng hóa tài khoản mà Ethereum đang theo đuổi — lộ trình này lấy EIP-4337 và người anh em gần gũi của nó EIP-7560 (còn gọi là tài khoản trừu tượng bản địa) làm trung tâm.
Tuần trước, Vitalik đã đề xuất EIP-7702 như một phương án thay thế cho EIP-3074. Nó cũng hướng đến việc mang lại lợi ích của tài khoản trừu tượng cho người dùng EOA, nhưng thiết kế phù hợp hơn với tiêu chuẩn EIP-4337 hiện tại và có thể chuyển tiếp mượt mà sang hình thái cuối cùng — EIP-7560.
Lưu ý của người dịch: ERC-4337 và ERC-7560 đều là các đề xuất liên quan đến trừu tượng hóa tài khoản trong hệ sinh thái Ethereum, nhằm cải thiện cách quản lý và tương tác tài khoản của người dùng, nâng cao trải nghiệm và bảo mật.
ERC-4337 cho phép người dùng quản lý tài khoản thông qua hợp đồng đại diện (Proxy Contract), giảm độ phức tạp và rủi ro khi tương tác với DApp. ERC-7560 hướng đến việc tích hợp trực tiếp tư tưởng từ các đề xuất như ERC-4337 vào tầng cơ sở của Ethereum, khiến mọi tài khoản tự nhiên có khả năng trừu tượng hóa, từ đó đạt được mức độ tích hợp sâu hơn và tối ưu hóa tốt hơn.
ERC-4337 là bước đi quan trọng để tiến tới ERC-7560, cả hai cùng tạo thành cốt lõi của lộ trình trừu tượng hóa tài khoản Ethereum.
Hiện tại, nhóm phát triển cốt lõi đang thảo luận về EIP-7702, và một số dấu hiệu ban đầu cùng phản hồi từ cộng đồng cho thấy EIP-7702 rất có thể sẽ thay thế EIP-3074 trong đợt hard fork Pectra.
Với kết quả này, cá nhân tôi cảm thấy rất hài lòng: Người dùng EOA sắp được tận hưởng phần lớn lợi ích từ tài khoản trừu tượng thông qua các công cụ và cơ sở hạ tầng được xây dựng dành riêng cho ERC-4337.
Tuy nhiên, con đường dẫn đến mục tiêu này khiến tôi khó lòng yên tâm, cảm giác rằng đây không phải là cách đi tối ưu nhất, và cũng là cảm xúc chung của nhiều người gần đây. Tôi tin chắc rằng nếu có quy trình tốt hơn, chúng ta hoàn toàn có thể giảm thiểu xung đột và đạt được sự đồng thuận nhanh chóng hơn.
Trong bài viết này, tôi muốn:
-
Phân tích những vấn đề tồn tại trong quá trình này
-
Đưa ra một khuôn khổ tư duy để hiểu về quản trị Ethereum
-
Thảo luận cách cải thiện để tránh lặp lại sai lầm tương tự trong tương lai
Tại sao mọi người cảm thấy bất mãn?
Toàn bộ sự việc khiến nhiều người cảm thấy bất mãn vì một vài lý do:
-
Con đường phê duyệt dài: EIP-3074 mất hàng năm trời mới cuối cùng được bật đèn xanh.
-
Phản hồi chậm trễ: Các nhà phát triển cốt lõi chỉ nhận được tiếng nói phản đối rộng rãi từ cộng đồng ERC-4337 sau khi 3074 đã được thông qua.
-
Cảnh báo thất bại: Dù các tác giả đề xuất 4337 đã nhiều lần bày tỏ lo ngại về 3074 với các nhà phát triển cốt lõi, nhưng hiệu quả thu được rất ít.
-
Thay đổi đột ngột: Giờ đây, chúng ta phải hủy bỏ EIP-3074 và thay thế bằng EIP-7702.
Khách quan mà nói, từng khâu riêng lẻ ở trên không có gì sai:
-
Thảo luận lâu dài là điều hợp lý.
-
Việc bị phản đối sau khi được chấp thuận cũng là hiện tượng bình thường.
-
Nếu có vấn đề mới nảy sinh, việc điều chỉnh hay thậm chí hủy bỏ quyết định cũ cũng là hợp logic.
Tuy nhiên, có lẽ tất cả chúng ta đều đồng ý rằng quá trình này hoàn toàn có thể diễn ra trôi chảy hơn. Hãy tưởng tượng nếu mọi việc diễn ra như sau:
Trong thời gian các nhà phát triển cốt lõi thảo luận về EIP-3074, cộng đồng ERC-4337 tích cực tham gia vào. Như vậy, chỉ có hai khả năng xảy ra:
-
Hoặc EIP-3074 được phê duyệt sau khi đã cân nhắc phản hồi từ cộng đồng EIP-4337 (có thể kèm sửa đổi), lúc đó cộng đồng EIP-4337 sẽ ủng hộ EIP-3074, và không cần phải đảo ngược quyết định.
-
Hoặc EIP-3074 chưa bao giờ được phê duyệt, nhưng cộng đồng EIP-4337 phối hợp với các nhà phát triển cốt lõi để thúc đẩy một đề xuất mà tất cả đều hài lòng, giống như EIP-7702.
Tiếng nói của mọi người đều được lắng nghe, không có kịch tính đảo chiều. Đây hẳn là một kết cục lý tưởng – nhưng tại sao lại không xảy ra?
Vấn đề nằm ở đâu?
Nhìn lại toàn bộ quá trình, cả hai bên tranh luận đều đổ lỗi cho nhau.
Các nhà phát triển cốt lõi (bao gồm cả tác giả EIP-3074) cho rằng, nếu đội ngũ EIP-4337 tích cực tham gia hơn vào quy trình All Core Devs (ACD), thì sự việc đã không xảy ra.
Trong quy trình này, các đề xuất cần được thảo luận lâu dài, và cuối cùng được các nhóm client chấp nhận rồi tích hợp vào giao thức. Họ cho rằng đội EIP-4337 có thể can thiệp bất kỳ lúc nào để nêu lên mối lo ngại, thay vì đợi đến khi EIP-3074 đã được phê duyệt. Rốt cuộc, quy trình ACD hoàn toàn minh bạch, các cuộc họp mở cửa, và những người như Tim Beiko còn đăng tóm tắt sau mỗi cuộc họp. Nếu đội EIP-4337 thực sự quan tâm, tại sao lại không dành thời gian tham gia?
Ngược lại, đội trừu tượng hóa tài khoản (tức các tác giả EIP-4337) nhấn mạnh rằng họ thực tế đã tham dự các cuộc họp ACD và nắm bắt mọi cơ hội để phản đối EIP-3074, nhưng không được các nhà phát triển cốt lõi tiếp nhận. Nhiều thành viên cộng đồng EIP-4337 cảm thấy bất ngờ, thậm chí tưởng rằng EIP-3074 đã bị bỏ rơi, hoặc không biết rằng nó vẫn đang được xem xét.
Ngoài ra, cũng có ý kiến cho rằng quy trình ACD quá phức tạp, khó tham gia đối với những người có công việc toàn thời gian và không thể theo dõi sát sao từng cập nhật. Một số người khác cho rằng việc chủ động hỏi ý kiến các bên liên quan then chốt (như cộng đồng EIP-4337) nên là trách nhiệm của ACD.
Theo tôi, cả hai phía đều chưa chạm đúng vào cốt lõi vấn đề. Có một nguyên nhân sâu xa hơn đang vận hành, và trừ khi chúng ta giải quyết hoặc ít nhất thừa nhận nó, chúng ta sẽ tiếp tục gặp thất bại trong quản trị và rơi vào vòng luẩn quẩn đổ lỗi vô nghĩa.
Căn bệnh nằm ở đâu?
Căn nguyên thật sự của thất bại quản trị nằm ở chỗ mọi người đều hiểu sai về All Core Devs. Thực tế, All Core Devs không phải là lực lượng ra quyết định duy nhất về việc cập nhật giao thức. Trong trường hợp này, một lực lượng quản trị khác thực tế đã vượt qua ACD và đóng vai trò quyết định.
Vấn đề là, lực lượng quản trị quan trọng này dù có ảnh hưởng lớn đến các vấn đề trọng đại của Ethereum như trừu tượng hóa tài khoản và mở rộng quy mô, lại hiếm khi được công nhận chính thức.
Ở đây tôi gọi lực lượng này là "lộ trình" (roadmap).
Tóm lại, toàn bộ sự việc chuyển từ 3074 sang 7702 là một ví dụ điển hình cho thấy sức mạnh của "lộ trình" đã đè bẹp quyền lực ra quyết định của All Core Devs.
Xét về mặt quản trị, khi một lực lượng vô hình áp đảo một lực lượng hữu hình, chúng ta cần cảnh giác, bởi vì vô hình tức là không chịu sự giám sát, do đó phải phơi bày và kiểm tra kỹ lưỡng lực lượng tiềm ẩn này.
Lộ trình là gì?
Trong giới Ethereum, chắc hẳn ai cũng quen thuộc với cụm từ "lộ trình", ví dụ như lộ trình tập trung vào Rollup, lộ trình ETH 2.0, hay lộ trình trừu tượng hóa tài khoản – chủ đề trung tâm của bài viết này.
Hãy hình dung, tại một cuộc họp All Core Devs, mọi người đang thảo luận cách mở rộng quy mô mạng lưới:
Nhà phát triển cốt lõi Bob đề xuất: Tôi ủng hộ EIP-1234, nó đề nghị tăng tốc độ khối lên 10 lần, dung lượng khối tăng gấp 10 lần, phí giao dịch giảm 100 lần.
Các nhà phát triển khác trả lời: Bạn nghiêm túc đấy chứ?
Hãy suy nghĩ, tại sao đề xuất của Bob lại bị bác bỏ nhanh chóng? Ông ấy thực sự đưa ra một giải pháp mở rộng hiệu quả, các chuỗi công khai khác như Solana cũng làm như vậy và đạt hiệu quả rõ rệt.
Lý do là vì đề xuất của Bob trái ngược với lộ trình mở rộng quy mô tập trung vào Rollup mà Ethereum kiên trì theo đuổi. Lộ trình này nhấn mạnh rằng để duy trì tính phi tập trung, việc người dùng thông thường có thể dễ dàng chạy node là cực kỳ quan trọng. Do đó, đề xuất của Bob làm tăng đáng kể độ khó khi chạy node, vi phạm lộ trình, nên bị loại bỏ.
Qua ví dụ này, tôi muốn cho thấy rằng các nhà phát triển cốt lõi tham gia vào các cuộc họp ACD, chịu trách nhiệm cập nhật giao thức, thực tế đang tuân theo một nguyên tắc hướng dẫn cao hơn – thứ mà tôi gọi là "lộ trình". Có nhiều loại lộ trình như lộ trình mở rộng, lộ trình trừu tượng hóa tài khoản, lộ trình MEV… Tất cả cùng tạo thành lộ trình tổng thể của Ethereum, là căn cứ để các nhà phát triển cốt lõi ra quyết định.
Khi nhà phát triển cốt lõi không đồng nhất với lộ trình
Do lộ trình không thuộc phần quản trị chính thức, các nhà phát triển cốt lõi không nhất thiết luôn đồng nhất với nó. Đặc biệt, vì không có quy trình "phê duyệt lộ trình" chính thức, nên không phải lộ trình nào cũng có mức độ công nhận như nhau. Điều này đòi hỏi những người hoạch định lộ trình phải tích cực quảng bá với các nhà phát triển cốt lõi và cộng đồng rộng lớn để giành được sự công nhận, từ đó nhận được sự đồng thuận và ủng hộ.
Lấy ví dụ trừu tượng hóa tài khoản, Vitalik đã nhiều lần ca ngợi lộ trình lấy EIP-4337 làm trung tâm, nhưng thực tế chủ yếu là đội EIP-4337, đặc biệt là Yoav và Dror, tích cực vận động lộ trình này tại các cuộc họp, diễn đàn trực tuyến và các cuộc họp ACD.
Tuy nhiên, dù vậy, một số nhà phát triển cốt lõi vẫn phản đối lộ trình lấy EIP-4337 làm trung tâm, cho rằng EIP-7560 (phiên bản gốc của EIP-4337, yêu cầu client tương lai phải triển khai) quá phức tạp, không phải con đường duy nhất để đạt được hình thái cuối cùng của tài khoản trừu tượng. Cuối cùng, mặc dù đội EIP-4337 phản đối EIP-3074 vì lo ngại việc đưa vào một stack công nghệ tài khoản trừu tượng tập trung hóa hơn sẽ chia rẽ hệ sinh thái, ACD vẫn phê duyệt EIP-3074.
Nhưng sau khi EIP-3074 được phê duyệt, sự phản đối mạnh mẽ từ toàn bộ cộng đồng EIP-4337 đã buộc các nhà phát triển cốt lõi phải xem xét lại. Hai bên tranh cãi gay gắt, cho đến khi Vitalik đưa ra EIP-7702 như một phương án thay thế, rõ ràng ủng hộ giải pháp trừu tượng hóa tài khoản lấy EIP-4337 làm trung tâm, tình thế mới chuyển hướng theo đúng lộ trình.
Vai trò của Vitalik
Dù tự coi mình là một nhà nghiên cứu, nhưng qua sự kiện này, rõ ràng Vitalik đóng một vai trò độc đáo và khác biệt trong quản trị Ethereum. Điều này đặt ra câu hỏi: Vitalik thực sự đóng vai trò gì trong quản trị Ethereum?
Chúng ta có thể hình dung Vitalik như CTO của một công ty lớn.
Nếu bạn từng làm việc tại một công ty công nghệ có quy mô nhất định, ví dụ trên 50 người, bạn sẽ hiểu rằng CTO không thể tham gia vào mọi quyết định kỹ thuật. Khi công ty lớn lên, các quyết định kỹ thuật tự nhiên được phân tán, các nhóm con trong từng lĩnh vực sản phẩm thường tự quyết định chi tiết triển khai.
Hơn nữa, CTO cũng không nhất thiết là chuyên gia giỏi nhất trong mọi lĩnh vực. Trong công ty có thể có những kỹ sư giỏi hơn CTO ở một số khía cạnh. Vì vậy, trong các tranh luận kỹ thuật, thường chính các kỹ sư đưa ra quyết định cuối cùng.
Tuy nhiên, CTO chịu trách nhiệm định hình tầm nhìn kỹ thuật của công ty, còn việc triển khai cụ thể thì giao cho các nhà phát triển.
Dù phép so sánh này không hoàn hảo, nhưng nó khá chính xác trong việc miêu tả vai trò của Vitalik trong hệ sinh thái Ethereum.
Vitalik không tham gia vào mọi quyết định kỹ thuật – ông không thể làm như vậy, cũng không phải là chuyên gia giỏi nhất trong mọi lĩnh vực. Nhưng ông có ảnh hưởng lớn đến lộ trình của các khía cạnh then chốt trên Ethereum (như mở rộng, trừu tượng hóa tài khoản, proof-of-stake...), không chỉ vì kiến thức kỹ thuật của ông, mà còn vì ông có khả năng phán xét cuối cùng liệu một lộ trình có phù hợp với tầm nhìn của Ethereum – tức là tầm nhìn của chính ông – hay không.
Động lực đằng sau mỗi sản phẩm thành công là tầm nhìn
Là một người sáng lập, tôi cho rằng mỗi sản phẩm thành công đều có một tầm nhìn rõ ràng ở phía sau. Và tầm nhìn đó thường cần một nhóm nhỏ người, thường là đội sáng lập, thậm chí thường chỉ một người sáng lập then chốt để xác lập.
Sức hấp dẫn của Ethereum nằm ở chỗ, một hệ thống phức tạp và đa tầng như vậy lại có thể phối hợp vận hành, trở thành một máy tính phi tập trung xử lý giá trị khổng lồ mỗi ngày. Điều này không thể đạt được nhờ quyết định kiểu ủy ban, mà nhờ tầm nhìn dẫn dắt của Vitalik, chúng ta mới có được Ethereum ngày nay – một hệ thống phối hợp và hiệu quả. Từ ý tưởng năm 2015 đến hôm nay, Ethereum luôn là hiện thân của trí tuệ Vitalik.
Điều này không hề giảm nhẹ đóng góp của các nhà nghiên cứu và kỹ sư khác, họ đã cống hiến rất nhiều cho sự phát triển của Ethereum. Tuy nhiên, không thể phủ nhận rằng Ethereum là sự thể hiện cực hạn của tầm nhìn Vitalik, vượt xa ảnh hưởng của bất kỳ cá nhân nào khác.
Hãy tự hỏi một cách trung thực: Khi bạn tham gia Ethereum vì sự cởi mở, chống kiểm duyệt và năng lượng đổi mới của nó, bạn có quan tâm rằng tất cả bắt nguồn từ ý tưởng ban đầu của Vitalik không?
Có thể trước đây bạn chưa nghĩ kỹ, nhưng sau khi hiểu điều này, bạn thực sự bận tâm sao?
Ethereum được sinh ra từ một tầm nhìn rõ ràng, và tiếp tục phát triển trong quá trình hiện thực hóa tầm nhìn đó – chính điều này tạo nên sức hút của nó.
Còn về tính phi tập trung thì sao?
Bạn có thể hỏi, nếu một người có ảnh hưởng lớn như vậy đến Ethereum, làm sao chúng ta có thể nói nó là phi tập trung?
Để trả lời câu hỏi này, chúng ta có thể tham khảo một bài viết kinh điển của Vitalik, nơi ông trình bày về nhiều lớp nghĩa của tính phi tập trung. Điểm mấu chốt của bài viết là phi tập trung bao gồm ba khía cạnh:
Phi tập trung về kiến trúc: Cần bao nhiêu nút ngừng hoạt động thì hệ thống mới dừng hoạt động?
Phi tập trung về logic: Các bộ phận của hệ thống có thể phát triển độc lập mà không ảnh hưởng đến chức năng tổng thể?
Phi tập trung về chính trị: Bao nhiêu người hoặc thực thể kiểm soát hệ thống này?
Ethereum rõ ràng là phi tập trung về kiến trúc và logic, vì nó phân bố trên nhiều nút, và các thành phần khác nhau (ví dụ cơ chế đồng thuận và tầng thực thi) có thể phát triển tương đối độc lập.
Về phi tập trung chính trị, tin tốt là không có thực thể đơn lẻ nào có thể tắt Ethereum, kể cả Vitalik. Nhưng không thể phủ nhận rằng vị trí then chốt của Vitalik trong việc định hình tầm nhìn và lộ trình có nghĩa là về mặt chính trị, có thể có sự đánh đổi.
Tôi cho rằng, để Ethereum tiếp tục đổi mới, chúng ta nên chấp nhận vai trò thực tế của Vitalik như một CTO, dù điều này có làm giảm đôi chút tính phi tập trung chính trị. Trước khi Ethereum trưởng thành ổn định như Bitcoin, cần có một nhân vật uy tín như vậy, người không chỉ ra quyết định dựa trên ưu nhược điểm kỹ thuật, mà còn đảm bảo các quyết định đó phù hợp với tầm nhìn dài hạn của Ethereum.
Không có vai trò như Vitalik, Ethereum có thể đối mặt với hai tình huống, và sự kiện EIP-3074 là một ví dụ sống động:
-
Bế tắc ra quyết định: Các bên không chịu nhượng bộ, dự án đình trệ, giống như tranh luận EIP-3074 phải chờ đến khi Vitalik can thiệp mới phá vỡ thế bế tắc.
-
Thiết kế hỗn loạn: Hệ thống có thể trở thành một đống linh tinh không ăn nhập, như trường hợp suýt xảy ra giữa EIP-3074 và EIP-4337 song song nhưng không tương thích.
Do đó, trong giai đoạn Ethereum vẫn đang phát triển nhanh chóng, sự lãnh đạo của Vitalik là then chốt để duy trì một hệ sinh thái vừa phi tập trung vừa không mất phương hướng.
Tầm quan trọng của cộng đồng
Tới đây, chúng ta gần như đã xây dựng xong một khuôn khổ hiểu biết toàn diện về quản trị Ethereum, nhưng vẫn còn một phần quan trọng chưa được đề cập – vai trò của cộng đồng.
Nếu Vitalik định hình tầm nhìn, các nhà nghiên cứu lập lộ trình, các nhà phát triển cốt lõi triển khai, vậy cộng đồng đóng vai trò gì? Chắc chắn không phải là vai trò phụ?
Thực tế, cộng đồng đóng vai trò trung tâm nhất. Bởi vì trước khi có tầm nhìn, tồn tại một thứ nền tảng hơn – đó là các giá trị. Chúng ta tụ họp thành cộng đồng vì chia sẻ các giá trị nhất định, và những giá trị này là nền tảng cho tầm nhìn của Vitalik, phải phù hợp với nhau, nếu không cộng đồng sẽ không tồn tại.
Có thể do ảnh hưởng từ hoàn cảnh lớn lên, hoặc cảm hứng từ trải nghiệm trước đó, mỗi người trong cộng đồng Ethereum, ở một khoảnh khắc nào đó, đã nhận ra giá trị của việc xây dựng một máy tính phi tập trung, không thể kiểm duyệt và ai cũng có thể tiếp cận được. Mỗi ngày chúng ta làm việc trên Ethereum là đang thực hành và khẳng định lại các giá trị đó, chính nhờ hành động này mà chúng ta trao sức sống và tính hợp pháp cho tầm nhìn, lộ trình và mã nguồn do Vitalik, các nhà nghiên cứu và nhà phát triển cốt lõi đề xuất.
Mô hình đơn giản hóa quản trị Ethereum: Khung VVRC
Hãy hình dung quản trị Ethereum như một cỗ máy được thiết kế tỉ mỉ, chúng ta đơn giản hóa nó thành bốn phần then chốt: Giá trị (Values), Tầm nhìn (Vision), Lộ trình (Roadmaps), Client (Clients), viết tắt là mô hình VVRC.
-
Giá trị (Values): Mọi thứ bắt đầu từ một bộ nguyên tắc và niềm tin cơ bản mà cộng đồng Ethereum cùng chia sẻ
-
Tầm nhìn (Vision): Vitalik với tư cách người sáng lập, dựa trên các giá trị cộng đồng, vẽ ra tầm nhìn phát triển tương lai của Ethereum.
-
Lộ trình (Roadmaps): Với tầm nhìn rõ ràng, các đội nghiên cứu bắt tay xây dựng các bước cụ thể để hiện thực hóa giấc mơ. Họ thiết kế các lộ trình kỹ thuật từng bước tiến tới mục tiêu.
-
Client (Clients): Cuối cùng, đội phát triển cốt lõi dựa trên lộ trình để viết mã và duy trì phần mềm client, đảm bảo mọi kế hoạch kỹ thuật trở thành hiện thực, cho phép người dùng và nhà phát triển sử dụng thực tế.
Quy trình này nghe có vẻ trôi chảy, nhưng thực tế phức tạp hơn. Ví dụ, các nhà phát triển cốt lõi thực tế nắm quyền quyết định cuối cùng, vì họ chịu trách nhiệm triển khai phần mềm. Vitalik và các nhà nghiên cứu khác chủ yếu đưa ra đề xuất, đôi khi đề xuất của họ có thể không được chấp nhận, như trường hợp EIP-3074 đã cho thấy.
Tổng thể, mô hình VVRC giúp chúng ta hiểu cách quản trị Ethereum vận hành lý tưởng, đồng thời nhắc nhở chúng ta cần liên tục điều chỉnh và hoàn thiện quy trình này, tránh tái diễn các vấn đề như sự kiện EIP-3074.
Làm thế nào để cải thiện quản trị Ethereum
Để tối ưu cấu trúc quản trị Ethereum, đảm bảo tránh lặp lại sai lầm như sự kiện EIP-3074/EIP-7702, tôi xin đề xuất một vài cải tiến:
Tăng tính minh bạch cho EIP: Đảm bảo các EIP đang được xem xét trở nên công khai và minh bạch hơn với cộng đồng, tránh tình trạng EIP-3074 được chấp thuận bất ngờ khiến mọi người bất ngờ. Thực tế, trạng thái EIP được ghi trên website EIPs không đồng bộ với tiến độ thảo luận tại ACD, do đó ngay cả khi các nhà phát triển cốt lõi đã đồng ý EIP-3074, trạng thái của nó vẫn hiển thị là "đang xem xét". Nên đề xuất thông báo trước cho cộng đồng về các EIP sắp được chấp thuận thông qua các kênh truyền thông xã hội của Quỹ Ethereum.
Tăng cường sự tham gia của cộng đồng: Thiết lập khoảng thời gian cố định trong các cuộc họp ACD để cộng đồng thảo luận về tác động của EIP đến các dự án cấp dưới, ngăn chặn tác động bất ngờ như EIP-3074 gây ra cho cộng đồng EIP-4337. Đồng thời, nếu các nhà nghiên cứu thấy phản hồi của họ không được các nhà phát triển cốt lõi chú ý, như trường hợp đội EIP-4337, họ có thể mời các thành viên cộng đồng tham gia thảo luận để tăng sức nặng lập trường.
Hiểu lẫn nhau, giao tiếp liên tục: Các nhà phát triển cốt lõi và nhà nghiên cứu phải hiểu nhau, họ đều là lực lượng then chốt trong quản trị, chỉ khác trọng tâm. Các nhà phát triển cốt lõi thông qua việc triển khai client có "quyền thực thi", tương đương "quyền biểu quyết". Các nhà nghiên cứu thông qua việc tích cực chia sẻ và thảo luận lộ trình của họ, giành được sự ủng hộ rộng rãi từ cộng đồng, tạo nên "ảnh hưởng lộ trình".
Khi hai bên bất đồng, các nhà phát triển cốt lõi có thể thiên về việc gạt bỏ ý tưởng của nhà nghiên cứu, như họ đã làm với đội EIP-4337. Nhưng hành động này dễ gây phản ứng ngược, vì khi xung đột xảy ra, cán cân quyền lực bị phá vỡ, sự hỗn loạn sau khi EIP-3074 được thông qua là minh chứng.
Ngược lại, khi nhà nghiên cứu gặp阻力, họ có thể chọn không hợp tác với các nhà phát triển cốt lõi nữa, đây cũng là một phần lý do ra đời quy trình RIP (Rollup Improvement Proposal) và việc tài khoản trừu tượng bản địa (EIP-7560) chủ yếu được thúc đẩy dưới dạng RIP thay vì EIP.
Mặc dù RIP hữu ích trong việc giúp L2 thử nghiệm các cập nhật giao thức khó áp dụng trực tiếp trên L1, nhưng nó không thể thay thế việc tham gia vào quy trình quản trị EIP. Các nhà nghiên cứu phải kiên trì giao tiếp với các nhà phát triển cốt lõi cho đến khi lộ trình đạt được sự đồng thuận.
Thông qua các biện pháp trên, chúng ta có thể nâng cao tính minh bạch trong quản trị, tăng cường sự tham gia của cộng đồng và thúc đẩy hợp tác hiệu quả giữa các nhà phát triển cốt lõi và nhà nghiên cứu, giảm thiểu các vấn đề quản trị có thể xảy ra trong tương lai.
Tổng kết
Sự kiện EIP-3074/EIP-7702 của Ethereum phơi bày sự phức tạp trong cấu trúc quản trị của nó: Ngoài quy trình quản trị chính thức (do các nhà phát triển cốt lõi thúc đẩy thông qua EIP và các đề xuất tại ACD), các lộ trình không chính thức do các nhà nghiên cứu đề xuất cũng có ảnh hưởng to lớn. Khi hai lực lượng này không hòa hợp, có thể dẫn đến bế tắc ra quyết định hoặc thay đổi đột ngột, và lúc đó vai trò của Vitalik trở nên đặc biệt then chốt, khi ông có thể dùng tầm nhìn của mình để điều phối các bên, giống như một thủ lĩnh tinh thần của dự án.
Chúng ta đơn giản hóa quản trị Ethereum thành một mô hình: Giá trị cộng đồng → Tầm nhìn của Vitalik → Lộ trình của đội nghiên cứu → Triển khai của nhà phát triển cốt lõi (mô hình VVRC). Chuỗi này cho thấy cách quyết định đi từ những ý tưởng rộng lớn dần đến hiện thực kỹ thuật cụ thể.
Để cải thiện hiệu quả quản trị, cần sửa chữa những vấn đề lệch khỏi mô hình lý tưởng này trong thực tế vận hành. Dù sao đi nữa, quản trị Ethereum tốt là cơ chế then chốt thúc đẩy dự án tiến lên. Sự kiện EIP-3074 như một ví dụ, phơi bày điểm yếu trong quản trị, mang lại cơ hội học hỏi và cải tiến, đảm bảo tương lai có thể đối phó tốt hơn với các thách thức tương tự, thúc đẩy Ethereum phát triển lành mạnh và bền vững.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@imTokenOfficial
