Zhuang's Diary

什么是zk-SNARKs？

Zcash是zk-SNARKs的第一个广泛应用，它是一种零知识密码学的新形式。Zcash的隐私保证源于可以屏蔽交易，但仍可通过zk-SNARK证明在网络共识规则下验证为有效。

缩写zk-SNARK代表“Zero-Knowledge Succinct Non-Interactive Argument of Knowledge 零知识简明非交互式知识”，并且指向的证明构造可以证明拥有某些信息，例如，一个密钥，不泄露该信息的情况下，也不在证明者和验证者之间进行任何交互。

“零知识”证明允许一方（证明方 prover）向另一方（验证方 verifier）证明声明的内容是真实的，不泄露超出声明本身有效性的任何信息。例如，考虑使用随机数的散列，证明者可以说服验证者确实存在具有该散列值的数字，而不透露数字的内容是什么。

在零知识“知识证明”中，证明者可以说服验证者不仅知道该数字存在，而且他们实际上知道这样一个数字，且不透露关于数字的任何信息。

可以在几毫秒内验证“简洁”的零知识证明，即使对于非常大的程序的声明内容，验证长度也只有几百字节。在最初零知识协议中，证明者和验证者必须多次来回通信，但在“非交互式”结构中，证明者发送“证明”给验证者，“证明”由单个消息组成。目前，唯一已知的生成非交互式的，足够短的，以发布到区块链的零知识证明方法具有“初始设置阶段 initial setup phase”，此阶段生成在证明者和验证者之间共享的公共参考字符串。我们将这个公共参考字符串称为系统的公共参数。

如果有人能够获得用于生成这些参数的随机性秘密，他们将能够创建对验证者看起来有效的错误证明。对于Zcash来说，这意味着恶意方可能会制造假币。为了防止此情况，Zcash设计了由多方程序产生公众参数。要详细了解参数生成程序并查看为防止随机性问题而采取的预防措施（例如，计算机正在生成公共参数），请访问Paramgen页面。要了解有关参数生成协议背后的数学的更多信息，请阅读博客文章或有关该主题的白皮书。

ZK-SNARKS如何在ZCASH中构建

为了在Zcash中拥有零知识隐私，根据网络共识规则确定交易有效的函数必须返回交易是否有效，而不泄露其执行计算的任何信息。这是通过对zk-SNARKs中的一些网络共识规则进行编码完成的。在很高的层面上，zk-SNARKs首先将你想要证明的东西转化为关于知道某些代数方程解的等价形式。

在下面的章节中，将简要介绍如何将用于确定有效交易的规则转换为方程，然后可以在候选解决方案上对方程进行评估，而不会向验证方程的当事方透露任何敏感信息。

计算 → 算术电路 → R1CS → QAP → zk-SNARK

将交易有效性函数转化为数学表示，第一步是将逻辑步骤分解为最小可能的操作，从而创建一个“算术电路”。 类似于一个布尔逻辑电路，其中一个程序被编译成离散的单个步骤，如AND，OR，NOT，当一个程序转换为一个算术电路时，它被分解为单个步骤，包括加法，减法， 乘法和除法（在特殊情况下，我们将避免使用除法）。

下面是计算表达式（a + b）*（b * c）的算术电路的例子：

看着这样一个电路，我们可以将输入值a，b，c看作在输出线上从左到右的“行进”。我们的下一步是建立的一级约束系统 (Rank 1 Constraint System)，即R1CS，以检查这些值是否“行进正确”。在上图中，R1CS将确认，b和c进入的乘法门的值是 b*c。

在这个R1CS表示中，验证者必须检查许多约束条件 - 几乎每条线路都有一个约束条件。 （由于技术原因，事实证明，我们只能对乘法门引出的线路有所限制。）在2012年关于该主题的论文中，Gennaro，Gentry，Parno和Raykova提出了一种很好的方法来“将所有这些约束集中成一个” 。该方法使用称为二次算术程序（QAP）的电路表示。需要检查的单个约束在多项式之间而不是数字之间。多项式可能相当大，因为当多项式之间的身份不成立时，它将无法保持多数点。因此，您只需检查两个多项式是否在一个随机选择的点上匹配，以便以高概率正确验证证明。

