区块链中文技术社区 - OtherChain-优秀转载
type: channel
link: https://bcskill.com/index.php/category/OtherChain-优秀转载/
items: Cosmos之Tendermint架构分析
items: VRF可验证随机函数
items: Algorand 共识算法
items: zk-SNARKs 介绍（零知识证明概述以及如何将 zk-SNARK 集成到以太坊中）
items: 零知识证明：STARKs 与 SNARKs
items: 什么是 zk-SNARK？
items: node-sass安装失败的问题 stack Error: EACCES: permission denied, mkdir
items: Chia 可用节点地址
items: Chia(奇亚)相关技术调研
items: 基于Python的开源量化交易系统开发框架

Cosmos之Tendermint架构分析
type: item
date: 2022-11-30T19:29:25+08:00
description: 一、介绍 有人把Tendermint当成一个共识，有人把它当成一个通信组件。这都是可以理解的。Tendermint融合了共识和网络通信部分。它类似于一个软件包，通过使用Tendermint可以很容易的开发一个和Cosmos相兼容的区块链（当然，如果使用Cosmos-sdk会更简单，但是会屏蔽更多的细节）。可以把它理解成Cosmos的一个底层架构，提供类似于基础服务的一个平台。Tendermint可以提供一个Cosmos标准的跨链的基础应用。 通过上面这个图可以看出Tendermint在整个Cosmos生态中的位置。Tendermint Core是所有Cosmos生态中区块链的核心（上图中的淡绿色部分），提供了DPOS+BFT的共识机制。Cosmos Hub提供了不同区块链的之间的交互和价值转移。各个区块链应用之间通过IBC接口进行通信。 二、整体架构 1、BFT Tendermint使用的共识算法是拜占庭容错共识协议，它是来源于DLS共识算法。使用这种算法的目的是可以简单方便的解决区块链的分叉机制。这种BFT的机制要求有固定的一组验证人，然后他们会尝试在某个区块上达成共识。每个区块的共识轮流进行，每一轮都有一个提议者来发起区块，之后由验证人来决定是否接受区块或者进入下一轮投票。 Tendermint采用由绝对多数的选票（三分之二）待定的最优拜占庭算法。因此它可以确定的做到： 如果想做恶，必须要有三分之一以上的选票出现问题，并且提交了两个值。 如果任何验证组引起安全问题，就会被发现并对冲突进行投票，同时广播有问题的那些选票。 因为使用了BFT，所以其共识的速度在所有的共识中最相当快速的，很容易达到并维持每秒千笔交易的速度。 2、P2P Tendermint中的网络底层通信，使用的是一种普通的反应器，它通过参数来查找需要连接的P2P节点，在Tendermint的节点连接中，维护着两组映射来管理连接自己和自己连接的对象，分别称做inbound,outbound. outbound中，有两种连接，一种是连接时指定的seed,一种是在初始化时检测出来的节点。一般情况下，outbound的数量少于10个。而inbound控制在50个左右的连接。 既然是基于反应器的，那么编程的复杂性就大大降低了。只需要服务监听就可以了。这里不再细节赘述网络通信部分。 网络在启动时，会启动一个协程，定时轮询outbound的数量，来控制连接的稳定性。 3、架构 Tendermint的设计目的是为了创建一个统一的区块链开发的基础组件。通过将区块链中主要的P2P和共识抽象出来，实现区块链开发过程中的组件式管理。这样做的优势有以下几点： 一个是代码重用。对通用的网络通信和共识就不必再重复的造轮子。 二是解放了区块链编程的语言。比如以太坊用go,c++，但是通过Tendermint的抽象后，可以使用任何语言（觉得和当初JAVA才提出时一次编译的想法有些相似啊）。特别是对于智能合约，这个优点就更显得明显了。 4、Tendermint的共识过程 Tendermint共识机制中通过作验证人（Validators）来对区块达成共识，这个在前面已经介绍过，一组验证人负责对每一轮的新区块进行提议和投票。整个共识达成的过程如下图所示。 每一轮的开始（New Round），节点对新一轮的区块进行提议。之后，合格的提议区块首先经过一轮预投票（Prevote）。在提议区块获得2/3以上的投票后，进入下一轮的预认可（Precommit），同样是待获得2/3以上的验证人预认可后，被提议区块就正式获得了认可（Commit）。而得到认可的这个区块就被添加的到区块链中。 下面为详细的过程： 在Tendermint算法中，如果遇到对同一特定区块的同意及否决信息同时超过2/3的情况，需要启用外部的维护机制去核查是否存在超过1/3的验证节点伪造签名或者投出双重选票。 5、Tendermint的交易流程 当一个Tx进来时, Tmcore的mempool(MP)会通过mempool connection(一个socket连接，由abci-server提供)调用Application Logic(AL:也就是abci-app，我们自己用任何语言编写的APP逻辑)里的checkTx方法，AL向MP返回验证结果。MP根据验证结果通过或者拒绝该Tx。 Tendermint(TM)把tx暂存在内存池（mempool）里，并把这条Tx通过P2P网络复制给其它TM节点。TM发起了对这条Tx的拜占庭共识投票，所有Tendermint节点都参与了。投票过程分三轮，第一轮预投票（PreVote），超过2/3认可后进入第二轮预提交（PreCommit），超过2/3认可后进入最后一轮正式提交（Commit） TM提交Tx时依次通…

