NEAR Whiteboard Series with NEAR | Technical Deep Dive Sessions, 31 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Whiteboard Series with NEAR | Ep: 38 Ethan Frey from CosmWasm

Description

CosmWasm Founder Ethan Frey (https://twitter.com/@CosmWasm) and NEAR Developer Nikolay Igotti (https://twitter.com/@NEARProtocol) discuss CosmWasm,

CosmWasm is a new smart contracting platform built for the cosmos ecosystem.

CosmWasm Key Features:
- Tight integration with Cosmos SDK and the Cosmos ecosystem.
- Mature tooling for developing and testing smart contracts.
- Secure architecure design to avoid almost all attack vectors present in Ethereum.
- IBC integration planned at the same time with the Cosmos Hub - prepare for the world of multi-chain contracts

------- About Whiteboard Series ---------

The Whiteboard Series with NEAR is a set of video interviews with Founders who are building scalable solutions for Blockchain. We deep dive into their story, what they're developing and how it is helping the ecosystem.

Follow the latest from NEAR Protocol on,

Website: https://near.org/
Discord: https://near.chat
Twitter: https://twitter.com/NEARProtocol
GitHub: https://near.ai/github

#WhiteboardSeries #Blockchain #FutureIsNEAR

A

uh Hello, my name is uh nicola gutier. I work working here and on the contract runtime and would like to introduce you adam frey. I don't, if tell us some words about yourself and what you're doing.

B

Well, hi yeah. My name is ian fry, I'm the founder of cosmosam. I am.

A

B

From cosmos, if you've heard of the cosmos ibc blockchains and worked in that uh 17 18, some other projects around it and in 2019 got really excited about smart contracts. So I'm looking at that. So.

A

B

uh Summer 2019, I started a project called cosmosim, which is uh web assembly blossom smart contracts embedded in custom sdk. So it's basically um all the tooling uh there's gold blockchains, like cosmos, basically a construction kit and then we're embedding one some contracts into that. um So I actually can answer all the questions about tendermint and sdk as well, because I spent time working that age ago. But all I'm working now is basically run time of that the bindings to the contract and then the contract itself.

A

Okay- and I think uh there are multiple uh blockchains supporting uh wasm contracts. So uh what what would you say is differentiating uh cosmos amount of those.

B

um Our biggest differentiator is we're not blocking. uh I think that so I think that's key people ask yourself: blockchain, maybe will someday, um but we are effectively a platform or a module to integrate other blockings.

B

So what cosmos? The idea is. um These people rejected the theory of maximism maximism everything around ethereum and said, rather than having one chain to rule them all um which was totally impossible theory in 2016 17.. um Let's do a network of blockchains. We connect them the same way the internet scales horizontally.

B

um So that's where it comes from. So what you have is you have a bunch of people, building application, specific blockchains, so they're they're code. The problem is: writing a code. The hard portion for the upgrade is kind of tedious. uh You just now put contracts as issues and smart contracts were a cool idea, so I added them into these. There are currently, I think, six five logistics blockchains in the constant ecosystem that integrated our module into theirs, which means um it runs inside of five or six blockchains.

B

Currently in testnet, um but yeah, it's running there I think near, took a different approach. They looked ethereum and scaled it vertically. So you guys actually broke a lot of the barriers of you know: uh 20 transactions, a second uh by making one chain of can actually scale up to uh you know real world speeds, so we've.

A

Gone horizontally.

B

A bunch of smaller chains, they have decent throughput and they're connected uh horizontally over ibc into blocking communication.

A

Okay and is cause one aiming to public blockchain only or you also want to want to connect uh private blockchains like uh like facebook, for example, libra.

B

Yeah, so this is a big question um right now we're looking at public blockchains, because that's what I've seen um we've looked at enterprise market. I think there's a huge market there actually um and in some way a business opportunity they can use cause of autumn, it's open for them to use apache, and if someone wants to, I think we're not going that route ourselves, because that's a lot of um the private blockchain market requires different expertise. It's enterprise sales.

B

I can sell the startups to cancel the enterprises. I do sell the devs, so um we look at that, and certainly we're not looking at we're very happy if someone else wants to integrate into those um uh private change. They're welcome to please talk to us.

B

A

And and so if you want to integrate like a multiple uh uh blockchains uh in in austin asmr, I think they they usually have their own, like uh runtime for execution of the contracts.

B

A

A custom set of of host functions so, for example, in case of in case of web assembly. It's it's indeed a portable standard. So it's probably okay, if you, if you uh can execute the contract, but how? How do you emulate the behavior of the particular uh blockchain.

B

You're right, uh we kind of don't miss an extraction later. um So the funny thing is decay is one thing I really don't like about it, which they change. They make backwards, compatible changes like every six months, um but that's a good thing too, because we have to use support in different versions. So we said quickly on um the same contract that runs in zero.

B

Thirty seven should run you say: eight there's nine, forty of the customers, okay, um which doesn't get minor to major changes, so we can't use their native uh native functions directly, so we had to make an abstraction layer between that. So um what we currently do is we have uh abstraction for uh sending messages to other uh other modules, which could be either contract or native modules.

B

um We have an abstraction of querying cut, other contracts or native modules, uh and we have a storage, local storage and we have an api which are basically pre-compiles.

B

So what you can do is basically offer a fixed set of functionality which you've standardized more or less, which is the bank module and staking module a lot of ps change, mostly so, um and that and when you call into it, takes your message from the from the contract converts into the native message. Format calls in the date of code takes a response and converts into the contract response. The same contract could run three different chains, uh possibly different versions of different sticky modules.

B

As long as they have an interface, so we define a common api. Basically, the changes implement.

A

B

That's also limited because you can expose extra and we added in recently about a month ago, uh because they're trying to integrate into a native chain that had its own uh swap kind of swap type, uh an oracle treasury type functionality, don't expose it. So we added a way of extending it. So basically we pass messages opaquely through our runtime. So if you want to extend your blockchain, your runtime, uh you can add handlers for different message types and you have it's a custom message type, which is basically just raw raw bytes.

B

You can pass on to your block to interpret it and we allow uh custom messages and custom queries, which means you basically just use a rust, binding, import, rust library, it says, give you these extensions and you have the extension apis and it also has a feature flag, say: okay, this contract only works on terra or only which in regen or notre enigma, because we're using these custom bindings and then the there blockchain handles those custom bindings.

B

um So you can write a portable contract using the standard set which runs on all chains or you can make use of custom custom features for that chain, but then you opt into them, and your contact is only change specific. At that point,.

B

uh There's a bit of a, I know the details on that. Sometimes it's a bunch of rust uh generics in there um and then yeah still vacation and stuff, but yeah. It actually works pretty pretty well um to pass it basically from the wasm.

B

That cares about the the format of the queries messages and it then it takes everything that bytes passes all the way through our virtual machine into a rush binding the go library into the go blockchain uh through about three different packages into the end users code is not ours and that then, actually has a handler for these fights to then uh handle them, and so basically you put that on both in your personal app and on the on the contract.

A

Okay, so it means you generally want to uh provide the servers some similar to what we have a in a standard like uh virtual machines like in java, for example, when you, when you can run the same java application on multiple operating systems by by colonizing their uh porting porting layer into into some some least common denominator.

B

Yeah, exactly and you're also allowed using jni to access the custom stuff with java too so um wonderful actually, ideally like. I will, if you know, if, let's say for change I'll, even simplify version of the swap I'll look for the unisop standard and off that in and they could all put this unicorn center. To the same you know, contract could use unit swap depending not carrying out whose kind of unit swap implementation is um or whether it's a contract native.

B

So that's something I'd like to kind of go towards, but right now we just standardized the basic ones which is moving tokens and staking.

A

Okay, yeah, I guess uh the selection of of the language for writing. The contracts in especially in your situation became very, very interesting problem. So what do you think about that? So do you believe that, like rust rules them all or there are, there should be multiple languages or there should be some other language which is default. So what's your opinion on that.

B

Well, I started rust as the tooling. I had to learn rust anyway before that the tooling for russell was really awesome and I actually learned russ on this project. I made I dabbled it before I'd written like a hobby project, but never done a real project in russ until I started working on this in the hackathon actually uh coding it um luckily with another rest app um but yeah. So if I was cool, I'm really going to love rust, I think it's an awesome language, but it's not for everyone that has a learning curve.

B

So I think maybe everyone will eventually get there, but I don't understand everyone go there tomorrow, right and um I hear a lot of people wishing to have so um cosmos sdk ecosystem, a lot of people program go and they want go. uh Other people talk about javascript, no javascript no or they want kotlin yeah, um I'm. Actually we were very inspired, so we saw parody first, their stuff, while russell saw near protocol- like I don't know, last august or september and uh and saudi had assembly strip working and like as a first class citizen.

B

No- and I was like that's awesome, uh so I've tried a little about this stuff. You know and it's a very nice nice set. We got time. I was very, very impressed with all the work you guys doing and taking user experience, dev experience as like the major point of utility. So I'm very inspired with that. So we are actually planning to add a similar script at some point at some point and go support as well. There's a apparently subset of go called tinygo which compiles the llvm and makes awesome code.

B

uh We have prototyped out minimal concept. It does do a job, uh we'll see how much we can logically put there.

A

B

It's uh it's definitely a plan of ours to add more languages.

A

But I think, I think, generally, like very serious distinction between languages lies in the area of uh automated or manual memory management. So so, if language semantics assumes automated memory in memory management like java, kotlin and javascript implementing it on a current wasm, runtimes may could be very non-trivial.

A

So uh so do you believe that there is a place for languages with automated memory management in a smart contract world.

B

Well, I think you can there's three ways of handling it. um The first ways don't care- and you say we throw away the contact every time right.

B

So during one running of a contract, you probably don't claim that much memory back right like it's, if you're in a hundred times and you allocate an allocated allocate but in one unless you're really uh doing something- weird, you probably don't keep allocating 50k, free, 550k, alexa, 50k, 350k and somehow managed to use 30 megabytes of ram uh by accident, because you're just going to keep keep loop uh in a warm contract.

B

So if you out, if you make a clean fresh instance, every time you run the contract and throw it away at the end, it doesn't really matter honestly: um it's not wasn't wazi which actually keeps long living processes. These run in a millisecond or two. um They shouldn't use that much memory, that's the cheap answer. uh The second answer is um theoretically they're, adding some sort of support for garbage collection memory manager in there you could compile your contract itself, make it huge. You actually could have a garbage collector in your contract.

B

Right, like you, can do all that, keep counting and you have access to all so you could kind of uh yeah. You kind of do that in your contract um quite hard, or we can wait for blossom to add support for the vm.

A

For that level,.

B

um So I definitely prefer I definitely prefer having uh rust and say, okay cleans up the end. I know it's great, but I think definitely people want useful languages. They want to not worry about garbage collection. They don't want to write ceo on russ. They want to write something easy and uh yeah, so I think it's our job building these runtimes and building these to figure out how to do that and whether it is just uh clearing your memory out. Every time you run a contract or whether it's somehow adding stubs to the garbage question.

B

That's uh that's our job.

A

Yes, actually, your first answer is very tempting I'd say it's uh like it's in many cases. Indeed, everybody know that gc is not probably the most straightforward technology in software engineering, so if you can avoid it by just not doing that, it's it's looking deep, very, uh very much attractive.

A

But but what's uh interesting, complete like consequences of that of that action is the limitation of the nature. What uh what the smart contract is. So it's uh it inherently becomes like uh very computationally limited, so it cannot have essentially unbounded allocation uh and de-allocation and inside of its evolution. So so we essentially put certain compute limits on a computation happening inside inside of a smart contract, and do you believe it's a good thing or bad thing.

B

Well, I think it's really good. You want to limit everything there, so I mean, since a smart contract has to run on. I don't know 20 to 100 machines in parallel and it blocks everything else, but well maybe near doesn't maybe run in parallel. That's awesome stuff, um but right now we're basically in the sequential model process, one transaction next transaction, next transaction, um and since you do that, you have to bound it like uh we cannot have a contract running more than 5-10 milliseconds.

B

Now, really, if you have contacts running 10 seconds doing uh doing stuff, then you know the whole watching for 10 seconds, which is not cool right. So uh by the nature of having a sequential blockchain, this linear history, we basically have to have everything native or smart contracts. All code must fit under certain certain limits.

B

um I think laws and outside of that context, can do a lot more and actually the more I get into it. The more I see the potential awesome not just in the web and not just in blockchains but everywhere so wazi, for example, system interface is like kind of this. I see that alternative docker in a way right. You can have these sandbox objects which just have a you know, a very clear interface of what this calls I can use.

B

um Those are actually really cool if you're building stuff like that, you need to have garbage collection or you need to have, um or you need to have automatic memory management like rust for c. So I think that's that creates incredibly important, and so I see the kind of the binding, the the the the conjunction that come together in auction workers. I know parody. Has that term. I use something for them: option workers uh so basically a blockchain triggers a task to run a wasm task to run. It runs in parallel and returns a result.

B

After I don't know, one block two blocks three blocks, so you can do a long-irving task that runs in parallel to the transactions um and actually maybe something a bit more near, because here it allows some sort of uh parallelization like that as well. um But when you start allowing that parallelization and you no longer have to limit the code running time to 10 milliseconds and when you say okay, this can run for one minute.

B

That's fine, just coaching one for a minute and when it's done it'll submit the result and when all the nodes have finished, writing this code. You'll submit all the results back and we have them and we guarantee it's correct, awesome, stuff, great stuff. So yeah.

A

That's exactly what the direction I was heading so like. If we talk about the smart contracts in the current form, then then I'm like raise two hands to support non-member management and stuff like that, but if we actually will think about stuff like smart services and and essentially open web as and smart services as a technology supporting that, then it probably means that what we think about, like a very short short time span and very primitive logic inside which is applicable to classical smart contracts, may not be really appropriate.

A

So so the question is uh probably more like uh not even practical but more like strategic in a sense. So how do you believe will we need in like, in the foreseeable future, uh smart services or smart, like smart applications which run for relatively long time, need relatively significant amount of resources and be able to actually perform theoretically unbound computations.

B

It's a very good question, very good question. I think I look for examples now and I think you know there's things like wearing reddish in the wasabi, which says you work right and it's awesome.

B

um I think there's two levels and the first level is like you're trying uh support contract platform is probably easy to write uh some code and deploy it right. So I think one of the big goals there is to make a barrier of entry developer work to lower that amount. The bare is really really low um and we're achieving that. I think quite a bit with we're achieving that quite a bit by adding other languages by adding assembly script.

B

I think go you know if kotlin is supporting it'll be awesome one day, you know, I think, a few of us from looking at that one as well uh still in productive development, um but I think that's great for me to use it. But if you say, if you want to write real services still you're right, I think it's you're, basically stuck with roster c, to write real long-running services um and stuck with it's not just a bad thing, but just raise lower. Raise the bar of entry, and so one really concrete example.

B

You can think of is running, for example um like clients. So if you want to run these in a browser or anywhere else, um that's a lot of logic. It's a lot of signature validation, a lot of uh math, shot, hashes, trees, trading, trees, subtrees, it's a lot of crazy stuff and a lot of the code we have is available in rust. You know so there is like seven go and some rust on our level.

B

I think indoors, all rust uh paradise love rust coat as well, so this is quite um quite available in the west and you could port that into some smart contracts, whether it's running in your browser, whether it's running in some smart service, uh which is sandbox, that's awesome and those pieces, I think, would have to still be written rust for now in the near future, at least and in the future they'll add, maybe better garbage collection, better language, support for other things, but I would basically say for one-off, smarter things open up to everyone to try.

B

It use wasman standard and if you need to use things that are not in the standard already, I would just uh stick with the rest for that, so I still want to make it a first language. It's my first choice of language uh for coding and I I definitely think the majority of developers will probably not be unrest in you know 60 months a year when they see an alternative but yeah. I think.

A

I definitely want to have more direct.

B

A

So like what was your other language before us, I'm just curious.

B

My last name is go which is boring actually after a while. So.

A

Okay, okay and probably before it was something like c or c, plus, plus right.

B

I started with c uh and you know.

A

B

And uh they were to java, like c c, but plus, there's university well c is like build data structure and safe right, everything you see and so like messing around with stuff or back then late 90s. um Then it was java and then in like the mid 2000s, you know I discovered python javascript, which was cool for hacking out websites, because that was basically the work you're doing then, uh in the like, you know late, not uh early tens and quickly hit the limits.

B

Once you started, building real services on there right, like you, know, 2012 1314, you start like scaling up services rather than just little like websites and you're like this doesn't work anymore. So from there I went to go um and yeah I played with rust. I played haskell. I definitely played them before uh and russell's the one that tracked me most. It had like the type system of haskell which I loved, uh but not this like uh reading from disc, is some weird I o monad. That is like non-normal operation. You can't consider it like.

B

That's really normal, like you can't you can't say, like you know, interacting outside the world is not acceptable. Like this is such a special case like no? No, so I think hats is wonderful, doing math but, like it definitely seemed yeah special okay. Reading from this should not be a special case, so I.

A

Love rust, uh yeah. It gave.

B

Me, like all that power, I love the type.

A

Actually, my background was also mostly like c and c, plus, plus and other low-level languages, and so for me, uh getting used to rust was like a breeze like it's just about the c plus plus in my like in my head. It's uh so in in a sense. It's it's, I think indeed depends on uh uh on a history on trajectory of of the person as a programmer and and so, but I guess, as for many people, the trajectory is actually start.

A

So at least the very seriously interacts with web programming, where it's typically like a gs or php for server side. For them, probably uh high level languages would be more natural. So that's, let's agree. Okay, then so.

A

So if, if you talk like like about uh promise of course, so why do you believe in the fact that relatively uh limited set of primitives, I think you meant you mentioned like uh send message received message and local storage and that's about it?

A

What why do you believe it's sufficient for writing non-trivial contracts, so.

B

Well, I see well, basically, I think message passing. I think his message passing is sufficient to build everything um and in fact we can kind of reduce our entire distribution systems. I think it's necessary if you actually, if you're, actually renting them properly, they have reduced synchronous messages passing or like basically, rpc calls and have all kinds of errors, because I actually believe that messages come back in balance and promises actually resolve sometimes um yeah. They believe anyway, but if you go to this, is you know back to super system?

B

Design uh async message passing is the fundamental of basically all ship systems. um The actor model has also been used uh heavily in building uh large scale systems, they're supposed to be loosely coupled, um and it looks inspired not just in like what the ethereum do, because there's a great example, but you can't copy them. I think they they paved a beautiful path ethereum, but they also did it with a bunch of assumptions. They made everything simpler. They made their way. They made their way as they scale up to larger, more complex applications.

B

What can we do so being able to pass messages between uh contracts? um Intonation is way and then the active models is basically uh you have your own state. You know where other state you can do everything it came to be a limit and so limit we hit briefly was going to query something. So if I want to know my balance, do I have to send a message uh to uh query the balance. Stop my transaction at some later time. I store the fact. I'm waiting this message.

B

Another message comes back, and so it's just being too hard so um triggering so. We actually said. Okay, I made an exception and we're gonna allow queries synchronously, um but I think it's fine, because which is kind of a break is actually quite everything on one chain before that was basically much more fluid, um but I think it's basically what you have. You have a bunch of of processes, sending messages back and forth, and you know they've built huge telecoms on that the actor model. That's all it is.

A

Okay, uh but if you think about the blockchains, there are typically at least two very important operations, which I don't think naturally much to message. Pacing and one is essentially identity, mess management where so that you need to understand under which account or like address or whatever you execute your contract and another one is the guest handling so like uh attach attachment to execution certain computational resource uh cost and those operations are not like.

A

The very unusual not like. First is normal for computer science, but I think second, one is somewhat unusual for for the for the computer science for computation to actually attach to it it's computational complexity, but generally, both of them, I think crucial for execution of of smart contracts. So how do you? How do you handle such a problems in osmo.

B

Well, you're right, there's a lot of things, so the first part I didn't mention all is actually one thing we exposed, we don't suppose callbacks we expose a environment object which has uh the message cider sender, uh the contract address it's um the block height the block time.

B

I don't know one more thing. You think the message that you have if any funds have sent the message, if your name token or sent the message as well so a little bit like what is your environment? What's your context, you're called in it's a read-only variable, so the structure can read it. um It's not even callbacks just pass it as like data uses data parts it- and this is our context, so we give of course a context, you're running and that's very common concept everywhere. I think you know languages um so give us context.

B

Tell you which who's authorized. What user is running this um the other gas handling? I should be a patriot contract. They should not worry about gas handling, they run out of gas, they don't have gas and it's up to the collar to worry about that and the run time to worry about that. So I don't think contracts should have to worry about gas and they definitely should not.

B

Have the safety depend on the fact of whether then they can predict a gas limit for dispatching a sub-call and predictably had the gas limit of the sub-call to be high enough to run correctly, but not enough to avoid re-entrancing and so a large portion of ethereum contract uh security is based on the fact that you're basically well aware of the current gas and able to mute limits of sub-calls when you dispatch, when you send a message to another contract or call under the contract, you limit its gas.

B

So it can't hurt you, which I think is a detail. You should not have to worry about the contract developer, so the runtime should make sure that the contact can't hurt. You basically.

A

So you believe it. It shall be handled like partially by just read-only variables in in the context and maybe partially by by native, for the blockchain parts of the contract is about right or not exactly.

B

Yeah I mean, I think I don't know what context is to go inside there, so you could ask more context but like if people decide they need to know uh the app hash. The last three blocks in their environment, like probably some custom callback for that one right, but um and they can query back in the blockchain. That's a query thing service query. Besides asking messages, saying messages, you have a query which can create anything for your current state. It's a read-only thing.

B

So um we passed these kind of standard messages which is yeah the block, heim type who send it. You know who what is my contract? Who am I right? Who am I um and they query the inquiry into whatever anything else, and she could have a handler saying. Show me the last three block headers that could be a custom query. You add the only option of blockchain. I don't know what else is really needed there. So, when I get to compositions, if you think of this composition, I got into this and started building logic contracts.

B

So we start getting things. I have a multi-state contract that wants to call into uh to a government's voting contract that will then dispatch votes into uh decided, stake funds no, for example, right. So let's say that it was taking to this contract, and so that is owned by someone else.

B

um So all these things just started building together recently, the last month, or so uh you know two three contracts tied together, how they do it and that you know what adding up the query thing calling back is really important to add that, so you could actually, you know, find out the state. You know uh show me all the validators before I bound to validate it, she'll be all the validators and then I can pick one of those and then do a bond validator.

B

As my my you know, the one of the highest uh best rewards, the one I bind to right, and so your logic can be there find the best one and immediately just dispatch the message to do that, um and that's enough really like I'm still working on a good framework to do it right now.

B

I do integration test at the high level at the very high level, uh which is kind of you know, running the blockchain all together, so I'm trying to figure out how to unit test integrations like that. uh That's currently. Well, I have ideas that still work in progress, so it needs to happen, but I haven't found issues like the most. I've tried to figure out the current one I'm working on is callbacks.

B

So um the way I do it is different. I should like to hear near's explanation a bit more here. um I we explicitly avoid re-entrances. You pick the active model to avoid re-entrancing because, well you know, sixty percent of all three attacks are re-entrancy, and so let's just get rid of interesting, so uh you know force people to think a little more percent, which means reentrancy, basically, is um my contract, a calls contract b, but I stay in memory not on disk right and then counter b. Calls back in contact.

B

A reading is f disk, which is different than state memory. Right, so let's say I have 100 tokens. Okay, I lower the memory by 100, raise your balance 100 in memory and then call some other contract sending it to it right. This one calls back again says, send my hundred tokens again and lower yours, and it keeps doing that, and everyone sees that and eventually just write, my zero for my balance and have now encrypted 10 different balances, each by 100 tokens and then just have a zero in my balance.

B

So that's very interesting short, so it's really tricky and so basically the way to avoid it is save all state before you call out. So when they call into you, they only see everything you save you'll have a different memory and uh and state uh when someone else passed into you. um So we did the active model which forces that, basically so before, when you were multiplying state, you have to persist all your changes and return a message and the message will be dispatched another module and it can just change state.

B

So only they can't change state and call into you, while you're changing state. Only one thing can change at a time and you can't have a call of depth. um So using that model it works pretty well, most things can blindly be it and our handling is if the message failed revert. The transaction if exceeded, keep the transaction and that works pretty well the failure mode. Is you usually don't need to know what happened when you dispatch it? You know it worked right. um The failure mode is right here.

B

If contact a in the constructor connect a wants to create a contract b. Let's say I want to create a token contract. The token contract wants to have I'm the mutual the code of contact right. So I said the minstrel. I create contract b that has a minter right, a b, but this token a needs to know who the picture is. I can draw the whiteboard better, probably, um and that's that's the kind of callback thing yeah.

A

I just want to say that, maybe to explain it better, you can use whiteboard. That's the whole point purpose of uh like having whiteboard.

B

And cool, so uh let's do this now, let's go to here, so this is actually, I think, a very interesting uh one and I'd love to hear here. So we have um I'll pick a few colors here, uh hopefully not too ugly, um and so usually we basically just say uh you know. This is.

B

This is some sort of defy contract yeah, no swap contractor market contract.

B

B

This is some token contract, yeah.

B

So usually what happens is if the default contract is move money, it will just say this is fine, it will go. This is what you handle properly.

B

I guess it will say something like uh send. 10 tokens to.

B

Right and when it does that one um all you need to worry about is either the tokens got sent, they did get sent right, so I will change my balance to the d5 contract. Based on whether or not this worked, if it doesn't work, then I revert my changes. You know the I don't close order book if they the order couldn't be claimed.

B

Then I revert my changes here, so I change my orders here sentence tokens and then it works or doesn't work, and I revert the whole transaction about that's fine and the whole idea of message passing it works. I make my changes optimistically and we're dispatching the messages and, if anything, fails over the whole transaction, uh which is actually the proper error handling in like 98 of cases, um and we don't need to add more too much more to it.

B

So what I so you know, that's, that's fine, um and now what we look in other cases. This is actually.

B

B

Create token contract yeah.

B

With minter- and let's say this address here is so we create a contract right yeah, so create this token contract that mentor and uh that's great, but the problem is the d5 contract. Never knows how to get the mentor address. Sydney's are the token address. There's no address that creates it right. Students have the address, so um this then at some point you say: okay, now we format is we call, you know, no, we've got a new address here and then somehow.

B

Okay, I just got created.

B

Okay, so this is a a standard call, and this is one case where you really do want to have this back and forth. Rpc style call right, it'll be nice, um so what we've done is basically callbacks. It's a little complex and this case is actually we say, not very common. It's not uncommon, it's not rare, but it's not very common, um so we're trying to make it more optimal.

B

But currently, basically what you have to do is you send a message here to the token contract saying make it make a counter contract and a callback saying when you're done instantiating, when you finish this contract call back to me and tell me your address, so that's basically how we're working on it and trying to make better support in the runtime for this this flow, um and so what that is is basically for us. The way it looks like if you want to see it is init contract defy contract, returns, init, contract message, then token.

B

B

So that's a flow in three steps. You see that bro yeah.

A

B

Yeah, um so we have this three step. It could be a promise another way another set up. So that's one place. We put elements here, um but basically it's just a little more like work. Yeah.

A

I just want to say that it's a typical continuation passing style so so, instead of like along along with the with the call you pass the control flow. So this this is not a callback in a classical sense. It's more like a continuation. You just ask okay, so this is this is what you're going to do next? The the course doesn't have to be put in a stack. Indeed. They they can be arbitrary, routed so and yeah.

B

A

uh That's pretty much what you do.

B

Yeah, so you say tell this address what your name is: okay, good! So I'll tell you I'll just what name is I'm done so yeah, I'm going to uh move a second, it's time to rain here.

B

Okay, keep talking I'll turn the video for a second.

A

A

At least the computation which was going on here is a very typical uh asynchronous computation, so exactly see, and what what you do here is requires certain computation models. So so these calls are not actually caused. They're more like in.

A

Pretty well, but maybe not so common to many programmers today.

A

I think I know that at least 13th is some form of like uh accordions in kotlin, for example, is an example of of simple cps international passing style uh callback uh represented in more in more natural way, and I guess, but I guess, for these distributed aspirin systems uh like the blockchain, especially.

A

With the cosmos, um what we have is very it's, it's not normal to be synchronous, so asynchronous is absolutely uh expected behavior, but uh yeah. It could also mean uh the like uh in in in a typical in a typical c or python or java program. Calling is a very cheap operation, and I guess that's no longer the case for um for the contracts calling each other so calling uh calling someone else can be expensive. It can fail it can.

A

It can break for like multiple reasons, so so so, whenever you program, you can always be prepared that this call didn't succeed, and this probably has to be expressed in uh in a developed development tools.

B

So yeah we want the language to capture that. So the point is right: now we kind of we still synchronously. We do this mainly for guarding reintroducing um in the local model, but with ibc. You actually have this yeah unbounded message passing so uh basically every contract, an ibc basically say I will commit an intent to call this contract on my blockchain.

B

That does it really to know that blockchain process of the blockchain result has to happen at blockchain. The result. The message that when it comes back to us, is really back to us that could take 10 seconds. It could take three days. I don't know um you are guaranteed to eventually get either an error or a um you're, basically not cared you're, going to get an error or result back from it as long as other blushing progresses. So you have a timeout for two days.

B

For example, and you have to see the other blockchain has passed high x little blasting at his side, actually out ever processing a result. Then we know your result will never get processed. So we could, just you know, call it a failure, um so it has this and that message passing. Is this message passing to return a message to be processed? um And then you don't just say well: if it fails, my transaction rolls back. I actually hold an immediate state. Is one level more complexity, so I have a I have.

B

Maybe uh this message in process: I have 10 different, different messages in process um and waiting for the results, and maybe they get rolled back so like. If I want to send money from you to some other thing, I say: well, your account balance is reduced in some temporary state reduced. But I have this temporary callback. You know state here and if the other one succeeds, then great that I actually remove it and if I don't then return it back to your account because it failed.

B

So that's another level of complexity which we will be adding uh in the next months uh when you have ibc support, is getting uh ready for production, um we're still waiting for the underlying ibc support in underlying sdk we're working on that one. So we're.

A

B

That, but that's a very that will have to take the same message, so we want to build all the tooling around this concept of sending messages around uh and not just you know, calling into it, because that we need the conceptual understanding there to be able to build multi-chaining um contracts.

B

um I'm also very curious how you use promises, you kind of have multiple shards, and you have promises over that. So I'm curious how you abstract that, yes,.

A

I think promises is rather weak form of of cps cps programming so so, which paradigms? Do you actually use in your sdk? Is it actually futures promises or something maybe something closer to core routines, or maybe something closer to?

A

I don't know like traditional callbacks, so yeah.

B

This is pretty wrong return messages. So the interface here, if you do something like this handle takes environment, you know called dependencies environment, the message yeah and it returns uh basically a vec of we call it cosmos message more or less. That is what we have um if you're following here. This means we take the basically depth is our storage, access or api access barrier environment? Is this dimension the block height who's, calling it messages over data? We call it into it. You know this is our thing and return a set.

B

We didn't know there's an error as a result. Actually not. This is something result. It's actually a little more complex than this, but it can error or concede. If it sees it returns a list of messages and um and that's all you do so, this actor model right turn it and then then the runtime takes messages and dispatches them in the same transaction um and those are also just other ones.

B

It keeps running to runs of gas somewhere along the lines or it's finished all the messages on the stack and then it's finished, and if everyone's succeeded and they've all processed it, then it goes and says commit this transaction successfully. If anywhere along the line, it runs out of gas or one of them says hey. I don't have this message, the whole transaction fails, so you can build large systems but yeah. Anything, of course anything fail. The bigger bigger it is the easiest one thing to fail and then simply ethereum.

B

If you call it the contract, it runs up gas somewhere.

A

So so I have two related questions for such a uh for such a primitives uh yeah. uh How do you expect people to reason about them, and how do you expect people to test them for uh like for complex scenarios like, for example, when only one of the messages fails and and so on?

A

So so uh I think the the hardest part about about such a such a vectors uh would be probably a correct handling of all the uh all the possible outcomes, both in reasoning, art and in testing part you can for some about some systems. It's very hard to reason, and, and sometimes even when you reason write you, you cannot test it properly.

B

That's still a problem if one thing fails doesn't matter because we say if any failed over the whole transaction, so we make basically a snapshot of the database and you're working on a cache, a temporary weber, temporary database- and you know temporary transaction and the whole transaction gets rolled back if any of those messages fail anywhere.

B

So you can write that message saying I can make these changes optimistically, assuming those messages are going to all succeed, because if those messages fail, then what I did got rolled back so it happened like I never handled this right. So so that's our assumption. Our critical assumption is, if anything fails. The whole thing rolls back.

A

Yeah right, but how about composability?

A

So imagine you wrote a contract which which has certain like set of outcomes, but it is being called as a uh from some other home, yes and so as a result, even if it like the inner transaction is not failing, the whole transaction uh fails so so to make to make uh uh a synchronous system like that composable, so that you can actually uh reason about how do how do I call from function, a function b and and so function b, always work.

A

Your whole system must be composable, so it's not always that this is like a top level call which is performed on on a button click by user. It sometimes may happen as a result of some other software call.

B

So you're right, that's what you tested so right now. The test we have is basically, we launch the blockchain and run those contracts together um and then work out. Now is integration test actually, even in russ unit tests, not even wasm just run those and say like I have these five different contracts. I want to string them together in this way right.

B

I assign these contacts to the addresses and whether this is a malicious, efc-20 token contract on the address or or it's a good contract or whatever else I can assign these addresses and then run the test on it. So that's what we're working on right now, one thing working to allow this integration test levels to happen easier for testability of it. So it's not hard. All you basically say is you set up a system with this code and this state assigned to each address so basically, an address.

B

A contract is a set of bytecode and a set of state, the current state, so you can initialize them all and set the current state of these ones and then run that um and just have a little a small mock run time uh in russ, so it can run in the same test as their code, which would then basically take the message we dispatch them, handle the errors, roll back the whole thing on failure.

B

um So I'm working on that one and it's definitely testable um it's a little harder to look at some types to make usually all like nicely abstracted, but the concepts are the testable. um What I feel it is basically writing it that people remember how to write it. This is like a lit. It's not natural! I guess, if you used to call in contracts right, if you're used to calling it it's not natural. Like that's my caller's thing, why I have to return a message that does that thing? um It's more of a mental!

B

I think this is more of a buried entry than a reasoning thing um in the end. Basically, I assume that um all those calls at the end of it basically are just saying you know do this: if air fail effectively, what you have is uh you just call this message and a question mark operation at the end of it is what you're doing in your end of your end of your code.

B

um So it's something's harder to reason about about those these contracts um than calling them, uh because yeah, the same call stack. If you think of the same call stack testing is definitely harder. We need to run time for it and that's one thing we're working on um now. There's some people built uh actually a funny tool called simulate, which is uh uh which will take these contracts and addresses, and then you can interactively send messages them and try it out manually.

B

um I want to make more unit testable, very low level unit, testable plus stack traces, um but yeah. So we have some tools on that right now. Most of my tests are basically running in the blockchain and running: go tests against their goal. Blockchain with these contractions installed.

A

And actually a related question is about debuggability of uh it's. I think it's a pain point not only like for for any particular blockchain, but I think uh for most or almost all blockchains uh suffer from uh from hardness of of debugging anything in trivial. So do you take any special measures here in an area of debatability?

A

B

Try to make everything testable in unit tests, so I use rust unit test.

B

So, like the contacts just found out, they can you know, compile them as rust and just run them and get full stack case and everything is beautiful um and then you run it in integra, you compile it to walls, and then you run that in a little runtime and suddenly you get like just vm failed when it panics so a divided by zero error, which would be actually give you a panic and in rust will just give you vm fails, because if you divide by zero vmware just like kill the vm with the trap, and then you don't get a message, you don't know why, right so the panics and stuff like that inside the the wasm become opaque, which is really annoying.

B

Actually, um so I tried a bunch of those and when you see anything like that, all you have to do is for me. I look for any unwrap statement or anything you can possibly panic and just look for those and half of those. um So I like having the rust testability um what the other thing we do for testability is we took json, which is a much maligned, and actually I personally also malign it, uh but universal human readable format. So all the messages are in that format and their turn value is too.

B

So if you look at the msg here um and handle is basically, this is just a serialized json as an object actually parse it here, but it's passive. The wire is json, and this constant message is another object that seals json, um so you can easily add in, and maybe I should do that as a log level um into the runtime. So every time you call a contract, it says what the call is and every dispatcher can be there. She could log say I called default contact. This set of arguments it dispatched, create token contract.

B

With this of arguments uh get token contract was called this argument and it created called uh uh uh informed, created on the d5 contract with this sub arguments, and you can print that out. uh It's not in binary, so it's pretty easy to print and log files.

B

So that's one thing: we've definitely had um for debuggability and I turned that off a while ago it was definitely early on. I was printing a lot of these json documents just straight up and reading them, as I was writing stuff. um But since it's been stable for a while and tested everything, I turned all that off, uh but it actually is, for this big composition, very interesting to turn a log log level back on.

B

So people can run the blockchain uh with a high level log level and see all those um all the messages going back and forth between them and recreate what happened.

A

Mm-Hmm: okay, that's uh that.

B

That's that's pretty nice that you.

A

Have at least this this kind of uh like uh development instruments um on our previous uh wordpress session, or we were discussing I'm sorry.

A

uh We were discussing their uh uh runtime uh verification as a mechanism of of solving at least partially uh the dependability problems. So uh do you believe in any form of formulification in your in your system, or maybe you already do- have some additional checkers which uh simplify the development of smart contracts.

B

I mean formulation is beautiful, I love it and I think right now it um I saw someone talk to people doing that and it's really cool stuff. Actually it wasn't directly uh but having a json parser in there or a borscht box or any parser basically blows up the whole whole thing right so for passing, uh eight byte uh human 64 um over a call- and we can knock that out, but if you're passing large sales, obviously parsing them. The verification includes a serializable parser, so I think it would make sense to take.

B

If you have actually um non some math, you could take the math, the actual logic inside of it and formally verify some subset of that logic. um Again in rust. Not wasn't because compiled wasn't would include all the sterilization stuff. On top of it and the hooks.

A

And the memory management all that stuff.

B

um So it seemed pretty hard to formally verify the actual wasm.

B

The rust itself is interesting um and I would definitely uh love to see if you could pull out like just the functional parts, you're doing and formally verify all of those- um and maybe that's doable, um I'm not sure unless I've tried doing formal verification. Stuff was basically the liquid haskell interest, which is a very different uh system than rust um and that's cool. The paint types is cool. I think it definitely can do a lot of stuff, and I found some interesting bugs you can prove mathematical theorems a lot of this stuff.

B

However, I feel is smart contracts, often more business logic than math, so I can prove a d tree that maintains certain variants, but proving what are the variants of unison contract? What are the invariants of it? What must never fail, I'm not sure it will go up and down the price will go up and down the amount of money reserve will change. Is there an invariant?

B

You can mathematically, say this and very much always held true for every subcontract, um and then we can guarantee that if the state is in this state and this transition happens, you'll always remain in a state, um and those invariants will always be true. So I think you need to find this mathematically and I think for many uh smart content for developing.

B

You don't really come from the mathematical proofs. You're not coming from a mathematical object, you're coming from some business domain and you're, trying to turn business logic into a contract which is fine. That's that's! Basically, what we're doing most of the stuff is building apps and business logic into contracts, and for that formalification for me, seems overkill. It makes sense if you have a rocket, that's going to a moon and there's very clear mathematical proof of what you need to do everywhere.

B

It makes sense if you have a binary tree or you have a database, possibly which has a very strong controls of what it should do. It should commit in this order. It should never fail this thing. If transactions, you know shouldn't have too parallel or the same data without causing some some roll back somewhere, um the lock should maintain. So you can have a set of invariants that must hold true for your database, uh any possible discorruption state. You should either uh be able to repair the corruption or be able to detect it's corrupted.

B

It will not blindly right so, and you know there's things like that, like a quick test in rus, which does some cool checks like that to fuzz your stuff right, which I think is actually an interesting way of doing some large testing, which I think will cover a lot of what people want to do with formal verification right. So um I think that'll be cool. I'd love to have quick check tied into like these. Basically um systems of contracts, okay,.

A

Yeah, so I guess we have very interesting discussion. We tried to limit ourselves to usually something approximately like like one hour to not uh not make people too much bored. Sorry, so I guess uh I'd love to say thank thanks. You for coming thanks, thanks for uh very, very interesting intro, for sharing your experience with the multi-chain. So thanks a lot. Thank.

B

You for having me here to talk.

B