Giải thích về quản trị cốt lõi của Ethereum

Một bài thuyết trình của Nixo Rokish từ Tổ chức Ethereum tại ETHBoulder, giải thích về quản trị giao thức cốt lõi của Ethereum, cách các phân nhánh cứng được điều phối, những hiểu lầm phổ biến về việc ai kiểm soát Ethereum và cách tham gia vào quy trình quản trị.

Bản ghi lời thoại này là một bản sao dễ tiếp cận của bản ghi lời thoại video gốc (opens in a new tab) được xuất bản bởi EthBoulder. Nó đã được chỉnh sửa đôi chút để dễ đọc hơn.

Giới thiệu (0:12)

Cảm ơn cả sáu người bạn của tôi đã đến dự. Được rồi. Hôm nay tôi sẽ nói với các bạn về quản trị cốt lõi của Ethereum. Tên tôi là Nixo. Tôi dẫn dắt nhóm hỗ trợ giao thức tại EF (Tổ chức Ethereum). Trong số tất cả các nhiệm vụ của chúng tôi, một trong những nhiệm vụ đó là làm cho quy trình quản trị trở nên rõ ràng và dễ điều hướng hơn cho tất cả những người khác tham gia vào những việc này vì Ethereum thực sự bao gồm nhiều thứ hơn là chỉ các nhà phát triển cốt lõi của nó.

Vì vậy, đây là dàn ý của bài nói chuyện. Chúng ta sẽ nói về quản trị cốt lõi là gì. Chúng ta sẽ nói về những hiểu lầm, cách quản trị Ethereum hiện đang hoạt động. Chúng ta sẽ đề cập đến cách nó so sánh với các hệ thống quản trị phi tập trung khác, lý do tại sao các nhà xây dựng nên quan tâm và các cách thức thực tế để tham gia.

Vậy, quản trị giao thức cốt lõi là gì? Tôi chạy một nút. Điều đó có nghĩa là tôi có một phần cứng, một máy tính ở nhà nơi tôi chạy phần mềm Ethereum. Khi tôi thiết lập phần mềm Ethereum này, tôi đã phải chọn các máy khách sẽ chạy phần mềm đó. Ethereum khá độc đáo ở chỗ nó có nhiều máy khách để đảm bảo sự đa dạng máy khách. Điểm mấu chốt của việc đó là nếu một máy khách ngừng hoạt động, nếu có lỗi trong một máy khách, toàn bộ mạng lưới sẽ không bị sập. Có những Chuỗi khối khác cũng có các máy khách khác. Tuy nhiên, Ethereum là mạng duy nhất được thiết lập theo cách thực sự bảo vệ chúng ta khỏi các lỗi. Vì vậy, nếu bạn nhìn vào Solana chẳng hạn, Solana có một máy khách khác, tôi nghĩ nó được gọi là GTO, nhưng nó chỉ có 20–21% tỷ lệ áp dụng. Vì vậy, nếu máy khách chiếm đa số ngừng hoạt động, Chuỗi sẽ bị sập. Và chúng ta đã thấy các mạng lưới khác bị sập. Và đó là lý do tại sao Ethereum là Chuỗi khối an toàn và có khả năng phục hồi tốt nhất.

Vì vậy, câu hỏi đặt ra là làm thế nào để bạn đưa các thay đổi vào Ethereum khi bạn phải điều phối với rất nhiều máy khách khác nhau. Đầu tiên, chúng ta sẽ phân biệt giữa phân nhánh cứng và phân nhánh mềm. Một phân nhánh mềm không yêu cầu sự điều phối như một phân nhánh cứng. Ethereum chủ yếu hoạt động với các phân nhánh cứng. Về cơ bản, phân nhánh cứng là tất cả các máy khách xây dựng một phiên bản Ethereum mới và quyết định tại một thời điểm được cấu hình trước để khởi chạy phiên bản Ethereum mới này. Nó vẫn là Ethereum nhưng có các tính năng mới. Nó có các tính năng khác biệt. Và tất cả những người vận hành nút như tôi, những người đang chạy các nút ở nhà hoặc các nhà vận hành chuyên nghiệp đều phải chấp nhận phiên bản Ethereum mới đó. Họ phải nâng cấp nút của mình hoặc cập nhật các nút của họ để bao gồm phần mềm mới đó.

Vậy làm thế nào để họ quyết định những tính năng nào sẽ được đưa vào các phân nhánh cứng đó? Họ phải thống nhất về các ưu tiên để phân bổ thời gian và nguồn lực của mình vì họ có thời gian và nguồn lực hữu hạn để phân bổ vào đó. Họ ưu tiên những thứ như lỗ hổng bảo mật hoặc bản vá bảo mật, những thứ như UX (trải nghiệm người dùng) — nếu có một Chuỗi khối khác đang cạnh tranh với chúng ta, chúng ta cần trở nên cạnh tranh với những Chuỗi khối khác đó. Vì vậy, một trong những điều mà họ xem xét là bất kỳ tính năng nào được đưa vào đều phải tương thích chuyển tiếp với các mục tiêu tiềm năng sắp tới trong lộ trình.

Năm ngoái đã có một sự việc thực sự gây tranh cãi xảy ra. Bạn có thể đã nghe nói về nó. Nó được gọi là EOF. Đó là EVM Object Format (Định dạng Đối tượng EVM). Đó là một tập hợp các tính năng dự kiến sẽ được đưa vào phân nhánh cứng Fusaka — Pectra, Fusaka, tôi nghĩ là cả hai — nhưng nó đã bị chia tách. Và một trong nhiều nguyên nhân khiến nó bị loại khỏi phân nhánh đó là vì Vitalik đã đăng một bài viết về tiềm năng Ethereum áp dụng RISC-V. Rất nhiều người đọc bài đó đã xem xét và kiểu như, được rồi, nếu chúng ta áp dụng RISC-V thì các tính năng mà chúng ta đang xem xét trong EOF sẽ đi kèm sẵn với RISC-V. Vậy tại sao chúng ta lại thêm sự phức tạp này vào giao thức? Tại sao chúng ta lại dồn tất cả các nguồn lực của nhà phát triển máy khách vào thứ này? Nó sẽ trở nên vô nghĩa nếu cuối cùng chúng ta chuyển sang RISC-V.

Vì vậy, đó giống như giọt nước tràn ly đối với EOF và cuối cùng nó đã bị loại khỏi phân nhánh. Một điều khác mà họ phải xem xét là nó phải được viết và kiểm tra nghiêm ngặt bằng sáu ngôn ngữ khác nhau vì các máy khách này được viết bằng sáu ngôn ngữ khác nhau. Vì vậy, đó là một ma trận thử nghiệm thực sự lớn để họ làm việc. Và vì điều đó, mọi lựa chọn thiết kế nhỏ nhất đều trở thành chủ đề tranh luận mà không có cơ quan thẩm quyền nào để giải quyết các bất đồng. Vì vậy, câu hỏi được đặt ra là ai sẽ quyết định — đó chính là mấu chốt của quản trị.

Những hiểu lầm (5:23)

Điều đó đưa chúng ta đến những hiểu lầm và chúng ta sẽ giải quyết một số trong số này. Một là Vitalik quyết định những gì được đưa vào giao thức Ethereum. Một hệ quả của điều đó là EF kiểm soát mọi thứ. Và điều thứ ba là tất cả đều là những thỏa thuận ngầm — những người trong cuộc, những người kỳ cựu (OG) đưa ra những quyết định này.

Vậy điều đầu tiên: Vitalik quyết định. Tôi chỉ chọn ra một nhóm nhỏ các EIP đang bị đình trệ do Vitalik là tác giả. Điều này có nghĩa là Vitalik đã ngồi xuống, anh ấy viết một đề xuất và anh ấy nói rằng tôi muốn những thứ này được đưa vào Ethereum và không ai đồng ý — những thứ này chỉ nằm im ở đó. Anh ấy đã không thể đưa những thứ này vào giao thức. Vì vậy, không phải mọi thứ anh ấy đề xuất đều tự động được đưa vào.

