Cam kết trạng thái

Cam kết trạng thái trong crypto là gì?

Cam kết trạng thái là một bản tóm tắt mật mã học cam kết với trạng thái hiện tại của blockchain tại một thời điểm cụ thể.

Nói đơn giản, đây là một dấu vân tay nhỏ gọn của một tập dữ liệu blockchain lớn hơn nhiều.

Tập dữ liệu lớn đó có thể bao gồm số dư tài khoản, dữ liệu lưu trữ của hợp đồng thông minh, nonce, bản ghi validator, số dư token, quyền sở hữu đối tượng, UTXO hoặc các giá trị trạng thái khác tùy theo thiết kế blockchain.

Cam kết trạng thái cho phép node, ví, bridge, light client, rollup và ứng dụng xác minh các tuyên bố về trạng thái blockchain mà không cần tải xuống hoặc mù quáng tin cậy toàn bộ cơ sở dữ liệu.

Trên Ethereum, dạng cam kết trạng thái quen thuộc nhất là state root được lưu trong block header.

Tài liệu chính thức về Merkle Patricia Trie của Ethereum giải thích rằng Ethereum sử dụng một state trie toàn cục, được cập nhật khi client xử lý block, và state root tạo thành có thể được xác minh bằng mật mã học.

Nếu hai node xử lý cùng một block hợp lệ và đạt cùng cam kết trạng thái, chúng có bằng chứng mạnh mẽ rằng cả hai đồng thuận về trạng thái kết quả.

Nếu một số dư tài khoản hoặc giá trị lưu trữ của hợp đồng thay đổi, cam kết trạng thái cũng sẽ thay đổi.

Đây là lý do cam kết trạng thái thiết yếu đối với cơ chế đồng thuận blockchain, state proof, fraud proof, validity proof, xác minh light client và truyền tin cross-chain.

Trong ngữ cảnh thuật ngữ crypto, State Commitment là gốc hoặc cam kết mật mã học đại diện cho trạng thái hiện tại của blockchain dưới dạng nhỏ gọn và có thể xác minh.

Vì sao cam kết trạng thái quan trọng?

Cam kết trạng thái quan trọng vì blockchain là cơ sở dữ liệu dùng chung được duy trì bởi nhiều bên tham gia độc lập.

Không người dùng nào nên phải tin cậy một máy chủ duy nhất để báo cáo số dư, giá trị hợp đồng hoặc trạng thái tài khoản chính xác.

Cam kết trạng thái cung cấp cho mạng một cách để thống nhất về một giá trị nhỏ gọn duy nhất đại diện cho trạng thái lớn hơn nhiều.

Nhờ đó, trạng thái có thể được kiểm tra bằng proof thay vì sự tin cậy mù quáng.

Ví dụ, một light client có thể không lưu toàn bộ trạng thái Ethereum, nhưng vẫn có thể xác minh state proof dựa trên state root đáng tin cậy.

Một bridge có thể cần bằng chứng rằng một thông điệp hoặc bản ghi rút tiền tồn tại trong trạng thái của chain khác.

Một rollup có thể công bố state root tóm tắt kết quả của nhiều giao dịch off-chain hoặc Layer 2.

Một ví có thể dựa vào node để lấy dữ liệu số dư, trong khi các hệ thống mạnh hơn có thể sử dụng proof để xác minh node không cung cấp thông tin sai.

Cam kết trạng thái cũng giúp việc thực thi blockchain có thể kiểm toán.

Khi mỗi block bao gồm cam kết về trạng thái kết quả, người dùng có thể xác minh rằng chain đã chuyển từ trạng thái hợp lệ này sang trạng thái hợp lệ khác theo các quy tắc của giao thức.

Cam kết trạng thái và trạng thái blockchain

Trạng thái blockchain là toàn bộ dữ liệu đang hoạt động cần thiết để xử lý giao dịch mới.

Cam kết trạng thái chỉ là biểu diễn mật mã học nhỏ gọn của trạng thái đó.

Sự khác biệt này quan trọng vì cam kết trạng thái không trực tiếp chứa mọi số dư hoặc ô lưu trữ.

Nó chỉ cam kết với những giá trị đó thông qua một cấu trúc dữ liệu mật mã học.

Ví dụ, state root của Ethereum không liệt kê mọi số dư tài khoản trong block header.

Thay vào đó, nó cam kết với state trie toàn cục lưu trữ các đối tượng tài khoản và trỏ đến các storage trie của hợp đồng.

Nếu ai đó muốn chứng minh một giá trị cụ thể, họ cung cấp đường dẫn proof liên kết giá trị đó với cam kết.

Bên xác minh kiểm tra proof dựa trên cam kết đã biết.

Nếu proof hợp lệ, bên xác minh có thể tin rằng giá trị thuộc về trạng thái đã cam kết.

Do đó, cam kết trạng thái giống như con dấu chống giả mạo phủ lên cơ sở dữ liệu blockchain đang hoạt động.

Cam kết trạng thái và state root

State root là một loại cam kết trạng thái phổ biến.

Trong Ethereum, state root là hash gốc của state trie toàn cục sau khi một block được thực thi.

Tài liệu chính thức về block Ethereum mô tả block chứa thông tin execution payload, bao gồm các root cam kết với dữ liệu quan trọng ở execution layer.

State root là một trường cụ thể, còn cam kết trạng thái là khái niệm rộng hơn.

Các hệ thống blockchain khác có thể sử dụng những tên gọi khác như app hash, state hash, world state root, global root, ledger commitment, accumulator root hoặc commitment root.

Tên gọi chính xác phụ thuộc vào giao thức.

Ý tưởng cốt lõi vẫn giống nhau.

Một trạng thái lớn được tóm tắt bằng một giá trị nhỏ, thay đổi khi trạng thái nền tảng thay đổi.

Với các chain theo kiểu Ethereum, state root là thuật ngữ thực tế mà người dùng và nhà phát triển thường gặp nhất.

Trong lý thuyết blockchain, cam kết trạng thái là khái niệm tổng quát hơn.

Cam kết trạng thái hoạt động như thế nào?

Cam kết trạng thái thường bắt đầu từ một cơ sở dữ liệu có cấu trúc gồm các giá trị trạng thái.

Blockchain tổ chức các giá trị đó trong cấu trúc dữ liệu mật mã học như Merkle tree, Merkle Patricia Trie, sparse Merkle tree, vector commitment tree hoặc một cấu trúc dữ liệu đã xác thực khác.

Mỗi giá trị được hash hoặc cam kết theo cách xác định.

Các hash này được kết hợp theo chiều từ dưới lên cho đến khi tạo ra một root cấp cao nhất.

Root cấp cao nhất này trở thành cam kết trạng thái.

Nếu một giá trị lá thay đổi, các hash dọc theo đường dẫn của nó sẽ thay đổi.

Thay đổi đó lan truyền lên trên cho đến khi root thay đổi.

Điều này khiến hành vi giả mạo có thể bị phát hiện, vì một giá trị giả không thể khớp cam kết gốc trừ khi kẻ tấn công có thể phá vỡ cơ chế mật mã học nền tảng.

Cam kết trạng thái hữu ích vì nó giúp một cơ sở dữ liệu khổng lồ có thể xác minh thông qua một root nhỏ cùng proof.

Proof không cần chứa toàn bộ cơ sở dữ liệu, mà chỉ cần đường dẫn và dữ liệu hỗ trợ cần để kiểm tra một tuyên bố.

Cam kết trạng thái trong Ethereum

Ethereum sử dụng Merkle Patricia Trie đã chỉnh sửa để cam kết với trạng thái execution layer.

Tài liệu chính thức về Merkle Patricia Trie của Ethereum nêu rằng Ethereum có một state trie toàn cục và trie này được cập nhật mỗi khi một block được xử lý.

Các đối tượng tài khoản Ethereum bao gồm nonce, balance, storageRoot và codeHash.

State trie toàn cục ánh xạ địa chỉ tài khoản đến các đối tượng tài khoản này.