如果证明者事先知道验证者选择检查哪一点，则他们可能能够制造无效的多项式，但仍然满足当时的身份。使用zk-SNARKs，复杂的数学技术（如同态加密和椭圆曲线配对）可用于“盲人式”评估多项式 - 即不知道哪个点正在评估。上面描述的公共参数用于确定将检查哪个点，且以加密形式，以便证明者和验证者都不知道公共参数是什么。

到目前为止的描述主要涉及如何获得“SNARKs”中的S和N - 如何获得短暂的，非交互式的单一消息证明 - 但尚未解决允许 “zk”（零知识）部分证明者维护其秘密投入的机密性。事实证明，在这个阶段，通过使证明者使用仍然满足所需身份的原始多项式的“随机偏移”，可以容易地添加“zk”部分。

有关Zcash中关于zk-SNARKs背后关键概念的深入解释，请参阅后面的博客文章。

Zcash使用 libsnark 分支，这是一个用于zk-SNARKs的C++库。 您可以检查代码并了解更多关于在 github 上的实现。要深入了解 Zcash zk-SNARKs 的协议，请参阅 Pinocchio协议 的本文。

ZK-SNARKS如何应用于创建屏蔽交易

在比特币中，通过链接发件人地址，收件人地址以及公共区块链上的输入和输出值来验证交易。 Zcash使用zk-SNARKs来证明有效交易的条件得到了满足，但没有透露任何有关地址或值的重要信息。 屏蔽交易的发件人构建了一个证据，以高概率显示：

输入总和 等于 每个屏蔽转换的输出总和。

发件人证明他们拥有输入的私钥，赋予他们花费的权力。

输入的私钥与整个交易的签名链接起来，链接是加密的，则，交易不会被不知道这些私钥的人修改。

另外，屏蔽交易必须满足下面描述的其他条件：

比特币跟踪(未花费的交易输出)UTXO，以确定哪些交易是可用的。 在Zcash中，UTXO的屏蔽等同物称为“承诺”，花费承诺包含暴露出“花费人”。 Zcash节点保留已经创建的所有承诺的清单以及所有已经暴露的花费人。承诺和无效值存储为散列值，以避免公开关于承诺的任何信息，或者哪些无效值与哪些承诺相关。

对于由屏蔽付款创建的每个新钞票，将公布一个承诺，其中包含以下内容的散列：

• 钞票发送的地址
• 发送的金额
• 本钞票所特有的数字“rho”（稍后用于派生花费人）和一个随机数。

1

Commitment = HASH(recipient address, amount, rho, r)

当屏蔽交易被花费时，发件人使用他们的支出密钥来公布一个花费者，该花费者是来自尚未用过的现有承诺的唯一编号（“rho”）的hash，并提供零知识证明，证明他们有权花费它。 该散列必须不在花费清单中，花费清单在区块链的每个节点中保存。

1

Nullifier = HASH(spending key, rho)

屏蔽交易的零知识证明证实，除了上面列出的条件外，以下认定也是正确的：

对于每个输入，都存在明确的承诺。

花费者和钞票承诺计算正确。

输出钞票的花费者与任何其他钞票的花费者发生绝不会发生冲突。

除了用于控制地址的支出密钥之外，Zcash还使用一组证明和验证密钥来创建和检查证明。这些密钥在上面讨论的公共参数程序中生成，并在Zcash网络中的所有参与者之间共享。对于每个屏蔽交易，发件人使用他们的证明密钥来生成他们的输入有效的证据。矿工通过使用验证密钥检查证明者的计算来检查被保护的交易遵循共识规则。Zcash证明生成的设计方式要求证明者事先做更多的工作，但它简化了验证，因此主要的计算工作被转移到交易的创建者（这就是为什么创建屏蔽Zcash事务可能会占用到40秒，同时验证事务有效仅需要几毫秒）。

Zcash的屏蔽交易的隐私依赖于标准的，经过验证的密码学（散列函数和流密码），但它增加了zk-SNARKs，与承诺和花费机制一起使用，允许屏蔽交易的发送者和接收者证明加密交易是有效的。其他为加密货币提供隐私的方法依赖于模糊交易之间的链接，但事实上Zcash交易可以存储在完全加密的区块链中，为加密货币应用程序开辟了新的可能性。加密交易使得各方可以享受公共区块链的好处，同时保护他们的隐私。计划的未来升级将允许用户根据自己的判断有选择地披露有关被屏蔽交易的信息。查看Zcash博客文章的近期未来，了解Zcash的未来计划。

