I believe the block.timestamp is the wall-clock date/time at which the block was mined. A block number set in the future based on some other block is based on an estimate of the rate of block mining. For example, the average/target block time is, at the time of writing, about ~17s. So if you want to set a time 24 hours in the future via block number, you can use 24 * 60 * 60 / 17 (number of seconds in a day divided by number of seconds per block) to determine roughly what block number will be mined at that time. Note that for times in the mid- and far- future, you will need to take into account the ice age: the rate of block generation will slow down, by design, to encourage a hard fork for proof-of-stake and, in the meantime, makes the profitability of mining decrease materially (when denominated in eth) as the ice age progresses.
Here is a simulator to get an idea of what is happening:
https://gist.github.com/CJentzsch/c78768f9837afb8eef74
Note that the rate of slowing has been slowed by a more recent change to the Ethereum protocol, so the simulator is out of date.
Currently the block time is around 17s
The average is currently between 14 and 15 seconds.
but the confirmation time is even longer around 2-3 minutes.
That depends on the gas price you're willing to pay, and the current state of the gas price market. Have a play with the "Gas-Time-Price Estimator" on ETH Gas Station to see how the average transaction time changes.
Moreover, as I understand even if the transactions-per-second are 7 we still need to wait the confirmation time before considering those transactions valid.
Transactions-per-second, at the time of writing, is about double this. (I can't find a source, but the network tops out at around 15, and we're pushing the block gas limit at present.)
The number of confirmations considered safe is subjective. It will depend on your risk profile. Ethereum (currently) doesn't have any concrete finality, in that given the right amount of power, any transaction could be reversed. There is risk associated with this.
Does this imply that the blockchain is not yet a viable solution for real time application?
From your example of a real-time application, no, it currently wouldn't support something like this. But then it could be argued that a blockchain wouldn't be a good fit for such a thing. Distributed and decentralised computing is a huge discipline - blockchain is just part of it.
Will someone ever build a very fast blockchain with confirmation times around the tens of milliseconds?
Any answers to this would be speculative :-) It depends on how you're defining "blockchain", and how it overlaps with the rest of the distributed computing world.
Best Answer
From what I understand, you are trying to estimate the time spent by calling a smart-contract (specifically a read call). In other words, how long does it take for a transaction to be processed by the blockchain?
Both read and write calls are sent as transactions, however, the latter requires mining and costs gas since it changes the state of the blockchain and requires consensus, while the former does not. The read call is just a database lookup that fetches the requested values from the blockchain, which is performed locally by the blockchain node that you are connected to.
(I am assuming that you already have established a connection to a blockchain node and that you are able to issue the calls)
For a read call, which does not require mining: You will have to record the time prior to calling the smart-contract (i.e. issuing the RPC call), let us call it t0, and record the time after the node responds to that call (i.e. when the requested value is returned), let us call it t1.
The time spent is simply, t1 - t0.
For a write call, which requires mining: t0 should be captured prior to sending the transaction and t1 should be captured when the confirmation message of that transaction is returned.
As above, the time spent is t1 - t0.
How to program it depends on what programming language you are using. For example, in Golang, you may use t0 = time.Now() to record the time at a specific point, and then use time.Now().Sub(t0) to get the duration (t1 - t0).