Funding Proposal: (Bridge|Trust)-less & Private: BTC & ETH on Secret Network, with a Dark DEX for anonymous swaps, cross-asset fungibility and (re)?mixing

The full document can be found at: (Bridge|Trust)-less & Private: BTC & ETH on Secret Network, with a Dark DEX for anonymous swaps, cross-asset fungibility and (re)?mixing. - HackMD - I am open to suggestions, collaboration and new ideas.


We plan to introduce and develop a novel trustless cross-chain ‘bridging’ and swap method to bring BTC, ETH and other tokens onto Secret Network in a way which can rapidly support many chains with minimal effort.

If a contract can generate Bitcoin or Ethereum keypairs then deposits can be made by a counterparty to addresses on other chains without a relay or a bridge, the Secret Contract acts as an escrow - releasing the key to the appropriate party upon payment or timeout in a similar way that a hash-time-lock contract does.

The initial Phase of development will focus on the fundamentals and solution discovery given the capabilities & constraints, concluding with a proof of concept implementation of SNIP-721 wrapped Bitcoin & Ethereum keypairs and a simple decentralized UI to deposit & withdraw.

The vision that guides this research is to engineer the prerequisites for a cross-chain ‘Dark DEX’ (Phase 2) which could offer a higher level of privacy than SecretSwap, enable more types of cross-asset fungibility without locking-up capital in liquidity pools, or increase transactions per second.

However, because security measures must be taken to not reveal too much information to sophisticated, malicious and/or interactive actors it may not be possible to track many KPIs like: liquidity, price, number of swaps, TVL etc. without compromising the privacy of the contract users, and remaining trustless imposes its own constraints which must be balanced too.

Milestones

Phase 1:

  • RNG + Ignition Ceremony
  • SNIP-721 contract for Bitcoin & Ethereum keypair escrow
  • Minting UI to deposit & withdraw BTC and Ethereum on Secret Network

Phase 2:

  • Privacy enhancing swaps, mixing & state-channels
  • Fungibility: SNIP-20 from sets of SNIP-721
  • Dark DEX proof of concept

Team

  • HarryR - Lead
  • MattDF - Advisor
  • AA - Marketing & Communications officer
  • GK - UX & product testing

E-mail scrt.network@conquest.finance for non-public discussion.

Funding Request

To fund Phase-1 of the project we initially require 69420.001 USD worth of SCRT. The exchange rate for USD/SCRT must be calculated on the date of payment. The legal jurisdiction can be either England & Wales, or Switzerland.

1 Like

Hey @HarryR
Thank you for your interest in building on SN. I would like to speak with you all in greater detail about this project. Please reach out to me on telegram: @Yonatan_SCRTLabs

Jumping in here (also had some time to touch base with @Yonatan on this). This is an extremely interesting proposal and I am very curious about it. That said, I’m still not clear about some of the details nor about the value prop of Phase 1.

First, let me try to explain the Phase 1 solution in my own words to make sure I get it. IIUC, the idea would be for users to be able to generate a BTC/ETH/other wallet for themselves on Secret Network (there will be a UI that will generate a keypair associated with the user sending that tx on Secret). Users will be able to share the address with ETH users (let’s take that as an example), which will be able to do a native ETH tx to move funds to the new address.

The user who created the wallet on Secret side (the receiving address) will be able to ask for the key itself, but no one else would.

When it comes to generalizing this, the idea would be that people would be able to ‘trade’ eth/btc/whatever address on Secret, creating a new kind of DEX/AMM in phase 2

My follow up questions to this are:

  1. Do I understand Phase 1 and Phase 2 correctly? I would assume so for the other questions.

  2. What’s the use case of Phase 1? I can’t really see anything useful to do with it, in which case it’s probably not enough for an MVP

  3. The cost seems arbitrary – on the higher end for what Phase 1 describes, and on the lower end for Phase 2.

  4. I’d like to see a more thorough explanation of the DEX. Is it a DEX or an AMM? More details on how it would work. My gut feeling is that it’s much more complicated than currently reasoned about.

I just want to be clear again that these probing questions are because WE ARE SUPER INTERESTED in this use case, but the proposal needs refinement.

Guy

1 Like

Thanks for jumping in, and Hi!

I’d just like to be upfront and say that I don’t intend for anything from Phase 1 other than the RNG to be deployed and used on mainnet, it’s research focused on overcoming the problems that make phase 2 possible at which point the Dark DEX can be specified and we can come back to you with a high-value seed phase proposition (or just approach VCs who seem to be creaming themselves over ZK tech at the moment).

Is it a DEX or an AMM? More details on how it would work. My gut feeling is that it’s much more complicated than currently reasoned about.

