V God nói chi tiết về những hạn chế của việc mở rộng cơ sở hạ tầng cơ bản

Tiêu đề gốc: "Các giới hạn đối với khả năng mở rộng của Blockchain"

Tác giả gốc: Vitalik Buterin, người sáng lập Ethereum 

Bản tổng hợp gốc: Babbitt

Khả năng mở rộng của blockchain có thể đạt được mức độ chính xác như thế nào? Nó thực sự có thể "giảm phí xử lý 100 lần bằng cách rút ngắn thời gian khối 10 lần và tăng kích thước khối lên 10 lần" như Elon Musk (CEO Tesla) mong muốn mà không gây ra sự tập trung quá mức và làm hỏng khối. có tính chất dây chuyền? Nếu không, blockchain có thể mở rộng đến mức nào? Điều gì sẽ xảy ra nếu bạn chọn mở rộng quy mô bằng cách thay đổi thuật toán đồng thuận? Quan trọng hơn, điều gì sẽ xảy ra nếu bạn thay đổi công nghệ để giới thiệu các tính năng như ZK-SNARK hoặc sharding? Về lý thuyết, một chuỗi khối phân đoạn có thể tiếp tục bổ sung thêm nhiều phân đoạn hơn, điều đó có dẫn đến nhiều thứ được thêm vào không?

Hóa ra là có một số yếu tố kỹ thuật quan trọng và khá tinh vi làm hạn chế khả năng mở rộng của chuỗi khối, ngay cả những yếu tố áp dụng sharding. Trong nhiều trường hợp, chúng ta sẽ có những giải pháp có khả năng mở rộng tương ứng nhưng những giải pháp này cũng có những hạn chế. Bài viết này sẽ khám phá nhiều vấn đề tồn tại trong các tình huống có khả năng mở rộng này.

Chỉ cần thêm tham số Có thể giải được mọi vấn đề. Nhưng với chi phí nào?

Người dùng thông thường cũng có thể chạy các nút, điều này rất quan trọng cho việc phân quyền của chuỗi khối

Vào lúc 2:35 sáng, bạn nhận được một cuộc gọi khẩn cấp từ một người bạn ở bên kia thế giới, người đang giúp bạn quản lý một nhóm khai thác (hoặc có thể là một nhóm đặt cược). Đối tác của bạn cho bạn biết rằng bắt đầu từ khoảng 14 phút trước, nhóm của bạn và một số nhóm khác đột nhiên tách khỏi chuỗi, trong đó chuỗi ban đầu vẫn mang 79% sức mạnh tính toán của mạng. Tùy thuộc vào nút của bạn, các khối được tạo bởi chuỗi đa số này (chuỗi gốc) là không hợp lệ. Điều này gây ra lỗi số dư: khối khóa dường như đã phân bổ nhầm 4,5 triệu xu bổ sung vào một địa chỉ không xác định.

Một giờ sau, bạn bắt đầu liên lạc trong nhóm điện tín với hai nhóm khai thác khác cũng đang bối rối như bạn, cũng như một số nhà thám hiểm và sàn giao dịch khối. Cuối cùng bạn thấy ai đó tweet một liên kết. Dòng tweet có nội dung: “Quỹ phát triển giao thức bền vững trên chuỗi mới đã chính thức được phát hành.”

Đến buổi sáng, Twitter và các diễn đàn cộng đồng tràn ngập những cuộc tranh luận không được kiểm duyệt và các cuộc thảo luận diễn ra khắp nơi. Nhưng tại thời điểm này, một phần lớn trong số 4,5 triệu token mới phát hành đã được chuyển đổi thành các tài sản khác trên chuỗi và hàng tỷ đô la giao dịch DeFi đã được thực hiện. 79% nút đồng thuận và tất cả các trình duyệt quan trọng cũng như ví nhẹ đang tuân theo chuỗi mới này. Có thể quỹ dành cho nhà phát triển mới này sẽ tài trợ cho một số hoạt động phát triển hoặc có thể toàn bộ số tiền này sẽ bị ngấu nghiến bởi các nhóm khai thác, sàn giao dịch hàng đầu, v.v. Nhưng bất kể kết quả thế nào, quỹ này về mọi mặt đều là việc đã rồi và người dùng thông thường không có khả năng chống trả.

Chương trình sắp kết thúc được thả ra. Có thể được tài trợ bởi MolochDAO hoặc thứ gì khác

Điều này có thể xảy ra với blockchain của bạn không? Thành phần ưu tú trong cộng đồng blockchain của bạn, bao gồm nhóm khai thác, trình khám phá khối và các nút được lưu trữ, có thể được phối hợp tốt. Có lẽ tất cả họ đều thuộc cùng một nhóm Telegram và WeChat. Nếu họ thực sự muốn thực hiện những thay đổi đột ngột đối với các quy tắc giao thức để nâng cao lợi ích của mình, họ có thể làm như vậy. Chuỗi khối Ethereum đã từng giải quyết hoàn toàn lỗi đồng thuận trong vòng mười giờ; nếu chuỗi khối của bạn chỉ triển khai một ứng dụng khách duy nhất và bạn chỉ cần triển khai các thay đổi mã cho vài chục nút, thì việc điều phối các thay đổi đối với mã ứng dụng khách sẽ có tốc độ nhanh hơn. Cách đáng tin cậy duy nhất để vô hiệu hóa một cuộc tấn công xã hội phối hợp như vậy là thông qua sự phòng thủ tích cực của cộng đồng phi tập trung, tức là người dùng.

Hãy tưởng tượng nếu người dùng đang chạy các nút xác minh chuỗi khối (trực tiếp hoặc thông qua các kỹ thuật gián tiếp nâng cao hơn) và tự động từ chối các nút vi phạm quy tắc của khối giao thức. , điều gì sẽ xảy ra ngay cả khi hơn 90% người khai thác hoặc người đặt cược hỗ trợ giao thức. Nếu mọi người dùng đều chạy một nút xác thực, cuộc tấn công này sẽ nhanh chóng thất bại: một số nhóm khai thác và sàn giao dịch sẽ phân nhánh, nhưng điều này có vẻ ngớ ngẩn. Tuy nhiên, ngay cả khi chỉ một số người dùng chạy các nút xác thực, cuộc tấn công sẽ không mang lại chiến thắng cho kẻ tấn công. Thay vào đó, điều này sẽ dẫn đến sự nhầm lẫn vì những người dùng khác nhau sẽ nhìn thấy các chuỗi khác nhau. Ít nhất, sự hoảng loạn của thị trường sau đó và khả năng tiếp tục phân chia chuỗi sẽ làm giảm đáng kể lợi nhuận mà những kẻ tấn công có thể đạt được. Bản thân chi phí thời gian để giải quyết xung đột có thể ngăn cản những kẻ tấn công.

Hãy nói rõ: khả năng chống lại những thay đổi giao thức độc hại của bạn xuất phát từ văn hóa chuỗi khối được người dùng xác thực, không phải PoW hay PoS.

——Hasu

Bạn có thể xem Hasu đã nói gì về điều này

Nếu cộng đồng của bạn bao gồm 37 người vận hành nút và 80.000 người nghe thụ động chịu trách nhiệm kiểm tra chữ ký và tiêu đề khối thì kẻ tấn công sẽ thắng. Nếu mọi người trong cộng đồng của bạn đang chạy một nút thì những kẻ tấn công sẽ thất bại. Chúng tôi không biết ngưỡng chính xác của “miễn dịch bầy đàn” trước các cuộc tấn công phối hợp là gì, nhưng có một điều hoàn toàn rõ ràng: nhiều nút hơn thì tốt hơn, ít nút hơn thì tệ hơn và chúng tôi chắc chắn cần nhiều hơn vài chục hoặc hàng trăm nút.

Vậy, chúng ta cần nút đầy đủ để hoàn thành bao nhiêu công việc?

