[Proposal] Trustless bridging for Zcash

[Igor]

tl;dr: A recently proposed TZE for native L2s would enable smart contracts on Zcash, but it comes with unsolved challenges around censorship resistance and liquidity fragmentation. We propose a more generic interface that would additionally support bridging. It would not only pave the path for programmability but also allow Zcash to tap into the liquidity of Ethereum with no trust assumptions. The proposed TZE is based on the existing Halo2 proving system, which is a strictly safer choice than the introduction of any new cryptographic primitive.

Introduction

Hello everyone, I’m Igor from Matter Labs (the core dev team of ZKsync). Our philosophy and values are closely aligned with the mission of Zcash.

We have followed a recent community discussion regarding the possibility of L2s on Zcash (1, 2, 3) with great interest. The ideas proposed by Abdel and the Starkware team are very interesting, and we would like to contribute to this conversation. In this post, we present a proposal that extends these ideas with a more generic approach.

The proposals discussed so far focus on minimizing consensus surface area. This post focuses on a complementary question: what trust assumptions remain at the system level once such a verifier exists, and whether those assumptions are acceptable for Zcash.

Potential L2 issues

The existing L2 landscape in Ethereum has two main problems today: liquidity fragmentation and censorship resistance. Both are being actively worked on with a lot of research and progress, but neither is universally solved. Our concern is that if the introduction of L2s will not be done carefully with respect to these problems, it can negatively affect the Zcash ecosystem.

Liquidity fragmentation

Unless the implementation is restricted enough to only allow a single L2 instance, there will likely emerge multiple L2s on Zcash. In Ethereum right now, there is a cluster of L2s that offer different use cases and trade-offs. Multiple leading L2s (e.g., ZKsync, Optimism, Arbitrum) are offering solutions to easily launch your own L2. The demand for this is also increasing, with the rise of AppChains.

This brings a problem: given that any amount of asset bridged to a particular chain becomes locked on the original chain, the overall liquidity becomes diluted across different chains. To solve this problem, a lot of effort in Ethereum is currently focused on cross-chain interoperability, which is meant to allow accessing funds regardless of the chain they’re bridged to. An example of such research is RIP-7755, but in general, to the best of my knowledge, all existing efforts assume some kind of stateful router implementation, which could be hard to implement in Zcash.

Censorship-resistance

Another issue is that while most L2 implementations are now secure enough to guarantee that funds cannot be stolen by a malicious operator, censorship resistance (e.g., the ability of the operator to freeze funds) still remains a problem. None of the top 15 rollups has achieved Stage 2 status on L2Beat, indicating that trust is still a requirement in the modern L2 landscape. Again, while a lot of work is being done here and more chains are introducing additional security guarantees, this is still a work in progress.

On Ethereum, additional protection measures are being regularly added on top of the base protocol to make it work (e.g., upgradeability restrictions, security councils, TEE verification, etc.), but on Zcash this can be problematic, since support for L2s has to be added at the consensus level, so changing the system will likely require changes to the core protocol.

Proposed solution

We propose introducing an abstraction that would generalize the multi-chain ecosystem for Zcash: instead of introducing an abstraction for implementing a rollup, we can introduce an abstraction for implementing a bridge as well.

This abstraction will exist as a TZE, for which public inputs (e.g., precondition/witness) would represent a state transition of two chains: the bridged network and Zcash itself.

This way, given a chain with already implemented censorship resistance and interoperability mechanisms, we can develop a single provable program to ensure the correctness of execution of both chains. As a result, we will be able to rely on the second chain to enforce the above-mentioned properties:

• If it is possible to enforce censorship resistance on the second chain, we can guarantee that no user will be denied exit back to Zcash without implementing additional protection measures in Zcash itself. Basic requirements for that are:
  • The second chain is sufficiently decentralized, with no single entity controlling block creation
  • The consensus mechanism of the second chain can be efficiently verified via a ZK proof
  • Exit requests initiated from the second chain are ordered, meaning that ignoring an exit request would cause the bridge to halt. This guarantees that even in an absolute worst-case scenario, where the decentralized network itself becomes malicious enough to censor a particular bridge user, intervention from the Zcash community is possible to fork the chain state and resurrect the bridge, allowing users to exit.