Mỗi tài khoản hợp đồng thông minh cũng có thể có storage trie riêng, và root của storage trie đó được lưu trong đối tượng tài khoản.

Điều này có nghĩa cam kết trạng thái của Ethereum có cấu trúc phân lớp.

State root toàn cục cam kết với các tài khoản.

storageRoot của từng tài khoản hợp đồng cam kết với dữ liệu lưu trữ lâu dài của hợp đồng đó.

Nếu một hợp đồng token cập nhật số dư người dùng trong vùng lưu trữ hợp đồng, storage root của hợp đồng thay đổi và state root toàn cục cũng có thể thay đổi.

Đây là cách việc thực thi hợp đồng thông minh trở thành một phần của trạng thái blockchain đã cam kết.

Cam kết trạng thái và Merkle Patricia Trie

Merkle Patricia Trie là cấu trúc dữ liệu khóa-giá trị đã xác thực được execution layer hiện tại của Ethereum sử dụng.

Nó kết hợp đường dẫn khóa kiểu trie, tính năng nén đường dẫn Patricia và Merkle hashing.

Phần trie cho phép tìm giá trị qua các đường dẫn xác định dựa trên khóa.

Phần Patricia nén các đường dẫn dài để giảm cấu trúc dư thừa.

Phần Merkle khiến cấu trúc có thể xác minh bằng mật mã học.

Tài liệu chính thức của Ethereum cho biết Merkle Patricia Trie có tính xác định và có thể xác minh bằng mật mã học, nghĩa là các trạng thái giống hệt có thể được chứng minh bằng cách so sánh root và đường dẫn proof.

Đây chính xác là những gì một cam kết trạng thái cần.

Nó cần được xây dựng theo cách xác định để các node trung thực tính cùng một root.

Nó cần tính toàn vẹn mật mã học để dữ liệu bị sửa đổi làm thay đổi cam kết.

Nó cần hỗ trợ proof để các giá trị cụ thể được xác minh mà không cần tải xuống toàn bộ dữ liệu.

Cam kết trạng thái và Merkle proof

Merkle proof là bằng chứng cho thấy một giá trị cụ thể thuộc về trạng thái được cam kết bởi một root.

Đặc tả EIP-1186 eth_getProof mô tả một phương thức JSON-RPC trả về các giá trị tài khoản và lưu trữ cùng dữ liệu Merkle proof.

Một proof thường chứa các node hoặc cam kết cần thiết để tái tạo đường dẫn từ giá trị mục tiêu đến state root.

Nếu root được tái tạo khớp với cam kết trạng thái đáng tin cậy, giá trị được xác minh.

Điều này cho phép bên xác minh xác nhận một tài khoản có số dư nhất định hoặc một ô lưu trữ hợp đồng có giá trị nhất định tại một block cụ thể.

Merkle proof quan trọng vì chúng giảm sự phụ thuộc vào các nhà cung cấp RPC, indexer và API bên thứ ba.

Một phản hồi RPC đơn giản cho biết máy chủ tuyên bố trạng thái là gì.

Phản hồi có proof hỗ trợ có thể cho thấy vì sao tuyên bố đó khớp với cam kết trạng thái.

Sự khác biệt này quan trọng với ví, bridge, hoạt động kiểm toán, hệ thống cross-chain và ứng dụng có giá trị cao.

Cam kết trạng thái làm các proof này có ý nghĩa vì proof cần một root đáng tin cậy để đối chiếu khi xác minh.

Cam kết trạng thái và block header

Block header là nơi nhiều blockchain lưu các cam kết nhỏ gọn với dữ liệu block lớn hơn.

Block header Ethereum bao gồm các root liên quan đến trạng thái, giao dịch và biên lai.

State root cam kết với world state kết quả.

Transaction root cam kết với danh sách giao dịch trong block.

Receipt root cam kết với biên lai giao dịch và log.

Các cam kết này phục vụ những mục đích khác nhau.

Cam kết trạng thái trả lời trạng thái blockchain trở thành gì sau khi thực thi.

Cam kết giao dịch trả lời những giao dịch nào được đưa vào.

Cam kết biên lai trả lời những đầu ra thực thi và log nào được tạo ra.

Kết hợp lại, các root này cho phép client xác minh những phần quan trọng của dữ liệu block mà không cần đặt toàn bộ dữ liệu đầy đủ trực tiếp trong header.

Cam kết trạng thái và cam kết giao dịch

Cam kết trạng thái không giống cam kết giao dịch.

Cam kết giao dịch cam kết với các giao dịch được đưa vào block.

Cam kết trạng thái cam kết với trạng thái kết quả sau khi các giao dịch đó được thực thi.

Ví dụ, một block có thể chứa giao dịch chuyển tài sản từ tài khoản này sang tài khoản khác.

Cam kết giao dịch chứng minh giao dịch đã được đưa vào.

Cam kết trạng thái chứng minh các thay đổi số dư kết quả nếu state proof liên quan được cung cấp.

Sự khác biệt này rất quan trọng đối với nhà phát triển xây dựng bridge hoặc proof.

Chứng minh giao dịch được đưa vào không phải lúc nào cũng đồng nghĩa với chứng minh trạng thái cuối cùng.

Một giao dịch có thể được đưa vào nhưng thất bại khi thực thi.

State proof có thể cho thấy trạng thái chain thực tế đã trở thành gì sau khi thực thi.

Cam kết trạng thái và cam kết biên lai

Cam kết biên lai cũng khác với cam kết trạng thái.

Một biên lai có thể cho thấy trạng thái thực thi, gas đã sử dụng, log và sự kiện.

Cam kết trạng thái cho thấy cơ sở dữ liệu trạng thái cuối cùng sau thực thi.

Sự kiện có thể hữu ích cho việc lập chỉ mục và logic ứng dụng, nhưng sự kiện không giống dữ liệu lưu trữ hợp đồng.

Một hợp đồng có thể phát sự kiện mà không thay đổi trạng thái.

Một hợp đồng có thể thay đổi trạng thái mà không phát một sự kiện hữu ích.

Đây là lý do một số hệ thống bảo mật cao ưu tiên storage proof hơn các giả định chỉ dựa trên sự kiện.

Biên lai có giá trị, nhưng trả lời câu hỏi khác với cam kết trạng thái.

Cam kết biên lai giúp chứng minh giao dịch đã báo cáo điều gì.

Cam kết trạng thái giúp chứng minh trạng thái blockchain thực sự chứa gì.

Cam kết trạng thái trong rollup

Rollup phụ thuộc nhiều vào cam kết trạng thái.

Một rollup xử lý giao dịch bên ngoài base chain hoặc trong môi trường thực thi riêng, rồi đăng các cam kết, dữ liệu hoặc proof trở lại settlement layer.

State root của rollup tóm tắt trạng thái Layer 2 hiện tại.

Người dùng có thể sử dụng cam kết đó để theo dõi số dư, khoản rút, thông điệp và trạng thái ứng dụng bên trong rollup.

Tài liệu chính thức về zk-rollup Ethereum giải thích rằng zero-knowledge rollup đăng validity proof để chứng minh các chuyển đổi trạng thái là chính xác.

Trong optimistic rollup, cam kết trạng thái có thể bị phản đối trong thời hạn tranh chấp nếu ai đó cho rằng quá trình chuyển đổi không hợp lệ.

Trong validity rollup, proof được dùng để cho thấy trạng thái mới đã cam kết tuân theo quy tắc.

Trong cả hai trường hợp, cam kết trạng thái là tuyên bố nhỏ gọn về trạng thái của rollup.

Nếu không có cam kết trạng thái, rollup sẽ không có cách hiệu quả để tóm tắt và quyết toán lượng lớn hoạt động thực thi Layer 2.

Điều này khiến cam kết trạng thái trở thành thành phần thiết yếu của khả năng mở rộng blockchain hiện đại.

Cam kết trạng thái và fraud proof

Fraud proof là một khiếu nại cho thấy một chuyển đổi trạng thái được tuyên bố là không hợp lệ.

