Ethereum Foundation: What's going on with Phase 1 and Phase 2?

Original title: introduction to | ethereum foundation fellows from the fourth AMA (July 2020) : Phase 1 and Phase 2 related issues

Eth2 Research Team

A Jian, enthusiast of Ethereum

Editor's note: In July 2020, Ethereum Foundation researchers hosted another Reddit AMA. This is an excerpt from the q&A. For easy reading, the names of the respondents are abbreviated: "Justin" for "Justin Drake," "Vitalik" for "Vitalik Buterin," and "Danny" for "Danny Ryan."

& have spent

Phase 1 and Phase 2 related problems & NBSP;

Q: How is Phase 1 progressing?

Danny: The specification for Phase 1 is relatively stable and is already in the testing and refining Phase. One of the most recent things on my to-do list is the addition of p2p networking specifications. Although it took a lot of time to network for Phase 0, I expect the implementation for Phase 1 to be much simpler because the P2P stack and common architecture are already there. Like many components of Phase 1, the work is more of an extension than a rewrite.

We already have a number of engineers and teams understanding and implementing Phase 1 components. Terence from the Prysmatic Labs team was a big help in the Phase 1 specification because he implemented the core state transition specification, found a lot of bugs, and made some great simplification Suggestions.

In addition, TXRX (PegaSys) team Mikhail has developed a Phase 1 simulator with the help of a Java translator written by his colleague Alex. Just last week, Mikhail reported on a working simulator with a beacon chain and two sharded chains, which successfully submitted crosslinks to the beacon chain. For me personally, this is incredibly exciting:)

Work for help Mikhail, Geth Guillaume (EF) team has been developing a project called "Catalyst" (Geth client improved version), with its core consensus logic through a local communication protocol to send for Eth2 client, Catalyst also retains all heavy, user level logic (EVM entry, trade execution, for the production of block trading binding, etc.). This work paves the way for what we call Phase 1.5, which is the plan to integrate the current Ethereum into the upgraded Eth2 system. We expect that soon the work of Mikhail and Guillaume will combine to allow Eth2 to drive Catalyst in local simulations.

There are no unsolved issues in Phase 1, which is very much like a plugin for Phase 0, so the engineering tasks for Phase 1 should not be particularly difficult, but at this stage most client teams are fully invested in launching Phase 0, so the engineering priorities will not begin until the end of the year

