Solana Proof of History: Cách PoH hoạt động

Lưu ý về tính chính xác: Hiệu suất mạng, số lượng validator, phí, tính năng giao thức, hỗ trợ ví và các tích hợp của bên thứ ba thay đổi theo thời gian. Hãy coi các số liệu đã lỗi thời như các ảnh chụp nhanh lịch sử và xác minh tài liệu nguồn chính hiện tại.

Proof of History của Solana là một cơ chế sắp xếp thứ tự thời gian mật mã, không phải là một giao thức đồng thuận độc lập. Nó hoạt động cùng với Tower BFT và Proof of Stake để giúp các validator sắp xếp thứ tự các sự kiện và đồng ý về sổ cái.

Tuyên bố miễn trừ trách nhiệm: Bài viết này chỉ dành cho mục đích thông tin và giáo dục. Nó không cấu thành lời khuyên tài chính hoặc đầu tư. Đầu tư tiền điện tử tiềm ẩn rủi ro đáng kể, bao gồm cả khả năng mất vốn. Hãy tham khảo ý kiến cố vấn tài chính đủ điều kiện trước khi đưa ra quyết định đầu tư.

Mục lục

1. Proof of History là gì? Đồng hồ mật mã của Solana được giải thích
2. Cách Proof of History hoạt động: Chuỗi băm SHA-256 từng bước
3. Tại sao Proof of History có thể giảm tải sắp xếp thứ tự
4. Proof of History so với Proof of Work so với Proof of Stake: So sánh trực tiếp
5. Proof of History tương tác với Kiến trúc đầy đủ của Solana như thế nào
6. Hạn chế và Chỉ trích của Proof of History: Đánh giá trung thực
7. Các câu hỏi thường gặp về Proof of History và Solana
8. Kết luận: Proof of History có phải là một sự đổi mới thực sự không?

Proof of History của Solana là gì?

Proof of History (PoH) là một cơ chế ghi nhận thời gian mật mã được tích hợp vào blockchain Solana, tạo ra một bản ghi có thể xác minh về thứ tự và thời gian của các sự kiện, mà không yêu cầu các validator phải liên tục giao tiếp với nhau để xác định thời điểm xảy ra một sự kiện.

Một blockchain là một sổ lệnh phân tán, nơi các bản ghi được liên kết bằng mật mã và duy trì trên một mạng lưới người tham gia mà không có cơ quan trung ương. Trên bất kỳ blockchain phân tán nào, các node phải đồng ý về hai điều trước khi xác nhận một giao dịch: điều gì đã xảy ra và khi nào nó xảy ra. Hầu hết các mạng lưới dành nỗ lực tính toán đáng kể cho câu hỏi thứ hai. Proof of History trả lời câu hỏi này bằng mật mã, để mạng lưới có thể tập trung toàn bộ băng thông của mình vào câu hỏi đầu tiên.

Một điểm phân biệt quan trọng cần làm rõ ngay lập tức: Proof of History không phải là một cơ chế đồng thuận. Cơ chế đồng thuận thực tế của Solana là Tower BFT. PoH là lớp ghi nhận thời gian mà Tower BFT phụ thuộc vào để hoạt động hiệu quả. Nhầm lẫn hai khái niệm này là lỗi phổ biến nhất trong các bài viết về công nghệ của Solana, và bài viết này sẽ sửa chữa nó xuyên suốt.

Proof of History được phát minh bởi Anatoly Yakovenko, đồng sáng lập của Solana Labs và trước đây là kỹ sư cấp cao tại Qualcomm. Ông đã giới thiệu khái niệm này trong một whitepaper năm 2017 có tựa đề Solana: A new architecture for a high performance blockchain. Mainnet beta của Solana đã ra mắt vào tháng 3 năm 2020, được xây dựng dựa trên kiến trúc mà whitepaper đó mô tả.

Solana là một blockchain Layer 1 hiệu suất cao có token gốc là SOL. Trần thông lượng lý thuyết của nó, được hỗ trợ bởi Proof of History hoạt động cùng với nhiều cải tiến kiến trúc khác, là một con số lý thuyết lịch sử khoảng 65.000 giao dịch mỗi giây (TPS). Thông lượng bền vững thực tế trong điều kiện mạng điển hình thấp hơn đáng kể, một điểm khác biệt mà bài viết này đề cập chi tiết.

Nếu bạn đã từng nghe Proof of History được mô tả là "giống như Proof of Stake" hoặc cho rằng đó là cơ chế đồng thuận của Solana, cả hai cách diễn đạt này đều không chính xác. So sánh đầy đủ và mối quan hệ chính xác giữa các cơ chế này sẽ xuất hiện trong các phần dưới đây.

Cách Proof of History hoạt động: Chuỗi băm SHA-256 từng bước

Phép loại suy về đồng hồ mật mã nắm bắt được những gì PoH làm, nhưng để hiểu tại sao các nhà đầu tư và nhà phát triển coi nó là một cải tiến kiến trúc thực sự, bạn cần xem cách đồng hồ thực sự chạy.

Hàm băm mật mã là gì? (Khối xây dựng cơ bản)

Một hàm băm mật mã nhận bất kỳ đầu vào nào (một từ, một tài liệu, một bản ghi giao dịch) và tạo ra một đầu ra có độ dài cố định, duy nhất cho đầu vào đó và có tính xác định. Nó cũng gần như không thể đảo ngược: biết đầu ra không cho bạn thông tin hữu ích nào về những gì đã được đưa vào. Đầu ra được gọi là giá trị băm, và nó hoạt động như một dấu vân tay duy nhất cho bất kỳ dữ liệu nào tạo ra nó.

