State Trie

State Trie trong crypto là gì?

State trie là cấu trúc dữ liệu mật mã lưu trữ trạng thái hiện tại của blockchain theo cách có thể được cập nhật, xác minh hiệu quả và tóm tắt bằng một hash gốc duy nhất.

Trong các blockchain theo kiến trúc Ethereum, state trie ánh xạ địa chỉ tài khoản đến dữ liệu tài khoản như số dư, nonce, root lưu trữ của hợp đồng thông minh và hash mã.

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

State trie toàn cục này là một trong những thành phần quan trọng nhất của execution layer Ethereum vì nó đại diện cho trạng thái đang hoạt động của mạng sau khi giao dịch được áp dụng.

State trie không giống danh sách giao dịch trong quá khứ.

Giao dịch mô tả điều đã xảy ra, còn state trie mô tả trạng thái hiện tại của blockchain sau khi các giao dịch đó thay đổi số dư, dữ liệu lưu trữ hợp đồng và dữ liệu tài khoản.

Ví dụ, khi người dùng gửi ETH từ tài khoản này sang tài khoản khác, giao dịch được ghi trong block nhưng state trie thay đổi vì số dư của hai tài khoản được cập nhật.

Khi người dùng gọi hợp đồng thông minh, giao dịch vẫn được ghi trong block, nhưng state trie có thể thay đổi do dữ liệu lưu trữ hợp đồng, số dư và nonce tài khoản có thể được cập nhật.

Nói đơn giản, state trie là cơ sở dữ liệu đã được xác thực chứa trạng thái tài khoản hiện tại của blockchain.

Vì sao state trie quan trọng?

State trie quan trọng vì blockchain cần một cách an toàn để chứng minh trạng thái hiện tại.

Trạng thái blockchain có thể gồm hàng triệu tài khoản, hợp đồng thông minh, số dư, mục lưu trữ và các giá trị khác. Các node phải đồng thuận về trạng thái này để quyết định giao dịch mới có hợp lệ hay không.

Nếu người gửi không đủ số dư, giao dịch phải thất bại. Nếu một storage slot của hợp đồng có giá trị nhất định, lệnh gọi hợp đồng thông minh có thể hoạt động khác. Nếu nonce đã được dùng, giao dịch phát lại không được chấp nhận.

State trie cung cấp cho client một cấu trúc xác định để lưu trữ và kiểm tra các giá trị này. Nó cũng tạo ra một state root duy nhất có thể được đưa vào block header.

Nếu hai client xử lý cùng một block và đạt cùng state root, đây là bằng chứng mạnh cho thấy họ đồng thuận về trạng thái kết quả.

Nhờ đó, state trie là thành phần cốt lõi của cơ chế đồng thuận blockchain, xác minh, proof cho light client, đồng bộ node, thực thi hợp đồng thông minh và tính toàn vẹn dữ liệu.

State trie và state root

State root là hash gốc của state trie sau khi tất cả giao dịch trong một block được xử lý.

Block header Ethereum bao gồm stateRoot, cam kết với toàn bộ trạng thái toàn cục tại block đó. Tài liệu Merkle Patricia Trie của Ethereum cho biết block header ở execution layer chứa các root cho state trie, transactions trie và receipts trie.

State root quan trọng vì đây là cam kết mật mã gọn nhẹ đối với một cơ sở dữ liệu lớn hơn rất nhiều.

Nếu có proof hợp lệ, người dùng không cần tải mọi tài khoản và giá trị lưu trữ hợp đồng để xác minh một tuyên bố cụ thể. Thay vào đó, họ có thể xác minh rằng một giá trị thuộc trạng thái được state root cam kết.

Nếu số dư tài khoản, storage root hợp đồng, nonce hoặc code hash thay đổi, đường dẫn hash dẫn tới root cũng thay đổi. Vì vậy, trạng thái khác phải tạo ra state root khác.

Do đó, state root là dấu vân tay của toàn bộ trạng thái blockchain tại một block cụ thể và giúp biến cơ sở dữ liệu trạng thái khổng lồ thành một giá trị có thể xác minh.

State trie hoạt động như thế nào?

State trie Ethereum sử dụng Merkle Patricia Trie đã được sửa đổi.

Merkle Patricia Trie kết hợp các ý tưởng từ Merkle tree, radix trie và Patricia trie. Trie là cấu trúc key-value dạng cây, trong đó đường đi trong cây dựa trên key. Patricia trie nén các đường dẫn để cây không lãng phí không gian cho những chuỗi node rỗng dài.

Merkle tree bổ sung các hash mật mã để dữ liệu có thể được xác minh thông qua các đường dẫn hash. Ethereum kết hợp các đặc điểm này để client có thể lưu trạng thái tài khoản, cập nhật hiệu quả và xác minh bằng root hash cùng Merkle proof.

Trong state trie Ethereum, đường dẫn dựa trên hash Keccak-256 của địa chỉ tài khoản. Giá trị lưu tại đường dẫn đó là đối tượng tài khoản được mã hóa RLP.

Tài liệu Ethereum chính thức nêu rằng đối tượng tài khoản Ethereum là một mảng gồm bốn phần tử: nonce, balance, storageRoot và codeHash.

Thiết kế này giúp mỗi tài khoản có thể được truy cập qua một đường dẫn mật mã xác định.

Dữ liệu nào được lưu trong state trie?

State trie lưu đối tượng tài khoản thay vì trực tiếp lưu mọi giá trị lưu trữ hợp đồng trong trie toàn cục chính.

Mỗi đối tượng tài khoản Ethereum chứa nonce, balance, storageRoot và codeHash.

Nonce giúp ngăn phát lại giao dịch và theo dõi hoạt động tài khoản. Balance ghi lại lượng tiền mã hóa gốc mà tài khoản nắm giữ. storageRoot trỏ đến một trie khác lưu dữ liệu hợp đồng thông minh của tài khoản. codeHash cam kết với bytecode hợp đồng thông minh liên kết với tài khoản hợp đồng.

Tài khoản sở hữu bên ngoài thường có mã trống và dữ liệu lưu trữ hợp đồng trống. Tài khoản hợp đồng thông minh có thể có mã và dữ liệu lưu trữ ảnh hưởng đến cách chúng thực thi.

State trie và storage trie

State trie và storage trie có liên quan nhưng khác nhau.

State trie là cấu trúc toàn cục ánh xạ địa chỉ tài khoản đến đối tượng tài khoản. Storage trie là trie riêng được dùng cho dữ liệu lưu trữ của một tài khoản hợp đồng thông minh cụ thể.

Tài liệu Ethereum giải thích rằng mỗi tài khoản có dữ liệu lưu trữ hợp đồng sẽ có một storage trie riêng. Đối tượng tài khoản trong state trie lưu storageRoot, tức root của storage trie tài khoản đó.

Điều này có nghĩa state trie toàn cục không trực tiếp chứa mọi storage slot của mọi hợp đồng. Thay vào đó, nó chứa đối tượng tài khoản và mỗi tài khoản hợp đồng có thể trỏ đến storage trie riêng.

Ví dụ, hợp đồng token có thể lưu số dư người dùng trong storage trie của chính hợp đồng. State trie toàn cục lưu đối tượng tài khoản hợp đồng token, và đối tượng đó trỏ đến storage root của hợp đồng token.

Thiết kế phân tầng này giúp tách trạng thái cấp tài khoản khỏi dữ liệu lưu trữ cấp hợp đồng.

State trie và transactions trie

State trie khác transactions trie. State trie lưu trạng thái tài khoản kết quả sau khi giao dịch được thực thi, còn transactions trie lưu các giao dịch có trong một block cụ thể.

Mỗi block có transactions trie riêng. Transactions trie không được cập nhật liên tục giữa các block như state trie toàn cục.

State trie phát triển từ block này sang block khác khi giao dịch thay đổi số dư tài khoản và dữ liệu lưu trữ hợp đồng. Có thể hiểu giao dịch là chỉ dẫn, còn state trie là kết quả sau khi các chỉ dẫn được áp dụng.

Sự khác biệt này quan trọng vì blockchain không chỉ là nhật ký giao dịch có thứ tự. Nó còn là một state machine, trong đó mỗi giao dịch hợp lệ đưa hệ thống từ trạng thái này sang trạng thái tiếp theo.

State trie và receipts trie

State trie cũng khác receipts trie. Receipts trie lưu biên lai giao dịch của một block. Biên lai ghi nhận kết quả thực thi như trạng thái, lượng gas đã dùng, log và dữ liệu sự kiện.

State trie ghi nhận trạng thái tài khoản cuối cùng sau thực thi. Receipts giúp ứng dụng hiểu điều gì xảy ra khi giao dịch thực thi, còn state trie giúp client xác minh trạng thái blockchain đã trở thành gì sau thực thi.

Ví dụ, một giao dịch hợp đồng thông minh có thể phát ra sự kiện được ghi trong receipt. Giao dịch đó cũng có thể thay đổi dữ liệu lưu trữ hợp đồng được ghi nhận thông qua state trie và storage trie.

Cả hai cấu trúc đều quan trọng nhưng trả lời các câu hỏi khác nhau: receipts trie trả lời giao dịch tạo ra gì, còn state trie trả lời trạng thái chain hiện tại là gì.

Các node của Merkle Patricia Trie

Merkle Patricia Trie sửa đổi của Ethereum sử dụng nhiều loại node. Tài liệu Ethereum chính thức mô tả branch node, leaf node, extension node và empty node.

Branch node có thể trỏ đến tối đa 16 đường dẫn node con và cũng có thể giữ một giá trị. Leaf node lưu đường dẫn và giá trị mã hóa cuối cùng. Extension node nén một đoạn đường dẫn chung để trie tránh các chuỗi node thưa dài.

Thiết kế này hữu ích vì key Ethereum dài và thưa. Nếu không nén đường dẫn, nhiều thao tác tra cứu sẽ lãng phí bước trên các đường dẫn rỗng hoặc không phân nhánh.

Bằng extension node và leaf node, Ethereum làm trie gọn hơn radix trie cơ bản. Bằng hash, Ethereum khiến trie có thể xác minh bằng mật mã. Sự kết hợp này là lý do cấu trúc được gọi là Merkle Patricia Trie sửa đổi.

Mã hóa RLP và hashing

Ethereum sử dụng mã hóa Recursive Length Prefix, thường gọi là RLP, để tuần tự hóa nhiều cấu trúc dữ liệu trong execution layer.

Trong state trie, đối tượng tài khoản được mã hóa RLP trước khi đặt làm giá trị. Node trie cũng được mã hóa trước khi được hash hoặc lưu trữ.

Tài liệu Merkle Patricia Trie Ethereum giải thích rằng khi node này tham chiếu node khác, tham chiếu có thể là hash Keccak-256 của node được mã hóa RLP tùy theo độ dài mã hóa.

