Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Martin Becze: Primea – The Next-Generation Blockchain Operating System

Episode Date: July 24, 2018

Martin Becze is a researcher at Dfinity working on a next-generation “Blockchain Operating System” called Primea – a continuation of his work on the eWASM project from his time at the Ethereum Foundation. Primea is an actor based IPC layer intended for use with WebAssembly programs. Martin first learned about Ethereum in 2014 and was immediately drawn into the possibilities opened by having a contracting virtual machines on a blockchain. While the EVM was impressive, Martin saw the possibility for greater usability and efficiency by using the new WebAssembly standards being created, and so led a team at the Ethereum Foundation in the creation of a new blockchain virtual machine, called eWASM. We learn about Martin’s experience on the eWASM project and how the limitations of backwards compatibility led him to begin writing a brand new execution environment from scratch, rethinking some of the core designs and mechanics of the EVM – this project became known as Primea. Martin explains many of the fundamental design shifts involved with the Primea platform, including his focus on using the actor-based model and object capabilities (and what these even mean!). He also lays out how the Primea platform fits into the larger design of the Dfinity blockchain. Topics covered in this episode: eWASM – Ethereum flavored WebAssembly (eWASM) Design. Primea – an actor based IPC layer intended for use with WebAssembly programs. Webassembly Dfinity – blockchain-based cloud computing project. Its aim is to develop a decentralized internet computer that will become the cloud 3.0. Episode links: Primea GitHub Communication Semantics - Edcon talk Primea Technical Deep Dive - EthCC talk This episode is hosted by Meher Roy and Sunny Aggarwal. Show notes and listening options: epicenter.tv/245

This episode of Epicenter is brought you by Shapeshift.io, the easiest, fastest, and most secure way to swap your digital assets. Don't run a risk of leaving your funds on a centralized exchange. Visit Shapeshift.io to get started. Hi, welcome to Epicenter, a cryptocurrency show. We are known for interviewing entrepreneurs, academics, and researchers in the blockchain space. I'm Meher Roy, and with me is... Sunny Agarwal. And today we have with us Martin Bessi, who is a researcher at DFINITY and is working on a project called Pramia, which he describes as a next generation blockchain operating system. We'll ask you, we'll get into what that means. But first, Martin, could you introduce yourself and tell us a little bit about your background and how you got involved with this space?

As introduced, I'm Martin Bisi. I work researcher at DFINITY. And I've been in a little bit of my background. involved in this space since 2013, 14 probably. Before that I was also, I've been interested in Bitcoin ever since I saw the white paper, but didn't really start programming and getting heavily involved in it until around Ethereum came out. That was sort of my initial step into this space. into this space with Ethereum and generalizable smart contracts. Cool.

And so, you know, for a while when I first met you, I think you were actually still working at the Ethereum Foundation. How did you initially get involved, like take the step of like, you know, learning about Ethereum to actually like joining the foundation and getting involved from that side of things? So before the Ethereum Foundation, I was just working on some of my own projects and I was trying to make a federated I was trying to build federated systems so if you're familiar with Macedon which is popular now they're federated they have servers and you have an account in the server but all the

servers can talk to each other so riot is another example or sorry the Matrix chat protocol. So you could have a count on one server and still talk to someone on a different server. So I was working on a federated protocol and was thinking about how I could decentralize it a little bit further. And this sort of led me to start doing research in blockchains. And the constraints I had could not fit into Bitcoin at the time. And when I saw Ethereum, it's like, well, this is really interesting. It's wide open. I can put anything I want on it.

So I thought it'd be a good use case for Ethereum. And, yeah, so I just started implementing it. I think it was early spring of 2014. I sat down and just started implementing some basic data structures. So I started with implementing RLP and if you don't know what RLP is, it's the serialization format. And then I moved on to implementing the Merkel tree. And then finally built my way up to implementing the virtual machine and networking. And I did this all in JavaScript.

So yeah, that's how I kind of got involved with Ethereum. And so is this what turned into the Ethereum GS library, which like, you know, I'm sure everyone who's like done some sort of development on Ethereum at some point has like played with at some point. So was that like that turned into Ethereum.js? Yeah, precisely. So that's how Ethereumjs got started. Originally I was trying to keep up with Gath and parity.

Well, it wasn't parity at the time. It was Ethereum C++ or A-Loth-0. So originally it was just a client. It wasn't the libraries that everyone thinks about on Ethereumjs. And at the time, I had a whole client that could even sync the blockchain, which is pretty cool. Now there's more transactions, and it's a little bit hard to sync the whole blockchain. But, yeah, so it started off as a client, and then we sort of broke it off into a bunch of little, little modules that became Ethereum.js.

Cool. And then, so I guess the thing that you're most famous for at World while at Ethereum Foundation for working on is the project called Ewasom. So, you know, stand for Ethereum-flavored WebAssembly. So could you tell us a little bit about what the goal of this project was and why you chose to tackle the VM problem as opposed to any of the multitudes of exciting projects going on

and like the Thurian Foundation? The VM problem can be exciting to you, right? No. It was, I felt like there was a lot of talk about these really hard problems, like scalability and, you know, cool zero-knowledge proofs and cool crypto. But we were sort of lacking on just basic engineering stuff. And nailing down, like, yeah, some simple stuff that should be at the base of the chain, I felt like. So that's what I wanted to tackle the VM for.

It felt like no one, it didn't seem... It felt like no one really seemed interested in it. And there was a lot of room for improvement there. So the number one rule of open source development is if you see a need, that's what you should work on. So, yeah, I saw a need there. So that's what I thought I should work on. So you saw some deficiencies with the Ethereum virtual machine. and then you saw that there was this other other work being done outside Ethereum,

which was the WebAssembly work. And we wondered if WebAssembly could be put into Ethereum as Ewasom, right? So could you explain to us what deficiencies you saw with EVM and why did you specifically choose WebAssembly to repair them? Right, this is a really good question. So there's a lot of, I think the thing that I realized, that caused me to rethink the theorem. Well, at first I came into it thinking, yeah,

Ethereum virtual machines is pretty cool. I had no knowledge of virtual machines, or not much. I've never implemented one before, hadn't really got into one too deep. So, as I was implementing it, I just kept seeing things like, oh, if this was different, it would be a lot easier to implement. Things would be faster. And then, you know, you started, I started to research virtual machines a little bit. And there's a lot of research on virtual machines.

So I started wondering, okay, why aren't we using, you know, a virtual machine? that is already in production, that you know has really great implementations and things like this. This was 2014-15, so this was really before WebAssembly was available. And what was out there at the time was Java, Java Virtual Machine, which is, you know, it's a pretty good virtual machine, but it's very complex. has a lot of opcodes and it is not necessary it's not deterministic in the specification of it so any virtual machine operating in the blockchain space or more general implementing or any virtual machine that is involved in symmetric computation It's metric computations where you have multiple parties doing the same computation and

needing to arrive to the same result. So whenever you have that situation, and that's what you have in the blockchain, you need to have a virtual machine that is always produces the same result with the same inputs. It has to be very strictly deterministic. There wasn't a whole lot of options if that is your first, if that is one of your main concerns. I was looking, I was looking, kept looking for something that could feel the need. And there wasn't really anything out there. When was it? I think it was 2015 when Brandon Ike made the post about WebAssembly announcing it.

And I got involved pretty early on just following discussions and commenting on gethub. And thinking about this as a possible replacement for the Ethereum virtual machine. Being involved early on in the discussions was really interesting for me. I learned a lot from people that had been designing virtual machines from a long time. And one thing I really, that WebAssembly brought to the table that previous virtual machines hadn't, was that it was deterministic. It was very well specified. And it was open and simple standard.

And it had the same goals that virtual machines in the blockchain need. And its goals were to be deterministic, to be size efficient, meaning the size of the program should be compact, small, and have a minimal trusted competing base. So these are all things we need in the blockchain space, so I thought it would be a pretty good fit. What exactly would be like, you know, the main, like,

what is the benefit of using the WebAssembly over the EBM, though? So, like, you know, you could say that, it's just like two different bytecode formats. Like, why does just switching the type of op codes you're using and stuff give you performance benefits? I've heard you talk about like, you know, with WebAssembly, we no longer need like, for example, pre-compiles and stuff. What is it about using a new upload system that allows you or a new VM allows you to like

drastically change the efficiency and stuff of the system? Great, great question. So there's several reasons. First of all, like, WebAssembly is designed to be a virtual instruction set, which means it's a little bit higher level than individual instruction sets. So your CPU has what's called the instruction set, which is just a list of base instructions it can understand and runs. So we have these little level instruction sets, and a WebAssembly is a list. the virtual instruction set that can easily map to all the low-level instruction sets.

And you compare that to what Ethereum did is it didn't, we didn't start from the premise of, okay, here are all the instruction sets and how do we make an instruction set that can efficiently map to all of them. We just started with the premise of, you know, whatever was the simplest thing as possible just to get us running, which was logical at the time. I know Ethereum was a lot of work so there's no way we could spend one or two years just designing a virtual machine. So that was the first from a design standpoint that was that that that is what is a WebAsimily spent a lot of time focusing on building an efficient instruction set. On a tactical side, some things that make web assembly faster than EVM is the word size.

The Ethereum virtual machine has a word size of 256 bits, which real hardware doesn't actually have. You have 32 and 64 bit operations. And the other thing is that the Ethereum virtual machine has unlabeled, has unconstrained jumps. So you can jump to random spots in the program, which is fine, most of the time, but when you try to translate an EPM program to native bytecode or native op codes, native op codes are theory and virtual machines stack based. And when you can jump around to arbitrary spots in the program and you still have to maintain the stack. There's no good way to produce a, it becomes much harder to write a program that is called

jitting, that compiles to native by code. So web assembly, it fixes this problem. It can only jump to certain spots in the program. You have nested blocks and you only can jump to the end of the block and that's it. So it becomes really easy to JIT or write a program or translate a web accessibility program to native code. So one thing I noticed was, you know, a lot of like the serverless computing people like, you know, people from Amazon Lambda, Google Cloud, they've actually been poking around like the Pocodot WebAssembly repos lately. And so it's almost like a little bit like, you know, they're actually depending on, the blockchain industry is depending on the, like, web industry to, like, kind of build stuff for us, but now it seems

like a little bit the web industry is like kind of like depending on us to build it for them. And so it's kind of like, you know, maybe the tables have turned a little bit. What do you think about this? Like, you know, maybe like, how beneficial has you think the industry support of WebAssembly has been? Yeah, that's super awesome. I had not heard that. serverless people were pocering around parody stuff.

Yeah, that's really cool. I'd love to see more of that, though. So, yeah, this started out for me. I wanted to bring better just development standards to the blockchain space because I felt like it was lacking. So the fact that, you know, you can get the same system, WebAssembly to run in blockchain and gets used everywhere else. I think that's a great sign that we're on the right track.

Yeah, so shared effort, if we can have a common virtual machine that has lots of use cases, not specific use cases in blockchain, but can also be used in Cervalus. For example, Fastly, which is a CDN is using it to do computation. It's used in games and browsers. So it has, we have lots of development coming in from all different angles onto a common platform, and that platform gets mapped into a lot of different hardware infrastructures. And this is kind of, I think, a waste in protocol. Juan Benet is sort of, I think, popularized that term when he talks about IPFAS as being a waste in protocol.

But I think WebAssembly is also a great example of a potential waist-thin protocol. So you try to bring WebAssembly as a replacement for the EVM. I wonder what was the reception? So A, how far did you get in the development? And B, what kind of reception did you have from the Ethereum Foundation for this work? So it meant a lot of resistance to start with, and, you know, rightly so, because, like, it was fairly new, no one knew what it was. So, yeah, it took some work convincing people. And, you know, whenever you make a change to a blockchain system that holds a lot of money or a monetary value, it shouldn't really, I don't think it should be easy to change, like, the core,

opponent of it. So I don't feel like that's a bad thing. But we slowly gained momentum. I think the big things, the big arguments that won out of the time was that it became obvious that we were going to keep wanting and keep needing to add pre-compiles. And if you don't want a pre-compiled op code is it's a op code that is almost like a contract in itself that just gets added natively. So in Ethereum right now we have like different hashing algorithms as pre-compiles and we have some pre-compiles that are used for verifying zero knowledge proofs to do pairings and stuff. So each of these pre-compiles, the problem with them is, they open up a large attack space. They can be really complex. So for example, the

pairing, once that handled pairing, I believe there was a bug not too long ago that was found in Geth. I'm not sure if it was Gether parity anymore, but it could have been a consensus-breaking bug if it hadn't been caught. But the essential problem is remains. You have, these are fairly complex programs and you say, okay, this is going to be part of the specification now. So that every time you, for example, if I add hash three as a pre-compiled, I have to add the specification for hash three to the specification of Ethereum. And that makes the entire thing much, much larger. Now, if we can have a simple instruction set that is efficient enough to allow us to implement Shaw 3 or any other

hashing algorithm in the instruction set itself. We don't have to add Shaw 3 as a specification to the Ethereum specification. We can just implement it in the base instruction set. So what this gives us is a smaller, what is called a smaller trusted competing base. and the trusted computing base is the amount of code you have to trust for the system to run correctly. So instead of trusting, you know, a SHA-3 implementation, Shaw-256, these pairings, all these other pre-compile code, all we have to trust now is the implementation of WebAssembly, and we can run everything inside it. So, I think that was probably the largest argument for it. And then the second argument that we sort of briefly touched on earlier is that, like, I think it's a waste-in protocol.

So you have a lot more mind share being directed into WebAssembly from lots of different industries, whether it being game, web browser, serverless. You have a lot of different people thinking about it and building common utilities for it. So it gets easier to develop over time. You get a wider variety of libraries or development tools, more people knowing about it. And you move to DFINITY and you started

this new project, Primeria, which is like the main theme of our conversation today. So give us a sense of why DFINITY in particular and what is Primer? It sort of isn't clear where I stopped EOsm and started Primer. They were kind of the same thing for a while, actually. So Pramia was an implementation of EWosom which started out that way. We should talk really quick about Ewasom and the fact that, so EWASM just took, took, it doesn't change anything else about Ethereum other than the virtual machine.

And I started with that, but then I was thinking, okay, well, if we have an optimal virtual machine, what would it look like if, you know, we had an optimal or a better way for contracts to interact with each other? And that's what Pramia started out to be. So I started changing, I tried to start with some small changes. After the Dow hack, I became interested in adding something called the actor model. And this was because the Dow hack was caused by something called a reentry bug. And that's where a program talks to another program, and then that program talks to the first program again.

And what happens in Ethereum is you get a new instance of the original program with the same state. And that can lead to confusion and the Tao and cause bugs. But that is not what happens in the actor model. Every instance of a contract, there's only one instance that stays around forever. Or not forever. one instance per contract ever exists so a contract might contract a might send a message to contract B and B might send a message to A again but A is going to finish this execution then it's going to process the next message in a skew so you never

can get into this reentry situation I started playing around with that after the Dow hack Grave Colvin was also also sort of interested in that one. So we sort of talked about it. And yeah, it started to implement it. And that was Primia. So Primia was basically like,

you know, it came out of this idea of like, okay, this Ewasan project's good, but it's like stuck with the backwards compatibility issues of like trying to remain somewhat backwards compatible with the EVM. If not in like directly like the contract and call each other,

but at least like in the programmer mindset. backwards compatible. And so DFINITY was like, okay, what if we wanted to like, Primeria was sort of like, what if we wanted to start from scratch altogether? So the second part of Mahir's question was, so why DFINITY, why move over to DFINITY to work on Pramia instead of continuing to work on it within the Ethereum Foundation? All right.

Yeah, so that's really simple. It's just there's no way to, there's the easy, path forwards to change the virtual machine in Ethereum. Well, easy. Kind of easy. It's still pretty hard. It's really hard to change anything about blockchain that are running, especially when it requires

a hard work. It becomes near impossible to make a change that would break old contracts, right? And that's what Premier did. It wasn't immediately clear or possible to represent all the old contracts if we made these changes. Things would have to break. So I actually spent a while trying to figure out how we could make this backwards compatible.

And I just sort of gave up at some point. I thought, well, it would be a lot easier and we didn't get a lot for the way. if we just started fresh. So you and yeah that's where DFINITY comes in. It was a fresh chain and it was doing some really cool stuff. Dominic Williams was doing some really cool stuff with proof of stake I thought so yeah so I joined efforts with affinity to like launch this forward. It's been really great, like having a fresh table, a clean slate to work on. You don't have to worry about backwards compatibility.

It makes your life a lot nicer. This episode is brought to you by ShapeShift. The world's leading trustless digital asset exchange quickly swap between dozens of leading cryptocurrencies, including Bitcoin, Ether, Zcash, Gnosis, Monero, Golem, Auger, and so many more. When you go to Shapeshift.io, you simply select your currency pair, give them your receiving address, send the coins, and boom. Shapeshift is not your traditional cryptocurrency exchange. You don't need to create an account.

You don't need to give them your personal information, and they don't hold your coins, so you are never at risk from a hacker or other malicious actor. Shapeshift has competitive rates and has even integrated in some of your favorite wallet apps like Jacks, so you can swap your digital assets directly within your wall. wallet just as easily as putting on your slippers. Whenever you see that good looking fox, you know that's where ShapeShift is. So to get started, visit Shapeshift.io and start trading, and we'd like to thank Shapeshift for their supportive Epicenter. Now let's maybe talk a little bit about what this whole actor model is. I, you know,

I've normally always heard of like this analogy of these like mailboxes and stuff. could you try to like maybe like break it down very simply what the actor model is and maybe how it's different than the current model of smart contract and the EVM and what are the benefits of it? The actor model is actually really, really simple, I think. And you can think of them every actor as like a person really or an entity. and people can usually, at least me, I only can respond to one thing at a time. So an actor has a mailbox, and other actors can put messages in their mailbox.

