Đối thoại cùng Vitalik: Khám phá tầm nhìn Ethereum 2025, sự tích hợp đổi mới giữa POS, L2, mật mã học và AI
Tuyển chọn TechFlowTuyển chọn TechFlow
Đối thoại cùng Vitalik: Khám phá tầm nhìn Ethereum 2025, sự tích hợp đổi mới giữa POS, L2, mật mã học và AI
Cuộc phỏng vấn lần này là cuộc trò chuyện bằng tiếng Trung, Vitalik thể hiện khả năng tiếng Trung rất trôi chảy.
Chuyên sâu báo cáo Web3Tác giả: DappLearning
Ngày 07 tháng 04 năm 2025, tại sự kiện Pop-X HK Research House do DappLearning, ETHDimsum, Panta Rhei và UETH đồng tổ chức, Vitalik và Tiểu Vi đã cùng xuất hiện tại buổi lễ.
Trong thời gian nghỉ giữa sự kiện, Yan – người sáng lập cộng đồng DappLearning – đã phỏng vấn Vitalik. Cuộc phỏng vấn đề cập đến nhiều chủ đề như ETH POS, Layer2, mật mã học và AI. Cuộc trao đổi được thực hiện hoàn toàn bằng tiếng Trung, với khả năng nói tiếng Trung rất lưu loát của Vitalik.
Dưới đây là nội dung cuộc phỏng vấn (đã được biên tập để dễ đọc hơn):
01 Quan điểm về nâng cấp POS
Yan:
Xin chào Vitalik, tôi là Yan từ cộng đồng DappLearning, rất vinh dự được phỏng vấn anh hôm nay.
Tôi bắt đầu tìm hiểu về Ethereum từ năm 2017. Tôi nhớ vào các năm 2018–2019, cộng đồng tranh luận rất sôi nổi về POW và POS, và có lẽ chủ đề này sẽ còn tiếp tục.
Nhìn lại hiện tại, POS trên ETH đã vận hành ổn định hơn bốn năm, với hàng trăm nghìn Validator trong mạng lưới đồng thuận. Tuy nhiên, tỷ giá ETH so với BTC lại liên tục giảm. Điều này vừa mang lại mặt tích cực, vừa đặt ra một số thách thức.
Vậy ở thời điểm hiện tại, anh nhìn nhận thế nào về việc nâng cấp POS của Ethereum?
Vitalik:
Theo tôi, giá cả của BTC và ETH hoàn toàn không liên quan gì đến POW hay POS cả.
Cộng đồng BTC và ETH có rất nhiều quan điểm khác nhau, và hai cộng đồng này đang làm những việc hoàn toàn khác biệt, cách suy nghĩ cũng khác hẳn.
Về giá trị của ETH, tôi cho rằng có một vấn đề: ETH có rất nhiều tương lai tiềm năng. Trong những viễn cảnh đó, Ethereum có thể có rất nhiều ứng dụng thành công, nhưng những ứng dụng này có thể không tạo ra giá trị tương xứng cho ETH.
Đây là điều nhiều người trong cộng đồng lo ngại, nhưng thực tế thì điều này rất bình thường. Ví dụ như Google, họ phát triển rất nhiều sản phẩm và làm nhiều điều thú vị. Nhưng hơn 90% doanh thu của họ vẫn đến từ dịch vụ Tìm kiếm.
Mối quan hệ giữa hệ sinh thái Ethereum và giá trị ETH cũng tương tự vậy. Một số ứng dụng trả phí giao dịch cao, tiêu thụ nhiều ETH, trong khi nhiều ứng dụng khác dù thành công nhưng lại không đóng góp nhiều vào giá trị của ETH.
Đây là vấn đề chúng ta cần suy ngẫm và tiếp tục tối ưu hóa. Chúng ta cần hỗ trợ thêm các ứng dụng mang lại giá trị dài hạn cho người nắm giữ ETH.
Vì vậy, tôi cho rằng thành công trong tương lai của ETH có thể đến từ những lĩnh vực này. Còn việc cải thiện thuật toán đồng thuận thì tôi thấy không liên quan mấy.
02 Kiến trúc PBS và lo ngại về tập trung hóa
Yan:
Đúng vậy, sự phát triển mạnh mẽ của hệ sinh thái ETH chính là lý do thu hút chúng tôi – những nhà phát triển – tham gia xây dựng.
OK, vậy anh đánh giá thế nào về kiến trúc PBS (Proposer & Builder Separation) của ETH2.0? Đây là một hướng đi tốt, giúp mọi người có thể dùng điện thoại làm nút nhẹ để xác minh proof (ZK), và chỉ cần stake 1 ether là có thể trở thành Validator.
Nhưng Builder có nguy cơ trở nên tập trung hóa cao hơn, vì họ phải xử lý chống MEV, tạo ZK Proof, và nếu áp dụng Based rollup thì vai trò của Builder còn nặng nề hơn, ví dụ như làm Sequencer.
Liệu điều này có khiến Builder trở nên quá tập trung? Dù Validator đã đủ phi tập trung, nhưng đây là một chuỗi liên kết. Nếu một khâu gặp vấn đề, cả hệ thống sẽ bị ảnh hưởng. Vậy làm sao để giải quyết bài toán chống kiểm duyệt ở khía cạnh này?
Vitalik:
Đúng vậy, theo tôi đây là một vấn đề triết học rất quan trọng.
Vào thời kỳ đầu của Bitcoin và Ethereum, tồn tại một giả định ngầm:
Việc xây dựng khối và xác minh khối là một thao tác giống nhau.
Giả sử bạn xây dựng một khối chứa 100 giao dịch, thì node của bạn phải chạy hết lượng gas tương ứng với 100 giao dịch đó. Khi bạn phát tán khối này ra toàn mạng, mọi node khác cũng phải thực hiện công việc tương tự (tiêu tốn lượng gas tương đương). Vì vậy, nếu chúng ta đặt giới hạn gas (gaslimit) sao cho mọi chiếc Laptop, Macbook hay máy chủ cỡ nhỏ đều có thể xây dựng khối, thì cũng cần yêu cầu phần cứng tương đương để xác minh khối.
Đó là công nghệ trước đây. Hiện nay chúng ta đã có ZK, DAS, và nhiều công nghệ mới như Statelessness (xác minh vô trạng thái).
Trước khi áp dụng các công nghệ này, việc xây dựng và xác minh khối phải đối xứng. Giờ đây, chúng có thể trở nên bất đối xứng. Nghĩa là chi phí xây dựng khối có thể rất cao, nhưng chi phí xác minh khối lại có thể rất thấp.
Lấy ví dụ với client vô trạng thái: nếu áp dụng công nghệ này và tăng gaslimit lên gấp mười lần, thì yêu cầu về sức mạnh tính toán để xây dựng khối sẽ tăng vọt, khiến máy tính thông thường không còn đủ khả năng. Lúc này, có thể cần dùng MAC studio hiệu suất cao hoặc máy chủ cấu hình mạnh.
Nhưng chi phí xác minh sẽ thấp hơn nhiều, vì việc xác minh không cần bộ nhớ, chỉ cần băng thông và tài nguyên CPU. Nếu kết hợp thêm ZK, chi phí CPU cho xác minh cũng được loại bỏ. Nếu thêm DAS, chi phí xác minh sẽ cực kỳ thấp. Như vậy, dù xây dựng khối tốn kém hơn, nhưng xác minh lại rẻ hơn rất nhiều.
Vậy so với tình hình hiện tại, liệu đây có phải là bước tiến tốt hơn không?
Vấn đề này khá phức tạp. Tôi suy nghĩ như sau: nếu trong mạng Ethereum có một vài siêu nút (super nodes) – tức là những nút có sức mạnh tính toán lớn hơn – và chúng ta cần họ để thực hiện các phép tính hiệu suất cao.
Vậy làm sao để ngăn họ làm điều xấu? Có thể kể đến một vài kiểu tấn công:
Thứ nhất: Tấn công 51%.
Thứ hai: Tấn công kiểm duyệt (Censorship attack). Nếu họ từ chối một số giao dịch của người dùng, làm sao giảm thiểu rủi ro này?
Thứ ba: Các hoạt động liên quan đến chống MEV, làm sao giảm rủi ro?
Về tấn công 51%, vì quá trình xác minh được thực hiện bởi các Attester, nên các node Attester này cần xác minh DAS, ZK Proof và client vô trạng thái. Chi phí xác minh rất thấp, do đó门槛 để làm node đồng thuận vẫn khá thấp.
Ví dụ, nếu có một vài Super Nodes xây dựng khối, và 90% khối do bạn tạo, 5% do anh ta, 5% do người khác. Nếu bạn hoàn toàn từ chối một giao dịch, thật ra cũng không quá tệ. Vì sao? Bởi bạn không thể can thiệp vào quá trình đồng thuận.
Bạn không thể thực hiện tấn công 51%, nên điều duy nhất bạn có thể làm là ghét bỏ một số giao dịch nhất định.
Người dùng chỉ cần chờ 10 hoặc 20 khối nữa, để một người khác đưa giao dịch của họ vào khối – đó là điểm thứ nhất.
Điểm thứ hai là chúng ta có khái niệm Fossil.
Fossil tách biệt vai trò "chọn giao dịch" khỏi vai trò "thực thi giao dịch". Việc chọn giao dịch nào đưa vào khối kế tiếp có thể được thực hiện một cách phi tập trung hơn. Nhờ phương pháp Fossil, các node nhỏ có khả năng độc lập lựa chọn giao dịch đưa vào khối tiếp theo. Trong khi đó, quyền lực của các node lớn lại bị hạn chế [1].
Phương pháp này phức tạp hơn trước, khi trước đây chúng ta tưởng tượng mỗi node là một chiếc laptop cá nhân. Nhưng hãy nhìn Bitcoin hiện tại – nó cũng có kiến trúc hỗn hợp. Các thợ mỏ Bitcoin hiện nay đều là các trung tâm dữ liệu chuyên dụng.
Vì vậy, trong POS, một phần node sẽ đòi hỏi nhiều tài nguyên tính toán hơn. Nhưng quyền lực của các node này bị giới hạn, trong khi các node khác có thể phân tán rộng rãi và phi tập trung hoàn toàn, từ đó đảm bảo an ninh và tính phi tập trung của mạng. Tuy nhiên, phương pháp này phức tạp hơn, đây cũng là một thách thức của chúng ta.
Yan:
Một góc nhìn rất tuyệt vời. Tập trung hóa không nhất thiết là xấu, miễn là chúng ta có thể hạn chế hành vi xấu của họ.
Vitalik:
Đúng vậy.
03 Mối quan hệ giữa Layer1 và Layer2, và định hướng tương lai
Yan:
Cảm ơn anh đã giải đáp thắc mắc lâu nay của tôi. Chuyển sang phần hai, với tư cách là người chứng kiến hành trình phát triển của Ethereum, tôi thấy Layer2 đã rất thành công. Vấn đề TPS hiện nay đã được giải quyết. Không còn cảnh tắc nghẽn như thời ICO nữa.
Cá nhân tôi thấy L2 hiện nay khá tiện dụng. Tuy nhiên, hiện tượng phân mảnh thanh khoản (liquidity fragment) ở L2 đang được nhiều người quan tâm và đề xuất các giải pháp.
Anh đánh giá thế nào về mối quan hệ giữa L1 và L2? Liệu có phải Ethereum mainnet hiện nay quá "buông lỏng", quá phi tập trung, mà không đặt ra ràng buộc nào cho L2? Liệu L1 có cần thiết lập quy tắc, mô hình chia sẻ lợi nhuận, hay áp dụng các giải pháp như Based Rollup? Justin Drake gần đây cũng đề xuất phương án này trên Bankless, tôi khá đồng tình. Anh nghĩ sao? Và tôi cũng tò mò, nếu đã có giải pháp cụ thể, thì khi nào sẽ triển khai?
Vitalik:
Theo tôi, hiện nay Layer2 của chúng ta đang có vài vấn đề.
Thứ nhất, tiến độ về mặt an ninh chưa đủ nhanh. Tôi luôn thúc đẩy các L2 nâng cấp lên Stage 1, và hy vọng năm nay có thể lên Stage 2. Tôi liên tục đốc thúc họ, đồng thời hỗ trợ L2BEAT trong việc minh bạch hóa dữ liệu ở khía cạnh này.
Thứ hai, vấn đề về khả năng tương tác giữa các L2. Giao dịch và truyền thông giữa hai L2 cần đơn giản, nhanh chóng và tiết kiệm chi phí hơn – đặc biệt khi hai L2 thuộc cùng một hệ sinh thái.
Năm ngoái, chúng tôi bắt đầu công việc này, hiện gọi là Open Intents Framework, cùng với Chain-specific addresses – phần lớn là các cải tiến về trải nghiệm người dùng (UX).
Theo tôi, vấn đề cross-chain giữa các L2 có thể 80% là vấn đề UX.
Dù giải quyết vấn đề UX có thể mất nhiều công sức, nhưng chỉ cần đúng hướng, những vấn đề phức tạp có thể trở nên đơn giản. Đây cũng là định hướng chúng tôi đang theo đuổi.
Một số việc cần tiến xa hơn. Ví dụ, thời gian rút tiền (withdraw) trên Optimistic Rollup hiện là một tuần. Nếu bạn có token trên Optimism hoặc Arbitrum, việc chuyển token về L1 hay sang L2 khác đều phải chờ một tuần.
Bạn có thể nhờ Market Maker đợi một tuần (và bạn phải trả phí cho họ). Người dùng thông thường có thể dùng Open Intents Framework Across Protocol để chuyển từ L2 này sang L2 khác – điều này khả thi với các giao dịch nhỏ. Nhưng với giao dịch lớn, thanh khoản của Market Maker vẫn bị giới hạn, dẫn đến phí giao dịch cao hơn. Tuần trước tôi đã đăng một bài viết [2], tôi ủng hộ phương pháp xác minh 2 trong 3: OP + ZK + TEE.
Bởi vì phương pháp 2 trong 3 có thể đồng thời thỏa mãn ba yêu cầu:
Yêu cầu thứ nhất là hoàn toàn Trustless – không cần Security Council (Hội đồng Bảo vệ), công nghệ TEE chỉ đóng vai trò hỗ trợ, do đó không cần tin tưởng hoàn toàn vào nó.
Yêu cầu thứ hai là chúng ta có thể bắt đầu dùng công nghệ ZK, tuy nhiên ZK vẫn còn non trẻ, nên chưa thể hoàn toàn phụ thuộc.
Yêu cầu thứ ba là giảm thời gian rút tiền từ một tuần xuống còn 1 giờ.
Hãy tưởng tượng, nếu người dùng dùng Open Intents Framework, chi phí thanh khoản của Market Maker sẽ giảm 168 lần. Vì thời gian chờ (để tái cân bằng) của Market Maker giảm từ 1 tuần xuống 1 giờ. Dài hạn, chúng tôi dự định giảm thời gian rút tiền từ 1 giờ xuống 12 giây (thời gian block hiện tại), và nếu dùng SSF thậm chí có thể xuống 4 giây.
Hiện tại chúng tôi cũng đang áp dụng zk-SNARK Aggregation, xử lý song song các proof ZK để giảm độ trễ (latency). Tất nhiên, nếu người dùng dùng ZK trực tiếp thì không cần qua Intents. Nhưng nếu qua Intents, chi phí sẽ rất thấp – tất cả nằm trong phần Khả năng tương tác (Interactability).
Về vai trò của L1, trong giai đoạn đầu lộ trình L2, nhiều người cho rằng chúng ta có thể sao chép hoàn toàn lộ trình của Bitcoin: L1 chỉ làm một vài việc rất ít như xác nhận proof, còn lại L2 làm tất cả.
Nhưng chúng tôi nhận ra rằng, nếu L1 hoàn toàn không đảm nhiệm vai trò gì, điều này sẽ rất nguy hiểm cho ETH.
Chúng ta đã từng nói, một trong những lo ngại lớn nhất của chúng ta là: sự thành công của các ứng dụng Ethereum không thể chuyển hóa thành thành công của ETH.
Nếu ETH không thành công, cộng đồng sẽ thiếu kinh phí, không thể hỗ trợ thế hệ ứng dụng tiếp theo. Nếu L1 hoàn toàn không có vai trò, trải nghiệm người dùng và toàn bộ kiến trúc sẽ bị kiểm soát bởi L2 và một vài ứng dụng. Sẽ không ai đại diện cho ETH. Do đó, nếu chúng ta phân bổ thêm vai trò cho L1 trong một số ứng dụng, điều đó sẽ tốt hơn cho ETH.
Chúng ta cần trả lời câu hỏi tiếp theo: L1 nên làm gì? L2 nên làm gì?
Tháng Hai, tôi đã đăng một bài viết [3], trong một thế giới lấy L2 làm trung tâm, có rất nhiều việc quan trọng cần L1 thực hiện. Ví dụ, L2 cần gửi proof lên L1; nếu một L2 gặp sự cố, người dùng cần dùng L1 để chuyển sang L2 khác; ngoài ra còn có Key Store Wallet, Oracle Data có thể đặt trên L1,... Có rất nhiều cơ chế cần dựa vào L1.
Một số ứng dụng giá trị cao, như DeFi, thực ra phù hợp hơn khi đặt trên L1. Lý do chính là vì DeFi có Time Horizon (kỳ đầu tư) dài, người dùng phải chờ rất lâu – một năm, hai năm, ba năm.
Điều này đặc biệt rõ trong thị trường dự đoán (prediction market). Đôi khi thị trường này đặt câu hỏi như: chuyện gì sẽ xảy ra vào năm 2028?
Khi đó nảy sinh vấn đề: nếu quản trị của một L2 có vấn đề, về lý thuyết, người dùng có thể rút (exit) khỏi L2 đó, chuyển về L1 hoặc sang L2 khác. Nhưng nếu trong L2 đó có một ứng dụng mà tài sản bị khóa trong hợp đồng thông minh dài hạn, người dùng sẽ không thể rút ra. Vì vậy, rất nhiều ứng dụng DeFi tưởng chừng an toàn về lý thuyết, thực tế lại không an toàn.
Vì những lý do này, một số ứng dụng vẫn nên được xây dựng trên L1, do đó chúng tôi lại bắt đầu chú trọng mở rộng khả năng của L1.
Hiện nay chúng tôi có một lộ trình: vào năm 2026, sẽ có khoảng bốn đến năm phương pháp nâng cao khả năng mở rộng của L1.
Thứ nhất là Delayed Execution (tách riêng việc xác minh và thực thi khối), nghĩa là mỗi Slot chỉ xác minh khối, rồi thực thi thực sự ở Slot tiếp theo. Ưu điểm là thời gian thực thi tối đa có thể tăng từ 200ms lên 3 hoặc 6 giây, tạo thêm thời gian xử lý [4].
Thứ hai là Block Level Access List, nghĩa là mỗi khối cần khai báo trong thông tin khối về các trạng thái tài khoản và lưu trữ cần truy cập – tương tự Stateless nhưng không có Witness. Ưu điểm là chúng ta có thể xử lý song song EVM và IO, một cách đơn giản để song song hóa.
Thứ ba là Multidimensional Gas Pricing [5], cho phép thiết lập dung lượng tối đa của khối – điều này rất quan trọng về mặt an ninh.
Và thứ tư là xử lý dữ liệu lịch sử (EIP4444), không yêu cầu mọi node lưu trữ vĩnh viễn mọi thông tin. Ví dụ, mỗi node chỉ cần lưu 1%, và dùng cách p2p để phân tán lưu trữ – node của bạn lưu một phần, node của anh ấy lưu phần khác. Như vậy, thông tin được lưu trữ phân tán hơn.
Vì vậy, nếu kết hợp bốn giải pháp này, chúng tôi tin rằng có thể tăng Gaslimit của L1 lên gấp 10 lần. Khi đó, các ứng dụng sẽ có cơ hội phụ thuộc nhiều hơn vào L1, làm nhiều việc hơn trên L1 – điều này tốt cho L1, và cũng tốt cho ETH.
Yan:
Được rồi, câu hỏi tiếp theo: tháng này chúng ta có thể đón nâng cấp Pectra chứ?
Vitalik:
Thực ra, chúng tôi hy vọng thực hiện hai việc: khoảng cuối tháng này tiến hành nâng cấp Pectra, sau đó vào Q3 hoặc Q4 sẽ thực hiện nâng cấp Fusaka.
Yan:
Ồ, nhanh vậy sao?
Vitalik:
Hy vọng là vậy.
Yan:
Tôi có câu hỏi tiếp theo liên quan đến điều này. Với tư cách là người theo dõi sự trưởng thành của Ethereum, chúng tôi biết rằng để đảm bảo an toàn, Ethereum có khoảng năm đến sáu client (client đồng thuận và client thực thi) đang được phát triển song song, dẫn đến khối lượng công việc phối hợp rất lớn và chu kỳ phát triển kéo dài.
Điều này có lợi có hại. So với các L1 khác, tốc độ có vẻ chậm hơn, nhưng lại an toàn hơn.
Vậy có giải pháp nào để chúng ta không phải chờ đến một năm rưỡi mới có một lần nâng cấp? Tôi cũng thấy anh từng đề cập một số phương án, anh có thể chia sẻ cụ thể hơn không?
Vitalik:
Đúng vậy, một giải pháp là tăng hiệu quả phối hợp. Hiện nay ngày càng có nhiều người luân chuyển giữa các nhóm, giúp giao tiếp giữa các nhóm hiệu quả hơn.
Nếu một nhóm client gặp vấn đề, họ có thể nêu ra để nhóm nghiên cứu biết. Ưu điểm của Thomas khi trở thành ED mới của chúng tôi chính là điều này – anh ấy vốn thuộc nhóm client, giờ lại nằm trong EF, nên có thể làm cầu nối phối hợp – đó là điểm thứ nhất.
Điểm thứ hai là chúng ta có thể yêu cầu nghiêm khắc hơn với các nhóm client. Hiện tại, nếu có năm nhóm, chúng ta cần cả năm nhóm đều sẵn sàng mới công bố hard fork tiếp theo. Bây giờ chúng tôi đang cân nhắc chỉ cần bốn nhóm hoàn tất là có thể bắt đầu nâng cấp, không cần chờ nhóm chậm nhất – điều này cũng khuyến khích tinh thần làm việc của mọi người.
04 Quan điểm về mật mã học và AI
Yan:
Vậy là cần có sự cạnh tranh vừa phải. Khá tốt. Mỗi lần nâng cấp đều đáng mong đợi, nhưng đừng để mọi người chờ quá lâu.
Tiếp theo, tôi muốn hỏi về mật mã học – câu hỏi hơi lan man một chút.
Năm 2021, khi cộng đồng chúng tôi mới thành lập, chúng tôi tập hợp các nhà phát triển từ các sàn giao dịch lớn trong nước và các nhà nghiên cứu từ các quỹ Venture để thảo luận về DeFi. Năm 2021 đúng là thời điểm mọi người đều tham gia tìm hiểu, học tập và thiết kế DeFi – một trào lưu toàn dân.
Nhưng về sau, đối với ZK, dù là đại chúng hay nhà phát triển, việc học ZK – như Groth16, Plonk, Halo2 – ngày càng khó theo kịp, và tiến bộ kỹ thuật lại diễn ra rất nhanh.
Một xu hướng khác là ZKVM đang phát triển nhanh, khiến hướng ZKEVM không còn hấp dẫn như trước. Khi ZKVM dần trưởng thành, nhà phát triển cũng không cần quá quan tâm đến tầng底层 ZK.
Về điều này, anh có lời khuyên hay quan điểm gì?
Vitalik:
Theo tôi, trong hệ sinh thái ZK, hướng đi tốt nhất là phần lớn nhà phát triển ZK nên biết một ngôn ngữ cấp cao (HLL - High Level Language). Họ có thể viết code ứng dụng trong HLL, trong khi các nhà nghiên cứu hệ thống proof tiếp tục cải tiến và tối ưu thuật toán底层. Nhà phát triển cần được phân tầng, họ không cần biết những gì đang xảy ra ở tầng dưới.
Hiện tại có một vấn đề: sinh thái Circom và Groth16 rất phát triển, nhưng điều này lại gây giới hạn lớn cho các ứng dụng ZK. Vì Groth16 có nhiều nhược điểm, ví dụ như mỗi ứng dụng đều cần Trusted Setup riêng, và hiệu suất cũng không cao, nên chúng tôi đang cân nhắc dành thêm nguồn lực để hỗ trợ các HLL hiện đại đạt được thành công.
Một hướng đi tốt khác là ZK RISC-V. Vì RISC-V cũng có thể trở thành một HLL, rất nhiều ứng dụng, kể cả EVM và các ứng dụng khác, đều có thể được viết trên nền RISC-V [6].
Yan:
Ổn rồi, như vậy nhà phát triển chỉ cần học Rust là được. Năm ngoái tôi tham dự Devcon Bangkok cũng được nghe về sự phát triển của mật mã học ứng dụng – điều này khiến tôi rất ấn tượng.
Về mật mã học ứng dụng, anh đánh giá thế nào về hướng kết hợp ZKP với MPC và FHE, và có lời khuyên gì cho các nhà phát triển?
Vitalik:
Đúng vậy, điều này rất thú vị. Theo tôi, triển vọng của FHE hiện nay rất tốt, nhưng tôi lo ngại một điều: MPC và FHE luôn cần một Ủy ban (Committee) – ví dụ như chọn bảy hoặc nhiều hơn các nút. Nếu những nút này bị tấn công 51% hoặc 33%, hệ thống sẽ gặp sự cố. Điều này tương đương với việc hệ thống có một Security Council – thậm chí còn nghiêm trọng hơn. Vì nếu một L2 ở Stage 1, Security Council cần bị tấn công tới 75% nút mới gặp vấn đề [7] – đó là điểm thứ nhất.
Điểm thứ hai là Security Council: nếu họ đáng tin cậy, phần lớn khóa sẽ được lưu trong ví lạnh (offline). Nhưng trong hầu hết MPC và FHE, Ủy ban cần phải online liên tục để hệ thống vận hành, nên họ thường triển khai trên VPS hoặc máy chủ khác – điều này khiến họ dễ bị tấn công hơn.
Điều này khiến tôi hơi lo lắng. Tôi nghĩ nhiều ứng dụng vẫn có thể triển khai, có ưu điểm, nhưng không hoàn hảo.
Yan:
Cuối cùng, tôi xin hỏi một câu hỏi nhẹ nhàng hơn. Tôi thấy gần đây anh cũng quan tâm đến AI. Tôi xin nêu vài quan điểm:
Ví dụ Elon Musk nói con người có thể chỉ là chương trình khởi động cho nền văn minh silicon.
Sau đó, trong cuốn “Nation States on the Internet”, có quan điểm cho rằng các quốc gia tập quyền có thể thích AI hơn, trong khi các quốc gia dân chủ thích blockchain hơn.
Từ kinh nghiệm trong giới tiền mã hóa, chúng tôi thấy tiền đề của phi tập trung là mọi người tuân thủ quy tắc, kiểm soát lẫn nhau và biết chấp nhận rủi ro – điều này cuối cùng lại dẫn đến chính trị tinh hoa. Vậy anh nghĩ sao về những quan điểm này? Chỉ cần trao đổi ý kiến.
Vitalik:
Ừm, tôi đang suy nghĩ nên bắt đầu từ đâu.
Bởi vì lĩnh vực AI rất phức tạp. Ví dụ năm năm trước, chẳng ai dự đoán được Mỹ sẽ có AI nguồn đóng tốt nhất thế giới, trong khi Trung Quốc lại có AI nguồn mở tốt nhất. AI có thể nâng cao năng lực của tất cả mọi người, nhưng đôi khi cũng làm tăng quyền lực của các chế độ tập quyền.
Nhưng AI đôi khi cũng mang lại hiệu ứng dân chủ hóa. Khi tôi dùng AI, tôi nhận thấy trong những lĩnh vực mà bản thân đã nằm trong top 1000 thế giới – ví dụ như phát triển ZK – thì AI hỗ trợ tôi khá ít, tôi vẫn phải tự viết phần lớn code. Nhưng trong những lĩnh vực tôi là người mới, AI giúp đỡ tôi rất nhiều. Ví dụ, phát triển ứng dụng Android – trước đây tôi chưa từng làm. Mười năm trước tôi từng làm một app bằng framework JavaScript chuyển thành app, nhưng chưa từng viết ứng dụng Android gốc nào.
Đầu năm nay tôi làm một thí nghiệm: thử dùng GPT để viết một app, kết quả chỉ mất một giờ là xong. Rõ ràng khoảng cách giữa chuyên gia và người mới đã được AI thu hẹp rất nhiều, và AI còn mở ra nhiều cơ hội mới.
Yan:
Bổ sung một chút, cảm ơn anh đã cho tôi một góc nhìn mới. Trước đây tôi nghĩ có AI, lập trình viên có kinh nghiệm sẽ học nhanh hơn, còn lập trình viên mới thì bất lợi. Nhưng đúng là ở một khía cạnh nào đó, AI cũng nâng cao năng lực của người mới. Có lẽ đây là sự bình quyền, chứ không phải phân hóa.
Vitalik:
Đúng vậy. Nhưng hiện nay, một vấn đề quan trọng và cần suy ngẫm là: các công nghệ chúng ta đang làm – bao gồm blockchain, AI, mật mã học và các công nghệ khác – khi kết hợp lại sẽ tạo ra hiệu ứng gì đối với xã hội.
Yan:
Vậy anh vẫn hy vọng con người sẽ không chỉ bị cai trị bởi tầng lớp tinh hoa, mà mong muốn đạt được trạng thái tối ưu Pareto cho toàn xã hội. Người bình thường được trao quyền qua AI và blockchain để trở thành cá nhân siêu việt.
Vitalik:
Đúng vậy, cá nhân siêu việt, cộng đồng siêu việt, con người siêu việt.
05 Kỳ vọng với hệ sinh thái Ethereum và lời khuyên cho các nhà phát triển
Yan:
OK, chúng ta đến câu hỏi cuối cùng: anh có kỳ vọng hay nhắn nhủ gì với cộng đồng nhà phát triển? Có điều gì anh muốn nói với các nhà phát triển trong cộng đồng Ethereum?
Vitalik:
Với các nhà phát triển ứng dụng Ethereum, hãy suy nghĩ kỹ.
Hiện nay, phát triển ứng dụng trên Ethereum có rất nhiều cơ hội, rất nhiều việc trước đây không thể làm thì nay đã có thể.
Có nhiều lý do:
Thứ nhất: Trước đây TPS của L1 hoàn toàn không đủ, giờ đây vấn đề này đã được giải quyết;
Thứ hai: Trước đây không thể giải quyết vấn đề riêng tư, giờ đây đã có thể;
Thứ ba: Vì có AI, độ khó khi phát triển mọi thứ đều giảm xuống. Dù độ phức tạp của hệ sinh thái Ethereum có tăng lên, nhưng nhờ AI, mọi người đều có thể hiểu Ethereum dễ dàng hơn.
Vì vậy, tôi nghĩ rất nhiều việc trước đây – dù là 10 năm hay 5 năm trước – thất bại, giờ đây có thể thành công.
Trong hệ sinh thái ứng dụng blockchain hiện nay, theo tôi vấn đề lớn nhất là chúng ta có hai loại ứng dụng.
Loại thứ nhất là rất cởi mở, phi tập trung, an toàn, cực kỳ lý tưởng – nhưng chỉ có 42 người dùng. Loại thứ hai là sòng bạc. Vấn đề là cả hai cực đoan này đều không lành mạnh.
Vì vậy, chúng tôi hy vọng có thể xây dựng những ứng dụng:
Thứ nhất, người dùng thực sự thích dùng – tức là mang lại giá trị thực sự.
Những ứng dụng này khiến thế giới tốt đẹp hơn.
Thứ hai, có mô hình kinh doanh thực sự – ví dụ về mặt kinh tế, có thể vận hành bền vững, không phải dựa mãi vào tiền từ các quỹ tài trợ hữu hạn hay tổ chức khác – đây cũng là một thách thức.
Nhưng hiện nay tôi thấy mọi người đều có nhiều nguồn lực hơn trước, nên nếu bạn tìm được ý tưởng tốt, và làm tốt, thì cơ hội thành công là rất lớn.
Yan:
Nhìn lại hành trình, tôi thấy Ethereum thực sự rất thành công, luôn dẫn dắt ngành công nghiệp, và nỗ lực giải quyết các vấn đề gặp phải trong ngành dưới tiền đề phi tập trung.
Một điều khác khiến tôi rất xúc động: cộng đồng chúng tôi luôn hoạt động phi lợi nhuận. Nhờ các chương trình tài trợ Gitcoin trong hệ sinh thái Ethereum, phần thưởng hồi tố từ OP, và các phần thưởng airdrop từ các dự án khác, chúng tôi nhận ra rằng xây dựng trong cộng đồng Ethereum có thể nhận được rất nhiều hỗ trợ. Chúng tôi cũng đang suy nghĩ làm sao để cộng đồng có thể vận hành ổn định và bền vững.
Việc xây dựng Ethereum thực sự đầy cảm hứng. Chúng tôi cũng mong sớm được chứng kiến sự hiện thực hóa của "máy tính toàn cầu". Cảm ơn anh đã dành thời gian quý báu.
Phỏng vấn tại Mosher岭, Hồng Kông
Ngày 07 tháng 04 năm 2025
Cuối cùng là bức ảnh chụp cùng Vitalik 📷
Dưới đây là các tài liệu tham khảo mà Vitalik đề cập trong bài viết, được biên tập viên tổng hợp:
[1]:
https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870
[2]:
https://ethereum-magicians.org/t/a-simple-l2-security-and-finalization-roadmap/23309
[3]:
https://vitalik.eth.limo/general/2025/02/14/l1scaling.html
[4]:
https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677
[5]:
https://vitalik.eth.limo/general/2024/05/09/multidim.html
[6]:
https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
[7]:
https://specs.optimism.io/protocol/stage-1.html?highlight=75#stage-1-rollup
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