Một hệ quả của điều đó là Tổ chức Ethereum kiểm soát mọi thứ. Tôi sẽ chọn một ví dụ cụ thể về một thời điểm mà tôi nghĩ là mâu thuẫn với điều đó. Vào năm 2024, đã có rất nhiều cuộc thảo luận về giới hạn gas. Và lý do cho điều đó là vào năm 2022 trong The Merge, chúng tôi đã tăng giới hạn gas lên 30 triệu. Đó là mức tính toán tối đa được phép trong một khối. Và sau đó chúng tôi gần như không đụng đến nó trong một thời gian vì nó không thực sự là một nút thắt cổ chai khiến mọi người phải nói rằng, "Đây là lý do tại sao tôi không chuyển sang Ethereum" hoặc "Điều này đang hạn chế trường hợp sử dụng Ethereum hiện tại của tôi."

Và vào cuối năm 2023, đầu năm 2024, có một câu chuyện rằng Solana đang đến. Nó sẽ đánh bại Ethereum. Và vì vậy mọi người đang suy nghĩ về việc Ethereum có thể làm gì để tăng tốc. Và một trong những điều đó là hãy bơm chỉ số Gas này lên. Và vào thời điểm đó, EF và các nhà phát triển máy khách kiểu như, "Chúng tôi có những thứ khác phải lo. Dù sao cũng cảm ơn." Nhưng hai người này, Eric Connor và Mariano Conti, đã bước vào và nói, "Không, chúng ta sẽ tăng giới hạn gas." Giới hạn gas là một thông số do trình xác thực kiểm soát. Và vì vậy họ có thể bắt đầu nói chuyện với các trình xác thực, các nhà vận hành chuyên nghiệp và nói, "Này, hãy tăng giới hạn gas của bạn lên."

Và đến một lúc nào đó, có đủ sự chấp nhận đến mức EF và các máy khách phải thốt lên, "Ồ, chúng ta phải chú ý đến điều này. Chúng ta phải đảm bảo những gì họ đang làm là an toàn và giá trị mà cuối cùng họ nâng lên sẽ là một điều an toàn cho mạng lưới." Vì vậy, họ đã phải phân bổ lại các nguồn lực của mình. Nethermind đã đưa ra khuôn khổ thử nghiệm này. EF đã thực hiện rất nhiều công việc ở Berlin. Tất cả các nhà phát triển máy khách đều đang đo lường hiệu suất của việc này. Và vì vậy tôi thích điều này vì nó đã buộc EF phải hành động trong việc quyết định những gì được ưu tiên.

Và tôi thích dòng tweet ngớ ngẩn mà tôi đã chụp màn hình ở đây vì nó giống như một hãng tin ngẫu nhiên nào đó gọi Eric Connor và Mariano Conti là các nhà phát triển cốt lõi. Họ không phải là nhà phát triển cốt lõi. Eric Connor là một người tham gia stake và là một thành viên cộng đồng. Mariano Conti là một cựu nhà phát triển ứng dụng MakerDAO. Nhưng họ lại được gọi là nhà phát triển cốt lõi vì quá trình phát triển Ethereum thực sự nằm ngoài thế giới của cách phần mềm truyền thống hoạt động và vì vậy họ thấy một thông số cốt lõi bị sửa đổi và họ kiểu như, "Ồ, đây chắc hẳn là các nhà phát triển cốt lõi." Họ không phải vậy. Vì vậy, đây chỉ là một ví dụ về việc các thành viên cộng đồng bước vào và nói rằng chúng tôi muốn thấy sự thay đổi này và biến nó thành hiện thực.

Tất cả đều là những thỏa thuận ngầm, những người trong cuộc, những người kỳ cựu — tôi hiểu thêm một chút lý do tại sao đây lại là một sự hiểu lầm vì về cơ bản bạn đến tham gia các cuộc gọi quản trị này, có hàng trăm người trong các cuộc gọi quản trị này. Có vẻ như tất cả họ đều rất thoải mái với những gì đang diễn ra. Bạn thì lạc lõng. Bạn không có ý niệm gì về cách những quyết định này được đưa ra. Bạn kiểu như, "Đã đến lượt tôi nói chưa?" Và có cảm giác như mọi người đang lắng nghe cùng 10 người đó để đưa ra những quyết định này.

Chế độ nhân tài và số liệu thống kê tham gia (10:18)

