Giới hạn của khả năng mở rộng blockchain

Tác giả: Vitalik Buterin

Tiêu đề gốc: 《Giới hạn của khả năng mở rộng Blockchain》

Thời gian phát hành: Ngày 23 tháng 5 năm 2021

Chúng ta có thể nâng cao khả năng mở rộng của blockchain lên mức nào? Liệu có thật sự như Elon Musk đã nói rằng "thời gian khối tăng gấp mười, kích thước khối tăng gấp mười và phí giao dịch giảm một trăm lần", mà không dẫn đến sự tập trung cực độ và vi phạm các thuộc tính bản chất của blockchain? Nếu câu trả lời là không, thì chúng ta có thể đạt được mức độ nào? Việc thay đổi thuật toán công thức sẽ như thế nào? Quan trọng hơn, nếu chúng ta giới thiệu các chức năng tương tự như ZK-SNARK hoặc phân đoạn thì sẽ ra sao? Một blockchain phân đoạn về lý thuyết có thể liên tục thêm các phân đoạn, vậy liệu có thật sự có thể làm như vậy không?

Thực tế cho thấy, dù có sử dụng phân đoạn hay không, có những yếu tố kỹ thuật quan trọng và rất tinh vi đã hạn chế khả năng mở rộng của blockchain. Nhiều tình huống có giải pháp, nhưng ngay cả khi có giải pháp, vẫn tồn tại những giới hạn. Bài viết này sẽ khám phá nhiều vấn đề trong số đó.

Nếu chỉ đơn giản là nâng cao các tham số, vấn đề dường như có thể được giải quyết. Nhưng chúng ta sẽ phải trả giá gì cho điều đó?

Việc người dùng thông thường có thể chạy nút là rất quan trọng cho sự phi tập trung của blockchain

Hãy tưởng tượng vào khoảng hai giờ sáng, bạn nhận được một cuộc gọi khẩn cấp từ người ở đầu kia của thế giới giúp bạn vận hành một bể khai thác (bể staking). Từ khoảng 14 phút trước, bể của bạn và một vài người khác đã bị tách ra khỏi chuỗi, trong khi mạng vẫn duy trì 79% sức mạnh tính toán. Theo nút của bạn, phần lớn các khối trên chuỗi là không hợp lệ. Lúc này xuất hiện lỗi số dư: khối dường như đã phân bổ 4,5 triệu token bổ sung cho một địa chỉ không xác định.

Một giờ sau, bạn và hai người tham gia bể khai thác nhỏ khác cũng gặp sự cố, một số trình duyệt khối và sàn giao dịch đang ở trong một phòng trò chuyện, thấy ai đó đã đăng một liên kết Twitter, bắt đầu bằng "Công bố quỹ phát triển giao thức bền vững mới trên chuỗi".

Đến sáng, các cuộc thảo luận liên quan đã lan rộng trên Twitter và một diễn đàn cộng đồng không kiểm duyệt nội dung. Nhưng lúc đó, một phần lớn trong số 4,5 triệu token đã được chuyển đổi thành các tài sản khác trên chuỗi và đã thực hiện hàng tỷ đô la giao dịch defi. 79% các nút đồng thuận, cùng với tất cả các trình duyệt blockchain chính và các điểm cuối ví 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ố phát triển, hoặc có thể tất cả những điều này đã bị các bể khai thác hàng đầu, sàn giao dịch và các mối quan hệ của họ nuốt chửng. Nhưng dù kết quả ra sao, quỹ thực sự đã trở thành một thực tế không thể phản kháng đối với người dùng thông thường.

Có lẽ có một bộ phim chủ đề như vậy. Có thể sẽ được tài trợ bởi MolochDAO hoặc các tổ chức khác.

Tình huống này có xảy ra trong blockchain của bạn không? Các tinh hoa trong cộng đồng blockchain của bạn, bao gồm các bể khai thác, trình duyệt khối và nút lưu trữ, có thể phối hợp rất tốt, họ rất có thể đều ở trong cùng một kênh telegram và nhóm WeChat. Nếu họ thực sự muốn vì lợi ích mà đột ngột sửa đổi quy tắc giao thức, thì họ có thể có khả năng đó. Blockchain Ethereum đã hoàn toàn giải quyết thất bại đồng thuận trong vòng mười giờ, nếu chỉ có một khách hàng thực hiện blockchain và chỉ cần thay đổi mã được triển khai trên vài chục nút, thì có thể nhanh chóng phối hợp thay đổi mã khách hàng. Cách duy nhất đáng tin cậy để chống lại loại tấn công hợp tác xã hội này là "phòng thủ thụ động", và sức mạnh này đến từ một nhóm phi tập trung: người dùng.

Hãy tưởng tượng, nếu người dùng chạy các nút xác thực blockchain (dù là xác thực trực tiếp hay các công nghệ gián tiếp khác), và 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ợ mỏ hoặc người staking ủng hộ các khối này, câu chuyện sẽ diễn ra như thế nào.

Nếu mỗi người dùng đều chạy một nút xác thực, thì cuộc tấn công sẽ nhanh chóng thất bại: một số bể khai thác và sàn giao dịch sẽ thực hiện phân nhánh, và trong suốt quá trình, họ sẽ trông rất ngớ ngẩn. Nhưng ngay cả khi chỉ một số người dùng chạy các nút xác thực, kẻ tấn công cũng không thể giành chiến thắng lớn. Ngược lại, cuộc tấn công sẽ dẫn đến sự hỗn loạn, và các người dùng khác nhau sẽ thấy các phiên bản blockchain khác nhau. Trong trường hợp xấu nhất, sự hoảng loạn trên thị trường và khả năng phân nhánh chuỗi kéo dài sẽ giảm đáng kể lợi nhuận của kẻ tấn công. Ý tưởng đối phó với những xung đột kéo dài như vậy có thể tự nó ngăn chặn hầu hết các cuộc tấn công.

Quan điểm của Hasu về điều này:

"Chúng ta cần làm rõ một điều, lý do chúng ta có thể chống lại các thay đổi giao thức ác ý là vì có văn hóa người dùng xác thực blockchain, chứ không phải vì PoW hay PoS."

Giả sử cộng đồng của bạn có 37 người chạy nút, cùng với 80.000 người nghe thụ động, kiểm tra chữ ký và tiêu đề khối, thì kẻ tấn công sẽ chiến thắng. Nếu mọi người đều chạy nút, thì kẻ tấn công sẽ thất bại. Chúng ta không rõ ngưỡng chính xác cho nhóm khởi động miễn dịch chống lại tấn công hợp tác là bao nhiêu, nhưng có một điều là rõ ràng: càng nhiều nút tốt, càng ít nút ác ý, và số lượng mà chúng ta cần chắc chắn không chỉ là vài trăm hay vài nghìn.

Vậy giới hạn công việc của nút đầy đủ là gì?

Để có càng nhiều người dùng có thể chạy nút đầy đủ, chúng ta sẽ tập trung vào phần cứng tiêu dùng thông thường. Ngay cả khi có thể dễ dàng mua phần cứng chuyên dụng, điều này có thể giảm bớt một số rào cản cho nút đầy đủ, nhưng thực tế là sự nâng cao khả năng mở rộng không như chúng ta tưởng tượng.

Khả năng xử lý giao dịch của nút đầy đủ chủ yếu bị hạn chế bởi ba yếu tố:

• Sức mạnh tính toán: Trong điều kiện đảm bảo an toàn, chúng ta có thể phân chia bao nhiêu CPU để chạy nút?
• Băng thông: Dựa trên kết nối mạng hiện tại, 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 sử dụng bao nhiêu không gian để lưu trữ? Hơn nữa, tốc độ đọc của nó nên đạt bao nhiêu? (tức là, HDD có đủ không? Hay chúng ta cần SSD?)

Nhiều quan niệm sai lầm về việc mở rộng blockchain một cách lớn lao bằng cách sử dụng công nghệ "đơn giản" xuất phát từ việc ước lượng quá lạc quan về những con số này. Chúng ta có thể lần lượt thảo luận về ba yếu tố này:

Sức mạnh tính toán

• Câu trả lời sai: 100% CPU nên được sử dụng cho xác thực khối
• Câu trả lời đúng: Khoảng 5-10% CPU có thể được sử dụng cho xác thực khối

Giới hạn này thấp như vậy vì bốn lý do chính sau đây:

