Merkle trees for hiding State fields from counter-parties?

Question

The Corda v3 docs describe Transaction tear-offs and the use of Merkle trees to 'hide' information during a transaction. Specifically, the example used is to hide sensitive data from an Oracle during it's validation of the transaction.

Does the Corda framework support using the Merkle tree to hide information from signing counter-party nodes? Or when the fully signed transaction is wired to counter-party nodes, can a subset of the State information be hidden? Can the level of 'redaction' vary by counter-party node or must the State be the same when the fully signed transaction is distributed out to the other parties?

Cais Manai · Answer 1 · 2018-04-03T09:11:38.630

In Corda, transactions are proposals to update the ledger. A transaction proposal will only be committed if:

It doesn’t contain double-spends
It is contractually valid
It is signed by the required parties

The simple answer is, it depends on your contract code. You can certainly use the framework to build a filtered transaction and send that to counterparties to sign. However, they'll only sign if it's contractually valid.

I think you'll find problems going down this route though, as you're essentially asking counterparties to sign something without them knowing what it is they're signing e.g. the transaction could include a hidden set of states transferring away their cash.

You could look into additional layers of encryption and only share keys with counterparties you want to view the sensitive data.

Corda also supports sending data using the flow framework, so you could send the sensitive data separately outside of a transaction.

On your last point, once a transaction is signed, it cannot be altered without invaliding the transaction.

Finally, take a look at this blog post by Mike Hearn - https://www.corda.net/2017/06/corda-sgx-privacy-update/ This solves the privacy problem described without the use of filtering

score 2 · Answer 2 · answered Aug 10 '18 at 14:43

As Cais says, the limitation of using tear-offs to hide part of a transaction from a counterparty is that the counterparty will probably be unwilling to sign the transaction because they can't tell exactly what they're signing over. What if one of the torn-off inputs is cash belonging to them and being transferred to someone else?

However, with any torn-off transaction, you at least have the ability to check whether or not all of the components of a certain group (inputs, outputs, commands, attachments...) have been torn off. You can use this to, for example, check that no inputs have been torn off the transaction before signing:

@InitiatingFlow
@StartableByRPC
class Initiator(val counterparty: Party) : FlowLogic<Unit>() {

    @Suspendable
    override fun call() {
        val notary = serviceHub.networkMapCache.notaryIdentities[0]
        val txBuilder = TransactionBuilder(notary)
                .addOutputState(TemplateState(), TemplateContract.ID)
                .addCommand(TemplateContract.Commands.Action(), ourIdentity.owningKey)

        val partlySignedTx = serviceHub.signInitialTransaction(txBuilder)

        // We filter out the outputs, which are of type `TransactionState<ContractState>`.
        val filteredTx = partlySignedTx.buildFilteredTransaction(Predicate {
            when (it) {
                is TransactionState<ContractState> -> false
                else -> true
            }
        })

        val session = initiateFlow(counterparty)
        val signature = session.sendAndReceive<TransactionSignature>(filteredTx).unwrap { it }
        val fullySignedTx = partlySignedTx.withAdditionalSignature(signature)

        subFlow(FinalityFlow(fullySignedTx))
    }
}

@InitiatedBy(Initiator::class)
class Responder(val session: FlowSession) : FlowLogic<Unit>() {

    @Suspendable
    override fun call() {
        val filteredTx = session.receive<FilteredTransaction>().unwrap { it }

        // We check that all inputs are visible before accidentally signing something away.
        filteredTx.checkAllComponentsVisible(ComponentGroupEnum.INPUTS_GROUP)

        val signature = serviceHub.createSignature(filteredTx)

        session.send(signature)
    }
}

You are still not able to verify the transaction's smart contracts, but you can at least be sure that you are not consuming any of your own inputs by signing.

You can use this approach in different ways. For example, you can check that only attachments have been torn off, where the attachments may contain secret data that the counterparty is not allowed to see.

Merkle trees for hiding State fields from counter-parties?

2 Answers2