who computes the contract's code?

madhamstermadhamster Member Posts: 5
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?

Comments

  • madhamstermadhamster Member Posts: 5
    sorry, wanted to put it in the General Discussion forum
  • cybertreibercybertreiber Vienna, AustriaMember Posts: 29 ✭✭
    I'm trying to get from the bigger picture into the nitty gritty details myself and found this discussion on reddit which answers parts of your q (http://en.reddit.com/r/ethereum/comments/1zko09/question_where_is_contract_computation_performed/).
    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?
  • sjenkinssjenkins Member Posts: 28
    Also, is there a potential attack where one miner knows the outcome of a computation in advance (because they created and triggered it) but the other miners all have to compute it from scratch?
  • madhamstermadhamster Member Posts: 5
    edited March 2014
    @Alex_GuangTou unfortunately in that reddit post there's no real answer... the top comment seems gibberish to me, it makes it sound like running a contract is part of the proof of work a miner does, which makes no sense to me...

    @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
    Post edited by madhamster on
  • jTAjTA Member Posts: 50
    Of course, some well articulated REST-like specs would likely ... resolve all, would they not?
  • sjenkinssjenkins Member Posts: 28
    @jTA we're not being offered well articulated REST-like specs though, we're being offered arbitrary code, written in whatever language you can find a compiler for, running on a general purpose VM. The security measure is that you must burn money to execute the code, but the flip-side is that is you can still detonate whatever sized logic bomb you can afford to set off.

    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.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    @madhamster the reddit comment by throw-y-away-y is essentially correct. It *is* run by *all* full nodes. (and it isnt gibberish at all...) It is required to know the state.(balances, etcetera)

    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.
  • madhamstermadhamster Member Posts: 5
    edited March 2014
    @Jasper from my current understanding (which unfortunately is based on voices, given lack of official statements on these details, so could be incomplete) the miner who finds a block will execute the contracts that recieved a transaction... so while everyone has a copy of the contract (it's in the blockchain), only who finds a block will execute its code. What would be the point of having everyone execute it while searching for an ethereum block, i.e. making it part of the proof of work?

    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?
  • sjenkinssjenkins Member Posts: 28
    If the other miners don't execute the code there's no proof that the miner who found the block has done so correctly.
  • chris613chris613 Member Posts: 93 ✭✭
    @madhamster? It is indeed the case that every full node executes every contract for exactly the reason sjenkins mentions, other full nodes need to verify the correct results of the computation.

    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! :)
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    What sjenkins said. Miners can see proposed transactions to include and incorporate them. Reading the whitepage, they get incentive to include because of fees. Heard elsewhere that fees where destroyed, though. *Something* would have to ensure miners actually put in transactions.

    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.
  • jTAjTA Member Posts: 50
    "Who computes the contract's code?" looks a basic enough question to me, even without dragging in more subtle temporal issues? And yet, after much ink and scrolling, still no definitive answer to even that? I rest my case! Far simpler to refer to page 99 , para 99 of ... , I would have thought? Suggesting that code (or worse) is the final arbiter just doesn't cut it for me, sorry. :(
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    I mentioned source code, i also mentioned the blog and whitepaper. You apparently just missed it. Besides, all current blockchains do this. You probably dont understand blockchains, bitcoin has (much less powerful)scripts too, all nodes execute those too..

    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
  • mquandallemquandalle FranceMember Posts: 50 ✭✭
    Here is a related writing about how a miner could rationally dispartch its computing power between mining and contracts execution https://github.com/aeronbuchanan/ethereum/blob/master/EthereumBasic.pdf
  • madhamstermadhamster Member Posts: 5
    edited March 2014
    thanks to everyone that replied, I think now it's clearer (apart from the timing issues brought up by sjenkins). So I guess my next question is, if someone sends a transaction to a node with a fee, who gets that fee? The miner that finds next block?

    So running a full node without mining will be expensive, because I'll run lots of computations but get no reward, right?
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    The logic bomb, well it seems to me that at worst it means the logic fees have to be high, so any attacker runs out of ether.

    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.
  • jTAjTA Member Posts: 50
    @Jasper Thanks. Sorry, being more used to the architectural style of REST and even IETF RPC's, one yearns for something akin to TCP/IP Illustrated, say. I am nothing if not ... optimistic. :)
  • jTAjTA Member Posts: 50
    @mquandalle Thank you! Useful background.
  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    @jTA i'm aware of people working on 'apis', of course we'll provide our own in due course, but these could be a good stop gap solution. I'll post here when I have more info.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Hadnt read mquandalles .pdf link writing the previous post. It looks good to me, but shouldnt say stuff like: "It is rather like a shared cloud computer the size of the internet" As long as every full-node has to compute everything.. It implies you can use it as 'cheap cpu service', whereas it is infact really expensive. (but it trustlessly is dutifully and has a balance, can do transactions) That is a small note on that paper, and if you know if it is being discussed in a place i might not find myself, please link.

    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.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Hadnt read mquandalles .pdf link writing the previous post. It looks good to me, but shouldnt say stuff like: "It is rather like a shared cloud computer the size of the internet" As long as every full-node has to compute everything.. It implies you can use it as 'cheap cpu service', whereas it is infact really expensive. (but it trustlessly is dutifully and has a balance, can do transactions) That is a small note on that paper, and if you know if it is being discussed in a place i might not find myself, please link.

    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.
  • chris613chris613 Member Posts: 93 ✭✭
    I'm also quite concerned about the true cost of every node running every contract. Ultimately I think that most nodes will only execute a subset of contracts based on user defined filters, it seems inevitable. Depending on how the hash power and filters are distributed this could be problematic because unpopular contracts might take a very very long time to confirm.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    That doesnt matter if creators of a block only need to check the transaction fee. They'd have to calculate the scripts of the previous block, not the block they create. Only if they win, then everyone has to calculate the scripts.

    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.
  • hippo66hippo66 Member Posts: 3
    If a contract contains code that adds a random element to the result (e.g. some sort of gambling contract) can all miners still agree on a newly created block?
Sign In or Register to comment.