Thay đổi một ký tự của đầu vào, và đầu ra sẽ thay đổi hoàn toàn và khó đoán. Sự nhạy cảm với đầu vào này chính xác là lý do tại sao việc băm tuần tự lại là cơ sở đáng tin cậy để ghi nhận thời gian.

Hàm băm cụ thể mà Proof of History sử dụng là SHA-256 (Secure Hash Algorithm, 256-bit), cùng thuật toán bảo mật các giao dịch Bitcoin. SHA-256 đòi hỏi nhiều tính toán để chạy nhưng lại cực kỳ nhanh để xác minh. Sự bất đối xứng này là trung tâm: tạo ra một giá trị băm thì chậm, nhưng kiểm tra một giá trị băm thì tức thì. Đặc tính đó chính xác là lý do tại sao SHA-256 phù hợp với chức năng ghi nhận thời gian của PoH.

Chuỗi băm: PoH mã hóa thời gian bằng mật mã như thế nào

PoH hoạt động bằng cách chạy SHA-256 theo một chuỗi liên tục, trong đó mỗi đầu ra trở thành đầu vào cho phép tính tiếp theo. Bởi vì mỗi bước yêu cầu thời gian tính toán thực tế, không thể bỏ qua, chuỗi đầu ra tạo thành một bản ghi có thể xác minh về thời gian trôi qua. Không ai có thể giả mạo việc đạt đến bước 500.000 mà không thực sự tính toán các bước từ 1 đến 499.999.

Hãy coi nó như một chiếc đồng hồ bấm giờ mật mã. Mỗi lần tích tắc của đồng hồ là một đầu ra SHA-256 được ghi lại, và chuỗi các lần tích tắc chứng minh rằng một lượng tính toán cụ thể, và do đó một lượng thời gian đo được, đã trôi qua giữa các sự kiện.

Đây là cách chuỗi hoạt động:

1. Validator dẫn đầu bắt đầu chuỗi. Một validator được chỉ định (là "leader" cho slot đó) chạy SHA-256 trên một đầu vào ban đầu, có thể là bất kỳ giá trị tùy ý nào hoặc giá trị băm của block trước đó.
2. Mỗi đầu ra trở thành đầu vào tiếp theo. Giá trị băm kết quả được đưa trở lại vào SHA-256 làm đầu vào mới. Đây là chuỗi. Mỗi liên kết phụ thuộc hoàn toàn vào liên kết trước đó.
3. Một bộ đếm tuần tự theo dõi vị trí. Mỗi lần lặp lại mang theo một số đếm: băm #1, băm #2, băm #347.891. Bộ đếm này là số lần tích tắc của đồng hồ.
4. Các giao dịch được nhúng vào chuỗi khi chúng đến. Khi một giao dịch vào mạng, leader sẽ băm nó vào chuỗi tại thời điểm chính xác đó. Dữ liệu giao dịch được tích hợp vào đầu ra băm tại vị trí đếm cụ thể đó.
5. Vị trí được nhúng chứng minh thời gian của giao dịch. Một giao dịch được băm tại vị trí 347.891 rõ ràng đã xảy ra sau vị trí 347.890 và trước vị trí 347.892. Không cần dấu thời gian bên ngoài. Bản thân chuỗi là bằng chứng.
6. Các validator khác xác minh chuỗi. Việc xác minh nhanh chóng vì việc kiểm tra một giá trị băm mất một phần nhỏ thời gian so với việc tạo ra nó. Một validator có thể xác nhận toàn bộ chuỗi là hợp lệ mà không cần chạy lại mọi phép tính.
7. Chuỗi kết quả là một dòng thời gian chống giả mạo. Việc thay đổi bất kỳ giá trị băm nào ở bất kỳ vị trí nào sẽ làm mất hiệu lực mọi giá trị băm theo sau nó, khiến bản ghi không thể bị làm giả mà không phải thực hiện lại tất cả công việc tiếp theo.

Phép loại suy về ảnh chụp nhanh chóng nắm bắt được thuộc tính chống giả mạo. Hãy tưởng tượng chụp ảnh mỗi giây, trong đó mỗi bức ảnh bao gồm bức ảnh trước đó trong khung hình. Bất kỳ ai nhìn vào ảnh #1.000 đều có thể xác minh chuỗi mà không cần có mặt trong mỗi lần chụp, vì mỗi hình ảnh được lồng vào nhau bằng mật mã trong hình ảnh tiếp theo. Việc thay đổi ảnh #400 sẽ làm hỏng rõ ràng mọi hình ảnh tiếp theo.

Chuỗi băm tuần tự này là cái mà các nhà mật mã học gọi là tương tự về chức năng với Hàm Trì hoãn Có thể Xác minh (VDF). Một VDF được định nghĩa chính thức, như mô tả bởi Boneh, Bonneau, Bünz và Fisch trong bài báo năm 2018 của họ được xuất bản tại CRYPTO (IACR ePrint 2018/601), là một hàm yêu cầu một lượng thời gian nhất định để tính toán, không thể song song hóa để tăng tốc độ tính toán đó và tạo ra một bằng chứng cho phép xác minh nhanh chóng. PoH đạt được hiệu quả thực tế tương tự thông qua băm SHA-256 tuần tự. Nó không chính thức là một VDF theo nghĩa lý thuyết độ phức tạp chặt chẽ, nhưng sự tương đồng về chức năng là chính xác. Các nhà nghiên cứu học thuật mô tả PoH là "giống VDF" hoặc "một VDF không chính thức" đang sử dụng cách diễn đạt chính xác.

