Do you think the future of Google is going to get impacted by the rise of chat GBT and Bing and it will eventually get replaced by them? What's your thought? And I think, you know, in many ways, Google is an AI first company and has been working on these things for a long time. So I'm sure they have a role to play. I think you'll also see lots of new companies, you know, open AI and others to, you know, enter this space. And I also think like there's going to be a ton of just unknowns and things that go wrong and, you know, automation run amok kind of thing. Hey guys, this is Dr. Nancy Lee, a direct product featured in Forbes that helped 100 people land their dream PM job offer in fan companies, a unicorn startup, and continue getting promoted as a product leader. In this channel, we talk about tech trends and free product management training. Like and subscribe and check out our new video every Tuesday. I'm very excited to have our guest today, Robert Latham. And it's such an honor to bring Rob on our show because Rob has a very amazing journey. He currently is a VP of product at Google and also part leader at Meta, also started two successful product in the past. And Rob, how are you doing? Welcome to the show. Yeah, thanks for having me doing really well. I've been enjoying some time, some vacation recently. And yeah, just really excited to share some thoughts with you and the audience here. Awesome. So Rob, let me ask you a quick question. Where are you based right now? I'm in Austin, Texas. So I lived in the Bay Area for quite a while and then actually moved to Boulder and moved back to the Bay Area, then moved to Austin at the end of 2019. So I've been here for a few years now. This is awesome. He actually moved before the booming pandemic. Just before, yes. And was traveling back and forth to the Bay Area and had, you know, a desk in, at Facebook at the time, had a desk in Menlo Parac, had a desk in Austin. I got all my stuff back from Austin, by the way, when I left the company. I'm still waiting for my stuff from Menlo Park, funnily enough. I see. Awesome. Given you had such amazing journey in different companies and also move across different places and making your own personal and career choice, do you want to give us a quick overview of your background? Sure. Yeah. Just going, going backwards, I've, you know, been in big tech companies the last six years, the last two years with Google working in the central privacy and security team. And then before that, I ran the product team for a group at Facebook, now Meta, called Business Integrity. So it was, you know, those are kind of my first big tech company roles the last six years. And then before that, I started two different companies. One was actually an ad blocking company. We sold the technology before I joined Facebook. And then before that, built one of the largest ads API partners to companies like Facebook and Twitter and LinkedIn. We started in display advertising, but then we pivoted to social media ads. We sold that business in 2013. For that, you know, it worked at a few different places. I worked at LinkedIn for a little while, which is interesting in the very early days when we had like 40 people at the company. Like you, I also grew up and moved to the U.S., grew up overseas and moved to the U.S., you know, went to college in the U.S., etc. So yeah, it's been, it's been a journey, but yeah, very, very glad to be here. Awesome. Another immigrant story. So let me ask you Rob, where are you original from? I grew up in South Africa. Wow, this is beautiful. It's always a place I want to visit. Actually, I have a student currently is in Nigeria and an answer in Kenya. It's like very global. It's amazing. Great to see lots of people just creating amazing career and cross cultures, cross companies as well. We're leading to our today's main topic regarding building trust in large and small and different sizes of organizations because we believe that culture differences and also even within the large organization that different people from very different perspective, the trust is actually very important for product managers to build. And actually I look up online, actually 55% of the business owners feel like having trust is one of the most important core value of the success of their company. And it's crazy. And also from product management perspective, we are also building trust among different stakeholders. And therefore today I want to hear from your perspective regarding you have been working in like 40 people LinkedIn team when they started and also all the way to manage your own large organization in Google and matter as a VP of product. Can you share with us regarding why trust is so important in all sizes of companies from product perspective? Yeah, absolutely. But I think the product manager has a pretty unique role and it's kind of like, you know, there's lots of different takes on how to be a good product manager and what it actually means. And but often you're kind of someone on my team once described it as you're the glue that's holding a lot of things together.  But it's something that kind of needs to bind things together and in itself, you know, people need to trust that you can help facilitate things. I think also that's like not really the case. And we can talk more about why I don't think that's the case. But I think there's also a lot of misperception about the role of product management. I think there's a lot of people who actually, I actually used to see this when people would want to transfer to become a product manager from another discipline. Often their understanding of what a PM does was different than the reality. And I think once they learn the reality, some of them are like, no, I actually don't want to do that job. I don't want to be meetings all day. So I think trust is really important because, you know, like a lot of other things as well, the product managers facilitating a lot of things. And so to be a good facilitator, I think you need to be someone that is trustworthy and someone that can, you know, help bring people together. Awesome. So Rob, I do want to dive deeper a little bit regarding the CEO product. You think you have a different opinion regarding the CEO product. So what's in reality? What product manager is doing? If we are not the CEO, are we the COO or CMO? So tell us more. Well, I've been a CEO and a COO and, you know, I've had some of these jobs. But I think the, you know, I think of one of the things I think of a product manager is doing is, you know, being responsive. This is again, these are not my words, but, you know, learning from others originally. So, you know, product managers is responsible for high quality of decisions that are made about the product, right? So, you know, I think it's in some cases, depending on the size of the team and the situation, you know, you're making some decisions or the way in which you're framing already is directing things a certain way.  I think the PM sometimes has that role, but really a lot more. It's like helping within the structure of whatever that organization, facilitating decision making and making sure those decisions are of high quality. Love it. When you emphasize on the facilitating part, I think at the lead to the challenges we're talking about regarding building trust, can you tell us why it's so challenging and crucial? We talked about crucial is important. Why is so hard to actually building trust and facilitate and bring everyone on the same page as a product manager? Yeah, I think a lot of times people are coming from different perspectives and different history with PMs. You know, I think it was Lenny Richesky recently was saying something about, you know, some people have experiences of PMs that aren't good PMs. And so, you know, you may have different, everyone's coming from a different background for perspective. Some people have been in organizations where there is no PM function. So, you know, you have to kind of meet people where they're at. The other thing I've also seen is, for example, with a lot of, you know, smaller organizations, you have engineering managers taking on that role of essentially some of the things that a PM would do, you know, and there hasn't been a PM function, you're creating one. And then, you know, some of the things, those things are things that an engineering manager wants to continue to do what they enjoy doing. So, you also, depending on where your organization is, you're actually, like, growing into certain things and you're defining roles and creating clarity. And so, you know, you need to get to know and spend time on the relationships in order to be able to facilitate the creation of that clarity in order to be able to also create swim lanes for people so they're not running into each other. You know, one of the things I find actually very useful in this is also to, you know, create leadership groups where it's multiple different functions that are sitting at the same table. So, you know, because it can sometimes feel like PM is telling other functions what to do. And in some cases, it's kind of true, but the reality is that it's much more, it's much better if it's a collaborative atmosphere and people are sitting at the same table. They're bringing different perspectives, you know, and they're kind of working together in that way. This is awesome. So, Rob, can you give up something juicy, which is a Google or META, you can pick any of the large companies from their perspective. What's in real life, the challenges you guys facing using that real life example, you can remove anything confidential. We just want to see from like leading tech perspective, right? Because I would imagine there's so many different teams in Google and it sounds easy to bring people on the same table, but when you actually execute it, you will face real life challenges. Can you give us some insider secret regarding like using Google or META as an example? What does it look like to work with others and you kind of push back you had when you implement the building trust strategies? Yeah, for sure. I mean, I think building trust, it's not just within the phone, your problem directly. It's also when in any of these companies, when you're trying to solve a problem, you're in some cases, you create other problems or you learn that there's other confounding issues. So I spent a lot of time working in the integrity or trust and safety space at META specifically. And so there, there's always these concerns where you're like, okay, we're going to, you know, implement this policy change that's going to, that's meant to stop this particular thing what we think is bad. But obviously the detection of things is not perfect and you kind of have these concentric circles of, you know, other folks who are impacted. So what ends up happening is it's customers getting impacted, but it's also other teams getting impacted. So they may not be able to ship something, you know, they have to work with partners to implement new, you know, new things that again create like these, these other effects. I think there's always these tradeoffs that you have to help manage across different teams. So it's not just across functions working on your thing, that's one aspect of this kind of cross functional leadership and value that you're helping to create. But it's also across different teams who are seeing different sides of the same, the same thing. So I think one of the things we like to do, I know it, for example, at META, one of the things we would try to do is, you know, gain alignment, for example, through sharing metrics. So we'd say, okay, this team is going to ship this thing. And we want to set up some guardrail. So let's make sure that this particular metric that we agree on, it doesn't go outside of this range. If it does, then let's have a discussion, etc. So a lot of times that those things were pretty, you know, manual hands-on, like, okay, we're like looking at the data every day, and we're having reviews and whatever, or every, every month, we might have a review about it. But then, you know, as you kind of instrument those things in your product, you can actually make it more automated. So it's just really like, not really a problem until, you know, you get some notifications like, okay, the, you know, this particular rate is dropping below this threshold. Let's, you know, go and have a discussion about it. So I think, you know, one thing is like different teams and different functions of different incentives. And so acknowledging that coming up with things that cut across those and perhaps allow you to align those incentives, metrics being one way of potentially doing that, turn out to be pretty useful. Because then also it takes some of the, it takes some of that personal adversarial nature of it away because it says, look, we've agreed in advance on this metric. So metric goes south, we'll talk about it.  Exactly. So no wonder. So like all the big tech companies and more tours, we are a data-driven company. And even for people currently interviewing with Meta, or when they were hiring interviewing with Meta, they asked lots of like prime metrics questions. So basically, you guys are using metric drive. The alignment was in different teams. Rob, I do have something real life challenge. Maybe you can help me out and regarding building trust in the remote environment, we frequently find out those kinds of trust is harder when it's in a remote environment. When we are in person, it's easy to have some coffee. I think it's, it's more easier to build as a human dynamic. Nowadays is remote. Do you have specific strategies to build trust and alignment in a remote environment in both like larger companies and small companies? Yeah. So many, many years ago, more than a decade ago, we had this thing where we had a bunch of, so my company was like 40 people and we had a bunch of people who were remote in Chicago and New York and other places. So we were mainly in the Bay Area. What I did is I said, okay, for this whole hands, we're all going to dial in from our computers. This was way before COVID and everyone was used to like, you know, zoom and things like that.  And so because it's the dynamics will be different. So we, we did that one time. It was like, people were like, okay, this is kind of weird. But I do think you need to kind of think about ways in which to put people on an equal footing in these remote settings, you know, you know, a couple of things I've done with various teams is like move things around or have like a, you know, again, depending where your teams are, if they're in Europe and if you have teams in Europe and Asia, like it's pretty challenging to get something that works for everyone. So alternating different times for things, you know, recording meetings, things like that. So people can kind of catch up on their own schedule. Those are all like useful things, sometimes not obvious, but useful things for remote work. Having something that a team can own more fully if they're in a remote location is useful. So that way they don't have these and like high coordination costs and, you know, very expensive kind of cross time zone bandwidth stuff. What do you mean, have people like high cross footing? Can you elaborate more? So, yeah, so like as an example, if, you know, let's say that I have a product and I have a team in London and I have a team in the Bay Area and they have to talk, they have to like talk about different specs like several times a day, like there's only so much of a window where that's easy. However, if it's something where they can go away for like two weeks and do a sprint and you know, then come back and then, you know, they don't have to like align and chat necessarily every single day. Like I think they can more fully own a particular feature or something like that. That's helpful. To your point, I don't think there's really any way to get around. You just have to meet people in person from time to time. So, you know, very targeted summits where you're talking about something for a few days can be very useful. You know, there is a downside of some of this stuff which is like I've also instances where people aren't super sensitive to the time of year. Like again, like also it's not just about in your area, like if say you're coordinating with people in Europe and they tend to take vacation, you know, at a certain time of the year. A lot of vacations, yeah. Yeah, but you have to just be sensitive to those things because you're then going to actually, you know, in trying to make things better, you're going to make things worse because people will say, oh, well, they're out of touch with the way things are done over here, et cetera. You know, I think even just, you know, we've seen more and more people being somewhat local to each other or like within a few hours of each other, maybe even in the same time zone of being remote. I mean, that's also, you still need to spend time getting to know each other in person in those settings too. So I think that's really important. And then I think just, you know, always listening and creating opportunities for feedback. We create these opportunities to try to listen to feedback, but I think sometimes, you know, we can do even more than that to hear what people are saying and to, you know, meet them, like I said, meet them where they're at. I love that. Hey, Rob, I do want to discuss in depth regarding the feedback systems. So currently I know for like different conflicts on Amazon has 360 feedback. I heard it's very stressful. You have people under you, like everybody needs to like you or you're in danger. Or in other big tech companies, they have like annual performance review. How the feedback system can be implemented within your team and also cross, like cross functionally. I personally believe that if we implement cross functionally, you didn't know how to say it better because their interests are not aligned for some cases. So can you, can you shine some lights on that? Yeah. So I think, I think the, the P zero on, on feedback, I think is people need to see that you take action on feedback. So I think the quality of feedback goes up the more, in my opinion, in my experience, the more people see that it actually makes a difference. And it's not just, Oh, we heard your feedback about X, but like if X is never going to change, that's, you know, not great. So I think that's, that's the main thing to start with, but you have to kind of ask the question lots of different ways. You can't also just assume, Hey, I did the survey once or twice a year. And now, you know, this is the full set of feedback. There's always stuff that isn't set. I generally think you have to facilitate mechanisms for this. People are going to talk and going to say stuff regardless. And so I think you just need to give them ways to do it in such a way that you're at least aware of these things. But again, I come back to what I said before is like, you need to figure out how you can make the experience for people better.  And again, to the thing you said earlier at the top, which was, you know, give them the ability to have balance in their lives so that they actually are excited to do the work that they're, that they're working on. Exactly. So specifically, how would you filter the feedback that's not constructive? For example, in our last episode, I talked to the senior director of product growth at Stash and Maria. So Maria mentioned something very interesting. She said she, she's open to feedback, but sometimes the feedback is hard to implement or she doesn't know how exactly to change it. Because one of the feedback she received is that you're too straightforward, Maria. You say, whatever you say, say it to others' face. That's too straightforward. Or sometimes we'll be like, Hey, Maria, your sentence structure too long. So she, she came from Latin America. So the way Spanish, the words, construction, it's just longer than English. So she just felt like it's me speaking directly is my personality. How do I actually change who I am? So there's like balance out there. So what do you think? And regarding implementing those feedback and some feedback may not be as constructed as you wish. Yeah. I mean, I think sometimes it's not right. So somebody, you just have to kind of take some of that into into account. One of the things I found useful is like, sometimes you need help from folks to gather feedback about things you could do better.  And like, she was able to get some insights that I wouldn't have gotten if I try to ask them directly. And then I was able to act on those things.  And so not all feedback is needs to be acted on. I think that's the other thing to take into account is like, sometimes people are upset or, you know, they have had certain experiences or so on, you need to kind of take everything with and sometimes it's really good to like bounce the feedback off of other people. So I find a peer have a mentor be like, look, I heard this thing. I feel like this is valid. I feel like this, I'm not so sure about this. What do you think? And then also, sometimes playing the feedback back to people, other people gives them permission to give you the feedback as well. So you'll learn some new things. So I think feedback is something you use as a tool, and you kind of then also like anything, I think it's content that you can use in different ways. And again, obviously not necessarily like saying, hey, John said this thing about me because maybe it's inappropriate to say who said it. But I said, you could go back to someone and say, I heard this thing from a couple of people on my team. Do you think, how do you think I could address this? What have you done? Have you seen examples, especially if it's a mentor or someone you trust, who's going to be very, you know, open and frank with you? I think that's also great. You can use the feedback in a few different ways. Yeah, exactly. I love this. One last question to you, Rob regarding feedback, you mentioned earlier that some company do it like annually or quarterly, whatever. What do you think is the best way to open the door and the free in terms of the frequency to receive feedback? How often do that? Yeah, I think it depends like what situation you are to the point you made earlier, which is like sometimes people who are new to a team are more willing and open to give feedback. I had one person on my team who gave who did like a 100 day report of how things were going. It was really useful. There's some really useful insights. I think it really depends on kind of where the team and where you're at. At one point, I did a thing where so, you know, a lot of these companies like Facebook, Google and others have pulse kind of things that they do. It's like an annual by annual survey that they do across the company. And so actually, I, you know, I was, we were growing very quickly, my team at Facebook meta. And I felt like there were some things that were going well, some things weren't. So I actually created like a mini monthly, like pulse survey that I just sent out anonymous. I asked people to comment anonymously or not. And you know, that was actually really useful, but I had a short life though, because we kind of moved through those issues. It didn't feel like we needed to keep doing that. Sometimes it'll feel burdensome. We've all been in these situations where we're like, keep getting asked to give feedback and it gets like a bit much and then it kind of annoys you. So you kind of got to calibrate it carefully. And sometimes when things are, you know, in a, in a more nascent or uncertain state, you may want more feedback, but you also may choose to ask for the feedback differently or, you know, may ask for it incidentally. So it doesn't seem like, you know, you're overly worried about stuff that again, this is like, again, like we said, tricky. But I think you're going to have to look at it as, you know, different times and places for different ways of gathering information about what's going well and what's not working. Yeah. Yeah. Exactly. I think this is is like true definition of leaders understanding how to fix problem actually on your mistakes as well. And I bet you have gone through a lot of this when you run startups and bigger companies as well. So Rob, let's ask more strategic pro strategy question. And we talk about people like feedback and trust and organizing different teams. Now, as we all know, the tech industry has been interrupted by AI. Do you think, and also like being is the number one most recent download search engine recently because chat GBT integration, different things. Do you think the future of Google is going to get impacted by the rise of chat GBT and being and it will eventually get replaced by them? What's your thought? Yeah, look, I think, I think everyone is going to Google included as to take, you have to pay attention to the stuff. And I think, you know, in many ways, Google is an AI first company and has been working on these things for a long time. So I'm sure they have a role to play, you know, in this. I think you'll also see lots of new companies, you know, open AI and others to, you know, enter this space and to figure out how to make this stuff work. I think there's also, I mean, if you've seen the chat GBT plugins, I think there's also a role for other companies to play where they're bringing new integrations, ways to use information. I also think like there's going to be a ton of just unknowns and things that go wrong and, you know, automation run amok kind of thing. You know, like, I know you can use the chat GBT plugin, for example, to like queue up emails. And, you know, I just saw a funny cartoon yesterday, I tweeted it yesterday, what was like, you know, where someone was like, Oh, I can just take this one, you know, this one bullet and turn it into a whole email. Thanks to AI and the other person was well, I can take this whole email and condense it to one bullet point so that I can print pretend like I read it. So I think you're going to see some really interesting overlaps in how this stuff works and how people use it. But ultimately, I think these things are tools. They're going to have a lot of disruption in certain areas, certain parts of certain industries and certain parts of the business. You know, I still think there's a lot of things where you will not be able to condense the answer down to like, you know, a nice paragraph or two of text, you're going to have to search and iterate and go through and look at stuff and take multiple sources into account. So, you know, I assume that these companies will figure out ways to create different experiences around these tools, whether that's a different new search experience or, you know, different ways of interacting with other tools like email or other things. Yeah, exactly. So do you think the trend of the industry in the AI space is going to be like similar to the original booming of Web3? So all like there's a foundation of like Ethereum network and there's so many different kind of like chance people building on top of Ethereum. And now this like downside of downturn of the Web3 industry was because people realized that not all the protocols are very necessary. And do you think this will be similar trend to the AI space right now? We're on the rise, people building different apps on top of AI. Do you think eventually we'll settle down using only one best model? Could be chat GBT or different things? Oh, by the way, Google has its own bar. You have like AI thing for bar. Do you think eventually we'll settle down on one best model that will just synchronize the whole world as a foundation? And then you build small things on top of that? Or there will be several like bars, chat GBT and AI engine, different things running in parallel. So what's your prediction of the industry? Yeah, I'm sure I think there'll be there'll be a few like I don't think there's gonna be thousands. There'll be like lots of like sub models and enhancements and plugins and things on all of these.   I've been playing around a lot, especially with chat GBT and it's really interesting and you know, it's gotten a lot better even just the last few months. And so I'm sure we're going to see a ton of stuff happen here. You know, I had a lot of experience, as I mentioned before, working as an API partner with some of these big companies, right? So if I put that lens on things, I think the hard thing here is figuring out how to, you know, build a successful scale that business on top of someone else's models and tech technology. So I think you're gonna have to look at things like, well, do we have like unique training data that we have a version that builds on top of the stuff and this data is proprietary and whatever, that's going to be very rare. But I think there'll be those cases. I think there's going to be, you know, people who monetize stuff in a very special way. There's going to be people and companies who are able to bring things into real world applications that, you know, require bits and atoms to work together. So I think there's going to be like interesting stuff we can't even really conceive of yet. But I do think there is this question of, you know, are you just an API partner of one of these models in one of these companies?  And, you know, frankly, like, this is difficult. Like a lot of companies in the space I was in and it kind of adds API business, you know, they try it and we're not able to build their own, you know, long term sustainable business on top of someone else's stuff. So I think it will be challenging. Perfect. So Rob, one of the most asked questions today is how can people become an AI product manager? So what's your advice to them? Because it's so hot right now. So what's your advice? Yeah, that's a good question.  So I think, you know, working on some of those kinds of basics and things that are like, you know, I like, in general, I like the, I guess I would say I like the unsexy side of sexy technology. So specific example, you know, we were competing for PhDs in ML and AI related disciplines.  And so I think, again, like if you're, you know, if you're thinking about some of that stuff, I'd say look at some of the things, maybe the unsexy side or the fundamentals of the baseline, the basics and learn those. That's always a good thing to, you know, to, you know, that's one way to kind of get up to speed on something in a way that maybe isn't as might be harder, less hard to get into than if you're trying to go work at the hottest new startup that's doing some of the stuff. Again, you should try that too. But the reality is a lot of these fundamentals, I think will stand people in good stead if they learn them and they understand them deeply. Exactly. All come from the foundations and fundamentals. And then you can move on to be the larger tech, smaller tech and totally up to your career choice. So one last question to you, Rob, is that what's your opinion regarding investing like gross mindset investing in themselves? And I think it's kind of new concept. Lots of people think about investing in stock market or buying some Bitcoin, different things. What's your opinion regarding investing in themselves and having a gross mindset? Do you think it's a foundation most important thing compared with investing in stock market and real estate? So what's your opinion on that? Yeah, I think it's really important. I mean, I think, you know, someone said to me recently that they don't have time for like networking and meeting other people outside of the core role. I'm like, you know, you kind of need to do that. Like you need to find, you know, mentors outside of your work or people that you trust that you can bounce things off of. I think you need to be taking courses.  I think if we take going back to AI questions, like if you're really great at writing emails, and that's like your core superpower, I'm like, I'm sorry, but you're going to have to develop some other skills. And again, I've worked with some of the best email writers, I think on the planet, like some PMs are really great at communicating. I think that will still be a valuable skill. However, like it can't be the only thing. I think there's like definitely this, you know, folks get comfortable with the things that they're good at. I think you need to get out of your comfort zone and learn new skills. And you need to talk to get out of your comfort zone. Also, we're talking to people that maybe, you know, you wouldn't talk to otherwise and learn things from them as well. So I think it's really going to be key to have a growth mindset. This is amazing, Rob. Thank you so much for sharing with us. All like golden neck and everything you just shared with us. So if the audience have follow up questions, where would they find you? My DMs are open on LinkedIn and on Twitter so people can hit me up on either of those spots and always happy to help make connections to other folks as well who can maybe be helpful. So yeah, feel free to hit me up on either of those platforms. This is awesome. So we're going to link Rob's Twitter in the description of the show. No, it's very popular. He's like posting amazing stuff on Twitter. So and like, subscribe and comment on our show so that I can bring more amazing speakers on our product insider podcast. Awesome. Thank you for joining us, Rob. And thank you for everyone who joined us and submitting all your questions through the back end. This is amazing. Awesome. Thank you guys. See you Rob. And thanks. Thank you for joining us.


Alors, bonjour tout le monde. Donc c'est un short update sur G1. G1 stands pour Green 1. Ne me demandez pas pourquoi. Accepte que ce might... Sorry, sorry, sorry. Ah, il y a des latencies. Il y a des... C'est Green, parce que sur cette figure, qui est la mère de toutes les figures, c'est-à-dire, c'est Green. Et ce que nous sommes intéressés dans ici est l'exécution. Et donc, il y a peut-être deux choses dans cette partie, peut-être plus de choses. L'une est de avoir une exécution parallèle d'acteurs. C'est une chose. Et l'autre chose que Marco m'a mentionnée d'aujourd'hui, c'est des computations arbitraires sur l'IPFS. Le baccalao ou le projet de code, selon le nom que vous voulez donner. Donc, nous avons deux milestones dans cette partie de Green. Milestone 1, c'était le 15 janvier. C'est une review de la technologie de parallélisation pour les machines virtuelles pour les modèles d'exécution. Et un second milestone de mid-June à mid-July, qui est en train d'utiliser l'architecture pour ces systèmes Avant de continuer, nous allons dire que la parallélisation des modèles d'exécution des modèles d'exécution de smart contract. Pourquoi ? Parce que les modèles d'exécution n'ont pas été utilisés mais pas dans le contexte du contract smart. Si vous êtes en train d'exécuter les modèles d'exécution des modèles d'exécution de smart contract. Mais tu fais partie du propositions pour les modèles de standard autour de la parallélisation ? Non, je ne vais pas interpréter Vous devrez voir ce que j'allais dire Mais je ne vais pas interpréter la design de Wazem Vm Je vais toujours interpréter Au niveau av elevé Non, non. Mais j'ai joué un peu avec Wazem pour comprendre comment est-ce Il y a des choses Il y a quelque chose, oui, close to pithreads and so on, that I use that and actually it works. But it's not, from what I understood, it's not in the core wasm specification. It's something that sits just, I mean next to the specification, that can be integrated within wasm vm and so on. But at the time I looked at wasm vm, the choice had not yet been made by the field team and they were considering different wasm engines. One was wasmer, the other one was EVM or he wasm, he wasm. There were a third one I don't remember, which one? So the choice of wasm is because I think wasm is standard that will be widely deployed. It's kind of, let's say, higher level language that they want to rely on and then they will compile this higher level language into actors and they might also compile other languages into wasm, like vm to wasm, EVM to wasm, I mean solidity to wasm and so on. I think it's because it's popular, portability, it's popular. That's great, but this is what we want to escape, actually. One of the difficulties we have so far is that in part of what we are doing, the engineering team is defining the next architecture. The architecture is not defining it now, it might be. But at the time we started thinking about that, there were several designs that were possible, like multiple wasm vm, so a single wasm vm, that would be parallelized and so on. And this was not fixed yet. But this is something we will work on. This will be part of the second milestone. Now we will know what they do in a vm, so far it's going in vm. We will use their design and we will base our work on their design. But so far there is nothing related to wasm that I will discuss. So what do we want to do, actually? So we want to parallelize smart contract execution. So let's assume that you have a block, you have two transactions and they are linked within the block. As you were saying, what is very convenient is to have this deterministic execution and sequential execution. One at a time, this is actually what most blockchains provide today. So transaction one will be executed before transaction two. So if they perform actions on a smart contract, like set x to three, set x to 20, the miners and the validators will do exactly the same operations in the same order and we are fine. We will get a consistent state. We know the story, you recall yesterday what was total of the broadcast, consensus, blockchain and so on. So this is all in this slide. And actually what we would like to have is this parallel execution, so meaning that the miners and validators might be using several threads at the same time and perform the executed transaction actions in any order, not arbitrary order, but in parallel. The problem, obviously, you know what it is. The set three and set 20, they might commute and then the challenge will be, what's the expected benefit? We will improve the blockchain support. Obviously, the latency, I'm not that clear about whether we improve it or not. I wouldn't be in that. How leveraging the multiple available cores on miners and validators. But the challenge is how do we ensure the consistency of the blockchain despite this parallel execution. So there are not so many papers discussing this. These are a few. There are some more, but I listed the more important ones. They are here ordered by date, not by the conference. This one has no conference because also it's a very interesting paper by early. From what I saw, it just appeared as a DAX tool report so far. There is a core report, a DAX tool report, but it's not published. It's not really published. DAX tool is not this. It's not this. Because this publishes the DAX tool report. It might be. It might be. It might be the case. So I will quickly... So the goal of my presentation is to tell you quickly what these papers propose considering the ideas a bit more than this list. We have the following research ideas that have been produced so far. Speculative concurrent execution using STM-like techniques. This is one area of work. Then there is another area of work leveraging static analysis to a priori detect conflict. So it's no longer a speculative. You will execute something that you know will produce something consistent. Then there is what I call multi-future prediction. This is this last paper that appeared at SOSP. Just this year. Foreigner paper. Very complexe. Very interesting system. But probably over-engineered a bit, I would say. As many SOSP papers. And I'm not saying that because I don't have one. Just because I have something in the case. And then there are papers discussing off-chain executions which I don't list here because this is a different model. Basically they would say, okay let's assume that smart contracts will be executed somewhere else because the blockchain is just here to manage their execution at a high level but they are not really part of the blockchain. So I don't cover them. If we want to follow that path then they might be of interest. Yes, yes. You could stone some sub-chains with the goal to... Basically what they... Basically what they would do, this system is a typical thing, is they would use the blockchain to kind of agree on, let's execute this contract, let's maybe agree on the output. But you know the main blockchain will be used to perform this agreement. Okay, we agree that the output of this smart contract is that one, rather than really executing the smart contract within the blockchain and having the smart contract if I update the state of the blockchain. Basically they will distinguish, they will separate agreement and execution as was done 20 years ago in the consensus world they would kind of apply this high level idea to smart contracts. Yes. So I will go back to each one very quickly but just to present you these ideas. So speculative concurrent execution using STMs, so the operating principle, so there are several papers, but the operating principle, if you read this POTC paper, you will get it. So it's fairly straightforward. So miners will execute transactions concurrently and they will use STM techniques to detect conflicts between transactions at runtime. I assume you're familiar with STMs. If you're not, I mean the STM techniques allow pinpointing the memory addresses that are accessed either in read or write modes. And so at runtime you're able, when you have an STM runtime you're able to say this memory address has been accessed by a set of transactions, more than one transaction and at least one was of write. These are reads, obviously. This is not an issue. So this is something that, I mean, those of you who made a TPFL in distributed programming, know a lot. Rashid was working a lot on this topic during years. And so what does happen to transactions that access the same portion of memory? So these transactions, they fail and they are rolled back.  The thing is that once this has been done, I recall that this execution should be then reproduced by validators. So this means that you cannot then say validators also have an STM-like runtime and they will execute the transactions because they need to end up with the same state than the miners. So this means that miners, once they have executed speculatively the transactions using this STM-like runtime, they will generate a serializable concurrent schedule. Okay? They will produce a schedule that they will embed in the block. They tell you how you should do it, exactly. And they embed this in the block, which is part of the discussion of people saying this cannot be integrated for instance, within Ethereum without doing a fork of the blockchain because the blockchain currently is not designed, is not architecture to get this... Yes. So I do not want to enter within the debate Ethereum or not. But yes, so they generate a schedule. And this this is the kind of happens before graph. You understand why? Okay? This transaction should happen before that one that should happen before that one and so on and so on. Again, so happens before in the lamport relationship that we know. And so the validators, they will execute the transactions according to this graph. And the thing is, so block is accepted by validators if the miners propose the correct happens before graph, so no data conflicts during the replay. So they are replaying and they observe I mean, the transactions that are executed in parallel do not access the same part of the memory. And there are no differences between the proposed final state and the obtained state. And they perform a evaluation within this paper but using a Java prototype. Why? Because obviously you don't have Ethereum virtual machine supporting STM-like runtime and so on. So they basically emulate to see the throughput gain they might observe. Just a question here, how big is that graph and how how is it I mean, it is it's a granularity of a block. The transactions that are within a block should be represented as a graph. Yes, yes, I would say yes. I would need to be this would need to be checked because you might have this at the granularity of operations within transactions but that would be useful so I assume it's at the granularity of the transaction. We would need to confirm that. So can you verify that the graph is correct? Because like so you don't verify it's just that when you execute it if you don't access the same portion of the memory this means that there is no problem. Front running transaction right? If by there's a conflict in some address I can like sweep sweep the graph so that the one that I'm interested in yes executes in that memory before and I take out that yes so are they addressing that at all? I mean that the minor so the minor they execute okay they they build the graph okay and they build the graph so that graph should yield then an execution by validators during which validators will not create this weird thing where to transaction access the same portion of the state Front running is still there because like I assume that the validator will actually test whether he will first they check and they need to obtain the same state the same final state which they know it's up to the minor how they resolve the conflict so the validator will think that there's no conflict yes but the minor can have the quality they want to resolve the conflict which means that I can do the graph that I don't know benefit to the users but anyway ah yes yes yes my idea is that I can show the execution you can just walk yes yes yes yes the minor decide what the graph will be okay but yes they don't address Front running no no no they don't address Front running the question they just address conflicts and you're perfectly right相er m can can jean car car car car car car car car car car car Et maintenant vous avez le public qui a traité le dîner. Oui, mais c'est une série de choses. Vous avez peut-être un graphiste, mais comme le graphiste, il s'agit d'une seule. Oui. C'est une série de choses. Le problème est que, en fait, ceci est maintenant sur le contraint de l'ordering, qui fait le travail de l'ordre plus facile. Mais si on a retiré tout ce qu'on veut, et qu'on ne veut vraiment poursuivre le contraint, on n'aurait pas besoin d'ordre, car l'ordre n'aurait pas besoin. Le travail de l'ordre est de décider sur ce qu'on veut. Oui. Juste pour que vous sachiez qu'il y a un autre papier en déclinant cette stratégie STM-based pour l'existence de smart contracts. Pierre Latillot, micro PDP 2018-2019, qui n'est pas une conférence de précision, mais de toute façon. La principale différence est la suivante. Les minors ne sont plus en train d'utiliser, en déclinant des loches. Ok, donc c'est plus optimiste la spéculation des minors. Les transactions de failles ne sont pas de rollback, mais sont retraitées dans un loop jusqu'à ce qu'ils arrivent. Donc, il n'y a pas besoin pour les rollbacks de l'Universlog, qui sont utilisés dans l'autre approche. Et les points avant le graphisme sont répliqués par ce qu'on appelle un graphiste bloc. Et par les validateurs, les frais, qui sont appelés les travailleurs, ils extractent des transactions par ce graphiste bloc, et ils déclinent que ce que l'on appelle l'ordre topologique, c'est qu'ils ont un graphiste. Comme vous l'avez dit, j'ai cette architecture où j'ai un pool de frais qui choisiront les événements pour être exécutés. Ils choisiront les transactions et ils vont juste faire sure d'utiliser le graphisme pour qu'ils renforcent l'ordre que le graphiste est encodé. Mais c'est très similaire, les mêmes idées et vous pourriez avoir les mêmes performances. Ok, c'est une partie de l'exécution spéculative par les validateurs et les validateurs reproduisent ce qu'ils ont fait et les libèrent. Il y a des différences margénales en ce moment. Pourquoi est-ce que ce n'est pas une solution ? Ça pourrait être une solution. Ça pourrait être. Je vais aller à la fin de mes conclusions. Pourquoi pas ? Alors, ce n'est pas une solution. Les libérations ététiques analysent ceci pour détecter les transactions. Le principe d'opérations, si vous voulez le savoir, c'est d'utiliser le papier. Donc, l'idée est d'utiliser les conflits statiques pour détecter les conflits entre les transactions. Parce que vous n'êtes pas sûrs que ce sera un conflit qui est un conflit actuel. Et vous générez l'exécution spéculative. Donc, nous ne sommes plus spéculatives. Nous analysons le code et vous générez l'exécution spéculative. Vous avez bien repris votre question précédente. Vous avez les transactions. Vous avez le read et le set de toutes les transactions. Nous voyons que Tx1 et Tx2 devraient préciser Tx3 parce qu'ils l'ont regardé par X et Y. Et Tx4 devraient être Tx5. Mais il n'y a pas de relation entre les autres. Et les validateurs et les minors peuvent utiliser ça pour exécuter les transactions pendant qu'il y a un état consistant. Le problème de la solution est que le code statique n'est pas un expert. Vous ne me demandez pas. Quand je dis que c'est pas efficace ça ne fonctionne pas sur les langues. Vous pouvez retirer les conflits qui sont compliqués plus que les références qui sont les cas de solidité. Pourquoi ? Parce que vous avez ces trucs qui sont dans votre code, dans votre transaction. Vous ne savez pas si vous avez un conflit de mémoire entre les transactions. Et c'est-à-dire que la solidité ne peut pas être ététiquement analysée. Donc, ce que je dis, ce n'est pas une solution. Et ce n'est pas une solution mais un remarque. Si vous utilisez Solana et la partie C il utilise un genre ététiquement analysée comment ça fonctionne. Donc, les transactions spécifient une structure d'instruction. C'est le nom qu'ils utilisent. Chaque instruction contient le programme et la liste des accounts que les transactions veulent lire ou rire. Ils disent que c'est comme un système opérant des APIs où vous pouvez parfois spécifier que c'est exactement ce qu'ils font. Ils travaillent sur la granularité des accounts et vous devez spécifier les accounts qui vont être accessés par chaque transaction. Et cela permet d'étudier les transactions non overlapées en parallèle. Cela permet aussi d'optimisation de l'exécution d'utiliser des processus particuliers des processus SIEM et d'expliquer comment ils peuvent livrer cette information pour avoir une meilleure performance. Donc, c'est un design stromande. Mais pourquoi pas ? Si vous voulez payer le prix de la question de l'application de l'application de l'application, vous pouvez mettre plus en parallèle. Vous avez besoin d'un langage qui permet votre langage d'être designé correctement. Vous avez besoin d'un langage domainé spécifique dans lequel vous allez avoir les constructeurs qui vont être facilement analysés. Pour exemple, dans l'EVM, il y a un static analyser pour que vous ne puissiez pas utiliser le static d'exécution. Oui, oui, oui. Vous avez besoin d'un langage qui n'est pas complet dans lequel tout est type donc c'est ce que l'application est précisément type avec des opérations type qui ne peuvent pas manipuler les accounts sans expliquer que les accounts sont manipulés. Mais si vous avez ça, oui, vous pouvez. D'où je comprends, dans le projet PL, le langage est donné, c'est un wasm c'est un code wasm il n'y a pas de langage, il y a plusieurs langages, mais je ne suis pas sûr que le team de engineering veut avoir seulement un langage. Et dire, ok, maintenant on a un genre, comme vous le voyez, c'est comme le JVM, c'est comme un code wasm pour lequel vous... Vous avez dit que vous avez besoin de l'account, oui? Oui, c'est écrit par les transactions. Nous avons un gaz trésor donc quand vous avez un code wasm vous devez choisir les opérations qu'est-ce que c'est? Peut-être, dans cette analyse vous devez vérifier pourquoi c'est écrit. Parce que vous avez les opérations à quel point vous devez faire un pass sur le message. Peut-être, on peut... Nous devons vérifier. Mon dernier slide est ce qu'il y a précisément pour discuter ce que nous devons discuter. Peut-être, donc la prediction multifuture. Donc, dans le principle vous devez trouver cette idée dans ce paper SOSP. Donc, la idée c'est d'optimiser ce model de détermination de l'exécution de consensus. La partie détermination est importante. La idée c'est de dire qu'il y a un temps entre le moment où la transaction est connue, parce qu'elle a été produite par quelqu'un. Je veux exécuter la transaction et exécuter. Et dans ce temps entre la détermination et le consensus la idée c'est d'optimiser l'exécution du futur de cette transaction.  Et ce que nous avons discuté avant, dans quel ordre sera-t-il appendie dans un bloc, vous ne le savez pas. Donc, vous devez avoir un multi-future, c'est-à-dire, vous savez, un set de possibles transactions qui pourraient être incluses dans un bloc, mais le prochain minor qui va gagner le consensus n'est pas connu, donc il peut faire tout ce qu'il veut. Donc, c'est pourquoi, basically, ils disent « OK, let's consider that we can have multiple possible futures, OK, so we generate an accelerated program for this future, this future, this future, this future, this future, and at runtime, they encode a set of constraints when they produce this multi-future, and at runtime, they are able to say, OK, now we see that we are in this future and not in this future or in this future and not in this future and so. So, yes, yes, I mean, so they adapt to the fact that there might be multiple futures and they need at runtime then to be able to, you know, to take the right future and if they didn't guess the one of the, I mean, if the future that actually occurs had not been studied before, they will just perform a one-at-a-time execution, a serializable execution. The nodes between the dissemination and consensus phase. The nodes, they know the transactions, they got them, they are waiting for the consensus to be reached, they have plenty of unused cores, at least they say so, and they leverage unused available CPU resources to generate, so, the thing is, so, traditional speculative execution has one execution context to deal with, whereas they have multiple execution contexts to deal with, and this is the overall architecture, so no, let's not consider this, OK, this is what would, so you have the future context, so there are multiples futures that can occur, depending on which transaction will be ordered before which one in the next block that will be produced, so they produce some context, they do some prediction of what the next block will be, OK, that might be this one, this one, this one, this one, they perform a problem specialisation, they use memorisation techniques, you know, to cache the results and not perform memory accesses, etc. This generates accelerated programs, AP, OK, that then will be, at runtime, used to accelerate the execution of the transactions, OK, so what I'm saying it's over-engineered, it's a bit complex for, you know, I mean, plus you need to indeed say that you have a plenty of CPUs to average, which might not be the case, or you might use your CPUs to do something else. Yes, yes, you won't have many possible futures. If the miners is a nice miner, you might have rules such that you know what possible futures will be. And actually, they implement this on top of Ethereum virtual machines, so it's compatible with, and they show that they have some improvements and so on. So it's a very complex system paper, I mean, it's very, I mean, this is not a toy that they did, but it's... So the nodes are the ones that compute the future context. Yes. But they have all the states that they are required. But they don't know in which order transactions will be placed in a block. Right, but they may not have even all the transactions. Yes, exactly, they don't have even all the transactions. So they compute the future according to the transactions that they've seen in their mempool? Exact. And this is why they compute multiple futures, but they might not have the actual... Yes, yes. And what Matej was saying is that if you have some rules on how miners integrate transactions within a block, okay, it might be possible to say the future should be that one if you know all transactions and so on. If you are missing some transactions, there is no way to guess... Yes. But this base on the idea that before doing that you will know all transactions that should be in the next block. And not mean you should not know more, you should not know less, you should know the exact numbers of transactions and you should know these transactions. Message pools. Yes, that's... No, no, I mean... That's right. You know what... I can imagine if you do this, you have a big pool and then you say okay, probably all the end transactions, everybody already knows them by now and it will be... Or even miners, but they have like... They have like very interesting having as much information as possible for the new block in that pool. But no... They have no incentive on having... Yeah, I think... I think it's worth all the... It's what I call an over-engineered work. But it's... I mean, between Solana, which is very basic, where basically you declare, and yes, base on declaration, we are all able to do an even base runtime that will pick transactions and execute in parallel those that do not access the same state and this, there is a huge gap. This is our main months of work and so on. What should we conclude on all these research ideas? There is something nice to draw a conclusion. This is this paper by Erli, this 2019 paper because basically it answers the following question which performance gain can we... can be expected, can we expect? And the idea is the following one. It uses historical data from Ethereum and it tries to estimate the potential benefit of speculative execution. Speculative execution means executing in parallel. I should have written parallel execution but executing in parallel is smart contracts. And so, they assume the following execution model. They say we have two phases. One is the concurrent phase where the virtual machine will execute smart contracts in parallel. It will track the written rights of each transaction. It will intercept and buffer the rights. And so, two transactions conflict if they access the same relocation and one at least is a right. And in a second phase, all conflicting transactions are replayed in a one-at-a-time order. So, they take the transaction of a block, of an Ethereum block, so they look at historical data, and take a block. They try to execute all transactions in parallel. A set of them work, meaning they commuted, they didn't access the same state. The other one that fail, they reexecute them in parallel. And they are looking at the time it takes to execute this rather than executing all transactions in a serializable manner. They cannot perform this study on all blocks.  It would have taken for too many time. So, they take transactions occurring from 2016 to December 2017. And so, this is the number of transactions per day on Ethereum. We can discuss this jump here. And they studied each time a window of one week of transactions. And on this one week of transactions, they execute one tenth of the transactions. Just to decrease the size of the data, they are actually processing. This is the cryptocity thing. It's important because it's something that is often mentioned in papers. This might induce bias in the way you interpret data and so on. So, cryptocities was a smart contract, token-like smart contract. And so, huge interest, many transactions and obviously many conflicts. Because... Because the parallelization cannot be done between functions in the same smart contract? It could, it could. And that's one possibility that I mentioned at the end. It's to do, for instance, conflict-free replicated data types to implement smart contracts. So, CRDTs, conflict-free replicated data types, these are data structures that, by design, commute. And, for instance, what is said is that accounts, credit and debit operations and account, which is something that blockchains are used a lot for, are the typical kind of objects for which you can design operations that commute when you don't have overflow or account. Yes. Yes. Yes. Yes. Yes. Yes. So, no, no, no.  Just, we need to decide the path we want to follow. This is Milestone 2, which, so, the last slide, we discussed. So, but what's interesting in this, which performance gain, so these are the number of transactions, the number of blocks on these seven intervals that they studied, just for you to have this, if you want. And that's the performance gain. And interestingly, or, I mean, or let's say, might be seen as a problem. This is the speed up on the y-axis. These are the seven periods of time that have been studied. This is over time. I mean, there are more and more conflicting transactions as time... So, this is the Crypto-Kitties case, but even here, this was already the case that the speed up was... This three lines are for the number of cores that are being used to execute transactions, obviously. This thing, I mean, the conflicting transactions, the number of conflicting transactions depend on the number of cores. We'll decide how many transactions are actually executing in parallel, and not... Eh, yes. Yes, yes, yes. No, no, no, no, exactly. That's... Yes. Yeah. That's the funny story. And so, having a larger number of cores is better. But there is a point after which at least there are lessons learned. They say after like 64 cores, they didn't observe any benefit in increasing the number of cores, at least on the data they studied. And so, this is the conflict rate, the percentage of conflicts that they observe. So, the conflict rate increases and the performance gain decreases. Yes. Yes. No, I'm curious about the conflict rate, because instead of Crypto-Kitties, everyone was transacting on basically the same conflict, so you had a lot of conflict. But if this is not all Crypto-Kitties, that was like 4-5, right? That was 7. Oh, it's 7. Okay, so that makes sense, because I mean you would expect that the more applications... No, no, Crypto-Kitties is this 7 one. So, these are the 7 periods. And this is the Crypto-Kitties. This is also why we observe higher number of transactions and so on and so on. All this is Crypto-Kitties. The speed up is what they gain by having these two phases. The Y-axis. Ah, the Y-axis? No, it's execution time. So, it's throughput. So, you have a block. It's the time to execute transactions within a block. A speed up of 2, it took 5 seconds rather than 10 seconds. So, it's the speed up of the execution of transactions within a block. So, I have a block to re-execute or to execute. It's what's the performance gain multiple suites. Concurrent execution. Yes. I mean, when you validate a posteriori for instance, you have all the blocks and you need to validate the chain again. Yeah, you catch up and there you will gain a lot. But otherwise, yes, there are other ways to optimize the support faster consensus is one, larger block is one. Hello. This is the number of conflicts per address. So, this year is so how many conflicts do we see and how many so we see that most addresses have very little conflicts and you have hotspots. So, you have some contracts that will yield very, very, very large number of conflicts. So, these are the so-called hotspots, these cryptocities and so on. And they perform an experiment where they remove this hotspot contract and obviously the concurrency is better. I mean, and the time the speedup is improved. Ok, so that's also a possibility for instance with subchains and so on to kind of redirect the very popular hotspots on some subchains and have some subchains that don't have hotspots or things like that. I mean, everything is open. I mean, this needs to be carefully just to say that these hotspots have a huge impact on this study. So, what are the lessons learned from the paper? Over time, speedups decline as transaction traffic increase. So, what we've seen with this slope they show that it's important to distinguish between reads and writes obviously, you know that reads, commutes, writes, do not. And they perform two experiments once in which they would just consider that if they touch the same memory address they conflict and one in which they will distinguish writes and reads and obviously it's just to say some incentives in going deeper in the possible analysis and really understanding what are writes and what are reads. They also studied another strategy where they have multiple concurrent phases, one first concurrent phase ok, you have a set of transactions that work, perfect.  At the end, you always have a serializable execution of transactions that did not make it in one of the previous phases and they showed that this didn't yield a good benefit. Basically, the ones that did not that induce conflict in the first phase they will induce conflicts everywhere and you don't have much benefit in trying to re-execute them in part. They show that accurate static conflict analysis yield a modest benefit so why actually just because what this means is that executing transactions that conflict is not a big issue you don't get much not executing them in parallel ok, you wasted some time in executing in parallel transactions that did not conflict but not that much it's not a big factor so they basically don't spend time trying to static analyze do a runtime that allows for concurrent execution be able at runtime to detect the conflict roll back the transactions that should be rolled back re-execute them and so and so but don't spend your time trying to generate a good schedule a priori be optimistic that's the idea but because the static analysis in a way probably works yes and it's a conservative approach and you don't gain much, it avoids conflicts but this conflict is not actually what slows down the thing ok the thing is, the system is efficient when you can execute things in parallel and even if you have conflicts and so on, you have executed many things in parallel and you got the benefit the static analysis part will avoid some conflicts but not much and the gain will not be much better the schedule is in the blockchain it's part of the blockchain state sorry it's in the block that the miner proposes it's a different block yes so it's a miner, it's a Byzantine miner it's producing two different blocks the two blocks cannot win one will win over the other so you still need a majority of validators to yes I guess otherwise I don't see how this would work but at the end, this is part of the block so you only have one schedule you have a winning schedule you agree on the schedule it should be part of the thing plus let me just finish have one slide and we discuss no problem, just that so increasing the number of cores it improves the performance but more than 64 was not useful and in high-contention periods it resulted from a very small number of popular contracts also known as hotspots and this is why I interrupted you Marco because what's next so now we can discuss so speculative execution we have four choices declare conflicts this requires an appropriate language detect conflicts requires runtime instrumentation we need to be able to statically analyze the code to create language to be able to analyze it use commutative data types to produce this was your remark contracts that use operations that commit, like to manipulate David operations STM is here Solana is here STM is here there is something else enable-disable speculative execution so that's something that basically why should it be by design I mean if you see that it's not you have periods of time where you have hotspots and so on an idea might be if you don't put hotspots within a subchain, etc it's to just see, observe that the performance is not better with speculative execution you just yes that says you just need to be included in the runtime design I believe, because it's not difficult to do and I think you can gain a lot it's like a B700 where you have this multiple things and you should not consider that by design speculative execution should be enforced maybe you will end up with cases or it should not be you should just be able to skip it if you have any of VA like the VM from JavaScript it does a first just in time compilation of the code and then it does the more deep compilation so that you can start fast and then have the efficient compilation could this be the case have a first password transaction just in time compilation detects some conflicts and then if you see that it's not a hotspot do a more or take only the transactions that are in the process I don't mean that's possible that means that you are in the static analysis you seem to like the static analysis the case where you analyze transactions no, it's a thing that compilers are already doing a lot of this work the thing is this is what interesting from the previous paper is I'm not sure that we gain a lot from knowing which one will actually yield conflicts what they show is that if you know this you will extract this transaction so you won't put them in the concurrent phase but what you will gain from doing this is not that high so that means that if you spend time if you spend resources trying to detect for at the end gaining 5% this needs to be carefully designed yes Ethereum c'est très proche de ce qu'on a plus ce que je n'ai pas dit, je suis désolé on n'a pas multistradie Ethereum, VM ceci est basé donc comment est-il estimé le temps ? 2 choses gaz estimation il y a un nombre d'opérations et ils montrent que les deux ont les mêmes graffes pas exactement les mêmes parce qu'il n'y a pas de map entre la coste de gaz ce sera en opérations c'est très proche ils montrent que c'est proche mais vous savez, c'est la façon qu'ils émulent ces mesures de temps ils prennent les mesures de temps STMs ? non, non parce que vous savez ce que les mesures de temps ont été accessées en STM d'ailleurs, toute la STM la histoire serait brouillante par design c'est ce que je dis, vous avez besoin de temps il faut être instrumenté parce que par design vous devez pouvoir dire que ces transactions sont conflites et les règles sont bouffées ils peuvent seulement s'appliquer à un temps de comité l'analyse, est-ce qu'ils se considèrent comme... parce que vous pouvez avoir des transactions sur un contact smart pour un autre contact parce que vous avez la transaction et vous savez les adresses que cela touche et comme la logique mais dans ce secteur est-ce qu'ils s'appliquent comme ça ? les papiers sont vraiment en train d'analyser ils considèrent que Ethereum n'existe pas et ils disent on va proposer une théorie d'exécution smart et donc ils disent que les tokens ERC ne pouvaient pas suivre ce design mais ils disent on a une théorie de la concurrence de l'objectif on devrait avoir le même contact smart d'être capable de dire mais ils ne sont pas au niveau des transactions nous avons d'autres transactions et si nous allons pour l'analyse de l'analyse nous allons au niveau de l'analyse comme l'account d'accounts ou quelque chose comme ça d'ailleurs c'est juste de l'air de temps plus nous n'avons pas d'experts de l'analyse donc nous devons avoir une partie du travail d'ailleurs pour savoir ce qui est nécessaire pour produire mais oui mais oui ce qui me semble le plus appréhensible c'est de détecter les conflits et en temps de temps alors si il y a un très simple compilation plus de stratégie d'imaginer nous pouvons essayer de livrer cette information mais nous ne devons pas dire que c'est la priorité pour moi ce serait pas la première idée ce n'est pas la première idée ce n'est pas la première idée la priorité est un peu épousé mais c'est un autre modèle c'est un autre langage je veux dire pardon pour moi ce serait un détecne ou la déclaration la approche solenne est très straight forward vous déclèrez basé sur la grandeur de discours sur la grandeur de discours et si la déclaration n'est pas faite par les développeurs vous les penalisez vous avez plusieurs blocs en même temps cela signifie que ces plusieurs blocs ont été votre contexte votre nouveau contexte vous ne faites pas des choses à la grandeur mais un set de blocs c'est vous avez des questions sur le BFT c'est la question concernant le BFT vous avez plusieurs vous avez des questions sur l'application ici mais vous avez des questions sur l'application maintenant oui il y a quelqu'un qui s'occupe vous avez déjà dit que vous avez des questions sur l'application mais comment ce mec peut savoir vous ne pouvez pas normalement vous pouvez je veux dire si vous avez juste regardé la transaction pas la change de state des transactions vous pouvez figurez quelle complète mais c'est un état oui un état qui peut le faire je pense que ce qu'est le fabricage dans l'autre modèle c'est l'application d'execution en fait je n'aime pas la distinction entre l'exécution d'exécution et l'application d'exécution parce que l'exécution d'exécution c'est juste un cas spécial d'exécution si vous avez trouvé votre application l'application d'exécution c'est en fait l'exécution et dans l'exécution d'exécution c'est juste que vous restrez le genre de transactions que vous pouvez exécuter et l'exécution de l'application mais peut-être ici si vous avez préparé la transaction il y a un état d'approche et que nous venons de l'exécution de l'exécution et il ne faut pas nécessairement être exécuté dans le programme je peux facilement imaginer des outils qui peuvent être arbitraux mais c'est un état d'approche et il peut y avoir quelque chose d'interaction mais je propose l'application d'exécution n°1 et vous proposez l'application d'exécution de l'application d'exécution mais il n'y a pas l'application d'exécution n°5 c'est juste un nombre de l'application donc comment ça ne marche pas ? non je dirais que vous êtes les leaders de l'exécution ah, ok, ok l'interface est bon mais avant, le leader propose d'exécuter quelque chose qu'il faut que l'application d'exécution d'exécution d'exécution d'exécution d'exécution de l'application d'exécution il manipule la salle parce que c'est la réception d'exécution et pendant ce que il fait il faut que l'application de l'exécution non, ça ne marche pas je ne sais pas comment vous parlez il y a un état qui va s'occuper du bloc ce bloc que l'exécution s'occuper va s'occuper du quelque chose donc comment ça peut s'occuper ? ça ne marche pas il faut qu'il s'occupe du bloc il s'occupe oui parce que si on le met il faut que tu aies l'access il faut que tu aies l'access il faut que tu aies l'access maintenant, tu as l'access et c'est le 5ème bloc où je fais mon 4ème bloc je ne la trouve pas mais il peut y avoir un bloc pour expliquer, vous devez le savoir


Welcome fellow barbarians to the 87th annual clan council meeting. Let's start off with a little roll call as is tradition Uh, uh, from the bear tree clan here Grog from the stone face clan. Uh-huh. Oog from the wind dragon clan present. Oh, okay. Great energy Well, that's it. I see that Oog has brought a new tool. He'd like to share. What do you brought a suit? Well, I found some interesting materials in the woods Pank some rocks together as they say and invented this leopard 2a5 armored tank. Wow, that is impressive Do any of the bigger dumber clans have this yet? Oh, no, no, no, I don't expect any civilized folk We'll have one of these for a few centuries. Excellent. Oh, speaking of heard we got some money from one of the civilizations Grog yeah, England tried to bribe stone face to fight wind dragon. Oh cool. How much I'd say just enough for another armored tank Fantastic, this is all positive Does anyone have the numbers on the east coast operations because the the clan that's supposed to have it does it here? Oh, well between the two of us We've taken two settlers and four workers from Canada and Persia's paid 400 gold in exchange for not setting fire to their minds every few seconds So all in all profits are up. That's great news There's more on the itinerary, but I think we should just leave it on a high note Everyone please enjoy the catering and we'll see you next time Egypt tries to build a wonder. That's it We're just not gonna talk about it Well, there's nothing to be done. I mean they might still stop by we can talk to them about it Ghostfish clan became a city-state. They're no longer a welcome member of this council. I mean, we don't know for sure What happened?  I bet they farm things. I bet they use roads. I bet they're boat Mormons I bet they build their own boats. Well, I built this battleship. That's that's different. Yeah, that's different I actually invited them here. I just think we could hear them out I can't believe you're on their side your clan has been sniping scouts before their first promotion since turn one Yeah, the world has changed a lot since then the Sims are getting way more advanced like not weapons or anything We're obviously still way ahead of them on that, right? But they're huge they take up most of the land now and call me crazy But I think they're making the ocean bigger. What if clan life just isn't sustainable anymore I actually always kind of liked farms ooh city-states have borders and walls and a military and gold money's the best Good to see everybody. I like what you've kept exactly the same with the place. How's Venice.  There's actually a lot of war going on Yeah, I wouldn't visit. Is that a giant death robot by the way? Yeah, it is nice.  It's hideous. I know. Bye pose, sir


So I did one thing, and because of this, suddenly everybody thought I've become some kind of an enemy. Then I made a deal with all the teachers. Also speaking of schooling and parents and careers, you know, we're in right now, we're in an age where there's so many different offbeat careers coming up. As YouTubers, we get this question all the time, you know, how did you talk to your parents about it? How do we convince our parents about this really new career that we have? I want to ask you, you know, if you had to convince your parents and tell them that this is what you… Or how did that discussion go? Did that happen where you had to sit them down and tell them that this is what I'm going to do for the rest of my life? I want to do YouTube now. Like, did that happen with YouTube? You're doing YouTube right now. You're doing YouTube. Well, not everybody can be convinced about everything, okay? Some things are just done. So just to give you an example, when I… when I passed my twelfth standard, at that time it was called PUC, after that I decided I will educate myself. I don't want to go to college. This is a family where everybody is educated, not going to college is like sacrilege. At least today there is a little more flexibility. Those days it's like if you don't go to college, you're finished.  That was a generation, if you don't go to college, you lost your life, you… on the street, that's about it. So they were terrified of this. My father being a physician, he was just freaked about it. He is a very studious man, all his life was second, third in everything that he has done. So he couldn't believe this that I want to educate myself. So I did one thing. And because of this suddenly everybody thought I've become some kind of an enemy. And they were not even talking to me properly. I did one thing.  But I never was putting on weight or anything because my level of physical activity was such. I could just run up a coconut tree, I was made like that. So I was every day cycling about fifty, sixty kilometers, swimming in the Cauvery and going back like this. So eating this, I decided to go to my city university library. Every day when they opened at nine, I went eight in the evening, they closed. That entire time I sat there, read all kinds of stuff. From Homer to popular mechanics, to national geographic, to literature, to geography, this, that, whatever. Whatever came my way, every day for one year I read like this, just all kinds of things. But the most important thing for me was, though I was such a huge eater at that time, this one year I went without a meal. Morning I ate as much as I could, breakfast at home and I went there and sat there the entire day without a meal which was a huge achievement for me because without food I could stay. This kind of expanded my way of looking at life. But you know family drama started, my mother started crying.  Then I said, if I must go to college, I'll go for literature. My father said, what will you do, reading poetry? You must become a doctor. He has a seat ready for me in the military, medical college, everything. I said, no. Then they said, okay, at least do engineering. Then I said, see, please do engineering. If I say I don't want to be a doctor, if you told me become a veterinary doctor, Ayurvedic doctor, at least a witch doctor, I would look at it. If I say no doctor, you say engineer. I'm not going to listen to this. Your problem is society. Your problem is not me. So I just went for literature and these three years, I went there in the beginning and they all had ready-made notes, the teachers, they would read. And everybody writing down, those days fountain pens, karakara, karakara, it makes noise. It just irritated me. I said, I don't want to listen to this karakara noise, I gave them a suggestion. If you give that notes wherever you've got it, we will photocopy it and give it back to you. We don't have to come, you don't have to come. Then you know, if I'm there, I'll ask hundred questions. So they didn't like it. Then I made a deal with all the teachers that they'll give me attendance. That was my only concern. So once a month I just… once a month I went to college just to check if they're keeping their part of the deal.  Just wandering aimlessly. But today, like when I went for the Rally for Rivers board where all the top experts are there, some questions came up when I just telling them casually, they said, «Sadhguru, how do you know all this?» I said, what… what was aimless wandering? Where I paid absolute attention to everything, from a worm to an insect to anything and everything I paid attention. Now it's become formidable knowledge. I never intended to learn anything, I just paid attention because it was life. And this is all it takes. We have come here to live, there is no other damn purpose. Those of them who want to go to heaven can go today, why are they postponing? If it's such a great place, I don't see why you should postpone it, isn't it so? This is very important for the youth. If anybody says there is a better place than this earth, it is a crime. It's because of that we have destroyed so many things here.