How to make transactions real-time for Dapps

Question

I am intrigued how exactly an Ethereum transaction's "state changing" works. I have read about the Bitcoin transactions, and so understand how the basics of validation and propagation through the network work.

What I'm wondering is how you accomplish what feels like real-time updates to your app if the transactions take ~20 seconds to resolve. In that post it was recommended this:

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).

However, I'm wondering if there are any techniques in Ethereum or any other blockchains where you can have sort of a "prevalidated transaction" which is part of a "prevalidated block" or something, such that when you create a transaction, it runs the code immediately, and ends up in some final meta state in the blockchain so you can treat it in your app as if everything was a success. Sort of how in an app like GitHub if your credit card expires, you can still use the service for a month or two and get warnings to update it, until finally it's shut off, sort of like a grace period. In essence, it still lets you perform transactions, without having any gas, and you go into debt so to speak.

Wondering if anything anywhere close to this exists in Ethereum or anywhere else. Something that would allow some sort of near-real-time Dapp. Because transactions and blocks must propagate across the network before they are incorporated into a final block, I can see no way of making it take less than a few seconds to 20 seconds like Ethereum's case. The only way I can see it taking less time is if there is a middle state between having a final valid transaction or block, and having an "in process" transaction or block, sort of thing. Wondering if anything does anything like this, haven't seen it.

Answer 1

tl;dr; no, Ethereum does not have such thing (at least directly)

What you're describing basically fights against the trustless part of Ethereum. Most likely some other "let's try this crazy idea" blockchain has something similar but I can't see how that could work with a trustless blockchain.

As I mentioned in the other post you linked it's all about different degrees of confidence. You can issue a transaction with enough gas and be fairly certain that it will be included in a block "soon". If I now issued a transaction with a big gas amount I could probably be 99% confident it will be included in a block within about half a minute. So in that sense I could treat the transaction as "already confirmed".

I my example above, you also have to consider the question "certain based on whose perspective?". If you issue such a transaction from your node and query the result from your own node you can probably give such 99% confidence level. But if you query result from a node from the other side of the world they might not have the same result yet.

Also, keep in mind chain reorganizations (reaching consensus). Basically anything is possible. The longer you wait (the more blocks on top of the current block) the more certain it is. If there's such a transaction with big gas in nodes' mempool (the list of non-mined transactions they are aware of) every node will do its best to include it in the next block (to maximize monetary gain).

Other points of interest:

• This is probably not the best place to ask "is such possible in other blockchains?". For obvious reasons.

• There is no "final block" and transactions don't have to propagate to the whole network in any timely fashion. Some part of the network might not know anything about the transaction and they still mine completely valid blocks. Network consensus mechanism then starts to "kill" off non-prevailing chains. (Meaning those chains are simply not continued anymore as their chance of becoming the canonical/"main" chain are getting close to zero)

• I guess you might call side chain transactions as sort of "prevalidated transactions". They will never appear in the main chain as separate transactions but the effect they have is reflected in the final transaction(s) on the main chain. So whatever happens in the side chain will be reflected in the main chain - but through the same transaction procedure as "regular" transaction (in fact there is no special treatment for main chain transactions which settle sub-transactions in side chains).