Transparent & Shielded DEX with Maya Protocol

Community Grants Applications
1

Hi all,

Thanks,
–h

17 Likes
2

Link is wrong, bro:

I’m definitely in favor of this grant. Think it’s a great idea. One question:

Deliverable 5.1
Integration into YWallet

Do you foresee a follow-up grant with integration into Zashi? Is that even something Zashi wants to add to it? cc @joshs

1 Like
3

I only speak for ywallet. What the other wallets do is up to them.

1 Like
4

Highly interested.

5 Likes
5

You have my vote.

1 Like
6

To give my full opinion, with complete belief hanh is an extremely competent developer who very likely could do an integration,

  1. I personally find the rate a tad high (which I note mainly as I gave prior opinions of a slightly lower rate and want to ensure my consistency, not because I find this rate egregiously high).

  2. This proposal supports sending to shielded addresses yet cannot receive to one (due to using a transparent vault). This means any desired integration of ZSAs would require a notable rewrite, right? Specifically, moving to FROST, generation of shielded inputs, the scanning logic… It also wouldn’t survive any deprecation of the transparent pool.

  3. This aims to support sending to shielded Zcash. Has any thoughts been given to actual solutions for how you cannot place a UA with an Orchard component within a Maya Protocol memo encoded onto the Bitcoin network (nor similar networks), or solely the existing comment it’s presumed workable (such as via a new encoding. as the raw bytes should fit, except then Maya would have to sign off on non-ASCII memos)?

  4. The document claims users will be able to use both transparent and shielded addresses. In Maya, single-sided liquidity may be added and removed by an external address. How would you allow a shielded address to so control liquidity given its non-identifiable origin?

  5. The traditional THORChain Bifrost design requires validators be able to scan and identify outputs on-chain. How do you plan to identify an output on-chain to a shielded address?

I think a lot of my questions here summarize as believing this document is under-specified and does not yet have enough technical details to confirm any integration can meet the claims stated. Sorry if this cuts a bit too much into milestone 1, the dedicated design phase, yet I do believe protocol viability should be confirmed. The above edge cases seem glaring and immediate enough.

2 Likes
7

Personally, I’m OK with this.

But I think you raised some great additional clarity questions.

8

Yeah, it’s not something I’d note as an issue if I hadn’t prior thrown out my opinion with a literal range. I just don’t want to ignore my prior stated opinion just because I like hanh :sweat_smile:

9
  1. That’s correct. The vault is transparent and only supports ZEC (not ZSA). Regarding tpool deprecation, IMO, it’s not an urgent concern.
  2. The current thought is to either use memoless (not available yet), or have the wallet extract a receiver from the UA and then it would fit. We could consider using more than 1 OP_RETURN too.
  4. Could you clarify why these are necessary in a transparent vault scheme?

My current understanding is that

  • a swap from ZEC would be z2t or t2t. No need to scan shielded outputs.
  • a swap to ZEC would be t2t or t2z. The tx comes from Maya and therefore it knows what to look for in the blockchain. No need to scan the outputs.
    In which case, do you see a need to scan shielded outputs?

Adding @mayaprotocol

Thanks,
–h

6 Likes
10

Re #2:

  1. Will YWallet pledge to cover the fees for memoless TXs, as someone most front the MAYA (CACAO?) for it?
  2. What is the timeline on memoless, as that now may effect this?
  3. How would you use multiple OP_RETURNs when Bitcoin bans that within a single transaction? Would it be via multiple transactions? Wouldn’t you also need to modify the Bitcoin Bifrost accordingly?

Sorry for the lack of clarity on my shielded output question. The THORChain model requires reporting TXs out (to users, who may be shielded) to the network to ensure they were performed properly. If the on-chain TX is an opaque shielded output, how do you plan to extract the address from it to report the TX to TC so that it can verify its integrity?

The tx comes from Maya and therefore it knows what to look for in the blockchain. No need to scan the outputs.

Only a subset of validators would have participated. All need to be able to observe it and report the outputs back to the chain.

