<p>Other nodes do the same computation, in a deterministic fashion, and they compare their result to the result the miner got. That's why there's no function that returns random results - different nodes would come up with different numbers, and the chain would fork. All other miners verify your block, and the penalty for building an incorrect block is losing the block you mined.</p>

<p>But there's a related question: can you gain an advantage by improving the speed of the VM, or skipping computations somehow?</p>

<p>I think you could. For example, you could offload the computations to a GPU. Even though Dagger is GPU-resistant, the VMs require a small amount of memory and could probably be run on a GPU.</p>

<p>The advantage would be pretty slight, though.</p>

CC BY-SA 3.0
2015-08-20T03:56:54.760Z
You're a little out of date with the mining algorithm, it got changed several times and is now supposedly GPU friendly, ASIC and pool resistant. A pool does have [40% of the network hash power](https://www.reddit.com/r/ethereum/comments/3hk9z0/everyone_stop_using_ethpoolorg_and_try_a/) though so the latter claim is provably incorrect.
Claris
CC BY-SA 3.0
2015-08-20T05:01:39.173Z
Thanks, I figured it was something like that, but I'm still confused.  First, more fundamentally, are all results of computation returned in the block chain as part of transaction?  Speed of return seems to indicate I'm getting first processer results back, regardless if block is invalidated later. I don't seem to wait for N confirmations of the block before getting my result.  Next, what about a contract asked to return some identifier of the node processing it? That would be a different result depending on who processes it, and not verifiable by others. Or millisecond timestamp?
JesseM
CC BY-SA 3.0
2015-08-20T03:44:48.433Z
2015-08-20T03:44:48.433Z
Nick ODell
<p>This may be as simple as a pointer to some place in the docs I've missed, but how/where is the output of a contract's computation checked, or assured against a malicious miner with an intentionally corrupted VM implementation?</p>

<p>Trivial example:
My contract takes two inputs, A and B, and returns their sum.  A disreputable miner wants to collect txn fees and the ethereum for the gas for this contract without doing the work, and hacks his VM implementation to always return "4" to the caller.  Any one who tests with "2+2" will think the function works.  </p>

<p>Assume the miner succeeded in mining the block with a request for my contract, and returned "4" (so as to not waste their own compute power, and pocket the gas cost).  Block hashes for transaction accepted and ether transferred are all correct and checkable, the source and opcodes of the contract are all checkable and correct.  But how is the output of the computation checked for correctness?</p>

<p>I feel like I'm missing something obvious.  What stops a miner from short circuiting the requested work (whatever it is), claiming to have finished the job, while only returning something syntactically correct, but semantically dubious or wrong?</p>

<p>Thanks.</p>

<transactions><transaction-fees><verification><transaction-verification><ethereum>
Ethereum - how is the output of a contract computation verified?
JesseM
# Ethereum - how is the output of a contract computation verified?

(Asked by: username_0 on 2015-08-20)

This may be as simple as a pointer to some place in the docs I've missed, but how/where is the output of a contract's computation checked, or assured against a malicious miner with an intentionally corrupted VM implementation?

Trivial example:
My contract takes two inputs, A and B, and returns their sum. A disreputable miner wants to collect txn fees and the ethereum for the gas for this contract without doing the work, and hacks his VM implementation to always return "4" to the caller. Any one who tests with "2+2" will think the function works.

Assume the miner succeeded in mining the block with a request for my contract, and returned "4" (so as to not waste their own compute power, and pocket the gas cost). Block hashes for transaction accepted and ether transferred are all correct and checkable, the source and opcodes of the contract are all checkable and correct. But how is the output of the computation checked for correctness?

I feel like I'm missing something obvious. What stops a miner from short circuiting the requested work (whatever it is), claiming to have finished the job, while only returning something syntactically correct, but semantically dubious or wrong?

Thanks.

**Tags:** transactions, transaction-fees, verification, transaction-verification, ethereum


---

## 1 answers

### Answer by username_1 on 2015-08-20. Score: 3

Other nodes do the same computation, in a deterministic fashion, and they compare their result to the result the miner got. That's why there's no function that returns random results - different nodes would come up with different numbers, and the chain would fork. All other miners verify your block, and the penalty for building an incorrect block is losing the block you mined.

But there's a related question: can you gain an advantage by improving the speed of the VM, or skipping computations somehow?

I think you could. For example, you could offload the computations to a GPU. Even though Dagger is GPU-resistant, the VMs require a small amount of memory and could probably be run on a GPU.

The advantage would be pretty slight, though.

> **Comments:**
> **username_2**: You're a little out of date with the mining algorithm, it got changed several times and is now supposedly GPU friendly, ASIC and pool resistant. A pool does have [40% of the network hash power](https://www.reddit.com/r/ethereum/comments/3hk9z0/everyone_stop_using_ethpoolorg_and_try_a/) though so the latter claim is provably incorrect.  
> **username_0**: Thanks, I figured it was something like that, but I'm still confused.  First, more fundamentally, are all results of computation returned in the block chain as part of transaction?  Speed of return seems to indicate I'm getting first processer results back, regardless if block is invalidated later. I don't seem to wait for N confirmations of the block before getting my result.  Next, what about a contract asked to return some identifier of the node processing it? That would be a different result depending on who processes it, and not verifiable by others. Or millisecond timestamp?  

---

