Vitalik phản hồi Musk: Việc cải thiện khả năng mở rộng của blockchain không hề đơn giản
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik phản hồi Musk: Việc cải thiện khả năng mở rộng của blockchain không hề đơn giản
Khi dung lượng tăng lên, số lượng nút tối thiểu cũng tăng theo, đồng thời chi phí cho chuỗi lưu trữ (nếu không ai chịu quản lý chuỗi lưu trữ, rủi ro mất dữ liệu sẽ gia tăng) cũng tăng lên.
Chuyên sâu báo cáo Web3Tác giả: Vitalik Buterin
Dịch: Alyson biên dịch
Gần đây, Elon Musk - người sáng lập Tesla - đã đăng tweet cho rằng Dogecoin lý tưởng nên tăng tốc độ xác nhận khối lên 10 lần, mở rộng kích thước khối lên 10 lần và giảm phí giao dịch xuống 100 lần, khi đó nó sẽ dễ dàng chiến thắng.
Phát biểu này đã vấp phải nhiều chỉ trích từ các KOL trong ngành tiền mã hóa. Vitalik Buterin, người sáng lập Ethereum, hôm nay cũng viết bài bình luận về vấn đề này, nhấn mạnh rằng việc đơn giản nâng cao các tham số mạng blockchain sẽ gây ra nhiều rắc rối hơn, đồng thời phân tích chi tiết những khó khăn và giới hạn mà blockchain gặp phải khi cải thiện hiệu suất. Dưới đây là bản dịch bài viết (đã lược bỏ một phần nhưng không làm thay đổi ý chính).
Khả năng mở rộng của blockchain có thể đạt đến đâu? Liệu như Elon Musk mong muốn, ta có thể thực sự "rút ngắn thời gian xác nhận khối 10 lần, tăng kích thước khối lên 10 lần và giảm phí giao dịch xuống 100 lần", mà không dẫn đến tập trung hóa cực đoan và làm tổn hại đến các thuộc tính cốt lõi của blockchain hay không? Nếu không, giới hạn nằm ở đâu? Điều gì xảy ra nếu bạn thay đổi thuật toán đồng thuận? Quan trọng hơn, điều gì xảy ra nếu bạn thay đổi công nghệ để đưa vào các chức năng như ZK-SNARK hoặc phân mảnh (sharding)?
Thực tế cho thấy, dù có phân mảnh hay không, vẫn tồn tại những yếu tố kỹ thuật quan trọng và tinh vi hạn chế khả năng mở rộng của blockchain. Trong nhiều trường hợp, những giới hạn này có giải pháp, nhưng ngay cả khi có giải pháp thì vẫn tồn tại giới hạn. Bài viết này sẽ đi sâu vào các vấn đề đó.
1. Các nút cần đủ mức phi tập trung
Vào lúc 2h35 sáng, bạn nhận được cuộc gọi khẩn cấp từ đối tác ở đầu bên kia thế giới, người đang giúp bạn quản lý mỏ đào (hoặc nhóm stake). Từ khoảng 14 phút trước, đối tác thông báo rằng mỏ của bạn và một vài nhóm khác đã bị tách khỏi chuỗi khối đang được 79% mạng lưới còn lại duy trì. Theo nút của bạn, các khối trên chuỗi đa số là vô hiệu. Có lỗi về số dư: một khối then chốt dường như đã cấp sai 4,5 triệu token bổ sung cho một địa chỉ chưa xác định.
Một giờ sau, bạn đang trò chuyện qua Telegram với hai nhóm đào nhỏ khác. Cuối cùng bạn thấy ai đó dán liên kết đến một bài tweet chứa thông báo được phát hành. Bài tweet bắt đầu bằng: "Thông báo về Quỹ phát triển giao thức bền vững mới trên chuỗi".
Đến sáng, các tranh luận trên Twitter và diễn đàn cộng đồng lan rộng khắp nơi. Nhưng lúc này, phần lớn trong số 4,5 triệu token đã được chuyển đổi thành tài sản khác trên chuỗi, và hàng tỷ USD giao dịch DeFi đã diễn ra. 79% các nút đồng thuận, cũng như tất cả các trình khám phá blockchain và ví nhẹ chính đều tuân theo chuỗi mới này.
Có thể quỹ phát triển mới sẽ tài trợ cho một số dự án phát triển, hoặc có thể toàn bộ số tiền này đã bị các sàn giao dịch hàng đầu nuốt chửng. Nhưng bất kể kết quả ra sao, quỹ này về cơ bản đã trở thành hiện thực, và người dùng bình thường hoàn toàn bất lực.
Liệu điều này có thể xảy ra trên blockchain của bạn không? Cộng đồng tinh hoa trên blockchain của bạn có thể phối hợp rất tốt — gồm các mỏ đào, trình khám phá khối và các nút lưu trữ. Họ rất có thể đều nằm trong cùng một kênh Telegram và nhóm WeChat. Nếu họ thực sự muốn thay đổi đột ngột quy tắc giao thức để phục vụ lợi ích riêng, họ có thể làm được điều đó. Cách duy nhất đáng tin cậy để vô hiệu hóa kiểu tấn công xã hội phối hợp này là phòng thủ thụ động — thông qua tập thể người dùng.
Hãy hình dung nếu mỗi người dùng đều chạy một nút xác minh chuỗi khối, tự động từ chối các khối vi phạm quy tắc giao thức (ngay cả khi hơn 90% thợ đào hoặc cổ đông ủng hộ), câu chuyện sẽ diễn ra thế nào. Nếu mọi người dùng đều chạy nút xác minh, cuộc tấn công sẽ nhanh chóng thất bại: một vài mỏ đào và sàn giao dịch sẽ bị tách nhánh, trông khá ngu ngốc.
Nhưng ngay cả khi chỉ một số người dùng chạy nút xác minh, kẻ tấn công cũng không thể giành chiến thắng hoàn toàn; thay vào đó, nó sẽ gây ra hỗn loạn, khi các người dùng khác nhau nhìn thấy các phiên bản chuỗi khác nhau. Ít nhất, sự hoảng loạn thị trường và nguy cơ chia rẽ kéo dài sẽ làm giảm đáng kể lợi nhuận của kẻ tấn công. Chính ý nghĩ phải đối mặt với một cuộc xung đột dai dẳng như vậy đã đủ để ngăn chặn phần lớn các cuộc tấn công.
Bài tweet của Hasu, đối tác nghiên cứu tại Paradigm
Nếu cộng đồng bạn gồm 37 nút chạy chương trình và 80.000 chương trình nghe thụ động kiểm tra chữ ký và tiêu đề khối, thì kẻ tấn công thắng. Nếu cộng đồng bạn có mọi người dùng đều chạy một nút, kẻ tấn công sẽ thất bại. Chúng ta không biết ngưỡng chính xác nào tạo ra miễn dịch nhóm chống lại các cuộc tấn công phối hợp, nhưng có một điều tuyệt đối rõ ràng: càng nhiều nút càng tốt, càng ít nút càng xấu, và chúng ta chắc chắn cần hàng chục hoặc hàng trăm nút trở lên.
2. Giới hạn công suất xử lý của nút nằm ở đâu?
Để tối đa hóa số lượng người dùng có thể chạy nút, chúng ta tập trung vào phần cứng tiêu dùng thông thường. Khả năng xử lý giao dịch của một nút đầy đủ bị giới hạn bởi ba yếu tố chính:
-
Hiệu suất tính toán: Phần trăm CPU cần thiết để vận hành an toàn một nút là bao nhiêu?
-
Băng thông: Với thực tế kết nối Internet hiện nay, một khối có thể chứa bao nhiêu byte?
-
Lưu trữ: Chúng ta có thể yêu cầu người dùng lưu trữ bao nhiêu GB dữ liệu trên ổ đĩa? Và tốc độ đọc phải nhanh đến đâu? (Tức là có thể dùng ổ cứng HDD hay bắt buộc phải dùng SSD?)
Nhiều người sai lầm khi nghĩ rằng blockchain có thể mở rộng rất xa nhờ các công nghệ "đơn giản", do quá lạc quan về các con số này. Hãy lần lượt xem xét ba yếu tố:
1) Hiệu suất tính toán
Câu trả lời sai: 100% hiệu suất CPU có thể dành cho việc xác minh khối.
Câu trả lời đúng: Khoảng 5-10% hiệu suất CPU có thể dùng cho việc xác minh khối.
Có bốn lý do chính khiến tỷ lệ này thấp đến vậy:
-
Chúng ta cần một biên an toàn để phòng khả năng bị tấn công DoS (kẻ tấn công có thể gửi giao dịch khai thác điểm yếu trong mã, đòi hỏi thời gian xử lý lâu hơn giao dịch thông thường);
-
Nút cần có khả năng đồng bộ lại blockchain sau khi ngắt kết nối. Nếu tôi mất kết nối mạng trong một phút, tôi phải có thể bắt kịp chỉ trong vài giây;
-
Việc chạy nút không nên nhanh chóng làm cạn pin hoặc làm chậm tất cả ứng dụng khác;
-
Nút còn phải thực hiện các nhiệm vụ khác ngoài xác minh khối, chủ yếu là xác minh và phản hồi các giao dịch và yêu cầu đến qua mạng p2p.
Lưu ý rằng cho đến gần đây, hầu hết các giải thích cho câu hỏi "Tại sao chỉ có 5-10%?" tập trung vào một vấn đề khác: vì các khối PoW xuất hiện ngẫu nhiên, nếu thời gian xác minh khối quá dài sẽ làm tăng nguy cơ tạo ra nhiều khối đồng thời.
Có nhiều cách giải quyết vấn đề này (ví dụ như Bitcoin NG hoặc chỉ sử dụng cơ chế Proof-of-Stake). Tuy nhiên, những bản vá này không giải quyết được bốn vấn đề còn lại, do đó chúng không mang lại lợi ích mở rộng lớn như nhiều người từng nghĩ ban đầu.
Tính song song cũng không phải là giải pháp vạn năng. Thông thường, thậm chí các client blockchain trông có vẻ đơn luồng cũng đã được song song hóa: một luồng xử lý xác minh chữ ký, các luồng khác xử lý thực thi, và một luồng riêng xử lý logic pool giao dịch nền. Hơn nữa, càng gần mức sử dụng 100% tất cả các luồng, thì năng lượng tiêu thụ khi chạy nút càng lớn, và biên an toàn chống DoS càng thấp.
2) Băng thông
Câu trả lời sai: Nếu cứ 2-3 giây lại có khối 10MB, mà đa số người dùng có tốc độ mạng >10MB/giây, thì họ đương nhiên có thể xử lý được.
Câu trả lời đúng: Có lẽ chúng ta chỉ có thể xử lý khối 1-5MB mỗi 12 giây, và điều này đã là rất khó rồi.
Ngày nay, chúng ta thường nghe các con số quảng cáo về băng thông kết nối Internet: thường thấy các con số 100 Mbps hoặc thậm chí 1 Gbps. Tuy nhiên, có sự khác biệt lớn giữa băng thông quảng cáo và thực tế do các lý do sau:
-
"Mbps" nghĩa là "triệu bit mỗi giây", trong khi một byte gồm 8 bit, do đó cần chia băng thông quảng cáo cho 8 để ra giá trị byte;
-
Giống như mọi công ty khác, nhà cung cấp Internet thường nói dối;
-
Luôn có nhiều ứng dụng cùng sử dụng chung kết nối Internet, nên nút không thể chiếm toàn bộ băng thông;
-
Mạng p2p luôn đi kèm chi phí phát sinh: các nút thường tải xuống và tải lại cùng một khối nhiều lần (chưa kể các giao dịch được phát tán qua mempool trước khi vào khối).
Khi Starkware thử nghiệm vào năm 2019, họ lần đầu tiên phát hành khối 500KB, điều này trở nên khả thi do chi phí gas giao dịch giảm. Thực tế là có một vài nút không thể xử lý khối kích thước này.
Kể từ đó, khả năng xử lý khối lớn của blockchain đã được cải thiện và sẽ tiếp tục cải thiện. Nhưng dù chúng ta làm gì, chúng ta vẫn còn rất xa so với việc đơn giản lấy băng thông trung bình tính bằng MB/giây, tin rằng mình có thể chấp nhận độ trễ 1 giây và có thể xử lý khối lớn như vậy.
3) Lưu trữ
Câu trả lời sai: 10TB.
Câu trả lời đúng: 512GB.
Như bạn có thể đoán, lập luận chính ở đây cũng giống như ở những nơi khác: sự khác biệt giữa lý thuyết và thực tế. Về lý thuyết, bạn có thể mua ổ SSD 8TB trên Amazon. Trên thực tế, chiếc laptop dùng để viết bài blog này chỉ có 512GB, và nếu yêu cầu mọi người tự mua phần cứng, nhiều người sẽ ngại (hoặc không đủ tiền mua ổ SSD 8TB giá 800 đô la), và thay vào đó sử dụng nhà cung cấp tập trung.
Hơn nữa, ngay cả khi bạn có thể cài đặt và vận hành nút khối trên một số ổ lưu trữ, mức độ hoạt động cao cũng dễ dàng nhanh chóng làm hỏng ổ đĩa, buộc bạn phải liên tục mua ổ mới.
Ngoài ra, kích thước lưu trữ quyết định thời gian cần thiết để một nút mới có thể kết nối và bắt đầu tham gia mạng. Mọi dữ liệu mà nút hiện tại phải lưu trữ đều là dữ liệu mà nút mới phải tải xuống. Thời gian đồng bộ khởi tạo (và băng thông) cũng là rào cản chính khiến người dùng ngại chạy nút. Khi viết bài blog này, việc đồng bộ một nút geth mới mất tôi khoảng 15 giờ.
3. Rủi ro của blockchain phân mảnh (sharding)
Ngày nay, việc vận hành một nút trên blockchain Ethereum đã là thách thức với nhiều người dùng. Vì vậy, chúng ta gặp phải điểm nghẽn. Vấn đề lớn nhất mà các nhà phát triển lõi quan tâm là kích thước lưu trữ. Hiện tại, mọi nỗ lực giải quyết các điểm nghẽn về tính toán và dữ liệu, thậm chí là thay đổi thuật toán đồng thuận, cũng khó có thể dẫn đến tăng đáng kể giới hạn gas. Ngay cả khi khắc phục được lỗ hổng DoS nghiêm trọng nhất của Ethereum, giới hạn gas cũng chỉ tăng thêm khoảng 20%.
Cách duy nhất để giải quyết vấn đề kích thước lưu trữ là trạng thái vô tình (statelessness) và hết hạn trạng thái (state expiry). Statelessness cho phép một lớp nút xác minh blockchain mà không cần duy trì lưu trữ vĩnh viễn. State expiry sẽ xóa các trạng thái chưa được truy cập gần đây, buộc người dùng phải cung cấp bằng chứng gia hạn thủ công.
Cả hai hướng đi này đã được nghiên cứu trong thời gian dài, và các bản demo nguyên mẫu về statelessness cũng đã bắt đầu xuất hiện. Sự kết hợp của hai cải tiến này có thể làm giảm đáng kể những lo ngại này và mở ra không gian để tăng giới hạn gas đáng kể. Tuy nhiên, ngay cả sau khi triển khai statelessness và state expiry, giới hạn gas có thể chỉ được tăng an toàn khoảng 3 lần, trước khi các giới hạn khác bắt đầu chi phối.
Phân mảnh (sharding) về cơ bản vượt qua các giới hạn trên bằng cách tách rời dữ liệu được chứa trên blockchain khỏi dữ liệu mà một nút đơn cần xử lý và lưu trữ. Nó sử dụng các kỹ thuật toán học và mật mã tiên tiến để xác minh gián tiếp khối, thay vì các nút phải tự tải xuống và thực thi để xác minh.
Do đó, blockchain phân mảnh có thể đạt được mức thông lượng giao dịch mà blockchain không phân mảnh không thể đạt tới một cách an toàn. Điều này thực sự đòi hỏi trí tuệ mật mã lớn để tạo ra cách xác minh hoàn chỉnh hiệu quả và đơn giản, từ chối thành công các khối vô hiệu, nhưng điều này là khả thi: lý thuyết đã chín muồi, và các bản demo nguyên mẫu dựa trên bản thảo đặc tả đang được phát triển.
Ethereum dự định sử dụng phân mảnh bậc hai, vì các nút phải xử lý được một phân mảnh đơn lẻ và chuỗi beacon (phải thực hiện một lượng công việc nhất định cho mỗi phân mảnh), do đó tổng khả năng mở rộng bị giới hạn. Nếu phân mảnh quá lớn, các nút sẽ không thể xử lý một phân mảnh đơn; nếu quá nhiều phân mảnh, các nút sẽ không thể xử lý chuỗi beacon. Tích số của hai giới hạn này tạo thành ngưỡng trên.
Có thể hình dung rằng bằng cách thực hiện phân mảnh bậc ba hoặc thậm chí phân mảnh theo hàm mũ, ta có thể đi xa hơn. Trong thiết kế như vậy, việc lấy mẫu tính sẵn có dữ liệu (data availability sampling) chắc chắn sẽ phức tạp hơn rất nhiều, nhưng điều này là có thể thực hiện được. Tuy nhiên, Ethereum sẽ không đi xa hơn mức bậc hai. Lý do là, phân mảnh giao dịch thực sự không thể mang lại lợi ích mở rộng bổ sung nào, trừ khi rủi ro trở nên rất cao.
Vậy những rủi ro đó là gì?
1) Số lượng người dùng tối thiểu
Có thể hình dung rằng, một blockchain không phân mảnh có thể vận hành chỉ cần một người dùng tham gia. Blockchain phân mảnh thì không như vậy: không nút nào có thể xử lý toàn bộ blockchain, do đó cần đủ nút để cùng xử lý. Nếu mỗi nút có thể xử lý 50 TPS, và blockchain cần xử lý 10.000 TPS, thì cần ít nhất 200 nút trên mạng.
Nếu blockchain này bất kỳ lúc nào có ít hơn 200 nút, thì hoặc các nút không thể theo kịp blockchain, hoặc không thể phát hiện khối vô hiệu, hoặc có thể xảy ra nhiều tình huống xấu khác, tùy thuộc vào cách cài đặt phần mềm nút.
Nếu công suất blockchain phân mảnh tăng gấp 10 lần, số lượng nút tối thiểu cũng tăng gấp 10 lần. Vậy bạn có thể hỏi: tại sao không bắt đầu với công suất nhỏ, khi thấy lượng người dùng đổ vào thì tăng công suất, và khi người dùng giảm thì giảm công suất? Như vậy ta chỉ sử dụng đúng phần cần thiết.
Tuy nhiên có một số vấn đề:
-
Bản thân blockchain không thể xác định chính xác số lượng nút độc lập, do đó cần một dạng quản trị nào đó để phát hiện và thiết lập số lượng phân mảnh. Vượt quá giới hạn công suất dễ trở thành nguồn gốc gây chia rẽ và xung đột.
-
Nếu nhiều người dùng bất ngờ rút lui đột ngột thì sao?
-
Tăng số lượng nút tối thiểu cần thiết để khởi động phân nhánh sẽ làm cho việc chống lại việc mua lại ác ý trở nên khó khăn hơn.
Gần như chắc chắn số lượng nút tối thiểu không nên vượt quá 1000. Do đó, rất khó để biện minh cho một blockchain có hàng trăm phân mảnh.
2) Khả năng truy xuất lịch sử
Một thuộc tính quan trọng của blockchain mà người dùng thực sự trân trọng là tính vĩnh viễn. Khi một công ty phá sản hoặc mất khả năng duy trì hệ sinh thái, các tài sản số lưu trữ trên máy chủ sẽ bị xóa sau 10 năm. Mặt khác, NFT trên Ethereum là vĩnh viễn.
Đúng vậy, người ta vẫn sẽ tải xuống và truy xuất mèo mã hóa của bạn vào năm 2371.
Tuy nhiên, một khi công suất blockchain quá cao, việc lưu trữ tất cả dữ liệu này sẽ trở nên khó khăn hơn. Nếu một lúc nào đó rủi ro quá lớn, một phần lịch sử sẽ không còn ai lưu trữ.
Việc định lượng rủi ro này khá dễ. Lấy dung lượng dữ liệu blockchain (MB/giây), nhân với 30 để có dữ liệu lưu trữ hàng năm tính bằng TB. Kế hoạch phân mảnh hiện tại có dung lượng khoảng 1,3 MB/giây, tức khoảng 40 TB/năm. Nếu tăng gấp 10 lần, sẽ thành 400 TB/năm.
Nếu chúng ta muốn dữ liệu không chỉ có thể truy cập mà còn dễ dàng truy xuất, thì còn cần dữ liệu phụ (ví dụ: giải nén các giao dịch rollup), do đó cần 4 PB mỗi năm, hoặc 10 năm cần 40 PB. Đây là giới hạn trên hợp lý mà hầu hết blockchain phân mảnh có thể đạt được một cách an toàn.
Do đó, dường như trên cả hai chiều này, thiết kế phân mảnh của Ethereum thực tế đã nhắm đến giá trị an toàn tối đa hợp lý. Các tham số có thể tăng một chút, nhưng không thể tăng quá nhiều.
4. Tổng kết
Có hai cách tiếp cận để mở rộng blockchain: cải tiến kỹ thuật cơ bản và đơn giản tăng các tham số. Trước tiên, tăng tham số nghe có vẻ hấp dẫn: nếu bạn tính toán trên giấy ăn, bạn dễ dàng thuyết phục bản thân rằng một chiếc laptop thông thường có thể xử lý hàng nghìn giao dịch mỗi giây, không cần ZK-SNARK, rollup hay phân mảnh. Tiếc thay, phương pháp này về căn bản là sai lầm, với rất nhiều lý do tinh vi.
Máy tính chạy nút blockchain không thể dùng 100% hiệu suất CPU để xác minh blockchain; chúng cần biên an toàn lớn để chống lại các cuộc tấn công DoS bất ngờ, cần dung lượng dự phòng để xử lý các nhiệm vụ như xử lý giao dịch trong mempool. Và người dùng không muốn việc chạy nút khiến máy tính của họ không thể dùng cho bất kỳ ứng dụng nào khác.
Băng thông cũng có chi phí phát sinh: kết nối 10MB/giây không có nghĩa là bạn có thể có khối 10MB mỗi giây, mà có thể chỉ có khối 1-5MB mỗi 12 giây, tương tự như lưu trữ. Việc tăng cấu hình phần cứng chạy nút và giới hạn việc vận hành nút cho một nhóm người tham gia nhất định không phải là giải pháp. Đối với một blockchain muốn phi tập trung, điều quan trọng là người dùng thông thường có thể chạy nút và văn hóa phổ biến việc chạy nút phải tồn tại.
Các cải tiến kỹ thuật cơ bản chắc chắn có tác dụng. Hiện tại, điểm nghẽn chính của Ethereum là dung lượng lưu trữ, và statelessness cùng state expiry có thể giải quyết vấn đề này, cho phép tăng giới hạn gas lên khoảng 3 lần (nhưng không đến 300 lần), bởi vì chúng ta muốn việc chạy nút trở nên dễ dàng hơn hiện tại. Blockchain phân mảnh có thể mở rộng hơn nữa, vì không nút đơn nào cần xử lý mọi giao dịch.
Tuy nhiên, ngay cả như vậy, vẫn có giới hạn: khi công suất tăng, số lượng nút tối thiểu cũng tăng, và chi phí lưu trữ dữ liệu lịch sử (nếu không ai buồn quản lý, rủi ro mất dữ liệu tăng lên) cũng tăng.
Nhưng chúng ta không cần quá lo lắng: những giới hạn này đủ cao để chúng ta có thể xử lý hơn một triệu giao dịch mỗi giây một cách an toàn trên blockchain. Tuy nhiên, để đạt được điều đó mà không đánh mất tính phi tập trung của blockchain, vẫn cần rất nhiều nỗ lự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
@VitalikButerin