Nhưng sự thật là quá trình phát triển Ethereum mang tính trọng dụng nhân tài nhiều hơn những gì tôi từng thấy trong hầu hết các quá trình phát triển phần mềm. Tất cả những người trên ảnh chụp màn hình này — đây là một trong ba ảnh trong cuộc gọi ACD ngẫu nhiên này mà tôi quyết định chụp lại — không ai trong số những người này được chỉ định ở đây. Mọi người chỉ đơn giản là những người đã xuất hiện. Họ là những nhà phát triển đã dành rất nhiều thời gian cho giao thức này. Họ là những người được mọi người công nhận là những nhà phát triển tài năng trong không gian này, liên tục đưa ra những quyết định đúng đắn, và không ai trong số này được chỉ định ở đây.

Vì vậy, tôi chỉ mới gia nhập EF hơn một năm trước. Tôi đã lấy những số liệu thống kê này. Chúng chỉ tính từ tháng 3 năm 2025. Tức là chưa đầy một năm. Số lượng người tham dự trung bình của All Core Dev (Tất cả các nhà phát triển cốt lõi) — đó là các cuộc gọi quản trị — là 98. Vì vậy, trung bình có 98 người trong các cuộc gọi này. Số lượng người tham dự tối đa trong một cuộc gọi kể từ đó là 153. Tôi nghĩ đó là ngày mà chúng tôi quyết định ngày ra mắt Mạng chính Pectra. Và tổng số người tham dự duy nhất là 567 chỉ trong năm ngoái. Tôi thực sự thích số liệu đó vì nó cho thấy rằng không phải lúc nào cũng là 100 người đó tham gia các cuộc gọi này. Các nhà phát triển ứng dụng, nhà nghiên cứu này, ai đó nghe về một tính năng nào đó đang được thảo luận, họ xuất hiện để lên tiếng phản đối hoặc ủng hộ nó và sau đó họ không đến tham gia một cuộc gọi nào khác nữa.

Quy trình quản trị hoạt động như thế nào (11:52)

Vì vậy, đây là một slide khá khô khan nhưng tôi nghĩ điều quan trọng là phải xem qua — đây là cách quản trị của Ethereum hiện đang hoạt động. Vì vậy, khi một trong những phân nhánh này đang được thảo luận, điều đầu tiên xảy ra là mọi người trong khoảng thời gian được phân bổ này có thể gửi đề xuất tiêu điểm của họ. Đề xuất tiêu điểm là tính năng chính mà chúng tôi muốn mọi người tập trung vào cho phân nhánh này. Người này có thể là một thành viên cộng đồng, một nhà nghiên cứu, một nhà phát triển cốt lõi — thực sự là bất kỳ ai gửi một trong những đề xuất tiêu điểm này. Sau đó, khoảng thời gian kết thúc và trên các cuộc gọi quản trị, chúng tôi sẽ thảo luận xem đề xuất nào trong số này là hợp lý. Mọi người đưa ra lập luận của mình, mọi người tranh luận và có sự đồng thuận về việc chúng ta nên chọn cái nào cho phân nhánh sắp tới đó.

Sau đó, họ chọn các tính năng phụ. Tức là những thứ nhỏ hơn không thực sự cần phải là những tính năng chính thúc đẩy phân nhánh này. Và trong suốt thời gian này, chúng tôi có các mạng phát triển dành riêng cho từng tính năng. Một mạng phát triển giống như một mạng thử nghiệm — một mạng thử nghiệm riêng tư để các nhà phát triển kiểm tra các tính năng này và đảm bảo rằng chúng thực sự hoạt động trên Ethereum. Và sau đó đến một lúc nào đó sẽ có sự đóng băng tính năng. Vì vậy, chúng tôi đã thảo luận về các tính năng chính, chúng tôi đã thảo luận về các tính năng phụ, chúng tôi đã chạy các mạng phát triển dành riêng cho từng tính năng này, thường là các tiêu điểm của phân nhánh. Và đó là sự đóng băng tính năng có dấu hoa thị vì tại thời điểm đó, chúng tôi đã quyết định sẽ không thêm bất kỳ tính năng nào nữa vào phân nhánh này. Chúng tôi sẽ chạy tất cả các tính năng cùng nhau, đảm bảo mọi thứ đều ổn, đảm bảo không có gì bị hỏng. Nhưng nếu có điều gì đó bắt đầu làm chậm tiến độ, nếu phân nhánh bị trì hoãn, nếu nó quá phức tạp, mọi thứ vẫn có thể bị loại bỏ tại thời điểm đó.

