The development of Ethereum in the past week: Ideally, ETH withdrawals will start in March next year

ECN以太坊中国

特邀专栏作者

2022-11-30 08:35

This article is about 7349 words, reading the full article takes about 11 minutes

Shanghai upgrades EIP, prediction time for opening of withdrawal function, latest progress of Layer 2...

Original title: "Original title: "》

Original author: ECN

main network

secondary title

Questions about the sustainability of the testnet

The discussion about the ETH supply crisis of the Goerli testnet has been going on for some time, and Afri, the developer responsible for the maintenance of the Goerli testnet, updated on the availability of the testnet at the 150th Ethereum Core Developer Conference (ACD) held on November 25. Results of the latest discussions on persistent issues.

In general, the long-term maintenance of the test network is difficult to guarantee, and there will be problems such as state expansion and difficulty in obtaining test currency supply. Therefore, Afri proposes a testnet proposal with a clearer lifecycle. A summary of the proposal reads:
A new testnet is released every two years on a specific date (e.g. October 1, 2023, 2025, 2027...).
Limit the lifecycle of the testnet to a maximum of 5 years (4 years + 1 year of long-term support, if needed)

If possible, extend the long-term support of the Goerli testnet by 2 years, ending in 2024.

source

secondary title

There are four EIPs confirmed to be included in the Shanghai upgrade

After discussing the testnet issue, the developers began to discuss which EIPs should be considered for inclusion in the Shanghai upgrade (Considered for Inclusion, CFI). The CFI status was added by Ethereum core developers a few years ago to highlight EIPs that the client team likes and wants to implement, but does not promise to implement them in a specific fork.

details

Although in the past several upgrades, almost all EIPs that entered CFI were deployed in the fork, and this raises the question of whether CFI is really useful or valuable, and whether it is a waste of time to even try to explain what CFI is. Instead, it should be included directly in the EIP.

Not so according to Tim Beiko. Obviously, for those who have been thinking about network upgrades, the background and differences of these EIPs are very clear, but for people in the community, it is difficult to get a sense of what is being considered.

In general, the following questions were discussed among CFI developers:
Should CFI exist?
If yes, should it mean that we want an EIP to be deployed "in this fork" or "in a fork soon"

How "strong" should the CFI's commitment be?

Therefore, the developers discussed the possibility of entering the EIP of CFI.

1. EVM Object Formatting (EOF) related EIP

Before EOF, two more EIPs (3570/3670) entered the CFI, but then the consensus turned to hope that the entire set of EOF EIPs should be deployed together to minimize any additional EOF versions (these version clients need permanent maintenance).

2. EIP-4844 proto-danksharding

Although there is no consensus on whether/when/how we should implement EOF, there is very strong support and these EIPs have all been implemented on the developer testnet. Then, the other three EIPs that go into CFI are: 4200, 4750 and 5450.

Since EIP-4844 was prototyped and deployed on a multi-client developer testnet, the developers agreed to move it to CFI.

3. EIP-4758 Disable SELFDESTRUCT

One problem with this proposal is that when a contract is deployed using CREATE 2, gets SELFDESTRUCTed, and then re-instantiates at the same address. At the meeting, the consensus on this EIP was to wait until there was a proposal to address this edge case before pulling this EIP into the CFI. So it's more a question of when than if.

4. EIP-2537 adds BLS precompilation

This EIP also goes into the CFI because it has been in the CFI since the Berlin upgrade.

To sum up, the following EIPs are now determined to be included in the Shanghai upgrade:
EIP-3651: Warm COINBASE (reduce the gas overhead of accessing COINBASE addresses)
EIP-3855: PUSH 0 instruction (add opcode PUSH 0)
EIP-3860: Limit and meter initcode (set a limit on the size of initcode and introduce a gas meter for this field)

EIP-4895: Beacon chain push withdrawals as operations (beacon chain push withdrawals as system operations)

EOF ( 3540, 3670, 4200, 4750, 5450)
And into the CFI are the following EIPs:
EIP-1153 (transient storage transient storage)
EIP-4844 (protodanksharding)

source

secondary title

Ideally start ETH withdrawals next March

On this issue, each client team expressed their views on the priority and scope of EIP in the Shanghai upgrade.

The Geth team stated that they want a relatively light-weight Shanghai upgrade, prioritize withdrawals, ideally include EOF, and then upgrade in March next year.

The Erigon team also expressed that they want a small fork, but feel that EOF and 4844 are relatively large, so they would be more willing to include some small EIPs in addition to withdrawals.

The Nethermind team is also supportive of enabling withdrawals and sees enough capacity to incorporate another large EIP, either EOF or 4844. They are biased towards 4844.

The Besu team also supports implementing withdrawals, but prefers EOF over 4844.

The Prysm team considers withdrawals a top priority and will choose 4844 if there is no delay.

Both the Lighthouse and Teku teams agreed, and the Nimbus team agreed to the withdrawal, but suspected that 4844 would cause significant delays.

Therefore, the broadest commitment from the developer team is to implement withdrawals as soon as possible, ideally next March. They will do other work in parallel, but if they can happen at the same time, they will incorporate these EIPs into the Shanghai upgrade, but the withdrawal will be the main upgrade of this upgrade.

source

secondary title

source

secondary title

mevwatch.info Updates OFAC Examiner Leaderboard

source

secondary title

DAppNode adds MEV Boost function

first level title

source

Layer 2

secondary title

source

secondary title

zkEVM expansion solution Scroll and privacy DID project zkCloak reach cooperation

source

secondary title

source

secondary title

