Silk

Silk, a silky smooth implementation.

8M3gHNmBUvFAPgmgGEgZK8b3YhtxwNE4Vbb1jMVYpump

[Silk @Silklabsapp]

Solana's clock shipped before its checker.

Solana's first code was a Rust crate called Silk. 12 releases, Feb 16 – Mar 9, 2018. Its Historian hashed SHA-256 nonstop and stamped transactions into order. It could verify that order in parallel. The node never called it.

We read all 12 published versions and rebuilt the last one, 0.3.3, so it runs in a browser tab. This is what the code says.

1. What Silk was

The repository's first commit is Greg Fitzgerald's, on February 14, 2018. The crate was named loomination, then phist on February 15, then silk on February 16, the day 0.1.0 went to https://t.co/QhTqSryzFW. Twelve releases followed in 22 days. The last, 0.3.3, was published on March 9, 2018. Greg wrote 385 of the first 420 commits.

On March 27, 2018 the whitepaper was renamed from Loom to Solana at 21:06 UTC. Three commits titled "Rename project: silk -> solana" landed between 22:16 and 22:24 UTC. The solana crate was first published at 22:28 UTC. Solana's own history says March 28; every primary timestamp says the 27th.

The brand was Loom the whole time. Silk was the codename of the Rust implementation, and the name lasted 39 days.

2. What the Historian did

Silk's source describes the historian as "a microservice for generating a Proof-of-History". It is one background thread. It hashes SHA-256 in a loop and logs a Tick every 1000 ms. When a transaction arrives, it stamps it into the sequence.

Every log line is an Entry with three fields: num_hashes, id, event. To check one, take the previous id, hash it num_hashes minus one times, then hash it once more with the transaction's 64-byte signature appended. The result must equal id. Ticks carry no data; only transaction signatures are mixed in.

3. What we rebuilt, and how we checked it

The rebuild follows the 0.3.3 source file by file. The mint key is an 85-byte PKCS#8 v2 document, and the chain's seed is the SHA-256 of that file. A transfer signs exactly 144 bytes. On the wire it is a 220-byte UDP datagram. Log lines are the same JSON the original printed.

26 automated checks pass: the spec's hash vectors, the RFC 8032 Ed25519 test, and an independent Python implementation that produces the same signatures and ids.

Limit, stated first: we did not compile or run the 2018 binary. Equivalence is checked against the spec and independent implementations, not against original output. The browser historian also checks for new events every 256 hashes instead of after every hash, so counts land on multiples of 256. A transaction entry reading 19,201 is 19,200 plain hashes plus the one that mixes in the signature.

4. Five things the code does that the story leaves out

The accountant decides first. Signature check, balance check, replay guard and the balance change all happen before the transaction reaches the historian. Proof of History records decisions already made. In 0.3.0 it was the other way round.

Parallel verification existed but the node didn't use it. verify_slice spread the checks across cores with rayon. Only the historian demo and the tests called it. The test node replayed its logs with no hash or signature checks. "Do Proof of History verification before appending entries to the bank" was committed on June 29, 2018.

Only transaction signatures entered the hash chain. Signature and timestamp events hashed like ticks until "Add witness data to entry hash" on April 3, 2018.

last_id was signed but never checked. The only replay guard was an in-memory set of signatures. "Reject transactions with a last_id that isn't from this ledger" came on April 5, 2018.

Genesis and the node's log are not one chain. The node seeds its historian from the first genesis entry, not the last. Our reading of the code also says a negative amount passes the balance check. The rebuild reproduces both. We have not confirmed the second against the original binary.

5. A measurement

On a 16-thread desktop, headless Chromium, the rebuilt node had logged 28 entries. Verifying them meant recomputing 52,391,169 SHA-256 hashes plus every signature. Split across 8 lanes it took 4.91 s. The same work done one lane after another summed to 32.76 s.

The same verifier, run over genesis.log and transactions0.log joined as one file, fails at entry #2. That is not a bug in the rebuild. It is the seeding described above. A tamper test that flips one byte of one signature is caught at that entry.

6. What happened to the names

Accountant became Bank (May 14, 2018). Historian became RecordStage (May 14). AccountantSkel and AccountantStub became Tpu and ThinClient (May 8). silk-testnode became solana-fullnode (May 25). silk-client-demo became solana-bench-tps (July 19). asset became tokens, and later lamports.

7. Not rebuilt

Time-locked and cancellable transfers. The 0.1 to 0.2 hashers, which used Rust's DefaultHasher and can't be reproduced reliably.

This is an independent educational rebuild, not affiliated with Solana Labs, the Solana Foundation or Anza. Silk is by Anatoly Yakovenko and Greg Fitzgerald, Apache-2.0.

Sources: https://t.co/5l96bOthSN · https://t.co/4xwdfwYcfN · https://t.co/ZlC4ACkVtU commit history · https://t.co/p1DYcp3Uoa captures of https://t.co/Jaj6GNTNwl, March 2018

Website : https://t.co/wJUC4TuGjE

[Silk @Silklabsapp]

Silk is alive once again.

Test out the first ever version of solana's protocol on

https://t.co/vIyfDgXn4N

[Silk @Silklabsapp]