• If the second chain has an implementation of interoperability functionality, then interoperability can be reused via bridging to the second chain. An interoperability layer no longer becomes a requirement for the Zcash protocol itself.
• Since it’s a generalization, we can still represent an L2 through it if that is the goal. For a rollup, information about the Zcash consensus is still trivially accessible.

Rough outline of the proposed TZE

The exact TZE specification is to be defined; we need the community’s input for that. However, there are some basic properties that certainly need to be present.

• “Genesis”/”Create” mode: TZE output used to initialize a TZE. During the creation, we need to specify the initial properties for the STF, including (most importantly) a unique identifier of an STF. This is required to correctly match deposits to a concrete TZE instance.
• “Deposit” mode: TZE output used to lock funds being deposited. The TZE must have a value attached and can only be consumed by the corresponding STF TZE.
• “STF” mode: A representation of the transition of the STF from state A to state B. It can consume deposit outputs provided that they match the STF ID, and can produce transparent UTXOs for withdrawals. The STF precondition must contain state roots for two chains, and the provided witness must be used to verify that ZK proof produces expected root hashes for both chains.
• (Optional) “Force withdrawal” mode: Provides the ability to request an operation to be performed on the destination chain; if this request is ignored, this TZE output can be used to switch the STF into a withdrawal-only mode, where the only kind of transaction that can be processed is force withdrawals. Note that this is a hard requirement for any chain with low censorship resistance guarantees (e.g., ZK rollups with a single block producer), since even with unrestricted STF submissions, a single censored user might not have enough computational power to outcompete the censoring operator (assuming that only some operations are censored).

Proving system

Another point we would like to discuss is the proving system chosen for the TZE. A previous proposal uses Circle STARKs and provided an overview comparing this option to RISC-V.

Disclosure: Matter Labs uses a proving system that is based on RISC-V (airbender).

However, we believe that adding a new proving system to the Zcash implementation may not be necessary, given that Zcash already has an integrated native proving system: Halo2.

Adding a new proving system would increase the number of potential failure points in the system; for example, a bug can exist either in Halo2 or the verifier used in the TZE. Instead, we could require that the state transition have a valid Halo2 proof, which would limit the overall complexity of the proposal. This way, the only remaining failure case would be a bug in Halo2 itself, which would have drastic consequences outside the scope of the TZE anyway.

This should not be limiting for implementations, since thanks to recursive verification we can “adjust” the type of proof: the underlying system can use Circle STARKs, airbender, SP1, or anything else, and the resulting proof can be “wrapped” into a Halo2 proof, similarly to what many rollups do in the Ethereum ecosystem when wrapping FRI proofs into a SNARK for Ethereum verification.

Isn’t just having TZE for verifying ZK proofs enough?

In theory, implementing either a bridge or a rollup is possible using a single-mode TZE, but we believe that this would introduce trust assumptions that are unacceptable:

1. Without a way to lock deposited funds, the deposit process becomes trusted (e.g., a UTXO must be spendable by the STF TZE, but there are no consensus-enforced rules ensuring that the deposit will actually be faithfully processed).
2. Without consensus-level logic to form public inputs for circuit verification, the possibility of malicious STF operator behavior increases. If the requirements for a valid STF transition, as well as rules for upgradeability and exit windows, are enforced at the consensus level, users of any particular STF gain additional security by default; these constraints are outside the control of the STF operator.
3. If we are considering a rollup or bridge to a network without strong censorship resistance guarantees, the network must provide a way to request a force withdrawal from L1 (Zcash) that would require the STF to process this operation in order to continue functioning. Without this mechanism, achieving a censorship-resistant implementation of the STF is impossible, which would open the possibility of freezing user funds.

Proposed bridge: Ethereum

Given the above, we would like to propose the first implementation of this TZE: a trustless bridge to Ethereum. If this proposal is accepted, Matter Labs is committed to providing a production-ready implementation for the Zcash community.

We believe that Ethereum is a good candidate (compared to a dedicated L2), because:

• It provides sufficient censorship resistance guarantees, being decentralized with no single block producer. Thus, for Ethereum, the forced withdrawal mechanism is optional, which simplifies the overall design.
• Its consensus can be efficiently verified using existing technology, making it possible to deliver a working implementation faster.
• An established ecosystem exists for transparent ZEC use cases (e.g., DeFi), covering any functionality an L2 can provide (assuming transparent pools).
• The interoperability ecosystem is very active, which helps ensure that ZEC liquidity is not overly fragmented.

Probably the most controversial point here is the actual censorship resistance of Ethereum; however:

1. The current state of censorship resistance on Ethereum is strictly better than on any existing L2, whether Ethereum-native or potential Zcash-native. Additionally, Ethereum is actively working on improvements in this area, e.g. EIP-7805, which is scheduled for inclusion in the next hard fork.
2. Even in the case of censorship on Ethereum, it is still possible to recover the bridge by hard-forking the Ethereum state and creating a new chain using a state snapshot as the genesis state. This would require community intervention and consensus-level adjustments, but this is a worst-case scenario, and the key point is that even then, ZCash users remain safe.

We are ready to discuss this topic in greater detail if required.

Prototype implementation

We have prepared a proof of concept for this architecture.

You can find it here: https://github.com/matter-labs/zcash_eth_bridge

It provides a very basic implementation of a bridge to Ethereum, allowing funds to be bridged from the Zcash network to Ethereum (where they are minted as an ERC-20 token) and back. The project includes a demo showcasing the flow, as well as links to all technical details of the implementation.

Caveats

This proposal has three main caveats:

1. It targets the transparent pool only. Shielded pools are explicitly out of scope, which is hopefully acceptable; given the Tachyon efforts, introducing additional complexity there is probably undesirable.
2. The problem of multiple instances still exists. While multiple L2s can exist in parallel without affecting each other, multiple bridges to the same network will result in multiple versions of bridged tokens on the target network. This means the community will likely need to select a “preferred” bridge and be involved in its governance.
3. ZIP 227 (shielded assets) is not covered in this proposal, although it should not introduce significant additional complexity.

Conclusion

We would like to hear community feedback on the following:

1. What do you think about the idea of a generic TZE optimized for bridging purposes that can still be used to implement an L2?
2. What do you think of Ethereum as a potential target chain for the first trustless bridge?
3. What do you think about using Halo2 as the proving system for this TZE?

Otherwise, if you have any questions, I’ll be happy to answer.

[zancas]

You prioritize BTC over ZEC in your holdings.

This is interesting!

Isn’t it clear that BTC (ledger distinguishability) exposes participants’ agency to manipulation by observers?

There seems to me to be a judgement where the value of the “unalterable course” of BTC is given more weight than the privacy of ZEC.

By “unalterable course” I mean the inability to effectively update the protocol.

Is this a fair characterization of your relative valuation of BTC over ZEC?

Or, to put it another way:

Why do you hold more BTC than ZEC?

[gluk64]

Dear @zancas, the X post you’re referring to mentions my personal holdings. They reflect my personal risk appetite and have nothing to do with this TZE proposal. Happy to discuss it with you in the comments of that post.

[abdel]

Thanks @Igor for this proposal, and for acknowledging our work.

While there are many interesting elements here in this proposal, and I acknowledge some of the challenges, and recognize that there is merit to discuss them and the tradeoffs, I have mix feelings about this direction (or rather I think it should be a parallel path not instead path).

I will elaborate more if i have time but the TL;DR of my first initial impressions (without filters), for the Zcash community:

• my proposal is to EXTEND (as opposed to bridged utility) Zcash in a SOVEREIGN (not dependent on ethereum) way and FUTUREPROOF (quantum resistant unlike halo2)
• this proposal is to make Zcash a vassal of ethereum (exaggerating here to make the point), depending on ethereum, not extending zcash but on the contrary potentially cannibalizing it, and in a non future proof way

I am not saying there is no value in trying to bridge trustlessly to Ethereum (I think there is). My bottom line message is that it’s not a substitute in trying to have a more native way to extend Zcash base layer, that is more sovereign.

So I think it would make sense to consider both paths.

[Igor]

Hey @abdel! Thank you for the message, and thank you for editing it – the new version sounds more polite

First of all, this proposal is not a critique of yours; as stated at the beginning of the post, I am trying to look at the problem from a different angle. I did not see the discussion regarding censorship resistance and liquidity fragmentation in the previous threads, and I believe that these are valid topics to be discussed.

In the latest edit you write “or rather I think it should be a parallel path not instead path”, but there is nothing in my proposal that suggests accepting it instead of yours; it’s quite the opposite – the proposal starts with “In this post, we present a proposal that extends these ideas with a more generic approach.”. My perspective is that, as a result of the discussion, we should end up with a solution that provides the most benefits to Zcash, and it’s much less about “who suggested what exactly”.

The reason why I suggest considering Halo2 is that it is already used in Zcash. Utilizing it would result in the technical stack (and thus overall complexity) of Zcash not increasing. If/when quantum resistance becomes a concern, Zcash will need to solve it anyway.

Regarding the “making Zcash a vassal” argument: I think that you missed the core point of the proposal. The core part is a generic TZE that allows expressing both the bridge and L2. Ethereum is not a prerequisite, and it was suggested because a) we know for a fact that Ethereum consensus can be efficiently ZK-proven, b) Ethereum is one of the most active DeFi ecosystems, and c) frankly, it’s something that we have expertise in, so we can provide an implementation if Zcash community agrees with the proposal.

Finally, this is not a ZIP, but a proposal that asks for feedback, so if you see any weak/controversial points here, I’ll be happy to discuss.

[abdel]

hahaha yes I am going through a roller coaster of emotions since yesterday, and I probably over reacted.

I agree with MANY things you wrote here. And I am more confident we can find ways to collaborate potentially.

I will write more structured thoughts and we can continue the discussion.

[abdel]

MY STRUCTURED REPLY HERE

[zancas]

I’m not on X.

[mrkit2u]

As a fellow bridge builder on Zcash (building red·bridge with my team), I have some thoughts to share. First, how awesome is it that others finally have more interest in financial connectivity to Zcash?! Incredible. So exciting to see these projects take form.

Much of my thinking around this thread is based on how I see Zcash, and from reading the forum and talking with other Zcashers, I think many agree. I asked AI to create this image for me a few months back as the price began to go up.

Matter Labs, Starkware, and red·bridge are all hoping to gather Zcash golden eggs. Same is true for Ethereum, Starknet, Avalanche, NEAR, and Solana, all of which benefit from a financial connection to Zcash. Remember this: Zcash is the goose. The Zcash community owns the goose.

With this in mind, let me begin by describing some boundaries that I see, where Zcash’s role begins and ends. The way I see it, Zcash’s value proposition is unstoppable private money. Not a controversial take, but perhaps deeper than it first appears. This is the north star of the Zcash community. It is a profound responsibility, it is offered by no one else, and providing this to the world is within our control through the Zcash chain.

A wise man once asked me, “You know what one word describes your trying to control something outside of your control? That word is suffering.” We as a community control Zebra. We control the private pools. We control the consensus protocol. We control TZEs. And so on.

However, we do not control what happens to bridged ZEC once it is “in the wild.” Specifically, we do not control whether it is still unstoppable private money. From the Zcash community’s point of view, concern about ZEC stops once it’s locked in the bridge’s escrow wallet. That’s the Zcash use case–to lock it up for safe keeping.

And that bridged ZEC? It is not ZEC. It is bridged ZEC. Whether it’s ZEC.rbr, ZEC.sn, ZEC.eth, or whatever name you give it (or even if you deceptively call it “ZEC” even though it’s on NEAR or Solana), those are different. As we say, ZEC is a coin, and those other things are tokens. When we first proposed red·bridge, I compared it to the International Peace Bridge between the USA and Canada: connecting two different countries with two different governments and two different monetary systems.

With this framing in mind, I have some critiques of what @igor and @abdel have said.

Igor, you deem Ethereum a worthy enough chain to have bridged ZEC on it, specifically that it is censorship resistant enough. You’re also concerned about liquidity, both about fragmentation and quantity. To me, based on what I’ve written above, these concerns don’t matter one bit to Zcash. Zcash is Zcash, and what happens across the international border is not a matter of concern for Zcash. The wider crypto ecosystem is the wild west, and Zcashers spending time worrying about how bridged ZEC tokens are used in it is the very definition of suffering. Blur this line at your own peril.

To frame the conversation, you suggest a “multi-chain ecosystem for Zcash.” IMO, this does not exist. Zcash stops at the border, and then there is a bridge, and beyond that, there are tokens that the bridge produces that can be used in the foreign land. Some will be private (with various gradations and qualities of privacy), and some will be transparent. This is not Zcash’s concern. Is there enough liquidity in the bridged ecosystem? Not Zcash’s concern. Can bridged ZEC tokens be censored? Again, not Zcash’s concern. The Zcash community caring about any of these things in respect to a particular bridge and foreign ecosystem is suffering.

I’m not saying that bridge builders—and indeed builders of the destination networks—should not be concerned with these things; we should! And for us, it’s not suffering; you and I control at least how the bridge software works. So, Igor, I’m glad you’re thinking about these things yourself. But in the context of this Zcash forum, those are problems for you and me to address with our respective bridges and their communities; they are not burdens for the wider Zcash community to bear. You need a TZE for your bridge to work? Focus just on that.

You continue:

The problem of multiple instances still exists. While multiple L2s can exist in parallel without affecting each other, multiple bridges to the same network will result in multiple versions of bridged tokens on the target network. This means the community will likely need to select a “preferred” bridge and be involved in its governance.

As you may have already guessed, I believe that Zcashers caring about this is just more suffering caused by bad boundaries. Why should Zcashers care if there are two bridges to the same network? Why would Zcashers need to be involved in bridge governance and/or pick one conical bridge? It’s actually to the Zcash community’s advantage to have a number of different bridges to choose from. Bridges are notorious honeypots for hackers, so having multiple paths to DeFi seems like a great way to diversify risk. For instance, on Avalanche, both BTC.b and WBTC are present without problems. Similarly, throughout cryptocurrencies, there are a number of competing representations of USD stablecoins. These diverse solutions lead to robustness.

All that said, here are some answers to your questions:

1. What do you think about the idea of a generic TZE optimized for bridging purposes that can still be used to implement an L2?

I think it’s awesome, but if Starknet would like a different TZE, and the Zcash community approves, perhaps they should have their own.

2. What do you think of Ethereum as a potential target chain for the first trustless bridge?

Seems fine. red·bridge will be bridging to Ethereum too (direct from Orchard!).

3. What do you think about using Halo2 as the proving system for this TZE?

I think it makes sense for this TZE to use Halo2 since it is already in use elsewhere.

I think the Zcash’s community’s involvement (as a whole) should stop with the TZE since the rest of what you propose–the exact bridge you build, etc., and how the token works on Ethereum–is outside the community’s control. (I do think you should establish your own community around the bridge to help you answer these kinds of questions, and membership may overlap.)

---

Abdel, I could not agree more that Zcash becoming a “vassal of Ethereum” or just depending on Ethereum would be a very bad thing for Zcash. I think Igor, as a member of the Ethereum community, blurred boundary lines in his proposal, and I hope that my writing a short book about Zcash, Boundaries and Suffering has addressed this concern.

There is absolutely no way the Zcash community should take on as its responsibility what happens in the wider cryptocurrency community. I even find it concerning that in Zashi, the NEAR Intents Pay and Swap buttons look exactly like the Zcash-native Receive and Send buttons. In two taps, you can be swapping ZEC coin for $TRUMP or $MELANIA, the poster children of memecoin chaos. (cc: @jswihart)

Boundaries are important. Those buttons should look different. Zcash needs to be very clear about what it is and what it is not.

Similarly, I would hope Starknet keeps equally strong boundaries, focusing on the necessary connection points (TZE or otherwise). Your characterization of a Starknet L2 on Zcash as “native” is concerning to me for the same reasons. It’s fine for the L2 to settle on Zcash, but it is a separate entity with a separate governance structure, separate development teams, and so on. Also, if you need one TZE and another one is needed for generic bridging, so be it.

---

As many of you know, I started off as someone more from the Avalanche community than from Zcash, but what came into clear focus for me at Devconnect in Buenos Aires this November is that I have developed a very strong connection to Zcash, and while I see Avalanche as an incredible ecosystem for businesses, consortiums, games, defi protocols, institutions, and even sovereign states to launch their own highly connected L1s, what Zcash is doing is simply amazing–world-changing–and it’s an honor to be on this voyage with everyone here.

[Igor]

Hey @mrkit2u, thanks for the message!

I interpret your point as “Zcash community should focus on the minimal surface of changes possible, and everything else should be handled by the people using the introduced minimal technology”. I can understand this sentiment, but not sure if I fully agree with it.

The technology indeed should be self-sufficient enough not to impose the burden of thinking about “outer world” on Zcash developers and community, but there is a difference between providing a minimal possible solution and providing a solution that would actually allow not thinking about “outer world”. If the introduced interface doesn’t provide enough safety by default, it can result in a situation where people using Zcash-native technology are put into avoidable risk, which could affect Zcash, even if the problem lies outside of Zcash. If we don’t take it into consideration, then the minimal possible solution is to actually do nothing. It’s already possible to have a trusted bridge on Zcash, so we can say that people who want to bridge Zcash elsewhere can use said trusted bridge. But if we are discussing the possibility of trustless bridging, then, IMHO, it makes perfect sense to define safe boundaries.

Igor, you deem Ethereum a worthy enough chain to have bridged ZEC on it, specifically that it is censorship resistant enough.

It’s not exactly what I said. My point was that:

1. Ethereum already provides the functionality that is missing on Zcash, so it can be used instead of a dedicated L2.
2. Ethereum can be efficiently ZK-proven (multiple implementations for ZK-based light clients exist), which brings it from “theoretical” candidates to “practical”.
3. Censorship resistance is a major concern, and generally, we need a force exit mechanism for bridges. However, given the current state of censorship resistance on Ethereum, it is possible to avoid this mechanism for Ethereum (and not possible for any given L2) if reducing the implementation complexity is the goal.

I’m not saying that Ethereum is a better chain than others; what I’m saying is that Ethereum can be a better candidate to open Zec for DeFi and other use cases than a dedicated L2.

To me, based on what I’ve written above, these concerns don’t matter one bit to Zcash. Zcash is Zcash, and what happens across the international border is not a matter of concern for Zcash.

This is a valid stance, and I’m not arguing that this path can be chosen. What I wanted to say is that Ethereum initially followed the same approach, but with the L2 ecosystem developing there, the problem became big enough for Ethereum to start working on it as a part of the core protocol. Depending on the path that Zcash community will choose, it might happen that the problem will become big enough for Zcash as well, and my point is that unlike Ethereum, Zcash itself is less positioned to solve it, at least given the current state of ecosystem research, since the existing solutions are mostly based on the persistent state, which is harder to implement on Zcash.

As such, thinking about the problem early and delegating the solution could be a viable option.

To frame the conversation, you suggest a “multi-chain ecosystem for Zcash.” IMO, this does not exist.

Again, I’m not suggesting a “multi-chain ecosystem for Zcash”; I’m saying that if the introduced primitive can be used to instantiate multiple bridges/L2s, it most likely will be used for that purpose. Ethereum didn’t actively plan a multi-chain ecosystem either, but currently, it has a lot of rollups with different trade-offs. And if it happens to Zcash, again, the problem might become big enough to affect the core protocol, similarly to how it happened with Ethereum.

Why should Zcashers care if there are two bridges to the same network? Why would Zcashers need to be involved in bridge governance and/or pick one conical bridge? It’s actually to the Zcash community’s advantage to have a number of different bridges to choose from.

If the community does not see it as a concern, it doesn’t have to be involved. This point was listed as a caveat of my proposal – I did mention that a multi-chain world can be problematic, based on the Ethereum ecosystem experience, but did not provide a solution for this problem. Being involved in a preferred bridge governance is one possible solution. Not being involved is also a solution. Which solution is better for Zcash, specifically, is for the community to decide.

I think the Zcash’s community’s involvement (as a whole) should stop with the TZE since the rest of what you propose–the exact bridge you build, etc., and how the token works on Ethereum–is outside the community’s control.

Probably, the phrasing in my post was misleading. My proposal is mainly about the TZE specification. The Ethereum bridge is one possible implementation, and it is described here to demonstrate how it solves issues presented in the proposal. And in case Ethereum is considered a good target bridge that the Zcash community will benefit from, Matter Labs will be able to work on an implementation. Whether the bridge will be maintained by Matter Labs or given to Zcash is, IMHO, less important – the core point of this part of the discussion is whether such a bridge is needed in the first place.

Abdel, I could not agree more that Zcash becoming a “vassal of Ethereum” or just depending on Ethereum would be a very bad thing for Zcash.

This response was addressed to Abdel, but I just want to mention that I already addressed this point above. I do not suggest any kind of dependence. The proposed TZE is generic; it can be used for both expressing a bridge to any network, given that its STF can be ZK-proven, or an L2.