Nguồn: Anatoly Yakovenko, "Solana: A new architecture for a high performance blockchain," 2017. Có sẵn tại solana.com/solana-whitepaper.pdf

Chuỗi dấu thời gian mật mã này cho phép lớp đồng thuận của Solana, Tower BFT, bỏ qua các vòng giao tiếp làm chậm các Blockchain khác, vì thời gian đã được chứng minh.

Tại sao Proof of History của Solana có thể giảm Chi phí Sắp xếp Thứ tự

Nguồn trích dẫn các phạm vi thông lượng lý thuyết và quan sát được trong lịch sử, nhưng Proof of History một mình không tạo ra số liệu TPS. Sự kết hợp giao dịch, lưu lượng bỏ phiếu, lập lịch thời gian chạy, phần cứng validator, mạng lưới, tắc nghẽn và phương pháp đo lường đều ảnh hưởng đến thông lượng được báo cáo. Sử dụng các phép đo trực tiếp theo thời gian cho các quyết định vận hành.

So sánh với Visa, Ethereum hoặc Bitcoin không giống nhau: chúng đếm các sự kiện khác nhau và sử dụng các mô hình tin cậy, quyết toán và cuối cùng khác nhau. PoH là một phần trong thiết kế của Solana, cùng với Sealevel, Turbine, Gulf Stream, thị trường phí và cơ sở hạ tầng validator.

Tower BFT Sử dụng PoH như thế nào để Bỏ qua các Vòng Giao tiếp

Tăng tốc độ từ PoH không phải là về việc băm nhanh hơn. Đó là về việc loại bỏ toàn bộ một loại giao tiếp mà các cơ chế đồng thuận truyền thống yêu cầu.

Các hệ thống phân tán phải chịu lỗi Byzantine (những người tham gia bị lỗi hoặc độc hại) cần Khả năng Chịu lỗi Byzantine (BFT): khả năng đạt được sự đồng thuận ngay cả khi một số validator ngoại tuyến, gửi thông tin sai lệch hoặc hành xử thù địch, miễn là ít hơn một phần ba số validator bị xâm phạm.

Định nghĩa chính: Khả năng Chịu lỗi Byzantine (BFT) đề cập đến khả năng của một hệ thống phân tán tiếp tục hoạt động chính xác ngay cả khi một số người tham gia gặp lỗi hoặc hành động độc hại. Khái niệm này bắt nguồn từ Bài toán các Tướng lĩnh Byzantine, một thử nghiệm tư duy khoa học máy tính cổ điển của Lamport, Shostak và Pease (1982).

Trong các hệ thống đồng thuận BFT truyền thống, các validator phải trao đổi tin nhắn để đồng ý về hai điều trước khi xác nhận một giao dịch: điều gì đã xảy ra và thời điểm xảy ra. Việc đồng ý về thời gian thường yêu cầu nhiều vòng trao đổi tin nhắn qua mạng. Khi số lượng validator tăng lên, chi phí giao tiếp này tăng theo cấp số nhân, làm cho việc đạt được sự đồng thuận nhanh chóng ngày càng tốn kém.

PoH cung cấp một tham chiếu sắp xếp có thể xác minh để giảm bớt một số phối hợp thời gian. Nó không loại bỏ giao tiếp đồng thuận hoặc làm cho một khe (slot) tương đương với cuối cùng về mặt kinh tế. Xác nhận lạc quan, xác nhận gốc và quyết toán ở cấp ứng dụng sử dụng các ngưỡng và thời gian khác nhau.

Sealevel và Gulf Stream: Tốc độ Vượt qua Đồng hồ

PoH một mình không tạo ra 65.000 TPS. Nó là lớp nền tảng làm cho các đổi mới hiệu suất khác của Solana có thể thực hiện được.

Sealevel là môi trường thực thi Hợp đồng Thông minh song song của Solana. Hợp đồng Thông minh là các chương trình được lưu trữ trên một Blockchain và được gọi thông qua các giao dịch. Nơi EVM của Ethereum xử lý các giao dịch tuần tự, Sealevel có thể chạy các giao dịch không xung đột trên nhiều lõi xử lý. Tính song song này đến từ các tài khoản mà mỗi giao dịch khai báo nó sẽ đọc hoặc ghi; PoH cung cấp một tham chiếu sắp xếp nhưng không xác định tài khoản nào là độc lập.

Gulf Stream là giao thức chuyển tiếp giao dịch không có mempool của Solana. Thay vì giữ các giao dịch chưa được xác nhận trong một hàng đợi chờ, Gulf Stream đẩy các giao dịch về phía validator lãnh đạo tiếp theo dự kiến trước khi khối hiện tại hoàn tất, sử dụng lịch trình lãnh đạo của PoH để biết ai là người tiếp theo. Turbine, giao thức truyền bá khối của Solana lấy cảm hứng từ BitTorrent, sau đó chia các khối đã xác nhận thành các gói nhỏ hơn và phân phối chúng một cách hiệu quả trên mạng lưới validator.

PoH là nền tảng. Sealevel và Gulf Stream xây dựng trực tiếp trên đó, và Turbine cũng vậy. Con số 65.000 TPS phản ánh tất cả các đổi mới này hoạt động cùng nhau, với PoH là lớp sắp xếp mà mỗi lớp phụ thuộc vào.

