以太坊nodejs

A. 哪些银行已经实现区块链应用落地

之前每每提到去中心化应用，我们总是会会想到国外的产品，如以太坊，但是今天再谈到这个话题时我更多地会想到中国自己的Asch（阿希），基于侧链技术的新一代去中心化应用开发。

ASCH是一个去中心化的应用开发，同时它也是中国的第一个去中心化应用，它的目的是帮助开发者快速创建去中心化应用。该具有易用、灵活、安全等特点。
从模式上来说，它跟以太坊类似，都属于区块链服务，但实现机制大不相同。就拿以太坊来说它最大的特色就是是极大地扩展了这个脚本引擎的功能，加入了读取区块链、计 费、跳转等新指令，还解除了栈内存、函数调用深度以及脚本长度限制等。但这种方式 有一个很大的缺点就是，应用代码本身及应用产生的数据都存在同一个区块链中，造成了 区块链的快速膨胀。
但是ASCH则不同，它的扩展性不是通过交易脚本来实现，而是通过侧链。ASCH系统中存在一个主链和若干个侧链(主要由开发者提供)，但是每条链只支持有限的几种交易类型，交易或者合约的逻辑直接由宿主语言来编写，而不是由交易脚本。
这样的好处一是降低了合约编程的难度，二是避免了区块链膨胀，三是每种应用都可以定制个性化的区块链参数。

ASCH不会直接复制 Crypti（去中心化的,建立在区块链上的应用商店）或Lisk（它是新一代的，允许JavaScript的开发和基于分布的分散的应用程序使用一个易于使用的，功能齐全的生态系统。）， 但是会参考Crypti的架构，也会复用其部分代码，但不会太多。
不同点主要有两方面
更安全的共识算法，Crypti使用的是Dpos，我们在其上增加Pbft算法，以增强一致性，降低双重支付风险。
我们使用c++语言编写了部分关键模块，非性能热点的部分依旧使用Nodejs来写。

B. 使用Nodejs部署智能合约

实现智能合约的方式很多种，可以用truffle框架来实现，编译，部署。
这里介绍一种简单的使用nodejs来实现，编译，部署的方法。
创建一个nodejs项目，实现一个简单的智能合约。

这个合约实现了一个造币和转币的逻辑。
我们的合约是运行在evm上面的字节码，solidity是静态语言，需要通过编译器生成evm的字节码。

调用 node compile.js ,对BaseToken进行编译，生成字节码。web3中提供了一个部署合约的接口，使用如下，

利用编译生成的abi和bytecode，创建一个合约对象，然后进行发布，等待着异步执行的方法输出合约地址 contractAddress ，这样就完成了部署。不过这种方式有一个问题，就是在发布合约时，你的私钥处于联网状态，
处于安全策略，我们需要尽量避免私钥在联网状态。

以太坊上部署合约是向空地址发送一个附有字节码的签名交易，其中发送者就是这个合约的拥有者。因此我们只需要将合约构建成一笔交易，我们在无网状态下对这笔交易进行签名，然后将签名发送到以太坊网络中。这样能够降低我们私钥被泄漏的风险。
对合约的签名方法如下：

以上对一个合约签名，这里需要注意的问题是，to的地址需要是，空地址。
完成签名之后，我们把这笔交易发送出去就好，最简单的方法就是使用 etherscan的发送Tx的方式 ，一旦发送完成，部署完成，就可以看到合约地址。

C. 使用Web3J与第三方合约交互——批量转账

之前使用NodeJs与智能合约交互，都是访问的自己部署的合约。最近要对线上第三方合约进行转账操作，人数比较多，一笔笔操作起来手指都点断了还容易出错。既然代币Token都遵守ERC20协议，肯定有统一的Transfer(转账)方法供客户端调用，那么编写程序实现自动转账应该可以实现，去查了相关资料发现web3j是不错的选择。

轻量级客户端与以太坊交互的Java库。

既然是调用第三方合约那么肯定需要知道合约地址，合约地址定义了到哪里去访问合约；
ABI（Application Binary Interface）: 应用程序二进制接口，定义了智能合约提供的方法功能

若是无法获取到ABI接口，也可以使用solc编译生产bin和abi文件。

(生产代理类时可以指定包路径和类名)

这样一来，便可以使用程序完成批量转账操作。

后来研究发现，使用NodeJs直接调用Web3也可以实现对应功能，不过还是对Java更熟悉一些，就采用了Java的方式。

D. 手机查node怎么查

可以打开cmd命令行，使用命令来查看。

具体步骤如下：
在开始菜单的搜索框中输入cmd，点击cmd.exe打开cmd命令行。
输入并执行node -v命令，就可查看到node的版本号，例如我的版本号就是10.4.1。
node是一个针对安卓手机的node.js框架。不需要手机ROOT。它将是Nodejs，为了做区块链相关，选择了以太坊通道平台。虽然互联网上的信息可以找到一些，但它十分混杂，充满了重复的错误，不够系统。

E. 目前国内有哪些区块链技术应用开发平台

