Tại sao hiệu suất Blockchain khó đo lường

Hiệu suất và khả năng mở rộng là những thách thức được thảo luận nhiều trong không gian tiền điện tử, liên quan đến cả dự án Lớp 1 (chuỗi khối độc lập) và giải pháp Lớp 2 (như tổng hợp và các kênh ngoài chuỗi). Tuy nhiên, chúng tôi không có số liệu hoặc tiêu chuẩn chuẩn hóa. Các con số thường được báo cáo theo những cách không nhất quán và không đầy đủ, gây khó khăn cho việc so sánh chính xác các dự án và thường che khuất những gì quan trọng nhất trong thực tế. 

Chúng ta cần một cách tiếp cận sâu sắc và kỹ lưỡng hơn để đo lường và so sánh hiệu suất – một cách tiếp cận chia hiệu suất thành nhiều thành phần và so sánh sự đánh đổi trên nhiều trục. Trong bài đăng này, tôi xác định thuật ngữ cơ bản, phác thảo các thách thức và đưa ra các hướng dẫn cũng như nguyên tắc chính cần ghi nhớ khi đánh giá hiệu suất blockchain. 

Khả năng mở rộng so với hiệu suất

Đầu tiên, hãy xác định hai thuật ngữ, khả năng mở rộng và hiệu suất, có ý nghĩa tiêu chuẩn về khoa học máy tính thường bị sử dụng sai trong bối cảnh blockchain. HIỆU QUẢ đo lường hệ thống là gì hiện có khả năng đạt được. Như chúng ta sẽ thảo luận bên dưới, số liệu hiệu suất có thể bao gồm số giao dịch mỗi giây hoặc thời gian xác nhận giao dịch trung bình. khả năng mở rộngMặt khác, đo lường Khả năng của một hệ thống để cải thiện hiệu suất bằng cách thêm tài nguyên.

Sự khác biệt này rất quan trọng: Nhiều cách tiếp cận để cải thiện hiệu suất không hề cải thiện khả năng mở rộng khi được xác định đúng. Một ví dụ đơn giản là sử dụng sơ đồ chữ ký số hiệu quả hơn, chẳng hạn như chữ ký BLS, có kích thước gần bằng một nửa chữ ký Schnorr hoặc ECDSA. Nếu Bitcoin chuyển từ ECDSA sang BLS, số lượng giao dịch trên mỗi khối có thể tăng 20-30%, cải thiện hiệu suất chỉ sau một đêm. Nhưng chúng tôi chỉ có thể thực hiện việc này một lần — thậm chí không có sơ đồ chữ ký nào tiết kiệm không gian hơn để chuyển sang (chữ ký BLS cũng có thể được tổng hợp để tiết kiệm nhiều không gian hơn, nhưng đây chỉ là một thủ thuật chỉ dùng một lần).

Một số thủ thuật chỉ dùng một lần khác (chẳng hạn như SegWit) có thể áp dụng được trong các chuỗi khối, nhưng bạn cần một kiến ​​trúc có thể mở rộng để đạt được sự cải thiện hiệu suất liên tục, trong đó việc bổ sung thêm nhiều tài nguyên sẽ cải thiện hiệu suất theo thời gian. Đây cũng là kiến ​​thức thông thường trong nhiều hệ thống máy tính khác, chẳng hạn như việc xây dựng một máy chủ web. Với một số thủ thuật phổ biến, bạn có thể xây dựng một máy chủ rất nhanh; nhưng cuối cùng, bạn cần một kiến ​​trúc nhiều máy chủ có thể đáp ứng nhu cầu ngày càng tăng bằng cách liên tục bổ sung thêm các máy chủ.

Hiểu được sự khác biệt cũng giúp tránh được lỗi danh mục phổ biến được tìm thấy trong các câu như “Blockchain X có khả năng mở rộng cao, nó có thể xử lý các giao dịch Y mỗi giây!” Khẳng định thứ hai có thể ấn tượng, nhưng đó là một hiệu suất số liệu chứ không phải số liệu về khả năng mở rộng. Nó không nói lên khả năng cải thiện hiệu suất bằng cách thêm tài nguyên.

