Security Ratio is calculated wrong.

[MicahZoltu]

frontend/src/mainsite/components/TotalValueSecured/TooltipSecurityRatio.tsx

Lines 30 to 32 in ddf5b36

	// 1e18 is Wei -> ETH, 1e12 is displaying in trillions, 1e2 is scaling down from using cents not dollars above.
	// We then leave four orders of size, because we expect a number < 0, which a bigint cannot hold.
	(num) => JSBI.divide(num, JSBI.BigInt(1e12 * 1e18 * 1e2 * 1e-4)),

The total amount of assets on Ethereum isn't what matters from a security standpoint. What matters is the total amount of assets that transferred ownership between most recent finalized block and head. Even more precisely, it is the total amount of assets transferred in exchange for some off-Ethereum good/service.

It is impossible to know this number precisely as we cannot know which transactions are causing asset ownership changes nor which are in exchange for off-chain goods/services, but we can probably get into the right ballpark by just assuming all ERC20 and ETH and NFT transfers are between owners in exchange for off-chain assets. This will give us a far more realistic view of the security ratio than just totally all assets on Ethereum and dividing by the stake.

On the stake side of the equation, we shouldn't count all stake, but rather the amount of stake an attacker would lose in an attack. In the most pathological scenario, I think this is something like 20% (or maybe it was 30%) of all stake due to possible proposer boost manipulation. Note: this assumes that there is no custodial or pooled staking, but for simplicity we should probably ignore these anyway and be optimistic.

So final formula would be something like total_assets_transferred_since_finality_in_usd / (0.2 * total_staked_eth_in_usd).

[JustinDrake]

What matters is the total amount of assets that transferred ownership between most recent finalized block and head.

I'd argue it's the total amount of assets that could be transferred between the most recent finalized block and head :)

[MicahZoltu]

I have been chewing on this and you make a good point, though I'm not sure how useful of a metric that ends up being pragmatically. I don't think "all money changed hands within a few minutes" has ever occurred in any financial system in all of history, and I suspect reasonable people can agree that trying to secure against that would be a massive waste of money.

You are technically correct though, that what I'm proposing isn't security of the future but rather how secure we were in the past. Of course, past performance is not indicative of future success, so one shouldn't use the metric I proposed to decide whether Ethereum will be safe, only to approximate how safe it has been over time (e.g., a chart should this).

[JustinDrake]

only to approximate how safe it has been over time

It's a false sense of past security :)

[MicahZoltu]

I could see an argument for a false sense of future security, but I don't see the argument for a false sense of past security.

We can get a pretty good idea of how much value was transferred on the network in the past, and we know how much was at stake in the past, so we can derive the past security metrics.

Perhaps a better metric would be: "How much value can be transferred in exchange for off-chain goods/services per block (on average) in order to be economically secured against double spend type attacks". This could include things like proposer boost causing a need for less than 50% of stake and we could include other factors that effect security.

[JustinDrake]

much value was transferred on the network in the past

We don't know how much value could have been transferred in the past.

[MicahZoltu]

We don't know how much value could have been transferred in the past.

Why does that matter here? The goal is to provide the user with useful and actionable information. Knowing that some parallel universe where a different amount of value was transferred in the past doesn't seem particularly useful nor actionable.