所谓区块链技术，简称BT（Blockchain technology），也被称之为分布式账本技术，是一种互联网数据库技术，其特点是去中心化、公开透明，让每个人均可参与数据库记录。

F. 以太坊web3.sendRawTransaction离线签名交易

工作中需要复现短地址攻击和the重入攻击，重入攻击可以直接通过eth.sendTransaction和remix来发送交易，但是短地址攻击由于钱包和remix这些都对input做了长度检测，无法通过这些方式来复现，只能通过发离线签名交易来实现。

1.环境依赖：nodejs , keythereum , ethereumjs-common , ethereumjs-tx 。

2.进入Node控制台，获取相应账户私钥。

3.签名交易，进入Node,这里注意nonce问题，需要Nonce是实际可执行的nonce，Nonce不对会发送交易失败,关于如何获取input data网络比较多就不详述了。

4.遇到的坑，网络出来的步骤是有问题的或者过时了，当时是参考的这篇文章， https://www.freebuf.com/articles/blockchain-articles/199903.html
，在控制台通过eth.sendRawTransaction发送签名好的交易，我遇到了这个错误 ** sendRawTransaction invalid sender **

G. 区块链技术入门，涉及哪些编程语言

Go语言

Go语言（Golang）是谷歌2009年推出的一种全新的编程语言，可以在不损失应用程序性能的情况下降低代码的复杂性。谷歌首席软件工程师罗布派克(Rob Pike)说：“我们之所以开发Go，是因为过去10多年间软件开发的难度令人沮丧。”

除比特币是由C++开发以外，目前最主流坊的客户端均有go语言开发，足以可见Go语言在整个区块链行业的地位。

C++

C++ 进一步扩充和完善了 C 语言，是一种面向对象的程序设计语言。C++ 可运行于多种平台上，如 Windows、MAC 操作系统以及 UNIX 的各种版本。C++是一种使用十分广泛的计算机程序设计语言。它是一种通用程序设计语言，支持多重编程模式，例如过程化程序设计、数据抽象、面向对象程序设计、泛型程序设计和设计模式等。

大多数的区块链企业都选择用C++编写区块链的底层，最著名的有比特币、ripple等，主要体现的是强计算性。

Java

Java不同于一般的编译语言或解释型语言。它首先将源代码编译成字节码，然后依赖各种不同平台上的虚拟机来解释执行字节码，从而实现了“一次编写，到处运行”的跨平台特性。而区块链项目的开发，对Java有着明显的依赖性。

其他的还有Python、系统架构、以太坊、Linux、hyperledger、JavaScript等都会有涉及。

H. 区块链之联盟链（三） 认识Fabric

Fabric 是超级账本联盟推出的核心区块链框架，它适合在复杂的企业内和企业间搭建联盟链。根据超级账本联盟的目标， Fabric 被建设为一个模块化的、支持可插拔组件的基础联盟链框架。；

与以太坊系的Quorum不同，Fabric从一开始就只考虑企业间的应用。其独有的channel概念，将企业根据业务目的不同以不同的子网连接起来， 每一个子网对应一个channel，而每个channel有自己独立的区块链。而Quorum很显然是只有一个公网（所有企业节点都加入进去），企业与企业间的私有业务是通过Private Manager 完成的。

理解channel的最简单方法就是，将它类比为一个消息服务提供的Topic，实际上Fabic最早就是基于Kafka 的分布式消息服务来实现。

       在Fabric网络中，一个企业可以有一个或多个节点加入整个联盟链；一个企业可以加入1个或者多个Channel（子网）；  一个节点可以加入1个或者多个channel。每个channel构成一个子网，所以Fabric 是 一种由子网组成的网络。

那么Fabric是怎么实现智能合约的执行和完成业务上链（将事务结果记录在区块链里）的呢？

与其它框架不同， Fabric 将整个过程分成了三个阶段：

业务背书阶段 ： 客户的请求发送的背书节点，通过智能合约完成业务的计算（但不更新状态），并完成背书；将背书结果返回个客户端。

业务的排序阶段 ： 客户端将背书结果通过Channel被发送到排序节点（orderer），在排序节点完成事务的排序，并打包到block里，最后下发给所有连接到channel的节点。

业务验证并写入账本阶段 : 通过Gossip 网络，所有Channel的节点都会接收到新的block，节点会验证block中的每一个事务，确定是否有效：有效地将会跟新world state，无效的将会标志为“无效”，不会更新World state，但整个block会被完整的加入到帐本中（包括无效的事务）。

根据以上的描述，Fabric 节点实际可以分为  ，普通节点和Order节点：

 Peer, 普通节点, 完成背书（包括只能合约的执行）和验证.

orderer,  排序节点，完成排序。

加入orderer节点的Fabric网络可以被描述如下：

每一个Channel，都定义了所有属于channel的节点，但是并不需要所有节点都连接到Orderer 节点（节点间可以通过gossip 协议通讯来传播私有数据或事务）.

       在区块链中，共识是区块链的基础。与公有链不同，联盟链的共识要求所有加入账本的事务是确定的、最终的，也就是不可以有分叉，区块与区块间的顺序是一定的，只存在唯一条链。在Fabric 中，这个客观需求正是由排序实现的，所有的事务将被提交给orderer节点获得确定的顺序，并最终打包成block进入帐本。 Fabric 从1.4.1开始支持基于Raft实现排序服务,  可以认为基于Raft实现共识。

基于RAFT的排序服务相对于早期的Kafka 具有更好的分布性，配置更加简单，是联盟链里常用的一个常用的达成共识的算法，Quorum就 默认使用RAFT作为共识层。简单的说，RAFT是一个leader和follower的模式， 所有加入RAFT网络的节点，任意时候都有一个leader,  只有这个leader有权决定事务的顺序，并打包成Block，其它节点只能作为follower提交事务和同步block。

基于FAFT网络，每个企业可以有一个或多个节点参与到Orderer中去。在Frabric中企业间的网络连接可以变化成如下形式：

       区块链的使用用户在以太网中被称作EOA（External of Account）, EOA的载体是钱包。我们沿用这个概念，来看看Fabric是如何实现用户和发起事务的。Fabric中EOA是一个CA中心发布的certificate（x.509），一个Certificate代表一个Identity（这与以太坊还是有很大区别的， 以太坊中一个EOA其实是一个hash地址），EOA能够参与的channel以及被授权的操作是有channel的MSP（ Membership Service  Provider）决定的（如下图）。

注：certificate 是一种密码学上验证身份的通用做法； certificate包含了个人的信息，公钥以及发布这个certificate的CA的签名。验证方只需要拥有这个CA的证书（包含CA的公钥），就可以验证这个签名是否正确，certificate的内容是否有篡改。简单的说，通过CA和Certificate，我们可以获得一个可验证的的身份和信任链。

      如上图，fabric中通要使用Wallet作为EOA的载体，一个Wallet中可以包含多个Identity（x.509 certificate）。 Identity 通过 CA提供的信任链来验证正确性。

  验证了身份之后， Fabric 通过MSP在区块链网络中解决该身份是否代表组织的成员和在组织内具有什么角色。例如，channel首先会验证当前用户Identity是否是有效地身份，然后通过MSP查看其所处的企业和具有的角色，最终确定该用户是否有权执行操作。

可以说，Fabric的访问控制是通过MSP来完成的。在每一个需要访问控制的地方都需要定义一个MSP。  例如，每个channel都定义一个MSP，这个MSP规定了在channel范围内资源的访问权限。 MSP 是Fabric里一个晦涩难懂的概念，也是其赋予企业间安全访问的基础。

前文提到， Fabric 将业务处理和上网分成了三个部分， 背书，排序，验证后加入账本。

其中背书是Fabric执行智能合约的阶段。以太坊中，智能合约是在EVM中执行的，有多种语言支持。 在Fabric，智能合约被称为chaincode： 一个chaincode 可以理解为是智能合约的容器，可以包含一个或多个智能合约， 不用于EVM, chaincode是在 JVM 或NodeJS中执行。

客户应用程序通过智能合约来访问账本，每一个可访问的智能合约都被安装在客户端可以访问的节点上，并被定义在channel里。（有只能合约的节点被称为背书节点，没有只能合约的节点被称未提交节点，提交节点只维护账本）

客户应用提交一个交易请求， 请求到达背书节点， 背书节点首先会验证客户的签名，确保客户的身份有权执行本次交易，接着执行交易提及的智能合约（chaincode），并生成一个背书响应（或者叫做交易提案，tran-proposal）。这个背书响应中通常包含World state 的读集合，写集合， 以及节点对本次交易的签名。这里与以太坊系联盟链最主要的不同是： 背书阶段只模拟交易，并不真正更新交易结果。 而真正更新交易在第三阶段完成。背书节点最后将生成的背书响应fanhui给客户端， 智能合约部分的执行就结束了。

通常一个交易的执行需要多方的签名，所以客户端需要将一个交易发送给多个背书节点，这些背书节点的选择需要满足背书策略的要求。

下图是一个包含有客户、背书节点，提交节点的网络示意图。

根据Fabric官方的参考文档，客户交易的正果过程可使用下图描述。

如上图，从1到3，为背书阶段，4为排序阶段，4.1,4,2, 5为验证提交阶段。 参考 Frabic的节点 概念，可以了解更多在交易细节的概念。  

总的来看， Fabric 更专注于企业间，通过上文，可以让大家对Fabric的基本构成与概念有一个总的了解。  Fabric本身并不神秘，都是使用的现有的企业间的技术。要更好的了解，建议参考阅读分布式消息系统和企业的安全基础设施（CA相关）的支持。与以太坊系联盟链实现比较，  Fabric 的子网更概念对于复杂企业间应用适应更强，但是其复杂的安全考量，使得运营成本很高，另外，Fabric 使用Certificate做为用户身份，有很大的局限性，在新的2.0里，Fabric对于此处将有所改变。

下一篇，我们将来看看Sawtooth , 由Inter 提供的区块链框架。

区块链之联盟链(一) 认识以太坊

区块链之联盟链(二) 认识Quotum

区块链之联盟链(三) 认识Fabric

区块链之联盟链(四) 认识Sawtooth