Justin: The research on Phase 1 design is almost complete. Here is the specification that has been formed. This specification still needs a lot of polishing (I've already put it on my task list), but the basics are done and the research and engineering risks are low.

I say "almost all" because it is possible to change the design of the specifications that we currently write. Specifically, we are considering replacing some Merkel tree data structures with pmc-based vector commitments (see this paper for examples). Pairing-based vector promises ideal Witness aggregation features that can significantly improve Phase 2's stateless performance. Pin-based vector promises can also use the same cryptography to authenticate shard chain block and shard chain state, making the two more conceptually compatible.

Q: How does Phase 1 compare to Phase 0 in terms of implementation complexity?

Justin: Phase 1 is much simpler than Phase 0. Roughly speaking, Phase 1 has only two parts:

There is only a fragmented chain of data-- Only the shard chain of data is a deliberately designed data structure. The shard chain of data alone is much simpler than the many groundwork laid by the beacon chain and Phase 0 (including the BLS aggregation signature algorithm, SSZ, GHOST fork selection rules, libP2P networking methods, and discv5 node discovery protocol). An interesting gadget in Phase 1 is a fee burning mechanism similar to EIP-1559, which also requires only a few lines of code to be added to the consensus mechanism.

A custody gameIs a small tool for solving data availability problems (see this video for more details). "Game" refers to the game of cryptography economics, and its complexity lies in the interaction type of "challenge-response". The good news is that game mechanics are constantly being refined and simplified (for example: see the latest specifications here). Another unusual feature of the hosting challenge is the use of a special cryptography programme called "Legendre PRF" (for example, see here), which does not really affect the complexity of the implementation.

Q: What do you think is the most challenging part of the remaining Phase 1 study (or have all the major research issues been resolved)?

Dankrad Feist: From my perspective, I do not see any major issues directly affecting Phase 1, although there is no such thing as an absolute (areas of research such as zero-knowledge proof are in full swing and may lead to some vastly improved ideas for Phase 0).

In addition, I think the most valuable ideas right now are about how to make the system more efficient after Phase 1 (i.e., Phase 1.5) by increasing the efficiency of the verified state. I still hope that we can improve the efficiency of our state commitment scheme, whether using polynomial commitment or a brand new vector commitment scheme, which will bring great benefits.

Q: What is the status of Phase 2?

Justin: After a lot of design space exploration and internal discussion, I should say that over time the Ethereum Foundation research team has become less and less positive about Layer-1's virtual machine abstraction (the so-called "execution engine" or "EE"). In contrast, Phase 2 is likely to end up on the traditional path, where the slices share a single, sovereign VM.

For virtual machine candidates, there are (a) EVM from Eth1; (b) A variant of WASM. While EVM is an appropriate, low-risk fallback, I hope we can move beyond it. Five years of hindsight have led us to believe that EVM has many suboptimal designs, which in general have caused great pain for DApp developers and the entire ecosystem.

The benefits of WASM (for example, tool-rich, widely accepted, ecologically mature, standardized) come from the browser world. WASM also seems to be becoming the standard for blockchain, as Near, Polkadot, Dfinity, EOS, and so on have embraced it. My hope is that a team such as Near or Polkadot will overcome the engineering challenges and prove that WASM is actually a better choice.

Danny: There is a lot of space for the Phase 2 design. Over the past 18 months, including the Quilt team and the eWASM team, they have done a great deal of in-depth research and understood most of these areas. If you want to dig deeper, check out their ethResearch posts on the ethResearch forum: varying degrees of abstract design, cross-sharding messaging schemes, virtual machine trade-offs, transaction format changes, and more.

Starting this year, there has been a shift in priorities to a consensus system that looks at how the existing Ethereum ecology can be integrated into Eth2 before "Phase 2" is fully implemented. To achieve this goal, Phase 2 research has quieted down as we worked hard to prepare the Phase 1 specification and Phase 1.5 research and development.

It is worth noting that eWASM's work is being driven by the Eth1x64 research and development project, which aims to provide the smallest available specifications and prototypes for Phase 2 simple versions. They've written some great research posts exploring the possibilities. Have a look!

The final form of Phase 2 is still up in the air, but with these results and the ongoing efforts of the eWASM team, I expect we will have a clearer idea as Phase 1/1.5 approaches production.

About cross-slice trading & NBSP;

Q: Have we figured out how?
Can a contract in Shard 1 process contract calls to different shards in a single transaction?
What criteria are used to determine which slice an intelligent contract/EOA will be on?

Danny: The cross-sharding of layer-1 is determined in the sharded Eth2 system to be implemented asynchronously, that is, through the crosslink mechanism of the sharding chain and beacon chain. When shard A is cross-linked to the beacon, shard B can use A receipt from Shard A to facilitate ETH transfer and contract interaction.

In addition, there are many Layer-2 schemes that support optimization and the fastest execution of cross-shard trades. I expect this to become the norm over time.

Because of the asynchronous nature of cross-shard interactions, it is not possible to make contracts that make calls to different shards in one stroke. There are mechanisms like "yanking" or "commit Capabilities" that might help you achieve your needs.

For example, I may yank a train ticket contract and a hotel contract to the same slice, and then atomically complete the reservation; Alternatively, I could promise to order both and then atomically resolve the promise when crosslink completes.

As to which shards the account will be placed on, the current plan considers the natural economic load balancing of the shards. That is, each account and contract can be deployed to any slice the user wants. There will be those who seek lower fees or are "closer" to important contracts. I expect it to mask this in the long term for contracts, making users interact with ethereum rather than with a particular slice. There are user experience challenges, but no insurmountable ones.

In other words, competent users/developers will keep an eye on sharding options and make strategic choices when feasible.

Aditya Asgaonkar:

- We know what cross-shard trading looks like from a beacon chain perspective. Please refer to my blog post for details
- Given the asynchronous design of cross-shard trading, the situation you describe is unlikely
- So far, there is no plan for such a standard. The contract /EOA should be able to be created on any slice.

Q: How do you share the load between slices? If everyone wants to put each contract on a particular slice, because there's an important input mechanism (Oracle), or there's an Uniswap that everyone wants to use.

Aditya Asgaonkar: The current expectation is that the Gas fee market will naturally produce an equilibrium based on partitioned loads. Intuitively, if a shard becomes slow and expensive, the user will leave that shard and migrate to another shard that is faster and cheaper. If the user does have more advantages by staying on the more expensive slice, such as having a contract that he visits frequently, the user will naturally choose to stay.

Q: So, DApp largely automates this choice?

Aditya Asgaonkar: From Phase 2's study of the current situation, this is unlikely to be the case. In our current scenario, any cross-shard activity (transaction, account/contract migration) requires some user to provide relevant data for the target shard. This is to eliminate the need for one shard to read another, which would break the scalability we seek.

In general, I would argue that there is still a lot of potential for change in the design of Phase 2, as this is an ongoing area of research. We should be able to discuss these things more specifically in a future AMA.

Text link:https://www.reddit.com

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia