Getting Started with Solana (5)

• 
  ：区块分割及广播流程
  
• 不同于交易转发过程，此时Leader与Validator间的通信协议是UDP
• 不同于Ethereum，区块同步基于TCP协议 (具体而言，DevP2P协议)
• 由于远高于Ethereum的吞吐量，Solana的带宽需求 (~1 Gbps) 也高于Ethereum (~25 Mbps)
• 类似于Bitcoin、Ethereum，提案区块需要广播，被全网节点验证；Solana中，Leader广播提案区块至其余Validator，进行验证、投票、同步

• 
  Solana中，提案区块的广播过程被称为涡轮 (Turbine)
  
• Turbine灵感源自于BitTorrent；类似于BitTorrent，Turbin也将完整数据拆分为多个片段，并引入纠删码处理丢包 (Packet Loss) 等问题
• Turbine主要用来应对带宽资源稀缺问题，降低Leader的“出口压力 (Stress of egress)”，同时确保数据可用性 (Data Avaliability)；具体而言，就是保证各Validator能快速同步区块状态变化的同时，降低Leader及各中继节点处的通信压力

• 
  Turbine是一种多层 (Multi-layer) 区块广播机制，是一种结构化路由 (Structured Routing) 方法
  
• 全局路由表被组织为多叉树结构，Solana通过DATA_PLANE_FANOUT定义分叉数量，进而决定多叉树深度；多叉树深度决定了Block广播的路由跳数；目前，Solana中，DATA_PLANE_FANOUT=200
• 从最顶层根节点开始，不同中继节点 (Validators)，按其质押的代币比例，被分配至多叉树不同的层；比例越高，位置越靠上，从而能更快地同步状态并发起投票交易
• 作为多叉树的一个节点，各Validator无需泛洪，仅需遵循既定规则将数据传输给下一跳，称之为"Re-transmission"
• 这棵多叉树即被称为Turbine Tree；区块广播时，为尽量降低恶意中继节点的干扰，一个Shred对应一个全新的Turbine Tree
• 
  不同于Bitcoin、Ethereum，Solana中，Leader不会广播完整的Block，而是广播分割后的碎屑 (Shreds)
  
• RS码是一种前向纠错 (Forward Error Correction，FEC) 编码
• 基于RS码，拆分Block得到的多个Shreds包含个Data Shreds以及个Coding Shreds (又称为Recovery Shreds)；前者存储序列化的交易内容，后者则由RS编码生成，负责实现数据恢复；、间的比例被称为FEC Rate
• Shreds传输过程中会发生丢包 (Packet Loss)，且路由跳数越多，丢包概率越大；Leader需要根据全球路由表 (更具体而言是Turbine Tree的深度) 动态调整FEC Rate；一般跳数越多，就越大
• 基于Reed-Solomon (RS) Coding，一个Block被拆分为多个Shreds，每个大小约为1280 Bytes，该过程被称为Sherding

• Solana目前采用的FEC Rate为32：32，即32个Data Shreds，32个Coding Shreds
• 设定DATA_PLANE_FANOUT=200时，Shreds传输一般经历2~3 Hops；此时，32：32的FEC Rate可提供99%的传输成功率
• 1280 Bytes被称为最大传输单元 (Maximum Transmission Unit，MTU)，即能直接在Validator间传输、且不会被分割为更小数据片段的最大数据量
• Leader传输Shred前需要对其签名

• 
  每个Shred分为三部分
  
• General Header (或Common Header)：包含签名、Shred类型、Shred索引、对应Slot序号等
• Data Header/Coding Header：Data Shred对应Data Header，包括Parent Offset、Size等；Coding Header对应Recovery Shred，包括两类Shred的数量、Coding Shred在FEC Group中的索引等
• Payload：序列化的交易数据或用来检、纠错的冗余数据
• 
  Turbine Tree构建及刷新流程
  
• 【创建Validator列表】根节点将所有Validator聚合至一个列表，继而基于各Validator质押的代币比例从低到高排序，比例越高越靠前
• 【列表混淆 (List Shuffling)】根节点按确定性规则 (Determinstic manner) 混淆已排序列表，基于随机数种子 (Seed) 为每一个Shred生成对应的Turbine Tree；Seed来自于Slot Leader的地址/ID、Slot序号、Shred的索引及类型等；Turbine Tree按DATA_PLANE_FANOUT分层
• Leader广播Block时，针对每一个Shred，首先发送至根节点，再依据对应的Turbine Tree，自下而上逐层转发
• 一旦某个Validator处出现无法依赖FEC恢复的错误，则通知Leader或周围节点进行重新传输

Reference

• https://blocksec.com/blog/solana-simplified-master-solana-core-concepts-in-one-read
• https://blocksec.com/blog/solana-simplified-02-writing-your-first-solana-smart-contract-from-scratch
• https://blocksec.com/blog/solana-simplifed-03-understand-solana-transactions-in-5-minutes
• https://explorer.solana.com/address/9wQQZPeLjnPQhMURKdEX3xFgiVqPPt9oBRD35BWDvHa3?cluster=devnet
• https://faucet.solana.com/
• https://app.blocksec.com/explorer/tx/solana/byRn8qtNAYSdvgaGCK4kmZV1m89b7uuFuy1cn96W6femp7WgwymLqJ2MP9hPbegqN9EPe7NvghWpqDFqoCDjKph
• https://beta.solpg.io/
• https://rareskills.io/post/spl-token
• https://rareskills.io/post/solana-instruction-introspection
• https://rareskills.io/post/solana-sysvar
• https://www.helius.dev/blog/proof-of-history-proof-of-stake-proof-of-work-explained
• https://www.helius.dev/blog/solana-executive-overview#consensus
• https://www.helius.dev/blog/how-to-land-transactions-on-solana#how-are-transactions-processed
• https://www.helius.dev/blog/solana-nodes-a-primer-on-solana-rpcs-validators-and-rpc-providers#solana-node-requirements
• https://www.quicknode.com/guides/solana
• https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana
• https://www.helius.dev/blog/solana-gulf-stream
• https://4pillars.io/en/articles/make-svm-great-again
• https://www.helius.dev/blog/turbine-block-propagation-on-solana
• https://www.helius.dev/blog/solana-commitment-levels
• https://www.helius.dev/blog/consensus-on-solana