SPEAKER_00: 0:13

Welcome back. Today I'm joined by Thomas Latin. The theme is simple. Tezos is being built to feel like one product, reliable when things break, and fast enough for real-time use. We'll start with real mainnet issues and the Etherlink 6.1 fix for FA token deposits, then move into instant confirmations and what sub 50 second 50 millisecond receipts change for real-time apps. We'll close with Tezos X staying on product delivery and what users should actually notice. On December 17, Etherlink 6.0 went live at 0700 UTC, and a few hours later, a real deposit failed. If Tezos is supposed to feel like one product, what's the first thing you want a normal user to believe in that moment?

SPEAKER_01: 1:12

Oh that that was a question for me.

SPEAKER_00: 1:15

Yes, sir.

SPEAKER_01: 1:16

Okay. So I guess if I were a user of Tezos, which I am, and I'm learning that feature is broken, I'm gonna want to know what the fix would be and when it would be live. And if the if the assets are safe as well.

SPEAKER_00: 1:34

Absolutely. What what did you know within the first hour? And what did maybe you guys miss?

SPEAKER_01: 1:41

So I think what happened first is that so we have a bunch of monitoring in place um that uh we used to know uh what is the health of the chain. And we started to get alerts about an asset that was basically locked on the L1, but that wasn't uh available on the on the layer two. So what happened in practice is that someone uh decided to make a deposit of um of a bunch of tokens uh from uh from uh I guess a temple or pukaya or uh using the the FA bridge, and they start uh waiting for for the asset to arrive on the L2. So when the when that happened, we we uh so we had we got our own alerts, we got I think uh uh a bug report uh happening as well from Discord, if I remember correctly. So we had this uh bunch of signals that something was wrong, which uh to be honest, we were like an hour or two hours after uh a successful upgrade. So it was like uh a bit of a roller coaster because on the one hand we we felt pretty good great about delivering Farfaday, so it's having 6.1 uh release, and on the other hand, we we quickly understood that probably something was uh was a bit fishy. So then it was about debugging, uh and it was about understanding what uh what happened, uh, which is something we've uh like bugs happen. Like we we we can try very hard, and we do try very hard to deliver the best software we can, and then we we miss something, and sometimes there's something obvious, and you feel guilty about it, and sometimes it's very tricky. Here it was a bit in between, to be honest. Uh but um it was clear. So the first was the first thing was to understand okay, uh, where are the funds? How are they safe? Uh how BethLink is built means that it's very hard for funds to be lost completely. Uh in practice, at the very least, they remain like they they remain safely locked on the L1. So we knew that at the worst, like the worst case scenario was not like funders have vanished. So the worst case scenario in practice with the bridge is uh funds have been uh locked away and are inaccessible. And this was the case. Um and and then it was like using the tools and and all the things that we have prepared ahead of time to try to have some visibility about the state of the chain. Uh and I think we actually found the issue quite quickly. And and once we found we found it, we we had a clear, we had a clear picture about how to fix it. And if I get the timeline right, uh within basically within the first day, we had we we knew the bug, we knew how to fix it. Um and then I don't know, like maybe the the day after we had a fix that was properly validated and ready to be voted on, and then we started the governance process quite quickly. And overall, it was like I don't know, 72 hours or maybe one more day. But um from the time where we got the report, which was a Wednesday morning, I think, to the time where the fix was deployed, which was which was the Saturday evening. And what I think is significantly is that we did that without admin keys, we did that in a non-custolable way, the FR link, uh at the end of the day, it is not something that we can control, it's not something that we can upgrade. The best we can do is to provide propose a fix to the community, and what is nice is that every time the community uh shows up and and we we have a successful governance that uh means that we can roll out in production quite quite quickly, and that's typically what I said uh okay.

SPEAKER_00: 5:51

So I know what you mean, and that's the it's awesome. In plain words, what actually failed for the FA token deposits and what was still working?

SPEAKER_01: 6:02

