Zhuang's Diary

Decentralized Identity Foundation Grows To 56 Members In Our First Year

May 23, 2018 marks the Decentralized Identity Foundation’s first anniversary. Over the past year, DIF has grown from a handful of founding organizations to 56 members. Together, we’re working to shape the future of decentralized identity technology and standards.

Technology Under Development

DIF members are working together to build a variety of technologies. Much of this work is being done in collaboration with the larger open source community through the W3C and events such as Rebooting Web of Trust and the Internet Identity Workshop.

Decentralized Identifiers (DIDs)

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, “self-sovereign” digital identity. DIDs are fully under the control of their owner, independent from any centralized registry, identity provider, or certificate authority.

Universal Resolver

The Universal Resolver is similar to Bind in the DNS system. However, instead of working with domain names, it works with self-sovereign identifiers that can be created and registered directly by their owners. This project was organized by DIF members with funding from British Columbia.

Chainpoint

Chainpoint is an open standard for anchoring data to a blockchain and creating a timestamp proof.

Hubs

Hubs are datastores containing semantic data objects at well-known locations. Each object in a Hub is signed by an identity and accessible via a globally recognized API format that explicitly maps to semantic data objects. Hubs are addressable via unique identifiers maintained in a global namespace. Several members within DIF have announced work on hub implementations, including Microsoft and Sovrin.

DIF Steering Committee Members

We’d like to thank the following Steering Committee members for providing leadership and helping DIF grow over the past year.

• Drummond Reed — Chief Trust Officer, Evernym

• Rouven Heck — Co-Founder & Project Lead, uPort

• Ryan Shea — Co-founder, Blockstack

• Muneeb Ali — Co-founder, Blockstack

• Wayne Vaughan — Chief Executive Officer, Tierion

• Daniel Buchner — Senior PM, Decentralized Identity, Microsoft

• Siva Kannan — Chief Software Development Officer, Gem

• Matt Smith — Software Architect, Gem

• Dan Gisolfi — CTO Trusted Identity |Distinguished Engineer, IBM

More Projects/companies working on blockchain and identity

More Projects/companies working on blockchain and identity.

最坏的情况是：f个节点是有问题的，由于到达顺序的问题，有可能f个有问题的节点比正常的f个节点先返回消息，又要保证收到的正常的节点比有问题的节点多，所以需要满足N-f-f>f => N>3f，所以至少3f+1个节点。

为什么至少要2f个prepare (包括自己的pre-prepare共2f+1)。这是因为之前论证的，如果有f个fault 节点，那么节点总数至少是N=3f+1。简单说一下论证过程，假设总数N个节点，f个fault节点，那么必须接收到N-f个消息应答，才能够判断出结果(因为fault节点可能不发送应答)。N-f个应答中有f个可能是假的(fault节点发出的)，那么真实的是N-f-f，要求真实的应答大于假的应答，即N-f-f > f ==> N > 3f。所以: N_min = 3f+1 所以在prepare和commit两个阶段必须收到2f+1(包括自己) 的应答消息，才能证明有f+1非fault节点发送了应答。(注意前提是非fault对于相同的消息，会产生相同的消息应答)那么这里也有个问题：就是接收2f+1个消息的时，判断是否一致，是否需要对比数据的的签名。我的看法是，如果2f+1个v，n都相同，d(m)只需要f+1相同就可以了。否则就共识失败了。

原文作者：Vijini Mallawaarachchi
原文地址：10 Common Software Architectural Patterns in a nutshell

有没有想过要设计多大的企业规模系统？在主要的软件开发启动之前，我们必须选择好体系结构，它将为我们提供所需的功能和质量。因此，在将它们应用到具体设计之前，我们应该了解不同的体系结构。

什么是架构模式？

根据维基百科中的定义：

架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。

在本文中，将简要地解释以下10种常见的体系架构模式，以及它们的用法、优缺点。

1. Layer 分层模式
2. CS 客户端-服务器模式
3. MS 主从设备模式
4. Filter 管道-过滤器模式
5. Broker 代理模式
6. P2P 点对点模式
7. Bus 事件总线模式
8. MVC 模型-视图-控制器模式
9. Blockboard 黑板模式
10. Expression 解释器模式

一. Layer 分层模式

这种模式也称为多层体系架构模式。它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。每个层都为下一个提供更高层次服务。

一般信息系统中最常见的是如下所列的4层。

• 表示层(也称为UI层)
• 应用层(也称为服务层)
• 业务逻辑层(也称为领域层)
• 数据访问层(也称为持久化层)

使用场景：

• 一般的桌面应用程序
• 电子商务Web应用程序

二. CS 客户端-服务器模式

这种模式由两部分组成：一个服务器和多个客户端。服务器组件将为多个客户端组件提供服务。客户端从服务器请求服务，服务器为这些客户端提供相关服务。此外，服务器持续侦听客户机请求。

使用场景：

• 电子邮件，文件共享和银行等在线应用程序
  

三. MS 主从设备模式

