Why Ushuaia Matters For Tezos X

SPEAKER_01 0:13

Jahan, thanks for joining us. There's a new Tezos protocol proposal on the table called Uswaya. And this one sits pretty directly in the path toward Tezos X. A lot of this proposal lives below the surface, data availability, roll-up infrastructure, faster confirmation, and test network for things Tezos may need later. Before we break any of that apart, what is Uswaya trying to make possible?

SPEAKER_00 0:46

Yeah, it's um yeah, it's a protocol that actually uh delivers a lot, uh, a lot of uh of features, uh, but the ones that are activated that are not under what we call a feature flag, I will come back on this later, uh, are indeed focusing on uh um the back end, the infrastructure, the implementation details of uh uh very important aspect of the protocol required to make Tesos X a reality uh due in 2026. So that's uh that's the main uh goal of uh of Ushuaia. Um yeah, and it can be a bit uh difficult for the community to understand the the yeah what's at stake. Uh no no no pun intended uh with uh with this uh now if someone only remembers one reason this proposal matters, what should it be? So it matters uh because it um uh it uh install an um infrastructure for Tezos X. So the DAL. The DAL uh uh has a bandwidth that increases. Um there are uh also some work on the PVM uh that uh we try to prepare for very something very uh um challenging that is a hot swap of the p of the PVM. It's quite uh I think we are the first to do that actually. Uh so it takes time and you cannot do it in just one shot. Um, and uh yes, there are also uh some features that we decided to put to make inactive on mainnet, but active on test nets to get the feedback of the community on uh uh something that is really uh concrete, I mean very specific. The actual protocol running on testnet with this feature active so that they can try and give us some feedback. It's not just a proposal, a design. We want them to try, we want them to see if their tooling adapts to it. Uh, so um, that's the reason why this uh protocol is uh has actually one, two, uh three features under a uh that are passive, not active on mainnet, but active on testnet. I think that's the first time we have so many feature flags uh uh in a protocol.

One Ledger Across EVM And Michelson

SPEAKER_01 3:26

There's a lot going on. Now, the Tezos X article talks about EVM and Mickelson apps sharing one ledger and interacting in the same transaction. That sounds clean from the outside, but most people are used to crypto feeling split across chains, bridges, wallets, and app environments. Can you give a simple example of what that shared ledger idea could actually look like for a user or a builder?

DAL Bandwidth Jumps To 10 MB/s

SPEAKER_00 3:54

Yeah, so um first you you have to understand why people are uh using one blockchain over another. There are many reasons, of course. Um sometimes it's just marketing, it's just that uh that's the the mind share. Oh yes, we use this one. I've been told it's a good one, I choose this one. Okay. But uh when it comes to builders, in general they have more uh rational uh um reasoning in place, and uh um one important aspect of it is uh the capacity to compose your D app with other apps, and also to use uh the liquidity that is available on this specific blockchain. And what happens is that uh with the diversity of blockchains that we have today, this the liquidity is spread everywhere, and it's hard to have both to have, for instance, uh the benefit of the Mikkelson uh environment to uh verify formally that your smart contract has no bugs, and also profit from let's say the liquidity of DeFi applications that are mostly developed in the EVM uh ecosystem. So the whole idea of uh of one of the idea of Tesla sex, but the one that we are talking about today, is um to say, okay, that's not a problem. It's not a problem to choose the uh ecosystem the ecosystem, the environment to develop your smart contract that actually fits your technical need. And you will have but because you will still have the possibility to atomically interact with another ecosystem that has other aspects that are also uh important and attractive, like let's say the liquidity of this specific DeFi application that you really want to be able to interact with. So TP, I have very concrete examples that François Thier, the product manager of TeslaSecs, is using all the time. Is uh, you know, you want to deploy your uh uh NFT marketplace, let's say uh uh Object, Object AT, of course, they are developed uh in Mikkelson, so they they they want to deploy in Mikkelson, but but they imagine they want to let their users pay in uh USDT or uh I mean some stablecoin that is deployed uh on Etherlink in using a single transaction. So having uh the swap done um in in the transaction that also uh uh buys the some NFT on the marketplace. Um if you had two blockchains, it's just impossible. You you have to do multiple transactions to to go through a bridge, it's not always safe and it it takes time. Uh with uh Tesosex, it's just one transaction. Okay, so you know it's done or it is not done. Okay, so it's it's it's a way to reason about your system that is far far simpler, but also give you uh uh guarantees that you uh uh that are difficult to to um seriously uh provide uh with a bridge. So that's the point, and uh we will have some uh some app to demonstrate uh um the benefit of Tesos X in the future, but I want to keep them uh a bit secret for now, so you'll see. Okay, secret, yes. I want to keep them secret for now. Secrets, yes.

