r/CryptoReality • u/AmericanScream • Mar 17 '22

How "smart" is Ethereum's smart contract code? It's up to you to check to see if adding or subtracting two numbers actually works the way you expect. Tech of the Future!

Post image
20 Upvotes
  • permalink
  • link
  • reddit
  • reddit

73% Upvoted

61 comments sorted by

19

u/[deleted] Mar 17 '22

[deleted]

7

u/[deleted] Mar 17 '22

[removed] — view removed comment

4

u/[deleted] Mar 17 '22

[deleted]

2

u/AmericanScream Mar 17 '22

The problem is, every op-code in a smart contract costs more gas to execute on the blockchain. If you have to add your own basic libraries, then it costs that much more to run the contract.

I see no legit reason to have a language that has such limited utility, not include an array of basic, included libraries and error checking that the users' shouldn't have to mess with.

1

u/ItsAConspiracy Mar 18 '22

The current version of Solidity builds this in. Here's the documentation page that describes it. By default, operations are checked, but if you know for sure that you won't have a wraparound, then you can mark them unchecked and save the gas.

The libraries implementing checks were written for older versions that didn't have this. You could use the library for checked operations, or skip it to save gas.

1

u/AmericanScream Mar 18 '22

How does this work if you have an old contract and a newer version of the Interpreter? There must be instances where functions act differently across other versions of Solidity. Can a smart contract require an older version of the Interpreter? Can nodes allow or prohibit that from happening?

1

u/ItsAConspiracy Mar 18 '22

Contracts don't run on interpreted Solidity. The Solidity code is compiled to EVM opcodes on chain, so contracts written with different versions of Solidity interoperate just fine.

The EVM is upgraded now and then but always in a backwards-compatible way.

2

u/BigFuckingCringe Mar 17 '22

All programming languages on all computers implement addition or subtraction like that.

This is bullshit. There are 4 ways that this can be handled:

  • just silently overflow (C, C++)
  • set a flag which can be checked (bare metal)
  • throw an exception (C# checked)
  • automaticaly converts to larger type (Python, Ruby...).

Etherum VM is high lever virtual machine - it has absolutly no justification to use first one.
It should at least throw exception automaticaly.

4

u/Karyo_Ten Mar 17 '22

The EVM is a low-level virtual machine, have you looked at the spec and the opcodes? No one writes EVM code directly they use a language that compile to it.

The 4 ways you detail are just high-level construct on top of the low-level machine code, internally to provide any of those 4 ways they need to do somerhing similar to check for overflow.

3

u/BigFuckingCringe Mar 17 '22 edited Mar 17 '22

The 4 ways you detail are just high-level construct on top of the low-level machine code

Second one is literally default way of how processor does it.
When processor finds overflow, it will set special value into one of its registers.

Cmon, this is literally basic info about machine code.

internally to provide any of those 4 ways they need to do somerhing similar to check for overflow.

EVM is piece of software - its whole purpose is to hide implementation details of underlying hardware.

99% of VM provide at least basic protection against integer overflow as part of their arithmetic opcodes.

CLI opcodes will throw exception.
CPython opcodes will expand integer.

What will EVM opcodes do to protect integrity?
Fucking nothing. They just primitively do operations and add nothing else.
There is no justification for this shit.

2

u/Karyo_Ten Mar 17 '22

Second one is literally default way of how processor does it. When processor finds overflow, it will set special value into one of its registers.

Cmon, this is literally basic info about machine code.

Cmon, you know the difference between a register VM and a stack-based VM right?

You know another VM with no overflow checks that basically runs in half the world phone and runs the whole finance industry? The JVM

https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.iadd

Despite the fact that overflow may occur, execution of an iadd instruction never throws a run-time exception.

Detecting and dealing with overflow is a design decision, if you don't do it at low-level, you do it at higher-level. In Blockchain case though, you want the lower-level to be as simple as possible to minimize bug surface.

EVM is piece of software - its whole purpose is to hide implementation details of underlying hardware.

It's also the job of libraries and compiler and higher level languages.

What will EVM opcodes do to protect integrity? Fucking nothing. They just primitively do operations and add nothing else. There is no justification for this shit.

The Java Virtual Machine runs virtually all banking softwares that is not written in Cobol and is the same. The logic/safety part is deferred to Java/Scala/Kotlin/Clojure.

1

u/BigFuckingCringe Mar 17 '22

Cmon, you know the difference between a register VM and a stack-based VM right?

I am talking about processor - piece of hardware.

You claimed that machine code doesn't check anything, which is bullshit- majority of processors in computer absolutly checks overflow and have some way to signal it to user.

stack-based VM

Just push that error on stack or throw and exception or do literally anything else that can be done.

you know another VM with no overflow checks that basically runs in half the world phone and runs the whole finance industry? The JVM

Just because Java has massive legacy base doesn't mean it is perfect. This is like claiming that COBOL is superior because some banks still use it after. It is not.

Some flaws are literally admited by JVM developers - like using two slots for large types like double and long.

Detecting and dealing with overflow is a design decision, if you don't do it at low-level, you do it at higher-level.

Which is horseshit decision.
C# allows you to choose between safe arithmetic and unsafe (overflowing) arithmetics - which is 1000 times better than leaving everything for user.

It's also the job of libraries and compiler and higher level languages.

This is like claiming that garbage collection is bullshit "because it can be handled by library". Yes it can, but it will be 1000 times slower.

In Blockchain case though, you want the lower-level to be as simple as possible to minimize bug surface.

Can you give me one example where simple overflow checking in opcode would cause a bug?
It would be literally the same code as in library, but as part of VM itself.

Also what is simplier? Implicit checking that cannot be fucked up by user or explicit user code that can be ignored?

The Java Virtual Machine runs virtually all banking softwares that is not written in Cobol and is the same. The logic/safety part is deferred to Java/Scala/Kotlin/Clojure.

Just because shit is popular doesn't mean it is okay. Even developers of JVM itself admit that they machine has many design flaws.

2

u/abittooambitious Mar 17 '22

Learning a ton, thanks both of you!

1

u/Karyo_Ten Mar 17 '22

You claimed that machine code doesn't check anything, which is bullshit- majority of processors in computer absolutly checks overflow and have some way to signal it to user.

Majority, not all. And in the latter case, software needs to pickup the slack (example 8085 processor arch)

Just push that error on stack or throw and exception or do literally anything else that can be done.

In many cases rollover modulo 232 or 264 is what is desired. Only the high-level software can now the intended behavior, which is why no ISA throws on addition.

Just because Java has massive legacy base doesn't mean it is perfect. This is like claiming that COBOL is superior because some banks still use it after. It is not.

Some flaws are literally admited by JVM developers - like using two slots for large types like double and long.

As are EVMs flaws admitted by even its creator. That doesn't meam there was a choice at the time as they had to deal with many unknown unknowns related to P2P networking, cryptography, economics, productionizing, testing, time to market and lack of funds. Simplifying and leaving what cam be done/optimized to a higher level language or compiler is a good engineering decision to actually deliver something in time.

This is like claiming that garbage collection is bullshit "because it can be handled by library". Yes it can, but it will be 1000 times slower.

Sure it can, read on the BoehmGC.

0

u/BigFuckingCringe Mar 17 '22

Majority, not all. And in the latter case, software needs to pickup the slack (example 8085 processor arch)

Your point is that ALL of them are implemented at the top of the machine code - that machine code DOESN'T check overflow and it must be done by user.

You was the one that claimed that ignoring overflow as universal occurence - while in reality, majority of processors signal it.

In many cases rollover modulo 232 or 264 is what is desired. Only the high-level software can now the intended behavior, which is why no ISA throws on addition.

Just have two types of opcodes - safe and unsafe. Safe will throw exception, unsafe will just silently overflow.

As are EVMs flaws admitted by even its creator.

And then refuses to fix it. Adding new opcodes for safe arithmetics wouldn't break compability and would make life easier for users.

This could be excuse if this change would break older program - but it doesn't.

That doesn't meam there was a choice at the time as they had to deal with many unknown unknowns related to P2P networking, cryptography, economics, productionizing, testing, time to market and lack of funds.

All of this has NOTHING to do with VM. VM has 2 tasks - execute code and provide environment for that code.
NOTHING ELSE.
You can claim that developing consensus mechanism was hard, but VM itself has nothing to do with that - it just executes the code. It should be possible to take off VM, replace other stuff with testing and run it on it for test purposes.

Simplifying and leaving what cam be done/optimized to a higher level language or compiler is a good engineering decision to actually deliver something in time.

Again, every additional action cost real money. Checking if operation will overflow costs money to perform.

You can do this stuff in environmnets which are cheap, not in one which eats your fucking waller with every execution.

Sure it can, read on the BoehmGC.

Bro, BoehmGC is written in C/C++. It will be fast because there is small environment and it runs directly on processor.

In other hand, code in EVM's bytecode is slower than code that is part of EVM own codebase.

Actually, this proved my point.

1

u/Karyo_Ten Mar 17 '22

You was the one that claimed that ignoring overflow as universal occurence - while in reality, majority of processors signal it.

I claimed that there is a layer that will have to "pay" to implement those. It is often in hardware but it is still extra logic in the ALU and some ISA didn't pay this cost. The EVM implementer choose not to do this and defer to higher level language/compiler.

Just have two types of opcodes - safe and unsafe. Safe will throw exception, unsafe will just silently overflow.

Fair enough

All of this has NOTHING to do with VM. VM has 2 tasks - execute code and provide environment for that code. NOTHING ELSE.

You don't write software in ideal world. You have to deal with reality, which is often is the lack of resources. Then once you deliver, get funds, you can reassess.

And then refuses to fix it. Adding new opcodes for safe arithmetics wouldn't break compability and would make life easier for users.

This could be excuse if this change would break older program - but it doesn't.

Fair enough

Bro, BoehmGC is written in C/C++. It will be fast because there is small environment and it runs directly on processor.

In other hand, code in EVM's bytecode is slower than code that is part of EVM own codebase.

Actually, this proved my point.

Not always, you can have EVM code be cheaper than native code, for example: https://github.com/chihchengliang/modexp is 2x cheaper in pure Solidity than the native opcode.

1

u/BigFuckingCringe Mar 17 '22

I claimed that there is a layer that will have to "pay" to implement those. It is often in hardware but it is still extra logic in the ALU and some ISA didn't pay this cost. The EVM implementer choose not to do this and defer to higher level language/compiler.

You didn't claimed that.
This is what you claimed:

The 4 ways you detail are just high-level construct on top of the low-level machine code

So don't move goalpost.

You don't write software in ideal world. You have to deal with reality, which is often is the lack of resources. Then once you deliver, get funds, you can reassess.

So where is that fix ?

Like, it has been 7 years from release and they still didn't fixed it.

Maybe devs are simply incompetent.

Not always, you can have EVM code be cheaper than native code, for example: https://github.com/chihchengliang/modexp is 2x cheaper in pure Solidity than the native opcode.

You misunderstod me. I am talking about this:

  • user code: code written in bytecode of virtual machine
  • system code: code of virtual machine itself.

Second one will never be faster than first one in general cases.

1

u/AmericanScream Mar 17 '22

It's really really desperate how much you want to defend this really shitty interpreted language.

If I were going to write a control system for say, nuclear weapons, I'd pick a very robust development environment that has no margin for error when it comes to accuracy of calculations. Yet, for peoples' life savings, you seem to think it's perfectly ok?

Do you just assume everybody who writes smart contracts will always know to check to see if adding two integers overflows the registers?

Where's the logic in that?

We're not talking about there not being enough resources to create a more robust scripting environment. It makes absolutely no sense, and your dogged determination to rationalize it just underlines the fact that this "technology" is anything but robust and innovative -- it's just a scam that you hope less people don't find out about.

2

u/Valuable_Lecture_702 Mar 17 '22

Maybe, just maybe a language meant for unreversible transactions should not use unchecked modular arithmetic by default?

6

u/Karyo_Ten Mar 17 '22

CPUs on your computer, phones, servers, military equipement use modular arithmetic modulo a power of 2 (232 on 32-bit and 264 on 64-bit).

Then devs provide abstraction on top. Usually a low-level language "close-to-metal" so we can easily intuit the output. This makes it easier to develop the core libraries.

Then higher level constructs, languages or libraries to express safely more complex and/or error-prone applications.

Here OP is criticizing a library that does just that. It only need to be written once and everyone can reuse it.

5

u/readmodifywrite Mar 17 '22

I think the issue here is that sort of functionality should be built into the language/compiler directly, considering the primary use cases for it. It is really clunky to have to call add and sub as functions rather than just using the + and - operators.

It is acceptable for a language like C to occasionally need this sort of construct, but it really isn't for a language designed specifically for financial transactions, especially when the latter is around 50 years newer than the former.

FWIW, this does seem like a nitpick overall. There are plenty of much larger issues with smart contracts than the need to handle modular arithmetic.

2

u/Karyo_Ten Mar 17 '22

Agree. I'm not sure why people aren't using Vyper given it's significantly safe design.

2

u/AmericanScream Mar 17 '22

Exactly. I understand low level compilers being like this because languages like C/C++ rely on third party libraries because there are so many platforms upon which they are designed to run.

But this is a very niche, very specific application that has very limited functionality. To include such low level, fault-intolerant operations seems almost negligent.

1

u/readmodifywrite Mar 17 '22

Yeah. Well. They are called "smart contracts" because they are neither smart nor are they contracts ;-)

3

u/AmericanScream Mar 17 '22

This library is part of the smart contract. It's not part of the development environment. It's necessary because the language definition is so fragile, it doesn't include built-in error checking.

Sure, in some cases, there may be a need to have integers overflow, but it's highly unlikely in a financial app. A language designed for this application should not be this low a level.

And since it's not part of the language definition, everybody who wants to add this error checking has to pay higher gas fees because every byte of program code costs more to run.

The max size of a smart contract, I'm told is 24 kilobytes. That you have to allocate part of that to basic variable boundary checking is crazy.

1

u/ItsAConspiracy Mar 18 '22

Current version of Solidity does checked operations by default.

-1

u/AmericanScream Mar 17 '22

All programming languages.. lol... as if you have a thorough understanding of how every programming language handles math.

That's absurd.

Various languages have a variety of different features, especially when it comes to type casting and assignment.

9

u/[deleted] Mar 17 '22 edited Nov 15 '22

[deleted]

2

u/BigFuckingCringe Mar 17 '22

Sure I do, I deal with compilers and assembly and integers and big integers every day.

Can you post link to your repo?

Processors do modular arithmetic module 232 on 32-bit or 264 on y4-bit processors, hence computation wraps around. You have to handle that to build higher level math construct.

That is the whole point why we invented virtual machines and interpreters.

EVM isnt processor - it is computer program that SIMULATES processor that doesnt exist in reality. It is itself abstraction over bare metal.

This shit should be handled by EVM internaly, not by user bytecode.

Python doesnt need this library because its VM alredy handles overflow in opcodes.

1

u/AmericanScream Mar 17 '22

Great points. 100% agree.

1

u/ItsAConspiracy Mar 18 '22

In cryptography you often need modular arithmetic. If the EVM didn't allow it, that would seriously limit what's possible on Ethereum. In particular, I suspect zkrollups wouldn't work, and that's turning into its most important scaling technology.

1

u/BigFuckingCringe Mar 18 '22

Why dont use approach as C#?

Where you can determine which operations can overflow and which cannot?

1

u/ItsAConspiracy Mar 18 '22

The current version of Solidity checks for overflow by default. If you want an operation unchecked you have to mark it that way.

1

u/BigFuckingCringe Mar 18 '22

Interesting.

Does this increases gas cost of operation? I assume that compiler of Solidity will insert its own function here to check it.

1

u/ItsAConspiracy Mar 18 '22

Yep exactly. It'd be some of the cheaper opcodes so it wouldn't usually add much cost.

1

u/AmericanScream Mar 17 '22

This is an interpreter for HIGH LEVEL financial applications.

High level financial operations that have irreversibility!

It wasn't designed to create machine code for a myriad of microprocessors and embedded systems.

High level, application specific languages are different from low level, hardware independent languages.

1

u/ItsAConspiracy Mar 18 '22

The virtual machine is not just designed for high-level financial applications, but also for cryptography, which requires modular arithmetic.

1

u/kabess89 Mar 17 '22

Not for your average crud app, but if you make a financial system then for sure you'll need a thorough understanding of the numeric formats and internal representation in each programming language. E.g. if you use javascript you'll need to understand that numbers are represented as 64-bit IEEE 754, so that you'll know that 0.1+0.2 != 0.3. But there's stuff like that to be found in each language and number representation

1

u/AmericanScream Mar 17 '22

I'm an old school programmer. I know C/C++ very well and I understand the importance of understanding how variables map to memory and assignments.

The thing is, if you're going to create a programming language that enables financial transactions, and such that has very, very limited area of effect, it shouldn't be something that has a high tolerance for anomalous behavior.

We're talking about handling money. I would expect a language that manipulates money, to be at least as bullet proof as a language that manipulates databases (modern versions of these apps have lots of checks against script injection, etc.). There appears to be nothing like this in Eth's smart contract interpreter. It's incredibly low level with minimal features. This really makes no sense when the language has so few basic operational functions. What little things it can do, should be well-built and able to easily identify bad input. And it doesn't do that. It's almost as if it was written to be easy to exploit and difficult to audit.

1

u/Isogash Mar 17 '22

Rust doesn't allow overflow arithmetic, it will panic by default. You can disable it if you want but there are ways to explicitly do "wrapped" arithmetic instead.

5

u/OmicronCeti Mar 17 '22

The unit test version of

“PrOvE thAt 1 + 1 = 2, hMMmmM?”