So, I recently came across an ICO that had one of the most audacious intros that I’ve ever seen in my entire life.
The front page for this project ( https://solana.io ) states:
710,000 transactions per second is volumes faster than what even Visa or Mastercard are capable of producing.
However, one cannot rule this out without taking a more in-depth look at the project and its specs.
So, let’s dig in, shall we?
I like to comb through a project’s website first before going into the whitepaper, because there’s often a load of pertinent information laden within that can help us to get a better gist of what’s being offered.
If you’ve visited the website via the link that I posted above at the beginning of the article and scroll down a bit past the initial invitation message for ‘The World’s Fastest Blockchain’, you’ll come across this screen:
Time as Data
It looks like Solana is fully aware of the audacity of their claims as evidenced by their comparative chart which asserts that their blockchain is capable of a processing power that not even Google or NASDAQ can provide.
In fact, according to the mini-infographic on their website, it appears that Solana’s blockchain allegedly possesses 42% more capacity than NASDAQ’s blockchain does.
Perhaps you can also see on the picture above that I provided, but it appears that Solana also divulges their core ‘secret’ to curating a blockchain capable of handling such a massive volume of transactions per second.
Solana’s apparent secret appears to be a consensus algorithm called, ‘Proof of History’.
Personally, I’ve never heard of such an algorithm, so I’m already intrigued at this point in my discovery.
According to the website, this consensus algorithm, “Relies on synchronized atomic clocks for a trusted source of time and ordering” which has allowed “Solana [to create] a cryptographically secure, trustless, time source and [build] a blockchain around it.” And it is this process that they title, ‘Proof of History’.
Obviously, there are a number of complexities outside of this concept that must be shelled out in greater depth before we can claim any thorough understanding of this consensus algorithm or truly audit the claims that this would allow Solana to potentially process upward of 700k transactions per second.
If said consensus mechanism does ‘check out’, then I’d say that Solana is worth its weight in gold as such a revolution in blockchain technology is unprecedented (no, Proof of Stake is not a revolution — it’s an over glorified buddy system).
If you’re a keen observer like myself, you’ll have noticed that there were three other categories on that subheading that ‘Time as Data’ was placed on:
So, we’re going to now go to the subheading title, ‘Scalable Finality’.
From here, we see a new block of text pop up (which I think is a pretty cool aesthetic effect):
In this section, the Solana team does make a pertinent point. Finality is a bit of an issue in crypto at this present moment in time.
By the term, ‘finality’, what they are referring to is the cautious ‘wait’ that we must all do after we accept a transaction in order to ensure that it cannot be ‘reversed’ on the blockchain due to someone attempting to scam us via a double-send.
According to Solana in this section, “Through Solana’s ‘Avalanche’ network communication innovation, finality times reduce exponentially as the network grows. This means we can expect — 500ms finality up through 10s of thousands of nodes and beyond.”
If this is true, then we’re already looking at one hell of a chain. Not only does Solana claim at this point that it can handle up to 700k transactions at this point (which is probably way more than it would ever need for the sole purposes of monetary/financial transactions), they also claim that they would be able to settle the majority of those payments within milliseconds, which is virtually instantaneous.
This actually makes sense if they have a way to verifiably ensure that timestamping mechanism that they discussed earlier can be curated with this level of pinpoint accuracy.
The reason that this cannot be done for blockchains is because a transaction can be sent to one party and an ‘inside party’ simultaneously. The ‘inside party’ could then broadcast this TX to the network at the same time as the scammed party and, if the inside party’s TX is mined into a block for the network first, then the UTXO (unconfirmed transaction output) that was sent to the network by the bad actor to the innocent party will eventually be reversed once it is discovered that this is a ‘double spend’ attempt.
Thus, the only way to retain the ultimate ‘safety’ on the Bitcoin blockchain is to wait for the next block to be curated and produced. On the Bitcoin protocol, each block takes 10 minutes to be produced. So, this is not necessarily ‘convenient’ by any means — especially if one is a vendor or merchant that needs to accept ‘fast payments’ for things such as movie tickets or train rides.
So, if what Solana alleges here proves to be the case, then this gives the blockchain an unspeakable advantage over Bitcoin and most other cryptocurrencies in the space.
This is the next subheading on that list that I was telling you about:
I actually found this proclamation to be an interesting one because it emphasizes the fact that Solana is not taking what many would consider to be the only conventional/plausible path to producing a blockchain capable of the output that Solana claims that its blockchain will provide.
In the excerpted subheading for ‘No Sharding’, it states:
So, I actually like this principle too. Essentially, what the team is saying is that it has found a way to organically produce a blockchain that is capable of scaling to the great heights that it purports that its blockchain will eventually reach without compromising their project with the excessive technical debt that sharding would require.
Need a refresher on exactly what the hell ‘sharding’ is?
And now, for the fourth and final section of this subheading — which is ‘smart contracts’
The excerpted portion of this subheading that pops up states this:
This is yet another facet of the project that I think is pretty awesome and necessary.
#1 — We know just from the subheading alone that apparently there is smart contract capability on this chain (and why wouldn’t there be with its massive capacity?)
Perhaps most important in this subsection though is the assertion that, “With Solana, you can write smart contracts in almost any language. We leverage Berkeley Packet Filter, allowing any language that LLVM supports to be utilized.”
So, in other words — just about any and every language that a normal dev/coder would more than likely understand.
Traveling Further Down
There are multiple different use cases on the website such as:
1. Decentralized Exchanges
3. Distributed Web Services and Storage
4. Distributed Ad Exchanges
These services all seem reasonable given what we know so far on the website. It’s also worth noting that the site asserts that these are just ‘some’ of the purported use-cases for the blockchain. So, I’m assuming that there are many more that were not listed there.
Just something to keep in mind!
This, in my opinion, is one of the more important features of any blockchain project — The Roadmap. Below is a picture of the one provided on their site.
While the roadmap is fairly simple in its structure and listings, the goals on there for the year are fairly sizeable.
By the end of this year, the mainnet itself is scheduled to go live. So, we’ll be able to test out by the end of 2018 whether or not this blockchain technology is capable of hitting the pinnacles that it plans to reach.
Based on the whitepaper, it looks like this idea has been in motion since 2017.
So, this was not thoughtlessly curated in the last two weeks.
I’m also seeing links for the whitepaper too. So, it appears that at least 50% of this next major milestone on the roadmap (February 2018) has already been hit as well.
Thankfully, we can put some faces to names here because there is a full listing of the team for Solana on their website as well.
From what I see on the website — these individuals appear to all be more than qualified to curate a project such as this. Although, I have no idea who any of them are — so that remains to be seen.
So, let’s check out the whitepaper, shall we?
Lo and behold, the whitepaper for this project is a bit of a monster. It shows up to as approximately 32 pages in a pdf document.
Regardless of the length though, we’re definitely going to dig into this project and get a better look at what’s going on here!
Right off the bat, I can say that the Legal Disclaimer is actually a smart idea. Although, in my personal opinion, it seems as though the SEC is leaning toward calling any and every ICO a security offering. So, I’m not sure how effective that this would be in deflecting any legal pressure that may result from the ICO itself. But, I’m sure the team has that covered! (However, you should be aware because any punitive actions there will definitely impact your tokens, their worth, and the team’s ability to continue forward with the project at all).
So, let’s dig into it, shall we?
So, it appears that the initial impression that I had of the ‘Proof of History’ being created with the sole purpose of usurping all other consensus mechanisms was a misinformed assumption.
I say that because of the statement made in the abstract that, “When used alongside a consensus algorithm such as Proof of Work (PoW) or Proof of Stake (PoS), PoH can reduce messaging overhead in a Byzantine Fault Tolerant replicated state machine, resulting inn (sp?) sub-second finality times.”
So, based on what I’m seeing, it appears that PoH can be an addition to PoW or PoS. I’m still not yet aware of which one it will be working alongside in this specific case yet.
But, thanks to patience, I was able to find out in the next line where it literally states, “This paper also proposes two algorithms that leverage the time keeping properties of the PoH ledger — a PoS algorithm that can recover from partitions of any size and an efficient streaming Proof of Replication (PoRep). The combination of PoRep and PoH provides a defense against forgery of the ledger with respect to time (ordering) and storage.”
So, I’m assuming you’re confused as hell at this point. Don’t worry, I am a bit too — but I strongly believe that we’ll find out more of what we need to know very soon. From first glance, it appears that the purpose of “Proof of Replication” is to prevent potential double-spending on the platform. However, we’ll find out a bit more about that later on in the paper, I’m sure.
Beyond the aforementioned quoted parts, the Abstract states that, “The protocol is analyzed on a 1 gbps network, and this paper shows that throughput up to 710k transactions per second is possible with todays hardware.”
I agree with this premise, personally and believe that’s why we have an issue with unintentionally forked chains so consistently on Bitcoin and other protocols that rely on Proof of Work.
There are a few questions I have about this part though.
So, there is a leader that is chosen through a Byzantine Fault sequence (I’m assuming based on prior statements on the website itself).
So, as a recap for those that don’t know/forgot:
Now, this portion of the whitepaper states that, for Proof of History, “The Leader [assuming they are chosen through BPoS] sequences user messages and orders them such that they can be efficiently processed by other nodes in the system, maximizing throughput. It executes the transactions on the current state that is stored in RAM and publishes the transactions and a signature of the final state to the replications nodes called Verifiers.”
Before we move forward from that portion, I have just a few questions:
1. How is the leader selected exactly? I assumed via the same process as Delegated Byzantine Fualt Tolerance in order to mitigate the risk of cheaters as explained here and used in the $NEO protocol: https://steemit.com/neo/@basiccrypto/neo-s-consensus-protocol-how-delegated-byzantine-fault-tolerance-works
If not, clarity on this would be great.
2. Also, what is to prevent the ‘Leader’ from cheating? Are there any scenarios in which the Leader can cheat? What is the percentage of nodes that must agree in this vote in order for the published version of the chain’s history to be “accepted” by the protocol? What are the requirements to join this network and become a node and vote?
3. The word ‘RAM’ was mentioned. What does that allude to? Is there some sort of centralized off-storage location for the data being transmitted on this blockchain? I’m hoping to find out more about this specific facet of the project later on in the whitepaper.
4. What incentive(s) do the nodes or does the ‘Leader’ have to be accurate or even desire to participate in this activity?
After reading on though, I did notice that there was an infographic posted immediately below the section that I was on that is supposed to explain this phenomenon in greater depth:
The questions that I have above still remain. And also, if this chain is devoid of blocks (haven’t seen any or seen a reference or allusion to block time as of yet), how do the verifiers simultaneously verify the transactions that are coming into the network while auditing the ‘Leader’s work in order to ensure that they are correct/not a bad actor and do so accurately within the purported ‘millisecond’ time frame that was presented on the front page of the website?
Below is the following excerpt — so the question of whether the leader was selected through a PoS method (albeit not the dbPoS theory, which was grossly inaccurate).
Alright, so to unpack everything — I think that the whitepaper was pretty explicit in its explanation of this portion of Proof of History.
However, I think the crucial element that’s missing here is the necessity of timestamping all transactions or interactions on the network when the most important priority is ensuring that there are no double-spends on the network.
This works in a major way for Bitcoin because it’s not a fungible asset — So, we know that a transaction for a certain amount could not have occurred, not because of the amount in the user’s wallet, but because of where those coins are supposed to be in the blockchain.
However, I have not seen any information as of yet on whether this coin is a fungible asset or not. So, the importance of sequencing would be rendered useless if there were a bad actor that compromised the network in some way because there would, while we would know the time of the transactions, we would have no evidence as to whether said transaction was legitimate.
So, if there were a record in the chain that, for example, hashed that the NYT ran a headline yesterday that there was a terrorist plot and today it says that ‘Mowing Your Lawn Makes You Live Longer’ from a pre-selected list of headlines that they are allowed to run (let’s say they have 200 options and only one option can be used on day at a specific time), then the timestamping function becomes essentially useless if we have no way of determining the veracity of the claim that the NYT ran a headline today stating that ‘Mowing Your Lawn Makes You Live Longer’.
Perhaps I am mistaken in my assertions. However, from what I’m seeing, that’s my major concern at this point — and this is something that’s absolutely critical if there is to be an immutable ledger created.
This, in many ways is where the beauty from ‘mining’ via the Proof of Work consensus algorithm comes from. Miners must validate the transactions and if they are not valid, then they do not receive the reward. So, in a way, this sort of speaks to a ‘hierarchy of needs’ on the blockchain.
If the network can agree on which transactions are legitimate, then the timing of said transactions are of little consequence.
For example, if the network can validate that John sent Susie $200, then the timing of John sending Susie $200 becomes irrelevant. What matters is the time at which Susie has received $200 (the confirmation) and whether John has said amount.
In terms of time, the only thing that will be considered is what spend attempt will be counted into the blockchain for Bitcoin. It is inherently designed in a way to entirely prevent the incidence of counterfeiting.
So, my main concern with this chain and what I am reading in the whitepaper thus far is that there does not appear to be a concrete method within Proof of History to ensure, in an efficient and quick enough manner, that money has not been double-spent and merely time stamping transactions will not suffice in this endeavor — especially if one Leader is responsible for making a report on which one came first on the chain.
This perhaps would work if each individual transaction were to be hashed, but if they are grouped, then hashed into a block (not sure what the block times are at this point in the paper), then I’m not seeing what the inherent advantage of time stamping the blocks would be.
Once again, I’m no authority on this issue and should not be considered to be one. So, if there is any enlightenment, response, or greater light that the team could potentially shed on the issue, I would definitely be eternally grateful for such clarification.
Timestamp for Events
Alright, so once again my issue, which you can see in the caption for Figure 3, which states “Inserting data into Proof of History”, how do we verify the data in Proof of History timestamps? Namely, how do we ensure that there has been no incidence of double-spending? This is a question that I must posit in light of the fact that I have no clue whether this cryptoasset is fungible or not.
If it is fungible, then this entire concept cannot work in absence of Proof of Work.
I believe that it would be a beautiful enhancement to Proof of Work that could possible reduce/eliminate the need for there to be any human nodes validating the transactions produced by miners.
However, in the absence of Proof of Work, it is hard to conceive whether the reliability/integrity of this consensus method could be maintained — especially if there are over 700k TX running on the network per second (remember, all requests and moves to offchain resources, smart contract executions count as TX, so this isn’t an infinitely impossible # to reach). Once again, without ensuring the immutability of the currency itself, any and all consensus methods that are designed are rendered useless or, at best, substantially less effective than they would otherwise be in more optimal conditions such as what I have described above.
I want to stop my analysis of the whitepaper here, because I need to gain a greater conception of the project and have some of these questions answered before I can provide a fruitful analysis on the rest of the whitepaper itself.
However, as a concept — it seems brilliant, assuming that there is a provided proof that ensures that this consensus algorithm is truly resistant to the vast majority of attack vectors that are not predicated on controlling more than half the network and that the immutability of transactions can be unequivocally preserved without question.
To recap the site, the design there is pristine, to say the least.
The information is concise and to the point and there are not too many bells and whistles on there to where you feel yourself getting lost or bogged down with the responsibility of accounting for all of the various facets that the coin is trying to ‘dabble’ into.
However, I feel forced to give this ICO a 3.5/5.
Disclaimer: I was commissioned to write this article review, but I was not directed on what type of review to write at all and I was told that I could be as ‘brutally honest’ as needed. So, I did so. I was not paid in Solana tokens, it was ETH — which I liquidated immediately into fiat. So, I have no objective motivation at this point to write an excessively flowery review or hype the project up beyond whatever hyping it needs/warrants. The purpose of this disclaimer is to ensure that the SEC doesn’t kick down my door tomorrow. Once again, I have 0 Solana tokens and explicitly refused to accept any for the curation of this article in order to remove any and all potential conflict of interest (i.e., me hyping this project so that my ‘bags’ can soar).