DAO的来源？

- 分布式自治组织（DAO）的概念最早由美国作家奥里·布莱福曼（Ori Brafman）在一本名为《海星和蜘蛛》的书中提出。他在书中将中心化组织比喻为蜘蛛，把分布式组织比喻为海星。

- 书中写道：蜘蛛是中心化（细胞）组织，如果把它的头切掉后（整个组织）就无法生存了。海星则是由彼此对等（无中心）的一堆细胞组成的，海星撕下的每只触手都可成长为完整的海星。海星和蜘蛛分别代表现实世界中去中心化和中心化的两种组织。海星型组织在遇到挫折和冲突被分解时，其组织将变成更小的去中心化组织，继续发挥作用；而蜘蛛型组织在首脑被割掉之后，将无法继续运作。相比之下， 海星型去中心化运作的组织将具有强大的生命力 。

- DAO，全称decentralized autonomous organization，分布式自治组织。DAO是区块链发展逾十年延伸出来的应用与组织创新，是一种通过无信仰和匿名的方式协调，集体为某一件事做出决定的机制。

- DAO更加安全，因为任何人都不能控制整个组织。并且由于DAO运行在无需许可的、去中心化的区块链技术之上，所以它能够不受外部因素干扰保持自治。也为后续DAO的建立和发展埋下了种子。

DAO VS 传统公司

- DAO是Decentralized 去中心化、Autonomous 自治、 Organization 组织的缩写，从字面理解，去中心化即为规则制定和执行的去中心化，自治即为完全由社区决定自己的规则。DAO的发展依赖于区块链技术，日常运营都基于去中心化的基础设施-区块链上，实现了去中心化的同时，区块链智能合约平台保障了代码的可信运行，使得组织规则能够程序化，通过程序设计再将规则的制定权交给社区。

- 在传统的公司架构中，组织的决策掌握在极少数人手里。公司里有股东，董事会，CEO 之类的角色，而这些角色之间又往往存在着复杂的利益关系。组织中的成员并没有实际参与到其重大决策及发展过程中，即便是在如今倡导自由开放的平权组织中，中心化仍然是主流。

- 在DAO发起之初，也有一个核心的团队，发起团队之外允许个体的加入，人人都可以成为股东，这个时候的DAO并不是完全的去中心化，仍有和公司类似的中心化团队。但DAO的创建，本质希望是极致透明的，之后经过动态的层级发展，逐渐扩容，最终实现组织决策是基于更去中心化的共识，最终发展成熟。基于此可以看出，DAO与公司有许多相似之处。

- DAO则更加去中心化，为每个投资者提供了一个平等的机会来塑造他们组织未来的成功，并在决策过程中拥有发言权。由于组织结构不受传统的等级管理线的限制，每一个创新的想法和建议都可以被整个组织充分考虑。

- 此外，更加透明化，作为一个构建在区块链上的DAO，每一笔金融买卖、规则、细则和决策都记录在公共分类账上，供每个人查看。采用协商一致的系统还意味着每个利益相关者都参与帮助决定如何使用组织资金和跟踪所花的金额。

DAO的发展类型

- 协议型DAO

MAKER、Aave、Compound和Uniswap等协议通常通过治理结构进行分类，该结构将相关通证分发到其社区，以便社区成员可以对网络决策（例如参数调整或智能合约升级）进行投票。由于这些决定固有的复杂性以及理解或实施它们所需的更高技术经验，一些跨各种协议的知识渊博的代表可能会成为各自治理领域的意见领袖。

例如UniswapDAO，任何UNI通证持有者都可以提交修改或引入新功能的提案，并获得其他社区成员的批准。但是，在此之前，只有在每个提案人的地址中分配了超过2,500,000个 UNI的情况下，才能提交提案以供社区考虑。

- 投资型DAO

专门针对投资者或更集中的投资环境的DAO通常需要利益相关者将资本分配到他们的组织中，以获得投票份额，这有助于确定DAO应该作为一个集体投资项目。

虽然当前投资型DAO尚有法律限制，但是投资型DAO的诞生证明了一种新投资模式的可行性，那就是很多人聚集在一起，投资门槛对每个人来说都会降低，但这个整体却可以投资更多的项目。

