Eth2.0 Phase 2 Community Call #103
Comments
villanuevawill
changed the title
|
Thanks @villanuevawill! Excited for this initiative :) |
|
I just updated the agenda above! |
|
Notes from the call: Eth2.0 Phase 2 Community CallTHESE NOTES ARE ROUGH, TAKEN LIVE, NOT EXACT TRANSCRIPTS. Tuesday, December 3rd, 2019. Participants:Will Villanueva IntroWV: This is first of monthly calls. Try to limit to 1.5 hrs. Calls will have themes, eg January call will focus on cross-shard or alternate proposals. Team updatesEwasmAB: Ewasm: Since Devcon, have made progress. Finished Groth16 verifier EE. Benchmark pairings using bigint api. Looked into metering: (1) prototype to determine cost for instructions, (2) edge cases. Standardizing Scout, which started in May as a prototyping engine in Rust, now have Scout.ts (for in-browser testing) and another in C++ (for plugging into client), now want to standardize Scout API which all implementations use. Working on Scout APIs: bigint and wasm-spawning wasm. Want Scout tests for each implementation to pass. Working to extend Scout in Rust to be more user-friendly. Next features: linking Wasm modules, cross-shard transactions. QuiltWV: Devcon and blog post with overview. Naive prototype of wasm-spawning-wasm with basic hello world. Want to eventually bring APIs into Wasm. Performance concerns, but want to look forward to iterate. Relayer which keeps state, some things black-boxed. Quilt new members working on expanding Scout to test/benchmark across shards; have long-running processes to test the whole system. WV and AD research on cross-shard txs, with lessons learned from Eth1 contract interactions and prototype increasing throughput. DR: Documentation? Onramp? WV: Yes, onboarding someone. Goal to support grant, but no announcement yet. Eth2 research teamDR: Reworking phase0&1 specs based on devcon decisions. PL and VB working on cross-shard mechanics. Eth1EE transition (devex, tooling) will be a major effort. VB: Eth1: Switch to witness-size bound will need changing gas costs, eg fees to access code. Work around in common cases: no fee if code already accessed. Efficiency by storing objects on beacon chain and accessing in shards eg put the 10,000 most-used Eth1 controcts into beacon chain. DR: How do we enforce Eth1 gas costs in Eth2. VB: Support gas changes earlier. DR: How to rectify Eth1 pricing in Eth2? VB: Once we have translation table for Eth1 and Eth2 gas, can compute ahead-of-time. AB: Metering overhead. How to meter in the first place. E.g. metering of EVM opcodes when implemented in Wasm. Have some options, injection, static analysis, lots to look into. VB: Two layers of metering (EVM in Wasm) is awkward. AB: Two classes of gas cost: state modifying & computational. But EVM in Wasm, both in Wasm. VB: State modifying doesn't matter as much. Must increase gas cost of things like SLOAD. State increasing have higher gas cost, state growth should be thought about more. AB: With recent repricing EIPs, concern about reentrancy, etc. Any new metering will raise questions. VB: People have suggested EIPs to mitigate this. AB: Don't think that any have been implemented. No generic soln. Proposal to version EVM contracts which prices old contracts with old costs. VB: Good to get closer to stateless. AB: If anyone is interested, please talk to us, this is important. VB: Anyone other to follow than Eth1x stateless stuff. AB: most repricing/versioning talk is on gitter. MG: If a witness isn't fixed size/depth, some depths cost more. "Mooching" off neighbors. How to support different costs? AB: Yes, different costs depending on how it was packaged. Relayers may charge less. MG: People will try to mine neighboring addresses. PD: this is depth attack. Alexey suggested AVL trees. Economic soln may charge for new account. This is an open and interesting problem. Stateless, relayers & state providers (Will)WV: Eth1x effort focusing on this. Curious to see benchmark numbers on witness sizes, performance for Eth1 with binary tree. Need discussion on network propagation (how do txs get to block proposer, market incentives, DoS attacks), storage, mempool, block proposer prioritizing list of txs, block proposer interacting with relayers. Receipts. Performance. Will look at cross-shard stuff with AD and Sam. State providing: payment or altruistic. MQC: Any new work on relayer networks and state provider networks? VB: Sharding rework is making things easier. Transactor with state can just publish. Because no enshroned balance and nonce system, depending/pending txs may be more difficult, but this is solved by having one tx do multiple txs. If have balance in shard 1 and want to work in shard 2, need mechanism how EEs move Eth between shards. Level of enshrinement of cross-shard txs, that's kind of separate. DF: why only Eth, could be any economic value. VB: Yes. If want Eth to be immediately spendable, then need enshrined mechanism that is replay-safe. Eth may be enshrined because it is used for tx fees. DF: Why wouldn't a value-holding EE do this? VB: Would need to be supported by all block producers. Problems with amount of state needs to be held. DF: Because value-holding EE also holds other assets? VB: Schemes for transfering Eth between shards: (1) enshrined reciepts between shards are put into shard blocks, (2) maintain state with counters and require branches to be put into block, (3) more cost for txs between shards. DR: Will shard blocks have enshrined coinbase mechanism with regards to an EE? Otherwise need to know account structure within EEs to accept fees. MG,WV: Mimic a coinbase. Would be nice to pay gas without sending Eth to multiple shards. EE tooling (Axic + Matt)MG: quilt/pm#2 . Need tools to handle multiproofs. Different proofs are different. Proto did write-up of different proof formats. Maybe generalize interface to higher level key-value. EE are all hand-written, would be good to state automatically do it and user just writes like now in Solidity not thinking about statelessness. WV: What would good tooling look like? MG: In link, nice way to interact. Abstract statelessness from dapp dev. Need testing framework. Need existing tools to generate multiproof. WV: Accumulators as existing module. So can focus on dapp dev. MG: Tools depend on the proof format. No need to rewrite. SM: Good multiproof runtime takes a lot of work. Devs should be aware. Maybe not ready for it yet. PL:Write up about merkle tree type abstraction, basically a merkle-specialized version of pyrsistent: https://github.com/protolambda/eth-merkle-trees/blob/master/typing_partials.md Join light client call tomorrow. AB: Agree with SM. Performance is of upmost importance. Big question: who can deploy EEs: few enshrined EEs ("umbrella EEs") vs. standalone EEs (user-deployed). Maybe something in the middle. Matt's proposal favors standalone. Working on optimized modules for sig verif, multiproof verif, etc for users to use. Solidity's YUL->Wasm working and outputs Wasm, maybe useful to have EE-specific language. MG: EE dev should not be focused on low-level proof format (e.g general index for MG's Merkle tree work). Need tools. Current accumulator work (Paul)PD: Big objective is call data size and runtime. Need performance in both (one or the other is not enough). There is an iteration process on this. One can survey existing ones, and one can implement one. It is quite difficult to build your own and is generally a low level engineering job. PD: Stateful people say stateless has lower throughputs. Want stateless people to respond that stateless has better throughput with the proper proof format, etc. Accumulators are central to this discussion. DR: Have you or anyone here ran into particular accumulators that are interesting? PD: Pairing based accumulators may have not meet our requirements. RSA accumulators work but I have note seen numbers. Matbe useful to work on some combination/tricks. From what I've seen, Merkle accumulators are competitive for the state size we're looking at, 80 million accounts. WV: Thoughts on optimizing or spreading out to other problems? PD: I'm active on this and been working on it little by little since summer. My binary token - has so far been the most performant one and Alexey has been working on this as well on & off. For help you could design your own, but it would take a lot of time and it's a bigger effort. Metering/interpreter Benchmark (Casey)CD: BN128 Pairings benchmarks presented at Devcon. Using Wabt interpreter with bigint host functions and websnark has runtime approaching native (!). Since then, making sure benchmarks are apples-to-apples eg using same algorithm. Then will publish report. Todo: BLS pairings. CD: Merkle Patricia trie for Eth1 benchmarks. Using multiproof format from TurboGeth. For 70 accounts from a state tree of 5000 accounts, and update the tree. Nest step is 71 million accounts. Have script to convert Eth1 data to turbotruth format. Want to sync node do mainnet and have realistic test vector. Turboproof format is changing. We are optimizing, not just using off-the-shelf. This is leading up to processing Eth1 blocks in Wasm, maybe as Eth1 EE. Cross Shard (Will + Proto)PL: https://ethresear.ch/t/commit-capabilities-atomic-cross-shard-communication/6509 Spectrum of passive (commit to everything, shards resolve, problem if early commit fails) to proactive (message passing). See links to other work in post. Contract languages (Axic)AB: Too early for EE-specific languages. One of the reasons Wasm was originally chosen is its wider language ecosystem. However until today, it is still relatively small: Rust, C, C++, and Nim are general purpose ones (using llvm), and AssemblyScript is Wasm-specific. API interface bindings exists in each language. Using these languages currently for writing EEs and as we go along we need to improve them. Likely they will be the first ones used to write "contracts" as well. May eventually design contract-specific languages. Maybe even Solidity could be used (it has wasm support now). Potentially Dfinity's Motoko's could be used, but it does have specific constructors for the actor model of Dfinity, which may not be possibly switched off. WV: How about Ink!, what Polkadot uses? AB: Ink is specific to Substrate. Similarly to how Motoko is specific. Ran out of time. Switchover (Casey)Alternate Proposals (Casey + Will)General Discussion |
Meeting Date/Time:
Tuesday 2019/12/03 at 15:00 GMT
Meeting Duration:
1.25 hours
Agenda
Team Updates
Discussion Time
The discussion time should be a casual Q&A. For this first meeting, we want to cover an overview and spend a max of 10 minutes per topic. If we don't make it through the entire agenda, we can continue discussion in the next community call.
Meeting Link
Will be posted in relevant channels 15 minutes before
The text was updated successfully, but these errors were encountered: