Recently I was asked what will happen if a client submits a command with the incorrect parameter and dispute against it. For an example, instead of agreeing to sell 1% of the holding, he send the command to sell 10%. Is there anything we can do prove that the command was sent by the client and the number is 10% instead of 1%?
A few questions I can think of
How to associate the command ID with the execution results? e.g. my holding is now decreased by 10%. How do we know which command/command ID lead to the change.
How to associate the ledger API user to a command id? e.g. for the command ID that leads to the change, which ledger API user submitted?
For the first question, the Ledger API gives you some support; there will be a transaction entry on the transaction stream of the submitting party that contains both the change (selling 10% of the holding) and the command ID. Other parties (who are not the submitting party) don’t get to learn the command ID, because it could in principle be confidential.
If this is not enough, the participant node where the submitting party is hosted might also provide you with some logs, but how these are configured and where to find them depends on your ledger. If that won’t cut it either, then you’ll need to build some logging/correlation mechanisms of your own.
For the second question, the ledger should provide some kind of cryptographic evidence that the transaction that changed the holding was authorized by the participant hosting the party. The evidence is necessarily ledger-specific, though we can come up with tools and APIs that allow you to verify the evidence (we’ve had plans around this, but to the best of my knowledge that work hasn’t been scheduled). However, there’s by design no general way to ensure that it was really a certain party that issued the command - if the party is hosted on a malicious participant node, that node (but no other nodes) can issue transactions in the name of that party as they please. That is to say, in our trust model, the parties must trust the participants that they are hosted on.
While @oggy is correct that by default we trust participants, you can build an infrastructure for non-repudiation of the participants towards users on top of that
For example, users could sign command payloads that they send to the participant and the participant (or some middleware in front of that) can store the signature. That way the participant can later prove to a user that they issued a command because they have the signature of the user on this command.
Towards the network, @oggy’s statement still holds. The participant can imitate you all it wants. But now you have an option for the participant to prove that it was honest towards its users.
@oggy, @cocreature. Thanks for your answers. I got a few more detailed questions now.
For question 1, Is the command id stored somewhere on the ledger? I checked the postgre database ledger and couldn’t find command id in any table. Also does the transaction entry replayable? e.g. if the client throw it away, can s/he replay it?
For question 2, one of the challenge we have is that parties can be shared in multiple ledger API user session. How to find out a command is executed under which ledger API user’s session? The ledger has cryptographic evidence for the parties involved but I don’t think ledger API user information is presented to the ledger. When a user login into ledger API, can ledger API records and associates all the command ID submitted under that user session?
Command IDs are stored on the ledger, you can get it from the transaction service. However, they are only exposed to the submitting party. The transaction stream is replayable. You can supply a starting offset.