Skip to content
CCPEDIAby Unity Nodes
VideosHow Daml Manages its State [2021]

How Daml Manages its State [2021]

Nothing is loaded from YouTube until you press play, and then without tracking cookies.

About this video

Daml is a development framework for creating systems of record that securely connect across business processes and data boundaries while retaining privacy, guaranteeing data integrity, and enforcing strict authorization. Allowing such systems to cross boundaries — legal, regulatory, organizational, or other — enables them to form seamless economic networks.

📖Get started with Daml: bit.ly/tryDaml 📚Learn more about Daml Smart Contracts: bit.ly/learn_daml 📮Check out our blogs: bit.ly/daml-blog-engineering 📋Become a Daml certified expert: bit.ly/daml-certification

In this video Shaul takes us through how bank accounts, blockchains, and Daml manage state, drawing parallels between them and diving into how to conceptualize past (events), present (Active Contract Set), and future (commands) state in Daml.

Everything you need to know about event sourcing: sitepen.com/blog/architecture-spotlight-event-sourcing Event sourcing pattern - Cloud design patterns: docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

Transcript

2,209 words

Captions as YouTube publishes them, usually machine-generated, so names such as Daml and Canton can be misheard.

  1. 0:01

    hey everyone show from digital asset here today i'm going to talk about state management demo in a previous video we talked about the demo ledger model if you haven't already seen that you may want to go back and view that first although this session could probably be understood as a standalone as well so before i talk about demo i'll talk about a simple example that we're all familiar with

  2. 0:24

    a bank account so when i go into my banking app the main thing i want to know is what's my balance so i log in i say i have a bid over two thousand dollars but then i might ask wait what how did that happen how did it get to that just last week i had five thousand after my paycheck came in so luckily banking apps also show us all of the events that took place that brought to this current balance

  3. 0:50

    the architectural pattern of storing all of the events that led up to a certain state is called event sourcing i'll repeat this because it's important before we go on event sourcing is a software design pattern which captures all of the events that happen leading to a current state so in this case all the transactions that happen in my bank account that led to the current state

  4. 1:13

    of 2257 in my bank account now if you're familiar with bitcoin or thea ethereum or any other blockchain you may be thinking that sounds awfully similar to what a blockchain does and that's right blockchains capture all of the events that happened in an immutable event log immutable simply means that it's an event log that has some protections against anyone changing the data after the fact so before we go into demo specifically let's talk a few minutes about what the advantages are

  5. 1:46

    of the event sourcing model so there are a few things and i won't touch on everything but i'll tell you about a few i'll touch on a few of the main points many times we want to know not only our current state but also what was the state in any past point in time for example i may want to query what was my bank balance as of february 10th how did we get to the current state what were all the transactions since february 10th

  6. 2:18

    the next thing with even source model is it makes it relatively straightforward to build a lot of important enterprise features that devil has so for example when a demo user needs high availability they can spin up replicas of any data store in the system and recreate them from the event log because everything is captured in the event log it's one place to capture everything and all data can be recreated from it

  7. 2:42

    if for example a data center has a catastrophic failure it burns down we only need to back up the event log and all other data in the system can be restored from that uh in a distributed network like all blockchains or distributed ledgers are it's easy to synchronize nodes because all they need to receive is the events and each node can locally reconstruct the current state so they

  8. 3:04

    can synchronize the state by just all sharing the event log between them the next thing is that in event source architectures all rights to the system go to the event log and all other data is recreated from there so this leads to very performant architectures i can create multiple secondary data stores also known sometimes as these are different things but there are caches or materialized

  9. 3:34

    views these are data stores which are optimized for performance and i won't go deep into this i talked about performance implications of event sourcing in demo in a previous video that you can find on the devil youtube channel so there are many other advantages to using the event source model but these are a few of them now in the event source model we talk about three-time horizons just like in life there's a past a present and a future

  10. 4:07

    the past is the event log itself it stores all of the historical events everything that happened so in my example of a bank account the event lag at my bank may say that i deposited 500 i withdrew 100 and i withdrew 200 note that all of the events are always in past tense i deposited i withdrew it's always things that i've done in the past the present in the event source model we call it the active state it's the application of all past events in our example

  11. 4:41

    after all these events my current balance in the bank is now 200 the future are the commands into the system now while we call them commands these are actually requests to make a future change to the state of the system so in our example i submit a command to withdraw 150 and another command to withdraw 100 these commands are validated by the system against my current balance in this example the first command succeeds since i had 200 in my bank account and i tried to withdraw 150

  12. 5:21

    and when this succeeds it would create a event in the system which would be withdrew one hundred and fifty dollars and now i would have a new active balance of fifty dollars when i try to put in the second command to withdraw a hundred dollars my command gets rejected it doesn't cause any new events and doesn't cause any change any state change to the system now i'll mention that in some events for systems we would also emit an event

  13. 5:46

    that a command has been rejected and the reason for that is to keep a full body trail but i won't go into the details here so up until now i talk generically about event source systems and now let's start going specifically into demo and talk about these three time horizons the past the present and the future and how we call them and down and how they look so the past events in demo are called

  14. 6:11

    demo events pretty simple anyone running a node on a demo network has an api to access the log of events the current state of a demo ledger is called the active contract set set or you'll see in our documentation acs for short anyone running a node on a demo network can query the active contract set what is the current balance of my bank account what is the current state of the system

  15. 6:38

    all of the requests to make a change to a demolition are called demo commands and anyone running a node on a demo network has an api to submit commits or in many cases they can do this through some graphical user interface through some web browser so now let's let's talk about these specifically in demo with a visual example remember that in demo the ledger is for multiple parties the state of the ledger is the active

  16. 7:04

    contract set now i'll mention that when i say contract this is the commonly used terminology in the industry but in this context you can think about it as just some piece of data that multiple parties have access to don't think about it in the legal context of a contract so now if you're using a demo driver for a traditional database such as postgres or oracle then all of these contracts are stored

  17. 7:29

    in one place on that database if you're using a demo driver for a blockchain or distributed ledger then each party may see and store locally on their nodes some subset of the active contract set so now going back to the event source model the active contract set the current state changes when events happen there are two main types of events in them a contract can get created which adds that contract to the active contract set

  18. 8:03

    and the contract can get archived removing it from the active contract set now i'll mention that there are a few more types of events but these two are really the ones that are material in order to understand how demo works the others we go into the uh into the details of the other types of events in our documentation so let's see an example tying together of these three time horizons

  19. 8:27

    let's start at the beginning of time an active contract set is empty it doesn't have any contracts in it now a command comes in requesting to create two contracts if the command gets accepted we'll now have two contracts in the active contract set let's say another command comes in it's submitted and it requests to archive one contract and to create a new contract if that command gets accepted then two more events will be created a contract archived and contact created

  20. 8:59

    event and one of the contracts that's currently in the active contract set will be archived and one new one will be created so now we have four events this far and two contracts in the active contract set continuing with this example the next command may request to archive one contract and create two so we'll have three new events in the system and the active contract set will have three contracts in it and we may have the next command

  21. 9:29

    requesting to archive two contracts and create three more and we'll have five new events in the event log and the active contract set will now have four contracts in it so now we'll talk about the format of demo commands until now i said things like a command will be submitted and request to archive two contracts and three three contracts in demo the commands are actually much simpler than that we don't need to explicitly explain which contracts should be archived and which should be created in every transaction

  22. 10:03

    and then we have two main types of commands we can request to create a contract and we can request to exercise a choice on a contract which already exists in the active contract set if the command is accepted then events will be recorded and the active contract set will change so here's an example of why create an exercise choice are much simpler than explicitly creating and archiving contracts let's say i already have a car contract on the ledger which represents

  23. 10:36

    ownership of a physical car this contract already specifies that i have a choice to transfer ownership of my car to a new buyer when i submit the command to transfer ownership many events can occur simultaneously but then was smart enough to translate my simple command into the many events that need to happen and to who needs to see which events so for example in this command to transfer ownership it will create a new car with the buyer being

  24. 11:06

    the new owner implicitly that will also archive the existing contract because i am no longer the owner of the car it will exercise more choices on other contracts that are already in the active contract set which will notify the motor vehicle registry for example and cancel my insurance contract with the insurance company and each of these choices will in turn archive and create many more contracts so every command can cause many many contracts to be archived and many contracts to be

  25. 11:39

    created but the command is very simple from as a user all i have to do is specify that what i want to do is transfer ownership and the demo runtime translates that into all of the events that need to happen and who needs to be aware of which events and that also translates to the change in active contract set for each of the users of the ledger so in this example the new owner may see some events and may have some changes to his view on the active contract set

  26. 12:12

    the vehicle registry we'll see some of the events and the insurance company will see some of the events now i'll go into much more detail about this example in a future presentation about the demo transaction graph and this will become much clearer but for now i'll leave it with this level of understanding the event sourced system so to recap demo creates an event source integration across organizational boundaries or across

  27. 12:41

    multiple parties we interact with the demo ledger using these three time horizons commands are a request to change the state in the future the active contract set is the current state of the ledger that's usually what i would want to query and the state that i care about the most and events are the audit log of all of the changes that happened until now if you want any more information there are a few links here

  28. 13:12

    extra links to blog posts about understanding events or systems and the event source pattern of course you can always go to demo.com and you can always ask us questions on discuss.demo.com thank you for watching