• Chúng ta cần một ranh giới an toàn để che phủ khả năng tấn công DoS (kẻ tấn công lợi dụng điểm yếu trong mã để tạo ra giao dịch cần thời gian xử lý lâu hơn so với giao dịch thông thường)
• Nút cần phải có khả năng đồng bộ với blockchain sau khi ngoại tuyến. Nếu tôi mất kết nối một phút, tôi phải có thể hoàn thành đồng bộ trong vài giây
• Chạy nút không nên nhanh chóng làm cạn kiệt pin, cũng không nên làm chậm tốc độ chạy của các ứng dụng khác
• Nút cũng có các công việc không liên quan đến sản xuất khối khác phải thực hiện, phần lớn là xác thực và phản hồi các giao dịch và yêu cầu đầu vào trong mạng p2p

Xin lưu ý rằng, cho đến gần đây, hầu hết các giải thích cho "tại sao chỉ cần 5-10%?" đã tập trung vào một vấn đề khác: vì thời gian tạo khối của PoW không cố định, việc xác thực khối cần thời gian dài, sẽ làm tăng rủi ro tạo ra nhiều khối cùng một lúc. Vấn đề này có nhiều phương pháp sửa chữa, chẳng hạn như Bitcoin NG, hoặc sử dụng chứng minh cổ phần PoS. Nhưng những điều này không giải quyết được bốn vấn đề khác, vì vậy chúng không đạt được tiến bộ lớn trong khả năng mở rộng như nhiều người mong đợi.

Tính song song cũng không phải là thuốc tiên. Thông thường, ngay cả khi là khách hàng blockchain có vẻ đơn luồng, cũng đã được song song hóa: chữ ký có thể được xác thực bởi một luồng, trong khi thực thi được thực hiện bởi các luồng khác, và có một luồng riêng xử lý logic của bể giao dịch ở phía sau. Hơn nữa, tỷ lệ sử dụng của tất cả các luồng càng gần 100%, thì tiêu thụ năng lượng của việc chạy nút càng nhiều, và hệ số an toàn chống lại DoS càng thấp.

Băng thông

• Câu trả lời sai: Nếu không có 2-3 giây mà tạo ra 10 MB khối, thì hầu hết người dùng có mạng lớn hơn 10 MB/giây, họ chắc chắn có thể xử lý các khối này
• Câu trả lời đúng: Có thể chúng ta có thể xử lý 1-5 MB khối mỗi 12 giây, nhưng điều này vẫn rất khó

Ngày nay, chúng ta thường nghe những thống kê phổ biến về băng thông mà kết nối internet có thể cung cấp: 100 Mbps thậm chí 1 Gbps là những con số rất phổ biến. Tuy nhiên, có một sự khác biệt lớn giữa băng thông được tuyên bố và băng thông thực tế mong đợi vì một số lý do sau:

1. "Mbps" có nghĩa là "triệu bits mỗi giây"; một bit là 1/8 của một byte, vì vậy chúng ta cần chia số bit được tuyên bố cho 8 để có được số byte.
2. Các nhà cung cấp mạng, giống như các công ty khác, thường xuyên nói dối.
3. Luôn có nhiều ứng dụng sử dụng cùng một kết nối mạng, vì vậy nút không thể độc quyền băng thông.
4. Mạng P2P không thể tránh khỏi việc sẽ giới thiệu chi phí: các nút thường cuối cùng sẽ tải xuống và tải lên lại cùng một khối nhiều lần (chưa kể đến việc giao dịch phải được phát sóng qua mempool trước khi được đóng gói vào khối).

Khi Starkware thực hiện một thí nghiệm vào năm 2019, họ đã phát hành khối 500 kB lần đầu tiên sau khi chi phí gas cho dữ liệu giao dịch giảm, một số nút thực sự không thể xử lý được kích thước khối này. Khả năng xử lý khối lớn đã và sẽ tiếp tục được cải thiện. Nhưng bất kể chúng ta làm gì, chúng ta vẫn không thể có được băng thông trung bình tính bằng MB/giây, thuyết phục bản thân rằng chúng ta có thể chấp nhận độ trễ 1 giây và có khả năng xử lý khối có kích thước đó.

Lưu trữ

• Câu trả lời sai: 10 TB
• Câu trả lời đúng: 512 GB

