Battle of the Languages

Transcript

uh we start with a panel that is actually exciting one because it's going to be very spicy at least I hope so and I have my good friend here moderator that I hope he made a good job with the questions so the next panel is going to be the battle of the languages and is moderated by Mei zali did I spell that right amazing so I guess we can start all the panelists can join on the uh on stage thank you good luck thank you on though it is now beautiful all right chman grab a seat yeah doesn't matter go for it in the middle CU it's

better there we go all right hello everyone um we'll kick off with a quick round of intros introduce myself early this morning so I'll be quick Medi co-founder and director of Sigma Prime blockchain security and research I'll pass it over to Harry hi I'm Harry I'm one of the founders and the CEO of spet and cantina we are an End security Marketplace we work with unisab coinbase you name it we work with them today but before that I used to build uh the solity compiler at the foundation um I work with a lot of uh Engineers uh building solma contracts and you know I'm happy to share my thoughts I'm Dave Grantham uh currently on the security team at polygon but

uh prior to this I worked at um protocol Labs on the LI P2P team I was head of security at the Linux foundation hyperledger for a long time uh the reason I'm here for rust is I was on the security team at Mozilla when rust was invented I ported the tool chain over to all the BSD platforms I ran the tier 2 build servers for many years was part of the team that like realized that C++ was the bug right so yeah I I I I think it's pretty fair to say that I'm one of the first rust programmers that wasn't on the rust team cuz yeah we had to learn it exciting Wolf Gang yeah hi I'm Wolf Gang GCE Camp uh I'm at updos Labs where

I'm currently leading the move platform um so uh what is move move is the new smart contact langage and we will probably talk a little bit about here uh which also comes with formal verification that's what I actually did primarily before um generally tackling the language move right now at updos updos is the L1 blockchain uh which came out of the Libra project exciting thanks for the intros um so this panel is around programming languages and you know it's a bit of a tribal topic everyone has some sort of preferences so I'm going to kick this off by asking Wolf Gang if you could please tell us a bit more about move and

what perhaps sets it apart from solidity uh if you could highlight some of the key advantages of move over other programming languages like solidity when it comes to small contracts yeah so like uh I would say one one of the key advantages of move is to be frank that it's later than solidity it was created after solidity many years after and uh it was around 2018 when move was incubated at Facebook at this time they still called themselves Facebook uh as a as a kind of uh long discussion process whether to use an existing smart contact language or whether to use rust and they concluded that uh there need to be a new

smart contact language and the main concern is very close to the objective of this conference is basically security so what differentiates move from uh other languages it has uh a virtual machine uh based on a pretty high high level bite code uh which can be fully verified you can at loading time at execution time basically verify type safety reference safety so move has a similar reference semantic and rust uh and other kinds of uh important safety aspects of the code and you can also take the move bite code and easily decompile it back into Source because there is no information lost in the move

bite code uh this also reflects in the fact that you can easily use tools like program analysis or formal verification on move because move is basically designed for being analyzable and transparent exciting and I believe there's a new version of move that came out very recently move V2 yep would you be able to perhaps highlight the main differences that were introduced in this version compared to the first one yeah I'm glad to so like uh the new compiler and I want to say right away a new compiler is considered a big risk factor in the industry we know that oh yeah uh the new compiler was created to basically unify the move verification or

move Prov architecture with a compiler architecture which were developed independently back at meter but share a lot of common commonalities if you know a little bit about formal verification you know that it's basically a compiler to an smt backend now so you compile just the different to a different target language if you want so in a lot of complex steps and that's really the same like uh compiling to bite code so that was one of the reasons so we can innovate faster in the move space By by unifying the both architectures by the way I forgot to say uh that's also important for the move compiler uh a property of move is that it's not finalized now so it's still evolving and uh the compiler was also created to make

it easier to evolve the language we created move two which is a new version of the language which has a couple of interesting aspects thank you uh I might change this up a little bit and go go with you Dave if that's okay sure um if you could tell us why in your opinion rust has become so popular amongst developers over the past decade when it comes to its security properties and security guarantees compared to the nightmare that you um pointed out earlier C++ oh okay so let me think so I I was a C++ programmer for my whole career uh I've been a programmer since 94 so like 30 years this year so wow um