DeFi các ứng dụng, bao gồm sàn giao dịch phi tập trung và các giao thức cho vay, yêu cầu thông lượng giao dịch cao để hoạt động ở quy mô lớn. Kiến trúc được kích hoạt PoH của Solana cho phép các ứng dụng này xử lý hàng nghìn thao tác mỗi giây ở lớp cơ sở, một năng lực mà hầu hết các Blockchain Layer 1 hiện tại không đạt được, mặc dù các giải pháp Layer 2 trên các chuỗi khác đang thu hẹp khoảng cách này cho các trường hợp sử dụng cụ thể.

Để hiểu tại sao kiến trúc này lại quan trọng, việc so sánh trực tiếp PoH với các cơ chế đồng thuận mà nó được thiết kế để hoạt động cùng sẽ hữu ích.

Proof of History so với Proof of Work so với Proof of Stake: So sánh Trực tiếp

Điểm cấu trúc quan trọng nhất trước khi so sánh này: Proof of History không phải là một cơ chế đồng thuận. Proof of Work và Proof of Stake là các cơ chế đồng thuận. So sánh PoH trực tiếp với PoW hoặc PoS giống như so sánh một chiếc đồng hồ với một hệ thống bỏ phiếu. Chúng giải quyết các vấn đề khác nhau và sự khác biệt đó định hình mọi thứ khác trong bảng này.

Lưu ý: TPS lý thuyết của Solana đại diện cho tổng sản lượng của PoH, Sealevel, Turbine và Gulf Stream trong điều kiện tối ưu. Con số này không thường xuyên đạt được trong hoạt động thực tế.

PoH so với Proof of Work: Tốc độ và Năng lượng

Proof of Work của Bitcoin và Proof of History của Solana giải quyết các vấn đề khác nhau, nhưng sự tương phản giữa chúng về thông lượng và năng lượng là rất rõ rệt. Trong PoW, các thợ đào cạnh tranh để giải một câu đố tính toán chuyên sâu. Người chiến thắng thêm khối tiếp theo và nhận phần thưởng. Cuộc cạnh tranh này tốn kém có chủ đích, vì chi phí năng lượng làm cho việc đảo ngược chuỗi trở nên cực kỳ tốn kém. Bitcoin xử lý khoảng 7 TPS như một kết quả trực tiếp của thiết kế này.

PoH không thay thế mô hình bảo mật của PoW. Nó giải quyết một vấn đề khác, vấn đề sắp xếp thời gian, với ít lãng phí tính toán hơn nhiều. Chỉ có một validator (lãnh đạo hiện tại) tạo ra chuỗi PoH thay vì mọi thợ đào cạnh tranh đồng thời.

SHA-256 cũng được sử dụng trong quá trình khai thác của Bitcoin, nhưng ứng dụng có sự khác biệt cơ bản. Thợ đào Bitcoin tìm kiếm một hàm băm có các thuộc tính cụ thể trong một cuộc đua cạnh tranh. PoH của Solana chạy SHA-256 tuần tự để tạo ra một bản ghi thời gian, chứ không phải để cạnh tranh vì bất cứ điều gì.

PoH vs. Bằng chứng về Stake: Không giống nhau

Không, Bằng chứng Lịch sử không giống với Bằng chứng về Stake. Solana không sử dụng PoH thay cho PoS. Nó sử dụng cả hai đồng thời, cho các mục đích khác nhau.

Bằng chứng về Stake là một cơ chế đồng thuận, trong đó các validator được chọn để tạo khối dựa trên lượng tiền điện tử mà họ đã đặt cược làm tài sản thế chấp. Ethereum đã chuyển sang Bằng chứng về Stake vào tháng 9 năm 2022 với bản nâng cấp Merge. PoS của Ethereum xử lý khoảng 15 đến 30 TPS trên lớp cơ sở của nó, với các giải pháp Layer 2 như Arbitrum và Optimism mở rộng thông lượng hiệu quả vượt xa con số đó.

Solana sử dụng hệ thống dựa trên PoS để lựa chọn validator, quyết định ai sẽ trở thành người dẫn đầu chịu trách nhiệm tạo ra chuỗi PoH cho một khe (slot) nhất định. PoH sau đó cung cấp thứ tự thời gian mà Tower BFT sử dụng để đạt được sự đồng thuận. Hai cơ chế này bổ sung cho nhau, không cạnh tranh. PoH là đồng hồ; PoS quyết định ai lên dây cót cho nó.

Cách Bằng chứng Lịch sử tương tác với Kiến trúc Toàn diện của Solana

Đối với các nhà phát triển đánh giá Solana như một nền tảng, câu hỏi không chỉ là PoH làm gì một cách cô lập. Đó là cách PoH phù hợp với toàn bộ kiến trúc tám đổi mới mà Anatoly Yakovenko đã mô tả trong Whitepaper năm 2017 của ông, và kiến trúc đó yêu cầu gì từ phần cứng chạy nó.

Tower BFT: Sử dụng Bản ghi PoH làm Đồng hồ bỏ phiếu

Tower BFT sử dụng bản ghi thời gian có thể xác minh của PoH để triển khai một cơ chế khóa phiếu bầu mà sẽ không thể thực hiện được nếu không có chuỗi các khe (slot) được chia sẻ, đáng tin cậy.