Điều này quan trọng vì mọi node phải được mã hóa theo cách xác định. Nếu hai client mã hóa cùng trạng thái khác nhau, họ có thể tính các root khác nhau và không thể đồng thuận.

Vì vậy, mã hóa xác định là chi tiết then chốt đối với đồng thuận. Hashing cũng làm hành vi can thiệp trở nên dễ phát hiện vì thay đổi một giá trị sẽ thay đổi hash node và đường dẫn hash trở lại root.

Kết quả là cơ sở dữ liệu key-value có thể xác minh, trong đó một root hash cam kết với mọi giá trị được bao gồm. Đây là nền tảng mật mã của state proof.

State proof

State proof là proof mật mã chứng minh một tài khoản hoặc giá trị lưu trữ nhất định tồn tại trong trạng thái được một state root cụ thể cam kết.

Đề xuất EIP-1186 eth_getProof giải thích rằng trạng thái dựa trên Merkle tree của Ethereum cho phép xác minh giá trị tài khoản và dữ liệu lưu trữ thông qua Merkle proof.

Một proof thường chứa các node cần thiết để tái tạo đường dẫn từ giá trị mục tiêu đến state root. Nếu hash tái tạo khớp state root đáng tin cậy, giá trị có thể được xác minh mà không cần tin tưởng hoàn toàn nhà cung cấp dữ liệu.

Điều này hữu ích cho light client, bridge, ứng dụng cross-chain, ví di động, kiểm toán viên và hệ thống hợp đồng thông minh cần xác minh trạng thái bên ngoài.

Ví dụ, proof có thể chứng minh một tài khoản có số dư nhất định tại một block cụ thể, hoặc một storage slot hợp đồng có giá trị nhất định tại block cụ thể.

State proof mạnh mẽ vì cho phép xác minh có chọn lọc thay vì tải toàn bộ cơ sở dữ liệu trạng thái. State trie giúp các proof này khả thi. Nếu không có cấu trúc trạng thái đã xác thực, người dùng sẽ cần đặt nhiều niềm tin hơn vào nhà cung cấp RPC và indexer.

eth_getProof

eth_getProof là phương thức Ethereum JSON-RPC được thiết kế để trả về giá trị tài khoản, giá trị lưu trữ và Merkle proof tương ứng.

EIP-1186 định nghĩa eth_getProof là phương thức trả về giá trị tài khoản và dữ liệu lưu trữ của tài khoản được chỉ định cùng dữ liệu proof.

Proof có thể bao gồm dữ liệu accountProof theo đường dẫn từ state root và dữ liệu storageProof theo đường dẫn từ storage root của hợp đồng.

Phương thức này hữu ích khi ứng dụng cần bằng chứng thay vì chỉ một phản hồi RPC thô. Ví dụ, ví hoặc bridge có thể muốn xác minh storage slot đối chiếu với state root của block.

Truy vấn số dư đơn giản chỉ báo cáo giá trị, còn truy vấn proof báo cáo giá trị cùng dữ liệu mật mã cần thiết để kiểm tra giá trị đó.

Sự khác biệt này quan trọng vì nhà cung cấp RPC có thể sai, bị kiểm duyệt, có lỗi hoặc có hành vi độc hại. Merkle proof giúp người dùng giảm mức độ tin cậy vào nhà cung cấp bằng cách đối chiếu proof với block header đáng tin cậy.

State trie và full node

Full node cần trạng thái hiện tại để xác minh block và giao dịch mới.

Tài liệu archive node Ethereum chính thức giải thích rằng dữ liệu toàn cục về từng tài khoản và hợp đồng được lưu trong cơ sở dữ liệu trie gọi là state.

Full node theo dõi trạng thái mới nhất của mạng để xác thực các block và giao dịch đến. Full node thường không lưu mọi trạng thái lịch sử vĩnh viễn.

Chúng có thể lưu trạng thái mới nhất và đủ dữ liệu trạng thái gần đây để xử lý tái tổ chức chain và vận hành mạng thông thường. Trạng thái lịch sử cũ thường có thể được cắt tỉa vì không cần cho việc xác minh tiêu chuẩn ở chain tip mới nhất.

Đây là lý do truy vấn số dư cũ hoặc dữ liệu lưu trữ hợp đồng cũ có thể khó trên full node thông thường. Trạng thái hiện tại cần thiết cho vận hành mạng, còn mọi trạng thái trung gian lịch sử hữu ích cho phân tích và proof nhưng nặng hơn nhiều để lưu.

Do đó, state trie ảnh hưởng đến phần cứng node, đồng bộ, lưu trữ và tính phi tập trung.

State trie và archive node

Archive node lưu trạng thái lịch sử thay vì chỉ giữ trạng thái hiện tại và các trạng thái gần đây.

Tài liệu archive node Ethereum giải thích rằng archive node lưu mọi trạng thái lịch sử được tạo sau mỗi block, đánh đổi yêu cầu ổ đĩa lớn hơn để đổi lấy truy vấn lịch sử nhanh.

Điều này quan trọng với trình khám phá blockchain, kiểm toán viên, nhà nghiên cứu, đội ngũ bảo mật, công cụ thuế, nhà cung cấp phân tích và nhà phát triển dApp.

Ví dụ, người dùng có thể hỏi số dư tài khoản tại block từ nhiều năm trước. Full node có thể cần thực thi lại giao dịch lịch sử để tái tạo trạng thái đó, trong khi archive node thường có thể truy cập trực tiếp trạng thái lịch sử từ ổ đĩa.

Tốc độ này đi kèm yêu cầu lưu trữ lớn hơn nhiều. Lịch sử state trie do đó có giá trị nhưng tốn kém. Đây là lý do nhiều người dùng dựa vào nhà cung cấp hạ tầng để truy vấn trạng thái lịch sử.

Tuy nhiên, phụ thuộc vào nhà cung cấp có thể làm phát sinh rủi ro về niềm tin, khả dụng và kiểm duyệt.

State trie, hợp đồng thông minh và số dư token

Hợp đồng thông minh phụ thuộc nhiều vào state trie và storage trie. Đối tượng tài khoản của hợp đồng xuất hiện trong state trie toàn cục. Mã hợp đồng được cam kết qua codeHash, còn dữ liệu lưu trữ bền vững được cam kết qua storageRoot.

Khi hợp đồng thực thi, nó có thể đọc và ghi storage slot. Các thay đổi này cập nhật storage trie của hợp đồng, storageRoot mới cập nhật đối tượng tài khoản trong state trie toàn cục, và đối tượng tài khoản được cập nhật thay đổi state root toàn cục.

Vì vậy, ngay cả cập nhật nhỏ đối với dữ liệu lưu trữ hợp đồng cũng có thể thay đổi state root cuối cùng của block. State trie là một phần trong cách kết quả hợp đồng thông minh trở nên hiển thị với cơ chế đồng thuận.

Nhiều số dư token được lưu trong dữ liệu lưu trữ hợp đồng thông minh thay vì trực tiếp trong state trie toàn cục. Hợp đồng token có thể lưu mapping từ địa chỉ người dùng đến số dư token trong storage trie của chính nó.

State trie toàn cục lưu đối tượng tài khoản hợp đồng token, bao gồm storageRoot của hợp đồng đó. Vì vậy, số dư coin gốc và số dư token được lưu khác nhau.

Số dư coin gốc là một phần của đối tượng tài khoản trong state trie toàn cục. Số dư token thường là giá trị lưu trữ trong storage trie của hợp đồng token cụ thể.

Sự khác biệt này quan trọng đối với proof và kiểm toán. Để chứng minh số dư coin gốc, account proof thường là đủ. Để chứng minh số dư token, proof có thể cần cả account proof của hợp đồng token và storage proof cho balance slot liên quan.

State trie, light client và stateless client

Light client là client xác minh dữ liệu blockchain mà không lưu toàn bộ trạng thái. State trie hỗ trợ light client vì cho phép proof gọn nhẹ liên kết với block header.

Light client có thể tin tưởng hoặc xác minh block header, sau đó dùng Merkle proof để kiểm tra giá trị trạng thái cụ thể. Cách này rẻ hơn nhiều so với lưu toàn bộ trạng thái cục bộ.

Ví dụ, ví di động có thể muốn xác minh giá trị lưu trữ hợp đồng mà không chạy execution node đầy đủ. Bridge có thể muốn xác minh sự kiện rút tiền hoặc trạng thái tài khoản được bao gồm trong trạng thái chain khác.

State trie cung cấp cấu trúc xác thực cần thiết cho các quy trình này. Tuy nhiên, kích thước proof và chi phí tạo proof vẫn có thể đáng kể. Đây là một lý do các nhà nghiên cứu Ethereum đã xem xét các lựa chọn thay thế như Verkle tree.

Stateless client là ý tưởng mở rộng blockchain dài hạn, trong đó validator hoặc người dùng có thể xác minh block mà không lưu toàn bộ trạng thái cục bộ. Thay vì mọi validator lưu mọi trạng thái, block hoặc giao dịch sẽ bao gồm witness chứng minh trạng thái mà chúng chạm tới.

State trie có liên quan vì witness Merkle Patricia Trie hiện tại có thể lớn, khiến xác minh stateless kém hiệu quả.

Bài viết về cấu trúc Verkle tree của Ethereum Foundation giải thích rằng Verkle tree hoạt động tương tự Merkle tree nhưng có thể tạo witness nhỏ hơn đáng kể qua vector commitment.

Đây là lý do Verkle tree được nghiên cứu như phương án thay thế có thể có cho cấu trúc cam kết trạng thái hiện tại của Ethereum. State trie hiện tại an toàn và đã được kiểm chứng thực tế, nhưng không được thiết kế để tạo witness stateless nhỏ nhất có thể.

State trie và Verkle tree

Verkle tree là cấu trúc cam kết trạng thái được đề xuất, sử dụng vector commitment thay vì chỉ liên kết hash.

Ethereum.org cho biết Ethereum dự định chuyển sang cấu trúc Verkle Tree trong tương lai, dù thời gian triển khai giao thức và chi tiết thực hiện có thể thay đổi.

Verkle tree được thiết kế để proof nhỏ hơn proof Merkle Patricia Trie. Bài viết Ethereum Foundation giải thích thiết kế Verkle tree cũng hợp nhất account trie và storage trie theo bố cục khác.

Đây sẽ là thay đổi lớn vì Ethereum hiện dùng state trie toàn cục kết hợp storage trie theo từng tài khoản. Mô hình trạng thái dựa trên Verkle có thể giúp stateless client thực tế hơn.

Tuy nhiên, việc chuyển từ state trie hoạt động lâu dài sang cấu trúc cam kết mới rất phức tạp, ảnh hưởng đến client, proof, ví, node, quy tắc thực thi, bố cục lưu trữ và các giả định của nhà phát triển.

Vì vậy, state trie vừa là nền tảng hiện tại vừa là lĩnh vực nghiên cứu giao thức đang tiếp diễn. Hiểu state trie giúp người dùng hiểu vì sao nghiên cứu Verkle quan trọng.

State trie, state bloat và phí gas

State bloat nghĩa là trạng thái hoạt động của blockchain ngày càng lớn và khó duy trì hơn. State trie tăng lên khi nhiều tài khoản, hợp đồng, storage slot và dữ liệu ứng dụng vẫn hoạt động.

Trạng thái lớn làm tăng dung lượng ổ đĩa, thời gian đồng bộ, khối lượng công việc cơ sở dữ liệu và yêu cầu phần cứng. Nếu node quá tốn kém để vận hành, ít người dùng có thể tự xác minh mạng hơn, điều này có thể làm suy yếu tính phi tập trung.

State bloat khác với tăng trưởng lịch sử blockchain vì trạng thái hoạt động cần để xử lý giao dịch mới. Giao dịch lịch sử quan trọng, nhưng trạng thái trung gian cũ đôi khi có thể bị cắt tỉa hoặc tái tạo. Trạng thái hiện tại phải sẵn có để xác thực.

Điều này khiến tăng trưởng trạng thái trở thành một trong các vấn đề mở rộng khó nhất của blockchain hợp đồng thông minh. State trie là cấu trúc dữ liệu nơi mức tăng trưởng đó hiển thị với client.

Chi phí gas được thiết kế một phần để định giá tính toán và truy cập trạng thái. Việc ghi dữ liệu lưu trữ bền vững tốn kém vì làm tăng hoặc thay đổi trạng thái node phải duy trì. Việc đọc trạng thái cũng có thể phát sinh chi phí vì truy cập trạng thái ảnh hưởng hiệu suất thực thi.

Khi hợp đồng thông minh tạo dữ liệu lưu trữ mới, storage trie và state root toàn cục có thể cần cập nhật. Khi hợp đồng xóa dữ liệu lưu trữ, quy tắc gas có thể hoàn phí hoặc tạo ưu đãi tùy quy tắc giao thức hiện hành.

Các cơ chế gas này liên quan đến state trie vì trạng thái bền vững là tài nguyên dùng chung của mạng. Nếu ghi storage quá rẻ, ứng dụng có thể làm phình state trie bằng dữ liệu giá trị thấp. Nếu quá đắt, ứng dụng hữu ích có thể khó xây dựng.

Nhà thiết kế giao thức phải cân bằng khả năng sử dụng, bảo mật và tính bền vững của trạng thái. State trie nằm ở trung tâm của sự đánh đổi kinh tế này.

State trie, nhà cung cấp RPC và trình khám phá blockchain

Nhà cung cấp RPC cung cấp các phương thức để ví và ứng dụng đọc trạng thái blockchain. Những phương thức trạng thái phổ biến gồm truy vấn số dư, dữ liệu lưu trữ, mã, số lượng giao dịch và lệnh gọi hợp đồng.

Tài liệu Ethereum JSON-RPC chính thức mô tả phương thức trạng thái là các phương thức báo cáo dữ liệu đang lưu như số dư tài khoản, dữ liệu hợp đồng và ước tính gas.

Khi ví yêu cầu số dư tài khoản, nhà cung cấp RPC đọc dữ liệu trạng thái từ node. Khi dApp yêu cầu giá trị hợp đồng, nhà cung cấp RPC có thể đọc storage slot hoặc mô phỏng lệnh gọi dựa trên trạng thái hiện tại.

Người dùng thường dựa vào RPC mà không nghĩ đến state trie đằng sau phản hồi. Tuy nhiên, state trie là yếu tố giúp các giá trị đó thuộc về một trạng thái blockchain có thể xác minh.

Với ứng dụng yêu cầu mức độ tin cậy cao, phản hồi RPC thô có thể không đủ. State proof có thể mang lại đảm bảo mạnh hơn khi được hỗ trợ và xác minh đúng cách. Điều này quan trọng với bridge, kiểm toán, công cụ tuân thủ và hệ thống cross-chain.

Trình khám phá blockchain dùng dữ liệu trạng thái để hiển thị số dư, token đang nắm giữ, dữ liệu lưu trữ hợp đồng, tác động giao dịch và thông tin tài khoản lịch sử. Explorer thường dựa vào dữ liệu đã được lập chỉ mục thay vì chỉ truy vấn trực tiếp state trie.

Việc lập chỉ mục giúp tìm kiếm nhanh hơn và giao diện dễ xây dựng hơn. Tuy nhiên, dữ liệu được lập chỉ mục cuối cùng vẫn đến từ trạng thái blockchain, giao dịch, log, receipt và kết quả thực thi.

Nếu explorer hiển thị số dư tại một block nhất định, thông tin đó liên quan tới trạng thái tại block đó. Nếu hiển thị số dư token, explorer thường suy ra từ thay đổi dữ liệu lưu trữ hợp đồng và sự kiện.

Archive node có thể giúp explorer trả lời nhanh các câu hỏi về trạng thái lịch sử. Nếu không truy cập được trạng thái lịch sử, explorer có thể phải tái tạo trạng thái cũ từ lịch sử giao dịch.

State trie thường không hiển thị với người dùng explorer thông thường, nhưng vẫn là cấu trúc cốt lõi khiến dữ liệu explorer có thể xác minh ở cấp giao thức.

State trie, bridge và mạng Layer 2

Bridge thường cần xác minh trạng thái hoặc sự kiện từ môi trường blockchain khác. State trie và Merkle proof có thể hỗ trợ việc xác minh này.