Các hệ thống fraud proof thường được thảo luận trong thiết kế optimistic rollup.

Nhà vận hành rollup có thể công bố cam kết trạng thái mới sau khi thực thi giao dịch.

Nếu cam kết sai, bên tham gia khác có thể phản đối bằng cách chứng minh quá trình chuyển từ trạng thái cũ sang trạng thái mới là không hợp lệ.

Quy trình tranh chấp cần các cam kết rõ ràng với trạng thái cũ, dữ liệu giao dịch và trạng thái mới được tuyên bố.

Vì vậy, cam kết trạng thái là một phần của cấu trúc bằng chứng cho fraud proof.

Fraud proof không chỉ là tuyên bố rằng có điều gì đó sai.

Nó phải liên kết tuyên bố với dữ liệu đã cam kết và quy tắc thực thi.

Đây là lý do tính khả dụng dữ liệu cũng quan trọng đối với fraud proof.

Nếu dữ liệu cần để tính lại quá trình chuyển đổi không khả dụng, bên phản đối có thể không chứng minh được gian lận.

Cam kết trạng thái và validity proof

Validity proof là bằng chứng mật mã học cho thấy một chuyển đổi trạng thái đã được thực thi chính xác.

Validity proof thường được dùng trong zero-knowledge rollup và các hệ thống dựa trên proof khác.

Prover bắt đầu từ cam kết trạng thái cũ, áp dụng giao dịch theo các quy tắc và chứng minh cam kết trạng thái mới là chính xác.

Bên xác minh không cần thực thi lại toàn bộ từng giao dịch nếu hệ thống proof đáng tin cậy và các giả định cần thiết về dữ liệu được đáp ứng.

Điều này có thể giúp việc xác minh rẻ hơn nhiều so với thực thi.

Cam kết trạng thái là trung tâm vì proof cần một cam kết điểm đầu và cam kết điểm cuối rõ ràng.

Về bản chất, proof cho biết hệ thống đã chuyển hợp lệ từ một trạng thái đã cam kết sang trạng thái đã cam kết khác.

Điều này biến cam kết trạng thái thành điểm neo cho quá trình xác minh có khả năng mở rộng.

Validity proof có thể hỗ trợ rollup, bridge, ứng dụng riêng tư và hệ thống thực thi nén.

Cam kết xác định trạng thái nào đang được chứng minh.

Cam kết trạng thái và light client

Light client sử dụng cam kết và proof để xác minh thông tin blockchain mà không lưu toàn bộ trạng thái.

Một light client có thể theo dõi block header và xác minh proof dựa trên các root trong những header đó.

Đối với một giá trị trạng thái, light client cần một cam kết trạng thái đáng tin cậy và state proof hợp lệ.

Điều này cho phép ví di động, thiết bị nhúng và hệ thống ít tài nguyên xác minh các thông tin cụ thể với ít dung lượng lưu trữ và băng thông hơn.

Do đó, cam kết trạng thái là phần quan trọng trong thiết kế ví giảm thiểu yêu cầu tin cậy.

Nếu không có chúng, light client sẽ phải tin cậy máy chủ từ xa nhiều hơn.

Máy chủ từ xa có thể báo cáo số dư, nhưng proof cho phép client kiểm tra số dư đó dựa trên trạng thái đã cam kết.

Việc xác minh light client không phải lúc nào cũng đơn giản vì client cũng cần header đáng tin cậy và các giả định về finality.

Dù vậy, về nguyên tắc, cam kết trạng thái giúp xác minh nhẹ trở nên khả thi.

Đây là một trong những lợi ích hướng đến người dùng quan trọng nhất của trạng thái đã xác thực.

Cam kết trạng thái và bridge

Bridge thường cần xác minh trạng thái từ blockchain hoặc mạng Layer 2 khác.

Một bridge có thể cần chứng minh khoản nạp đã diễn ra, khoản rút đã được hoàn tất hoặc một thông điệp tồn tại trong trạng thái đã cam kết.

Cam kết trạng thái giúp bridge xác minh những tuyên bố này an toàn hơn.

Ví dụ, hợp đồng bridge có thể xác minh một proof dựa trên state root đã biết từ hệ thống khác.

Nếu proof hợp lệ, bridge có thể giải phóng tiền hoặc chuyển tiếp thông điệp.

Tuy nhiên, bridge vẫn có rủi ro ngay cả khi sử dụng cam kết trạng thái.

Bridge cũng phải xác minh cơ chế đồng thuận, finality, tính khả dụng dữ liệu, định dạng proof và quy tắc thông điệp của chain nguồn.

State proof chính xác chỉ là một phần trong sự an toàn của bridge.

Thiết kế bridge kém vẫn có thể thất bại do validator yếu, relayer kém, lỗi hợp đồng thông minh, tấn công phát lại hoặc giả định finality sai.

Cam kết trạng thái giúp giảm yêu cầu tin cậy, nhưng không tự động khiến mọi bridge trở nên bảo mật.

Cam kết trạng thái và tính khả dụng dữ liệu

Tính khả dụng dữ liệu nghĩa là dữ liệu cần để xác minh hoặc tái tạo các chuyển đổi trạng thái được công khai và có thể truy cập.

Chỉ riêng cam kết trạng thái không đảm bảo người dùng có thể kiểm tra trạng thái được tạo ra như thế nào.

Một tác nhân độc hại có thể công bố cam kết mới nhưng giữ lại dữ liệu cần thiết để xác minh quá trình chuyển đổi.

Đây là lý do tính khả dụng dữ liệu là vấn đề lớn đối với rollup, sharding và hệ thống blockchain mô-đun.

Tài liệu chính thức về tính khả dụng dữ liệu của Ethereum giải thích rằng khái niệm này đề cập đến việc dữ liệu giao dịch đã được công bố hay chưa để bên tham gia có thể xác minh hoặc tái tạo trạng thái.

Cam kết trạng thái và tính khả dụng dữ liệu hoạt động cùng nhau.

Cam kết cho biết trạng thái được tuyên bố là gì.

Dữ liệu khả dụng cho phép người khác kiểm tra liệu quá trình chuyển đổi sang trạng thái đó có hợp lệ hay không.

Cam kết không kèm dữ liệu có thể trở thành một hộp đen.

Một blockchain có khả năng mở rộng cần cả cam kết nhỏ gọn lẫn dữ liệu có thể truy cập.

Cam kết trạng thái và stateless client

Stateless client là ý tưởng mở rộng dài hạn, trong đó node có thể xác minh block mà không cần lưu toàn bộ trạng thái cục bộ.

Thay vì mọi node duy trì toàn bộ cơ sở dữ liệu trạng thái, nhà sản xuất block hoặc peer cung cấp witness chứng minh các giá trị trạng thái được block truy cập.

Tài liệu chính thức về statelessness của Ethereum giải thích rằng statelessness nhằm giúp node xác minh block bằng witness thay vì cơ sở dữ liệu trạng thái cục bộ lớn.

Cam kết trạng thái là trung tâm của thiết kế này vì witness phải xác minh dựa trên một cam kết.

Nếu witness chứng minh mọi giá trị được truy cập khớp cam kết trạng thái trước đó và các giá trị kết quả tạo ra cam kết mới, bên xác minh có thể kiểm tra block với ít trạng thái cục bộ hơn.

Điều này có thể giúp vận hành node dễ dàng hơn theo thời gian.

Tuy nhiên, witness Merkle Patricia Trie hiện tại có thể rất lớn.

Đây là một lý do nghiên cứu Ethereum tập trung vào Verkle tree và cấu trúc witness nhỏ hơn.

Statelessness không chỉ là mẹo lưu trữ.

Nó phụ thuộc vào các cam kết trạng thái hỗ trợ proof hiệu quả.

Cam kết trạng thái và Verkle tree

Verkle tree là hướng nâng cấp được đề xuất để giúp state proof Ethereum nhỏ hơn và hiệu quả hơn.

Tài liệu chính thức về Verkle tree của Ethereum mô tả Verkle tree là cấu trúc dữ liệu có thể giúp node Ethereum ngừng lưu trữ lượng lớn dữ liệu trạng thái mà vẫn duy trì khả năng xác thực block.

Verkle tree kết hợp cấu trúc tree với vector commitment.

Tên Verkle bắt nguồn từ vector commitment và Merkle tree.

So với proof Merkle Patricia Trie hiện tại, Verkle proof có thể nhỏ hơn đáng kể đối với nhiều mô hình truy cập trạng thái.

Witness nhỏ hơn rất quan trọng đối với stateless client và khả năng mở rộng trong tương lai.

Verkle tree không loại bỏ nhu cầu về cam kết trạng thái.

Chúng thay đổi cấu trúc cam kết được sử dụng để biểu diễn và chứng minh trạng thái.

Điều này cho thấy cam kết trạng thái là một khái niệm rộng, có thể được triển khai bằng các cấu trúc dữ liệu mật mã học khác nhau.

Phương thức cam kết có thể phát triển, trong khi nhu cầu cam kết với trạng thái vẫn mang tính nền tảng.

Cam kết trạng thái và vector commitment

Vector commitment là cam kết mật mã học với danh sách hoặc vector giá trị, hỗ trợ proof hiệu quả về từng vị trí riêng lẻ.

Vector commitment có thể hữu ích cho trạng thái blockchain vì chúng có thể giảm kích thước proof so với một số cách tiếp cận hash tree.

Verkle tree sử dụng vector commitment trong cấu trúc giống tree.

Điều này khác Merkle tree truyền thống, nơi hash của node cùng cấp được dùng để xác minh đường dẫn.

Vector commitment có thể giúp proof nhỏ gọn hơn, nhưng có thể đưa vào các giả định mật mã học và độ phức tạp triển khai khác.

Với người dùng, điểm quan trọng không phải là chi tiết toán học.

Điểm quan trọng là hệ thống cam kết trạng thái mới hơn hướng tới giảm chi phí chứng minh trạng thái.

Proof nhỏ hơn có thể hỗ trợ light client, stateless client, rollup, bridge và các hệ thống bảo vệ quyền riêng tư.

Tuy nhiên, các cơ chế cam kết mới cần được thử nghiệm cẩn thận trước khi bảo vệ những mạng công khai lớn.

Thiết kế cam kết trạng thái luôn là sự cân bằng giữa kích thước proof, chi phí xác minh, chi phí cập nhật, giả định bảo mật và rủi ro triển khai.

Cam kết trạng thái và sparse Merkle tree

Sparse Merkle tree là một cấu trúc cam kết trạng thái phổ biến khác trong các hệ thống crypto.

Nó thường được dùng khi khóa nằm trong không gian khóa cố định rất lớn.

Mỗi khóa có thể có một vị trí trong tree, nhưng phần lớn vị trí có thể trống.

Các nhánh trống có thể được nén hoặc biểu diễn hiệu quả tùy theo cách triển khai.

Sparse Merkle tree hữu ích vì hỗ trợ rõ ràng proof có mặt và proof không có mặt.

Một số hệ thống Layer 2, bridge, ví và blockchain dành riêng cho ứng dụng sử dụng sparse Merkle tree hoặc các biến thể để cam kết trạng thái.

Chúng không giống Merkle Patricia Trie hiện tại của Ethereum.

Chúng là một cách khác để giải quyết cùng vấn đề cơ bản.

Vấn đề là cách cam kết với trạng thái khóa-giá trị lớn và chứng minh hiệu quả từng giá trị riêng lẻ.

Sự đa dạng này cho thấy cam kết trạng thái là một nhóm thiết kế, không phải một cấu trúc dữ liệu đơn lẻ.

Cam kết trạng thái và Bitcoin

Bitcoin thường không được mô tả bằng cam kết trạng thái tài khoản toàn cục theo kiểu Ethereum.

Block Bitcoin cam kết với giao dịch thông qua Merkle root trong block header.

Trạng thái có thể chi tiêu đang hoạt động của Bitcoin là tập UTXO, được suy ra từ lịch sử giao dịch.

Hướng dẫn dành cho nhà phát triển Bitcoin về blockchain giải thích rằng block header bao gồm Merkle root cho các giao dịch trong block.

Điều này có nghĩa Bitcoin có các cam kết mạnh về việc giao dịch được đưa vào.

Tuy nhiên, block header Bitcoin không bao gồm cam kết trực tiếp với toàn bộ tập UTXO hiện tại giống cách Ethereum đưa state root cho trạng thái tài khoản vào block header.

Một số nghiên cứu và đề xuất đã xem xét cam kết UTXO vì cam kết trực tiếp với trạng thái có thể chi tiêu có thể hỗ trợ light client và mô hình xác thực.

So sánh này hữu ích vì cho thấy các blockchain khác nhau cam kết với các loại dữ liệu khác nhau.

Các hệ thống hợp đồng thông minh theo kiểu Ethereum cần cam kết trạng thái rõ ràng vì ứng dụng phụ thuộc nhiều vào trạng thái tài khoản và hợp đồng hiện tại.

Mô hình Bitcoin tập trung trực tiếp hơn vào lịch sử giao dịch và tập UTXO được suy ra từ đó.

Cam kết trạng thái và blockchain dựa trên tài khoản

Blockchain dựa trên tài khoản thường cần cam kết trạng thái rõ ràng vì số dư tài khoản và dữ liệu lưu trữ hợp đồng là thành phần trọng yếu của việc thực thi.

Khi một giao dịch được thực thi, nó có thể cập nhật số dư tài khoản, nonce, dữ liệu lưu trữ hợp đồng thông minh, bản ghi staking và dữ liệu ứng dụng.

Trạng thái kết quả phải được cam kết để các node khác có thể xác minh kết quả chính xác.

Đây là lý do state root phổ biến trên nền tảng hợp đồng thông minh.

Chúng cung cấp cho mạng một cam kết duy nhất với cơ sở dữ liệu trạng thái rộng lớn.

Nếu không có cam kết trạng thái đáng tin cậy, sẽ khó hơn để chứng minh một giá trị lưu trữ hợp đồng là chính xác.

Việc xây dựng bridge, rollup và light client phụ thuộc vào proof tài khoản hoặc lưu trữ cũng sẽ khó hơn.

Chain dựa trên tài khoản thường có trạng thái phức tạp hơn hệ thống thanh toán đơn giản.

Sự phức tạp đó khiến thiết kế cam kết trạng thái đặc biệt quan trọng.

Chain càng có khả năng lập trình, trạng thái đã xác thực càng có giá trị.

Cam kết trạng thái và blockchain dựa trên đối tượng

Một số blockchain dùng mô hình trạng thái dựa trên đối tượng thay vì trạng thái đơn giản dựa trên tài khoản.

Trong hệ thống dựa trên đối tượng, tài sản, hợp đồng và dữ liệu có thể được biểu diễn thành đối tượng có chủ sở hữu, trường dữ liệu và quyền hạn.

Các hệ thống này vẫn cần cam kết trạng thái.

Cam kết có thể tóm tắt quyền sở hữu đối tượng, nội dung đối tượng, số phiên bản, dữ liệu package hoặc kết quả thực thi.

Cấu trúc chính xác khác với account trie toàn cục của Ethereum.

Tuy nhiên, mục tiêu vẫn là giúp trạng thái hiện tại có thể xác minh.

Nếu một đối tượng thay đổi quyền sở hữu, cam kết trạng thái phải phản ánh thay đổi đó.

Nếu nội dung đối tượng thay đổi, cam kết phải phản ánh bản cập nhật này.

Điều này cho thấy cam kết trạng thái không giới hạn ở mô hình tài khoản kiểu Ethereum.

Bất kỳ blockchain nào duy trì trạng thái đang hoạt động đều cần cách cam kết với trạng thái đó một cách bảo mật.

Cam kết trạng thái và dữ liệu lưu trữ hợp đồng thông minh