VRF可验证随机函数
type: item
date: 2021-10-21T16:22:15+08:00
description: Why VRF？ 场景 在区块链场景中，有的框架会用算法随机产生出块节点与验证节点（如Algorand），甚至解决分叉。按传统的随机算法，按一定的哈希规则随机轮询，选出一个节点来记账/验证。如果这个随机轮询的规则是谁都可以复现的，那么可以推测出将来的某个记账/验证节点，集中攻击它。 为了解决这个问题，就引入了VRF，只有自己能够完成这个哈希过程，而别人只能在他声明之后验证这个过程，防止有人可以提前推测出将来的记账节点。 POS中的权益研磨（Grinding） （以下来源于以太坊Github上的《Proof of Stake FAQ》） 在任何基于区块链的权益证明算法中，都需要某种机制，来随机从当前活跃验证者集合中选择能够产生下一个区块的验证者。举个例子，如果当前活跃的验证者集合由持有40以太币的Alice，持有30以太币的Bob，持有20以太币的Charlie与持有10以太币的David组成，那么你想让Alice成为下一个区块的创建者的概率为40%，而Bob的概率为30%等（在实践中，不仅要随机选择一个验证者，而是要（随机产生）一个无限验证者序列，只有这样如果Alice不在线的时候，就可以有其他人在过段时间替代她，但是这并没有改变问题的本质）。在非基于区块链的算法中，出于不同的原因也经常需要考虑随机性。 （以下来源Ouroboros白皮书《Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol》） 基于PoS的区块链协议最基本的一个问题就是模拟领导者选举过程。为了在股东们之间的选举达到一个真正的随机性，系统中就必须要引入熵(entropy)，但引入熵的机制可能会容易被敌手操作。例如，一个控制一群股东的敌手可能会试图模拟协议的执行，尝试不同的股东参与者的顺序以此来找到对敌对股东有力的继续者。这会导致一个叫做"grinding"的致命弱点，敌对参与者可能会使用计算资源来倾斜领导者选举。 VRF的目的 VRF的目的就是要生成随机值，且无法被预测，同时还要可验证，可重放。 VRF是什么? VRF是可验证随机函数(verifiable random function)，一方面具有伪随机性，另一方面它还具有可验证性(输出包括一个非交互零知识证明) 伪随机性 可验证性 VRF的方式是，实现本地抽签，各个节点自己抽签，如果抽中了之后，大家可以很容易地验证这个结果确实是你生成的。 eg. 假设现在是round 10（第10 轮），节点们可能会轮流抽签，以节点自己的私钥+ 一个全网都知道的随机数（比如是这轮的轮次10）作为输入，生成了一个随机数（0-100）；设置一个条件：100 个节点轮流抽签，谁先抽出来的随机数大于10，就是这一轮的打包者。假设5 号节点抽到了11，可是只有5 号知道其他人不知道，因此他在广播这个随机的同时还需要广播一个零知识证明。通过零知识证明，全网只需要通过5 号的公钥就可以验证，接受5 号为这轮打包者。图解如下： VRF具体的操作流程？ 证明者生成一对密钥，PK、SK； 证明者计算result = VRF_Hash（SK，info），proof = VRF_Proof（SK，info）； 证明者把result，proof，PK递交给验证者； 验证者计算result = VRF_P2H（proof)，True/False = VRF_Verify(PK, info, proof) True表示验证通过，False表示验证未通过。所谓的验证通过，就是指proof是否是通过info生成的，通过proof是否可以计算出result，从而推导出info和result是否对应匹配、证明者给出的材料是否有问题。 抽签有没有必要用VRF？ 相比随机预言机 普通哈希Hash(a)=b，所有人都可以重现，检验正确性； VRF是Hash(SIG(sk, a))=b，别人无法复现这个过程。但是可以拿b，pk，和中间信息验证b是跟a对应的。相比非对称加密 在密码学签名算法中，大都会引入随机性，也就是对相同信息的多次签名会得到不同的签名值，因此矿工可以不断对相同的输入SK和block，计算签名，以满足结果小于D。那么理论上任何人都会成为出块者，只要计算足够多次的签名。 有些非对称加密方式得到的随机数不是均匀分布的，如RSA 缺乏零知识，不管使用确定性签名还是随机性签名，都存在个安全隐患。就是一旦将自己的出块凭证公布，任何人都可以公开验证，包括攻击者。那么攻击者可以对出块节点进行攻击，使其不能出块。使用VRFs的方式，矿工只需要公布自己的R表明自己的出块权，当出完块的时候再公布P，那么攻击者就无法在出块之前知道谁具有出块权，因此也就无法实施针对性的攻击。 应用 Consensus…