SPEAKER_01 7:44

Now Ushuaia is not the full Tezos X vision by itself, but it feels like one of the upgrades that prepares the ground for it. If Tezos X is the direction, what is Ushwaya unblock that the roadmap can't just assume will be there?

SPEAKER_00 8:03

Yes, so um again, I would try to keep things uh high-level enough, but there is something that uh we have been uh delivering for a long time now. It's the DAL, you know, the DAL has been uh there for a long time on main on Tesla main net, uh, which is not uh something that other chains uh have, all have uh quite the opposite. We're only a few blockchains to have a a DAR, but our DAL, and it was completely uh intentional, had a um a bandwidth of uh uh something like uh uh uh sorry, six um 0.66 yes 0.6 uh kilobytes per second. It was just to start with something, something uh reasonable, not too ambitious, just to check if the system in production works. Uh but you we knew that I mean it's meant to scale. Uh essentially, you can change some parameters and add more nodes in the system, and you know you would get a higher bandwidth. And that's what we did um uh with uh Ushuaia. We changed some parameters, we make sure it works because you know before we make a proposal, we do uh intensive uh testing uh at nomadic labs and tree tech to make sure everything is ready and safe for production. And now engineers, co-engineers, they're confident. 10 megabytes per second is something that we can do with uh the current hardware recommendation, with um with I mean under the assumptions that we are currently using. So we decided to activate that and it's working, which makes uh the the the bandwidth and the publication, the bandwidth used for the publication of transactions of Tesossax uh not the bottleneck anymore uh for uh to have ice throughput. So typically, if you only look at the bandwidth of the of the dial, you can uh I think um publish one 100 and uh sorry, 100k uh tp uh transaction per second with uh no no issue. You can even do a bit more maybe. But uh so it makes uh this problem a problem of the past. We don't have to think about it anymore and focus on the on the uh the other important components of Tesos X. One of them is the Wasm uh PVM that we need to be migrated to uh to the RISC-V PVM and a new storage system. So we we we are trying to change uh the uh very fundamental infrastructure that uh Etherlink and then Tezos X when Etherlink will become Tezos X, that's on top of which uh this system are running. So imagine you have a car and you say, Okay, it's running in production, and we want to change the engine without stopping the car. Okay, so that's what we are doing. So it's it's like you know, uh uh you you can picture that as uh you you have someone uh opening the the car and uh doing some stuff inside, and at some point say, Okay, we have to engine, let's push this button, and uh now it's the second engine that we that we'll uh use. It's changing technically, I can tell you, and you don't want to mess that up, otherwise the the blockchain will just stop. Your car will just say, No, no, it's not working. Woo! Nothing is working anymore. So that's the um the change in front of us.

SPEAKER_01 11:48

Well, since it's crypto, is it a flying car?

SPEAKER_00 11:51

Yeah, of course it's a flying car.

SPEAKER_01 11:54

Okay, so Ushuaia raises Dow bandwidth from around you said 0.66 per second to about 10, right? Yes, it's a times 15. Yeah, roughly, right? So that's a big jump on paper, but the real tension is capacity, not and participation, right? So, what does that added capacity make possible and how do you increase it without making baker participation too heavy?

SPEAKER_00 12:21