Vì vậy, sau một số mạng phát triển — có thể là hai, có thể là 10 — tất cả các máy khách đều quyết định tại một thời điểm nào đó rằng điều này đã ổn định. Chúng tôi tin tưởng vào những gì đang diễn ra lúc này. Chúng tôi đang ở một vị thế tốt. Hãy bắt đầu nghĩ đến việc đưa điều này ra Mạng chính Ethereum. Họ cắt các bản phát hành máy khách và sau đó có một khoảng thời gian 30 ngày mà nhóm bảo mật EF đưa ra chương trình tiền thưởng tìm lỗi (bug bounty). Họ ký hợp đồng kiểm toán bảo mật. Và sau đó vào cuối khoảng thời gian 30 ngày đó, chúng tôi khởi chạy phân nhánh trên các mạng thử nghiệm. Đây là những mạng thử nghiệm mà bạn có thể đã nghe nói đến — như Holesky. Đây là nơi các nhà phát triển ứng dụng có thể kiểm tra các sản phẩm của họ trước khi phân nhánh đi vào hoạt động. Và những quá trình này thường kéo dài tối thiểu 14 ngày mỗi lần chỉ để đảm bảo rằng mọi thứ đều ổn. Chúng tôi không mong đợi bất kỳ vấn đề lớn nào vì nó đã trải qua các mạng phát triển dành riêng cho từng tính năng và các mạng phát triển tổng quát trước đó, nhưng trong lịch sử, nó đã làm hỏng một số mạng thử nghiệm này. Và vì vậy, đây giống như cơ hội cuối cùng để tìm và tiêu diệt tất cả những lỗi này.

Và sau đó, khi mạng thử nghiệm không cần cấp phép đã ổn định, ngày ra mắt Mạng chính sẽ được chọn. Tiếp theo đó, có một khoảng thời gian đệm 30 ngày. Khoảng thời gian đệm 30 ngày này tồn tại vì các L2 và các giao thức đã yêu cầu điều này để chuẩn bị sẵn sàng cho phân nhánh. Vì vậy, đó là tối thiểu 30 ngày và sau đó phân nhánh sẽ diễn ra.

Cấu trúc cuộc gọi và sự điều phối (15:01)

Trong suốt thời gian này, có một số chuỗi cuộc gọi chính diễn ra. Đây đều là các cuộc gọi công khai được phát trực tiếp trên YouTube. Các cuộc gọi lớn là ACDE và ACDC. E là viết tắt của lớp thực thi — đó là những thứ như giao dịch, triển khai hợp đồng thông minh, quản lý mempool. ACDC là lớp đồng thuận — vì vậy đó là những thứ thuộc về trình xác thực như quản lý trình xác thực, phạt cắt giảm. Và những cuộc gọi đó luân phiên nhau vào các ngày thứ Năm. Vì vậy, có một cuộc gọi ACD vào mỗi thứ Năm và một trong số đó là ACDE và sau đó cuộc gọi tiếp theo là ACDC, cứ tiếp tục như vậy.

Các cuộc gọi ACDE và ACDC tập trung vào phân nhánh mà chúng tôi hiện đang thực hiện và các phân nhánh mà chúng tôi đang định hình cho tương lai. Các cuộc gọi ACDT thì đi sâu vào chi tiết kỹ thuật hơn. Đó là các máy khách nói về những lỗi mà họ không thể vượt qua hoặc các chi tiết triển khai cần được giải quyết về phân nhánh mà họ hiện đang làm việc. Vì vậy, ngay bây giờ phân nhánh tiếp theo sắp diễn ra là Glamsterdam. Do đó, các cuộc gọi ACDT này bị chi phối bởi cuộc trò chuyện về ePBS và danh sách truy cập cấp độ khối, những thứ sẽ được đưa vào Glamsterdam. Và đây là những cuộc gọi mang tính kỹ thuật cao.

Và sau đó có các cuộc gọi đột phá (breakout calls). Các cuộc gọi đột phá là khi các thành viên cộng đồng, nhà nghiên cứu, nhà phát triển nói rằng, "Này, tôi có một tính năng mà tôi muốn đưa vào Ethereum trong hai phân nhánh tới." Và vì vậy họ tổ chức các cuộc gọi hàng tuần, hàng tháng hoặc hai tháng một lần này, nơi họ thảo luận chi tiết về việc triển khai, thay đổi và lặp lại trên thông số kỹ thuật, và nhìn chung giải quyết tất cả các câu hỏi mà mọi người có, tất cả những điều chưa biết đã được nhận diện để đảm bảo rằng nó ở trạng thái tốt nhất có thể để được đưa vào phân nhánh trong hai phân nhánh tới. Và những cuộc gọi đó có thể được lên lịch bất cứ khi nào người điều phối quyết định.

Một quy trình đang tiến hóa (15:29)

Vì vậy, một điều tôi muốn nhấn mạnh với mọi người là quy trình này không hề tĩnh tại. Quy trình mà tôi vừa mô tả cho bạn đã hoạt động được chưa đầy một năm. Ethereum đã hoạt động được 10 năm. Nhưng nó liên tục thay đổi và lý do nó liên tục thay đổi là vì không có ai nắm quyền điều hành. Và quy trình này phần nào tiến hóa để tìm ra cách hoạt động hiệu quả nhất. Và tôi nói là hiệu quả, nhưng danh tiếng mà quản trị Ethereum có được là thực sự trì trệ, khó thông qua mọi thứ, khó hiểu — và đó là vì khi bạn có 100 đến 500 người đưa ra quyết định, thành thật mà nói tôi rất ấn tượng rằng điều này lại có thể hoạt động được.

Vì vậy, Tim đã đăng một bài viết vào tháng 4 năm 2025 có tên là "Cấu hình lại Tất cả các Nhà phát triển Cốt lõi" (Reconfiguring All Core Devs), cuối cùng trở thành đề xuất cho cách mọi thứ hoạt động ngay bây giờ. Và lý do cho điều đó là vì trước đó chúng tôi gần như có một câu chuyện gắn kết về những gì chúng tôi nên tập trung vào trong Ethereum. Đã có The Merge, một công việc khổng lồ. Mọi người đều rất hào hứng. Hầu hết mọi người đều rất hào hứng. Các thợ đào thì không. Và sau The Merge, bạn có tính năng rút tiền. Vì vậy, chúng tôi không muốn mọi người bị khóa ETH của họ trong một hợp đồng và FUD này giống như họ sẽ không bao giờ lấy được ETH ra khỏi đó. Vì vậy, chúng tôi phải phát hành tính năng đó càng nhanh càng tốt. Và sau đó là Proto-Danksharding và rồi Pectra xuất hiện và Pectra giống như một sự pha trộn của các EIP không liên quan khác nhau và không thực sự có một câu chuyện gắn kết. Và nó trở nên quá lớn vì mọi người chỉ nhồi nhét mọi thứ vào do thiếu sự gắn kết đến mức nó phải được chia thành hai phân nhánh khác nhau vì các nhóm thử nghiệm kiểu như, "Phạm vi quá lớn. Chúng tôi không thể kiểm tra tất cả những thứ này."

Và vì vậy động lực của Tim khi làm điều này là, được rồi, chúng ta cần nghĩ ra một cách để giữ cho các phân nhánh này tập trung và gắn kết nhất có thể. Và tính năng tiêu điểm chính là câu trả lời cho điều đó. Điểm mấu chốt của việc đó là phát hành theo cách ưu tiên làm cho mọi người cảm thấy như họ biết phân nhánh này nói về cái gì, để họ không phải nhồi nhét 25 EIP khác nhau vào.

Vì vậy, ảnh chụp màn hình khác ở trên cùng là Tim đang đề xuất các định nghĩa cho các giai đoạn đưa vào của các EIP này. Và điểm tôi muốn nhấn mạnh với điều này là đôi khi bạn nghe mọi người nói rằng quy trình này quá quan liêu. Nhưng những gì thực sự đang xảy ra là mọi người bước vào quy trình quản trị này và họ kiểu như, "Làm thế nào để tôi đưa một EIP vào?" và những người đã ở đó 10 năm thì kiểu như, "Bạn cứ làm thôi." Và mọi người kiểu như, "Thật tồi tệ." Và vì vậy những gì những điều này làm là chúng mô tả những gì đang xảy ra để giúp những người bên ngoài dễ dàng tham gia vào quy trình này hơn, bởi vì nếu bạn chỉ mới đến đây và bạn kiểu như, "Tôi có một EIP, tôi không quan tâm đến quản trị Ethereum, tôi chỉ muốn đưa EIP này vào" — bạn muốn có một tiêu chí đánh giá, bạn muốn có một danh sách kiểm tra, bạn muốn có một hướng dẫn từng bước rất rõ ràng về cách đưa EIP này vào. Vì vậy, hầu hết những điều này thiên về việc mô tả cách quy trình hoạt động hơn là tạo ra các quy tắc quan liêu mà mọi người phải tuân theo để gây khó khăn cho việc đưa các EIP vào.

