EOS新闻动态

EOS新闻动态

EOS简介,新闻动态更新
EOS技术讨论

EOS技术讨论

EOS, Bitshares, steem, Graphene技术分析
EOS众筹价格

EOS众筹价格

EOS众筹模式,价格讨论
EOS其他相关

EOS其他相关

其他的关于EOS的问题和话题都在这

EOS学习笔记2-运行本地节点链接公共测试网络

EOS代码分析郑浩 发表了文章 • 0 个评论 • 210 次浏览 • 1 天前 • 来自相关话题

昨天Dawn2.0发布了公共的测试网络,本文介绍一下如何在本地运行一个节点,链接到公共测试节点,注册账户进行测试。github教程,笔者系统配置,ubuntu16.04,RAM 4G,
1.使用安装脚本安装本地节点,
git clone [url=https://github.com/eosio/eos]https://github.com/eosio/eos[/url] --recursive

cd eos
./build.sh ubuntu  
2.使用脚本运行本地节点连接到公共测试节点
  cd ~/eos/build/scripts
./start_npnode.sh这个命令将使用名称为testnet_np的实例数据文件夹。
你应该会看到以下的回应:
Launched eosd.
See testnet_np/stderr.txt for eosd output.
Synching requires at least 8 minutes, depending on network conditions.
 
使用以下命令来确认eosd的运行和同步:
 
tail -F testnet_np/stderr.txt
使用CTRL-C来推出tail,在同步的过程中,你会看到以下类似的信息:
3439731ms chain_plugin.cpp:272 accept_block ] Syncing Blockchain --- Got block: #200000 time: 2017-12-09T07:56:32 producer: initu
3454532ms chain_plugin.cpp:272 accept_block ] Syncing Blockchain --- Got block: #210000 time: 2017-12-09T13:29:52 producer: initc同步完成后,你会看到以下类似信息:
42467ms net_plugin.cpp:1245 start_sync ] Catching up with chain, our last req is 351734, theirs is 351962 peer ip-10-160-11-116:9876
42792ms chain_controller.cpp:208 _push_block ] initt #351947 @2017-12-12T22:59:44 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] inito #351948 @2017-12-12T22:59:46 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] initd #351949 @2017-12-12T22:59:48 | 0 trx, 0 pending, exectime_ms=0
3.创建钱包,密钥对,申请账号。
cd eosc
./eosc wallet create#创建钱包,记得保持私钥,丢失后将无法解锁你的钱包。

./eosc create key
Private key: 5XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的私钥
Public key: EOSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的公钥./eosc wallet import 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #导入你的私钥现在公共测试网络需要申请来注册账户,申请地址,按照文档步骤填写表格,大概在半个小时我收到了邮件回复。
这个时候查看我的账户,里面有100EOS代币了。
./eosc get account name55

{
"account_name": "name55",
"eos_balance": "100.0000 EOS",
"staked_balance": "0.0001 EOS",
"unstaking_balance": "0.0000 EOS",
"last_unstaking_time": "1969-12-31T23:59:59",
"permissions": [{
"perm_name": "active",
"parent": "owner",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
},{
"perm_name": "owner",
"parent": "",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
}
]
}
这样就可以使用公共测试网络来进行测试,和DAPP的开发部署了。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
 
 
 
 
 
 
 
  查看全部
昨天Dawn2.0发布了公共的测试网络,本文介绍一下如何在本地运行一个节点,链接到公共测试节点,注册账户进行测试。github教程,笔者系统配置,ubuntu16.04,RAM 4G,
1.使用安装脚本安装本地节点,
git clone [url=https://github.com/eosio/eos]https://github.com/eosio/eos[/url] --recursive

cd eos
./build.sh ubuntu
 
2.使用脚本运行本地节点连接到公共测试节点
  
cd ~/eos/build/scripts
./start_npnode.sh
这个命令将使用名称为testnet_np的实例数据文件夹。
你应该会看到以下的回应:
Launched eosd.
See testnet_np/stderr.txt for eosd output.
Synching requires at least 8 minutes, depending on network conditions.

 
使用以下命令来确认eosd的运行和同步:
 
tail -F testnet_np/stderr.txt
使用CTRL-C来推出tail,在同步的过程中,你会看到以下类似的信息:
3439731ms            chain_plugin.cpp:272          accept_block         ] Syncing Blockchain --- Got block: #200000 time: 2017-12-09T07:56:32 producer: initu
3454532ms chain_plugin.cpp:272 accept_block ] Syncing Blockchain --- Got block: #210000 time: 2017-12-09T13:29:52 producer: initc
同步完成后,你会看到以下类似信息:
42467ms            net_plugin.cpp:1245           start_sync           ] Catching up with chain, our last req is 351734, theirs is 351962 peer ip-10-160-11-116:9876
42792ms chain_controller.cpp:208 _push_block ] initt #351947 @2017-12-12T22:59:44 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] inito #351948 @2017-12-12T22:59:46 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] initd #351949 @2017-12-12T22:59:48 | 0 trx, 0 pending, exectime_ms=0

3.创建钱包,密钥对,申请账号。
cd eosc
./eosc wallet create#创建钱包,记得保持私钥,丢失后将无法解锁你的钱包。

./eosc create key
Private key: 5XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的私钥
Public key: EOSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的公钥
./eosc wallet import 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #导入你的私钥
现在公共测试网络需要申请来注册账户,申请地址,按照文档步骤填写表格,大概在半个小时我收到了邮件回复。
这个时候查看我的账户,里面有100EOS代币了。
./eosc get account name55

{
"account_name": "name55",
"eos_balance": "100.0000 EOS",
"staked_balance": "0.0001 EOS",
"unstaking_balance": "0.0000 EOS",
"last_unstaking_time": "1969-12-31T23:59:59",
"permissions": [{
"perm_name": "active",
"parent": "owner",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
},{
"perm_name": "owner",
"parent": "",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
}
]
}

这样就可以使用公共测试网络来进行测试,和DAPP的开发部署了。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
 
 
 
 
 
 
 
 

EOS.IO发布黎明2.0版本 & 开发更新

EOS新闻动态郑浩 发表了文章 • 0 个评论 • 42 次浏览 • 2017-12-06 20:59 • 来自相关话题

译者:岳利鹏、许莉,原文:https://steemit.com/eos/%40eos ... pdate




EOS.IO Dawn 2.0 已经发布,此次发布提供了由 block.one 团队维护的一个公开测试网络,对于 2017 年秋季路线图,以及原定于 2017 年 12 月 21 日前完成的大部分功能,此次发布也都提供了 Alpha 实现。正如我们路线图所公布的,“第二阶段 - 最小可行测试网络”将在 2017 年秋季之前展示如下内容:

- P2P 网络代码

- wasm 检测和 CPU 沙盒

- 资源利用跟踪/限制率

- 创世块导入测试

- 链间通信

目前,我们已经完成了大部分功能的初步实现。但是,由于并行开发路线的安排,链间通信的实现在一个单独的分支上进行,所以初始测试网络将不会用上链间通信的功能。

如果您对 EOS.IO Dawn 2.0 的性能测试感兴趣,可以在 Github 仓库找到启动和操作一个私有网络的所有区块链和网络代码。我们的内部测试表明,在普通硬件上,单线程实现可以承受每秒数千次传输和可处理多个块。即便如此,对于一些已知的攻击方式,我们还没有实现对应的解决方案。比如,首次编译新合约可能需要 34 ms,如果被利用,可能导致网络以超过 30 TPS 的交易速率碎片化。

针对这个问题,我们的解决方案是限制合约代码更新的频率,并限制代码更新与处理使用新代码交易之间的时间延迟。这个时间延迟将在 60 秒左右,以期能够让所有的块生产者有时间从 web assembly 中编译/缓存优化后的 x86 指令。

由于这些不可忽视的攻击方式,私有测试网络的其中一项任务仍然是性能测试,但是功能测试现在已经可以在公开测试网上进行了,我们已经将公开测试网人为地限制在 30 TPS,以确保正常的运行时间和访问。

在接下来的 6 个月里,我们将不断对网络进行测试和调试,以提高稳定性和性能。
Dawn 2.0的新特征

初始状态导入测试

我们实现了一个快照工具,它将根据分布在以太坊网络上 EOS ERC-20代币来导入初始状态。我们的测试网络只包含了注册有效EOS公钥的余额。大概有20%的ERC-20代币已经注册到了一个EOS的公钥中。我们的快照还为以太坊账户所有未注册的ERC-20代币提供了一个恢复工具,这个工具可帮我们从已签署的以太坊交易中恢复公钥。这包含了99%的EOS ERC-20代币,但是还将需要你导入你的以太坊私钥到你的EOS.IO的钱包里。

出于安全考虑,我们的测试网络不会要求用户导入他们的以太坊私钥然后通过恢复工具进行恢复。如果你的EOS私钥在测试的时候受到威胁,你可以随时在以太坊网络上注册一个新密钥。
 
代币“水龙头”

我们还实现了一个“水龙头”功能,这样就可以允许那些没有代币或者还没有注册一个有效的EOS公钥的人们进行网络测试。




资源使用和费率限制

我们实现了基本的费率限制和资源使用追踪。它追踪带宽、数据库存储以及计算力使用。这个时候我们的费率限制算法存在着一些已知的bugs,但是这不会影响测试和应用程序的开发。

我们知道有很多人都很关心费率限制相关信息,比如谁将会被收费,还有如何将它们的代币租出去以此换来收益等等。




带宽

所有的交易都会消耗掉区块生产者设置的网络带宽的最大值。拥有交易权的所有账户会根据交易的大小把3天内的流量累加。想获得带宽会要求授权账户(不是合约)抵押代币或由应用程序提供者委托代币。




计算带宽

所有的交易都消耗计算力。计算可以是并行地进行的,所以你可以把它想象成多个车道的高速公路,每个车道都拥有不同的拥挤程度。每个范围(车道)都会有自己独立的速率限制,并且基于最拥挤的程度,用户将针对同时请求的范围(通道)数量和速率限制来计费O(S^2)。




数据库存储

EOS.IO合约有访问内存数据库的权限,它们可以在该数据库存储状态。合约收费是根据它们存储数据的总和以及每个独立数据库条目的固定开销 ,这个内存数据库是独立的并且与EOS.IO的存储协议是分开的,这样做是为了让内存的膨胀不那么集中。




P2P 网络代码

对于mesh网络代码,我们已经有了基本实现,并且这些代码正在公开测试网络中试运行。目前 Block.one 运行了 21 个独立的服务器,每个服务器都配置了一个初始生产者。




EOS黎明3.0

EOS Dawn 3.0将通过安全的区块链间通信,重新解释单链水平扩展和无限扩展。有了这两个特点,对于区块链技术可以建立什么样的东西,以及区块链网络如何去中心化就都没有限制了。




无限扩展与无限去中心化

区块链技术的圣杯是在两个独立区块链之间实现安全通信,而不需要某一区块链验证另一个区块链上的所有内容。这需要使一个区块链成为另一个区块链的轻客户端。

轻客户端只使用块头和Merkle证明来验证交易。 EOS.IO将成为第一个支持轻客户端验证的POS协议。更重要的是,它将能首次产生Proof-of-Completeness。这意味着您可以证明您已经提前收到来自其他链的所有相关消息,无需等待或接受挑战的时间。

而传统的轻客户端必须处理所有的块头,EOS.IO将使轻客户端只需要当出块人改变、或需要一个更近块的新消息时再处理块头。这将使得高效率的频繁通信成为可能。在最坏的情况下,两个区块链每500毫秒一次通信的开销将比发送的消息总数高出约2个交易。

在这种模式下,只要至少有三分之一的生产者是诚实的,通信就会得到保证。此外,即使一个生产者腐败,如果他们签署任何可能破坏轻客户(或者叫外部区块链)的消息,他们会自动受到惩罚。

最后,传递到另一个区块链的往返时间取决于每个链不可逆的最终确定性等待时间。一个基于EOS.IO的链将能够发送一条消息给外部的EOS.IO链,并在3秒内得到一个密码学验证的响应。

这种级别的链间通信和安全性使得能够以非常低的延迟在链之间创建双向挂钩。虽然双向挂钩是最常见的例子,但任何商业之间的通信都可以用同样的方法进行。 




公有/私有通信

通过跨链通信,私有区块链可以与公有区块链进行安全的双向通信。这使得各种不适合公有性质的传统区块链应用成为可能。例如,有人可以创建瑞士银行的区块链,除了银行业主和个人之外,对每个人都是超级秘密。




开发进展

为了交付我们的公共测试网络,我们将开发划分为两条平行路径,以便我们可以重构代码的重要部分以实现可读性、性能和跨链通信。这个重构工作已经在eos-noon分支上开展。

在过去的更新中,我们表示我们打算专注于共享内存架构,以便开发人员可以轻松地与其他合约执行同步读取访问和原子事务。这种方法的后果是丧失了单台高性能机器的水平扩展性。

借助EOS Dawn 3.0,我们将通过使用最多65000个不同的分区region来恢复执行多机横向扩展的能力。所有分区将共享相同的帐户和合约代码,但在内存数据库中是独立的。一个分区内的合同必须使用异步交易与其他分区的合作伙伴进行通信。有了这个架构,一个块生产者可以作为一个集群来实现。




集成苹果的安全硬件

在上次更新中,我们宣布了我们打算支持Apple,Android和许多智能卡使用的椭圆曲线。我们的eos-noon分支现在包括一个全功能的验证概念,在最新的MacBook Pro上使用Touch ID(也包括Face ID)对消息进行签名和验证。类似的代码也适用于本机iPhone应用程序。这意味着基于EOS.IO的移动应用将成为已知最安全的区块链钱包 

此外,eos-noon分支现在已经整合了对多种签名类型的支持,这意味着可以使用安全硬件来签名需要在eos-noon上进行验证的交易。




500毫秒区块确认

在我们的eos-noon分支上,我们对底层的DPOS框架实施了一些改变,以支持500 ms的块(每秒2个块)。这一变化将大大提高去中心化应用程序的响应速度。为了实现这一点,我们在区块调度发生方面进行了一些改变。

同一个生产者将连续生产12块,然后交给下一个生产者。这解决了从生产者到生产者交接的块生产中最大的瓶颈。在新的结构下,意外延迟可能会导致每次切换时都会丢失几个块,但是在切换之间应该有非常快的确认。我们将尝试不同的交接期。交接期时间越长,在正常操作期间丢失的块越少,但是如果单个节点停机,则停机时间越长。在500毫秒的时间内,每隔12个区块,“停机时间”也不会比单个生产者在Steem和BitShares上丢失单个区块时更差。在这种情况下,首次确认可能需要6秒。




去除替补生产者

跨链通信需要轻客户端跟踪活跃生产者集合发生变化的所有区块。“替补生产者名录”造成每分钟会增加或删除一个新生产者,这迫使轻客户每分钟处理至少一个块头。为了减少生产者变更的频率,我们改变了区块调度结构,只包括前21名生产者。我们正在考虑为替补生产者提供某种待命薪酬,但他们实际上不会负责生产区块。




一秒不可逆

每个区块生产者将签署每个区块,只要大于2/3的生产者签署了该区块,这个区块就可以被标记为不可逆的。生产者只能在每个块高度上签署一个块头。这意味着,如果有分叉,生产者不能在两条分叉的相同高度上签名区块。任何这样的签名都是生产者不当行为的密码证明,可以通过多种方法处理,包括自动丧失生产者地位,潜在的抵押损失,以及仲裁可能造成的损害赔偿责任。 

不像其他协议需要在出下一个块之前收集大于2/3的签名,EOS的DPOS流水线允许区块链在“等待状态”中前进而签名收集。这些额外的签名发生在区块链之外,并且在Steem或BitShares的传统DPOS规则下,区块在变得不可逆转之后可以进行修剪。

在这个模型下,有可能实现拜占庭容错,因为任何块不可能接收到大于2/3的非拜占庭节点的密码证据签名。




删除生产者洗牌计划

为了最小化生产者切换期间丢失块数量,我们希望可以最小化两个生产者之间的延迟。如果纽约的生产者计划跟随中国的生产者,在正常情况下(块间隔的50%)可能需要250ms的时间才能接收到该数据块,如果网络拥堵,可能需要更长的时间。另一方面,纽约和得克萨斯州的生产者只有50ms的延迟(块间隔的10%)。这意味着在从纽约到德克萨斯的交接比从纽约到中国的路由丢失的可能性要低得多。

如果我们安排从纽约到德克萨斯州、加利福尼亚州、夏威夷、日本、中国、印度、以色列、意大利、英国、冰岛,然后回到纽约的区块生产,那么从来没有超过50到100ms。但是,如果顺序是随机的,那么平均交接时间将显著增高。

生产者洗牌被引入,以最大限度地减少一个生产者选择后续生产者的潜力。这个风险存在于一个生产者被认为是恶意的世界,但在高度审查公有的生产者与高品质的数据中心的世界里,它不再有意义。如果一个生产者故意伤害他的邻居,会有宪法和可预期的行为流程来解决争端。

在EOS下,生产者将以平均等待时间最小化的方式对生产者排序进行投票,把网络拥塞而导致的总丢失块最小化。




已知的问题

EOS Dawn 2.0 存在一些已知的问题,不过早期版本出现严重的不稳定性也在预料之内。 这次发布的目的在于展示基本功能,在未来的 6 个月,我们的团队将会致力于解决 bug,提高稳定性和性能。

为了支持测试网络的稳定性,我们已经禁止了生产者投票。




结束语

在这里要感谢我们的开发团队,为了开发交付 EOS Dawn 2.0,全球范围内展开了通力工作,,这是一个将成为最强大,性能最高,最分散的应用平台的 alpha 版本。 我们正在按照我们发布的路线图执行,并提供比原计划更多的功能和能力。 我们期待到2018年,并且有信心在EOS令牌分发完成之前,所有功能都将完成并解决错误。
 
