# L2 Future - Session 2
### "dApp development"
Fri. Nov. 20, 2020
4pm CET - 6pm CET
Previously: [Notes from Session 1](https://hackmd.io/uUURJoqbQfKIWcpIGW4Y3A?view)
**Table of contents**
[Practical options for developers](#Practical-options-for-developers) w/ links to dev documentation
## Proposed schedule
4pm CET: **Welcome**
**~ 4:05pm CET**: Overview
**~ 4:15pm CET**: Work session / discussion, questions about developing and deploying dapps that depend on L2s.
**~ 6pm CET**: Finis!
## Discussion notes
Each one comes with its own trade-offs
How to connect to nodes, how to inspect these nodes
ZKSync has been interest to see, it was used with Gitcoin
This is at ERC-20 transfers
NFT that costs $20 to move is not sustainable
L2 will be easier to port things over
Will this kill composability?
Fragmentation and async
Polkadot cross-chain transfers is a starting point
The lockup is a challenge
ORU seems to be the path forward
Don't need to exit the L2
Composability is going to be an issue
We have nodes that are not compatible
Using different languages
We are talking about users interacting with the chain
The way dapps are designed, it feels "designed for Metamask"
The browser as the UX drove it for years
Now there is innovation, breaking from propietary UX, now there are standards for interacting with dapps
Cosmos and Polkadot, preparing us for multi-chain
This is for staking, watching governance for that one, don't need to have the switch
A dashboard approach
With Cosmos and Polkadot, there is no assumption about one chain should interact
There is an assumption about WASM-based binary
Cosmos is ahead, prototyping their IPC
Regarding Zinc and Cairo
Interested in composability
Take application that was on L2
Interop aspect, what will Eth2 have in store for that?
User experience, swapping networks in Metamask isn't the solution
Cross-shard interactions similar to threading
Within a single shard perhaps it is similar to coroutines
Something inside of solidity
What happens to the notion of transaction in the composability scenario?
From web2, the notion of Correlation ID
(for reference see: [Correlation IDs for microservices architectures](https://hilton.org.uk/blog/microservices-correlation-id))
The idea is that the transaction moves from committed to confirmed
In Atomic Swaps, both sides commit, neither side does
For transactions, there are multiple stages
But there are complicated interactions here
The ABI needs to define a state machine or other interface to document multi-network interactions
Enable cross-L2 swaps and interactions
There was a set of standards for this in the earlier web eras.
"The Web Services Flow Language (WSFL) is an XML language for the description of Web Services compositions. " - IBM proposal
Web service choreography - HP proposal
These L2s are developing languages
Working on a VM and a language
Transpiled to EVM
L2s are developing their own VMs for differentiation
Is going to be challenging?
Developers would prefer the compiler have a flag, instead of a completely different architecture.
There is no standard interface for communicating across contracts.
For Vyper, to define certain chunks of functionality. You'd write this program, "this action is on Ethereum", "this is on this L2", "this is on that L2", linking this action to that action requires a deposit, etc.
The Atomic Swap. The mechanism for cross-L2 action is the issue. In xDAI, what is tha action to get the ETH over there. This is what Cosmos and Polkadot are developing.
Is there a spec for this kind of thing?
This is currently a thought. There is an EIP, will look it up.
Tokenization is the biggest use of Ethereum
Example is compound. Tokenizing the debt itself. Integration with another system, Synthetix and Aave, it would be much hard to take into account how Compound works without the token.
The token comes with assumptions.
While there will be a future of cross-shard comms, we will start at the token level.
On solidity we're discussing moving some of the compiler into a standard library and making it explicitly importable: https://github.com/ethereum/solidity/issues/10282
This would allow having "dialects" of the language for different targets.
If L2 is going to be the layer of small fish, who want to put $10 on Compound, this is the shift in thinking. Not every transaction needs to run through the complex VM. The user only needs to know that it can be settled.
Tokenization is a UX technology. Settlement as an explicit token. stETH tokenized Eth2 deposit.
You can't have tokens for every possible state, e.g. chess moves.
Tokens summarize all the actions into a summary statistic. If there is a condition for pulling it out, it only has to be on the L1.
Which types of actions need to be settled back on the L1. For a game, you don't need to save the game state back to L1.
What you want to settle is the result of the chess game.
A small subset will need to actively communicate between L1 and L2.
Worked w/ Connect on generalized state channels. It could all be nailed down to one use case: conditional transfers.
There were multiple interpreters, use cases boiled down to single asset, two party outcome. It didn't matter what was happening, it mattered what resolved. Signed outcomes, state transitions. What mattered was what party got what asset.
Eventually all outcomes comes down to who gets the balance.
Back to tokens for everything.
Tokens to escrow, final transfer.
Example is liquidity provider.
LPs providing liquidity on L1.
Assets between L2s need LPs.
Tokenization requires liquidity providers.
LPs are an opportunity for low-risk investment.
Some user wants to take their DAI from L2 to L2.
Will users provide, will they run a node to do this?
As we saw with ICOs, there will be a design for liquidity mining.
L2 apps w/o sufficient liquidity. AMM on L2 w/o liquidity would have terrible slippage. L Mining can help create a good user experience.
Bridge networks. Generalized bridge.
The problem is that bridges need operators. How to make it convenient as possible.
The main struggle with Connext was running nodes. Having access to node operators was the big struggle. Users complained, and it turned out that the node was not available.
Providing infrastructure for L1, there could be a relayer service for multiple L2s.
This is where Cosmos shines. Not only ready for multiple chains, addressing evaluating the provenance of the token.
There also there's this rebalancing problem for LPs to be able to keep serving end users between protocols, I think the solution there would be economic game incentives for LPs to be actively rebalance between protocols?
*There also this rebalancing problem for LPs to be able to keep serving end users between protocols, I think the solution there would be economic game incentives for LPs to be actively rebalance between protocols?
People will deploy capital to the various protocols, for arbitrage. The design may not need to be there, the profit already creates the opportunity.
The DeFi craze is causing this to happen to centralized exchanges.
There is going to be a lot of opportunity for arbitrage between L2s and L2-L1.
As a wallet enthusiast, how do wallets fit into this?
There are different trust assumptions on the different L2 chains.
We are going to see friction on the dapp level. Wallet infrastructure will need to be developed.
Applications should not make the assumption. Become multi-chain, multi-system. xDAI chain is a great example. It would be more reasonable to request, then when requirement is met, request is made on the other chain. Wallets will have to adapt.
Earlier Nick said that it would be nice to have a transaction package. Currently only one connection is allowed. Simple way today would be to allow multiple connections.
Would that tie everyone to JSON-RPC
All chains should imlement JSON-RPC. Would love everything to be gRPC, but this is not feasible. Only for desktop use.
Just talking about Ethereum. It is already flawed because it pre-dates chain ID. This was a design flaw. First fork happened. Chain ID should be in the transaction layer already. we need to create JSON-RPC providers, intent of targeting a specific chain. We can have a wallet which exposes accounts for both, simultaneously. Simply include the target. Simple change on interface would make multi-EVM wallets easier to design, make multi-system wallets easier to design. All of the complexity can be reduced to target a chain.
Would love those JSON-RPC endpoints to have a chain assumption.
Systems wanted to be so compatible, they would have the exact methods with different behavior.
JSON-RPC endpoint ERC-20 transfers. How much should newer systems accomodate multiple networks?
L2s should not use the same methods as Ethereum. fuel_sendTransaction
So it is more than simply supplying chain ID.
Context about the methods used. It is reasonable to change the method.
This starts to seem like an interesting tooling problem.
Eth2 example, what are they doing for this?
What happened is they saw a demand for an exact mapping into a REST API
Signatures. This requires more signatures per user.
If you were to have a different signature, you should have a different method in JSON-RPC.
These assumptions are made due to the assumption of the single chain.
When you sign something, define how to sign it.
DID decentralized identity defines the signature method.
The challenge there is how to map different accounts and signatures across chains. Mapping Ethereum account. Do Cosmos and Polkadot have standards for this?
They do not have so much translation of identity across systems. To some extent, as we build L2s, we try to hide how the user went a layer up, I don't see this as a feature. There should be a clear display of this context change. There should be a prefix in an address naming the system. On Cosmos, all addresses have a prefix.
I started realizing that accounts are not addresses. Accounts are the conjunction of chain ID and addresses.
We grew up in this country Ethereum, all of our dapps, even the addresses have these assumptions.
There is Ethereum exeptionalism.
EU prefixing banking numbers IBAN, this became the standard.
In 2016, just after launch. There were so many proposals to fix the addressing question. This was before the checksumming came into use. There were proposals for prefix, additional data. The prefix was the least number of changes. Even at the time the nicer solutions were rejected out of fear they would not be adopted.
There was even an IBAN standard for Ethereum addresses. Adhering to IBAN required a certain number of bits, the first byte of the address required a 0.
Have become a bit obsessed with standardization. Least change you can cause to the majority of stakeholders, the more likely it is to succeed. Need to take into account existing market conditions.
Chain agnostic improvement proposals. Superset of Ethereum proposals, which could enable standards to apply to all chains. Utilize existing standards, inherit standards from each system. So that it is not disruptive.
A lot of the paricipation comes on the interface application development. Chain IDs, account IDs, how do we take these intents to target one JSON-RPC.
The discussion in 2016 were not oriented toward changing the system, more of a recommendation to Metamask and others at the time.
Some interesting comments in the chat, we should up business models as a topic.
Flash Boys 2.0 by Phillip Daian
We are already seeing miner extractable value happening. Private mempools, managed by the mining pool managers. There are interesting ways to play with that.
Hard to design public goods with business models but there is a lot of play with here.
Block producers are in a privileged position. Problem is front-running their customers.
Paying miners like mob bosses. It is turning in an interesting thing, arbitrage opportunities. Get in before them, take some of that trade away from them, in a public pool. People don't want their trades taken from them. Ethereum's lack of privacy support is the cause of that. L2 frameworks will have their own system for managing block mining. The only thing you can say for sure, the mining pool will be smaller than Ethereum.
Rollups may not have this.
There is "mining" by combining the txns, w/ validity.
Have the privacy-oriented networks removed this opportunity? Could a network be privacy-protecting and aggregate data somehow, similar to the way that Brave aims to?
Business opportunity to sell business intelligence data.
We see Binance chain, if a business spins up a chain w/ certain benefits, we may see entities who want to spin up their own chain.
Brokerage can host their own L2.
Zk rollups pinpointing state
ORU has dispute time period
Zk rollups Tradeoff complex cryptography
ORU Economic assurance, less comples, cheaper, more scalable
Zk rollups hardware / gpu requirements
ORU capital requirements
## Practical options for developers
- ZK Rollups
- [StarkEx Website](https://starkware.co/product/starkex/)
- [Cairo platform and language overview](https://medium.com/starkware/hello-cairo-3cb43b13b209)
- Deployed systems: [DeversiFi](https://www.deversifi.com/)
- ZK Rollups
- [zkSync Website](https://zksync.io/), [zkSync Block Explorer](https://zkscan.io/)
- [Overview](https://medium.com/matter-labs/zksync-is-live-bringing-trustless-scalable-payments-to-ethereum-9c634b3e6823), [Documentation](https://zksync.io/dev/), [Zinc language](https://zinc.zksync.io/)
- Deployed systems: [zkSync Wallet](https://wallet.zksync.io/)
- ZK Rollups
- [Hermez Website](https://hermez.io/)
- [White Paper](https://hermez.io/hermez-whitepaper.pdf), [Developer guide](https://docs.hermez.io/#/developers/dev-guide), [Smart Contracts](https://github.com/hermeznetwork/contracts)
### Aztec 2.0
- ZK Rollups w/ privacy
- [Aztec Website](https://aztec.network/)
- [Overview of Aztec 2.0](https://medium.com/aztec-protocol/aztec-zkrollup-layer-2-privacy-1978e90ee3b6), [Developer Documentation](https://developers.aztec.network/)
- Deployed systems: [zk.money](https://zk.money/)
- Optimistic Rollups w/ EVM
- [Optimism Website](https://optimism.io/)
- [ORU overview](https://medium.com/plasma-group/ethereum-smart-contracts-in-l2-optimistic-rollup-2c1cef2ec537), [OVM deep-dive](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52), [Deposit-Withdraw Example](https://github.com/ethereum-optimism/Buidler-Deposit-Withdraw-Example)
### Fuel Labs
- Optimistic Rollups
- [Fuel Labs Website](https://fuel.sh/)
- [Overview of beta / testnet](https://medium.com/@fuellabs/announcing-the-fuel-v0-open-beta-565a2d340fc3), [Documentation](https://docs.fuel.sh/v1.0.0/Introduction/Welcome.html)
- Plasma L2 w/ an EVM
- [SKALE Website](https://skalelabs.com/)
- [Why SKALE?](https://medium.com/skale/why-skale-de649cbf3ab9) - Overview
### Matic Network
- Plasma L2 w/ an EVM
- [Matic Network Website](https://matic.network/)
- Deployed systems: [Polymarket](https://polymarket.com/), [Quickswap](https://quickswap.exchange/#/swap)
- State channels to bridge EVM L2s
- [Connext Website](https://connext.network/)
- [v1 Documentation](https://docs.connext.network/en/stable/develop/contracts.html#), [Vector / Cross-L2 Transfers](https://medium.com/connext/instant-cross-l2-transfers-are-now-on-testnet-2f1295530c22)