Vào ngày 27 tháng 2, Raul Romanutti, thành viên nhóm điều phối tài chính của Ethereum Foundation, đã đăng một bài viết với tiêu đề "Mọi Chuyện Vẫn Ổn (Cho Đến Khi Grant Cạn Kiệt)" (This Is Fine (Until the Grant Runs Out)). Bài viết giới thiệu về Dự án Odin – một kế hoạch hỗ trợ bền vững có cấu trúc nhắm vào một số nhóm chiến lược từng nhận được tài trợ lớn từ EF.
Nếu chỉ nhìn vào thông tin, Odin dễ bị xếp vào danh mục "EF lại tung ra một chương trình tài trợ hàng hóa công cộng". Nhưng nó khác với các grant thông thường: các dự án nhận được không phải là một khoản vốn khởi nghiệp mới, cũng không phải một cơ hội ứng tuyển công khai, mà là một cơ chế đồng hành dài hạn hướng đến các nhóm đã được tài trợ hiện có. EF Blog đặt mục tiêu trong khung thời gian hai năm: giúp các nhóm này thiết lập một con đường bền vững đáng tin cậy, giảm sự phụ thuộc dài hạn vào một nguồn tài trợ duy nhất; trong đó, tư vấn chiến lược tại chỗ sẽ đồng hành và thực thi trong khoảng 12 tháng.
Odin quan tâm đến quãng đường sau khi grant kết thúc.
Điểm chính mà 0xRahul đề cập trong tweet cũng nằm ở đây. Anh ấy không trình bày vấn đề dưới dạng "EF có còn muốn tài trợ cho hàng hóa công cộng hay không", mà tập trung vào tính bền vững của các nhóm công cụ dành cho nhà phát triển: các công cụ mã nguồn mở lớn, phức tạp và được sử dụng rộng rãi không thể duy trì lâu dài chỉ bằng nhiệt huyết hoặc các grant ngắn hạn.
Trước đây, cộng đồng tiếng Trung thảo luận về hàng hóa công cộng thường xoay quanh việc quyên góp Gitcoin, phân phối RetroPGF, danh sách tài trợ của EF, hoặc một dự án có phù hợp để được quyên góp hay không. Dự án Odin hướng đến giai đoạn muộn hơn: sau khi một dự án hàng hóa công cộng đã chứng minh được tầm quan trọng của mình, làm thế nào để không bị lệ thuộc vào khoản grant tiếp theo?
Grant vẫn quan trọng, nhưng vấn đề bắt đầu thay đổi
Trước tiên, hãy loại bỏ một cách hiểu sai: Dự án Odin không phải là tín hiệu cho thấy EF ngừng tài trợ cho hàng hóa công cộng.
Từ thông tin công khai gần đây, EF vẫn tiếp tục tài trợ cho nghiên cứu giao thức, client, mật mã, ZK, công cụ dành cho nhà phát triển, giáo dục và thử nghiệm hàng hóa công cộng. EF Ecosystem Support Program trong Bản Cập nhật Phân bổ Q1 2026 vẫn liệt kê các dự án bao phủ nhiều hướng cơ sở hạ tầng và công cụ như EthereumJS maintenance, BuidlGuidl, WalletConnect clear signing library, L2BEAT 2026, DISC-NG Geth, Lighthouse, Vero, formal verification. Những danh sách tài trợ theo quý tương tự đã xuất hiện trong vài năm qua.
Grant không biến mất, chỉ là bản thân nó không giải quyết được mọi vấn đề.
Đối với các dự án giai đoạn đầu, grant có thể giảm chi phí khởi động; đối với công việc nghiên cứu, grant có thể bao phủ các khám phá không dễ thương mại hóa; đối với giáo dục cộng đồng và cơ sở hạ tầng công cộng, grant vẫn là nguồn tài chính quan trọng. Nhưng nếu một nhóm công cụ mà nhiều dự án đang phụ thuộc chỉ có một nguồn tài trợ chính duy nhất trong thời gian dài, rủi ro sẽ trở nên tập trung.
EF Blog đề cập rằng nhiều nhóm không thiếu năng lực kỹ thuật, điểm yếu nằm ở các năng lực phi kỹ thuật như gây quỹ, giao tiếp đối ngoại, thiết kế tổ chức, cấu trúc pháp lý. Nhóm có thể viết trình biên dịch, nghiên cứu, bảo trì stack mạng, nhưng chưa chắc có thời gian trả lời những câu hỏi: Ai phụ thuộc nhiều nhất vào chúng tôi? Người dùng nào sẵn sàng ký hợp đồng hỗ trợ dài hạn? Công việc nào có thể được doanh nghiệp mua? Nguồn thu nào không ảnh hưởng đến tính trung lập của dự án?
Odin cố gắng bổ sung chính là phần năng lực này.
Tại sao công cụ dành cho nhà phát triển dễ mắc kẹt nhất ở đây
0xRahul trong một chuỗi tweet dài đã liệt kê bốn mô hình công cụ dành cho nhà phát triển truyền thống: mã nguồn mở từ công ty lớn, gắn liền với sản phẩm lớn hơn, SaaS thương mại, bảo trì miễn phí.
Bốn mô hình này khi áp dụng vào Ethereum đều có những hạn chế rõ rệt.
Công cụ mã nguồn mở từ công ty lớn thường mạnh, nhưng lâu dài phụ thuộc vào chiến lược công ty. Khi công ty sẵn sàng đầu tư, hệ sinh thái hưởng lợi; khi hướng đi của công ty thay đổi, mức độ ưu tiên bảo trì cũng thay đổi theo. Đối với hệ sinh thái như Ethereum nhấn mạnh tính trung lập đáng tin cậy, việc đặt các công cụ quan trọng vào sự quan tâm dài hạn của một công ty duy nhất là không ổn định.
Công cụ gắn liền với sản phẩm lớn cũng tương tự. Nó có thể phục vụ tốt người dùng của một dòng sản phẩm hoặc nền tảng cụ thể, nhưng khó giữ được sự hoàn toàn mở. Công cụ dành cho nhà phát triển Ethereum cần được sử dụng xuyên ví, xuyên client, xuyên L2, xuyên giao thức, một khu vườn khép kín sẽ làm suy yếu thuộc tính công cộng của nó.
SaaS thương mại có thể giải quyết một phần vấn đề, nhưng không phải tất cả. Nhiều nhóm crypto bản thân còn ở giai đoạn đầu, ngân sách nghiên cứu & phát triển có hạn. Quan trọng hơn, các công cụ như trình biên dịch, ngôn ngữ, thư viện cơ bản, stack mạng, nền tảng minh bạch, giá trị thường thể hiện ở sự an toàn và hiệu quả của toàn bộ hệ sinh thái, rất khó để tính phí trực tiếp theo từng người dùng.
Cuối cùng là bảo trì miễn phí. Các thư viện nhỏ hoặc công cụ cá nhân có thể tiến triển trong ngắn hạn nhờ sở thích, nhưng cơ sở hạ tầng lớn thì không. Trình biên dịch cần được kiểm tra và phản hồi bảo mật lâu dài, ngôn ngữ cần lộ trình và quản trị cộng đồng, stack mạng P2P cần sự phối hợp xuyên dự án, nền tảng giám sát rủi ro cần duy trì dữ liệu liên tục. Đây không phải là công việc một lần.
Công cụ dành cho nhà phát triển thường rơi vào vị trí khó xử: chúng quá cơ bản, không ai muốn mất; lại quá công cộng, khó có thể tự nhiên tạo ra doanh thu.
Dự án Odin không phải là một "chương trình tăng tốc"
EF Blog mô tả Odin là một kế hoạch hỗ trợ có cấu trúc, nhưng nó không giống với các chương trình tăng tốc khởi nghiệp.
Các chương trình tăng tốc thường phục vụ các công ty tăng trưởng, mục tiêu là sản phẩm, thị trường, gây quỹ và mở rộng quy mô. Odin không yêu cầu các nhóm hàng hóa công cộng kể một câu chuyện ở quy mô đầu tư mạo hiểm (venture scale), nó quan tâm đến việc liệu các nhóm này có thể tiếp tục cung cấp giá trị qua nhiều chu kỳ tài chính, dần dần trở thành các tổ chức ổn định hơn hay không.
Cơ chế cơ bản của Odin là mỗi nhóm sẽ có một cố vấn chiến lược tại chỗ. Cố vấn này không phải để đào tạo một lần, mà là tham gia lâu dài vào việc lập kế hoạch và thực thi tính bền vững của nhóm. Toàn bộ quá trình đại khái bao gồm ba giai đoạn:
- Giai đoạn đầu tiên là sắp xếp các lựa chọn thực tế. Hiện tại nhóm sống bằng gì? Trước đây đã thử những cách gây quỹ nào? Ai trong hệ sinh thái hưởng lợi từ nó? Có những kênh tài chính nào khả dụng? Cái giá của mỗi kênh là gì?
- Giai đoạn thứ hai là xác thực con đường. Ví dụ như bắt đầu đối thoại với các nhà tài trợ tiềm năng, đối tác, người dùng doanh nghiệp, đại biểu DAO hoặc các nhóm giao thức, để đánh giá những hướng đi nào không phải chỉ là kế hoạch trên giấy.
- Giai đoạn thứ ba là thực thi. Bao gồm chuẩn bị tài liệu gây quỹ hoặc hợp tác, xây dựng đường ống hợp tác, khi cần thiết thiết kế các hợp đồng hỗ trợ, thỏa thuận dịch vụ hoặc các hình thức thu nhập lặp lại khác.
Quy trình này nghe có vẻ không hấp dẫn bằng câu chuyện kể về "hàng hóa công cộng", nhưng nó giải quyết phần thực tế nhất của dự án: nhóm không thể mỗi lần đều bắt đầu tìm kiếm khoản tiền tiếp theo khi thời gian hoạt động (runway) sắp hết.
Tại sao Vyper được chọn
Vyper là người tham gia thí điểm đầu tiên của Dự án Odin.
Sự lựa chọn này không đáng ngạc nhiên. Vyper là ngôn ngữ hợp đồng thông minh Pythonic hướng đến EVM, nhấn mạnh tính an toàn, đơn giản và dễ đọc. EF Blog đề cập rằng, ở thời kỳ đỉnh cao, Vyper từng bảo vệ giá trị trên chuỗi lên tới hơn 270 tỷ USD. Ngay cả ngày nay, nó vẫn hỗ trợ hàng nghìn hợp đồng và tổng giá trị bị khóa (TVL) hàng chục tỷ USD.
Ngôn ngữ và trình biên dịch là cơ sở hạ tầng công cộng điển hình. Một khi chúng gặp sự cố, ảnh hưởng không chỉ đến một ứng dụng đơn lẻ, mà là tất cả các giao thức và nhà phát triển phụ thuộc vào chúng. Nhưng xét về mô hình kinh doanh, các dự án loại này không dễ xử lý: ngôn ngữ cốt lõi nên giữ mã mở, khả năng an toàn và xác minh hình thức hóa lại cần đầu tư liên tục, chỉ dựa vào quyên góp cộng đồng khó có thể duy trì đội ngũ lâu dài.
Việc nhóm Vyper mới thành lập Foundation for Verified Software (FVS) đã đặt vấn đề này lên bàn. Trang web chính thức của FVS cho thấy, tổ chức này tập trung vào nghiên cứu xác minh hình thức hóa, công cụ mở và hỗ trợ hệ sinh thái, các dự án hiện tại bao gồm Vyper, Vyper-HOL, Verifereum, HOL4. EF Blog cũng đặt Vyper / FVS vào vị trí người tham gia thí điểm đầu tiên của Odin để thảo luận.
Đây chưa phải là mẫu hình thương mại hóa đã chạy thông suốt. Nói chính xác hơn, nó là một hình thái tổ chức đang được thử nghiệm: quỹ tiếp nhận nghiên cứu dài hạn và công cụ mã nguồn mở, nhóm sau đó xoay quanh việc xác minh hình thức hóa, kiểm toán, đào tạo, hợp đồng hỗ trợ hoặc POC doanh nghiệp, để thăm dò xem liệu có thể hình thành thu nhập ổn định hay không.
Trong ngữ cảnh cộng đồng tiếng Trung, Vyper không chỉ là "một dự án ngôn ngữ nhận được sự hỗ trợ của EF". Khi các yêu cầu về an toàn hợp đồng từ DeFi, L2 và vốn thể chế ngày càng cao, những khả năng như xác minh hình thức hóa cũng có thể dần chuyển từ chủ đề nghiên cứu thành dịch vụ chuyên nghiệp có thể được mua sắm.
libp2p và L2BEAT: Hai trường hợp đối chiếu
EF Blog mở đầu có đề cập đến libp2p. Đây là stack mạng P2P được nhiều hệ thống Web3 sử dụng, và cũng được các Ethereum client sử dụng để phát hiện node, truyền bá thông điệp, truyền bá khối và phiếu bầu của trình xác thực. EF Blog dùng nó làm một trong những trường hợp áp lực tài chính gần đây, để minh họa rằng ngay cả cơ sở hạ tầng mã nguồn mở được phụ thuộc rộng rãi cũng có thể rơi vào trạng thái cầu cứu khi tài nguyên không đủ.
Trường hợp này minh họa khó khăn tài chính của sự phụ thuộc tầng đáy: càng ở tầng đáy, người sử dụng càng nhiều, quan hệ thanh toán trực tiếp lại càng không rõ ràng. Mỗi dự án đều mong muốn libp2p ổn định, nhưng khó có thể nói dự án nào nên chịu chi phí bảo trì chính.
L2BEAT thì cung cấp một góc nhìn khác.
L2BEAT là công cụ minh bạch rất quen thuộc với cộng đồng tiếng Trung, theo dõi lâu dài các rủi ro và dữ liệu về L2, cầu, DA, ZK. Nó không phải là thí điểm của Odin, nhưng nó công khai nguồn tài trợ, phù hợp để xem như một trường hợp kết hợp tài chính.
Theo trang quyên góp của L2BEAT, nguồn tài chính của nó bao gồm Quỹ Đối tác, các grant từ Ethereum Foundation, Optimism RPGF, Gitcoin, phần thưởng và đền bù từ việc tham gia các khuôn khổ quản trị L2, grant chuyên đề, tài trợ hội nghị, thăm dò báo cáo và dashboard, quyên góp trực tiếp từ cộng đồng, v.v.
Danh sách này khá thú vị. Nó chỉ ra rằng các nhóm hàng hóa công cộng chưa chắc chỉ có hai con đường: hoặc hoàn toàn dựa vào grant, hoặc trở thành SaaS. Một nhóm lâu dài cung cấp dữ liệu trung lập và đánh giá chuyên môn có thể nhận được hỗ trợ từ nhiều vai trò khác nhau trong hệ sinh thái. Nhưng điều kiện tiên quyết là, nó cần phải nói rõ nguồn tài chính, để bên ngoài có thể tiếp tục xem xét cấu trúc khuyến khích của nó.
Kết hợp các cơ chế tài chính, thay vì chỉ đặt cược vào một câu trả lời
Hai năm gần đây, cộng đồng tiếng Trung đã khá quen thuộc với các cơ chế tài trợ hàng hóa công cộng như Gitcoin, Optimism Retro Funding, Protocol Guild, Drips. Chúng thường được đặt trong bối cảnh "đa dạng hóa nguồn tài chính" và "dòng thu nhập bền vững" để thảo luận.
Nhưng các cơ chế này giải quyết những vấn đề không giống nhau: Gitcoin Grants phù hợp hơn với việc tổng hợp tín hiệu cộng đồng, cũng có thể giúp hàng hóa công cộng giai đoạn đầu có được sự chú ý và vốn khởi động; Optimism Retro Funding khen thưởng công việc đã tạo ra ảnh hưởng, phù hợp để bù đắp cho đóng góp trong quá khứ; Protocol Guild nhắm đến những người đóng góp vào R&D lõi của Ethereum L1, thiết lập cơ chế tài trợ trên chuỗi lâu dài hơn; Drips quan tâm đến tài trợ theo sự phụ thuộc, hy vọng vốn có thể chảy lên các dự án mã nguồn mở ở thượng nguồn dọc theo mối quan hệ phụ thuộc.
Đối với các nhóm công cụ dành cho nhà phát triển lớn, mấu chốt không phải là chọn ra một câu trả lời duy nhất trong số các cơ chế này, mà là hiểu được giới hạn phù hợp của từng loại vốn. QF cần dự án liên tục kêu gọi bình chọn, kết quả Retro Funding tồn tại sự không chắc chắn, DAO grants chịu ảnh hưởng của chu kỳ quản trị và biến động token, quyên góp trực tiếp thường khó bao phủ chi phí đội ngũ ổn định.
Trọng tâm của Dự án Odin cũng không nằm ở việc phát minh ra một cơ chế tài chính mới, mà là giúp các nhóm kết hợp các cơ chế hiện có và thu nhập tiềm năng lại với nhau: grant có thể hỗ trợ nghiên cứu, retro funding có thể khen thưởng ảnh hưởng, DAO hoặc giao thức có thể cung cấp hỗ trợ chuyên đề, người dùng doanh nghiệp có thể mua dịch vụ hoặc hợp đồng hỗ trợ, đối tác có thể cùng phát triển POC.
Những điều này nghe có vẻ là vấn đề vận hành thông thường, nhưng đối với nhiều nhóm hàng hóa công cộng, bản thân năng lực vận hành thông thường đã là điểm yếu. Điều Odin thực sự bổ sung chính là năng lực dịch "dự án có giá trị" thành "ai thực sự phụ thuộc vào nó, ai sẵn sàng hỗ trợ nó liên tục, và thu nhập nào sẽ không làm tổn hại thuộc tính công cộng của nó".
Nói cách khác, câu khẩu hiệu "ngoài grant" không chỉ là một khẩu hiệu, mà là một bộ kết hợp tài chính, quan hệ hợp tác và năng lực tổ chức cụ thể hơn.
Cộng đồng tiếng Trung có thể hiểu như thế nào
Cộng đồng tiếng Trung trước đây nhìn nhận hàng hóa công cộng, thường có hai lối vào.
Một lối vào là quyên góp. Ví dụ, mỗi khi Gitcoin mở một vòng, sẽ có giới thiệu dự án, hướng dẫn quyên góp, hướng dẫn tương tác. Hàng hóa công cộng ở đây giống hành vi tham gia cộng đồng hơn.
Lối vào thứ hai là tin tức. Ví dụ, EF công bố danh sách tài trợ theo quý, Optimism mở Retro Funding, một dự án nào đó nhận được grant. Hàng hóa công cộng ở đây giống dòng chảy tài chính hệ sinh thái hơn.
Dự án Odin cung cấp lối vào thứ ba: vận hành dài hạn của các nhóm hàng hóa công cộng.
Đối với cộng đồng tiếng Trung, góc độ này gần gũi hơn với nhà phát triển và các bên giao thức. Nếu một giao thức lâu dài phụ thuộc vào một thư viện mã nguồn mở, nền tảng dữ liệu rủi ro, trình biên dịch, công cụ xác minh hoặc cơ sở hạ tầng an toàn nào đó, thì không thể chỉ chuyển tiếp lời cầu cứu khi nó thiếu tiền. Cách làm hợp lý hơn là liệt kê những sự phụ thuộc này vào ngân sách hệ sinh thái của chính mình: Những công cụ nào là sự phụ thuộc then chốt đối với chúng ta? Có nên cung cấp hỗ trợ dài hạn không? Có cần mua hợp đồng hỗ trợ không? Có nên tham gia vào tài trợ theo sự phụ thuộc không? Có nên dành chi tiêu cho hàng hóa công cộng trong ngân sách quản trị không?
Việc coi nó là vấn đề từ thiện không chính xác, nó gần với vấn đề chuỗi cung ứng hơn. Hàng hóa công cộng không quan trọng vì "đáng được quyên góp", mà vì nhiều nhóm đã phụ thuộc vào nó trong việc phát triển hàng ngày, an toàn, dữ liệu và đánh giá quản trị. Vì sự phụ thuộc này là có thật, việc hỗ trợ nó không chỉ là biểu hiện của thiện chí, mà còn là một hình thức quản lý rủi ro hệ sinh thái.
Nếu một giao thức sẵn sàng chi tiền cho tạo lập thị trường, khuyến khích, tăng trưởng và thương hiệu, nhưng lại không muốn trả tiền cho các công cụ cơ bản mà nó phụ thuộc, thì thứ nó tiết kiệm được không phải là chi phí, mà là chuyển chi phí sang người bảo trì và toàn bộ hệ sinh thái. Lý do Dự án Odin đáng được chú ý cũng chính là vì nó đẩy vấn đề này từ "ai sẵn sàng tài trợ" tiến thêm một bước: ai thực sự phụ thuộc vào những nhóm này, người đó nên tham gia vào thiết kế tính bền vững của họ sớm hơn.
Dự án Odin sẽ không giải quyết tất cả vấn đề tài trợ hàng hóa công cộng. Hiện tại nó cũng chỉ là một kế hoạch hỗ trợ có cấu trúc hướng đến một số ít nhóm đã được tài trợ mang tính chiến lược. Nhưng nó đã nói rõ một vấn đề bị trì hoãn lâu nay: các dự án hàng hóa công cộng không thể chỉ chứng minh mình có giá trị khi ứng tuyển grant, mà còn phải tìm ra trong vận hành hàng ngày ai thực sự phụ thuộc vào mình, ai sẵn sàng hỗ trợ mình liên tục, và thu nhập nào sẽ không làm tổn hại thuộc tính công cộng của mình.
Đây có lẽ là một tín hiệu cho thấy cuộc thảo luận về hàng hóa công cộng của Ethereum đang bước vào giai đoạn tiếp theo. Vấn đề trước đây là "ai nên được tài trợ"; vấn đề bây giờ bắt đầu trở thành "các nhóm đã được chứng minh là quan trọng, làm thế nào để không bị quyết định sống chết bởi khoản grant tiếp theo".