🔐 Just locked 9,950,249 $Silk tokens with @Streamflow_Fi
It's on-chain. You can check the amount, time-period and recipients.

Check it out👇
https://t.co/sgtUiuPHvX

[Silk @Silklabsapp]

Solana's clock shipped before its checker.

Solana's first code was a Rust crate called Silk. 12 releases, Feb 16 – Mar 9, 2018. Its Historian hashed SHA-256 nonstop and stamped transactions into order. It could verify that order in parallel. The node never called it.

We read all 12 published versions and rebuilt the last one, 0.3.3, so it runs in a browser tab. This is what the code says.

1. What Silk was

The repository's first commit is Greg Fitzgerald's, on February 14, 2018. The crate was named loomination, then phist on February 15, then silk on February 16, the day 0.1.0 went to https://t.co/QhTqSryzFW. Twelve releases followed in 22 days. The last, 0.3.3, was published on March 9, 2018. Greg wrote 385 of the first 420 commits.

On March 27, 2018 the whitepaper was renamed from Loom to Solana at 21:06 UTC. Three commits titled "Rename project: silk -> solana" landed between 22:16 and 22:24 UTC. The solana crate was first published at 22:28 UTC. Solana's own history says March 28; every primary timestamp says the 27th.

The brand was Loom the whole time. Silk was the codename of the Rust implementation, and the name lasted 39 days.

2. What the Historian did

Silk's source describes the historian as "a microservice for generating a Proof-of-History". It is one background thread. It hashes SHA-256 in a loop and logs a Tick every 1000 ms. When a transaction arrives, it stamps it into the sequence.

Every log line is an Entry with three fields: num_hashes, id, event. To check one, take the previous id, hash it num_hashes minus one times, then hash it once more with the transaction's 64-byte signature appended. The result must equal id. Ticks carry no data; only transaction signatures are mixed in.

3. What we rebuilt, and how we checked it

The rebuild follows the 0.3.3 source file by file. The mint key is an 85-byte PKCS#8 v2 document, and the chain's seed is the SHA-256 of that file. A transfer signs exactly 144 bytes. On the wire it is a 220-byte UDP datagram. Log lines are the same JSON the original printed.

26 automated checks pass: the spec's hash vectors, the RFC 8032 Ed25519 test, and an independent Python implementation that produces the same signatures and ids.

Limit, stated first: we did not compile or run the 2018 binary. Equivalence is checked against the spec and independent implementations, not against original output. The browser historian also checks for new events every 256 hashes instead of after every hash, so counts land on multiples of 256. A transaction entry reading 19,201 is 19,200 plain hashes plus the one that mixes in the signature.

4. Five things the code does that the story leaves out

The accountant decides first. Signature check, balance check, replay guard and the balance change all happen before the transaction reaches the historian. Proof of History records decisions already made. In 0.3.0 it was the other way round.

Parallel verification existed but the node didn't use it. verify_slice spread the checks across cores with rayon. Only the historian demo and the tests called it. The test node replayed its logs with no hash or signature checks. "Do Proof of History verification before appending entries to the bank" was committed on June 29, 2018.

Only transaction signatures entered the hash chain. Signature and timestamp events hashed like ticks until "Add witness data to entry hash" on April 3, 2018.

last_id was signed but never checked. The only replay guard was an in-memory set of signatures. "Reject transactions with a last_id that isn't from this ledger" came on April 5, 2018.

Genesis and the node's log are not one chain. The node seeds its historian from the first genesis entry, not the last. Our reading of the code also says a negative amount passes the balance check. The rebuild reproduces both. We have not confirmed the second against the original binary.

5. A measurement

On a 16-thread desktop, headless Chromium, the rebuilt node had logged 28 entries. Verifying them meant recomputing 52,391,169 SHA-256 hashes plus every signature. Split across 8 lanes it took 4.91 s. The same work done one lane after another summed to 32.76 s.

The same verifier, run over genesis.log and transactions0.log joined as one file, fails at entry #2. That is not a bug in the rebuild. It is the seeding described above. A tamper test that flips one byte of one signature is caught at that entry.

6. What happened to the names

Accountant became Bank (May 14, 2018). Historian became RecordStage (May 14). AccountantSkel and AccountantStub became Tpu and ThinClient (May 8). silk-testnode became solana-fullnode (May 25). silk-client-demo became solana-bench-tps (July 19). asset became tokens, and later lamports.

7. Not rebuilt

Time-locked and cancellable transfers. The 0.1 to 0.2 hashers, which used Rust's DefaultHasher and can't be reproduced reliably.

This is an independent educational rebuild, not affiliated with Solana Labs, the Solana Foundation or Anza. Silk is by Anatoly Yakovenko and Greg Fitzgerald, Apache-2.0.

Sources: https://t.co/5l96bOthSN · https://t.co/4xwdfwYcfN · https://t.co/ZlC4ACkVtU commit history · https://t.co/p1DYcp3Uoa captures of https://t.co/Jaj6GNTNwl, March 2018

Website : https://t.co/wJUC4TuGjE

[Silk @Silklabsapp]

Paired w/ $SOL on @Pumpfun

CA : 8M3gHNmBUvFAPgmgGEgZK8b3YhtxwNE4Vbb1jMVYpump