I can’t find any useful info about how DAML architecture support smart-contracts.
For example on fabric chain code is executed on few peers (depend on endorsement policy), and if all validation are successful(on every peer) the transaction can be written to ledger (in very big simplification). But how is this achieved using DAML drivers? Or maybe it is not at all?
I found similar topic here -Transaction validity model on HLF
But if above is true (maybe i misunderstand it) it would mean that DAML doesn’t support smart-contracts at all.
I know this documents, but I still can’t understand how to use it in different blockchains through drivers.
The first way that it could be achieved that come to my head is that daml .dar files are transpiled to for example chaincode then install it in infrastructure node and then this chaincode get executed.
The second way is that every infrastructure node(HLF) has to have its own participant node(daml). But this solution to be adopted to existing infrastructure would need to install a participant node for each existing infrastructure node.
I think one of my colleagues will be able to elaborate on this, but basically it’s the second case you’ve outlined.
The link you included in your original post gives evidence to that fact, so e.g. when you look at the underlying Fabric node, DAML contracts are serialized as a binary strings; it’s an encoding of DAML-LF, our low level ‘bytecode’ for lack of a better analogy.
But this solution to be adopted to existing infrastructure would need to install a participant node for each existing infrastructure node.
I can’t really speak to this - let’s see if someone else can shed some light on this.
Where the Fabric peer node has a custom chaincode deployed which is part of the Daml Driver for Fabric. It’s essential that we deploy the Ledger API Server alongside each node for a few reasons. One of them is local validation of all Daml logic, another one is to ensure that all Daml ledgers have a unified Daml API so users can port and/or migrate applications from one ledger to another (a bit more background on this here and here)
The second architecture is based on https://www.canton.io/ and is a two-layer network. In that architecture there are two types of nodes: a domain node and a participant node. The domain node can be thought of as the first layer (L1) and includes the Fabric node and a Daml Driver for Fabric, and the L2 contains the Ledger API server.
So to summarize, Daml itself is a smart contract language but it doesn’t transpile to Chaincode (in theory we could do that but it would have many limitations). Conceptually we do something similar to Fabric but instead of validating the smart contract directly in chaincode, we deploy a chaincode onto the Fabric peer which communicates over an RPC with a local Daml engine which runs the validation.
From the Fabric network’s perspective the Daml ledger is just another Chaincode running on the ledger, and only those who want to participate in the Daml ledger need to run Daml ledger nodes.
An interesting way to think of it is:
From the perspective of a Daml application, it is communicating with a Daml ledger and the fact that there’s a Fabric network storing and coordinating data behind the scenes is just an implementation detail
From the perspective of a Fabric network participant, the Daml legder is just another smart contract running on the network, and the Daml ledger is embedded in the network’s data