Để tối đa hóa số lượng người dùng có thể chạy các nút, chúng tôi sẽ tập trung vào phần cứng cấp độ người tiêu dùng thông thường. Có thể tăng thêm dung lượng mạng bằng cách yêu cầu một số phần cứng chuyên dụng dễ mua (ví dụ: từ Amazon), nhưng điều đó không thực sự bổ sung nhiều vào khả năng mở rộng.

Có ba hạn chế chính đối với khả năng xử lý khối lượng giao dịch lớn của nút đầy đủ:

Sức mạnh tính toán: Cần bao nhiêu phần trăm sức mạnh CPU để chạy một nút một cách an toàn?

Băng thông: Xem xét thực tế của các kết nối internet hiện tại, một khối có thể chứa bao nhiêu byte?

Bộ nhớ: Chúng ta có thể yêu cầu người dùng lưu trữ bao nhiêu GB dung lượng đĩa? Ngoài ra, tốc độ đọc cần thiết là bao nhiêu? (Có thể sử dụng ổ cứng HDD không? Hay tôi cần SSD?)

Nhiều quan niệm sai lầm về việc blockchain có thể được mở rộng đến mức nào khi sử dụng quan điểm công nghệ “đơn giản”, do quá phức tạp. lạc quan về từng con số này. Chúng ta có thể giới thiệu lần lượt 3 yếu tố sau:

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

Lỗi: Có thể sử dụng 100% năng lượng CPU để xác minh khối

Đúng: Khoảng 5-10% năng lượng CPU có thể được sử dụng để xác minh khối

Có bốn lý do chính khiến tỷ lệ này thấp như vậy:

Chúng ta cần một giới hạn an toàn để tính đến khả năng xảy ra các cuộc tấn công DoS (những kẻ tấn công cố gắng tấn công khai thác điểm yếu trong mã) Các giao dịch được thực hiện mất nhiều thời gian xử lý hơn so với các giao dịch thông thường)

Các nút cần có khả năng đồng bộ hóa chuỗi sau khi chúng ngoại tuyến. Nếu tôi ngắt kết nối mạng trong một phút, tôi sẽ có thể đồng bộ hóa lại với mạng sau vài giây

Việc chạy một nút không được làm tiêu hao pin quá nhanh và cũng không được làm cho tất cả các ứng dụng khác chạy chậm hơn

Các nút cũng cần thực hiện các nhiệm vụ sản xuất không theo khối khác, chủ yếu xoay quanh việc xác thực và phản hồi các giao dịch và yêu cầu đến trên mạng p2p.

Xin lưu ý rằng cho đến gần đây, hầu hết các lời giải thích cho "Tại sao chỉ có 5-10%?" đều tập trung vào một câu hỏi khác: vì các khối PoW xuất hiện ngẫu nhiên nên nó mất nhiều thời gian hơn để xác minh các khối, làm tăng nguy cơ nhiều khối được tạo cùng một lúc. Có nhiều giải pháp cho vấn đề này (ví dụ: Bitcoin NG hoặc sử dụng PoS). Nhưng những bản vá này không giải quyết được bốn vấn đề còn lại, vì vậy chúng không mang lại những lợi ích to lớn về khả năng mở rộng như nhiều người nghĩ ban đầu.

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

Băng thông

Lỗi: Nếu chúng tôi tạo khối dữ liệu 10 MB cứ sau 2-3 giây thì hầu hết người dùng đều có mạng tốc độ> 10 MB/giây, vì vậy họ chắc chắn có thể xử lý các khối như vậy

Đúng: có lẽ cứ 12 giây chúng ta có thể xử lý các khối 1-5 MB. Điều này đã khó khăn rồi.

Ngày nay chúng ta thường nghe thấy số liệu thống kê được quảng cáo về lượng băng thông mà kết nối Internet có thể cung cấp: người ta thường nghe thấy những con số 100 Mbps hoặc thậm chí 1 Gbps. Tuy nhiên, có sự khác biệt đáng kể giữa băng thông được quảng cáo và băng thông thực tế dự kiến vì một số lý do:

