a16z: Tại sao hiệu suất chuỗi khó đo lường?

Odaily资深作者

2022-08-10 03:31

Bài viết này có khoảng 4907 từ, đọc toàn bộ bài viết mất khoảng 8 phút

Tìm hiểu sâu về nó, cách sử dụng và so sánh các chỉ số hiệu suất này.

Bài viết này đến từ a16zBài viết này đến từ

, tác giả gốc: Joseph Bonneau, do dịch giả Katie Koo của Odaily biên soạn.

Chúng tôi cần một cách tiếp cận kỹ lưỡng và chi tiết hơn để đo lường và so sánh hiệu suất—chia nhỏ hiệu suất thành các thành phần và so sánh sự đánh đổi trên nhiều trục dữ liệu. Bài báo này xác định ý nghĩa của hiệu suất chuỗi khối và phác thảo những thách thức của nó, đồng thời cung cấp các hướng dẫn và nguyên tắc chính cần ghi nhớ khi đánh giá hiệu suất chuỗi khối.

tiêu đề phụ

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

Đầu tiên, khả năng mở rộng và hiệu suất có ý nghĩa khoa học máy tính tiêu chuẩn thường bị áp dụng sai trong các chuỗi khối. Hiệu suất đo lường những gì hệ thống 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 giao dịch mỗi giây hoặc thời gian xác nhận giao dịch trung bình. Mặt khác, khả năng mở rộng đo lường khả năng tăng hiệu suất của hệ thống bằng cách thêm tài nguyên.

Sự khác biệt rất quan trọng: nếu được xác định đúng, nhiều cách để cải thiện hiệu suất hoàn toàn không cải thiện khả năng mở rộ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 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 - không có sơ đồ chữ ký tiết kiệm không gian hơn để chuyển đổi (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 đó là một thủ thuật một lần khác).

Một số thủ thuật một lần khác (chẳng hạn như SegWit) cũng có thể được sử dụng trong chuỗi khối, nhưng bạn cần một kiến trúc có thể mở rộng để cải thiện hiệu suất liên tục, trong đó việc 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à suy nghĩ thông thường đối với nhiều hệ thống máy tính khác, chẳng hạn như xây dựng một máy chủ web. Với một vài thủ thuật phổ biến, bạn có thể xây dựng một máy chủ chạy nhanh. Nhưng cuối cùng, một kiến trúc đa máy chủ là cần thiết để đá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ủ.

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

tiêu đề phụ

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

Nhưng việc đo lường và so sánh độ trễ và thông lượng rất phức tạp. Ngoài ra, người dùng cá nhân không thực sự quan tâm đến thông lượng (đó là số liệu trên 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, các giao dịch của họ được xác nhận nhanh chóng và rẻ nhất có thể. Trong khi 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 mới cho các hệ thống chuỗi khối không thực sự tồn tại trong các hệ thống máy tính truyền thống.

tiêu đề phụ

Những thách thức của việc đo lường độ trễ

Thoạt nhìn, độ trễ có vẻ đơn giản: mất bao lâu để một giao dịch được xác nhận? Nhưng có một vài 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? Chúng tôi có ngừng đếm thời gian khi các giao dịch nằm trong một khối được đề xuất hoặc khi một khối được xác nhận bởi một hoặc sáu khối tiếp theo không?

Cách tiếp cận phổ biến nhất là đo thời gian từ khi người dùng phát một giao dịch lần đầu tiên đến khi nó được "xác nhận" một cách hợp lý từ quan điểm của người xác thực. 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 đơn lẻ cũng có thể áp dụng các tiêu chí khác nhau tùy thuộc vào số tiền giao dịch.

Cách tiếp cận lấy trình xác nhận làm trung tâm bỏ qua 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áy khách mất bao lâu để phát một giao dịch cho đến khi phần lớn các nút 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?) Sự chậm trễ phía khách hàng rất khó xảy ra 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ể quan trọng đối với các trường hợp phức tạp hơn như chứng minh rằng giao dịch Zcash được bảo vệ là chính xác.

Ngay cả khi chúng tôi bình thường hóa cửa sổ thời gian mà chúng tôi đang cố gắng đo độ trễ, thì câu trả lời còn tùy thuộc. Cho đến nay, không có hệ thống tiền điện tử nào cung cấp độ trễ giao dịch cố định. Một quy tắc cơ bản của ngón tay cái là:

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

Cộng đồng nghiên cứu mạng từ lâu đã hiểu điều này. Đặc biệt nhấn mạnh vào "phần đuôi dài" của phân phối, vì độ trễ cao thậm chí chỉ trong 0,1% giao dịch (hoặc truy vấn máy chủ web) có thể ảnh hưởng nghiêm trọng đến người dùng cuối.

Trong các chuỗi khối, độ trễ xác nhận thay đổi vì một số lý do:xử lý hàng loạt:

Hầu hết các hệ thống xử lý theo lô các giao dịch theo một số cách, chẳng hạn như trên hầu hết các hệ thống L1, chúng xử lý theo lô các giao dịch thành các khối. Điều này sẽ gây ra độ trễ thay đổi, vì một số giao dịch sẽ phải đợi cho đến khi hết lô. Những người khác có thể đủ may mắn để tham gia 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ỳ sự chậm trễ nào.tắc nghẽn thay đổi:

Hầu hết các hệ thống đều gặp phải tình trạng tắc nghẽn, có nghĩa là nhiều giao dịch được phát hành hơn 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 vào những thời điểm không thể đoán trước hoặc khi tốc độ giao dịch mới thay đổi trong một ngày hoặc một tuần hoặc để đáp ứng với các sự kiện bên ngoài như ra mắt NFT phổ biến.Sự khác biệt của lớp đồng thuận:

Việc xác nhận các giao dịch tại L1 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ể thêm độ trễ thay đổi bất kể tình trạng 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. Các hệ thống PoS cũng có thể thêm các độ trễ khác nhau (ví dụ: nếu không có đủ nút trực tuyến để thành lập một ủy ban trong một vòng hoặc nếu cần thay đổi quan điểm để đối phó với sự sụp đổ của người lãnh đạo).

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

Tuyên bố về độ trễ phải hiển thị phân phối thời gian xác nhận, không phải là một số như giá trị trung bình hoặc trung bình.

Mặc dù các số liệu thống kê tóm tắt như giá trị trung bình, trung vị hoặc phần trăm cung cấp một phần bức tranh, nhưng 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 phối. Trong một số ứng dụng, nếu phân phối độ trễ tương đối đơn giản, độ trễ trung bình có thể cung cấp thông tin chi tiết tốt. Nhưng trong tiền điện tử, điều này hầu như không bao giờ xảy ra. Thông thường, thời gian xác nhận là rất lâu.

Một mạng lưới các kênh thanh toán như Lightning Network là một ví dụ điển hình. Đây là giải pháp mở rộng quy mô L2 cổ điển, hầu hết thời gian các mạng này 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ễ theo mức độ lớn.

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

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

tiêu đề phụ

Thách thức của việc đo thông lượng

Thông lượng nhìn bề ngoài 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? Nhưng có hai khó khăn chính: "giao dịch" chính xác là gì, và liệu chúng ta có đang đo lường những gì một hệ thống làm hiện nay hoặc những gì nó có thể làm không?

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

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

Điều này rõ ràng là đúng trong Ethereum, nơi các giao dịch có thể bao gồm mã tùy ý và sửa đổi trạng thá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 phù hợp với môi trường thực thi EVM. Không có cách nào dễ dàng để 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 các giao dịch EVM với một tập hợp các giao dịch Solana bằng môi trường BPF. So sánh cả hai với một tập hợp các giao dịch Bitcoin cũng đáng lo ngại như nhau.

Một chuỗi khối phân chia 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. Trong 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ỗi đơn vị thời gian. Lớp thực thi phức tạp hơn.

Lớp thực thi đơn giản hơn, chẳng hạn như máy chủ Rollup chỉ hỗ trợ các giao dịch thanh toán, giúp tránh được khó khăn trong tính toán định lượng. Ngay cả trong trường hợp này, các khoản thanh toán thay đổi theo số lượng đầu vào và đầu ra. Các giao dịch kênh thanh toán có thể khác nhau về số lượng "bước nhảy" được yêu cầu, điều này sẽ ảnh hưởng đến thông lượng. Thông lượng của máy chủ tổng số phụ thuộc vào mức độ hiệu quả của một lô giao dịch được "nối mạng" thành các tập hợp thay đổi tổng hợp nhỏ hơn.

Một thách thức khác về thông lượng là vượt ra ngoài việc đo lường hiệu suất ngày nay theo kinh nghiệm để đánh giá năng lực lý thuyết. Điều này giới thiệu các vấn đề mô hình hóa khác nhau để đánh giá các khả năng tiềm năng. Đầu tiên, chúng ta phải xác đị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 tế hầu như không bao giờ đạt được năng lực lý thuyết, đặc biệt là các hệ thống chuỗi khối. Vì lý do mạnh mẽ, chúng tôi muốn việc triển khai nút không đồng nhất và đa dạng trong thực tế (chứ không phải tất cả các máy khách đều 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 trở nên khó khăn hơn.

Yêu cầu 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 người xác thực (số lượng, triển khai và kết nối mạng của họ). 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ừ các mạng phổ biến như Ethereum sẽ đủ.

tiêu đề phụ

Đánh đổi độ trễ và thông lượng

tiêu đề phụ

Phí giao dịch

Có thể hiểu được, người dùng cuối quan tâm nhiều hơn đến sự đánh đổi giữa độ trễ và chi phí hơn là giữa độ trễ và thông lượng. Người dùng không có lý do ngay lập tức để quan tâm đến thông lượng, họ chỉ quan tâm đến việc có thể xác nhận giao dịch nhanh chóng và với mức phí thấp nhất có thể (một số người dùng quan tâm nhiều hơn đến phí, một số quan tâm nhiều hơn đến độ trễ). Phí cao bị ảnh hưởng bởi một số yếu tố:
Có bao nhiêu nhu cầu thị trường để giao dịch?
Thông lượng tổng thể đạt được của hệ thống là gì?
Tổng doanh thu mà hệ thống cung cấp cho người xác thực hoặc người khai thác là bao nhiêu?

Bao nhiêu phần trăm doanh thu này dựa trên phí giao dịch hoặc dựa trên phần thưởng lạm phát?

Hai yếu tố đầu tiên đại khái là đường cung và cầu dẫn đến giá bù trừ thị trường (mặc dù một số người cho rằng các công ty khai thác, như liên đoàn, đẩy phí lên trên điểm này). Tất cả những yếu tố khác đều như nhau, thông lượng cao hơn sẽ dẫn đến phí thấp hơn, nhưng có nhiều yếu tố cần giải quyết hơn.

Đặc biệt, điểm 3 và 4 ở trên là những vấn đề cơ bản trong thiết kế hệ thống blockchain, nhưng chúng ta thiếu những nguyên tắc tốt cho cả hai. Chúng tôi có một số hiểu biết về những ưu và nhược điểm của việc trao phần thưởng lạm phát cho người khai thác 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 chuỗi khối, nhưng chúng ta vẫn chưa có một mô hình được chấp nhận rộng rãi về lượng doanh thu cần chuyển đến các trình xác nhận. Hầu hết các hệ thống ngày nay được xây dựng dựa trên phỏng đoán có giáo dục về việc bao nhiêu doanh thu là đủ để những người xác thực hoạt động trung thực mà không cản trở việc sử dụng hệ thống trên thực tế. Trong mô hình đơn giản hóa, có thể thấy rằng chi phí cài đặt cuộc tấn công 51% tỷ lệ thuận với phần thưởng của trình xác thực.

tiêu đề phụ

Tóm lại là

Đánh giá hiệu suất một cách công bằng và chính xác là khó. Điều tương tự cũng áp dụng cho việc đo hiệu suất của ô 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. Khi nói đến ô tô, một số người dùng quan tâm đến tốc độ tối đa hoặc khả năng tăng tốc, những người khác quan tâm đến mức tiêu thụ nhiên liệu và những người khác lại quan tâm đến sức kéo. Tất cả những điều này không dễ dàng để có được giá trị chính xác. Ví dụ, tại Hoa Kỳ, Cơ quan Bảo vệ Môi trường có các hướng dẫn chi tiết về cách đánh giá mức tiết kiệm xăng và cách nó phải được hiển thị cho người dùng tại các đại lý.