Let me preface this by saying, I'm not a coder, don't know cryptography, and this could all be gobbledygook.
A month or two ago I discovered Solana used a blockchain clock to help resolve their network efficiency/security.
I started thinking that perhaps this could also be used in the context of a proof-of-work model. Like if say, events had a proofed time, then orphan block fairness, maybe even the need for confirmations could be resolved.
A lot of proof of work mechanisms are actually striving to resolve time using propagation as a proxy (which is slower), or network timings as a padding. You don't know when transactions occur, so you use confirmations via propagation. You don't know when blocks are mined, so that constraints block-time. Time is worked around, because there is no absolute sense of time.
Solana uses a specific variation of a Verifiable Delay Function (https://eprint.iacr.org/2018/601.pdf), in their words:
"Our specific implementation uses a sequential pre-image resistant hash that runs over itself continuously with the previous output used as the next input. Periodically the count and the current output are recorded."
They use SHA-256, and apparently this implementation is pretty much impossible to parallelize (ie must run single core). I'm not honestly sure of Scrypt could be used in the same way.
It's explained here:
https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274
Because it's single core, and the speeds at which ASICs running SHA-256 are predictable, they can also approximate the bounds in which this can be speed up (30% or so). Making it, so within these boundaries, they can have certainty of it's honesty. As far as I understand it, because it's published, and sequential, it cannot be modified retrospectively. Changing a part of the sequence in the past, alters the whole sequence.
I heard that originally Satoshi actually wanted to implement a blockchain clock prior to settling on his solution for bitcoin. In a sense, proof of work acts as a clock. I wonder is this still possible to integrate a clock with tighter timing into a Proof-of-Work system?
I have no idea if this is doable, but it does seem to me one of the central design flaws of proof of work is not knowing time. If it was possible to create a reliably proofed time, some slower mechanisms could be replaced or eliminated. Orphan blocks, in theory at least would then come down not to centralization but how much lost work is tolerable to miners and the network - which in itself would come down to efficiency and network speed.
If confirmations aren't able to be eliminated, they could at least be reduced. Of course efficiency in blockchain propagation itself would be key - if there's too much variability, it would limit the use of this.
Please accept again, that I am not a coder, and I could have all this wildly wrong. I do grasp though that this would essentially be completely altering how the chain propagates and how immutable history functions, and is by no means a simple thing.
No comments:
Post a Comment