And each actor can take one thing out of their mailbox at a time and designate what to do with that message. It can read it, and then, you know, send other messages or do something. Or discard it, right? So that's essentially what the really broad model for an actor is. And what Ethereum has is it's more like everything is compatible. Ethereum acts like one big program right now.

where you have a function in this program, every contract acts like a function and a function can call another function. And that function, if it calls the original function again, it's going to start a new instance of the function with the same state. Yeah, so those are the, I think, the big difference. I might try to make it a little bit more clear. In Ethereum, when you have a program, it doesn't send a message to another program, but it does is make a call. And what that means is it pauses itself. So it's running, it's running and running and pauses this message.

Now the other programs running, running, running, running. And then if that program can send another message, another one, it's going to, both those, programs are going to be paused. And in the actor model, this never happens. Programs don't pause or lock like this because they always run, they get a message and they run to completion and then they grab the next message from the inbox. Two of the properties that the EEM provides then in that case are these concepts of being synchernice and being atomic. Could you actually, you know, maybe explain to the listeners that what are these two concepts?

Are they the same thing? What's the different? Or are they different? Yeah. Yeah, they're actually not the same thing. So asynchronous versus asynchronous. So synchronous would be like if we, let's say we do this as humans. synchronous would be like I say one thing to you and then I pause and I'm free while you talk

and I can't do anything else so I'd be like I'd be like hello sonny and then I hi yeah so that's synchronous that's really weird humans don't act that way um asynchronous is what we we're more accustomed to like I say one thing but I keep on moving and I keep doing things And then when you receive my message, you respond. Adamicity. Adamicity means, let's say we all are trying to, if I want to convince everyone's opinion or no one's opinion. So I try to convince you of something. and I try to convince, you know, Alice is something, and I want to convince both of you or none of you.

And I don't want to be stuck in the state where one of Alice is convinced, but you're not convinced. And so this is the basis of sort of animosity. Like, I either can convince you to both. You're both committed or you're both not committed. Yeah. Does that explain it, you think? Well, oftentimes ademicity is, like the example used, is this common train and hotel problem. Maybe could you describe this like how that, what that problem is and what admissity means in that context?

Right. So the train and hotel problem is where I want to convince both the train and the train company and the hotel company to book me a train raid in a hotel room or I don't want to convince either of them because I don't want to be stuck in a situation where I only have a train but no hotel or in a situation where I have a hotel but no train. So that's the idea there. So if I'm understanding this story correctly, so you worked on the EVM, you saw its flaws. But I think the first level of flaws you saw were in the addition of opcodes and things like that. But then you realize that, okay,

they're like deeper, like conceptual issues around how the, how the Ethereum virtual machine runs. And like these issues are, The first is the lack of an actor model, which essentially allows, if I am a contract and you are, Martin, you are another contract, me to call you and then I get paused. But then Martin, you can again call me while I'm paused and a new instance of me will spawn up. And these two instances can basically conflict and that's what led to the Daoburg. So like, so that's that's sort of one issue you realize. The second issue, it seems to me, is in you, you wanted, you saw the need for a system in which contracts can keep executing sort of in parallel.

That's what, that's how I understood asynchronous, asynchronous meaning that, so Martin as a contract sends me a message. I process that message and I then move on to the next message. So I keep moving on from message to message to message. And I don't need to depend on other things being complete in order to keep processing my messages. So you want to enable some functionality by which contracts would just care about their inbox and like process message one, do something that might lead them to create other messages. then once that is complete, process message two, then process message three, process message four, and so on.

And in order to move from message one to message two to message three, they do not need to depend on any other, the execution of any other contracts. So you felt like this sort of construct is needed in the blockchain space. And then the third thing that I gather is you felt the need for contracts to do atomic operations. So maybe a contract needs to withdraw money from a different contract. And at the same time, it needs to change data in a certain contract. But that contract wants to ensure that either both of these operations happen or none of them happen. So the money gets withdrawn and the data gets written to two different contracts or none of them end up happening. And so you felt like that these three things are needed.

So it's like asynchronous communication, atomicity, and the actor model. And sort of this is what led you to build Primer. Yep. And I add to that. So there's two things I'd add to that, though. That nails it pretty close. Also scalability, whenever you have sharding, you have asynchronous messages between shards.

There hasn't, there's very few sharding, well, okay, there's a couple sharding schemes that have synchronous messages between shards, but I think those are kind of crazy. So generally, any messaging between shards, shards themselves, are act like an actor, right? So you have, a blockchain is an actor. And you have a list of incoming messages and they're put in a mailbox. And in a block chain, the mailbox is a block.

