 Okay, we're live Alex, did you or anyone else have any particular agenda or discussion items? I don't think anyone added anything to the ticket on GitHub Yeah, nobody ever adds anything But since we have Danny and Sammy here, I think they probably have questions. So I would just start with those And answering those questions Okay, well, I don't actually have any questions. I just I work for a little bit and well, I think Think Cina Cina has been like been talking to you guys from through a bit, but he's now working on Other projects so So I'm just just checking out what's going on. Well, yeah, nice to Nice to meet you, Sammy. We are a big fan of Trubit here and I've definitely had a lot of conversations with them What's in it about what what Trubit team is doing with technology. Yeah, if anyone if anyone has questions for us, then please Feel free to chime in with questions. If not, maybe We could kind of go down the line and each of us just give a brief Update of kind of what we're working on and status of the project. Is that sound reasonable? I Think there's actually one agenda point we could talk about and The last couple of days I've seen some discussion around the future of Evian based languages versus E wasm and and the connection to you apparently there was an update last on the last call all core def call by Vitalik and with a potential roadmap on something termed Ethereum 2.0 and Some people have understood those words as going forward with something based on web assembly or maybe more specifically E wasm and that would mean that all of these Evian based languages Would kind of be deprecated and wouldn't really have a future So maybe that's a good topic to talk about What do you think guys I think I agree but we I think we could also do the update thing just for the purpose of documenting What's going on? Maybe we could do a quick update and then talk about that And yeah, I guess let's do an update. Do you want to start Everett with your side of things? Sure So, yeah, the I mean more more naming crisis is happening because we're trying to you know, figure out what to name all these You know, we're trying to plug in, you know, E wasm the em E wasm execution engines into into into Ethereum clients and make them you know ready to run on a blockchain and that is causing confusion about like are we going to You know have E wasm code able to call EVM code and if so, what's the layer that kind of handles all that logic? but otherwise just been kind of gradually Refactoring EVM to make it so that I can pull out these call semantics But I don't like I think I'm running into a little bit of the the perfect is the enemy of the good crisis Because I keep not quite being satisfied with the refactorings and it makes me not Make enough progress probably so I'm gonna try to get this gas refactoring into KVM and then I'll be able to pull out the Hopefully pull out the calls into the the K specification of this abstraction layer between a client and an execution engine and Yeah, that's about it. Otherwise, I've just been working on K tooling stuff which Is not very E wasm specific but could produce an E wasm debugger for instance or a EVM debugger Stuff like that. So That's about it Any questions or move on? Yeah, if anyone has questions, please feel free to just speak up I think separately we could we could also deep dive a bit more into this naming Discussion ever it has mentioned, but maybe do it after the To stand up Okay, I'll go ahead and give an update. Hi guys, this is Lane. I'm sorry my avatar says the theory in foundation I can't change it. That's just how the streaming software works Yeah, so as people may or may not be aware we are working now and launching any wasm testnet so The piece of that I've been working on is tests. So trying to write some low-level Web assembly tests to make sure that all of the various EEI host functions Are working properly or passing the test that the layer we have Which sits in between the wasm engine and the ethereum client that we're using CPP ethereum Yeah, basically is bug free or as close to bug free as possible I think we may talk a little bit more about what host functions in the AI and all that kind of stuff is in a few minutes here That's sort of seems like an interesting topic to dive into And the other thing I've been focused on is we are now talking to the Trinity team, right? So Trinity is a brand new client written in Python that Piper Merriam and Jason Carver and a bunch of other awesome people are working on and they've just done an alpha release So we're sort of figuring out right now how to a specific question Which is how to integrate how to add you wasm support to Trinity and then a related general question Which is how to think about adding you wasn't support to any ethereum clients in general We're working on some proposals and hope to share those very very soon for feedback That's great to hear Lane. Maybe I go next Mostly I've been and been working on on Hera, which is the C++ DM implementation and I also have been working on the a Library in Rust to implement the you wasm Quote e I which is all the methods as of today all the methods a contract can access and give a nicer abstraction and rust any connection to that I Worked on a couple of current ethereum pre-compiles implemented in rust Which can be compiled directly to WebAssembly And this would be a I mean it has two purposes One of them the actual Library can be used to write contracts in rust and the pre-compiles Make sense for two reasons. One of them. They're like a good demonstration of Why there wouldn't be any to have pre-compiles because one could write them as a contract and second it should be a good starting point to do benchmarks across different e wasm VM implementations As Lynn has mentioned there is working progress to implement the native E wasm support in Trinity, which means the entire VM and Execution engine and the execution engine is the actual part running WebAssembly so they The entire VM would be written and the entire client and the VM would be written in Python Where as Hera, which is the C++ implementation uses Currently a single C++ Execution engine called binarian But there's some work ongoing which would enable Hera to use multiple execution engines Of course one at a time But one of the newer execution engines we're looking at is a JIT And based on LLVM and having these pre-compiles and having the support for the JIT as well as having the Trinity implementation would enable us to do benchmarks across all of these and Having benchmarks would enable us to do a couple of things. But one of them is to determine The entire gas calculation and gas costs in a more reasonable way than we did before Something that's really exciting and thank you Well, lately I've been working on Writing more test cases For E wasm and reviewing reviewing Well, new test cases from Lane as well Well, yeah, I think we are having good progress on writing new test cases and Well, Casey and Jared are not here, but they are having a good progress as well on on the on the E wasm Explorer, so I've been trying to help a little bit on that and fixing just minor minor bugs there Hugo, can you explain what the E wasm Explorer is and how it fits into the test set? Yeah, sure Well, currently the The E wasm Explorer we have is a fork from either chain so Jared and Casey adapted it to to access the E wasm node and actually show for example, you can see the the current blocks You can see the pending transactions You You you have You also have the list of accounts and you can see the E wasm by code of the contracts deployed to the E wasm Testnet and I think that's it Does anyone have any questions about any of the update topics and if not we'll move on to the other topic that Alex proposed Alex, I think you said you wanted to talk about the Maming flash abstraction Sorry, yes, it There would be two topics. I think it could be a good conversation starter one of them is These two different abstractions we have in the naming around them or maybe three different abstractions in the naming around them which may be quite a big topic to talk about and the other one is What is the future of Evian based languages and and If if E wasm comes around Which one should we start with? Well, the naming one seems like a more concrete discussion to me So I would vote to start with that it's up to I Don't know how concrete do you envision the other discussion being? Well, for that one at least from myself I can give my opinion and an overview Just to set the the scene But luckily we do have a couple of adult people from from Viper as well on the call So they might be able to chime in and give they their own view on the topic Regarding the naming discussion, I guess we would need to start with a Quick introduction to what are these different things? We are trying to name and And I guess started the naming discussion from that point I'm happy to start with any of those Naming is the most important thing. Okay For someone that has come from naming Viper to Viper with a Y I can just tell you guys please just check everywhere where these names have been used before We've had trouble with the capitalization of E wasm is it lower case E upper case wasm is it all lower case Which is not even as hard as changing a letter. So could I see you? Yeah, just just trust me take take it from from me be very careful because it turned out there was already a Viper language like a programming language We had to change it so now it's with the Y so guys just like Google yourself flat and make sure like all the items or Like for instance Pi Pi the package managers also have those names available It's very important. That's all I can say Yeah, I agree. I guess the theorem community kind of has a history of naming problems, huh? I'm glad that you guys settled on Viper with a Y and there's no naming conflict and Everybody's happy and using that name Well, if you're if you're on maybe we should just quickly start with the the language part Everett if you don't mind Yeah, yeah, okay. I guess I can Watch out you want to start with your view on the Viper What the future would be with Viper if if E wasm comes around right so solidity part I'll start with with what we just discussed on the it kind of happened organically, right? So What is what is interesting is like What what are the implications because we see these things like and EVM to wasm converter, right and I looked at it and and we just start laughing because like all our languages and this includes solidity Was basically designed around this concept of 256 bits and now we're moving to 64 bits and The conclusion that I just made well overthinking it just like for 10 minutes. So just consider what I'm saying That it's not too well for through is that basically like we either have to start adding new types to these languages Because it just doesn't make sense to translate 256 bits the incentives are just not there To do so because it's just so much more inefficient to write 256 bit math in 64 bit math And then there's no incentive for anybody to ever run a contract using V1 Which means we have to start adding 64 bit types to the language So that would be my first question. Is that is that what's intended? I Think if you're asking about deprecation of V1 At least my personal opinion is that yeah, we should You know take steps to deprecate EVM again But just because it's you know, it's kind of a first cut and it's you know It doesn't have good modularity and separation of concerns and it has like some kind of weird things That people kind of largely agree are not good for for low-level VM languages stuff like the unstructured control flow and All sorts of other little issues and I think I think people largely agree that that EVM V1 is not the ideal Design of a VM. It doesn't have good separation between the aetherium level stuff and the VM level stuff But regarding the 256 bit and 64 bit translations I think that's just Fact of life that we're gonna have to live with the idea behind wasm is you know we're We're We're trying to make a and you know a language that maps well to hardware So that we can be you know executed efficiently on hardware And so that a lot of the standard optimization engines that exist can be applied directly to it and The fact of the matter is that 256 bit hardware doesn't exist like that So right so the translator would be a stopgap basically you Mean EVM to wasm specifically Yes, it would be like a type of stopgap until the languages accommodate 64 bit types Well, I don't know if I would I Would like it to be that EVM to wasm is yeah, just a stopgap basically just to get Just to be an initial approximation of the contract But I would not count on even able to wasm being a semantics preserving transformation right, I would say like so You know, I would I would say like if you if you are confident in your bytecode before and then you put it through EVM to wasm you still need to go through all your quality assurance Checks on a generated wasm code to be confident in your bytecode after Yeah, so basically what The conclusion I'm making from my side is one kind of has to just start from scratch in terms of the language development Like you can take the syntax as the base the you know the the structure of what it looks like But basically considering like you don't everything should just start from scratch Including even the API Yeah, I suppose I suppose so I don't know how much how much from scratch though You really have to do because I think that a lot of that heavy lifting has been done I think Alex would know better than me about exactly how much the heavy lifting has been done But but I think like a lot of the the 256, you know a bit encoding into 64-bit arithmetic Has been done. So Alex, can you maybe talk a bit about that? So actually I wanted to read it Okay, sir I guess I didn't unmute it. I just wanted to give a quick overview for Those potential people who gonna maybe watch this after the the live stream and just to maybe clarify some of the confusion and that confusion is And sorry for saying this having all the viper for folks on the call But it really seems at the moment solidity would would have a bigger market share so people are really Concerned what happens to solidity if he wasn't goes live and But it's nothing against Viper it's just the fact no That may or hopefully will change. I actually hope there will be more languages And just first of all we we have set this I think every single time we made any kind of discussion about he wasn't as It really makes sense to have domain specific languages For smart contracts But one of the main points of using web assembly is that we have access to a much Bigger and much more mature toolchain one of those toolchains is LFDM which enables a lot of different Languages people are familiar with but they may not be domain specific enough In some cases, but they do make sense to to write heavy lifting code in For example that the one thing already mentioned would be pre-compiled So anything which I would be like a utility library or a much more low-level Thing that really makes sense probably to write in a language which can be optimized by adult existing toolchains But probably higher level The rules and logic Very likely makes more sense to be written in a domain specific language One of those would be solidity another example today would be Viper, but they're I think they're tone a ton more being developed for EVM and and probably Quite a few being developed for web assembly based blockchains already and and for the for the actual solidity in question In the solidity project itself there is an intermediate language in development which would have a Web assembly output, but then of course the solid language will need to be translated into this intermediate language Which probably is a tiny bit bigger task, but we do expect it to happen You know fairly soon within in within a year but it's worth mentioning that one of the One of the other projects Working on the k-framework of whichever it we have on the call who is a big contributor to the k-framework K-framework based on my understanding should be able to Compile solidity to web assembly At some point of the future as well So one may not need to to wait for the solidity compiled to compilers who support this Yeah, I would say the solidity compiler will probably have support for you wasm sooner than the K-framework SBC stuff will be ready. That's more of a six months sort of proposition, but but also the I Think supporting you wasm from soul C shouldn't be too Hard because It took two engineers here at RV Only a few months to support Yella from soul C. So I think that it should be And yella has different architecture for integers and stuff than an EVM does for example. So okay go on Yeah, it's definitely not It's not a big deal to do it It's just a matter of time and right now the the focus isn't on on that project But it's definitely definitely on the the timeline to to be one of the the more important projects next So hopefully that will happen But as a stop gap as Everett has mentioned and EVM to wasm Could be used to translate codes generated by solidity or Viper to WebAssembly and Then I guess just a quick note on this other topic which have been brought up Whether we should keep all of these 256 bit centric Designs we have currently one of them is the ABI the contract ABI and I think personally I would be interested in and maybe looking at this in more detail and and Thinking about a 64 bit ABI Which actually isn't really dependent on he wasm. It could be supported by current EVM languages as well and if the ecosystem is is Determined to use He wasm which would be 64 bit then this transition could be started Even before launching he wasm, but that probably is a good idea to think about that because whenever a Contract a higher-level logic contract would need to be written in any kind of language and most of the languages aren't really designed for 256 bits and Therefore there would be a need for a framework and in any of these languages To to deal with ABI encoding and everything else which would be a common thing in writing a contract And if that is 256 bit on a 64 bit machine, that is probably a lot of wasted effort Which doesn't need to be done So probably in the next couple of months that could be a good discussion point And I think that's all I wanted to say sounds good to me basically from Since I'm we're a very small team as an it's just me currently on permanently on Viper The way I see it is I would start with the second version of Viper that specifically targets 64 bit and all the types Would Specifically be catered for that Including the in-memory bytes Because that also changes so kind of like writing a second version But just keeping the the lessons we've learned from the syntax side I don't know if that's if it's even necessary to be that extreme though because the Already in the EVM to wasm repo there are a bunch of chunks of wasm code that directly You know do the 256 bit arithmetic Over 64, you know over the 64 bit representation just you know handling chunks of them at a time So, you know for you can I think The approach I would think is you know, okay add the 64 bit types to To Viper and then when you're emitting EVM code, you know, just round it up to 256 bits And then when you're emitting Wasm code if it's a 64 byte use the native and if it's the 256 just emit the chunk of wasm code that you know handles the the 250 So I'm just saying I don't know if it's I don't know if you need to worry too much about It at that layer, I guess is what I would say or maybe you could just start off by adding the 64 bit types To the Viper level and then say okay if you're emitting wasm Code, you know, we're only going to let you use the 64 bit types Initially and then down the line worry about emitting I'm just saying like there's already wasm code in place already chunks of wasm code You can take that have at least some testing against them That that's roughly what I have in mind so like sort of have like Like like I said the stopgap one would support like let's call it Viper one It's not the real version, but it would be the the EVM one version and then I see like adding 64 bit types being like only like sort of like mashed together But it's early days. So I'll see how it how it develops But yes, that's that's roughly what I had in mind Okay Yeah Actually, there's one comment on on the ABI You know right now the ABI on On the part of interfacing with a contract it usually starts with a selector, which is at 32 bit Number and which then Which isn't followed by the actual ABI encoded data and this selector right now only is a hash of the function name and The input argument types But it doesn't take the return types into consideration and there has been an Issue I'm not sure if you guys are familiar with it or heard about it but due to Due to the way solidity that the compiler in solidity didn't Do a couple of checks in the past because it was kind of impossible to do them Effectively before having the return data copy and return data size of codes It didn't do it didn't do any checks whether the called Function on a remote contract returned the expected data length because there was no no way to tell and therefore In ERC 20 token some of them I think at some point They have changed the interface of ERC 20 the transfer function And previously it didn't return anything but after the change it returned a boolean and they also changed the semantics whether on an error it should return false or whether it should throw but it was a big mix between these two and Some of the decentralized exchanges decided to take the newer version of the interface Where it expects a boolean and the boolean has to return true if it was successful and There was a change in the compile and the solid a compiler when return data size was made available in Byzantium and After that basically what happened? I think roughly five to ten percent of the tokens were broken if they if the exchanges were compiled with the recent So the diversion which actually checked the length I Can give you the the actual issue numbers to which explains this in more detail But what this sparked as a discussion is a potential change to the ABI where the selector should include the return data types as well and not just the input argument the types of things input arguments and if you want to Include those in the ABI that's already a breaking change and if you do that we could also consider looking at a Different kind of a bi then what we have today. I'm sorry. This this may have been too long as an explanation But maybe relevant to this discussion I agree that would be a perfect scenario to put it in but even Considering like that the history must actually consider having some type of versioned a bi perhaps If you know what I mean Because this is a perfect example that like completely backfired and it's really difficult to patch post-mortem Yeah, the versioning also came up as a Potential thing which should be added if such a break is just made Yeah, so that would allow breaking changes and it would allow the the client libraries to pack the you know the data based on a version kind of like Catering for expansion later like you don't design something like you kind of design it so you can expand it later I think that that would definitely be a good Value add in the ABI design Yeah, I think versioning in general is something that needs to happen in a lot more places in Yeah, the ecosystem Yeah, and maybe I would be a perfect use case because you can have like the client knows. Okay. This is VX So I can't do this and then like the the contract can just assert based on like I don't know You know eight bits even it doesn't need to be much May may make it like 32 bits. I Guess every the only reason I mentioned this is It's definitely not an issue to support the current ABI even if if the language is designed to be 64 bit But if we have this opportunity to maybe change the ABI because of these issues then we may It may be may be useful to think ahead and and look at 64 bit options Yeah the reason why I suggest that like thinking of a new ABI is basically because Because of the incentives People are going to only be using 64 bit structures because it's going to be so much faster than the you know The stop gap or there's no real reason to Send all that all those error bytes just because of the old version. I certainly hope so Do you guys want to move on to the the naming discussion? It's just one quick note like a time check here I'm going to have to end the call in about 15 minutes sharp. We can maybe go two or three minutes over Let's just make the best use of time because it is a big topic Okay, I guess I can give like a one-minute overview of what we would like to name So one thing we have I Guess I start from this part as evmc which started out as a C header defining an ABI had to plug in a VM implementation into an Ethereum client and Where to start it from is writing an evm JIT and a C++ and plugging it into the C++ client and It's also the motivation to have it plugged in into go Ethereum What the earth just has evolved into a stable specification It's called evmc right now It is supported on a client side by Cpp Ethereum and there's a prototype for go Ethereum and there's and I've dated prototype for PI Ethereum But it's been proposed that maybe it should be supported by PI EVM on the VM side. It has three Working VMs implemented in it. One of them is EVM JIT. The other one is a Interpreter called Aleph interpreter Which is the old interpreter pulled out from Cpp Ethereum and third one is Hera, which is the EVM was an implementation so this evmc is Defining an abstraction layer had to separate the VM from the client and There are consideration that there are the ideas that this could be used as Just an abstract layer Even if it's not see but used within the client even within the Python client The like to add Alex that KVM also conforms largely to evmc Once I heard about it I I migrated it over to use the same status codes for instance in the same and I naming conventions Yeah, the status codes was is one thing. I'm not sure if you also use the the rest of subtraction Well, yeah, this came up really as a discussion and PI EVM slash rating The the other thing we have right now is something called the EI which started out as a list of functions Contracts on the wasm can import from the client And EI stands for Ethereum environment interface, but it really seems like that it could be Used as an abstract interface of what are the state? a client exposes to a Contract and how the state can be accessed and modified And ever it has started to use EI as a term for this exact thing to subtract thing in the k-frame work And the last thing we have which the EI was Originally used for is the actual list of functions a contract on the wasm can use So probably these are the three things we have right now and there's a confusion between them between the naming of them I'm not sure ever. Do you want to take over from here? That sounds pretty pretty accurate in terms of my understanding of the of the situation But yeah, the main the main thing is we're going to the trendy folks with this proposal And I just want to you know, not be spreading more confusion With with you know more different uses of the names so Yeah, I think the the when I was writing the EI spec I was thinking E. I was both layers It was the you know the there's the EVMC which is kind of the layer that the execution engine exposes to the client in order to drive the execution engine and to Get back information about what has happened During execution like was it not a gas or a revert or something like that And then the EI is the other direction What the client exposes to the EVM And initially I was kind of ballooning EI out to cover both layers but I think Now EVMC is kind of the client the execution engine side and EI is more the client side But I still think that EI should be more general than just e wasm for instance Because we well, I mean you could you could think like you know e wasm v 1.0 e wasm v 2.0 or something right you want You know at least it to be you know specific to each Each version of e wasm then beyond that you would think okay I would also want to be able to support the different versions of EVM or or something like that so Yeah, so for my my thoughts on it are you know EI would be the methods exposed the state update and state get getter methods exposed by the Ethereum client or Ethereum node to the execution engine and The execution engine also exposes some kind of status codes and hooks for driving execution to The client and then we could call that EVMC or we could call the whole thing EVMC and come up with some other name for the smaller thing That is the what the execution engine is exposing But yeah, mostly I just want to Make sure that we you know I want to like let's decide on some names and commit to it type of thing You know like let's just do that and move forward I think I would like to add one one little thing to the EVMC is that We really need to make a separation I think between Two things if EVMC is used for the abstraction layer Then the actual C ABI which is Which is what's EVMC right now is the C ABI should have a distinct name Because it's one thing that a client has this internal abstract separation of concerns Regarding the client and the state and the VM and it's another thing. That's a actual VM conforms to this if this ABI And the client confirms to the ABI and therefore VMs can be plugged in to the client Well, I guess I would just think of calling that as like, you know The C plus the CPP Ethereum implementation of EVMC You see what I mean? Like you don't I don't know that we need a whole new name for each language's implementation of the same Interface as much as just saying like this is you know the implementation the interface in this language So it's actually not C++ related. This is This is more like an actual ABI and Whatever system you're on but it definitely works in the Mac and Linux so any kind of UNIX or POSIX system It's an actual ABI binaries can be compiled to and if you have the VM compiled as a binary then you should be able to Like the client could use an FFI if it's it's a script language or it could be an actual binary and would be able to load The binary without any issues. Whereas I think if it's just the abstract The abstract layer within it a client that may not be 100% compatible Also, I don't think we will come to any kind of Consensus during this call, but it's more like just Raising the the actual topic for discussion and whoever is on the call who or whoever is is watching this after feel free to to raise your voice and Come to the Iwasm lobby Which should be on on I guess in the YouTube description as well Yeah, I'm I don't know. I guess that that seems like a pretty succinct summary of of what's going on there So I don't yeah, I also don't I also think we should discuss this over text and pull requests more than over Over a video call. So cool. Any last-minute? Questions or updates? Okay. Yeah, I think that's a good place to stop Alex ever. Thank you guys so much. That's um I'm learning here as well, and this is just a really really interesting Topics as you guys said, we're not gonna reach any conclusions on this call. So please join us in the in the Iwasm Gitter channel I posted that both on the public YouTube link as well as Here in the meetup. Thanks guys. We'll see you again in I guess three weeks for the next call Hi, Greg Thanks guys. Thanks guys. Thank you. Bye. Bye. Thank you Right