Solana became well-known for its exceptional performance among Layer 1 blockchains by making significant trade-offs and departing from many conventional blockchain designs. Moreover, Solana benefits from a distinctive advantage in the communication field thanks to the background of its co-founders. Consequently, Solana has successfully implemented multiple optimizations on its messaging layer.
Recap of the Previous Architecture
PoH: The Starting Point
When discussing Solana, it is important to consider PoH, as the following features are all designed to coordinate with it.
Many people may think of PoH as a new consensus algorithm, but in reality, PoH is not a consensus mechanism. Instead, it acts as a clock that operates before consensus. The PoH clock allows the leader validator to bypass the need for a global consensus on the timestamp and sequence of transactions, thus enabling faster transaction execution.
Essentially, PoH is a specialized Verifiable Delay Function (VDF) that can handle high-frequency calculations. For those unfamiliar with VDF, it is a function that requires a specific number of sequential steps for evaluation, and the result can be efficiently verified. VDFs are commonly used to measure duration. In the case of PoH, its hash chain includes hashes of any data observed by the application, ensuring that the data existed before the subsequent hashes. An important aspect of VDFs is their ability to convert large inputs into fixed outputs.
In practice, the leader timestamps transactions, allowing validators to retrieve the public key of the designated leader. The leader then signs the timestamp, enabling validators to verify the signature and confirm that the signer is the owner of the designated leader's public key. Users can then send transactions to the designated validator.
Each block includes cryptographic proof, which allows anyone to verify that a certain amount of time has elapsed since the last proof. All data hashed into the proof has undoubtedly occurred prior to the generation of the proof. There is no specific time requirement for when this block reaches each validator, as it may arrive in any order or even be replayed years later.
Tower BFT: Optimized Version of PBFT for PoH
Solana uses Tower BFT as its consensus algorithm, which is an optimized version of PBFT designed specifically for Proof of History. Similar to traditional PBFT, the active set of validators consists of all staked accounts with leader identities that have voted within a cluster-configured number of ticks. The leader schedule for each epoch is calculated based on the ledger state at the beginning of the previous epoch.
Tower BFT has a few notable differences compared to other PBFT algorithms. Thanks to the Proof of History clock, Tower BFT doesn't require all validators to agree on a newly produced block before moving on to the next one. Instead, the next slot leader can directly build on top of the current slot leader. Another significant difference is that voting messages are treated as transactions in Solana. This design choice is what enables Solana to achieve nearly 90% of the TPS (transactions per second) observed on its network. The actual TPS is approximately 400, which is quite impressive when compared to other Layer 1 protocols.
Mempool-Less Transaction Forwarding
The unique design of Solana allows for efficient transaction processing through a pre-decided leader validator set and the separation of consensus and execution. Unlike other protocols, such as Ethereum, Solana does not rely on a mempool for transaction propagation. Instead, all transactions, whether initiated programmatically or by end-users, are promptly routed to leaders for inclusion in blocks.
With this mempool-less approach, the lifecycle of a transaction in Solana is significantly shorter compared to traditional blockchains. This eliminates gossip time and inherently improves the overall efficiency of the process.
Turbine Block Propagation
Solana introduces turbine block propagation to enhance efficiency in node communications. Unlike traditional gossip networks, transactions are divided into batches, enabling a node to send transactions to multiple parties without generating multiple copies.
Solana validators organize transactions into smaller batches known as "entries." In a network with 15 validators, if the fanout size is set to 3, the leader node initially broadcasts to a special root node located at the top of the turbine tree. The root node then shares the data with 3 nodes in the first layer. Nodes in this layer further transmit the data to a subset of nodes in the next layer. This process continues, with each node in a layer retransmitting to a unique subset of nodes in the next layer, until all nodes in the cluster have received all the data shreds.
This approach reduces communication costs and enhances the efficiency of block propagation in the Solana network.
Alpenglow: Increase Bandwidth Reduce Latency
Anza research (Professor Roger Wattenhofer and two of his recent PhD students, Kobi Sliwinski and Quentin Kniep, from ETH Zurich (Eidgenössische Technische Hochschule Zürich) in Switzerland), a recently established branch of Solana Labs, has unveiled Alpenlow, a groundbreaking consensus protocol poised to replace the existing system. Named after the atmospheric phenomenon of a rosy glow on alpine peaks, Alpenlow promises significant advancements in latency, security, and overall protocol elegance. This report provides a comprehensive overview of Alpenlow's key features, its underlying design principles, and the projected roadmap for its implementation.
Practical and Aggressive: The "20% + 20%" Model
Alpenlow introduces a sophisticated security model that rethinks the traditional approach to Byzantine Fault Tolerance (BFT). Instead of a single threshold for all types of failures, Alpenlow differentiates between malicious actors and non-malicious failures, such as power outages or network interruptions. This innovative "20% + 20% security" model is designed to provide robust protection against a combination of threats.
The protocol is engineered to withstand up to 40% of the network experiencing a combination of malicious and non-malicious failures. This is a significant increase from the standard 33% BFT, which typically only accounts for malicious attacks. The underlying philosophy is that malicious attacks are rare and can be penalized, allowing for a more nuanced and resilient security posture.
The Elegance of Simplicity: A Streamlined Protocol
A core tenet of Alpenlow's design is simplicity. A more streamlined protocol is not only more efficient but also inherently faster. To achieve this, several key components of the current Solana architecture have been removed or fundamentally redesigned:
- Removal of Tower BFT: The existing Tower BFT consensus protocol will be completely deprecated.
- Elimination of Proof of History (PoH): In a significant departure, Proof of History will be replaced by system timeouts, simplifying the timekeeping mechanism.
- Direct Communication Over Gossip: While the gossip protocol may still have a role, Alpenlow will prioritize direct communication between nodes for consensus, reducing unnecessary network chatter.
In place of these removed components, Alpenlow introduces two new protocols: Rotor and Voter.
The Engines of Alpenlow: Voter and Rotor
Rotor: The Data Dissemination Powerhouse
Rotor is a revamped version of the Turbine protocol, serving as the primary mechanism for data dissemination. The key innovation in Rotor is its single-layer design. In this model, the leader node directly sends erasure-coded slices of a block to all relay nodes in a pipelined fashion. This direct-to-all approach is incredibly fast, with the data dissemination process expected to take only a few milliseconds. To incentivize nodes to handle the high bandwidth required for this, a reward system is also being planned.
Turbine features a technique where each block is erasure-coded into many smaller pieces which can be disseminated rapidly.
Rotor utilizes the bandwidth of participating nodes proportionally to their stake, alleviating the leader bottleneck for high throughput, total available bandwidth is used asymptotically optimally.
Rotor features a single layer of relay nodes, as opposed to the multi-layer tree of Turbine. In this way, Rotor minimizes the number of network hops. Moreover, Rotor introduces new techniques to determine the relay nodes, resulting in improved resilience.
Voter: A Modernized Voting Mechanism, takes over the voting and block finalization logic.
Voter is an entirely new voting protocol based on cutting-edge academic research. Its operation is elegantly simple:
- Nodes use system timeouts to determine if a block was received in a timely manner.
- Based on this, they cast a "good" or "bad" vote.
- These votes are broadcast to the entire network.
The decision-making process is swift and decisive:
- If a block receives "yes" votes from at least 80% of the stake, it is immediately finalized in a single round, in two rounds if only 60% of the stake is responsive.
- These two voting modes are integrated and performed concurrently, such that finalization happens as soon as the faster of the two paths terminates.
The correctness of the Voter protocol is rigorously backed by a detailed academic paper with mathematical proofs, ensuring its reliability and security.
Voting messages: BLS signatures data into UDP
Optimistic Confirmation
With TowerBFT, Solana had about 12.8 sec from block creation until block finality.
Alpenglow can achieve actual finality in about 150 ms (median). Sometimes finality can be achieved as fast as 100 ms, which is an unbelievably low number for a world-wide L1 blockchain protocol.
Solana can compete with Web2 infrastructure in terms of responsiveness, potentially making blockchain technology viable for entirely new categories of applications that demand real-time performance.
- Network Latency: about 65% of Solana's stake is within 50ms network latency of Zurich. The long tail of stake has more than 200ms network latency from Zurich.
- Rotor: The yellow bars show the delay incurred by Rotor, the first stage of our protocol.
- Notarization: The red bars mark the time when a node has received notarization votes from at least 60% of the stake.
- Finalization: Finally, the blue bars show the finalization time.
Unprecedented Performance: Sub-Second Finality
A primary driver behind the development of Alpenlow is the quest for reduced transaction finality time. While Solana already boasts high transactions per second (TPS), the Anza team aimed to drastically cut down the time it takes for a transaction to be irreversibly confirmed on the network.
Through extensive simulations, Alpenlow has demonstrated a median finality of approximately 150 milliseconds. This is a remarkable improvement, positioning Solana to be significantly faster than competing blockchains, some of which claim finality times in the range of 400 milliseconds. It's crucial to note that this is full and final confirmation, not merely an optimistic confirmation that could be subject to later reversal.
In terms of bandwidth, while the existing Turbine protocol is considered near-optimal, Alpenlow is expected to offer slight improvements. The main focus, however, remains firmly on latency reduction.
The Road Ahead: Development and Deployment
Alpenlow is currently in its official reveal phase. The Anza research team is now moving into a period of extensive testing to ensure the protocol's stability and performance in real-world conditions. The projected timeline for the deployment of Alpenlow is towards the end of the current year or early next year. This phased and cautious rollout underscores the commitment to a secure and seamless transition for the Solana network.
In conclusion, Alpenlow represents a significant leap forward for the Solana blockchain. Its focus on drastically reduced latency, a more nuanced and robust security model, and a simplified and elegant protocol design promises to deliver a more performant and resilient network for users and developers alike.
Launchpad War
IBRL: Increase Bandwidth Reduce Latency
On-chain token distribution and liquidity bootstrapping platform.
Two Phases:
- Initial token distribution period: collect capital that will be deployed for on-chain liquidity, and optionally for the team raising to fund operations, with Dutch auction, fixed price FCFS, permissioned choices
- mix-and-match components, based on the goals of the distribution, amount allocated to Gavel’s mechanisms, etc.
- Sandwich-resistant AMM: After the public sale has ended, liquidity is added to Gavel's AMM using the remaining token inventory, and a portion of the SOL that was collected. The amount of SOL is chosen to ensure that the opening price on the AMM matches the public sale clearing price.
- Transient Liquidity: On a fixed schedule, it withdraws a portion of the liquidity, swaps it for the coin, and burns the coin. The schedule is configurable.
$IBRL: is a test token that exists solely to demonstrate the Gavel protocol in production. The token has no present or future utility.
-
700,000,000 is distributed through a 24-hour public sale.
- Fixed window: the sale runs for a set duration, finishing at a pre-set slot
- Fixed supply: a pre-set amount of the total supply is up for sale
- Fair distribution: participants receive token allotment proportional to their share of the total funds collected, with no limit on how much they can deposit
-
300M tokens are deposited into the Gavel AMM, paired with 3/7 of the SOL collected during the public sale.
-
Transient: Autonomous Wallet
- 3/7 go to Liquidity
- 4/7 go to Burn Mechanism
- 1 bp per 1000 slots, beginning immediately after trading goes live on the AMM
- Actually 6~7 mins per transaction
- 240 per day, 6000(~50day) halving
- 240 per day, 6000(~50day) halving
-
Token Holdings
- Burned Address: 27.2%
- Burn Account Holdings: 5.94K Sol, 928K
- These KOL hold two many bags
-
Basically
- Buy back the 100% token with 70% raised Sol
- The public is a opportunity to arbitrage, could make money in most cases
- Sell out slowly, because the buyback and burn mechanism progress slowly
Believe: Internet Capital Market, Leading Meteora
- Meteora Dynamic Bonding Curve
- Fee scheduler: Timestamp based fees, such as high fees at launch before dropping over time, in order to deter snipers
- Dynamic Fee: Volatility-based fee, to capture more fees during high volume/volatility periods, which helps maximize yield for LPs while protecting against sniper activity
- Configurations:
pool_fees
: includebase_fee
anddynamic_fee
(optional). Partner can add fee scheduler inbase_fee
or just a fixed fee.pool_fees
defines the trading fee for any pool that is created from this configuration.collect_fee_mode
(0 | 1
):0
means the virtual pool will only collect fee in quote token,1
means virtual pool will collect fee in both tokens.migration_option
: right now we only support migration to Meteora DAMM, so partner must set the value as0
for this field.activation_type
(0 | 1
):0
means slot,1
means timestamp, this field indicates the time unit that pool will work with, mostly in calculating fee scheduler and dynamic fee.token_type
(0 | 1
):0
means SPL Token,1
means Token2022.token_decimal
: the token decimals that the token will use when user creates the virtual pool with this configuration, we only support token decimals from 6 to 9.partner_lp_percentage
: the percentage of LP that partner can claim after token is migrated.partner_locked_lp_percentage
: the percentage of LP that partner will locked after token is migrated.creator_lp_percentage
: the percentage of LP that creator can claim after token is migrated.creator_locked_lp_percentage
: the percentage of LP that creator will be locked after token is migrated.migration_quote_threshold
: the threhold for quote token, that after virtual pool reserve get such quote token amount, the token will graduate from the launch pool and will be migrated.fee_claimer
: the address of partner that can claim trading fees from the virtual pools as well as fees from the locked LPs.owner
: owner of the configuration.quote_mint
: the quote mint address that virtual pool will support.locked_vesting
: locked vesting for creator after token is migrated (token will be migrated to Jup lock)migration_fee_option
: allow partner to choose a fee option on graduated pool (currently support 0.25% | 0.3% | 1% | 2%)token_supply
: when the fields are specified, token will have fixed supply in pre and post migration, leftover will be returned to leftover_receiver (configured in config key)sqrt_start_price
: square root of min price in the bonding curve for the virtual pools.curve
: an array of square price and liquidity, that defines the liquidity distribution for the virtual pools.
- At Migration
- 360M Tokens
- 190 Sol
- Fees
- Each transaction incurs a 2% fee
- Fees are split 70/30 between the creator and Believe, with fee claiming beginning once coin graduates
- Believe Capital:
- Strategic investment and founder support for the Believe ecosystem
- Positioning for Start-up, memecoins also involved, not a direct competitor for pump.fun
- Launchcoin itself is the largest mindshare
- Overall survival is pretty low, <0.5%
- The ecosystem status
- Snippers hunted lots of tokens
- The token is purely ICO for startups, few of them has utilities, not to mention buyback
- Selling the influence and resources
- Key KOLS: Ben Pasternak, @pasternak
WaterMinder
- Track daily water, Apple Editors' Choice
- Application is great, but no token utility so far
- Link: WaterMinder - best water tracker app for your hydration needs!
PCLUE: Polymarket Telegram Trading Bot
- PCULE tokens are held in Solana wallet to determine fee tier
- 30% of all trading fees collected by the platform will be used to purchase PCULE tokens from the open market. Buybacks are automatically triggered once accumulated fees reach 10,000 USD, creating natural buy pressure based on actual platform usage.
- Link: @polycule_trade_bot
PCULE Required | Fee Rate |
---|---|
0 | 1.00% |
10,000 | 0.95% |
25,000 | 0.90% |
50,000 | 0.85% |
100,000 | 0.80% |
250,000 | 0.75% |
500,000 | 0.70% |
1,000,000 | 0.65% |
2,500,000 | 0.60% |
5,000,000 | 0.55% |
10,000,000+ | 0.50% |
AIXBC
- On-Chain VC
- General Partner
- @fiiishcake
- @Kevin
- Head of DeFi Ecosystem Binance
- Head of Ecosystem, Mode at the same time
- Launch Execution
- Launch between 10am-8pm ET(10pm~8am for UTC+8)on Monday-Thursday for optimal attention
- Deploy from the account with fewer followers and RT it from your main
- This avoids snipers that dump on true supporters
- Immediately upon launch, can quote-tweet the launch post from main
- Be sure main account follows the smaller one after you launch
- Token Utility: 1M and 10M Private Telegram Group
- Incubation
- Strategic Capital - Direct investment in promising Believe ecosystem projects
- Founder Resources - Access to Believe University modules, proven playbooks, and launch frameworks
- Expert Community - Connect with successful founders, industry experts, and our 1000+ member network
- Ongoing Support - Continued guidance and resources as you scale your project
Bonk: Flipping Pump, Leading Raydium
-
Raydium LaunchLab combines the simplicity of a bonding curve with the power of Raydium's AMM infrastructure, offering:
- Quick and free launches: Anyone can launch a token, for free.
- No-code interface: Use default settings in JustSendit mode, or customize in LaunchLab mode.
- Familiar format: Users buy on a bonding curve and liquidity is migrated to a Raydium AMM pool.
- Liquidity locking: Post-migration liquidity is locked or burned to ensure long-term integrity.
- Community pool: 50% of trading fees go back to the community
- Creator incentives: Launch creators can earn trading fees from AMM liquidity.
-
At migration
- 85 SOL
- 206M Tokens
-
Fees: 1% fees, 24h fees 1.24m
-
Clear Tokenomics and Utility
- 🔥 Buy/Burn: Revenue is used to purchase BONK tokens from the open market and burn them, reducing the total supply.
- 💰 BONKsol Staking: Revenue is allocated to buying BONKsol, keeping the SOL within the ecosystem and securing the network.
- 🌱 SBR: Revenue supports SBR initiatives, contributing to the broader ecosystem growth.
- 🔐 BonkRewards: Allocated for user rewards and incentives within the BONK ecosystem.
- 📢 Marketing: Dedicated to promoting the platform and expanding user adoption.
- 🔧 Tech Dev/Operations: Reserved for $GP reserve, Hiring/Growth and Development/Integration.
-
Token Launches
-
Tech and Memes
-
Hackathon
-
Community: Chinese -> South Korea
-
Key Roles
- BONK创始人@SolportTom
- 42cfcPtPRHN6YQkWMzFhD9N67XWNZnAARYdMoR7RjsLX
- BONK联创@TheOnlyNom
- 4ZjYSCH3Sib9iMSM3QN2sL2kwxNcXG2P4XCemSC2hsyb
- Primitive Ventures 创始人
- 6ALGMay8AmcywGAX72ho7JbSucD7zeh4hwMVyXDb9zgy
- Bonk Guy @theunipcs
- 5M8ACGKEXG1ojKDTMH3sMqhTihTgHYMSsZc6W8i7QW3Y
- BONKINU 核心贡献者 @iamkadense
- EHEyxyKa2QfLBVqjViHGKNxWy1YTFa51r3Bui27ctT67
- BONK创始人@SolportTom