GöeIP-001: Set Balance of 0x552fCB6425a1eD22696c967E741C3bC49c52c338 to Ninety-two Quintillion Ether

[q9f]

See also: #101

---

göeip: 0001
title: Set Balance of 0x552fCB6425a1eD22696c967E741C3bC49c52c338 to Ninety-two Quintillion Ether
description: Increase the total supply to prevent the network for gaining significant value.
author: Afri Schoedon (@q9f)
discussions-to: https://github.com/goerli/testnet/issues/97
status: Draft
type: Standards Track
category: Core
created: 2022-03-23

Abstract

Set the balance of 0x552fCB6425a1eD22696c967E741C3bC49c52c338 to ninety-two quintillion Ether.

Motivation

Setting the total supply to an enormously high value will prevent anyone from ever expecting this Ethereum developer-focused testnet to have any non-zero value.

Specification

The keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

As per FORK_BLOCKNUM on the Goerli Testnet, the balance of the account 0x552fCB6425a1eD22696c967E741C3bC49c52c338 shall be set to 92000000000000000000000000000000000000 (ninety-two quintillion Ether, 0x45368e347c3e8bcc6f2d29c000000000).

Any previous balance must be ignored and shall be overridden. No other irregular state changes are intended.

Rationale

The most simplistic approach to increasing the total supply without much development effort is to set a single account balance. Then, the funds can be later redistributed by the author of this proposal and the account owner, who has also shown similar efforts over the last three years since genesis.

Copyright

Copyright and related rights waived via CC0.

[q9f]

I would appreciate it if the geth team could indicate if this is an appropriate course of action for a testnet. @karalabe @fjl

As discussed today with @parithosh

Ref https://twitter.com/q9fmz/status/1505939597615935492

Also, #85 and ethereum/staking-launchpad#417 has a lot of historical contexts.

[prestonvanloon]

I support this effort. Thanks!

[kingliu8888]

Me too

[philknows]

Please sir, may I have some more? +1

[GregTheGreek]

+1 Inflation good for network security

[roninkaizen]

great idea, I support this as well, +1

[ligi]

I support it and hope it works to scare the faucet drainers/speculators away - but also wonder: who controls 0x552fCB6425a1eD22696c967E741C3bC49c52c338
A lot of power in this EOA ..

[Buttaa]

Please do it

[holiman]

I don't support this. Let's just make a new testnet, goerli2, and nuke the old one. Doing a testnet-only hardfork is a lot of work

[timbeiko]

Let's just make a new testnet, goerli2, and nuke the old one.

I think this shifts the balance of "hard" from client devs to the entire ecosystem. A lot of infrastructure providers serve Goerli, and several projects are deploying their staging environments on it. One thing that's useful for applications on testnets is having other contracts there so they can test interactions. When we nuke a testnet, you need to coordinate everyone to move to the new one.

Considering we are already planning to deprecate Rinkeby and Ropsten, I think keeping Goerli as a testnet where a lot of applications are already live (and which is linked to the Prater CL testnet) has a lot of value.

Doing a testnet-only hardfork is a lot of work

If that's the case, I think this definitely affects when we'd like to have this fork happen. My view is that we should not let this delay the merge, so if we expect significant overhead in doing this fork, then it should be considered for after that.

I misinterpreted the comment, my bad. AI(now)UI, I believe the issue is that a testnet-only fork is a lot of work not just "because we need to do a hard fork", but because there isn't an easy way to configure a fork which only goes live on a testnet. For example, from Geth: https://github.com/ethereum/go-ethereum/blob/a8040bc2c51605a4cca9e48cac83ff14928d50c2/params/config.go#L506-L507 (h/t @lightclient)

[GregTheGreek]

I don't support this. Let's just make a new testnet, goerli2, and nuke the old one. Doing a testnet-only hardfork is a lot of work

Valid point.

If we did start a new network It might be helpful to pre-allocated every account with Ninety-two Quintillion Ether (lol) each. We could generate that address by taking a snapshot of any account holding at least 0.1 ETH or something. I'd be willing to help string that together.

[timbeiko]

@GregTheGreek how easy/hard is it to keep the full network state? This way, you'd maintain deployed contracts.

[ligi]

It might be helpful to pre-allocated every account with Ninety-two Quintillion Ether (lol) each. We could generate that address by taking a snapshot of any account holding at least 0.1 ETH or something.

wonder if that 'airdrop' would not set wrong incentives for the group of people that create the problem in the first place

[GregTheGreek]

@timbeiko thats sort of the "ethermint problem" from way back. Forking a mainnet state requires more custom logic then actually adding support for networks specific hardforks.

From my POV i still think its not a crazy ask to have custom support for that.

I'd be happy to take a look to see how pluggable we could be, I know Besu can do this very easily.

Edit: It will be pretty ugly in geth to have

{name: "arrowGlacierBlock", block: c.ArrowGlacierBlock, optional: true},
{name: "mergeStartBlock", block: c.MergeForkBlock, optional: true},
{name: "goerliBalanceBlock", ...}

[GregTheGreek]

It might be helpful to pre-allocated every account with Ninety-two Quintillion Ether (lol) each. We could generate that address by taking a snapshot of any account holding at least 0.1 ETH or something.

