EOS新闻动态

EOS新闻动态

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

EOS技术讨论

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

EOS众筹价格

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

EOS其他相关

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

EOS区块链PHP开发包

回复

jimi2018 发起了问题 • 1 人关注 • 0 个回复 • 12 次浏览 • 2018-12-06 10:28 • 来自相关话题

新手教程:一张图搞清楚 nodeos,keosd,cleos,eosiocpp 之间的关系

回复

jimi2018 发起了问题 • 2 人关注 • 0 个回复 • 268 次浏览 • 2018-08-25 10:29 • 来自相关话题

EOS学习笔记5---EOS测试网络

郑浩 发表了文章 • 0 个评论 • 810 次浏览 • 2018-03-31 18:42 • 来自相关话题

迄今为止,所有使用EOS区块链进行实验的工作都是使用eosd托管所有21个区块生产者的单个实例执行的。虽然这是验证区块链功能,开发新合同或其他方面的完美有效解决方案,但它不会扩展。它也没有公开在合同和块数据必须跨多个实例共享时引发的那类问题。提供扩展能力涉及在多个主机上部署多个eosd节点,然后将其排列成一个对等(p2p)网络。组成这个网络涉及剪裁和分发配置文件,协调启动和停止以及其他任务。 手动完成这项任务非常繁琐,容易出错。幸运的是提供了一个解决方案,以下面描述的Launcher应用程序的形式提供。
测试网络的节点,网络和拓扑

在进入EOS测试网的细节之前,让我们澄清一些术语。在这份文件中,我使用“host主机”和“machine机器”这两个术语可以相互交换。主机通常归结为一个IP地址,但实际上它可能有更多。 下一个词是“node节点”。节点是配置为用作0个或更多生产者的eosd可执行文件的实例。节点和主机之间不存在一对一映射,主机可以服务多个节点,但一个节点不能跨越多个主机。 我使用“local network本地网络”来指代任何一组节点,无论是在单个主机上还是在多个节点上,都在关闭,因此访问不必离开安全的网络环境。 最后还有涉及远程主机的分布式网络的想法。这些可能是您可能无法直接访问启动和停止eosd实例的主机,但您可能希望与之建立分布式的测试网络。
 
本地主机网络
 
在单台机器上运行testnet是最快捷的入门方式。正如你将在下面看到的,这是Launcher应用程序的默认模式。您可以立即设置本地主机网络,只需告诉启动程序需要激活多少生产或非生产节点,以及可能使用的网络拓扑类型。 缺点是在单个主机上运行多个节点时需要大量硬件。此外,多个节点将在CPU周期方面相互竞争,限制真正的并发性,并且本地主机网络性能与主机间性能差异很大,即使速度很高也是如此。
 
分布式网络

活网的最具代表性的模型是将eosd节点分布在多个主机上。 Launcher应用程序能够通过使用通过ssh推送的bash脚本启动分布式节点。在这种情况下,需要额外的配置来将配置的引用替换为“localhost”或“127.0.0.1”,并将其与各个对等机器的实际主机名或IP地址相替换。

启动分布式测试网络需要操作员对配置为进行身份验证的所有远程计算机进行ssh访问,而无需用户输入密码。下面详细描述该配置。

在测试网跨越多个远程网络的情况下,可以在分布式运营商之间在外部共享通用启动器定义的配置文件,每个运营商负责启动他或她自己的本地网络。

请注意,启动器不会将eosd的实例推送到远程主机,您必须单独准备各种测试网络主机。
 
网络拓扑

网络拓扑或“形状”描述节点如何连接以共享事务和数据块,并请求相同的数据。改变网络拓扑的想法是,节点必须发送报告新事务或块的消息的次数与必须重复消息以确保所有节点知道它的次数之间存在折衷。

启动器具有基于节点间连接的两种基本不同网络“形状”的定义,这可以通过命令行选项来选择。如果您希望创建自己的自定义网络拓扑,可以通过提供json格式的文件来实现。该文件通常是启动器在“输出”模式下创建的模板的编辑版本。
 
星形网络






一个“星”旨在支持测试网络中更多的节点。在这种情况下,连接到一个节点的对等点的数量和这些节点的分布会根据网络中节点的数量而变化。
 
网状网络






在“网状”网络中,每个节点都连接到尽可能多的对等节点。
 
自定义网络形状
 

这是自定义部署的一个示例,其中节点群集除了通过单个交叉点以外都是隔离的。
 
启动器应用程序
为了解决在局域网或更广泛的网络中分布多个eosd节点所隐含的复杂性,启动器应用程序已创建。

基于少数命令行参数,启动器能够编写每个节点的配置文件,在对等主机之间安全地分发这些文件,然后启动eosd的多个实例。

以这种方式启动的Eosd实例将其输出记录在单个文本文件中。最后,启动器应用程序还能够关闭部分或全部测试网络。
 
运行启动器应用程序

启动程序用于配置和部署使用配置的路由相互通信的生产和非生产eosd节点。假设机器具有足够的内存和磁盘空间用于多个eosd实例,则每个节点的配置都存储在单独的目录中,允许多个节点在同一主机上处于活动状态。启动程序使用多个配置源来部署测试网络。一些命令行参数可以用来设置简单的本地网络。 为了支持部署分布式网络,启动程序将从JSON文件中读取更详细的配置。您可以使用启动程序根据您提供的命令行选项创建默认的JSON文件。编辑该文件以根据需要替换实际主机名和其他详细信息,然后重新运行提供此文件的启动程序。 目前,启动程序仅激活平台本地节点,稍后将添加dockerized节点。应该直接将生成的配置文件用于dockerized节点。
 
启动器命令行参数launcher command line arguments:
-n [ --nodes ] arg (=1) total number of nodes to configure and
launch
-p [ --pnodes ] arg (=1) number of nodes that are producers
-d [ --delay ] arg (=0) number of seconds to wait before starting the next node. Used to simulate a person keying in a series of individual eosd startup command lines.
-s [ --shape ] arg (=star) network topology, use "star"
"mesh" or give a filename for custom
-g [ --genesis ] arg (="./genesis.json")
set the path to genesis.json
-o [ --output ] arg save a copy of the generated topology
in this file
--skip-signature EOSD does not require transaction
signatures.
-i [ --timestamp ] arg set the timestamp for the first block.
Use "now" to indicate the current time
-l [ --launch ] arg select a subset of nodes to launch.
Currently may be "all", "none", or
"local". If not set, the default is to
launch all unless an output file is
named, in which case it starts none.
-k [ --kill ] arg The launcher retrieves the previously
started process ids and signals each with the specified signum. Use 15 for a sigterm and 9 for sigkill.
-h [ --help ] print this list需要注意的是如果testnet.json中是--shape参数,--nodes, --pnodes,和 --genesis 参数将被忽略。
 

生成的多主机测试网络配置文件


这是通过运行以下命令生成的文件:launcher --output <filename> [other options]
在这种模式下,启动程序不会激活任何eosd实例,它会生成给定文件名的文件。这个文件是一个JSON格式的模板,提供了一个简单的方法。