"Mbps" có nghĩa là "Mbps" "Hàng triệu bit"; là 1/8 byte nên bạn cần chia số bit được quảng cáo cho 8 để lấy số byte trong quảng cáo.

Giống như tất cả các công ty, các nhà cung cấp Internet thường nói dối.

Luôn có nhiều ứng dụng sử dụng cùng một kết nối internet nên một nút không thể chiếm toàn bộ băng thông.

Mạng P2p chắc chắn có chi phí riêng: các nút thường phải 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 các giao dịch trong khối trước đó). phát qua mblockquotepool).

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

Bộ nhớ

Lỗi: 10 TB

Đúng: 512 GB

Như bạn có thể đoán, lập luận chính ở đây: sự khác biệt giữa lý thuyết và thực hành. Về lý thuyết, bạn có thể mua ổ SSD 8 TB trên Amazon (bạn thực sự cần ổ SSD hoặc NVME; ổ cứng quá chậm để lưu trữ trạng thái blockchain). Trên thực tế, máy tính xách tay được sử dụng để viết bài đăng blog này có dung lượng lưu trữ 512 GB và nếu bạn yêu cầu mọi người mua phần cứng của riêng họ, nhiều người trong số họ sẽ lười biếng (hoặc họ không đủ khả năng chi 800 USD cho ổ SSD 8 TB) và sử dụng một nhà cung cấp tập trung. Ngay cả khi bạn có thể cài đặt chuỗi khối vào một số bộ lưu trữ, mức độ hoạt động cao có thể dễ dàng ghi vào đĩa một cách nhanh chóng và buộc bạn phải tiếp tục mua đĩa mới.

Một tập hợp các giao thức blockchain các nhà nghiên cứu đã khảo sát dung lượng ổ đĩa mà mọi người có. Tôi biết kích thước mẫu là nhỏ, nhưng nó vẫn nói lên điều gì đó

Ngoài ra, kích thước lưu trữ xác định cách các nút mới có thể trực tuyến và bắt đầu tham gia Thời gian cần thiết cho mạng. Mọi dữ liệu 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ộ hóa ban đầu (và băng thông) cũng là rào cản lớn đối với người dùng đang chạy các nút. Tại thời điểm viết bài đăng trên blog này, tôi mất khoảng 15 giờ để đồng bộ hóa nút geth mới. Nếu mức sử dụng Ethereum tăng gấp 10 lần, việc đồng bộ hóa nút geth mới sẽ mất ít nhất một tuần, điều này rất có thể khiến kết nối mạng của bạn bị hạn chế. Điều này đặc biệt quan trọng trong một cuộc tấn công khi phản ứng thành công đối với cuộc tấn công liên quan đến người dùng mới chưa bao giờ chạy nút.

Hiệu ứng tương tác

Ngoài ra còn có tương tác. Do cơ sở dữ liệu sử dụng cấu trúc cây nội bộ để lưu trữ và truy xuất dữ liệu nên chi phí tìm nạp dữ liệu từ cơ sở dữ liệu tăng theo logarit của kích thước cơ sở dữ liệu. Trong thực tế, do lớp trên cùng (hoặc các lớp trên cùng) có thể được lưu vào bộ đệm trong RAM nên chi phí truy cập đĩa tỷ lệ thuận với kích thước của cơ sở dữ liệu, bội số của kích thước của dữ liệu được lưu trong bộ nhớ đệm trong RAM.

Đừng hiểu bức ảnh 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 và phần trong bộ nhớ thường chỉ là một cấp độ duy nhất (nhưng lớn) (xem cây LSM được sử dụng trong Leveldb). Nhưng nguyên tắc cơ bản là như nhau

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

Vậy điều này có ý nghĩa gì đối với Ethereum?

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

