Blockchain on Producthunt daily

solana

Thu, 25 Sep 2025 15:29:48 +0800

solana-labs/solana

PLEASE READ: This repo is now a public archive

This repo still exists in archived form, feel free to fork any reference implementations it still contains.

See Agave, the Solana validator implementation from Anza: https://github.com/anza-xyz/agave

Building

1. Install rustc, cargo and rustfmt.

1
2
3

$ curl https://sh.rustup.rs -sSf | sh
$ source $HOME/.cargo/env
$ rustup component add rustfmt

When building the master branch, please make sure you are using the latest stable rust version by running:

`1`	`$ rustup update`

When building a specific release branch, you should check the rust version in ci/rust-version.sh and if necessary, install that version by running:

`1`	`$ rustup install VERSION`

Note that if this is not the latest rust version on your machine, cargo commands may require an override in order to use the correct version.

On Linux systems you may need to install libssl-dev, pkg-config, zlib1g-dev, protobuf etc.

On Ubuntu:

1
2

$ sudo apt-get update
$ sudo apt-get install libssl-dev libudev-dev pkg-config zlib1g-dev llvm clang cmake make libprotobuf-dev protobuf-compiler

On Fedora:

`1`	`$ sudo dnf install openssl-devel systemd-devel pkg-config zlib-devel llvm clang cmake make protobuf-devel protobuf-compiler perl-core`

2. Download the source code.

1
2

$ git clone https://github.com/solana-labs/solana.git
$ cd solana

3. Build.

`1`	`$ ./cargo build`

Testing

Run the test suite:

`1`	`$ ./cargo test`

Starting a local testnet

Start your own testnet locally, instructions are in the online docs.

Accessing the remote development cluster

devnet - stable public cluster for development accessible via devnet.solana.com. Runs 24/7. Learn more about the public clusters

Benchmarking

First, install the nightly build of rustc. cargo bench requires the use of the unstable features only available in the nightly build.

`1`	`$ rustup install nightly`

Run the benchmarks:

`1`	`$ cargo +nightly bench`

Release Process

The release process for this project is described here.

Code coverage

To generate code coverage statistics:

1
2

$ scripts/coverage.sh
$ open target/cov/lcov-local/index.html

Why coverage? While most see coverage as a code quality metric, we see it primarily as a developer productivity metric. When a developer makes a change to the codebase, presumably it’s a solution to some problem. Our unit-test suite is how we encode the set of problems the codebase solves. Running the test suite should indicate that your change didn’t infringe on anyone else’s solutions. Adding a test protects your solution from future changes. Say you don’t understand why a line of code exists, try deleting it and running the unit-tests. The nearest test failure should tell you what problem was solved by that code. If no test fails, go ahead and submit a Pull Request that asks, “what problem is solved by this code?” On the other hand, if a test does fail and you can think of a better way to solve the same problem, a Pull Request with your solution would most certainly be welcome! Likewise, if rewriting a test can better communicate what code it’s protecting, please send us that patch!

Disclaimer

All claims, content, designs, algorithms, estimates, roadmaps, specifications, and performance measurements described in this project are done with the Solana Labs, Inc. (“SL”) good faith efforts. It is up to the reader to check and validate their accuracy and truthfulness. Furthermore, nothing in this project constitutes a solicitation for investment.

Any content produced by SL or developer resources that SL provides are for educational and inspirational purposes only. SL does not encourage, induce or sanction the deployment, integration or use of any such applications (including the code comprising the Solana blockchain protocol) in violation of applicable laws or regulations and hereby prohibits any such deployment, integration or use. This includes the use of any such applications by the reader (a) in violation of export control or sanctions laws of the United States or any other applicable jurisdiction, (b) if the reader is located in or ordinarily resident in a country or territory subject to comprehensive sanctions administered by the U.S. Office of Foreign Assets Control (OFAC), or (c) if the reader is or is working on behalf of a Specially Designated National (SDN) or a person subject to similar blocking or denied party prohibitions.

The reader should be aware that U.S. export control and sanctions laws prohibit U.S. persons (and other persons that are subject to such laws) from transacting with persons in certain countries and territories or that are on the SDN list. Accordingly, there is a risk to individuals that other persons using any of the code contained in this repo, or a derivation thereof, may be sanctioned persons and that transactions with such persons would be a violation of U.S. export controls and sanctions law.

linera-protocol

Sun, 21 Sep 2025 15:24:17 +0800

