Transaction validity model on HLF

Questions
,
1

Hey!
Recently, I and my team at Imapp have been playing around with DAML on
Fabric. It works really well, the quick-start documentation is comprehensive and well written, thank you for that :pray:.

Having tested some of the basic functionalities, we went a little deeper and wanted to restore events from Hyperledger. We have seen that this can be done directly via daml tool, but we wanted to recover them directly from Fabric nodes. We then went through the transaction types that are sent to Hyperledger, but we saw that the only transactions that are sent to Hyperledger are RawBatchWrite. Are those raw bytes validated somehow on Fabric side?

Based on the documentation, we conclude that DAML on Fabric implements DAML VM, which validates transactions, keeps some cache and sends raw bytes to Hyperledger. Which means that Hyperledger, in this architecture, is a database and does not validate transactions (aside from read/write races). Each transaction is validated on the DAML part of the architecture and then update is just stored on Hyperledger. It seems that DAML transactions originating on remote peers are not validated w.r.t. business rules locally.

In example:
We have the two parties - Alice and Bob; both are running a HLF peers, share a channel, on which a DAML contract is uploaded and instantiated. Both parties are also running own, independent DAML-on-Fabric instances.

Alice creates a DAML transaction and sends it to DAML-on-Fabric, which validates and executes it, creating a corresponding transaction on Fabric. Fabric orderer includes the transaction in a new block. Bob’s instance of DAML-on-Fabric does not validate the transaction at all.

Is our conclusion correct?

What about transaction finality? How do we know that the tx has been put in a Fabric block?

Do you plan to use Hyperledger 2.0 mechanism External code launcher*,

*which could be a clean solution to ensure that transaction’s validity
is ensured and protected by Hyperledger rather than external services
and treating Hyperledger as a simple K-V database.

CC: @sormeter , @Tim

5 Likes
2

Hi @pzelazko thank you for digging in to this :slight_smile:

You’re correct in your understanding, but with one final step missing - Bob’s DAML interpreter will only accept DAML transactions that are valid and consistent with the DAML library he is running. It’s not quite the same as pre-commit validation of course.

There are some interesting developments for DAML on Fabric coming up in the next 6-9 months which do address some of this. Happy to give you a preview - @Ratko_Veprek is the man to talk to.

1 Like
3

Hi @Tim,
thank you for the answer.
Does Bob’s interpreter read each transaction as soon as it is mined in a block, or is there a chance that Bob only sees the state corruption after, let’s say 1 month, when he first reads the corrupted state, to work on these bytes.

Example:
Malory creates a transaction that transfers some tokens from Mallory to Alice, but his transaction is corrupted - instead of subtracting value from his account and adding the value to Alices; he just adds the funds to Alice’s account.

Does Bob see this state corruption immediately, or only when he creates a tx that has sth to do with Alice’s/Malory’s accounts?

4

Hi @pzelazko In your example of a business logic error in the workflow (subtracting rather than adding), this would be something that would be caught in interpretation and as part of the smart contract execution when the “corrupted” funds are attempted to be used in an invalid state by a subsequent workflow step that depends on them.

Also in the example you have given this would be a contract and business rule specific protection as the corruption here does not appear to be one of tampering or state manipulation but rather faulty business processing.