Consensus and Trust Model
Last updated
Last updated
The Kasplex indexer is an open-source project that can be operated by individuals or service providers. The Kasplex team is committed to promoting indexer diversity. This diversity in clients establishes a fundamental consensus where anyone can independently authenticate all data.
Each state change associates with a checkpoint initialized with the previous checkpoint. This checkpoint acts as a secure hash ensuring data integrity and authenticity.
If two indexers provide different checkpoints for the same op record, then the inconsistency will be detected.
The trust model of Kasplex Indexer operates under a 1 - N assumption, asserting that for every state change, there will be at least one indexer providing authentic data. This model guarantees that no data is omitted.
In scenarios where two or more indexers provide different checkpoints for the same operation record, this discrepancy signals a potential inconsistency. Such conflicts trigger an investigation or verification process to ensure data consistency and resolve discrepancies.
Based on 1-of-N Trust Assumption, to prove that alll KRC-related transactions were included in the ledger after it has been pruned can be verified with following steps:
A header of a block B and a Merkle proof that transaction appears in B's Accepted Transactions Merkle Root(ATMR)
Proof that B appeared in the selected chain, a proof of chain membership (PoChM)
You can get more information via KIP-6
Retrieve transaction components from indexer and make a hash to check the transaction ID.
When syncing, an indexer obtains all the KRC history and proofs from an existing indexer, and asks for the hash thereof from all peers. The Merkle security assures that a cheating indexer can only omit transactions.
Node synchronizers
For a new deployed synchronizers, it will automatically pull historical data from the archive database we provide and generate the latest state. Each state change corresponds to a checkpoint, which can be checked between all other indexer/light indexers. This may take a while to continue, and will automatically switch to the Kaspa node's RPC interface when it's done.
After developing the p2p mechanism, the node synchronizer will also check data integrity with all peers.
OP Executer
The OP Executor acts as a computation layer. It will fetch the KRC20 transaction data from the local DB after the synchronizer has archived it, automatically track the latest blocks and handle the reorganization logic and compute the latest states.