So you get a block and it has the messages and they're... And Ethereum ran one at a time. So you can see Ethereum as a single actor as a stands now. And then when you add multiple shards, now you have multiple actors. Each shard is an actor. Um, I didn't, so what I was thinking was like, well, if the shards themselves are actors, why don't we just move that down a level and make all contracts an actor, right? And it would be a more cohesive system.

So now programmers don't have to think in two models. Because otherwise, you have two different models to think about. You have one model, if contracts are talking to each other in a shard, and then you have a different model for contracts talking to each other in different charts. And I thought that would be really confusing. So I thought we could simplify it just by having one system. Arthur, what about like, you know, sometimes there are advantages to having systems that are like synchronous and atomic.

So like, you know, for example, like, why did the EVM make like the design choices it did? For example, let's say you in, in, in, in, uh, infinity, you did want to solve the train and hotel problem and you wanted an execution to be atomic. How would you make that happen now when we don't have like atomicity between contract like in program execution? Yeah. So that's really good question. And it does get a little bit harder to do in Ethereum. So let's talk about why Therium did it. Ethereum was coming from the database world. It was sort of like looking at it as a stored procedure. So there you am it's really easy to solve this. You don't have to do any special coding. In Primia or DFINITY it's a little bit harder to do it and the

way you do it is sort of like a two-phase lock. Now we don't have to implement a full two-phase lock because we know everything at least within a shard is being executed correctly. But what this means is, so we send a message to the train company saying, hey, I'd like to reserve a train. Right. And the train company will give us back a reference that says, okay, this is reserved. Do you want to confirm? And then you do the same with the hotel. And you get a confirm. And then once you get both the confirms, you confirm them both, and you have them both reserved.

So that's the basis of the lock system. And let's say if you sent, you reserved a train and you get the confirm back. And then you go to get the hotel and there's no room in the hotel. you don't confirm with the train said you cancel. So that's the very high-level description of like what it looks like to program atomicity on top of this. Does this mean then you end up having to bake in some sort of like timing assumptions because like things have to time out at some time,

otherwise you might get into like endless to general problem situations? It depends on several things. Whether you have to debate in timing assumptions, I would assume some contracts would, you know, you would say I would like to reserve a train and you would get back a confirmed button that was valid for, you know, a thousand gas or something, or, you know, a thousand ticks or one block or two blocks or something like that, right? So some amount of time. And after that, it would be like, yeah, dropped. Uh-huh. And now what about the, you know, the synchronicity versus asynchroncity side of things? One of the, like, you know, things that makes JavaScript, like, kind of good, especially for the web world, is the fact that it's generally asynchronous.

But then it also leads into this, like, call back hell kind of situation that, like, people, like, hey, How do you help improve the user developer experience on doing that? It is definitely a lot more complex for developers to have to think through asynchronous logic. Yeah, totally. And JavaScript, okay, but JavaScript is also probably the most widely deployed language, one of the most widely deployed languages. and developers have managed to use it fairly well. And taking a page from JavaScript,

JavaScript adds ES6 adds async, a weight. So, like, primitives that sort of make asynchronacy easier to deal about and makes it look more linear. So that's the, I think, the simple way to do it is just provide better high-level languages. I see. Cool. So going back to the actor model basics now,

one of the things with an actor model is it usually, like, you know, the idea is that you're trying to run many contracts or actors in parallel. And let's say one contract, one actor ends with sending a message to A, sends a message to B, but also C. sends a message to B. And it depends how B, executes depends on what order it received the messages in. But what happens in the situation where on two different computers, in one computer A was faster, but in the other computer C was faster. And now you have now you introduce some level of non-determinism into the system where on these two different computers, B is acting on messages

in different orders. So how do you resolve this situation? Because obviously in the blockchain world, we need absolute determinism. Yeah, there's several ways to resolve this, actually. And the way I implemented in Primeria is I count how long a program runs according to how much gas it spent.

So if you're first, familiar with Ethereum, gas can be spent in several ways. One way is through computation, like doing opcodes. Another way is through using memory or another way is storing things. So if we only use the gas that went towards computation, so the end up codes. We only count that that should give us some measurement of time if the gas is if the metering is correct or about correct and that's debatable are you designing us in in premier are you having different types of gas for like you know storage versus like are these storage gas different than computation gas but one of the

nice things oh not nice one of the things i always found a little bit weird about ethereum is it basically pegs the rate storage costs to computation costs And you know, I feel those two might be to fluctuate. Is this something that you're doing, like keeping these separate or are they still like joined in one gas counter? I still only keep track of the the gas that's used for computation as opposed to gas that's used for storage and whatnot but there's still only one gas count or you know a transaction.