Ví dụ, bridge có thể cần proof rằng message, giá trị lưu trữ hoặc trạng thái tài khoản đã tồn tại tại một block nhất định. Nếu bridge có thể tin cậy block header và xác minh proof, nó có thể giảm phụ thuộc vào nhà cung cấp dữ liệu tập trung.

Đây là lý do EIP-1186 lưu ý Merkle proof quan trọng với công nghệ Layer 2. State proof có thể giúp hệ thống xác minh các tuyên bố về số dư, storage slot và trạng thái hợp đồng.

Tuy nhiên, bảo mật bridge phụ thuộc vào nhiều yếu tố hơn cấu trúc proof. Nó còn phụ thuộc vào xác minh header, giả định finality, fraud proof, validity proof, kiểm soát multisig, bảo mật hợp đồng thông minh và thiết kế vận hành.

State trie proof chính xác rất mạnh, nhưng chỉ là một phần của bảo mật bridge. Người dùng không nên cho rằng bridge an toàn chỉ vì bridge nhắc đến Merkle proof.

Mạng Layer 2 thường dùng state root, proof và cấu trúc cam kết để tóm tắt việc thực thi off-chain hoặc trên chain riêng. Layer 2 có thể công bố state root lên chain Layer 1 và sử dụng fraud proof, validity proof hoặc cơ chế data availability để chứng minh các chuyển đổi trạng thái hợp lệ.

Thiết kế cụ thể phụ thuộc kiến trúc Layer 2. State trie Ethereum là bối cảnh quan trọng vì cho thấy blockchain có thể cam kết với trạng thái lớn qua root gọn nhẹ.

Hệ thống Layer 2 có thể dùng cấu trúc dữ liệu khác, nhưng khái niệm tương tự: trạng thái thực thi lớn được tóm tắt bằng một cam kết, sau đó người dùng và hợp đồng xác minh các tuyên bố đối chiếu với cam kết đó.

State trie và bảo mật

State trie cải thiện bảo mật bằng cách giúp phát hiện hành vi can thiệp vào trạng thái. Nếu node thay đổi số dư tài khoản mà không tuân theo quy tắc giao dịch hợp lệ, state root kết quả sẽ không khớp block header được chấp nhận.

Nếu nhà cung cấp nói sai về giá trị lưu trữ, Merkle proof hợp lệ phải thất bại khi đối chiếu với state root đáng tin cậy. Nếu hai client không đồng thuận về quy tắc chuyển đổi trạng thái, chúng có thể tính state root khác nhau và từ chối block của nhau.

Điều này khiến state trie có ý nghĩa then chốt với đồng thuận. Lỗi trong việc triển khai state trie có thể nghiêm trọng vì có thể gây bất đồng client hoặc xác minh trạng thái sai.

Vì vậy, execution client phải triển khai cẩn thận logic trie, mã hóa, hashing và cập nhật trạng thái. Bảo mật state trie cũng phụ thuộc vào khả năng chống va chạm của hash mật mã.

Nếu kẻ tấn công có thể tạo hai trạng thái khác nhau cùng root, họ có thể phá vỡ tính toàn vẹn của proof. State trie blockchain hiện đại dựa trên các giả định mật mã khiến điều này gần như không khả thi trong điều kiện hiện tại.

State trie và triển khai client

Các execution client Ethereum khác nhau triển khai cùng quy tắc trạng thái nhưng có thể sử dụng cơ sở dữ liệu nội bộ và tối ưu hóa khác nhau. Kết quả then chốt với đồng thuận phải là cùng một state root.

Cách client lưu node trie trên ổ đĩa, cache trạng thái, cắt tỉa trạng thái cũ và phục vụ truy vấn lịch sử có thể khác nhau.

Điều này nghĩa là state trie vừa là khái niệm giao thức vừa là thách thức triển khai. Ở cấp giao thức, client phải đồng thuận về root và quy tắc chuyển đổi. Ở cấp cơ sở dữ liệu, đội ngũ client có thể tối ưu bố cục lưu trữ, tốc độ truy cập, cắt tỉa, snapshot và hành vi đồng bộ.

Người dùng thường nhận thấy những khác biệt này qua hiệu suất node, dung lượng ổ đĩa, thời gian đồng bộ và độ tin cậy RPC.

State trie và gỡ lỗi của nhà phát triển

Nhà phát triển thường gián tiếp gặp state trie qua storage slot, account proof và truy vấn trạng thái lịch sử. Nhà phát triển hợp đồng có thể cần biết mapping được lưu thế nào trong dữ liệu lưu trữ hợp đồng.

Nhà nghiên cứu bảo mật có thể cần chứng minh storage slot có giá trị cụ thể ở một block. Nhà phát triển bridge có thể cần xác minh giá trị trạng thái hợp đồng từ môi trường khác. Nhà phát triển ví có thể cần giải thích vì sao truy vấn số dư phụ thuộc block tag như latest hoặc finalized.

Nhà phát triển dApp có thể cần archive node khi gỡ lỗi trạng thái hợp đồng cũ. Hiểu state trie giúp nhà phát triển diễn giải đúng các vấn đề này và tránh nhầm lịch sử giao dịch với trạng thái hiện tại.

Nhiều lỗi xuất phát từ giả định rằng event, dữ liệu lưu trữ, số dư và trạng thái tài khoản là cùng một thứ. State trie làm rõ nơi mỗi phần dữ liệu tồn tại.

State trie và trải nghiệm người dùng phổ biến

Hầu hết người dùng crypto không tương tác trực tiếp với state trie. Họ tương tác với ví, dApp, explorer và nhà cung cấp RPC.