DAO的成员结合他们的专业知识来构建与其目标或总体目标一致的投资组合。投资型DAO的例子包括Stacker Ventures、BitDAO等。BitDAO的行动和方向是由BIT通证的持有者投票决定的，Defi领域是其投资重点。他们会投各类优质项目，然后在未来获得回报，再将回报给到自己的投资人。

- 收藏型DAO

在NFT走入主流后，专注于收藏NFT的收藏型DAO就诞生了。策展人小组成为了特定艺术家、平台或系列背后的粘合剂，帮助他们能够拥有一个健康长寿的职业生涯。收藏型DAO 的主要逻辑是社区成员共同决策、投资、持有或释放NFT艺术收藏品，共同维护一个NFT Collection。

Jenny DAO是由社区驱动的NFT艺术品的收藏型DAO，负责获取NFT并将它们添加到由 Unicly协议的智能合约控制的保险库中。只有在同意Jenny通证持有者达到一定阈值并指示智能合约解锁金库时，才能投资和治理项目。

- 服务型DAO

服务型DAO是人才储备的分配方，使用链上凭证将资源从一个DAO输送、分配到另一个 DAO。服务型DAO为个人创建去中心化的工作小组，为开源的互联网工作，从本质上讲，它其实就是加密原生的人才中心。

从法律到创意，从治理到营销，从开发到财务管理，服务型DAO与Web3.0世界中的“数字游民”签订合同，他们的工作往往会得到一定的奖励，例如DXDAO将投票权奖励给那些对 DXDAO产品、社区讨论和策略做出贡献的人，这也代表着他们对其为网络创造的价值的所有权。

- 社交型DAO

在一个以投机为主导的行业中，社交型DAO关注的是社会资本而不是金融资本。社交型DAO是群聊的自然演变，你的朋友最后也将成为你的同事。社交媒体把每个人都变成了传媒公司，而社交型DAO则把每个群聊都变成了数字业务。社交型DAO向人们证明，加密领域不仅仅是赚快钱的地方，互联网是结交志同道合之人的最佳场所。

社交型DAO是依靠着身份证明和社区共识构建了活跃而庞大的社区，这种模式是非常有趣的，Bored Ape Yacht Club、Bored Ape Kennel Club都属于这种类型的社区。

当然，DAO、元宇宙与Web3.0的全面落地还需耐心等待，我们不妨先看看目前这一领域内的发展情况。DAO作为一种底层设计，与加密市场的许多风口都存在联系，可以说，DAO是加密市场各大热门板块的交汇点。

DAO的展望

- 随着DAO的发展和成熟，越来越多的传统/加密投资机构都加入了这一现代社会组织结构和社会形态的范式转移浪潮。DAO在未来的趋势中，会逐渐打破传统和加密行业的观念桎梏，使更多的年轻人加入进来，善于和乐于接受新事物的建造者将获得行业的红利。

- DAO将承担更强的早期价值发现功能，汇集更大规模的基础资金和团结对生态发展最积极热情的实践和推动者；在更多的赛道和领域发挥作用的同时，不断探索治理模式中的本土化问题；行业型的关键指标会被建立，超越传统互联网巨头的新生组织会出现，DAO作为对新的组织关系和社会结构的治理探索，必定会为 Web3.0乃至元宇宙的发展注入源源不断的动力。

- 未来，DAO或许能成为重要的社会组织形式，最大化地实现组织的效能及价值流转，形成新的商业变革。

紧跟数字经济时代

把握数字算力红利

打造价值IPFS生态

一、web应用组成和虚拟目录映射

1、WEB应用程序是指提供给浏览器访问的程序，一个web应用由多个静态资源和动态资源组成

• html、css、js文件
• jsp文件、java程序、支持jar包
• 配置文件
• ……

2、web应该用开发好以后，若想供外界访问，需要把web应用所在目录交给服务器管理，这个过程称之为虚拟目录的映射。
tomcat中虚拟目录的映射方式详细情况可以参考tomcat文档中configrure/context配置。列举三种方式：（1）server.xml 方式，当path=”“时，表示该目录为缺省目录，该方法需要重启服务器

<Context path="/itcast" docBase="C:\news"/>

