Cryptographic schemes:

    Proof of History:

Proof of History in Solana is a consensus technique that enables the Solana Blockchain to remain a decentralized network while still achieving fast transactions. It creates a verifiable record of the order of the blochain’s events that have occurred.
For example to make an analogy that simplifies this technique, we have scrambled photos taken in each stage of the cell division:

We would still manage to organize them using the theory of cell division as a function of time even if we don't know the time of each photo.

Same way, Solana using hashing, a verifiable recursive delay function evaluates in a specified number of successive steps and generates outputs that are verified publicly, SHA256 hashes the incoming transactions and events, it evaluates in a specified number of successive steps and generates a unique output that it openly and efficiently verified.
Essentially a SHA-256 runs over and over using the previous output as the next input to the next SHA-256 hash. The count and the current output are periodically recorded.

In order to parallelize we need a brute force attack using cores, which is impossible. 2 Hence,we 128 can assure that real time has passed between every generated counter as well as the order of each counter matching the real time.
Since the used hash function is collision resistant, this hashes can only be computed by a single computer thread because it is impossible to predict what is the hash value at a given index. if we want
to know the hash value at the index 600 we actually need to run the algorithm 600 times from the value of the start. Therefore, this means that actual real time has passed between i=0 and i=600 according to the data structure.

In the previous figure (1),
● The hash 62f51643c1 was generated on the count 510144806912.
● The hash c43d862d88 was generated on the count 510146904064.
Thus, according to the counts and the Proof of History we can trust that real time occurred between the count 510144806912 and the count 510146904064.

                                    -figure 2 Inserting a TX in PoH

In figure(2) in The Proof of History Sequence, we can observe that transaction (TX1)
occurred at count 501 and the transaction (TX2) occurred at count 51014 then we can say by analyzing the PoH that TX1 happened no later than count 510 and TX2 was inserted no later than count 510148. Therefore, TX1 was made before TX2.

                                                       figure3- Digital Signature

Any input into the PoH has reference to the PoH itself. When users insert a transaction, they use the previous recent hash that is visible to them and then they sign the transaction.
This signed transaction is a part of the input SHA-256(previous hash, signed TX) to
produce the next hash in PoH. Without the user’s private key, nothing can be modified.

Verification:

Unlike the recorded sequence that is produced by a single CPU, the output is verified in parallel.

                                            figure 4: Parallel Verification

As in figure4, a single validator can validate that hash 1 was used as the input of hash 2. At the same time it verifies that hash 2 and the signed TX were the input to generate hash 3 using two cores for verification.
The total time of generating the PoH can be computed with the total number of hashes over the hashes per second fore 1 single core:

The total time is takes to verify the PoH is:

Horizontal Scaling:

By blending the sequence state from each generator to the other we can arrive to horizontal scaling in order to make many synchronized PoH generators. The scaling can be achieved without splitting into partitions (Sharding). It is mandatory to use the output of the two generators to fully maintain the order of events. 

In the previous table, Generator A and B will be mixing sequences such as A gets a data from B(hash1b), hash1b carries the most recent state fom B, and the most recent state B observed in A.
Therefore, The next hash in A depends on the state from B. Like this we can infer that hash1b happened before hash3a. This is a transitive property meaning that if there are more than 2 generators to be synchronized through a specific generator commonly ( A B C ) we can then track down that A anc are dependent on each other despite being synchronized directly, B is their common generator.
The periodic synchronization is a timer gainer for the overall system because each generator is in charge of part of external traffic. This way, the system will be able to treat a bigger number of events to trace it according to the real time value using the network reaction time (latency) between the generators.

Consistency:

In order to secure the generated sequences and make them resistant to attacks, users are ought to insert the most recent observed output of the sequence they suppose is valid into their own input

Attacks:

Reorder:

During an attack, malicious Proof of History generators create a duplicated second sequence with a reversed order of events, in the case it can access all the events or is able to produce faster hidden sequences. to secure the system from this type of attacks, each generated event itself by the users must have the latest recent hash that the client considered a valid sequence. 
If a client generates Event1 data, they are ought to attach the recent hash they noticed.

In order to publish the sequence, Event3 points at hash30a, if it's not the case, the users of this sequence will consider it invalid. Therefore any attack is limited because it is a partial disorder, and the client will observe the number of hashes produced.
In addition, the software written by clients doesn’t simply assume that a sequence is correct from just the period of hashes between most recent and the new entered hash, it also prevents malicious Proof of History generators from rewriting the client Event hashes because they submit their signature with the data of the most recent and inserted hash instead of submitting only the data. 
The Verification of this data is done by verifying the signature as well as looking up at the last hash prior to the inserted event hash.

(Signature, PublicKey, hash30a, event3 data) = Event3 Verify(Signature, PublicKey, Event3) Lookup(hash30a, PoHSequence)

    2.Reversal:

To generate a reverse order the attacker starts the malicious sequence right after the second event which is already a delay that allows the normal peer to peer nodes the communication about the original non malicious one.

    3.Long Rang Attacks:

This type of attack consists of using old abandoned private keys and generating a falsificated ledger.
A malicious client that has access to a discarded private key has to remake as well a historical record which takes the same amount of time as the original one they are trying to create. This operation requires a faster processor than the network in use, if not, the attacker will never be able to reach the history length. Besides, there exists only one single source of time for the synchronization since the network is made in such a way that all participants will rely only on one single historical record. This way PoH protects against both space and time attacks.

Privacy and Security in Solana

 Solana is a high-performance blockchain platform that aims to provide fast, low-cost transactions and decentralized applications. The Solana protocol does not have built-in privacy features, however, there are some privacy-enhancing solutions that have been proposed for Solana, such as using zero-knowledge proofs to enable private transactions. But it's not widely adopted yet.

In Addition Solana is a decentralized blockchain platform, meaning that it uses distributed consensus to validate and record transactions on its network. This makes it resistant to many forms of attacks, including those that involve taking control of a single point of failure.
The Solana network is secured by a proof-of-stake (PoS) consensus mechanism, in which validators on the network stake their own tokens to participate in the consensus process. This provides an economic incentive for validators to act honestly and to ensure the security of the network.
However, like any software system, Solana is not immune to all types of attacks and vulnerabilities. It is so fast and it requires constant verification in order to keep malicious sequences from infecting the system, but until now, the function it uses SHA-256 is collision resistant and the PoS was very secure so far. Smart contract code can be audited and tested to minimize potential vulnerabilities, but it is not perfect. A smart contract running on Solana can have bugs, which can be exploited to steal funds or disrupt the normal operation of the contract.
In short, while Solana is designed to be highly secure, it is important to note that no system can be completely secure and that users should exercise caution when using the platform and interacting with smart contracts.

Solana vs other Cryptocurrencies

Ethereum founder said lately that Solana deserves to have a chance even though it is the first competitor to his currency. Solana got noticed and the prices were going up since a while because of its efficiency, speed and the cheap transaction fees. 

It is hard to say whether one platform is more secure than the other, but there is a slight difference between Solana and Ethereum as this last one is more decentralized than Solana, because speed comes with a cost. Other than that Solana is a very secure platform with a very high performance.