a16z: Nguyên tắc cơ bản để đánh giá hiệu suất blockchain

Viết bởi：Joseph Bonneau，thành viên nghiên cứu a16z crypto

Biên dịch: Amber, Foresight News

Cuộc thảo luận về hiệu suất và khả năng mở rộng là một trong những chủ đề lâu dài nhất trong toàn bộ thế giới tiền mã hóa.

Cuộc tranh luận về ưu nhược điểm và hiệu quả của các giải pháp lớp một và lớp hai vẫn đang diễn ra, nhưng do thiếu các chỉ số và tiêu chuẩn đánh giá chuẩn hóa, dữ liệu mà các bên đưa ra trong cuộc tranh luận thường thiếu tính nhất quán, điều này chắc chắn càng làm gia tăng sự khác biệt trong quan điểm.

Nói một cách đơn giản, chúng ta cần một phương pháp chi tiết và toàn diện hơn để so sánh hiệu suất, chẳng hạn như chúng ta cần phân chia hiệu suất thành nhiều chiều để so sánh riêng biệt và tìm ra một tiêu chuẩn tổng hợp. Trong bài viết này, tôi sẽ bắt đầu từ các thuật ngữ cơ bản, tóm tắt những thách thức mà thị trường hiện đang đối mặt, và mở rộng về một số nguyên tắc cơ bản cần ghi nhớ khi đánh giá hiệu suất của blockchain.

Khả năng mở rộng & Hiệu suất

Đầu tiên, hãy định nghĩa hai thuật ngữ, khả năng mở rộng và hiệu suất. Hai từ này có ý nghĩa chuẩn trong khoa học máy tính, nhưng thường bị lạm dụng trong môi trường blockchain. Hiệu suất thường được sử dụng để đo lường hiệu quả mà hệ thống có thể đạt được, các chỉ số hiệu suất có thể bao gồm số lượng quy trình có thể xử lý mỗi giây hoặc thời gian cần thiết dưới các yêu cầu cụ thể. Trong khi đó, khả năng mở rộng được sử dụng để đo lường khả năng của hệ thống trong việc cải thiện hiệu suất bằng cách thêm tài nguyên nhất định.

Tại sao chúng ta cần xác định rõ ràng điều này? Bởi vì thực tế là nhiều phương pháp cải thiện hiệu suất không thực sự cải thiện khả năng mở rộng. Một ví dụ đơn giản là việc sử dụng các phương pháp ký số hiệu quả hơn, chẳng hạn như chữ ký BLS, có kích thước khoảng một nửa so với chữ ký Schnorr hoặc ECDSA. Nếu Bitcoin chuyển từ ECDSA sang BLS, số lượng giao dịch mỗi khối có thể tăng 20-30%, từ đó cải thiện hiệu suất ngay lập tức. Nhưng chúng ta chỉ có thể làm điều này một lần - không có phương pháp 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 thêm không gian, nhưng đó cũng chỉ là một mẹo một lần nữa).

Thực tế, trong mạng lưới blockchain còn nhiều mẹo cải thiện khác cũng chỉ là một lần (chẳng hạn như SegWit), nhưng điều chúng ta thực sự cần là một kiến trúc có khả năng mở rộng để đạt được cải tiến hiệu suất liên tục, chỉ có như vậy chúng ta mới có thể liên tục cải thiện hiệu suất bằng cách thêm tài nguyên liên tục. Thực tế, trong thời đại Web2, đây đã là một phương pháp phổ biến, ví dụ như xây dựng máy chủ, mặc dù chúng ta có thể xây dựng một máy chủ đủ nhanh, nhưng cuối cùng thường cần nâng cấp thành kiến trúc nhiều máy chủ, trong đó cần phải liên tục thêm máy chủ mới để đáp ứng nhu cầu lưu trữ/xử lý dữ liệu ngày càng tăng.

Hiểu sự khác biệt này cũng giúp tránh những sai lầm hiển nhiên trong các tuyên bố như "một blockchain có khả năng mở rộng cao, nó có thể xử lý bao nhiêu giao dịch mỗi giây!" Mặc dù cách nói này có thể rất kích thích, nhưng thực tế số lượng giao dịch mà nó có thể xử lý là chỉ số hiệu suất chứ không phải chỉ số khả năng mở rộng.