Khả năng mở rộng vốn đòi hỏi phải khai thác tính song song. Trong không gian blockchain, việc mở rộng quy mô Lớp 1 dường như yêu cầu phân mảnh hoặc thứ gì đó trông giống như phân mảnh. Khái niệm cơ bản về sharding — chia trạng thái thành nhiều phần để các trình xác thực khác nhau có thể xử lý độc lập — rất khớp với định nghĩa về khả năng mở rộng. Thậm chí còn có nhiều tùy chọn hơn trên Lớp 2 cho phép thêm xử lý song song - bao gồm các kênh ngoài chuỗi, máy chủ tổng hợp và chuỗi bên.

Độ trễ so với thông lượng

Về mặt cổ điển, hiệu suất của hệ thống blockchain được đánh giá theo hai chiều, độ trễ và thông lượng: Độ trễ đo lường tốc độ xác nhận một giao dịch riêng lẻ, trong khi thông lượng đo lường tốc độ tổng hợp của các giao dịch theo thời gian. Các trục này áp dụng cho cả hệ thống Lớp 1 và Lớp 2, cũng như nhiều loại hệ thống máy tính khác (chẳng hạn như công cụ truy vấn cơ sở dữ liệu và máy chủ web).

Thật không may, cả độ trễ và thông lượng đều phức tạp để đo lường và so sánh. Hơn nữa, người dùng cá nhân không thực sự quan tâm đến thông lượng (là thước đo toàn hệ thống). Điều họ thực sự quan tâm là độ trễ và phí giao dịch - cụ thể hơn là giao dịch của họ được xác nhận nhanh chóng và ít tốn kém nhất có thể. Mặc dù nhiều hệ thống máy tính khác cũng được đánh giá trên cơ sở chi phí/hiệu suất, phí giao dịch là một trục hiệu suất hơi mới đối với các hệ thống blockchain không thực sự tồn tại trong các hệ thống máy tính truyền thống.

Những thách thức trong việc đo độ trễ

Độ trễ ban đầu có vẻ đơn giản: giao dịch mất bao lâu để được xác nhận? Nhưng luôn có nhiều cách khác nhau để trả lời câu hỏi này.

Đầu tiên, chúng ta có thể đo độ trễ giữa các thời điểm khác nhau và nhận được các kết quả khác nhau. Ví dụ: chúng tôi có bắt đầu đo độ trễ khi người dùng nhấn nút “gửi” cục bộ hay khi giao dịch chạm vào mempool không? Và chúng ta có dừng đồng hồ khi giao dịch nằm trong khối được đề xuất hay khi một khối được xác nhận với một hoặc sáu khối tiếp theo?

Cách tiếp cận phổ biến nhất dựa trên quan điểm của người xác thực, đo lường từ thời điểm khách hàng lần đầu tiên phát giao dịch cho đến thời điểm giao dịch được “xác nhận” hợp lý (theo nghĩa là người bán trong thế giới thực sẽ xem xét khoản thanh toán đã nhận và giao hàng) . Tất nhiên, những người bán khác nhau có thể áp dụng các tiêu chí chấp nhận khác nhau và thậm chí một người bán cũng có thể sử dụng các tiêu chuẩn khác nhau tùy thuộc vào số tiền giao dịch.

Cách tiếp cận lấy người xác nhận làm trung tâm đã bỏ sót một số điều quan trọng trong thực tế. Đầu tiên, nó bỏ qua độ trễ trên mạng ngang hàng (mất bao lâu từ khi máy khách phát một giao dịch đến khi hầu hết các nút đều nghe thấy nó?) và độ trễ phía máy khách (mất bao lâu để chuẩn bị giao dịch trên máy cục bộ của khách hàng?). Độ trễ phía khách hàng có thể rất nhỏ và có thể dự đoán được đối với các giao dịch đơn giản như ký thanh toán Ethereum, nhưng có thể đáng kể đối với các trường hợp phức tạp hơn như chứng minh giao dịch Zcash được bảo vệ là chính xác.