source

ecology

secondary title

WETH Joke Recap

In recent days, jokes about the decoupling of WETH and ETH have been circulating on Twitter, and a considerable part of them are actually developers on Ethereum making reverse jokes on this. But this led some people to believe it was true, and the rumors of WETH's decoupling intensified for a while, and even the professional news media Bloomberg reported this rumor as a fact.

Dankrad Feist, a researcher at the Ethereum Foundation, tweeted a warning:

Many people make jokes about WETH. But beware, a layman may not know that WETH is completely different from a bridge asset.... I think it would be better to label these more clearly as a joke.

In order to break the information barrier for the spread of WETH decoupling rumors, some people in the community began to popularize WETH.

For example, Hudson Jameson stated that WETH is not insolvent. Its supply is not stored by a centralized platform or group, but is run and managed by smart contracts. Its packaging contract is open source, and many experts have studied whether this contract has loopholes, so it is generally considered safe to use. Also, it is different from other encapsulated assets because it is deployed on the decentralized Ethereum. Therefore, it is impossible for it to be insolvent (unless there is an unlikely contract loophole), and it will always be linked to the ETH deposited by the user at a ratio of 1:1.

Ethereum ecological researcher 0 xCygaar briefly introduced the mechanism of WETH:

First of all, WETH is an ERC-20 token, which means that the logic of WETH is contained in a simple smart contract on the Ethereum blockchain. WETH encapsulates ETH at a ratio of 1: 1, allowing holders to use ETH more easily on various DApps. This is the token contract address of WETH: https://etherscan.io/address/0 xc 02 aaa 39 b 223 fe 8 d 0 a 0 e 5 c 4 f 27 ead 9083 c 756 cc 2 #code….

Notice the balance mapping on line 32 of the contract, which is a mapping of how much WETH each user has in storage.

Let's take a look at the core functions: deposit, withdraw, and transfer (transferFrom).
How the deposit function (line 38) works is simple. After you deposit ETH, you will get as much ETH. On line 39, the user's balance is incremented by the amount of ETH the user sent in the deposit transaction.
The process of withdrawing money (line 42) is also simple. First of all, the WETH contract will ensure that your balance is less than or equal to the withdrawal amount. After that, it reduces the user's WETH balance and sends the user the same amount of ETH as the withdrawal transaction.

The transfer (line 63) proceeds similarly to the above. First, the contract will check whether the user contract has enough WETH for transfer. Next, it does an authorization check to see if someone other than this user is making the transfer (L 69-72). After the final transaction is completed, the balances of both parties on the source chain and the target chain will be adjusted.

source:

https://twitter.com/dankrad/status/1596864596421189632

https://twitter.com/hudsonjameson/status/1596876948910723072

https://twitter.com/0 xCygaar/status/1596273841386708993

secondary title

source:

https://twitter.com/gitcoin/status/1594751121444085760

secondary title

Maker Announces rETH Deployed on the Maker Protocol as a Collateral Asset

Maker tweeted that Rocket Pool’s rETH is now deployed as a collateral asset on the Maker protocol, which will support more Ethereum stakers. With the new rETH-A vault type, users can now stake rETH to generate DAI.

The parameters of the rETH-A vault type are as follows:
Minimum mortgage ratio: 170%
Stability Fee: 1.5%

source:

https://twitter.com/makerdao/status/1594700128920682503? s= 21

secondary title

Erigon decides to end support for Akula

On the 24th, the Erigon team said it would end support for Akula because they found another implementation similar to Akula and also written in Rust. It's the same domain as Akula, and has the same/similar artifacts.

Since they think this implementation will gain more support and popularity after being open sourced, it will soon rival and surpass Akula in functionality. Therefore, they could not see how Akula would attract the capabilities in grants in the future, and they also knew that the implementation was superior to them in terms of team resources and influence, so they decided to terminate Akula's technical, management and financial support.

However, Erigon did not specify which implementation it is. In this regard, the community pointed the finger of speculation at Paradigm's Reth.

Ethereum developer Lefteris Karapetsas tweeted @paradigm under Erigon and asked if it was them. The co-founder of the Gnosis chain responded, "Yes, it does".

source:

https://twitter.com/ErigonEth/status/1595479897220055041

https://twitter.com/LefterisJP/status/1595524180035919885

https://twitter.com/gakonst/status/1595648232226291712

secondary title

Metamaks' new privacy policy will collect user IP and wallet addresses

On the 23rd, Metamask updated its privacy policy, and its default RPC provider, Infura, will collect the following information from users:
Identity information, such as first name, last name, username or similar identifier, job title, date of birth, and gender;
Contact information, such as postal address, email address and telephone number;
Personal profile information, such as username and password, interests, preferences, feedback and survey responses;
Feedback and communications, such as information provided by users when they answer surveys, when users participate in market research activities, report service issues, receive customer support, or otherwise communicate with them;
financial information, such as credit card or other payment card details;
transactional information, such as details of purchases made by users through their services and billing details;
Usage information, such as information about how users use its services and interact with them;
Marketing information, such as user preferences for receiving marketing communications and details of how to engage with them;
Financial information, such as bank account numbers and bank router numbers; holdings of financial assets;

Technical information such as Ethereum wallet addresses, application programming interface (API) keys, and network information about transactions.

Regarding Metamask's policy of collecting user privacy information, users have the following three countermeasures:
Choose an RPC provider that does not collect private information and continue to use the Metamask wallet.
source:

source:

https://consensys.net/privacy-policy/

https://twitter.com/CryptoSnooper_/status/1595604825734987776