Now, I agree that that might need be separated out, but I felt like it was simpler not to change that right now and deal with that probably at a later time. So as it stands now, it's still bundled together at a high level. So I'm actually trying to get a sense of what Premier is, right? Like so, Primer is not a virtual machine because it's also espousing that contracts ought to communicate with each other in a particular way. And that's functionality beyond the virtual machine. So the virtual machine is like how a contract is executing. But so it's not just a virtual machine because it also involves this design of how the communication ought to happen between contracts. So, yeah, so like the question becomes like, what is Primer?

Right. So that's a good question. So it's definitely not the virtual machine. Like in implementation of Pramia, the virtual machine is abstracted away. So you can use other virtual machines with it. You could use like just JavaScript or whatever. Also, it does not include knowledge of, about gas. It doesn't know anything about gas. It is. All Primia is a messaging system

between actors. We discussed actors briefly, but to review they're just a simple program that has a mailbox and it does something. It can receive a message. It can send messages and it can create new actors. So those are the three things the actors could do. That's the most basic description of that I would say. Oh, this is cool. So actually the virtual machine piece is abstracted. You could, so you could have like Ethereum virtual machines communicating in this actor style model and Primer can enable that, but you could have WOSM machines communicating in this actor-based model and Primer can enable that as well. So it's almost as if you are building something to which,

which doesn't map to a name in conventional, like technological systems. Like it doesn't, it doesn't map really well to the name virtual machine. It doesn't, what you're building is not an operating system. It's not a virtual machine. It's like a model of communication. Yeah, it's pretty, I think that it's somewhat closely related to micro kernels, right?

And it's like a very small layer that says how programs can communicate and how programs can interact. Your operating system should keep programs, you know, their memory separated so a malicious program can't take over another program's process, right? That's the core proposition value of operating system. It keeps the programs in line, doesn't allow one program to use up all the resources of the computer, etc. So it's kind of like an operating system in that sense. It's kind of not as in it's a little bit higher level. like operating systems only run usually on one CPU so it'd be like an operating system that had virtual machines built into it I guess another like important design aspect of Pramia is along with

the actor model is this object capabilities system that you have you know this opt capability This is actually something that became somewhat popular in the OS world and then you're kind of like applying it here. Could you tell us a little bit about what object capabilities are and why you found it useful and important to implement them in Primeo? Yeah, so object capabilities have a long history in smart contracts. Like before the blockchain. One of the pioneers of object capabilities, Mark Miller designed a language called E-Ling that was sort of, that had a lot to do with smart contracts. They were thinking about smart contracts in, I think it was the 90s, early 2000s.

But long before the blockchain, and that was along with, Halfini and some other notable cypherpunks. And the idea of an object capability is a capability, you have objects and they have some methods on it. And a capability describes a transferable right to perform one or more operations on the given object. So you can think of it in terms of like a key, you can pass a key around and that gives you a right to open a lock or to perform the operation of opening a lock and you can copy that key and you can delegate that key to other people. So I think that's a pretty good analogy for capabilities.

And so why is this, why do you prefer this over the more traditional form of access control, which is called access control list. Why did you choose to go with this model instead? It's sort of just like, yeah, it was not for me a clear path. I started out with the actor model. It was my first step. And then I wanted, I knew that I wanted to be able to, build secure zones factors.

So I wanted to be able to use a program and I wanted to be able to isolate the program from the global world. You can't do this in Ethereum today. Like if I deploy a contract, any other contract in Ethereum can always message it. I cannot isolate it. I can't protect it from the outside.

So I started with like, okay, that is really important to me. And the reason that's really important to me is I also want to enable extreme modularity. I want programs to be extremely modular and reusable. This is also taking a page from JavaScript World. MPM has a ridiculous, sometimes overly ridiculous amount of modularity in it. I mean, there's like five notes. no op packages on NPM. She's totally excessive.

I've actually used one before. So you can't have any level of modularity in a high security or in a platform that needs high security. If your modules, if they're, the poet's contracts, all needs. to include code that prevents them or needs to have extra code to prevent them from being invoked by parties that aren't supposed to. So I wanted to provide at a system level, provide system guarantees of who can communicate to Hugh. One way to do that is an access control list. I honestly don't know how you could design a system like this with the ACL.

Yeah. I never really considered ACLs in depth. Yeah. At least for this. So, yeah. I started from the point of view of looking at continual CSP and communicating sequential processes. And from there, moved to more

of the actor model and object capabilities. But ACLs, you need, what ACL does, instead of having a key, the object themselves keeps a list of who can talk to it. So that would be like me saying, okay, Sonny, you can talk to me, as opposed to you just having a reference to me and being able to talk to me if you have the reference.