So, in plain words, um what failed is that so when we how does the FA deposit work very quick? So, what happens when you do a deposit of an FA token from the L1 to the L2 is that from the perspective of the L1, the Etherlink smart roller, which is really the the thing that is power powering the chain, uh becomes the owner of the of the token uh from the perspective of the L1. And then uh there is a communication that is happening, and I think the details are a bit out of the scope of the discussion, but basically the etherlink chain receives a message that is saying now there is a token that has been deposited. Uh, it is this token. This token is uh is uh controlled or uh like uh is uh handled on the layer two side by a by the by the smart contract, which is uh which has an address and it's uh near C20 smart contracts, uh, which is a standard of the Ethereum world. And uh what needs to happen is this the message of oh, there is a deposit that is happening for this token needs to be forwarded to the to the smart contract in question. Because we need the smart contract to mint VRAP token, uh basically, for this uh deposited token. So it stays in the L1, and then we mint on the L2, and when we do a withdrawal, we burn the VRAT token and we release the token in the L1, basically. And and the state of uh we need to have some mint happening in the L2 was uh broken, basically. And it was broken because in a nutshell we've uh changed how our uh deposit works between uh the 5.0 uh series and the 6.0 series, and we've tested it extensively from uh basically anti-context. So in in our test suite, we we create new instances of Etherlink in a row and we we do a bunch of things. And we missed the mark when it comes to testing on the line on an existing context. We we do that regularly, but for this in particular, we missed the mark. And the the logic, like basically the logic introduced in 6.1, in 6.0 didn't work for when you migrate from 5.4. Um, but again, the thing remained that the the funds were safe, they weren't destroyed in the L1, like they weren't burnt in the L1, they were locked. And so it was possible for the starting blockchain to say, okay, we we miss them, we missed this uh deposit order once, but we can reinject it. And so the fix what was twofold basically: fixing the logic, making sure that when you do a FA deposit, it works, and then re-injecting to some extent or like uh interpreting correctly the FA deposit that was uh in limbo uh uh between the time of the deposit and the time of the activation. Um so yeah, that's that's in a nutshell what happened and how we fixed it.

SPEAKER_00: 9:11

Okay. Wait. So you said the test suite started from a fresh state, but uh mainnet had older bytecode from 5.0. If it has this one product, what is the reliability lesson about upgrade paths versus clean room deployments?

SPEAKER_01: 9:30

Um so I think that that's a that's a um a long running long-running challenges challenge. Like testing on mainnet context is hard. Uh and we we do it, obviously, because like what matters is that at the end of the day, Astr Link mainnet works. Uh it's a good thing that Astr Link works from uh from a new genesis, but that doesn't bring a lot of value to users. So we do testing on mainnet context and on uh like a realistic context. Um but I think we can, at least for uh for the layer two, uh, because that's where I'm focusing the most, we can we can do better. Uh and that's one of the output of this whole uh experience, this whole journey, is to say that uh we need to make sure that when we deliver something, it has been uh correctly tested, including on mainnet. And right now it's uh it's too much of a best effort uh that we we do. Again, I don't want to uh to undermine what uh the engineers working on Etherlink uh are doing on a day-to-day basis, but we can always do better. We can always make things that rely on rigor and discipline. It's better when it's done by the system. And so this is the next step for us is to raise the bar when it comes to ma net migration, because uh the same thing for the L1 uh uh for Tezos L1, and it's the same thing for uh for Italian. It's like we we are uh we are uh living, breathing blockchains uh that happens to evolve. Uh it's a bit of a catchphrase, um and that happens very regularly. Uh and and and to meet the expectation from the community, we need to have a good engineering practice. And on this particular case, I think it showed that we had a blind spot and we are we are uh building the necessary automation. Basically, it's not it's not rocket science. I'm not saying that we are revolutionizing uh engineering here. I'm saying that we had a blind spot and that we are fixing it.

SPEAKER_00: 11:47

You re-inject the last deposit into the delayed inbox via a migration so it can mint correctly after 6.1. Why is a migration the right tool if the theme is one product and not good luck try again?

SPEAKER_01: 12:02

I mean, so um uh from that perspective, we are I guess if we tried with a thought experiment, uh we had uh one clear objective that was like the availability needs the fix. And then there is the the question of like what to do with the funds that are locked at the moment. And I think I mean if you have the cynical approach and you have a look at the situation, I think it was like$12. If you if you if you just look at uh at the value of funds that were in uh in this uh frozen state. But that's that's not the good and the correct way to think about it because it was$12 that day, and it could have been$100,000, or it could have been$12 that are worth a lot to a given community that uh uh that was trusting uh Etherlink and Tezos. So I think the the stance here is to say that Etherlink and and Tezos and what we are building, we want it to be something that is reliable and that people can have some trust into it. And and I think what we what we were focused on uh when we said these$12. So to say it a bit provocatively, is that we were showing the community that their trust and the reputation that we have, that I think we have actually, uh, is well deserved. And that and that, yes, it's it's$12 today, and it can be$100,000 tomorrow, it can be uh an NFT that has no value because it's not for sale uh the day after, and it will work the same. And your product can use the FA bridge because the uh bugs happen, but when they happen, they are they are dealt with um in a way that takes into account that uh they have value, no matter uh for who and and basically for who users, which is the main point. Um so so I think it's consistent with the fact that Tezos is one product, and I think we've dealt with this kind of situation the same way since uh Tezos Genesis is to consider that we are providing a platform. Uh, this platform uh needs to work, it needs to work reliably, and it needs to work in a way that doesn't try to factor out like certain um interest or certain uh like uh like the needs of a few. It's a platform that needs that is open, decentralized, uh non-costal, and that treats every user the same way.

SPEAKER_00: 14:37

You chose fast governance in one product language. What is the principle here? What makes this urgent enough to go fast, but still careful enough to be trusted?

SPEAKER_01: 14:49

So I think it's a good opportunity to remind a bit how the Etherlink governance works because there is a bit of difference with uh what is uh happening on uh on the Tezos layer one. Not to say that one is better than the other, but I think we were in uh in position with Etherlink uh to experiment as well a bit with uh with governance processes. So on Etherlink, you have uh you have two ways to propose an upgrade. So, first thing, Etherlink, the same way uh Tezos is built, doesn't have an admin key. Like uh we cannot uh at any point uh and I would uh even argue that it's harder uh than uh traditional layer one because of the security model, we cannot impose anything um to uh to the etherlink community, to to the tesosbakers and to the to the etherlink users. We need to go through the governance. Um, and we have two tracks for the governance. We have uh what we initially called the regular and the security upgrades track. Uh and we have now what we call the fast and the the slow and the fast track, which are, I mean, like uh code-wise, they are the same. The difference is more in the semantics and how we want to do that. In any case, what we have is two ways to propose an upgrade to the community, and the main difference is how fast it how much time it requires, how much time it gives to the vote to the voters to vote, uh the slow track be taking more time, uh uh, but uh requiring a slightly lower uh quorum. So the idea is that governance can be weaponized potentially, if uh because if you uh gather a majority of the stake, there's a majority enough of the quorum, you can uh uh use the governance to to impose uh uh an upgrade that maybe people don't want and could vote against if they had enough time. So the the the much time it works it takes to like the longer the governance period, the lower the quorum, because we still have the supermajority. So we need uh 80% of uh of votes, I think, in favor for a vote to pass. But we'll give a bit more time if uh like depending on the core. Anyway, so we have a slow and and uh fast track. The slow track is for the normal upgrades, it's for the day-to-day basis, and it's uh a way to respect everyone's time and to say, okay, uh, you have uh four days to vote. Uh that that gives you time to put that in your agenda because uh we don't consider it to be trivial to vote on. It's it's made easy, but it's it's it's uh it's a difficult decision. It's it's done by a key that maybe you want to protect. Uh, you may have uh processes to protect this key. So yeah, so this is uh the regular one. We are targeting uh basically, I think it's uh around 10 days of governance. And 10 days is is uh significantly slower than uh uh smaller than uh than the Teslayer one. Uh but it's still very long when it means that you have to wait 10 days for uh for the an upgrade to fix one of your main components, uh which is in that case the the fabric. So we have also the fast track. So it was called the security upgrade track at the beginning because it was the idea oh, we have the security issues on ethernings, that's gonna happen. Uh we have a way to deploy the fix. Uh again, we have a way to propose a fix that can be deployed very quickly if the Tesla's deckers uh agree with us. But actually, it doesn't have to be a security bug. It can be uh it can be a UX issue, it can be it can be something that impacts the user enough that we collectively as a community decide that it's okay to annoy everyone and to have to say like it needs to be fixed in 10 hours, which was the case for the Febridge. Because not only so we so basically, what I didn't say before is that when we realized that the deposit any deposit was affected, basically, we disabled the front end of the of the Febridge. Uh which again, uh I want to state that the Febridge is completely permissionless and that anyone can deposit any funds whenever they want. What we do is that we have a front end, uh that is a convenience, uh, and that we propose to the community. And because we have the we are actually we don't we there is a sorry, uh it's I I need to be precise. There is a front end that is deployed, uh that is operated by the company with uh that is called Optimistic Lab that we work uh very closely with. And what we suggested to Optimistic Lab is to disable the the February at that time because we knew that uh they are operating it, so they have uh uh um obligation towards the people that are using their uh infrastructure, and so we suggested that to them. Uh they agreed because they agreed that the situation was dire, and then we proposed to the community to fix it as soon as possible so that we can restore the service. And uh, I would say that um I'm rumbling a bit, but uh that's the main idea. Is that the question was uh why why the fast governance? Because it was affecting uh key part of the infrastructure. We were in a situation where we were in a position to propose a fix very quickly, and we were able to gather the support of Thesus Baker without nothing uh without them, nothing can happen. So uh and we would convince them that it was worth it. So I would say that in any case we choose nothing, we propose, we choose to propose, and we were convincing enough that bakers uh rally around the the vote and and and and and voted it uh on a Friday.

SPEAKER_00: 21:06

Uh which uh wasn't it one of the uh biggest turnouts?

SPEAKER_01: 21:11

I think it was a record indeed. Uh I uh I if I remember correctly, we we break we broke a record this day. Wow.

SPEAKER_00: 21:20

Now, if someone only remembers one thing from this incident, what should it be that increases their trust in Tezos behaving like one product?

SPEAKER_01: 21:31

Um so I would say that at this for this issue in particular, we we showed two things uh which are very collected. The first one is that uh when something breaks, we uh fix it quickly. Yes. Uh and we fix it quickly without compromising on what matters, and in particular, uh what matters uh for us is that Ferlink is non-cushable, and that we don't need an admin key. To have a response to an incident that is um how to say that that is uh on par with industry standard, I would say. Uh and I would it's probably a wrong word, but a web to industry standard. In the sense that we uh again, it's a bit of uh uh strong claim because a web 2 would have fixed that in 24 hours or less. But uh but the the the two days that we have to we have to wait more were necessary because it's a decentralized system uh that manipulates a lot of money, then we have like uh dozens and dozens and dozens of millions of dollars on ethics and uh uh and and and we take that very seriously. Uh so so I would say that I would say that we uh I would have preferred that we don't have to do that to do it, but we I think we showed that uh when when uh what shit happens, uh we are uh we we can as a community deal with it and in a way that uh that is aligned with our values and with our core values, I think. Because if I think if you see if you talk to any Tezos user that have been there for a while and uh as well, it's like what Tezos decided to do differently is to never compromise on decentralization. Uh and and and yeah, I think it's it's precious in our industry, in the sense that it has value. Uh it's it's a value that we are fighting every day to have people recognize. And I think it works uh to the extent that uh Etherlink uh has seen at seen adoption and the Tezos are still its core uh users and really like a strong community. So it's what it's worth it basically.

SPEAKER_00: 23:56

We've talked about reliability when something breaks. So now let's talk about speed that feels real to users, not just benchmarks. When you say instant confirmation, what exactly is being confirmed and what's not being confirmed yet?

SPEAKER_01: 24:14

Okay, so a bit of context. So instant confirmation is a feature that has been uh introduced with uh with the Farfide Ekarnel, so the Ecarn MC.o. Um and I think it's interesting because here um like we we didn't plan to do instant confirmation. The truth is that we had we have had our eye set on performances on throughput for a long time. Uh since uh since uh Arthur first mentioned uh the sex roadmap and the scalability journey. All we've seen we've been speaking about was one million transactions per second, and that it was important. When we built the Fairlink, we knew that we were comparing ourselves with uh other layer tools, uh blockchain, typically Arbitrum and uh and Optimism and uh and this kind of uh uh obviously uh great products in the sense that they have a real success. And we knew that we couldn't arrive and say, oh, we have built this shiny layer tool blockchain, and uh actually you have to wait three seconds to have uh a block. So we set a block time to 500 milliseconds, and I think to be fair, I think in early 2025 uh we thought the we were done in terms of flat RC. And then we had people adopting the chain, and we had people saying that, okay, so the DeFi today uh is not satisfied with 500 milliseconds. It's it was fine in 2023, uh, and when in in the second half of 2025, the the discourse has moved on, and now we are seeing base doing 200 milliseconds, for instance, and we are seeing uh we are seeing Arbitrum uh lower base as well. And we we are seeing competitors doing that. I think the main use case that has been driven is uh is a DeFi use case. Uh people uh in DeFi. Uh and I'm speaking not as a DeFi uh uh expert, but as someone that has what do you mean?

SPEAKER_00: 26:22

I want financial no, I'm kidding.

SPEAKER_01: 26:25

No, but I'm speaking about someone that I've uh that has speak with uh with uh with our DeFi expert uh internally uh to understand why they were saying to us it's very important. And and the key idea, I think, is that the the financial world, uh fine uh decentralized and not is moving way faster than 500 milliseconds. So when you think about a blockchain as a portfol as part of a portfolio, portfolio that is dealing with value that moves at a faster pace in a few places, it's not okay to, I don't know, like to take a position at uh T0 and have to wait 500 milliseconds to change this position if the in the world around us has changed. So that was the use case. It was to unlock DeFi to have a way to react to the real world faster and to take position on this view that is a blockchain of the real world uh faster and and safer in the sense that if they want to release their position or to increase this position in between these two ticks that are blocks, they can. So this was the use case. Uh what we did very and I will try to remain very high level because there is little value in going deep into the details actually, is to say that we already have a sequencer that is also operated by Optimistic Labs. But uh what we can do for Optimistic Lab is to provide them with a sequencer node that doesn't wait for a block to advertise the transactions that are being that will be included. So what the what the sequencer is doing uh since uh around January 15, if if you if you ask it, is to advertise ahead of time. Okay, I'm I'm about to create a block. The time stamp of this block will be uh this time stamp. And then all the transactions that I received until the block is created, I will stream them to anyone who is asking uh ahead of time, as soon as I have confirmed that. Because the sequencer is uh per delegation by the Tezos Baker, the entity that is responsible for creating blocks, and there is one. Uh we can have a debate about whether or not it's a good property for a decentralized system. I think personally that we have put in place the correct um safeguard and the correct infrastructure for it to remain in alignment with our decentralization uh uh ethos. We have a uh a sequencer that is being elected by the by the backers that can uh be monitored, uh, that has anti-censorship things that are put in place by the network itself, by uh Etherling itself, and that can be changed uh without uh optimistic cloud in this case being able to say anything against it. So I think so. I think we are in a situation where it gives us an opportunity as well. Uh and there are challenges, there are infrastructure challenges, but there are also opportunities with this uh uh having a single entity designing on the order. And by designing what we have implemented and what optimistic cloud it's running is uh actually um uh not designing, it's including as a as it received transaction and preserving this. And before you had to trust the sequencer in the sense that oh um uh between two blocks it's a black box. And now what is happening is that as soon as it has received and uh accepted the transaction, it streams it to third party. So we say that even uh uh instant confirmation is is even uh a step in controlling the sequencer, because if the sequencer then decides to create another block, it's it's possible to monitor and to raise an alert. So but what it gives, so and and okay, so this is for the sequencer part part. The sequencer today, Optimistic Lab today, with the software that they're running, streams ahead of time the content of the block as soon as they know it. Um and so in between the 500 milliseconds that you have to wait for your block to be created, you know what will be the transaction in order. And once you have done that, what you can do is to start executing this transaction ahead of time. You can say, okay, I have the state of the previous block, I know what will be the time sample of the next block. So I know for each transaction, execute them uh incrementally, execute the block implementally. And if you do that, you can compute the receipts. And if you can compute the receipts, you can know what is the result of your uh transaction, and you can know if you've been able to put this order in place. You can know if you if you've been able to buy this buy or sell this uh this token. And you can use it as well. You can say, okay, I know that I I I have bought it, now I don't want it anymore. Let's sell it very quickly. Or on the opposite, like I know that I have bought some position, and now it's even more interesting to buy. Let's buy it directly because I know my balance, I know I know if there's a supply because uh because I know what people other people are doing as well. It's not limited to what I'm doing, I know what anyone is doing at this time, and so that's what uh instant confirmation is. It's the idea that uh instance is obviously uh I shouldn't say that, but let's it's obviously a buzzword, like it's not instance the sense that your transaction still has to go to the sequence or it still has to be valuable.

SPEAKER_00: 32:19

It's gotta be magic, it has to happen when I think about it. I can't, I can't believe it.

SPEAKER_01: 32:24

I don't think you think at a five uh at a 50 millisecond uh pace, to be honest. Probably not.

SPEAKER_00: 32:29

Probably not.

SPEAKER_01: 32:30

Uh it's probably faster than your reflex. So I would say that uh, but we are talking about the reflex of both. I mean again, the the main um adopters of this feature will be defined and and and taking position and stuff like that. So but but yeah, so what we have claimed and what we are measuring today is uh is less than 50 milliseconds uh for 90 percent of your transaction, you know the receipt of this transaction, and then there is a 10% that uh that remains that way because you have some outliners and and we could uh talk about them. But I think to be honest, that they are a bit uh uh uh uh deep into the tech, but uh I will let you decide if you want to point me on it. But uh but for 90% of your transaction, you know uh in less than 50 milliseconds what what is the result, and uh and then you have a bit of a caveat for the first version of instant confirmation, and in the spirit of being transparent, uh you have the an assurance of basically the sequencer uptime that this uh instant confirmation is final. Because what what I can say is that there is one scenario where the sequencer can drop the ball today, and it's if it is restarted by optimistic lab or if there is a bug that makes it crash. Because uh in that case, transactions are lost and it restarts from scratch. This is uh uh I think we have a pretty good track record uh in uh like a collectively uh with Etherlink. We have Etherlink today, if you go to statutes.etherlink.com has a pretty good uh uh uptime. Uh but it is again, like uh if you want to use instant confirmation, it's for uh engage engaging your money, then you need to know the the the footnotes, and that's that is the current footnotes, which is that you uh there is value in uh in taking position between blocks, but you cannot uh yet just ignore the block frontiers. So it's more about giving you opportunities uh rather than giving you a 100 uh percent certainty. The certainty is like nine, like four nines, basically, uh, in and more in practice. But uh yeah, that's it. Sorry, I'm talking too much, I guess.

SPEAKER_00: 35:01

You're doing great. So reliability is how you handle the bad day, speed is how you build the good day. Now, how does Tesos start to feel like one product to the user across all of this? In product terms, what's Tezos X trying to change for a user who doesn't care where execution actually happens?

SPEAKER_01: 35:24

So I would say that the first thing is that to some extent we want to we we want to propose to the community again, like uh all I'm saying is always uh uh there is what we build to propose, and there is what the community adopts. But I think we are convinced that the frontier between the layer one and the layer two, they don't matter that much. Tezos is one ecosystem, it happens to be that we have a nickname or we have named our layer two blockchain Etherlink, uh, and it made it made sense at the time. But Etherlink wasn't something that was in opposition to Tezos, you know, it always uh was supposed to be part of the Tezos ecosystem. Uh, and I would say that Tezos X, uh, as uh uh explained uh in by Astor and Barriftol, so with Tezos Explain and all these good resources, is really about uh enshrining that to reuse the word a bit randomly, but uh to to really make that a reality uh beyond any doubt. Uh we we want people to use Tezos, uh and it happens that part of what they will do will happen on this layer two blockchains that we have built, uh uh or that they will keep using uh the very good uh products and they have that we have on the L1. Uh, but they don't have to be reminded every time by using a different uh wallet or by uh having to choose a different network on uh on this wallet that uh that's that is different because strictly speaking, again, they are not like the Etherlink is so intertwined with uh with Tezos, like the security of Etherlink is guaranteed by Tezos, the the safety of the fund. Uh you cannot lost fund in Etherlink. Again, what I the worst case that we have today is that we can uh uh lock them in in a way that requires an upgrade, a migration uh to to to unlock, but but that's that's it. So uh so yeah, so so the next steps for uh for etherlink is Tesos X. Uh and and I would like if I said that it was always the case. Like uh SRLink what when it was launched, uh we knew that there was a demand, but it was still an adventure, like no certainty exists in the in the blockchain space. But amen. But but but uh but etherlink being successful was always Thesos being successful. And Tesos X is about uh taking what works with Etherlink, taking the good property, the what we think has value for the user, the the low latency, the the throughput, the fees that are very low, and making that available uh first to uh people that are using the ecosystem of Tezos, uh people that have invested years in uh in having smart contracts and uh and decentralized application, the apps that are using uh uh uh ecosystem. All of a sudden, they can use the same uh execution context as if they link, and they can enjoy the same benefits. Um and and and then that's the and again, that's potentially the not potentially that's the first step of the roadmap, uh, which is uh of the remaining roadmap, which is like the fifth or sixth step of the actual roadmap that was presented in 2021. But uh but now we are in the step where uh yeah Mikkelson can enjoy the benefits soon. And and then we we want like we have our set or eyes set or uh or more on uh runtime or ecosystems that are Linux compatible. Like, why do would we have to stick to blockchain environment when we can have web to technologies, industry-guide technology technologies that works in our uh decentralized uh execution layer? Uh so that's that's our next steps that are coming for Pesosex. So it's really for I think this this experiment to some sense. I know I I don't know if uh the marketing would uh call it an experiment, to be honest, but uh it's uh I'm 40 minutes in talking uh in Rambling. You're doing great, you do it great. So this experiment who has become a success at least uh to us into the next step, which is like coming back to Tesos, so in the sense that one brand, uh uh not one brand, but one ecosystem that is really uh integrated, and then uh moving past that in the sense that integrating more uh with the Linux compatible environment.

SPEAKER_00: 40:23

Okay, so put it all together. When things break, you fix them fast and transparently. When things work, you make them fast enough for real time. What is the next proof point that makes Tezos feel like one product of someone who has never read a technical post?

SPEAKER_01: 40:41

So I think the next product is about user-facing features of Tezos X. Um, if you followed uh the technical roadmap of Tezos, uh you know that we've delivered uh in the past four or five years with respect to this Tezos X roadmap. Um we have had Smart Rollups and Ethernink, we have had the DAL that is in production, we have uh shrunk the time block of Tezos from 60 seconds to six seconds, which uh kudos to the team that has worked on that. I I wasn't part of the effort, but I can just say that I was amazed by uh by what they've done to achieve that. Uh I think it's a it's an engineering marvel uh what they have accomplished. Um so you have all that, and there are parts that are user-facing. Ethern is user-facing. Uh six-second block time on Tesos is user-facing. But it's not Tesos X, it's not the vision that Arthur gave gave us about like this uh this uh uh multi-runtime uh uh environment. Uh these have been prerequisites, important ones. But I think what we that will come next will really be this. Okay, now there is no dot, now it's Tesosta, and this is EVM and Mikkelson. So what is today Etherlink, and uh the capacity to have uh to use your um Tezos wallet to use your Tesla smart contracts on the layer two. That is uh this this will be part of uh uh a governance proposal that we make for Etherlink to turn Ethanlink into something else, to something more, something bigger. And the target, I think I I can uh I can say that the target is uh during the first half of 2026. To have this uh the to to to have this uh etherling teenager because becoming the Thesos uh adult that it was always meant to be well thank you so much, sir, for taking your time to do this.

SPEAKER_00: 43:11

I know I I pushed you to ramble. That was my fault, that's not yours. I set you up for that. Uh I want to thank you once again. That that is our episode with Thomas within. If you only take one thing from the it's the Tesos is being built to feel like one product, reliable when things break and fast enough for real-time use. If you want to follow the EtherLink governance process and read up on instant confirmation, come check out the official Etherlink channel documentation.