Ngay cả khi chúng tôi đã chuẩn hóa khoảng thời gian mà chúng tôi đang cố gắng đo bằng độ trễ thì câu trả lời hầu như luôn là nó phụ thuộc. Không có hệ thống tiền điện tử nào từng được xây dựng có độ trễ giao dịch cố định. Một nguyên tắc cơ bản cần nhớ là:

Độ trễ là một sự phân phối, không phải là một con số.

Cộng đồng nghiên cứu mạng lưới từ lâu đã hiểu điều này (ví dụ, xem phần này bài nói chuyện tuyệt vời của Gil Tene). Sự nhấn mạnh đặc biệt được đặt vào “đuôi dài” của phân phối, vì độ trễ tăng cao thậm chí trong 0.1% giao dịch (hoặc truy vấn máy chủ web) sẽ nghiêm trọng. tác động người dùng cuối.

Với blockchain, độ trễ xác nhận có thể thay đổi vì một số lý do:

Hàng loạt: hầu hết các hệ thống giao dịch theo nhóm theo một cách nào đó, ví dụ như thành các khối trên hầu hết các hệ thống Lớp 1. Điều này dẫn đến độ trễ thay đổi vì một số giao dịch sẽ phải đợi cho đến khi lô được lấp đầy. Những người khác có thể gặp may mắn và tham gia đợt cuối cùng. Các giao dịch này được xác nhận ngay lập tức và không gặp phải bất kỳ độ trễ bổ sung nào.

Tắc nghẽn thay đổi: hầu hết các hệ thống đều bị tắc nghẽn, nghĩa là có nhiều giao dịch được đăng tải hơn (ít nhất là trong một số thời điểm) so với mức hệ thống có thể xử lý ngay lập tức. Mức độ tắc nghẽn có thể thay đổi khi các giao dịch được phát sóng vào những thời điểm không thể đoán trước (thường được tóm tắt dưới dạng Quá trình Poisson) hoặc khi tỷ lệ giao dịch mới thay đổi trong suốt ngày hoặc tuần hoặc để phản ứng với các sự kiện bên ngoài như đợt ra mắt NFT phổ biến.

Phương sai của lớp đồng thuận: Việc xác nhận giao dịch trên Lớp 1 thường yêu cầu một tập hợp các nút phân tán để đạt được sự đồng thuận trên một khối, điều này có thể gây thêm độ trễ thay đổi bất kể tắc nghẽn. Các hệ thống bằng chứng công việc tìm thấy các khối vào những thời điểm không thể đoán trước (hay nói một cách trừu tượng là quy trình Poisson). Hệ thống bằng chứng cổ phần cũng có thể gây ra nhiều độ trễ khác nhau (ví dụ: nếu không đủ số lượng nút trực tuyến để thành lập ủy ban trong một vòng hoặc nếu cần phải thay đổi chế độ xem để ứng phó với sự cố của người lãnh đạo).

Vì những lý do này, một hướng dẫn tốt là:

Tuyên bố về độ trễ phải thể hiện sự phân bổ (hoặc biểu đồ) thời gian xác nhận, thay vì một con số duy nhất như giá trị trung bình hoặc trung vị.

Trong khi các số liệu thống kê tóm tắt như giá trị trung bình, trung vị hoặc phân vị cung cấp một phần bức tranh thì việc đánh giá chính xác một hệ thống đòi hỏi phải xem xét toàn bộ phân bổ. Trong một số ứng dụng, độ trễ trung bình có thể cung cấp cái nhìn sâu sắc nếu phân bố độ trễ tương đối đơn giản (ví dụ: Gaussian). Nhưng trong tiền điện tử, hầu như không bao giờ như vậy: Thông thường, có một khoảng thời gian dài xác nhận chậm.

Mạng kênh thanh toán (ví dụ: Lightning Network) là một ví dụ điển hình. Là một giải pháp mở rộng quy mô L2 cổ điển, các mạng này hầu hết cung cấp xác nhận thanh toán rất nhanh, nhưng đôi khi chúng yêu cầu đặt lại kênh, điều này có thể làm tăng độ trễ lên gấp nhiều lần.

