区块链行业吧 关注：25贴子：359
2.去中心化自治组织
通常意义上“去中心化自治组织（DAO, decentralized autonomous organization）”的概念指的是一个拥有一定数量成员或股东的虚拟实体，依靠比如67%多数来决定花钱以及修改代码。成员会共同商量决定组织如何分配资金。分配资金的方法可能是悬赏，工资或者更有吸引力的机制比如用内部货币奖励工作。这仅仅使用密码学区块链技术就从根本上复制了传统公司或者非营利组织的法律意义以实现强制执行的东西。至此许多围绕DAO的讨论都是围绕一个带有接受分红的股东和可交易的股份的“去中心化自治公司（DAC，decentralized autonomous corporation）”的“资本家”模式；作为替代者，一个被描述为“去中心化自治社区（decentralized autonomous community）”的实体将使所有成员都在决策上拥有同等的权利并且在增减成员时要求67%多数同意。每个人都只能拥有一个成员资格这一规则需要被群体强制实施。
通常意义上“去中心化自治组织（DAO, decentralized autonomous organization）”的概念指的是一个拥有一定数量成员或股东的虚拟实体，依靠比如67%多数来决定花钱以及修改代码。成员会共同商量决定组织如何分配资金。分配资金的方法可能是悬赏，工资或者更有吸引力的机制比如用内部货币奖励工作。这仅仅使用密码学区块链技术就从根本上复制了传统公司或者非营利组织的法律意义以实现强制执行的东西。至此许多围绕DAO的讨论都是围绕一个带有接受分红的股东和可交易的股份的“去中心化自治公司（DAC，decentralized autonomous corporation）”的“资本家”模式；作为替代者，一个被描述为“去中心化自治社区（decentralized autonomous community）”的实体将使所有成员都在决策上拥有同等的权利并且在增减成员时要求67%多数同意。每个人都只能拥有一个成员资格这一规则需要被群体强制实施。
然后合约对每一项都有具体的条款。它将维护一个所有开放存储的更改记录以及一个谁投票表决的表。还有一个所有成员的表。当任何存储内容的更改获得了三分之二多数同意，一个最终的交易将执行这项更改。一个更加复杂的框架会增加内置的选举功能以实现如发送交易，增减成员，甚至提供委任制民主一类的投票代表（即任何人都可以委托另外一个人来代表自己投票，而且这种委托关系是可以传递的，所以如果A委托了B然后B委托了C那么C将决定A的投票）。这种设计将使DAO作为一个去中心化社区有机地成长， 使人们最终能够把挑选合适人选的任务交给专家，与当前系统不同，随着社区成员不断改变他们的站队假以时日专家会容易地出现和消失。 一个替代的模式是去中心化公司，那里任何账户可以拥有0到更多的股份，决策需要三分之二多数的股份同意。一个完整的框架将包括资产管理功能-可以提交买卖股份的订单以及接受这种订单的功能（前提是合约里有订单匹配机制）。代表依然以委任制民主的方式存在，产生了“董事会”的概念。
综述：去中心化应用
上述合约机制使得任何一个人能够在一个虚拟机上建立通过全网共识来运行命令行应用（从根本上来说是），它能够更改一个全网可访问的状态作为它的“硬盘”。然而对很多人来说，交易发送机制的命令行接口，缺乏足量的用户使得去中心化成为有吸引力的替代方案。最后，一个完整的“去中心化应用”应该包括底层的商业逻辑组件【无论是否在Ethereum完整实施，使用Ethereum和其它系统组合（如一个P2P消息层，其中一个正在计划放入Ethereum客户端）或者仅有其它系统的方式】和上层的图形用户接口组件。Ethereum客户端被设计成一个网络浏览器，但包括对“eth” Java API对象的支持，可被客户端里看到的特定的网页用来与Ethereum区块链交互。从“传统”网页的角度看来，这些网页是完全静态的内容，因为区块链和其它去中心化协议将完全代替服务器来处理用户发起的请求。最后，去中心化协议有能够自己利用一些方式使用Ethereum来存储网页。
上述合约机制使得任何一个人能够在一个虚拟机上建立通过全网共识来运行命令行应用（从根本上来说是），它能够更改一个全网可访问的状态作为它的“硬盘”。然而对很多人来说，交易发送机制的命令行接口，缺乏足量的用户使得去中心化成为有吸引力的替代方案。最后，一个完整的“去中心化应用”应该包括底层的商业逻辑组件【无论是否在Ethereum完整实施，使用Ethereum和其它系统组合（如一个P2P消息层，其中一个正在计划放入Ethereum客户端）或者仅有其它系统的方式】和上层的图形用户接口组件。Ethereum客户端被设计成一个网络浏览器，但包括对“eth” Java API对象的支持，可被客户端里看到的特定的网页用来与Ethereum区块链交互。从“传统”网页的角度看来，这些网页是完全静态的内容，因为区块链和其它去中心化协议将完全代替服务器来处理用户发起的请求。最后，去中心化协议有能够自己利用一些方式使用Ethereum来存储网页。
结论
Ethereum协议最初是作为一个通过高度通用的语言提供如链上契约，Ethereum协议将不直接“支持”任何应用，但图灵完备编程语言的存在意味着理论上任意的合约都可以为任何交易类型和应用创建出来。围绕这个去中心化存储，去中心化计算和去中心化预测市场以及数十个类似概念建立的协议和去中心化应用，有潜力从根本上提升计算行业的效率，并通过首次添加经济层为其它的P2P协议提供有力支撑，最终，同样会有大批与金钱毫无关系的应用出现。
Ethereum协议实现了的任意状态转换概念是提供了个独特潜力的平台；与封闭式的，为诸如数据存储，Ethereum从设计上是开放式的，并且我们相信它极其适合作为基础层服务于在将来的年份里出现的极其大量的金融和非金融协议。第十篇就先讲到这个以前的大家可以自行翻看。
Ethereum协议最初是作为一个通过高度通用的语言提供如链上契约，Ethereum协议将不直接“支持”任何应用，但图灵完备编程语言的存在意味着理论上任意的合约都可以为任何交易类型和应用创建出来。围绕这个去中心化存储，去中心化计算和去中心化预测市场以及数十个类似概念建立的协议和去中心化应用，有潜力从根本上提升计算行业的效率，并通过首次添加经济层为其它的P2P协议提供有力支撑，最终，同样会有大批与金钱毫无关系的应用出现。
Ethereum协议实现了的任意状态转换概念是提供了个独特潜力的平台；与封闭式的，为诸如数据存储，Ethereum从设计上是开放式的，并且我们相信它极其适合作为基础层服务于在将来的年份里出现的极其大量的金融和非金融协议。第十篇就先讲到这个以前的大家可以自行翻看。
在accounts代码包内部的各种结构体/接口中，accounts.Manager在相互调用关系上无疑是处于顶端的，它本身是公共类，向外暴露包括查询单个Account，返回单个或多个Wallet对象，订阅Wallet更新事件等方法。在其内部它维持一个Wallet列表，通过每个Wallet实现类持有一组Account账户对象，并通过一个event.Feed成员变量来管理所有向它订阅Wallet更新事件的需求。
Manager订阅Wallet的更新事件
着重介绍一下这里的订阅(subscribe)操作，Manager的Subscribe()函数定义如下:
[plain] view plain copy
1. // /accounts/manager.go
2. func (am *Manager) Subscribe(sink chan<- WallletEvent) event.Subscription {
3. return am.feed.Subscribe(sink)
4. }
首先注意这个Subscribe()函数是让外部调用对象 向该Manager作订阅的操作，事实上该Manager本身也是通过相同的订阅机制去获知新添的Wallet对象，它的成员变量updates就是该Manager本身得到所订阅事件的通道。其次，Manager.Subscribe()函数只有一个chan参数，由于golang语言中channel机制的强大，订阅操作仅仅需要一个chan对象就足够了，真是简单之极，根本不必知道背后是谁发起了订阅。尽管如此，这里依然值得思考的是，究竟是什么对象向Manager发起了订阅呢？其实，向某个Manager对象订阅Wallet更新事件的，正是另外一个Manager对象，也就是<Backend>的实现类。
得出以上这个结论，是很有意义的。后面可以了解到，accounts.Manager主要作为eth.Ethereum(或者les.Ethereum)的一个成员存在，而这个eth.Ethereum是以太坊客户端程序中最主要的部分，它以服务的形式提供几乎所有以太坊系统运行所需的功能，所以一个以太坊客户端可视为一个accounts.Manager的存在，那么真相就是，所有以太坊客户端之间在通过accouts.Manager相互订阅Wallet更新事件。
Manager订阅Wallet的更新事件
着重介绍一下这里的订阅(subscribe)操作，Manager的Subscribe()函数定义如下:
[plain] view plain copy
1. // /accounts/manager.go
2. func (am *Manager) Subscribe(sink chan<- WallletEvent) event.Subscription {
3. return am.feed.Subscribe(sink)
4. }
首先注意这个Subscribe()函数是让外部调用对象 向该Manager作订阅的操作，事实上该Manager本身也是通过相同的订阅机制去获知新添的Wallet对象，它的成员变量updates就是该Manager本身得到所订阅事件的通道。其次，Manager.Subscribe()函数只有一个chan参数，由于golang语言中channel机制的强大，订阅操作仅仅需要一个chan对象就足够了，真是简单之极，根本不必知道背后是谁发起了订阅。尽管如此，这里依然值得思考的是，究竟是什么对象向Manager发起了订阅呢？其实，向某个Manager对象订阅Wallet更新事件的，正是另外一个Manager对象，也就是<Backend>的实现类。
得出以上这个结论，是很有意义的。后面可以了解到，accounts.Manager主要作为eth.Ethereum(或者les.Ethereum)的一个成员存在，而这个eth.Ethereum是以太坊客户端程序中最主要的部分，它以服务的形式提供几乎所有以太坊系统运行所需的功能，所以一个以太坊客户端可视为一个accounts.Manager的存在，那么真相就是，所有以太坊客户端之间在通过accouts.Manager相互订阅Wallet更新事件。
除Manager之外，这里其他几个重要的结构体还包括：
· event.Feed{}：它可以管理一对多的订阅模式，每个调用者提供一个chan对象，用以发送所订阅的内容。Feed{}处理的订阅内容是类型泛化的，而每一个Feed{}对象，在其生命周期内，只能处理一种类型的订阅内容，即向chan对象发送的value。Feed.Subscribe()方法返回<Subscription>接口的实现体feedSub{}，Feed.Subscribe()帮助Manager实现了<Backend>所声明的方法Subscribe()。在Feed结构体内部，CaseList被用来管理所有订阅者发过来的chan对象。
· accounts.Account{}：它的成员除了一个common.Address类型，即20bytes长的地址变量外，还有一个可选成员URL，可以是网址，也可以是本地存储的路径+文件全名。在以网址形式存在时，URL.Scheme就是网络协议名，而作为本地存储文件时，URL.Scheme是字符串常量"keystore"。
· accounts.<Wallet>：它很像一般意义上的“钱包”，其管理的多个Account，恰似个人用户在现实中拥有的多个银行账户，每个Account上的Ether余额，可从数据库(core.state.StateDB)中查询。<Wallet>接口声明的函数中，尤其需要注意的是SignXXX()，其中SignTx()是对一个Transaction(tx)对象进行数字签名，SignHash()是对一个Hash值进行数字签名，由于任何一个对象(只要可序列化)可以作Hash运算，所以这里SignHash()其实是针对任何一个对象，尤其是Block区块作数字签名。
<Wallet>是接口类型，它的实现体包括软件钱包(keystore.keystoreWallet)和硬件钱包(usbwallet.wallet)，注意这里的硬件钱包是有实物的。<Wallet>之下的代码体系对于外部都不是公共的，所有向外暴露的“钱包”对象以及相关更新事件，都是以<Wallet>形式存在。
软件实现的Wallet - keystore
软件实现Wallet主要通过本地存储文件的方式来管理账户地址。同时，<Wallet>对象需要对交易或区块对象提供数字签名，这需要用到椭圆曲线数字签名(ECDSA)中的公钥+密钥，而每个公钥也是某个账户地址(Address)的来源，所以我们也需要本地存储ECDSA的公钥密钥信息。以太坊中这个通过本地存储文件的方案实现accounts.<Wallet>功能的机制被成为keystore。
· event.Feed{}：它可以管理一对多的订阅模式，每个调用者提供一个chan对象，用以发送所订阅的内容。Feed{}处理的订阅内容是类型泛化的，而每一个Feed{}对象，在其生命周期内，只能处理一种类型的订阅内容，即向chan对象发送的value。Feed.Subscribe()方法返回<Subscription>接口的实现体feedSub{}，Feed.Subscribe()帮助Manager实现了<Backend>所声明的方法Subscribe()。在Feed结构体内部，CaseList被用来管理所有订阅者发过来的chan对象。
· accounts.Account{}：它的成员除了一个common.Address类型，即20bytes长的地址变量外，还有一个可选成员URL，可以是网址，也可以是本地存储的路径+文件全名。在以网址形式存在时，URL.Scheme就是网络协议名，而作为本地存储文件时，URL.Scheme是字符串常量"keystore"。
· accounts.<Wallet>：它很像一般意义上的“钱包”，其管理的多个Account，恰似个人用户在现实中拥有的多个银行账户，每个Account上的Ether余额，可从数据库(core.state.StateDB)中查询。<Wallet>接口声明的函数中，尤其需要注意的是SignXXX()，其中SignTx()是对一个Transaction(tx)对象进行数字签名，SignHash()是对一个Hash值进行数字签名，由于任何一个对象(只要可序列化)可以作Hash运算，所以这里SignHash()其实是针对任何一个对象，尤其是Block区块作数字签名。
<Wallet>是接口类型，它的实现体包括软件钱包(keystore.keystoreWallet)和硬件钱包(usbwallet.wallet)，注意这里的硬件钱包是有实物的。<Wallet>之下的代码体系对于外部都不是公共的，所有向外暴露的“钱包”对象以及相关更新事件，都是以<Wallet>形式存在。
软件实现的Wallet - keystore
软件实现Wallet主要通过本地存储文件的方式来管理账户地址。同时，<Wallet>对象需要对交易或区块对象提供数字签名，这需要用到椭圆曲线数字签名(ECDSA)中的公钥+密钥，而每个公钥也是某个账户地址(Address)的来源，所以我们也需要本地存储ECDSA的公钥密钥信息。以太坊中这个通过本地存储文件的方案实现accounts.<Wallet>功能的机制被成为keystore。
