Releases: solana-labs/solana
35,000 Transactions per Second
Loom (Protocol) renamed to Solana
Loom Protocol is no more! To avoid confusion with the Ethereum-based Loom Network, we've renamed our project to Solana. Why Solana? We're proudly paying homage to the most beautiful place we've lived, Solana Beach, California. The cofounders have fond memories of surfing mushy waves at Fletcher Cove 🌊🦈🌊 and enjoying much grub and grog at Pizza Port just around the corner. Stay in touch at https://solana.io 🍺🍕🍺
New in v0.4.0
Solana's TPS Report: now processing 35,000 transactions per second
This release offers a 700% increase in transaction throughput, from 5ktps to 35ktps, over the v0.3.0 release while also laying the groundwork for a slew of new optimizations. Thanks to the new streamer functionality contributed by @aeyakovenko, input to the server is already I/O bound and able to consistently pull transactions off the wire at over 700ktps!
Introducing smart contracts
We added a highly-constrained, but surprisingly flexible form of smart contracts called spending plans to the blockchain. We can represent postdated checks, cancellations of those checks, transaction expirations, and witness signatures.
Sunny days ahead for Solana
35ktps is just the beginning and we're optimistic about our odds of improving that by another 10x in the near-term. Here's why:
Consensus with OCC (no relation to Orange County)
Solana's soon-to-come consensus mechanism, that relies on our unique Proof of History blockchain format, won't degrade performance. We're happily moving forward under the same technical constraints of a centralized system. As we approach our theoretical maximum of 710,000 transactions we'll trade throughput for availability, but that's it!
Blockchain format updated for parallel verification
One of the most exciting aspects of Proof of History is that it allows for parallel verification. We're working to extend that property to all aspects of blockchain verification, including accounting and our smart contracts. Here's some of the changes we made:
-
We've moved to a token encoding where the maximum number of tokens can be represented within a signed 64-bit integer. The new format means that we can apply the highly parallel map-reduce technique to calculating balances without spilling into multi-word integers.
-
We've relaxed the ledger entry format such that transactions may be added without requiring serialization via a hash from the Proof of History hash chain. That means we get to start shipping huge batches of transactions to GPU for verification. Four thousand cores at our disposal!
Contributions
Thanks so much to those that reviewed our beta release:
- @jackson-sandland for the documentation review and test-driving the Solana benchmark suite
35ktps
Loom renamed to Solana
To avoid confusion with the Ethereum-based Loom Network, we've renamed our project to Solana. Why Solana? We're proudly paying homage to the most beautiful place we've lived, Solana Beach, California. The cofounders have fond memories of surfing mushy waves at Fletcher Cove 🌊🦈🌊 and enjoying much grub and grog at Pizza Port just around the corner. 🍺🍕🍺
New in v0.4.0-beta
Solana's TPS Report: now processing 35,000 transactions per second
This release offers a 700% increase in transaction throughput, from 5ktps to 35ktps, over the v0.3.0 release while also laying the groundwork for a slew of new optimizations. Thanks to the new streamer functionality contributed by @aeyakovenko, input to the server is already I/O bound and able to consistently pull transactions off the wire at over 700ktps!
Introducing smart contracts
We added a highly-constrained, but surprisingly flexible form of smart contracts called spending plans to the blockchain. We can represent postdated checks, cancellations of those checks, transaction expirations, and witness signatures.
Sunny days ahead for Solana
35ktps is just the beginning and we're optimistic about our odds of improving that by another 10x in the near-term. Here's why:
Consensus with OCC (no relation to Orange County)
Solana's soon-to-come consensus mechanism, that relies on our unique Proof of History blockchain format, won't degrade performance. We're happily moving forward under the same technical constraints of a centralized system. As we approach our theoretical maximum of 710,000 transactions we'll trade throughput for availability, but that's it!
Blockchain format updated for parallel verification
One of the most exciting aspects of Proof of History is that it allows for parallel verification. We're working to extend that property to all aspects of blockchain verification, including accounting and our smart contracts. Here's some of the changes we made:
-
We've moved to a token encoding where the maximum number of tokens can be represented within a signed 64-bit integer. The new format means that we can apply the highly parallel map-reduce technique to calculating balances without spilling into multi-word integers.
-
We've relaxed the ledger entry format such that transactions may be added without requiring serialization via a hash from the Proof of History hash chain. That means we get to start shipping huge batches of transactions to GPU for verification. Four thousand cores at our disposal!
Renamed silk to solana
v0.4.0-alpha Rename project: silk -> solana
Proof of Order
You can now start the Historian or Accountant in tick-less mode. That means you lose the duration between events, but add determinism in the event log. You're left with a proof of order, not a proof of history.
Timestamp processing
This is a small patch on v0.3.1 that processes timestamps as they enter the system.
Genesis
V0 testnet
$ cargo build --release
$ target/release/silk-testnode &
$ time target/release/silk-client-demo
Depositing 10,000 units in Alice's account...
Done.
Transferring 1 unit 10,000 times...
Done.
Checking on Alice's Balance 2118
Checking on Alice's Balance 1989
Checking on Alice's Balance 1870
Checking on Alice's Balance 1742
Checking on Alice's Balance 1593
Checking on Alice's Balance 1477
Checking on Alice's Balance 1349
Checking on Alice's Balance 1240
Done. Checking final balances.
Alice's Final Balance 0
Bob's Final Balance 10000
target/release/silk-client-demo 0.54s user 0.33s system 37% cpu 2.340 total
Added new Claim event, signed event data
In this version UserDataKey events were renamed to Discovery events, and a new event Claim was added. The Discovery events are used to publish hashes to the event log. It allows you to order data that you discovered, but not attempt to assign any ownership to it. The new event Claim exists to claim ownership over that same data. For example, one use of the chain would be to allow graphics designers to hash their images, sign them with a private key, and then publish Claim events to effectively claim copyright on those images. Those observing the log would not be able to see the image, but should they get a copy, they could track down the copyright holder via the Claim's public key.
self-ticking logger
With this release, one can create a historian and send it UserDataKey events over time. You can then query the historian for the hashed log entries and verify them in parallel.
Switch to sha256 hashes
v0.2.1 Version bump