Daml may not be running in the same way you envision. The Daml compiler is not taking Daml code and producing “native” code, be that Java or Kotlin or assembly.
The Daml compiler compiles Daml code to a custom, protobuf-based format we have defined called Daml-LF. Those Daml-LF files (
.dalf extension) are then zipped up into
.dar files, which are sent to a Daml ledger through the gRPC API.
The Daml Ledger is (roughly) a process that:
- Exposes a gRPC endpoint conforming to the Daml gRPC API.
- Is able to execute Daml-LF code when prompted through the gRPC API.
- Is able to save contracts somewhere.
I’m obviously glossing over a ton of things here and all of those are defined in much more formal ways in our docs, but I think this level of detail is enough here.
When you run “Daml over Corda”, for example, that means that you will run some process that can do all these three things, and saves its data to a Corda Ledger. I’m not too familiar with Daml on Corda per se, but geneally speaking, for such an integration, you can think of the Daml Ledger using the underlying thing (in this case the Corda blockchain) as a data store. Daml contracts will not necessarily be encoded as Corda contracts; instead, maybe we’ll encode an entire Daml transaction as one opaque blob of data inside one Corda contract.
So the Daml-LF is really the most “native” code you can see: that is going to be interpreted by the Ledger (which is usually written in Java) directly, without producing more “native” code first.
To see the Daml-LF produced by the Daml compiler, you can use
daml damlc compile path/to/File.daml
for a single source file, or you can use the command
daml damlc inspect path/to/package.dar
for an entire DAR archive at once.
Both print the Daml-LF code (in a textual representation, not in its native protobuf format) to stdout, so you may want to redirect that to a file, for example:
daml damlc compile daml/Main.daml > tmp
would compile the Daml code in
daml/Main.daml and save the resulting Daml-LF in