New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

J1 SAY 08 Martin Becze from eWASM to primea DFINITY

Ethereum ParisTue, Oct 9, 2018, 12:00 AM

Speaker

Martin Becze

Transcript

all right hi again I'm Martin BZ and I'm gonna be talking about par mia and unfortunately once again the logo still doesn't work but I did have a nice there's nice premium um yes so continuing on from where Alex left off premier really started in the with you awesome and it borrows a lot from the awesome it borrows and builds off the work that you awesome does he uses the web assembly instruction set and it uses metering the same metering that he of awesome uses and premiere started with you awesome colonel which was created originally to test you awesome and then I started experimenting with some ideas with nested contracts and other more exotic forms of communication that didn't quite fit into aetherium and didn't have a way to be backwards compatible so that's what inspired it to branch from he wasn't colonel so currently Crimea is being built developed within divinity and it sits above the web assembly instruction set and below consensus so it's the layer that facilitates inter process communication for contracts you can think of it kind of like a colonel so the problems that is trying to solve our performance current blockchain computers lack performance scalability trying to fix sort of ad hoc designs well it's the times we see a lot of recreating things that I've already existed impeding for a long time without any knowledge of those things not being able to extend if you the EVM is hard to reuse and to extend for other purposes than outside of aetherium so try fix that and provide a greater level of inter polarity so some solutions that premier offers and maybe not solution to all these problems but quite a few of them one thing we change is how contracts communicate and I'll get into this later we introduced concurrency so we can perform parallelism which helps with performance and of course as alex has told you about all the benefits of you awesome and webOS Emily we use webassembly as our base virtual machine and lastly we try to make this general-purpose so it can be used in lots of different places not just the box train even so I'll get into communication communication is what really is different than what's in you azam are in theory 'm so communication in premiere pro mia provides restricted communication and i'll talk just a bit more about that later we also have asynchronous message passing so there's no synchronous calls like in aetherium everything's done asynchronously so what do I mean by restricted communication let's say I have three contracts here ten occation contracts and business object and like a database contract the lines between the circles here represent who can communicate to who so by default not every contract communicate to every other contract is restricted so this allows you to build isolated zones of contracts and you don't have to worry about the you don't have to worry about them getting attacked or being misused you can put all your logic that checks for incoming messages and then like a thin occasion model module and then hopefully you can just reuse off-the-shelf components to build the rest of your apps also since we have we know who can communicate to who we can potentially see groups of contracts that are communicating and our mutually exclusive won't talk to each out there that allows us to do partial ordering of the messages so these two groups of contracts it doesn't really matter what order we run them in because they're not going to communicate to each other so asynchronous messaging why did we want this original motivation um back when I was working on you awesome colonel was looking at the different charting schemes all of them had one thing in common asynchronous messaging is between the different shards and I thought it would be good to have a unified set of communication semantics for this so like you're in charge Communications should be the same as your communications across charts also asynchronous messaging allows us it forces everything to be concurrent and that enables us potentially to build parallelism or run these things in parallel another difference is things are non atomic by default now I'll get into this next but you can have atomicity it's just not there by default and we encapsulate our asynchronous message passing in the actor model so the review this is how synchronous calling works in aetherium and I'm gonna explain a little bit of a little bit of overhead that it introduces so if contract a calls B and let's say it's using 100 bytes of registers then B has to run but we also have to keep the 100 bytes of registers for a paused then when B pulse C C has to run and we have to maintain B's State also a runtime state right so every time we do a call it introduces more and more overhead that we have to keep around and then when C's done running we can go back to B we can throw away C state now now so you can finish running now we can throw away C State now we can throw away B's de sorry and then go back to a but every call you do in a nested call you get sort of an additive growth of resources being locked up and this gets this problems a little bit even worse when you have to do with storage and reverts so the atomicity semantics of aetherium so like when a calls beep and we mutate a state now we have to keep a Szold state around and then when B calls C we have to keep a am B's old state around or storage around right and then finally C runs now we go back to B and we still have to keep a be in C's state all around there storage right and then B returns to a and if a crashes we have to revert B and C's state and a state for their storage so you lock up all the contracts that you touch with having reverts and that could potentially over add a lot of overhead especially if you do lots of lots of calls and the way if there any elimi this limits the snow is just to put a max cap on how many calls so you can do Owens is 124 I think but if you eliminated this added Nyssa T and I think singers calling you could potentially do a lot more calls because well there's no overhead so there isn't it no overhead and doing a call it means you can have unlimited call that's this is what I would look in the asynchronous model you know is running has 100 bytes and it calls me and it's just done throw away and then be call see it's done throw it away and then see can return result to be behaved way accepting runs and then you know there's the way and then lastly returns to a but the problem with that is it's an auto atomic and a lot of times you want atomicity you want to do like book a hotel and I train at the same time so the way you have to implement atomic databases is usually using some sort of commitment scheme like a two-phase commit so instead of doing that for you we we would provide a library allows you to build this type of stuff on top of asynchronous messaging and I think we make it fairly easy to but it would look something like this like a is running calls B and then B is going to return a lock to a and then a B will wait so lock up at state so you have to manually say hey we want to keep this data round and this way like you as a programmer can account for the extra costs if you need atomicity if you don't need atomicity it won't have extra costs so then B can't when it's done running and everything is okay says okay I'll commit an A or B finally runs and saves the results of course vice versa if a fails it can call revert and B will just throw away its old state so how do we encapsulate the the messaging we use the actor model and it's very straightforward each contract or program is an actor um actors have an inbox I have a mailbox which other actors can cue messages on so you see the different actors carrying messages on their actors inboxes our mailboxes they have some sort of persistent storage and they have a address so it just works like postal service if you will and what actors can do is they can create more actors they can send messages to other actors if they have the actors address and they can designate what to do with the next message in their inbox and that's really what the actor model quarterback remodel is we do have some differences from chemical actor model and that is we're deterministic by definition after model is non-deterministic but we have to have determinism since we're want to run in a blockchain you you could loosen that restriction if you're running off chain though so one interesting fact about actor model is you can't have entry bugs so it says we're a calls B and then B is going to call back to a and now there's a new instance of a running so instead with actor model what happens is a calls B and then B calls a and a first instance will finish running then it'll get the next message and continue so important part of this is making this deterministic so it's we order the messages by how much gas was spent and when they were sent so a mailbox may have a set of messages in them ABC and it's going to get reordered to a CBA so a was sent earliest in time because only 25 gas is spent then bu because 30 and then lastly was 40 so we use gases approximation of time here so if gas stands for how many operations can be done in a certain set of time then you can you can order messages using that metric so what happens when an actor is ready to run the next message it has a message it has message a it has 25 gas spent it needs to know if there's any outstanding messages in this system that are possibly older than 25 and the way we do this is maintain a scheduler that keeps track of where all the actors are in time the scheduler hiris knows that a actor a has ran for 300 ticks or 300 Ponte gas same with B B and knows it's a 200 C at 310 and D F 400 so when actors ready to DQ a message it asked the scheduler hey are there any could there possibly be any outstanding messages older than 25 the scheduler knows that all actors have ran past 25 gas and therefore could not have sent a message earlier than 25 so it's fine and goes ahead and runs it now if you know the actor had a message is 6 hundred then there could still be messages older than 600 so NASA's schedule a hey are there messages alert it could there be messages older than 600 well there's several actors that have not ran to the point of 600 yet therefore it could be possible that this actor would get a message older than 600 so a pauses and goes to sleep in it will wake up once all the other actors have either all gone to sleep themselves or have reached 600 gasps so the last thing I have to say about it actor model is that it has a distributed memory model a means there's no shared memory in between anything okay so now I'm gonna talk about the webassembly interface okay so this is how we interact with Crimea we have so it's a object-oriented interface that means we have objects that the system maintains and then the wasum binary references and our objects are functions which allows us to make calls to other actors data buffer that allows us to send chunks of data to other actors an element buffer which allows us to construct a central essentially a table of other references so we could pop create a a element buffer and I could have functions and data buff buffers and whatnot in it a module reference this is our abstraction for creating new modules or lots of modules this is this is what you need to use to create a new actor and an ID and lastly also so IDs allow allow you to at nf5 allows an actor to identify itself and lastly links links stand for more whole links and are used in persistent storage so the system maintains a list of references and an array it might look something like this might have two function references a data reference and the link reference and then the webassembly binary would refer to like function two with the integer one since we're counting from zero so it's really basic but that's how it works so function references you might have some C code like this and what a function reference does is allow one binary or awesome actor to pass a reference to one of its functions or of another actor even to other actors so for example a might have a function reference to be that points to main and the system maintains this function reference and underneath the function reference contains two bits of information the ID of the actor which in Atheneum is like its address and the export name or table index of the function and that way the system knows when a invokes main on B this is going to generate a message and the system will know how to start B up and what function call so this gives us something and this also allows us to have mobility so if a has a function reference to one of the references in C and also has a function reference be what it can do is call B's function reference with with the parameter with the argument of C's function reference so that allows a to tell be about C now B has sees function reference and this is how all the communication is built up in Crimea there's no global communication everything is done by passing around these references that said there probably need to be like large registries of other contracts that might want to talk to each other and you'll be able to look em them up so functions in wasum the the function api looks like this we have externalize so that's where we take one function that is in the any any func table and turn it in it turns into a function reference it takes one slot and any func table which is index and this function will generate wrapper type checking information and put it on to its array of funk funk shion's and returns the index of the array which we use this function f then you can send that elsewhere if you get a function reference you have to internalize it so given a slot in the any funk table and a function reference this will do the opposite of externalizing it will put it will generate a wrapper for the phone function which when called will create a message in Crimea to send to the other actor so this allows you to put a function reference on a table the news call indirect so we don't have to introduce a new type of call into premiere we just reuse webassembly semantics for for calling lastly - just how much gas we want to spend when we do the call you have to set that explicitly so set gas budget is how much gas you're going to spend when you call this function reference and takes in a function reference an integer or just how much gas and it returns a new function reference and then there's also get gas budget so given a function reference it returns how much gas is going to be spent when you call that function so this is sort of interesting because it allows it would allow a by nerim to internalize one of its are externalized ones functions set how much gas it's supposed to use and send it to another actor in so the other actor can read it and override the gas budget but it allows other contracts to define how much gas to spend when calling them lastly is also a very important thing about functions as we annotate them so in webassembly the only types we have are i-32 i-64 at 32 float32 of 64's we extend the typing information with our custom objects so and we might have something and see like this function and it expects a function reference and add a debuff and when this is externalized this typing information is also captured so when this when a func ref the Foo is called it underneath those are going to be I thirty twos but it's going to use as I thirty twos as indexes into the reference table and replace them with the actual objects and we store the custom type information in a custom section in the Oise in binary and it looks just like the regular type section in wasum except we have a few more integers for our system options okay I think a time but I don't know I'm just finish up this one part so function annotations yeah custom type and we have to do runtime checking one any fungus called replace the i30 to use with actual objects and if it wasn't an object in the reference table the runtime didn't it you know we'll throw this is also interesting because this means references func references are capabilities if you know are from know of capability systems it's a capability to send a message and it's also an opaque reference it's unfortunately you can't create function reference out of thin air and honestly like the other properties the capabilities it is transferable so data bus work just like any funks or sorry like func references except this for like chunks of data so you think of it as like a memory section that you can send around because webassembly functions only take in I thirty twos or I 64 is some fluids etc if you want to give it if you want to give one function and chunk a data like you don't want to have it have like you know 100 I 32 s so instead you create a data buffer which takes some chunk of memory puts it in a data object which you can then send around has the internal eyes and externalizing internalized methods the same as functions except instead of reading and writing from the in e funk table we read and write to memory lastly has a links command tell you how long it is elements are also similar to data buffers except they contain a list of other references I can make a element buffer of data of like a bunch functions act put you know data buffers in it or whatever it's really just like array of references and this is sort of analysis to what tables do in awesome if tables could hold any references currently tables in watham only can hold functions right funk so yeah as externalized internalize and length lastly there is a module which allows us to create new actors I'm given a data buff which turns a module rough um the data buff here is the law wasn't binary module dot itself so if a actor calls module dot self it gets a reference to itself and then modeled export given a module reference and a name will return a function reference lastly we have links links are used for persistent storage and to represent Merkle links so link wrap given any any one of the above references and you the system objects returns a link and then unwrap takes in a link in a continuation which is a callback and that callback is given the result of looking up this merkel hash if you're a light client it might have to go out to the network might be take a long time that's why it's a callback and then we'll return the resulting object okay so I think I'm at a time way out of time so I'm gonna stop now but you know the same stuff is inter polarity and the accidents ability which Alex also covered so alright thank you [Applause]

Automatic transcript — names and jargon may be misspelled.