wasn't even born I think that the reason that rust was popular or has been popular comes down to a couple of things so like when we were at Mozilla looking at rust um the goal was to figure out how we could slow down bugs security bugs specifically going into Firefox right it like we got tired of getting just hammered at pondon every year y you Fu geohot I like you but I would flip you off I'm I'm not Linus I'm not going to flip off on stage anyway uh so when we were doing this you got to remember firo Fox is C++ dlls and JavaScript code flying in formation that

looks like a browser okay and so you either had to be JavaScript or you had to be C++ and if they were going to rewrite components in a new language it would have to be a dropin replacement for C++ which is exactly why and probably the only reason why rust is a dropin replacement for C++ that it can expose a c uh calling interface and a cabi and all that stuff um that has certainly helped it because it allows you to incrementally change from an old in an old code base and a mature code base to rust um but I think at the end of the day we all fight in our in our engineering teams we all fight bad

habits and I think rust is the first language that we can honestly say that bad habits generally don't compile right I think it was some very basic things like flipping the default mutability on on variables to being readon you have to like explicitly say this is a variable I'm going to change right um I think it's very opinionated and very unforgiving borrow Checker um also really hammer home sort of the you know you can only have one mutable reference to something uh again that's a bad habit that we all carried over from C and C++ like oh it's just a pointer I'll just throw it around who cares um and which is we all know probably the source of most security bugs and then um let's see

the last thing about Russ that I think was really cool is that there was like we basically accepted that the long time um assumption that long compile times were a bad thing always right we we were just like look no we're going to do a ton of static analysis and we're going to take a hit on our cicd pipelines our compile times and all that stuff for all of the wonderful static analysis analysis results we can get out of this and so at the end of the day it rust is very programmer friendly it's just highly selective as to who it thinks is a programmer and it will mock you but it will if you

persist you actually end up being a better programmer and going from rust back to languages like JavaScript or CN C++ or whatever you're actually a much better programmer so I don't know I I think that it eliminates whole classes of security bugs we've been fighting for decades great but at the same time it forces Engineers to level up their skills and in the end um you get better code generally out of it um and your engineers get better I don't know I it just seems like the right thing to do that makes sense we're Big R fans at Sigma Prime so I can't really disagree but yeah yeah and then because you can

just drop in replace it you could write a rewrite a dll in Rust and put it in to replace a C++ one everybody's like well why wouldn't we do this yeah in fact Linux has officially accepted support for rusta yeah that'll be really interesting right yeah yeah we how that goes as as well performing as C++ it is it's exactly the same there are projects which come to different conclusion not because of the language but because of the way how people use the language interesting yeah I would love to dig into that but you know in rewriting components in Firefox we found that there wasn't really any hit at at execution time but we did see things like the URL parser and Firefox which was like an endless source of security

bugs when we rewrote that in Rust the number of security bugs literally went to zero it was like it's done right like there's no more security bugs I mean at least for a brief while I think there might have been sounds dreamy but it went from like just a constant pain in the ass to like nothing that makes sense yeah all right I would love to save some time to take some questions from the audience so I'm going to move to Harry Harry you've been involved in solidity probably safe to say since almost day one um you uh you obviously have a very strong security background in solidity so solidity has perhaps the largest developer Community when it comes to Smart contracts and it's its ecosystem but at the same time it's probably the

uh language that suffers from the most hacks over the past five years uh we've lost tremendous amount of money on on chain smart contract exploitation uh so from your perspective what steps do you think developers should be taking to effectively mitigate or avoid these security foot guns so I will will get to that uh but I want to maybe like tell a wider point which is you know I love rust I love you know when I was younger I mean I used to love hll and you know rust is practical like a like an objectoriented um H H it is um I also I think like rust is great for building um like systems level um

software but I don't think rust or even moo for that matter is well designed for blockchain applications the safety um advantages that rust has built in it doesn't even apply for blockchain like period like uh I meet a lot of people that learned solity for the first time that was their first programming language ever they don't understand anything about move semantics Bor Checker these are all the issues that the uh that the users are facing and I feel like in that sense um building a programming language where you don't truly understand your uses is uh it's fundamentally flawed and this is the mistake that a lot of uh

like compiler engineers make where they like all this programming language I mean I love hll but if I if I were to build a solity to be like hcll then there would be no blockchain there would be no smart contracts in the world So Sol made a lot of pragmatic choices in its design it's extremely simple you can talk to a lot of people here where they learned their first programming language was solidity course so I think that's where a lot of the success of solidity came from making it extremely simple um a lot of the security um issues that these languages so they don't really apply in blockchain like you know for example memory like memory is like Epal like after a transaction you throw it away so you don't really have to worry too much about uh memory management