转自因特链 查看全部
译者:岳利鹏、许莉,原文:https://steemit.com/eos/%40eos ... pdate




EOS.IO Dawn 2.0 已经发布,此次发布提供了由 block.one 团队维护的一个公开测试网络,对于 2017 年秋季路线图,以及原定于 2017 年 12 月 21 日前完成的大部分功能,此次发布也都提供了 Alpha 实现。正如我们路线图所公布的,“第二阶段 - 最小可行测试网络”将在 2017 年秋季之前展示如下内容:

- P2P 网络代码

- wasm 检测和 CPU 沙盒

- 资源利用跟踪/限制率

- 创世块导入测试

- 链间通信

目前,我们已经完成了大部分功能的初步实现。但是,由于并行开发路线的安排,链间通信的实现在一个单独的分支上进行,所以初始测试网络将不会用上链间通信的功能。

如果您对 EOS.IO Dawn 2.0 的性能测试感兴趣,可以在 Github 仓库找到启动和操作一个私有网络的所有区块链和网络代码。我们的内部测试表明,在普通硬件上,单线程实现可以承受每秒数千次传输和可处理多个块。即便如此,对于一些已知的攻击方式,我们还没有实现对应的解决方案。比如,首次编译新合约可能需要 34 ms,如果被利用,可能导致网络以超过 30 TPS 的交易速率碎片化。

针对这个问题,我们的解决方案是限制合约代码更新的频率,并限制代码更新与处理使用新代码交易之间的时间延迟。这个时间延迟将在 60 秒左右,以期能够让所有的块生产者有时间从 web assembly 中编译/缓存优化后的 x86 指令。

由于这些不可忽视的攻击方式,私有测试网络的其中一项任务仍然是性能测试,但是功能测试现在已经可以在公开测试网上进行了,我们已经将公开测试网人为地限制在 30 TPS,以确保正常的运行时间和访问。

在接下来的 6 个月里,我们将不断对网络进行测试和调试,以提高稳定性和性能。
Dawn 2.0的新特征

初始状态导入测试


我们实现了一个快照工具,它将根据分布在以太坊网络上 EOS ERC-20代币来导入初始状态。我们的测试网络只包含了注册有效EOS公钥的余额。大概有20%的ERC-20代币已经注册到了一个EOS的公钥中。我们的快照还为以太坊账户所有未注册的ERC-20代币提供了一个恢复工具,这个工具可帮我们从已签署的以太坊交易中恢复公钥。这包含了99%的EOS ERC-20代币,但是还将需要你导入你的以太坊私钥到你的EOS.IO的钱包里。

出于安全考虑,我们的测试网络不会要求用户导入他们的以太坊私钥然后通过恢复工具进行恢复。如果你的EOS私钥在测试的时候受到威胁,你可以随时在以太坊网络上注册一个新密钥。
 
代币“水龙头”

我们还实现了一个“水龙头”功能,这样就可以允许那些没有代币或者还没有注册一个有效的EOS公钥的人们进行网络测试。




资源使用和费率限制

我们实现了基本的费率限制和资源使用追踪。它追踪带宽、数据库存储以及计算力使用。这个时候我们的费率限制算法存在着一些已知的bugs,但是这不会影响测试和应用程序的开发。

我们知道有很多人都很关心费率限制相关信息,比如谁将会被收费,还有如何将它们的代币租出去以此换来收益等等。




带宽

所有的交易都会消耗掉区块生产者设置的网络带宽的最大值。拥有交易权的所有账户会根据交易的大小把3天内的流量累加。想获得带宽会要求授权账户(不是合约)抵押代币或由应用程序提供者委托代币。




计算带宽

所有的交易都消耗计算力。计算可以是并行地进行的,所以你可以把它想象成多个车道的高速公路,每个车道都拥有不同的拥挤程度。每个范围(车道)都会有自己独立的速率限制,并且基于最拥挤的程度,用户将针对同时请求的范围(通道)数量和速率限制来计费O(S^2)。




数据库存储

EOS.IO合约有访问内存数据库的权限,它们可以在该数据库存储状态。合约收费是根据它们存储数据的总和以及每个独立数据库条目的固定开销 ,这个内存数据库是独立的并且与EOS.IO的存储协议是分开的,这样做是为了让内存的膨胀不那么集中。




P2P 网络代码

对于mesh网络代码,我们已经有了基本实现,并且这些代码正在公开测试网络中试运行。目前 Block.one 运行了 21 个独立的服务器,每个服务器都配置了一个初始生产者。




EOS黎明3.0

EOS Dawn 3.0将通过安全的区块链间通信,重新解释单链水平扩展和无限扩展。有了这两个特点,对于区块链技术可以建立什么样的东西,以及区块链网络如何去中心化就都没有限制了。




无限扩展与无限去中心化

区块链技术的圣杯是在两个独立区块链之间实现安全通信,而不需要某一区块链验证另一个区块链上的所有内容。这需要使一个区块链成为另一个区块链的轻客户端。

轻客户端只使用块头和Merkle证明来验证交易。 EOS.IO将成为第一个支持轻客户端验证的POS协议。更重要的是,它将能首次产生Proof-of-Completeness。这意味着您可以证明您已经提前收到来自其他链的所有相关消息,无需等待或接受挑战的时间。

而传统的轻客户端必须处理所有的块头,EOS.IO将使轻客户端只需要当出块人改变、或需要一个更近块的新消息时再处理块头。这将使得高效率的频繁通信成为可能。在最坏的情况下,两个区块链每500毫秒一次通信的开销将比发送的消息总数高出约2个交易。

在这种模式下,只要至少有三分之一的生产者是诚实的,通信就会得到保证。此外,即使一个生产者腐败,如果他们签署任何可能破坏轻客户(或者叫外部区块链)的消息,他们会自动受到惩罚。

最后,传递到另一个区块链的往返时间取决于每个链不可逆的最终确定性等待时间。一个基于EOS.IO的链将能够发送一条消息给外部的EOS.IO链,并在3秒内得到一个密码学验证的响应。

这种级别的链间通信和安全性使得能够以非常低的延迟在链之间创建双向挂钩。虽然双向挂钩是最常见的例子,但任何商业之间的通信都可以用同样的方法进行。 




公有/私有通信

通过跨链通信,私有区块链可以与公有区块链进行安全的双向通信。这使得各种不适合公有性质的传统区块链应用成为可能。例如,有人可以创建瑞士银行的区块链,除了银行业主和个人之外,对每个人都是超级秘密。




开发进展

为了交付我们的公共测试网络,我们将开发划分为两条平行路径,以便我们可以重构代码的重要部分以实现可读性、性能和跨链通信。这个重构工作已经在eos-noon分支上开展。

在过去的更新中,我们表示我们打算专注于共享内存架构,以便开发人员可以轻松地与其他合约执行同步读取访问和原子事务。这种方法的后果是丧失了单台高性能机器的水平扩展性。

借助EOS Dawn 3.0,我们将通过使用最多65000个不同的分区region来恢复执行多机横向扩展的能力。所有分区将共享相同的帐户和合约代码,但在内存数据库中是独立的。一个分区内的合同必须使用异步交易与其他分区的合作伙伴进行通信。有了这个架构,一个块生产者可以作为一个集群来实现。




集成苹果的安全硬件

在上次更新中,我们宣布了我们打算支持Apple,Android和许多智能卡使用的椭圆曲线。我们的eos-noon分支现在包括一个全功能的验证概念,在最新的MacBook Pro上使用Touch ID(也包括Face ID)对消息进行签名和验证。类似的代码也适用于本机iPhone应用程序。这意味着基于EOS.IO的移动应用将成为已知最安全的区块链钱包 

此外,eos-noon分支现在已经整合了对多种签名类型的支持,这意味着可以使用安全硬件来签名需要在eos-noon上进行验证的交易。




500毫秒区块确认

在我们的eos-noon分支上,我们对底层的DPOS框架实施了一些改变,以支持500 ms的块(每秒2个块)。这一变化将大大提高去中心化应用程序的响应速度。为了实现这一点,我们在区块调度发生方面进行了一些改变。

同一个生产者将连续生产12块,然后交给下一个生产者。这解决了从生产者到生产者交接的块生产中最大的瓶颈。在新的结构下,意外延迟可能会导致每次切换时都会丢失几个块,但是在切换之间应该有非常快的确认。我们将尝试不同的交接期。交接期时间越长,在正常操作期间丢失的块越少,但是如果单个节点停机,则停机时间越长。在500毫秒的时间内,每隔12个区块,“停机时间”也不会比单个生产者在Steem和BitShares上丢失单个区块时更差。在这种情况下,首次确认可能需要6秒。




去除替补生产者

跨链通信需要轻客户端跟踪活跃生产者集合发生变化的所有区块。“替补生产者名录”造成每分钟会增加或删除一个新生产者,这迫使轻客户每分钟处理至少一个块头。为了减少生产者变更的频率,我们改变了区块调度结构,只包括前21名生产者。我们正在考虑为替补生产者提供某种待命薪酬,但他们实际上不会负责生产区块。




一秒不可逆

每个区块生产者将签署每个区块,只要大于2/3的生产者签署了该区块,这个区块就可以被标记为不可逆的。生产者只能在每个块高度上签署一个块头。这意味着,如果有分叉,生产者不能在两条分叉的相同高度上签名区块。任何这样的签名都是生产者不当行为的密码证明,可以通过多种方法处理,包括自动丧失生产者地位,潜在的抵押损失,以及仲裁可能造成的损害赔偿责任。 

不像其他协议需要在出下一个块之前收集大于2/3的签名,EOS的DPOS流水线允许区块链在“等待状态”中前进而签名收集。这些额外的签名发生在区块链之外,并且在Steem或BitShares的传统DPOS规则下,区块在变得不可逆转之后可以进行修剪。

在这个模型下,有可能实现拜占庭容错,因为任何块不可能接收到大于2/3的非拜占庭节点的密码证据签名。




删除生产者洗牌计划

为了最小化生产者切换期间丢失块数量,我们希望可以最小化两个生产者之间的延迟。如果纽约的生产者计划跟随中国的生产者,在正常情况下(块间隔的50%)可能需要250ms的时间才能接收到该数据块,如果网络拥堵,可能需要更长的时间。另一方面,纽约和得克萨斯州的生产者只有50ms的延迟(块间隔的10%)。这意味着在从纽约到德克萨斯的交接比从纽约到中国的路由丢失的可能性要低得多。

如果我们安排从纽约到德克萨斯州、加利福尼亚州、夏威夷、日本、中国、印度、以色列、意大利、英国、冰岛,然后回到纽约的区块生产,那么从来没有超过50到100ms。但是,如果顺序是随机的,那么平均交接时间将显著增高。

生产者洗牌被引入,以最大限度地减少一个生产者选择后续生产者的潜力。这个风险存在于一个生产者被认为是恶意的世界,但在高度审查公有的生产者与高品质的数据中心的世界里,它不再有意义。如果一个生产者故意伤害他的邻居,会有宪法和可预期的行为流程来解决争端。

在EOS下,生产者将以平均等待时间最小化的方式对生产者排序进行投票,把网络拥塞而导致的总丢失块最小化。




已知的问题

EOS Dawn 2.0 存在一些已知的问题,不过早期版本出现严重的不稳定性也在预料之内。 这次发布的目的在于展示基本功能,在未来的 6 个月,我们的团队将会致力于解决 bug,提高稳定性和性能。

为了支持测试网络的稳定性,我们已经禁止了生产者投票。




结束语

在这里要感谢我们的开发团队,为了开发交付 EOS Dawn 2.0,全球范围内展开了通力工作,,这是一个将成为最强大,性能最高,最分散的应用平台的 alpha 版本。 我们正在按照我们发布的路线图执行,并提供比原计划更多的功能和能力。 我们期待到2018年,并且有信心在EOS令牌分发完成之前,所有功能都将完成并解决错误。
 
转自因特链

EOS 编译、测试指南(五) --EOS 节点分类浅析

EOS代码分析郑浩 发表了文章 • 0 个评论 • 72 次浏览 • 2017-11-07 16:26 • 来自相关话题

EOS 团队于 2017 年 9 月 14 日推出了 Dawn 1.0 release 版本,熟悉 Linux 和 C++的开发人员可以在此基础上尝试自己的合约开发了。OracleChain 团队一直以 来都在对 EOS 代码进行了编译和测试,陆续发布了四份《EOS 编译、测试指南》, 详细介绍了 EOS 的入门知识、基本结构,帮助开发人员学习、研究 EOS。 基于 EOS 刚刚推出的 Dawn 1.0,OralceChain 团队进行了测试,本次将以节 点功能为例,详细介绍 EOS 上不同节点服务之间的区别,基于此开发人员可以根 据自己的业务需求,在 EOS 网络上运行自定义节点,从而参与、利用 EOS 网络 为外部提供服务。 该指南主要依据 EOS 的官方文档,以及欧链团队的实践经验编写,开发者有 任何技术问题可以关注欧链小秘书、在欧链科技社区里向 OracleChain 团队提问 或者发送邮件到 contact@oraclechain.io。
 EOS 文档:https://eosio.github.io/eos/ 
EOS 代码:https://github.com/EOSIO/eos 
备注:OracleChain 团队使用 Mac 环境进行开发。
 
上一章中,我们通过源码研究了 EOS 合约执行机制。合约执行内容主要包括 三方面:合约发布和存储,合约执行环境的数据存取接口,以及状态数据持久化 等。依靠 web assemble 沙盒技术,让合约拥有与 native code 一样的执行速度。 与 bitcoin 相似,EOS 各节点通过 P2P 网络互联,相互传递 block 信息,任何 一个节点都可以参与验证和转发 block 信息,从而达成全网共识。而与 bitcoin 不同的是,EOS 内部采用 DPOS 的出块机制。每个节点可以选出代理,或者直 接投票,选出其信任的 21 个出块节点。这样做,既避免了出块权过于集中,又保证了共识机制不至于分叉(投票表决)。同时,这种投票保证的信任机制避免 了计算资源的浪费,将资源真正运用到 DAPP 的服务中。因此,我们可以把 EOS 合约,当作一个运行在“云”上的服务 
 
 
一、EOS 节点的功能和分类
 EOS 网络中,所有节点都可以参与验证/转发交易和区块,发现和维护一个 点对点网络。 EOS 网络节点可根据函数功能分为四个集合。开发者可以组合不同的集合, 发布符合自己需求的节点,加入到 EOS 网络中,再由这个节点为最终用户提供更 多差异化服务。
 
二、network(转发路由)
 所有节点都包含转发路由模块。通过这个模块,节点可以加入到 EOS 网络 中,参加对交易和区块的验证,发现和共享 p2p 连接池。另外,如果要投票或选 择代理人选出出块节点,就可以通过组合其他模块来实现。 要启动只带有转发和验证功能的节点,我们只需要在启动 eosd 的时候注释掉所有 plugin。config.ini 如下:
 
三、producer(验证出块) 
只有出块节点包含有效的 producer function。出块节点可以根据自己的资源 提供交易和存储服务。普通节点根据节点的价值偏好(可以是资源对应 token 的 单价),投票选出出块节点。选出的出块节点将组成一个网络,任意一个出块时 间段内,只有一个出块节点被全网授权去验证交易,并将交易打包成块。最后, block 被转发到其他节点验证和转发,全网达成共识。 启动一个 producer 节点时,需要在 config.ini 文件中启动 producer plugin,并 且配置出块节点相关数据:
 
四、wallet(保存私钥和发起交易)
 钱包用户都需要有 wallet api 来维护自己的 EOS 智能资产,例如桌面端的 EOS 客户端、钱包 app 等。对于资源吃紧的手机终端的钱包 app 来讲,由于不能保存 所有的账户信息,所以只保留用户相关的数据,并使用类似比特币的 SPV 技术,远程拉取交易所需信息并发出交易。 在 EOS 源码中,wallet 以 plugin 的形式提供对外服务,我们可以使用 eosc 对 这些接口进行简单调用。
在配置中,也需要指定加载 wallet plugin
 
五、blockchain functions(账号状态和交易历史)
 通常只有全节点才会使用 blockchain functions。blockchain 模块实际包含两 部分数据,一部分是保存着所有账号的状态机,另一部分是保存着所有历史交易 的 block 数据。全节点依靠自身保存的完整的账号状态和交易历史,可以在本地 独立地验证所有交易。 举个例子,对于出块节点来说,不一定会带有 wallet 模块,但一定会有带有 blockchain 模块。blockchain 模块是出块节点产生共识的基础数据,出块节点只有 遵守共识,产生的 block 数据才会被区块链所接受。 blockchain 模块也通过 http api 对外提供查询接口,我们可以使用 eosc 对这 些接口进行调用:
 
六、总结 
在 EOS 目前的版本之上,我们已经可以初步的搭建自己的测试网络,完成区 块链基本功能测试。我们相信再不久的将来,基于 EOS,将会开发出丰富的区块 链应用。
 
OracleChain 团队 2017 年 11 月 1 日
 
转自:欧链科技
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  查看全部
EOS 团队于 2017 年 9 月 14 日推出了 Dawn 1.0 release 版本,熟悉 Linux 和 C++的开发人员可以在此基础上尝试自己的合约开发了。OracleChain 团队一直以 来都在对 EOS 代码进行了编译和测试,陆续发布了四份《EOS 编译、测试指南》, 详细介绍了 EOS 的入门知识、基本结构,帮助开发人员学习、研究 EOS。 基于 EOS 刚刚推出的 Dawn 1.0,OralceChain 团队进行了测试,本次将以节 点功能为例,详细介绍 EOS 上不同节点服务之间的区别,基于此开发人员可以根 据自己的业务需求,在 EOS 网络上运行自定义节点,从而参与、利用 EOS 网络 为外部提供服务。 该指南主要依据 EOS 的官方文档,以及欧链团队的实践经验编写,开发者有 任何技术问题可以关注欧链小秘书、在欧链科技社区里向 OracleChain 团队提问 或者发送邮件到 contact@oraclechain.io。
 EOS 文档:https://eosio.github.io/eos/ 
EOS 代码:https://github.com/EOSIO/eos 
备注:OracleChain 团队使用 Mac 环境进行开发。
 
上一章中,我们通过源码研究了 EOS 合约执行机制。合约执行内容主要包括 三方面:合约发布和存储,合约执行环境的数据存取接口,以及状态数据持久化 等。依靠 web assemble 沙盒技术,让合约拥有与 native code 一样的执行速度。 与 bitcoin 相似,EOS 各节点通过 P2P 网络互联,相互传递 block 信息,任何 一个节点都可以参与验证和转发 block 信息,从而达成全网共识。而与 bitcoin 不同的是,EOS 内部采用 DPOS 的出块机制。每个节点可以选出代理,或者直 接投票,选出其信任的 21 个出块节点。这样做,既避免了出块权过于集中,又保证了共识机制不至于分叉(投票表决)。同时,这种投票保证的信任机制避免 了计算资源的浪费,将资源真正运用到 DAPP 的服务中。因此,我们可以把 EOS 合约,当作一个运行在“云”上的服务 
 
 
一、EOS 节点的功能和分类
 EOS 网络中,所有节点都可以参与验证/转发交易和区块,发现和维护一个 点对点网络。 EOS 网络节点可根据函数功能分为四个集合。开发者可以组合不同的集合, 发布符合自己需求的节点,加入到 EOS 网络中,再由这个节点为最终用户提供更 多差异化服务。
 
二、network(转发路由)
 所有节点都包含转发路由模块。通过这个模块,节点可以加入到 EOS 网络 中,参加对交易和区块的验证,发现和共享 p2p 连接池。另外,如果要投票或选 择代理人选出出块节点,就可以通过组合其他模块来实现。 要启动只带有转发和验证功能的节点,我们只需要在启动 eosd 的时候注释掉所有 plugin。config.ini 如下:
 
三、producer(验证出块) 
只有出块节点包含有效的 producer function。出块节点可以根据自己的资源 提供交易和存储服务。普通节点根据节点的价值偏好(可以是资源对应 token 的 单价),投票选出出块节点。选出的出块节点将组成一个网络,任意一个出块时 间段内,只有一个出块节点被全网授权去验证交易,并将交易打包成块。最后, block 被转发到其他节点验证和转发,全网达成共识。 启动一个 producer 节点时,需要在 config.ini 文件中启动 producer plugin,并 且配置出块节点相关数据:
 
四、wallet(保存私钥和发起交易)
 钱包用户都需要有 wallet api 来维护自己的 EOS 智能资产,例如桌面端的 EOS 客户端、钱包 app 等。对于资源吃紧的手机终端的钱包 app 来讲,由于不能保存 所有的账户信息,所以只保留用户相关的数据,并使用类似比特币的 SPV 技术,远程拉取交易所需信息并发出交易。 在 EOS 源码中,wallet 以 plugin 的形式提供对外服务,我们可以使用 eosc 对 这些接口进行简单调用。
在配置中,也需要指定加载 wallet plugin
 
五、blockchain functions(账号状态和交易历史)
 通常只有全节点才会使用 blockchain functions。blockchain 模块实际包含两 部分数据,一部分是保存着所有账号的状态机,另一部分是保存着所有历史交易 的 block 数据。全节点依靠自身保存的完整的账号状态和交易历史,可以在本地 独立地验证所有交易。 举个例子,对于出块节点来说,不一定会带有 wallet 模块,但一定会有带有 blockchain 模块。blockchain 模块是出块节点产生共识的基础数据,出块节点只有 遵守共识,产生的 block 数据才会被区块链所接受。 blockchain 模块也通过 http api 对外提供查询接口,我们可以使用 eosc 对这 些接口进行调用:
 
六、总结 
在 EOS 目前的版本之上,我们已经可以初步的搭建自己的测试网络,完成区 块链基本功能测试。我们相信再不久的将来,基于 EOS,将会开发出丰富的区块 链应用。
 
OracleChain 团队 2017 年 11 月 1 日
 
转自:欧链科技
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

EOS 编译、测试指南(四) --EOS 智能合约数据结构 API

EOS代码分析郑浩 发表了文章 • 0 个评论 • 50 次浏览 • 2017-11-07 15:13 • 来自相关话题

EOS 团队于 2017 年 9 月 14 日推出了 Dawn 1.0 release 版本,熟悉 Linux 和
C++的开发人员可以在此基础上尝试自己的合约开发了。OracleChain 团队一直以
来都在对 EOS 代码进行了编译和测试,陆续发布了三份《EOS 编译、测试指南》,
详细介绍了 EOS 的入门知识、基本结构,帮助开发人员学习、研究 EOS。基于
EOS 刚刚推出的 Dawn 1.0,OralceChain 团队进行了测试,本次将以代币的发行
为例,详细介绍 EOS 上 WASM 的数据库机制和智能合约的数据库 API,基于此开
发人员可以在 EOS 上发行自己的代币和开发钱包应用。
该指南主要依据 EOS 的官方文档,以及欧链团队的实践经验编写,开发者有
任何技术问题可以关注欧链小秘书、在欧链科技社区里向 OracleChain 团队提问
或者发送邮件到 contact@oraclechain.io。
EOS 文档:https://eosio.github.io/eos/
EOS 代码:https://github.com/EOSIO/eos
备注:OracleChain 团队使用 Mac 环境进行开发。
EOS.IO 的架构目标,是成为一个高效的消息分发平台,消息被分发到 account
(合约)中然后被高效地并发执行。
EOS 底层需要一个高效的沙盒运行环境。沙盒中,底层的脚本语言,执行环
境都是可以被替换的。在白皮书中,EOS 宣传支持 EVM 和 WASM 两种沙盒运行
环境。目前所知,WASM 的运行效率比 EVM 高很多,这点为 EOS 提供了有力的
竞争条件。高效的执行环境,提供了更快的交易反馈时间,从而在单个出块周期
处理更多的业务,可以运行更大规模的运算。



一、智能合约的数据库 API

EOS 的合约执行依赖于 WASM 的沙盒运行环境。
上一份指南中,OracleChain 团队分析了 block 数据结构的存储,EOS 使用
boost::interprocess,将 block 信息通过文件映射存储到磁盘上。
而在 EOS 合约执行过程中,所有的 account 状态都存储在沙盒的运行内存
中。EOS 对 account 的操作,通过调用 contract/eoslib/db.hpp 的 table 模版类,进
行类似于传统的增删查改操作。db.hpp 通过一个 c 接口,接入 WASM 沙盒环境,
实现了跨平台的储存机制。WASM 对数据存储的具体实现,依赖 chainbase.hpp
中,database 类实现的 mmap 数据存储接口。
account 的状态数据,均存储在一个 table 的数据结构中,我们可以在 db.hpp
中可以看到对其的实现:
template<uint64_t scope, uint64_t code, uint64_t table, typename Record, typename PrimaryType, typename SecondaryType = void>
 struct Table { 
… }
 struct Table<scope,code,table,Record,PrimaryType,void>
 {
 …
 } 
由此可见智能合约的数据结构大致如下: 
* - **scope** - an account where the data is stored
* - **code** - the account name which has write permission
 * - **table** - a name for the table that is being stored 
* - **record** - a row in the table
 * - **PrimaryType** - primary key in one record 
* - **SecondaryType** - secondary key in one record

开发者使用 db.hpp 调用中 C 或 C++包装的 api,来实现数据存取。
在每一条交易信息中会使用 scope 指定哪些账号需要对该消息读、写。code
决定了对应 account 可以采取的操作,这种操作权限和代码分离的设计提升了安
全性。同时,如果修改了不在 scope 中的 account 的信息或者执行了非 code 的操
作,会直接导致该交易失败。
以代币的发行实例来看 (代码部分参见 contract/currency.cpp),代币的所有
账户都以 Table 的形式存储: using Accounts = Table<N(currency),N(currency),N(account),Account,uint64_t>;
合约文件中,提供了初始化代币和代币转账接口,当代币合约被存储时,各
节点会自动执行一次合约中的 init 接口。当每次合约被调用,将调用合约中的apply 接口: 
 