Cách duy nhất để giải quyết vấn đề kích thước lưu trữ là không có trạng thái và hết hạn trạng thái. Tính không trạng thái cho phép một lớp nút xác thực chuỗi khối mà không cần duy trì bộ nhớ vĩnh viễn. Trạng thái hết hạn của bản phát hành trạng thái chưa được truy cập gần đây, yêu cầu người dùng cung cấp bằng chứng theo cách thủ công về việc tiếp tục duy trì các trạng thái này. Cả hai con đường đã được sử dụng trong một thời gian dài và việc triển khai bằng chứng khái niệm về trạng thái không trạng thái đã được bắt đầu. Kết hợp lại, 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 cơ hội cho giới hạn gas cao hơn đáng kể. Tuy nhiên, ngay cả sau khi thực hiện trạng thái không trạng thái và hết hạn trạng thái, giới hạn gas chỉ có thể được tăng lên một cách an toàn khoảng 3 lần trước khi các giới hạn khác bắt đầu chiếm ưu thế trở lại.

Điều gì xảy ra sau khi phân mảnh?

Sharding về cơ bản khắc phục được những hạn chế trên vì nó tách dữ liệu có trong chuỗi khối khỏi dữ liệu mà một nút duy nhất cần xử lý và lưu trữ, thay vì các nút xác minh. các khối bằng cách tự tải xuống và thực thi chúng, các kỹ thuật toán học và mật mã tiên tiến được sử dụng để xác minh các khối một cách gián tiếp.

Kết quả là các chuỗi khối phân đoạn có thể đạt được thông lượng giao dịch rất cao một cách an toàn mà các chuỗi khối không phân đoạn không thể làm được. Cần rất nhiều sự khéo léo về mật mã để tạo ra một sự thay thế hiệu quả và được xác minh đầy đủ nhằm loại bỏ thành công các khối không hợp lệ, nhưng điều đó có thể thực hiện được: lý thuyết đã được thiết lập và bằng chứng về khái niệm dựa trên đặc tả dự thảo đã có trong công trình .

Ethereum đang có kế hoạch sử dụng Với phân đoạn thứ cấp, khả năng mở rộng tổng thể của nó bị hạn chế bởi thực tế là các nút phải có khả năng xử lý các phân đoạn riêng lẻ và chuỗi đèn hiệu, chuỗi này phải thực hiện công việc quản lý nhất định cho từng phân đoạn. Nếu phân đoạn quá lớn, nút không thể xử lý một phân đoạn duy nhất nữa; nếu có quá nhiều phân đoạn, nút không thể xử lý chuỗi báo hiệu nữa. Tích của hai ràng buộc này tạo thành một giới hạn trên.

Có thể hình dung rằng người ta có thể tiến xa hơn với phân mảnh gấp ba hoặc thậm chí phân mảnh theo cấp số nhân. Việc lấy mẫu tính khả dụng của dữ liệu chắc chắn trở nên phức tạp hơn trong thiết kế này, nhưng nó có thể được thực hiện. Nhưng Ethereum sẽ không áp dụng sharding cao hơn sharding thứ cấp. Lý do là thực sự không có lợi ích bổ sung nào về khả năng mở rộng có thể đạt được từ việc chia nhỏ các phân đoạn giao dịch trừ khi các rủi ro khác bắt đầu trở nên cao đến mức không 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ể hình dung rằng ngay cả khi chỉ có một người dùng sẵn sàng tham gia thì những người không Chuỗi khối được phân chia cũng có thể được chạy. Điều đó không xảy ra với các chuỗi khối phân mảnh: không một nút nào có thể xử lý toàn bộ chuỗi, vì vậy bạn cần có đủ nút để chúng ít nhất có thể xử lý chuỗi khối cùng nhau. Nếu mỗi nút có thể xử lý 50 TPS và toàn bộ chuỗi có thể xử lý 10.000 TPS thì chuỗi sẽ cần ít nhất 200 nút để tồn tại. Nếu chuỗi có ít hơn 200 nút tại một thời điểm nào đó, thì một trong hai nút không thể theo kịp chuỗi nữa, các nút ngừng phát hiện các khối không hợp lệ hoặc những điều xấu khác có thể xảy ra tùy thuộc vào cách thiết lập phần mềm nút.