issues which is a big thing in systems level languages um so a lot of the designed choices and solidity were made to like make it extremely simple to write code um it was purpose built for building smart contracts and as a matter of fact a lot of the bugs are not necessarily an issue with the language but rather you know bugs that you have when you write any software a classical example is um rounding issues yeah so if you look at the history of uh rounding in Computing you know Computing um you can look at many rocket launches that fail because of a bug in in rounding um

the same thing in uh smart contracts if you don't really pay attention to um rounding issues you can have a defa protocol hack um the the issue the bigger problem with uh the crypto is that it's such an adversarial environment where anyone can now come and interact with your software it's it's even worse than even I think Aerospace where I don't think like when there is a rocket launch people are trying to adversar attack it whereas if you are trying to launch a def protocol billions of dollars on the line people are going to be coming in and trying to find bugs in it unforgiving so I think the bugs the kind of bugs that are in solidity uh smart contracts that will always be there in like pretty much every language the kind of bugs that rust and other languages solve are

non-existent in blockchain like memory management issues I don't know a single bug in you know in a def5 protocol or some other protocol that is because of poor memory management um so to answer your question um the kind of box and solidity are really um logic issues and you have to be extremely careful when you're writing code you have to almost uh think about it as a writing um like mathematical code like you have to be very precise in your um building software and if you're coming from web to you have this philosophy of building fast and you know breaking things that doesn't really work in building smart contracts you have to be very methodical

about uh writing software you have to plan out very very well and if you want to get good at security I think the best way to is to understand like how previous hacks has happened um there are ways to level up your security skills if you are a engineer you can do things like competitions or boundaries it's it's a good way to like learn about uh security issues so I know that was a lot you know no no no thank you so if I were to summarize the reason why we're seeing all these hacks and solidity is not due to the language it is due to the popularity of the language exactly and I want to give Wolf Gang an opportunity to react to that because obviously move is meant to bringing a whole set of built-in protections for safer smart

contract development so would you have anything to respond to what Harry just said well I mean I by the way I I love solidity know I love I know solidity quite well because I also built a compiler from the move language into the evm oh yeah and as part of that I I was getting acquainted with solidity my criticism would be not actually on solidity but on the evm so like uh the target of solidity now and that influences a little bit back to the language the problem with the evm is that uh it's basically a low-level foman architecture with memory but even worse than that the control flow graph is obfuscated by by having basically indirect jumps over values on

the stack way to jump tuna it makes really hard to reason about I like you like a real computer scientist looked at it and was like H I don't know about this mean definitely I I I have a lot of appreciation for the yellow paper now so and it's a great piece of work and it started this industry but it was not written by a comp compiler specialist yes obviously so like so that's unfortunately uh like like a like a weight which solidity and evm has to carry which is hard to remove today know that would m i mean thank you I mean I agree like in in that sense where a lot of the solidity like quirks come from the evm um we have to be somewhat close to the evm we have to optimize the language so things are optimal in the

bite code so you have to make certain design choices that make sense if you understand the evm but may not be as intuitive and as a compiler designer you have this question where okay you can make the intuitive thing but it's going to be way more expensive or you make the the most optimal thing so this is it's like the hard design challenge where you know people want to optimize for gas people want things that are that are like you know efficient um and you have to make this trade-off of like do I make this intuitive and make it less efficient or do I make it very close to the evm and maybe add some quirks that makes sense uh I asked you how to upskill in terms of security had great answers contest there's a lot of resources now in solidity I want to ask

the same question to these two gentlemen if someone was to try to learn move and secure move development what would be the perhaps two resources that you would like to point them to uh how compar to Zana I'm sorry uh best resources to learn how to develop safely in move ah okay um so this is indeed always difficult if you have a new language you need to come up with the templates and the patterns uh to use it yeah and I I would not doubt that uh so basically solidity is more advanced here this point of time of course of course of course of course no because of all all the long because of the size of the market because of the long time it was there so we're working on it and we're

getting better but we have the advantage that we can create tools uh easier okay and uh those tools can can be based on on Modern ml techniques like llm or so but there can also be on synthesizing or analyzing the actual code and uh so yeah so like I I think in the long run I I would better move but who knows okay same question to you Dave if that's okay I mean we keep hearing that rust is hard right it's a hard it's a very steep learning curve do you have an advice for people watching or here in the audience who are willing to spend a bit of time to learn rust and hopefully learn it securely yeah so I

mean there's a there's a ton of really good resources out there about writing secure rust and like understanding it all I think the reason why people say rust is hard is because it looks like an alol family language and it isn't right you have curly braces you have parentheses all the things so you think oh it's JavaScript oh it's C++ it is not it is an ml-based language that looks like an algol language and so you have to think that it was originally designed to be a functional language which is why he was saying it's like a it's like an object objective like hasal and so you have to be willing to break your brain and you have to program it in the way that you uh realize that a

lot of your habits as a c or C++ programmer or even a JavaScript programmer or whatever don't necessarily apply all the things they told you you were supposed to do in computer science class in college like you need to make a smart pointer to manage your memory you need to do proper error handling all that stuff rust will 100% punish you until you do that um and so you just need to go back to the fundamentals of what you learned in in University and just accept that just embrace it because it really about forcing you to do proper things as a as a software engineer I know I sound like a rust Fanboy and I am but I'm going to be honest that rust has a very dark side that I don't think a

lot of us are talking about which is the compiler is amazing at telling you you suck as a programmer and so it forces you to be better but then we have this other tool cargo which for some reason didn't carry the same like paranoia that the compiler the rust compiler has into the cicd you know your dependency management all that kind of stuff like you would expect that cargo when you're updating a dependency would somehow be able to diff like do a Delta and say like this dependency from this minor version to this minor version 60% of the code changed like you should not trust this anymore right like want to upgrade yeah but it but it happily

will do that it's like oh who cares it's the new version it doesn't matter it's been completely Rewritten it's full of black hole you know back doors and all kinds of really terrible stuff and so what I'm getting out here is that we have this really amazing compiler that makes you a better engineer writes code that eliminates whole classes of security bugs and then we have this build management tool that it uses hashes maybe you know to track versions and stuff but there you would expect it to reflect all the best practices in dependency uh management uh software supply chain security auditing you know all the auditing things we do like what was changed in these two versions you

know was there anything related to memory management anything related to Secrets management anything related to cryptography anything like I just think Russ could be infinitely better on this front um instead of it just being yet another build tool you could leverage in theory the compiler's static analysis capability so that when you are updating a a library it is able to detect that there are you know cryptographic algorithms in here that are being modified there are you know basic types that are being modified like fixed size arrays have changed size right so all of the all of the uh type um assumptions that we have all through our code have

to be Revisited now because because this isn't 20 bytes it's now 24 bytes or something like that and I don't know I love rust to death but cargo needs some serious work thanks for the transparency yeah can I add something to like the earlier uh commend like I think to truly appreciate rust I mean I love rust but to truly appreciate rust you need to write C and you need to write C++ yes and only if only after writing you know CN C++ would you like really appreciate like R like if you were a new programmer and if you were to learn rust like like what the hell is a borrow Checker like it makes no sense yeah why would you do that right yes it makes no sense and then you you know but if you if you

write C that it makes a lot of sense and if you if you write like C++ it makes a lot of sense so the way the rust language was evolved and designed was to solve the limitations of CN C++ and you can only truly appreciate rust if you if you pain yes exactly you need to go through like a lot of segmentation Falls in in see you need to like be able to debug a lot of things I'm like what the hell is going on why why is my memory getting leagued and only then you would truly appreciate rust being repeatedly humiliated at Pondo can't disagree I want us to take a bit of time to talk about compiler bugs if that's okay um and how ideally how to prevent them uh not too long ago there's been a compiler

bug in the sway compiler which resulted in funds being stuck in a lending protocol sway land um compiler bugs can be really really challenging to detect um especially relying on traditional testing techniques um so I'm just opening it up here to see if you have any thoughts on how we as an industry could be doing better at detecting and hopefully preventing from arising in the first place these type of uh bugs H I think yeah go for it I can just say like we created just a new compiler and so we definitely thought deeply about this problem and uh we also were advised

by our security company a sec about it so you need to come up with uh a new testing approach now what we basically doing is comparion testing on all the transactions which were ever executed on our blockchain no so every single of those transactions will be running through the old compiler and the new compiler so that works if you create a new compiler if you create cre a new feature in an existing compiler which I think this uh I don't know whether that buck we're talking about was caused by that but that is indeed a different problem so there is really no no silver ballet a part of being extremely careful to roll the thing out that's what we

also doing by the way with the new compiler uh we have done it basically at already half a year ago but it's still not activated by default so you have to do it for long long time I remember when I was at Google when there was uh basically switching from GCC to uh to uh to this other C compiler architecture I forgot the L not L yeah cang right yeah uh that took them two years or three years no so that's what said took the time for Rolling or switching the entire company so it's just very difficult but and and and laborsome and takes long but it can be done okay you know rust exposure to compiler

bugs is like several layers right I to make it to to be able to say that it's legitimately a rust bug would be just a front-end bug right and they're very transparent about changes in the front end in fact I think for the last few years rust's front end has really just been about adding sugaring desugaring right like you know async a weight actually just dgar to it's just a short cut for like some pedantic rust underneath it um and so they're not really changing the language itself but we are exposed to lovm bugs right because that is the backend and you know I honestly as an engineer I don't I don't know that there's a way

you can that you can prevent them I think Google's approach to finding Chrome bugs could be really helpful here where they just like they have headless Chrome instances millions of them and they just load web pages and they look look at the memory footprint and you know the execution context and like you know do we ever have a poter jump out of you know seg faults page you know all this stuff right and so I don't know I think what we could do is Baseline a certain version of llvm like Wolf Gang was saying here is like once you have one that you fairly well trust because you fuzz the crap out of it that anytime there's a new update You' kind of make this managed

transition from an existing one to the new one you know you're compiling in both you're comparing the differences you're running all kinds of fuzzing operations on it yep I it's really tough I mean I don't remember what the guy's name is one of the Unix guys you know wrote that famous paper like how do you trust the trusters or what you know it's about it's about you know compiler bugs you could actually inject something in a compiler to put back doors into software so I don't know you just kind of have to fuzz them I think honestly yeah to gain some kind of trust you just have to throw all kinds of junk at them and see any yeah any thoughts I mean first of all like this is like my nightmare like

your nightmare yes yes yes like you know I I would you know ship a PR and if there is a mistake in it in in solidity there's like billions of dollars of okay um so it's a nightmare and we put a lot of work into securing solidity and you can see the results like there are zero Coen bugs in solidity that was discovered in in onchain so nobody has ever found a bug um that could be traced back to a compiler bug on the main net that is not the case for other languages there was a reeny bug in wiper recent ABI bug in sway nothing like that in the solidity history and we put a lot of work into engineering the compiler so like we want we wanted to have like zero

cin box um couple of things we do like first of all like the entire compiler is kind of simple and it's uh self-contained we don't really have too much external dependency uh we get a question a lot why don't we just use an lvm framework or something to um build the solidity programming language there are multiple issues there but one issue is that okay you're introducing an external dependency uh of of something that wasn't even designed for the evm so that by definition adds a lot of unnecessary complexity so we have avoided to we have avoided adding too many external dependency like we tightly control like the entire like code generation Pipeline and we kind of understand the entire entire stack we made the compiler quite simple um we

have purposefully designed a lot of things so it's easy to write it's easy to write the compiler um and lastly we do a lot of uh fussing and that's been quite effective so solidity has you know there are some advantages in how we build the language the first thing is we put a lot of assertions into the the codee generation pipeline the entire power planine has a lot of assertions and what we can do with this assertions is you can you can create random solidity programs you can you have the grammar you can use a fer to Generate random solidity programs and you can try to comile it and you can see if one of the assertions would fail and this is extremely successful in finding

bugs before it goes into production uh the other thing we do is solity has two different code generation pipelines and when you have two different code generation pipeline what what you could do is you can Generate random solidity uh programs you can compile it in two different pipelines and now you can send random call data into it and you can now compare if the state is different in two different um two different like code generation environments and this is also very successful in uh finding bugs before it gets into like prodection and we have discovered many bugs that would have gone into production this way we have also discovered bugs that we know in in in like in well in in actual compiler but it's very very hard to

trigger it like lot of the time with fuzzers they generate code that a human would never write yeah so fuzzing very useful you know building with the the mindset of like you know building a secure computer is very important making sure your dependencies are small so you understand what you're building is important the you know writing a lot of assertions and trying to like you would rather you would rather have solidity fail uh than generate Bad Bite code so so it is build with that mindset that makes sense bav has been doing tremendous work over the years with thean foundation on securing the compiler sh out yeah um I think can we take maybe one question one or two questions from the audience yeah you you go yeah uh I have a question actually I

really enjoy it because like as an application developer like for me it's really interesting to understand like the thought process behind like the development of compilers so one thing I felt over the years with solidity especially because I have been working with solidity since I don't know six seven years was like solidity 3.0 or something like that uh but recently I'm also starting to take a pick into move so that's pretty interesting as well one thing I felt over the years is kind of getting better on the solidity side is that uh I sometimes I felt kind of a disconnection between uh what the um compiler developers or even a lower

