Giải thích chi tiết về các trở ngại và thách thức về hiệu suất của mô-đun blockchain: mô-đun mạng, mô-đun đồng thuận và mô-đun thực thi

Tác giả gốc: Chenxing Li

Tối ưu hóa hiệu suất blockchain là một chủ đề rất nóng . Tuy nhiên, do sự phức tạp của hệ thống blockchain, ngưỡng hiểu biết có hệ thống về tối ưu hóa hiệu suất là rất cao, tạo điều kiện cho “tiêu chuẩn hiệu suất ảo”. Trước đây đã có Bước nhảy vọt vĩ đại "triệu tps" và sau đó là chuỗi thời gian ngừng hoạt động "800.000 tps".

Do đó, tôi hy vọng sẽ mở rộng các thách thức và tắc nghẽn về hiệu suất quyết định các mô-đun khác nhau của chuỗi khối và thấy được độ sâu đằng sau những dữ liệu đẹp đẽ đó.

1. Mô-đun mạng

Trước hết Đối với một hệ thống tập trung, giao tiếp mạng là nền tảng của toàn bộ hệ thống và một số người gọi nó là Lớp 0.

Tôi tóm tắt mô-đun mạng thành ba lớp: lớp cơ sở mạng, lớp kết nối nút và lớp giao thức quảng bá. Mỗi lớp là nền tảng của lớp tiếp theo và hiệu suất của mỗi lớp là giới hạn trên của hiệu suất của lớp tiếp theo.

Băng thông và độ trễ của mô-đun mạng tạo thành cơ sở cho tốc độ tps và độ trễ cuối cùng của hệ thống chuỗi khối.

1.1 Lớp cơ sở mạng

Băng thông: Nó chủ yếu phụ thuộc vào sự phát triển của cơ sở hạ tầng mạng và các yêu cầu cấu hình của các nút blockchain. Trong vài năm qua, yêu cầu cấu hình mạng của chuỗi công cộng thường nằm trong khoảng từ 20Mbps đến 100 Mbps. Đến năm 2022, Aptos đã yêu cầu băng thông mạng 1 Gbps. Nói tóm lại, yêu cầu về băng thông càng cao thì ngưỡng nút càng cao và càng tập trung.

Độ trễ: Độ trễ có giới hạn tối ưu hóa, đó là tốc độ ánh sáng. Độ trễ truyền trên Internet lớn hơn tốc độ trễ ánh sáng. Conflux đã đo độ trễ nút liên lục địa lên tới 200-300ms. Nếu đó là một "chuỗi phòng máy tính" nơi tất cả các nút đều nằm trong trung tâm dữ liệu thì độ trễ có thể được bỏ qua.

1.2 Lớp kết nối nút

Lớp kết nối nút Việc phát tin nhắn trong mạng chủ yếu được thực hiện thông qua liên lạc giữa các nút lân cận.

Băng thông: Nói chung, lớp kết nối nút có thể có được băng thông gần bằng băng thông của lớp cơ sở mạng. Bạn cũng có thể chọn hy sinh băng thông để giảm độ trễ: ví dụ: khi bạn muốn phát một tin nhắn, hãy gửi tin nhắn đó đến tất cả hàng xóm cùng lúc (yêu cầu về băng thông được nhân lên nhiều lần), thay vì gửi một tin nhắn rồi gửi tin nhắn tiếp theo.

Độ trễ: Độ trễ phát tin nhắn có liên quan đến số lượng nút. Càng nhiều nút thì độ trễ càng cao.

Hiện tại có Bitcoin và Ethereum có lẽ có hàng nghìn nút trong xưởng. Theo thử nghiệm của chúng tôi, nếu toàn bộ mạng có 10.000 nút trên khắp thế giới thì độ trễ phát sóng trung bình là 3 ~ 6 giây và tối đa là 15 giây. Với một số tối ưu hóa giao thức, độ trễ tối đa có thể giảm thêm một nửa.

Một số chuỗi công khai yêu cầu độ trễ xác nhận từ 1 đến 2 giây rõ ràng chỉ có thể hỗ trợ ít nút hơn

1.3 Lớp giao thức phát sóng

Lớp kết nối nút chỉ chịu trách nhiệm chuyển tiếp các khối dữ liệu, bất kể dữ liệu đó là gì. Lớp giao thức quảng bá xác định các quy tắc chuyển tiếp giao dịch và khối cụ thể.

Băng thông: chủ yếu phụ thuộc vào cách giảm truyền tải dư thừa. Hãy tưởng tượng, nếu mọi người hàng xóm đều gửi cho bạn cùng một giao dịch thì có phải là lãng phí không? Giao thức chuyển tiếp Shrec do Conflux thiết kế tăng tps của các giao dịch phát sóng lên 6 lần trong cùng một băng thông mạng bằng cách giảm sự dư thừa.

Tuy nhiên, miễn là băng thông lớp cơ sở mạng đủ cao (chẳng hạn như 1Gbps), điều này sẽ không trở thành nút cổ chai ngay cả khi nó không được tối ưu hóa.

