a16z: Các nguyên tắc chính để đo lường hiệu suất blockchain

Tiêu đề gốc: "a16z: Tại sao hiệu suất của dây chuyền lại khó đo lường? 》

Tác giả gốc: Joseph Bonneau, a16z 

Tác giả gốc: Katie Gu, Hành tinh Odaily hàng ngày

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 lĩnh vực mật mã, cả liên quan đến các dự án L1 và giải pháp L2. Tuy nhiên, chúng tôi không có số liệu hoặc điểm chuẩn chuẩn hóa. Cách báo cáo dữ liệu thường 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 tôi cần một cách tiếp cận kỹ lưỡng và sắc thái 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 giữa nhiều trục dữ liệu. Bài viết này xác định hiệu suất của blockchain là gì 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 lưu ý khi đánh giá hiệu suất của blockchain.

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 tiêu chuẩn về khoa học máy tính và trong blockchain thường bị lạm dụng. Hiệu suất đo lường những gì hệ thống hiện có thể đạ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. 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 chính xác, nhiều phương pháp 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 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 - không còn sơ đồ chữ ký tiết kiệm không gian nào để 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 đó 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ũng có thể được sử dụng trong blockchain, nhưng bạn cần một kiến trúc có thể mở rộng để đạt được những cải tiến hiệu suất liên tục, trong đó cần bổ sung thêm nguồn lực có thể cải thiện hiệu suất theo thời gian. Đây cũng là cách tiếp cận truyền 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 số mẹo phổ biến, bạn có thể xây dựng một máy chủ nhanh. Nhưng cuối cùng thì cần phải có kiến trúc nhiều máy chủ, với các máy chủ bổ sung liên tục được bổ sung để đáp ứng nhu cầu ngày càng tăng.

Hiểu được sự khác biệt này cũng có thể giúp tránh được các loại lỗi phổ biến được tìm thấy trong các tuyên bố như "Thương mại Blockchain". Tuyên bố thứ hai có thể ấn tượng, nhưng nó là thước đo hiệu suất, không phải thước đo khả năng mở rộng và không đề cập đến khả năng tăng 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 tận dụng tính song song. Trong không gian blockchain, việc mở rộng quy mô L1 dường như yêu cầu phân nhánh hoặc thứ gì đó tương tự như phân nhánh. Khái niệm cơ bản của 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ý nó một cách độ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 khác 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 hợp và chuỗi bên.

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

Nói chung, hiệu suất hệ thống blockchain Nó được đánh giá thông qua hai chiều, độ trễ và thông lượng. Số liệu độ trễ xác định tốc độ của các giao dịch riêng lẻ, trong khi thông lượng đo lường tốc độ giao dịch tổng thể theo thời gian. Các trục này áp dụng cho cả hệ thống L1 và L2, cũng như cho 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).

Nhưng độ trễ và thông lượng rất 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à 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 biệt hơn, 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 blockchain không thực sự tồn tại trong các hệ thống máy tính truyền thống.

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

Độ trễ ban đầu có vẻ đơn giản: một giao dịch diễn ra trong bao lâu Mất bao lâu để được xác nhận? Nhưng có một số 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ấp vào nút "Gửi" cục bộ hay khi giao dịch chạm vào mempool không? Chúng ta chỉ dừng đếm thời gian khi một giao dịch nằm trong khối được đề xuất hay khi một khối được xác nhận bởi một hoặc sáu khối tiếp theo?

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

Cách tiếp cận lấy người xác thực làm trung tâm đã bỏ lỡ 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 (khách hàng 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ễ của khách hàng (mất bao lâu để chuẩn bị giao dịch trên mạng của khách hàng). máy cục bộ?) Độ trễ của máy khách 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 rằng giao dịch Zcash bị chặn là chính xác.

Ngay cả khi chúng tôi bình thường hóa khoảng thời gian mà chúng tôi đang cố gắng đo độ trễ, thì câu trả lời là điều đó còn tùy. 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. Nguyên tắc cơ bản là:

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

Cộng đồng nghiên cứu mạng lưới đã biết điều này từ lâu. Đặc biệt nhấn mạnh vào "đoạn dài" của quá trình phân phối, vì độ trễ cao thậm chí chỉ 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 blockchain, độ trễ xác nhận khác nhau vì nhiều lý do:

Phân nhóm: Hầu hết các hệ thống phân nhóm giao dịch theo cách nào đó, chẳng hạn như phân nhóm giao dịch thành các khối trên hầu hết các hệ thống L1. Điều này sẽ 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ể đủ 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 nữa.

Tắc nghẽn có thể 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 đăng hơn mức hệ thống có thể xử lý ngay lập tức. Mức độ tắc nghẽn có thể xảy ra 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 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ư ra mắt một loại 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 trong L1 thường yêu cầu một nhóm các nút phân tán đạt được sự đồng thuận về một khối, điều này có thể sẽ bổ sung thêm độ trễ thay đổi bất kể tắc nghẽn. 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. Hệ thống PoS cũng có thể bổ sung thêm nhiều độ trễ khác nhau (ví dụ: nếu không có đủ 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 quan điểm để ứng phó với sự sụp đổ của người dẫn đầu).

Vì những lý do này, một nguyên tắc chỉ đạo tốt sẽ là:

Các tuyên bố về độ trễ phải hiển thị sự phân bổ thời gian xác nhận chứ không phải một con số như giá trị trung bình hoặc trung vị.

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 vị 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 bổ. Trong một số ứng dụng, nếu việc phân bổ độ trễ tương đối đơn giản thì độ trễ trung bình có thể mang lại cái nhìn sâu sắc. Nhưng trong tiền điện tử, điều này gần như không bao giờ xảy ra. Thông thường, thời gian xác nhận kéo dài.

Mạng kênh thanh toán (chẳng hạ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, 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.

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 vẫn có thể thay đổi khi hệ thống và yêu cầu hệ thống thay đổi. Ngoài ra, không phải lúc nào cũng rõ ràng cách so sánh phân bổ độ trễ giữa các hệ thống cạnh tranh. Ví dụ: giả sử một hệ thống có độ trễ giao dịch được xác nhận phân bố đồng đều trong khoảng từ 1 đến 2 phút (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 vòng 1 phút và 5% giao dịch khác trong vòng 11 phút (trung bình 90 giây, trung bình là 60 giây), thì 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ố ứng dụng lại 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ó mức độ ưu tiên như nhau. Người dùng có thể trả nhiều tiền hơn để được ưu tiên cao hơn nên ngoài những điều trên, độ trễ còn phụ thuộc vào phí giao dịch phải trả. Tóm lại:

Độ 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à phân bổ độ 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.

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

Nhìn bề ngoài, thông lượng có vẻ đơn giản: a Có bao nhiêu giao dịch mỗi giây hệ thống có thể xử lý? Nhưng có hai khó khăn lớn: "giao dịch" chính xác là gì và chúng ta đang đo lường xem hệ thống đang làm gì hôm nay hoặc nó có thể làm gì?

Mặc dù "giao dịch mỗi giây" (tps) là 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 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ế, chẳng hạn như tùy chọn xác minh đa giao dịch hoặc đa tín hiệu của Bitcoin, 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 đúng trong Ethereum, nơi các giao dịch có thể bao gồm mã tùy ý và sửa đổi bất kỳ trạng thái nào. 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 được thực hiện bởi một giao dịch, 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 giao dịch EVM với một tập hợp các nền tảng giao dịch Solana sử dụng môi trường BPF. Việc so sánh cả hai với một tập hợp các giao dịch Bitcoin cũng có liên quan không kém.

Một blockchain 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. Ở 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 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ủ Rollup chỉ hỗ trợ các giao dịch thanh toán, tránh được những khó khăn khi tính toán định lượng. Ngay cả trong trường hợp này, các khoản thanh toán cũng khác nhau tùy thuộc vào số lượng đầu vào và đầu ra. Các giao dịch trên kênh thanh toán có thể khác nhau về số lượng "bước nhảy" cần thiết, điều này sẽ ảnh hưởng đến thông lượng. Thông lượng máy chủ tổng hợp phụ thuộc vào mức độ hiệu quả của một loạt giao dịch có thể được "kết nối" thành một tập hợp các thay đổi tổng hợp nhỏ hơn.

Một thách thức khác về thông lượng là phải 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. Điều này giới thiệu các vấn đề mô hình hóa khác nhau để đánh giá 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 công suất 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 sẽ không đồng nhất và đa dạng trong thực tế (thay vì 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 khiến việc mô phỏng chính xác thông lượng blockchain trở nên khó khăn hơn.

Tóm lại:

Các 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 nhận ( 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ừ các mạng phổ biến như Ethereum là đủ.

Sự đánh đổi giữa độ trễ và thông lượng

Độ trễ và thông lượng thường là sự đánh đổi. Sự cân bằng này thường không đơn giản và độ trễ tăng lên đáng kể khi tải hệ thống đạt thông lượng tối đa.

Hệ thống tổng hợp kiến thức bằng không là một ví dụ tự nhiên về sự đánh đổi thông lượng/độ trễ. Một số lượng lớn giao dịch sẽ làm tăng thời gian chứng minh và do đó 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 minh, sẽ được dàn trải trên nhiều giao dịch hơn, quy mô lô lớn hơn và thông lượng tăng lên.

Phí giao dịch

Có thể hiểu được, người dùng cuối lo ngại hơn về sự cân bằng giữa độ trễ và đánh đổi phí, thay vì đánh đổi giữa độ trễ và thông lượng. Không có lý do trực tiếp nào khiến người dùng 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ớ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í và một số quan tâm nhiều hơn đến độ trễ). Mức phí cao bị ảnh hưởng bởi nhiều yếu tố:

Nhu cầu thị trường cho giao dịch là bao nhiêu?

Thông lượng tổng thể mà hệ thống đạt được là bao nhiêu?

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?

Bao nhiêu trong số doanh thu này đến từ phí giao dịch hoặc 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á cân bằng thị trường (mặc dù có những tuyên bố rằng các công ty khai thác, như các tập đoàn, tăng phí cao hơn mức này). điểm). Tất cả các yếu tố khác đều như nhau, thông lượng cao hơn sẽ dẫn đến mức 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 chúng. Chúng tôi có một số hiểu biết về lợi ích và hạn chế của việc trao phần thưởng lạm phát cho người khai thác liên quan đến 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ề mức doanh thu cần thiết để trao cho người xác thực. Ngày nay, hầu hết các hệ thống đều được xây dựng dựa trên phỏng đoán có căn cứ về mức doanh thu đủ để cho phép người xác nhận hoạt động một cách trung thực mà không cản trở việc sử dụng hệ thống thực sự. Trong mô hình đơn giản hóa, có thể thấy rằng chi phí cài đặt một cuộc tấn công 51% tỷ lệ thuận với lợi nhuận của trình xác thực.

Tăng chi phí tấn công là điều tốt, nhưng chúng ta không biết bao nhiêu biện pháp an ninh 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 người tuyên bố chi tiêu ít hơn 50% cho việc bảo dưỡng xe so với người kia. Có nên đi đến công viên này không? Điều này có thể là do chúng hoạt động hiệu quả hơn và nhận được mức độ bảo mật tương tự với số tiền ít hơn. Một khả năng khác là chi tiêu nhiều hơn mức cần thiết để giữ chuyến đi an toàn mà không mang lại lợi ích gì. Nhưng cũng có thể là công viên đầu tiên rất nguy hiểm. Các hệ thống chuỗi khối cũng tương tự. Sau khi thông lượng được tính toán, 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 thưởng (và do đó khuyến khích) ít người xác thực hơn. Hiện tại, chúng tôi không có công cụ tốt để đánh giá liệu điều này có khả thi hay không hoặc liệu nó có khiến hệ thống dễ bị tấn công hay không. Tóm lại:

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

Không gian blockchain vẫn 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, trong tương lai, chúng tôi có thể sử dụng khối lượng công việc được tiêu chuẩn hóa để đánh giá thông lượng hệ thống hoặc biểu đồ tiêu chuẩn hóa để thể hiện sự 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à công bố càng nhiều dữ liệu càng tốt, đồng thời cung cấp mô tả chi tiết về phương pháp đánh giá để có thể nhân rộng và so sánh với các hệ thống khác.

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