（2）$CATALINA_BASE/conf/[enginename]/[hostname]/ 目录下放置任意.xml文档，在该文档中配置context,tomcat将会把context指定的docBase映射到.xml文档名称的虚拟目录,如下，可通过a/b/xx.html访问到news下面的xx.html。该方法不需要重启服务器。ROOT.xml表示缺省应用。
a#b.xml

<Context docBase="C:\news"/>

（3）tomcat会自动检测加载webapps下面的web资源。

注：关于tomcat可以看上一篇。

二、web资源组织结构和web.xml

1、目录结构：开发web应用时，不同类型的文件有严格的存放规则，否则不仅可能会使web应用无法访问，还会导致 web服务器启动报错。web应用中，web.xml是其中最重要的一个文件，它用于对web应用中的web资源进行配置。

下面举例说明，如何构建一个简单的web应用并放入服务器。

第一步：D:\mail下按照web应用固定目录格式组织mail文件夹

1.html内容

welcome to mail

web.xml内容,可以从$CATALINA_BASE/conf/web.xml中抄写。

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
                      http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
  version="3.0">
<welcome-file-list>
        <welcome-file>1.html</welcome-file>
    </welcome-file-list>
</web-app>

第二步：把web应用发布到tomcat以供用户访问。这里采用server.xml中配置的方式。此种方式需要重启服务器，另外我们顺便把tomcat http连接端口改成80。
server.xml

<Context path="" doBase="D:\apache-tomcat-7.0.73\webapps\mail"/>

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"/>

第三步：启动tomcat,通过浏览器访问。实验中把tomcat端口设置成80，因此浏览器可以不指定端口；把web应用mail设置成缺省web应用，因此可以不指定访问地址；把1.html配置成mail的欢迎页面，因此可以不指定页面。

注意：实验发现tomcat7.0.73版本中如果conf/catalina/localhost目录下面的.xml文件的docBase包含tomcat本身的目录会被忽略掉。

三、UML描述web资源访问过程

这里描述了用户在浏览器地址栏输入网址并按下回车键访问web资源的整个流程，看完下一章节的http协议详解再回来看这个过程会更加理解关于http协议的那部分。（图片看不清可以在新标签页打开）

1. Http Basic Auth

这是一种最古老的安全认证方式，这种方式就是简单的访问API的时候，带上访问的username和password，由于信息会暴露出去，所以现在也越来越少用了，现在都用更加安全保密的认证方式，可能某些老的平台还在用。

如下图所示，弹出一个框，让你填写用户名密码。这就是Tomcat自带的HTTPBasic认证。

当用户名密码输入错误后，会返回401 Unauthorized 表明认证失败，无法访问应用。

当认证成功后，你再看看详细的request headers，会发现多了一个请求头：

Authorization: Basic xxxXXXxxx

这就是你访问应用的凭据了，那段xxxXXX字符串是我写的表示这是一段密文，这是一段什么密文呢，就是讲用户名和密码进行一个Base64加密后得到的密文。所以你现在是不是也有同感了---这tm也太容易盗取了，所以现在新的应用几乎不怎么用这种方式了，虽然简单，但是安全级别太低了。

 

2. OAuth2

本人之前的博客介绍过OAuth2 以及使用Azure AD实现OAuth2认证方式，在这里呢，还是把那篇博客部分内容抠出来，方便大家总结查看。

https://blog.csdn.net/aHardDreamer/article/details/88650939

OAuth 即：Open Authrization(开放授权)， 它是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密资源，而无需将用户名和密码提供给第三方。比如我们熟知的通过qq/微信/微博等登录第三方平台。OAuth 1.0版本发布后有许多安全漏洞，所以在OAuth2.0里面完全废止了OAuth1.0，它关注客户端开发者的简易性，要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。读起来有点绕口，其实原理也非常简单，请看下面讲解。

一、首先我们要了解在OAuth2 认证和授权的过程中有这三个角色：

1. 服务提供方：顾名思义，提供受保护的服务和资源的，用户在这里面存了很多东西。

2. 用户： 存了东西（照片，资料等）在服务提供方的人。

3. 客户端：服务调用方，它要访问服务提供方的资源，需要在服务提供方进行注册，不然服务提供方不鸟它呀。

二、OAuth2 认证和授权的过程：

1）用户想操作存放在服务提供方的资源；

2）用户登录客户端，客户端向服务提供方请求一个临时token;

3）服务提供方验证客户端的身份后，给它一个临时token;