Algorand 共识算法
type: item
date: 2021-10-12T10:38:45+08:00
description: 2018年是公链技术爆发的一年，诞生了诸多从共识方面创新的项目。由于目前人们普遍认为存在区块链“不可能三角”，这些共识往往要在性能、安全、去中心化、激励机制中做出取舍。例如，EOS达成每秒数千次交易速度是以牺牲去中心化为前提的。然而“不可能三角”从来没有像FLP、CAP这些分布式系统定理一样得到严谨的数学证明，因此有些人认为打破“不可能三角”是有可能的。可验证随机函数VRF被认为是一个有前景的方向。本次为大家带来最近热度非常高的Algorand项目的分析。 1、Algorand共识算法简介 Algorand共识算法是图灵奖获得者Silvio Micali在2017年底提出。Michali是MIT的教授，是一位密码学家和计算机理论学家，在伪随机数以及零知识证明领域很有名。 Algorand共识算法的论文的下载地址：https://people.csail.mit.edu/nickolai/papers/gilad-algorand.pdf Algorand采用了VRF函数，并结合账户的余额比例，随机确定区块生成以及投票人角色。 所谓VRF（Verifiable Random Function）就是可验证随机函数。 随机数对于区块链技术来说很关键。 本质上，分布式账本的核心问题就是随机选择出块人的问题，这个随机性要能被全网确认，并且不能被操控，也不能被预测， 否则恶意节点通过操控这个随机数就可以操控长链，从而实现双花攻击。 PoW的方案是让大家进行算力竞赛，设置一个计算哈希的难题，谁先算出来谁赢，算力高的赢的概率高，算力低的赢的概率低，以这样的方式保证胜出者是随机的。投入的算力能够体现在哈希值上， 这样全网能够验证，并选择包含最多算力的那条链。恶意节点只能通过提升自己的算力来增加攻击成功的概率。 PoS的方案是选举，大家不用浪费电力去进行算力竞赛，而是文明一点，随机选举一个节点来出块，并且被选中的概率和它拥有的份额相关。 如果“随机”这一步没有问题的话，恶意节点只能通过增加自己的份额，增加自己被选中的概率，从而增加双花攻击的成功概率。 这里有一点比PoW的方案要好就是，要实现攻击，先得成为持币大户，如果攻击成功币价大跌，攻击者也会承受最大的损失。 那么接下来的核心问题就是，这个不能被操控不能被预测的随机数从哪来。传统地PoS方案尝试从链上现有的数据入手，比如使用上一个区块的哈希值，上一个区块的时间戳等等来作为随机数的来源，但这些会带来额外的安全风险。 因为区块本身的信息就是节点写进去的，然后又要根据里面的信息来选举后续的出块者，存在循环论证的嫌疑，安全性不会太好。 这也是传统地认为PoS方案不如PoW可靠的部分原因。 Algorand提出的VRF能够由私钥( SK )以及讯息( X )产生一组可验证的伪随机 (pseudorandom) 数Y以及证明 ⍴。任何人都可以透过Verify函数来检验这个随机字串是否真的是该公钥对应私钥持有者，依照规定使用Evaluate函数所产生，而不是自己乱掰的。更详细一点的VRF三个函示描述如下： •Keygen(r) → (VK, SK). On a random input, the key generation algorithm produces a verification key VK and a secret key SK pair. •Evaluate(SK, X) → (Y, ⍴) . The evaluation algorithm takes as input the secret key SK , a message X and produces a pseudorandom output string Yand a proof ⍴ . •Verify(VK, X, Y, ⍴) → 0/1 . The verification algorithm takes as input the verification key VK , the message X , the output Y, and the proof ⍴ . It outputs 1 if and only if it verifies that Y is the output produced by the evaluation algorithm on inputs SK and X . 为什么我们需要这么一个大家自己产生，却又要可以被验证的随机字串产生器呢？这是因为在Algorand的拜占庭演算法中，虽然也存在着每一轮不同的区块生产者(称为Leader)以及验证委员会(Committee, Verifiers)，但并不是用「公开选举」的方式来选的，而是透过每个使用者自己对奖的方式来看看自己是不是下一轮的Le…

