Just read the white paper, and there's something important IMHO that isn't mentioned (or that I didn't understand): who executes the contract code? It's said "A contract is "activated" every time someone sends a transaction to it, at which point it runs its code" - but who's CPU physically will make those computations?
my guess is that the miner that finds the next block executes that code - so the time the computation takes is actually dependant on the miner that finds the block... won't it be a problem, if you have a really long computation (for example some numerical physics simulation), that in the meantime someone else finds a block? or maybe that particular contract both has a very long computation time and is highly timely dependent (for example, do some complex numeric simulation and decide to buy or sell some stock) - could these be relevant problems?
0 ·
Comments
The timing discrepancies or lets possible say jitter problems are over the top of my head as well. Wouldn't mind clarification. Maybe timestamping of a transaction after being accepted and processed by > x amount of nodes can act as on objective criteria?
@sjenkins that is a great question! We really need some devs to chime in on this... For example, let's say I make a contract that does "mining", i.e. it hashes a value incrementing it by one every iteration, until the hashed value has enough zeros... I set the difficulty (number of zeros) of this mining algorithm 100 times higher then the current ethereum difficulty, precompute several answers for it and publish the contract and send a transaction to it. Now what will happen, given that finding an answer to this takes 100 times (on average) longer than finding an ethereum block, is that while other miners are busy solving it I'll have all the time to find a real ethereum block (and use one of the precomputed answers for my contract). So I could basically do a 51% attack. Of course I'd have to send a giant fee to the contract, since if I understand correctly the ethereum protocol, miners would stop working on it once they've done more operations on it than the fee pays for... one would have to run the numbers to see if it's feasible, but still it's very scary... and it could turn out to be doable
If you target miners with this then its a twice amplified attack: Firstly the hash is run as native code as fast as the miner can manage while the bomb is run somewhat slower on a VM. Secondly you are only paying once for your code to be executed by *all* of the miners. (Devs, is this last part true?)
Still, the numbers may not work out and such attacks may be prohibitively expensive. Worth considering though that this is achieved by burning money for all the *real* work done on the network too.
Anything that makes the calculations potentially differ has to be avoided. For instance floating points would have to be treated carefully, as processors sometimes subtilly differ in results. There are also things the computation doesnt have access too, like the exact time. Block numbers will have to do.
You can do time-expensive calculations in ethereum, but they'd be expensive in ether too. The cost of computation and storage are voted on by block winners, so if too much is used, they'll increase the price until fixed. It is a concern that full-nodes may be a bit heavy to run. Luckily it looks like ethereum will have a decent lightweight client.
I personally find it discomforting that we are left in the dark and have to guess from random people on reddit and the forums on such important matters. No offense, but I'd like to know what devs think about this. Why doesn't the white paper mention these problems?
Your complaint about getting answers from "random people on reddit and the forums" isn't fair. This project is in very early stages, and you want the devs working on code, not answering questions all the time about the specifics. There are lots of people on these forums who speak C++ and are perfectly capable of reading and understanding the specific; many of them are happy to accurately answer these questions when they can.
@sjenkins? I'm interested in your comment "you can still detonate whatever sized logic bomb you can afford to set off." A naive solution to this is to think that nothing stops a miner from throwing out a contract execution after some arbitrary time and simply solving a block that doesn't include that tx. I'm not sure this naive solution helps, as it's essentially giving up any chance of the fees for what you're already executed, so it's at best a trade-off. The subtleties of timing attacks like you suggest are very interesting as well. Suppose you pre-compute a series of extremely long running contracts and give them plenty of ether to pay the fees. Then you publish them all, and while the rest of the full nodes are crunching them trying to win the huge fee, you can solve a block that includes them without bothering with executing them. If the contracts are long and numerous enough, it seems like it would greatly increase your chances of solving the block. I guess this depends on the cpu time ratio between contract execution and nonce testing. I need to do more code reading about how contract state is handled as this knowledge is also relevant to another thread where we are discussing the blacklisting of contracts. I'll be back!
Blocks that win are executed by all full nodes at least.
Frankly, i think ethereum does a very good job in explaining things. There is a lot of explanation of choices in the whitepaper, source codes and blog. I dont think this is very much for a general audience, a more specific audience has to assess this and the greater audience must get confidence in that. Same goes for *many* things, unfortunately, the general audience does not always find the technical one. This is a difficult problem, often overcome by 'authority'. The problem is that many authorities have become contested, or have made too big mistakes.
Not saying they couldnt or will not do it yet better, of course. In part it is still in development, so just not set in stone yet. Maybe they could recap near the release time.
Btw: slight 'complication' the contracts are actually not stored on the blockchain, not whole, at least. They use some kind of trie-tree to store many contracts efficiently, using their simularities.
It is apparent for instance from this post: https://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/ it also shines through a bit in the fees section of the whitepaper https://github.com/ethereum/wiki/wiki/[English]-White-Paper#wiki-fees
So running a full node without mining will be expensive, because I'll run lots of computations but get no reward, right?
Ditching a script because it takes too long is problematic, because then you dont have anything to put on the blockchain to punish, i think that makes it vulnerable to DDOS. But it could be preferable for individual miners to ditch it. It is better to run it and use all the ether.
Not entirely sure on how it works exactly. But for the above reason I expect miners only need to check if there is enough ether to initially start the transaction. In the latter, the particular block miners are trying to create cannot bother them. The block before that, can though.
So a strategy is to try get an advantage winning the next block by putting a logic bomb in the current block, which takes the others time to process... But it is like ~10 minutes between blocks, i dont know how much ether it costs per second of computation time, but it is *a lot*.
Still, what if an attacker does decide to try it, what can he do with it? Maybe he has a shot at two blocks, attacking after he wins a block, not very useful. More likely to try an (potentially) even more expensive attack. Where you put the logic bomb in, and while people are trying to calculate it, you try to fork from before the logic bomb. If you succeed, it is like the logic bomb never existed, and you can repeat it with the same ether. However, not sure if the 'uncle' system or something interferes with it.
I think the above attack using really expensive-for-the-attacker long-to-compute scripts should be considered, a wealthy party may decide to try it.
I also noticed that currently in the whitepaper, fees regarding storage is paid back, and those fees are attached to the other CPU-related fees. The issue is someone might try choke up the data-storage side, making people increase the fees to prevent needing to much storage. Either he makes a profit(the refunded ammount is the current fee, not the fee when it started) or he breaks even. If CPU fees are attached, they would be unduly high, as those are not the problem at that point.
I think the above attack using really expensive-for-the-attacker long-to-compute scripts should be considered, a wealthy party may decide to try it.
I also noticed that currently in the whitepaper, fees regarding storage is paid back, and those fees are attached to the other CPU-related fees. The issue is someone might try choke up the data-storage side, making people increase the fees to prevent needing to much storage. Either he makes a profit(the refunded ammount is the current fee, not the fee when it started) or he breaks even. If CPU fees are attached, they would be unduly high, as those are not the problem at that point.
Miners could write programs that 'run scripts faster' but by letting scripts that dont fit that through is a socialized cost, everyone has to run it, it isnt a disadvantage to the particular miner. Also, he gets fees forit..
Also i think you're exaggerating the computation cost compared to that of mining. I expect only when volumes get really big, or in an attack CPU could become an issue.