 But I appreciate you all joining today. So we have Anthony Lusardi from Digital Asset here, again, to talk about when to use Digital Asset, modeling language, Dan will smart contracts and really going into do they need to be public permissionless and centralized. And we're very grateful that he's here today. And Anthony, I'll hand it off to you now. Yeah, awesome. Yeah, thank you very much, everybody, for having me here. Thanks, Chris, for helping me put it together. And David, as well. I really appreciate getting the opportunity to talk about these things, which is less about Dan will specifically, except at the end, talk a little bit about it and more about when do we need our smart contracts to be public permissionless and decentralized. And also, I would caveat one small, small thing there is that demo actually doesn't stand for anything anymore. So it's really just a demo. It's not Digital Asset's markup language. But anyway, let's get started. And also, I'll want everybody to know that you're free to ask questions whenever you want. If I'm talking and you feel like interrupting, go ahead. I really want to make sure that the session is engaging and that people can ask questions. And we can all actually discuss these things rather than just me dictating to you to even further incentivize that. The first five people who ask questions will send you some demo swag. And we actually have some pretty cool t-shirts that aren't just the corporate logo, but actually look a little fun. So I'll drop my email in the chat. And if you are one of those people, this is basically on the Honor system. Just email me. And I'll get back to you with all the info I need in order to get you your shirt. But anyway, that's my email address. And yeah, let's get started. So to answer my question for myself, at least, I would say that some of our smart contracts absolutely need to be public, permissionless, and decentralized. But all of them don't. And I'll disclaim this too in the rest of this talk with the fact that I personally love public chains. I am huge into Bitcoin. And I personally think that the world changed significantly in 2009. And so I'm definitely trying. I'm definitely approaching this from a aspect where I think that these technologies coexist. And they accomplish largely different goals from each other. But on the more private side, it happens to be inspired by the public side, but does some things a little different. And so that leads me to the first question for the audience. And since this is a hyperledger audience, I imagine some people might have thoughts on this. So if you do, maybe I'll give you a moment to think about it. But why would we want permissioned smart contracts as opposed to everything being a public smart contract? All right, no takers. So I'll actually I'll say mine then. And if anybody comes up with anything in between, then feel free to chime in. But anyway, it's in my mind, it's because decentralization doesn't really solve every problem. And really, unless your asset on a public network is fully issued by it and enforced by it, by the network itself, decentralization would actually leave you in a situation where applications become much more costly in their operation, much more exploitable, and aren't really providing the guarantees that you expect applications to provide. You actually see that a lot in present day smart contract applications where, because of the software development lifecycle, devs actually need to upgrade their smart contracts. And because of that, they are very often end up trading off the benefits of decentralization and largely just losing them. And in exchange, are accepting all the negative aspects where, like I said, it becomes much more costly to operate your codes out there completely in public and anybody can see it. And if they find an exploit, they can run it at any time off into great profit, as we see fairly regularly in the news. And you lose out on those guarantees. So that is unfortunate for a lot of different applications. And then further, when it comes to public chains, what we're really seeing is a very narrow band of applications succeed, particularly financial applications. And we don't really see much else. And my own feeling on why that is, and I think that this is actually well supported by the facts as I'll show on, the next slide is public blockchains need transaction fees. There's a lot of claims out there that you can get rid of them, but it is my opinion and quite a well accepted one that transaction fees are needed for public blockchains because they incentivize the block producers to sustain the blockchain too, and they also help prevent spam and because they encourage a wide amount of block producers, they provide security to the network. So these transaction fees are actually very necessary. And transaction fees aren't going to be a core part of why you would use private chains. They have their own benefits beyond this, but this is one thing where we see kind of what public blockchains are kind of limiting themselves to really by necessity, by function of how they work. And really that boils down to when you have financial transactions, you really just have to answer the question, can I make money on this? So on those transactions, participants become very insensitive to the actual cost of doing them as long as it can be a profitable transaction for them, for themselves. Whereas on the other side, you might have the question now, is it really worth spending $50 right now to renew my decentralized domain name? And that's what we're actually seeing too. So if we went to EtherScan and we look at the top 50 addresses of those that we can identify, not all of these we can identify, a lot of them are probably exchanges, but of the ones that are well-identified, they're basically all financial applications. In fact, the one non-financial application that sometimes makes it into the top 50 here is ENS, that decentralized domain name on Ethereum. And that's really like so far down the list that it's sometimes in the top 50 and sometimes not. And prices here too are just fluctuating substantially, which makes it very unpredictable as to when you can affordably use most contracts on Ethereum. And really on any public blockchain, it becomes, when you're doing large applications on them, it becomes very cost prohibitive because costs fluctuate so much. Not so much with value transfers because they're so small, but as your transaction gets more and more complex, it just becomes more and more costly. And then that will itself be a factor of pounds based on the congestion on the network. As you can see, even right now, it costs about $15 just to swap the token on Ethereum. And that's basically all I'm going to talk about application specifics here, but it's something to keep in mind that public blockchains have really limited themselves to these things by necessity, which is fine. I mean, it's a huge space in general, but it doesn't really leave room for some other creativity. And so I have another question for the audience and really I want to know what do you think then some of the other pros and cons of the public and private chain choice are? And then I'll of course also give my thoughts. Ling Cheng said business logic or that was a few minutes ago. I think that was in regards to the first one. Oh, okay. Sorry, I didn't see the chat. I had it behind the other window. And just Herwood said security and ownership of nodes. Yeah, absolutely. That's a pro on the private side because you get to, well, in both you get to run your nodes, but you actually get full control over how your node is structured rather than having to be very broadcasting, talking to the entire world. And Jess also says where trust needs to exist versus where it needs to be developed. That's also true. That's another trade-off. If trust needs to exist in a business relationship and that's a pro of a private chain, if it doesn't need to exist or if it's in a way or if you are capable of structuring it away where it is not necessary, then that's a pro of a public chain, but those are very good points. And yeah, so I have quite a list and actually some of those, those are on it as well. Pros, one big thing. Oh, Jess also says all around cost and interoperability. Yep. As we saw with public chains costs are, it's not just about being expensive. It's that costs are unreliable. You can't really predict next month what your costs are going to look like because you're at the behest of the other, all the other participants in the network. And also, yes, interop is much easier because while there is still, there are still elements of trust in a private network that actually makes it so that you can interop in much more traditional ways. It's actually very hard for two public chains to truly trustlessly as they would really need to, you know, transfer assets between themselves. There are a variety of schemes, but really much, much simpler interoperability there. So yeah, that's another great point. And yeah, so one of the things I had here is simpler upgrade authority. So really like I mentioned earlier, even on permission list ledger centralization is a major, upgrades are a major source of centralization, even on permission of sledgers. You know, there's some exceptions like the Uniswap standard, at least the V1. I think V2 and V3 might have some governance introduced, but I'm not too up to date on them. But most smart contracts have this upgrade path that by necessity is going to be controlled by a small group of people or an equally small group of large token holders. And this is true in both public and private chains. There will be upgrade paths. There's different ways of structuring it such that, you know, people can selectively upgrade and opt into upgrading. Also again, on both public and private chains, that's actually kind of the methods that we recommend with Damol ourselves and that a lot of other people are doing on a variety of languages and on other platforms. But that's always something to consider is that upgrades introduce centralization in some way to some degree and largely is the same across public and private chains except when you're talking about base layer upgrades. And so then in that case, you know, having this authority rather than having it be abstracted, deep in a smart contract and rely on very new untested forms of governance, you can actually just have a very simple, this is who's going to be able to upgrade this contract when and how, which I think is very nice to have, especially when, you know, that full lack of control is actually very hard to implement. Also privacy and so by necessity, you know, all public chain state has to be shared with all people. And this has led to like a real industry of bot reducers, exploit, discovers and really cool things called flash loans that I recommend people check out just go ahead and Google flash loans. It is really, really cool to see some of the, it's a crazy thing that happens on public chains. It's probably a fairly harmful thing that happens on public chains, but it's also a very technically and financially interesting thing that happens on them. So I don't promote using flash loans or anything, but it's a really, really interesting thing there. And, you know, it's really this brand new tool chest where people can go ahead and find weaknesses and that lack of privacy leads to it. And then the, probably also poor coding practices on some other cases lead to more of those exploits, but privacy really, really opens up that window maximum to the most amount of people who would be capable of exploiting this now are, now are able to. And so on private ledgers, you actually get quite strong permissions on who is shared, on what is shared with who and when, and later I'll actually show you how that's achieved in Damo. And also similarly, trust is made explicit like I mentioned, create authority. On public chains, you generally trust somebody via the token holders to vote properly or the dev team or others who just simply hold the keys to upgrade the contract. Whereas on private chains, you can take that implicit and poorly defined trust, make it explicit. And so it'll be well-defined. And so you know exactly who you're trusting, when you're trusting them and how. And I think that's something that is really, really missing from public chains in general, except for some cases where it's not. Went off the screen a little bit there, but operational costs are cheaper and predictable. So as mentioned earlier, whatever the costs are for each network participants around the server, no more, no less, that's what it costs. And it ends up being cheaper too, because you don't need to make certain guarantees that I'll talk about on the next slide, which removes financially incentivizing block producers to behave well. You don't have that layer because you are trading off and putting a little more trust in the system. And that really reduces your operational costs. Also is going to make them much more predictable. You'll know if I'm putting a shank through this many transactions on average, it's going to cost me this much. If I suddenly need to burst and increase my capacity to do 10 times more than that, I know roughly how much that's going to cost me, whereas on a public chain, I won't know that. At least not in any sort of sense of the future. But let's talk a little bit about some cons on using private chains over public chains. And the first really is that they're not permissionless. So if you need your application to be deployed once, run forever, never have any intended interference or change to it, then private ledgers probably aren't the place for your application. Private ledgers in general are going to trend towards well-permissions contracts, meaning parties to a contract and all parties to it, and their respective nodes all have permissions, rights, and obligations over their contracts. But of course, it's also now exactly what we mean when we're talking about permissionless public chains. So what we mean there is that anyone anywhere on a permissionless chain can access the contract as long as they can pay the transaction fee to do so. This is not something that's possible on private blockchains. You can create really open, a low permission, federated entities with it, but you cannot entirely remove the permissioning of it in the same way you would be able to on a public permissionless blockchain. And so this might not always matter, and many practical applications deployed on public blockchains actually do have a permissions architecture. So it's really worth considering whether or not your public and permissionless application, and probably applies less so for the hyper ledger side, but really it's worth considering whether or not you need these things. If you truly need permissionlessness, which will give you the next point, censorship resistance, then you want a public permissionless chain. And so with censorship resistance, there is the argument that even public, even sorry, even private chains are censorship resistant because you can go ahead and deploy your own private ledger and nobody else can stop you. It's not censorship resistant in the way people talk about it in the public space where really any node can choose to exclude any other node and they have positives and tradeoffs to that or any node can choose to exclude any other party and there's positives and negatives to that, but it is possible whereas with the public chain, it's not. So those are really the two major things that you won't be able to get in the private blockchain space. You can still get to a very high degree of censorship resistance in a private blockchain somewhat, but not anywhere near the same degree you will in a public one. And there's actually quite a lot of detail there that I think would probably take up the rest of this talk. So let's just leave it at that for right now. And so now I just wanna talk a little bit about DEML itself and kind of what the pros and cons of it are. So, or really the pros of DEML. So the first is that DEML has a, or it gives you a simplified stack. DEML is a very high level language that with its tooling abstracts away lots of concerns. So you don't need to make any assumptions about the underlying data storage or any of the core platform code, you get this very clean separation. You don't have to muck around with ABI's or other data formats that are very terse by necessity in some cases. And instead you can use very standard GRPC and JSON interfaces that also those interfaces themselves automatically derive from your code, which I think is really cool. And for DEML by virtue of it being a functional language, you get a lot more guarantees. So you get with DEML using the UTXO model essentially you have transactions that don't have unintended execution paths. Every execution path in every next step at a DEML application is known ahead of time. And for the majority of errors and issues, those are actually all caught at compile time before your application ever ends up on a network as opposed to execution time when it's live and running. You also get the ability to explicitly define, read, write and execute permissions, which DEML is going to enforce, which gives you these very explicit obligations and kind of ties back to earlier where I said, you know, if you need to trust somebody in part of your business application, then you should at least make sure you're explicit about it. And this really like make sure that you can specify who can read, who can write and who can execute on this smart contract without other parties being able to read, write or execute if they're not allowed to. And you also get a lot of platform flexibility and interoperability as just mentioned earlier, code that's written for most chains today, whether they're public or private, tend to have these very tight couplings of their execution environment and data storage. And also, so it's tied to their network architecture as well and these public and private deployments tend towards one or two platforms taking really the lion's share of the space. And so what that means is if you end up choosing an architecture that ends up not being one of the bigger winners in the space, then you might find you have a hard time finding support you need. And so with Daniel, we basically separate the runtime from the platform. The platform that it's running on will be used for its data persistence and consensus, which are very, very valuable parts of this whole equation. But then you then also have the flexibility and the ability to interrupt with other platforms or even just other nodes running the same software as well. And yeah, lastly, there's really no need for reconciliation. And this is one of the biggest pros of, I would say, blockchains in general in the space. And I think when you boil it down, like when people talk about using blockchains to solve business problems, what they're really talking about is the fact that there are all these people out there who desperately, desperately want to work together on a business problem. And what they end up with is if you keep a copy of your data, your client keeps a copy of their data. It's not in the same format. It's not following the same schema. It doesn't have the same exact expectations. You could imagine if you were to give five programmers the same exact RFC and say implement the spec such that it can act, such that these applications can interoperate with each other. Of those five programmers, you might get back six or seven different implementations. It's very, very hard to match specs together with these things. And so really with Damol, you get the very simple ability to codify all your operations between two or more parties that want to work together but are going to otherwise not be able to match their specs. And what this boils down to is that both parties can share the same schema and keep the same matching set of records relative to the parts of records that they are authorized to see and use without having disparate records that are going to periodically fall out of sync with each other and need to be reconciled with each other. That reconciliation on top of just being really, really hard to do in general is also very expensive in and of itself. And yeah, so I am actually getting close to the end of my presentation here, but I just wanted to show you a little bit about what Damol looks like in case you're unfamiliar and kind of how it codifies these processes. So like I said before, Damol has these abilities to say, who can sign off of my contract? This is like a signatory to a real-life contract that you would sign on a piece of paper. This is the person authorizing it. These are observers. These are who you share the contract with such that they can see it. And you can have guarantees of things you can enforce any sort of prerequisites that you want, essentially. And then you can be very explicit about who can do what, when, with the contract. So for example, to accept BRIOU, that's over here, the recipient can actually choose to accept it and go ahead and create that actual obligation. Or the recipient can go ahead and reject it and essentially archive this contract. All this little function down here does is it archives the contract. So like I mentioned earlier, Damol is a UTXO model, which makes reasoning about the state of your contracts very simple. And so when you run one of these choices, the contract itself archives and the other choices aren't going to be able to execute because you need an active contract in order to execute a choice on it. And so that's really all that does. It's a little helper function. And really that's what it looks like. And it gives you quite a lot of things from there because that little bit of code, actually, this is all the code to my front end. I'm not the best at writing front end code. Maybe somebody could write somewhat meter code than me. And obviously this presentation isn't very clear because it was too much to fit on a slide. But it does show you that you get quite a lot for free and you can have a full featured application with very, very little behind it other than the business logic here. Right now you'll notice we haven't worked with, we haven't worried about our data persistence. We're not worrying about our actual deployment here. We're not worrying about any sort of consensus because both deployment and consensus are largely handled by the blockchains we run on top of. We're not worrying about our JSON API or GRPC API. All that is free. And I think that's pretty great. And yes, so in conclusion, and obviously if anybody has any comments or questions, we still have a bit of time here, but I'd say not everything needs to be public. And really in most interactions, you do end up trusting someone. So you might as well be explicit about it. And yeah, that's my talk. If I'll just ask you a question here, is Damol hosted as a platform or simply a programming language? It's actually both. So Damol itself, what I'm referring to Damol for the most part, I'm referring to the programming language. But we also have a essentially an SDK on top of it that we call Damol Connect. And that includes your JSON API, GRPC API. It includes a bunch of tooling to help you develop your applications. It includes co-generator tools that can make sense of your Damol code itself and make interfaces such that your user interface can easily hook into it in both JavaScript and Java and a lot of other stuff. And then yes, there are also places to host and deploy Damol code. So we have hub.damol.com. And then we also have a bunch of partners, you know, at VMware, Oracle and other places where you can go ahead and use them as well. And so can I talk a bit more about interoperability? Yes. So for interop, we have something called Canton. And what Canton does is it essentially allows you to, sorry. What Canton does is it allows you to take your Damol applications and without writing any other code, have them communicate across either the same blockchain, like if you have two fabric nodes and you want to interrupt between them or between completely different ones. So if you want your fabric node to talk to your sawtooth node and they're both running Damol smart contracts, Canton will be able to do that. So you can actually check it out at Canton.io. And you can also visit bit.ly slash try Damol. And that'll get you to a forum post on our fairly active forum where we have a bunch of links to these things up. I don't know if the Canton one's there. So I'm going to add that immediately after this call. But yeah, it's a great resource to start off with there. And Polly has a question. Can EVM and Damol be run simultaneously? Or is it either or? Say on Bessu, can Damol be run on public UTXO chains? So that's, there's a lot there. I would say, so when you're running Damol on Bessu, for example, if your code is in Damol, it can't directly talk to any code that's running purely in EVM because it wouldn't be able to enforce the guarantees from those contracts to the Damol contracts. So, you know, you could always rig up a compatibility layer or something there, but I would say that in general, when you're trying to do these things, like once you've committed to using your Damol code, it's not going to be able to interrupt with, or it's not going to be able to freely interrupt with non-Damol code. You'll need to either have a compatibility layer there or I'd actually recommend, you know, porting your code over. If you actually tried it out, you might find that it's actually pretty easy to do. And can Damol be run on public UTXO chains? The short answer to that is yes, of course, because Damol doesn't care about where it's persisting data. But again, Damol is just, is not actually, wouldn't be actually be executing on those chains, wouldn't be giving you the trustless properties of those chains. It would be writing data to those chains that then other people could read off of and maybe connect their own runtime to. We do have some slightly old examples of these things working. And we have, for example, a reference application that can, you know, execute Bitcoin transactions on a Bitcoin test network. And we also have some other things that can do similar stuff on a test of theorem network. But I would say that in general, it really is more geared towards private chains. And so what's this question from Jess? Could Damol manage a multi-chain hybrid model with some things being done on private and some things offload to public? Yes, absolutely. So Damol can like pretty much anything else out there interact with whatever you want. You know, you would just need to make it talk to the JSON API or GRPC API. And yeah, you could have a hybrid model like that. Oh, we also have a question from YouTube. Thanks, Steve. So Hamza says, can we consider smart contracts used by only one participant on a private network? Let's say three participants are there and each has their own smart contracts no one else is using. Is this a valid use case? Yeah, I can't see why that wouldn't be a valid use case. That's actually one nice benefit of Damol, too, is that you can go ahead and deploy this single node and a variety of people could use it for completely different applications and you don't have to worry about your node being application-specific. There are some cases right now where in some of the private space you have when you deploy your chain, you are deploying a very application-specific chain and Damol doesn't have that restriction. So yeah, that's a great question, Hamza. And it's definitely a valid use case. And yeah. Any other questions right now? Thanks again, Anthony. That was really informative. And thank you, everyone, who asked questions. A lot of good constructive discussion here. Yeah, absolutely. I got a lot of great questions. Again, before everybody leaves, and I'll actually say it, my email address is anthony.losarty at digitalasset.com. That's A-N-T-H-O-N-Y dot L-U-S-A-R-D-I at digitalasset.com. If you ask a question, this, of course, will be on the Honor System. Please go ahead and email me and I will make sure you get your t-shirt. No, we do have some pretty cool ones, in my opinion. But yeah, thanks, Chris and David, for having me and thanks everybody for listening and asking such great questions. Awesome. Thank you again. And we look forward to everyone joining the next meetup. And again, as always, if anything that you would like to present or talk about, please feel free to reach out to me and we'll try and fit you in within the schedule. Great, thanks everyone. Thank you. Thank you.