Solana: A new architecture for a high performance blockchain

1 Solana: A new architecture for a highperformance blockchain DisclaimerNothing in this white paper is an offer to sell, or the solicitation of an offerto buy, any tokens. Solana is publishing this white paper solely to receive feedback and comments fromthe public. If and when Solana offers for sale any tokens (or a Simple Agreement for Future Tokens), itwill do so through definitive offering documents, including a disclosure document and risk factors. Thosedefinitive documents also are expected to include an updated version of this white paper , which maydiffer significantly from the current version. If and when Solana makes such an offering in the UnitedStates, the offering likely will be available solely to accredited in this white paper should be treated or read as a guarantee or promise of how Solanasbusiness or the tokens will develop or of the utility or value of the tokens. This white paper outlinescurrent plans, which could change at its discretion, and the success of which will depend on many factorsoutside Solanas control, including market-based factors and factors within the data and cryptocurrencyindustries, among others.

2 Any statements about future events are based solely on Solanas analysis of theissues described in this white paper . That analysis may prove to be paper proposes a new blockchain architecture based on Proofof History (PoH) - a proof for verifying order and passage of timebetween events. PoH is used to encode trustless passage of time intoa ledger - an append only data structure. When used alongside aconsensus algorithm such as Proof of Work (PoW) or Proof of Stake(PoS), PoH can reduce messaging overhead in a Byzantine Fault Tol-erant replicated state machine, resulting inn sub-second finality paper also proposes two algorithms that leverage the time keep-ing properties of the PoH ledger - a PoS algorithm that can recoverfrom partitions of any size and an efficient streaming Proof of Replica-tion (PoRep). The combination of PoRep and PoH provides a defenseagainst forgery of the ledger with respect to time (ordering) and stor-age.

3 The protocol is analyzed on a 1 gbps network, and this papershows that throughput up to 710k transactions per second is possiblewith todays IntroductionBlockchain is an implementation of a fault tolerant replicated state publicly available blockchains do not rely on time, or make a weakassumption about the participants abilities to keep time [4, 5]. Each node inthe network usually relies on their own local clock without knowledge of anyother participants clocks in the network. The lack of a trusted source of timemeans that when a message timestamp is used to accept or reject a message,there is no guarantee that every other participant in the network will makethe exact same choice. The PoH presented here is designed to create a ledgerwith verifiable passage of time, duration between events and messageordering. It is anticipated that every node in the network will be able to relyon the recorded passage of time in the ledger without OutlineThe remainder of this article is organized as follows.

4 Overall system design isdescribed in Section 3. In depth description of Proof of History is describedin Section 4. In depth description of the proposed Proof of Stake consensusalgorithm is described in Section 5. In depth description of the proposedfast Proof of Replication is described in Section 6. System architecture andperformance limits are analyzed in Section 7. A high performance GPUfriendly smart contracts engine is described in Section Network DesignAs shown in Figure 1, at any given time a system node is designated asLeader to generate a Proof of History sequence, providing the network globalread consistency and a verifiable passage of time. The Leader sequences usermessages and orders them such that they can be efficiently processed by othernodes in the system, maximizing throughput. It executes the transactionson the current state that is stored in RAM and publishes the transactionsand a signature of the final state to the replications nodes called execute the same transactions on their copies of the state, and pub-lish their computed signatures of the state as confirmations.

5 The publishedconfirmations serve as votes for the consensus 1: Transaction flow throughout the a non-partitioned state, at any given time, there is one Leader in thenetwork. Each Verifier node has the same hardware capabilities as a Leaderand can be elected as a Leader, this is done through PoS based for the proposed PoS algorithm are covered in depth in Section terms of CAP theorem, Consistency is almost always picked over Avail-ability in an event of a Partition. In case of a large partition, this paperproposes a mechanism to recover control of the network from a partition ofany size. This is covered in depth in Section Proof of HistoryProof of History is a sequence of computation that can provide a way tocryptographically verify passage of time between two events. It uses a cryp-tographically secure function written so that output cannot be predictedfrom the input, and must be completely executed to generate the function is run in a sequence on a single core, its previous output as the3current input, periodically recording the current output, and how many timesits been called.

6 The output can then be re-computed and verified by externalcomputers in parallel by checking each sequence segment on a separate can be timestamped into this sequence by appending the data (or ahash of some data) into the state of the function. The recording of the state,index and data as it was appended into the sequences provides a timestampthat can guarantee that the data was created sometime before the next hashwas generated in the sequence. This design also supports horizontal scalingas multiple generators can synchronize amongst each other by mixing theirstate into each others sequences. Horizontal scaling is discussed in depth inSection DescriptionThe system is designed to work as follows. With a cryptographic hash func-tion, whose output cannot be predicted without running the function ( ,ripemd, etc.), run the function from some random starting valueand take its output and pass it as the input into the same function the number of times the function has been called and the output ateach call.

7 The starting random value chosen could be any string, like theheadline of the New York times for the example:PoH SequenceIndex OperationOutput Hash1sha256( any random starting value )hash12sha256(hash1)hash23sha256(hash2)h ash3 WherehashNrepresents the actual hash is only necessary to publish a subset of the hashes and indices at example:4 PoH SequenceIndex OperationOutput Hash1sha256( any random starting value )hash1200sha256(hash199)hash200300sha256 (hash299)hash300As long as the hash function chosen is collision resistant, this set of hashescan only be computed in sequence by a single computer thread. This followsfrom the fact that there is no way to predict what the hash value at index300 is going to be without actually running the algorithm from the startingvalue 300 times. Thus we can thus infer from the data structure that realtime has passed between index 0 and index the example in Figure 2, hash62f51643c1was produced on count510144806912 and hashc43d862d88was produced on count the previously discussed properties of the PoH algorithm, we cantrust that real time passed between count 510144806912 and count 2: Proof of History Timestamp for EventsThis sequence of hashes can also be used to record that some piece of datawas created before a particular hash index was generated.

8 Using a combine function to combine the piece of data with the current hash at the currentindex. The data can simply be a cryptographically unique hash of arbitraryevent data. The combine function can be a simple append of data, or anyoperation that is collision resistant. The next generated hash represents atimestamp of the data, because it could have only been generated after thatspecific piece of data was example:PoH SequenceIndex OperationOutput Hash1sha256( any random starting value )hash1200sha256(hash199)hash200300sha256 (hash299)hash300 Some external event occurs, like a photograph was taken, or any arbitrarydigital data was created:PoH Sequence With DataIndex OperationOutput Hash1sha256( any random starting value )hash1200sha256(hash199)hash200300sha256 (hash299)hash300336sha256(append(hash335 , photographsha256))hash336 Hash336is computed from the appended binary data ofhash335and thesha256of the photograph. The index and thesha256of the photograph arerecorded as part of the sequence output.

9 So anyone verifying this sequencecan then recreate this change to the sequence. The verifying can still be donein parallel and its discussed in Section the initial process is still sequential, we can then tell that thingsentered into the sequence must have occurred sometime before the futurehashed value was SequenceIndex OperationOutput Hash1sha256( any random starting value )hash1200sha256(hash199)hash200300sha256 (hash299)hash300336sha256(append(hash335 , photograph1sha256))hash336400sha256(hash 399)hash400500sha256(hash499)hash500600s ha256(append(hash599, photograph2sha256))hash600700sha256(hash 699)hash700 Table 1: PoH Sequence With 2 EventsIn the sequence represented by Table 1,photograph2was created beforehash600, andphotograph1was created beforehash336. Inserting the datainto the sequence of hashes results in a change to all subsequent values in thesequence. As long as the hash function used is collision resistant, and thedata was appended, it should be computationally impossible to pre-computeany future sequences based on prior knowledge of what data will be inte-grated into the data that is mixed into the sequence can be the raw data itself, orjust a hash of the data with accompanying the example in Figure 3, inserted into theProof of History sequence.

10 The count at which it was inserted is 510145855488and the state at which it was inserted it is3d039eef3. All the future gen-erated hashes are modified by this change to the sequence, this change isindicated by the color change in the node observing this sequence can determine the order at which allevents have been inserted and estimate the real time between the 3: Inserting data into Proof of VerificationThe sequence can be verified correct by a multicore computer in significantlyless time than it took to generate example:Core 1 Index DataOutput Hash200sha256(hash199)hash200300sha256(h ash299)hash300 Core 2 Index DataOutput Hash300sha256(hash299)hash300400sha256(h ash399)hash400 Given some number of cores, like a modern GPU with 4000 cores, theverifier can split up the sequence of hashes and their indexes into 4000 slices,and in parallel make sure that each slice is correct from the starting hash tothe last hash in the slice.