Điều thứ ba là các cam kết (commit) theo thời gian trên Forkcast. Forkcast là một sản phẩm của nhóm tôi, do Wolfram Mark, một thành viên trong nhóm tôi tạo ra vào giữa năm ngoái khi nhóm của tôi ở phiên bản hiện tại được thành lập. Và nó đã trở thành một nguồn tài nguyên chuẩn mực để mọi người sử dụng nhằm tương tác với một phân nhánh, để xem những gì sẽ được đưa vào một phân nhánh và nó ảnh hưởng đến họ như thế nào. Tất cả những thứ này đều chưa đầy hai năm tuổi. Vì vậy, điểm tôi muốn nói là quy trình này thay đổi rất nhiều. Nó không hề tĩnh tại. Nó không phải là một bộ máy quan liêu đóng băng khó có thể chen chân vào.

Các hệ thống quản trị có thể so sánh (20:21)

Vì vậy, tôi muốn nhanh chóng đề cập đến các hệ thống quản trị phi tập trung tương tự nhất mà tôi có thể thấy so với quản trị Ethereum. Và điểm tôi đang cố gắng nhấn mạnh ở đây là điều này có tính bền vững — mặc dù thật đáng kinh ngạc khi 100 đến 500 người có thể đưa ra quyết định, nhưng nó bền vững trong thế giới thực. Chúng ta thực sự thấy các ví dụ về việc này đang hoạt động.

IETF là Lực lượng Đặc nhiệm Kỹ thuật Internet (Internet Engineering Task Force). Đây là cơ quan tiêu chuẩn do tình nguyện viên điều hành đã tạo ra TCP/IP, HTTP. Đây là tổ chức chịu trách nhiệm lớn nhất cho việc chúng ta có internet miễn phí ngày nay. Hạt nhân Linux (Linux kernel) — nó là cốt lõi của hệ điều hành Linux. Vì vậy, đó là phần mềm mã nguồn mở cung cấp năng lượng cho các máy chủ internet, điện thoại Android, siêu máy tính. Sự khác biệt ở đó là họ có một mô hình kiểu như nhà độc tài nhân từ với Linus Torvalds. Nhưng ngay cả như vậy, họ vẫn có hơn 17.000 người đóng góp, điều này thật đáng kinh ngạc.

Những thứ mà điều này không giống: các Chuỗi khối khác có tính năng bỏ phiếu token trên chuỗi. Ethereum đặc biệt tránh bất kỳ loại cơ chế bỏ phiếu nào vì theo ý kiến của tôi, điều đó dẫn đến các con đường bị thâu tóm và nó phần nào loại bỏ động lực để biến mọi thứ thành một chế độ nhân tài, nơi mọi người chỉ tin tưởng những người viết mã tốt nhất. Và sau đó là các L2. Họ có đa chữ ký (multi-sig). Họ có các hội đồng bảo mật. Đây giống như các vị trí được bổ nhiệm để đưa ra những quyết định này. Và điều đó có những sự đánh đổi của nó. Nó tập trung hơn. Tuy nhiên, nó di chuyển nhanh hơn.

Tại sao các nhà xây dựng quan tâm (22:38)

Vậy tại sao các nhà xây dựng lại quan tâm đến quản trị? Bởi vì các nhà xây dựng chính xác là những người mà Ethereum được tạo ra để phục vụ. Ethereum không được tạo ra cho các nhà phát triển cốt lõi. Nó không được tạo ra cho các trình xác thực. Đôi khi những người này bị nhầm lẫn về điều đó. Các nhà phát triển cốt lõi và trình xác thực của Ethereum phục vụ Ethereum, và Ethereum phục vụ các nhà xây dựng và người dùng.