zk-SNARKs 介绍（零知识证明概述以及如何将 zk-SNARK 集成到以太坊中）
type: item
date: 2021-08-25T11:33:00+08:00
description: 在这篇文章中，我们旨在从实用的角度概述 zk-SNARK。我们会将实际的数学视为一个黑匣子，并尝试围绕如何使用它们建立一些直觉。我们还将给出最近在以太坊中集成 zk-SNARKs 的工作的简单应用。 零知识证明 零知识证明的目标是让验证者能够说服自己，证明者拥有秘密参数的知识，称为见证，满足某种关系，而不会将见证透露给验证者或其他任何人。 我们可以更具体地将其理解为有一个程序，表示为C，接受两个输入：C(x, w)。输入x是公开输入，w是秘密见证输入。该程序的输出是布尔值，即，或者true或false。然后给目标一个特定的公共输入x，证明证明者知道一个秘密输入w，使得C(x,w) == true。 我们将专门讨论非交互式零知识证明。这意味着证明本身是一组数据，无需证明者的任何交互即可对其进行验证。 示例程序 假设 Bob 得到了H某个值的散列，他希望有一个证明 Alice 知道s散列到的值H。通常 Alice 会通过给sBob来证明这一点，之后 Bob 会计算哈希并检查它是否等于H。 但是，假设 Alice 不想向sBob透露该值，而只是想证明她知道该值。她可以为此使用 zk-SNARK。 我们可以使用以下程序来描述 Alice 的场景，这里编写为一个 Javascript 函数： function C(x, w) { return ( sha256(w) == x );} 换句话说：程序接受一个公共散列x和一个秘密值w，true如果w等于SHA-256 散列，则返回x。 使用函数翻译 Alice 的问题，C(x,w)我们看到 Alice 需要创建一个证明，证明她拥有s这样的C(H, s) == true，而不必透露s。这是 zk-SNARKs 解决的一般问题。 zk-SNARK 的定义 甲 ZK-SNARK 包括三个算法 G, P, V 定义如下： 该 密钥生成器 G 需要一个秘密参数 lambda 和程序 C，并产生两个公开可用的按键， 证明键 pk，和一个 验证密钥 vk。这些密钥是公共参数，只需为给定程序生成一次 C。 该 证明 P 作为输入的证明键 pk，公共投入 x 和私人见证 w。该算法生成 证明 prf = P(pk, x, w) 者知道证人 w 并且证人满足程序的证明。 该 验证 V 单位计算 V(vk, x, prf) 其回报率 true ，如果证明是正确的， false 否则。因此，如果证明者知道w 满足 的证人，则此函数返回真 C(x,w) == true。 这里注意lambda 生成器中使用的秘密参数 。该参数有时会使在实际应用中使用 zk-SNARK 变得棘手。这样做的原因是任何知道这个参数的人都可以生成假证明。具体来说，给定任何程序 C 和公共输入， x 一个知道的人 lambda 可以生成一个证明 fake_prf ，以便 V(vk, x, fake_prf) 在true 不知道秘密的情况下 评估为 w。 因此，实际运行生成器需要一个非常安全的过程，以确保没有人知道并将参数保存在任何地方。这就是 Zcash 团队为了生成证明密钥和验证密钥而进行极其复杂的仪式的原因 ，同时确保“有毒废物”参数 lambda 在此过程中被销毁。 我们示例程序的 zk-SNARK Alice 和 Bob 在实践中如何使用 zk-SNARK 来让 Alice 证明她知道上面例子中的秘密值？ 首先，如上所述，我们将使用由以下函数定义的程序： function C(x, w) { return ( sha256(w) == x ); } 第一步是让 Bob 运行生成器 G 以创建证明密钥 pk 和验证密钥 vk。首先，随机生成 lambda 并将其用作输入： (pk, vk) = G(C, lambda) 小心处理参数 lambda，因为如果 Alice 了解 lambda 的值，她将能够创建假证明。Bob 将与 Alice 共享 pk 和 vk。 Alice 现在将扮演证明者的角色。她需要证明她知道哈希到已知哈希 H 的值 s。 她使用输入 pk、H 和 s 运行证明算法 P 以生成证明 prf： prf = P(pk, H, s) 接下来 Alice 向 Bob 提供证明 prf，Bob 运行验证函数 V(vk, H, prf)，在这种情况下会返回 true，因为 Alice 正确地知道秘密 s。Bob 可以确信 Alice 知道这个秘密，但 Alice 不需要向 Bob 透露秘密。 可重复使用的证明和验证密钥 在我们上面的例子中，如果 Bob 想向 Alice 证明他知道一个秘密，则不能使用 zk-SNARK，因为 Alice 无法知道 Bob 没有保存 lambda 参数。鲍勃可能能够伪造证明。 如果一个程序对很多…