Độ trễ: Một số giao thức đồng thuận sẽ khuếch đại độ trễ của lớp giao thức quảng bá lên nhiều lần. Ví dụ: khoảng thời gian chặn của Bitcoin yêu cầu độ trễ của lớp giao thức quảng bá gấp 5 lần và việc xác nhận yêu cầu 6 khối. Vì vậy, việc tối ưu hóa độ trễ ở đây là rất quan trọng. Năm 2016, Bitcoin đã giảm độ trễ phát khối từ 120 giây xuống dưới 10 giây thông qua thiết kế các khối nhỏ gọn.

Khối nhỏ gọn không chứa giao dịch hoàn chỉnh mà chỉ chứa 6 byte đầu tiên của hàm băm giao dịch, vì các giao dịch này đã được phát trên mạng và được hầu hết các nút nhận. Điều này có thể tăng tốc độ phát sóng khối, cho phép lớp giao thức quảng bá đạt được độ trễ gần bằng độ trễ của lớp kết nối nút. Sau năm 2017, các chuỗi công cộng hiệu suất cao về cơ bản đã áp dụng thiết kế này.

2. Mô-đun đồng thuận

Giao thức đồng thuận là phần phức tạp và phức tạp nhất của hệ thống blockchain. Nó điều phối nhiều nút không tin cậy lẫn nhau và cung cấp các dịch vụ phi tập trung đáng tin cậy cho các ứng dụng lớp trên. Trong một thời gian dài, tối ưu hóa hiệu suất của mô-đun đồng thuận đã là một chủ đề nóng.

Băng thông: Những thiếu sót của chính sự đồng thuận Satoshi khiến băng thông đồng thuận của nó ở mức rất thấp, nếu không sẽ làm tăng các nhánh mạng và giảm tính bảo mật của hệ thống.

Các giao thức mới sau năm 2017 về cơ bản có thể tận dụng tối đa băng thông, điều này không còn là vấn đề nữa.

Tuy nhiên, một số dự án nhầm lẫn TPS của mô-đun đồng thuận với TPS của hệ thống chuỗi khối và gọi việc sử dụng toàn bộ băng thông là “có khả năng mở rộng vô hạn”, như thể băng thông mạng là không giới hạn.

Độ trễ: Độ trễ đồng thuận đề cập đến khoảng thời gian từ khi tạo khối đến khi hoàn thiện. Độ trễ xác nhận đồng thuận của Satoshi Nakamoto là rất kém, yêu cầu độ trễ của lớp giao thức phát sóng khoảng 30 đến 60 lần.Các giao thức PoW tiếp theo như Bitcoin-NG, OHIE, v.v. chưa tối ưu hóa độ trễ này. Prism tối ưu hóa độ trễ lên 23x và Conflux lên 3x. Tôi có hiểu biết hạn chế về giao thức PoS và tôi ước tính rằng nó đòi hỏi độ trễ gấp khoảng 5 lần.

Tuy nhiên, có sự khác biệt lớn giữa giao thức PoW và PoS: PoW đề cập đến độ trễ tối đa, PoS đề cập đến độ trễ trung bình, còn độ trễ tối đa và độ trễ trung bình có thể là 3 lần khác nhau. Do đó, sự đồng thuận PoS thường hoạt động tốt hơn về độ trễ. Nếu có ít nút thì không thể nhập 10 giây. Còn Ethereum áp dụng đồng thuận PoS nhưng chậm hơn thì chỉ có thể nói là một điều kỳ lạ.

Mô-đun đồng thuận là nơi quan trọng nhất dành cho "tiêu chuẩn hóa tham số ảo". Ví dụ, rõ ràng là bạn cần đợi 6 khối để đáp ứng yêu cầu bảo mật, nhưng nhóm dự án lại nói với bạn rằng 1 khối là đủ, dù sao nếu không có ai tấn công thì bí mật sẽ không bị lộ, còn nếu không có tài sản, không ai sẽ tấn công.

Ngoài ra còn có một công nghệ gọi là sharding: nhóm các nút và chỉ định giao dịch cho mỗi nhóm. Mỗi nhóm chỉ xử lý các giao dịch của riêng mình và tin cậy các nhóm khác. Kỹ thuật này giúp bạn dễ dàng đạt được tps cao khi khoe khoang bằng cách tăng số lượng nhóm, nhưng người ta tin rằng các nhóm khác sẽ mang đến rủi ro bảo mật. Do đó, sharding phù hợp với các tình huống có yêu cầu bảo mật thấp, chẳng hạn như chuỗi liên minh trong nước.

3. Mô-đun thực thi

Ethereum Vậy đó có thể mở ra một thế giới bên ngoài Bitcoin vì nó tạo ra các tài sản kỹ thuật số có thể lập trình được. Do đó, mô-đun thực hiện giao dịch cũng là một phần quan trọng của hệ thống blockchain. Nó cũng là một liên kết đã bị bỏ qua trong quá trình tối ưu hóa hiệu suất ban đầu.

Việc thực thi không còn phân biệt giữa băng thông và độ trễ, chỉ quan tâm đến số lượng giao dịch hoặc tác vụ điện toán được xử lý trên một đơn vị thời gian.

Hiệu quả của mô-đun thực thi bị giới hạn bởi các tài nguyên khác nhau của hệ thống máy tính.

Tài nguyên CPU 3.1

Trong quá trình thực thi nối tiếp, hiện tượng thắt cổ chai về hiệu năng CPU là rất rõ ràng. Trong 5 năm qua, hiệu suất lõi đơn của CPU đã tăng chưa đến 1 lần. Trong EVM, nếu không tính đến quyền truy cập bộ lưu trữ, CPU nhanh nhất có thể thực thi 100 triệu gas trong khoảng 1 giây, gấp 80 lần hiệu suất hiện tại của Ethereum (chỉ là ước tính sơ bộ về cường độ).

Thực thi song song là một bước quan trọng trong việc sử dụng tài nguyên CPU. Một số dự án đang cố gắng đề xuất các mô hình ngôn ngữ có lợi hơn cho tính song song, chẳng hạn như Move.

Một nghiên cứu về song song hóa EVM trong Conflux cho biết tiềm năng song song hóa hiện tại của các giao dịch trên chuỗi Ethereum là 9 lần tps.

Tuy nhiên, có nhiều thách thức trong việc song song hóa VM. Ví dụ, lý tưởng nhất là các giao dịch có tính song song cao; trong trường hợp xấu nhất, các giao dịch phụ thuộc lẫn nhau và chỉ có thể được tuần tự hóa. Vậy làm thế nào để thiết kế giá gas và giới hạn gas sao cho trong trường hợp lý tưởng có thể phát huy tối đa khả năng tối ưu hóa song song và trong trường hợp xấu nhất là việc thực thi sẽ không theo kịp?

3.2 Tài nguyên truy cập bộ nhớ

Giống như lớp cơ sở hạ tầng mạng, hiệu suất ở đây chủ yếu phụ thuộc vào sự phát triển của phần cứng và cấu hình tối thiểu của nút blockchain. Trừ khi dữ liệu được lưu trữ trong bộ nhớ, hiệu suất đọc và ghi khi thực hiện giao dịch không thể vượt quá hiệu suất đọc và ghi của đĩa cứng.

Cũng lấy Aptos làm ví dụ. Yêu cầu lưu trữ cho các nút của họ là 40K IOPS và một giao dịch có thể liên quan đến việc sửa đổi trạng thái của hai tài khoản của người gửi và người nhận. Nghĩa là, trong trường hợp xấu nhất, mạng có thể chỉ hỗ trợ 2 10.000 tps.

Nhưng tuyên bố của họ về TPS là 160.000. Bạn có thể tưởng tượng có bao nhiêu điều kiện tiên quyết chưa được tiết lộ đằng sau việc này.

3.3 Cấu trúc lưu trữ có thể kiểm chứng

Cấu trúc lưu trữ có thể xác minh là cấu trúc dữ liệu quan trọng để lưu trữ trên blockchain. Nó cho phép một nút nhẹ truy vấn trạng thái trên chuỗi từ một nút đầy đủ mà nó không tin cậy và là liên kết quan trọng nhất trong chuỗi khối không cần sự tin cậy. Trong Ethereum, việc truy cập cấu trúc lưu trữ có thể kiểm chứng MPT chậm hơn 10 lần so với truy cập trực tiếp vào cơ sở dữ liệu. Do đó, một số blockchain chỉ cần loại bỏ cấu trúc lưu trữ có thể kiểm chứng để đổi lấy hiệu suất tốt hơn.

Cuối cùng, tóm lại, tối ưu hóa hiệu suất của blockchain không phải là một quá trình theo đuổi giới hạn mà là sự đánh đổi giữa tính bảo mật, hiệu quả và phân cấp dưới nhiều hạn chế khác nhau.

Một số sự đánh đổi có thể được Tối ưu hóa, chẳng hạn như sự đồng thuận của Satoshi Nakamoto, mâu thuẫn giữa băng thông đồng thuận và bảo mật sau đó đã được giải quyết.

Một số sự đánh đổi là không thể tránh khỏi và nếu bạn yêu cầu 256 GB bộ nhớ cho mỗi nút, bạn nhất định không có quá nhiều người tham gia độc lập.

Nếu mù quáng theo đuổi hiệu suất cao trên giấy tờ, bạn sẽ chỉ nhận được chuỗi thời gian ngừng hoạt động tập trung. Chỉ bằng cách thực sự đối mặt và giải quyết các vấn đề trong tối ưu hóa hiệu suất mới là cách đúng đắn để cải thiện hiệu suất.

Do giới hạn về không gian nên có nhiều cân nhắc liên quan đến bảo mật chưa được đề cập. Tuy nhiên, nội dung trên cũng đủ để bẻ gãy nhiều miếng bánh lớn.

Liên kết gốc

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