L2 Future - Session 2

# L2 Future - Session 2 ### "dApp development" Fri. Nov. 20, 2020 4pm CET - 6pm CET [Airmeet link](https://www.airmeet.com/e/2287d140-1ad3-11eb-a69f-694f61e413c8) Previously: [Notes from Session 1](https://hackmd.io/uUURJoqbQfKIWcpIGW4Y3A?view) **Table of contents** [Proposed schedule](#Proposed-schedule) [Discussion notes](#Discussion-notes) [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 Pedro 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 Bryant NFT that costs $20 to move is not sustainable L2 will be easier to port things over David Will this kill composability? Fragmentation and async Bryant Polkadot cross-chain transfers is a starting point David The lockup is a challenge ORU seems to be the path forward Bryant Don't need to exit the L2 Pedro 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 Bryant There is an assumption about WASM-based binary Cosmos is ahead, prototyping their IPC Regarding Zinc and Cairo Nick Interested in composability L2-L2 L1-L2 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 Bryant Cross-shard interactions similar to threading Within a single shard perhaps it is similar to coroutines Nick Something inside of solidity Jamie What happens to the notion of transaction in the composability scenario? Nick From web2, the notion of Correlation ID (for reference see: [Correlation IDs for microservices architectures](https://hilton.org.uk/blog/microservices-correlation-id)) Bryant The idea is that the transaction moves from committed to confirmed Across L2 In Atomic Swaps, both sides commit, neither side does For transactions, there are multiple stages But there are complicated interactions here Nick The ABI needs to define a state machine or other interface to document multi-network interactions Bryant Enable cross-L2 swaps and interactions Jamie 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 http://xml.coverpages.org/WSFL-Guide-200110.pdf Web service choreography - HP proposal http://xml.coverpages.org/HP-WSOrchestration.pdf David These L2s are developing languages Working on a VM and a language Bryant Transpiled to EVM David L2s are developing their own VMs for differentiation Is going to be challenging? Bryant Developers would prefer the compiler have a flag, instead of a completely different architecture. David There is no standard interface for communicating across contracts. Bryant 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. tBTC https://docs.keep.network/tbtc/index.pdf David Is there a spec for this kind of thing? Bryant This is currently a thought. There is an EIP, will look it up. Pedro 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. Alex 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. David 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. Bryant Tokenization is a UX technology. Settlement as an explicit token. stETH tokenized Eth2 deposit. Nick You can't have tokens for every possible state, e.g. chess moves. Bryant 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. David 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. Nick What you want to settle is the result of the chess game. David A small subset will need to actively communicate between L1 and L2. Pedro 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. Nick Back to tokens for everything. Pedro Tokens to escrow, final transfer. Example is liquidity provider. David 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? Pedro 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. Nick Bridge networks. Generalized bridge. David The problem is that bridges need operators. How to make it convenient as possible. Pedro 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. Fengkie 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? Pedro 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. David There is going to be a lot of opportunity for arbitrage between L2s and L2-L1. Pedro 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. Alex 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. Nick Would that tie everyone to JSON-RPC Pedro 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. David Would love those JSON-RPC endpoints to have a chain assumption. Pedro Systems wanted to be so compatible, they would have the exact methods with different behavior. David JSON-RPC 2.0 JSON-RPC endpoint ERC-20 transfers. How much should newer systems accomodate multiple networks? Pedro L2s should not use the same methods as Ethereum. fuel_sendTransaction Nick So it is more than simply supplying chain ID. Pedro Context about the methods used. It is reasonable to change the method. Nick This starts to seem like an interesting tooling problem. Pedro JSON-RPC authenticators. Jamie Eth2 example, what are they doing for this? Pedro What happened is they saw a demand for an exact mapping into a REST API Bryant https://github.com/ethereum/eth2.0-APIs David Signatures. This requires more signatures per user. Pedro 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. David The challenge there is how to map different accounts and signatures across chains. Mapping Ethereum account. Do Cosmos and Polkadot have standards for this? Pedro 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. Jamie We grew up in this country Ethereum, all of our dapps, even the addresses have these assumptions. David There is Ethereum exeptionalism. Pedro EU prefixing banking numbers IBAN, this became the standard. Alex 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. Pedro 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. Alex The discussion in 2016 were not oriented toward changing the system, more of a recommendation to Metamask and others at the time. David Some interesting comments in the chat, we should up business models as a topic. Bryant 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. David Block producers are in a privileged position. Problem is front-running their customers. Bryant 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. David Rollups may not have this. Bryant There is "mining" by combining the txns, w/ validity. Jamie 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? Bryant Business opportunity to sell business intelligence data. David 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. Bryant Brokerage can host their own L2. David CBDC Pedro Zk rollups pinpointing state ORU has dispute time period Bryant Zk rollups Tradeoff complex cryptography ORU Economic assurance, less comples, cheaper, more scalable Pedro Zk rollups hardware / gpu requirements ORU capital requirements --- ## Practical options for developers ### Starkware - 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/) ### zkSync - 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/) ### Hermez - 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/) ### Optimism - 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) ### SKALE - 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/) - [Documentation](https://docs.matic.network/docs/develop/getting-started) - Deployed systems: [Polymarket](https://polymarket.com/), [Quickswap](https://quickswap.exchange/#/swap) ### Connext - 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)