Đây là cách nó hoạt động trong thực tế. Các validator trên Solana bỏ phiếu cho các khối mà họ tin là hợp lệ. Mỗi phiếu bầu được liên kết với một số khe PoH cụ thể. Tower BFT thực thi quy tắc khóa: một khi validator đã bỏ phiếu cho một khe, họ không thể bỏ phiếu cho một fork xung đột trong một số khe tiếp theo tăng theo cấp số nhân. Khóa càng lâu, validator càng có nhiều SOL đã stake mà họ có nguy cơ mất (bị slashing) nếu cố gắng bỏ phiếu cho cả hai phía của một fork.

Tower BFT có thể thực thi các khóa dựa trên thời gian này chính xác vì PoH cung cấp một chuỗi các khe được chia sẻ, có thể xác minh. Nếu không có PoH, sẽ không có tham chiếu chung đáng tin cậy cho "khe 347.891 diễn ra trước khe 347.892". Việc khóa phiếu bầu dựa trên thời gian đòi hỏi một đồng hồ đáng tin cậy. PoH chính là đồng hồ đó.

Lịch trình người dẫn đầu được xác định trước bằng cách sử dụng trọng số SOL đã stake. Các validator biết nút nào dự kiến sẽ tạo ra luồng PoH và đề xuất một khối cho mỗi khe sắp tới. Khả năng dự đoán này cho phép chuyển tiếp có nhận biết người dẫn đầu trước khi khối hiện tại được hoàn tất, giảm sự phụ thuộc vào mempool toàn cầu thông thường mà không loại bỏ tình trạng tắc nghẽn, lỗi giao dịch, phí ưu tiên hoặc rủi ro MEV.

BFT trong ngữ cảnh của Tower BFT có nghĩa là mạng có thể chịu được tới một phần ba các validator hành động độc hại hoặc lỗi, đồng thời vẫn đạt được sự đồng thuận. Cấu trúc khóa theo cấp số nhân đảm bảo rằng việc tấn công mạng thông qua thao túng phiếu bầu trở nên đắt đỏ hơn theo cấp số nhân khi thời gian khóa tăng lên.

Sealevel: Cách Sắp xếp Giao dịch của PoH cho phép Xử lý song song

Hầu hết các blockchain xử lý giao dịch tuần tự, từng giao dịch một, vì nếu không có thứ tự đã xác minh, chúng không thể xác định an toàn giao dịch nào có thể chạy đồng thời mà không xung đột. Nếu hai giao dịch cùng cố gắng sửa đổi cùng một số dư tài khoản, việc xử lý chúng song song mà không biết thứ tự của chúng có nguy cơ dẫn đến kết quả chi tiêu gấp đôi.

Sealevel giải quyết vấn đề này bằng cách đọc hàng đợi giao dịch đã xác minh của PoH và phân tích các tập hợp tài khoản đọc và ghi đã khai báo của mỗi giao dịch. Vì mọi giao dịch Solana phải chỉ định các tài khoản mà nó đọc và ghi vào, Sealevel có thể xác định tại thời điểm gửi giao dịch nào là độc lập. Các giao dịch độc lập (những giao dịch chạm vào các tài khoản hoàn toàn khác nhau) có thể thực thi đồng thời trên nhiều lõi bộ xử lý hoặc luồng GPU. Các giao dịch phụ thuộc lẫn nhau thực thi tuần tự theo thứ tự PoH đã xác minh của chúng.

Vai trò của PoH là cung cấp hàng đợi giao dịch được sắp xếp, có dấu thời gian mà Sealevel tiêu thụ. Nếu không có thứ tự đã xác minh mà PoH tạo ra, việc thực thi song song sẽ đòi hỏi chi phí điều phối tốn kém để ngăn chặn xung đột. Solana gọi các chương trình trên chuỗi của mình là "chương trình" thay vì hợp đồng thông minh trong tài liệu gốc của nó, phản ánh sự khác biệt về kiến trúc so với mô hình thực thi của Ethereum, mặc dù thuật ngữ "hợp đồng thông minh" được hiểu rộng rãi và sử dụng trên toàn ngành.

Gulf Stream sử dụng lịch trình người dẫn đầu của PoH để đẩy các giao dịch chưa xác nhận trực tiếp đến các validator dẫn đầu sắp tới, và Turbine sử dụng các khối được sắp xếp theo PoH làm cơ sở cho cây lan truyền khối theo kiểu BitTorrent của nó. Mọi thành phần hiệu suất chính trong kiến trúc của Solana đều phụ thuộc vào PoH làm nền tảng sắp xếp của nó.

Sự chặt chẽ về kiến trúc này cũng là nguồn gốc của một số chỉ trích đáng kể nhất của PoH, đặc biệt là các yêu cầu về phần cứng mà nó đặt ra cho các validator.

Hạn chế và Chỉ trích về Bằng chứng Lịch sử: Một Đánh giá Trung thực

Bằng chứng Lịch sử mang lại những đánh đổi kiến trúc thực sự, và hệ quả nhất trong số đó là yêu cầu phần cứng mà nó đặt ra cho các validator chạy nó.

Việc chạy một validator Solana yêu cầu phần cứng máy chủ cao cấp: CPU có nhiều lõi, tối thiểu 128GB RAM, SSD NVMe và kết nối mạng đa gigabit. Tài liệu của Solana khuyến nghị các thông số kỹ thuật phần cứng có chi phí từ 5.000 đến 20.000 đô la trở lên để lắp ráp và vận hành.

Rào cản chi phí này hạn chế sự tham gia vào tập hợp các validator đối với các nhà điều hành có nguồn lực tốt. Một node đầy đủ Bitcoin có thể chạy trên Raspberry Pi với chi phí dưới 100 đô la. Validator Solana thì không thể. Kết quả là áp lực tập trung hóa: chi phí tham gia càng cao, nhóm các validator tiềm năng càng nhỏ và sức mạnh đồng thuận của mạng càng tập trung vào các nhà điều hành tổ chức được tài trợ tốt.

Áp lực tập trung hóa là cách diễn đạt chính xác ở đây, chứ không phải tập trung hóa đã hoàn thành. Solana đã duy trì khoảng 1.500 đến 2.000 validator hoạt động, thấp hơn tập hợp validator của Ethereum với vài trăm nghìn validator, mặc dù ngưỡng phần cứng thấp hơn của Ethereum liên quan đến các yêu cầu kinh tế khác nhau (yêu cầu 32 ETH để stake). Quỹ Solana đã triển khai các chương trình ủy quyền stake để hỗ trợ các validator nhỏ hơn, nhưng yêu cầu phần cứng cơ bản do nhu cầu thông lượng của PoH thúc đẩy vẫn mang tính cấu trúc, không phải ngẫu nhiên.

Sự đánh đổi là có chủ đích: kiến trúc của Yakovenko ưu tiên thông lượng hơn khả năng tiếp cận, chấp nhận áp lực tập trung hóa như một cái giá của hiệu suất. Liệu sự đánh đổi đó có chấp nhận được hay không phụ thuộc vào điều mà người đánh giá coi trọng nhất.

Sự cố mạng: Bằng chứng Lịch sử có phải là nguyên nhân?

Bản thân Bằng chứng Lịch sử không phải là nguyên nhân gây ra các sự cố mạng lớn của Solana. Các sự cố bắt nguồn từ các đợt lũ giao dịch spam làm quá tải khả năng tính toán của mạng và từ các lỗi trong phần mềm client của validator.

Các sự cố đã được ghi nhận là cụ thể. Vào tháng 9 năm 2021, mạng Solana đã trải qua một đợt ngừng hoạt động kéo dài 17 giờ do một loạt giao dịch do Bot tạo ra trong đợt chào bán Raydium initial DEX. Khối lượng giao dịch spam đã làm quá tải bộ nhớ của validator, khiến các validator bị lỗi và mạng ngừng hoạt động cho đến khi có thể tổ chức khởi động lại phối hợp. Các sự cố mạng bổ sung đã xảy ra vào tháng 1 năm 2022 và tháng 5 năm 2022, mỗi lần là do sự kết hợp của các cuộc tấn công spam và lỗi phần mềm validator chứ không phải do sự cố trong chính cơ chế PoH.

Kết nối kiến trúc trung thực là thế này: thiết kế của PoH ưu tiên thông lượng hơn quản lý tài nguyên thận trọng, điều đó có nghĩa là mạng không có cơ chế giới hạn tốc độ tích hợp sẵn hoặc ngăn chặn spam dựa trên phí vào thời điểm xảy ra các sự cố ngừng hoạt động đó. Một mạng được thiết kế cho 65.000 TPS phải xử lý lượng lưu lượng truy cập đến tương đương 65.000 TPS, bao gồm cả lưu lượng truy cập độc hại. Các kiến trúc thận trọng hơn, bằng cách hạn chế thông lượng, cũng hạn chế bề mặt tấn công.

Sau năm 2022, Solana đã triển khai nhiều biện pháp kỹ thuật: giao thức mạng QUIC để tiếp nhận giao dịch linh hoạt hơn, thị trường phí giao dịch để làm cho spam trở nên tốn kém về mặt kinh tế, và chất lượng dịch vụ có trọng số theo cổ phần để ưu tiên các giao dịch từ các validator có lượng stake có ý nghĩa. Những biện pháp này đã cải thiện đáng kể độ ổn định của mạng.

Lịch sử ngừng hoạt động phản ánh sự chưa trưởng thành về kỹ thuật trong một hệ thống hiệu suất cao, chứ không phải là một lỗi trong bản thân khái niệm Lịch sử Bằng chứng (Proof of History), mặc dù hai yếu tố này có kết nối về mặt kiến trúc. Các nhà đầu tư và nhà phát triển đánh giá Solana nên hiểu rõ sự khác biệt này.

Sự phụ thuộc vào đồng bộ hóa đồng hồ

Chuỗi băm tuần tự của PoH phụ thuộc vào việc các validator duy trì đồng hồ cục bộ đủ chính xác. Độ lệch đồng hồ đáng kể giữa các validator có thể tạo ra sự không nhất quán về thời gian slot, nơi các validator không đồng ý về việc đầu ra băm nhất định thuộc về slot nào.

Trong thực tế, điều này được quản lý thông qua đồng bộ hóa NTP (Giao thức Thời gian Mạng) tiêu chuẩn, và độ lệch đồng hồ chưa từng là nguồn gây ra lỗi thực tế đáng kể. Nó đại diện cho một bề mặt tấn công lý thuyết: một kẻ tấn công tinh vi có thể thao túng các tín hiệu thời gian đến một số lượng đáng kể các validator có thể phá vỡ việc phân bổ slot. Điều này được thừa nhận là một yếu tố thiết kế thay vì một lỗ hổng nghiêm trọng trong mô hình đe dọa hiện tại.

Câu hỏi thường gặp về Lịch sử Bằng chứng của Solana

Các câu trả lời sau đây giải quyết những câu hỏi phổ biến nhất về Lịch sử Bằng chứng, được rút ra từ các mẫu tìm kiếm phản ánh những gì nhà đầu tư, nhà phát triển, nhà nghiên cứu và những người hoài nghi thường xuyên hỏi nhất.

