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:
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.
Production-ready
The scaling solution is already launched with real transactions from the block explorers.
Ethereum-compatible
Using the same Metamask wallet to access everything without creating a new wallet or updating Metamask settings.
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.
High throughput and low fees
The higher throughput the better. The lower fees the better.
Gas fee is only needed when depositing. OpenPosition / ClosePosition / AddMargin / RemoveMargin are gas free because of meta transactions.
Funds on L1 and L2 are all controlled by the same wallet (Metamask or Walletconnect). No extra L2 wallet needed.
Frequent operations like OpenPosition / ClosePosition can be speeded up by L2.
Traders can also create a wallet on L2 and trade with AMM on L2 without touching L1.
Cons
Traders need to deposit first. This adds a little bit complexity but should not be a big burden.
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.
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.
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.
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.
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.
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.
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.
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.
@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.
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?
#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.
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.