4）客户端获得临时token之后，将用户引导至服务提供方的授权页面，并请求用户授权。（在这个过程中会将临时token和客户端的回调链接/接口 发送给服务提供方 ---很明显服务提供方到时会回来call这个接口在用户认证并授权之后）

5）用户输入用户名密码登录，登录成功之后，可以授权客户端访问服务提供方的资源；

6）授权成功后，服务提供方将用户引导至客户端的网页（call第4步里面的回调链接/接口）；

7）客户端根据临时token从服务提供方那里获取正式的access token；

8）服务提供方根据临时token以及用户的授权情况授予客户端access token;

9）客户端使用access token访问用户存放在服务提供方的受保护的资源。

 

三、拿access token的方法（Grant Type）有下面四种，每一种都有适用的应用场景：

1. Authorization Code （授权码模式）

结合普通服务器端应用使用。

1）用户访问客户端，后者将前者导向认证服务器，假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

2)客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌：GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向页面链接。请求成功返回code授权码，一般有效时间是10分钟。

3）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向页面链接。请求成功返回access Token和refresh Token。

 

2. Implicit（简化模式）

结合移动应用或 Web App 使用。

Access Token直接从授权服务器返回(只有前端渠道)

不支持refresh tokens

假定资源所有者和公开客户应用在同一个设备上

最容易受安全攻击

 

3. Resource Owner Password Credentials

适用于受信任客户端应用，例如同个组织的内部或外部应用。

使用用户名密码登录的应用，例如桌面App

使用用户名/密码作为授权方式从授权服务器上获取access token

一般不支持refresh token

假定资源拥有者和公开客户在相同设备上

 

4. Client Credentials

适用于客户端调用主服务API型应用（比如百度API Store，不同项目之间的微服务互相调用）

只有后端渠道，使用客户凭证获取一个access token

因为客户凭证可以使用对称或者非对称加密，该方式支持共享密码或者证书

 

 

3. Cookie-Session Auth

Cookie-Session 认证机制在我们初学J2EE的时候接触的比较多，就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象；通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效；

但是这种基于cookie-session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来。

 

基于session认证所显露的问题：

1）Session 增多会增加服务器开销

每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

2）分布式或多服务器环境中适应性不好

用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。不过，现在某些服务器可以通过设置粘性Session，来做到每台服务器之间的Session共享。

3）容易遭到CSRF攻击

因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击

 

4. Token Auth

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

流程：

用户使用用户名密码来请求服务器

服务器进行验证用户的信息

服务器通过验证发送给用户一个token

客户端存储token，并在每次请求时附送上这个token值

服务端验证token值，并返回数据

 

这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin。

 

 

JWT （Json Web Token） 是Token Auth认证方式中常用的token格式

JWT作为一个开放的标准（RFC 7519），定义了一种简洁的，自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在，这些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。

简洁性

可以通过URL，POST参数或者在HTTP header发送，因为数据量小，传输速度也很快

自包含性

负载中包含了所有用户所需要的信息，避免了多次查询数据库

 

下列场景中使用JSON Web Token是很有用的：

Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。

Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。

 

JWT的结构：

通过这张图，很清晰看出JWT的结构分为三部分，他们之间用“.”连接：

Header：

header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。

例如：

然后，用Base64对这个JSON编码就得到JWT的第一部分

 

Payload:

JWT的第二部分是payload，它包含声明（要求）。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。

Registered claims : 这里有一组预定义的声明，它们不是强制的，但是推荐。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。

Public claims : 可以随意定义。

Private claims : 用于在同意使用它们的各方之间共享信息，并且不是注册的或公开的声明。

 

下面是一个例子：

对payload进行Base64编码就得到JWT的第二部分

注意，不要在JWT的payload或header中放置敏感信息，除非它们是加密的。

 

Signature:

为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。

例如：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。

碰到JWT token可以去JWT官网解密看看，下面这是官网解密出来的数据，可以很清楚的看到它的三部分内容：

 

更多关于JWT的内容，可以前往这个博客：

https://www.cnblogs.com/cjsblog/p/9277677.html

 

参考：

https://www.jianshu.com/p/f8c43dcd8b69

https://blog.csdn.net/alan_liuyue/article/details/88183267

https://www.cnblogs.com/cjsblog/p/9277677.html