Kind of like if I knew your first. number than I am able to talk to you. Right, that's the capability, exactly. That's great, great analogy. And so the central, one of the largest problems with that, well, okay, in literature there's a lot of problems with it. And I don't want to go into that too much because there's a long and complex history that Mark Miller is the guy to talk to.

But the reason for me, I didn't choose it to implement. that has added a lot of complexity. Object capabilities was a much simpler way to implement this, and I thought provided a much cleaner, yeah, surface. Right, yeah. So we're actually using a, like, object capabilities model as well in the Cosmos SDK. And one of the things I think I, what I noticed was the defaults of a, object capability system is to fail safely while the default in access control list is to fail in a bad way.

And so, for example, I think the parody, both the parody wallet bugs were sort of a failure of access control list. Yeah, definitely. Like everyone's expect, every contract expected to implement its own access control list using these like modifiers, like only owner and stuff like that. And when you fail to do that, then you allow anyone to the default was to allow anyone to, like access functions of your wallet that you don't want to. Yeah, that's like pretty crazy. We're dealing with money here and yeah, I don't know. A few months back, we did an episode with Archane, Greg Meredith.

And to me, what Premier is trying to do and parts of what Archieen are trying to do look superficially similar, right? In our chain also there's this concept of that I won't call them actors. Like there are these processes sending messages over channels. And to me it feels like the archane concept of process maps to your concept of actor. And your concept of the inbox for each actor maps to the archane concept of the channel. Is this correct or there is some fundamental difference between these two models? Okay, so there are some differences.

So Greg's coming from, he's looking at, he's looking at his system is coming from the point of view of communicating sequential processes. And it's like more formal, it's a formal way of describing patterns of interaction in concurrence. systems. And yeah, ACR model is a concurrent system. So there are going to be a lot of similarities between the two. And they probably have equivalence, though I don't know enough about CSP to say 100%. Yeah, they're exactly equivalent. Craig would probably say no or something. I don't know. But yeah, I was definitely, I've hung out with Greg before, and I think it's really cool. I think my approach tends to be a little bit more engineering, and he's a little bit, or archands a little bit more coming at this from a theoretical and formal point of view.

But yeah, I think it's great work still. So give us a sense of what is the current state of prime. And unlike other things with DFINITY, Primer is open source, so developers can actually play with it. Yeah, this is, well, yeah, this is part of the thing where I started writing Primeria before DFINITY. So I started writing Prima at the Theorem Foundation. So I was open to begin with. And I should say like, well, the rest of DFINITY's code is going to be open.

They're just going to wait till the test net launches. And then at that point, it'll be open. So it's just like cleaning stuff up at this point. The state of Primer right now is it's being used in an internal test net for DFINITY. So it's up and running. It seems to be working pretty good. Yep, and it's on GitHub. The documentation is still lacking.

We have some docs that just haven't been published. But yeah, you can expect that at probably the end of the summer. Yeah. Have you also been working on like higher level languages? So, I mean, obviously developers are probably not going to be writing in like WebAssembly bytecode. So have you been working on like, you know, subsets of. Rost or C or something that can like compile like a Prima flavored of Rust or something like that. Yep, definitely.

We've been working on Rust and C and C++. So there's SDK and it provides like header files for you. So if you've looked at like what Paradis done with Ewasum and their tutorials on how to get started in Rust, The DFINITY will have something similar to that. It'll be pretty easy to get started. So we're targeting those C and C++, I think, to start with in Rust. Also, action script works, but that's not a very full-hatured language. And we also have one of the engineer who is working on an internal implementation of Haskell that compiles to Wasam.

which will be pretty cool. Martin, unfortunately, we have come to the end of the hour. I'm actually really looking forward to the DFINITY test net, right? So DFINITY is coming up with all of these new ideas, right? Like including the random beacon, including the primary system, the primary model of communication. And I'm really looking forward to being able to run a node on DFIN, and play with it.

So yeah. Thank you for joining us today and walking us patiently through Premier. I think I finally understood Primeria after your explanation during the show today. And to our listeners, thank you so much for joining us. As you know, we release new episodes of Epicenter every Tuesday or Wednesday. You can subscribe to a show on iTunes, SoundCloud. or other podcast apps like Stitcher for iOS and Android. And if you like to see videos, you can get the video version of this show at

YouTube.com slash epicenter Bitcoin. Recently, we started a Gitter community in order to chat with our listeners. So you can check that community out at epicenter.tv slash Gitter. Finally, we love to have your reviews on Twitter or iTunes. So please do leave us reviews there and we look forward to catch you next week. Thank you.