It’s not possible for this to be an on-chain AMM as it cannot rely on a price / UTXO oracle (like Shinobi protocol) or overly complex game theoretic / economic mechanics without contravening my requirements.

I have a very good intuition for the complexity involved, and I believe that mostly non-interactive cross-asset fungibility without oracles or trusted third parties while retaining strong anonymity guarantees is solvable, and I have intricate knowledge of this from my experience working with, analysing the defecits and developing various privacy enhancing coins / technologies, zkSNARKs, mixing algorithms etc.

Let me be frank though, I do not want to be responsible for a MVP which makes convenient but bad compromises to get to market faster, or something that gives users a false sense of security just because it’s deployed on Secret Network, as if it accidentally gains traction we’ll be stuck with it and it will suck.

For example, monetizing this directly from user transactions is non-trivial without breaking anonymity (like scrt’s native gas token does for those who aren’t exceptionally careful). And I agree that simply encapsulating wallets as NFTs with an escrow method is not the end goal, it’s a known stepping stone - to overcome the problems making it unsuitable for use with a “Dark DEX”. Personally I think the current Cosmos/Secret token standards just perpetuate the problems that we’re now stuck with on Ethereum which make composability and gasless meta-transactions an absolute nightmare (and these patterns are blindly followed by most other smart-contract chains), and having an AMM like SecretSwap is an ‘easy’ solution that leaks de-anonymizing data on every transaction even without gas payer linkage… those are bad convenient compromises.

We need something better, and I don’t think you can do that if the scope is too narrow or is artificially limited by incrementalism.

