The operation of Solana Network is based on a number of innovations specially developed for this network. With that in mind, we’ll begin by describing each of these innovations, their implications, opportunities, and their role within Solana.
Proof of History (PoH), a quick consensus protocol
As mentioned earlier, Solana’s story begins with the publication of the White Paper Proof of History (PoH). This is a very peculiar consensus protocol. First, Proof of History is very different from other consensus protocols known as Proof of Work (PoW) or Proof of Stake (PoS). The reason? Proof of History uses time (and timestamps) to generate a consensus system, as opposed to Proof of Work (which uses a cryptographic puzzle) or Proof of Stake (which uses coins to be “wagered” or held to participate in a voting system ).
But how does it work? Let’s see it this way: physics teachers often say that everything that happens around you happens in space and in linear time. This “linearity” of time is important in understanding simple phenomena like throwing a ball and seeing how the position of that ball changes over time. For example, the moment you let go of the ball to make it go off, you can say that the ball is at the origin (your hand) at its time “0 seconds”. But after 10 seconds the ball has reached its destination and in those 10 seconds you can create an accurate chronology of what happened to the ball. Indeed, with the necessary knowledge, you can know everything about what happened to the ball.
The same goes for the proof of history. This protocol creates a record of precise timestamps for everything that happens on the blockchain. This way the log annotates this event with an accurate timestamp when a coin is moved from one wallet to another. This enables the events to be recreated precisely. In this way, if you want to get information about past events related to a token, address or certain smart contracts, just look at the temporary records of these items in the past and we will know everything from their origin to the current moment .
The good thing about this system is that creating timestamps with cryptographic evidence is not a very computationally complex task. This allows Proof of History (PoH) to be a very fast consensus algorithm. In fact, it’s perhaps one of the fastest, only surpassed by Proof of Elapsed Time (a type of Proof of History that uses hardware acceleration and was created by Intel for HyperLedger). The bad? Proof of History is an algorithm that is not very resistant to certain attacks. To avoid this, it must be used under certain conditions to ensure its safety.
First, PoH requires a strong timestamp verification and verification system. For this purpose, this algorithm uses a verifiable delay function, for which a certain number of successive steps must be evaluated. However, this system offers a unique output that can be publicly and efficiently reviewed. This prevents malicious actors from tampering with the timestamps and messing up the log. To be sure that this system is efficient, The algorithm uses the SHA-256 function (the same one used by Bitcoin) to perform a verification hash to see if this step was actually taken.
This process of generating and checking timestamps is done with each block in Solana. In addition, the generation takes place step by step, so that an exact chronology can be created for each event.
Tower BFT, a powerful Byzantine fault tolerance protocol
Another Solana innovation is Tower BFT, a Byzantine fault tolerance protocol that, when combined with Proof of History, helps keep your consensus protocol and decentralized network working securely. Tower BFT is a further development of Practical Bizantine Fault Tolerance (PBFT), a Byzantine fault tolerance protocol known in the world of distributed computing.
Tower BFT’s role is to act as the “judge” within the timestamping system that runs across the Solana network. In this way, Tower BTF uses the synchronized clock between all nodes to serve as a point of control, verification and acceptance for the work carried out by the nodes. In this way, a decentralized consensus on this work can be established and accepted in the network, if this work is carried out respecting all the rules proposed by the Solana protocol.
Since Tower BTF is a derivative of PBFT, this system is very fast and the Solana development team has optimized it even further to avoid unnecessary latency times within the system. As a result, Tower BFT and PoH are able to provide Solana with a high speed of block and consensus generation within the network, an average of 0.5 seconds per block generated in the network.
Turbine and Gulf Stream, transactions that move quickly on the network
One of the biggest problems in distributed systems is bandwidth and the need to transmit all information generated on the network to all nodes that are part of the network. The problem is easy to see, when you have a network with thousands or tens of thousands of nodes, every transaction and event within the network needs to be sent to each of those nodes in order for the event to be registered and the desired consensus to be generated. So if you have a lot of transactions (or they are too heavy) it creates a serious bandwidth problem and slowdown within the network. Bitcoin and many cryptocurrencies solve this from two points:
- They use information dissemination algorithms that are optimized for decentralized networks (such as Gossip, Kademlia or others).
- They minimize the size of your transactions and keep your blocks “low in fat”.
Hence positions like the 2 MB blocks in Bitcoin or the fact that the size of the transactions should be optimized on an extreme level.However, this is not practical in networks that support distributed applications because it limits their growth in many ways. To address these two issues at Solana, they set out to create the Turbine and Gulf Stream logs.
Turbine is a block propagation protocol that makes it easier to deliver the information to the nodes and helps maintain consensus within the network. This is an essential process that needs to be fast as Solana’s block generation speed is fast (an average of 0.5 seconds per block), which indicates that the way this information is passed on to the network must be the same or faster. To do this, Turbine shares the problem and by sharing we mean that the information in the blocks is broken down into small sections that are sent to the network and reconstructed by the nodes according to their own states.
In short, Turbine cheats, instead of sending all the information of the block, it displays the contents of the block and helps the rest of the nodes to rebuild that block. And in the event that a node does not have the information it needs to recover, it can request that information from the rest of the network in parallel to reduce bandwidth consumption, maximize speed, and achieve its goal of maintaining a secure consensus . The strange thing is that this system is based on what we could call “pyramidal”, in that the generator node (the first node) sends some of the information to a certain group of nodes and those other nodes distribute the information that the correspond to certain groups of them. In the end, the entire network receives the information, they rebuild the block and the consensus is generated.
But you wonder How do the other nodes know the information they need to read the first node to recreate generated block? The Gulf Stream comes into operation there. Gulf Stream is a Solana network transaction caching protocol. Its job is to receive the transaction and send it to all nodes, but prioritizing the generating nodes. So, All nodes on the network have the information necessary to rebuild the turbine blocks. Also remember that Solana creates its blocks thanks to the choice of a quorum that has the ability to generate a block and send it to the network.
However, the role of these generators is not just to create the block, but also to act as a selector for the next generation group. This means that it is always known in advance which nodes will generate the next block. For this reason, the nodes can receive the transactions and forward them to the next generator nodes. In this way, such transactions can be taken over and included in the next block, which minimizes block production time. All of this is possible because the process of selecting the block generation ladder in Solana is deterministic, that is, it is possible to know in advance who will be the next block generator.
To avoid tampering with the system, every transaction in Gulf Stream has a marked lifespan of approx. 24 seconds. If a transaction is not confirmed during this period, only one exit can be expected: a transaction failure and the need to resend the transaction. However, Solana’s processing speed is so fast that it can only do so when it reaches peak performance. With the ability to reach up to 50,000 TPS on its current mainnet network, this is difficult to achieve.
Sealevel, parallelization of intelligent contracts
One of Solana’s greatest advances is the ability to parallelize the execution of transactions and smart contracts. Let’s remember that in blockchain, even the simplest transaction is actually a smart contract, and this is true for Bitcoin and, of course, Solana. Also, Solana uses the C and Rust languages To create a unique intelligent contract programming environment and, among other things, to parallelize the execution. This is possible thanks to Sealevel, the name under which the Solana developers identified this function.
Smart contract example in Solana in C language
With Sealevel, Solana can read, execute and write instructions within the Solana Smart Contract Execution Layer in parallel. In contrast to networks like Ethereum and EOS, in which their intelligent contract systems are single-threaded (only one action can be performed at a time), Solana can execute several actions at the same time, execute different intelligent contracts and use all computing resources of the network in parallel.
To make it easier to look at, imagine you have a folder with 100 sheets of paper and each sheet has 10 problems. This is a total of 1000 problems that must be solved by the computer network. When we set up a network like Ethereum to solve these problems, we take each sheet of paper and solve each problem one at a time until everyone is finished. In Solana it would happen that the 100 leaves would be taken and the 10 problems solved by each of them at the same time. This makes one thing clear: If the computers on the Solana network are powerful, Solana will run much faster than Ethereum. In fact, it would be impossible for Ethereum to match Solana’s speed.
Sealevel is useful because it helps Solana scale in ways that other networks cannot. For example, if we install a Solana node on a weak computer, our processing capacity will be less. However, as we upgrade the equipment, our processing capacity increases. This enables the efficiency and performance of our computing equipment to have a direct impact on Solana’s scalability, which has been accurately demonstrated in its test networks and its performance peaks of up to 500,000 transactions per second. In addition, this tells us something about Solana: Solana does not require any second layers and is able to process everything directly in the blockchain.
Other cool features in Solana
On the other hand, Solana is a network that is dedicated to the provision of decentralized applications (DApps). With that in mind, Solana has distributed storage systems (known as archivers) that are used to store first-level information for applications, making it easier to access these resources across the network. in addition, Solana has a system called Cloudbreak that is used to maintain a consistent data structure across all nodes.
In a nutshell, Solana is a highly innovative project with its own solutions for many of its problems and technical challenges in order to make one of the fastest blockchain networks available today.