有关如何在Zcash中构建屏蔽事务的更深入解释，请参阅我们的博客文章，了解屏蔽地址之间的事务如何工作。有关当前Zcash协议的完整详细信息，请参阅我们的协议规范。

ZK-SNARKS的未来应用

在Zcash中创建屏蔽交易只是zk-SNARKs许多可能应用中的一个例子。从理论上讲，您可以使用zk-SNARK来验证任何关系，而不会泄露输入或泄露信息。对复杂函数生成证明的计算量仍然过大，许多程序还不适用，但Zcash团队正在推动优化zk-SNARKs的界限，并且已经以更高效的实施方式开创了新局面。

就目前而言，Zcash的zk-SNARKs实现可以作为企业用例的零知识安全层添加到任何现有的分布式分类帐解决方案中。

zk-SNARKs 原文链接

参考

Zcash协议规范

解释SNARKs系列文章

1. 同态隐藏

2. 多项式盲评估

3. 系数测试知识和假设

4. 如何验证多项式盲评估

5. 从计算到多项式

6. Pinocchio Protocol — 皮诺曹协议

7. 配对椭圆曲线

8. 零知识证明在 Quorum 中是如何使用的 — Zero Knowledge Proofs and how they can be implemented in Quorum

9. 零知识证明在以太坊智能合约端如何实现区间证明 — zero knowledge range-proof precompiled contract for the go-ethereum client

论文

1. 皮诺曹协议

2. Paramgen白皮书

3. Zerocash论文

技术博客文章

1. Matt Green: 零知识证明

2. Zcash交易解剖

3. 隐私交易如何完成的

4. Zcash的参数是如何生成的

5. 在Rust进行密码学配对

相关项目

1. HAWK：私有的智能合约

2. BOLT：私有的支付通道

后面的博客中会针对上述内容进行分析。

背景

channel，即“管道”，是用来传递数据（叫消息更为合适）的一个数据结构，即可以从channel里面塞数据，也可以从中获取数据。channel本身并没有什么神奇的地方，但是channel加上了goroutine，就形成了一种既简单又强大的请求处理模型，即N个工作goroutine将处理的中间结果或者最终结果放入一个channel，另外有M个工作goroutine从这个channel拿数据，再进行进一步加工，通过组合这种过程，从而胜任各种复杂的业务模型。

goroutine不同于thread，threads是操作系统中的对于一个独立运行实例的描述，不同操作系统，对于thread的实现也不尽相同；但是，操作系统并不知道goroutine的存在，goroutine的调度是有Golang运行时进行管理的。启动thread虽然比process所需的资源要少，但是多个thread之间的上下文切换仍然是需要大量的工作的（寄存器/Program Count/Stack Pointer/…），Golang有自己的调度器，许多goroutine的数据都是共享的，因此goroutine之间的切换会快很多，启动goroutine所耗费的资源也很少，一个Golang程序同时存在几百个goroutine是很正常的。

Go Channel的基本操作语法如下：

1
2
3
4
5

c := make(chan bool)    //创建一个无缓冲的bool型Channel
c <- x                  //向一个Channel发送一个值
<- c                    //从一个Channel中接收一个值
x = <- c                //从Channel c接收一个值并将其存储到x中
x, ok = <- c            //从Channel接收一个值，如果channel关闭了或没有数据，那么ok将被置为false

不带缓冲的Channel兼具通信和同步两种特性，颇受青睐。

模型01-go关键字

直接加上go关键字，就可以让一个函数脱离原先的主函数独立运行，即主函数直接继续进行剩下的操作，而不需要等待某个十分耗时的操作完成。

1
2
3
4
5
6
7
8
9

