Algorithm

Native Scalability of the BSC(Binance Smart Chain) Blockchain The scalability problem has plagued many cryptocurrencies since almost day one. Blockchain ledgers and decentralized payment networks provide decentralized security to users — but usually, the more decentralized security they provide, the longer it can take for new transactions to be verified and added to the blockchain. These networks are faced with the challenge of providing ample transaction speed as their user count and transaction volume continues to increase, while still preserving the security and decentralization of the network.

When we talk about scalability and throughput, we’re referring to how many transactions can take place per second (this capability is called transactions per second (TPS)). With a high volume of transactions occurring every second, time becomes a crucial element for efficiency. Each computer (or node) processing transactions on a decentralized blockchain network has its own internal clock on which it operates. With thousands of nodes all over the world, there are bound to be slight discrepancies with local system clocks. This becomes problematic when the decentralized network needs to reach consensus about which transactions have taken place and the order in which they occurred. The timestamp synchronization problem is inherent in both Proof-of-Work (PoW) and Proof-of-Stake (PoS) consensus mechanisms.

When transactions occur, they are timestamped according to their local system clock. Then, when other nodes verify the transactions, messages about their confirmation or rejection are also timestamped. The inherent discrepancies between local system clocks (even those from nodes acting in good faith) ultimately pave a path for attacks where bad actors can try to take over a cryptocurrency network using fake transaction broadcasts that closely approximate real timestamps — for example, “fake stake” (or “resource exhaustion”) attacks in the case of PoS, and Denial-of-Service (DoS) attacks in the case of PoW. To ensure that transactions have not been manipulated and that funds are spent only once, a lot of time and processing power needs to be dedicated to verifying timestamp accuracy in a PoW or PoS system.

When all the respective clocks across the decentralized network are synchronized, transactions take much less time to verify because individual nodes do not have to dedicate so much processing power toward verifying various timestamps. This synchronization allows the network to optimize for speed, and as a result, the Solana blockchain is inherently fast and engineered for native scalability — enabling higher energy efficiency and higher security through the low processing power and the tamper-resistant nature of its synchronized timestamps. Solana’s efforts to boost transaction speed rely on a semi-centralized structure in which a node leader is elected and all nodes agree to adopt one universal source of time.

Solana’s built-in mechanism for synchronizing time across nodes helps the network support a theoretical peak capacity of 65,000 transactions per second, currently. Although this figure is supported by a testnet rather than real-world implementation, even at-scale speeds of 50% of Solana’s testnet capacity would be a groundbreaking achievement for the blockchain space. In terms of today’s transaction speeds, 65,000 transactions per second is around 10,000 times faster than Bitcoin, 4,000 times faster than Ethereum, and 35 times faster than Ripple — even around 2.5 times faster than Visa. The protocol is theoretically designed to scale with Moore’s Law, doubling in capacity every two years with improvements in hardware and bandwidth. In other words, as computers get faster, so will Solana.

A New Blockchain Architecture: Proof of Stake and Proof of History Most existing blockchains largely ignore the role of time in their function, with each node timestamping transactions and messages about their confirmation or rejection solely according to its local clock, and sorting out the discrepancies later on. This becomes problematic when the decentralized nodes of a network must reach consensus about the validity of transactions and the order in which they occurred.

In traditional consensus methods, all of the nodes must communicate with one another to determine that time has passed. Each node submits an upvote or downvote for any given block to indicate that the block is valid or invalid, respectively. A certain number of upvotes must be counted in order for a block to be considered valid by the network. So, if a local clock produces a timestamp that widely differs from the time used by other validators, it can result in a delay in confirmation time or even rejection of the block.

Because nodes must communicate back and forth to establish the passing of time, a significant amount of processing power and time must be dedicated to determining the correct chronological order of messages and transactions. The longer it takes to reach consensus, the slower the process of adding new blocks becomes because the next block cannot be verified and added to a blockchain until the current one is confirmed.

Without a trusted source of time, discrepancies between individual device clocks can become a recurring and significant problem, in which there is no guarantee that each node or network participant will verify the authenticity of a message quickly or accurately.

Solana’s blockchain protocol is designed to provide a verifiable passage of time and still preserve many decentralized characteristics without resorting to a “central clock.” The project employs what is known as a Proof-of-History (PoH) consensus method to add the element of time to the Solana blockchain ledger. PoH is designed to cryptographically verify the passage of time between two events. It chains messages from nodes about the validity of blocks together to provide a relative chronological order of events that is not dependent upon local clocks or timestamps.

To accomplish this, a network node is selected as the leader and placed in charge of generating a PoH sequence. This leader sequences messages for maximum efficiency and throughput. The ordered output is sent to replicator nodes called validators, which are in charge of verification for the consensus algorithm. At any given time, there is one leader on the network, which is chosen by PoS elections. Solana’s PoS system relies on a Byzantine Fault Tolerance (BFT) mechanism called Tower Consensus. Tower Consensus leverages PoH as a global source of time before consensus is achieved in order to reduce latency.

Any validator node is eligible to be chosen as the PoH leader. If there is any failure detected with the PoH generator, then the validator node with the next highest voting power will be chosen to replace the original leader.

Proof-of-Stake Consensus Algorithm With the SOL-SAFT Coin SOL-SAFT is the native coin of the Solana blockchain. The validators who process transactions and run the network — as well as the leaders who generate PoH sequences — are chosen according to how much stake they have in the network's overall success, represented by how much SOL they have staked. The nodes with the biggest stakes likely will be chosen to validate and add transactions to the blockchain, thereby earning the associated rewards. This structure ensures that those running the network have a strong incentive to guarantee that it performs optimally and without failure.

Users who hold only a small amount of SOL can also delegate their SOL to a larger validator. By doing so, they can earn a portion of the validator rewards despite not having enough SOL to become a validator themselves. This method of delegation incentivizes even those with small SOL holdings to support the Solana network.

Solana’s incentive system increases the overall security of its network, as many people are financially invested in its proper functioning. It also deters malicious and frivolous actors from attacking the Solana blockchain because of the staking requirements to become an active network participant.

SAFT Token Structure and Economics In addition to providing staked users with eligibility to become a validator or leader, SAFT can be used for generating staking rewards, paying transaction fees on the Solana network, and PoS voting for governance of the network.