0

I'm trying to understand the current implementation of smart contracts and transactions and am wondering about real-time behavior. I read that it can take up to 10 minutes for a transaction to become part of a block, and read here that "you have to create a so-called transaction which has to be accepted by all others". So I don't see how you could have real-time transactions and built say a Todo list application where each time you created a todo it would instantly save to the database and upon refresh would be there, and it would charge the user per todo (let's say) immediately. Wondering if this is possible, or if it's been considered, or why it's not possible, or how you would handle a situation like this.

1

I'm unsure where you have found out that it would take 10 minutes for a transaction to be in a block. It does not take 10 minutes. Currently the average time is a bit less than 20 seconds (https://ethstats.net/).

According to the network everything is ready once a transaction is mined in a block but the consensus system dictates that a block is actually never final. In theory even the first block of the network might get reverted due to consensus chain reorganization. In practice though a block is final after a few other blocks are mined on top of it.

It's basically up to you to decide when do you accept for a block to be final enough with a big enough certainty. Some exchanges for example require 10 blocks (10 confirmations) on top of the block to consider it final enough to be accepted as a non-revertible transaction.

So, in theory the blockchain is some "20 seconds away from real-time". 20 seconds might not be too long an interval for a todo application. But you always have to remember that there is the consensus tradeoff to be made: how many blocks do you want to wait before you trust the block to be final enough.

REMEDIES

There are ways to circumvent this "slow" transaction time. For example:

1) Do some of the processing outside blockchain. Obviously all such processing is much faster. Then just update data in the blockchain at certain intervals or so.

2) Side chains / state channels. These are rather new approaches but they partially utilize the first method; some of the processing is done in for example a side chain which performs much faster. These solutions are mostly valid only for transactions between known participants (so a lot of transactions back and forth between known participants) and not for "random" transactions to random participants.

  • So wondering if there are example apps that demonstrate how to handle this latency. Like, I've seen games (a and b), I don't see how they could function if they have a 20 second delay. – Lance Pollard Feb 17 at 15:37
  • Your link is about Bitcoin. This is Ethereum, a completely different blockchain. I edited my answer to add some remedies. You can find more information about the suggested remedies around the web. – Lauri Peltonen Feb 17 at 15:43
  • Interesting thoughts on the remedies. Wondering if you are aware of any blockchain or research in which there is no delay (real-time), I'd be interested to see how they did it. – Lance Pollard Feb 17 at 15:45
  • 1
    Typically it's a tradeoff between decentralization + trustless nature vs (partially) centralized + trusted. So the more centralized something is the faster it is typically. Centralized databases are very fast. Decentralized blockchains are "very" slow. So it just depends on what you are looking for. For speed, just use centralized databases. For trustless properties, use Ethereum. And then there are lots of options in-between (for example Ripple, Neo or BigChainDB) – Lauri Peltonen Feb 17 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.