Như mọi người có thể đoán, lập luận chính ở đây tương tự như ở những nơi khác: sự khác biệt giữa lý thuyết và thực tiễn. Về lý thuyết, chúng ta có thể mua ổ cứng SSD 8 TB trên Amazon (thực sự cần SSD hoặc NVME; HDD quá chậm cho việc lưu trữ trạng thái blockchain). Trên thực tế, máy tính xách tay mà tôi sử dụng để viết bài này có 512 GB, nếu bạn yêu cầu mọi người đi mua phần cứng, nhiều người sẽ trở nên lười biếng (hoặc họ không thể chi trả 800 đô la cho ổ SSD 8 TB) và sử dụng dịch vụ tập trung. Ngay cả khi có thể lưu trữ blockchain trên một thiết bị lưu trữ nào đó, nhiều hoạt động cũng có thể nhanh chóng làm cạn kiệt ổ đĩa và buộc bạn phải mua ổ đĩa mới.

Một nhóm các nhà nghiên cứu về giao thức blockchain đã khảo sát không gian đĩa của mọi người. Tôi biết kích thước mẫu rất nhỏ, nhưng vẫn…

Hơn nữa, kích thước lưu trữ quyết định thời gian cần thiết để nút mới có thể trực tuyến và bắt đầu tham gia vào mạng. Bất kỳ dữ liệu nào mà các nút hiện có 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ộ ban đầu này (và băng thông) cũng là rào cản chính mà người dùng có thể chạy nút. Khi tôi viết bài này, việc đồng bộ một nút geth mới đã mất khoảng 15 giờ. Nếu mức sử dụng Ethereum tăng gấp 10 lần, thì việc đồng bộ một nút geth mới sẽ mất ít nhất một tuần, và có khả năng cao hơn sẽ dẫn đến việc kết nối internet của nút bị hạn chế. Điều này càng quan trọng hơn trong thời gian tấn công, khi người dùng chưa từng chạy nút trước đó cần kích hoạt nút mới để phản ứng thành công với cuộc tấn công.

Tác động tương tác

Hơn nữa, có sự tương tác giữa ba loại chi phí này. Vì cơ sở dữ liệu sử dụng cấu trúc cây bên trong để lưu trữ và truy xuất dữ liệu, chi phí lấy dữ liệu từ cơ sở dữ liệu tăng theo logarit của kích thước cơ sở dữ liệu. Thực tế là vì các cấp cao nhất (hoặc vài cấp đầu tiên) có thể được lưu trữ trong RAM, nên chi phí truy cập đĩa tỷ lệ thuận với kích thước cơ sở dữ liệu, là bội số của kích thước dữ liệu được lưu trong bộ nhớ RAM.

Đừng hiểu bức tranh này theo nghĩa đen, các cơ sở dữ liệu khác nhau hoạt động theo những cách khác nhau, thường thì phần trong bộ nhớ chỉ là một lớp riêng (nhưng lớn) (xem cây LSM được sử dụng trong leveldb). Nhưng nguyên lý cơ bản là giống nhau.

Ví dụ, nếu bộ đệm là 4 GB, và chúng ta giả định rằng mỗi lớp của cơ sở dữ liệu lớn gấp 4 lần lớp trước đó, thì trạng thái hiện tại của Ethereum ~64 GB sẽ cần ~2 lần truy cập. Nhưng nếu kích thước trạng thái tăng gấp 4 lần lên ~256 GB, thì điều này sẽ tăng lên ~3 lần truy cập. Do đó, việc tăng giới hạn gas gấp 4 lần thực sự có thể chuyển thành thời gian xác thực khối tăng khoảng 6 lần. Tác động này có thể lớn hơn: ổ đĩa cần nhiều thời gian hơn để đọc và ghi khi đã đầy so với khi còn trống.

Điều này có nghĩa là gì đối với Ethereum?

Hiện tại, việc chạy một nút trên blockchain Ethereum đã là một thách thức đối với nhiều người dùng, mặc dù ít nhất việc sử dụng phần cứng thông thường vẫn là khả thi (khi tôi viết bài này, tôi vừa đồng bộ một nút trên máy tính xách tay của mình!). Do đó, chúng ta sắp gặp phải tình trạng tắc nghẽn. Vấn đề mà các nhà phát triển cốt lõi quan tâm nhất là kích thước lưu trữ. Do đó, những nỗ lực lớn hiện tại để giải quyết các nút thắt về tính toán và dữ liệu, thậm chí thay đổi thuật toán đồng thuận, khó có thể mang lại sự tăng trưởng lớn trong giới hạn gas. Ngay cả khi giải quyết được điểm yếu DoS lớn nhất của Ethereum, cũng chỉ có thể nâng giới hạn gas lên 20%.

