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

New tools:

• silk-mint: Mint new tokens
• silk-genesis: Generate a barebones genesis log from the mint

New features:

• Automatically execute transactions when a trusted time source submits a timestamp
• Cancel pending transactions

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

Demonstrate the historian, an interactive Proof-of-History

v0.2.0

Remove assertions that fail in the kcov docker container