零知识证明：STARKs 与 SNARKs
type: item
date: 2021-08-25T11:15:00+08:00
description: 新技术之间的冲突 纵观历史，总是有类似的技术大约在同一时间进入市场，寻求类似的结果，但以不同的方式解决问题。当这种市场现象发生时，采用者应该尝试客观地评估每一项技术。 由于 STARK 阵营和 SNARK 阵营都对各自的技术充满热情，我们认为对这两种技术进行客观比较会很有趣。 STARKs 与 SNARKs 快速复习一下，零知识证明技术使一方能够向另一方证明他们知道某些事情，而证明者不必自己传达信息来证明他们的知识。它们既是一种隐私增强技术，因为它们减少了用户之间需要提供的信息量，又是一种扩展技术，因为它们可以允许以更快的速度验证证明，因为它们不包含全部信息非私有系统的信息。 当今市场上最引人注目的两种零知识技术是 zk-STARKs 和 zk-SNARKs。两者都是双方证明知识的方法的首字母缩写词：zk-STARK代表零知识可扩展的透明知识论证，zk-SNARK代表零知识简洁非交互式知识论证。本文将深入探讨从文化和技术的角度分析这两种不同的零知识技术之间的核心差异。此外，这两种零知识技术本质上都是非交互式的，这意味着代码可以部署并自主运行。 下面，我们有几个表格描述了两种技术之间的一些高级差异。我们还将深入研究段落格式的差异。 资料来源：物质实验室 SNARK 2012 年 1 月，加州大学伯克利分校一位名叫 Alessandro Chiesa 的教授与人合着了一篇论文，为他们首次构建的零知识证明创造了术语 zk-SNARK。Zk-SNARK 在其基础上依赖于椭圆曲线来保证安全性。密码学中的椭圆曲线在基本假设下运行，即找到相对于公知基点的随机椭圆曲线元素的离散对数是不可行的。 虽然关于椭圆曲线随机数生成器是否存在后门一直存在很大争议，但整个算法通常仍然是安全的。尽管侧信道攻击中有几个流行的漏洞，但可以通过多种技术轻松缓解。量子攻击确实笼罩在基于椭圆曲线的密码学上，但打破其安全模型所需的量子计算尚未广泛应用。 除了基于椭圆曲线之外，zk-SNARK 还需要可信设置。可信设置是指密钥的初始创建事件，用于创建私人交易所需的证明以及这些证明的验证。最初，当这些密钥被创建时，在验证密钥和发送私人交易的密钥之间有一个隐藏的参数链接。如果用于在可信设置事件中创建这些密钥的秘密没有被破坏，则可以利用这些秘密通过虚假验证来伪造交易，从而使持有者能够执行诸如凭空创建新令牌并使用它们等操作用于交易。由于 zk-SNARKs 的隐私特性，将无法验证凭空创建的代币实际上是凭空创造。话虽如此，信任设置仅在最初需要 因此，基于 SNARK 的网络的用户必须依赖于正确执行可信设置的事实，这意味着与可信设置密钥相关的秘密已被销毁，并且不会由监督仪式的个人持有。对可信设置的依赖一直是 SNARK 批评者最关注的领域之一。话虽如此，开发人员只需要最初使用可信设置，而不是持续使用。 SNARK 的另一个重要批评领域是它们不具有量子抗性。一旦量子计算在很大程度上可用，SNARKs 背后的隐私技术将被打破。当然，SNARKs 的支持者正确地指出，当使用量子计算机时，我们将面临更多问题，例如破坏 RSA 和大多数钱包基础设施。 话虽如此，尽管存在与可信设置相关的问题，但实际上 SNARK 的采用速度比 STARK 快得多的原因有很多。SNARKs 比 STARKs 早几年被发现，这使该技术在采用方面取得了重要的领先优势。Zcash 是较早的数字资产项目之一，它在区块链开发社区中普及了 SNARK 的使用。由于 Zcash 和其他 SNARKs 的采用者，SNARKs 拥有最多的开发人员库、已发布的代码、项目和积极致力于该技术的开发人员。除了 Zcash，新兴的 DEX Loopring 也使用了 SNARK。如果开发人员想开始使用零知识技术，他们在使用 SNARK 方面将比 STARK 获得更多支持。 此外，据估计 SNARK仅需要 STARK 所需气体的 24%，这意味着与 SNARK 进行交易对最终用户来说要便宜得多。最后，SNARKs 的证明大小比 STARKs 小得多，这意味着它需要更少的链上存储。 STARKs 虽然 SNARKs 在文档和开发人员支持方面比 STARKs 有一些明显的优势，但 STARKs 确实提供了一些独特的好处。但首先，让我们从技术角度深入了解 STARK 是什么。 Eli Ben-Sasson、Iddo Bentov、Yinon Horeshy 和 Michael Riabzev 在2018 年撰写了第一篇描述 STARK 的论文。与 SNARK 不同，STARK 的基础技术依赖于哈希函数。马上，依靠散列函数提供了一些好处，例如抗量子。此外，开始在网络中使用 STARK 不需要可信设置。 话虽如此，STARKs 的证明尺寸远大于 SNA…