Đối với vấn đề kích thước lưu trữ, giải pháp duy nhất là không trạng thái và trạng thái hết hạn. Không trạng thái cho phép nhóm nút xác thực mà không cần duy trì lưu trữ vĩnh viễn. Trạng thái hết hạn sẽ làm cho trạng thái gần đây không được truy cập trở nên không hợp lệ, người dùng cần cung cấp chứng minh thủ công để cập nhật. Cả hai con đường này đã được nghiên cứu trong một thời gian dài và đã bắt đầu thực hiện các khái niệm xác minh không trạng thái. Hai cải tiến này kết hợp có thể giảm bớt những lo ngại này một cách đáng kể và mở ra không gian cho việc nâng cao giới hạn gas một cách đáng kể. Nhưng ngay cả khi thực hiện không trạng thái và trạng thái hết hạn, giới hạn gas cũng có thể chỉ được nâng lên một cách an toàn khoảng 3 lần, cho đến khi các giới hạn khác bắt đầu phát huy tác dụng.

Một giải pháp trung hạn khả thi khác là sử dụng ZK-SNARKs để xác thực giao dịch. ZK-SNARKs có thể đảm bảo rằng người dùng thông thường không cần lưu trữ trạng thái cá nhân hoặc xác thực khối, ngay cả khi họ vẫn cần tải xuống tất cả dữ liệu trong khối để chống lại các cuộc tấn công dữ liệu không khả dụng. Hơn nữa, ngay cả khi kẻ tấn công không thể ép buộc gửi khối không hợp lệ, nhưng nếu khó khăn trong việc chạy một nút đồng thuận quá cao, vẫn sẽ có nguy cơ tấn công kiểm duyệt phối hợp. Do đó, ZK-SNARKs không thể nâng cao khả năng của nút vô hạn, nhưng vẫn có thể nâng cao đáng kể (có thể là 1-2 bậc). Một số blockchain đang khám phá hình thức này trên layer1, trong khi Ethereum đang hưởng lợi từ các giao thức layer2 (còn gọi là ZK rollups), chẳng hạn như zksync, Loopring và Starknet.

Vậy sau phân đoạn sẽ ra sao?

Phân đoạn giải quyết căn bản các hạn chế trên, vì nó tách rời dữ liệu chứa trên blockchain với dữ liệu mà một nút đơn cần xử lý và lưu trữ. Nút xác thực khối không phải bằng cách tự mình tải xuống và thực hiện, mà là sử dụng các kỹ thuật toán học và mật mã tiên tiến để xác thực khối một cách gián tiếp.

Do đó, blockchain phân đoạn có thể an toàn sở hữu mức độ thông lượng rất cao mà blockchain không phân đoạn không thể đạt được. Điều này thực sự cần rất nhiều kỹ thuật mật mã để thay thế hiệu quả cho xác thực đầy đủ đơn giản, để từ chối các khối không hợp lệ, nhưng điều này là khả thi: lý thuyết đã có nền tảng và các khái niệm xác minh dựa trên tiêu chuẩn dự thảo đã được thực hiện.

Ethereum dự định áp dụng phân đoạn bậc hai (quadratic sharding), trong đó khả năng mở rộng tổng thể bị giới hạn bởi thực tế rằng các nút phải có thể xử lý đồng thời một phân đoạn đơn và chuỗi tín hiệu, trong khi chuỗi tín hiệu phải thực hiện một số công việc quản lý cố định cho mỗi phân đoạn. Nếu phân đoạn quá lớn, nút sẽ không thể xử lý một phân đoạn đơn, nếu phân đoạn quá nhiều, nút sẽ không thể xử lý chuỗi tín hiệu. Tích của hai ràng buộc này tạo thành giới hạn.