11

I am not sure why you would expect the wallet dev to cover the transaction fees. I don’t think it is common practice, is it?
In any case, this topic was discussed with the Maya Protocol team before submitting this proposal. It impacts only swaps from BTC to shielded ZEC and I feel this is not a blocker.
But I referred to it in the proposal: “There are some concerns regarding the length of UA and it may prevent some use cases but it seems to be workable.”

I will let @mayaprotocol answer this one himself. AFAIK, this can be turned off.

12

Memoless requires a TX be made on TC/Maya to acquire an address. That incurs a fee. The presumed UX, so the user doesn’t already need RUNE/MAYA, is for the UI to pay the fee upfront and then recoup that with the affiliate fee. That’s why I asked if YWallet, the UI for Zcash, would adopt this practice.

You’re correct that YWallet doesn’t need to do this as it’d only be from Zcash though, and this is a concern for UIs which let you swap to Zcash, so I’m fine dropping this. Sorry for wasting our time on it.

AFAIK, this can be turned off.

That’d let validators collude to steal all coins which are intended to go to a shielded address as it’d prevent them from being slashed upon that occurring.

While you may presume validators are honest, it’s just 14 nodes (67% of a partitioned subset) which perform send outs at a specific moment for a specific TX (on TC, and I assume the Maya multisigs are similarly configured). That means only 14 nodes would have to be compromised. Compromising the observation system, which you suggest disabling, requires compromising the global set. That’s why you cannot simply presume validators are sufficiently honest here as the issue is a minority subset of validators potentially colluding.

In order to slash validators who claim to send to shielded address X, yet actually send to shielded address Y, the integrator must have a competent solution to detect from on-chain outputs if X was actually sent to. If you cannot do this, you will either break the system, putting Zcash users at risk, or you will have to not allow sending to z addresses which is a distinct grant proposal. That’s why I’m pushing you to have the answer to this now.

13

We’ll discuss this with the Maya Protocol team during our next meeting. In any case, even if directly sending to a shielded address may not be possible, the wallet could automatically generate a one-time transparent address and auto-shield after. As long as the process is seamless for the user, I think we achieve our goal.

1 Like
14
  1. This makes the integration completely transparent.
  2. That shifts the burden to wallets while opening up an additional metadata side-channel.

Personally, I believe this proposal has been made off the intent yet lacks the evaluation and detail necessary for it to be actually and fairly reviewed. I look forward to hearing if you do have a solution to put forth re: shielded outputs (from your discussions with Maya).

I believe the final opinion I’ll share (until something new pops up) is that the ECC/ZF/ZCG should stop starting funding for transparent infrastructure. There is a critical necessity for shielded infrastructure. With discussions to remove transparent addresses desired yet reliant on this infrastructure existing, efforts should be put towards building said infrastructure. While I wouldn’t mind efforts to expand transparent infrastructure regardless, the limited financial means of Zcash at this time make my opinion thus.

(Yet also, I’m not part of any of those groups so my opinion doesn’t really matter. The above is my contribution to the technical discussion and solely my personal opinion)

4 Likes
15

Compensation total budget:

$110000.00 USD

Please provide justification for the total compensation budget:

This is based on the value provided to the Zcash community and the cost of the TC proposal.

Note: The work done by the TC integration team is not going to be directly used.

Isn’t it ironic that you’re setting the budget for the remaining grant milestone of my team’s ongoing work, while previously claiming the total integration should cost $20k? Also, why not utilize my team’s existing TC work, which is publicly available? The scripts are reusable for Maya since it’s a fork of TC.

It appears you’ve been selected as the committee’s chosen developer, leading to the cancellation of my team’s ongoing grant abruptly.

16

It looks to me like the 20k mentioned was regarding milestone 3 by itself (unit tests), not the entire integration.

As to your speculation about why Nighthawk’s grant was cancelled, I don’t see why you don’t consider the justification given as a full explanation already. There is no need to continue with constant accusations of bias and conspiracy when the reasons are clear to all. It is not a sympathetic look, Adi.

We want this development to happen in a timely manner and we need a responsive and reliable team for that, and that simply wasn’t demonstrated. I’m sorry that it didn’t work out with Nighthawk for this, but you must take some responsibility for your part in the interaction, or you’re only making it more clear why it wasn’t a good fit.

4 Likes
17

I just have two questions:

What are the tools that the grant will produce for others to actually include this in their projects?

milestone 5 is “integration to Ywallet” and it’s valued at $0.00 USD. Does this mean that the effort will be subsidized by the grant itself, or is it that what’s being developed is tailored to Ywallet?.

1 Like
18

Hi pacu, there is some background to it.

Initially, I thought that someone else would do the integration into TC/MP and I just inquired about what wallets need to do. They told me that it is a matter of using their REST api and putting the right data in memos. There are also some client libraries. Typically, wallet integrations do not ask for grants but they recoup their cost through the affiliate program. That’s why I posted

But then I realized I misunderstood and there was no definitive plan to build the MP integration. That’s why I submitted this proposal.

1 Like
19

Hi all, members of the Maya Protocol Team, ZCG and I had a call yesterday to flesh out some details regarding this proposal.

Before getting into the discussion, let’s have a quick overview of how Maya Protocol (MP) works from a high-level point of view. Feel free to skip this part if you are already familiar with Thorchain or Maya Protocol.

Let’s consider a user who wants to swap from ETH to ZEC. They start the swap by sending some ETH to the MP address (Asgard vault). This transaction is on the ETH blockchain and contains a memo that indicates where they want the ZEC to go.

Several machines that make the MP validator set, constantly monitor the ETH blockchain and look for incoming funds to the Asgard address. When they detect such a transaction, they report it to the MP blockchain.
Note that they are decentralized, therefore multiple reports are being submitted.
If/When 67% of the validators agree on the same report, the Cosmos consensus BFT engine (Tendermint) finalizes the report. The first part of the swap, the incoming leg, is complete.

Then Mayanodes work through the MP state machine which ultimately leads to the beginning of the second leg of the swap, the outgoing payment. This is also decentralized and multiple signers are involved in building the outgoing transaction. They each sign a share of the threshold signature. When enough shares are obtained, the fully signed transaction is broadcast.

Validators keep monitoring the ZEC blockchain and report the MP blockchain when they see the second leg of the swap. As always, once 67% of the observers are in agreement the 2nd leg of the swap is finalized and the swap is completed. If the output is shielded, validators need the outgoing viewing key which was used to build the transaction.

The key takeaways:

  • Nodes run a program called Bifrost that is in charge of monitoring the different blockchains (BTC, ETH, etc). When they see something interesting to MP, they send a message to the MP chain
  • Every message has to have 67% agreement to be finalized
  • The MP logic is implemented by another program that a new chain does not need to modify
  • The state of MP is in the Maya blockchain. It is public data.
  • Bifrost must observe both incoming and outgoing transactions

Shielded or Transparent

Whether a user does a transparent or a shielded swap, the description is stored in the MP blockchain and anyone can access it with the right tools.
If I want to swap 1 ETH for 100 ZEC, the MP blockchain will eventually have my Zcash destination address, whether it is transparent or shielded.
I cannot hide the address and the amount. But if I use a shielded address, other transactions to this address are hidden. There is an advantage to using a shielded address, but it is not completely hidden.

In other direction, if I want to swap 100 ZEC for 1 ETH and I make a payment from a shielded address (z2t) there is an issue with refunds. When a swap cannot be completed (too much slippage, vaults are offline, etc), MP refunds the user. With a z2t, MP does not have a refund address and the funds are blocked. This is similar to Binance’s problem.

All in all, we recognize that shielded transactions cause significantly more risks. However, since a user will not interact directly with the MP vault, it should be mitigated by a proper wallet UI.

11 Likes
20

Happy to answer questions people may have on how Maya works!

7 Likes