layer uh like the infrastructure uh developers have in mind and the actual needs of application developers and so many times I ended up like swearing and why the hell this thing is implemented this way I could have much more enjoyed one example the custom errors that were introduced yes I led them and I hate them because I hate the syntax but I love the idea so now it's better but back in the days like if using the custom errors would have forced me to rethink completely the uh structure of the error handling that I we had in our protocol and we ended up not using them even though I love the idea so how do we improve on this aspect how do we get

better in to make so that the experience for a developers is better because that's also helps in writing secure code I mean I I totally understand where you're coming from and so I personally believe there is an opportunity to make solidity 100 times better than it is today and people just need to work hard on doing it and I'm very you know I don't work at solity anymore I you know it really pains me to see like the slow pace of like how things are done um but there is a opportunity to make it 100 100 times better the customer is a great example uh because you know we we shipped this feature um it worked but certain other features did not work well you know when

it comes to customers like triats for example and triats is a great example of like a uh a language design that is optimized for the evm but it's not optimized for the developer and this is like the challenge that we have to do like there there are ways to implement the tri cats so that it's very like obvious to use for the individual developer but it's going to be much more much more like gas um INE it's very inefficient when it comes to like gas whereas the current implementation is like very tightly connected to the evm so this is you know I personally think we should have done the other way like you know optimiz for the developer but the team wanted to make it like to be very close to the evm so this is like

one challenge we have to always face you know like we have to make it intuitive but also optimal and very closely tied to the evm and the evm is also somewhat stagnant recently like right now we are making some improvements with the eoff but in the last you know three or four years there was no major changes in the evm that actually improved the compilers or or languages so that was also like one constraint we had as a compiler Engineers like the ethereum community was entirely focused on the merge which meant no other thing could be done um to improve the ecosystem so there was a massive backlog of uh evm changes eips that could not get in and all the

compilers had to just you know do with what we have makes sense yep at the back hi uh I have a number of questions but I think the most important one is for Wolf Gang I'm a fellow move developer and I I think one of the major criticisms within the ecosystem is multiple chains used move first it was DM now DM doesn't exist um now sui and move and I think another Cosmos based chain used move and there's major differences in these compilers and that's one of the major I've said major

three times but I but it's like how I think somebody who's in the senior um development of the move language on Aptos how would you address this criticism and is there any initiative to try to make the make these compilers agnostic and like be coll like kind of bring this ecosystem together yeah let me uh paraphrase I think you are wondering about the move dialects now right well I'm suan move on sui is different than move on so the different move versions so so to say first the first year uh of of the startups uh M labs and updos we actually close

synchronized the two language versions so or the you know that three already has a different po model from the very beginning which is completely based on objects and not on storage like uh like updos move is and also solidity is no anyway so like we tried to synchronize that but then we recognized in order to evolve those things and innovate in the space of languages it doesn't make sense to to always have a it's very difficult you know to agree on Lang language design uh things it's can take years until you agree and discuss a really long time and and whatever so we decided it might be better uh that we can evolve and innovate independently and maybe

synchronize ever now and then and we did for example for enam types which were recently introduced both in s and adaptas um but uh we also recognize that there are basically different approaches and in the hope that we eventually consolidate it uh but yeah so so I I totally get what you're saying it's just not practical for us uh in different companies to have uh to synchronize basically on every step no because we are still evolving the language the language is not done at this point of time yeah do they all have the same base do they all like work from the same bu base or they like entirely different

implementations the basically very similar in in in in or the same in in in core aspects no but but basically the model how the how the blockchain is programmed Inu is different than in upos or it was back at Libra and and d uh DM at uh uh at met uh so that choose more like a Zola model I think where you have basically uh you don't you cannot excess storage from a contract you have to declare up front what the inputs are and uh we found that model too restrictive and I I don't want to really uh talk bad about our colleagues or former colleagues so I don't want to we just

thought it's not the way how to do it now and that's where this Divergence basically started and from from this different program models there are different requirements which are coming to the language and uh that's what's happening I know yeah all right unfortunately we're out of time we could probably keep going um for another hour but thank you so much for our panelists give it up thank you please great Engineers thanks for sharing your insights um I'm sure they'll be looking around so if you have more questions around their languages their respective languages go grab them ask them questions um and yeah what what are we on to next