Dữ liệu lưu trữ hợp đồng thông minh là một trong các nguyên nhân chính khiến cam kết trạng thái phức tạp.

Hợp đồng thông minh có thể lưu số dư, phê duyệt, vị thế, lệnh, phiếu bầu, giá trị cấu hình và nhiều bản ghi khác.

Các giá trị này có thể thay đổi sau mỗi giao dịch.

Cam kết trạng thái phải phản ánh chính xác các thay đổi đó.

Trên Ethereum, storage trie của mỗi hợp đồng có root riêng và tài khoản hợp đồng lưu root đó bên trong state trie toàn cục.

Điều này cho phép tạo proof cho các ô lưu trữ hợp đồng cụ thể.

Ví dụ, proof có thể cho thấy ánh xạ số dư token có một giá trị nhất định tại một block nhất định.

Điều này hữu ích cho kiểm toán, bridge, quản trị, rollup và xác minh cross-chain.

Dữ liệu lưu trữ hợp đồng thông minh làm cam kết trạng thái trở nên mạnh mẽ, nhưng cũng nặng hơn vì trạng thái có thể tăng lên rất lớn.

Đây là lý do chi phí lưu trữ, state bloat và kích thước proof là các mối quan ngại lớn về khả năng mở rộng.

Cam kết trạng thái và số dư token

Số dư token thường nằm trong dữ liệu lưu trữ hợp đồng thông minh thay vì trực tiếp trong trạng thái tài khoản cơ sở.

Điều này nghĩa là chứng minh số dư token có thể cần storage proof cho hợp đồng token.

Số dư coin gốc có thể được chứng minh từ đối tượng tài khoản.

Số dư token có thể yêu cầu chứng minh tài khoản hợp đồng token và ô lưu trữ liên quan bên trong storage root của hợp đồng đó.

Sự khác biệt này quan trọng với bridge và airdrop.

Hệ thống cần xác minh quyền sở hữu token nên hiểu quyền sở hữu đó được lưu trữ ở đâu.

Hệ thống không nên giả định mọi số dư đều thuộc cùng một trường trạng thái.

Cam kết trạng thái có thể hỗ trợ cả proof coin gốc lẫn token, nhưng các đường dẫn proof có thể khác nhau.

Nhà phát triển nên hiểu chuẩn token và bố cục lưu trữ trước khi xây dựng hệ thống proof.

Cam kết trạng thái chỉ hữu ích khi bên xác minh biết chính xác giá trị nào đang được chứng minh.

Cam kết trạng thái và NFT

Quyền sở hữu NFT cũng có thể được biểu diễn bằng cam kết trạng thái.

Hợp đồng NFT thường lưu dữ liệu quyền sở hữu cho từng token ID.

Proof quyền sở hữu NFT có thể cần xác minh giá trị lưu trữ hợp đồng liên quan tại một block cụ thể.

Điều này có thể hữu ích với bridge NFT cross-chain, bỏ phiếu snapshot, quyền truy cập có kiểm soát, phần thưởng và việc kiểm tra quyền sở hữu trong quá khứ.

Tuy nhiên, metadata NFT có thể không phải lúc nào cũng được cam kết đầy đủ bởi trạng thái blockchain.

Một số metadata NFT được lưu off-chain hoặc tham chiếu qua liên kết bên ngoài.

Cam kết trạng thái có thể chứng minh quyền sở hữu on-chain, nhưng có thể không chứng minh hình ảnh hoặc tệp metadata off-chain sẽ luôn khả dụng.

Sự khác biệt này quan trọng với người dùng cho rằng state proof chứng minh mọi thứ về NFT.

Thông thường, nó chỉ chứng minh giá trị trạng thái on-chain đang được kiểm tra.

Cam kết trạng thái rất mạnh mẽ, nhưng không tự động xác minh tính lâu dài của dữ liệu off-chain.

Cam kết trạng thái và trạng thái lịch sử

Cam kết trạng thái gắn với block hoặc thời điểm cụ thể trong lịch sử của chain.

Cam kết trạng thái hiện tại chứng minh trạng thái hiện tại.

Cam kết trạng thái cũ có thể chứng minh trạng thái lịch sử nếu bên xác minh có block header cũ và proof phù hợp.

Điều này hữu ích cho kiểm toán, snapshot, hồ sơ pháp lý, quản trị và các tuyên bố lịch sử.

Tuy nhiên, dữ liệu trạng thái lịch sử có thể tốn kém để lưu trữ.

Nhiều full node duy trì trạng thái hiện tại và gần đây nhưng loại bỏ trạng thái trung gian cũ.

Archive node lưu nhiều trạng thái lịch sử hơn để có thể trả lời truy vấn cũ nhanh hơn.

Tài liệu chính thức về archive node Ethereum giải thích rằng archive node lưu mọi trạng thái lịch sử và hữu ích cho các truy vấn lịch sử nhanh.

Điều này nghĩa là cam kết trạng thái lịch sử có thể tồn tại trong block header cũ, nhưng việc tạo proof cho trạng thái cũ có thể cần truy cập cơ sở dữ liệu trạng thái lịch sử.

Cam kết trạng thái duy trì khả năng xác minh, nhưng vẫn cần ai đó có dữ liệu cần thiết để tạo proof.

Cam kết trạng thái và archive node

Archive node quan trọng vì chỉ riêng cam kết trạng thái không lưu toàn bộ dữ liệu trạng thái.

Một block header có thể chứa state root từ nhiều năm trước.

Để tạo proof dựa trên root cũ đó, node cần truy cập các node trie lịch sử hoặc dữ liệu trạng thái liên quan.

Full node tiêu chuẩn có thể không sẵn dữ liệu trạng thái cũ đó.

Archive node được thiết kế để lưu các trạng thái lịch sử nhằm truy cập nhanh.

Đây là lý do trình khám phá blockchain, công ty phân tích, kiểm toán viên và nhà cung cấp hạ tầng thường dựa vào archive node.

Với người dùng, vấn đề thực tế là trạng thái cũ có thể khó xác minh hơn trạng thái hiện tại nếu dữ liệu proof không dễ tiếp cận.

Với nhà phát triển, điều này nghĩa là hệ thống proof lịch sử cần lập kế hoạch lưu trữ dữ liệu cẩn thận.

Cam kết trạng thái là điểm neo nhỏ gọn, nhưng proof vẫn cần dữ liệu hỗ trợ.

Hạ tầng archive thu hẹp khoảng cách đó cho việc xác minh lịch sử.

Cam kết trạng thái và state bloat

State bloat xảy ra khi trạng thái blockchain đang hoạt động trở nên quá lớn.

Mỗi tài khoản, hợp đồng, ô lưu trữ, số dư token, lệnh và vị thế mới đều có thể làm tăng lượng trạng thái cần được cam kết và duy trì.

Trạng thái lớn hơn có thể làm tăng dung lượng lưu trữ node, thời gian đồng bộ, khối lượng công việc cơ sở dữ liệu và độ phức tạp của proof.

Cam kết trạng thái không loại bỏ chi phí của trạng thái.

Chúng chỉ tóm tắt và xác thực trạng thái đó.

Nếu trạng thái nền tảng tăng quá lớn, node vẫn cần lưu, cập nhật hoặc chứng minh các phần của trạng thái đó.

Đây là lý do nghiên cứu về cam kết trạng thái liên quan đến state expiry, storage rent, pruning, statelessness và Verkle tree.

Blockchain cần các cam kết bảo mật, nhưng cũng cần quản lý trạng thái bền vững.

State bloat là một trong những vấn đề dài hạn khó nhất đối với nền tảng hợp đồng thông minh.

Cam kết trạng thái tốt hơn có thể giúp ích, nhưng không phải là giải pháp duy nhất.

Cam kết trạng thái và storage rent

Storage rent là công cụ kinh tế tính phí hoặc yêu cầu dự trữ giá trị để duy trì dữ liệu trong trạng thái blockchain.