Trên thực tế, do nhu cầu dự phòng (bao gồm cả việc lấy mẫu tính khả dụng của dữ liệu), số lượng nút tối thiểu an toàn cao hơn chỉ đơn giản là "chuỗi TPS chia cho nút TPS" Cao hơn vài lần; đối với ví dụ trên, chúng tôi đã nói 1000 nút.

Nếu công suất của một chuỗi khối phân mảnh tăng gấp 10 lần thì số lượng người dùng tối thiểu cũng sẽ tăng gấp 10 lần. Bây giờ, bạn có thể hỏi: tại sao chúng ta không bắt đầu với dung lượng rất nhỏ, tăng dung lượng khi thấy nhiều người dùng và giảm dung lượng khi số lượng người dùng giảm?

Thực sự có một số vấn đề ở đây:

Bản thân blockchain không thể phát hiện một cách đáng tin cậy số lượng người dùng duy nhất, vì vậy, điều này sẽ yêu cầu 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. Việc quản lý những hạn chế về năng lực có thể dễ dàng trở thành nguồn gốc của sự phân mảnh và xung đột.

Điều gì sẽ xảy ra nếu nhiều người dùng thoát đột ngột và bất ngờ?

Tăng số lượng người dùng tối thiểu cần thiết để bắt đầu phân nhánh, khiến việc tiếp quản độc hại 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ư chắc chắn là có thể. Mặt khác, việc đặt số lượng người dùng tối thiểu là 1 triệu là điều không nên. Ngay cả việc đặt số lượng người dùng tối thiểu là 10.000 cũng có một chút rủi ro. Do đó, có vẻ khó để biện minh cho một chuỗi khối phân mảnh có hơn hàng trăm phân đoạn.

Truy xuất lịch sử

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

Có, tới 2372 năm trước đây, mọi người vẫn có thể tải xuống và kiểm tra CryptoKitties 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ả dữ liệu này sẽ trở nên khó khăn hơn, cho đến một lúc nào đó có nguy cơ lớn về lịch sử Một số bộ phận cuối cùng sẽ được...không ai lưu trữ.

Việc định lượng rủi ro này rất dễ dàng. Lấy dung lượng dữ liệu của blockchain tính bằng MB/giây và nhân với ~30 để có được lượng dữ liệu được lưu trữ tính bằng TB mỗi năm. Gói sharding hiện tại có dung lượng dữ liệu khoảng 1,3 MB/giây, tương đương khoảng 40 TB/năm. Nếu bạn tăng con số đó lên gấp 10 lần thì sẽ trở thành 400 TB/năm. Nếu chúng ta muốn dữ liệu không chỉ có thể truy cập được mà còn dễ dàng truy cập thì chúng ta cũng cần siêu dữ liệu (ví dụ: giải nén các giao dịch tổng hợp), tức là 4 PB mỗi năm hoặc 40 PB trong 10 năm. Internet Archive chỉ sử dụng 50 PB. Do đó, đây là giới hạn khối lượng trên hợp lý để bảo mật chuỗi khối được phân chia.

Vì vậy, có vẻ như trong hai chiều này, thiết kế shending Ethereum thực sự đã nhắm đến giá trị bảo mật tối đa khá hợp lý. Hằng số có thể tăng lên một chút, nhưng không quá nhiều.

Tóm tắt

Có hai cách để cố gắng mở rộng chuỗi khối : Cải tiến kỹ thuật cơ bản và bổ sung các thông số đơn giản. Lúc đầu, việc tăng các tham số nghe có vẻ hấp dẫn: nếu bạn đang làm phép toán trên khăn ăn, bạn sẽ dễ dàng thuyết phục bản thân rằng một chiếc máy tính xách tay ở nhà có thể xử lý hàng nghìn giao dịch mỗi giây mà không cần ZK-SNARK, tổng hợp hoặc phân đoạn. Thật không may, có nhiều lý do tế nhị giải thích tại sao phương pháp này về cơ bản lại có sai sót.

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

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

Đặc biệt cảm ơn Fepx Lange, Martin Swende, Marius van der Wijden và Mark Tyneway vì những phản hồi và nhận xét của họ về bài viết này.

Bản gốc văn bản Liên kết

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia