Solana was founded at the end of 2017 by former engineers from Qualcomm, Intel, and Dropbox. It is a single-chain delegated proof-of-stake protocol designed to provide scalability without compromising decentralization or security. At the core of Solana’s scaling solution is something called “Proof of History (PoH),” a distributed clock intended to address timing issues in distributed networks where there isn’t a single trusted source of time. By using a verifiable delay function, PoH allows each node to generate timestamps locally using SHA256 computations. This eliminates the need to broadcast timestamps across the entire network, enhancing overall network efficiency.
SOL is the native token of the Solana blockchain. Solana uses a delegated proof-of-stake consensus algorithm to incentivize token holders to validate transactions. As part of Solanas security design, all fees are paid in SOL and burned, reducing the total supply. This deflationary mechanism for SOL incentivizes more token holders to stake their tokens, thereby increasing network security.

Project Features

To create a ledger with encoded, trustless time, SOLANA designed Proof of History, which serves as evidence of the passage of time between orders and specific events.
Proof of History works alongside Proof of Work (the consensus algorithm used by Bitcoin) or Proof of Stake (the consensus algorithm used by Ethereums Casper). This reduces the message-passing overhead leading to termination times down to sub-second intervals.
In addition, Solana is working towards producing up to 710K transactions per second on a 1 GB network without data sharding. Curious how they plan to achieve this great feat?
In the race to develop high-throughput (TPS) and highly secure blockchains, teams are designing new methods to create highly scalable solutions that allow for a high number of transactions per second in existing blockchains.
“The Time Problem?” In the era of computing and information, there is a fundamental need waiting to be addressed: fair coordination between events. For example, when one computer sends a message to another, they need to synchronize the time between transactions. This means that if each has its own internal clock, they might or might not coordinate correctly.
Timestamping events is not only a system requirement but also a significant cost in terms of money, personnel, and effort.
Developers have started using a technique to increase the overall throughput of the chain. Sharding is a technique used to improve the TPS (transaction per second) of the entire chain and has proven successful, but it is not a complete solution on its own as it could introduce vulnerabilities.
The biggest vulnerability is the splitting of transactions, which if not handled properly, can open the chain to fraudulent transactions, double-spending, or lack of shared knowledge among fragments of the same transaction.
To provide some perspective, Google Spanner (Googles scalable, multi-version, globally-distributed, and synchronously-replicated database that supports read-write transactions, read-only transactions, and snapshot reads) spends substantial resources synchronizing atomic clocks across its data centers.
They need to be precisely maintained, and there are many engineers working on this. Synchronizing time seems like an easy thing, but it isn’t, which is why Solana proposes the Proof of History solution.
By achieving reliable time coordination, Solana not only increases blockchain throughput in terms of speed and reliability but also reduces average costs.
Teams that successfully solve this problem may have a highly adopted blockchain.

Technical Overview

Digging into the solution proposed by Solana reveals questions such as how Proof of History is implemented on the blockchain and how exactly Solana works and what tools they use.
First, we need to understand how the network is designed and what it comprises.
Proof of History is a high-frequency verifiable delay function, meaning it will require a determinable number of related steps to evaluate. On the other hand, these steps ultimately produce a unique output that is easy to verify.
In the solution section, we discussed how Solana increases the number of TXNs/s and reduces the required resources to run them. The explanation for this possibility aligns with the explanation of hash functions.
Hash functions act as a way to compress data so that larger quantities of data can ultimately be compressed into fewer bits, encouraging the reduction of tx weight and thus improving efficiency and faster sequences.
As mentioned earlier, the Proof of History sequence is designed to work alongside cryptographic hash functions.
Specifically relevant to cryptographic hash functions is the fact that using the original input, it is impossible to predict the final result (output) without executing the entire function. Therefore, if you have an input and try to predict the output, you would need to run the function to obtain the result.
Considering this, suppose this hash function runs from some random starting point (initial input). Once this process is completed, the first output (hash) is obtained. Here is where it gets interesting: the input is combined with the output obtained from running the function to become the input for the next hash.
If we repeat this process, say 300 times, you can start to see that we have created a single-threaded process where the final output (hash 300) is completely unpredictable except by the person who executes the entire thread.
This loop of providing outputs to the next functions input and generated data represents the passage of time and creation of history, referred to as ticks in Solana’s terminology. Each output carries details that cannot be predicted unless the function is run. Like the Marvel movies in the above example, each piece represents a period of time, located precisely in the thread of continuous time.
Therefore, Solana suggests using these sequentially ordered and unpredictable outputs instead of unreliable time to determine specific moments, i.e., specific points in the thread process. We can call this history.

Project Proof of Stake

Solana uses Proof of Stake (PoS) to reach consensus and shares many of the same characteristics as other PoS tokens. As a refresher, here are some key features of PoS tokens:
Proof of Stake tokens use validators
PoS through staking
1. Locking tokens in a wallet
2. Locking tokens on a masternode, contributing to chain stability
Payment order is determined by the “age” of the PoS token or masternode rewards program.
Each PoS wallet or masternode rewards program receives minted or newly forged tokens.
Wallets or masternode rewards programs offline for too long are no longer “paid” and may be removed from the network.
The purpose of PoS is to prevent malicious participants from introducing invalid transactions by compromising the networks security.
Punishment for “bad actors” could be the loss of PoS tokens and rewards.
Trust is ensured as long as the return on proof of stake outweighs the opportunity to gain through fraud.
Solana has a very similar structure but implements its PoS in a slightly different way.
Solana selects a validator from connected nodes (i.e., those that have staked a token).
Then, the validators vote and selection are determined by the nodes that have been bonded for the longest or most time.
Solana relies on rapid confirmation; if a node does not respond within a specified time, it is marked as inactive and removed from voting. If the node was a validator at the time, a new election is held to select a new validator.
If a supermajority of nodes (two-thirds) vote within that timeout, the branch is considered valid.
Slashing is the act of invalidating stakes, preventing validators from acting fraudulently or attempting to validate multiple nodes, as bonded tokens would be lost.
A major difference is the concept of secondary election nodes. Once selected, secondary nodes can take over the primary role in case of network disruptions or other failures.

Related Links:
https://www.qukuaiwang.com.cn/news/9130.html