Deciders in the Haircomb system play a crucial role in determining the outcomes of transactions or actions that require cryptographic verification. Their primary function is to decide which of the possible destinations in a Merkle Segment will receive the COMB. Deciders act as cryptographic keys, but with enhanced flexibility. They are designed to sign small (16-bit) decisions, allowing for multiple choices within a system. By making and committing decisions, Deciders ensure that the transaction routing process is secure, verifiable, and transparent. They contribute to maintaining the integrity of the Haircomb ecosystem by preventing double spending or double decision-making.
In essence, Deciders provide a mechanism for trusted third-party arbitration in trades or multi-party decisions, adding a layer of trust to transactions and creating a decentralized decision-making process.
The structure of a Decider consists of a chain of cryptographic keys, with each key (or Decider) holding the power to make a single decision in the chain. The key components of a Decider include:
Structurally, Deciders can be chained together to decide on larger values. Each Decider in the chain references the next one, except for the last in the chain, which has no successor. This creates a flexible decision-making system where multiple transactions can be decided by the same Decider, or a single Decider can be part of multiple chains.
Deciders are used in third-party arbitration scenarios where two parties engage in a transaction (e.g., trading COMB for another currency). A trusted third party (the arbiter) creates a Decider and distributes the Short Decider to both parties. The parties construct a Merkle Segment with two possible destinations: one for the buyer and one for the seller. The seller funds the Merkle Segment address, and once the buyer transfers the agreed-upon amount in the other currency, the arbiter verifies the transaction and uses the Decider to determine whether the COMB is sent to the buyer or rolled back to the seller.
Benefits:
In this use case, a Decider is used to send conditional payments based on predefined outcomes. For instance, if a smart contract depends on an external event (such as a vote result or external API data), a Decider can be employed to choose from multiple payment destinations. The destinations could represent different parties or varying payment amounts, and the Decider selects the appropriate destination once the conditions are met.
Benefits: