Daml and Canton: Privacy-aware smart contracts on interoperable ledgers by Andreas Lochbihler [2021]

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

1. 0:00

   welcome to a presentation on dumbledore canton the privacy of where my contracts on interoperable lecture i'm addressing foreign oh yeah sorry thank you um a former methods engineer at digital asset working on both the language and the synchronization protocol so what is this all about um essentially we consider the big uh promise of distributed ledgers to be and the idea of distributed ledger breaking data silence so if we look at what we

2. 0:46

   currently have um in industry is well we've got different organizations parties a b and c and each of them keeps their own data in their own database and this makes it actually hard to cross automate workflows to cross organization boundaries because all these data formats are different so we need to invest a lot of money into uh building integration software and those data silos usually are not perfectly consistent so there's

3. 1:17

   disagreement we need reconciliation mechanisms out the light the world would be much better in terms of automating these workflows if we had a shared ledger or shared database at least at a conceptual level where all participants can then uh write their data to or retrieve the data from and therefore we have a lot less integration effort and a lot less worry about making the data consistent now the problem with such a shared databases of course um how do we manage authorization

4. 1:58

   who can access what data so confidentiality privacy how can we make the whole thing scale so is it spans large number organization and in particular how can we compose those things after the fact because if we have those three parties having their own database then we have another group of parties having their other another database where they put their own data then these would just be bigger silos but they're again silos and we would have the same trouble that we currently have

5. 2:30

   with automating workflows across text so the solution that digital asset is building is essentially demo and countermast a synchronization protocol that was a smart contract language based on haskell and a full stack of tools to develop your application around that but at its very core it provides this abstraction of a shared database that's how we think about it and it has a built-in notion of authorization

6. 3:03

   and something to talk about confidentiality and privacy but of course we can't have such a shared database as it's just a virtual construct that allows us to reason about the smart text in practice we also have an implementation um that tries to implement the abstraction faithfully well white rice well we need to make a few trust assumptions whether they're reasonable that of course depends on the application but in our

7. 3:34

   point of view it is and that works essentially in the scalable why and in a globally composable and this talk is in split into two parts first introducing the abstraction and talking a bit about tamil and then talking a bit about the implementation how it works given that this is more um audience group um please feel free to interrupt me at any point ask questions whatever um if you don't want to be recorded

8. 4:05

   um you can also ask them in the chat window and i can then read them out and answer so let's so maybe i can ask a question are you talking about permissionless satan or permission permission permission setting so as as you will see and yet we might not even need a blockchain a distributed ledger is really more of a synchronization um creating this shared database idea you can use

9. 4:42

   essentially a block chain to talk about your trust assumptions or to to to get a root of trust essentially um but whether you do that in a permission setting or a permissionless setting that's then not the concern that we're working with mostly we're talking here about a permission setting so okay thanks got it all right so let's start with the abstraction um essentially the abstraction is a ledger model

10. 5:20

    and you can find more on docsdonald.com about it um so what is this abstraction well a ledger or a blockchain is very good at ordering six right so we're putting things in order and what we put in order that's very flexible and what we've chosen to put in order is hierarchical transactions they're produced by an interpreter that uh basically reads smart contract code and produces these things so you see here a

11. 5:52

    hierarchical transaction in the middle of the stream um that has on the nodes descriptions of some action on data that we store on the ledger and then the arrows indicate indicate essentially a consequence relation so as a consequence of performing a certain action on data one um we actually have two consequences you also need to perform action on data two in action on data four and they again have further consequences and that hierarchy essentially gives us composability of workflows so

12. 6:26

    one could specify left hand side the action on data two with the consequence of the action of data three as uh one workflow and the right subtree as another workflow and then you can compose them without having uh envisioned that you ever want to compose them later just by putting them together and that is what you get when you do such a trade like structure now um we're talking here about

13. 6:56

    privacy aware smart contracts so we also need to talk about authorization and confidentiality policies and what you can do in donald is basically annotate each node in the train with who needs to authorize this and then you also need to and then you can also say who needs who's allowed to see this piece of data what we should be able to uh read from that uh read that data uh at least within the lecture of course if carol and donald just have access to

14. 7:33

    that data and learn that data once they have been given that data they can distribute that with uh via out of bounds channels so there's no mechanism to actually really control who sees that data it's just a control on what the legend distributes to whom the ledger distributes his data and what these people then do with it that's out of scope of the social technical solution right so i said okay we're good at ordering things if we have a blockchain or a

15. 8:07

    distributed religion so we can put essentially those transactions one after the other in in the conceptual model and we can then summarize essentially the state from past transactions as the set of smart contract states instances directed and here we have a simple example suppose we have a token um that is issued by carol and owned currently by alice we have another token issued by donald and that's owned by bob and then alice has made an offer

16. 8:42

    to bob to trade her token issued by sea with a token issued body and if bob is willing to enter that trade he could then exit you could then produce such a transaction and then um have it committed to the ledger so b submits awesomeness um such three and that three here is an exercise so on that offer there's an accept choice and that uses as an input this offer contract that we see here as current active state and as a consequence it just does a transfer of the two tokens

17. 9:22

    so swap and of course here we see the composability in terms of um sub transactions because this subtree would be just a token transfer that one can implement independently and maintain and the right hand sub tree is just the same thing again it's uh transferring the d token from bob to us so here we're consuming the token and here we're creating a new right so if we move past this transaction how

18. 9:55

    does the state of our ledger essentially change the set of active contract instances well now alice owns a token body and bob owns a token by c and the offer contract has been consumed so this is essentially the ut examiner any questions so far so is it executed all these transactions are executed on the single blockchain or different blockchains so this transaction right so this is a good question at the moment we're still at the abstract level where we imagine we have

19. 10:32

    a shared database right so on that shared database well you just have a list and everything is totally ordered when you come to the implementation you can then start to think about well okay this token can live on one blockchain that token can live on another blockchain and the whole thing is coordinated by a certain blockchain yeah that that is essentially what this data model gives us right because we will later see how we can compute from this hierarchical thing things that we can decompose and center

20. 11:06

    different parts okay um but before we go into how we ship these kind of things and we can also talk about visibility and for such a transaction essentially we can build boxes and have increasing visibility as we move down in the tree right so carol the issuer of the token that was originally owned by alice doesn't need to be aware of all the rest of what's happening carol should only be concerned with the total transfer

21. 11:44

    similarly donald needs only to be uh concerned with token transfer issued by him and alice and bob they need to agree on oh yeah we're doing this um swap of tokens so they they will see everything and that can be computed just from what we have annotated and now how do we reason about that well um formally if you write that down as a mathematical definition such a ledger is nice but um it's just

22. 12:21

    too low too large a thick right so you can have ledges where you can use the same contract several times you could have ledges just from syntax you could have ledges that have nothing to do with your your model because we haven't talked about anything there yet or they're not bothered but um what you can express here saying well we want the model to be consistent in the sense that we don't have double spends you can use the contract only after you've created it

23. 12:52

    and those kind of things and these can be expressed using this linear order who are essentially counting uh summarizing dimension state we want the things to be conformant to a model and a model here essentially describes the valid actions how the data can be involved and that's actually the logic that's implemented in the smart contract which can be written in demo you could also implement this with with other smart contract languages that map to this abstract model but um we're currently only half just implementation

24. 13:25

    and then there's authorization we want that all actions are properly authorized and if we go back yeah go back to here um because bob accepts this exercises accept choice bob certainly needs to authorize this root note but we also want to have that sub roots so that the whole sub tree is authorized and certainly here well bob executes on behalf of ellis as part of accepting the

25. 13:57

    offer the transfer of alice's token to bob right for that we need alice's authority and that authority is actually derived by alice having having made that offer so by making the offer alice is found essentially to accept that bob uses her transfer choice so we need to have some sort of delication in the model built into that and you can write that down with formal mathematical specifications that's well authorization and

26. 14:28

    what would basically nicely say is we only want to consider valid ledges where we don't have double spends um where we adhere to the uh code that's prescribed in the model in the demo mode and that satisfy the authorization and if you want to write that in demo so this is a preview of the language which that we have it's basically open source on donald.com it's more or less haskell with a bit of custom syntax and a few primitives um for expressing

27. 15:05

    rise and obligations uh integrated here in vs code ah as an editor so what we see here here we see a template token which is essentially the data definition of is is a token with an issuer an owner and we say that the issuer is the one who can basically create it uh and the owner can then have to control to transfer the contract to a new owner and then we're creating right and that's

28. 15:35

    a very nice and declarative way to specify things you can also run essentially the um your your scenarios so small cases uh use cases to to to see how the program evolves and that gives you essentially what you see here in terms of legislate so originally with heart tokens where carol's token was owned by allies and now after the swap it's now called owned by bob and vice versa and that happens at different uh they these were created at different transactions

29. 16:12

    and are visible to different people right so for example the x here says that carol is aware of this token whereas donald is not aware of this token even so they participated in the same uh transaction after youths in practice we've got a few clients from the finance industry um you build various trading settlements clearing systems uh data exchange formats that kind of stuff um because in the financial world as you know uh it's very easy to digitize uh goods and therefore to transfer them and

30. 16:53

    therefore it's it's a prime example for for that kind of thing we've also got a few customers from the healthcare space um they're mostly interested in essentially the privacy guarantees because if you want to store health care data or personal uh personal and identifiable information you quickly get into regulatory issues especially you need to make sure that you're able to delete the data eventually and that's something um we can offer with with the solution

31. 17:26

    and we're also working together with big consulting friends like accenture to pulsation so that was a very very high level discussion of the abstract concept as a summary we have this list of transactions that we want to think about and that you can wrap your head around so if we go now for the implementation well how do we want to implement that faithfully and scalable with reasonable trust assumptions so what we're basically looking here for is

32. 17:58

    synchronization well the simplest solution to implement that is of course to find a trusted third party who runs the database that can work in some cases but you need to have significant trust in the third party well both for integrity well you can mitigate integrity by doing some replication and do bft start consensus but for confidentiality you also have a single point of failure because

33. 18:30

    well if any of the replicas uh is broken essentially the data can be um siphoned away from there and we're back into the data science problem because if you uh because different groups of parties may not be able to agree on the same trusted third party and therefore we're back to data science the better way to go about this is to think about oh let's store the data actually at the participant notes

34. 19:00

    right so here we have two participant nodes and you can have money and then we just need a synchronization primitive to keep them essentially in sync and that is what we call a canton domain an accounting domain you can then implement on something like a hyperledger fabric or an ethereum blockchain or something like fiscal because that's the integrations we currently have um but you can also run it just with plain database as a backend and the domain essentially

35. 19:34

    acts as your route of trust so what does that domain do well there's two components to it the sequencer and the mediator as we call them the sequence is responsible for implementing a total order multicast so it doesn't need to know what the data is that it's shipping around just needs to make sure that the relevant parties see the relevant data in the right order and the mediator essentially acts as the coordinator in a two-phase commit

36. 20:04

    program protocol itself we'll see in a minute but as you asked before we need to uh prepare what we should wear right so this was our example transaction um we're going to split that up into many boxes so there's one outer box that's going to be sent to alice and bob now as we talked there are these sub-transactions and these are workflows on their own so they deserve to be in a box on their own

37. 20:37

    so the token transfer that is of course a workflow that originates from the business relationship between address and the token issue carol but of course by as a consequence we certainly also have a business relationship between bob and carol because suddenly bob will own a token issued by carol so that suck box needs then also be shipped to bob and carol in addition to being shipped to us

38. 21:08

    and the same on the right hand side now so if we have split up the box and dot y we can then look at essentially how we do that so bob initiates the whole thing by sending encrypted versions of all these things to the sequencer and all that the sequencer does is basically assigning a timestamp so this can be a virtual timestamp but essentially it's the way to guarantee um the ordering it forwards a summary to the mediator and

39. 21:40

    distributes the envelopes according to their receptions to those parties and then those parties do their job of validating of validating the uh transaction request that includes validating that contracts are still active so for example carol in her validation phase will check that actually yes this is still a valid token that i have issued to alice therefore i'm going to approve it and this is how you can prevent double

40. 22:19

    spends and then once all parties that need to respond have responded or maybe someone have rejected the whole thing um those verdicts essentially come to the mediator in essentially the collect phase of a two-phase commit protocol and once it has received enough responses we can then move on to the decision phase where the mediator as a centralized instance can decide okay i'm gonna commit that or i'm gonna abort it that information is again distributed to everyone that's involved

41. 22:57

    and then we can execute so um in terms of confidentiality privacy and scalability who sees what that's actually the important part and that's where we refer to a privacy aware smart contract so we still have that and bob and alice since they see the root node and are involved in the root note of the transaction they also of course can compute what uh the children those are and therefore they see everything so that's something we've already talked