Mục đích của Lịch sử Bằng chứng trong Solana là gì?

Lịch sử Bằng chứng tạo ra một bản ghi thời gian mật mã cho phép các validator của Solana đồng ý về thứ tự và thời gian của các giao dịch mà không cần trao đổi tin nhắn đóng dấu thời gian với nhau. Bằng cách giải quyết câu hỏi "khi nào điều này xảy ra" bằng mật mã, PoH giúp Tower BFT tập trung hoàn toàn vào câu hỏi "điều này có hợp lệ không", giảm tải cho cơ chế đồng thuận và cho phép Solana đạt thông lượng giao dịch cao.

Không. Lịch sử Bằng chứng là một cơ chế theo dõi thời gian; Cơ chế đồng thuận (Consensus Mechanism) dùng để chọn validator nào sẽ đề xuất các khối. Chúng giải quyết các vấn đề khác nhau. Solana sử dụng cả hai đồng thời: PoH cung cấp chuỗi thời gian có thể xác minh để sắp xếp thứ tự giao dịch, trong khi một hệ thống dựa trên PoS xác định validator nào sản xuất luồng PoH cho mỗi slot. Việc nhầm lẫn hai khái niệm này là phổ biến trong các bài viết chất lượng thấp về Solana, nhưng chúng là các thành phần kiến trúc riêng biệt.

Anatoly Yakovenko, đồng sáng lập và CEO của Solana Labs, đã giới thiệu Lịch sử Bằng chứng trong một Whitepaper năm 2017 có tựa đề Solana: Một kiến trúc mới cho blockchain hiệu suất cao. Trước khi thành lập Solana Labs, Yakovenko là kỹ sư trưởng cấp cao tại Qualcomm, nơi ông làm việc về hệ điều hành phân tán và thuật toán nén. Mainnet beta của Solana đã ra mắt vào tháng 3 năm 2020.

Thông lượng lý thuyết của Solana là con số lý thuyết trong lịch sử khoảng 65.000 giao dịch mỗi giây trong điều kiện tối ưu; thông lượng quan sát thực tế thường dao động từ 2.000 đến 4.000 TPS. Lớp cơ sở của Ethereum xử lý khoảng 15 đến 30 TPS, với các giải pháp Top mở rộng đáng kể thông lượng hiệu quả. Lợi thế tốc độ lớp cơ sở của Solana là có cấu trúc, được thúc đẩy bởi việc sắp xếp thời gian của PoH cho phép thực thi song song và giảm tải cho cơ chế đồng thuận.

Ba hạn chế chính được ghi nhận là: yêu cầu phần cứng validator cao (RAM 128GB+, SSD NVMe, mạng đa gigabit, chi phí phần cứng từ 5.000 đến 20.000 USD+) tạo áp lực tập trung hóa bằng cách loại trừ những người tham gia có ít tài nguyên hơn; các vấn đề về độ tin cậy của mạng trong lịch sử, bao gồm sự cố ngừng hoạt động 17 giờ vào tháng 9 năm 2021 và nhiều lần tạm dừng mạng vào năm 2022 do các cuộc tấn công spam và lỗi client validator; và sự phụ thuộc vào đồng bộ hóa đồng hồ, nơi độ lệch đồng hồ đáng kể của validator đại diện cho một bề mặt tấn công lý thuyết được quản lý trong thực tế thông qua đồng bộ hóa NTP.

Mức tối đa lý thuyết của Solana là con số lý thuyết trong lịch sử khoảng 65.000 giao dịch mỗi giây, như được mô tả trong Whitepaper năm 2017 của Yakovenko. Con số này đại diện cho tất cả các đổi mới kiến trúc của Solana hoạt động ở công suất tối đa trong điều kiện mạng tối ưu. Thông lượng quan sát thực tế trong điều kiện mạng trực tiếp điển hình dao động từ khoảng 2.000 đến 4.000 TPS. Giới hạn lý thuyết phản ánh thiết kế kiến trúc; con số thực tế phản ánh hiệu suất sản xuất.

Tower BFT là cơ chế bỏ phiếu và chọn Fork của Solana có trọng số theo stake, được xây dựng xung quanh các slot PoH. Các validator bỏ phiếu với việc khóa lại ngày càng tăng, làm cho các phiếu bầu mâu thuẫn trở nên tốn kém. Không nên coi một slot mục tiêu là hoàn tất cuối cùng; hãy xác minh mức cam kết hiện tại và yêu cầu của ứng dụng.

Bản thân cơ chế mật mã, chuỗi băm tuần tự SHA-256, là an toàn. SHA-256 chưa bao giờ bị phá vỡ thành công trong môi trường sản xuất và được cộng đồng bảo mật coi là an toàn về mật mã. Độ tin cậy ở cấp độ mạng, bao gồm cả các sự cố ngừng hoạt động năm 2021 và 2022, là một mối quan tâm riêng biệt với bảo mật mật mã. Chuỗi băm của PoH không bị xâm phạm trong bất kỳ sự cố ngừng hoạt động mạng nào của Solana; những sự kiện đó là do cạn kiệt tài nguyên và lỗi phần mềm, không phải do bất kỳ lỗi nào của giao thức mật mã.

Nếu không có PoH, các validator của Solana sẽ cần trao đổi tin nhắn đóng dấu thời gian trước mỗi vòng đồng thuận để xác định thứ tự giao dịch, như các hệ thống đồng thuận BFT truyền thống yêu cầu. Tải trọng trao đổi tin nhắn này tăng lên theo số lượng validator và hạn chế thông lượng. PoH thay thế việc giao tiếp đó bằng một bằng chứng mật mã: chuỗi băm tự nó chứng minh thứ tự và thời gian của các sự kiện, do đó các validator có thể tiến hành trực tiếp bỏ phiếu về tính hợp lệ của giao dịch thay vì thương lượng về thời gian trước.

Không. Việc băm SHA-256 tuần tự của PoH chạy trên một validator lãnh đạo được chỉ định duy nhất cho mỗi slot, không phải trên một trường các thợ đào cạnh tranh. Nó không tiêu tốn năng lượng theo cách khai thác Proof of Work của Bitcoin, nơi mọi thợ đào đồng thời tiêu tốn năng lượng tính toán để cạnh tranh tìm ra một hàm băm hợp lệ. Tổng mức tiêu thụ năng lượng của Solana chỉ bằng một phần nhỏ so với Bitcoin. Chi phí phần cứng liên quan đến các validator Solana là một vấn đề tài chính và phi tập trung, nhưng nó khác biệt với câu hỏi về mức tiêu thụ năng lượng.

Solana bản thân nó là một blockchain Blockchain. Nó không chạy trên một mạng khác theo cách mà các giải pháp Top của Ethereum làm. Solana vận hành blockchain độc lập của riêng mình sử dụng Lịch sử Bằng chứng để sắp xếp thời gian giao dịch và Tower BFT để đồng thuận, với SOL là token gốc của nó.

Mã nguồn của Solana là mã nguồn mở, làm cho cơ chế PoH có sẵn cho các dự án khác nghiên cứu và điều chỉnh. Trong thực tế, PoH được tích hợp sâu vào toàn bộ kiến trúc của Solana. Tower BFT, Sealevel và Gulf Stream đều phụ thuộc vào chuỗi PoH. Trích xuất và áp dụng PoH cho một blockchain khác sẽ yêu cầu sao chép phần lớn các lớp xung quanh của Solana để đạt được lợi ích hiệu suất tương tự.

Khám phá SOL trên Bybit

Người đọc có thể xem lại thông tin thị trường SOL hiện tại hoặc thị trường giao ngay SOL/USDT. Các liên kết này cung cấp quyền truy cập thị trường và không chứng minh rằng Solana, ví hoặc giao thức của bên thứ ba là phù hợp với mọi người đọc.

Kết luận: Proof of History có phải là một sự đổi mới thực sự?

Proof of History là một sự đổi mới mật mã thực sự. Cơ chế chuỗi hàm băm SHA-256 giải quyết một vấn đề thực tế trong các hệ thống phân tán: chứng minh sự trôi qua của thời gian mà không cần tin tưởng vào bất kỳ đồng hồ đơn lẻ nào, theo cách mà bất kỳ người quan sát nào cũng có thể xác minh được mà không yêu cầu thực thi lại toàn bộ tính toán.

Các tác động về hiệu suất là có thật. Lợi thế về thông lượng ở lớp cơ sở của Solana so với các blockchain Layer 1 lớn khác mang tính cấu trúc, không phải ngẫu nhiên, và PoH là cơ chế nền tảng giúp điều đó trở nên khả thi. Các nhà đầu tư khi đánh giá liệu lợi thế đó có bền vững hay không nên cân nhắc nó với các sự đánh đổi đã được ghi nhận: yêu cầu phần cứng của validator tạo ra áp lực tập trung hóa, lịch sử độ tin cậy của mạng bao gồm các sự cố nghiêm trọng và một thiết kế tối ưu hóa hiệu suất ưu tiên thông lượng hơn là khả năng phục hồi thận trọng.

Những sự đánh đổi đó là những thách thức về kỹ thuật, không phải là những lỗi cơ bản trong thiết kế mật mã. Việc triển khai QUIC, thị trường phí và chất lượng dịch vụ theo trọng số stake (stake-weighted quality-of-service) sau năm 2022 cho thấy đội ngũ kỹ thuật của Solana đã giải quyết được những lỗi nghiêm trọng nhất về độ tin cậy. Liệu sự trưởng thành hơn nữa có mang lại cấu hình độ tin cậy phù hợp với cam kết về thông lượng hay không là một câu hỏi mà lịch sử hoạt động đang diễn ra của mạng lưới sẽ trả lời.

Một người đọc đã nghiên cứu qua bài viết này hiện có thể định nghĩa chính xác Proof of History và giải thích cách chuỗi hàm băm SHA-256 tạo ra một bản ghi thời gian có thể xác minh được. Họ có thể phân biệt PoH với các cơ chế đồng thuận như Proof of Stake, nêu rõ lý do tại sao PoH cho phép lợi thế về thông lượng của Solana và đánh giá các hạn chế đã được ghi nhận với bối cảnh phù hợp. Đó là bức tranh kỹ thuật cần thiết để đánh giá kiến trúc của Solana dựa trên các giá trị của nó.

Thông tin trong bài viết này phản ánh tài liệu kỹ thuật có sẵn công khai và hiện hành tại thời điểm xuất bản. Các giao thức Blockchain và các chỉ số hiệu suất mạng thay đổi theo thời gian. Nội dung này không liên kết với hoặc được tài trợ bởi Solana Labs hoặc Solana Foundation.

Đọc thêm

• Cơ chế đồng thuận Solana
• Kiến trúc Solana
• Tốc độ Solana: TPS Thực tế so với Lý thuyết