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

Bản gốc: https://a16zcrypto.com/why-blockchain-performance-is-hard-to-measure/

Bởi Joseph Bonneau

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ử, có liên quan đến cả dự án lớp 1 (các chuỗi khối độc lập) và các giải pháp lớp 2 như các kênh tổng hợp và kênh ngoại tuyến. Tuy nhiên, chúng tôi không có số liệu hoặc điểm chuẩn được tiêu chuẩn hóa. Các con số thường được báo cáo không nhất quán và không đầy đủ, khiến việc so sánh chính xác các dự án trở nên khó khă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 chi tiết và kỹ lưỡng hơn để đo lường và so sánh hiệu suất—một phương pháp chia nhỏ hiệu suất thành các thành phần và so sánh chúng với sự đánh đổi theo nhiều trục. Trong bài đăng này, tôi định nghĩa các thuật ngữ cơ bản, phác thảo các thách thức và cung cấp các nguyên tắc cũng như nguyên tắc chính cần ghi nhớ khi đánh giá hiệu suất chuỗi khối.

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

Trước 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 khoa học máy tính tiêu chuẩn và thường bị lạm dụng trong bối cảnh 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 này rất quan trọng: nếu được xác định rõ ràng, nhiều cách để cải thiện hiệu suất sẽ không cải thiện khả năng mở rộng chút nào. 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 ta chỉ có thể làm điều 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 đây là thủ thuật một lần).

Nhiều thủ thuật một lần khác (chẳng hạn như Segregated Witness) có thể thực hiện đượ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 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à sự khôn ngoan thông thường trong nhiều hệ thống máy tính khác, chẳng hạn như xây dựng 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ủ rất nhanh; nhưng cuối cùng, bạn cần một kiến trúc nhiều máy chủ để liên tục bổ sung các máy chủ bổ sung để đáp ứng nhu cầu ngày càng tăng.

Hiểu sự khác biệt này cũng giúp tránh các lỗi 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!" Tuyên bố thứ hai có thể ấn tượng, nhưng đó là thước đo hiệu suất, không phải thước đo khả năng mở rộng. Nó không tính đế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 yêu cầu khai thác tính song song. Trong không gian chuỗi khối, quy mô lớp 1 dường như yêu cầu phân đoạn hoặc những gì trông giống như phân đoạn. 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ý trạng thái đó một cách độc lập — rất phù hợp với định nghĩa về khả năng mở rộng. Lớp 2 có nhiều tùy chọn hơn 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.

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

Theo truyền thống, hiệu suất của hệ thống chuỗi khối được đánh giá theo hai chiều: độ trễ và thông lượng: độ trễ đo tốc độ xác nhận các giao dịch riêng lẻ, trong khi thông lượng đo tỷ lệ 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ác hệ thống Cấp 1 và Cấp 2, cũng như nhiều loại hệ thống máy tính khác 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 khó đo lường và so sánh. Ngoài ra, 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, các giao dịch của họ được xác nhận càng nhanh càng tốt 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 đại diện cho một trục hiệu suất mới cho các hệ thống chuỗi khối không tồn tại trong các hệ thống máy tính truyền thống.

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

Thoạt đầu, sự chậm trễ có vẻ đơn giản: mất bao lâu để một giao dịch đượ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? Chúng ta có dừng đồng hồ khi một 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 phổ biến nhất để đo lường điều này là từ góc độ của người xác thực, từ thời điểm khách hàng phát giao dịch lần đầu tiên cho đến khi giao dịch đó được "xác nhận" một cách hợp lý (theo nghĩa là người bán trong thế giới thực sẽ cân nhắc việc nhận thanh toán và gửi một mặt hàng) . Tất nhiên , những người bán khác nhau có thể có 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ể có các tiêu chí khác nhau dựa trên số tiền giao dịch.

Cách tiếp cận lấy trình xác thực làm trung tâm bỏ qua một vài đ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ễ phía máy khách (mất bao lâu để giao dịch được chuẩn bị trên máy cục bộ của khách hàng?). Đối với các giao dịch đơn giản như ký thanh toán Ethereum, độ trễ phía khách hàng có thể rất nhỏ và có thể dự đoán được, nhưng đối với các trường hợp phức tạp hơn như chứng minh rằng các giao dịch Zcash được bảo vệ là chính xác, độ trễ có thể rất đáng kể.

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 bằng độ trễ, câu trả lời hầu như luôn phụ thuộc vào nó. Chưa bao giờ có một hệ thống tiền điện tử cung cấp độ trễ giao dịch cố định. Các quy tắc cơ bản của ngón tay cái cần nhớ 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 một chuỗi khối, sự chậm trễ xác nhận có thể khác nhau vì một số lý do:

Batching: Hầu hết các hệ thống giao dịch theo đợt theo một số cách, chẳng hạn như các khối trên hầu hết các hệ thống lớp 1. Điều này gây ra độ trễ thay đổi vì một số giao dịch phải đợi cho đến khi hết lô. 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 mà không có bất kỳ sự chậm trễ nào.

Tắc nghẽn có thể thay đổi: Hầu hết các hệ thống đều bị tắc nghẽn, nghĩa là có (ít nhất một số thời điểm) nhiều giao dịch cần xử lý hơn hệ thống có thể xử lý cùng một lúc. Mức độ tắc nghẽn có thể tăng lên khi các giao dịch được phát vào những thời điểm không thể đoán trước (thường được trừu tượng hóa dưới dạng quy trình Poisson) hoặc khi tỷ lệ 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 chẳng hạn như các đợt phát hành 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 ở 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 các khối, điều này có thể thêm độ trễ thay đổi mà không bị ảnh hưởng bởi tắc nghẽn. Một hệ thống bằng chứng công việc phát hiện ra các khối vào những thời điểm không thể đoán trước (cũng được trừu tượng hóa như một quy trình Poisson). Các hệ thống bằng chứng cổ phần cũng có thể 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 một ủy ban trong một vòng hoặc nếu cần thay đổi chế độ xem để phản hồi lại sự cố của người dẫn đầu).

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

Tuyên bố về độ trễ phải trình bày phân phối (hoặc biểu đồ) thời gian xác nhận, không phải là một 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ư phương tiện, 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, độ trễ trung bình có thể cung cấp thông tin chi tiết tốt nếu phân phối độ trễ tương đối đơn giản (ví dụ: Gaussian). 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 sẽ rất lâu.

Các mạng kênh thanh toán như Lightning Network là một ví dụ điển hình. Là giải pháp thay đổi quy mô L2 cổ điển, các mạng này cung cấp xác nhận thanh toán rất nhanh trong hầu hết các trường hợp, 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 thêm độ trễ.

Ngay cả khi chúng tôi có số liệu thống kê chính xác về phân phối độ trễ chính xác, chúng vẫn có thể thay đổi theo thời gian khi các hệ thống và yêu cầu hệ thống thay đổi. Không phải lúc nào cũng rõ ràng về cách so sánh phân phối độ trễ giữa các hệ thống cạnh tranh. Ví dụ: hãy xem xét một hệ thống xác nhận các giao dịch có độ trễ phân bổ đồng đều trong khoảng từ 1 đến 2 phút (trung bình và trung bình 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% 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.

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ó cùng mức độ ưu tiên. Người dùng có thể trả nhiều tiền hơn để có mức độ ưu tiên bao gồm cao hơn, do đó, ngoài tất cả những điều trên, độ trễ còn phụ thuộc vào phí giao dịch đã thanh toán. Nói ngắn gọn:

Độ 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.

Thách thức của việc đo 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 phát sinh: "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 hay những gì nó có thể làm được 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 một 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ư tùy chọn xác minh đa giao dịch hoặc đa chữ ký của Bitcoin, 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í) toàn bộ công việc của 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 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 bất kỳ giao dịch nào trong số này 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 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. 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. Các lớp thực thi luôn phức tạp hơn.

Lớp thực thi đơn giản hơn, chẳng hạn như máy chủ tổng số 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. Tuy nhiên, ngay cả trong trường hợp này, số lượng đầu vào và đầu ra được trả sẽ khác nhau. Số lượng "bước nhảy" cần thiết cho giao dịch kênh thanh toán có thể khác nhau, điều này ảnh hưởng đến thông lượng. Thông lượng của máy chủ tổng số có thể phụ thuộc vào khoảng cách mà một lô giao dịch có thể được "chia nhỏ" 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ới 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á năng lực 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ế ở 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à 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ế (trái ngược với 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 chuỗi khối trở nên khó khăn hơn.

Tổng thể:

Yêu cầu 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, 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 sẽ đủ.

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

Độ trễ và thông lượng thường là một sự đánh đổi. Như Lefteris Kokoris-Kogias đã lưu ý, sự đánh đổi này thường không suôn sẻ, với độ trễ tăng lên đáng kể khi tải hệ thống đạt đến thông lượng tối đa.

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

Phí giao dịch

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à độ 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ỉ là họ 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í, những người khác quan tâm đến độ trễ). Nhìn chung, chi phí 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?
• Tổng thông lượng đạ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 so với 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 mức giá bù trừ thị trường (mặc dù có những tuyên bố rằng các công ty khai thác hoạt động như một tập đoàn để đẩy phí lên trên điểm này). Tất cả những yếu tố khác đều bằng nhau, thông lượng nhiều hơn sẽ dẫn đến phí thấp hơn, nhưng còn nhiều điều hơn thế nữa.

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

Tăng chi phí tấn công là một điều tốt, nhưng chúng tôi cũng không biết bảo mật bao nhiêu là "đủ". Hãy tưởng tượng bạn đang cân nhắc đến hai công viên giải trí. Một trong số họ tuyên bố chi ít hơn 50% cho việc bảo dưỡng xe so với người kia. Có phải là một ý tưởng tốt để đi đến công viên này? Có thể là chúng hiệu quả hơn và nhận được sự bảo mật tương tự với số tiền ít hơn. Có thể người kia đang chi tiêu nhiều hơn mức cần thiết để giữ cho chuyến đi được an toàn mà không mang lại lợi ích gì. Nhưng nó cũng có thể là công viên đầu tiên nguy hiểm. Các hệ thống chuỗi khối cũng tương tự như vậy. Sau khi thông lượng được tính vào, các chuỗi khối có phí thấp hơn sẽ có phí thấp hơn vì chúng thưởng (và do đó khuyến khích) ít trình xác thực hơn. Ngày nay, chúng ta không có cá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ổng thể:

So sánh 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.

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ó khăn. Đ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. Với một chiếc ô 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 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 sức kéo. Tất cả những điều này không dễ đánh giá. Ví dụ, tại Hoa Kỳ, Cơ quan Bảo vệ Môi trường cung cấp 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 trình bày cho người dùng tại các đại lý.

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