extern "C" {
 void init() {
 storeAccount(N(currency),Account( CurrencyTokens(1000ll*1000ll*1000ll) ) ); 
}
 void apply( uint64_t code, uint64_t action ) {
 if( code == N(currency) ) {
 if( action == N(transfer) ) 
currency::apply_currency_transfer(currentMessage< 
TOKEN_NAME::Transfer >() ); 


}

table将不同scope/code/table的account数据,存储到了不同的内存映射中。
在 currency.cpp 合约中,eos 使用 table 实现了代币账户下各种业务逻辑。
当用户发行 currency 合约时,会用工具把 cpp 生成 currency.wast.cpp 文件,

同时需要一个 abi 文件作为第三方输入到合约的数据接口,接着 wasm-jit 会把
wast 代码,连同 abi 接口,一起存储到 tx 的 message 中,让其他节点验证并存
储此合约,等待合约被调用。
以下代码中,实现了打包 currency 合约到 transaction 中的流程:

types::setcode handler; handler.account = "currency";
auto wasm = assemble_wast( currency_wast ); 
handler.code.resize(wasm.size());
 memcpy( handler.code.data(), wasm.data(), wasm.size() );
eos::chain::SignedTransaction trx;
 trx.scope = {"currency"};
 trx.messages.resize(1); 
trx.messages[0].code = config::EosContractName; trx.messages[0].authorization.emplace_back(types::AccountPermission{"currenc y","active"}); transaction_set_message(trx, 0, "setcode", handler); 
trx.expiration = chain.head_block_time() + 100;
 transaction_set_reference_block(trx, chain.head_block_id()); 
chain.push_transaction(trx); 
chain.produce_blocks(1);
 

二、智能合约数据存储实例

智能合约中基础的功能之一是 token 在某种规则下的转移。以 EOS 提供的
token.cpp 为例,定义了 eos token 的数据结构:typedef eos::token<uint64_t,N(eos)> Tokens; 以 currency 合约为例。合约中,也用类 token 模版类生成了代币 currency: typedef eos::token<uint64_t,N(currency)> CurrencyTokens; 有了 eos token 和我们发行的子代币,我们就能编写合约,让用户使用不同
的代币进行交易。在 currency.cpp 或 exchange.cpp 中,eos 实现了发行代币、代
币流通、兑换功能。
eos 和自定义 currency 在流通时,都使用一个类似的 Transfer 结构体:
 
struct Transfer{ 
AccountName from; 
AccountName to;
 Tokens quantity; 
};

这样,在转账时,调用 currency.cpp 中实现的 abi 接口,传入 Transfer 结构
表明想要转账的 token 数量:
Transfer MeToYou;
 MeToYou.from = N(Me);
 MeToYou.to = N(You);
 MeToYou.quantity = Tokens(100);
当 eos 的合约处理接收到这样的请求时,会调用相关流程完成对对应 token
的处理。
void apply_transfer( const Transfer& transfer ) {
 auto from = getAccount( transfer.from ); 
auto to = getAccount( transfer.to ); 
from.balance -= transfer.quantity; to.balance += transfer.quantity; 
assertion storeAccount( transfer.from, from );
 storeAccount( transfer.to, to ); 
}
最终存储结果将保存到沙盒的内存中。

三、智能合约数据库的持久化
在沙盒机制中,当我们运行一个合约、发行一个代币时,EOS 为我们提供的
一些基础运行框架。其中最重要的两个:第一,实现了平台无关的 account 存储
机制;第二,提供了一个 account 间结算的业务平台。同时 EOS 会将沙盒里面的
数据存储接口储存在具体物理设备上来,实现数据的持久化。
在 chain/wasm_interface.cpp 中,对接了 wasm 的 context,并使用 context 获
取到 db.hpp 中实现的数据存储接口,然后将这些接口实现到了
message_handing_contexts.hpp 中。
 
chain/wasm_interface.cpp:
#define DEFINE_RECORD_UPDATE_FUNCTIONS(OBJTYPE, INDEX) \
DEFINE_INTRINSIC_FUNCTION4(env,store_##OBJTYPE,store_##OBJTYPE,i32,i64,scop e,i64,table,i32,valueptr,i32,valuelen) { \
UPDATE_RECORD(store_record, INDEX, valuelen); \
} \
DEFINE_INTRINSIC_FUNCTION4(env,update_##OBJTYPE,update_##OBJTYPE,i32,i64,s cope,i64,table,i32,valueptr,i32,valuelen) { \
UPDATE_RECORD(update_record, INDEX, valuelen); \
} \
DEFINE_INTRINSIC_FUNCTION3(env,remove_##OBJTYPE,remove_##OBJTYPE,i32,i64, scope,i64,table,i32,valueptr) { \
UPDATE_RECORD(remove_record, INDEX, sizeof(typename INDEX::value_type::key_type)*INDEX::value_type::number_of_keys); \ }

message_handing_contexts.hpp:
int32_t update_record( Name scope, Name code, Name table, typename ObjectType::key_type *keys, char* value, uint32_t valuelen )
int32_t remove_record( Name scope, Name code, Name table, typename ObjectType::key_type* keys, char* value, uint32_t valuelen )
int32_t load_record( Name scope, Name code, Name table, typename IndexType::value_type::key_type* keys, char* value, uint32_t valuelen ) 这样后面的处理流程就比较清晰了。当合约在读取数据时,将调用
message_handing_contexts.hpp 的 load_recod 接口:
template <typename IndexType, typename Scope>
int32_t load_record( Name scope, Name code, Name table, typename IndexType::value_type::key_type* keys, char* value, uint32_t valuelen ) {
const auto& idx = db.get_index<IndexType, Scope>();
auto tuple = load_record_tuple<typename IndexType::value_type, Scope>::get(scope, code, table, keys);
auto itr = idx.lower_bound(tuple);
… }
上面 load_record 代码中,调用了 db.get_index 方法。此处的 db 也就是
chainbase/chainbase.hpp 中实现的 database 类。database 中使用了 boost 的
managed_mapped_file,实现了对数据的存储和读取的接口。
在 EOS 提供的插件 plugins/chain_plugin/chain_plugin.hpp 中提供了一种从数
据库读取 table 的方法: get_table_rows_result get_table_rows( const get_table_rows_params& params )const;
利用这个方法开发者就能读取到合约目前的所有状态,开发属于自己的钱包
了。
 
 

四、总结
EOS.IO 发布的 Dawn 1.0 版本已经提供了开发智能合约的基本 API,本次
OracleChain 团队从数据库结构到持久化方法介绍了 EOS 智能合约的数据库 API。
基于这些 API,开发者就可以开发出自己的钱包。
转自:欧链科技
 
  查看全部

EOS 团队于 2017 年 9 月 14 日推出了 Dawn 1.0 release 版本,熟悉 Linux 和
C++的开发人员可以在此基础上尝试自己的合约开发了。OracleChain 团队一直以
来都在对 EOS 代码进行了编译和测试,陆续发布了三份《EOS 编译、测试指南》,
详细介绍了 EOS 的入门知识、基本结构,帮助开发人员学习、研究 EOS。基于
EOS 刚刚推出的 Dawn 1.0,OralceChain 团队进行了测试,本次将以代币的发行
为例,详细介绍 EOS 上 WASM 的数据库机制和智能合约的数据库 API,基于此开
发人员可以在 EOS 上发行自己的代币和开发钱包应用。
该指南主要依据 EOS 的官方文档,以及欧链团队的实践经验编写,开发者有
任何技术问题可以关注欧链小秘书、在欧链科技社区里向 OracleChain 团队提问
或者发送邮件到 contact@oraclechain.io。
EOS 文档:https://eosio.github.io/eos/
EOS 代码:https://github.com/EOSIO/eos
备注:OracleChain 团队使用 Mac 环境进行开发。
EOS.IO 的架构目标,是成为一个高效的消息分发平台,消息被分发到 account
(合约)中然后被高效地并发执行。
EOS 底层需要一个高效的沙盒运行环境。沙盒中,底层的脚本语言,执行环
境都是可以被替换的。在白皮书中,EOS 宣传支持 EVM 和 WASM 两种沙盒运行
环境。目前所知,WASM 的运行效率比 EVM 高很多,这点为 EOS 提供了有力的
竞争条件。高效的执行环境,提供了更快的交易反馈时间,从而在单个出块周期
处理更多的业务,可以运行更大规模的运算。



一、智能合约的数据库 API

EOS 的合约执行依赖于 WASM 的沙盒运行环境。
上一份指南中,OracleChain 团队分析了 block 数据结构的存储,EOS 使用
boost::interprocess,将 block 信息通过文件映射存储到磁盘上。
而在 EOS 合约执行过程中,所有的 account 状态都存储在沙盒的运行内存
中。EOS 对 account 的操作,通过调用 contract/eoslib/db.hpp 的 table 模版类,进
行类似于传统的增删查改操作。db.hpp 通过一个 c 接口,接入 WASM 沙盒环境,
实现了跨平台的储存机制。WASM 对数据存储的具体实现,依赖 chainbase.hpp
中,database 类实现的 mmap 数据存储接口。
account 的状态数据,均存储在一个 table 的数据结构中,我们可以在 db.hpp
中可以看到对其的实现:
template<uint64_t scope, uint64_t code, uint64_t table, typename Record, typename PrimaryType, typename SecondaryType = void>
 struct Table { 
… }
 struct Table<scope,code,table,Record,PrimaryType,void>
 {
 …
 } 
由此可见智能合约的数据结构大致如下: 
* - **scope** - an account where the data is stored
* - **code** - the account name which has write permission
 * - **table** - a name for the table that is being stored 
* - **record** - a row in the table
 * - **PrimaryType** - primary key in one record 
* - **SecondaryType** - secondary key in one record

开发者使用 db.hpp 调用中 C 或 C++包装的 api,来实现数据存取。
在每一条交易信息中会使用 scope 指定哪些账号需要对该消息读、写。code
决定了对应 account 可以采取的操作,这种操作权限和代码分离的设计提升了安
全性。同时,如果修改了不在 scope 中的 account 的信息或者执行了非 code 的操
作,会直接导致该交易失败。
以代币的发行实例来看 (代码部分参见 contract/currency.cpp),代币的所有
账户都以 Table 的形式存储: using Accounts = Table<N(currency),N(currency),N(account),Account,uint64_t>;
合约文件中,提供了初始化代币和代币转账接口,当代币合约被存储时,各
节点会自动执行一次合约中的 init 接口。当每次合约被调用,将调用合约中的apply 接口: 
 
extern "C" {
 void init() {
 storeAccount(N(currency),Account( CurrencyTokens(1000ll*1000ll*1000ll) ) ); 
}
 void apply( uint64_t code, uint64_t action ) {
 if( code == N(currency) ) {
 if( action == N(transfer) ) 
currency::apply_currency_transfer(currentMessage< 
TOKEN_NAME::Transfer >() ); 


}

table将不同scope/code/table的account数据,存储到了不同的内存映射中。
在 currency.cpp 合约中,eos 使用 table 实现了代币账户下各种业务逻辑。
当用户发行 currency 合约时,会用工具把 cpp 生成 currency.wast.cpp 文件,

同时需要一个 abi 文件作为第三方输入到合约的数据接口,接着 wasm-jit 会把
wast 代码,连同 abi 接口,一起存储到 tx 的 message 中,让其他节点验证并存
储此合约,等待合约被调用。
以下代码中,实现了打包 currency 合约到 transaction 中的流程:

types::setcode handler; handler.account = "currency";
auto wasm = assemble_wast( currency_wast ); 
handler.code.resize(wasm.size());
 memcpy( handler.code.data(), wasm.data(), wasm.size() );
eos::chain::SignedTransaction trx;
 trx.scope = {"currency"};
 trx.messages.resize(1); 
trx.messages[0].code = config::EosContractName; trx.messages[0].authorization.emplace_back(types::AccountPermission{"currenc y","active"}); transaction_set_message(trx, 0, "setcode", handler); 
trx.expiration = chain.head_block_time() + 100;
 transaction_set_reference_block(trx, chain.head_block_id()); 
chain.push_transaction(trx); 
chain.produce_blocks(1);
 

二、智能合约数据存储实例

智能合约中基础的功能之一是 token 在某种规则下的转移。以 EOS 提供的
token.cpp 为例,定义了 eos token 的数据结构:typedef eos::token<uint64_t,N(eos)> Tokens; 以 currency 合约为例。合约中,也用类 token 模版类生成了代币 currency: typedef eos::token<uint64_t,N(currency)> CurrencyTokens; 有了 eos token 和我们发行的子代币,我们就能编写合约,让用户使用不同
的代币进行交易。在 currency.cpp 或 exchange.cpp 中,eos 实现了发行代币、代
币流通、兑换功能。
eos 和自定义 currency 在流通时,都使用一个类似的 Transfer 结构体:
 
struct Transfer{ 
AccountName from; 
AccountName to;
 Tokens quantity; 
};

这样,在转账时,调用 currency.cpp 中实现的 abi 接口,传入 Transfer 结构
表明想要转账的 token 数量:
Transfer MeToYou;
 MeToYou.from = N(Me);
 MeToYou.to = N(You);
 MeToYou.quantity = Tokens(100);
当 eos 的合约处理接收到这样的请求时,会调用相关流程完成对对应 token
的处理。
void apply_transfer( const Transfer& transfer ) {
 auto from = getAccount( transfer.from ); 
auto to = getAccount( transfer.to ); 
from.balance -= transfer.quantity; to.balance += transfer.quantity; 
assertion storeAccount( transfer.from, from );
 storeAccount( transfer.to, to ); 
}
最终存储结果将保存到沙盒的内存中。

三、智能合约数据库的持久化
在沙盒机制中,当我们运行一个合约、发行一个代币时,EOS 为我们提供的
一些基础运行框架。其中最重要的两个:第一,实现了平台无关的 account 存储
机制;第二,提供了一个 account 间结算的业务平台。同时 EOS 会将沙盒里面的
数据存储接口储存在具体物理设备上来,实现数据的持久化。
在 chain/wasm_interface.cpp 中,对接了 wasm 的 context,并使用 context 获
取到 db.hpp 中实现的数据存储接口,然后将这些接口实现到了
message_handing_contexts.hpp 中。
 
chain/wasm_interface.cpp:
#define DEFINE_RECORD_UPDATE_FUNCTIONS(OBJTYPE, INDEX) \
DEFINE_INTRINSIC_FUNCTION4(env,store_##OBJTYPE,store_##OBJTYPE,i32,i64,scop e,i64,table,i32,valueptr,i32,valuelen) { \
UPDATE_RECORD(store_record, INDEX, valuelen); \
} \
DEFINE_INTRINSIC_FUNCTION4(env,update_##OBJTYPE,update_##OBJTYPE,i32,i64,s cope,i64,table,i32,valueptr,i32,valuelen) { \
UPDATE_RECORD(update_record, INDEX, valuelen); \
} \
DEFINE_INTRINSIC_FUNCTION3(env,remove_##OBJTYPE,remove_##OBJTYPE,i32,i64, scope,i64,table,i32,valueptr) { \
UPDATE_RECORD(remove_record, INDEX, sizeof(typename INDEX::value_type::key_type)*INDEX::value_type::number_of_keys); \ }

message_handing_contexts.hpp:
int32_t update_record( Name scope, Name code, Name table, typename ObjectType::key_type *keys, char* value, uint32_t valuelen )
int32_t remove_record( Name scope, Name code, Name table, typename ObjectType::key_type* keys, char* value, uint32_t valuelen )
int32_t load_record( Name scope, Name code, Name table, typename IndexType::value_type::key_type* keys, char* value, uint32_t valuelen )
这样后面的处理流程就比较清晰了。当合约在读取数据时,将调用
message_handing_contexts.hpp 的 load_recod 接口:
template	<typename	IndexType,	typename	Scope>
int32_t load_record( Name scope, Name code, Name table, typename IndexType::value_type::key_type* keys, char* value, uint32_t valuelen ) {
const auto& idx = db.get_index<IndexType, Scope>();
auto tuple = load_record_tuple<typename IndexType::value_type, Scope>::get(scope, code, table, keys);
auto itr = idx.lower_bound(tuple);
… }

上面 load_record 代码中,调用了 db.get_index 方法。此处的 db 也就是
chainbase/chainbase.hpp 中实现的 database 类。database 中使用了 boost 的
managed_mapped_file,实现了对数据的存储和读取的接口。
在 EOS 提供的插件 plugins/chain_plugin/chain_plugin.hpp 中提供了一种从数
据库读取 table 的方法: get_table_rows_result get_table_rows( const get_table_rows_params& params )const;
利用这个方法开发者就能读取到合约目前的所有状态,开发属于自己的钱包
了。
 
 

四、总结
EOS.IO 发布的 Dawn 1.0 版本已经提供了开发智能合约的基本 API,本次
OracleChain 团队从数据库结构到持久化方法介绍了 EOS 智能合约的数据库 API。
基于这些 API,开发者就可以开发出自己的钱包。
转自:欧链科技
 
 

DPOS如何预防DDOS攻击

EOS其他相关郑浩 回复了问题 • 3 人关注 • 1 个回复 • 67 次浏览 • 2017-10-26 16:50 • 来自相关话题

授权股权证明机制白皮书(Delegated Proof-of-Stake ,DPOS)

EOS其他相关郑浩 发表了文章 • 0 个评论 • 45 次浏览 • 2017-10-26 16:27 • 来自相关话题

授权股权证明机制白皮书
(Delegated Proof-of-Stake ,DPOS)
作者: Daniel Larimer
April 3, 2014
翻译:yidaidaxia_郝晓曦
比特坊数字资产研究俱乐部 翻译作品(www.bitfarm.io)

摘要
本白皮书介绍一种股权证明机制的新实现方式,该方式可以对交易进行秒级验证,并且能够在更短的时间内提供比现有任何股权证明系统都更好的安全性。在比特币网络产生一个区块的时间过后,一个授权股权证明系统(DPOS)能使你的交易得到20%股东的核实,而在比特币网络声明交易已几乎不可逆(6个区块,约1小时)的时间过后,在DPOS机制下,通过其代表,你的交易已经得到100%股东的核实。

1.0 背景
分布式交易总账需要在尽可能短的时间内做到安全、明确及不可逆,便于提供一个最坚实且去中心化的系统。在实践中,该流程分为两个方面:选择一个独特的节点来产生一个区块,并使得交易总账不可逆。

1.1 工作量证明机制(Proof of Work, POW)
第一个成功解决该问题的尝试是比特币系统(Bitcoin),比特币系统使用工作量证明机制使更长总账的产生具有计算性难度。工作量证明机制就好比是乐透,平均每10分钟有一个节点找到一个区块。如果两个节点在同一个时间找到区块,那么网络将根据后续节点的决定来确定以哪个区块构建总账。从统计学角度讲,一笔交易在6个区块(约1个小时)后被认为是明确确认且不可逆的。然而,核心开发者认为,需要120个区块(约一天),才能充分保护网络不受来自潜在更长的已将新产生的币花掉的攻击区块链的威胁。
尽管出现更长的区块链会变得不太可能,但任何拥有巨大经济资源的人都仍有可能制造一个更长的区块链或者具备足够的哈希算力来冻结用户的账户。

1.2 股权证明机制(Proof of Stake, POS)
股权证明机制已有很多不同变种,但基本概念是产生区块的难度应该与你在网络里所占的股权(所有权占比)成比例。到目前为止,已有两个系统开始运行:点点币(Peercoin)和未来币(NXT)。点点币使用一种混合模式,用你的股权调整你的挖矿难度。未来币使用一个确定性算法以随机选择一个股东来产生下一个区块。未来币算法基于你的账户余额来调整你被选中的可能性。
未来币和点点币都分别解决了谁来生产下一个区块的问题,但他们没有找到在适当的时间内使区块链具备不可逆的安全性的方法。根据我们能找到的信息,做到这点,点点币需要至少6个区块(约一小时),未来币需要10个区块。我们找不到在10个区块后未来币能提供什么级别安全性的根据。
我们之前发布了基于交易的股权证明机制(Transactions as Proof of Stake, TaPOS)的白皮书,在该机制中,每笔交易都包含区块链中前一个区块的哈希值。通过该系统,对任何人而言,网络变得越来越安全而不可逆,因为最终每个区块都经过了股东投票。股权证明机制面临的挑战是它没有定义谁来产生下一个区块。

1.3 瑞波共识机制(Ripple Consensus)
瑞波共识算法,使一组节点能够基于特殊节点列表达成共识。初始特殊节点列表就像一个俱乐部,要接纳一个新成员,必须由51%的该俱乐部会员投票通过。共识遵循这核心成员的51%权力,外部人员则没有影响力。由于该俱乐部由“中心化”开始,它将一直是“中心化的”,而如果它开始腐化,股东们什么也做不了。与比特币及点点币一样,瑞波系统将股东们与其投票权隔开,并因此比其他系统更中心化。

2.0 授权股权证明机制(DPOS)
当使用去中心化自治公司(Decentralized Autonomous Company, DAC)这一说法时,去中心化表示每个股东按其持股比例拥有影响力,51%股东投票的结果将是不可逆且有约束力的。其挑战是通过及时而高效的方法达到51%批准。
为达到这个目标,每个股东可以将其投票权授予一名代表。获票数最多的前100位代表按既定时间表轮流产生区块。每名代表分配到一个时间段来生产区块。所有的代表将收到等同于一个平均水平的区块所含交易费的10%作为报酬。如果一个平均水平的区块含有100股作为交易费,一名代表将获得1股作为报酬。
网络延迟有可能使某些代表没能及时广播他们的区块,而这将导致区块链分叉。然而,这不太可能发生,因为制造区块的代表可以与制造前后区块的代表建立直接连接。建立这种与你之后的代表(也许也包括其后的那名代表)的直接连接是为了确保你能得到报酬。
该模式可以每30秒产生一个新区块,并且在正常的网络条件下区块链分叉的可能性极其小,即使发生也可以在几分钟内得到解决。

2.1 成为一名代表
成为一名代表,你必须在网络上注册你的公钥,然后分配到一个32位的特有标识符。然后该标识符会被每笔交易数据的“头部”引用。

2.2 授权你的选票
每个钱包有一个参数设置窗口,在该窗口里用户可以选择一个或更多的代表,并将其分级。一经设定,用户所做的每笔交易将把选票从“输入代表”转移至“输出代表”。一般情况下,用户不会创建特别以投票为目的的交易,因为那将耗费他们一笔交易费。但在紧急情况下,某些用户可能觉得通过支付费用这一更积极的方式来改变他们的投票是值得的。 

2.3 保持代表诚实
每个钱包将显示一个状态指示器,让用户知道他们的代表表现如何。如果他们错过了太多的区块,那么系统将会推荐用户去换一个新的代表。如果任何代表被发现签发了一个无效的区块,那么所有标准钱包将在每个钱包进行更多交易前要求选出一个新代表。

2.4 解决区块链分叉
和工作量证明系统及其他股权证明系统一样,最佳区块链是最长的有效区块链。任何时候,一名代表错过签发一个区块的机会,该区块链将比潜在竞争对手短。只要在你的交易被写入区块后的100个区块中的51%被生产出来了,那么你就可以安全地认为你在主区块链上。
也许,在防止区块链分叉所导致的损失方面,最重要的事是在事发后第一时间得知消息。因为代表们通过生产区块得到很好的报酬,他们将保持接近100%的在线时间来防止因被投票罢免而损失收入。你可以安全地认为如果在过去的10个区块中,有一两个区块错过生产,则互联网的某些部分可能正发生连接问题,那么用户应该对此特别警觉并要求额外的确认数。如果10区块中有超过5个错过生产,那么这意味着你很可能在一条支链上,因此应该停止所有交易,直到分叉得到解决。
以一种及时的方式(少于5分钟)简单地发现并警示用户网络分叉,是可以最小化潜在损失的非常重要的能力。而知道你是否正处在一条支链上则更为重要。

2.5 100名代表是去中心化的吗?
因为去中心化已经成为一个流行术语,所以其定义很难完全固定。我们将自由市场看作去中心化的基本形式,并将对进入自由市场设置障碍看作是所有中心化的基础。像任何事物一样,中心化有程度之分,所以我们把授权股权证明机制与其它方案的中心化程度进行对比。

2.5.1 比特币
比特币系统目前正以授权工作量证明(Delegated Proof of Work, DPOW)为基础而运行,因此有大约10名代表控制了绝大多数的哈希算力。在那些为其竞争而能使用规模经济进行无收益挖矿的人手中,哈希算力本身就是中心化的。最后,工作量证明机制为进入市场设置障碍,使得“在职”的区块制造者无法轻易被取代。与比特币系统相比,DPOS在区块生产方面至少去中西化了10倍,并且也许在市场竞争方面去中心化了无数倍。
尽管在哈希算力方面有一定量的去中心化,当想到掌控比特币系统的股东(比特币持有者)所持股份的占比,我们认为比特币系统是最中心化的。如果你考虑使用比特币体系的用户总数,其中参与挖矿的人很可能少于百分之一。

2.5.2 点点币
点点币是一个混合系统,所以它由于工作量证明机制而是部分中心化的。和比特币系统一样,它也有矿池。与比特币相比,点点币无疑是更去中心化的,然而,因为股权证明机制矿池需要用户保持他们的电脑在线且钱包解锁,只有一小部分的股东参与了任何形式的挖矿。

2.5.3 未来币
未来币使用透明锻造,以确定的选出下一个制造节点。可以将其类比为,使用授权股权证明机制但你只能将你的投票权授予你自己,而你获得锻造区块机会的频率直接取决于你的账户余额。在这个意义上来说,未来币比点点币和比特币更为去中心化。但由于对安全风险的顾虑以及事实上大多数常规用户不会整天开启他们的电脑来籍此获得锻造机会方面的优势,它仍然遭受着少的可怜的挖矿参与度。
从这个角度来讲,我们可以断定未来币网络是由一小部分股东来保障网络安全的。事实上,如果你不上线投票,那么你将失去你的选票。为了解决这个问题,一些未来币用户用他们的股权建立股权池,并信任第三方来为他们挖矿。这是以一种形式的授权股权证明来提高股东参与度,但这也使他们的账户余额在他们参加这些矿池时承受风险。

3.0 攻击
一般而言,网络必须抵御两种类型的攻击:拒绝服务攻击和双重支付攻击。一个攻击者通过不把一些或全部的交易加入总账来进行拒绝服务攻击。这种攻击可以由任何拥有51%网络(无论比特币、未来币或其它)的人进行。而利用在网络正试图达成共识时的短期优势,可以进行双重支付攻击。
为抵御这些攻击,网络必须使51%的股东尽快达成协议。

3.1 防止排除交易
拥有全部经股东投票选出的100名代表,并且按要求轮流生产区块,意味着任何一笔由至少1%的股东批准的交易能够在30分钟内加入总账。这意味着没有代表可以通过将投票支持其他代表的交易排除在外来获取利益。

3.2 将一些代表的权力中心化
与其所被授权的投票权无关,这前100人所获得的权力权重是相同的,每名代表都有一份相等的投票权。因此,无法通过获得超过1%的选票而将权力集中到一个单一代表手上。
个人或者组织控制区块链的多名代表是有可能的。但是这个过程将需要欺骗很大比例的股东数去支持“傀儡”。
即使可以建立这51%傀儡,他们扰乱网络的能力仍将是有限的、能够被快速识别快速纠正的。没有工作量证明机制设置的进入障碍,占据多数的诚实用户会把攻击鉴别出来,然后将代码分叉并无视攻击者生产的区块。这种攻击可以扰乱网络,但不会是致命的。

3.3 针对代表的分布式拒绝服务攻击(DDOS)
因为只有100名代表,   可以想象一个攻击者对每名轮到生产区块的代表依次进行拒绝服务攻击。幸运的是,由于事实上每名代表的标识是其公钥而非IP地址,这种特定攻击的威胁很容易被减轻。这将使确定DDOS攻击目标更为困难。而代表之间的潜在直接连接,将使妨碍他们生产区块变得更为困难。

4.0 基于交易的股权证明机制(TaPOS)
代表制是一个短时间内达成坚固共识的高效方式,而TaPOS为股东们提供了一个长效机制来直接批准他们的代表的行为。平均而言,51%的股东在6个月内会直接确认每个区块。而取决于活跃流通的股份所占的比例,差不多10%的股东可以在几天内确认区块链。这种直接确认保障了网络的长期安全,并使所有的攻击尝试变得极度清晰易见。

5.0 高质量的服务
假设一个DPOS系统拥有10亿美元的市场总量,平均每年的交易费为0.25%,代表们合计获得所有交易费的10%,那么每名代表每年能获得25,000美元以使其节点保持在线。
这是一个利润可观的角色,许多人将为获取它持续竞争。这意味着每个想要获得这份工作的人都会想方设法从拥有这份工作的人那里把它“偷走”。为做到这点,他们将对代表行为进行统计学分析,以找到对于标准算法的任何偏离行为。一旦找到这种偏离,他们就能有希望赢得一些选票。
那些拥有这份工作的人,可能会全力以赴地证明他们正在按标准软件运行。他们越有效地证明其对区块生产的正直性,越有可能保住他们的工作。你可以想象开发者会很快制作出系统,代表们可以通过这些系统快速证明哪些交易得到了广泛的散播。
事实上,市场竞争将产生用以证明代表们的正直性与可靠性的最具创造性的解决方案。让网络变得更安全的工作可以获得很多收益,而尝试绕轮网络则得不到什么好处。

6.0 结论
DPOS流程与TaPOS结合所产生的网络,其网络共识的可证明性将至少3倍于比特币、点点币及未来币网络。DPOS能够更快地达成共识,同时消除随机小股东带来小规模干扰的可能性。经济激励确保了代表们致力于证明他们有良好行为,并可能采用类似于瑞波系统的共识算法(来实现这种证明)。DPOS,事实上,是一种通过无网络分叉之虞的去中心化方式来产生瑞波特殊节点列表的方法。 查看全部
授权股权证明机制白皮书
(Delegated Proof-of-Stake ,DPOS)
作者: Daniel Larimer
April 3, 2014
翻译:yidaidaxia_郝晓曦
比特坊数字资产研究俱乐部 翻译作品(www.bitfarm.io)

摘要
本白皮书介绍一种股权证明机制的新实现方式,该方式可以对交易进行秒级验证,并且能够在更短的时间内提供比现有任何股权证明系统都更好的安全性。在比特币网络产生一个区块的时间过后,一个授权股权证明系统(DPOS)能使你的交易得到20%股东的核实,而在比特币网络声明交易已几乎不可逆(6个区块,约1小时)的时间过后,在DPOS机制下,通过其代表,你的交易已经得到100%股东的核实。

1.0 背景
分布式交易总账需要在尽可能短的时间内做到安全、明确及不可逆,便于提供一个最坚实且去中心化的系统。在实践中,该流程分为两个方面:选择一个独特的节点来产生一个区块,并使得交易总账不可逆。

1.1 工作量证明机制(Proof of Work, POW)
第一个成功解决该问题的尝试是比特币系统(Bitcoin),比特币系统使用工作量证明机制使更长总账的产生具有计算性难度。工作量证明机制就好比是乐透,平均每10分钟有一个节点找到一个区块。如果两个节点在同一个时间找到区块,那么网络将根据后续节点的决定来确定以哪个区块构建总账。从统计学角度讲,一笔交易在6个区块(约1个小时)后被认为是明确确认且不可逆的。然而,核心开发者认为,需要120个区块(约一天),才能充分保护网络不受来自潜在更长的已将新产生的币花掉的攻击区块链的威胁。
尽管出现更长的区块链会变得不太可能,但任何拥有巨大经济资源的人都仍有可能制造一个更长的区块链或者具备足够的哈希算力来冻结用户的账户。

1.2 股权证明机制(Proof of Stake, POS)
股权证明机制已有很多不同变种,但基本概念是产生区块的难度应该与你在网络里所占的股权(所有权占比)成比例。到目前为止,已有两个系统开始运行:点点币(Peercoin)和未来币(NXT)。点点币使用一种混合模式,用你的股权调整你的挖矿难度。未来币使用一个确定性算法以随机选择一个股东来产生下一个区块。未来币算法基于你的账户余额来调整你被选中的可能性。
未来币和点点币都分别解决了谁来生产下一个区块的问题,但他们没有找到在适当的时间内使区块链具备不可逆的安全性的方法。根据我们能找到的信息,做到这点,点点币需要至少6个区块(约一小时),未来币需要10个区块。我们找不到在10个区块后未来币能提供什么级别安全性的根据。
我们之前发布了基于交易的股权证明机制(Transactions as Proof of Stake, TaPOS)的白皮书,在该机制中,每笔交易都包含区块链中前一个区块的哈希值。通过该系统,对任何人而言,网络变得越来越安全而不可逆,因为最终每个区块都经过了股东投票。股权证明机制面临的挑战是它没有定义谁来产生下一个区块。

1.3 瑞波共识机制(Ripple Consensus)
瑞波共识算法,使一组节点能够基于特殊节点列表达成共识。初始特殊节点列表就像一个俱乐部,要接纳一个新成员,必须由51%的该俱乐部会员投票通过。共识遵循这核心成员的51%权力,外部人员则没有影响力。由于该俱乐部由“中心化”开始,它将一直是“中心化的”,而如果它开始腐化,股东们什么也做不了。与比特币及点点币一样,瑞波系统将股东们与其投票权隔开,并因此比其他系统更中心化。

2.0 授权股权证明机制(DPOS)
当使用去中心化自治公司(Decentralized Autonomous Company, DAC)这一说法时,去中心化表示每个股东按其持股比例拥有影响力,51%股东投票的结果将是不可逆且有约束力的。其挑战是通过及时而高效的方法达到51%批准。
为达到这个目标,每个股东可以将其投票权授予一名代表。获票数最多的前100位代表按既定时间表轮流产生区块。每名代表分配到一个时间段来生产区块。所有的代表将收到等同于一个平均水平的区块所含交易费的10%作为报酬。如果一个平均水平的区块含有100股作为交易费,一名代表将获得1股作为报酬。
网络延迟有可能使某些代表没能及时广播他们的区块,而这将导致区块链分叉。然而,这不太可能发生,因为制造区块的代表可以与制造前后区块的代表建立直接连接。建立这种与你之后的代表(也许也包括其后的那名代表)的直接连接是为了确保你能得到报酬。
该模式可以每30秒产生一个新区块,并且在正常的网络条件下区块链分叉的可能性极其小,即使发生也可以在几分钟内得到解决。

2.1 成为一名代表
成为一名代表,你必须在网络上注册你的公钥,然后分配到一个32位的特有标识符。然后该标识符会被每笔交易数据的“头部”引用。

2.2 授权你的选票
每个钱包有一个参数设置窗口,在该窗口里用户可以选择一个或更多的代表,并将其分级。一经设定,用户所做的每笔交易将把选票从“输入代表”转移至“输出代表”。一般情况下,用户不会创建特别以投票为目的的交易,因为那将耗费他们一笔交易费。但在紧急情况下,某些用户可能觉得通过支付费用这一更积极的方式来改变他们的投票是值得的。 

2.3 保持代表诚实
每个钱包将显示一个状态指示器,让用户知道他们的代表表现如何。如果他们错过了太多的区块,那么系统将会推荐用户去换一个新的代表。如果任何代表被发现签发了一个无效的区块,那么所有标准钱包将在每个钱包进行更多交易前要求选出一个新代表。

2.4 解决区块链分叉
和工作量证明系统及其他股权证明系统一样,最佳区块链是最长的有效区块链。任何时候,一名代表错过签发一个区块的机会,该区块链将比潜在竞争对手短。只要在你的交易被写入区块后的100个区块中的51%被生产出来了,那么你就可以安全地认为你在主区块链上。
也许,在防止区块链分叉所导致的损失方面,最重要的事是在事发后第一时间得知消息。因为代表们通过生产区块得到很好的报酬,他们将保持接近100%的在线时间来防止因被投票罢免而损失收入。你可以安全地认为如果在过去的10个区块中,有一两个区块错过生产,则互联网的某些部分可能正发生连接问题,那么用户应该对此特别警觉并要求额外的确认数。如果10区块中有超过5个错过生产,那么这意味着你很可能在一条支链上,因此应该停止所有交易,直到分叉得到解决。
以一种及时的方式(少于5分钟)简单地发现并警示用户网络分叉,是可以最小化潜在损失的非常重要的能力。而知道你是否正处在一条支链上则更为重要。

2.5 100名代表是去中心化的吗?
因为去中心化已经成为一个流行术语,所以其定义很难完全固定。我们将自由市场看作去中心化的基本形式,并将对进入自由市场设置障碍看作是所有中心化的基础。像任何事物一样,中心化有程度之分,所以我们把授权股权证明机制与其它方案的中心化程度进行对比。

2.5.1 比特币
比特币系统目前正以授权工作量证明(Delegated Proof of Work, DPOW)为基础而运行,因此有大约10名代表控制了绝大多数的哈希算力。在那些为其竞争而能使用规模经济进行无收益挖矿的人手中,哈希算力本身就是中心化的。最后,工作量证明机制为进入市场设置障碍,使得“在职”的区块制造者无法轻易被取代。与比特币系统相比,DPOS在区块生产方面至少去中西化了10倍,并且也许在市场竞争方面去中心化了无数倍。
尽管在哈希算力方面有一定量的去中心化,当想到掌控比特币系统的股东(比特币持有者)所持股份的占比,我们认为比特币系统是最中心化的。如果你考虑使用比特币体系的用户总数,其中参与挖矿的人很可能少于百分之一。

2.5.2 点点币
点点币是一个混合系统,所以它由于工作量证明机制而是部分中心化的。和比特币系统一样,它也有矿池。与比特币相比,点点币无疑是更去中心化的,然而,因为股权证明机制矿池需要用户保持他们的电脑在线且钱包解锁,只有一小部分的股东参与了任何形式的挖矿。

2.5.3 未来币
未来币使用透明锻造,以确定的选出下一个制造节点。可以将其类比为,使用授权股权证明机制但你只能将你的投票权授予你自己,而你获得锻造区块机会的频率直接取决于你的账户余额。在这个意义上来说,未来币比点点币和比特币更为去中心化。但由于对安全风险的顾虑以及事实上大多数常规用户不会整天开启他们的电脑来籍此获得锻造机会方面的优势,它仍然遭受着少的可怜的挖矿参与度。
从这个角度来讲,我们可以断定未来币网络是由一小部分股东来保障网络安全的。事实上,如果你不上线投票,那么你将失去你的选票。为了解决这个问题,一些未来币用户用他们的股权建立股权池,并信任第三方来为他们挖矿。这是以一种形式的授权股权证明来提高股东参与度,但这也使他们的账户余额在他们参加这些矿池时承受风险。

3.0 攻击
一般而言,网络必须抵御两种类型的攻击:拒绝服务攻击和双重支付攻击。一个攻击者通过不把一些或全部的交易加入总账来进行拒绝服务攻击。这种攻击可以由任何拥有51%网络(无论比特币、未来币或其它)的人进行。而利用在网络正试图达成共识时的短期优势,可以进行双重支付攻击。
为抵御这些攻击,网络必须使51%的股东尽快达成协议。

3.1 防止排除交易
拥有全部经股东投票选出的100名代表,并且按要求轮流生产区块,意味着任何一笔由至少1%的股东批准的交易能够在30分钟内加入总账。这意味着没有代表可以通过将投票支持其他代表的交易排除在外来获取利益。

3.2 将一些代表的权力中心化
与其所被授权的投票权无关,这前100人所获得的权力权重是相同的,每名代表都有一份相等的投票权。因此,无法通过获得超过1%的选票而将权力集中到一个单一代表手上。
个人或者组织控制区块链的多名代表是有可能的。但是这个过程将需要欺骗很大比例的股东数去支持“傀儡”。
即使可以建立这51%傀儡,他们扰乱网络的能力仍将是有限的、能够被快速识别快速纠正的。没有工作量证明机制设置的进入障碍,占据多数的诚实用户会把攻击鉴别出来,然后将代码分叉并无视攻击者生产的区块。这种攻击可以扰乱网络,但不会是致命的。

3.3 针对代表的分布式拒绝服务攻击(DDOS)
因为只有100名代表,   可以想象一个攻击者对每名轮到生产区块的代表依次进行拒绝服务攻击。幸运的是,由于事实上每名代表的标识是其公钥而非IP地址,这种特定攻击的威胁很容易被减轻。这将使确定DDOS攻击目标更为困难。而代表之间的潜在直接连接,将使妨碍他们生产区块变得更为困难。

4.0 基于交易的股权证明机制(TaPOS)
代表制是一个短时间内达成坚固共识的高效方式,而TaPOS为股东们提供了一个长效机制来直接批准他们的代表的行为。平均而言,51%的股东在6个月内会直接确认每个区块。而取决于活跃流通的股份所占的比例,差不多10%的股东可以在几天内确认区块链。这种直接确认保障了网络的长期安全,并使所有的攻击尝试变得极度清晰易见。

5.0 高质量的服务
假设一个DPOS系统拥有10亿美元的市场总量,平均每年的交易费为0.25%,代表们合计获得所有交易费的10%,那么每名代表每年能获得25,000美元以使其节点保持在线。
这是一个利润可观的角色,许多人将为获取它持续竞争。这意味着每个想要获得这份工作的人都会想方设法从拥有这份工作的人那里把它“偷走”。为做到这点,他们将对代表行为进行统计学分析,以找到对于标准算法的任何偏离行为。一旦找到这种偏离,他们就能有希望赢得一些选票。
那些拥有这份工作的人,可能会全力以赴地证明他们正在按标准软件运行。他们越有效地证明其对区块生产的正直性,越有可能保住他们的工作。你可以想象开发者会很快制作出系统,代表们可以通过这些系统快速证明哪些交易得到了广泛的散播。
事实上,市场竞争将产生用以证明代表们的正直性与可靠性的最具创造性的解决方案。让网络变得更安全的工作可以获得很多收益,而尝试绕轮网络则得不到什么好处。

6.0 结论
DPOS流程与TaPOS结合所产生的网络,其网络共识的可证明性将至少3倍于比特币、点点币及未来币网络。DPOS能够更快地达成共识,同时消除随机小股东带来小规模干扰的可能性。经济激励确保了代表们致力于证明他们有良好行为,并可能采用类似于瑞波系统的共识算法(来实现这种证明)。DPOS,事实上,是一种通过无网络分叉之虞的去中心化方式来产生瑞波特殊节点列表的方法。

大家都能看懂的 EOS 知识

EOS其他相关admin 发表了文章 • 0 个评论 • 113 次浏览 • 2017-10-26 15:37 • 来自相关话题

作者是老猫的同事,这篇是他写了发给他的朋友们看的,我觉得写得非常好,推荐给大家,哪怕你还是个小白,只要有耐心,也能大致看明白。对于商业未来的见解,很多时候都是用心的结果。


如果您喜欢,欢迎打赏,我将全部转给作者。







在过去一个多月,包括中国在内的各国政府相继对区块链行业采取了不同的监管政策。相对于中国政府对比特币交易所和ICO采取的严厉监管政策,日本政府对比特币交易采取的开方友好政策奠定了日本在今后全球区块链发展浪潮当中的市场地位。虽然各类区块链应用代币的市场价格受政策影响起起落落,但伴随着比特币突破 5000 美金,区块链兴起的大趋势已经逐步展现。

 

区块链所带来的并不仅仅是比特币这一全球化数字货币,或是各类去中心化应用(Decentralized Application)。在信息和大数据时代,区块链这一技术最重要的地位来自于它重新建立的信息和价值传播结构。

 

在区块链行业生态当中,一个能够满足商业需求、高效的区块链公共应用平台是必不可少,并占有极其重要的地位。以太坊(Ethereum)的兴起以及在今年上半年的爆发性增长,为我们提供了一个绝佳的参考范例。然而,不得不承认的是,整个区块链行业还处于一个在初期完善基础架构的阶段,现阶段阻碍区块链大规模应用的最大障碍存在于技术上。目前以太坊的机制以及运行效率,很难支持一个庞大的去中心化商业应用生态。

 

简略地说,一个成熟的区块链公共应用平台至少需要满足以下条件:

 

 在低延迟的基础上支持大规模用户

 提供免费服务

 便利地升级与 Bug 恢复

 

不幸的是,从目前的情况来看,以太坊很难能够满足这三个条件。首先:以太坊现阶段能够处理每秒5笔左右的交易。虽然以太坊创始人 Vitalik 在上个月的一次会议上表述以太坊 + Plasma 的扩容方案能够使以太坊的交易处理能力与 Visa 相媲美,但为了达成这个目标,以太坊还需要进行相当复杂的升级。

 

第二:在以太坊的机制下,每笔转账以及智能合约的运行,都需要消耗以太币,这是以太币作为以太坊系统代币的价值来源。然而,在很多商业应用下,免费服务对于用户体验是非常必要的。在用户不必因使用区块链应用平台而付出费用的基础上,平台将发展更大的用户规模。而在这一模式下,应用开发者也完全能够创建其特有的盈利模式。

 

第三:区块链应用平台需要为开发者提供便捷地修复 bug 的机制。在区块链和智能合约上面,代码即法律,然而代码之中存在 bug 是无法避免的。一个区块链底层平台和智能合约在遭遇 bug 时无法无法及时修复是一个非常可怕且失去用户信任的情况。

 

在这样的情况下,我们判断,虽然以太坊极其成功地普及了链上智能合约的技术并建立了包含各类区块链应用和 ERC-20 代币的庞大生态,但它远未发展为能够满足现实商业需求的应用平台。限制它商业发展的阻碍存在于其技术机制。

 

为什么我们认为 EOS 有潜力成为一个更为完善的区块链公共应用平台?因为 EOS 能够解决我们以上提出的三个条件。

 

首先:EOS 的 DPOS 共识算法和石墨烯底层工具组能够满足每秒上万次,甚至每秒上百万次交易请求的企业级应用需求。石墨烯底层工具处理高频数据的能力已经通过 EOS 技术负责人Daniel Larime 之前创立的两个项目 BTS 和 STEEM 得到充分的印证。更加值得注意的是:以太坊是一条公共区块链,在以太坊链上运行的每一个应用都会消耗整条链的资源;而 EOS 并不是一条公链,它是一个区块链基础架构,开发者可以在 EOS 架构上自由创建自己的公链。链与链之间不会影响彼此的资源使用,不会出现平台因个别消耗资源巨大的应用而造成大面积的网络拥堵。

 

第二:在 EOS 上转账交易与运行智能合约并不需要消耗 EOS 系统代币。在 EOS 系统当中,有三大类资源被应用程序消耗:带宽和日志存储(磁盘),计算和计算积压(CPU),以及状态存储器(RAM)。这些资源根据账户持有 EOS 数量来分配,这也是 EOS 系统代币的价值来源。这种和以太坊不同的运作机制将满足更多的商业场景应用,并吸引更大数量级别的用户。

 

第三:EOS 建立的约束性合约(被称作 EOS “宪法”)定义了仅依靠代码无法完全执行的用户间义务。该合约还定义了源代码协议的人类可读性意图。当出现系统错误时,人类可读性意图可用于区分此错误是否确实为 bug,并判断社区的修复举措是否得当。而当系统面临一个漏洞时,区块生产者还可以加速变更约束性合约。

 

另外,EOS 的跨链交互和虚拟机独立架构都有许多可圈可点的机制。比如 EOS 设置的以太虚拟机(EVM),能够支持现有在以太坊运行的智能合约。现存在于以太坊的区块链应用,通过添加少量适配,就能够在 EOS 系统上运行。

 

我们可以说,EOS 的设计原理十分符合区块链公共平台的商业运行逻辑,而它的核心技术机制经过了很大程度的实践证实,代表了区块链技术的根本进步。可以预见,在 2018 年 6 月 1 日 EOS 代币分发结束,并推出 1.0 版本网络之后,整个区块链行业将迎来崭新的商业应用浪潮。
 
原文转自公众号猫说 查看全部

DQmcCXL82K7Fa8BXJBeLCYGJf1MyerTiyfeXwtkCe7wiTiw_1680x8400.png


作者是老猫的同事,这篇是他写了发给他的朋友们看的,我觉得写得非常好,推荐给大家,哪怕你还是个小白,只要有耐心,也能大致看明白。对于商业未来的见解,很多时候都是用心的结果。


如果您喜欢,欢迎打赏,我将全部转给作者。







在过去一个多月,包括中国在内的各国政府相继对区块链行业采取了不同的监管政策。相对于中国政府对比特币交易所和ICO采取的严厉监管政策,日本政府对比特币交易采取的开方友好政策奠定了日本在今后全球区块链发展浪潮当中的市场地位。虽然各类区块链应用代币的市场价格受政策影响起起落落,但伴随着比特币突破 5000 美金,区块链兴起的大趋势已经逐步展现。

 

区块链所带来的并不仅仅是比特币这一全球化数字货币,或是各类去中心化应用(Decentralized Application)。在信息和大数据时代,区块链这一技术最重要的地位来自于它重新建立的信息和价值传播结构。

 

在区块链行业生态当中,一个能够满足商业需求、高效的区块链公共应用平台是必不可少,并占有极其重要的地位。以太坊(Ethereum)的兴起以及在今年上半年的爆发性增长,为我们提供了一个绝佳的参考范例。然而,不得不承认的是,整个区块链行业还处于一个在初期完善基础架构的阶段,现阶段阻碍区块链大规模应用的最大障碍存在于技术上。目前以太坊的机制以及运行效率,很难支持一个庞大的去中心化商业应用生态。

 

简略地说,一个成熟的区块链公共应用平台至少需要满足以下条件:

 

 在低延迟的基础上支持大规模用户

 提供免费服务

 便利地升级与 Bug 恢复

 

不幸的是,从目前的情况来看,以太坊很难能够满足这三个条件。首先:以太坊现阶段能够处理每秒5笔左右的交易。虽然以太坊创始人 Vitalik 在上个月的一次会议上表述以太坊 + Plasma 的扩容方案能够使以太坊的交易处理能力与 Visa 相媲美,但为了达成这个目标,以太坊还需要进行相当复杂的升级。

 

第二:在以太坊的机制下,每笔转账以及智能合约的运行,都需要消耗以太币,这是以太币作为以太坊系统代币的价值来源。然而,在很多商业应用下,免费服务对于用户体验是非常必要的。在用户不必因使用区块链应用平台而付出费用的基础上,平台将发展更大的用户规模。而在这一模式下,应用开发者也完全能够创建其特有的盈利模式。

 

第三:区块链应用平台需要为开发者提供便捷地修复 bug 的机制。在区块链和智能合约上面,代码即法律,然而代码之中存在 bug 是无法避免的。一个区块链底层平台和智能合约在遭遇 bug 时无法无法及时修复是一个非常可怕且失去用户信任的情况。

 

在这样的情况下,我们判断,虽然以太坊极其成功地普及了链上智能合约的技术并建立了包含各类区块链应用和 ERC-20 代币的庞大生态,但它远未发展为能够满足现实商业需求的应用平台。限制它商业发展的阻碍存在于其技术机制。

 

为什么我们认为 EOS 有潜力成为一个更为完善的区块链公共应用平台?因为 EOS 能够解决我们以上提出的三个条件。

 

首先:EOS 的 DPOS 共识算法和石墨烯底层工具组能够满足每秒上万次,甚至每秒上百万次交易请求的企业级应用需求。石墨烯底层工具处理高频数据的能力已经通过 EOS 技术负责人Daniel Larime 之前创立的两个项目 BTS 和 STEEM 得到充分的印证。更加值得注意的是:以太坊是一条公共区块链,在以太坊链上运行的每一个应用都会消耗整条链的资源;而 EOS 并不是一条公链,它是一个区块链基础架构,开发者可以在 EOS 架构上自由创建自己的公链。链与链之间不会影响彼此的资源使用,不会出现平台因个别消耗资源巨大的应用而造成大面积的网络拥堵。

 

第二:在 EOS 上转账交易与运行智能合约并不需要消耗 EOS 系统代币。在 EOS 系统当中,有三大类资源被应用程序消耗:带宽和日志存储(磁盘),计算和计算积压(CPU),以及状态存储器(RAM)。这些资源根据账户持有 EOS 数量来分配,这也是 EOS 系统代币的价值来源。这种和以太坊不同的运作机制将满足更多的商业场景应用,并吸引更大数量级别的用户。

 

第三:EOS 建立的约束性合约(被称作 EOS “宪法”)定义了仅依靠代码无法完全执行的用户间义务。该合约还定义了源代码协议的人类可读性意图。当出现系统错误时,人类可读性意图可用于区分此错误是否确实为 bug,并判断社区的修复举措是否得当。而当系统面临一个漏洞时,区块生产者还可以加速变更约束性合约。

 

另外,EOS 的跨链交互和虚拟机独立架构都有许多可圈可点的机制。比如 EOS 设置的以太虚拟机(EVM),能够支持现有在以太坊运行的智能合约。现存在于以太坊的区块链应用,通过添加少量适配,就能够在 EOS 系统上运行。

 

我们可以说,EOS 的设计原理十分符合区块链公共平台的商业运行逻辑,而它的核心技术机制经过了很大程度的实践证实,代表了区块链技术的根本进步。可以预见,在 2018 年 6 月 1 日 EOS 代币分发结束,并推出 1.0 版本网络之后,整个区块链行业将迎来崭新的商业应用浪潮。
 
原文转自公众号猫说

缺失的白皮书:DPOS共识算法工作原理及鲁棒性根源分析

EOS其他相关郑浩 发表了文章 • 0 个评论 • 74 次浏览 • 2017-10-17 13:32 • 来自相关话题

雷锋网(公众号:雷锋网)按:本文发表于Steem,作者是dantheman。译者是万云首席技术官奚海峰,首发公众号万云BaaS。奚海峰曾任IBM研究院工程师和高级咨询顾问,Sempra Commodities 主管架构师及 Tudor Investment 软件开发主管。在美国12年间,获得了包括“IBM 研究成就奖”在内的多次嘉奖,在一流国际会议和杂志上发表过多篇学术论文,并且持有美国发明专利。雷锋网已获授权转载。

这篇“缺失的白皮书”是对委托权益证明(DPOS)的分析,目的是为DPOS的工作原理及其鲁棒性根源提供一个分析。DPOS的早期描述可以在bitshares.org找到。不过,那个描述还包含了许多不属于实际共识过程的内容。

所有区块链本质上都是一种由交易驱动的确定性状态机。共识是商定确定性交易顺序和过滤无效交易的过程。有许多不同的共识算法都可以产生等效的交易排序,但DPOS已经通过在多个区块链上经年累月的可靠运行证明自身是健壮、安全和有效的。

像所有共识算法一样,块生产者可能导致的最大损害是审查。所有块的有效性必须基于确定性的开源状态机逻辑。

DPOS算法概要

DPOS算法分为两部分:选择一组块生产者和调度生产。选举过程确保利益相关方最终得到控制,因为当网络不能顺利运行时,利益相关方的损失最大。选举方法对实际运行中如何达成共识几乎没有影响,因此,本文将重点介绍如何在块生产者被选择之后达成共识。

为了帮助解释这个算法,我想假设3个块生产者A,B和C。因为共识(的达成)需要2/3+1多数来解决所有情况,这个简化的模型将假设生产者C是打破僵局的那个人。在现实世界中,将有21个或更多的块生产者。像工作量证明一样,一般规则是最长链胜出。任何时候当一个诚实的对等节点看到一个有效的更长链,它都会从当前分叉切换到更长的这条链。

我将举例说明在大多数想得到的网络条件下DPOS如何运行。这些例子应该可以帮助您理解为什么DPOS稳健且难以破坏。

正常操作

在正常操作模式下,块生产者每3秒钟轮流生成一个块。假设没有人错过自己的轮次,那么这将产生最长链。块生产者在被调度轮次之外的任何时间段出块都是无效的。





 
少数分叉

不超过节点总数三分之一的恶意或故障节点可能创建少数分叉。在这种情况下,少数分叉每9秒只能产生一个块,而多数分叉每9秒可以产生两个块。这样,诚实的2/3多数将永远比少数(的链)更长。





 
离线少数的多重生产

(离线的)少数人可以试图产生无限数量的分叉,但是他们的所有分叉都将比多数人的那条链短,因为少数人在出块速度上注定比多数人来的更慢。





 
网络碎片化

网络完全有可能碎片化,导致没有任何分叉拥有多数块生成者。在这种情况下,最长的链将倒向最大的那个少数群体。当网络连通性恢复时,较小的少数群体会自然切换到最长的那条链,明确的共识将恢复。





 
有可能存在这样三个分叉,其中两个最长的分叉长度相同。在这种情况下,第3个(较小)分叉的块生产者重新加入网络时会打破平局。块生产者总数为奇数,因此不可能长时间保持平局。稍后我们还会讲到生产者“洗牌”,它使得出块顺序随机化,从而确保即使是生产者数目相同的两个分叉也会以不同的步长增长,最终导致一个分叉超过另一个。
 
在线少数的多重生产

在这种场景下,少数节点B在其时间段内产生了两个或更多可供选择的块。下一个计划生产者(C)可以选择基于B产生的任何一种方案继续构建链条。一旦如此,这个选择就成为最长的链,而所有选择B1的节点都将切换分叉。少数不良生产者企图广播再多的替代块也无关紧要,它们作为最长链的一部分永远不会超过一轮。
 





 
最后不可逆块

在网络碎片化的情况下,多个分叉都有可能持续不断增长相当长的时间。长远来看最长的链终将获胜,但观察者需要一种确切的手段来判定一个块是否绝对处于增长最快的那条链。这可以通过观察来自2/3+1多数块生产者的确认来决定。

在下图中,块B已被C和A所确认,这代表了2/3+1多数确认,由此我们可以推断没有其它链会比这个更长 – 如果2/3的生产者是诚实的。
 





 
请注意,这个“规则”类似于比特币的6块确认“规则”。一些聪明人也许可以谋划一系列事件使得两个节点(应该是“交易”?)出现在不同的最后不可逆块上。这种边缘案例要求攻击者能完全控制通信延迟,并且在几分钟内两次--而不是一次--使用该控制。即便这真的发生了,那么最长链(胜出)的长期规则仍然适用。我们估计这种攻击的可能性足够接近0,且经济后果无关紧要,因此不足为虑。

生产者法定人数不足

在缺乏明晰的生产者法定人数这种不太可能的情况下,少数人还是可以继续出块。利益相关方可以在这些块里包括更改投票的交易。这些投票可以选出一组新的生产者,并将出块参与率恢复到100%。一旦如此,少数链将最终超过所有其他以低于100%参与率运行的链。


在此过程中,所有观察者都会知道,在一条参与率超过67%的链形成之前,网络状态是不定的。那些选择在此条件下进行交易的人所冒的风险与选择接受不到6个确认的人相似。他们知道存在这样一些小的可能性,即:共识也许最终在一个不同的分叉上建立起来。在实践中,这种情况比接受少于3个比特币交易确认的块要安全多了。

多数生产者舞弊

如果多数生产者变得腐败,那么他们可以产生无限数量的分叉,每个分叉都看起来以2/3多数确认向前走。这种情况下,最后不可逆块算法蜕变为最长链算法。最长链就是为最大多数所批准的那条链,而这将由少数剩下的诚实节点决定。这种行为不会持续很长时间,因为利益相关方最终会投票替换生产者。
 





 
交易作为权益证明(TaPoS)

当用户为一个交易签名时,他们是在对区块链状态的一定假设下这样做的。这个假设是基于他们对最近几个块的看法。如果最长链的共识发生改变,则潜在会使签名者之前的假设失效。


就TaPoS而言,所有交易都包含最近一个块的散列,如果该块在链历史中不存在则这些交易被认为是无效的。任何在孤儿分叉上给交易签名的人,都会发现该交易无效且无法迁移到主分叉。

该过程的一个附带作用是可以抵御试图产生替代链的长期攻击。每个利益相关方在每次交易时都直接对区块链做出确认。随着时间推移,所有的块都是由所有利益相关方确认过的,这在一条伪造链里是无法复制的。

确定性生产者洗牌

在上面所有例子中,我们展示的都是块生产者按循环调度出块。实际上,每出N个块(N是生产者数量),块生产者集合都会洗牌一次。这种随机性确保块生成者B不会总是忽略块生成者A,每当形成多个拥有相同数量生产者的分叉时,平局最终都会被打破。

结论

在每一个我们能想到的自然网络分裂的情况下,委托权益证明都是强健的,甚至在面对相当数量生产者舞弊的情形时也是安全的。不像其它共识算法,当大多数生产者不合格时,DPOS还是可以继续工作。在此过程中,社区可以投票替换掉不合格的生产者,直到恢复100%参与率。我还不知道有任何其它算法可以在如此高强度和变化多端的失败条件下依然保持强健。

说到底,DPOS引人注目的安全性来自于其选择块生产者和验证节点质量的算法。运用赞成投票的过程可以确保一个人即使拥有50%的有效投票权也不能独自挑选哪怕一个生产者。DPOS旨在优化拥有强壮网络连接的诚实节点100%参与(共识过程)的名义条件。这使得DPOS有能力在平均只有1.5秒的时间内以99.9%的确定性确认交易,同时以优雅和可检测的方式降级 – 从降级中恢复正常也不过是小事一桩。

其它共识算法以网络条件差的不诚实节点为名义条件展开设计,这样设计的最终结果就是性能更差、延迟更高、通信开销高的网络,而且这个网络在33%节点失效的情况下会完全停摆。

在BitShares成功运行三年以及在Steem运行一年期间,我们经历了各种各样的网络条件和软件错误。DPOS成功穿行于其间,在处理了比任何其它区块链更多交易的同时持续达成共识,展现了非凡的能力。
 
原文转自雷锋网 查看全部
雷锋网(公众号:雷锋网)按:本文发表于Steem,作者是dantheman。译者是万云首席技术官奚海峰,首发公众号万云BaaS。奚海峰曾任IBM研究院工程师和高级咨询顾问,Sempra Commodities 主管架构师及 Tudor Investment 软件开发主管。在美国12年间,获得了包括“IBM 研究成就奖”在内的多次嘉奖,在一流国际会议和杂志上发表过多篇学术论文,并且持有美国发明专利。雷锋网已获授权转载。

这篇“缺失的白皮书”是对委托权益证明(DPOS)的分析,目的是为DPOS的工作原理及其鲁棒性根源提供一个分析。DPOS的早期描述可以在bitshares.org找到。不过,那个描述还包含了许多不属于实际共识过程的内容。

所有区块链本质上都是一种由交易驱动的确定性状态机。共识是商定确定性交易顺序和过滤无效交易的过程。有许多不同的共识算法都可以产生等效的交易排序,但DPOS已经通过在多个区块链上经年累月的可靠运行证明自身是健壮、安全和有效的。

像所有共识算法一样,块生产者可能导致的最大损害是审查。所有块的有效性必须基于确定性的开源状态机逻辑。

DPOS算法概要

DPOS算法分为两部分:选择一组块生产者和调度生产。选举过程确保利益相关方最终得到控制,因为当网络不能顺利运行时,利益相关方的损失最大。选举方法对实际运行中如何达成共识几乎没有影响,因此,本文将重点介绍如何在块生产者被选择之后达成共识。

为了帮助解释这个算法,我想假设3个块生产者A,B和C。因为共识(的达成)需要2/3+1多数来解决所有情况,这个简化的模型将假设生产者C是打破僵局的那个人。在现实世界中,将有21个或更多的块生产者。像工作量证明一样,一般规则是最长链胜出。任何时候当一个诚实的对等节点看到一个有效的更长链,它都会从当前分叉切换到更长的这条链。

我将举例说明在大多数想得到的网络条件下DPOS如何运行。这些例子应该可以帮助您理解为什么DPOS稳健且难以破坏。

正常操作

在正常操作模式下,块生产者每3秒钟轮流生成一个块。假设没有人错过自己的轮次,那么这将产生最长链。块生产者在被调度轮次之外的任何时间段出块都是无效的。

594d25d40ff4e.jpg

 
少数分叉

不超过节点总数三分之一的恶意或故障节点可能创建少数分叉。在这种情况下,少数分叉每9秒只能产生一个块,而多数分叉每9秒可以产生两个块。这样,诚实的2/3多数将永远比少数(的链)更长。

594d25e0ef536.jpg

 
离线少数的多重生产

(离线的)少数人可以试图产生无限数量的分叉,但是他们的所有分叉都将比多数人的那条链短,因为少数人在出块速度上注定比多数人来的更慢。

594d25ed4afbb.jpg

 
网络碎片化

网络完全有可能碎片化,导致没有任何分叉拥有多数块生成者。在这种情况下,最长的链将倒向最大的那个少数群体。当网络连通性恢复时,较小的少数群体会自然切换到最长的那条链,明确的共识将恢复。

594d2608b7c7c.jpg

 
有可能存在这样三个分叉,其中两个最长的分叉长度相同。在这种情况下,第3个(较小)分叉的块生产者重新加入网络时会打破平局。块生产者总数为奇数,因此不可能长时间保持平局。稍后我们还会讲到生产者“洗牌”,它使得出块顺序随机化,从而确保即使是生产者数目相同的两个分叉也会以不同的步长增长,最终导致一个分叉超过另一个。
 
在线少数的多重生产

在这种场景下,少数节点B在其时间段内产生了两个或更多可供选择的块。下一个计划生产者(C)可以选择基于B产生的任何一种方案继续构建链条。一旦如此,这个选择就成为最长的链,而所有选择B1的节点都将切换分叉。少数不良生产者企图广播再多的替代块也无关紧要,它们作为最长链的一部分永远不会超过一轮。
 

594d26176c8a2.jpg

 
最后不可逆块

在网络碎片化的情况下,多个分叉都有可能持续不断增长相当长的时间。长远来看最长的链终将获胜,但观察者需要一种确切的手段来判定一个块是否绝对处于增长最快的那条链。这可以通过观察来自2/3+1多数块生产者的确认来决定。

在下图中,块B已被C和A所确认,这代表了2/3+1多数确认,由此我们可以推断没有其它链会比这个更长 – 如果2/3的生产者是诚实的。
 

594d262e2719c.jpg

 
请注意,这个“规则”类似于比特币的6块确认“规则”。一些聪明人也许可以谋划一系列事件使得两个节点(应该是“交易”?)出现在不同的最后不可逆块上。这种边缘案例要求攻击者能完全控制通信延迟,并且在几分钟内两次--而不是一次--使用该控制。即便这真的发生了,那么最长链(胜出)的长期规则仍然适用。我们估计这种攻击的可能性足够接近0,且经济后果无关紧要,因此不足为虑。

生产者法定人数不足

在缺乏明晰的生产者法定人数这种不太可能的情况下,少数人还是可以继续出块。利益相关方可以在这些块里包括更改投票的交易。这些投票可以选出一组新的生产者,并将出块参与率恢复到100%。一旦如此,少数链将最终超过所有其他以低于100%参与率运行的链。


在此过程中,所有观察者都会知道,在一条参与率超过67%的链形成之前,网络状态是不定的。那些选择在此条件下进行交易的人所冒的风险与选择接受不到6个确认的人相似。他们知道存在这样一些小的可能性,即:共识也许最终在一个不同的分叉上建立起来。在实践中,这种情况比接受少于3个比特币交易确认的块要安全多了。

多数生产者舞弊

如果多数生产者变得腐败,那么他们可以产生无限数量的分叉,每个分叉都看起来以2/3多数确认向前走。这种情况下,最后不可逆块算法蜕变为最长链算法。最长链就是为最大多数所批准的那条链,而这将由少数剩下的诚实节点决定。这种行为不会持续很长时间,因为利益相关方最终会投票替换生产者。
 

594d2630cbd99.jpg

 
交易作为权益证明(TaPoS)

当用户为一个交易签名时,他们是在对区块链状态的一定假设下这样做的。这个假设是基于他们对最近几个块的看法。如果最长链的共识发生改变,则潜在会使签名者之前的假设失效。


就TaPoS而言,所有交易都包含最近一个块的散列,如果该块在链历史中不存在则这些交易被认为是无效的。任何在孤儿分叉上给交易签名的人,都会发现该交易无效且无法迁移到主分叉。

该过程的一个附带作用是可以抵御试图产生替代链的长期攻击。每个利益相关方在每次交易时都直接对区块链做出确认。随着时间推移,所有的块都是由所有利益相关方确认过的,这在一条伪造链里是无法复制的。

确定性生产者洗牌

在上面所有例子中,我们展示的都是块生产者按循环调度出块。实际上,每出N个块(N是生产者数量),块生产者集合都会洗牌一次。这种随机性确保块生成者B不会总是忽略块生成者A,每当形成多个拥有相同数量生产者的分叉时,平局最终都会被打破。

结论

在每一个我们能想到的自然网络分裂的情况下,委托权益证明都是强健的,甚至在面对相当数量生产者舞弊的情形时也是安全的。不像其它共识算法,当大多数生产者不合格时,DPOS还是可以继续工作。在此过程中,社区可以投票替换掉不合格的生产者,直到恢复100%参与率。我还不知道有任何其它算法可以在如此高强度和变化多端的失败条件下依然保持强健。

说到底,DPOS引人注目的安全性来自于其选择块生产者和验证节点质量的算法。运用赞成投票的过程可以确保一个人即使拥有50%的有效投票权也不能独自挑选哪怕一个生产者。DPOS旨在优化拥有强壮网络连接的诚实节点100%参与(共识过程)的名义条件。这使得DPOS有能力在平均只有1.5秒的时间内以99.9%的确定性确认交易,同时以优雅和可检测的方式降级 – 从降级中恢复正常也不过是小事一桩。

其它共识算法以网络条件差的不诚实节点为名义条件展开设计,这样设计的最终结果就是性能更差、延迟更高、通信开销高的网络,而且这个网络在33%节点失效的情况下会完全停摆。

在BitShares成功运行三年以及在Steem运行一年期间,我们经历了各种各样的网络条件和软件错误。DPOS成功穿行于其间,在处理了比任何其它区块链更多交易的同时持续达成共识,展现了非凡的能力。
 
原文转自雷锋网

从BM和V神互怼中,深入对比PoW和DPoS的共识机制!

EOS其他相关郑浩 发表了文章 • 0 个评论 • 108 次浏览 • 2017-10-17 13:21 • 来自相关话题

BM和V神都是区块链界中星光熠熠的天才明星。


Vitalik Buterin,以太坊(Ethereum)项目的创始人,币圈人称“小神童”、“V神”、“维维”。如今,Vitalik已然成为了币圈及链圈内最耀眼的人物之一。


Daniel larimer,币圈人称BM(bytemaster),比特股(BitShares)、Steem以及EOS项目的创始人,BM是区块链界中极少数的连续创业者,比特股(BitShares)、Steem这两个项目已成功运行。


今年8月份时媒体写了BM和V神互怼的文,我仔细分析,在他们的互怼中的最核心都是在怼PoW和DPoS这两种共识机制在去中心化,治理能力,资源费用,预防DOS攻击,共识周期等这几方面的对比。


1.PoW和DPoS,谁更中心化?


PoW






这是以太坊的区块生产节点分布图。你可以看到,两个矿池控制了51%的哈希算力,它们可以任意忽视其它所有矿池生产的区块,其中7个节点的哈希算力就达到了整个网络的90%。


而且,以太坊的完全节点也都是经过加强的,普通大众根本承受不起。所以,几乎所有的轻客户端根本不需要操心默克尔证明的问题,虽然Vitalik说默克尔证明多么的有价值。


在以太坊,他们单方面地制定决策,比如在DAO事件上;由于这个决策是由少数人制定的,没有大众参与,这就给予了内部人士不对等的交易机会。在这件事上,代码并非法律,操作者们才是。


PoW挖矿这种模式,比多数上市公司还中心化;硬件和电力现在都很便宜,这意味着矿池在投票权上是处于垄断地位的;现在比特币和以太坊都是这样。


当你把利益不同的人绑定到一起,不让代币持有人投票,由PoW导致的中心化,最终的结局就是寡头统治,而他们是不会对他们的行为负责任的。


如果你不允许代币持有人投票,这就表示你把受益者和决策制定者分开了。这样的话,制定出来的决策或许并不符合代币持有者的最大利益。比特币拓展的问题上看到过这一幕,数年来,矿工们控制了网络,收取高额费用。


投票的人并不是最后结果的直接受益者---这就是现在比特币和以太坊的组织方式。


DPoS


比特股、Steemit 以及EOS所使用的底层框架是石墨烯框架。石墨烯框架采用DPoS共识算法,平均出块速度1.5秒,出块节点(见证人)由持币用户选举投票产生,每个用户的投票权重则按照用户持币占系统总量比例计算。


全网持有代币的人可以通过投票系统来选择区块生产者,一旦当选任何人都可以参与区块的生产。


以EOS为例,预计每3秒生产一个区块。任何时刻,只有一个生产者被授权产生区块。如果在某个时间内没有成功出块,则跳过该块。


EOS架构中区块产生是以21个区块为一个周期。在每个出块周期开始时,21个区块生产者会被投票选出。前20名出块者首选自动选出,第21个出块者按所得投票数目对应概率选出。所选择的生产者会根据从块时间导出的伪随机数进行混合。以便保证出块者之间的连接尽量平衡。


事实是,对于矿工(节点提供者)来说,比特币和以太坊都比DPoS区块链更中心化。


2.治理能力对比


在PoW的共识机制下,矿工,Casper staker,矿池,股权池,基金会,完全节点,交易所都想占主导,而那些个人持币者却没有发言权。外部观察者根本无法知道这个特别委员会是否取得了共识。人们也就不确定共识的步骤是什么。


比如在ETC和BCC这些分叉,都是基金会和矿池组织双方的博弈,而我们这些个人持币者只是被通知的角色,是无参与决策权的。这样的治理算法则会导致特别委员会的治理模式,社区作出的决定会令个人持币者感到模糊不清的。


在DPoS模式下,治理的结构是清晰的,所有的股东都有发言权。这种治理的成本与共识过程是一致的,每个人都能知道治理的政策是什么,也知道他们该怎么参与。制定决策的时候,就很清楚,不会有二义性。不会有“意外分叉”,因为区块链很清楚新的硬分叉路径,旧的节点共识会通知他们“关停”,除非他们升级了。


在正常情况下,DPOS块链不会经历任何叉,因为块生产者合作生产区块而不是竞争。如果有区块分叉,共识将自动切换到最长的链条。具有更多生产者的区块链长度将比具有较少生产者的区块链增长速度更快。此外,没有块生产者应该同时在两个区块链分叉上生产块。如果一个块生产者发现这么做了,就可能被投票出局。


Bitshares成功运行了3年多,Steem也成功了1年多,性能达到每秒上千笔交易量,它们能降低交易费,还能进行19次无缝硬分叉,而这都归功于DPoS治理能力。


然而比特币和以太坊不久的将来还会面临分叉的问题。或许未来存在一种方法,能把矿工,股东,矿池,基金,完全节点,交易所和商标持有人聚到一起取得共识,然后强制他们遵守这个统一的治理架构。然而,现在还没有这种方案出现。


3.能源利用对比


PoW的核心要义为:算力越大,挖到块的概率越大,维护区块链安全的权重越大。相对其他共识机制而言,PoW逻辑简单,容易实现,容错达50%,其安全有严格的数学论证。但PoW最大的问题之一,被指责最多是浪费能源。


比特币和以太坊每年收集了40到50亿美金,他们把这些资金花在了挖矿的电力资源上,这些消耗的电力资源比一些小国家的都多;


在DPoS共识机制比特股,Steem和EOS的应用程序不需要用户为区块链上的操作支付费用。像传统的基于Web的应用程序一样,应用程序开发人员提供程序运行需要的资源,而不是由用户提供。


这些资源包括带宽、计算力、存储容量等。这意味着用户可以创建免费的区块链应用程序,新用户无需经历繁琐的加密数字货币购买流程,就可直接使用区块链上的应用程序。


可以免费使用的区块链平台自然可能会得到更多的关注。有了足够的用户规模,开发者和企业可以创建对应的盈利模式。


在DPoS中,那些原本要被浪费掉的四五十亿美元将会被代币持有人编入预算,代币持有人能以最有利于网络的方式来使用这笔资金。


4.共识周期长短对比


PoW机制最大的问题之一是的共识达成的周期较长,比特币每秒只能最多交易7笔交易,以太坊是每秒13笔左右,这样的交易量无法取代现有的商业应用。


相对于现实的以现有的应用程序,比如:交易所和Ebay,Uber,AirBnB和Facebook这些社交媒体为例;这些应用每天需要能够处理数千万日活跃用户提供服务,每秒平均需处理的事件高达数十万条。


基于石墨烯底层DPoS的已运行了三年的比特股和运行一年的Steem已实力证明可以达到1.5秒的平均确认速度和有限条件下实测3300笔的数据吞吐量;


而EOS将通过并行链的方式,最高将可以达到每秒数百万笔,并且并行本地链甚至将可以达到毫秒级的确认速度。


5.预防DOS攻击


事实是以太坊和比特币都遭受过DOS攻击,而Steem和Bitshares则运行良好。正如上图显示的那样,以太坊中7个节点的哈希算力就达到了整个网络的90%,把这7个节点拿掉,就能轻松摧毁以太坊。


总结:


通过以上几方面的对比,DPoS比PoW的优势明显,但这两种机制还存在最大的问题在于没有所谓的“最终确认”。


当获得一个区块确认时,只能代表交易有99%的可能性受到区块链的认可,当获得两个确认时,信心值会增高到99.9%的可能,当获得6个确认时,信心值可能会提升到99.9……9%,所有的确认都只是一个概率上的表达,而不是一个确定性的事情,理论上有可能存在其他攻击影响。


现在区块链上数字资产的应用越来越多来源于真实世界或金融资产,对交易的最终确认有很高的要求,需要有不同的共识机制。


共识机制是区块链的核心技术,现在各种区块链共识机制的选择是认为至今为止的相对的最优选择;当未来区块链技术越来越多应用于现实,未来将会不断有所改进,以切合实际的需要。


未来已来,只是尚未流行!

让我们跟随区块链的浪潮,共同穿越未来!!

作者:Ann729
链接:http://www.jianshu.com/p/ed5a3d766e5d
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

  查看全部
BM和V神都是区块链界中星光熠熠的天才明星。


Vitalik Buterin,以太坊(Ethereum)项目的创始人,币圈人称“小神童”、“V神”、“维维”。如今,Vitalik已然成为了币圈及链圈内最耀眼的人物之一。


Daniel larimer,币圈人称BM(bytemaster),比特股(BitShares)、Steem以及EOS项目的创始人,BM是区块链界中极少数的连续创业者,比特股(BitShares)、Steem这两个项目已成功运行。


今年8月份时媒体写了BM和V神互怼的文,我仔细分析,在他们的互怼中的最核心都是在怼PoW和DPoS这两种共识机制在去中心化,治理能力,资源费用,预防DOS攻击,共识周期等这几方面的对比。


1.PoW和DPoS,谁更中心化?


PoW

4124900-9c5b076d6946f381.png


这是以太坊的区块生产节点分布图。你可以看到,两个矿池控制了51%的哈希算力,它们可以任意忽视其它所有矿池生产的区块,其中7个节点的哈希算力就达到了整个网络的90%。


而且,以太坊的完全节点也都是经过加强的,普通大众根本承受不起。所以,几乎所有的轻客户端根本不需要操心默克尔证明的问题,虽然Vitalik说默克尔证明多么的有价值。


在以太坊,他们单方面地制定决策,比如在DAO事件上;由于这个决策是由少数人制定的,没有大众参与,这就给予了内部人士不对等的交易机会。在这件事上,代码并非法律,操作者们才是。


PoW挖矿这种模式,比多数上市公司还中心化;硬件和电力现在都很便宜,这意味着矿池在投票权上是处于垄断地位的;现在比特币和以太坊都是这样。


当你把利益不同的人绑定到一起,不让代币持有人投票,由PoW导致的中心化,最终的结局就是寡头统治,而他们是不会对他们的行为负责任的。


如果你不允许代币持有人投票,这就表示你把受益者和决策制定者分开了。这样的话,制定出来的决策或许并不符合代币持有者的最大利益。比特币拓展的问题上看到过这一幕,数年来,矿工们控制了网络,收取高额费用。


投票的人并不是最后结果的直接受益者---这就是现在比特币和以太坊的组织方式。


DPoS


比特股、Steemit 以及EOS所使用的底层框架是石墨烯框架。石墨烯框架采用DPoS共识算法,平均出块速度1.5秒,出块节点(见证人)由持币用户选举投票产生,每个用户的投票权重则按照用户持币占系统总量比例计算。


全网持有代币的人可以通过投票系统来选择区块生产者,一旦当选任何人都可以参与区块的生产。


以EOS为例,预计每3秒生产一个区块。任何时刻,只有一个生产者被授权产生区块。如果在某个时间内没有成功出块,则跳过该块。


EOS架构中区块产生是以21个区块为一个周期。在每个出块周期开始时,21个区块生产者会被投票选出。前20名出块者首选自动选出,第21个出块者按所得投票数目对应概率选出。所选择的生产者会根据从块时间导出的伪随机数进行混合。以便保证出块者之间的连接尽量平衡。


事实是,对于矿工(节点提供者)来说,比特币和以太坊都比DPoS区块链更中心化。


2.治理能力对比


在PoW的共识机制下,矿工,Casper staker,矿池,股权池,基金会,完全节点,交易所都想占主导,而那些个人持币者却没有发言权。外部观察者根本无法知道这个特别委员会是否取得了共识。人们也就不确定共识的步骤是什么。


比如在ETC和BCC这些分叉,都是基金会和矿池组织双方的博弈,而我们这些个人持币者只是被通知的角色,是无参与决策权的。这样的治理算法则会导致特别委员会的治理模式,社区作出的决定会令个人持币者感到模糊不清的。


在DPoS模式下,治理的结构是清晰的,所有的股东都有发言权。这种治理的成本与共识过程是一致的,每个人都能知道治理的政策是什么,也知道他们该怎么参与。制定决策的时候,就很清楚,不会有二义性。不会有“意外分叉”,因为区块链很清楚新的硬分叉路径,旧的节点共识会通知他们“关停”,除非他们升级了。


在正常情况下,DPOS块链不会经历任何叉,因为块生产者合作生产区块而不是竞争。如果有区块分叉,共识将自动切换到最长的链条。具有更多生产者的区块链长度将比具有较少生产者的区块链增长速度更快。此外,没有块生产者应该同时在两个区块链分叉上生产块。如果一个块生产者发现这么做了,就可能被投票出局。


Bitshares成功运行了3年多,Steem也成功了1年多,性能达到每秒上千笔交易量,它们能降低交易费,还能进行19次无缝硬分叉,而这都归功于DPoS治理能力。


然而比特币和以太坊不久的将来还会面临分叉的问题。或许未来存在一种方法,能把矿工,股东,矿池,基金,完全节点,交易所和商标持有人聚到一起取得共识,然后强制他们遵守这个统一的治理架构。然而,现在还没有这种方案出现。


3.能源利用对比


PoW的核心要义为:算力越大,挖到块的概率越大,维护区块链安全的权重越大。相对其他共识机制而言,PoW逻辑简单,容易实现,容错达50%,其安全有严格的数学论证。但PoW最大的问题之一,被指责最多是浪费能源。


比特币和以太坊每年收集了40到50亿美金,他们把这些资金花在了挖矿的电力资源上,这些消耗的电力资源比一些小国家的都多;


在DPoS共识机制比特股,Steem和EOS的应用程序不需要用户为区块链上的操作支付费用。像传统的基于Web的应用程序一样,应用程序开发人员提供程序运行需要的资源,而不是由用户提供。


这些资源包括带宽、计算力、存储容量等。这意味着用户可以创建免费的区块链应用程序,新用户无需经历繁琐的加密数字货币购买流程,就可直接使用区块链上的应用程序。


可以免费使用的区块链平台自然可能会得到更多的关注。有了足够的用户规模,开发者和企业可以创建对应的盈利模式。


在DPoS中,那些原本要被浪费掉的四五十亿美元将会被代币持有人编入预算,代币持有人能以最有利于网络的方式来使用这笔资金。


4.共识周期长短对比


PoW机制最大的问题之一是的共识达成的周期较长,比特币每秒只能最多交易7笔交易,以太坊是每秒13笔左右,这样的交易量无法取代现有的商业应用。


相对于现实的以现有的应用程序,比如:交易所和Ebay,Uber,AirBnB和Facebook这些社交媒体为例;这些应用每天需要能够处理数千万日活跃用户提供服务,每秒平均需处理的事件高达数十万条。


基于石墨烯底层DPoS的已运行了三年的比特股和运行一年的Steem已实力证明可以达到1.5秒的平均确认速度和有限条件下实测3300笔的数据吞吐量;


而EOS将通过并行链的方式,最高将可以达到每秒数百万笔,并且并行本地链甚至将可以达到毫秒级的确认速度。


5.预防DOS攻击


事实是以太坊和比特币都遭受过DOS攻击,而Steem和Bitshares则运行良好。正如上图显示的那样,以太坊中7个节点的哈希算力就达到了整个网络的90%,把这7个节点拿掉,就能轻松摧毁以太坊。


总结:


通过以上几方面的对比,DPoS比PoW的优势明显,但这两种机制还存在最大的问题在于没有所谓的“最终确认”。


当获得一个区块确认时,只能代表交易有99%的可能性受到区块链的认可,当获得两个确认时,信心值会增高到99.9%的可能,当获得6个确认时,信心值可能会提升到99.9……9%,所有的确认都只是一个概率上的表达,而不是一个确定性的事情,理论上有可能存在其他攻击影响。


现在区块链上数字资产的应用越来越多来源于真实世界或金融资产,对交易的最终确认有很高的要求,需要有不同的共识机制。


共识机制是区块链的核心技术,现在各种区块链共识机制的选择是认为至今为止的相对的最优选择;当未来区块链技术越来越多应用于现实,未来将会不断有所改进,以切合实际的需要。


未来已来,只是尚未流行!

让我们跟随区块链的浪潮,共同穿越未来!!

作者:Ann729
链接:http://www.jianshu.com/p/ed5a3d766e5d
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

 

【翻译】EOS vs Ethereum - 泰坦之战(中文版)

EOS其他相关郑浩 发表了文章 • 0 个评论 • 90 次浏览 • 2017-10-17 13:16 • 来自相关话题

原文地址: eos-vs-ethereum-clash-of-the-titans
author: @mohit18jan
 
近日,Dan Larimer与eos.io团队宣布开发一个共识区块链操作系统-EOS ,为应用开发者提供数据库,账户权限,调度,账户认证以及应用间通讯等功能。

自EOS代币发售以来,经常有人对EOS与Ethereum之间进行比较。EOS和Ethereum都是去中心化的智能合约平台,允许用户开发去中心化的应用(dapps).

Ethereum是迄今为止规模最大也最成功的去中心化应用平台,但是也有其限制。Vitalik Buterin最近在 Reddit’s Ethereum 交易社区的一篇帖子之中承认“Ethereum可扩展性很操蛋;区块链的底层设计存在瓶颈,单个节点上,必须对整个网络之中的每一笔交易都要进行处理”。

不过,在EOS和Ethereum的设计和愿景上存在诸多差异,我们看一下其中的一些区别:






 
EOS

委托股权证明机制(DPOS)
损坏程序的修复机制(冻结和修复损坏或冻结的程序)
无多条区块链分叉的风险
用具有合法约束力的区块链宪法,建立共同的司法管辖.
为开发者提供全套的加密和区块链通讯功能,使得开发者能够专注于商业逻辑的功能开发.
通过横向和纵向的扩展,可以让EOS网络处理能力达到每秒处理上百万笔交易.
可以支持数千个工业规模的去中心化应用
对单个app的拒绝服务(DoS)攻击,不会让整个网络中断.
零交易费用,除了初始的EOS代币外,开发者无其它成本







 
Ethereum

工作量证明机制,计划向POS/POW混合机制迁移
失败和损坏的程序,会造成投资损失,或者区块链硬分叉(DAO程序的失败,导致了ETH和ETC的分叉)
修复一个损坏的程序,需要中断整个网络
前期测试网络的处理能力是25笔交易每秒,经过优化之后,可能达到每秒50或100笔交易.
Vitalik Buterin提出了无限扩容路线图,通过数据库切片的方式来实现,该扩容方式具有技术难度,正在进行开发。
暴涨的交易量通常会让整个网络冻结拥堵.
每一次计算,存储操作和带宽占用,都需要消耗Gas费.



EOS认为,不同的应用中,往往需要同样类型的功能.他们希望能够提供这些功能,如加密和app/区块链通讯工具,很多应用都会用到。EOS以区块链的形式提供了一套完整的工具包,使得开发者只需专注于应用的开发即可.举个例子,假如所有的手机制造商都需要自己创造一个如安卓或者IOS的操作系统,那么,手机制造商的数量将会剧烈减少.

原理和管理机制

以太坊网络当前对工作证明机制的实现存在一个问题,即修复损坏的程序是很困难的.DAO出现了致命的bug,被黑客攻击而项目破产,使得以太坊网络分裂为ETC和ETH.

如果再有这样的情况,某个存在缺陷的合约导致了数百万美元的损失,又该如何应对?Vitalik Buterin和其他以太坊社区的领导者,需要进行另外一次硬分叉么?再弄出一个Ethereum Class Two,或者其它的支链么?

另外,存在缺陷的智能合约,曾导致一家加拿大数字货币交易所QuadrigaCX,损失了超过价值一千万美元的以太币.因此,如果以太坊上面智能合约存在漏洞,要么会导致投资者损失,要么导致硬分叉,中断整个网络.

EOS可以冻结和修复有问题的应用。如果在你的应用之中存在缺陷-社区可以冻结该应用,部署修复代码,而不需要中断整个网络。简而言之,在EOS上硬分叉会被当做常规事务一样的处理。

可扩展性--规则颠覆者?

Dan在2017共识大会上所做的EOS展示,重点强调几个消费者服务的处理能力,能够达到数千笔交易每秒。对区块链应用的大规模应用而言,可扩展性是异常重要的。

在Ethereum上,早期的测试网络达到了25笔交易每秒(在一些优化的条件下), 经过优化,有可能达到50或100笔交易每秒. 对于金融机构和社交网络等大型的去中心化应用来说,这种处理速度远远不够。
Vitalik Buterin提出了一个“无限扩容”路线图,开发周期为两年,严重依赖数据库切片技术。

切片概念是指将数据库分割为更小的部分,叫做"shards",然后在分散的服务器上传播这些切片.

虽然由于存在复杂的技术限制,对该方案存在种种疑虑,不过,如果该方案成功,可以预期,Ethereum将会继续享受作为区块链智能合约平台的先发优势。

EOS会利用纵向与横向扩容技术,使得区块链的扩展能力,可能达到每秒处理数百万笔交易的级别。它依赖于一项叫做石墨烯(Graphene)的可靠技术, 在压力测试中,该技术能够实现每秒钟10,00-100,000笔交易的处理能力。通过纵向和横向扩展,实现每秒钟数百万笔交易的处理量,还是有可能的。

结论:

谁是胜利者?还未知晓!

我相信,两者都是很重要的技术,可以共存(像Windows和Mac那样)。然而,在从零开始构建商业级别的区块链应用时,EOS更有优势。这篇文章略微偏向EOS,毕竟,每篇文章都会不可避免的带有作者的看法和信念。

备注: 本人并不持有EOS或Ethereum代币,本文中的信息不可被视作投资建议

作者:shuke0327
链接:http://www.jianshu.com/p/10ea3a5f1b5e
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
  查看全部
原文地址: eos-vs-ethereum-clash-of-the-titans
author: @mohit18jan
 
近日,Dan Larimer与eos.io团队宣布开发一个共识区块链操作系统-EOS ,为应用开发者提供数据库,账户权限,调度,账户认证以及应用间通讯等功能。

自EOS代币发售以来,经常有人对EOS与Ethereum之间进行比较。EOS和Ethereum都是去中心化的智能合约平台,允许用户开发去中心化的应用(dapps).

Ethereum是迄今为止规模最大也最成功的去中心化应用平台,但是也有其限制。Vitalik Buterin最近在 Reddit’s Ethereum 交易社区的一篇帖子之中承认“Ethereum可扩展性很操蛋;区块链的底层设计存在瓶颈,单个节点上,必须对整个网络之中的每一笔交易都要进行处理”。

不过,在EOS和Ethereum的设计和愿景上存在诸多差异,我们看一下其中的一些区别:


DQmcCXL82K7Fa8BXJBeLCYGJf1MyerTiyfeXwtkCe7wiTiw_1680x8400.png

 
EOS


委托股权证明机制(DPOS)
损坏程序的修复机制(冻结和修复损坏或冻结的程序)
无多条区块链分叉的风险
用具有合法约束力的区块链宪法,建立共同的司法管辖.
为开发者提供全套的加密和区块链通讯功能,使得开发者能够专注于商业逻辑的功能开发.
通过横向和纵向的扩展,可以让EOS网络处理能力达到每秒处理上百万笔交易.
可以支持数千个工业规模的去中心化应用
对单个app的拒绝服务(DoS)攻击,不会让整个网络中断.
零交易费用,除了初始的EOS代币外,开发者无其它成本




DQmUpKZ1aG2jX5qB8mfVCj3yopCtzhZxHgcgXWDhsNp9QJK_1680x8400.png

 
Ethereum


工作量证明机制,计划向POS/POW混合机制迁移
失败和损坏的程序,会造成投资损失,或者区块链硬分叉(DAO程序的失败,导致了ETH和ETC的分叉)
修复一个损坏的程序,需要中断整个网络
前期测试网络的处理能力是25笔交易每秒,经过优化之后,可能达到每秒50或100笔交易.
Vitalik Buterin提出了无限扩容路线图,通过数据库切片的方式来实现,该扩容方式具有技术难度,正在进行开发。
暴涨的交易量通常会让整个网络冻结拥堵.
每一次计算,存储操作和带宽占用,都需要消耗Gas费.




EOS认为,不同的应用中,往往需要同样类型的功能.他们希望能够提供这些功能,如加密和app/区块链通讯工具,很多应用都会用到。EOS以区块链的形式提供了一套完整的工具包,使得开发者只需专注于应用的开发即可.举个例子,假如所有的手机制造商都需要自己创造一个如安卓或者IOS的操作系统,那么,手机制造商的数量将会剧烈减少.

原理和管理机制

以太坊网络当前对工作证明机制的实现存在一个问题,即修复损坏的程序是很困难的.DAO出现了致命的bug,被黑客攻击而项目破产,使得以太坊网络分裂为ETC和ETH.

如果再有这样的情况,某个存在缺陷的合约导致了数百万美元的损失,又该如何应对?Vitalik Buterin和其他以太坊社区的领导者,需要进行另外一次硬分叉么?再弄出一个Ethereum Class Two,或者其它的支链么?

另外,存在缺陷的智能合约,曾导致一家加拿大数字货币交易所QuadrigaCX,损失了超过价值一千万美元的以太币.因此,如果以太坊上面智能合约存在漏洞,要么会导致投资者损失,要么导致硬分叉,中断整个网络.

EOS可以冻结和修复有问题的应用。如果在你的应用之中存在缺陷-社区可以冻结该应用,部署修复代码,而不需要中断整个网络。简而言之,在EOS上硬分叉会被当做常规事务一样的处理。

可扩展性--规则颠覆者?

Dan在2017共识大会上所做的EOS展示,重点强调几个消费者服务的处理能力,能够达到数千笔交易每秒。对区块链应用的大规模应用而言,可扩展性是异常重要的。

在Ethereum上,早期的测试网络达到了25笔交易每秒(在一些优化的条件下), 经过优化,有可能达到50或100笔交易每秒. 对于金融机构和社交网络等大型的去中心化应用来说,这种处理速度远远不够。
Vitalik Buterin提出了一个“无限扩容”路线图,开发周期为两年,严重依赖数据库切片技术。

切片概念是指将数据库分割为更小的部分,叫做"shards",然后在分散的服务器上传播这些切片.

虽然由于存在复杂的技术限制,对该方案存在种种疑虑,不过,如果该方案成功,可以预期,Ethereum将会继续享受作为区块链智能合约平台的先发优势。

EOS会利用纵向与横向扩容技术,使得区块链的扩展能力,可能达到每秒处理数百万笔交易的级别。它依赖于一项叫做石墨烯(Graphene)的可靠技术, 在压力测试中,该技术能够实现每秒钟10,00-100,000笔交易的处理能力。通过纵向和横向扩展,实现每秒钟数百万笔交易的处理量,还是有可能的。

结论:

谁是胜利者?还未知晓!

我相信,两者都是很重要的技术,可以共存(像Windows和Mac那样)。然而,在从零开始构建商业级别的区块链应用时,EOS更有优势。这篇文章略微偏向EOS,毕竟,每篇文章都会不可避免的带有作者的看法和信念。

备注: 本人并不持有EOS或Ethereum代币,本文中的信息不可被视作投资建议

作者:shuke0327
链接:http://www.jianshu.com/p/10ea3a5f1b5e
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。