[WIP] Layer 2 Proposal

Hi all,

We did some initial research on the scaling solutions and we want to share it here. Any feedback is welcome.

Goals

Below are several things to consider for the scaling solutions:

  1. Time to market
    We prioritize time to market over other scaling features. Hopefully, we can have as few code rewrites as possible. We can afford another migration if there is a dominant DeFi chain or L2 solution in the future.

  2. Production-ready
    The scaling solution is already launched with real transactions from the block explorers.

  3. Ethereum-compatible
    Using the same Metamask wallet to access everything without creating a new wallet or updating Metamask settings.

  4. Usability (Smaller withdraw dispute period)
    Some L2 solutions like plasma or optimistic rollups need a dispute period, and we want to have a minimum dispute period or no dispute at all.

  5. High throughput and low fees
    The higher throughput the better. The lower fees the better.

List of Scaling Solutions

Here is the link to our research on scaling projects. Please let us know if there is anything here that’s not up-to-date.

Our Proposal to the New Perpetual Protocol Design

The pros and cons of this design:

  • Pros
    1. Gas fee is only needed when depositing. OpenPosition / ClosePosition / AddMargin / RemoveMargin are gas free because of meta transactions.
    2. Funds on L1 and L2 are all controlled by the same wallet (Metamask or Walletconnect). No extra L2 wallet needed.
    3. Frequent operations like OpenPosition / ClosePosition can be speeded up by L2.
    4. Traders can also create a wallet on L2 and trade with AMM on L2 without touching L1.
  • Cons
    1. Traders need to deposit first. This adds a little bit complexity but should not be a big burden.
    2. Unable to query AMM from L1. We reduce our composability by moving the AMM to L2.

New Addition to the Design

  • Root Bridge Contract/Client Bridge Contract
    This is provided by the scaling solution in order to send transactions or ERC-20 tokens between L1 and L2.
  • Meta Tx Gateway
    This is provided by the scaling solution in order to send meta transactions from L1 to L2.
  • Deposit Proxy
    A proxy to deposit funds from L1 to L2.
  • Order Proxy
    A proxy to send meta transactions from L1 to L2.

Features Required from Scaling Solutions

Take Matic for example. Below are the features we need to validate:

  • Deposit DAI (or other stable coins) => Matic.
  • Withdraw Matic DAI => DAI.
  • Calling a view function on Ethereum from Matic.
  • Send a transaction to Ethereum from Matic (Who are going to pay the fees?)
  • Sign a message (web3.personal.sign()) in Ethereum and verify it (web3.personal.ecRecover()) on Matic
  • Send a meta transaction from Ethereum to Matic
  • Get Oracle data on L2

We will filter out the projects based on these features.

Candidates and Validation Results

Most of the solutions are not fully production-ready yet, so we only have a few choices. We will start by evaluating xDAI and Matic and post the results below in the comments section.

Please let us know if you have any feedback. Thanks.

4 Likes

This looks very promising. I agree with the goals. These days, one also has to consider fork-ability. It’s hard with open source and decentralization.

I like “Traders can also create a wallet on L2 and trade with AMM on L2 without touching L1”. The CEX market is way bigger than DeFi, so this is important to capture market share from CEX’es.

I’m a fan of Optimism, because it’s a “pure” L2 (not a sidechain or L1-bridge). The main con with Optimism is slow withdrawal, but I’m sure someone will create a quick-withdrawal-service. To do this you would have to run your own nodes and validate the fraud proof and have capital to lock/lend during the fraud-check period.

I’m also a fan of zkRollups. Loopring doesn’t offer Turing-complete smart contracts, so it’s not an option. StarkWare Cairo looks promising, but requires rewriting the code in L2. StarkWare could also be used to prevent someone forking the protocol, but on the other hand it wouldn’t be as decentralized.

We also have to consider if users are comfortable putting their funds in the scaling solution we decide on. We could use Tron or EOS with a bridge, but scaling doesn’t matter, if users aren’t comfortable putting their funds on these blockchains. Therefore, we have to consider what other projects are doing, because if most projects go with Optimism, then most users will trust putting their funds in an Optimism layer.

4 Likes

Agreeing with @bardur 's view on Optimism. Their approach seems to be the most inviting in the long run because, if I understanding their use-case correctly, a user/integrator would be able to choose to either participate in L2 or stay in L1 (because all states ends up in L1).

That said though, to achieve short term production goal, we need every single component to be, not necessarily perfect, but must be ready to go when we need it. That means we must be able to deploy and remain in operations, and its security must be decent enough so we could put user’s funds in it.

Looking at what the variety of ecosystems in offer atm, I can see that the project’s tech stack will have to migrate several times to adopt, either due to a better tech available, or like bardur pointed out, due to shift of community trends. Cost of migration might be the top concern here so we can remain agile. That means if we could keep the core logic intact, not having to rewrite too much, and only write disposable boilerplate codes for each platform, that would be ideal.

1 Like

How do you think about fork-ability and vampire-attacking in this design, and also in a more general picture like should we defend it or shouldn’t?

Here are some results of me looking into Matic. Pls let me know if there is any doubt or error!


Currently Matic has two cross-chain bridges: PoS and Plasma. PoS bridge has a far shorter withdrawal time while Plasma bridge has a better security of 7 days challenge period.

As far as I’m concerned , there is perhaps one advantage of Matic over xDai: oracle, as Chainlink is on the list of next version (of implementation) on its site.


Doable:

  • Deposit ERC20 and Ether => Matic.
  • Withdraw ERC20 and Ether from Matic => Ethereum
  • Sign a message (web3.eth.personal.sign()) on Ethereum and verify it using Solidity’s ecrecover() on Matic
    • web3-eth-personal is intended to interact with the node’s accounts; web3.eth.accounts.sign() is the right one
  • Features of Solidity 0.6: return struct

Not doable:

  • Calling a view function on Ethereum from Matic.
  • Send a transaction to Ethereum from Matic (Who are going to pay the fees?)

Behaviors of direction from Matic to Ethereum have not been implemented yet but also noted as the next version.

1 Like

I don’t think fork-ability should be a high priority, but only a minor goal to consider. PERP is harder to fork than Uniswap, Balancer, Curve etc. because a fork of PERP would have to build up trading liquidity and an insurance fund. I don’t see how one would do a vampire attack on active perpetual contracts.

StarkWare could provide some protection against fork-ability, because too my knowledge the prover isn’t open source. But I don’t think we should decide on a scaling solution based on fork-ability, but we can keep this in mind when designing the system.

2 Likes

Thank you. I think forking perp might just create an incentive war in which the competitors and we both reward a lot of tokens to attract users. Don’t know what it will turn out to be.
But I didn’t think about the Insurance fund and you’re right, this should be the most defensible thing that’s hard to copy.

updates for xDai,

  • two way bridge
    • transactions can be sent on one side and be executed on the other side.
  • multiple ETH-ERC20/ERC20-ERC20 extension
    • they have native extensions to support coin/token transfer
    • Omni provides arbitrary ERC20/ERC677/ERC827 transfer, but charge 0.05% fee while withdraw.
  • fully EVM compatible, current info
    • block size: 1.25M
    • block time: 5secs
    • version: Istanbul

Problems

  • not support getter functions between chains
    • not a big impact
  • no price feed oracle.
    • have a L1 contract to push latest price to xDai

Here is the development resource.


Hi @bardur, I’m also a fan of rollups, especially zk series! StarkWare is also my personal first choice, but our first concern is ecosystem.

2 Likes

not support getter functions between chains

we have it WIP https://github.com/poanetwork/tokenbridge-contracts/issues/492

no price feed oracle

what do you think about using OpenOracle from Coinbase/Compound? https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068

2 Likes

I have some concerns about xDai:

  • Since it is a sidechain it has a very different security model. It has a different set of validators and a different consensus algorithm compared to Ethereum.
  • It’s a bit faster (5 sec. block-time) and has a bit more throughput (70 TPS), but this seems slow compared to Optimism and StarkWare. 5 sec. will feel slow when dYdX, Synthetix and Uniswap will have instant transaction settlement.
  • Users must have DAI to pay for gas fees. I don’t think DAI can be used as an asset in PERP because Maker can’t hold the peg. If we go with USDC or USDT, then users must deposit DAI and USDC to use PERP.

On the positive side, they use a standard EVM and can in theory be ported to another chain/tech, but any migration will be difficult and creates problems for users.

@igor Hopefully users will trade millions of dollars or even billions, and I don’t think we can’t use OpenOracle from Coinbase. There is currently only one truly trusted Oracle solution (and I don’t own any LINK token). The Oracle is only used for setting the funding rate in PERP, but still I think it is important to have a community trusted solution.

1 Like

@igor, my bad, I forgot you have OpenOracle.
Our priority now is to launch on mainnet. So we don’t want to change too much in this stage. We’re looking forward your Asynchronous information receiving by an AMB extension proposal.

1 Like

Hi @bardur, thanks for your feedback.

We really want to adopt Optimism or StarkWare, but as we know Optimism is not production ready, and we need to change everything we built in the past half year if we adopt StarkWare now. It’s too risky for us to migrate on these solutions now. So, in this stage we choose to deploy on xDai first, but we will keep eyes on L2 solutions and migrate to it if we find a better one (not matter technique side or ecosystem)

As the gas fees on xDai, we’re planning to use meta transactions so we cover the fees on xDai. Users only need to pay ETH gas fees when deposit/withdraw.

And yes, we prefer more decentralized one, that’s another reason why we keep ChainLink solution.

1 Like

@Kimi I fully agree with you. Good to hear that you have a solution for gas fees on xDai and that you are looking for solutions for the long term.

I’m really fascinated by the architecture where everything runs on L2 and only proxies are on L1. This is the right solution for the future. It makes sense to go with xDai now (instead of L1 Ethereum), because then we use the futureproof architecture and have a better user experience than other L1 projects currently have.

2 Likes

Ava Labs !

Avalanche mainnet launch Monday.

Athereum already usable.

Avalanche is definitely something in our radar, but they don’t have their ETH <-> AVAX bridge ready yet.

AVA labs build Athereum - like i understand it, no bridge necessary . It’s Ethereum running on the consenus of Avalanche . The whole entire infrastructure like MEW or Metamask etc… is there already . Am i wrong?

AVA will need an atomic-swap-like feature on top of what you’ve mentioned above:

  • lock 10 token on Ethereum
  • mint 10 token on AVA

and vice versa:

  • burn 10 token on AVA
  • free 10 token on Ethereum

this enables value transfer between two chains and is essentially what a bridge does.

it requires commitment from the AVA community though, because there has to be a group of servers literally watching both chains 24/7

#1 happy to find Nervos emerging on the research scope, so I am very thrilled to share our update and Roadmap for Q4 2020.
Especially for a new concept proposed by our researcher,Jan -Interoperability 2.0.

Interoperability 2.0 means that Nervos protocols help different blockchain networks merge into a single large crypto network. The coolest part is that it requires end-users to do nothing.

So far, we have such four-component like jigsaw puzzles to achieve it.


One is simple UDT token standard,which is a very general token standard on Nervos without too many limitations.

And PW-SDK provides any blockchain user could keep use their own wallet and address on any blockchain to operate the asset and aApp on Nervos CKB. So far it has been implemented on Nervos mainnet providing users using ethereum wallet like metamask or imToken wallet to sign the transaction on NervosCKB.In next
Be free to have a look :
first used case of PW-SDK : Portal Wallet

PolyJuice is a EVM compatible layer on CKB. So far,it could be used on the part feature of solidity smart contract. Here is Demo of polyjuice through fork ENS contract on it without any migrating cost :
repo :https://github.com/nervosnetwork/polyjuice

ToCKB is our cross-chain solution which is just released which provides token from any other chain to map on Nervos CKB. Unfortunately, it just starts and we pursue that we could release the prototype even the first MVP in Q4,2020.

repo: https://github.com/nervosnetwork/toCKB

1 Like

#2 In the long term, what Nervos want to do is connecting multi chain into a huge network like the graphic below:


Users on different chains could still use their own wallet just like today we could use numerous browsers and enjoy the same class service on the Internet.And users are not necessary to know additional knowledge about that so do we don’t TCP/IP and still have a good time surfing on internet.

appendix 1

Sorry for the discourse forum only allow me to put two links in single post.
I put the other links here:

Portal wallet
first used case of PW-SDK : Portal Wallet
repo: https://github.com/lay2dev/pw-co