LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资讯 > Lava技术团队解答PoC2+协议升级

Lava技术团队解答PoC2+协议升级

2020-02-17 Lava 来源:火星财经

前言:

本次访谈,是针对近期Lava技术团队提出的“PoC2+”新P盘标准,选取了社区关注的若干问题,专门邀请Lava技术开发团队亲自作出解答。问题主要包括:

·什么是PoC2+新标准?

·PoC2+相比于以前的标准,做了哪些改变?

·新标准解决了旧标准中存在的什么“问题”和“漏洞”?

·如何看待Lava目前出现的“碰撞PID双挖”现象?

·新标准对整个PoC领域带来什么影响?

·升级新标准后,原来的币会无效吗?

·具体如何升级?升级后会形成新旧链共存的情况吗?

·Lava发布了新的P盘软件,是免费和开源的吗?性能如何?

Q:Lava技术团队最近提出了PoC2+新标准,究竟什么是PoC2+?

A:PoC2+,顾名思义,是PoC2的升级版。对于不太了解PoC2的朋友们,这里简单地扫个盲。

所有的PoC币都涉及一个很重要的概念,俗称“P盘”,它的实质是用程序产生大量与矿工地址挂钩的哈希数据,并将这些数据写入硬盘。这整个过程就叫作Plotting,具体的数据文件就叫作Plot文件,因为是P开头,就简单称为“P盘”了。那么这里就产生了,具体的哈希数据怎么计算、数据是如何组织成Plot文件、Plot文件又如何与矿工地址挂钩……等等一系列问题。

Burstcoin这个项目对PoC的贡献,很大程度就是确立了一整套标准,定义了P盘所涉及的一系列规范,下图1就是该规范中P盘种子的结构,使用了8字节Plot ID+ 8字节nonce number。


图1. Burst的P盘格式

在这种格式上,延伸出来的规范的第一代就是PoC1,如图2:


图2. PoC1

后来根据镜像互换原则,拓展了新的版本,也就是PoC2,如图3:


图3. PoC2

可以说,我们今天看到的所有PoC项目都沿用了这个PoC2规范,也就是说当前大家用的是完全一样的P盘规范。

而PoC2+试图在根源上解决P盘规范雷同的问题,图4是Lava的P盘种子结构,种子由8字节nonce number + 20字节矿工公钥 + 4字节项目路径组成。


图4. Poc2+种子构成

利用新种子构造新的Plot文件,即是PoC2+下的“P盘文件”。根据种子尾缀的项目路径,可以特异化不同项目的种子,使得不同项目所使用的“P盘文件”产生差异,首次实现了PoC共识下的“算力确权”。

Q:既然是PoC2的改进版,为什么不叫PoC3呢?

A:原因很简单,因为PoC3是一个已经存在的概念。对PoC技术比较关心的朋友可能会知道,目前有一些PoC社区的资深开发者正在探讨和研究一种将有现实意义的存储内容作为Plot数据的机制,这种机制如果可以跑通,可能会给整个PoC领域带来比较颠覆性的变化,这个机制就是所谓的PoC3。

当然,这个机制目前还在论证和尝试阶段,Lava技术团队也在保持跟进,我们会时刻保证自己处在PoC领域的最前沿……不过,这就不是今天的主题了,不再赘述。总而言之,Lava这次提出新标准叫作PoC2 Plus,是出于贴切和严谨的考虑,因为这确实是建立在PoC2基础上的改进。

Q:那么如何理解PoC2+相比于旧标准所做出的改变?

A:要解答这个问题,我们先简单理解一下原有的PoC2标准的技术原理。


PoC挖矿,是矿工先准备Plot文件并写入硬盘,然后通过硬盘参与挖矿的竞争。PoC2标准则是定义了矿工地址怎么生成PID,以及PID怎么生成Plot文件的过程。所以说,如果用一个简单粗暴的方式来总结PoC2的作用,就是它把矿工和硬盘关联了起来。

Lava提出的PoC2+标准,则是重新定义了“怎样把矿工和硬盘关联起来”这个过程。并且,我们让这种关联更加简洁、明确和安全。但是更重要的意义是,新标准针对整个PoC领域给出了一个通用解决方案,我们试图把行业规范确立起来,让跟多项目加入到这个框架里面。

Q:你提到基于旧标准做了一些“重新定义”,具体定义了什么呢?另外,旧标准存在什么问题,导致Lava要做这样一个“重新定义”?

A:从技术人员的角度来说,我们认为原有的PoC2标准确实是存在一些瑕疵和漏洞的。从短期来看,这些瑕疵和漏洞可能会引发一些小问题。而从长期来看,必定会对整个PoC行业的发展产生很大的、负面的影响。

旧标准有一个PID的概念,即Plot ID的缩写。PID是根据矿工地址压缩而成的,用以组成Plot文件的Seed(随机种子)。但是在我们看来,PID有两个问题:冗余性和安全性。冗余性是指它并不是必要的东西,我们完全可以直接将矿工地址和Plot文件联系起来,用矿工地址(Key ID形式)作为身份标识,因此PoC2+新标准直接取消了这个设计。安全性问题,是考虑到PID本身只是十几位长度的数字字符串,它相对于地址是有损压缩,有碰撞的可能,这会引发共识过程的混淆和混乱。

Q:之前社区里有出现通过寻找PID碰撞来双挖Lava和其他PoC币种的行为,也属于你说的旧标准带来的问题吗?

A:可以这么理解。本质上,这种双挖是需要找到两个不同地址,恰好对应同一个PID,那么同一个PID下出的新区块自然就同时指向两个地址,两个地址都可以得到挖矿奖励。在我们看来,这属于一种设计上的漏洞。这种“碰撞双挖”不同于一般意义的双挖,一般意义的双挖是明确开放给你挖,是公平的;而这种双挖是需要找到特定的“双挖PID”,是有门槛的,会影响到公平性。这次我们力推的PoC2+升级就可以填补这个漏洞,此类双挖行为会得到根本的抑制。

Q:新标准对整个PoC领域带来什么影响?

A:这又是一个很大的话题,Lava技术团队可能得另起一篇专门作出解读,这里就概括性地说一说。

从整个PoC领域的视角来看,新标准到底做了什么呢?我给大家总结一下,不要看前面说了一大堆那么复杂,其实新标准的内核就是一句话:算力确权。什么叫确权,确权就是明确归属,我们要明确PoC算力的归属,明确算力到底属于哪个地址(矿工)、明确算力到底属于哪个币。旧标准下一个Plot文件放在硬盘里,这个Plot文件也就是算力啊,但是它到底是属于谁的、属于哪个币的,完全是不清不楚,毕竟连PlotID都可以碰撞出来。

对于任何一个采用PoC2+新标准的项目来说,它既可以支持双挖,也可以不支持双挖,新标准只是提供了一个框架,不做价值取向判断,是项目方要去做这个判断,就是我的币到底要不要和别的币双挖?无论你的答案是什么,新标准都可以帮你在技术上做好“确权”,不再会说不清楚了。

Q:升级新标准后,原来的币会无效吗?会形成新链旧链共存的情况吗?

A:先回答第一个问题。这次升级仅仅是一个协议上的升级,并不是另造一个新币,所以不存在所谓“新币”、“老币”的区别。

对于第二个问题,这取决与我们最终采用什么方式进行升级。原则上,此次升级必须采取硬分叉方式完成,因此对于不升级软件版本的节点,是无法兼容升级后的链的。此外,我们希望把升级做成算力主导,即让算力来投票。近期我们会讨论发起升级的整体技术流程,希望社区保持关注。

Q:连同新标准,Lava还发布了新的P盘软件,这是免费和开源的吗?

A:对,这次新标准的升级,Lava提出了一个概念叫做“PoC2+全家桶”,其实就是把适配新标准的P盘软件(Plotter)和挖矿软件(Miner,包含扫盘软件)都一并提出并发布了。全家桶的意义很明确,就是给PoC行业提供了一整套解决方案,拿来即用,而且有一定的定制化能力。对于任何想要进入PoC行业的项目来说,新标准给出了一个新的选择,而且配套设施都是齐全的。我们觉得这对整个行业是有积极意义的。

Lava是一个坚持走开源、平等和扩大共识路线的项目,我们的软件在原则上也会做开源并免费向用户提供。为了安全性和稳定性考虑,短时间内应该还不会完全开源出来,但是一定是秉持着免费、开放的原则,服务广大矿工用户。

Q:新的P盘软件性能如何?能做个简单的介绍吗。

A:没问题。首先我要强调一下,我们绝对不会因为P盘软件免费,就给大家非常垃圾的性能,而且我们会不断进行开发和升级,最终做到行业里最优秀的水平,这一点请用户放心。

从用户接受性的角度,我们在设计上兼容最常用的TurboPlotter,这样熟悉TurboPlotter的老矿工用户都可以快速上手,不会付出太多的学习接受成本。之前社区里比较关心的GUI界面(图形界面),因为时间和开发量问题,暂时还没有给出图形版本,不过我们提供了更为灵活的脚本,让用户可以在经过极为简单的配置后就快速开始P盘;而对性能有更高要求的用户,也可以通过详细的参数配置来提高性能、缩短P盘时间。

在性能方面,我们的整体思路是单GPU计算Hash同时为多个硬盘写入数据,即所谓“多P”;并且,我们对磁盘写入和任务调度进行了特别的优化,进一步压缩写入时间。根据我们的测试,普通8T规格SATA硬盘的写入速度平均可达到100MB/s(24000 nonces/min),作为参照TurboPlotter的写入速度平均在60MB/s;N卡RTX 2060 下的Hash计算速度可以轻松超过240000 nonces/min。可以说,相比于参照产品TurboPlotter,Lava的版本带来超过40%的性能提升。因为篇幅有限,性能方面的介绍没法很详细和严谨,我们还是鼓励矿工用户参与实操测试,亲自体验和验证软件的性能,提出宝贵的意见和建议!

—-

编译者/作者:Lava

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...