Zhuang's Diary

第一步：也是最重要的一步，就是下载谷歌浏览器！

第二步：下载 Graphviz http://graphviz.org/download/
安装后配置环境变量，再path里面添加安装目录！

第三步：添加以下测试代码 （添加 _”net/http/pprof” 不然不会有效果！）

具体看源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

1 package main
2 import (
3    "net/http"
4    "runtime"
5    "os"
6    "fmt"
7    "runtime/trace"
8    _"net/http/pprof"
9    "runtime/debug"
10   "time"
11   "sync"
12 )
13 func main() {
14   //开启强大的分析器
15   go pprof()
16    //以下是运行测试(也可以贴你自己的)代码
17   var c sync.Map
18   for i:=0;i<100;i++{
19      time.Sleep(time.Second*1)
20      go func(){
21         for j:=0;j<1000000;j++{
22            time.Sleep(time.Millisecond*20)
23            c.Store(fmt.Sprintf("%d",j),j)
24            fmt.Println(c.Load(fmt.Sprintf("%d",j)))
25         }
26      }()
27   }
28   time.Sleep(time.Second*20)
29    fmt.Scan()
30 }
31 //运行pprof分析器
32 func pprof(){
33   go func() {
34      //关闭GC
35      debug.SetGCPercent(-1)
36      //运行trace
37      http.HandleFunc("/start", traces)
38      //停止trace
39      http.HandleFunc("/stop", traceStop)
40      //手动GC
41      http.HandleFunc("/gc", gc)
42      //网站开始监听
43      http.ListenAndServe(":6060", nil)
44   }()
45 }
46 //手动GC
47 func gc(w http.ResponseWriter, r *http.Request) {
48   runtime.GC()
49   w.Write([]byte("StartGC"))
50 }
51 //运行trace
52 func traces(w http.ResponseWriter, r *http.Request){
53   f, err := os.Create("trace.out")
54   if err != nil {
55      panic(err)
56   }
57   err = trace.Start(f)
58   if err != nil {
59      panic(err)
60   }
61   w.Write([]byte("TrancStart"))
62   fmt.Println("StartTrancs")
63 }
64 //停止trace
65 func traceStop(w http.ResponseWriter, r *http.Request){
66   trace.Stop()
67   w.Write([]byte("TrancStop"))
68   fmt.Println("StopTrancs")
69 }

第四步：接下来就看图说话了。

程序运行后随便打开一个CMD 然后输入

1

go tool pprof  http://localhost:6060/debug/pprof/profile

需要等待分析时间，大约30秒，然后再输入

1

web

查看具体pprof的信息了

第五步：查看trace的信息，在谷歌浏览器中输入

然后等一会儿，再输入

当然期间也可以手动gc。在程序运行的地方自动生成一个文件

在cmd中输入 go tool trace trace.out(具体路径)

它会生成一个URL 地址，使用谷歌浏览器打开即可

CPU Profiling

Golang 提供了 pprof 包（runtime/pprof）用于输出运行时的 profiling 数据，这些数据可以被 pprof 工具（或者 go tool pprof，其为 pprof 的变种）使用。通常我们这样来使用 pprof 包：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

1 // 定义 flag cpuprofile
2 var cpuprofile = flag.String("cpuprofile", "", "write cpu profile to file")
3 func main() {
4    flag.Parse()
5    // 如果命令行设置了 cpuprofile
6    if *cpuprofile != "" {
7        // 根据命令行指定文件名创建 profile 文件
8        f, err := os.Create(*cpuprofile)
9        if err != nil {
10            log.Fatal(err)
11        }
12        // 开启 CPU profiling
13        pprof.StartCPUProfile(f)
14        defer pprof.StopCPUProfile()
15    }
16    ...

假定我们编写的一个程序 mytest 中加入了上述代码则可以执行并生成 profile 文件：

1

./mytest -cpuprofile=mytest.prof

这里，我们生成了 mytest.prof profile 文件。有了 profile 文件就可以使用 go tool pprof 程序来解析此文件：

1

go tool pprof mytest mytest.prof

pprof 程序中最重要的命令就是 topN，此命令用于显示 profile 文件中的最靠前的 N 个样本（samples），例如（此例为 http://blog.golang.org/profiling-go-programs 中的例子）：

1
2
3
4
5
6
7
8
9
10
11
12

1 (pprof) top10
2 Total: 2525 samples
3    298  11.8%  11.8%    345  13.7% runtime.mapaccess1_fast64
4    268  10.6%  22.4%   2124  84.1% main.FindLoops
5    251   9.9%  32.4%    451  17.9% scanblock
6    178   7.0%  39.4%    351  13.9% hash_insert
7    131   5.2%  44.6%    158   6.3% sweepspan
8    119   4.7%  49.3%    350  13.9% main.DFS
9     96   3.8%  53.1%     98   3.9% flushptrbuf
10    95   3.8%  56.9%     95   3.8% runtime.aeshash64
11    95   3.8%  60.6%    101   4.0% runtime.settype_flush
12    88   3.5%  64.1%    988  39.1% runtime.mallocgc

开启 CPU profiling 后，Golang 程序在 1 秒钟会停顿 100 次，每次停顿都会记录 1 个样本。上例中，前两列表示运行的函数的样本数量（the number of samples in which the function was running）和占总样本数的百分比，例如说 runtime.mapaccess1_fast64 函数在 298 次采样中（占总采样数量的 11.8%）正在运行。第三列表示前几行样本数量总和占总样本数的百分比（第二行 22.4% 为 11.8% + 10.6%）。第四、五列表示出现的函数的样本数量（the number of samples in which the function appeared）和占总样本数的百分比，这里“出现的函数”指的是在采样中正在运行或者等待某个被调用函数返回的函数，换句话就是采样中那些位于调用栈上的函数。我们可以使用 -cum（cumulative 的缩写）flag 来以第四、五列为标准排序。需要注意的是，每次采样只会包括最底下的 100 个栈帧（stack frames）。

使用 web 命令能够以图形化的方式（SVG 格式）显示函数调用关系。例如（图片来源于 http://blog.golang.org/profiling-go-programs ）：

这里每个方块的大小由运行的函数的样本数量决定（这样就能方便的一眼看到热点函数）。箭头表示的是调用关系，箭头上的数字表示的是采样到的调用次数。web 命令还可以指定显示特定的函数，例如：

1

(pprof) web mapaccess1

当我们有大致的想法（也就是确定热点函数）后，就可以深入特定的函数。我们使用 list 命令（此例为 http://blog.golang.org/profiling-go-programs 中的例子）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

1 (pprof) list DFS
2 Total: 2525 samples
3 ROUTINE ====================== main.DFS in /home/rsc/g/benchgraffiti/havlak/havlak1.go
4    119    697 Total samples (flat / cumulative)
5      3      3  240: func DFS(currentNode *BasicBlock, nodes []*UnionFindNode, number map[*BasicBlock]int, last []int, current int) int {
6      1      1  241:     nodes[current].Init(currentNode, current)
7      1     37  242:     number[currentNode] = current
8      .      .  243:
9      1      1  244:     lastid := current
10    89     89  245:     for _, target := range currentNode.OutEdges {
11     9    152  246:             if number[target] == unvisited {
12     7    354  247:                     lastid = DFS(target, nodes, number, last, lastid+1)
13     .      .  248:             }
14     .      .  249:     }
15     7     59  250:     last[number[currentNode]] = lastid
16     1      1  251:     return lastid

上例中，第一列为运行到此行时的样本数，第二列为运行到此行或从此行调用的样本数，第三列为行号。如果需要显示汇编，可以使用命令 disasm（使用命令 weblist 可以同时显示源码和汇编代码， 这里 有一个范例）。通过样本数，我们可以定位到热点行，然后考虑适合的优化策略。

pprof 包

pprof 包进行 profiling 有两种方式：

• 采样。CPU Profiling 需要不断采样，（如上所述）pprof 包提供了一套特殊的 API（StartCPUProfile / StopCPUProfile）
• 快照。下面详细谈这种方式（同样可以使用 go tool pprof 程序来解析输出的 profile 文件）

pprof 包预先定义了（还可以自己扩展）4 种快照模式：

• goroutine，当前所有 goroutines 的 stack traces
• heap，所有的堆内存分配（为降低开销仅获取一个近似值，To reduce overhead, the memory profiler only records information for approximately one block per half megabyte allocated (the “1-in-524288 sampling rate”), so these are approximations to the actual counts）
• threadcreate，致使新系统线程创建的 stack traces
• block，致使在同步原语上阻塞的 stack traces

相关 API 具体用法如下：

1
2
3
4

1 // 根据名字查找 Profile
2 p := pprof.Lookup("heap")
3 // 将一个 pprof（程序）格式的快照写入 w
4 p.WriteTo(w, 0)

这里的 WriteTo 方法原型为：

1

1 func (p *Profile) WriteTo(w io.Writer, debug int) error

其中 debug 参数：

• 为 0 时，仅仅输出 pprof（程序）需要的十六进制地址
• 为 1 时，输出时增加函数名和行号，这样无需工具也可以阅读此 profile
• 为 2 时，并且当输出 goroutine profile 时，输出的 goroutine 栈的格式为未 recovered panic 时的格式

memory profiling

以 https://blog.golang.org/profiling-go-programs 中的例子为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

1 // 定义 flag memprofile
2 var memprofile = flag.String("memprofile", "", "write memory profile to this file")
3 ...
4    // 需要 profiling 的函数
5    FindHavlakLoops(cfgraph, lsgraph)
6    if *memprofile != "" {
7        f, err := os.Create(*memprofile)
8        if err != nil {
9            log.Fatal(err)
10        }
11        // WriteHeapProfile 等价于 Lookup("heap").WriteTo(w, 0)
12        pprof.WriteHeapProfile(f)
13        // 关闭文件
14        f.Close()
15        return
16    }

使用 go tool pprof 程序打开生成的 profile 文件：

1
2
3
4
5
6
7

1 (pprof) top5
2 Total: 82.4 MB
3    56.3  68.4%  68.4%     56.3  68.4% main.FindLoops
4    17.6  21.3%  89.7%     17.6  21.3% main.(*CFG).CreateNode
5     8.0   9.7%  99.4%     25.6  31.0% main.NewBasicBlockEdge
6     0.5   0.6% 100.0%      0.5   0.6% itab
7     0.0   0.0% 100.0%      0.5   0.6% fmt.init

这里显示了函数当前大致分配的内存。类似 CPU profiling，通过 list 命令查看函数具体的内存分配情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

1 (pprof) list FindLoops
2 Total: 82.4 MB
3 ROUTINE ====================== main.FindLoops in /home/rsc/g/benchgraffiti/havlak/havlak3.go
4   56.3   56.3 Total MB (flat / cumulative)
5...
6    1.9    1.9  268:     nonBackPreds := make([]map[int]bool, size)
7    5.8    5.8  269:     backPreds := make([][]int, size)
8      .      .  270:
9    1.9    1.9  271:     number := make([]int, size)
10   1.9    1.9  272:     header := make([]int, size, size)
11   1.9    1.9  273:     types := make([]int, size, size)
12   1.9    1.9  274:     last := make([]int, size, size)
13   1.9    1.9  275:     nodes := make([]*UnionFindNode, size, size)
14     .      .  276:
15     .      .  277:     for i := 0; i < size; i++ {
16   9.5    9.5  278:             nodes[i] = new(UnionFindNode)
17     .      .  279:     }
18...
19     .      .  286:     for i, bb := range cfgraph.Blocks {
20     .      .  287:             number[bb.Name] = unvisited
21  29.5   29.5  288:             nonBackPreds[i] = make(map[int]bool)
22     .      .  289:     }

有了这些信息，我们就可以着手进行优化了。

BSD开源协议

是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

• 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
• 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
• 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者 二次开发。

Apache Licene 2.0 协议

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：

• 需要给代码的用户一份Apache Licence
• 如果你修改了代码，需要在被修改的文件中说明。
• 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
• 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
• Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

英文原文：http://www.apache.org/licenses/LICENSE-2.0.html

MIT 协议

MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称「X条款」（X License）或「X11条款」（X11 License）

MIT内容与三条款BSD许可证（3-clause BSD license）内容颇为近似，但是赋予软体被授权人更大的权利与更少的限制。

被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。

被授权人可根据程式的需要修改授权条款为适当的内容。

在软件和软件的所有副本中都必须包含版权声明和许可声明。

此授权条款并非属copyleft的自由软体授权条款，允许在自由/开放源码软体或非自由软体（proprietary software）所使用。

此亦为MIT与BSD（The BSD license, 3-clause BSD license）本质上不同处。

MIT条款可与其他授权条款并存。另外，MIT条款也是自由软体基金会（FSF）所认可的自由软体授权条款，与GPL相容。

协议英文原文：http://www.opensource.org/licenses/mit-license.php

GPL 协议

在自由软件所使用的各种许可证之中，最为人们注意的也许是通用性公开许可证(General Public License，简称GPL)。

GPL同其它的自由软件许可证一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。
GPL还规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的 整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循GPL流通 的程序不能同非自由的软件合并。GPL所表达的这种流通规则称为copyleft，表示与copyright(版权)的概念“相左”。

GPL协议最主要的几个原则：

• 确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软 件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。

• GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。

• 无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。

• 开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。

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相同就可以了。否则就共识失败了。