每晚八点，我们在社区分享知识，等你。
NervosFans 微信公号：Nervosfans
入群请加乐乐微信：sensus113 美果大冰微信：xj73226
备注入群，谢谢！
简介
本文旨在为希望了解分片提案细节并实施的人提供合理完整的规范及介绍。文中仅对二次分片的“第1阶段”进行了描述；第2、3、4阶段暂不做讨论，超二次分片（“以太坊3.0”）也暂不做讨论。
假设变量c表示单个节点的计算能力水平。简单的区块链中，交易容量受O（c）限制，因为每个节点都必须处理每笔交易。二次分片的目标是借助双层设计增加容量。第1阶段无需硬分叉，主链保持不变。 但是会发布一个验证人管理器合约（validator manager contract）到主链，用来维护分片系统。分片数量为O（c）（目前O（c）= 100），每个分片像是个单独的“星系”：有自己的帐户空间，交易需要指定在哪个分片中发布，且分片间通信非常有限（第1阶段的通信其实是不存在的）。
分片在一个简单的最长链规则PoS系统上运行，权益在主链上（确切说是在VMC内）。所有分片共享一个验证池；这也意味着在VMC上注册验证人的人理论上能在任意时间被赋予在任意分片上创建区块的权利。每个分片的块大小/gas上限为O（c），因此系统的总容量为O（c ^ 2）。
分片系统的大部分用户将运行（i）主链上的全（O（c）资源需求）或轻（O（log（c））资源需求）节点，以及（ii）通过RPC与主链对话的“分片客户端”（姑且视客户端可信，原因是客户端也在用户计算机上运行），且可作任意分片的轻客户端，特定分片的全客户端（用户须指定自己“正在观察”的特定分片）或验证人节点。（i）或（ii）情形下，分片客户端的存储和计算要求不会超过O（c）（除非用户指定自己正在观察每个分片；一般区块浏览器以及大型交易所可能会需要这么做）。
文中‘Collation（理序）’一词用于区别Block，原因是（i）不同的RLP对象：交易为0级对象，理序为打包交易的1级对象，block为打包理序（区块头）的2级对象；（ii）分片语境下表达更清晰。基本上，理序必须包含CollationHeader和TransactionList；见证人和Collation的详细格式将在无状态客户端部分定义。整理人（Collator）指主链验证人管理合约中getEligibleProposer函数采样的理序提议者； 下文会对机制做出介绍。
二次分片
常量
· LOOKAHEAD_PERIODS（前瞻期）: 4
· PERIOD_LENGTH（周期长）: 5
· COLLATION_GASLIMIT（整理gas上限）: 10,000,000 gas
· SHARD_COUNT（分片计数）: 100
· SIG_GASLIMIT（签名gas上限）: 40000 gas
· COLLATOR_REWARD（整理人奖励）: 0.001 ETH
验证人管理器合约（Validator Manager Contract /VMC）
假设VALIDATOR_MANAGER_ADDRESS（现有“主分片”上）地址上有VMC，支持以下功能：
· deposit() returns uint256：在验证人集中添加验证人，验证人大小为函数调用中的msg.value（即已存入ETH数量）。此函数返回验证人索引。
· withdraw(uint256 validator_index) returns bool：验证msg.sender == validators [validator_index] .addr是否从验证人集中删除验证人并退还存入的ETH。
· get_eligible_proposer(uint256 shard_id, uint256 period) returns address：用区块哈希作种子伪随机的从验证人集中选出签名人。被选中的几率应与验证人存款数量成正比。函数应能为现行周期或未来LOOKAHEAD_PERIODS个周期返回一个值。
· add_header(uint256 shard_id, uint256 expected_period_number, bytes32 period_start_prevhash, bytes32 parent_hash, bytes32 transaction_root, address coinbase, bytes32 state_root, bytes32 receipt_root, uint256 number) returns bool：尝试处理collation header；成功时返回True，故障时恢复。
· get_shard_head(uint256 shard_id) returns bytes32：返回header哈希，即管理器合约认为的给定分片的头部。
还有个log类型是：
· CollationAdded(indexed uint256 shard_id, bytes collation_header_bytes, bool is_new_head, uint256 score) 其中collation_header_bytes在Vyper中可构建成：
注意：coinbase和number被重命名为collation_coinbase和collation_number，因为它们是vyper中的保留关键字。
Collation header
首先，将“collation header”定义成一个带以下值的RLP列表：
其中：
· 指分片的ID；
· expected_period_number指collation预计被包含的周期编号；根据period_number = floor(block.number / PERIOD_LENGTH)计算出；
· period_start_prevhash指
· PERIOD_LENGTH * expected_period_number – 1块的区块哈希（即预计周期开始前最后一个块的哈希）。分片中代表区块数据的操作码（即如NUMBER、DIFFICULTY）代表的是本区块的数据，除了COINBASE，它指代的是本分片的coinbase；
· parent_hash指父理序的哈希；
· transaction_root指保存本理序中包含交易的特里结构根哈希；
· state_root指本理序后分片的新状态根；
· receipt_root指收据特里结构跟哈希；
· number指理序编号，也是分叉选择规则的指数，且
调用add_header(shard_id, expected_period_number, period_start_prevhash, parent_hash, transaction_root, coinbase, state_root, receipt_root, number)时返回true，则collation header有效。以下情形时，验证人管理器合约应调用：
· shard_id不小于0，不大于SHARD_COUNT；
· expected_period_number等于现行周期编号（即floor(block.number/PERIOD_LENGTH)）
· 相同分片带parent_hash哈希的collation已被认可；
· 相同分片的理序在现行周期中暂未被提交；
· add_header发送人地址等于get_eligible_proposer(shard_id, expected_period_number)函数返回的地址。
当（i）其collation header有效；（ii）在给定state_root和receipt_root中parent_hash的state_rootresults之上执行collation；以及（iii）消耗的总gas小于或等于COLLATION_GASLIMIT时，collation有效。
理序状态迁移函数
执行collation的状态迁移过程如下：
· 按顺序执行transaction_root指向的树中的每笔交易；及
· 将COLLATOR_REWARD奖励分配给coinbase。
getEligibleProposer细节
以下是Viper中的一个简单实现：
无状态客户端
需要验证人在给定分片上创建区块时，会提前几分钟通知（确切地说几分钟=LOOKAHEAD_PERIODS * PERIOD_LENGTH个块的时间）。Ethereum 1.0中，创建区块时为验证交易需要访问整个状态。分片中，我们的目标是不要求验证人存储整个系统的状态（相当于O（c ^ 2）的计算资源要求）。相反，允许验证人创建只知道状态根的理序，将提供“见证人数据”（即Merkle分支）、证明受交易影响帐户的交易前状态、提供足够信息计算交易执行后交易后状态根的责任推给交易发送方。
（注意，非无状态范例中实现分片理论上是可行的；但是需要：（i）存储租金来限制存储大小；以及（ii）分配验证人在单个分片中创建O（c）时间的区块。）
数据格式
修改交易的格式，要求交易必须指定一个access list，枚举自己可以访问的状态部分（这点稍后会做更准确地描述；现在姑且将其视为地址列表）。VM执行期间，尝试读取或写入交易指定访问列表之外任何状态的操作都会返回错误。这么做是为了防止有人发动这样的攻击：发送一笔在随机执行时消耗500万个gas周期的交易，随后试图访问交易发送方和整理者没有见证人的随机账户来阻止整理者包含交易，白白浪费掉整理者的时间。
签名交易主体之外，但是与交易一起打包，交易发送方还必须指定“见证人”，即RLP编码的Merkle树节点列表，列表提供了交易在其访问列表中指定的状态部分。这样一来，整理者仅凭状态根即可处理交易。发布理序时，整理者还会为整个理序发送见证人。
交易包格式
理序格式
见：无状态客户端概念（The Stateless Client Concept）。
未完待续。
https://github.com/ethereum/sharding/blob/develop/docs/doc.md
网友评论