作为本系列的最后一篇文章,本文继续对 zk-SNARK 协议进行完善,最终形成一个完整的 zk-SNARK 协议
上一篇文章中我们学习了如何将程序转换为多项式进行证明。到这里似乎已经有点晕了,本文将对协议执行进一步的约束,并对协议展开优化。
前文主要介绍了如何构造多项式的零知识证明协议,现在将开始探讨如何构造更通用的协议。本节主要是讲如何将一组计算的证明转换为多项式进行证明。本文重点主要包括:多项式的算术性质,多项式插值等。
每周以太坊进展 2020-01-26
以太坊区块数据结构及以太坊的4棵数
既然决心要扩大知名度,那么免不了要偶尔蹭蹭热点,恰好我之前就已经给很多人说过Hotstuff,同时正好也在之前的专栏里介绍过BFT,所以正好可以顺理成章地讲一下LibraBFT。
发布 ~
本篇文章就来具体介绍 Runtime 编译成 wasm 所需要的条件
每周以太坊进展 2020-01-19
SDK 的 1.0 版本出炉~
上次我们讲到,比特币带来了一个新思路——用经济学和博弈论的原理约束节点,让他们不会作恶,于是整个问题重新回到了异步普通容错问题的轨道,于是整个问题的消息复杂度回到了O(N),即,可扩展。关于扩展性问题我们到以后的文章里再深入说,在这里我们只说它和O(N^2)消息复杂度的传统容错算法,例如PBFT,的最大区别。
我管拜占庭容错诞生直到比特币诞生这段时间内的所有BFT算法,包括像是后来诞生的但是还未受到比特币和区块链影响的BFT算法叫做传统BFT算法。这类算法包括著名的PBFT,也包括之前的不那么practical的BFT,和后PBFT时代中提出了“投机型”BFT的Zyzzyva。这类BFT算法的最大特点,就是他们并没有把区块链当做主要的应用场景(废话)。然后这类BFT算法我们又可以拿PBFT和Zyzzyva分成三个阶段。
译文:所有人都知道X是不够的。我们还需要所有人都知道所有人都知道X,以及所有人都知道所有人都知道所有人都知道X,就像是在拜占庭将军问题里的那样——这是个分布式数据处理中的经典的困难问题。
用户可能存在这两种情况:1. 用户将资产保存在以太坊钱包或链上其他地方,并希望与路印协议构建的交易所进行交互。2. 用户将资产保存在路印协议构建的交易所中,并希望在其他地方使用链上功能。
我们的目标之一是以最小的摩擦来弥补链上与链下之间的差距,以实现最佳的用户体验。
通过本文,你将学会:1\区块链应用和传统应用在数据存储层的不同之处;2\使用区块链进行数据存储时遇到的约束;3\Substrate可用的存储数据类型和使用方法。
在之前的文章 Substrate应用 - 抛硬币游戏(一),我们完成了runtime的开发,从而实现了一个自定义功能(即抛硬币游戏)的区块链网络。现在让我们来看一下如何编写测试代码和UI,你也可以直接看最终的模块代码和UI代码。
以太坊2.0:脱胎换骨迈向”世界计算机“之路
本文为tendermint paper: The latest gossip on BFT consensus的读书笔记, 本文旨在理清论文中所讲的BFT共识. 如果您在阅读过程中有任何意见可以发起ISSUE, 如果喜欢的话可以点击star.
star
智能合约语法层面漏洞详解
系列四 — 区块链中的BFT及HotStuff BFT(Libra BFT)分析
扫一扫 - 使用登链小程序
106 篇文章,294 学分
3 篇文章,269 学分
55 篇文章,237 学分
13 篇文章,206 学分
16 篇文章,163 学分