42. 23:30

    about what carol sees right so carol will see some merkle tree that just ha just reveals the left-hand subtree so carol will learn oh yeah there's something bigger involved in there but i only get the data that's involved in the left uh such branch and that is what we call carol's projection in the ledger model and there we have a theory that well if you project a valid ledger then you end up again with a valid edge so this is an important uh aspect

43. 24:09

    and that is essentially the um the cornerstone why this whole thing works in a distributed setting because you can transport validity back and forth over those projections and that's why you can check it in a distributed way the sequence of the mediator which are the root of the trust they only see essentially the structure and who's involved they don't see the actual business data

44. 24:41

    that's being communicated and that's actually the important thing so this transaction will look the same if there is instead of a token some other contract being exchanged or if say you have a numeric field in there you can't learn the value that's involved in there because um all the data that they get is ready to start piece and in particular if everything comes along the innocent bystander well in that protocol it doesn't see anything of course you can monitor

45. 25:16

    the incoming and outgoing traffic uh on on on the domain and therefore make its deductions um but as part of the protocol it doesn't receive anything so you can try to find lower level attacks to infer some pieces of data but if we assume that these channels are securely secure communication channels eric doesn't learn anything about what's actually going on so um that brings me to the end of the half hour overview

46. 25:54

    session i've briefly talked about the ledger model um which gives us an idea of freedom right or authorization over hierarchical rules and a two-phase commit protocol so the interesting bit that we have been asked before is of course well um can we run that over multiple blockchains and of course the answer is yes so if we know that this token for elvis is managed on one domain and that token is managed on another domain then we don't only involve the sequencer

47. 26:34

    and the mediator of one domain but we would probably have the sequence intermediate of the of the top notes domain to be the commit coordinator and all the other domains being essentially the secondary domains that are need to wait on the decision of the mediator of the coordinating domain and the point here is that well why can't they actually wait is because the mediator and the sequencer don't see what the transaction is actually involved involving

48. 27:14

    they don't really care the only way they know that they should accept the other blockchain's verdict comes from the fact that on that other that alice and bob have expressed their consent that they want to be part of that transaction on that other domain and that's how they derive that they should act upon such a thing right so any questions uh yeah oh sorry go ahead go go ahead no no no go ahead no you go ahead

49. 27:58

    okay uh i i just wanted to say that it actually looks uh quite interesting it reminds me what uh of what people are doing at cosmos now you know uh there is this cosmos infrastructure there is also kind of uh a protocol to to establish two-phase commit basically between different blockchains yeah yeah something something that we must say here is um the commit protocol that we have is not intended to interact with native applications on that blockchain

50. 28:36

    right right um if you want to integrate that site i have an erc20 token on the theory that i want to transfer to i don't know some other token on some other chain what would the workflow would look like that you would first need to transfer your eoc 20 token on that blockchain into its integer demo world then you can do all your demo stuff cross chain blaster and then essentially you

51. 29:06

    would transfer it back by another native integration for that particular piece of token on the target uh on the target zone so you would get essentially three transactions right and only the cross change thing what that executes atomically is what uh is done in in donald and the rest is essentially preparatory stuff on the individual objects do you have any notion of a timeout if if just takes too long to

52. 29:38

    to commit a transaction or something yeah so um time is always a difficult thing in a distributed system right so um if you if you involve only a single domain as we see here in the diagram then you can very easily define timeouts because by having a total order multicast here everyone reads stuff in the same order and therefore everyone comes to the conclusion this has timed out at the same point in time

53. 30:09

    so yes you can easily do a timeout there if you talk about cross-domain things you essentially can only have timeouts on the coordinating domain and for the other things nothing there but then you always have the chance to say oh after a certain period of time i actually submit an abort request and when that gets sequenced that will override if later the original request was actually sequenced and that of course can then be distributed again right and that's the coordinator who is

54. 30:42

    sequencer who is taking care of it right this is where where the route of trust lies right and by choosing the blockchain that you wish you can then pick the trust assumptions that you need yeah yeah it sounds cool yeah maybe anthony has no time to ask questions oh good um yeah so basically i was wondering if you could just explain for a moment uh kind of how delegation works with some of these

55. 31:15

    contracts because we have some contracts creating other ones right so if we go back to the um ledger model that one that's where i talked a bit about delegation so essentially every exercise has an idea of an actor or the controller as we as as you can write it also in demo and that is required to authorize that action and that can be a single party or a set of parties it can be dynamically computed uh it's fairly

56. 31:51

    fairly flexible um and then we have those dollar signs and those dollar signs is what we had seen as the signatory and what that happened what that means is well since ellis is a signatory of the author um that authorization propagates to the immediate children right so by creating the offer contract alice has consented that if bob accepts the offer then the car the token contract will be transferred right so this sub transaction here

57. 32:32

    we see that alice here is the actor so we need the authority from there and we basically inherit it by using the fact that alice has consented to create that offer and that way you get essentially this idea of of delegation and you can pass that uh even down several layers by making it explicit that oh yeah the authority from up here shall go through the actor here and end up down here yeah makes sense

58. 33:10

    sorry was i muted it makes sense thank you yep any further questions diamond i i can ask quan again so this contract language uh how do people react at it i know it's a functional language right and if you talk to to like average blockchain people they would say we want something like javascript or salidisi everybody hates celestia but still they want to to have something like that what's the reaction um i guess i play that question to anthony who has

59. 33:52

    probably more insight into uh how our customers reacted out than the thing in the well you've done in the development and research area but yeah definitely it is a different uh kind of language and it requires a different kind of thinking so if you approach it for the first time um you can make an analogy as oh this is a data definition language like sql and the exercise choices are actually stored procedures

60. 34:26

    if you tell that people then they will apply their sql skills and uh just think about how do how would i store that in a database um that doesn't exploit the full nature of how to get it really properly working with authorization in a distributed setting but it's also one way to go about it anthony uh yeah i would say that well really depends on on who you're talking to i think that one of the advantages that

61. 34:58

    something like solidity and uh you know a very turning complete-ish uh public blockchain has over some other ones is a whole um at least in the context of people who wanna who are interested in those things is that you know they can write the code and deploy it and no longer have to be responsible for maintaining it uh basically and it's really like it's often a very different question when you're talking about

62. 35:26

    the more uh private space and you know that's not to disparage the public space um there's obviously you know innovations that are coming out of that like bitcoin for example seems like it's taking over the world but uh i think in general that's one thing that is affecting people when you talk about it and then more to your questioning or when uh people see these functional languages yeah i think that the initial reaction is you know i want to program in a very imperative way

63. 35:59

    uh but ultimately whenever you're programming on any sort of blockchain being private or public you're not programming in that way you really should be thinking about your state and state transitions and things and most of your execution should be atomic which also simplifies things too really you get a lot better scalability and a lot better fall tolerance when you don't have to worry about a shared global state and i think that's something that we

64. 36:30

    often see just becomes issues in some of some chains when they want to have everything be uh during complete and written in in an imperative style in particular so i think that yeah this can definitely be a challenge to somebody who's new to it um but i think in the long run that having a haskell type language for these things having a utxo based model for actually transitioning between uh these states is probably going to be

65. 37:00

    far more advantageous and far less error-prone because says haskell programmers you know always say i'd rather have my errors at compile time than execution and so that's what we hope to get at here yeah so so let me out today um by by picking a type safe language as the substrate um we avoid a lot of the problems that people nowadays do smart contract verification for right so we don't have decided to oh you

66. 37:32

    you just have a plain bicode language with go-to instructions that can jump into the middle of another instruction and you don't get re-entrance-y attacks and all that kind of stuff just by a properly designed language yeah it grips you i i i i i'm just wondering how how your customers react because i always tell people we should have something better than selling this right and and there are so many languages i guess where people try to do something

67. 38:04

    by trying still solidity is the thing somehow yeah it's it's amazing and yeah i think overall uh you know people in our customers initial reactions might be oh there's this whole functional language i have to learn but what we're finding at least over time is that people start to kind of get it and actually start to really like it so you know for example on our forum we have some very dedicated users who are really you can tell they're just

68. 38:35

    really diving into it and really liking uh the way you can develop with these languages cool that sounds very nice thanks yeah awesome i think i ran out of questions but that's that's very interesting presentations thanks a lot and thanks making it for me essentially you're welcome anytime thanks for joining sure okay i guess i i have to leave but i will i'll be somewhat around i guess if you want yeah on the okay thanks a lot

69. 39:16

    bye bye bye do i just stop recording yeah it'll