Nó liên quan đến cam kết trạng thái vì mỗi mục dữ liệu lưu trữ lâu dài cuối cùng phải được đưa vào trạng thái đã cam kết.

Nếu việc lưu dữ liệu quá rẻ, người dùng và ứng dụng có thể tạo trạng thái giá trị thấp, gây gánh nặng cho mạng trong nhiều năm.

Nếu lưu trữ quá đắt, các ứng dụng hữu ích có thể khó xây dựng hơn.

Cam kết trạng thái làm trạng thái có thể xác minh, nhưng không quyết định ai phải trả phí lưu trữ trạng thái đó.

Storage rent, khoản nạp, chi phí gas và khoản hoàn trả giúp giải quyết khía cạnh kinh tế của tăng trưởng trạng thái.

Cam kết trạng thái giải quyết khía cạnh mật mã học.

Cả hai đều cần thiết cho thiết kế blockchain bền vững.

Một blockchain có thể có state root mạnh nhưng vẫn gặp vấn đề nếu trạng thái tăng trưởng không giới hạn.

Đây là lý do cam kết trạng thái và kinh tế trạng thái cần được nghiên cứu cùng nhau.

Cam kết trạng thái và finality

Cam kết trạng thái trở nên hữu ích hơn khi gắn với một block đã finality hoặc được xác nhận mạnh mẽ.

Nếu block có thể bị tái tổ chức, cam kết trạng thái của nó có thể bị thay thế bởi cam kết trạng thái khác từ một nhánh chain khác.

Điều này quan trọng với bridge, khoản rút, kiểm toán và thông điệp cross-chain.

Bridge không nên dựa vào cam kết trạng thái từ block có thể dễ dàng bị đảo ngược.

Light client nên hiểu mô hình finality của chain có trạng thái mà nó xác minh.

Một số chain có finality xác suất, trong đó mức độ tin cậy tăng dần theo thời gian.

Một số chain có finality kinh tế rõ ràng hoặc theo kiểu BFT.

Cam kết chứng minh trạng thái tương ứng với một block.

Finality cho người dùng biết họ nên tin tưởng bao nhiêu rằng block sẽ tiếp tục là block chính thức.

State proof mạnh nhất khi cam kết block nền tảng cũng đã finality theo các quy tắc đồng thuận liên quan.

Cam kết trạng thái và cơ chế đồng thuận

Cơ chế đồng thuận và cam kết trạng thái hoạt động cùng nhau, nhưng không phải là một.

Đồng thuận quyết định block nào được chấp nhận và theo thứ tự nào.

Hàm chuyển đổi trạng thái thực thi các block đó và tạo trạng thái mới.

Cam kết trạng thái tóm tắt trạng thái mới đó.

Nếu cơ chế đồng thuận chấp nhận block có state root sai, các node trung thực phải từ chối block đó trong quá trình xác thực thực thi.

Nếu node bất đồng về quy tắc thực thi, chúng có thể tính các cam kết trạng thái khác nhau và phân tách.

Đây là lý do các triển khai client phải tính cam kết trạng thái chính xác theo quy tắc giao thức.

Cam kết trạng thái có ý nghĩa cốt yếu đối với đồng thuận vì chúng đại diện cho kết quả thực thi đã được thống nhất.

Chúng không chỉ là chỉ mục cơ sở dữ liệu hoặc metadata tùy chọn.

Cam kết trạng thái sai có thể làm block không hợp lệ.

Cam kết trạng thái và nhà cung cấp RPC

Nhà cung cấp RPC là các dịch vụ mà ví và dApp sử dụng để đọc và gửi dữ liệu blockchain.

Khi ví yêu cầu số dư, nhà cung cấp RPC đọc trạng thái từ node.

Khi dApp kiểm tra giá trị hợp đồng, nhà cung cấp có thể đọc dữ liệu lưu trữ hợp đồng hoặc mô phỏng thực thi dựa trên trạng thái hiện tại.

Tuy nhiên, phản hồi RPC thông thường không phải lúc nào cũng là proof mật mã học.

Nó có thể chỉ là giá trị do nhà cung cấp báo cáo.

Cam kết trạng thái cho phép xác minh mạnh hơn khi nhà cung cấp cũng cung cấp dữ liệu proof.

Với Ethereum, EIP-1186 định nghĩa eth_getProof cho proof tài khoản và lưu trữ.

Điều này nghĩa là các ứng dụng cần độ đảm bảo cao hơn có thể yêu cầu dữ liệu proof thay vì tin cậy phản hồi thông thường.

Phần lớn người dùng thông thường không tự xác minh các proof này.

Tuy vậy, cam kết trạng thái tạo nền tảng cho các công cụ có thể giảm yêu cầu tin cậy vào nhà cung cấp hạ tầng.

Cam kết trạng thái và indexer

Indexer tổ chức dữ liệu blockchain để ứng dụng có thể tìm kiếm nhanh.

Chúng có thể theo dõi chuyển token, quyền sở hữu NFT, vị thế DeFi, phiếu bầu quản trị hoặc hoạt động tài khoản.

Indexer hữu ích vì trạng thái thô và log có thể khó truy vấn trực tiếp.

Tuy nhiên, dữ liệu được lập chỉ mục không giống cam kết trạng thái.

Indexer có thể mắc lỗi, chậm hơn chain hoặc dùng quy tắc diễn giải riêng.

Cam kết trạng thái là một phần của hệ thống xác minh mật mã học thuộc giao thức.

Đối với ứng dụng giá trị cao hoặc nhạy cảm về bảo mật, dữ liệu được lập chỉ mục có thể cần được kiểm tra dựa trên trạng thái hoặc biên lai đã cam kết.

Điều này đặc biệt quan trọng khi đầu ra indexer kích hoạt hành động tài chính.

Indexer cải thiện khả năng sử dụng, còn cam kết trạng thái cải thiện khả năng xác minh.

Một ứng dụng crypto đáng tin cậy nên hiểu sự khác biệt này.

Cam kết trạng thái và quyền riêng tư

Cam kết trạng thái có thể hỗ trợ các hệ thống bảo vệ quyền riêng tư, nhưng không tự động mang tính riêng tư.

Trên blockchain công khai, cam kết trạng thái thường tóm tắt trạng thái công khai hoặc có thể được suy ra công khai.

Tùy theo chain và công cụ, bất kỳ ai cũng có thể kiểm tra số dư, dữ liệu lưu trữ hợp đồng và lịch sử giao dịch.

Hệ thống bảo vệ quyền riêng tư có thể sử dụng cam kết theo cách khác.

Ví dụ, giao thức có thể cam kết với các giá trị ẩn và dùng zero-knowledge proof để cho thấy các chuyển đổi hợp lệ mà không tiết lộ mọi chi tiết.

Trong các hệ thống đó, cam kết có thể che giấu dữ liệu mà vẫn hỗ trợ xác minh.

Vì vậy, từ commitment có nghĩa rộng hơn state root công khai.

Cam kết trạng thái có thể minh bạch, riêng tư hoặc riêng tư một phần tùy theo thiết kế.

Người dùng không nên cho rằng cam kết trạng thái che giấu dữ liệu trừ khi giao thức cung cấp rõ ràng tính năng bảo mật quyền riêng tư.

Phần lớn cam kết trạng thái trên chain công khai tập trung vào tính toàn vẹn hơn là tính bảo mật thông tin.

Cam kết trạng thái và zero-knowledge proof

Zero-knowledge proof thường sử dụng cam kết để biểu diễn trạng thái trước và sau thực thi.

Prover có thể cho thấy quá trình chuyển từ cam kết trạng thái này sang cam kết trạng thái khác là hợp lệ mà không buộc bên xác minh thực thi lại mọi thứ.

Điều này phổ biến trong validity rollup, hệ thống riêng tư và mô hình thực thi nén.

Proof có thể cho biết cam kết trạng thái mới xuất phát từ cam kết trạng thái cũ và một tập thao tác hợp lệ.

