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 .
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.
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.