Có thể tưởng tượng rằng, thông qua phân đoạn bậc ba hoặc thậm chí phân đoạn theo cấp số nhân, chúng ta có thể đi xa hơn. Trong thiết kế như vậy, việc lấy mẫu khả năng dữ liệu chắc chắn sẽ trở nên phức tạp hơn, nhưng điều này có thể thực hiện được. Nhưng Ethereum không vượt qua phân đoạn bậc hai, lý do là, lợi ích mở rộng bổ sung có được từ việc phân đoạn giao dịch đến phân đoạn giao dịch thực sự không thể đạt được trong điều kiện rủi ro khác có thể chấp nhận được.

Vậy những rủi ro này là gì?

Số lượng người dùng tối thiểu

Có thể tưởng tượng rằng, chỉ cần có một người dùng sẵn sàng tham gia, blockchain không phân đoạn có thể hoạt động. Nhưng blockchain phân đoạn không phải như vậy: một nút đơn không thể xử lý toàn bộ chuỗi, vì vậy cần đủ nút để cùng nhau xử lý blockchain. Nếu mỗi nút có thể xử lý 50 TPS, trong khi chuỗi có thể xử lý 10.000 TPS, thì chuỗi ít nhất cần 200 nút để tồn tại. Nếu chuỗi có ít hơn 200 nút vào bất kỳ thời điểm nào, có thể xảy ra tình trạng nút không thể giữ đồng bộ, hoặc nút ngừng phát hiện các khối không hợp lệ, hoặc có thể xảy ra nhiều điều xấu khác, tùy thuộc vào cài đặt phần mềm của nút.

Trong thực tế, do cần có sự dư thừa (bao gồm cả việc lấy mẫu khả năng dữ liệu), số lượng tối thiểu an toàn cao hơn nhiều lần so với đơn giản là "TPS chuỗi chia cho TPS nút", đối với ví dụ trên, chúng ta đặt nó ở mức 1.000 nút.

Nếu dung lượng của blockchain phân đoạn tăng gấp 10 lần, thì số lượng người dùng tối thiểu cũng tăng gấp 10 lần. Bây giờ mọi người có thể hỏi: tại sao chúng ta không bắt đầu từ dung lượng thấp hơn, khi có nhiều người dùng thì tăng lên, vì đó là nhu cầu thực tế của chúng ta, số lượng người dùng giảm thì lại giảm dung lượng?

Có một số vấn đề ở đây:

1. Blockchain bản thân không thể phát hiện đáng tin cậy có bao nhiêu người dùng duy nhất trên đó, vì vậy cần có một số hình thức quản trị để phát hiện và thiết lập số lượng phân đoạn. Quản trị giới hạn dung lượng rất dễ trở thành nguồn gốc của sự chia rẽ và xung đột.
2. Nếu nhiều người dùng đột ngột mất kết nối cùng một lúc thì sao?
3. Tăng số lượng người dùng tối thiểu cần thiết để khởi động phân nhánh khiến việc phòng thủ chống lại sự kiểm soát ác ý trở nên khó khăn hơn.

Số lượng người dùng tối thiểu là 1.000, điều này gần như có thể nói là không vấn đề gì. Mặt khác, số lượng người dùng tối thiểu là 1 triệu, điều này chắc chắn không khả thi. Ngay cả khi số lượng người dùng tối thiểu là 10.000 cũng có thể nói bắt đầu trở nên rủi ro. Do đó, có vẻ khó để chứng minh rằng một blockchain phân đoạn với hơn vài trăm phân đoạn là hợp lý.

Khả năng truy xuất lịch sử

Một thuộc tính quan trọng mà người dùng thực sự quý trọng của blockchain là tính vĩnh cửu. Khi một công ty phá sản hoặc duy trì hệ sinh thái không còn mang lại lợi ích, tài sản kỹ thuật số lưu trữ trên máy chủ sẽ không còn tồn tại trong vòng 10 năm. Trong khi đó, NFT trên Ethereum là vĩnh cửu.

Đúng vậy, đến năm 2372, mọi người vẫn có thể tải xuống và xem lại mèo crypto của bạn.

Nhưng một khi dung lượng của blockchain quá cao, việc lưu trữ tất cả những dữ liệu này sẽ trở nên khó khăn hơn, cho đến khi có một thời điểm xuất hiện rủi ro lớn, một số dữ liệu lịch sử cuối cùng sẽ… không ai lưu trữ.

Để định lượng rủi ro này rất dễ dàng. Lấy dung lượng dữ liệu của blockchain (MB/giây) nhân với ~30 để có được lượng dữ liệu lưu trữ hàng năm (TB). Dung lượng dữ liệu của kế hoạch phân đoạn hiện tại khoảng 1,3 MB/giây, vì vậy khoảng 40 TB/năm. Nếu tăng gấp 10 lần, thì sẽ là 400 TB/năm. Nếu chúng ta không chỉ muốn có thể truy cập dữ liệu, mà còn theo cách thuận tiện, chúng ta cũng cần siêu dữ liệu (chẳng hạn như giải nén giao dịch tổng hợp), do đó mỗi năm đạt 4 PB, hoặc sau mười năm đạt 40 PB. Internet Archive sử dụng 50 PB. Vì vậy, có thể nói đây là giới hạn kích thước an toàn của blockchain phân đoạn.

Do đó, có vẻ như ở hai khía cạnh này, thiết kế phân đoạn của Ethereum thực sự đã rất gần với giá trị an toàn tối đa hợp lý. Các hằng số có thể tăng một chút, nhưng không thể tăng quá nhiều.

Kết luận

Có hai cách để cố gắng mở rộng blockchain: cải tiến công nghệ cơ bản và đơn giản là nâng cao các tham số. Đầu tiên, nâng cao các tham số nghe có vẻ hấp dẫn: nếu bạn đang thực hiện các phép toán trên giấy ăn, điều này rất dễ khiến bạn tin rằng máy tính xách tay tiêu dùng có thể xử lý hàng nghìn giao dịch mỗi giây mà không cần ZK-SNARK, rollups hoặc phân đoạn. Thật không may, có rất nhiều lý do tinh vi để giải thích tại sao phương pháp này có những thiếu sót cơ bản.

Máy tính chạy nút blockchain không thể sử dụng 100% CPU để xác thực blockchain; họ cần một biên độ an toàn lớn để chống lại các cuộc tấn công DoS bất ngờ, họ cần dung lượng dự phòng để thực hiện các nhiệm vụ như xử lý giao dịch trong bộ nhớ, và người dùng không muốn khi chạy nút trên máy tính của họ thì không thể sử dụng cho bất kỳ ứng dụng nào khác. Băng thông cũng sẽ bị hạn chế: kết nối 10 MB/s không có nghĩa là mỗi giây có thể xử lý 10 MB khối! Có thể chỉ có thể xử lý 1-5 MB khối mỗi 12 giây. Lưu trữ cũng tương tự: việc nâng cao yêu cầu phần cứng để chạy nút và hạn chế các nhà điều hành nút chuyên dụng không phải là giải pháp. Đối với blockchain phi tập trung, việc người dùng thông thường có thể chạy nút và hình thành một văn hóa, rằng việc chạy nút là một hành vi phổ biến, là điều cực kỳ quan trọng.

Tuy nhiên, cải tiến công nghệ cơ bản là khả thi. Hiện tại, nút thắt chính của Ethereum là kích thước lưu trữ, và không trạng thái cùng trạng thái hết hạn có thể giải quyết vấn đề này, và cho phép nó tăng tối đa khoảng 3 lần, nhưng không thể nhiều hơn, vì chúng ta muốn việc chạy nút dễ dàng hơn so với hiện tại. Blockchain áp dụng phân đoạn có thể mở rộng hơn nữa, vì các nút đơn trong blockchain phân đoạn không cần xử lý mỗi giao dịch. Nhưng ngay cả blockchain phân đoạn, dung lượng cũng có giới hạn: khi dung lượng tăng, số lượng người dùng tối thiểu an toàn cũng tăng, chi phí lưu trữ blockchain (và nếu không ai lưu trữ chuỗi, rủi ro mất dữ liệu) sẽ tăng lên. Nhưng chúng ta không cần quá lo lắng: những giới hạn này đủ để chúng ta có thể xử lý hơn một triệu giao dịch mỗi giây trong khi đảm bảo an toàn hoàn toàn cho blockchain. Nhưng để đạt được điều này mà không làm tổn hại đến đặc tính phi tập trung quý giá nhất của blockchain, chúng ta cần nỗ lực nhiều hơn nữa.