Time-Sensitive Processing

Hey, I just read the whitepaper for the first time today. Cool stuff. I'm wondering what the current thought is on time-sensitive processing constraints. For instance, you might have an organization voting on its next investment decision, but it needs to be made in the next hour, or you might be simulating a text-based adventure game using cryptocurrencies (hell, you might even be making an Ethereum clone of Crysis if you have a death wish). Obviously you aren't going to get blazing processing speeds (it would be one hell of a slow game of Crysis), but is there any way to guarantee returns are made within a certain time limit? My understanding is a contract is called and it waits for a miner to process it - but is there a requirement for some miner to get it within a time limit? Could you offer an increased price to increase its value to miners and get it processed sooner (is that even how it works?). Is there a way to guarantee/replicate a certain speed, replicating a dedicated server running the equivalent (centralized) code? What's the constraining factor here?

In summary - how fast could I run Crysis? Thank you.


  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    All full nodes do all computations. Non-miners may also run full nodes.

    Miners put transactions that are valid into blocks. In principle they can tell whether or not they are valid without the computation. Only one miner gets to put a block in every block number. But once the block is on the blockchain, all full nodes will have to do all the storage and all the computation implied by the block. This is the no 1. problem of cryptoeconomics.

    So it cannot at all run Crysis. It is not intended to provide raw computing power, it is intended that everyone has consensus over it, with everything following the rules. However, it may still be able to do stuff with games. For instance, keep track of who owns which items, or the game may find maps via magnet links, or parts of maps. These magnet links might be controllable by contracts. For instance a advertising board in-game might use such a link to display advertisements right from the contract that handles people paying for said advertisements. The 'domain name' in-ethereum can be controlled by such a contract too.
  • dogcomplexdogcomplex Member Posts: 3
    Ahhh, I understand now - for some reason I thought only one node did the computation of a contract (or a piece of its computation) and the others just verified it. Thanks for the response, this makes much more sense.

    But if we *did* want to have one contract that rendered a game or something stupid with every step, would that basically mean it would be computed and delivered once every new block (60 seconds, if I recall?) as the network waits for the previous block before the next one comes? And every full node operator would have to make that same computation at some point to catch up? I guess I was confused about the cloud computing potential application mentioned in the white paper, where it talked about [email protected] and such potential computations - but I guess that's sorta a special case, since the computations would be done off of the ethereum code and only verified in ethereum by the blockchain... correct?

    So the speed of computation (of the consensus output) is limited by block creation time right? And we don't want to push it to be less than 60 seconds or whatever since it would precipitously increase overhead and defeat the purpose of a consensus algorithm. If that's all right, that makes sense...

  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Yes, full-node operators need to catch up if they're behind, and the current plan is a one-minute block time.

    The use of Ethereum to get raw computation in essence needs tricks that make it incentive-aligned, and only that is on the blockchain.

    For instance Merkle trees can be used to show that a file contains some piece of data, only using a single hash that is the root of the tree. By requiring people to show to the Ethereum contract that they have random bits of the file, they can be forced to actually have the entire file.
  • dogcomplexdogcomplex Member Posts: 3
    Without every full node having to do the computation themselves, right? Interesting...

    So, what exactly would be the effect of shortening block time? Is it that all transactions wouldn't reach all miners in time, so there would be a lot of different new blocks being proposed by miners - even honest ones - simply because some messages didn't make it in time? So, we need a reasonable delay to let most transactions make the transfer before the block is created?

    Or is it just that we don't want to make so many blocks? Or rather - we can't make short block times because we'd be paying for it with a longer blockchain filled with blocks of a small amount of transactions - and we'd rather have a fewer, bigger blocks instead. Else, a full node trying to catch up would be doing much more work decrypting each block for the same amount of substance (transactions).

    Just testing my intuitions on this all, please correct me if I'm wrong!

    I wonder if there could be a coin consensus protocol that adds a new block to the chain without a timer - instead creating a new one every time a majority of miners agrees on a block. Does that sound possible or even desirable - or would it be fundamentally opposed to what bitcoin/ethereum are?
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Every full node has to do all ethereum-contract computation. But if you can figure out a way to pay people to do computation without needing to repeat it to check.(There sort-of are)

    Afaik the main issue with shorter block times is multiple being blocks created at the same time. Particular blocks dont have that much overhead in size as far as i know, at least when there is enough traffic. Actually, it might be possible to vary the block time too.
Sign In or Register to comment.