首先摆出一堆零碎的想法，完全是没有经过验证的。如果有异议，欢迎指正~
这里不从头说起，如果看不明白，请自己查阅相关资料。
关于文件缓存：
借鉴Avalanche。
只是假设，一个100k的文件，被拆分成10个10k的文件b1,b2...b10。
每一次被请求都取随机系数c1,c2...c10，发送包E1=b1c1+b2c2+...+b10c10。
当一个节点收到E1,E2时候，则可以继续取得随机系数c1c2发送E3=E1c1+E2c1给其它节点。
对于下载来说，只要收集到了足够多的线性方程，通常是10个，就可以解出原始数据，降低对于稀有块的依赖
对于节点缓存，通常每个节点保持大于一的数量，以便生成新的方程。
文件分块数量应该被限制，如果分块数量过大，那么就会出现“内存不足以初始化解线性方程组的矩阵！”这种尴尬的状况。
那么对于巨型文件，不管是创建方程，还是解方程组，内存占用都是无比巨大的，所以只能对数据进行分段处理，于是依然会出现“稀缺文件段”这种p2p网络一直面对的问题。我真的不知道有什么好的方案了。
（以上所有的加法乘法基于有限域运算）
关于路由算法：
依然是借鉴，这次中枪的是骡子的kad（Kademlia）。
但是对于不稳定节点，或者是恶意节点的侦测不是很出色。（不指望有多强大的低抗攻击的能力，至少策略上能遏制一下消极上传的节点）
那么我的想法是这样~
以“邻居们”作为一个个团体，相互监视，依然是假设（数据没有经过测试），邻居取自己最近的一些节点，数量浮动在20-40之间，尽量少变更。
构建一个邻居队列，每10s（未验证）发送一个心跳（可以包含自己的工作状态，如网络压力，计算压力，存储压力等），依次发送给邻居们，那么不考虑丢包的情况，一个节点离线能很快被发现。
关于碰撞：
没有靠谱的方案。碰撞的概率本来就非常低，可以说是0概率事件。有Hash算法，把数据分配到160位的地址空间（来源于kad），要将命运交给Hash算法的优秀程度么？
就算是多级Hash，依然是在0.0000...01的概率里面继续增加零而已。没有一个靠谱的方案。但是这个问题必须解决。
所以我很无奈，那就这样好了，一旦不幸的发现了碰撞，那么给出提示“亲爱的用户，您的数据被损坏，经过我们努力，抢救到了x个可能的副本，请您选择哪个是您做需要的。。。”
恶意节点和新节点：
对于新节点，加入网络后，不会主动请求数据。所有操作都是被动的。
对于一个下载数据的节点来说，p2p网络是一个平铺的平面，那么资源就是一个以ID为圆心的圆圈，那么圆圈内的节点都“应该”有请求的数据，并且这个圆圈就是一个邻居们组成的团体。
于是，可以向圆圈的所有节点请求，如果发现某一个节点没有数据，那么表示“你是一个新来的”，好，我通知你的邻居们“这里有个新人没数据！”
于是圆圈内的节点都知道这个新人没有数据，那么就标注这个节点缺失了数据，开始等待被请求，如果长时间未被请求，那么在“邻居”对这个“新人”好感度降低。
长期来说，很多节点会做同样的工作，最终新人就会请求足够的数据，来做好自己在p2p网络中需要的存储工作。
如果说，你很消极，或者是个虚假节点，压根不工作，那么就会让邻居们非常讨厌你，给出一定的惩罚措施。比如在路由表中加入黑名单，或者封禁多长时间，长久以来的效果就是你被从网络中分割出去了。
对此，如果有人恶意攻击，不断提示某节点缺失数据，导致正常节点被分割，还没有想出靠谱的辩解方法（不能占用太多带宽）。
如果一个节点长期收不到邻居们的心跳，那么，或许你就被分割了。
如果自己是一个正常节点，那么被诬陷显然是个很大的损失，这里提供一个不靠谱的为自己辩护的方案。
当搜索到自己的邻居，但是收不到对方心跳的时候，那么就需要为自己辩护了，那么每次心跳时候，发送一点自己所缓存的数据。
作为邻居收到带有辩护数据包的时候，就增加好感度，取消封禁或者黑名单，但是显然，对于被诬陷的节点，每次心跳的时候要发送的数据会更多。至少能保证就算是个消极节点，为了呆在网络中，仍然要通过心跳把自己的数据散布到网络中。
如果存在恶意节点伪造方程组。作为下载节点，有义务分析出错误方程的来源，然后向邻居们举报该节点，降低好感度。被举报次数过多，就可以直接封禁了吧？
那么作为邻居，接受举报的先决条件是举报的节点应该是近期从本地请求过该资源的节点，所以，能稍微遏制一下恶意诬陷举报的情况，如果你想诬陷别的节点，那么你就要消耗自己的带宽先向邻居们请求数据，才可以举报某个节点。
但目前只想到这么多，欢迎提出更好的方案。
通讯方面：
全部使用UDP通讯，上层协议保证传输的稳定？如果说压根就不要“连接”这种概念会是什么效果呢？
所有的通讯都是节点对团体的，团体就是目标节点和他的邻居们。于是通讯时候。对这个团体依次发送消息，有回应，就得到数据了，没有回应，继续下一个。都没有回应的话，这个网络距离崩溃不远了。
对于目前尴尬的内网，如何搞定NAT呢?
因为节点会发送心跳，对于那些变态的网关，只用20秒就关闭udp端口，我只好对你说抱歉！那么通常心跳就足够维持自己跟邻居们的通讯了。
但是如何连接到内网用户呢？要为了现在的局面而下很大功夫去通过处在公网的邻居搞定反向连接？甚至两个内网用户再打洞？处在公网的节点压力有多大呢？一切没有经过测试，也没有找到存在的数据来分析一下压力，于是这个想法也搁浅了。
其它方面想到了，再补充。