func (m *SomeController) PorcessSomeTask() {
    var task models.Task
    if err := task.Parse(m.Ctx.Request); err != nil {
        m.Data["json"] = err 
        m.ServeJson()
        return
    }
    go task.Process()
    m.ServeJson()

如果 func(peer Peer) 函数需要耗费大量时间的话，这个请求就会被 block 住。有时候，前端只需要发出一个请求给后端，并且不需要后端立即所处响应。遇到这样的需求，直接在耗时的函数前面加上go关键字就可以将请求之间返回给前端了，保证了体验。

不过，这种做法也是有许多限制的。比如：

• 只能在前端不需要立即得到后端处理的结果的情况下使用
• 这种请求的频率不应该很大，因为目前的做法没有控制并发量

模型02-并发控制

上一个方案有一个缺点就是无法控制并发，如果这一类请求同一个时间段有很多的话，每一个请求都启动一个goroutine，如果每个goroutine中还需要使用其他系统资源，消耗将是不可控的。

遇到这种情况，一个解决方案是：将请求都转发给一个channel，然后初始化多个goroutine读取这个channel中的内容，并进行处理。假设我们可以新建一个全局的channel

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

var TASK_CHANNEL = make(chan models.Task)

// 然后，启动多个goroutine：
for i := 0; i < WORKER_NUM; i ++ {
    go func() {
        for {
            select {
            case task := <- TASK_CHANNEL:
                task.Process()
            }
        }
    } ()
}

// 服务端接收到请求之后，将任务传入channel中即可：
func (m *SomeController) PorcessSomeTask() {
    var task models.Task
    if err := task.Parse(m.Ctx.Request); err != nil {
        m.Data["json"] = err 
        m.ServeJson()
        return
    }
    // go task.Process()
    TASK_CHANNEL <- task
    m.ServeJson()
}

这样一来，这个操作的并发度就可以通过WORKER_NUM来控制了。

模型03-处理channel满的情况

不过，上面方案有一个bug：那就是channel初始化时是没有设置长度的，因此当所有WORKER_NUM个goroutine都正在处理请求时，再有请求过来的话，仍然会出现被block的情况，而且会比没有经过优化的方案还要慢（因为需要等某一个goroutine结束时才能处理它）。因此，需要在channel初始化时增加一个长度：

1

var TASK_CHANNEL = make(chan models.Task, TASK_CHANNEL_LEN)

这样一来，我们将 TASK_CHANNEL_LEN 设置得足够大，请求就可以同时接收 TASK_CHANNEL_LEN 个请求而不用担心被block。不过，这其实还是有问题的：那如果真的同时有大于 TASK_CHANNEL_LEN 个请求过来呢？一方面，这就应该算是架构方面的问题了，可以通过对模块进行扩容等操作进行解决。另一方面，模块本身也要考虑如何进行“优雅降级了”。遇到这种情况，我们应该希望模块能够及时告知调用方，“我已经达到处理极限了，无法给你处理请求了”。其实，这种需求，可以很简单的在Golang中实现：如果channel发送以及接收操作在select语句中执行并且发生阻塞，default语句就会立即执行。

1
2
3
4
5
6
7
8

select {
case TASK_CHANNEL <- task:
    //do nothing
default:
    //warnning!
    return fmt.Errorf("TASK_CHANNEL is full!")
}
//...

模型04-接收发送给channel之后返回的结果

如果处理程序比较复杂的时候，通常都会出现在一个goroutine中，还会发送一些中间处理的结果发送给其他goroutine去做，经过多道“工序”才能最终将结果产出。

那么，我们既需要把某一个中间结果发送给某个channel，也要能获取到处理这次请求的结果。解决的方法是：将一个channel实例包含在请求中，goroutine处理完成后将结果写回这个channel。

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

type TaskResponse struct {
    //...
}

type Task struct {
    TaskParameter   SomeStruct
    ResChan         *chan TaskResponse
}

//...

task := Task {
    TaskParameter   : xxx,
    ResChan         : make(chan TaskResponse),
}

TASK_CHANNEL <- task
res := <- task.ResChan
//...

（这边可能会有疑问：为什么不把一个复杂的任务都放在一个goroutine中依次的执行呢？是因为这里需要考虑到不同子任务，所消耗的系统资源不尽相同，有些是CPU集中的，有些是IO集中的，所以需要对这些子任务设置不同的并发数，因此需要经由不同的channel + goroutine去完成。）

模型05-等待一组goroutine的返回

将任务经过分组，交由不同的goroutine进行处理，最终再将每个goroutine处理的结果进行合并，这个是比较常见的处理流程。这里需要用到WaitGroup来对一组goroutine进行同步。一般的处理流程如下：

1
2
3
4
5
6
7
8
9
10
11

var wg sync.WaitGroup
for i := 0; i < someLen; i ++ {
    wg.Add(1)
    go func(t Task) {
        defer wg.Done()
        //对某一段子任务进行处理
    } (tasks[i])
}

wg.Wait()
//处理剩下的工作

模型06-超时机制

即使是复杂、耗时的任务，也必须设置超时时间。一方面可能是业务对此有时限要求（用户必须在XX分钟内看到结果），另一方面模块本身也不能都消耗在一直无法结束的任务上，使得其他请求无法得到正常处理。因此，也需要对处理流程增加超时机制。

我一般设置超时的方案是：和之前提到的“接收发送给channel之后返回的结果”结合起来，在等待返回channel的外层添加select，并在其中通过time.After()来判断超时。

1
2
3
4
5
6
7
8
9
10
11

task := Task {
    TaskParameter   : xxx,
    ResChan         : make(chan TaskResponse),
}

select {
case res := <- task.ResChan:
    //...
case <- time.After(PROCESS_MAX_TIME):
    //处理超时
}

模型07-广播机制

既然有了超时机制，那也需要一种机制来告知其他 goroutine 结束手上正在做的事情并退出。很明显，还是需要利用channel来进行交流，第一个想到的肯定就是向某一个chan发送一个struct即可。比如执行任务的goroutine在参数中，增加一个 chan struct{} 类型的参数，当接收到该channel的消息时，就退出任务。但是，还需要解决两个问题：

1. 怎样能在执行任务的同时去接收这个消息呢？
2. 如何通知所有的goroutine？

对于第一个问题，比较优雅的作法是：使用另外一个channel作为函数的输出，再加上select，就可以一边输出结果，一边接收退出信号了。

另一方面，对于同时有未知数目个执行goroutine的情况，一次次调用 done <-struct{}{}，显然无法实现。这时候，就会用到golang对于channel的tricky用法：当关闭一个channel时，所有因为接收该channel而阻塞的语句会立即返回。示例代码如下：

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

// 执行方
func doTask(done <-chan struct{}, tasks <-chan Task) (chan Result) {
    out := make(chan Result)
    go func() {
        // close 是为了让调用方的range能够正常退出
        defer close(out)
        for t := range tasks {
            select {
            case result <-f(t):
                // do task
            case <-done:
                return
            }
        }
    }()

    return out
}

// 调用方
func Process(tasks <-chan Task, num int) {
    done := make(chan struct{})
    out := doTask(done, tasks)

    go func() {
        <- time.After(MAX_TIME)
        //done <-struct{}{}

        //通知所有的执行goroutine退出
        close(done)
    }()

    // 因为goroutine执行完毕，或者超时，导致out被close，range退出
    for res := range out {
        fmt.Println(res)
        //...
    }
}

参考：

http://blog.golang.org/pipelines

https://gobyexample.com/non-blocking-channel-operations

web3

Github： https://github.com/ethereum/web3.js/
web3.js是以太坊提供的一个Javascript库，它封装了以太坊的RPC通信API，提供了一系列与区块链交互方法，使js与以太坊交互变得简单。

infura

官网： https://infura.io/
本地安装geth的方法需要花比较多的时间和空间来同步区块，利用infura可以简单很多，infura提供公开以太坊和测试节点，可以利用infura提供的api访问以太坊以及IPFS。去官网只需要提供email注册得到链接即可。

使用web3和infura开发

最常用的操作例如查看一个以太坊地址的ether余额为例（类似etherscan）.

通过npm或其他方式引入web3, 并使用infura提供主网/测试网进行初始化。

1
2
3
4
5
6
7

// xxxx为你在infura申请的地址
web3 = new Web3(new Web3.providers.HttpProvider("https://mainnet.infura.io/xxxxxxxx"));
// 接下来就可以调用web3的接口了,例如获取一个地址的ether数量
// wei是以太坊上的的最小单位，ether小数点后18位为一个wei
var balanceWei = web3.eth.getBalance("0xC257274276a4E539741Ca11b590B9447B26A8051").toNumber();
// 从wei转换成ether
var balance = web3.fromWei(balanceWei, 'ether');

至此便可以从以太坊主网上进行操作了，例如查看区块信息，部署智能合约等。
具体开发可以参考以太坊JS API： https://github.com/ethereum/wiki/wiki/JavaScript-API

相关内容：

1. 以太坊编程 III
2. 以太坊编程 II
3. 以太坊编程 I

gRPC 简介：

gRPC 是一款高性能、开源的 RPC（Remote Procedure Call）框架，产自 Google，基于 ProtoBuf 序列化协议进行开发，支持多种语言（Golang、Python、Java等），本篇只介绍 Golang 的 gRPC 使用。因为 gRPC 对 HTTP/2 协议的支持使其在 Android、IOS 等客户端后端服务的开发领域具有良好的前景。gRPC 提供了一种简单的方法来定义服务，同时客户端可以充分利用 HTTP/2 stream 的特性，从而有助于节省带宽、降低 TCP 的连接次数、节省CPU的使用等。

安装：

gRPC 的安装：

1

$ go get -u google.golang.org/grpc

因为 gRPC 是基于 protobuf 实现的接口序列化，所以也要安装 protobuf： 安装及简介教程(Golang 序列化之 ProtoBuf)。

实验：

下面我们使用 gRPC 定义一个接口，该接口实现对传入的数据进行大写的格式化处理。

1. 创建项目 golang Demo 工程：

client目录下的 main.go 实现了客户端用于发送数据并打印接收到 server 端处理后的数据

1. server 目录下的 main.go 实现了服务端用于接收客户端发送的数据，并对数据进行大写处理后返回给客户端
2. example 包用于编写 proto 文件并生成 data 接口
3. 定义 gRPC 接口：

1
2
3
4
5
6
7
8
9

syntax = "proto3";
package example;
service FormatData {
    rpc DoFormat(Data) returns (Data){} 
    // 此处定义的方法为简单RPC。其余的服务器端流式 RPC，客户端流式 RPC，双向流式 RPC请查询参考链接
}
message Data {
    string text = 1;
}

编译 protobuf：

1

protoc --go_out=plugins=grpc:. *.proto // 在 example 目录中执行编译，会生成：data.pb.go

实现 server 端：

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

package main
import (
	"gRPCDemo/example"
	"net"
	"google.golang.org/grpc"
	"google.golang.org/grpc/reflection"
	"golang.org/x/net/context"
	"strings"
	"log"
)
// 定义监听地址
const (
	HOST string = "localhost"
	PORT string = "8080"
)
// 定义接口
type FormatData struct{}
func (fd *FormatData) DoFormat(ctx context.Context, in *example.Data) (out *example.Data, err error) {
	str := in.Text
	out = &example.Data{Text: strings.ToUpper(str)}
	return out, nil
}
// 直接在 main 方法中注册接口
func main() {
	// 启动服务器
	// 指定我们期望客户端请求的监听端口
	listener, err := net.Listen("tcp", HOST+":"+PORT)
	if err != nil {
		log.Fatalln("faile listen at: " + HOST + ":" + PORT)
	} else {
		log.Println("Demo server is listening at: " + HOST + ":" + PORT)
	}
	// 创建 gRPC 服务器的一个实例
	rpcServer := grpc.NewServer()
	// 在 gRPC 服务器注册我们的服务实现
	example.RegisterFormatDataServer(rpcServer, &FormatData{})
	reflection.Register(rpcServer)
	// 实现阻塞等待，直到进程被杀死或者 Stop() 被调用
	if err = rpcServer.Serve(listener); err != nil {
		log.Fatalln("faile serve at: " + HOST + ":" + PORT)
	}
}

实现 client 端：

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

package main
import (
	"google.golang.org/grpc"
	"log"
	"gRPCDemo/example"
	"golang.org/x/net/context"
)
// 定义请求地址
const (
	ADDRESS string = "localhost:8080"
)
// main 方法实现对 gRPC 接口的请求
func main() {
	// 为了调用服务方法，我们首先创建一个 gRPC channel 和服务器交互。
	// 可以使用 DialOptions 在 grpc.Dial 中设置授权认证（如， TLS，GCE认证，JWT认证）
	conn, err := grpc.Dial(ADDRESS, grpc.WithInsecure())
	if err != nil {
		log.Fatalln("Can't connect: " + ADDRESS)
	}
	defer conn.Close()
	// 一旦 gRPC channel 建立起来，我们需要一个客户端 存根 去执行 RPC
	client := example.NewFormatDataClient(conn)
	// 调用简单 RPC
	resp,err := client.DoFormat(context.Background(), &example.Data{Text:"hello,world!"})
	// 如果调用没有返回错误，那么我们就可以从服务器返回的第一个返回值中读到响应信息
	if err != nil {
		log.Fatalln("Do Format error:" + err.Error())
	}
	log.Println(resp.Text)
}

执行验证结果：
先启动 server，之后再执行 client
client 侧控制台如果打印的结果为： HELLO,WORLD! ，证明 gRPC 接口定义成功。

参考

http://doc.oschina.net/grpc?t=60133

https://github.com/grpc/grpc-go

https://grpc.io/