- To be committed, transactions must achieve both validity and uniqueness consensus
- Validity consensus requires contractual validity of the transaction and all its dependencies
- Uniqueness consensus prevents double-spends
Two types of consensus
Determining whether a proposed transaction is a valid ledger update involves reaching two types of consensus:
- Validity consensus - this is checked by each required signer before they sign the transaction
- Uniqueness consensus - this is only checked by a notary service
Validity consensus is the process of checking that the following conditions hold both for the proposed transaction, and for every transaction in the transaction chain that generated the inputs to the proposed transaction:
- The transaction is accepted by the contracts of every input and output state
- The transaction has all the required signatures
It is not enough to verify the proposed transaction itself. We must also verify every transaction in the chain of transactions that led up to the creation of the inputs to the proposed transaction.
This is known as walking the chain. Suppose, for example, that a party on the network proposes a transaction transferring us a treasury bond. We can only be sure that the bond transfer is valid if:
- The treasury bond was issued by the central bank in a valid issuance transaction
- Every subsequent transaction in which the bond changed hands was also valid
The only way to be sure of both conditions is to walk the transaction’s chain. We can visualize this process as follows:
When verifying a proposed transaction, a given party may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer(s). The transaction proposer(s) will always have the full transaction chain, since they would have requested it when verifying the transaction that created the proposed transaction’s input states.
Imagine that Bob holds a valid central-bank-issued cash state of $1,000,000. Bob can now create two transaction proposals:
- A transaction transferring the $1,000,000 to Charlie in exchange for £800,000
- A transaction transferring the $1,000,000 to Dan in exchange for €900,000
This is a problem because, although both transactions will achieve validity consensus, Bob has managed to “double-spend” his USD to get double the amount of GBP and EUR. We can visualize this as follows:
To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction.
If one or more of the inputs have already been consumed in another transaction, this is known as a double spend, and the transaction proposal is considered invalid.
Uniqueness consensus is provided by notaries. See Notaries for more details.
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.