wonder if that 'airdrop' would not set wrong incentives for the group of people that create the problem in the first place

Push the problem back 1-2 years lol

[q9f]

Hi @holiman - thanks for your perspective; I really appreciate it.

I don't support this. Let's just make a new testnet, goerli2, and nuke the old one. Doing a testnet-only hardfork is a lot of work

I want to say, I see three options moving forward: (1) increasing total supply minimalistic testnet-only hardfork (this proposal), (2) resetting genesis of goerli and reusing existing infrastructure but ditching state, and (3) starting a new testnet from scratch.

Unfortunately, options (2) and (3) would kill the ability to maintain and merge with the Prater beacon-chain testnet. In addition, (3) would lose all community and integration and even encourage developers to default back to deprecated or even dead networks such as Ropsten or Kovan: https://twitter.com/q9fmz/status/1507250849025773579

I'm still in favor of (1), and while I deeply respect your work and opinion, I would argue that a testnet hardfork that does not change anything on the EVM can be done with much less work than any other hardfork that would affect mainnet or change EVM behavior in any other way. I would even argue that security standards and test-requirement for a testnet are much lower.

Last but not least, the in (1) proposed change is very small.

[yangdiweif]

I think Inflation takes a lot of effort to implement and test. How long will it take? And when will it begin?

Btw, who is the owner of "0x552fCB6425a1eD22696c967E741C3bC49c52c338 " ?

In addition, it is worth considering that many developers and dapp companies coudn't get goerli so they have used a lot of money to buy goerli. Will Inflation cause imbalance and arguments and complaints?

[ghost]

PoC Geth Changes for GöeIP-001 ethereum/go-ethereum#24591

@holiman I don't think those 20 lines of changes seems to be "a lot of work"

I think Inflation takes a lot of effort to implement and test. How long will it take? And when will it begin?

@yangdiweif Only 3 lines would be necessary to make this change.

[q9f]

Btw, who is the owner of "0x552fCB6425a1eD22696c967E741C3bC49c52c338 " ?

I am.

PoC Geth Changes for GöeIP-001 ethereum/go-ethereum#24591

@holiman I don't think those 20 lines of changes seems to be "a lot of work"

I think he meant the process of testing and releasing.

The required code changes are intentionally minimalistic.

[irKxing]

I'm prefered to agree with @holiman.

I've been monitoring goerli transactions for the three days. The total amount of all transactions is very small.
@q9f, you still have 19 millon goeth, which can be used to get enough test goeth for all goerli developers. Why don't you share it with everyone and want to add Ninety-two Quintillion goeth to your own address?

I don't think it's worth doing a lot of hard forking for a testnet, or doing anything that might affect the mainnet.

[ligi]

I don't think those 20 lines of changes seems to be "a lot of work"

That's just one client. Also if clients have such single-testnet specific stuff in their codebase it increases their complexity (that is already too high) even more - moving to a state where it is really not maintainable anymore. So if it is really done it should be a generalized solution that is applicable do other networks also.

[holiman]

I also think the proposal is way too hacky. An alternate proposal which doesn't involve forever hardcoding Afri's key would be

• At the FORK_BLOCK, set the balance of all active signers to 92000000000000000000000000000000000000

[q9f]

I also think the proposal is way too hacky. An alternate proposal which doesn't involve forever hardcoding Afri's key would be

• At the FORK_BLOCK, set the balance of all active signers to 92000000000000000000000000000000000000

I'm fine with that. It's more generic and could also apply to other existing/future Clique networks if necessary. It's slightly more implementation effort though.

The alternative would be to reset the Goerli genesis by changing the initial allocation and bumping the chain ID - what do you think about this? (We would need to come up with a solution for Prater, though.)

[kingliu8888]

我也认为这个提议太老套了。另一个不涉及永远硬编码非洲的关键的提案是

• 在 FORK_BLOCK，设置所有活动的余额 signers 到 92000000000000000000000000000000000000

我没意见。它更通用，如果有必要，也可以适用于其他现有/未来的集团网络。不过，实施工作稍微多一些。

另一种选择是通过更改初始分配和碰撞链ID来重置Goerli起源- -您对此有何看法? （不过，我们需要为普拉特想出一个解决方案。）

👍👍👍

[ghost]

The alternative would be to reset the Goerli genesis by changing the initial allocation and bumping the chain ID - what do you think about this? (We would need to come up with a solution for Prater, though.)

@q9f Could we preserve every state data from Goerli using this method or we are purging everything and beginning from zero?

[q9f]

Could we preserve every state data from Goerli using this method or we are purging everything and beginning from zero?

I don't think this is feasible, we would have to bundle the entire state with the clients. I would go for a clean state instead.

[ghost]

I don't think this is feasible, we would have to bundle the entire state with the clients. I would go for a clean state instead.

Yes I tried this once and the client lagged a lot due to those hardcoded states from genesis block.

[q9f]

I also think the proposal is way too hacky. An alternate proposal which doesn't involve forever hardcoding Afri's key would be

• At the FORK_BLOCK, set the balance of all active signers to 92000000000000000000000000000000000000

I gave it a go: #101

[q9f]

Replaced by #101.