Và ngay cả khi chúng tôi có số liệu thống kê tốt về phân bổ độ trễ chính xác, chúng có thể sẽ thay đổi theo thời gian khi hệ thống và nhu cầu về hệ thống thay đổi. Cách so sánh phân bổ độ trễ giữa các hệ thống cạnh tranh cũng không phải lúc nào cũng rõ ràng. Ví dụ: hãy xem xét một hệ thống xác nhận các giao dịch có độ trễ được phân bổ đồng đều trong khoảng từ 1 đến 2 phút (với giá trị trung bình và trung bình là 90 giây). Nếu một hệ thống cạnh tranh xác nhận chính xác 95% giao dịch trong 1 phút và 5% còn lại trong 11 phút (với thời gian trung bình là 90 giây và trung bình là 60 giây), thì hệ thống nào tốt hơn? Câu trả lời có lẽ là một số ứng dụng thích cái trước và một số ứng dụng thích cái sau.

Cuối cùng, điều quan trọng cần lưu ý là trong hầu hết các hệ thống, không phải tất cả các giao dịch đều được ưu tiên như nhau. Người dùng có thể trả nhiều tiền hơn để có được mức độ ưu tiên cao hơn, do đó, ngoài tất cả những điều trên, độ trễ sẽ thay đổi tùy theo mức phí giao dịch được thanh toán. Tóm tắt:

Độ trễ rất phức tạp. Càng nhiều dữ liệu được báo cáo thì càng tốt. Lý tưởng nhất là nên đo lường sự phân bố độ trễ hoàn chỉnh trong các điều kiện tắc nghẽn khác nhau. Việc phân tích độ trễ thành các thành phần khác nhau (cục bộ, mạng, phân đợt, độ trễ đồng thuận) cũng rất hữu ích.

Những thách thức trong việc đo lường thông lượng

Thông lượng thoạt nhìn cũng có vẻ đơn giản: một hệ thống có thể xử lý bao nhiêu giao dịch mỗi giây? Hai khó khăn chính nảy sinh: chính xác thì “giao dịch” là gì và chúng ta đang đo lường những gì một hệ thống thực hiện ngày nay hoặc những gì nó có thể làm được?

Mặc dù “giao dịch mỗi giây” (hoặc tps) là một tiêu chuẩn trên thực tế để đo lường hiệu suất của blockchain, nhưng các giao dịch lại có vấn đề khi coi đó là một đơn vị đo lường. Đối với các hệ thống cung cấp khả năng lập trình cho mục đích chung (“hợp đồng thông minh”) hoặc thậm chí các tính năng hạn chế như giao dịch đa kênh của Bitcoin hoặc các tùy chọn để xác minh nhiều chữ ký, vấn đề cơ bản là:

Không phải tất cả các giao dịch đều như nhau.

Điều này rõ ràng đúng trong Ethereum, nơi các giao dịch có thể bao gồm mã tùy ý và trạng thái sửa đổi tùy ý. Khái niệm gas trong Ethereum được sử dụng để định lượng (và tính phí) tổng khối lượng công việc mà một giao dịch đang thực hiện, nhưng điều này rất cụ thể đối với môi trường thực thi EVM. Không có cách nào đơn giản để so sánh tổng khối lượng công việc được thực hiện bởi một tập hợp giao dịch EVM với một tập hợp các giao dịch Solana sử dụng môi trường BPF. Việc so sánh với một tập hợp các giao dịch Bitcoin cũng khó khăn tương tự.

Các chuỗi khối tách lớp giao dịch thành lớp đồng thuận và lớp thực thi có thể làm cho điều này rõ ràng hơn. Ở lớp đồng thuận (thuần túy), thông lượng có thể được đo bằng byte được thêm vào chuỗi trên một đơn vị thời gian. Lớp thực thi sẽ luôn phức tạp hơn.

Các lớp thực thi đơn giản hơn, chẳng hạn như máy chủ tổng hợp chỉ hỗ trợ các giao dịch thanh toán, tránh được khó khăn trong việc định lượng tính toán. Tuy nhiên, ngay cả trong trường hợp này, các khoản thanh toán có thể khác nhau về số lượng đầu vào và đầu ra. Kênh thanh toán các giao dịch có thể khác nhau về số lượng “bước nhảy” cần thiết, điều này ảnh hưởng đến thông lượng. Và thông lượng của máy chủ tổng hợp có thể phụ thuộc vào mức độ mà một loạt giao dịch có thể được “ghi” vào một nhóm thay đổi tóm tắt nhỏ hơn.

Một thách thức khác với thông lượng là việc vượt ra ngoài việc đo lường hiệu suất ngày nay bằng thực nghiệm để đánh giá năng lực lý thuyết. Phần này giới thiệu tất cả các loại câu hỏi mô hình hóa để đánh giá năng lực tiềm năng. Đầu tiên, chúng ta phải quyết định khối lượng công việc giao dịch thực tế cho lớp thực thi. Thứ hai, các hệ thống thực hầu như không bao giờ đạt được năng lực lý thuyết, đặc biệt là hệ thống blockchain. Vì lý do mạnh mẽ, chúng tôi hy vọng việc triển khai nút không đồng nhất và đa dạng trong thực tế (thay vì tất cả các máy khách chạy một triển khai phần mềm duy nhất). Điều này làm cho việc mô phỏng chính xác thông lượng blockchain thậm chí còn khó thực hiện hơn. 

Tổng thể:

Khiếu nại về thông lượng yêu cầu giải thích cẩn thận về khối lượng công việc giao dịch và số lượng trình xác thực (số lượng, cách triển khai và kết nối mạng của chúng). Trong trường hợp không có bất kỳ tiêu chuẩn rõ ràng nào, khối lượng công việc lịch sử từ một mạng phổ biến như Ethereum là đủ.

Sự cân bằng độ trễ-thông lượng

Độ trễ và thông lượng thường là sự cân bằng. BẰNG Sơ lược về Lefteris Kokoris-Kogias, sự cân bằng này thường không suôn sẻ, với điểm uốn mà độ trễ tăng mạnh khi tải hệ thống đạt đến thông lượng tối đa.

Hệ thống tổng hợp không có kiến ​​thức trình bày một ví dụ tự nhiên về sự cân bằng thông lượng/độ trễ. Các lô giao dịch lớn làm tăng thời gian chứng minh, làm tăng độ trễ. Nhưng dấu chân trên chuỗi, cả về quy mô bằng chứng và chi phí xác thực, sẽ được khấu hao theo nhiều giao dịch hơn với quy mô lô lớn hơn, làm tăng thông lượng.

Phí giao dịch

Có thể hiểu được, người dùng cuối quan tâm nhiều hơn đến sự cân bằng giữa độ trễ và lệ phí, không phải độ trễ và thông lượng. Người dùng không có lý do trực tiếp nào để quan tâm đến thông lượng, chỉ có điều họ có thể xác nhận giao dịch nhanh chóng với mức phí thấp nhất có thể (với một số người dùng quan tâm nhiều hơn đến phí và những người khác quan tâm nhiều hơn đến độ trễ). Ở mức độ cao, phí bị ảnh hưởng bởi nhiều yếu tố:

1. Nhu cầu thị trường để thực hiện giao dịch là bao nhiêu?
2. Thông lượng tổng thể mà hệ thống đạt được là bao nhiêu?
3. Tổng doanh thu mà hệ thống cung cấp cho người xác nhận hoặc người khai thác là bao nhiêu?
4. Bao nhiêu trong số doanh thu này dựa trên phí giao dịch so với phần thưởng lạm phát?

Hai yếu tố đầu tiên đại khái là các đường cung/cầu dẫn đến mức giá cân bằng thị trường (mặc dù người ta khẳng định rằng thợ mỏ hoạt động như một cartel để tăng phí trên mức này). Tất cả những yếu tố khác đều như nhau, thông lượng nhiều hơn sẽ có xu hướng dẫn đến mức phí thấp hơn, nhưng còn nhiều điều nữa đang diễn ra.

Đặc biệt, điểm 3 và 4 ở trên là những câu hỏi cơ bản về thiết kế hệ thống blockchain, tuy nhiên chúng ta thiếu những nguyên tắc tốt cho cả hai điểm đó. Chúng tôi có một số hiểu biết về những ưu điểm và nhược điểm của việc mang lại doanh thu cho người khai thác từ phần thưởng lạm phát so với phí giao dịch. Tuy nhiên, mặc dù có nhiều phân tích kinh tế về các giao thức đồng thuận blockchain, chúng tôi vẫn chưa có mô hình được chấp nhận rộng rãi về số tiền doanh thu cần chuyển cho người xác thực. Ngày nay, hầu hết các hệ thống đều xây dựng dựa trên phỏng đoán có căn cứ về mức doanh thu đủ để giữ cho người xác thực hành xử trung thực mà không ảnh hưởng đến việc sử dụng hệ thống trong thực tế. Trong các mô hình đơn giản hóa, có thể chỉ ra rằng chi phí để thực hiện một cuộc tấn công 51% có phần thưởng cho người xác nhận.

Tăng chi phí cho các cuộc tấn công là một điều tốt, nhưng chúng tôi cũng không biết mức độ bảo mật là “đủ”. Hãy tưởng tượng bạn đang cân nhắc việc đi đến hai công viên giải trí. Một trong số họ tuyên bố chi tiêu ít hơn 50% cho việc bảo trì xe so với người kia. Có nên đi đến công viên này không? Có thể là chúng hiệu quả hơn và nhận được mức độ an toàn tương đương với ít tiền hơn. Có lẽ người kia đang chi tiêu nhiều hơn số tiền cần thiết để giữ cho các chuyến đi an toàn mà không mang lại lợi ích gì. Nhưng cũng có thể xảy ra trường hợp công viên đầu tiên gặp nguy hiểm. Các hệ thống chuỗi khối cũng tương tự. Khi bạn tính đến thông lượng, các chuỗi khối có mức phí thấp hơn sẽ có mức phí thấp hơn vì chúng mang lại ít phần thưởng hơn (và do đó khuyến khích) cho người xác thực của chúng. Ngày nay, chúng tôi không có công cụ tốt để đánh giá xem điều này có ổn không hoặc liệu nó có khiến hệ thống dễ bị tấn công hay không. Tổng thể:

So sánh phí giữa các hệ thống có thể gây hiểu nhầm. Mặc dù phí giao dịch rất quan trọng đối với người dùng nhưng chúng bị ảnh hưởng bởi nhiều yếu tố bên cạnh bản thân thiết kế hệ thống. Thông lượng là thước đo tốt hơn để phân tích toàn bộ hệ thống.

Kết luận

Đánh giá hiệu suất một cách công bằng và chính xác là rất khó. Điều này cũng đúng khi đo hiệu suất của một chiếc ô tô. Cũng giống như blockchain, những người khác nhau sẽ quan tâm đến những thứ khác nhau. Với ô tô, một số người dùng sẽ quan tâm đến tốc độ tối đa hoặc khả năng tăng tốc, những người khác về mức tiêu thụ xăng và những người khác nữa về khả năng kéo. Tất cả những điều này là không tầm thường để đánh giá. Ví dụ, ở Hoa Kỳ, Cơ quan Bảo vệ Môi trường duy trì các hướng dẫn chi tiết về cách đánh giá mức tiêu hao nhiên liệu cũng như cách nó phải được trình bày cho người dùng tại đại lý.

Không gian blockchain còn một chặng đường dài mới đạt được mức tiêu chuẩn hóa này. Ở một số khu vực nhất định, chúng tôi có thể đạt được điều đó trong tương lai với khối lượng công việc được tiêu chuẩn hóa để đánh giá thông lượng của hệ thống hoặc biểu đồ tiêu chuẩn hóa để trình bày phân bổ độ trễ. Hiện tại, cách tiếp cận tốt nhất dành cho người đánh giá và người xây dựng là thu thập và xuất bản càng nhiều dữ liệu càng tốt, kèm theo mô tả chi tiết về phương pháp đánh giá để có thể sao chép và so sánh với các hệ thống khác.