Tùy hệ thống, một phần dữ liệu có thể công khai và một phần có thể được giữ ẩn.

Điều này biến cam kết thành cầu nối giữa xác minh nhỏ gọn và tính toán phức tạp.

Cam kết trạng thái xác định điều đang được chứng minh.

Zero-knowledge proof xác định vì sao quá trình chuyển đổi nên được chấp nhận.

Kết hợp lại, chúng cho phép hệ thống mở rộng hoặc bảo vệ quyền riêng tư trong khi vẫn duy trì tính chính xác có thể xác minh.

Đây là một trong những ứng dụng nâng cao quan trọng nhất của cam kết trạng thái trong hạ tầng crypto hiện đại.

Cam kết trạng thái và proof không có mặt

Proof không có mặt cho thấy một khóa hoặc giá trị không hiện diện trong trạng thái đã cam kết.

Proof có mặt cho thấy một thứ tồn tại.

Proof không có mặt cho thấy một thứ không tồn tại.

Điều này có thể quan trọng đối với tạo tài khoản, kiểm tra nullifier, sparse Merkle tree, hệ thống danh tính và yêu cầu airdrop.

Ví dụ, hệ thống riêng tư có thể cần chứng minh nullifier chưa được sử dụng trước đó.

Bridge có thể cần chứng minh thông điệp chưa từng được sử dụng.

Cơ quan đăng ký có thể cần chứng minh tên hoặc khóa vẫn chưa được cấp.

Một số cấu trúc cam kết giúp tạo proof không có mặt dễ hơn cấu trúc khác.

Đây là một lý do thiết kế cam kết trạng thái quan trọng vượt ngoài các proof số dư đơn giản.

Hệ thống cam kết trạng thái tốt phải hỗ trợ các loại proof mà giao thức thực sự cần.

Cam kết trạng thái và giả định bảo mật

Cam kết trạng thái phụ thuộc vào các giả định mật mã học.

Cam kết dựa trên hash phụ thuộc vào khả năng chống va chạm và khả năng chống tìm ảnh gốc của hàm hash.

Vector commitment có thể phụ thuộc vào những giả định toán học khác tùy theo cơ chế.

Nếu cơ chế mật mã học nền tảng bị phá vỡ, cam kết có thể không còn đáng tin cậy.

Bảo mật triển khai cũng quan trọng.

Một cơ chế cam kết chính xác vẫn có thể nguy hiểm nếu phần mềm client mã hóa giá trị sai hoặc xác minh proof không đúng.

Mã nguồn có ý nghĩa cốt yếu đối với đồng thuận phải xử lý chính xác các trường hợp biên.

Các client khác nhau phải tính cùng cam kết từ cùng trạng thái.

Đây là lý do thay đổi cam kết trạng thái được xử lý cẩn thận trong các đợt nâng cấp blockchain lớn.

Thay đổi cấu trúc cam kết là thay đổi một phần sâu trong mô hình bảo mật của chain.

Cam kết trạng thái và công cụ dành cho nhà phát triển

Nhà phát triển gặp cam kết trạng thái qua phương thức RPC, hệ thống proof, block header, state root rollup, storage proof và cơ sở dữ liệu client.

Nhà phát triển hợp đồng thông minh có thể cần biết số dư token được lưu thế nào để tạo proof.

Nhà phát triển bridge có thể cần xác minh storage proof dựa trên root đã finality.

Nhà phát triển rollup có thể cần tính và công bố state root sau các batch.

Nhà phát triển ví có thể cần quyết định nên tin cậy giá trị RPC hay xác minh proof.

Nhà phát triển indexer có thể cần đối chiếu sự kiện đã lập chỉ mục với trạng thái đã cam kết.

Nhà nghiên cứu giao thức có thể so sánh Merkle Patricia Trie, sparse Merkle tree, Verkle tree và các accumulator khác.

Đây đều là các vấn đề cam kết trạng thái dưới những hình thức khác nhau.

Hiểu khái niệm này giúp nhà phát triển tránh nhầm lẫn giữa việc giao dịch được đưa vào, log sự kiện, biên lai và trạng thái thực tế.

Hệ thống an toàn nhất làm rõ cam kết nào đang được xác minh và giá trị trạng thái nào đang được chứng minh.

Những hiểu lầm phổ biến về cam kết trạng thái

Một hiểu lầm phổ biến là cam kết trạng thái chứa toàn bộ trạng thái.

Nó không chứa toàn bộ trạng thái vì chỉ là bản tóm tắt mật mã học nhỏ gọn của trạng thái đó.

Một hiểu lầm khác là transaction proof giống state proof.

Transaction proof có thể cho thấy giao dịch được đưa vào, còn state proof có thể cho thấy giá trị trạng thái kết quả.

Hiểu lầm thứ ba là cam kết trạng thái làm dữ liệu trở nên khả dụng.

Cam kết chứng minh tính toàn vẹn, nhưng tính khả dụng dữ liệu là yêu cầu riêng biệt.

Hiểu lầm thứ tư là mọi blockchain đều cam kết với trạng thái theo cùng một cách.

Các chain khác nhau dùng mô hình trạng thái và cấu trúc cam kết khác nhau.

Hiểu lầm thứ năm là cam kết trạng thái tự động đồng nghĩa với quyền riêng tư.

Phần lớn cam kết trạng thái công khai cung cấp tính toàn vẹn và khả năng xác minh, không phải tính bảo mật thông tin.

Lợi ích của cam kết trạng thái

Lợi ích đầu tiên của cam kết trạng thái là xác minh nhỏ gọn.

Một root nhỏ có thể đại diện cho cơ sở dữ liệu trạng thái rất lớn.

Lợi ích thứ hai là khả năng phát hiện giả mạo.

Thay đổi trạng thái nền tảng sẽ thay đổi cam kết.

Lợi ích thứ ba là hỗ trợ proof.

Người dùng có thể xác minh giá trị cụ thể bằng proof có mặt hoặc proof không có mặt.

Lợi ích thứ tư là hỗ trợ light client.

Light client có thể kiểm tra các giá trị trạng thái được chọn mà không cần lưu toàn bộ trạng thái.

Lợi ích thứ năm là hỗ trợ mở rộng.

Rollup và hệ thống proof sử dụng cam kết trạng thái để tóm tắt các batch thực thi lớn.

Lợi ích thứ sáu là xác minh cross-chain.

Bridge và hệ thống truyền tin có thể xác minh tuyên bố dựa trên cam kết từ chain hoặc layer khác.

Lợi ích thứ bảy là khả năng kiểm toán.

Cam kết trạng thái giúp cho thấy mỗi block tạo ra một trạng thái cụ thể đã được thống nhất.

Hạn chế của cam kết trạng thái

Hạn chế đầu tiên là chỉ riêng cam kết không cung cấp dữ liệu nền tảng.

Người dùng vẫn cần tính khả dụng dữ liệu và dữ liệu proof để xác minh tuyên bố.

Hạn chế thứ hai là kích thước proof.

Một số cấu trúc cam kết tạo ra proof quá lớn để xác minh light client hoặc stateless hiệu quả.

Hạn chế thứ ba là chi phí cập nhật.

Cập nhật cam kết sau nhiều thay đổi trạng thái có thể tốn nhiều tài nguyên tính toán.

Hạn chế thứ tư là độ phức tạp triển khai.

Việc mã hóa, hash, tạo proof và xác minh proof phải chính xác.

Hạn chế thứ năm là truy cập lịch sử.

Cam kết cũ có thể tồn tại trong block header, nhưng việc tạo proof có thể cần dữ liệu trạng thái cũ từ archive node.

Hạn chế thứ sáu là giả định bảo mật.

Các cơ chế cam kết khác nhau phụ thuộc vào những bảo đảm mật mã học khác nhau.

Hạn chế thứ bảy là người dùng khó nhận biết.

Phần lớn người dùng không trực tiếp thấy cam kết trạng thái, do đó ví và ứng dụng phải giải thích rõ về bảo mật dựa trên proof.

Cách đánh giá hệ thống cam kết trạng thái

Hãy bắt đầu bằng cách xác định trạng thái nào đang được cam kết.

Sau đó kiểm tra cấu trúc dữ liệu nào tạo ra cam kết.

Xem xét liệu cam kết có hỗ trợ proof có mặt hay không.

Xem xét liệu nó có hỗ trợ proof không có mặt khi ứng dụng cần hay không.

Kiểm tra kích thước proof và chi phí xác minh.

Kiểm tra chi phí cập nhật khi nhiều giá trị trạng thái thay đổi.

Xem xét các giả định mật mã học phía sau cơ chế cam kết.

Kiểm tra dữ liệu proof cho trạng thái hiện tại và lịch sử có dễ tiếp cận không.

Xem xét liệu cam kết có được đưa vào block đã finality, batch rollup hoặc điểm neo đáng tin cậy khác không.

Hãy đặt câu hỏi liệu tính khả dụng dữ liệu có được giải quyết riêng với bản thân cam kết hay không.

Thực tiễn tốt nhất cho nhà phát triển

Sử dụng tài liệu giao thức chính thức trước khi triển khai xác minh proof.

Phân tách transaction inclusion proof và state proof trong thiết kế.

Xác minh proof dựa trên các cam kết đáng tin cậy và đã finality khi có thể.

Không giả định sự kiện và log giống các giá trị lưu trữ đã cam kết.

Hiểu bố cục lưu trữ hợp đồng trước khi chứng minh số dư token, quyền sở hữu NFT hoặc quyền quản trị.

Lập kế hoạch tạo proof lịch sử nếu ứng dụng cần snapshot trạng thái cũ.

Cân nhắc tính khả dụng dữ liệu bên cạnh việc xác minh cam kết trạng thái.

Kiểm toán kỹ mã xác minh proof vì lỗi mã hóa nhỏ có thể trở thành lỗ hổng nghiêm trọng.

Theo dõi các thay đổi trong lộ trình, chẳng hạn nghiên cứu Verkle tree, nếu hệ thống phụ thuộc sâu vào state proof Ethereum.

Ghi lại ứng dụng chứng minh điều gì, sử dụng cam kết nào và những giả định nào vẫn còn.

Thực tiễn tốt nhất cho người dùng

Hãy hiểu rằng số dư hiển thị có thể đến từ nhà cung cấp RPC hoặc indexer, thay vì từ proof do chính bạn xác minh.

Sử dụng ví và trình khám phá đáng tin cậy, nhưng hãy nhớ rằng các hệ thống giá trị cao có thể cần xác minh dựa trên proof mạnh hơn.

Thận trọng với các bridge tuyên bố xác minh trạng thái từ chain khác.

Kiểm tra bridge phụ thuộc vào proof gốc, validator, relayer, multisig hay ủy ban bên ngoài hay không.

Hãy hiểu cam kết trạng thái không đảm bảo mọi dữ liệu đều dễ truy cập.

Hãy nhớ rằng trạng thái cũ có thể cần hạ tầng archive để chứng minh hiệu quả.

Không giả định việc giao dịch được đưa vào đồng nghĩa thay đổi trạng thái cuối cùng đã diễn ra thành công.

Chờ finality đầy đủ trước khi dựa vào cam kết trạng thái cho các hành động có giá trị cao.

Sử dụng giao dịch thử với số tiền nhỏ khi tương tác với hệ thống phụ thuộc vào state proof cross-chain.

Chỉ xem các tuyên bố dựa trên proof mạnh hơn tuyên bố thông thường khi proof thực sự được xác minh dựa trên cam kết chính xác.

FAQ

Cam kết trạng thái trong crypto có nghĩa là gì?

Cam kết trạng thái là một root hoặc cam kết mật mã học đại diện cho trạng thái hiện tại của blockchain theo cách nhỏ gọn và có thể xác minh.

Cam kết trạng thái có giống state root không?

State root là một dạng cam kết trạng thái phổ biến, đặc biệt trong blockchain theo kiểu Ethereum.

Cam kết trạng thái chứng minh điều gì?

Cam kết trạng thái không tự chứng minh một giá trị, nhưng cho phép người dùng xác minh giá trị khi kết hợp với state proof hợp lệ.

Vì sao Ethereum sử dụng state root?

Ethereum sử dụng state root để cam kết với world state toàn cục sau khi mỗi block được thực thi.

Khác biệt giữa cam kết trạng thái và transaction root là gì?

Cam kết trạng thái đại diện cho trạng thái blockchain kết quả, trong khi transaction root cam kết với các giao dịch được đưa vào block.

Merkle proof là gì?

Merkle proof là dữ liệu hỗ trợ giúp bên xác minh kiểm tra liệu một giá trị có thuộc về trạng thái được cam kết bởi root hay không.

Rollup sử dụng cam kết trạng thái như thế nào?

Rollup sử dụng cam kết trạng thái để tóm tắt trạng thái Layer 2 sau khi các batch giao dịch được thực thi.

Cam kết trạng thái có giải quyết tính khả dụng dữ liệu không?

Không. Cam kết trạng thái chứng minh tính toàn vẹn, còn tính khả dụng dữ liệu đảm bảo dữ liệu cần để xác minh hoặc tái tạo chuyển đổi trạng thái có thể truy cập.

Verkle tree là gì?

Verkle tree là cấu trúc cam kết trạng thái được đề xuất, sử dụng vector commitment để hỗ trợ witness nhỏ hơn và xác thực stateless hiệu quả hơn.

Cam kết trạng thái có riêng tư không?

Không phải lúc nào cũng vậy, vì phần lớn cam kết trạng thái trên chain công khai cung cấp khả năng xác minh thay vì tính bảo mật thông tin, trừ khi kết hợp với mật mã học bảo vệ quyền riêng tư.

Kết luận

Cam kết trạng thái là cam kết mật mã học nhỏ gọn với trạng thái đang hoạt động của blockchain tại một thời điểm cụ thể.

Nó cho phép tập dữ liệu lớn gồm số dư, tài khoản, dữ liệu lưu trữ hợp đồng và dữ liệu ứng dụng được đại diện bằng root hoặc giá trị cam kết nhỏ.

Trong Ethereum, state root là cam kết trạng thái chính cho trạng thái execution layer toàn cục.

Root này được tạo từ Merkle Patricia Trie và thay đổi bất cứ khi nào trạng thái nền tảng thay đổi.

Cam kết trạng thái thiết yếu đối với đồng thuận, light client, Merkle proof, rollup, bridge, kiểm toán và nghiên cứu stateless client.

Chúng giúp người dùng xác minh các tuyên bố về trạng thái mà không cần mù quáng tin cậy nhà cung cấp cơ sở dữ liệu.

Chúng cũng hỗ trợ các hệ thống nâng cao như fraud proof, validity proof và truyền tin cross-chain.

Tuy nhiên, cam kết trạng thái không giống tính khả dụng dữ liệu đầy đủ, việc giao dịch được đưa vào, log biên lai hoặc quyền riêng tư.

Nó phải kết hợp với proof phù hợp, dữ liệu phù hợp và các giả định finality phù hợp.

Thiết kế cam kết trạng thái tiếp tục phát triển khi blockchain tìm kiếm proof nhỏ hơn, cập nhật nhanh hơn và yêu cầu thấp hơn đối với node.

Verkle tree và nghiên cứu statelessness cho thấy tương lai của cam kết trạng thái vẫn là chủ đề tích cực trong kỹ thuật và mật mã học.

Trong ngữ cảnh thuật ngữ crypto, State Commitment là điểm neo mật mã học cho phép blockchain chứng minh trạng thái của mình mà không cần đặt toàn bộ trạng thái vào mọi block header.

Điểm chính cần nhớ là cam kết trạng thái biến trạng thái blockchain khổng lồ thành root có thể xác minh, giúp việc xác minh giảm thiểu yêu cầu tin cậy trở nên khả thi trên node, ví, rollup, bridge và ứng dụng.