交付键放置与查找的迁移证书
键放置与分布式查找路线最后交付三份可重算记录：环上哪些键改变owner、稳定评分哪些排名改变、局部指表如何找到全局定义的owner。下载标准库核验器，普通和python -O都执行显式检查，只把JSON写到标准输出。
一、先声明配置身份
把空间固定为0,…,31，每个坐标放一把身份不同的键。所有节点使用同一份键坐标、token坐标、owner映射、破同值规则与配置版本。这里的键坐标是测试输入，不用运行一次不可重放的随机散列来代替手算表。
配置改变时，旧token和键坐标保留。跨配置比较的是物理owner：两个不同token可以指向同一机器，不能只因token编号变化就把它记成跨机器搬迁。空配置、重复token坐标、重复成员身份分别明确拒绝。
二、提交环的两个精确差集
初始A@1、B@8、C@16、D@24。每个坐标归顺时针第一个不小于它的token；超末尾绕回1。
| 配置 | A的键 | B的键 | C的键 | D的键 | E的键 |
|---|---|---|---|---|---|
| 初始 | 25,…,31、0、1 | 2,…,8 | 9,…,16 | 17,…,24 | 无成员E |
| 加入E@12 | 不变 | 不变 | 13,…,16 | 不变 | 9,…,12 |
| 随后删除B@8 | 不变 | 无成员B | 不变 | 不变 | 2,…,12 |
数量依次是(9,7,8,8)、(9,7,4,8,4)、(9,0,4,8,11)，每行总数32。第一次差集只有9、10、11、12，旧owner全为C，新owner全为E。第二次差集只有2,…,8，旧owner全为B，新owner全为E。
请给出两个范围证明：加入只把旧(8,16]分成(8,12]与(12,16]；删除B只把它原(1,8]交给后继E。含右端的约定使键12归E、键16仍归C；环首尾使键31归A。若这些边界对不上，不应靠调整数量总和掩盖错误。
第一份实际迁移率4/32不是1/5。后者来自新旧随机token共同取期望的理想模型，不要求任何固定32位置配置都恰好达到。请再选择一处不同空位加入E，观察移动区间大小变化，同时保持“没有旧节点之间互换键”的确定性性质。
三、虚拟节点与尚未完成的数据交接
另从空系统初始化八个token：A@1/17、C@5/21、B@9/25、D@13/29。八个负责段各含4个坐标，四台机器各8把键。这里没有声称可以把上节现网旧坐标随意改成新表而免搬迁。
把某一把键的请求量设成1000次，其余31把各1次。总计1031次，即使每台仍8把键，热点owner至少承担1000次。报告必须把键数与请求量分列；添加其它token不会自动拆开一把热键。
再执行一个故意未完成的交接：C仍存键10的值v10，公布E@12之后E的存储仍空。放置函数返回E正确，但E没有v10。记录这个反例，说明迁移清单只告诉系统需要搬哪些数据，没有证明数据已落盘、旧写已隔离或新配置已经安全对外生效。
若选三个后继token做候选副本，先投影到物理owner去重；同一机器的两个token不能当作两次独立故障容忍。机架、供电域和实际复制确认留给相应协议合同。
四、按稳定分数重算HRW
固定下面评分，分数高者优先，并列节点名A<B<C<D<E。旧成员为A/B/C/D。
| 键 | A | B | C | D | 加入E的分数 |
|---|---|---|---|---|---|
| alpha | 90 | 20 | 70 | 40 | 75 |
| beta | 30 | 80 | 60 | 20 | 81 |
| gamma | 10 | 50 | 95 | 40 | 10 |
| delta | 70 | 60 | 20 | 85 | 90 |
| epsilon | 40 | 30 | 60 | 55 | 59 |
| zeta | 65 | 65 | 10 | 50 | 65 |
旧owner依次A、B、C、D、C、A。加入E后变A、E、C、E、C、A，所以只有beta、delta迁移。zeta的A/B/E同为65，既定全序仍取A；把输入成员列表倒序，结果必须不变。
独立回到旧四成员，再删除C。owner变A、B、B、D、D、A，只有gamma和epsilon改变。逐键提交完整排名再取top-2，例如alpha原为A/C，删C后A/D：主owner未变不代表候选副本集未变。
迁移性质只要求所有幸存节点的相对评分和破同值次序保持。请制造一个错误版本：加入E后用新成员总数重新计算全部分数，或者用成员列表下标作身份。此时可能出现原A的键转投旧B，已不受HRW稳定性证明保护。
概率报告另外写前提：独立同分布连续分数使新节点成为第一名的概率为1/(N+1)，进入top-r概率为r/(N+1)。固定六键表是精确例子，不是验证随机函数独立性的统计证据。容量2:1也不能直接比较2U_A与U_B来实现，因为这会给A获胜概率3/4，而非2/3。
五、从局部指表求同一个后继
换到仍为32位置、成员1/4/8/14/21/28的稳定环。每节点保存自己的严格后继，以及五项finger[i]=successorKey(u+2^i mod32)。完整表见Chord页和JSON的network字段；查找核心不读取全表来代替转交。
提交以下五次执行：
| 起点 | 键 | 实际处理节点 | 返回owner |
|---|---|---|---|
| 4 | 31 | 4→21→28 | 1 |
| 1 | 27 | 1→21 | 28 |
| 28 | 0 | 28 | 1 |
| 14 | 14 | 14 | 14 |
| 8 | 3 | 8→28→1 | 4 |
每次转交都保存当前successor、候选finger、顺时针距离、是否落在开区间(u,k)以及选中者。最终返回还须核key属于(u,successor]，或恰等于当前节点。成员1在第一行只是返回的身份，不需要为回答“谁负责”额外处理一次查询；真正取值另发请求。
第一行目标前驱p=28，到p的距离从δ(4,28)=24变δ(21,28)=7，再变0。它说明完整指表的前驱距离减半。另取成员0/1/16，从0查15，第一跳只能去1，到key距离从15变14，没有减半；到前驱1的距离则从1变0。两种距离不能混用。
六、分别验三个失败或降级出口
- 成员和successor都正确，只保留每节点一个successor指针。从4查31走4→8→14→21→28，仍返回1。答案正确，但完整指表的O(m)证明不再适用，最坏可能走O(N)成员
- 仍有成员1，却把28的successor设为4。从28查0会错误返回4。这个例子违反正确后继前提，说明终止区间错误不能由“每步向前”修复
- 完整指表中，从4向21转交时地址不可达，返回UNKNOWN并保存已处理的4；限制预算只有一步也返回UNKNOWN。超时和预算不足都不是“已经查到另一个owner”
静态查找不包含join、stabilize或失效修复。原Chord维护规格的后续纠错说明一般动态保证必须另证；本任务没有实现一套自动修复所有成员变化的协议。
七、核成本与迁移后的新结果
区分三种计数：环全表二分是O(1+log V)查找，但数组配置更新可能O(V)；HRW单owner可扫描O(N)，本附件为了保存完整排名实际排序O(N(1+log N))；Chord完整指表为O(m)转交、每跳扫描m项，因此本地总工作O(m²)。初始化标准指表、故障地址集合、全候选日志和穷举oracle均另计。
核验器为小M枚举每个坐标以报告物理份额，需M次环查找；这不是在大空间中常数时间计算全部真实键数的算法。完整迁移清单也需遍历给定键集，真正网络搬运再按字节收费。
最终保留输入配置版本、旧新owner、迁移差集、HRW完整排名、五份局部查询轨迹、降级轨迹、错误successor及两份UNKNOWN。改变一个token坐标或一个节点分数后，重新计算实际结果；只保留原期望公式，不能替代迁移验收。