The gov says we are not in recession, but at the same time, we hear about skyrocketing inflation, interest rate increases, and layoffs in almost every sector of the economy. Despite crypto and TradFi being impacted the most severely, many companies are still building their tokens, protocols, and DeFi products. Are you one of them? Today, I will be speaking on data types, and hold on. I have something very important to say. You might picture me as a 60+-year-old professor from MIT torturing students with lectures about subjects that no longer matter. But that’s not true. Data types are still important, and neglecting them leads to serious consequences. I will try to briefly go through all potential issues and address them so you don’t find the 8 minutes you spend on reading this article wasted. Modern languages like JavaScript and Python are using “duck typing” to determine the type of variable. If we assign this sort of formula to a variable, the language interpreter knows it is dealing with numbers, and it will perform mathematical operations on this literal. a = 2 + 2 The duck typing can be explained by this sentence: “If it walks like a duck and it quacks like a duck, then it must be a duck”. When you look closer into the meaning of it - it makes perfect sense. If literal has letters and numbers, it must be a string, and that’s clear. But what if it has numbers? Is it a , , , , or . In most cases, your language interpreter will handle types in the correct way. The problem starts when your program needs to run (even simple) equations on large numbers. boolean integer decimal float date “If it walks like a duck and it quacks like a duck, then it must be a duck”, right? Actually it’s not. Ethereum Denominations in a Nutshell In the next paragraphs, I am referring to Ethereum common denominations - and . Let me briefly introduce you to them so we speak the common language. wei gwei The smallest denomination is , and equals (18 zeros) I repeat - 18 zeros. It is hard to wrap our minds around such large numbers but they make a difference and matter a lot. 1 wei 1 ether 1,000,000,000,000,000,000 Wei . The next common denomination is . equals (9 zeros) Gwei is more bearable for humans - in the end, everybody wants to be a millionaire, right? (wink, wink) 1 gwei 1 ether 1,000,000,000 gwei . Let’s sum it up - 1 ether equals: 1,000,000,000 gwei (9 zeros) 1,000,000,000,000,000,000 wei (18 zeros) Technical note: Ethereum has two layers - the execution layer and the consensus layer. The execution layer is using wei to represent ether values, and the consensus layer is using gwei. If you are a blockchain developer, you need to learn to interact with both. Real-World Example: Stakefish’ tip and MEV Pool I am a software engineer at . I’m responsible for building our DeFi products palette, and one of the most recent ones is our tip and MEV pool for Ethereum. stakefish Starting from September 15, 2022, all validators are eligible for transaction tips and can participate in MEVs to earn additional rewards. Transaction tips and MEVs are earned when the validator proposes a new block. We decided to build a smart contract that collects all rewards into a common vault and allows user to claim their share from it. I am not trying to advertise our product, but I need to set the context of this article. If you are more interested in this product, you can . I’m not selling you anything besides my experience. read more here As I mentioned, we have a smart contract that receives transaction tips and MEV rewards earned by validators. It means our smart contract has a fairly large balance. It is 963+ ether now ($1.1M), and we have 8671 validators contributing to it. The critical part responsible for synchronization between Ethereum execution and the consensus layer is . It is a very important system that allows us to determine what validators are contributing to the pool. Oracle The oracle is written in Python, but it could be written in JavaScript - the problem remains unchanged, and I will prove it soon. Let’s deep dive into the code! Why Data Types Matter The balance of the smart contract equals 963,135,554,442,603,402,422 wei (963 ether) now. This number isn’t only hard to understand for humans but also for computers (language interpreters to be exact). Let’s check JavaScript: const vault_balance = parseInt("963135554442603402422") console.log(vault_balance) // 963135554442603400000 (lost 2422 wei in total) I only casted the balance from to , and I am already short. We didn’t run any equation yet. string int 2422 wei The smart contract balance is so high thanks to many validators contributing to it. Now, let’s calculate what the average validator share of contract’s balance now: const vault_balance = parseInt("963135554442603402422") const validator_count = 8671 const avg_validator_contribution = vault_balance / validator_count // 111075487768723730 (lost 7 wei per validator) The average share is 0.111 ether. But this amount isn’t correct - we are actually 7 wei short. It is in total (7 wei times 8671 validators). I will show the correct number later on. 60,697 wei Proceeding further down the rabbit hole of losses - let’s calculate the total amount of rewards per given validator. Have in mind that the user needed to deposit 32 ether to start a validator, so I will deduct it from the validator balance. And I will take as an example one random validator contributing to the smart contract that has a balance of 32.779 ether. const vault_balance = parseInt("963135554442603402422") // (lost 2422 wei) const validator_count = 8671 const avg_validator_contribution = vault_balance / validator_count // (lost 7 wei) const initial_deposit = parseInt("32000000000000000000") const validator_balance = parseInt("32779333896000000000") const total_validator_rewards = validator_balance - initial_deposit + avg_validator_contribution // 890409383768723700 (lost 23 wei per validator) The total rewards earned by this validator equals 0.8904 ether, but this value isn’t accurate as well. At this moment, we miscounted for in total (23 wei times 8671 validator). As you can see, this way of calculating numbers isn’t sustainable. 199,443 wei What Goes Wrong? There are two problems with the code above: In JavaScript, the maximum safe value for integers equals only. It means it can handle up to (0.009 ether) 2^53 - 1 9007199254740991 wei Technically, we could have used but we would have problems with division. We would end up with “floating” values. The floats are the root of all evil in finance because they are approximate. It means they lose precision. We need to use decimals. (The main difference between decimal and float is that decimal stores exact value and float approximates.) BigInt If you ever had done any Ethereum-related coding in JavaScript, you must’ve heard about . This library contains all the necessary utilities to interact with the blockchain. To fix the issue above, we will use one of the tools called that supports extremely large numbers and handles decimals in the right way. ethers.js BigNumber Let’s do it! const vault_balance = BigNumber.from("963135554442603402422") // no loss const validator_count = BigNumber.from(8671) const avg_validator_contribution = vault_balance.div(validator_count) // no loss // 111075487768723723 const initial_deposit = BigNumber.from("32000000000000000000") const validator_balance = BigNumber.from("32779333896000000000") const total_validator_rewards = validator_balance.sub(initial_deposit).add(avg_validator_contribution) // 890409383768723723 As you can see, now we ended up with the accurate number. How do I know this is actually the right number? I will repeat the same exercise in Python to prove that I’m right. Let’s Try It in Python Python supports long integers, so the values will not get suddenly cut as we have seen in JavaScript. Unfortunately, it still determines all floating numbers as s by default: float vault_balance = int("963135554442603402422") # no loss validator_count = 8671 avg_validator_contribution = vault_balance / validator_count # 111075487768723728 (5 wei too much) initial_deposit = int("32000000000000000000") validator_balance = int("32779333896000000000") total_validator_rewards = validator_balance - initial_deposit + avg_validator_contribution # 890409383768723712 (lost 11 wei) Wondering where exactly it lost precision? The division casted to instead of . The correct snippet would look like that: avg_validator_contribution float decimal vault_balance = Decimal("963135554442603402422") validator_count = Decimal(8671) avg_validator_contribution = vault_balance / validator_count # 111075487768723723 initial_deposit = Decimal("32000000000000000000") validator_balance = Decimal("32779333896000000000") total_validator_rewards = validator_balance - initial_deposit + avg_validator_contribution # 890409383768723723 Now, the values returned by Python and JavaScript are exact. Check on your own! These sorts of losses are marginal, and they can be easily missed. Often, we find out about them when they compound over time and grow to significant numbers. Situations like that always give headaches, not only to developers but also to other departments such as finance or legal. You should always test your formulas, and never use nice round numbers to do so! It would mean the world to me if you . I am focusing my activity on software engineering and blockchain. I am open-sourcing most of my work, so you might want to check . follow me on Twitter my GitHub