Khả năng mở rộng về bản chất cần tận dụng tính song song. Trong lĩnh vực blockchain, mở rộng lớp một thường cần phân mảnh hoặc những thứ trông giống như phân mảnh. Khái niệm cơ bản của phân mảnh thực sự là chia trạng thái thành nhiều phần, để các xác thực viên khác nhau có thể xử lý độc lập một phần nào đó, và điều này rất phù hợp với định nghĩa về khả năng mở rộng. Tất nhiên, lớp hai còn nhiều tùy chọn hơn cho phép thêm xử lý song song, bao gồm các kênh ngoài chuỗi, Rollup và sidechain, v.v.

Độ trễ và thông lượng

Trong quá khứ, chúng ta thường quen với việc đánh giá hiệu suất của blockchain bằng hai chiều độ trễ và thông lượng: độ trễ có thể được sử dụng để đo lường tốc độ xác nhận của một giao dịch đơn lẻ, trong khi thông lượng được sử dụng để đo lường tổng số giao dịch có thể được xác nhận trong một khoảng thời gian cụ thể. Cách đo lường này áp dụng cho cả mạng lớp một và lớp hai, thậm chí còn hoàn toàn áp dụng cho các loại hệ thống máy tính khác ngoài blockchain.

Thật không may, cả hai chiều độ trễ và thông lượng thực sự đều khó đo lường và so sánh. Hơn nữa, một điểm rất quan trọng là, người dùng cá nhân thực sự không quan tâm đến thông lượng, họ chỉ quan tâm đến độ trễ và phí giao dịch. Phí giao dịch là một chiều quan trọng trong hệ thống blockchain, điều này không tồn tại trong lĩnh vực máy tính truyền thống.

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

Việc đo lường độ trễ có vẻ đơn giản: giao dịch mất bao lâu để được xác nhận? Nhưng vấn đề thực tế sẽ xuất hiện trong quá trình thực hiện. Đầu tiên, độ trễ mà chúng ta đo ở các thời điểm khác nhau thường không giống nhau, chúng ta thực sự bắt đầu tính từ khi người dùng nhấn nút gửi? Hay là khi nhiệm vụ đến bộ nhớ đệm? Và khi khối được xác nhận, liệu chúng ta có nên ngay lập tức dừng đồng hồ? Các chi tiết thao tác khác nhau sẽ mang lại các kết quả khác nhau.

Phương pháp phổ biến nhất là đo lường từ góc độ của xác thực viên, từ thời gian khách hàng lần đầu phát sóng giao dịch đến khi giao dịch được xác nhận hợp lý (theo một nghĩa nào đó, các thương gia trong thế giới thực sẽ xem xét việc nhận được thanh toán và phát hàng hóa). Tất nhiên, các thương gia khác nhau có thể áp dụng các tiêu chuẩn chấp nhận khác nhau, thậm chí một thương gia đơn lẻ cũng có thể áp dụng các tiêu chuẩn khác nhau tùy thuộc vào kích thước giao dịch.

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

Ngay cả khi chúng ta chuẩn hóa thời gian cửa sổ đo lường độ trễ, câu trả lời cuối cùng vẫn phụ thuộc vào tình huống. Chưa bao giờ có một hệ thống tiền mã hóa nào đảm bảo độ trễ giao dịch không đổi. Một quy tắc kinh nghiệm cơ bản cần nhớ là: độ trễ là một phân phối, chứ không phải là một con số.

Cộng đồng nghiên cứu mạng đã nhận thức được điều này từ lâu và chỉ ra rằng đuôi dài là rất quan trọng, ngay cả khi 0.1% quy trình gặp độ trễ cũng có thể ảnh hưởng nghiêm trọng đến trải nghiệm cuối cùng của người dùng.

Đối với blockchain, độ trễ xác nhận có thể khác nhau vì nhiều lý do:

Xử lý theo lô: Hầu hết các hệ thống xử lý giao dịch theo cách nào đó, điều này dẫn đến độ trễ biến đổi, vì một số giao dịch phải chờ cho hàng đợi xử lý theo lô được lấp đầy mới được xử lý. Các tham gia mạng có thể rất may mắn khi lên chuyến xe cuối cùng của lô này. Những giao dịch này sẽ được xác nhận ngay lập tức mà không có độ trễ bổ sung nào, nhưng những người đã vào hàng đợi trước đó sẽ phải chờ lâu hơn để được xác nhận.

Tắc nghẽn không chắc chắn: Hầu hết các hệ thống đều trải qua tình trạng tắc nghẽn, điều này có nghĩa là số lượng giao dịch được phát sóng vượt quá số lượng mà hệ thống có thể xử lý ngay lập tức. Khi giao dịch được phát sóng vào những thời điểm không thể dự đoán (thường được trừu tượng hóa thành quá trình Poisson), 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 phản ứng với các sự kiện bên ngoài, mức độ tắc nghẽn có thể khác nhau.

Sự khác biệt trong lớp đồng thuận: Trong lớp một, việc xác nhận giao dịch thường cần một nhóm các nút phân tán để đạt được sự đồng thuận về khối, điều này có thể làm tăng độ trễ biến đổi mà không bị ảnh hưởng bởi tắc nghẽn. Hệ thống chứng minh công việc phát hiện khối vào những thời điểm không thể dự đoán. Hệ thống chứng minh cổ phần cũng có thể làm tăng độ trễ theo nhiều cách khác nhau.

Vì những lý do này, một hướng dẫn tốt là: các tuyên bố về độ trễ nên được trình bày dưới dạng phân phối thời gian xác nhận, thay vì một con số đơn lẻ như trung bình hoặc trung vị.

Mặc dù các số liệu thống kê tổng hợp như trung bình, trung vị hoặc phần trăm cũng có thể chỉ ra một số quy luật, nhưng việc đánh giá chính xác hệ thống cần 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 cái nhìn tốt. Nhưng trong tiền mã hóa, tình huống lý tưởng này không thường xảy ra: thường thì thời gian xác nhận sẽ rất dài.

Mạng lưới kênh thanh toán (chẳng hạn như mạng Lightning) là một ví dụ rất tốt. Là một giải pháp mở rộng L2 cổ điển, các mạng này trong hầu hết các trường hợp cung cấp dịch vụ xác nhận thanh toán rất nhanh, nhưng đôi khi chúng cần phải thiết lập lại kênh, điều này có thể dẫn đến độ trễ tăng lên vài bậc.

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

Cuối cùng, cần lưu ý rằng, 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ột mức độ ưu tiên. Người dùng có thể trả nhiều phí hơn để có được mức độ ưu tiên bao gồm cao hơn, vì vậy ngoài tất cả những điều đã đề cập, độ trễ còn phụ thuộc vào phí giao dịch mà họ trả. Tóm lại: độ trễ rất phức tạp. Càng nhiều chi tiết trong các điều kiện tiên quyết càng tốt. Lý tưởng nhất là nên đo lường toàn bộ phân phối độ trễ dưới 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 (địa phương, mạng, xử lý theo lô, độ trễ đồng thuận) cũng rất hữu ích.

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

Thông lượng thoạt nhìn 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 thực tế, vấn đề cũng ẩn chứa dưới bề mặt. Điểm khó khăn chủ yếu nằm ở hai khía cạnh, thứ nhất là cái gì được coi là giao dịch, chúng ta đang đo lường những gì mà một hệ thống đã làm hôm nay? Hay chúng ta cần đo lường những gì nó có thể làm?

Mặc dù số lượng giao dịch mỗi giây (hoặc TPS) là tiêu chuẩn chung để đo lường hiệu suất của blockchain, nhưng việc sử dụng giao dịch làm đơn vị đo lường là 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 các tùy chọn xác thực giao dịch đa dạng của Bitcoin, một câu hỏi cơ bản là: không phải tất cả giao dịch đều bình đẳng.

Trong mạng Ethereum, giao dịch có thể chứa bất kỳ mã nào và 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 mà giao dịch đang thực hiện, nhưng điều này rất hạn chế trong môi trường thực thi EVM. Không có cách đơn giản nào để so sánh tổng khối lượng công việc hoàn thành của một tập hợp giao dịch EVM với một tập hợp giao dịch Solana sử dụng môi trường BPF. So sánh bất kỳ cái nào trong số này với một tập hợp giao dịch Bitcoin cũng không hợp lý.

Việc phân chia lớp giao dịch thành lớp đồng thuận và lớp thực thi của blockchain có thể làm rõ điều này hơn. Trong lớp đồng thuận (thuần túy), thông lượng có thể được đo lường bằng số byte được thêm vào chuỗi trong mỗi đơn vị thời gian. Trong khi lớp thực thi phức tạp hơn nhiều.

Lớp thực thi đơn giản hơn, chẳng hạn như máy chủ rollup chỉ hỗ trợ 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, số lượng đầu vào và đầu ra của giao dịch thanh toán cũng sẽ khác nhau. Số lượng tham số biến đổi cần thiết cho giao dịch kênh thanh toán có thể khác nhau, điều này sẽ ảnh hưởng đến thông lượng. Thông lượng của máy chủ rollup có thể phụ thuộc vào mức độ mà một lô giao dịch có thể "tóm tắt" thành một tập hợp các gói dữ liệu nhỏ hơn.

Một thách thức khác của thông lượng là vượt qua việc đo lường hiệu suất hiện tại để đánh giá công suất lý thuyết. Điều này đưa ra nhiều vấn đề mô hình để đánh giá công suất 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ế của lớp thực thi. Thứ hai, các hệ thống thực tế gần như chưa bao giờ đạt được công suất lý thuyết, đặc biệt là các hệ thống blockchain. Vì lý do tính ổn định, chúng ta muốn các nút thực hiện trong thực tế là đa dạng và khác biệt (chứ không phải tất cả các khách hàng đều chạy một triển khai phần mềm). Điều này làm cho việc mô phỏng chính xác thông lượng của blockchain trở nên khó khăn hơn.

Tóm lại, việc cân nhắc thông lượng cần giải thích cẩn thận khối lượng công việc giao dịch và số lượng xác thực viên. Trong khi không có tiêu chuẩn rõ ràng nào, chỉ có thể so sánh với lịch sử tải của mạng phổ biến như Ethereum.

Cân nhắc tổng hợp giữa độ trễ và thông lượng

Sau khi thống kê độ trễ và thông lượng, chúng ta cần thực hiện một sự cân nhắc tổng hợp giữa hai yếu tố này. Như Lefteris Kokoris-Kogias đã chỉ ra, sự cân nhắc này thường không suôn sẻ, khi tải của hệ thống gần đạt đến thông lượng tối đa của nó, độ trễ sẽ tăng vọt.

Hệ thống ZK Rollup cung cấp một ví dụ tự nhiên về sự cân nhắc giữa thông lượng/độ trễ. Giao dịch số lượng lớn làm tăng thời gian chứng minh, từ đó làm tăng độ trễ. Tuy nhiên, về kích thước chứng minh và chi phí xác thực, sức mạnh tính toán trên chuỗi sẽ nghiêng về các cụm giao dịch lớn hơn, từ đó tăng thông lượng.

Phí giao dịch

Có thể hiểu rằng, người dùng cuối quan tâm hơn đến sự cân nhắc giữa độ trễ và phí, thay vì độ trễ và thông lượng. Người dùng không cần phải quan tâm đến thông lượng, họ chỉ muốn xác nhận giao dịch nhanh chóng với phí thấp nhất có thể (một số người dùng quan tâm hơn đến phí, trong khi những người khác quan tâm hơn đến độ trễ). Tổng thể, phí chịu ảnh hưởng từ nhiều yếu tố:

• Nhu cầu thị trường lớn đến mức nào?

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

• Hệ thống này cung cấp bao nhiêu thu nhập cho các xác thực viên hoặc thợ mỏ?

• Trong số thu nhập này, có bao nhiêu là dựa trên phí giao dịch và phần thưởng lạm phát?

Nói một cách đơn giản, trong các điều kiện tương tự, thông lượng cao hơn nên dẫn đến phí thấp hơn. Tuy nhiên, điểm thứ 3 và thứ 4 được đề cập ở trên là những vấn đề cơ bản trong thiết kế hệ thống blockchain. Mặc dù đã có nhiều phân tích kinh tế về giao thức đồng thuận blockchain, nhưng chúng ta vẫn chưa đạt được một mô hình đồng thuận về việc xác thực viên cần bao nhiêu thu nhập. Hầu hết các hệ thống ngày nay đều dựa trên những suy đoán có cơ sở về việc cung cấp bao nhiêu thu nhập là đủ để khiến các xác thực viên hành động một cách trung thực mà không ảnh hưởng đến sức hấp dẫn của mạng đối với người dùng. Trong mô hình đơn giản hóa, chỉ cần làm cho chi phí khởi động cuộc tấn công 51% tỷ lệ thuận với phần thưởng của các xác thực viên.

Tăng chi phí tấn công là một điều tốt, nhưng chúng ta cũng không biết mức độ an toàn nào là "đủ". Hãy tưởng tượng rằng bạn đang xem xét đến hai công viên giải trí. Một trong số đó tuyên bố rằng chi phí bảo trì các trò chơi của nó thấp hơn 50% so với công viên còn lại. Liệu có phải là một ý tưởng tốt để đến công viên này không? Có thể là chúng có hiệu suất cao hơn và có thể đạt được mức độ an toàn tương đương với ít tiền hơn. Có thể công viên kia đã chi tiêu nhiều hơn mức cần thiết để giữ cho các thiết bị giải trí an toàn mà không mang lại lợi ích nào. Nhưng cũng có thể công viên đầu tiên rất nguy hiểm. Hệ thống blockchain cũng tương tự. Khi xem xét thông lượng, các blockchain có phí thấp hơn thường có phí thấp hơn vì chúng thưởng ít hơn. Hôm nay, chúng ta không có công cụ tốt để đánh giá đ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: so sánh phí giữa các hệ thống có thể gây ra một mức độ hiểu lầm nhất định. Mặc dù phí giao dịch rất quan trọng đối với người dùng, nhưng chúng cũng bị ảnh hưởng bởi nhiều yếu tố khác ngoài thiết kế hệ thống. Thông lượng là một chỉ số tốt hơn để phân tích toàn bộ hệ thống.

Kết luận

Đánh giá công bằng và chính xác về hiệu suất là rất khó khăn. Đo lường blockchain và đo lường một chiếc xe có đáng mua hay không cũng phức tạp như nhau, những người khác nhau sẽ quan tâm đến những điều khác nhau, đối với ô tô, một số người dùng sẽ quan tâm đến tốc độ tối đa hoặc thời gian tăng tốc 100 km, một số người khác quan tâm đến mức tiêu thụ nhiên liệu, trong khi một số người chỉ quan tâm đến việc chiếc xe có thể chở được bao nhiêu hàng. Chính vì lý do này, Cơ quan Bảo vệ Môi trường Hoa Kỳ thậm chí đã ban hành một hướng dẫn về tiêu chuẩn đánh giá ô tô.

Trong lĩnh vực blockchain, chúng ta vẫn chưa đến thời điểm có thể ban hành một tiêu chuẩn hóa. Đôi khi chúng ta có thể tìm thấy một khối lượng công việc tiêu chuẩn và từ đó vẽ ra "biểu đồ tiêu chuẩn" về thông lượng và phân phối độ trễ của mạng blockchain, nhưng hiện nay, đối với các nhà nghiên cứu và xây dựng, phương pháp tốt nhất chỉ là thu thập càng nhiều dữ liệu càng tốt và mô tả môi trường thử nghiệm một cách chi tiết trước khi đưa ra quan điểm, vì chỉ có như vậy chúng ta mới có thể có được một kết quả so sánh tương đối khách quan.