什么是 zk-SNARK？
type: item
date: 2021-08-25T10:16:00+08:00
description: Zcash 是 zk-SNARKs 的第一个广泛应用，zk-SNARKs 是一种新颖的零知识密码学形式。Zcash 强大的隐私保证源于这样一个事实，即 Zcash 中的屏蔽交易可以在区块链上完全加密，但仍然可以通过使用 zk-SNARK 证明在网络的共识规则下验证其有效性。 首字母缩略词 zk-SNARK 代表“零知识简洁的非交互式知识论证”，指的是一种证明结构，在这种结构中，人们可以证明拥有某些信息，例如一个秘密密钥，而无需透露该信息，并且之间没有任何交互证明者和验证者。 “零知识”证明允许一方（证明者）向另一方（验证者）证明一个陈述是真实的，而不会透露超出陈述本身有效性的任何信息。例如，给定一个随机数的散列，证明者可以说服验证者确实存在一个具有该散列值的数字，而无需透露它是什么。 在零知识“知识证明”中，证明者不仅可以说服验证者该数字存在，而且他们实际上知道这样一个数字——同样，无需透露有关该数字的任何信息。“Proof”和“Argument”之间的区别是非常技术性的，我们不在这里讨论。 “简洁”的零知识证明可以在几毫秒内得到验证，即使是关于非常大的程序的语句，证明长度也只有几百字节。在第一个零知识协议中，证明者和验证者必须来回通信多轮，但在“非交互式”结构中，证明由从证明者发送到验证者的单个消息组成。目前，生成非交互式且足够短以发布到区块链的零知识证明的最有效的已知方法是具有初始设置阶段，该阶段生成在证明者和验证者之间共享的公共参考字符串。我们将这个公共引用字符串称为系统的公共参数。 如果有人可以访问用于生成这些参数的秘密随机性，他们将能够创建对验证者来说看起来有效的虚假证明。对于 Zcash，这意味着恶意方可以制造假币。为了防止这种情况发生，Zcash 通过精心设计的多方仪式生成了公共参数。要了解有关我们的参数生成仪式的更多信息，并查看我们为防止暴露 Zcash 所必需的秘密随机性（例如，计算机被喷灯）而采取的预防措施，请访问我们的Paramgen 页面。要了解有关参数生成协议背后的数学原理的更多信息，请阅读我们关于该主题的博客文章或白皮书 ( 1 , 2 )。 如何在 Zcash 中构建 zk-SNARK 为了在 Zcash 中实现零知识隐私，根据网络的共识规则确定交易有效性的函数必须返回交易是否有效的答案，而不会泄露其执行计算的任何信息。这是通过在 zk-SNARKs 中编码一些网络的共识规则来完成的。在高层次上，zk-SNARK 的工作原理是首先将您想要证明的内容转换为关于了解某些代数方程的解的等效形式。在下一节中，我们简要概述了如何将确定有效交易的规则转换为方程，然后可以对候选解决方案进行评估，而无需向验证方程的各方透露任何敏感信息。 Computation → Arithmetic Circuit → R1CS → QAP → zk-SNARK 将我们的交易有效性函数转化为数学表示的第一步是将逻辑步骤分解为尽可能小的操作，从而创建一个“算术电路”。类似于布尔电路，其中程序被编译成离散的单步，如 AND、OR、NOT，当程序被转换为算术电路时，它被分解为由加法、减法等基本算术运算组成的单步，乘法和除法（尽管在我们的特殊情况下，我们将避免使用除法）。 以下是用于计算表达式 (a+b)(bc) 的算术电路的示例： 看看这样的电路，我们可以将输入值 a、b、c 视为在电线上从左到右“行进”到输出电线。我们的下一步是构建所谓的 1 级约束系统或 R1CS，以检查值是否“正确移动”。在这个例子中，R1CS 将确认，例如，从 b 和 c 进入的乘法门出来的值是 b*c。 在这个 R1CS 表示中，验证器必须检查许多约束——几乎电路的每条线路都有一个约束。（由于技术原因，事实证明我们只对来自乘法门的电线有约束。）在 2012 年关于该主题的论文中，Gennaro、Gentry、Parno 和 Raykova 提出了一种“将所有这些约束捆绑在一起”的好方法. 此方法使用称为二次算术程序 (QAP) 的电路表示。需要检查的单个约束现在在多项式之间而不是在数字之间。多项式可能非常大，但这没关系，因为当多项式之间不存在同一性时，它在大多数情况下都不会成立。因此，您只需检查两个多项式是否在随机选择的一个点上匹配 以便以高概率正确验证证明。 如果证明者事先知道验证者会选择检查哪一点，他们可能能够制作无效的多项式，但仍然满足该点的身份。与ZK-SNARKs，复杂的数学技术，如同态加密和配对的椭圆曲线的用于评价多项式“盲目地” -即在不知道哪个点正被评估。上面描述的公共参数用于确定将检查哪个点，但采用加密形式，以便证明者和验证者都不知道它是什么。 到目前为止的描述主要解决了如何获得“SNARKs”中的 S 和 N——如何获得一个简短的、非交…

