Về Vitalik và tác động của các lộ trình khác nhau đối với quy trình quản trị Ethereum
Tuyển chọn TechFlowTuyển chọn TechFlow
Về Vitalik và tác động của các lộ trình khác nhau đối với quy trình quản trị Ethereum
Bản đồ lộ trình công nghệ là lực lượng cốt lõi bị xem nhẹ trong quản trị Ethereum, và vai trò của Vitalik phù hợp hơn với vị trí CTO.
Chuyên sâu báo cáo Web3Tác giả: Derek Chiang, CEO của ZeroDev
Biên dịch: Faust, Geeker web3
Tóm tắt: Bài viết này là quan điểm của Derek Chiang, CEO của ZeroDev, sau khi Vitalik đề xuất EIP-7702 nhằm dung hòa mâu thuẫn giữa ERC-4337 và EIP-3074. Với góc nhìn từ một nhà sáng lập trong hệ sinh thái AA, bài viết nêu bật những vấn đề hiện tại trong mô hình quản trị Ethereum một cách khách quan và chính xác, thẳng thắn chỉ ra rằng:
Một trong những mâu thuẫn về quản trị trên Ethereum nằm ở chỗ lộ trình do các nhà nghiên cứu vạch ra thường mâu thuẫn với quan điểm của các nhóm phát triển client như Geth, và Vitalik đóng vai trò như CTO cuối cùng đưa ra quyết định.
Sau khi ghi nhận tích cực vai trò của Vitalik, Derek cũng chỉ ra những cải tiến mà Ethereum nên thực hiện trong mô hình quản trị của mình – điều này mang ý nghĩa tham khảo sâu sắc không chỉ với cộng đồng Ethereum mà cả cộng đồng Bitcoin.
Nội dung chính: Nếu bạn chưa theo dõi sự kiện liên quan đến AA (Trừu tượng tài khoản) trên Ethereum, đây là phần tổng hợp ngắn gọn:
Vài tuần trước, đề xuất EIP-3074 đã được các nhà phát triển cốt lõi của Ethereum phê duyệt và sẽ được đưa vào bản hard fork tiếp theo tên gọi «Pectra». Đề xuất này bổ sung hai opcode mới cho EVM, giúp tài khoản EOA trên Ethereum có trải nghiệm AA gần như nguyên bản.
Kể từ đó, nhiều người trong cộng đồng ERC-4337, đặc biệt là những người đề xuất 4337, đã phản đối mạnh mẽ EIP-3074, với lý do lo ngại về rủi ro bảo mật và sự không tương thích với lộ trình AA của Ethereum. Trước đây, lộ trình của Ethereum rõ ràng tập trung vào ERC-4337 và các đề xuất tương tự như 7560 (còn gọi là «nativeAA»).
Đầu tháng Năm, Vitalik đề xuất EIP-7702 như một phương án thay thế cho EIP-3074, tạo sự cân bằng giữa 4337 và 3074 — vừa mang lại trải nghiệm AA cho người dùng EOA, nhưng đồng thời tương thích hơn với ERC-4337 và phù hợp với «giải pháp cuối cùng cho AA» là 7560.
Hiện tại, các nhà phát triển cốt lõi đang xem xét EIP-7702, và kết quả thảo luận sơ bộ cũng như tâm lý cộng đồng cho thấy EIP-7702 rất có thể sẽ thay thế EIP-3074 như đã nêu ở trên.
Cá nhân tôi rất hài lòng với kết quả này: Người dùng EOA sẽ sớm được trải nghiệm các sản phẩm trong hệ sinh thái ERC-4337 và tận hưởng phần lớn lợi ích từ AA. Tuy nhiên, tôi không khỏi nghĩ rằng chúng ta hoàn toàn có thể đạt được kết quả này theo cách tốt hơn, và nhiều người trong vài tuần qua cũng đã chỉ ra điều đó. Tôi tin rằng nếu có quy trình quản trị tốt hơn, chúng ta đã có thể tiết kiệm rất nhiều công sức và đạt được mục tiêu nhanh hơn.
Trong bài viết này, tôi muốn:
-
Xác định đâu là vấn đề trong quy trình quản trị
-
Đưa ra một mô hình tư duy để hiểu quản trị Ethereum
-
Đề xuất các cải tiến nhằm tránh những sự cố quản trị tương tự trong tương lai
Tổng kết và suy ngẫm về sự kiện EIP-3074
Câu chuyện kể trên khiến nhiều người bất mãn vì những lý do sau:
EIP-3074 mất hàng năm trời mới được phê duyệt. Sau khi 3074 chính thức được thông qua, các nhà phát triển cốt lõi mới nhận được phản ứng dữ dội từ cộng đồng 4337.
Mặt khác, các tác giả của ERC-4337 đã nhiều lần bày tỏ lo ngại về EIP-3074 với đội ngũ cốt lõi Ethereum nhưng không thành công. Hiện tại, Ethereum đang lên kế hoạch hủy bỏ việc phê duyệt 3074 và thay thế bằng một EIP khác (7702).
Bản thân từng bước trong quy trình trên đều không sai:
-
Việc thảo luận một EIP có thể kéo dài vài năm là điều bình thường.
-
Một EIP bị từ chối sau khi được phê duyệt là điều bình thường.
-
Nếu phát hiện vấn đề mới, một EIP đã được phê duyệt vẫn có thể bị rút lại.
Tuy nhiên, sự việc có thể được giải quyết suôn sẻ hơn. Hãy tưởng tượng nếu mọi chuyện diễn ra như sau:
Trong quá trình thảo luận về 3074, cộng đồng 4337 đã chủ động tương tác với các nhà phát triển cốt lõi. Nếu giả định này đúng, thì chỉ có hai khả năng xảy ra:
-
Sau khi xem xét phản hồi từ cộng đồng 4337, đề xuất 3074 được phê duyệt (có thể kèm chỉnh sửa), lúc này cộng đồng 4337 sẽ chấp nhận 3074 và đội ngũ cốt lõi không cần phải hủy bỏ nó.
-
Hoặc 3074 chưa bao giờ được phê duyệt, nhưng cộng đồng 4337 và đội ngũ cốt lõi cùng nhau đề xuất một phương án làm hài lòng tất cả, giống như trường hợp 7702.
Mọi tiếng nói đều được lắng nghe, không có cú đảo chiều kịch tính. Điều đó thật tuyệt — vậy tại sao thực tế lại không như vậy?
Chuyện gì đã sai?
Nhìn lại toàn bộ quá trình, hai bên đều đổ lỗi cho nhau.
Các nhà phát triển cốt lõi (và tác giả EIP-3074) cho rằng đây là lỗi của «những người ủng hộ 4337» vì họ không tích cực tham gia vào quy trình thảo luận All Core Devs (ACD), nơi các EIP phải trải qua quá trình xem xét lâu dài trước khi được các đội phát triển client như Geth chấp nhận và triển khai.
Họ cho rằng trong suốt quá trình xem xét 3074, «những người ủng hộ 4337» hoàn toàn có thể tham gia và bày tỏ quan điểm, thay vì đợi đến khi 3074 được thông qua rồi mới phản đối. Rốt cuộc, toàn bộ quy trình ACD đều được lưu trữ công khai, các cuộc họp mở cửa cho tất cả, và TimBeiko còn tích cực đăng tóm tắt sau mỗi cuộc họp ACD. Vậy thì nếu những người ủng hộ 4337 quan tâm đến chủ đề này, tại sao họ không chủ động tham dự các cuộc họp?
Mặt khác, các thành viên cốt lõi của 4337 khẳng định họ luôn tham gia các cuộc họp ACD và phản đối 3074 hết mức có thể, nhưng các nhà phát triển cốt lõi không lắng nghe. Còn cộng đồng 4337 đa số cảm thấy bất ngờ — nhiều người nghĩ 3074 đã chết từ lâu, thậm chí không biết nó đang có nguy cơ được phê duyệt cao.
Nhiều người chỉ ra rằng quy trình ACD thiếu minh bạch, gây khó khăn cho những ai đang «làm việc nghiêm túc» trong cộng đồng Ethereum nhưng không kịp theo dõi cập nhật. Một số người còn cho rằng ACD nên chủ động lấy ý kiến từ các bên liên quan (ở đây là cộng đồng 4337).
Tuy nhiên, tôi cho rằng cả hai bên đều chưa chạm đến gốc rễ vấn đề. Đằng sau còn tồn tại một vấn đề sâu xa hơn, và trừ khi chúng ta giải quyết hoặc ít nhất thừa nhận điều này, chúng ta sẽ tiếp tục rơi vào các sự cố quản trị, các bên đổ lỗi cho nhau, điều đó hoàn toàn vô nghĩa.
Nguyên nhân gốc rễ của sự cố quản trị: Lộ trình
Khác với quan điểm phổ biến, gốc rễ của sự cố quản trị nằm ở chỗ ACD không phải là nguồn quyền lực quản trị duy nhất cho các cập nhật giao thức Ethereum. Nó đã bị thay thế bởi một nguồn quyền lực khác. Vấn đề nằm ở chỗ dù nguồn quyền lực kia ảnh hưởng lớn hơn ACD trong các chủ đề trọng yếu như AA hay mở rộng, nhưng lại hiếm khi được công nhận.
Trong bài viết này, tôi gọi lực lượng đó là «lộ trình».
Như tôi sẽ chỉ ra dưới đây, sự cố quản trị «3074-4337-7702» là một ví dụ điển hình cho việc quyền lực của «lộ trình» đè bẹp quyền lực của ACD. Khi nói về quản trị, nếu chúng ta nhận thấy một lực lượng vô hình đang áp đảo lực lượng hữu hình, chúng ta phải cực kỳ cảnh giác, vì cái vô hình thường khó giải thích và ít người chú ý đến, do đó cần phải phơi bày nó ra.
Lộ trình là gì?
Bất kỳ ai trong cộng đồng Ethereum chắc hẳn đều thường xuyên bắt gặp cụm từ «lộ trình», ví dụ như «lộ trình hướng tới rollup», «lộ trình ETH2.0», hay trong trường hợp này là «lộ trình AA».
Để minh họa quan điểm của tôi, hãy tưởng tượng một cuộc họp ACD, nơi các nhà phát triển cốt lõi đang thảo luận cách mở rộng Ethereum:
-
Một nhà phát triển cốt lõi tên Bob: Tôi ủng hộ EIP-1234, đề xuất tăng tốc độ tạo khối lên 10 lần, kích thước khối lên 10 lần, giảm phí xuống 100 lần.
-
Các nhà phát triển khác: …… Anh điên à?
Hãy suy nghĩ một chút. Tại sao đội ngũ cốt lõi lại từ chối ý kiến của Bob? Anh ấy chỉ đề xuất một phương án mở rộng trông rất hợp lý, và nhiều blockchain công khai như Solana, Aptos, Sui cũng làm như vậy để đạt TPS cao.
Lý do là vì EIP-1234 giả định này vi phạm «lộ trình hướng tới rollup» của Ethereum, theo đó vấn đề then chốt cho phi tập trung là người dùng bình thường có thể chạy node với chi phí thấp, do đó EIP giả định này không thể được chấp nhận vì nó sẽ làm tăng đáng kể chi phí vận hành node Ethereum.
Tôi dùng ví dụ này để minh họa rằng các nhà phát triển cốt lõi tham gia quy trình quản trị ACD và quyết định cập nhật giao thức đang chịu sự hướng dẫn của một lực lượng cao hơn, mà tôi gọi là «lộ trình». Hiện nay có nhiều «lộ trình» như «lộ trình mở rộng», «lộ trình AA», «lộ trình MEV», chúng cùng cấu thành nên lộ trình tổng thể của Ethereum, và các nhà phát triển cốt lõi phải dựa vào đó để ra quyết định.
Khi quan điểm của nhà phát triển cốt lõi mâu thuẫn với lộ trình
Do lộ trình không phải là thành phần chính thức trong quy trình quản trị Ethereum, nên không đảm bảo rằng đội ngũ cốt lõi sẽ tuân thủ. Hơn nữa, không có quy trình «phê duyệt» chính thức nào dành cho lộ trình, do đó không phải lộ trình nào cũng có «tính chính thống» như nhau. Các nhà nghiên cứu đằng sau lộ trình phải nỗ lực thuyết phục các nhà phát triển cốt lõi và cộng đồng để giành được «tính chính thống», từ đó có được sự ủng hộ của đội ngũ phát triển cốt lõi.
Trong lĩnh vực AA và trừu tượng tài khoản, chính Vitalik đã nhiều lần thúc đẩy lộ trình AA tập trung vào 4337, nhưng nhìn chung, chủ yếu là nhóm đứng sau 4337, đặc biệt là Yoav và Dror, đã tích cực vận động lộ trình này trên diễn đàn và tại các cuộc họp ACD.
Tuy nhiên, dù đã nỗ lực, một số nhà phát triển cốt lõi vẫn phản đối mạnh mẽ lộ trình AA tập trung vào 4337. Họ cho rằng 7560 (phiên bản native của 4337 mà các client Ethereum sẽ triển khai trong tương lai) quá phức tạp và không phải là giải pháp duy nhất cho «kết thúc của AA». Cuối cùng, ACD quyết định phê duyệt 3074, bất chấp sự phản đối từ nhóm 4337, những người cho rằng 3074 sẽ làm phân mảnh hệ sinh thái AA.
Sau khi 3074 được phê duyệt, toàn bộ cộng đồng 4337 phản ứng dữ dội, buộc các nhà phát triển cốt lõi phải tái thảo luận về 3074. Cuộc thảo luận sau đó rơi vào bế tắc, tác giả 4337 và 3074 không thuyết phục được nhau, Vitalik đề xuất EIP-7702 như một phương án thay thế cho 3074, rõ ràng tương thích với «kết thúc của AA» dựa trên 4337, từ đó hóa giải xung đột và đưa kết quả cuối cùng phù hợp với lộ trình AA.
Vai trò của Vitalik: CTO thực tế của Ethereum
Dù tự nhận là nhà nghiên cứu, câu chuyện trên cho thấy rõ ràng rằng Vitalik sở hữu quyền lực quản trị khác biệt hoàn toàn so với các nhà nghiên cứu khác. Vì vậy, câu hỏi đặt ra là: Vitalik đóng vai trò gì trong quản trị Ethereum?
Theo cá nhân tôi, việc coi Vitalik như CTO của một công ty cực kỳ lớn là hợp lý (nhân tiện, giả sử Ethereum «công ty» này không có CEO để sát với thực tế hơn).
Nếu bạn từng làm việc tại một công ty công nghệ có hơn 50 nhân viên, bạn biết rằng CTO không thể tham gia vào mọi quyết định kỹ thuật. Khi công ty đạt đến quy mô nhất định, quy trình ra quyết định kỹ thuật chắc chắn phải phân tán — thường mỗi lĩnh vực sản phẩm/dịch vụ sẽ có một nhóm chuyên trách, và nhóm đó tự do quyết định chi tiết.
Hơn nữa, CTO không nhất thiết là chuyên gia hàng đầu trong mọi (hoặc bất kỳ) lĩnh vực. Trong công ty có thể có những kỹ sư giỏi hơn CTO ở một số lĩnh vực cụ thể, do đó, trong các tranh luận chi tiết kỹ thuật, thường chính các kỹ sư đưa ra quyết định cuối cùng.
Tuy nhiên, CTO mới là người định ra tầm nhìn kỹ thuật. Việc thực thi tầm nhìn đó được giao cho các nhà phát triển.
Dù đây không phải là phép so sánh hoàn hảo, tôi cho rằng nó hợp lý để khái quá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ể. Ông cũng không phải chuyên gia hàng đầu ở mọi lĩnh vực. Nhưng ông có ảnh hưởng áp đảo trong việc định hình lộ trình cho tất cả các giải pháp then chốt (mở rộng, AA, POS…) của Ethereum, không chỉ nhờ chuyên môn kỹ thuật mà còn vì ông là người phán xét cuối cùng xem liệu một lộ trình có phù hợp với tầm nhìn Ethereum (tầm nhìn của ông) hay không.
Mọi sản phẩm thành công đều bắt đầu từ một tầm nhìn
Nếu việc coi Vitalik là CTO của Ethereum chưa đủ gây tranh cãi, thì phần gây tranh cãi nhất sắp tới: Chúng ta nên chấp nhận vai trò CTO của Vitalik.
Là một người sáng lập startup, tôi tin rằng đằng sau mọi sản phẩm thành công đều phải có một tầm nhìn dài hạn mạch lạc — đúng vậy, Ethereum cũng là một «sản phẩm», vì nó giải quyết các vấn đề thực tế cho người dùng thực tế. Và một tầm nhìn mạch lạc phải do một nhóm nhỏ xây dựng, thường là người sáng lập startup, và thường chỉ có một người.
Điều tuyệt vời ở Ethereum là mặc dù nó là một hệ thống cực kỳ phức tạp với vô số thành phần, nhưng các thành phần này kết hợp hoàn hảo để tạo thành một máy tính phi tập trung hoạt động hiệu quả, xử lý giao dịch trị giá hàng tỷ đô la mỗi ngày.
Chúng ta có được ngày hôm nay không phải nhờ thiết kế từ một ủy ban nào đó, mà chính là nhờ Vitalik đã tích cực lãnh đạo với tầm nhìn vượt trội, giúp chúng ta xây dựng nên Ethereum mạch lạc và đẹp đẽ như ngày nay. Ethereum là ý tưởng của Vitalik từ năm 2015, và vẫn như vậy cho đến tận bây giờ.
Tất nhiên, điều này không nhằm hạ thấp đóng góp của các nhà nghiên cứu và kỹ sư khác, những người đã đóng vai trò lớn trong thành tựu hiện tại của Ethereum. Tuy nhiên, điều này không mâu thuẫn, vì Ethereum là hiện thực hóa tầm nhìn của Vitalik, vượt trội hơn bất kỳ tầm nhìn cá nhân nào khác về mặt quy mô.
Thành thật mà nói, bạn có thể phàn nàn gì? Khi bị thu hút bởi sự cởi mở, khả năng chống kiểm duyệt và tốc độ đổi mới của hệ sinh thái Ethereum, bạn có từng phàn nàn rằng nó bắt nguồn từ tầm nhìn của Vitalik? Có lẽ bạn chưa từng, vì bạn chưa nghĩ đến điều đó — nhưng giờ thì có, vậy bạn thực sự bận tâm chuyện này không?
Vậy còn phi tập trung thì sao?
Nhưng bạn sẽ nói, còn phi tập trung thì sao? Nếu một người có quyền lực áp đảo như vậy đối với Ethereum, làm sao chúng ta có thể nói nó phi tập trung?
Để trả lời, chúng ta phải quay lại bài viết kinh điển của Vitalik về ba loại phi tập trung:
-
Phi tập trung về kiến trúc: Cần bao nhiêu nút lỗi để hệ thống ngừng hoạt động?
-
Phi tập trung về logic: Các thành phần con của hệ thống có thể phát triển độc lập trong khi hệ thống tổng thể vẫn hoạt động ổn định, hay phải phối hợp chặt chẽ?
-
Phi tập trung về chính trị: Cuối cùng có bao nhiêu cá nhân hoặc tổ chức kiểm soát hệ thống?
Theo các định nghĩa này, Ethereum rõ ràng phi tập trung về kiến trúc, và có thể nói cũng phi tập trung về logic do các thành phần ít phụ thuộc lẫn nhau (ví dụ như lớp đồng thuận và lớp thực thi).
Về phi tập trung chính trị, điều tốt là không cá nhân hay tổ chức nào có thể tắt Ethereum, kể cả Vitalik. Tuy nhiên, có người cho rằng mức độ phi tập trung chính trị của Ethereum không cao như người ta tưởng, vì Vitalik đóng vai trò lớn trong việc định hình tầm nhìn và lộ trình của Ethereum.
Tuy nhiên, tôi cho rằng nếu chúng ta muốn Ethereum tiếp tục đổi mới, chúng ta phải chấp nhận Vitalik với vai trò CTO thực tế, ngay cả khi điều đó có nghĩa là đánh đổi một phần phi tập trung chính trị.
Nếu Ethereum thực sự «cứng nhắc» như Bitcoin, gần như không thể thay đổi, thì có lẽ Vitalik đã nghỉ hưu từ lâu. Nhưng trước khi đạt đến bước đó, điều quan trọng là phải có một nhân vật được tôn trọng, đáng tin cậy để đưa ra phán xét về các quyết định kỹ thuật, không chỉ dựa trên việc giải pháp kỹ thuật có ưu việt hay không, mà còn xem liệu nó có phù hợp với tầm nhìn Ethereum hay không.
Nếu không có một nhân vật như Vitalik, thì chỉ có thể xảy ra hai kết cục, và câu chuyện quanh 3074 minh họa rõ điều đó:
-
Quy trình quản trị Ethereum có thể rơi vào bế tắc vô tận, các bên không chịu nhượng bộ, không ai tiến triển được, như tình trạng tranh luận 3074 trước khi Vitalik can thiệp.
-
Hoặc, Ethereum có thể trở thành một «Frankenstein» thiết kế rời rạc. Như đã nói, 3074 và 4337 có thể bất phân thắng bại, dẫn đến hệ sinh thái AA bị chia cắt thành hai không gian song song không tương thích.
Vai trò của cộng đồng
Sau những suy ngẫm trên, chúng ta gần như đã vẽ ra một mô hình quản trị Ethereum hoàn chỉnh, nhưng vẫn còn một thiếu sót rõ rệt — cộng đồng.
Nếu Vitalik định hình tầm nhìn, các nhà nghiên cứu định hình lộ trình, các nhà phát triển cốt lõi triển khai lộ trình, thì cộng đồng đóng vai trò gì? Chắc chắn không phải là ngồi yên?
May mắn thay, cộng đồng thực sự đóng vai trò quan trọng nhất. Bởi vì trước khi có tầm nhìn, đã có các giá trị. Chúng ta tụ họp thành cộng đồng vì gắn bó với những giá trị nhất định, và tầm nhìn của Vitalik cuối cùng phải phù hợp với các giá trị đó, nếu không sẽ mất sự ủng hộ từ cộng đồng.
Tất cả mọi người trong cộng đồng Ethereum đều tin rằng việc sở hữu một máy tính phi tập trung, có thể truy cập cho tất cả, không thể kiểm duyệt và trung lập đáng tin cậy là có lợi cho thế giới. Mỗi ngày, qua công việc trên Ethereum, chúng ta duy trì và khẳng định các giá trị này, và qua đó trao tính chính thống 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 quản trị VVRC của Ethereum
Vì vậy, đây là mô hình tư duy đầy đủ về quản trị Ethereum: Giá trị ⇒ Tầm nhìn ⇒ Lộ trình ⇒ Client, gọi tắt là VVRC:
-
V == Giá trị == Cộng đồng;
-
V == Tầm nhìn == Vitalik;
-
R == Lộ trình == Nhà nghiên cứu;
-
C == Client == Nhà phát triển cốt lõi;
Chúng hoạt động như sau:
-
Cộng đồng tập hợp quanh một số giá trị nhất định.
-
Vitalik thể hiện một tầm nhìn phù hợp với các giá trị đó.
-
Các nhà nghiên cứu xây dựng lộ trình dựa trên tầm nhìn.
-
Các nhà phát triển cốt lõi triển khai client theo lộ trình.
Tất nhiên, thực tế phức tạp hơn bất kỳ mô hình đơn giản nào. Thực tế, các nhà phát triển cốt lõi là nhóm duy nhất có thể «bỏ phiếu» thực sự cho một đề xuất thông qua việc thay đổi mã nguồn client. Vitalik và các nhà nghiên cứu khác chỉ đóng vai trò cố vấn, đôi khi ý kiến của họ không được các nhà phát triển cốt lõi chấp nhận — và đó chính là lý do EIP-3074 được phê duyệt.
Dù vậy, tôi cho rằng mô hình VVRC hợp lý trong việc mô tả cách quản trị Ethereum thường hoạt động, và chúng ta cần «gỡ lỗi» quy trình này để không còn xảy ra sự cố như EIP-3074.
Cách cải thiện mô hình quản trị Ethereum
Bây giờ chúng ta đã có một mô hình tư duy về cách hoạt động của quy trình quản trị Ethereum, đây là một số ý tưởng để cải tiến:
-
Cần nâng cao tính minh bạch về tiến độ thảo luận các EIP đang được xem xét. Toàn bộ cộng đồng không nên cảm thấy «bất ngờ» về việc một EIP được chấp thuận; việc phê duyệt 3074 gây sốc như vậy không nên tái diễn.
Hiện tại, trạng thái «status» của EIP trên trang web EIP không phản ánh đúng tiến độ trong quy trình ACD. Đó là lý do tại sao nó vẫn hiển thị 3074 ở trạng thái «được xem xét», dù các nhà phát triển cốt lõi đã bỏ phiếu thông qua, và thậm chí không có dấu hiệu nào cho thấy nó từng được xem xét để phê duyệt.
Lý tưởng nhất, khi một EIP sắp được chấp thuận, Quỹ Ethereum nên tuyên bố công khai và rõ ràng trên mạng xã hội để nâng cao nhận thức cộng đồng.
-
Đôi khi các nhà phát triển cốt lõi có thể đánh giá thấp tác động của một EIP cụ thể đến các dự án và người dùng phía dưới, như trường hợp của cộng đồng 3074 và 4337. Do thời gian họp ACD có hạn và phải phối hợp múi giờ, thường chỉ những người «liên quan trực tiếp» mới được phát biểu.
Dù vậy, thỉnh thoảng dành thời gian phát biểu cho các thành viên cộng đồng để bình luận về tác động của một EIP sau khi được thông qua là điều có ý nghĩa.
Nếu các nhà nghiên cứu cảm thấy ý kiến của họ không được các nhà phát triển cốt lõi tiếp nhận, như trường hợp 4337, họ có thể mời các thành viên cộng đồng tham gia để củng cố lập luận của mình.
-
Điều quan trọng là các nhà phát triển cốt lõi và các nhà nghiên cứu phải thừa nhận lẫn nhau, dù sức mạnh khác nhau, nhưng đều là một phần của quyền lực quản trị Ethereum. Các nhà phát triển cốt lõi nắm quyền thay đổi và cập nhật client Ethereum — đây là quyền lực duy nhất có thể «bỏ phiếu» bằng cách thay đổi giao thức. Các nhà nghiên cứu nắm quyền thay đổi và diễn giải lộ trình, thường nhận được sự ủng hộ công chúng lớn hơn nhờ tích cực chia sẻ và viết về ý tưởng của họ.
Khi hai lực lượng này xung đột, các nhà phát triển cốt lõi có xu hướng gạt bỏ ý kiến nhà nghiên cứu, ví dụ như gạt bỏ phản đối từ nhóm 4337. Tuy nhiên, hành động này có thể gây xung đột, vì khi hai lực lượng va chạm, hệ thống trở nên bất ổn — như những diễn biến kịch tính sau khi 3074 được phê duyệt.
Tương tự, khi gặp phản kháng, các nhà nghiên cứu có thể có xu hướng từ bỏ hợp tác với nhà phát triển cốt lõi — theo tôi, đây là một phần lý do ra đời quy trình RIP, và cũng là lý do tại sao native AA (7560) hiện chủ yếu được quảng bá như một RIP chứ không phải EIP.
Mặc dù thử nghiệm các cập nhật giao thức gây tranh cãi trên L2 có lợi, chúng ta không thể coi RIP là thay thế cho việc tham gia quy trình quản trị EIP. Các nhà nghiên cứu phải tiếp tục hợp tác với các nhà phát triển cốt lõi cho đến khi giá trị của cả hai hoàn toàn thống nhất trong lộ trình.
Kết luận
Sự kiện 3074/7702 phơi bày cách quản trị Ethereum thực sự vận hành — ngoài quyền lực quản trị rõ ràng do các nhà phát triển cốt lõi thúc đẩy qua quy trình EIP/ACD, còn có quyền lực ẩn danh do các nhà nghiên cứu thúc đẩy qua lộ trình. Khi các quyền lực này lệch pha, chúng ta thấy bế tắc và giằng co, và có thể cần một lực lượng thứ ba — Vitalik — để phá vỡ thế cân bằng.
Tiếp đó, chúng tôi cho rằng Vitalik đại diện cho một lực lượng độc đáo — «tầm nhìn» của Ethereum, vốn là nền tảng cho tính chính thống của mọi lộ trình. Chúng tôi so sánh Vitalik với CTO của một công ty lớn, thừa nhận vai trò CTO giả định của ông là cần thiết để Ethereum duy trì tốc độ đổi mới, ngăn Ethereum suy thoái thành một «Frankenstein» rời rạc.
Cuối cùng, chúng tôi đề xuất mô hình VVRC để mô tả mô hình quản trị Ethereum: Giá trị (cộng đồng) ⇒ Tầm nhìn (Vitalik) ⇒ Lộ trình (nhà nghiên cứu) ⇒ Client (nhà phát triển cốt lõi). Sau đó, chúng tôi đề xuất các phương pháp để khắc phục «lỗi» trong mô hình này.
Quản trị Ethereum là «cỗ máy chế tạo cỗ máy» — để Ethereum hoạt động đúng, chúng ta phải quản trị hợp lý. Vì vậy, 3074 là một trường hợp quý giá về sự cố quản trị, và tôi hy vọng cộng đồng Ethereum có
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
@godrealmx