Um uh actually, yes, it increases throughput. It's uh the ability to uh to publish uh in the system larger transactions, larger blocks. Okay, and um and it opens new use cases uh typically um privacy. So with privacy you need to publish on the uh on the network um proofs, ZK proofs that are um in general uh large uh with respect to the I mean a transaction in in uh uh on blockchain is uh the order of magnitude is dozens of uh kilobytes. Uh ZK proof is more uh hundreds of kilobytes. Okay, it's one order of magnitude higher, and you want if you want good throughput, you need to produce and to uh share them um uh at a good pace, and uh with that it's possible to uh to to actually integrate that kind of use cases.

SPEAKER_01 13:28

What had to improve technically to make that jump realistic?

SPEAKER_00 13:35

Um well it's uh the the architecture uh of of the DAL uh the design is still the same as before. Uh and um what we did is to uh optimize the code, the implementation of the design, to uh check, as I've said before, to validate that it it works under the hardware that has not changed. We we don't ask bakers and participants to the infrastructure to actually upgrade their hardware. That's very important to us for the accessibility of uh of the blockchain. And uh and that's it. Um to uh yeah uh the next steps for the DAO uh may require some change in the original design, but as I've said before, we have plenty of room now, so there is no need for now to uh to revise this design.

SPEAKER_01 14:32

Another change is that the DAO data can become available faster. So instead of waiting through a fixed delay, the network can move once enough attesting power has seen the data. Where do those seconds actually matter?

SPEAKER_00 14:46

Oh uh yes, so indeed uh that's something I should have said. Not only we increase the bandwidth, but we also introduce a new mechanism uh called dynamic lag. Uh the idea is uh um simply that in the past, again, by security, just not to not take too much risk in production. We said, okay, let's let's take it easy and start uh uh I mean humble and just see if it works in production to wait for um 11 blocks that all participants in the DAL have received the information. So it's it's a quite long time, but it was a security for us to make sure that uh the DAL was uh you know stable, etc. And uh we did that for the first version and we start measuring, okay. Now in practice, do we need to wait that much? And it happened that actually two to three bucks are enough. So we introduced a way to um to wait for uh not a fixed amount of time, but an actual uh percentage of the what is called the attestation, just people saying, Oh, I received information, I'm I'm okay. You just look at the essentially as a network saying I'm okay, and you say, Okay, now that you have uh enough of these people uh saying I received the information, you say now it's official, this uh information has been published. Okay, and uh and in practice it looks like two to three bucks are enough. So it means in practice that we we go from uh hundreds of seconds uh or a bit less to uh 20 seconds to wait for a publication to happen on DAL. Why is that important? Well, it's important for any users of the DAL, but for now we have only one that is uh the layer two, Tesos X, and it's used to publish the blocks from uh the sequencer to um the official L1 protocol. So you may remember or not, but because it's a bit technical that uh uh a roll up, what it does is to uh use the layer one as a settlement layer. So it says, okay, uh that's the information that I gathered from the sequencer, and now I want to make it official. So I publish it on the on the L1, and the consensus will decide what is official. Um and and uh it's important if and only if you need to uh uh I mean in practice, if you need to withdraw something from uh the L2 to the L1, because in practice people just trust the sequencer because uh the sequencer is assumed to be honest. And uh if you just work if you just uh interact with the L2, it you just interact with the sequencer and it works in practice. Now, when you want to withdraw, it's a bit different because it's on the L1 to make sure that the two protocols agree about the reality. So you have to wait for the L1 to receive the information. That's why this uh Dell lag is important.

Governance Pace Versus Rollup Pace

SPEAKER_01 18:04

Okay, all right. I'm gonna pivot here. Tezos governance is deliberate by design, that's one of its strengths. But role of development can move on a different clock, especially with Etherlink and Tezos X. What friction showed up between those two timelines?

SPEAKER_00 18:23

Yeah, uh, they are completely different, completely different pace, and indeed, um, you can uh they're decoupled. You have a protocol with uh some uh OCaml code uh written for layer one, you have a another protocol written as a roll-up kernel in Rust uh for um for the layer two, and you can change uh the layer two without changing the layer one and uh the other way around. So these two are decoupled and uh and but at the same time they have some dependencies. In general, we don't we try to minimize these dependencies. But in this case, as I've told you, when you want to change the engine, the actual semantics, the fundamental aspect of uh uh your roll-up semantics, it is it has to be done also at the layer one level. Because that you may remember that the layer one level is the uh source of truth about uh what is uh a valid interpretation of the layer two protocol. You don't have to trust the sequencer, the protocol will check in the end. So the sequencer cannot do anything wrong because at the end of the day, the pro the protocol, the layer one protocol, is uh the one that will say, No, no, I know I know what is valid, and you did something uh dishonest, and and then you can uh you can um uh make sure that the the the fonts are not uh uh are still safe. Um so uh it's two different from an engineering perspective, it's two different ways of working uh that we have on layer one and layer two. For many reasons, they are not uh I mean uh the the the layer one is this is really our security uh layer, our settlement layer. It is far more complex, it has a consensus. It I mean, that's the whole point of our architecture to have uh a very robust but complex uh layer one, on top of which you have a uh a protocol that is focusing on application uh for the layer two. And so these two are not working at the same pace at all. So we started to put in place uh um uh feature flag that are not activated by protocol parameters as before, but that are governed by the layer two. So this ability to have components on the layer one, the one that uh the layer two depends on, that are inactive by default when the new protocol activates. But at some point, when the layer two protocol is ready, it can send a signal to uh the layer one protocol and uh activate uh the feature for the specific rollup that you're that you're looking for. So it creates um an optionality uh that is very useful in practice because it means you can do, for instance, some experimental roll-ups that use some experimental feature of rollups deployed in the layer one. But uh, for instance, uh on Tesos X, uh, you want to take it again and uh and only activate when you know the the feature is is mature. So you have uh a lot of ways to uh Um to make this um uh far more uh pragmatic uh and and decouple the two uh development pays. So that's indeed uh something that we ship in Ushwaya. It's quite simple, uh but it's very, very useful for developers, for core developers.

SPEAKER_01 22:20

We we've talked through the clean version. Now I kind of want to talk about where this gets difficult. What assumption behind Ushwaya was hardest to validate?

SPEAKER_00 22:32

Okay, um, everything that is under a feature flag are things that we know we could not decide uh by by ourselves. Um that's one thing. Uh there are actually that's one big thing, and inside there are several uh of these cases. And there is something else also that happened during this protocol. Is I think in our um during, you know, we organize this uh feedback loop with the community. We we say, okay, we have a project of proposal, but we want to share it as early as possible with the community to get the feedback to know what we will actually put in the proposal. And there is something that we we decided not to put in the proposal, uh, a change in the in the way we uh we we do the governance typically is something that we decide not to put in the proposal. So it's something that we uh immediately uh removed. Now coming back on the feature flag, the idea is to uh offer uh a design and an implementation and uh discuss the um you know uh the 20%, the last 20% with the community based on uh very um concrete implementation, something very specific. Okay, we have a testnet, test it, tell us uh how it looks like, do some simulation, give us feedback, let's let's discuss the latest uh aspect of the design. So typically for unshrined uh liquid staking, we uh we did the work on the security aspect, because that's uh something that we don't want to uh that's of course critical, and also uh we believe it has no um uh uh no room for discussions. It's clear what has to be done there, and it must be done very, very uh rigorously. But on the token economics, for instance, uh I don't know the latest uh the the last details on the on the um on the fee for bakers, for instance, or uh uh some aspects uh to relate the governance with the liquid staking, etc. Something that we wanted to discuss with the community. So we said, okay, let's put that under a feature flag, activate on a test net, start the discussion on uh Tezos Agora and uh and and uh refine for the next version of the protocol uh the the last details. So that's that's uh quite uh a long process, but I feel that the only way to get uh uh a consensus on uh uh the this next version of the of the Tezos protocol.

SPEAKER_01 25:16

Now, Ushway also includes, like you said, testnet facing work that's not a mainnet launch, but it points toward things Tezos may need later. The two pieces here are STES, which tests protocol native liquid staking, and then TZ5 accounts, which start testing a path toward post-quantum account support. How should people think about these pieces without mistaking them for mainnet launches?