这种模式由两方组成,主设备和从设备。主设备组件在相同的从设备组件中分配工作，并计算最终结果，这些结果是从设备返回的结果。

使用场景：

• 在数据库复制中，主数据库被认为是权威的来源，并且要与之同步
• 在计算机系统中与总线连接的外围设备(主和从驱动器)
  

四. 管道-过滤器模式

此模式可用于构造、生成和处理数据流的系统。每个处理步骤都封装在一个过滤器组件内。要处理的数据是通过管道传递的。这些管道可以用于缓冲或用于同步。

使用场景：

• 编译器。连续的过滤器执行词法分析、解析、语义分析和代码生成
• 生物信息学的工作流
  

五. 代理模式

此模式用于构造具有解耦组件的分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责组件之间的通信协调。

服务器将其功能(服务和特征)发布给代理。客户端从代理请求服务，然后代理将客户端重定向到其注册中心的适当服务。

使用场景：

• 消息代理软件，如Apache ActiveMQ，Apache Kafka，RabbitMQ和JBoss Messaging
• 负债均衡 Ngix

六. 点对点模式

在这种模式中，单个组件被称为对等点。对等点可以作为客户端，从其他对等点请求服务，作为服务器，为其他对等点提供服务。对等点可以充当客户端或服务器或两者的角色，并且可以随时间动态地更改其角色。

使用场景：

• 像Gnutella和G2这样的文件共享网络
• 多媒体协议，如P2PTV和PDTP
• 像Spotify这样的专有多媒体应用程序

七. 事件总线模式

这种模式主要是处理事件，包括4个主要组件：事件源、事件监听器、通道和事件总线。消息源将消息发布到事件总线上的特定通道上。侦听器订阅特定的通道。侦听器会被通知消息，这些消息被发布到它们之前订阅的一个通道上。

使用场景：

• 安卓开发
• 通知服务

八. MVC 模型-视图-控制器模式

这种模式，也称为MVC模式，把一个交互式应用程序划分为3个部分，

• 模型：包含核心功能和数据
• 视图：将信息显示给用户(可以定义多个视图)
• 控制器：处理用户输入的信息
  这样做是为了将信息的内部表示与信息的呈现方式分离开来，并接受用户的请求。它分离了组件，并允许有效的代码重用。

使用场景：

• 在主要编程语言中互联网应用程序的体系架构
• 像Django和Rails这样的Web框架
  

九. 黑板模式

这种模式对于没有确定解决方案策略的问题是有用的。黑板模式由3个主要组成部分组成。

• 黑板——包含来自解决方案空间的对象的结构化全局内存
• 知识源——专门的模块和它们自己的表示
• 控制组件——选择、配置和执行模块
  所有的组件都可以访问黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上查找特定类型的数据，并通过与现有知识源的模式匹配来查找这些数据。

使用场景：

• 语音识别
• 车辆识别和跟踪
• 蛋白质结构识别
• 声纳信号的解释
  

十. 解释器模式

这个模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。

使用场景：

• 数据库查询语言，比如SQL
• 用于描述通信协议的语言
  

体系架构模式的比较

下面给出的表格总结了每种体系架构模式的优缺点。

名称—优点—缺点
1.分层模式:
- 一个较低的层可以被不同的层所使用。层使标准化更容易，因为我们可以清楚地定义级别。可以在层内进行更改，而不会影响其他层。
- 不是普遍适用的。在某些情况下，某些层可能会被跳过。
2.客户端-服务器模式:
- 很好地建立一组服务，用户可以请求他们的服务。
- 请求通常在服务器上的单独线程中处理。由于不同的客户端具有不同的表示，进程间通信会导致额外开销。
3.主从设备模式:
- 准确性——将服务的执行委托给不同的从设备，具有不同的实现。
- 从设备是孤立的：没有共享的状态。主-从通信中的延迟可能是一个问题，例如在实时系统中。这种模式只能应用于可以分解的问题。
4.管道-过滤器模式:
- 展示并发处理。当输入和输出由流组成时，过滤器在接收数据时开始计算。轻松添加过滤器，系统可以轻松扩展。过滤器可重复使用。可以通过重新组合一组给定的过滤器来构建不同的管道。
- 效率受到最慢的过滤过程的限制。从一个过滤器移动到另一个过滤器时的数据转换开销。
5.代理模式:
- 允许动态更改、添加、删除和重新定位对象，这使开发人员的发布变得透明。
- 要求对服务描述进行标准化。
6.点对点模式:
- 支持分散式计算。对任何给定节点的故障处理具有强大的健壮性。在资源和计算能力方面具有很高的可扩展性。
- 服务质量没有保证，因为节点是自愿合作的。安全是很难得到保证的。性能取决于节点的数量。
7.事件总线模式:
- 新的发布者、订阅者和连接可以很容易地添加。对高度分布式的应用程序有效。
- 可伸缩性可能是一个问题，因为所有消息都是通过同一事件总线进行的。
8.模型-视图-控制器模式:
- 可以轻松地拥有同一个模型的多个视图，这些视图可以在运行时连接和断开。
- 增加复杂性。可能导致许多不必要的用户操作更新。
9.黑板模式:
- 很容易添加新的应用程序。扩展数据空间的结构很简单。
- 修改数据空间的结构非常困难，因为所有应用程序都受到了影响。可能需要同步和访问控制。
10.解释器模式:
- 高度动态的行为是可行的。对终端用户编程性提供好处。提高灵活性，因为替换一个解释程序很容易。
- 由于解释语言通常比编译后的语言慢，因此性能可能是一个问题。

这款区块链小程序“小协议”，用户只需输入协议的标题和内容，可以选择是否加密存储协议内容，支付一定的服务费（费用和字数正相关），生成协议，甲方将协议微信转发乙方，乙方同意之后，这份协议就会被写入以太坊网络。

在使用小协议时，不需要用户购买以太坊进行支付，直接微信支付人民币，小协议会在后台用以太坊帮写入用户所需要的数据。全部过程都在微信里完成。

据了解，小协议会读取甲方和乙方的微信ID，这是固定的身份标识，背后通常绑定了很多个人核心信息，例如手机号、银行卡、指纹等等，安全性较高，易验证。这解决了电子合同的身份验证问题。

会话秘钥是指甲方创建协议和乙方确认协议时，根据当时的时间戳，在微信系统内生成的一次记录值，这秘钥是可变的，只和本次会话挂钩。这解决了签订时间的问题。

另外，小协议的显现载体是通过图片为载体来显现合同内容的，因此解决了显现载体的问题。

但是，一份有法律效应的协议，除了不可篡改且能验明身份，还需要得到现有法律的支持，不然出了纠纷，法院也无法解决问题，这个协议就变得没有意义。这也许是此次“小协议”暂停服务的重要原因之一。国内对电子协议是有专门立法的，但是在具体执行上，存在一些不认可的领域，尤其是涉及到大额交易时。

Credits 白皮书：

https://www.credits.com/Content/Docs/TechnicalWhitePaperCREDITSEng.pdf

网络节点

节点的类型：

1. 公共节点（CN）是参加交易验证的节点，具有最小的信任因子。它也是可信节点和当前处理的候选人。
2. 可信节点（TN）是参加交易验证的节点，具有最大值信任因子（1），它是当前处理和普通节点的候选人。在投票和选举的数学计算期间，该节点不是可信的。数学计算取决于节点的数量和网络的复杂性。
3. 网络主节点（MN）是参与验证的节点。负责将交易添加到账本中。在投票和选举的数学计算期间，该节点不是可信的。

系统使用可信因子 - 从0到1的绝对分数值，以（可信节点数的数量+1）表示网络中节点的总数。该可信节点的最大数量不能超过网络节点的50％。

网络主节点的概念

所有网络节点都是分布式的，没有任何一个具有优先权。网络节点被定义为将处理存储事务队列，构建一个新的交易块并将其放入账本中的节点。

CREDITS平台通过最新的节点账本和容量证明的校验以证明节点的账本是最新的。
基于最新的账本，节点通过计算一个 hash 运算来使得自己变成网络主节点。之后全网广播，结构中包含了一个时间戳和一个基于最新账本的计算值，其他网络节点接到结果后开始验证并通过。此验证过程原则上为 BFT。验证通过后全网认定了唯一的网络主节点。

添加之后，初始消息被分成若干块，每块由16个词组成。每个消息都经过64 ~ 80 次迭代，在每次迭代中，2个次被转换，其余的词定义转换函数。每个块的结果都被hash 计算得到摘要。

网络节点设备

建议使用物质激励来维护网络中最优性能的服务器和高互联网带宽。作为物质补偿，主网络节点的所有者将获得报酬，即CREDITS Token。其余的部分（½）赠予参与BFT共识的可信节点。百分比可以是改变的，通过网络的联邦投票决定费率激励系统。

构建共识

如上所述，主网络节点由所有节点选择。主要任务是：获取候选状态的事务以推动所有节点追加账本。

整个过程可以分为以下几个阶段：

1. 搜索网络主节点;
2. 构建可信节点;
3. 接收交易清单并建立一份候选人清单;
4. 处理候选人名单，节点投票（可信节点和普通节点有不同的权重因子;
5. 移除候选人未经证实的交易;
6. 构建一个已经被确认的交易清单，加入账本;
7. 使用包含的块的时间戳和散列码将交易添加到账本中;
8. 将块发送到所有网络节点。收到时，它被添加到所有节点的注册表中。

交易没有被包含在注册表中

未包含在就绪交易列表中的交易标记为已拒绝。这样的交易立即显示给交易的发起人。

不包含在账本中的交易仍保留在候选人的集合中并存储在网络节点上。服务器同时也在收取新交易，然后搜索过程重新开始。这种连续循环操作可以在保持高度可靠性的同时快速进行交易的稳定性。

—笔者认为上述过程对交易的排序是不严谨的。