node-sass安装失败的问题 stack Error: EACCES: permission denied, mkdir
type: item
date: 2021-08-19T11:29:07+08:00
description: sudo npm install -g node-sass --unsafe-perm=true --allow-root 参考 https://stackoverflow.com/questions/49679808/error-eacces-permission-denied-mkdir-usr-local-lib-node-modules-node-sass-b https://www.cnblogs.com/chrissong/p/10961521.html

Chia 可用节点地址
type: item
date: 2021-05-12T15:34:00+08:00
description: http://chia-ip.onepool.com/

Chia(奇亚)相关技术调研
type: item
date: 2021-04-14T12:37:26+08:00
description: P盘配置需求 CPU线程数>=P盘任务数2 (主频越高线程越多越快) 内存大小>=P盘任务数4.5G NVME固态硬盘（缓存盘）>=P盘任务数*332G (读写速度越大越快) 要加快P盘速度可以堆配置增加同时P盘任务数，或者用多台电脑。 P盘目录不能为中文，过程中日志内没有error报错就是正常的，等待即可 Chia(奇亚)资料库 Chia(奇亚)官网 https://www.chia.net/ 区块浏览器 https://www.chiaexplorer.com/ Github源码库 https://github.com/Chia-Network Chia(奇亚)商业白皮书中文版 https://www.kuangjiwan.com/news/news-2883.html 技术绿皮书 https://www.chia.net/assets/ChiaGreenPaper.pdf Chia挖矿教程 https://www.kuangjiwan.com/news/news-2882.html Chia(奇亚)常见问题解答 https://www.kuangjiwan.com/news/news-2884.html Chia(奇亚)命令行参数 https://www.kuangjiwan.com/news/news-2886.html Chia(奇亚)plot文件规格大小 https://www.kuangjiwan.com/news/news-2887.html Chia减半计划表 https://www.kuangjiwan.com/news/news-2889.html Chia多机集群教程 https://www.kuangjiwan.com/news/news-2891.htm https://www.kuangjiwan.com/news/news-2882.html https://www.kuangjiwan.com/news/news-2887.html https://www.kuangjiwan.com/news/news-2891.html

基于Python的开源量化交易系统开发框架
type: item
date: 2020-12-18T18:00:27+08:00
description: 开源地址： https://github.com/vnpy/vnpy 功能特点 全功能量化交易平台（vnpy.trader），整合了多种交易接口，并针对具体策略算法和功能开发提供了简洁易用的API，用于快速构建交易员所需的量化交易应用。 覆盖国内外所有交易品种的交易接口（vnpy.gateway）： 国内市场 CTP（ctp）：国内期货、期权 CTP Mini（mini）：国内期货、期权 CTP证券（sopt）：ETF期权 飞马（femas）：国内期货 恒生UFT（uft）：国内期货、ETF期权 飞创证券（sec）：ETF期权 宽睿（oes）：国内证券（A股）、ETF期权 中泰XTP（xtp）：国内证券（A股）、ETF期权 恒生期权（hsoption）：ETF期权 华鑫奇点（tora）：国内证券（A股）、ETF期权 飞鼠（sgit）：黄金TD、国内期货 金仕达黄金（ksgold）：黄金TD 鑫管家（xgj）：期货资管 融航（rohon）：期货资管 中汇亿达（comstar）：银行间市场 海外市场 富途证券（futu）：港股、美股 老虎证券（tiger）：全球证券、期货、期权、外汇等 Interactive Brokers（ib）：全球证券、期货、期权、外汇等 易盛9.0外盘（tap）：全球期货 直达期货（da）：全球期货 MetaTrader 5（mt5）：外汇、CFD、期货、股票 Alpaca（alpaca）：美股（零佣金） 佳兆业投资（kasia）：港股 数字货币 BitMEX（bitmex）：数字货币期货、期权、永续合约 Bybit（bybit）：数字货币永续合约 币安（binance）：数字货币现货 币安永续（binances)：数字货币永续合约 OKEX（okex）：数字货币现货 OKEX永续（okexs）：数字货币永续合约 OKEX期货（okexf）：数字货币期货 OKEX期权（okexo）：数字货币期权 火币（huobi）：数字货币现货 火币期货（huobif）：数字货币期货 火币永续（huobis）：数字货币永续 火币期权（huobio）：数字货币期权 Gate.io永续（gateios）：数字货币永续合约 Deribit（deribit），数字货币期权、永续合约 Bitfinex（bitfinex）：数字货币现货 Coinbase（coinbase）：数字货币现货 Bitstamp（bitstamp）：数字货币现货 1Token（onetoken）：数字货币券商（现货、期货） 特殊应用 RPC服务（rpc）：跨进程通讯接口，用于分布式架构 开箱即用的各类量化策略交易应用（vnpy.app）： cta_strategy：CTA策略引擎模块，在保持易用性的同时，允许用户针对CTA类策略运行过程中委托的报撤行为进行细粒度控制（降低交易滑点、实现高频策略） cta_backtester：CTA策略回测模块，无需使用Jupyter Notebook，直接使用图形界面直接进行策略回测分析、参数优化等相关工作 spread_trading：价差交易模块，支持自定义价差，实时计算价差行情和持仓，支持半自动价差算法交易以及全自动价差策略交易两种模式 option_master：期权交易模块，针对国内期权市场设计，支持多种期权定价模型、隐含波动率曲面计算、希腊值风险跟踪等功能 portfolio_strategy：组合策略模块，面向同时交易多合约的量化策略（Alpha、期权套利等），提供历史数据回测和实盘自动交易功能 algo_trading：算法交易模块，提供多种常用的智能交易算法：TWAP、Sniper、Iceberg、BestLimit等，支持对接外部智能算法交易服务（如金纳算法） script_trader：脚本策略模块，针对多标的组合类交易策略设计，同时也可以直接在命令行中实现REPL指令形式的交易，不支持回测功能 market_radar：市场雷达模块，允许用户基于自定义的公式实时计算任意合约组合数据，公式支持标准Python运算语法以及内置函数 paper_account：模拟交易模块，纯本地化实现的模拟交易功能，基于交易接口获取的实时行情进行委托撮合，提供委托成交推送以及持仓记录 chart_wizard：K线图表模块，基于RQData数据服务（期货）或者交易接口（数字货币）获取历史数据，并结合Tick推送显示实时行情变化 portfolio_manager：投资组合模块，面向各类基本面交易策略，以独立的策略子账户为基础，提供交易仓位的自动跟踪以及盈亏实时统计功能 rpc_service：RPC服务模块，允许将某一VN Trader进程启动为服务端，作为统一的行情和交易路由通道，允许多客户端同时连接，实现多进程分…