STES And Protocol Native Liquid Staking

SPEAKER_00 25:44

Yeah, so um for these pieces uh uh let me start with the simplest one, uh the TZ5. Okay, TZ5 is it's easy, it's yet another uh cryptographic uh scheme, but this one is uh resistant to post-quantum computer. And we we want uh to uh start as early as possible, uh turning Tezos into a post-quantum uh resistant chain because uh it's a bit uh surprise for a lot of engineers, but uh post-quantum computers may come earlier than uh what we believed. I for a long time I thought not before uh 2050, like I will be you know retired, no problem. Actually, this problem will come probably uh earlier than that. So we want to go through the full stack of the Tezos protocol and say every cryptographic uh pieces that is used today in the protocol, and there are many, uh, needs to be uh uh revisited to be uh resistant to post to post-control. So we started with the simplest uh part that is only to add another encryption scheme, um, another um uh family of signatures, this is E5. But um we uh finally decided to put it under our feature flag for the following reason. Uh we want to, in the next version of the Tezos protocol, we want to propose to have uh what we call stateful account. And uh it's uh sorry, it's a it's a spoiler uh for the even the next proposal. I'm sharing that today. Uh, but it's very important because it's uh uh uh an idea uh that um I uh when I started with blockchain, I was surprised we didn't have that. When you you you have an address on on Tezos, let's say some TZ1, okay, you know it's uh the hash of a of your public um uh public key. So there is uh something, two things that are coupled, your identity on the chain, because your address is how you are uh identified on the chain. And at the same time, the cryptographic uh uh keys that are used to authenticate you to actually it's your password. In some sense, it's it says uh that's the secret that you own, and that makes your actions on the blockchain uh um uh uh verified uh as you being the one uh that does it. And these two are completely coupled. So it means that uh if you have a TZ1 and uh post-quant post-quantum uh uh I mean quantum computers arrive, you're screwed. Okay, that if you if you keep that, because uh your secret can be can be cracked now. So what do you do? Either you ask everyone to recreate a new uh TC5 to be secured and to move the phones uh here and there, but you you need the attention of people to do that. Maybe they won't uh be in front of their computer or just don't listen to you. So they will they won't do it. So you could do it as a protocol level during immigration, you force it, etc. But it's not great, it's not what you want, and you don't want people also to change their identity and say, Oh, you were known as this TZ1, now that's your new identity. Maybe they they won't realize that and they will feel uh something wrong happened. So that's a feature we want to add uh stateful account that will allow you simply to keep your TZ1 as your identity, but programmatically change the way uh you are authenticated. So typically it creates a pass, a migration path for our users, because we will tell them now you can keep your identity and and and use a cryptographic um a post-quantum cryptography. That's fine. And for people that are not paying attention during the migration of the protocol, we'll be able to say, Oh, you are this easy one, but while you were sleeping and go to uh vacation for such a long time, post-quantum computer arrives and we secured your font by deactivating your uh your your key. So we you will be able to have a way to uh just to change your key with a post-quantum one, and the fonts are safe. So it's uh it's a way to protect fonts, to prepare people to migrate. So that's a feature that we will uh uh have in the next uh protocol proposal, and we wanted people not to immediately jump to TC5 because we'll have a better UX in the next proposal. So we we want tools to be able to integrate them, uh, to integrate the cryptographic scheme, but we didn't want the users to immediately migrate to TZ5 because we'll have something better in the next uh proposal. So that's the story, it's a bit long, but it's quite simple. And I think that's a good uh good call to uh to allow Tesos to uh Tesos user to move to post quantum uh to the post-quantum area. Uh now I have to talk about the other one. You remember the Estes? Yeah, this one is um uh is um very interesting uh and uh beautiful to be honest. It's about uh um introducing uh liquid uh stacking, so this ability to stake but keep your token liquid. And you you know in the today in the layer one you don't have that. When you stake, your uh your tests are uh locked, you cannot use them for DeFi or whatever. And uh what happened in other chain is that uh some uh smart contracts were deployed on the chain, and they say, Okay, we create a token that will be um that that will that you will receive in exchange of your stake uh coins that are completely equivalent to them, but you can use the the other one uh uh in a liquid way. Okay, so it worked very well. For instance, in uh Ethereum you have the I think it's STF that allows you to uh um to both stake and have uh a liquid token to use that is equivalent to your original F. But but this um token liquid tokens have been deployed by uh you know uh actors uh that are uh um centralized entity. Okay, when you do that, you give a lot to uh the actual administrator of the smart contracts, they are multi-six, they are their controls, so your tokens are not really owned by uh yourself anymore. They are you trust, of course, and they cannot do anything wrong normally, but it's uh it's not what we like. We like the decentralization uh to be kept. And that's why we proposed uh we propose in Ushuaien uh this unshrined uh uh est a liquid token following the same principle, except that there is no owner of the contract, it's managed by the protocol under the governance of the protocol, and all backers can participate in this uh in this pool. So it means that uh the the the uh the you the user of uh of this S test won't have to choose one baker of the other, they they will uh keep um um actually a very good uh ownership of their uh of their uh stack test. So that's I think a brilliant idea. Uh there is a white paper explaining all the technical details. It's quite uh actually uh I can say that because I I was not I helped a bit in the design, but I I was not really the author of this design, so I can say that very simply. There have been some very smart choices in the design of this uh of this uh uh liquid uh uh staking. Uh look at the white paper, it's brilliant. And um and uh we have been able to implement this design. And now, as I've told you before, there are some token economic aspects of uh that needs the input of the bakers. We need to run simulation, we need to know what are the final touch to put to put that in in production, and again, feature flag, test net, people uh make make their experiments, see what makes sense, what does not, and we'll iterate and we'll find uh with the community a way to converge to something beautiful.

SPEAKER_01 35:15

Well, Jan, you work close enough to the protocol to see both the roadmap and the friction underneath it. A year from now, if Ushuaia did its job, what should people be able to build, use, or assume on Tezos that feels harder today?

Where To Track The Proposal

SPEAKER_00 35:33

Uh that's in very interesting idea. Uh okay, so um in a year. I can tell you in uh less than a year, Tezos X will uh will uh I mean in uh a month or two, uh something like that. Tezos X will the MVP, the the first version of Tezos X will actually uh be on mainnet. So uh and that will unlock already a lot of things, as I've told you before. Now, in a year, we'll have even more things. Um, typically, I assume that uh uh Tezos will be post-quantum resistant because we are working super hard. We'll probably have far more uh features for privacy. Uh we'll um have uh Tezos X iterations uh done, so maybe two to three more iterations of Tesos X. So you can imagine uh the RISC-V uh having replaced the Wasm PVM, you can imagine even uh a new runtime. So in the first version of uh of Tesos X, you will have the EVM runtime and the Mikelson runtime, but our goal is to add more runtime, so I suppose we'll have time to uh implement more. Um what will happen? Uh you will have these stateful accounts that I've uh I've explained before. So ways to have sponsored operations, to have uh a very um neat way to administer to handle your the authentication of your uh of your of your account. Um yeah, there are many, many things, uh many ideas in in in on Tesla. So I I I probably forget uh I'm probably forgetting some of them, but that's the big picture of it. Um and uh it's quite exciting. Um yeah, so that's I hope it helps you with the vision of that's a great place to leave it.

SPEAKER_01 37:36

I think that's awesome. Ushwa is one of those upgrades where a lot of the important work sits below the surface. The Dow roll-up infrastructure, faster data confirmation, baker participation, and test network around STES and post-quantum accounts may not be the easiest thing to explain in one sentence, but they all connect back to the same larger question. What has to be true underneath Tezos before Tezos X can feel real from the user side? Jan, thanks again for walking us through it. For anyone listening, you can follow the Ushwa proposal on Tezos Agora. Read more about the Tezos X roadmap over on Spotlight and keep an eye on the testnet pieces as they develop.

SPEAKER_00 38:26

Thank you. That was great. Bye-bye.