Build a plugin for calculating SCI of blockchains about hack HOT 13 OPEN

Very interesting and potentially impactful idea - here's some initial feedback off the top of my head...!

Initial take is that it will be very difficult to do ground up estimates accurately for a) multiple blockchains, and b) the entire network, although if you can source enough reliable data you could certainly try.

If you are thinking about doing bottom-up estimates, a more manageable discrete plugin could be for a specific network's client, e.g. an Ethereum validator node. You could then examine how the carbon expenditure varies across different execution/consensus client pairs, different hardware choices, number of additional validators per node, etc etc. (I'm just using Ethereum validators as an example here, you could swap out another network). Generalizing over the whole network means accounting for the different configurations of different operators (home staker, institutions, exchanges, etc) and their different hardware choices, grid carbon intensities, etc.

Bitcoin is the network with the greatest energy consumption and maybe that is good justification for focusing on creating a plugin for that first? I think it could be difficult to account for the fact that most mining is done using ASICs whose TDP is probably not easily sourced and the grid carbon intensity of the power they consume is probably also quite uncertain, and variable across locations and time, but I am really just speculating - I'd say it's well worth investigating further if you are keen for it with some of these complexities in mind.

The smart contract idea is interesting, but would be very complicated to do - is it the contract deployment you want to capture, or specific contract function execution, or the second order effects of adding code to the state trie?

The other data source I'm aware of apart from the one you cited is this https://ccaf.io/cbnsi/cbeci

on the other hand maybe there's an API call you can use to abstract away all the complexity of a ground up estimate - if you can retrieve carbon or energy from an external API then you can use our existing plugins to convert it into an SCI score.

Just some initial thoughts for discussion - encourage you to push ahead with refining the idea!!

from hack.

Love that you came back with such a detailed response.

Bottom up energy estimates based on gas is where my mind went first too, but there are some issues to think about:

• gas is for measuring the amount of work done by the virtual machine not the actual machine running the client software. Each EVM opcode has a certain gas cost associated with it, but the actual energy expended by the node might vary because clients implementing the EVM are available in several languages and are hardware agnostic. To be honest these variations might be miniscule, but nevertheless translating from opcode --> energy is going to be a challenge. Could be possible with some smart profiling though if you are really keen to mess around at a very low level.

• the estimateGas method is available for measuring the total gas likely to be used by a certain transaction; however, you still need a coefficient linking gas to energy, and you also need access to a node exposing the eth_estimateGas method. I guess in this case you could calculate your gas offline and pass it as an argument to your plugin. We do have plugins like that, where all they really do is multiply an argument by a coefficient and add the result to the outputs array to be used in IF (see e-net for example).

• You only pay gas for transactions that change the ethereum global state, so the gas-first approach only covers a subset of possible operations (e.g. would not cover eth_call or any view function in a contract.

None of these are blockers, just nuances to be consider as you refine the idea.

I would love to see you get a plugin out of this research, but there are other pathways to participating in the hackathon. I think the discussion in this thread could be worked up into a solid article to submit to the "best content" category (e.g. a detailed break down of why these bottom up estimates are hard plus recommendations for heuristics that can be applied), especially if you were to combine this with some IF-based estimates of SCI using our existing plugins (e.g. you could imagine a setup where you run some testnet validators on a cloud virtual machine, retrieve the usage stats via an API (our azure exporter plugin does this) then feeds that usage data through the sci-e -> sci-o -> sci-m -> sci pipeline to get an overall SCI score for your setup. Combined with some assumptions about hardware choices (maybe there's data?), validators per node etc etc you could potentially scale up to the network and compare with the existing data that you referenced earlier in the thread..?

Just throwing some ideas, but it seems like some combination of the concepts mentioned in this thread so far could become a pretty compelling project.

from hack.

Hi @ktg9 we've started having a few hackathon participants on our weekly livestream (Mondays at 1430 UTC) to chat through their ideas. If you are interested, you'd be welcome.

Sorry for slow response - we've been a bit tunnel-visioned overt he last week doing a big refactor. I'll respond to your last points soon!

from hack.

Hi @ktg9 registration emails will be going out to all teams this week. Keep an eye on your inbox :)

from hack.

Hi @Sophietn , I've decided to run this project solo 😄

from hack.

Hi @ktg9 - No problem. I'll remove the recruiting label on this issue. Best of luck!

from hack.

Hi @jmcook1186, thank you for your comment.
Sorry It took me a while to respond, because I want to read as much materials as I can so that I can discuss about this intelligently with you.

You're absolutely right about the difficulty of doing a ground up estimate. It's super hard or even impossible, since each network has multiple nodes; each node in turn runs on different OS, hardwares (and we don't know their configuration). So calculation via a models is impractical.

Right now, most of my knowledge regarding this issue coming from Crypto Carbon Rating Institute (CCRI) researches and reports. CCRI chooses the measurement via real world data approaches (as you can see in their paper https://carbon-ratings.com/dl/whitepaper-pos-methods-2023). To simplify, here is what do:

• First they analyze the blockchain network and choose its minimum requirement for a node
• Then they estimate the electricity for running a single node, calculate upper and lower bound. They estimate by measuring the electricity consumed by running the required software (validators, consensus,...) and compare it to the electricity in idle state.
• Multiple the energy for a single node to the number of nodes of the entire network

So, about your suggestion of examine how the carbon expenditure varies across different execution/consensus client pairs, different hardware choices, number of additional validators per node, etc etc, I think it's a great idea. What I can do is relying on CCRI data and build a plugin that calculate SCI scores for different hardwares, consensus mechanisms,... but then the plugin is really just a look up (since CCRI produces data by measurement, so they only tests some standard configurations, for example Intel i3-8109U, 2 cores, 8GB RAM, Ubuntu 20.04). The plugin's users can't receive the results outside of these configurations.

This also answers your question about bitcoin mining is done using ASICs whose TDP is probably not easily sourced and the grid carbon intensity of the power they consume is probably also quite uncertain; it's absolutely right. That's why CCRI chose a different approach, analyzing the minimum requirement energy consumption, producing a best guess energy consumption number and multiplying it to the number of nodes. So in this case, if I choose to use their data, then I have to trust their methodology also.

Another idea I have to the plugin is calculating SCI for each blockchain transaction (this includes, transferring tokens like ETH, USDT, BNB,..), deploying smart contract, executing smart contract function, etc. To do this, we can rely on the concept of transaction fee / gas fee. Let's take an example of Ethereum, in this blockchain, there are 3 types of transactions:

• Regular transactions: sending ETH from one account to another
• Contract deployment transactions
• Contract call transactions

Ethereum transactions cost gas, which refers to the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network and we have these data:

• Gas cost of each transaction can be calculated using eth_estimateGas method
• Total gas consumed every day is also available
  So, if we accept the number provided by CCRI about total energy consumed by Ethereum network per day, then we can calculate energy per transaction by formula (gas cost of transaction) * total energy / total gas

Here are challenges I'm facing with the above approach:

• The gas is documented as measures the amount of computational effort required to execute specific operations on the Ethereum network but it's not just that; it also includes a priority fee (https://ethereum.org/en/developers/docs/gas) which used to incentivize the miner/validator, motivating them to include the transaction into the block to be mined. Now the nature of this priority fee is just to tip the validator, it has nothing to do with the amount of computation required. How to extract the exact amount of gas paying for computation, or we can just take the gas as is and calculating SCI based on that ?

After a few days of researches, I discover that blockchain energy consumption is a vast topic and also pose a lot of questions. With the time and resources I have, I cannot produce a calculating model or do measurement via real world data by myself so I think the best way is to combine the data available from trusted sources and do some computation on that.

I really hope we can produce a plugin allowing blockchain users to know how their actions impact the environment. Hope to receive some of your insightful perspectives, @jmcook1186 and others.

from hack.

Hi @jmcook1186 , thank you for your answer.
I spent some days to think about it as well as doing some research 😃 .
I'm so happy to see you leave such insightful comments.

Here are my thoughts:

• About the last point that the gas-first approach only covers a subset of possible operations (e.g. would not cover eth_call or any view function in a contract). I totally agree, this is a potential blocker since it would be incredibly hard to calculate the energy spent for eth_call and view function because no data is available for them, I found no research for this problem. There is no reliable way to estimate how many eth_call and view calls per day and if somehow we come up with a number, then estimating the energy spent for these calls are impossible because many users don't directly call EVM node RPC for these operations, but they will call via an API like infura and these API services are run internally,. Therefore, I decide to only calculate carbon footprint for blockchain transactions (the calls that actually creates transactions and make change to the blockchain). The number that CCRI produces in their API also doesn't account for eth_call and view calls; but it works in my favor because I can say that all the energy they estimate is for processing transactions. For example if today's Ethereum energy consumption is 200kwh, and transactions are (t1,t2,...tn) then I can say that the total energy consumption for (t1,t2,...tn) is 200kwh.

• About this issue gas is for measuring the amount of work done by the virtual machine not the actual machine running the client software.; the EVM virtual machine is maintained in every full node. As stated in the doc The execution client (also known as the Execution Engine, EL client or formerly the Eth1 client) listens to new transactions broadcasted in the network, executes them in EVM, and holds the latest state and database of all current Ethereum data. (https://ethereum.org/developers/docs/nodes-and-clients). So about this point, if we say that all energy consumed by nodes is to serve the purpose of processing transactions (the execution clients, consensus clients) - then I think we can say these these transactions costs all the energy? What do you think about this point?

• About the point and you also need access to a node exposing the eth_estimateGas method. I guess in this case you could calculate your gas offline and pass it as an argument to your plugin. We don't need to calculate gas offline, there are many free APIs that allows us to do so, and my intention is to ask the user to input api key in input yaml file

• you still need a coefficient linking gas to energy -> This is brilliant, I've never thought of this thing honestly 😄 . This is also one of the blockers and I'm still working on it. As I mentioned, not all gas is spent for executing transactions in the network. In case of Ethereum, the gas fee also includes a priority tip. Therefore, I'm thinking of some methods to calculate the coefficient myself as a default, and I will also allow user to pass in their coefficient if they think theirs is more accurate.

If you have time, please look through these points 😄

Regards.

from hack.

This might not be the best way of doing it but to me it seems like we would have to run the nodes and measure the CPU usage by scanning the processs on the Operating System level (it is easier than it sounds). We can use one reference programming language for the node then do a relative calculation to estimate the nodes with other programming languages (we know the relative energy efficiency of programming languages anyway).

However, I am not sure why we would need a real time reporting of the energy efficiency of blockchains. This will not change drastically. An offline study done yearly will be more than enough. Am I missing something here?

from hack.

Hi @canhuzmeli,

I agree you can just run some nodes and retrieve some usage stats and feed them into a pipeline to estimate e.g. carbon intensity. Similar things have been done by several groups already. I think you're right that this is sufficient for most users.

What's being proposed here is a just the ability to be more granular - I think it's nice to have both - for example, people might be able to use @ktg9 's approach to understand how to minimize the impact of their specific setup.

from hack.

Hi @jmcook1186, I've registered this but still haven't received the email for next steps, can you check? 😃

from hack.

Hi @russelltrow , can you check this for me?

from hack.

Hi @ktg9
I see you have the 'recruiting' label for your Hackathon project!
Would you be interested in taking a segment on any of our Weekly Live Hackathon Prep and Q&A Sessions taking place every Monday 2.30 GMT, to discuss your idea and attract participants?

from hack.