linera-io/linera-protocol

Linera is a decentralized blockchain infrastructure designed for highly scalable, secure, low-latency Web3 applications.

Documentation

Visit our developer page and read our whitepaper to learn more about the Linera protocol.

Repository Structure

The main crates and directories of this repository can be summarized as follows: (listed from low to high levels in the dependency graph)

linera-base Base definitions, including cryptography.
linera-version A library to manage version info in binaries and services.
linera-views A library mapping complex data structures onto a key-value store. The corresponding procedural macros are implemented in linera-views-derive.
linera-execution Persistent data and the corresponding logic for runtime and execution of Linera applications.
linera-chain Persistent data and the corresponding logic for chains of blocks, certificates, and cross-chain messaging.
linera-storage Defines the storage abstractions for the protocol on top of linera-chain.
linera-core The core Linera protocol, including client and server logic, node synchronization, etc.
linera-rpc Defines the data-type for RPC messages (currently all client ↔ proxy ↔ chain ↔ chain interactions), and track the corresponding data schemas.
linera-client Library for writing Linera clients. Used for the command-line client and the node service in linera-service, as well as the Web client in linera-web.
linera-service Executable for clients (aka CLI wallets), proxy (aka validator frontend) and servers.
linera-sdk The library to develop Linera applications written in Rust for the Wasm virtual machine. The corresponding procedural macros are implemented in linera-sdk-derive.
examples Examples of Linera applications written in Rust.

Prerequisites

See INSTALL.md for software requirements to develop in this repo.

Quickstart with the Linera CLI tool

The following commands set up a local test network and run some transfers between the microchains owned by a single wallet.

# Make sure to compile the Linera binaries and add them in the $PATH.
# cargo build -p linera-storage-service -p linera-service --bins
export PATH="$PWD/target/debug:$PATH"

# Import the optional helper function `linera_spawn`.
source /dev/stdin <<<"$(linera net helper 2>/dev/null)"

# Run a local test network with the default parameters and a number of microchains
# owned by the default wallet. This also defines `LINERA_TMP_DIR`.
linera_spawn \
linera net up --with-faucet --faucet-port 8080

# Remember the URL of the faucet.
FAUCET_URL=http://localhost:8080

# If you're using a testnet, start here and run this instead:
#   LINERA_TMP_DIR=$(mktemp -d)
#   FAUCET_URL=https://faucet.testnet-XXX.linera.net  # for some value XXX

# Set the path of the future wallet.
export LINERA_WALLET="$LINERA_TMP_DIR/wallet.json"
export LINERA_KEYSTORE="$LINERA_TMP_DIR/keystore.json"
export LINERA_STORAGE="rocksdb:$LINERA_TMP_DIR/client.db"

# Initialize a new user wallet.
linera wallet init --faucet $FAUCET_URL

# Request chains.
INFO1=($(linera wallet request-chain --faucet $FAUCET_URL))
INFO2=($(linera wallet request-chain --faucet $FAUCET_URL))
CHAIN1="${INFO1[0]}"
ACCOUNT1="${INFO1[1]}"
CHAIN2="${INFO2[0]}"
ACCOUNT2="${INFO2[1]}"

# Show the different chains tracked by the wallet.
linera wallet show

# Query the chain balance of some of the chains.
linera query-balance "$CHAIN1"
linera query-balance "$CHAIN2"

# Transfer 10 units then 5 back.
linera transfer 10 --from "$CHAIN1" --to "$CHAIN2"
linera transfer 5 --from "$CHAIN2" --to "$CHAIN1"

# Query balances again.
linera query-balance "$CHAIN1"
linera query-balance "$CHAIN2"

# Now let's fund the user balances.
linera transfer 5 --from "$CHAIN1" --to "$CHAIN1:$ACCOUNT1"
linera transfer 2 --from "$CHAIN1:$ACCOUNT1" --to "$CHAIN2:$ACCOUNT2"

# Query user balances again.
linera query-balance "$CHAIN1:$ACCOUNT1"
linera query-balance "$CHAIN2:$ACCOUNT2"

More complex examples may be found in our developer manual as well as the example applications in this repository.

Contributing

We welcome contributions from the community! If you’d like to contribute to the Linera protocol:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

For detailed guidelines, see our contribution guide.

monad

Fri, 19 Sep 2025 15:27:28 +0800

category-labs/monad

Monad Execution

Overview