本文档中描述的对象由使用ssl的助手和testnet节点描述符的集合组成。节点描述符被列为名称,值对。请注意,名称的作用既是节点描述符映射中的关键字,也是对等列表中节点的别名。例如:{
"ssh_helper": {
"ssh_cmd": "/usr/bin/ssh",
"scp_cmd": "/usr/bin/scp",
"ssh_identity": "phil",
"ssh_args": "-i ~phil/.ssh/id-sample"
},
ssh helper字段是指向ssh和scp的路径,必要时是身份标识以及任何可选参数。"nodes": [[
"testnet_0",{
"genesis": "./genesis.json",
"remote": true,
"ssh_identity": "",
"ssh_args": "",
"eos_root_dir": "/home/phil/blockchain/eos",
"data_dir": "tn_data_0",
"hostname": "remoteserv",
"public_name": "remoteserv",
"p2p_port": 9876,
"http_port": 8888,
"filesize": 8192,
"keys": [{
"public_key": "EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV",
"wif_private_key": "5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"
}
],
"peers": [
"testnet_1",
"testnet_2",
"testnet_3",
"testnet_4",
"testnet_5"
],
"producers": [
"inita",
"initg",
"initm",
"inits"
]
}
],[
"testnet_1",{该testnet.json文件的其余部分是节点描述符集合。上面的片段是由命令行programs/launcher/launcher -p6 -s mesh -o testnet.json 创建,之后编辑引用一个名为‘remoteserv’的远程主机。
 
JSON文件的元素
这个表格描述了所有在testnet.json中用到的键/值对。Value Description
ssh_helper a set of values used to facilitate the use of SSH and SCP
nodes a collection of descriptors defining the eosd instances used to assemble this testnet. The names used as keys in this collection are also aliases used within as placeholders for peer nodes.ssh_helper elements Description
ssh_cmd path to the local ssh command
scp_cmd path to the local scp command
ssh_args any additional command line arguments needed to successfully connect to remote peers
ssh_identity The user name to use when accessing the remote hostsnode elements Description
genesis path to the genesis.json file. This should be the same file for all members of the testnet.
remote specifies whether this node is in the local network or not. This flag ties in with the launch mode command line option (-l) to determine if the local launcher instance will attempt to start this node.
ssh_identity a per-node override of the general ssh_identity defined above.
ssh_args a per-node override of the general ssh_args
eos_root_dir specifies the directory into which all eosd artifacts are based. This is required for any hosts that are not the local host.
data_dir the root for the remaining node-specific settings below.
hostname the domain name for the server, or its IP address.
public_name possibly different from the hostname, this name will get substituted for the aliases when creating the per-node config.ini file's peer list.
p2p_port combined with the public name to identify the endpoint listed on for peer connections. When multiple nodes share a host, the p2p_port is automatically incremented for each node.
http_port defines the listen endpoint for the client API services
filesize sets the capacity in megabytes for the size of the blockchain backing store file.
keys specify the authentication tokens for this node.
peers this list indicates the other nodes in the network to which this one actively connects. Since this file may be edited to alter the hostname, public name, or p2p port values, the peers list here holds aliases for the actual endpoints eventually written to the individual config.ini files.
producers this list identifies which of the producers from the genesis.json file are held by this node. Note that the launcher uses a round-robin algorithm to spread the producer instances across the producing nodes.
配置分布式服务器
 
 
该testnet.json文件ssh_helper部分包含必要的连接并发出命令到其他服务器的SSH的元素。除了对ssh_helper部分提供全局配置设置,每个节点的配置可以提供最高权限身份和连接参数。还需要提供服务器至少复制EOSD可执行的,与genesis.json文件到适当的位置,相对于一些命名为EOS的根目录。举例来说如果定义EOS的根目录为/home/phil/blockchain/eos,启动器将贯穿各种shell命令使用SSH,最后运用SCP复制一个config.ini文件到远程的数据目录。
 
运行时构件
 
启动器应用程序为每个节点实例创建一个单独的日期和配置目录。文件以tn_data_<n>命名,Per-Node File Description
config.ini The eosd configuration file.
eosd.pid The process ID of the running eosd instance.
blockchain/* The blockchain backing store
blocks/* The blockchain log store
stderr.txt The cerr output from eosd.
stdout.txt The cout output from eosd.一个名为 "last_run.json"的文件A file called "last_run.json" contains hints for a later instance of the launcher to be able to kill local and remote nodes when run with -k 15.
 
 因为EOS还在不断的开发完善中,所以该文档可能会过时,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
  查看全部
迄今为止,所有使用EOS区块链进行实验的工作都是使用eosd托管所有21个区块生产者的单个实例执行的。虽然这是验证区块链功能,开发新合同或其他方面的完美有效解决方案,但它不会扩展。它也没有公开在合同和块数据必须跨多个实例共享时引发的那类问题。提供扩展能力涉及在多个主机上部署多个eosd节点,然后将其排列成一个对等(p2p)网络。组成这个网络涉及剪裁和分发配置文件,协调启动和停止以及其他任务。 手动完成这项任务非常繁琐,容易出错。幸运的是提供了一个解决方案,以下面描述的Launcher应用程序的形式提供。
测试网络的节点,网络和拓扑

在进入EOS测试网的细节之前,让我们澄清一些术语。在这份文件中,我使用“host主机”和“machine机器”这两个术语可以相互交换。主机通常归结为一个IP地址,但实际上它可能有更多。 下一个词是“node节点”。节点是配置为用作0个或更多生产者的eosd可执行文件的实例。节点和主机之间不存在一对一映射,主机可以服务多个节点,但一个节点不能跨越多个主机。 我使用“local network本地网络”来指代任何一组节点,无论是在单个主机上还是在多个节点上,都在关闭,因此访问不必离开安全的网络环境。 最后还有涉及远程主机的分布式网络的想法。这些可能是您可能无法直接访问启动和停止eosd实例的主机,但您可能希望与之建立分布式的测试网络。
 
本地主机网络
 
在单台机器上运行testnet是最快捷的入门方式。正如你将在下面看到的,这是Launcher应用程序的默认模式。您可以立即设置本地主机网络,只需告诉启动程序需要激活多少生产或非生产节点,以及可能使用的网络拓扑类型。 缺点是在单个主机上运行多个节点时需要大量硬件。此外,多个节点将在CPU周期方面相互竞争,限制真正的并发性,并且本地主机网络性能与主机间性能差异很大,即使速度很高也是如此。
 
分布式网络

活网的最具代表性的模型是将eosd节点分布在多个主机上。 Launcher应用程序能够通过使用通过ssh推送的bash脚本启动分布式节点。在这种情况下,需要额外的配置来将配置的引用替换为“localhost”或“127.0.0.1”,并将其与各个对等机器的实际主机名或IP地址相替换。

启动分布式测试网络需要操作员对配置为进行身份验证的所有远程计算机进行ssh访问,而无需用户输入密码。下面详细描述该配置。

在测试网跨越多个远程网络的情况下,可以在分布式运营商之间在外部共享通用启动器定义的配置文件,每个运营商负责启动他或她自己的本地网络。

请注意,启动器不会将eosd的实例推送到远程主机,您必须单独准备各种测试网络主机。
 
网络拓扑

网络拓扑或“形状”描述节点如何连接以共享事务和数据块,并请求相同的数据。改变网络拓扑的想法是,节点必须发送报告新事务或块的消息的次数与必须重复消息以确保所有节点知道它的次数之间存在折衷。

启动器具有基于节点间连接的两种基本不同网络“形状”的定义,这可以通过命令行选项来选择。如果您希望创建自己的自定义网络拓扑,可以通过提供json格式的文件来实现。该文件通常是启动器在“输出”模式下创建的模板的编辑版本。
 
星形网络

star.png


一个“星”旨在支持测试网络中更多的节点。在这种情况下,连接到一个节点的对等点的数量和这些节点的分布会根据网络中节点的数量而变化。
 
网状网络

mesh.png


在“网状”网络中,每个节点都连接到尽可能多的对等节点。
 
自定义网络形状
 

这是自定义部署的一个示例,其中节点群集除了通过单个交叉点以外都是隔离的。
 
启动器应用程序
为了解决在局域网或更广泛的网络中分布多个eosd节点所隐含的复杂性,启动器应用程序已创建。

基于少数命令行参数,启动器能够编写每个节点的配置文件,在对等主机之间安全地分发这些文件,然后启动eosd的多个实例。

以这种方式启动的Eosd实例将其输出记录在单个文本文件中。最后,启动器应用程序还能够关闭部分或全部测试网络。
 
运行启动器应用程序

启动程序用于配置和部署使用配置的路由相互通信的生产和非生产eosd节点。假设机器具有足够的内存和磁盘空间用于多个eosd实例,则每个节点的配置都存储在单独的目录中,允许多个节点在同一主机上处于活动状态。启动程序使用多个配置源来部署测试网络。一些命令行参数可以用来设置简单的本地网络。 为了支持部署分布式网络,启动程序将从JSON文件中读取更详细的配置。您可以使用启动程序根据您提供的命令行选项创建默认的JSON文件。编辑该文件以根据需要替换实际主机名和其他详细信息,然后重新运行提供此文件的启动程序。 目前,启动程序仅激活平台本地节点,稍后将添加dockerized节点。应该直接将生成的配置文件用于dockerized节点。
 
启动器命令行参数
launcher command line arguments:
-n [ --nodes ] arg (=1) total number of nodes to configure and
launch
-p [ --pnodes ] arg (=1) number of nodes that are producers
-d [ --delay ] arg (=0) number of seconds to wait before starting the next node. Used to simulate a person keying in a series of individual eosd startup command lines.
-s [ --shape ] arg (=star) network topology, use "star"
"mesh" or give a filename for custom
-g [ --genesis ] arg (="./genesis.json")
set the path to genesis.json
-o [ --output ] arg save a copy of the generated topology
in this file
--skip-signature EOSD does not require transaction
signatures.
-i [ --timestamp ] arg set the timestamp for the first block.
Use "now" to indicate the current time
-l [ --launch ] arg select a subset of nodes to launch.
Currently may be "all", "none", or
"local". If not set, the default is to
launch all unless an output file is
named, in which case it starts none.
-k [ --kill ] arg The launcher retrieves the previously
started process ids and signals each with the specified signum. Use 15 for a sigterm and 9 for sigkill.
-h [ --help ] print this list
需要注意的是如果testnet.json中是--shape参数,--nodes, --pnodes,和 --genesis 参数将被忽略。
 

生成的多主机测试网络配置文件


这是通过运行以下命令生成的文件:
launcher --output <filename> [other options]

在这种模式下,启动程序不会激活任何eosd实例,它会生成给定文件名的文件。这个文件是一个JSON格式的模板,提供了一个简单的方法。

本文档中描述的对象由使用ssl的助手和testnet节点描述符的集合组成。节点描述符被列为名称,值对。请注意,名称的作用既是节点描述符映射中的关键字,也是对等列表中节点的别名。例如:
{
"ssh_helper": {
"ssh_cmd": "/usr/bin/ssh",
"scp_cmd": "/usr/bin/scp",
"ssh_identity": "phil",
"ssh_args": "-i ~phil/.ssh/id-sample"
},

ssh helper字段是指向ssh和scp的路径,必要时是身份标识以及任何可选参数。
"nodes": [[
"testnet_0",{
"genesis": "./genesis.json",
"remote": true,
"ssh_identity": "",
"ssh_args": "",
"eos_root_dir": "/home/phil/blockchain/eos",
"data_dir": "tn_data_0",
"hostname": "remoteserv",
"public_name": "remoteserv",
"p2p_port": 9876,
"http_port": 8888,
"filesize": 8192,
"keys": [{
"public_key": "EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV",
"wif_private_key": "5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"
}
],
"peers": [
"testnet_1",
"testnet_2",
"testnet_3",
"testnet_4",
"testnet_5"
],
"producers": [
"inita",
"initg",
"initm",
"inits"
]
}
],[
"testnet_1",{
该testnet.json文件的其余部分是节点描述符集合。上面的片段是由命令行programs/launcher/launcher -p6 -s mesh -o testnet.json 创建,之后编辑引用一个名为‘remoteserv’的远程主机。
 
JSON文件的元素
这个表格描述了所有在testnet.json中用到的键/值对。
Value	Description
ssh_helper a set of values used to facilitate the use of SSH and SCP
nodes a collection of descriptors defining the eosd instances used to assemble this testnet. The names used as keys in this collection are also aliases used within as placeholders for peer nodes.
ssh_helper elements	Description
ssh_cmd path to the local ssh command
scp_cmd path to the local scp command
ssh_args any additional command line arguments needed to successfully connect to remote peers
ssh_identity The user name to use when accessing the remote hosts
node elements	Description
genesis path to the genesis.json file. This should be the same file for all members of the testnet.
remote specifies whether this node is in the local network or not. This flag ties in with the launch mode command line option (-l) to determine if the local launcher instance will attempt to start this node.
ssh_identity a per-node override of the general ssh_identity defined above.
ssh_args a per-node override of the general ssh_args
eos_root_dir specifies the directory into which all eosd artifacts are based. This is required for any hosts that are not the local host.
data_dir the root for the remaining node-specific settings below.
hostname the domain name for the server, or its IP address.
public_name possibly different from the hostname, this name will get substituted for the aliases when creating the per-node config.ini file's peer list.
p2p_port combined with the public name to identify the endpoint listed on for peer connections. When multiple nodes share a host, the p2p_port is automatically incremented for each node.
http_port defines the listen endpoint for the client API services
filesize sets the capacity in megabytes for the size of the blockchain backing store file.
keys specify the authentication tokens for this node.
peers this list indicates the other nodes in the network to which this one actively connects. Since this file may be edited to alter the hostname, public name, or p2p port values, the peers list here holds aliases for the actual endpoints eventually written to the individual config.ini files.
producers this list identifies which of the producers from the genesis.json file are held by this node. Note that the launcher uses a round-robin algorithm to spread the producer instances across the producing nodes.

配置分布式服务器
 
 
该testnet.json文件ssh_helper部分包含必要的连接并发出命令到其他服务器的SSH的元素。除了对ssh_helper部分提供全局配置设置,每个节点的配置可以提供最高权限身份和连接参数。还需要提供服务器至少复制EOSD可执行的,与genesis.json文件到适当的位置,相对于一些命名为EOS的根目录。举例来说如果定义EOS的根目录为/home/phil/blockchain/eos,启动器将贯穿各种shell命令使用SSH,最后运用SCP复制一个config.ini文件到远程的数据目录。
 
运行时构件
 
启动器应用程序为每个节点实例创建一个单独的日期和配置目录。文件以tn_data_<n>命名,
Per-Node File	Description
config.ini The eosd configuration file.
eosd.pid The process ID of the running eosd instance.
blockchain/* The blockchain backing store
blocks/* The blockchain log store
stderr.txt The cerr output from eosd.
stdout.txt The cout output from eosd.
一个名为 "last_run.json"的文件A file called "last_run.json" contains hints for a later instance of the launcher to be able to kill local and remote nodes when run with -k 15.
 
 因为EOS还在不断的开发完善中,所以该文档可能会过时,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 

EOS从入门到精通(四)

郑浩 发表了文章 • 0 个评论 • 1503 次浏览 • 2018-01-12 16:10 • 来自相关话题

原文地址大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第四讲。我们来解读EOS白皮书的最后几部分。今天的内容相对于上一节课会简单一些,主要讲EOS的治理,然后简单讲一下虚拟机;跨链通讯部分我会在高级篇重点解读










我们先来看治理部分,所谓的治理我的理解就是管理那些没法完全使用软件算法实现的共识。在我们熟悉的区块链产品比特币和以太坊中是没有这部分共识的,这样就造成了一个非常严重的问题,社区经常因为一些原因分裂,导致分叉。2017年比特币已经被分叉无数次了,以太坊也已经出现了数次分叉,而这样的结果就是没有管理好非代码共识所造成的。

EOS认识到区块链的权力来源应该是Token持有人,而不应该是矿工,Token持有人将自己的权力通过投票的方式委托给区块生产者,这样区块生产者就具备了冻结账户、更新有缺陷的应用程序、提出对底层协议硬分叉的改变的权力。当然这种权力是受限的、是被检查的。可以用下面的结论总结这种权力:
所有的区块链变更都需要区块生产者同意,如果区块生产者拒绝Token持有人想要的变更,那么他将被投票出局,如果区块生产者的变更没有经过Token持有人的同意,那么其他非区块生产者的全节点会拒绝该改变。






一个智能合约可能会出现异常比如说因为bug的原因导致行为不正确或者资源消耗不在一个合理的范围内,在这种情况下区块生产者有权力纠正这种情况,纠正的方式就是冻结账户,冻结账户的概念就是所有与待冻结账户有关的变更都不打包。冻结账户需要21分之17的区块生产者同意才行,如果区块生产者滥用权力,解决方案也很简单,就是将他投票出局,这样被冻结的账户就会被解冻。






如果冻结账户已经不能解决问题,不可预知的代码已经造成了破坏,此时EOS可以支持在不需要硬分叉的前提下修改账户代码。我的理解这有点类似于交易的回滚。当然与冻结账户类似,也需要21个中的17个区块生产者同意才行。






这里的宪法不知道翻译的准不准确,我的理解是这样的,智能合约也是要遵循法律法规的,很多事情是没有办法通过代码来进行约束的,同时由于EOS是全球性的,那么合约遵循哪里的法律法规就成了一个问题。这块EOS是怎么做的呢,就是将这些法规数字化,然后进行Hash签名,后面所有交易都要选一个宪法来绑定到合约中,这样就能解决管辖权和法律选择带来的争端。这个理解不一定是对的,因为白皮书上我的感觉也是写的不太清楚。







EOS还规定了升级协议和宪法的流程,我们可以看一下,如果要对宪法进行修改,需要区块生产者提出,并获得至少17个区块生产者的批准,并且连续30天保持批准,然后所有用户都使用新的宪法hash来签署交易。升级代码协议也是类似的流程。按照EOS的默认配置,添加新特性的升级流程大概需要2-3个月,修复一般bug需要1-2个月。对于出现了严重的有害bug或安全漏洞,区块生产者可能会加快修复,当然这一般来说是违反宪法的。具体如何权衡这个白皮书里面没有讲,我猜这应该需要社区的努力了。治理这部分,对于需要长期稳定运行的区块链产品是非常必要的,如果没有这部分,那么就没法避免分叉带来的危害。EOS在这方面我认为是当前做的最好的。











好的我们简单讲一下脚本和虚拟机,我们从上面可以看到,EOS首先给自己的定位是一个平台,用于协调向账户传送已认证的消息。而具体的脚本语言和虚拟机的细节都是特定于实现的细节的,这些细节大多数独立于EOS的技术设计。也就是说,任何具有足够性能的确定性和正确的沙箱化的语言或虚拟机都可以与EOS API集成。











模式定义的消息和模式定义的数据库,这两个我们放在一起讲,这两个概念从字面意思上不是很好理解,我的理解是,所有的消息或数据存储其实在实现上是使用二进制的方式发送或存储的,但是为了人类可读,他们都可以被解码成Json字符串。





分离授权与应用,这段出现在白皮书的这个地方我认为有点怪,我理解这部分应该出现在性能和并行计算部分。不管怎么说我们将这部分再讲一下:

为了最大限度的实现并行计算,并最大限度的减少与事物日志中重新生成应用程序状态相关的计算债务,EOS将验证逻辑分成三部分:1、验证消息是否内部一致;2、验证所有先决条件都是有效的;第三步才是修改应用程序状态。验证消息的内部一致性是只读的,而且不需要访问区块链状态,这意味着它可以以最大的并行度来执行;验证先决条件也是只读的,因此也可以从并行性中受益;修改应用程序状态才需要写权限,并且必须顺序处理每个应该程序。身份认证是一个验证消息可被使用的只读过程。 应用程序实际上在发挥作用。 实时计算时两者都需要被计算,然而一旦消息被包含进区块它就不再需要进行消息验证的操作了。






我们再来看一下虚拟机独立架构,上面的简介我们说了,理论上只要符合性能、确定性、正确性和沙箱化这几个条件的任何虚拟机都可以跟EOS进行对接,也就是说EOS的架构是独立于虚拟机的,所以叫虚拟机独立机构。白皮书上没有任何虚拟机的技术细节,就讲了两个虚拟机Web Assembly和以太坊虚拟机。Web Assembly是一个新兴的、高性能的虚拟机,它拥有llvm的编译后端,因此理论上可以支持所有支持llvm编译的众多编程语言,包括c和c++等。当前EOS的测试网络仅支持Web Assembly,也仅支持C和C++编程语言开发智能合约。EOS规划中也会支持以太坊虚拟机,以太坊虚拟机其实跟Web Assembly有点像,移植起来比较容易。当然支持以太坊虚拟机的重点不在于技术上的难易程度。试想一下,如果以太坊上的智能合约只要稍作修改就能在EOS上运行,那原来很多在以太坊上的项目就可以比较平滑的迁移到性能更高的EOS上。这对EOS的生态建设会有很大助力,当然以太坊也是一个不小的打击。






关于跨链通讯,我今天不准备跟大家讲细节,白皮书上的内容其实远远不够,只是跟大家同步一下,通过Merkle证明可以实现轻量级客户端,并且还能比较容易的实现跨链通讯。我会在高级篇重点讲解跨链通讯技术。

好了今天就讲到这里,经过四节课程我们终于将EOS的白皮书讲完了,非常感谢大家的参与。关于EOS白皮书的任何问题大家都可以提问了,我会挑选我能回答的问题回答。

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35
  查看全部
原文地址大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第四讲。我们来解读EOS白皮书的最后几部分。今天的内容相对于上一节课会简单一些,主要讲EOS的治理,然后简单讲一下虚拟机;跨链通讯部分我会在高级篇重点解读

3115234-6f776e9f780e9285.png


3115234-81c9f05e9049d3ab.png

我们先来看治理部分,所谓的治理我的理解就是管理那些没法完全使用软件算法实现的共识。在我们熟悉的区块链产品比特币和以太坊中是没有这部分共识的,这样就造成了一个非常严重的问题,社区经常因为一些原因分裂,导致分叉。2017年比特币已经被分叉无数次了,以太坊也已经出现了数次分叉,而这样的结果就是没有管理好非代码共识所造成的。

EOS认识到区块链的权力来源应该是Token持有人,而不应该是矿工,Token持有人将自己的权力通过投票的方式委托给区块生产者,这样区块生产者就具备了冻结账户、更新有缺陷的应用程序、提出对底层协议硬分叉的改变的权力。当然这种权力是受限的、是被检查的。可以用下面的结论总结这种权力:
所有的区块链变更都需要区块生产者同意,如果区块生产者拒绝Token持有人想要的变更,那么他将被投票出局,如果区块生产者的变更没有经过Token持有人的同意,那么其他非区块生产者的全节点会拒绝该改变。

3115234-d2bbbd3500190a2a.png


一个智能合约可能会出现异常比如说因为bug的原因导致行为不正确或者资源消耗不在一个合理的范围内,在这种情况下区块生产者有权力纠正这种情况,纠正的方式就是冻结账户,冻结账户的概念就是所有与待冻结账户有关的变更都不打包。冻结账户需要21分之17的区块生产者同意才行,如果区块生产者滥用权力,解决方案也很简单,就是将他投票出局,这样被冻结的账户就会被解冻。


3115234-9e0abb9646ca336b.png

如果冻结账户已经不能解决问题,不可预知的代码已经造成了破坏,此时EOS可以支持在不需要硬分叉的前提下修改账户代码。我的理解这有点类似于交易的回滚。当然与冻结账户类似,也需要21个中的17个区块生产者同意才行。

3115234-939008ee4f884a92.png


这里的宪法不知道翻译的准不准确,我的理解是这样的,智能合约也是要遵循法律法规的,很多事情是没有办法通过代码来进行约束的,同时由于EOS是全球性的,那么合约遵循哪里的法律法规就成了一个问题。这块EOS是怎么做的呢,就是将这些法规数字化,然后进行Hash签名,后面所有交易都要选一个宪法来绑定到合约中,这样就能解决管辖权和法律选择带来的争端。这个理解不一定是对的,因为白皮书上我的感觉也是写的不太清楚。


3115234-72ac8cb7fb2b04d9.png


EOS还规定了升级协议和宪法的流程,我们可以看一下,如果要对宪法进行修改,需要区块生产者提出,并获得至少17个区块生产者的批准,并且连续30天保持批准,然后所有用户都使用新的宪法hash来签署交易。升级代码协议也是类似的流程。按照EOS的默认配置,添加新特性的升级流程大概需要2-3个月,修复一般bug需要1-2个月。对于出现了严重的有害bug或安全漏洞,区块生产者可能会加快修复,当然这一般来说是违反宪法的。具体如何权衡这个白皮书里面没有讲,我猜这应该需要社区的努力了。治理这部分,对于需要长期稳定运行的区块链产品是非常必要的,如果没有这部分,那么就没法避免分叉带来的危害。EOS在这方面我认为是当前做的最好的。


3115234-9ef86e822dabde3d.png


3115234-ce873ccd46052a34.png

好的我们简单讲一下脚本和虚拟机,我们从上面可以看到,EOS首先给自己的定位是一个平台,用于协调向账户传送已认证的消息。而具体的脚本语言和虚拟机的细节都是特定于实现的细节的,这些细节大多数独立于EOS的技术设计。也就是说,任何具有足够性能的确定性和正确的沙箱化的语言或虚拟机都可以与EOS API集成。


3115234-727433ad6ec22863.png


3115234-258872573c957ff0.png

模式定义的消息和模式定义的数据库,这两个我们放在一起讲,这两个概念从字面意思上不是很好理解,我的理解是,所有的消息或数据存储其实在实现上是使用二进制的方式发送或存储的,但是为了人类可读,他们都可以被解码成Json字符串。

3115234-8a385993dabea285.png

分离授权与应用,这段出现在白皮书的这个地方我认为有点怪,我理解这部分应该出现在性能和并行计算部分。不管怎么说我们将这部分再讲一下:

为了最大限度的实现并行计算,并最大限度的减少与事物日志中重新生成应用程序状态相关的计算债务,EOS将验证逻辑分成三部分:1、验证消息是否内部一致;2、验证所有先决条件都是有效的;第三步才是修改应用程序状态。验证消息的内部一致性是只读的,而且不需要访问区块链状态,这意味着它可以以最大的并行度来执行;验证先决条件也是只读的,因此也可以从并行性中受益;修改应用程序状态才需要写权限,并且必须顺序处理每个应该程序。身份认证是一个验证消息可被使用的只读过程。 应用程序实际上在发挥作用。 实时计算时两者都需要被计算,然而一旦消息被包含进区块它就不再需要进行消息验证的操作了。

3115234-94c8f5eaacc9654b.png


我们再来看一下虚拟机独立架构,上面的简介我们说了,理论上只要符合性能、确定性、正确性和沙箱化这几个条件的任何虚拟机都可以跟EOS进行对接,也就是说EOS的架构是独立于虚拟机的,所以叫虚拟机独立机构。白皮书上没有任何虚拟机的技术细节,就讲了两个虚拟机Web Assembly和以太坊虚拟机。Web Assembly是一个新兴的、高性能的虚拟机,它拥有llvm的编译后端,因此理论上可以支持所有支持llvm编译的众多编程语言,包括c和c++等。当前EOS的测试网络仅支持Web Assembly,也仅支持C和C++编程语言开发智能合约。EOS规划中也会支持以太坊虚拟机,以太坊虚拟机其实跟Web Assembly有点像,移植起来比较容易。当然支持以太坊虚拟机的重点不在于技术上的难易程度。试想一下,如果以太坊上的智能合约只要稍作修改就能在EOS上运行,那原来很多在以太坊上的项目就可以比较平滑的迁移到性能更高的EOS上。这对EOS的生态建设会有很大助力,当然以太坊也是一个不小的打击。


3115234-0e13e33a25c423bf.png

关于跨链通讯,我今天不准备跟大家讲细节,白皮书上的内容其实远远不够,只是跟大家同步一下,通过Merkle证明可以实现轻量级客户端,并且还能比较容易的实现跨链通讯。我会在高级篇重点讲解跨链通讯技术。

好了今天就讲到这里,经过四节课程我们终于将EOS的白皮书讲完了,非常感谢大家的参与。关于EOS白皮书的任何问题大家都可以提问了,我会挑选我能回答的问题回答。

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35
 

EOS从入门到精通(三)

郑浩 发表了文章 • 0 个评论 • 2097 次浏览 • 2018-01-12 15:52 • 来自相关话题

原文地址大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第三讲。今天我们来解读EOS白皮书中的“应用程序的确定性并行”和“Token模型与资源使用”:下面是这两章节的思维导图:










我们先来讲解一下应用程序的确定性并行,这部分在入门篇我们不做重点解读,因为这里面涉及到了很多编程方面的知识,我在这里只跟大家做一下同步,让大家对EOS的高性能有一些感性的认识。





好,我们开始应用程序确定性并行这个章节的解读:该部分从简介、最小化的通讯延迟、只读消息处理、多账户的原子交易、区块链状态的部分评估、自主最优调度这几个方面跟大家讲解EOS并行执行的原理。





我们知道区块链最简单的理解是一个公共的账本,而维护账本共识的核心基础就是行为的确定性,这意味着如果需要并行计算,那么所有的并行计算都不能互斥或加锁,因为锁的状态是不确定的。不加锁,就需要一些方法来保证所有账户只能读写自己的私有数据库。这样每个账户都必须顺序的处理消息,因此EOS的并行级别是账户级别的。

EOS将消息传递 组织成独立的线程,这样可以比较容易的评估线程并行的可能性,因为每个账户的状态只取决于传递给他们的消息。进度表,我这里理解成消息的执行顺序,这个顺序在区块产生后是确定的,而在产生过程中是不确定的,是由区块生产者按照并行算法决定。比如说区块生产者A生产区块,那么消息执行顺序就由A来决定,A产生区块后,生产者B验证区块时要完全按照A的执行顺序来验证。

当脚本产生一个消息后不会被立即传送,而是会被安排到下一个循环,因为接收方当前可能在另一个线程内主动修改自己的状态。







最小通讯延迟,这里的延迟,是指一个账户向另一个账号发送消息并接收响应所需要的时间,EOS的设计目标是能够在一个区块内来回交换消息,那么EOS是如何做到的呢?EOS将区块分成了几个循环,循环又分成了多个线程,每个线程包含一个交易列表,每个交易包含一组要传递的消息。这个结构可以看成为一棵树,在这个树中交替的层被顺序的并行的处理,我们看下面这张图






可以看到,循环是顺序执行的,线程是可以并行的,交易和消息是要顺执行的,而接受者和被通知的账户是可以并行的。为什么接受者这个地方是可以并行呢?这要看一下下面的只读消息处理





只读消息的处理,EOS对于无需更新状态的消息处理是可以并行的,只要特定的只读消息处理程序被包含在特定的循环内的一个或多个线程中就可以。






我们再来看一下多账户的原子交易。有些时候需要确保消息以原子的方式传递给多个账户并需要被其接受。在这种情况下双边的消息会被放在同一个交易中,两边的账户也会被分配在相同的线程,并且消息会被顺序的处理。这样做的目的是为了确保交易成功,而这其实会带来性能上的损耗,而且在成本上也会很高,因此出于性能和成本的考虑,应用程序最好能尽力减少涉及两个或更多使用率高的账户的原子操作。







区块链状态的部分评估,我简单说一下我的理解,不同于以太坊所有的全节点都必须运行所有的合约,EOS具备这种允许完整节点选择要运行的任何程序子集的能力,这样带来一个好处就是如果我仅仅运行一个小应用,那么我可以使用有限资源启动完整节点,比如一个交易所的开发人员运行完整节点,以便向用户展示交易状态,这个程序是不需要与社交媒体的程序有状态关联的。






自主最优调度,我的理解是EOS设计了这样一个调度框架,每个区块生产者都可以根据自己的算法来进行区块的生产。EOS不强制区块生产者将任何消息发送给任何其他账户,每个区块生产者都可以根据处理交易所需的计算复杂性和时间做出自己的主观预测。

在网络层面上,所有的交易都会收取一个固定的计算带宽成本,区块生产者也可以使用自己的算法来测量资源的使用。这里的计算带宽,我的理解应该是广义的,可能包含计算资源,状态存储资源以及网络带宽。

一般情况下只要一个区块生产者认为交易在资源使用的限度内是有效的,那么所有的其他区块生产者也会接受,但是交易可能需要最长1分钟才能找到生产者,为什么是一分钟,因为一分钟内交易可以在21个区块生产者之间流转一遍,如果还没有找到,那么这个交易就不会被打包了。






好了,关于程序确定性和并行执行就讲到这里,我们来看一下TOKEN模型和资源使用。主要从简介、客观与主管的衡量、付费策略、委托能力、分离交易成本与Token的价值、状态存储成本、区块奖励和社区利益应用这几个方面解读。





所有的区块链资源都是有限的,需要系统的防止被滥用,比特币和以太坊是用手续费和Gas来防止资源被无限使用的,那么EOS是怎么防止资源被滥用的呢?

我们先看一下EOS提供的资源有哪些,主要有存储和带宽资源、计算和计算Backlog以及状态存储。先解释一下计算Backlog是什么,可以翻译成计算积压,我的理解是这样的,比如说一个完整节点断网一段时间,等重新联网后需要重新同步未同步的区块,然后对这些新的区块进行重新验算,我理解这些计算任务就叫计算Backlog。

区块生产者发布他们的带宽、计算资源和状态存储资源、每个用户对资源的使用率跟Token持有的比例成正比。持有1%的Token的账户可以使用1%的状态存储资源。

带宽和计算资源由于是瞬时资源没法保存,因此采用的策略是在保留的基础上进行分配,算法类似于Steamit限制带宽的算法,有点像QoS算法。举例来说:假如你持有1%的Token,那么在瞬时资源的使用上,你最少可以使用到1%,如果系统比较空闲,那么你可以使用的更多,如果系统非常繁忙,那么系统至少可以保证有1%的资源是专门给你提供的。






所有的资源使用约束最终都是主观的,由区块生产者根据各自的算法和估计来执行,EOS允许使用客观的根据消息或存储容量来衡量消耗,也可以自己定义主观的衡量算法。我的理解是,EOS给了一个推荐的简单算法,至于区块生产者要不要使用,由他们自己决定。这在EOS上都是允许的。





付费策略,这个我们也早就提过了,应用不能强制用户为使用区块链资源而付费,同样的EOS也不会强制应用的收费策略。






委托能力,我们知道,持有EOS的人不一定是应用开发者,可能不会立即使用链上资源,那么这些人就可以向其他用户提供或出租这些带宽,EOS允许这样做,同时区块生产者能够识别这样的授权,并相应的分配带宽。通过这个设计,将来EOS的持有者通过出租EOS可能就能带来持续的盈利。这就是为什么有人将EOS比作地皮的原因。






分离交易成本与Token的价值,这点非常重要,它的优点就是应用程序的可用带宽仅取决于Token的持有量跟Token的价格没有关系,只要持有一定数量的Token,就可以在固定的状态和带宽使用的情况下永久的用下去。开发者和用户不受Token市值波动的影响。这点是比特币和以太坊做不到的。

EOS区块链使区块生产者能够自然地增加每个Token可用的带宽,计算和存储,而不管Token的价值如何。EOS区块链每次产生区块时都会授予区块生产者Token。Token的价值将影响生产者能够购买的带宽,存储和计算量;这个模型自然会利用上升的Token价值来提高网络性能。






虽然可以委托带宽和计算资源,但应用程序状态的存储将要求开发人员持有Token,直到该状态被删除。如果状态从未被删除,则Token被有效地从流通中移除。每个账户都需要一定的存储空间,因此每个账户都必须保持最低的余额,随着网络存储容量的增加,这个最低要求的平衡将会下降。





块奖励,由所有区块生产上公布的期望收益的中位数决定,EOS可能会配置区块生产者的奖励执行上限,使得Token的供应的年度增长在5%以内。

关于社区利益应用这个章节,说实话我没太看明白,英文和翻译过来的中文都没太理解,这里就不给大家讲了,以免传递错误的信息,好在这个部分看起来不是非常重要。如果有了解的同学可以发消息说一下。

好了,今天的主要内容就讲到这里,总结一下,我们今天讲了两部分内容,并行执行和Token模型与资源使用。重点在Token模型与资源使用的理解上。理解了这个才能明白EOS Token本身的价值所在。我在前段时间写过专门写过一小篇文章介绍EOS的经济系统,可以给大家分享一下。地址是:EOS经济系统分析

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35 查看全部
原文地址大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第三讲。今天我们来解读EOS白皮书中的“应用程序的确定性并行”和“Token模型与资源使用”:下面是这两章节的思维导图:

3115234-e2de29b9edfca842.png


3115234-6a8cd6a8a2254d5d.png

我们先来讲解一下应用程序的确定性并行,这部分在入门篇我们不做重点解读,因为这里面涉及到了很多编程方面的知识,我在这里只跟大家做一下同步,让大家对EOS的高性能有一些感性的认识。

3115234-90a06ff3c2fa810e.jpeg

好,我们开始应用程序确定性并行这个章节的解读:该部分从简介、最小化的通讯延迟、只读消息处理、多账户的原子交易、区块链状态的部分评估、自主最优调度这几个方面跟大家讲解EOS并行执行的原理。

3115234-d16b3737cd4b4f70.jpeg

我们知道区块链最简单的理解是一个公共的账本,而维护账本共识的核心基础就是行为的确定性,这意味着如果需要并行计算,那么所有的并行计算都不能互斥或加锁,因为锁的状态是不确定的。不加锁,就需要一些方法来保证所有账户只能读写自己的私有数据库。这样每个账户都必须顺序的处理消息,因此EOS的并行级别是账户级别的。

EOS将消息传递 组织成独立的线程,这样可以比较容易的评估线程并行的可能性,因为每个账户的状态只取决于传递给他们的消息。进度表,我这里理解成消息的执行顺序,这个顺序在区块产生后是确定的,而在产生过程中是不确定的,是由区块生产者按照并行算法决定。比如说区块生产者A生产区块,那么消息执行顺序就由A来决定,A产生区块后,生产者B验证区块时要完全按照A的执行顺序来验证。

当脚本产生一个消息后不会被立即传送,而是会被安排到下一个循环,因为接收方当前可能在另一个线程内主动修改自己的状态。


3115234-92a0e2bb8de68a3d.jpeg


最小通讯延迟,这里的延迟,是指一个账户向另一个账号发送消息并接收响应所需要的时间,EOS的设计目标是能够在一个区块内来回交换消息,那么EOS是如何做到的呢?EOS将区块分成了几个循环,循环又分成了多个线程,每个线程包含一个交易列表,每个交易包含一组要传递的消息。这个结构可以看成为一棵树,在这个树中交替的层被顺序的并行的处理,我们看下面这张图


3115234-907334d8b97f0840.png

可以看到,循环是顺序执行的,线程是可以并行的,交易和消息是要顺执行的,而接受者和被通知的账户是可以并行的。为什么接受者这个地方是可以并行呢?这要看一下下面的只读消息处理

3115234-e3fc42125b6c55a2.jpeg

只读消息的处理,EOS对于无需更新状态的消息处理是可以并行的,只要特定的只读消息处理程序被包含在特定的循环内的一个或多个线程中就可以。

3115234-e7123f9ef376c2d2.jpeg


我们再来看一下多账户的原子交易。有些时候需要确保消息以原子的方式传递给多个账户并需要被其接受。在这种情况下双边的消息会被放在同一个交易中,两边的账户也会被分配在相同的线程,并且消息会被顺序的处理。这样做的目的是为了确保交易成功,而这其实会带来性能上的损耗,而且在成本上也会很高,因此出于性能和成本的考虑,应用程序最好能尽力减少涉及两个或更多使用率高的账户的原子操作。


3115234-969a8c63c4c4cfd9.jpeg


区块链状态的部分评估,我简单说一下我的理解,不同于以太坊所有的全节点都必须运行所有的合约,EOS具备这种允许完整节点选择要运行的任何程序子集的能力,这样带来一个好处就是如果我仅仅运行一个小应用,那么我可以使用有限资源启动完整节点,比如一个交易所的开发人员运行完整节点,以便向用户展示交易状态,这个程序是不需要与社交媒体的程序有状态关联的。


3115234-432e599677e0e9e4.jpeg

自主最优调度,我的理解是EOS设计了这样一个调度框架,每个区块生产者都可以根据自己的算法来进行区块的生产。EOS不强制区块生产者将任何消息发送给任何其他账户,每个区块生产者都可以根据处理交易所需的计算复杂性和时间做出自己的主观预测。

在网络层面上,所有的交易都会收取一个固定的计算带宽成本,区块生产者也可以使用自己的算法来测量资源的使用。这里的计算带宽,我的理解应该是广义的,可能包含计算资源,状态存储资源以及网络带宽。

一般情况下只要一个区块生产者认为交易在资源使用的限度内是有效的,那么所有的其他区块生产者也会接受,但是交易可能需要最长1分钟才能找到生产者,为什么是一分钟,因为一分钟内交易可以在21个区块生产者之间流转一遍,如果还没有找到,那么这个交易就不会被打包了。


3115234-922ffc6c696e7ead.jpeg

好了,关于程序确定性和并行执行就讲到这里,我们来看一下TOKEN模型和资源使用。主要从简介、客观与主管的衡量、付费策略、委托能力、分离交易成本与Token的价值、状态存储成本、区块奖励和社区利益应用这几个方面解读。

3115234-952e0b50986021ae.jpeg

所有的区块链资源都是有限的,需要系统的防止被滥用,比特币和以太坊是用手续费和Gas来防止资源被无限使用的,那么EOS是怎么防止资源被滥用的呢?

我们先看一下EOS提供的资源有哪些,主要有存储和带宽资源、计算和计算Backlog以及状态存储。先解释一下计算Backlog是什么,可以翻译成计算积压,我的理解是这样的,比如说一个完整节点断网一段时间,等重新联网后需要重新同步未同步的区块,然后对这些新的区块进行重新验算,我理解这些计算任务就叫计算Backlog。

区块生产者发布他们的带宽、计算资源和状态存储资源、每个用户对资源的使用率跟Token持有的比例成正比。持有1%的Token的账户可以使用1%的状态存储资源。

带宽和计算资源由于是瞬时资源没法保存,因此采用的策略是在保留的基础上进行分配,算法类似于Steamit限制带宽的算法,有点像QoS算法。举例来说:假如你持有1%的Token,那么在瞬时资源的使用上,你最少可以使用到1%,如果系统比较空闲,那么你可以使用的更多,如果系统非常繁忙,那么系统至少可以保证有1%的资源是专门给你提供的。


3115234-18833c0d2e58223e.jpeg

所有的资源使用约束最终都是主观的,由区块生产者根据各自的算法和估计来执行,EOS允许使用客观的根据消息或存储容量来衡量消耗,也可以自己定义主观的衡量算法。我的理解是,EOS给了一个推荐的简单算法,至于区块生产者要不要使用,由他们自己决定。这在EOS上都是允许的。

3115234-c95b1066a4c4ce43.jpeg

付费策略,这个我们也早就提过了,应用不能强制用户为使用区块链资源而付费,同样的EOS也不会强制应用的收费策略。

3115234-4719dbbd50abd0fc.jpeg


委托能力,我们知道,持有EOS的人不一定是应用开发者,可能不会立即使用链上资源,那么这些人就可以向其他用户提供或出租这些带宽,EOS允许这样做,同时区块生产者能够识别这样的授权,并相应的分配带宽。通过这个设计,将来EOS的持有者通过出租EOS可能就能带来持续的盈利。这就是为什么有人将EOS比作地皮的原因。


3115234-ee6d56fb81761dba.jpeg

分离交易成本与Token的价值,这点非常重要,它的优点就是应用程序的可用带宽仅取决于Token的持有量跟Token的价格没有关系,只要持有一定数量的Token,就可以在固定的状态和带宽使用的情况下永久的用下去。开发者和用户不受Token市值波动的影响。这点是比特币和以太坊做不到的。

EOS区块链使区块生产者能够自然地增加每个Token可用的带宽,计算和存储,而不管Token的价值如何。EOS区块链每次产生区块时都会授予区块生产者Token。Token的价值将影响生产者能够购买的带宽,存储和计算量;这个模型自然会利用上升的Token价值来提高网络性能。


3115234-d691d8cfcc9eb11e.jpeg

虽然可以委托带宽和计算资源,但应用程序状态的存储将要求开发人员持有Token,直到该状态被删除。如果状态从未被删除,则Token被有效地从流通中移除。每个账户都需要一定的存储空间,因此每个账户都必须保持最低的余额,随着网络存储容量的增加,这个最低要求的平衡将会下降。

3115234-a58eff9b0e097704.jpeg

块奖励,由所有区块生产上公布的期望收益的中位数决定,EOS可能会配置区块生产者的奖励执行上限,使得Token的供应的年度增长在5%以内。

关于社区利益应用这个章节,说实话我没太看明白,英文和翻译过来的中文都没太理解,这里就不给大家讲了,以免传递错误的信息,好在这个部分看起来不是非常重要。如果有了解的同学可以发消息说一下。

好了,今天的主要内容就讲到这里,总结一下,我们今天讲了两部分内容,并行执行和Token模型与资源使用。重点在Token模型与资源使用的理解上。理解了这个才能明白EOS Token本身的价值所在。我在前段时间写过专门写过一小篇文章介绍EOS的经济系统,可以给大家分享一下。地址是:EOS经济系统分析

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35

EOS存储系统介绍

郑浩 发表了文章 • 0 个评论 • 1106 次浏览 • 2017-12-27 20:57 • 来自相关话题

EOS简介


近期 EOS 的团队发布了EOS存储部分的白皮书。根据白皮书上的内容我们可以了解EOS存储部分的设计理念。

首先EOS存储基于IPFS(星际文件系统)之上设计的;

其次不同与一些去中心化的存储方案需要特殊的工具或特殊的浏览器,EOS存储可以提供任意浏览器访问的能力;

EOS存储使用基于EOS发行的token TOK激励区块生产这保证存储的可访问性和带宽。

下面我们详细说一下EOS具体的设计细节
 
IPFS

IPFS是一种去中心化的文件系统,它将文件名和文件内容强关联起来(文件名是文件内容的hash)。也就是说在任意终端上,相同文件内容的文件其名称也一定相同。当你下载一个文件的时候可以通过文件名来校验文件的完整性。IPFS提供了一个p2p的网络传输层用于终端之间基于文件名称发现和分享文件。但是IPFS并不提供和保证文件的存储、托管和带宽。也就是说即使能有文件名,但是有可能找不到对应的文件内容。IPFS团队为了解决这个问题,发布了FileCoin区块链,使用区块链的支付系统来激励拥有剩余存储空间的人帮助提供稳定可靠文件的存储、托管和带宽(具体规则我没有深入研究,按照白皮书上讲的,FileCoin 应该跟 Maidsafe, Siacoin, 和 Storj类似)。

EOS对存储的需求

作为一个可以任意运行智能合约的平台,EOS设计性能需要达到百万级。这个这样的设计如果每秒进行100w次交易,每次交易产生100字节的数据,那么每秒钟就有100M的数据记录。如果每个区块生产节点都要存储一份这样的数据,那时间稍久数据量就是一个天文数字。另外,对于一些智能合约他们天然就有存储数据的需要,比如需要存储文字、图片、声音、视频等等数据。这些数据更不可能存储在区块链上了。

EOS存储的设计

按照EOS的需求,那IPFS+FileCoin是不是就解决了呢?理论上是的,但是有一个问题,FileCoin的经济激励系统是不符合EOS的设计哲学的,它需要终端用户为使用存储和带宽付费。基于这样的考虑,EOS没有选择IPFS+FileCoin的方案。而是基于IPFS自己设计了一套机制。

首先设计了一套文件系统智能合约,发行了一种 token 叫TOK。它允许每个用户定义一个目录结构,这个目录结构下面的所有文件都链接了一个IPFS文件。也就是说TOK只存储IPFS的文件链接和一个人类可读的文件名。

那如何上传一个文件?

用户通过签名一个交易创建一个指向IPFS文件的链接,并将该交易广播的区块链。这个交易包含了用户的home目录和相应的IPFS文件名以及文件大小。同时用户也可以指定文件被存储在哪个TOK 区块生产者上。然后用户将通过标准的restfull api(API由EOS.io定义)上传文件到指定的区块生产者。一旦区块生产者验证文件和文件名匹配,则其会广播交易到整个区块链系统,其他的区块生产会通过IPFS网络复制那个文件。这样用户就成功的上传了一个文件,同时在的home目录下保存了该文件的链接。

我们上面提到了,IPFS是不保证文件的可用性的,那么EOS怎么保证呢?另外每一个人能存储多大体积的文件?如何分配有限的资源呢?这要说一下TOK的作用了。

EOS存储里定义TOK,若用户需要存储空间那必须锁定一部分TOK(这个概念跟我们之前讲的使用EOS资源需要锁定EOS是相同的道理),不同的是其价格里面出现了一个参数叫CRR(Constant Reserve Ratio我翻译成准备金率常数)并且定义了一个公式:价格=余额/(供给*CRR)。

为什么要有这个CRR我一开始也不太理解,想了很长时间才想明白,TOK跟EOS token有一个非常大的区别EOS token只有一个服务商(区块链系统)但是存储系统设计的就不是这样,它可以有很多服务商不同的服务商在均衡服务质量和服务价格方面如何体现自己的竞争力呢?就是靠调整CRR。就是说有些服务商可能提供的服务质量比较高那他们可以将CRR调高一些,而有些服务商可能质量相对一般,那他们为了提高自己的竞争力就会将CRR调低一些。

不良信息的管控

这里就不多讲了,大致上说EOS存储可以任意删除不符合法律规定的内容,由于EOS是国际化的那可能出现内容符合某个法律但是不符合另外一个法律的情况,这就需要社区来进行维护,对于不守规矩的区块生产者就将它票出去。

隐私

EOS存储是一个存储公共信息的平台,如果你想存储私有信息,那需要你在上传之前就自行加密。

去中心化和复制(副本)

区块生产者们代表的是至少20个独立的个人或组织,每一个生产者可以复制和托管全球不同辖区的数据。只要这20个区块生产者有一个在线并提供文件,那么这个文件就可以被提供给所有人。

该方法提供了比其他存储方案更好的可用性,因为区块生产者需要随时更新他们的服务已获得投票并且获得区块生产的报酬。

得票排在25名以后的区块生产者是没有义务存储数据提供服务的,但是他们要展示自己的能力以便能被投票到排名前25。

EOS存储的经济系统

天下没有免费的午餐,那到底是谁在为存储空间和带宽付费呢?

存储的经济系统

存储的经济系统相对简单一些,持有TOK的的人将有每年5%的EOS通胀来支付。其供需逻辑跟我们之前分析EOS token的逻辑是一致的。也就是说最终支付存储费用的是TOK的时间价值。

带宽的经济系统

相对存储,带宽的分配相对复杂一些,因为内容的生产者和内容的消费者是完全不对等的,如果由内容生产者来支付所有消费者的带宽这可能不现实,比如说有个用户上传了一个视频到Youtube上,结果被点击播放了几百万次,这个带宽的费用其实是惊人的。那么怎么处理带宽的激励经济呢?EOS想的办法按照我的理解是对于在EOS系统内的用户不管是上传还是下载数据占用的带宽,都将锁定一小部分TOK(仅在使用时锁定,使用完成后释放),由TOK的时间价值来支付带宽成本。另外区块生产者还需要免费提供一部分带宽给没有在EOS系统注册的用户使用。

另外内容上传者可以提供TOK来补贴带宽,比如部分广告或电影宣传片。

总结

EOS存储的设计理念处处体现着EOS的设计哲学,特别是其经济激励系统,无处不在。在去中心化的世界里提供类似中心化的服务,也许这才是区块链的正确发展方向。

参考资料《EOS storage whitepaper》

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

  查看全部
EOS简介


近期 EOS 的团队发布了EOS存储部分的白皮书。根据白皮书上的内容我们可以了解EOS存储部分的设计理念。

首先EOS存储基于IPFS(星际文件系统)之上设计的;

其次不同与一些去中心化的存储方案需要特殊的工具或特殊的浏览器,EOS存储可以提供任意浏览器访问的能力;

EOS存储使用基于EOS发行的token TOK激励区块生产这保证存储的可访问性和带宽。

下面我们详细说一下EOS具体的设计细节
 
IPFS

IPFS是一种去中心化的文件系统,它将文件名和文件内容强关联起来(文件名是文件内容的hash)。也就是说在任意终端上,相同文件内容的文件其名称也一定相同。当你下载一个文件的时候可以通过文件名来校验文件的完整性。IPFS提供了一个p2p的网络传输层用于终端之间基于文件名称发现和分享文件。但是IPFS并不提供和保证文件的存储、托管和带宽。也就是说即使能有文件名,但是有可能找不到对应的文件内容。IPFS团队为了解决这个问题,发布了FileCoin区块链,使用区块链的支付系统来激励拥有剩余存储空间的人帮助提供稳定可靠文件的存储、托管和带宽(具体规则我没有深入研究,按照白皮书上讲的,FileCoin 应该跟 Maidsafe, Siacoin, 和 Storj类似)。

EOS对存储的需求

作为一个可以任意运行智能合约的平台,EOS设计性能需要达到百万级。这个这样的设计如果每秒进行100w次交易,每次交易产生100字节的数据,那么每秒钟就有100M的数据记录。如果每个区块生产节点都要存储一份这样的数据,那时间稍久数据量就是一个天文数字。另外,对于一些智能合约他们天然就有存储数据的需要,比如需要存储文字、图片、声音、视频等等数据。这些数据更不可能存储在区块链上了。

EOS存储的设计

按照EOS的需求,那IPFS+FileCoin是不是就解决了呢?理论上是的,但是有一个问题,FileCoin的经济激励系统是不符合EOS的设计哲学的,它需要终端用户为使用存储和带宽付费。基于这样的考虑,EOS没有选择IPFS+FileCoin的方案。而是基于IPFS自己设计了一套机制。

首先设计了一套文件系统智能合约,发行了一种 token 叫TOK。它允许每个用户定义一个目录结构,这个目录结构下面的所有文件都链接了一个IPFS文件。也就是说TOK只存储IPFS的文件链接和一个人类可读的文件名。

那如何上传一个文件?

用户通过签名一个交易创建一个指向IPFS文件的链接,并将该交易广播的区块链。这个交易包含了用户的home目录和相应的IPFS文件名以及文件大小。同时用户也可以指定文件被存储在哪个TOK 区块生产者上。然后用户将通过标准的restfull api(API由EOS.io定义)上传文件到指定的区块生产者。一旦区块生产者验证文件和文件名匹配,则其会广播交易到整个区块链系统,其他的区块生产会通过IPFS网络复制那个文件。这样用户就成功的上传了一个文件,同时在的home目录下保存了该文件的链接。

我们上面提到了,IPFS是不保证文件的可用性的,那么EOS怎么保证呢?另外每一个人能存储多大体积的文件?如何分配有限的资源呢?这要说一下TOK的作用了。

EOS存储里定义TOK,若用户需要存储空间那必须锁定一部分TOK(这个概念跟我们之前讲的使用EOS资源需要锁定EOS是相同的道理),不同的是其价格里面出现了一个参数叫CRR(Constant Reserve Ratio我翻译成准备金率常数)并且定义了一个公式:价格=余额/(供给*CRR)。

为什么要有这个CRR我一开始也不太理解,想了很长时间才想明白,TOK跟EOS token有一个非常大的区别EOS token只有一个服务商(区块链系统)但是存储系统设计的就不是这样,它可以有很多服务商不同的服务商在均衡服务质量和服务价格方面如何体现自己的竞争力呢?就是靠调整CRR。就是说有些服务商可能提供的服务质量比较高那他们可以将CRR调高一些,而有些服务商可能质量相对一般,那他们为了提高自己的竞争力就会将CRR调低一些。

不良信息的管控

这里就不多讲了,大致上说EOS存储可以任意删除不符合法律规定的内容,由于EOS是国际化的那可能出现内容符合某个法律但是不符合另外一个法律的情况,这就需要社区来进行维护,对于不守规矩的区块生产者就将它票出去。

隐私

EOS存储是一个存储公共信息的平台,如果你想存储私有信息,那需要你在上传之前就自行加密。

去中心化和复制(副本)

区块生产者们代表的是至少20个独立的个人或组织,每一个生产者可以复制和托管全球不同辖区的数据。只要这20个区块生产者有一个在线并提供文件,那么这个文件就可以被提供给所有人。

该方法提供了比其他存储方案更好的可用性,因为区块生产者需要随时更新他们的服务已获得投票并且获得区块生产的报酬。

得票排在25名以后的区块生产者是没有义务存储数据提供服务的,但是他们要展示自己的能力以便能被投票到排名前25。

EOS存储的经济系统

天下没有免费的午餐,那到底是谁在为存储空间和带宽付费呢?

存储的经济系统

存储的经济系统相对简单一些,持有TOK的的人将有每年5%的EOS通胀来支付。其供需逻辑跟我们之前分析EOS token的逻辑是一致的。也就是说最终支付存储费用的是TOK的时间价值。

带宽的经济系统

相对存储,带宽的分配相对复杂一些,因为内容的生产者和内容的消费者是完全不对等的,如果由内容生产者来支付所有消费者的带宽这可能不现实,比如说有个用户上传了一个视频到Youtube上,结果被点击播放了几百万次,这个带宽的费用其实是惊人的。那么怎么处理带宽的激励经济呢?EOS想的办法按照我的理解是对于在EOS系统内的用户不管是上传还是下载数据占用的带宽,都将锁定一小部分TOK(仅在使用时锁定,使用完成后释放),由TOK的时间价值来支付带宽成本。另外区块生产者还需要免费提供一部分带宽给没有在EOS系统注册的用户使用。

另外内容上传者可以提供TOK来补贴带宽,比如部分广告或电影宣传片。

总结

EOS存储的设计理念处处体现着EOS的设计哲学,特别是其经济激励系统,无处不在。在去中心化的世界里提供类似中心化的服务,也许这才是区块链的正确发展方向。

参考资料《EOS storage whitepaper》

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

 

EOS从入门到精通-账户体系(文字稿)

郑浩 发表了文章 • 1 个评论 • 1273 次浏览 • 2017-12-27 09:05 • 来自相关话题

本文是王巨老师EOS课程的文字版,首发在简书,经本人同意后转载,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第二讲。今天的课程原本计划讲两部分内容,账户系统和并行执行。但是一天的备课下来,我发现账户系统的内容特别多,而且理解EOS的账号体系对于将来进行智能合约的开发非常有帮助,因此我决定在本次课程中详细给大家讲解一下EOS的账户体系。并行执行这部分放到下一讲跟TOKEN模型放到一起。
另外,上次有同学说没有ppt的问题,我今天也会在讲课的过程中穿插加入ppt。




大家可以先看一下上面这个思维导图,这就是本节课要讲解的大纲。主要分了5个章节,简介、消息和处理程序、基于角色的权限管理、带有强制延时性的消息、恢复被盗窃的密钥。其中今天会重点讲解基于角色的权限管理。

好的,我们开始讲解EOS的权限系统
 



EOS相对于比特币和以太坊只有私钥和地址的概念,EOS的账户体系是相当完备的,从这点来看,比特币和以太坊在可用性上差了EOS一大截。比如说比特币和以太坊没法自定义账户地址,只能用一堆人类没法理解的字符串做地址和私钥。而EOS可以使用一个人类可以阅读的2-32个字符来创建账户。另外在白皮书上强调,创建一个账号需要付出额外的一点点成本,来覆盖账户的存储成本,这一般是由开发者也就是应用提供方来承担。最后,EOS的账户还支持域的概念,比如说:
@domain这个账号的拥有者是唯一能创建@user.domain的人。




好我们继续讲消息和处理程序,讲账户为什么要讲消息和处理程序呢?这是因为账户和消息是EOS只能合约的两个不可或缺的组成部分,而且他们之间有着密切的关联,单独讲哪一个也没法讲清楚他们的本质。我们看看EOS的消息机制就明白了,所谓的消息就是账户与账户之间的沟通语言,每个账户都可以发送结构化的消息给任意其他账户,每个账户都可以定义处理消息的脚本,每个账户还有自己的私有数据库,消息处理脚本也可以给其他账户发消息,最终 消息和消息处理脚本组成了EOS的智能合约。
我来进一步解释一下,发消息很容易理解,消息处理脚本就是在一个账户收到了消息之后怎么处理消息。这个处理脚本本身还可以发消息给其他账户。这个怎么理解呢?我的理解是有些消息是人手工发的,比如说a给b转账50eos,有些消息是可以由处理消息的脚本来发的,比如说b在收到50eos这个消息后有个消息处理脚本会自动向c发送25个eos。这其实就是一个非常简单的合约了。




好的,我们来讲一下今天的重点基于角色的权限管理,这也是BM系区块链的一个特色,权限管理在BTS和Steamit上已经比较完善了,在EOS上还会做更多的优化。我们先来看看权限管理的简介:判断一条消息是否被授权最简单的方式是包含一个签名,当然验证这个签名的前提是要知道这个签名是谁的。一般来说权限是与个体或群组绑定在一起,理论上不会有一种权限跟个体或群组没关系,因为这样是没有意义的。EOS提供了细粒度和高级别的权限控制,可以控制到谁在什么时候做什么事情。认证和权限管理必须标准化,并且与应用程序的业务逻辑分开,这样可以用通用的方式来管理权限,并且为性能优化提供可能。EOS还支持多账户的控制机制,能对账户的安全性提供保障,减少被黑客攻击而造成的资金损失风险。EOS甚至还允许定义什么密钥或账户可以发送特定的消息类型给另一个账户。
举个例子:一个用户的社交媒体账户可以使用一个密钥,而另一个密钥可以用于访问交易所,甚至可以授权其他账户来代表本账户而不是分配一个密钥。

下面我们就详细讲一下EOS的权限管理方案:




首先EOS为权限级别进行了命名比如说Owner、Active、Friend。这些命名可以是系统默认的比如Owner和Active,有些是可以自定义的比如Friend的。我们来看Steamit里面的权限实例:它是硬编码了三个权限级别:Owner、Active、Posting。其中Posting权限只能进行发帖操作投票等社交操作,Active权限可以做除了修改Owner以外的所有事情。Owner可以作为冷备份而存在。EOS本身也囊括了这些概念,而且允许自定义权限的层次结构和分组。




在设计了权限级别之后,EOS还设计了命名的消息处理群组,这个命名的消息处理群组可以在其他帐户配置他们权限级别时被引用。上面有一个简单的例子,在账户名下有一个分组A,分组A下面有个子分组b,它下面有消息类型。一个交易所的交易合约 在这种模式下就可以将订单的创建和取消 分开存取,通过交易合约进行分组 可以方便 交易所用户。




 权限级别和消息处理群组,这两个概念之间就可以做映射了。就是说可以将某个消息处理群组分配到某个权限级别上,或者反过来说,可以在某个权限级别上定义很多消息处理群组。举个例子:一个帐户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射。 有了这个映射,任何朋友可以以这一帐户的身份在这一帐户的社交媒体上发帖。 尽管他们将以帐户所有者的身份发帖,他们仍然使用自己的密钥来签名消息。 这意味着总是可以辨识出是哪一个朋友在以何种方式使用帐户。




如何进行权限评估,简单的来讲就是从小到大进行逐级匹配,比如:当 @alice 以 "Action" 类型发送一条消息给 @bob 时,首先会检查 @alice 是否为 @bob.groupa.subgroup.Action 定义过权限映射。 如果什么都没有找到,紧接着检查 @bob.groupa.subgroup 映射,然后是 @bob.groupa,最后 @bob 将被检查。 如果都没有找到,那么假定映射为命名的权限群组 @alice.active。
一旦一个映射被识别,则使用相关联的签名验证权限。 如果失败了,则跃迁至父权限,直至拥有者权限@alice.owner。




我们在看一下上面这张图,我简单讲一下:我们先看左侧,可以看到上面带key字符的就是各种权限,底下的三个方框是命名的消息群组,我们可以看到,这个交易的合约被映射到家庭组这个权限上,而提现这个消息被映射到律师这个权限上,也就是说家庭组里面的成员可以进行交易,但是唯独不能进行取现。因为取现最先匹配上的是律师这个密钥。




好,我们看看EOS的默认权限群组,默认的权限组上面我们也有讲到,是Owner和Active,Owner可以做任何事情,这个权限一般来说不用来做具体的工作,一般用来做冷备份,比如说Active权限丢了,就可以是用Owner权限来恢复。Active权限可以做除了修改Owner以外的所有事情,一般业务都是有Active权限来完成。其他的所有权限组也都是从Active权限派生出来的。




权限的并行评估这部分内容,相对来说没有特别重要,我们就简单讲一下。基本上说的是,由于权限的评估是只读的,因此可以进行并行化处理,同时可以提前到交易广播阶段完成,而不是在打包块的过程中。另外在区块链被重新加载重放交易时由于区块的执行肯定是通过了权限验证的,因此可以忽略,以此来提高执行效率。
好了权限管理这部分就讲到这里,我们在看下一部分,带强制性延时的消息




这部分比较简单,主要说的是,时间是安全的重要属性,EOS允许有时间延时的消息,在特别的时间范围内可以取消消息。这点是比特币和以太坊不能实现的,特别是在网络拥堵的情况下,若手续费比较低,往往一笔交易很长时间得不到确认,而用户完全没有办法取消交易。这种延时消息具体延时多长时间完全有消息的敏感程度决定,比如说买咖啡可能是几秒钟,买房可能是几天,转移整个账户可能是一个月,确切的时间取决于应用开发者和用户。




EOS允许恢复被盗窃的密钥,这在比特币和以太坊上是不可能的,在比特币和以太坊上一旦密钥丢失那么整个账户也随之丢失,EOS提供了恢复密钥的机制。具体来说就是可以使用30天内的任意Owner权限的密钥,注意这个密钥可能已经被黑客换过了,但是在这个场景下这个密钥还是可以使用的;使用任意30天内的Owner密钥和指定的合作伙伴才能恢复密钥。这里面合作伙伴不能在没有Owner协助的基础上恢复密钥。合作伙伴也不会参与任何日常交易,这样可以大大降低法律上的风险。EOS破70了,有打赏0.1个EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35 查看全部
本文是王巨老师EOS课程的文字版,首发在简书,经本人同意后转载,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第二讲。今天的课程原本计划讲两部分内容,账户系统和并行执行。但是一天的备课下来,我发现账户系统的内容特别多,而且理解EOS的账号体系对于将来进行智能合约的开发非常有帮助,因此我决定在本次课程中详细给大家讲解一下EOS的账户体系。并行执行这部分放到下一讲跟TOKEN模型放到一起。
另外,上次有同学说没有ppt的问题,我今天也会在讲课的过程中穿插加入ppt。
3115234-85357636542086a5.png

大家可以先看一下上面这个思维导图,这就是本节课要讲解的大纲。主要分了5个章节,简介、消息和处理程序、基于角色的权限管理、带有强制延时性的消息、恢复被盗窃的密钥。其中今天会重点讲解基于角色的权限管理。

好的,我们开始讲解EOS的权限系统
 
3115234-24d3a54187816447.jpeg

EOS相对于比特币和以太坊只有私钥和地址的概念,EOS的账户体系是相当完备的,从这点来看,比特币和以太坊在可用性上差了EOS一大截。比如说比特币和以太坊没法自定义账户地址,只能用一堆人类没法理解的字符串做地址和私钥。而EOS可以使用一个人类可以阅读的2-32个字符来创建账户。另外在白皮书上强调,创建一个账号需要付出额外的一点点成本,来覆盖账户的存储成本,这一般是由开发者也就是应用提供方来承担。最后,EOS的账户还支持域的概念,比如说:
@domain这个账号的拥有者是唯一能创建@user.domain的人。
3115234-3d8c59f9edc7c92a.jpeg

好我们继续讲消息和处理程序,讲账户为什么要讲消息和处理程序呢?这是因为账户和消息是EOS只能合约的两个不可或缺的组成部分,而且他们之间有着密切的关联,单独讲哪一个也没法讲清楚他们的本质。我们看看EOS的消息机制就明白了,所谓的消息就是账户与账户之间的沟通语言,每个账户都可以发送结构化的消息给任意其他账户,每个账户都可以定义处理消息的脚本,每个账户还有自己的私有数据库,消息处理脚本也可以给其他账户发消息,最终 消息和消息处理脚本组成了EOS的智能合约。
我来进一步解释一下,发消息很容易理解,消息处理脚本就是在一个账户收到了消息之后怎么处理消息。这个处理脚本本身还可以发消息给其他账户。这个怎么理解呢?我的理解是有些消息是人手工发的,比如说a给b转账50eos,有些消息是可以由处理消息的脚本来发的,比如说b在收到50eos这个消息后有个消息处理脚本会自动向c发送25个eos。这其实就是一个非常简单的合约了。
3115234-70c0601c6aa9f16e.jpeg

好的,我们来讲一下今天的重点基于角色的权限管理,这也是BM系区块链的一个特色,权限管理在BTS和Steamit上已经比较完善了,在EOS上还会做更多的优化。我们先来看看权限管理的简介:判断一条消息是否被授权最简单的方式是包含一个签名,当然验证这个签名的前提是要知道这个签名是谁的。一般来说权限是与个体或群组绑定在一起,理论上不会有一种权限跟个体或群组没关系,因为这样是没有意义的。EOS提供了细粒度和高级别的权限控制,可以控制到谁在什么时候做什么事情。认证和权限管理必须标准化,并且与应用程序的业务逻辑分开,这样可以用通用的方式来管理权限,并且为性能优化提供可能。EOS还支持多账户的控制机制,能对账户的安全性提供保障,减少被黑客攻击而造成的资金损失风险。EOS甚至还允许定义什么密钥或账户可以发送特定的消息类型给另一个账户。
举个例子:一个用户的社交媒体账户可以使用一个密钥,而另一个密钥可以用于访问交易所,甚至可以授权其他账户来代表本账户而不是分配一个密钥。

下面我们就详细讲一下EOS的权限管理方案:
3115234-4908ed9a38ca3081.jpeg

首先EOS为权限级别进行了命名比如说Owner、Active、Friend。这些命名可以是系统默认的比如Owner和Active,有些是可以自定义的比如Friend的。我们来看Steamit里面的权限实例:它是硬编码了三个权限级别:Owner、Active、Posting。其中Posting权限只能进行发帖操作投票等社交操作,Active权限可以做除了修改Owner以外的所有事情。Owner可以作为冷备份而存在。EOS本身也囊括了这些概念,而且允许自定义权限的层次结构和分组。
3115234-419f4031056d82bb.jpeg

在设计了权限级别之后,EOS还设计了命名的消息处理群组,这个命名的消息处理群组可以在其他帐户配置他们权限级别时被引用。上面有一个简单的例子,在账户名下有一个分组A,分组A下面有个子分组b,它下面有消息类型。一个交易所的交易合约 在这种模式下就可以将订单的创建和取消 分开存取,通过交易合约进行分组 可以方便 交易所用户。
3115234-3af156d20070806e.jpeg

 权限级别和消息处理群组,这两个概念之间就可以做映射了。就是说可以将某个消息处理群组分配到某个权限级别上,或者反过来说,可以在某个权限级别上定义很多消息处理群组。举个例子:一个帐户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射。 有了这个映射,任何朋友可以以这一帐户的身份在这一帐户的社交媒体上发帖。 尽管他们将以帐户所有者的身份发帖,他们仍然使用自己的密钥来签名消息。 这意味着总是可以辨识出是哪一个朋友在以何种方式使用帐户。
3115234-db7bd000104ed61e.jpeg

如何进行权限评估,简单的来讲就是从小到大进行逐级匹配,比如:当 @alice 以 "Action" 类型发送一条消息给 @bob 时,首先会检查 @alice 是否为 @bob.groupa.subgroup.Action 定义过权限映射。 如果什么都没有找到,紧接着检查 @bob.groupa.subgroup 映射,然后是 @bob.groupa,最后 @bob 将被检查。 如果都没有找到,那么假定映射为命名的权限群组 @alice.active。
一旦一个映射被识别,则使用相关联的签名验证权限。 如果失败了,则跃迁至父权限,直至拥有者权限@alice.owner。
3115234-b31e28e27ed297e7.jpeg

我们在看一下上面这张图,我简单讲一下:我们先看左侧,可以看到上面带key字符的就是各种权限,底下的三个方框是命名的消息群组,我们可以看到,这个交易的合约被映射到家庭组这个权限上,而提现这个消息被映射到律师这个权限上,也就是说家庭组里面的成员可以进行交易,但是唯独不能进行取现。因为取现最先匹配上的是律师这个密钥。
3115234-1ef1c9e86f9e22df.jpeg

好,我们看看EOS的默认权限群组,默认的权限组上面我们也有讲到,是Owner和Active,Owner可以做任何事情,这个权限一般来说不用来做具体的工作,一般用来做冷备份,比如说Active权限丢了,就可以是用Owner权限来恢复。Active权限可以做除了修改Owner以外的所有事情,一般业务都是有Active权限来完成。其他的所有权限组也都是从Active权限派生出来的。
3115234-8111c31a9c663d44.jpeg

权限的并行评估这部分内容,相对来说没有特别重要,我们就简单讲一下。基本上说的是,由于权限的评估是只读的,因此可以进行并行化处理,同时可以提前到交易广播阶段完成,而不是在打包块的过程中。另外在区块链被重新加载重放交易时由于区块的执行肯定是通过了权限验证的,因此可以忽略,以此来提高执行效率。
好了权限管理这部分就讲到这里,我们在看下一部分,带强制性延时的消息
3115234-700402bc86da9ce7.jpeg

这部分比较简单,主要说的是,时间是安全的重要属性,EOS允许有时间延时的消息,在特别的时间范围内可以取消消息。这点是比特币和以太坊不能实现的,特别是在网络拥堵的情况下,若手续费比较低,往往一笔交易很长时间得不到确认,而用户完全没有办法取消交易。这种延时消息具体延时多长时间完全有消息的敏感程度决定,比如说买咖啡可能是几秒钟,买房可能是几天,转移整个账户可能是一个月,确切的时间取决于应用开发者和用户。
3115234-93d4e36d8300b5ff.jpeg

EOS允许恢复被盗窃的密钥,这在比特币和以太坊上是不可能的,在比特币和以太坊上一旦密钥丢失那么整个账户也随之丢失,EOS提供了恢复密钥的机制。具体来说就是可以使用30天内的任意Owner权限的密钥,注意这个密钥可能已经被黑客换过了,但是在这个场景下这个密钥还是可以使用的;使用任意30天内的Owner密钥和指定的合作伙伴才能恢复密钥。这里面合作伙伴不能在没有Owner协助的基础上恢复密钥。合作伙伴也不会参与任何日常交易,这样可以大大降低法律上的风险。EOS破70了,有打赏0.1个EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35

EOS学习笔记4---公共测试网络

郑浩 发表了文章 • 0 个评论 • 1352 次浏览 • 2017-12-25 21:03 • 来自相关话题

本章包括以下内容:
1.概述
2.测试网络和主网络的区别之处。
3.节点。
4.公共测试网络终端。
5.本地EOSD和公共测试网络的连接。
6.本地EOSC和公共测试网络的连接。
7.测试网络账户。
8.网页钱包。(普通终端用户)
9.命令行(开发者)
 
 
1.概述
     公共测试网络的存在是为了支持已经有自己的独立测试网络的开发人员和测试人员来测试他们的代码,但没有‘主网络’公共生产环境的一些问题和限制。
      公共测试网络允许开发者使用在注册时提供的免费测试代币。注册链接在这里。
 
2.测试网络和主网络的不同之处。
    公共测试网络有一些和主网络不一样的地方,在写这篇文章时,包括以下方面。
   *存在     公共主网络还不存在,公共测试网络已存在。
   *创世区块    主网络的创世区块不同于公共测试网络的创世区块。测试网络的创世区块包含了一个水龙头账户和供核心开发人       员测试用的若干个‘initx’(inita- initu)账户。至少有些initx账户也在对立的私人测试网络中提供创世区块。
   *重置     测试网络为了支持测试有重置的可能。
   *版本     测试网络实际上包括了许多不同地址和重置循环的测试网络,这取决于开发社区的需求。
   *主机     测试网络当前仅核心开发者可以在主机上建立和操作配置产块节点。公共主网络的产块节点是由代币持有人投票选举       产生的。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
3.节点
    测试网络由产块节点和非产块节点组成。
 
4.公共测试网络终端。
    以下是当前可用的公共测试网络:
    * Testnet1
        · HTTP Endpoint:tesnet1.eos.io
        · P2P Endpoint:  p2p-testnet1.eos.io:9876
        · Web Wallet Endpoint: t1wallet.eos.io  ,  t1api.eos.io  ,   t1readonly.eos.io
你也可以使用curl来连接。$ curl testnet1.eos.io/v1/chain/get_info5.本地EOSD和公共测试网络的连接。
为了使你的本地EOSD连接到公共的测试网络,得确保你机器的时间是精确的,同时需要按照以下来调整config.ini的配置。p2p-peer-address = p2p-testnet1.eos.io调整 block-interval-seconds 来匹配测试网络,值为2,否则你的本地eosd节点不会和公共测试网络进行同步。block-interval-seconds = 2

6.本地EOSC和公共测试网络的连接。
你可以使用http终端加主机名和端口来连接测试网络。$ eosc -H ${http_endpoint} -p 80 ${options} ${subcommand}

此外,公共测试网络没有提供任何钱包的功能。为了完成签名交易/推送交易/钱包的操作,你需要使用eosc使你的本地钱包连接到公共测试网络。这样做才能确保本地钱包的正常使用。以下命令会在你当前工作的文件夹产生一个data-dir文件夹,这个文件夹包含了经过钱包密码加密的私钥。$ eos-walletd
# this will create a data-dir folder inside your current working directory, this data-dir folder will contain your private keys encrypted with the wallet password然后指定你本地钱包终端端口,除非你覆盖它,钱包终端将是localhost,端口是8888.$ eosc -H ${http_endpoint} -p 80 ${options} --wallet-host ${wallet_endpoint} --wallet-port ${wallet_port} ${subcommand}


7.测试网络的账户。
在开始前首先你需要一个账户名和EOS的公钥。
    *找到你的账户名
      · 输入你的ETH地址或者EOS公钥来找到创世文件分配给你的账户名称,在这里查找。
      ·如果你的地址不包含在快照中,可以通过这里来申请。
    *准备好你的EOS公钥。
      · 如果你的公钥在快照中,你的EOS公钥就是EOS众筹合约的公钥。
      · 如果你通过水龙头申请的账户,你的EOS公钥就是你提交到水龙头应用的公钥。
一旦你拥有了账户名称,你就可以选择喜欢和方式和EOS进行互动了。
 
8.网页钱包。(普通终端用户)
    *访问测试网页钱包
    *创建账户
    * 注册登陆。
    *点击账户边栏。
    *输入你刚才通过之前步骤获得的账户。
    *输入你的EOS公钥,包括EOS Active Key 和Owner Key。
    *点击添加账户。
 
9.命令行(开发者)
  *你需要eos-walletd 和eosc ,看这里,创建本地环境。
  *连接到公共测试网络
  *使用eosc导入你的私钥,看这里
  *学习如何使用eosc,命令介绍看这里,并综合教程。
 
因为EOS还在不断的开发完善中,所以该文档可能会过时,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
  查看全部
本章包括以下内容:
1.概述
2.测试网络和主网络的区别之处。
3.节点。
4.公共测试网络终端。
5.本地EOSD和公共测试网络的连接。
6.本地EOSC和公共测试网络的连接。
7.测试网络账户。
8.网页钱包。(普通终端用户)
9.命令行(开发者)
 
 
1.概述
     公共测试网络的存在是为了支持已经有自己的独立测试网络的开发人员和测试人员来测试他们的代码,但没有‘主网络’公共生产环境的一些问题和限制。
      公共测试网络允许开发者使用在注册时提供的免费测试代币。注册链接在这里
 
2.测试网络和主网络的不同之处。
    公共测试网络有一些和主网络不一样的地方,在写这篇文章时,包括以下方面。
   *存在     公共主网络还不存在,公共测试网络已存在。
   *创世区块    主网络的创世区块不同于公共测试网络的创世区块。测试网络的创世区块包含了一个水龙头账户和供核心开发人       员测试用的若干个‘initx’(inita- initu)账户。至少有些initx账户也在对立的私人测试网络中提供创世区块。
   *重置     测试网络为了支持测试有重置的可能。
   *版本     测试网络实际上包括了许多不同地址和重置循环的测试网络,这取决于开发社区的需求。
   *主机     测试网络当前仅核心开发者可以在主机上建立和操作配置产块节点。公共主网络的产块节点是由代币持有人投票选举       产生的。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
3.节点
    测试网络由产块节点和非产块节点组成。
 
4.公共测试网络终端。
    以下是当前可用的公共测试网络:
    * Testnet1
        · HTTP Endpoint:tesnet1.eos.io
        · P2P Endpoint:  p2p-testnet1.eos.io:9876
        · Web Wallet Endpoint: t1wallet.eos.io  ,  t1api.eos.io  ,   t1readonly.eos.io
你也可以使用curl来连接。
$ curl testnet1.eos.io/v1/chain/get_info
5.本地EOSD和公共测试网络的连接。
为了使你的本地EOSD连接到公共的测试网络,得确保你机器的时间是精确的,同时需要按照以下来调整config.ini的配置。
p2p-peer-address = p2p-testnet1.eos.io
调整 block-interval-seconds 来匹配测试网络,值为2,否则你的本地eosd节点不会和公共测试网络进行同步。
block-interval-seconds = 2

6.本地EOSC和公共测试网络的连接。
你可以使用http终端加主机名和端口来连接测试网络。
$ eosc -H ${http_endpoint} -p 80 ${options} ${subcommand}

此外,公共测试网络没有提供任何钱包的功能。为了完成签名交易/推送交易/钱包的操作,你需要使用eosc使你的本地钱包连接到公共测试网络。这样做才能确保本地钱包的正常使用。以下命令会在你当前工作的文件夹产生一个data-dir文件夹,这个文件夹包含了经过钱包密码加密的私钥。
$ eos-walletd
# this will create a data-dir folder inside your current working directory, this data-dir folder will contain your private keys encrypted with the wallet password
然后指定你本地钱包终端端口,除非你覆盖它,钱包终端将是localhost,端口是8888.
$ eosc -H ${http_endpoint} -p 80 ${options} --wallet-host ${wallet_endpoint} --wallet-port ${wallet_port} ${subcommand}


7.测试网络的账户。
在开始前首先你需要一个账户名和EOS的公钥。
    *找到你的账户名
      · 输入你的ETH地址或者EOS公钥来找到创世文件分配给你的账户名称,在这里查找。
      ·如果你的地址不包含在快照中,可以通过这里来申请。
    *准备好你的EOS公钥。
      · 如果你的公钥在快照中,你的EOS公钥就是EOS众筹合约的公钥。
      · 如果你通过水龙头申请的账户,你的EOS公钥就是你提交到水龙头应用的公钥。
一旦你拥有了账户名称,你就可以选择喜欢和方式和EOS进行互动了。
 
8.网页钱包。(普通终端用户)
    *访问测试网页钱包
    *创建账户
    * 注册登陆。
    *点击账户边栏。
    *输入你刚才通过之前步骤获得的账户。
    *输入你的EOS公钥,包括EOS Active Key 和Owner Key。
    *点击添加账户。
 
9.命令行(开发者)
  *你需要eos-walletd 和eosc ,看这里,创建本地环境。
  *连接到公共测试网络
  *使用eosc导入你的私钥,看这里
  *学习如何使用eosc,命令介绍看这里,并综合教程
 
因为EOS还在不断的开发完善中,所以该文档可能会过时,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
 

EOS学习笔记3---EOS词汇表

郑浩 发表了文章 • 0 个评论 • 684 次浏览 • 2017-12-23 17:49 • 来自相关话题

在EOS的系统中有一些名词需要搞懂其定义。我们来看下官方对其中重要概念的定义。
 Account:账户
     由本地或者自定义权限(由一个或者多个私钥和账户控制)指定的一个链上身份。
 
Authority:权限
      一个抽象的权限,代表了如何在现实中组织权限,这些权限跟一个个体或者一组个体绑定。
 
Block(Blk):区块
     区块链的一个确定的单元。每个区块包含0个或者多个交易,以及和之前区块的密码学连接。一个区块是‘不可逆转的确认’,这是因为绝大多数产块者(Block Producer)都同意一个完整的区块包含了正确的交易。一旦一个区块经过不可逆转的确认后,它就成为了不可改变的区块链的永久的一部分。
 
DAC(Decentralized Autonomous Collective, or Decentralized Autonomous Corporation.)
     分布式自治公司。
 
DAO(Decentralized Autonomous Organization.)
    分布式自治组织。
 
DPoS:(Delegated Proof of Stake,OR   Democracy as Proof of Stake )
    DPos是一个许多共识机制的集成,例如,如何在确认产块者的问题上达成共识,如何确认交易和区块是否‘真实有效’,并且不可逆转的确认和处理。
 
Key pair(keys):密钥对
    一个公钥和它对应的私钥。
 
larimer:(BM的姓名 Daniel Larimer)
    基础货币EOS的1/1000,1 Larimer = 0.0001 EOS
 
Master Password:主密码
    用来解锁和加密钱包文件的密码。
 
Message:(Msg)消息
    区块链的一个变化。一个或多个消息构成交易。
 
Oracle:预言机
  在区块链和智能合约中,预言机是一个代理人,来发现和确认现实世界发生的事情并提交给区块链供智能合约来使用。
 
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
Permission:权限
    一个重量级的安全机制,它通过评估其签字权来确定一个消息是否被正确授权。
 
Pravite Key:私钥
    用来签署交易的密钥。
 
Public Key:(pub key)公钥
    伴随交易传递的公开可用的密钥。
 
Smart Contract:智能合约
    一个智能合约是一个旨在促进,核实或加强合约谈判和履行的计算机协议。
 
Transaction(Tx,Txn):交易
     一个全或无的区块链状态改变。由一个或者多个消息构成。通常是智能合约的执行。
 
Wallet:钱包
    由客户端(比如eosc)生成和管理的一个加密文件,可以管理私钥,用安全的方法促进签署的交易,钱包可能处于开或者关两种状态。
 
Witness:(block producer),见证人,产块者。
    一个当前轮到的节点,为区块链产生即时的区块。或者一组节点的其中一个成员,被选举轮值。见证人和产块者,矿工是一个意思。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
  查看全部
在EOS的系统中有一些名词需要搞懂其定义。我们来看下官方对其中重要概念的定义。
 Account:账户
     由本地或者自定义权限(由一个或者多个私钥和账户控制)指定的一个链上身份。
 
Authority:权限
      一个抽象的权限,代表了如何在现实中组织权限,这些权限跟一个个体或者一组个体绑定。
 
Block(Blk):区块
     区块链的一个确定的单元。每个区块包含0个或者多个交易,以及和之前区块的密码学连接。一个区块是‘不可逆转的确认’,这是因为绝大多数产块者(Block Producer)都同意一个完整的区块包含了正确的交易。一旦一个区块经过不可逆转的确认后,它就成为了不可改变的区块链的永久的一部分。
 
DAC(Decentralized Autonomous Collective, or Decentralized Autonomous Corporation.)
     分布式自治公司。
 
DAO(Decentralized Autonomous Organization.)
    分布式自治组织。
 
DPoS:(Delegated Proof of Stake,OR   Democracy as Proof of Stake )
    DPos是一个许多共识机制的集成,例如,如何在确认产块者的问题上达成共识,如何确认交易和区块是否‘真实有效’,并且不可逆转的确认和处理。
 
Key pair(keys):密钥对
    一个公钥和它对应的私钥。
 
larimer:(BM的姓名 Daniel Larimer)
    基础货币EOS的1/1000,1 Larimer = 0.0001 EOS
 
Master Password:主密码
    用来解锁和加密钱包文件的密码。
 
Message:(Msg)消息
    区块链的一个变化。一个或多个消息构成交易。
 
Oracle:预言机
  在区块链和智能合约中,预言机是一个代理人,来发现和确认现实世界发生的事情并提交给区块链供智能合约来使用。
 
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
Permission:权限
    一个重量级的安全机制,它通过评估其签字权来确定一个消息是否被正确授权。
 
Pravite Key:私钥
    用来签署交易的密钥。
 
Public Key:(pub key)公钥
    伴随交易传递的公开可用的密钥。
 
Smart Contract:智能合约
    一个智能合约是一个旨在促进,核实或加强合约谈判和履行的计算机协议。
 
Transaction(Tx,Txn):交易
     一个全或无的区块链状态改变。由一个或者多个消息构成。通常是智能合约的执行。
 
Wallet:钱包
    由客户端(比如eosc)生成和管理的一个加密文件,可以管理私钥,用安全的方法促进签署的交易,钱包可能处于开或者关两种状态。
 
Witness:(block producer),见证人,产块者。
    一个当前轮到的节点,为区块链产生即时的区块。或者一组节点的其中一个成员,被选举轮值。见证人和产块者,矿工是一个意思。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 

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

郑浩 发表了文章 • 0 个评论 • 971 次浏览 • 2017-12-15 15:01 • 来自相关话题

昨天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的任何问题。