Allow Us to Introduce Ourselves…

Introducing Yellow Submarine, the first practical Universal Private Settlement (UPS) layer built, with love, for all EVM-compatible chains. What does this mean in simple terms? Yellow Submarine enables private transactions across different EVM-compatible chains. A transaction might start on Polygon and end up on Arbitrum, but when it travels on Yellow Submarine, there will be nothing to link the origin of the transaction with its destination.

It’s just like a submarine — after it goes underwater no one knows where it will come back up except the people onboard. The concept of Yellow Submarine can be applied to many DeFi applications, including DEXs, DAOs, and Dapps across a variety of use cases.

Currently, privacy on Ethereum and other EVM-compatible chains is very difficult. Ethereum is a public blockchain where all transactions are transparent. To date, privacy has mostly been reserved to UTXO chains, like ZCash, which was one of the first blockchains to implement zero-knowledge proofs (ZKP) for privacy. However, due to the limitations of a stateless UTXO architecture, programmability is known to be limited.

Ethereum, on the other hand, is highly programmable. However, due to the limitations of a stateful account model architecture, ZKP for privacy is much more difficult to achieve. Yellow Submarine leverages Findora’s multi-chain architecture, to parallelize ZKP for privacy and scalability on the UTXO chain, with EVM for programmability, composability and interoperability.

One of the benefits of the EVM is the composability it offers developers. So while technically interoperable, EVM chains still operate much like an archipelago of islands separated in the same sea. Yellow Submarine connects these islands in a stealthy kind of way by making private transactions across EVM blockchains as simple as a few clicks.

Yellow Submarine is a prototype project by Columbus DAO, built in cooperation with Findora Foundation and Discreet Labs. It combines Columbus DAO’s chain-agnostic cryptographic technology with Findora’s ZKP cryptographic tools

The Privacy Loop

That’s enough about us introducing ourselves. Let’s dive under the surface and explain how Yellow Submarine works.

0/ Preface

First off, as a preface, we define the asset transfer path from one EVM chain (such as BSC) to another EVM chain (such as Ethereum) as a full loop. We will demonstrate to the crypto community how a full loop with ZKP operations in the middle can remove the link between the source EVM address and the destination EVM address.

A simple use case demonstrating a full loop in Yellow Submarine is as follows:

As a user, I would like to transfer my assets on EVM chain 1 (source chain) to EVM-chain 2 (destination chain), such that my address on the source chain and my address on the destination chain cannot be linked by any 3rd-party.

We chose to demonstrate the full loop first for the following practical reasons:

1. We wanted to best accommodate the existing UX of Ethereum users by supporting popular EVM wallets such as Metamask end-to-end.
2. A full loop removes a lot of the complexity of certain out-of-band information sharing for a full anonymous transfer operation such as the one in the Zcash Sapling protocol.
3. A half loop requires storing the destination private key for users, which further requires heavy changes to the wallet and more special user interactions.

1/ Bridging EVM Asset Bridge

Yellow Submarine adopts a customized and enhanced version of Chainbridge. It is called the Columbus Bridge. The main customization that has been done is to allow a single-relayer-to-multi-network architecture where every relayer can monitor multiple networks at the same time. This allows the ability to increase the number of relayers with lower cost and connect each relayer to diversified fullnodes. By doing so, the failure rate of relayers’ operations can be largely decreased, which boosts the success rate of the Columbus Bridge operations.

The main enhancements include the following:

1. Restricting Columbus Smart Contract to only interact with it and nothing else
2. a set of dashboard monitoring tools for:

• the relayers
• the statistics of the bridge
• failed transfers

3. Tools to deal with failed transfers

After a user clicks “Transfer” the frontend will invoke the deposit function of the Columbus Bridge at the source chain with the following three parameters:

1. destinationChainID
2. resourceID
3. data

destinationChainID is the chain ID of the destination chain registered in the Columbus Bridge (every EVM chain will have a unique destinationChainID).

resourceID is a unique ID for the asset type a user tries to transfer.

data is Web3 encoded data with: tokenContractAddress, userAddress, amount, recipientUTXOAddress. (data will be used as the input data for several functions calls before the step #12 in the flow diagram below).

After the calling of the deposit function of the Columbus Bridge, the Bridge contract will find the target handler registered for the asset with resourceID and call it through the generic handler. In this case, the target handler is just the ColumbusDeck Contract. The ColumbusDeck Contract then calls the corresponding ERC20 contract to lock the token. If the operations in this path have been all successfully executed, the original deposit call to the bridge contract will return with a status of success while an event will be emitted. Relayers will be able to monitor the event. And then, one of the relayers will be able to send a voteProposal to the other side of the Columbus Bridge (i.e. the Findora Smart Chain).

After all the relayers’ vote over a certain threshold, the Columbus Bridge on Findora Smart Chain will also call a target handler registered for the asset with resourceID. This time, the target contract is the ColumbusRelayer contract. The ColumbusRelayer contract then forwards to the call to the bridge contract of something called Prism++, which we will explain in more detail below.

2/ Accessing ZK — Findora EVM to UTXO

This step is made possible by Findora Native Chain (UTXO) and an atomic swap protocol called Prism and its counterpart, Prism++. This enables users to convert an ERC20 asset into a private Findora Custom Asset on Findora Native Chain. Each approved ERC20 asset will have a corresponding Custom Asset address on the Native Chain.

3/ Breaking the link — Findora Triple Masking

Once the asset has been transferred to the Findora Native Chain, these assets can utilize the ZKP privacy features that are powered by the Findora Zei cryptographic library. This step allows users to convert an asset to a private asset and transfer it to a brand new wallet address. In essence the asset will almost appear to be minted on the new wallet. Because of the ability of the ZKP to prove the validity of a transaction, the only thing that will be recorded will be the proof itself. No link can be established between the originating account and destination account, making it impossible to externally trace beyond this point.

4/ Forward to Findora EVM — Findora UTXO to EVM

The asset can now return to Findora Smart Chain via Prism++. In the step #14, the frontend will call a WASM binding provided by Findora, which then initiates a call to the WithdrawFRC20 function of the Prism++ bridge contract. Prism++ is designed in a highly extensible pattern. It allows the ability to set the processing logic and a certain type of asset based on an enum type defined in the PrismAsset. In this case, the Prism++ bridge can be set to do nothing for any asset from Yellow Submarine. This saves the steps in Findora EVM processing. The Prism++ bridge then calls the registered low level call function with data. In our case, it will call the depsitFromPrismBridge function of the ColumbusRelayer contract. The ColumbusRelayer contract will further call the Columbus Bridge Contracts.

5/ Back to the Start — Asset Transfer to Target Chain

This asset can now be used on Findora Smart Chain, or transferred to any target EVM compatible chain via the Columbus Bridge. A primary enhancement made for the Chainbridge contract is that the Columbus Bridge Contract can only be called by the ColumbusRelayer. Similar to the process of the first-time passing of Columbus Bridge, the executeProposal function of the bridge contract on destination chain will be called after the successful calling of a target contract at the Findora Smart Chain side, and similar relayers’ monitoring and voting process. After that, the bridge contract on the destination chain will execute the target contract, which is the ColumbusDeck contract. The ColumbusDeck contract will decode the data passed across the Columbus Bridge and unlock the same amount of token to the recipient address based on the information in the decoded data. Then, the recipient will receive the token. At that point, the whole process finishes. The destination EVM address is not able to be traced externally (though it may be able to be audited) to the source EVM address.

Stay tuned for Part 2…