Và mọi người đều đã từng có khoảnh khắc đó với một AI khi bạn đi quá sâu vào chi tiết và nó đang cố gắng sửa chữa một thứ nhỏ nhặt này mà không thể lùi lại để nhìn vào toàn bộ mục đích của dự án. Và các nhà phát triển cốt lõi cũng có thể như vậy khi họ đang cố gắng hoàn thiện quy trình phát triển cốt lõi. Và trong trường hợp đó, điều rất quan trọng là các nhà xây dựng phải tham gia vì quá trình phát triển cốt lõi tiêu tốn quá nhiều công sức đến mức hầu hết thời gian họ không đồng thời xây dựng trên Ethereum. Họ tham gia rất sâu vào quá trình phát triển cốt lõi. Nó chiếm toàn bộ thời gian của họ. Và vì vậy, các nhà xây dựng ứng dụng thực sự phải nỗ lực bước vào và nói, "Này, chúng tôi cần điều này. Điều này rất quan trọng đối với Ethereum." Chỉ để đảm bảo rằng góc nhìn đó luôn hiện diện và họ không chỉ bị bó hẹp vào việc chỉ làm việc cho các nhà phát triển cốt lõi.

Cách tham gia (24:40)

Vậy làm thế nào để bạn tham gia hoặc đưa tính năng của mình vào? Đây là một lời khuyên khá chung chung, nhưng tôi nghĩ nó là tốt nhất. Hãy lên tiếng mạnh mẽ về những điểm yếu (pain points) của bạn. Lên Twitter, viết bài trên blog, xác định các giải pháp cho những điểm yếu của bạn. Suy đoán về những thứ có thể giúp ích cho bạn. Nếu bạn tìm thấy những người khác có cùng những điểm yếu đó, thông thường bạn có thể tìm thấy một EIP hiện có để giải quyết điểm yếu đó hoặc nhờ ai đó giúp bạn viết một EIP làm điều đó.

Một điều tôi thích ở phần mềm mã nguồn mở là nhìn chung các công ty có nguồn vốn tốt sẽ phân bổ thời gian và nguồn lực của nhà phát triển để duy trì các công cụ mã nguồn mở mà họ đang sử dụng. Và cuối cùng nó trở thành một nhóm các công ty khác nhau hợp tác để duy trì thứ này và đó cũng có thể là cách nó hoạt động trong Ethereum. Vì vậy, nếu bạn có một điểm yếu mà bạn đã xác định được, bạn có thể tìm một nhà phát triển Base có điểm yếu tương tự, và Base là một tổ chức có nguồn vốn tốt nên họ có thể sẽ sẵn sàng phân bổ một số nguồn lực để phát hành một tính năng hoặc dẫn dắt một tính năng thông qua một phân nhánh cứng của Ethereum.

Tôi sẽ để lại cho bạn một số tài nguyên. Forkcast.org — đó là nơi bạn có thể truy cập và xem những gì sẽ được đưa vào một phân nhánh, nó ảnh hưởng như thế nào đến một số bên liên quan nhất định. Vì vậy, nếu bạn là một nhà phát triển ứng dụng, có một phần dành cho các nhà phát triển ứng dụng. Nếu bạn là một nhà phát triển Ví, một nhà phát triển máy khách lớp đồng thuận, có các phần về cách tất cả những điều đó ảnh hưởng đến bạn. YouTube là nơi tất cả các video cuộc gọi đó được tải lên. Chúng cũng được nhúng trong trang forkcast.org/calls, nơi có các bản tóm tắt, thông tin về người nói, vì vậy việc điều hướng các cuộc gọi đó sẽ dễ dàng hơn. Thư mục EIP, diễn đàn Ethereum Magicians nơi bạn có thể đến nói chuyện với những người khác về các giải pháp tiềm năng hoặc các EIP mà bạn muốn viết. Và rất sớm thôi, nhóm của tôi sẽ có một trang web hỗ trợ giao thức. Nó trông rất tuyệt. Nó chưa sẵn sàng để chia sẻ. Email của tôi cũng ở đó — nixo@ethereum.org (opens email client). Vậy thôi.