Khi ví hiển thị số dư, ví đang đọc trạng thái. Khi dApp kiểm tra người dùng đã phê duyệt token hay chưa, dApp đang đọc trạng thái lưu trữ hợp đồng. Khi lệnh gọi hợp đồng thành công hoặc thất bại, điều đó phụ thuộc vào trạng thái hiện tại.

Khi explorer hiển thị giá trị hợp đồng tại một block, điều đó phụ thuộc vào truy cập trạng thái hoặc dữ liệu lập chỉ mục bắt nguồn từ trạng thái. State trie là hạ tầng ẩn nhưng ảnh hưởng đến hoạt động người dùng hằng ngày.

Nếu truy cập trạng thái chậm, dApp có thể có cảm giác chậm. Nếu RPC cung cấp trạng thái sai, người dùng có thể thấy số dư sai hoặc giao dịch thất bại. Nếu trạng thái lịch sử không sẵn có, người dùng có thể khó kiểm toán hoạt động cũ.

Những hiểu lầm phổ biến về state trie

Một hiểu lầm phổ biến là state trie lưu mọi giao dịch. State trie lưu trạng thái tài khoản hiện tại, còn giao dịch được lưu riêng trong block và transaction trie.

Một hiểu lầm khác là dữ liệu lưu trữ hợp đồng thông minh được lưu trực tiếp trong state trie toàn cục. State trie toàn cục lưu đối tượng tài khoản, còn dữ liệu lưu trữ hợp đồng nằm trong storage trie riêng được tham chiếu bởi giá trị storageRoot.

Hiểu lầm thứ ba là full node luôn lưu mọi trạng thái lịch sử. Nhiều full node giữ trạng thái hiện tại và gần đây, đồng thời cắt tỉa các trạng thái trung gian cũ.

Hiểu lầm thứ tư là state root chính là trạng thái. State root là cam kết mật mã gọn nhẹ với trạng thái, không phải toàn bộ cơ sở dữ liệu trạng thái.

Hiểu lầm thứ năm là Merkle proof chứng minh mọi sự thật có thể có về hợp đồng. Merkle proof chứng minh một giá trị tài khoản hoặc dữ liệu lưu trữ cụ thể đối chiếu với một root cụ thể, không chứng minh toàn bộ ý nghĩa nghiệp vụ của giá trị đó.

Lợi ích của state trie

Lợi ích đầu tiên là khả năng xác minh. Người dùng và client có thể xác minh giá trị trạng thái qua proof liên kết với state root.

Lợi ích thứ hai là tính xác định. Client xử lý cùng block hợp lệ phải đạt cùng state root.

Lợi ích thứ ba là tra cứu hiệu quả. Đường dẫn trie cho phép client tìm dữ liệu tài khoản và dữ liệu lưu trữ qua key xác định.

Lợi ích thứ tư là bằng chứng chống can thiệp. Thay đổi một giá trị sẽ thay đổi đường dẫn hash và root cuối cùng.

Lợi ích thứ năm là hỗ trợ light client. Proof có chọn lọc có thể xác minh dữ liệu mà không cần tải toàn bộ trạng thái.

Lợi ích thứ sáu là cấu trúc chuyển đổi trạng thái rõ ràng. Mỗi block biến trạng thái trước đó thành trạng thái mới với root mới.

Các lợi ích này khiến state trie trở thành nền tảng của blockchain hợp đồng thông minh dựa trên mô hình tài khoản.

Hạn chế của state trie

Hạn chế đầu tiên là tăng trưởng lưu trữ. Khi nhiều tài khoản và giá trị lưu trữ hợp đồng tích lũy, trạng thái trở nên nặng hơn đối với node.

Hạn chế thứ hai là kích thước proof. Proof Merkle Patricia Trie có thể lớn hơn mong muốn đối với stateless client và xác minh quy mô lớn.

Hạn chế thứ ba là độ phức tạp triển khai. Mã hóa trie, hashing, cắt tỉa, cache và lưu cơ sở dữ liệu khó triển khai chính xác.

Hạn chế thứ tư là chi phí trạng thái lịch sử. Lưu mọi trạng thái lịch sử đòi hỏi dung lượng ổ đĩa lớn hơn rất nhiều so với vận hành full node thông thường.

Hạn chế thứ năm là sự nhầm lẫn của nhà phát triển. Nhiều nhà phát triển không hiểu khác biệt giữa state, storage, transaction, receipt, log và dữ liệu đã lập chỉ mục.

Các hạn chế này giải thích vì sao quản lý trạng thái vẫn là lĩnh vực nghiên cứu và kỹ thuật tích cực. State trie hoạt động hiệu quả, nhưng tạo ra những thách thức thực tế về mở rộng và khả năng sử dụng.

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

Hãy hiểu khác biệt giữa trạng thái tài khoản và dữ liệu lưu trữ hợp đồng trước khi xây dựng hệ thống dựa trên proof.

Sử dụng tài liệu Ethereum chính thức khi tìm hiểu cơ chế Merkle Patricia Trie. Sử dụng eth_getProof cẩn thận khi xây dựng hệ thống cần account proof hoặc storage proof.

Hãy xác minh proof đối chiếu với block header đáng tin cậy thay vì tin tưởng mù quáng phản hồi RPC. Nhớ rằng số dư token thường nằm trong dữ liệu lưu trữ hợp đồng, không trực tiếp trong state trie toàn cục.

Dùng archive node hoặc nhà cung cấp dữ liệu archive khi cần truy cập nhanh trạng thái lịch sử cũ. Thiết kế hợp đồng thông minh để giảm dữ liệu lưu trữ bền vững không cần thiết.

