Solana Proof of History Review (Op-Ed)

Image result for Solana proof of history

Disclaimer: The views espoused in this article are that of the editor and the editor alone. Please conduct your own research and form your own conclusions.

I’ve been reading through Solana’s Proof of History articles (not the documentation yet per se), and I’m just not convinced here that this is an efficient solution to the timestamping issue in blockchain.

View story at

I’m also curious as to how this implementation of ‘Proof of History’ would actually solve anything.

At the end of the day, more so than the timing of transactions, the version of the transaction history is the most important factor on blokchains.

Nodes keep an active record of the mempool and if you attempt to send a double-spend (i.e., a spent TX that is waiting to be verified that is already in the mempool), then the receiving nodes will refuse to add said TX to the mempool. Most clients are oriented to automatically debit your balance regardless, but we’re going to assume this is in an instance where an attacker is interfacing directly w the protocol.

In most cases, time is already accounted for because the TX that is transmitted to the network first will propagate among nodes first.

It takes a bit of time for a TX to propagate, but not that long.

Check this stackexchange answer out for more information on how TX’s propagate around the network node mempools after being broadcasted:

When a transaction is broadcast to the network, what is actually being sent?

Client creates a new transaction, adds it to its memory pool Client broadcasts an inv frame, which indicates that it has something in its memory pool, by giving the hash of the transaction to one or more connected peers Peer receives inv frame, checks its own memory pool, it’s not

This e-mail that Satoshi sent through the Metzdowd mailing list also addresses this issue as well:

Satoshi stated,

“The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.

A transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort.

If the transactions did come at exactly the same time and there was an even split, it’s a toss up based on which gets into a proof-of-work first, and that decides which is valid.

When a node finds a nonce value, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it’s now invalid according to the accepted chain.

This is one reason why it is safe to, at the very least, wait until a TX has been included within a block.

Let’s Double Back to Solana Now

I believe I get what they’re trying to do here.

By devising the protocol in such a way that incorporates information within the TX that verifies it must have come after a certain point in time, the theory is that, by verifying the prior TX, one can automatically filter out any attempts to attack the chain (i.e., someone double spending by spending a spent output).

But that logic doesn’t follow with me all the way because there is still the fact that transactions must propagate to the chain the same way as one would expect it to do so in any other protocol. Thus, Solana isn’t really getting to the heart of what would make blockchain scale.

I’m not entirely sure, in my opinion, if Proof of History would have a palpable impact on the actual speed of transactions.

Perhaps I am off and wrong about what I’m saying, but that’s what it appears to be from where I’m sitting.

This statement,

Because of this, we have pretty good certainty that a custom ASIC will not be 100x faster, let alone 1000x, and most likely will be within 30% of what is available to the network. We can construct protocols that exploit this bound and only allow an attacker a very limited, easily detected and short-lived opportunity for a denial of service attack. More on that in the next article!”

Presents a few more issues for me as well — mainly the idea that parity on these networks will remain minimal at best.

The additional load on the networks from verifying this information is not clear to me either. I’m assuming that there will be another input in TX headers on the protocol to verify the TX itself, which = more memory load on the protocol.

Not sure how that’s congruent with a faster protocol.

All in all, I’m just not sold on Solana’s methodology and I’m not fully understanding what it is about their process that will make their blockchain inherently quicker.

Again, I could’ve just missed the boat on understanding what they’re trying to implement, but its simply not clicking for me at this point and I’m questioning the purposefulness of what they’re proposing. However,



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Yes No