This repository contains the execution component of a Monad node. It handles the transaction processing for new blocks, and keeps track of the state of the blockchain. Consequently, this repository contains the source code for Category Labs’ custom EVM implementation, its database implementation, and the high-level transaction scheduling. The other main repository is monad-bft, which contains the source code for the consensus component.

Building the source code

Package requirements

Execution has two kinds of dependencies on third-party libraries:

Self-managed: execution’s CMake build system will checkout most of its third-party dependencies as git submodules, and build them as part of its own build process, as CMake subprojects; this will happen automatically during the build, but you must run:
1

git submodule update --init --recursive
after checking out this repository.
System: some dependencies are expected to already be part of the system in a default location, i.e., they are expected to come from the system’s package manager. The primary development platform is Ubuntu, so the required packages use the Debian/Ubuntu package names; an up-to-date list of the required system dependencies can be found in the docker configuration file docker/release.Dockerfile (you will need all the packages installed via the apt install commands)

Minimum development tool requirements

gcc-15 or clang-19
CMake 3.27
Even when using clang, the only standard library supported is libstdc++; libc++ may work but it is not a tested platform

CPU compilation requirements

As explained in the hardware requirements, a Monad node requires a relatively recent CPU. Execution explicitly requires this to compile: it needs to emit machine code that is only supported on recent CPU models, for fast cryptographic operations.

The minimum ISA support corresponds to the x86-64-v3 feature level. Consequently, the minimum flag you must pass to the compiler is -march=x86-64-v3, or alternatively -march=haswell (“Haswell” was the codename of the first Intel CPU to support all of these features).

You may also pass any higher architecture level if you wish, although the compiled binary may not work on older CPUs. The execution docker files use -march=haswell because it tries to maximize the number of systems the resulting binary can run on. If you are only running locally (i.e., the binary does not need to run anywhere else) use -march=native.

Compiling the execution code

First, change your working directory to the root directory of the execution git repository root and then run:

1
2

CC=gcc-15 CXX=g++-15 CFLAGS="-march=haswell" CXXFLAGS="-march=haswell" ASMFLAGS="-march=haswell" \
./scripts/configure.sh && ./scripts/build.sh

The above command will do several things:

Use gcc-15 instead of the system’s default compiler
Emit machine code using Haswell-era CPU extensions
Run CMake, and generate a ninja build system in the <path-to-execution-repo>/build directory with the CMAKE_BUILD_TYPE set to RelWithDebInfo by default
Build the CMake all target, which builds everything

The compiler and CPU options are injected via environment variables that are read by CMake. If you want debug binaries instead, you can also pass CMAKE_BUILD_TYPE=Debug via the environment.

When finished, this will build all of the execution binaries. The main one is the execution daemon, build/cmd/monad. This binary can provide block execution services for different EVM-compatible blockchains:

When used as part of a Monad blockchain node, it behaves as the block execution service for the Category Labs consensus daemon (for details, see here); when running in this mode, Monad EVM extensions (e.g., Monad-style staking) are enabled
It can also replay the history of other EVM-compatible blockchains, by executing their historical blocks as inputs; a common developer workflow (and a good full system test) is to replay the history of the original Ethereum mainnet and verify that the computed Merkle roots match after each block

You can also run the full test suite in parallel with:

`1`	`CTEST_PARALLEL_LEVEL=$(nproc) ctest`

A tour of execution

To understand how the source code is organized, you should start by reading the execution developer overview, which explains how execution and consensus fit together, and where in the source tree you can find different pieces of functionality.

sui

Fri, 20 Jun 2025 15:30:47 +0800

MystenLabs/sui

Welcome to Sui

Sui is a next-generation smart contract platform with high throughput, low latency, and an asset-oriented programming model powered by the Move programming language.

Sui Highlights

Sui offers the following benefits and capabilities:

Unmatched scalability, instant settlement
A safe smart contract language accessible to mainstream developers
Ability to define rich and composable on-chain assets
Better user experience for web3 apps

Sui is the only blockchain today that can scale with the growth of web3 while achieving industry-leading performance, cost, programmability, and usability. As Sui approaches Mainnet launch, it will demonstrate capacity beyond the transaction processing capabilities of established systems – traditional and blockchain alike. Sui is the first internet-scale programmable blockchain platform, a foundational layer for web3.