Cân nhắc chi phí gas khi ghi vào storage vì trạng thái bền vững tốn kém. Theo dõi nghiên cứu giao thức như Verkle tree nếu hệ thống phụ thuộc nhiều vào state proof.

Không nên cho rằng định dạng proof hiện tại sẽ luôn không thay đổi trong các bản nâng cấp giao thức tương lai.

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

Sử dụng ví và explorer đáng tin cậy, nhưng nhớ rằng dữ liệu hiển thị đến từ truy vấn trạng thái và dữ liệu lập chỉ mục.

Kiểm tra số block khi so sánh số dư hoặc giá trị hợp đồng giữa các công cụ. Hãy hiểu số dư hiện tại và số dư lịch sử có thể yêu cầu cách truy cập dữ liệu khác nhau.

Dùng xác minh dựa trên proof khi cần mức đảm bảo cao và công cụ hỗ trợ. Đừng cho rằng phản hồi RPC đơn giản tương đương proof mật mã.

Thận trọng khi dùng bridge hoặc ứng dụng tuyên bố xác minh trạng thái từ chain khác. Xem ứng dụng dùng trạng thái hiện tại, trạng thái lịch sử, log hay lập chỉ mục off-chain.

Hãy hiểu thay đổi dữ liệu lưu trữ hợp đồng thông minh có thể ảnh hưởng hành vi ứng dụng ngay cả khi việc chuyển token không rõ ràng. Tính minh bạch blockchain phụ thuộc vào các cấu trúc dữ liệu như state trie.

State trie vô hình với hầu hết người dùng, nhưng giúp dữ liệu public chain có thể xác minh.

FAQ

State trie nghĩa là gì?

State trie là cây key-value mật mã lưu trạng thái blockchain hiện tại và tạo root hash cam kết với trạng thái đó.

State trie Ethereum là gì?

State trie Ethereum là Merkle Patricia Trie sửa đổi toàn cục ánh xạ địa chỉ tài khoản đã hash đến đối tượng tài khoản được mã hóa RLP.

Đối tượng tài khoản Ethereum lưu gì?

Đối tượng tài khoản Ethereum chứa nonce, balance, storageRoot và codeHash.

State root là gì?

State root là hash gốc của state trie sau khi giao dịch của block được thực thi.

State trie có giống storage trie không?

Không. State trie lưu đối tượng tài khoản, còn storage trie lưu dữ liệu hợp đồng cho từng tài khoản hợp đồng riêng lẻ.

State trie có giống lịch sử giao dịch không?

Không. State trie lưu trạng thái tài khoản hiện tại, trong khi lịch sử giao dịch ghi các giao dịch có thứ tự trong block.

Merkle proof là gì?

Merkle proof là tập node trie có thể chứng minh một giá trị cụ thể được bao gồm trong trạng thái được root hash cam kết.

eth_getProof là gì?

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

Vì sao archive node quan trọng với state trie?

Archive node quan trọng vì lưu trạng thái lịch sử và có thể trả lời truy vấn trạng thái cũ nhanh hơn full node thông thường.

Ethereum có luôn dùng state trie hiện tại không?

Ethereum hiện sử dụng Merkle Patricia Trie trong execution layer, nhưng nghiên cứu Ethereum đã xem xét Verkle tree như cấu trúc cam kết trạng thái trong tương lai.

Kết luận

State trie là một trong các cấu trúc dữ liệu cốt lõi của blockchain hợp đồng thông minh dựa trên mô hình tài khoản.

Nó lưu trạng thái hiện tại của tài khoản và cho phép client tóm tắt trạng thái đó qua một root mật mã duy nhất.

Trong Ethereum, state trie toàn cục ánh xạ địa chỉ tài khoản đã hash đến đối tượng tài khoản chứa nonce, balance, storageRoot và codeHash. Mỗi hợp đồng sau đó có thể có storage trie riêng, với root được lưu trong đối tượng tài khoản hợp đồng.

State root trong mỗi block header cam kết với toàn bộ trạng thái kết quả sau khi mọi giao dịch trong block được xử lý. Điều này khiến state trie thiết yếu đối với đồng thuận, xác minh, light client, proof, đồng bộ node, thực thi hợp đồng thông minh và tính toàn vẹn dữ liệu blockchain.

State trie cũng tạo thách thức vì tăng trưởng trạng thái hoạt động làm tăng lưu trữ node, kích thước proof, độ phức tạp đồng bộ và chi phí dữ liệu lịch sử. Đây là lý do archive node, cắt tỉa trạng thái, chi phí gas, thiết kế storage, eth_getProof và nghiên cứu Verkle tree đều liên quan đến cùng chủ đề.

Với người dùng, state trie phần lớn ẩn sau ví, explorer và dApp. Với nhà phát triển và đội ngũ hạ tầng, đây là khái niệm then chốt để hiểu số dư, dữ liệu lưu trữ hợp đồng, proof, truy vấn lịch sử và giới hạn mở rộng.

Trong ngữ cảnh thuật ngữ crypto, State Trie là cơ sở dữ liệu trạng thái blockchain đã được xác thực, ghi nhận trạng thái tài khoản hiện tại và tạo state root dùng để xác minh trạng thái đó.

Điểm chính cần nhớ là state trie biến trạng thái blockchain khổng lồ và liên tục thay đổi thành cấu trúc có thể xác minh mà node, ứng dụng và người dùng có thể tin cậy thông qua root và proof mật mã.