First, let me try to explain the Phase 1 solution in my own words to make sure I get it. IIUC, the idea would be for users to be able to generate a BTC/ETH/other wallet for themselves on Secret Network (there will be a UI that will generate a keypair associated with the user sending that tx … etc

That’s one way of doing it and similar to my starting point. But the wallets need to be freely tradable on scrt.network without any further native ETH transactions, ideally they need to be fungible (that’s really difficult without making the SPV client compromise that Shinobi has made, and now they’re stuck with high gas fees and only support BTC), without revealing the wallet address until the final withdrawal, with an ever growing anonymity set size and no cross-chain linkability or correlation, without side-channel de-anonymization, without relying on expensive oracles or continuously running external processes which are prone to breaking down etc.

TL;DR I’m limited by difficult constraints where the answers will define what I can and cannot do when it comes to a DEX that doesn’t suck and is actually anonymous. I can’t commit to a half-arsed but easy solution because there are still some hard problems to solve - and importantly they’re worth solving properly without compromises. Secret network makes this possible with much less effort and fewer compromises.

When it comes to generalizing this, the idea would be that people would be able to ‘trade’ eth/btc/whatever address on Secret, creating a new kind of DEX/AMM in phase 2

Yes.


At the moment I’m continuing to problem-solve and we’re in the process of refining the proposal. Query nodes + the extra builtins coming up in Shockwave let us do some very interesting ‘transactionless’ things using derivation schemes, but without those building blocks it will be much less valuable if implemented.

Ethereum specific:

Given an Ethereum block hash (any time after the deposit) the depositor can privately use the state trie to prove to the contract that the wallet has at least a certain ETH balance. The proved block hash and declared value is included in the public metadata so anybody can verify that if the block hash is real then the proof of funds must be legitimate.

This doesn’t reveal the wallet address until the NFT owner chooses to void the token and gain access to the secret, only then do they learn the wallet address. The NFT can change hands on scrt.network any number of times while keeping the wallet address secret.

The same method can be used for ERC-20 tokens (or even EIP-721 tokens), but is slightly more complex as the storage slot used to track owner/balance varies from contract to contract (it can still be generalized, but requires access to an Ethereum archive node and per-token logic in the client).

BTC / others:

Because Bitcoin has no global state tree a proof of funds would reveal the specific block that contains the deposit transaction (bad). By verifiably/trustlessly constructing an off-chain merkle tree of all BTC blocks a proof similar to the Ethereum case can be made without revealing which block the UTXO exists in - thus keeping the wallet address secret and increasing the anonymity set size.

… I’m not sure if I need to use this method as there are other methods with different trade-offs when considered as a whole. But it’s in my toolbox.


The cost seems arbitrary – on the higher end for what Phase 1 describes, and on the lower end for Phase 2.

It is enough to cover some of the expenses involved in solving the problems necessary to get to the point where phase 2 is both theoretically and practically possible, and more importantly can be specified in a way which won’t drastically change.

Then factor in drafting the phase 2 proposal, legal oversight + jurisdictional advice (I’d rather not get dragged infront of the FCA, NCA, or the SEC), and finding more staff of the calibre I need is both tedious and expensive.

(Also, if you can recommend legal counsel familiar with this kind of project I would appreciate it).


On a side note: I do not trust the DDT5/scrt-rng project - it should not be used by any projects. I have uploaded a stripped down version which doesn’t allow the ‘owner’ to permanently break dependant contracts by changing the settings. Likewise I do not trust the blackbox.cash project as it offers no protection against a malicious relayer (which is a shame because it’s a good idea, but again should not be used by anybody) - it can also be permanently broken by the ‘owner’.

1 Like

Hey, I am responding because I was mentioned. I am fully aware of a number of issues the RNG has, which I am quite open about, and in fact I wish there were more awareness around the way randomness is being done on the Network. But before I get to that: You cannot do a 1-tx random number generator that I see you’ve got. It is vulnerable to a very simple attack:

Say there is a gambling app contract. User calls roll-dice. App requests an RN from this single-tx RNG contract. If dice roll == 6, user gets some tokens. To attack, user just needs to call two msgs in 1 tx (a feature that is allowed on Cosmos chains):

  • msg0: roll-dice
  • msg1: query dice result. If result == 6 → return Ok(()). If result != 6, return Err().

As you might know, when an error is returned, all previous state changes within the tx rolls back. So user can just keep doing this, and the only txs the user will execute are favourable. It doesn’t matter what prng algorithm you use, or that the user cannot see the seeds or random outputs. The attack still works in many situations.

So it needs to happen over 2 transactions. Note that Chainlink’s VRF also happens over 2 txs, so it is not an insurmountable issue for apps.

The admin keys should not allow breaking the contract, but only to share hashed entropy with a second contract (a new one with no admin, and configured the way the community prefers following some feedback) which I intended to create once there’s uptake, but so far I think this vulnerability I laid out isn’t fully appreciated, which is hampering uptake.

To be clear, I am not claiming that the 2-tx RNG I created has the same level of resistance against attacks as Chainlink’s VRF. But it is a step up, vs. the blatantly vulnerable 1-tx model.

Not 100% sure what’s the RNG you have in mind. But it sounds promising that people are looking into this because there is definitely room for improvement, but it is quite likely to require off-chain computation if you want it to be comparable in security to Chainlink’s VRF. I am happy to contribute/chip in if I can be helpful.

As you might know, when an error is returned, all previous state changes within the tx rolls back. So user can just keep doing this, and the only txs the user will execute are favourable. It doesn’t matter what prng algorithm you use, or that the user cannot see the seeds or random outputs. The attack still works in many situations.

Yup I’m fully aware of this, but whether or not the output of the RNG can be abused is dependent on the protocol using it.

There are many cases where the block delay is necessary, this is application-specific and should be baked into the application which uses the RNG.

There are also many cases where the block delay isn’t necessary, so why should the RNG have any additional functionality when it can be handled by a client library.

The most important thing for the RNG is to be seeded securely (thus it needs some kind of public seeding ceremony), to cycle the seed securely, and to provide entropy on demand with no possibility of two contracts or sequences of messages ever providing the same output in different circumstances.

All I’m proposing with this is:

  • to keep the RNG simple and easy to verify
  • public ignition ceremony so we can trust RNG output
  • Provide client library to retrieve entropy from RNG once upon initialization
    • client library cycles its own seed internally
    • further requests for entropy won’t require any external contract calls thus lowering gas & complexity of the multi-block schemes when they’re required.

Most importantly, I’m proposing that contracts don’t use the RNG directly, they use a client library which follows known secure patterns.

I’m also digging into the technical details of if the block height and block time parameters not being trustworthy then what’s stopping an attacker from arbitrarily fast-forwarding time using a sequence of transactions?

I have a WIP document with research about protocols for external time/block oracles, and lots of previous notes about VDFs and work the Ethereum foundation were doing etc. and came to the conclusion that something Secret Network really needs to guarantee is linearity of time and that time has passed.

Without this you’d have to rely on some kind of mediator, e.g. for a HTLC protocol the participants agree between them on a trustworthy third-party (or pool of third parties) who do something as simple as sign the current time and block height of the network, and protocols like Shinobi can use the Bitcoin light client to get a rough gauge on PoW vs time, but really need a better solution.

Essentially lots of problems in crypto require guarantees of one kind or another about time & linearity, in most cases this is trivial because at least one participant is honest, but when the contract is being executed in an isolated environment you can’t rely on this.

Agreed about needing some sort of time oracle, the easiest way to do this is probably to update the consensus mech to generate a DPOS signed block height on every new block?

1 Like