Sui Architecture

  flowchart LR
    CC(CLI Client) --> ClientService
    RC(Rest Client) --> ClientService
    RPCC(RPC Client) --> ClientService
    ClientService --> AuthorityAggregator
    AuthorityAggregator --> AC1[AuthorityClient] & AC2[AuthorityClient]
    subgraph Authority1
      AS[AuthorityState]
    end
    subgraph Authority2
      AS2[AuthorityState]
    end
    AC1 <==>|Network TCP| Authority1
    AC2 <==>|Network TCP| Authority2

Sui Overview

Sui is a smart contract platform maintained by a permissionless set of authorities that play a role similar to validators or miners in other blockchain systems.

Sui offers scalability and unprecedented low-latency for common use cases. Sui makes the vast majority of transactions processable in parallel, which makes better use of processing resources, and offers the option to increase throughput with more resources. Sui forgoes consensus to instead use simpler and lower-latency primitives for common use cases, such as payment transactions and asset transfers. This is unprecedented in the blockchain world and enables a number of new latency-sensitive distributed applications, ranging from gaming to retail payment at physical points of sale.

Sui is written in Rust and supports smart contracts written in the Move programming language to define assets that may have an owner. Move programs define operations on these assets including custom rules for their creation, the transfer of these assets to new owners, and operations that mutate assets.

Sui has a native token called SUI, with a fixed supply. The SUI token is used to pay for gas, and is also used as delegated stake on authorities within an epoch. The voting power of authorities within this epoch is a function of this delegated stake. Authorities are periodically reconfigured according to the stake delegated to them. In any epoch, the set of authorities is Byzantine fault tolerant. At the end of the epoch, fees collected through all transactions processed are distributed to authorities according to their contribution to the operation of the system. Authorities can in turn share some of the fees as rewards to users that delegated stakes to them.

Sui is supported by several cutting-edge peer-reviewed studies and extensive years of open-source development.

More About Sui

Use the following links to learn more about Sui and the Sui ecosystem:

Learn more about working with Sui in the Sui Documentation.
Join the Sui community on Sui Discord.
Find out more about the Sui ecosystem on the Sui Resources page.
Review information about Sui governance, decentralization, and Developer Grants Program on the Sui Foundation site.

How to Contribute

See the Contributing Guide for details on how to contribute to Sui.

Code of Conduct

See the Code of Conduct for details on our code of conduct.

License

See the LICENSE file for more details.

deep-prove

Thu, 29 May 2025 15:30:17 +0800

Lagrange-Labs/deep-prove

🚀 DeepProve: Zero-Knowledge Machine Learning (zkml) Inference

Welcome to DeepProve, a cutting-edge framework designed to prove neural network inference using zero-knowledge cryptographic techniques. Whether you’re working with Multi-Layer Perceptrons (MLPs) or Convolutional Neural Networks (CNNs), DeepProve offers a fast and efficient way to verify computations without revealing the underlying data. zkml is the name of the subcrate implementing the proving logic.

🤔 What Does DeepProve Do?

DeepProve leverages advanced cryptographic methods like sumchecks and logup GKR to achieve sublinear proving times. This means you can prove the correctness of your model’s inference faster than ever before!

📊 Benchmark Highlights

CNN 264k: This runs a CNN on the cifar 10 dataset for a total of 264k parameters. DeepProve is proving 158x faster at this size! Dense 4M: This runs a multiple dense layers for a total of 4 million parameters. DeepProve is proving 54x faster at this size!

Model Type	ZKML Proving Time (ms)	ZKML Verification Time (ms)	EZKL Proving Time (ms)	EZKL Verification Time (ms)
CNN 264k	1242	599	196567.01	312505
Dense 4M	2335	520	126831.3	1112

📜 Licensing

zkml folder: Licensed under the Lagrange License, unless otherwise specified.
Rest of the Code: Licensed under Apache 2.0 + MIT, as per the original repository.

🌟 Use Cases

Proving inference of AI models has a wide range of applications, especially in scenarios where privacy and trust are paramount. For instance, in healthcare, sensitive patient data can be used to make predictions without exposing the data itself. In finance, models can be verified for compliance without revealing proprietary algorithms. Additionally, in decentralized applications, zero-knowledge proofs can ensure the integrity of AI computations on the blockchain, fostering trust and transparency. These use cases highlight the transformative potential of ZKML in various industries.

🙏 Acknowledgements

This project builds upon the work from scroll-tech/ceno, reusing the sumcheck and GKR implementation from their codebase. Check out their work at scroll-tech/ceno.

For more technical details and usage instructions, dive into the ZKML README.

Happy proving! 🎉