I thought that maybe a distributed real-time server could solve that.
It certainly could. The block-chain *is* that distributed time server, this is the very function it serves. (We have no other proven design for such a beast.
)Quote
For example, the calendar time is taken to be a median value among the nodes in the network.
It is not so simple. Sybil could just overwhelm and warp the median, for example.
Quote
And then every let's say 5 seconds a chuck of transactions is committed to the distributed hash table.
The definition of "committed" becomes very problematic, here. This is concerning because this committal is strictly necessary as part of avoiding double spends. Without the proof chain securing consensus over a full history you end up in some messy situations. In any case you need "someone" to select and order transaction sequences *before* consensus is reached, and consensus has to be reached in a way that precludes re-selecting or re-ordering those transactions in the process, or after the fact, by any party. Further, you need to do so in a way that reaches at least a "50% + 1" security threshold in order to be able to assert majority consensus, which is much more difficult than it might initially seem. Most (arguably "all") DHT structures fall to only 1/3 collusion, in the best of cases. Bitcoin was the first p2p network to demonstrate any security threshold above this norm.