以太坊怎么开发

A. 如何基于ethereum开发区块链应用

目前实际动手做区块链开发，大致有两条路。

直接基于现成的区块链开发平台（主要是Ethereum和HyperLedger）来开发。山茄

自己从基础开始造区块链，表面上看，从开发效率、投入成本、产业合作等方面毫无疑问应该走第一条路，但搏档实际上情况要复杂得多。

区块链的发展，还是需要更多写代码的人实际参与，才能实实在在的推动。

现在整个技术社区的注意力主要还是在Web和移动开发逗银察上面，相关人才供销两旺。不过个别有心人已经开始转向大数据分析、深度学习、VR/AI这些前景看好的技术。

B. ETH开发实践——批量发送交易

在使用同一个地址连续发送交易时，每笔交易往往不可能立即到账， 当前交易还未到账的情况下，下一笔交易无论是通过 eth.getTransactionCount() 获取nonce值来设置，还是由节点自动从区块中查询，都会获得和前一笔交易同样的nonce值，这时节点就会报错 Error: replacement transaction underpriced

在构建一笔新的交易时，在交易数据结构中会产生一个nonce值， nonce是当前区块链下，发送者(from地址)发出的交易(成功记录进区块的)总数， 再加上1。例如新构建一笔从A发往B的交易，A地址之前的交易次数为10，那么这笔交易中的nonce则会设置成11， 节点验证通过后则会放入交易池（txPool）,并向其他节点广播，该笔交易等待矿工将其打包进新的区块。

那么，如果在先构建并发送了一笔从地址A发出的，nonce为11的交易，在该交易未打包进区块之前， 再次构建一笔从A发出的交易，并将它发送到节点，不管是先通过web3的eth.getTransactionCount(A)获取到的过往的交易数量，还是由节点自行填写nonce， 后面的这笔交易的nonce同样是11， 此时就出现了问题：

实际场景中，会有批量从一个地址发送交易的需求，首先这些操作可能也应该是并行的，我们不会等待一笔交易成功写入区块后再发起第二笔交易，那么此时有什么好的解决办法呢？先来看看geth节点中交易池对交易的处理流程

如之前所说，构建一笔交易时如果不手动设置nonce值，geth节点会默认计算发起地址此前最大nonce数（写入区块的才算数），然后将其加上1， 然后将这笔交易放入节点交易池中的pending队列，等到节点将其打包进区块。

构建交易时，nonce值是可以手动设置的，如果当前的nonce本应该设置成11， 但是我手动设置成了13， 在节点收到这笔交易时， 发现pending队列中并没有改地址下nonce为11及12的交易， 就会将这笔nonce为13的交易放入交易池的queued队列中。只有当前面的nonce补齐（nonce为11及12的交易被发现并放入pending队列）之后，才会将它放入pending队列中等待打包。

我们把pending队列中的交易视为可执行的，因为它们可能被矿工打包进最新的区块。 而queue队列因为前面的nonce存在缺失，暂时无法被矿工打包，称为不可执行交易。

那么实际开发中，批量从一个地址发送交易时，应该怎么办呢？

方案一：那么在批量从一个地址发送交易时， 可以持久化一个本地的nonce，构建交易时用本地的nonce去累加，逐一填充到后面的交易。（要注意本地的nonce可能会出现偏差，可能需要定期从区块中重新获取nonce，更新至本地）。这个方法也有一定的局限性，适合内部地址（即只有这个服务会使用该地址发送交易）。

说到这里还有个坑，许多人认为通过 eth.getTransactionCount(address, "pending") ，第二个参数为 pending ， 就能获得包含本地交易池pending队列的nonce值，但是实际情况并不是这样， 这里的 pending 只包含待放入打包区块的交易， 假设已写入交易区块的数量为20， 又发送了nonce为21，22，23的交易， 通过上面方法取得nonce可能是21（前面的21，22，23均未放入待打包区块）， 也可能是22（前面的21放入待打包区块了，但是22，23还未放入）。

方案二是每次构建交易时，从geth节点的pending队列取到最后一笔可执行交易的nonce, 在此基础上加1，再发送给节点。可以通过 txpool.content 或 txpool.inspect 来获得交易池列表，里面可以看到pending及queue的交易列表。

启动节点时，是可以设置交易池中的每个地址的pending队列的容量上限，queue队列的上容量上限， 以及整个交易池的pending队列和queue队列的容量上限。所以高并发的批量交易中，需要增加节点的交易池容量。

当然，除了扩大交易池，控制发送频率，更要设置合理的交易手续费，eth上交易写入区块的速度取决于手续费及eth网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。

C. EOS的开发流程

EOS的是Block.One主导研发的一个区块链底层公链系统，它专门为支撑商业去中心化 应用（Decentralized Application）而设计，其代码开源。

比特币被称为区块链1.0，因为它开辟了数字加密货币的天下，走出了从0到1的决定性一步。

以太坊被称为区块链2.0，因为它提供了可运行智能合约的图灵完备的虚拟机，带来了无限的可能性。

而EOS则被称为区块链3.0，为什么？ 两个字：性能。

EOS的定位正是其首页的口号：

英文：The most powerful infrastructure for decentralized applications。

中文：最强大的去中心化应用基础设施。

EOS期望做加强版的以太坊，一个高吞吐量的智能合约平台。

以太坊虽然功能齐备，但受制于其设计选择，15秒的出块速度导致交易吞吐量 远远不能达到大规模实用的程度，大约只有30~40TPS（交易/秒）。而EOS则选择了不同的技术路线，目标是达到可观的百万TPS——考虑到Visa实际的处理速度才1700TPS，这一目标的确相当诱人。

EOS的共识机制

比特币和以太坊之所以吞吐量这么低，是受制于其设想的应用场景以及针对该场景所选择的共识机制——这两者都假设系统运行的环境完全不可信，因此都采用了工作量证明（Proof of Work）这种共识机制。

共识，顾名思义，就是大家对某件事达成统一的认识——对于 区块链而言，某件事指的就是对交易的确认——任何一个节点要提交交易，都需要大家认可。

比特币和以太坊目前所采用的PoW机制是传奇人物中本聪的设计。在这种机制下，矿工们为了获得记账权和数字币奖励，需要不停挖矿来寻找合规的哈希值，通过对哈希值的共识来对交易数据进行确认和打包。PoW没有准入门槛，任何节点都 有平等的权利参与记账——当然，胜出的概率与算力有关：

RAM的价格是基于班科（Bancor）算法，也就是说是由市场供需调节的：如果RAM供不应求，则买入RAM时就需要更多的EOS通证，而这时卖出RAM也能获得更多的EOS通证。

内存是消耗资源，不可赎回，只能买卖。以EOS上发币为例，目前发币需要20M的内存，一个EOS可买20KB，按目前的存储价格发一个币需要消耗1000个EOS。这是EOS内存消耗的刚需来源。

课程概述

本课程面向对EOS去中心化应用开发感兴趣的朋友，课程内容涵盖EOS DApp开发的核心概念、智能合约的开发与部署以及前端页面与EOS区块链如何交互，并最终完成一个基于React和EOS的完整Dapp的开发。

第一章：进入EOS世界

了解EOS的定位与特点、共识机制、付费计算模型等核心概念。

第二章：Hi EOS

了解EOS节点的软件整体框架以及节点服务器、钱包服务器和命令行工具的作用， 学习配置、启动EOS节点服务器和钱包服务器的方法，初步了解命令行工具的使用方法。

第三章：钱包、密钥与账户

理解EOS中与个人身份相关的三个核心概念：钱包、密钥与账户，学习使用命令行工具 创建钱包、密钥与账户的方法。

第四章：智能合约的开发与交互

了解智能合约的概念与作用，学习EOS智能合约的编写和编译，学习使用命令行工具 部署合约并与合约交互。

了解EOS智能合约中状态的持久化机制，学习使用多索引表保存合约状态。

第五章：发行自己的代币

学习在EOS上发行代币的原理和实现机制，并通过实际操作，掌握如何 使用命令行工具进行代币的发行、转账和余额查看等操作。

第六章：使用代码与智能合约交互

理解应用与EOS区块链交互的原理，学习利用JSON RPC接口和eosjs封装库来 访问EOS区块链。

第七章：实战便签DApp开发

综合运用EOS知识，使用React完成一个EOS便签去中心化应用，学习从需求分析到 代码实现的完整过程。

eos开发还是需要一个完整的学习的，上面的课程地址如下：EOS教程

D. 以太坊是什么，谁创建的

以太坊（英文Ethereum）是一个开源的有智能合约功能的公共区块链平台，通过其专用加密货币以太币（Ether）提供去中心化的虚拟机（“以太虚拟机” Ethereum Virtual Machine）来处理点对点合约。
以太坊的概念首次在2013至2014年间由程序员Vitalik Buterin受比特币启发后提出，大意为“下一代加密货币与去中心化应用平台”，在2014年通过ICO众筹开始得以发展。
截至2018年2月，以太币是市值第二高的加密货币，仅次于比特币。

E. 如何开发数字货币

谢邀~

为何要开发数字货币?从中央银行的角度来看有6个好处：

第一、提升经济交易活动的便利性和透明度

第二、降低传统纸币发行、流通的高昂成本

第三、更好地支持经济和社会发展

第四、助力普惠金融的全面实现

第五、 减少洗钱、逃漏税等违法犯罪行为

第六、提升央行对货币供给和货币流通的控制力

数字货币开发步骤：

第一步、

首先我们要从git 上下载某套区块链体系的源码,比如选择比特币的主干代码下载好

相关源码。

同时准备好对应的编译环境(C + +的建议在Linux)和安装好对应开发环境和工具。

第二步、

代码都是需要编译的,因此需要准备编译环境和工具,需要下载环境编译工具、配

好系统环境变量, qt环境等文件,编译命令在Itc源代码里的文件里有详细说明。

不过系统和开发环境的搭建、程序编译等过程都比较繁琐,不建议普通用户自己制作。对于开发人员,第一次可能要预计2-3天的安装配置时间。

第三步、

拿比特币开发来说,他是Q的开发环境，下载好源码并配置好环境后,在QtCreator内打开该比特币核心的源码,配置相关文件和编译器,开始尝试编译比特币核心的客户端。

第四步、

改造成自己的数字货币，打开各个源文件,找到对应的地方调整参数即可,如调整

每个区块出币数,总产量,调整难度等等,然后就到最关键的点,就是改名为自己的币名。

想怎么取名就怎么取名,别忘记在资源文件夹里替换掉相关图标。如果一切顺利,经过重新

编译,你的新币就顺利发明了。

对于这个数字货币的开发,还是属于技术比较专业的,因此最好有-个专业的团队协助。

数字货币开发大致需要学习的框架：

1、搭建以太坊私链测试环境以及公链节点环境配置

2、以太坊中以太币的交易、确认原理

3、以太坊中json rpc接口

4、以太币转账与提现原理

5、服务器对接以太坊公链接口，自有服务器存储业务数据，公链存储交易可匿名数据

6、私钥的安全处理

以下是开发的代码示例：

举例下市场上常用的数字货币钱包有：

APP类：kcash、imtokenweb：myEthereumWalletgoogle 浏览器插件：metaMask

其中最常用的就是imToken

区块链交易技术概念：

让我们来看看区块链交易是如何以比特币为例进行处理的。为了将一定数量的比特币发送到另一个钱包，您需要以下信息：将资金发送到您的钱包的地址，您想要发送的加密货币数量

接收者的钱包的ID。

每笔交易都使用唯一的机密私人密钥进行签名。一旦付款由发件人签署，它就变为公开可用。交易仍需要确认，以便收款人可以得到这笔钱为了确认交易，有必要生成一个新的链条块。

这些块是通过进行复杂的数学计算来找到唯一的密钥而生成的。创建一个新块需要10分钟，找到该密钥的人获得一定数量的硬币作为奖励。一旦创建了链的新块，就不可能将其从数据库中删除或以某种方式更改信息。因此，区块链交易是最终且不可逆的。

数字货币的三大核心优点：

第一点、数字货币是公平的货币

数字货币没有特定的发行机构，不是由某一国家发行的，仅仅是依靠特定算法产生的，这就意味着无法通过操纵发行数量来操纵数字货币，因此数字货币是一种自由的、非国家的货币。

我们可以看到现在有许多国家是直接认可了虚拟货币，那么有需求，就需要交易的平台。

我们现在许多想搭建虚拟货币交易平台的投资者，为什么不能去这些地区搭建交易平台呢?搭建虚拟货币交易平台，这不就是一个很好的商机吗?

第二点、数字货币的安全系数更高

纸币的出现虽然方便了我们日常生活中的交易，但是会有被偷盗以及收到的风险。电子货币虽然可以避免这些风险，但是会出现诸如被盗刷、等新的问题。

数字货币则可以避免以上问题。并且将每一笔交易记录在网络上进行广播，是的所有节点都保存全部货币的流通信息，这样任意一个节点在交易之前就可以轻易地发现货币的流通。

第三点、数字货币的交易可以实现匿名交易

由于没有传统银行开户和身份认证的过程，数字货币是纯匿名的。虽然可以根据本地完整的交易记录查询到每个账号的流水信息。

但却无法知道这个账号的主人是谁，同样也没有任何人有能力操纵他人账号上的数字货币，这样很好的保护了使用人的隐私。

如果您也在持有交易数字货币、外汇黄金原油、合约期货：

F. 区块链和智能合约，以太坊开发，183位开发者整理，知识体系汇总

在以太坊上开发应用程序的可用工具、组件、模式和平台的指南。

此列表的创建是由 ConsenSys 的产品经理推动的，他们认为需要在新的和有经验的区块链开发人员之间更好地共享工具、开发模式和组件。

开发智能合约

智能合约语言

构架

IDE

其他工具

测试区块链网络

测试以太水龙头

前端以太坊 API

后端以太坊 API

引导程序/开箱即用工具

以太坊 ABI（应用程序二进制接口）工具

以太坊客户端

贮存

Mahuta - 具有附加搜索功能的 IPFS 存储服务，以前称为 IPFS-Store

OrbitDB - IPFS 之上的去中心化数据库

JS IPFS API - IPFS HTTP API 的客户端库，用 JavaScript 实现

TEMPORAL - 易于使用的 API 到 IPFS 和其他分布式/去中心化存储协议

PINATA - 使用 IPFS 的最简单方法

消息传递

测试工具

安全工具

监控

其他杂项工具

Cheshire - CryptoKitties API 和智能合约的本地沙箱实现，可作为 Truffle Box 使用

ERCs-以太坊评论请求存储库

ERC-20 - 可替代资产的原始令牌合约

ERC-721 - 不可替代资产的令牌标准

ERC-777 - 可替代资产的改进令牌标准

ERC-918 - 可开采令牌标准

流行的智能合约库

可扩展性

支付/状态通道

等离子体

侧链

POA桥

POA 桥用户界面

POA 桥梁合同

ZK-SNARK

ZK-STARK

预构建的 UI 组件

以上内容，来自git库：

github.com/ConsenSys/ethereum-developer-tools-list

我是鱼歌，一个在深圳创业的全栈程序员，主攻区块链，元宇宙和智能合约，附加小程序和app开发。

[祈祷]

G. 想在以太坊上发个币但不会写代码，这时该怎么发币

首先我可以很明确的告诉你：如果你本人不会写代码，并且不懂虚拟货币的发行方式，没有任何人可以教你，网上也没有相关的教程，因为虚拟货币的发售本身就属于违法行为。

其次，我也知道你在以太坊上发币是什么用途，无非就是做一个资金盘骗人罢了，奉劝你遵纪守法！因为公民发售虚拟货币做资金盘是严重的违法行为！

以太坊上面确实可以发行自己的虚拟货币。

不知道是不是最近的虚拟货币牛市把有些人炒傻了，还是有些人本身就是属于歪门邪道的人，竟然会在网上提问怎么在以太网上发售虚拟货币？我在看到这个问题的时候非常无语：一个想要做骗子的人竟然问别人怎么样实行自己的骗术，简直可笑。以太坊确实可以发售虚拟货币，但如果你连基本的发售虚拟货币的方式都不懂，你又怎么样谈你在以太坊上面的项目。

H. 以太坊是骗人的吗怎么做

以太坊并非骗局，但是不法分子围绕着以太坊设计的骗局数不胜数，规避以太坊骗局的最好方式就是，切莫轻信比人保证的投资收益率，管理好自己的钱袋子。选择正规的数字货币交易所，去做投资。目前市场上主流的数字货币交易所有币安、火币网、比特网等。

拓展资料
以太坊设计原则
简洁原则
以太坊协议将尽可能简单，即便以某些数据存储和时间上的低效为代价。一个普通的程序员也能够完美地去实现完整的开发说明。这将最终有助于降低任何特殊个人或精英团体可能对协议的影响并且推进以太坊作为对所有人开放的协议的应用前景。添加复杂性的优化将不会被接受，除非它们提供了非常根本性的益处。
通用原则
没有“特性”是以太坊设计哲学中的一个根本性部分。取而代之的是，以太坊提供了一个内部的图灵完备的脚本语言以供用户来构建任何可以精确定义的智能合约或交易类型。想建立一个全规模的守护程序（Daemon）或天网（Skynet），你可能需要几千个联锁合约并且确定慷慨地喂养它们，一切皆有可能。
模块化原则
以太坊的不同部分应被设计为尽可能模块化的和可分的。开发过程中，应该能够容易地让在协议某处做一个小改动的同时应用层却可以不加改动地继续正常运行。以太坊开发应该最大程度地做好这些事情以助益于整个加密货币生态系统，而不仅是自身。
无歧视原则
协议不应主动地试图限制或阻碍特定的类目或用法，协议中的所有监管机制都应被设计为直接监管危害，不应试图反对特定的不受欢迎的应用。人们甚至可以在以太坊之上运行一个无限循环脚本，只要他愿意为其支付按计算步骤计算的交易费用。

I. 以太坊智能合约开发：让合约接受转账

在以太坊智能合约开发中，通常会有向合约地址进行转账的需求，那么有几种向合约地址进行转账的方式呢？

有三种方式：

部署合约时转账

调用合约提供的方法

直接向合约地址进行转账

但有一个问题，以太坊的智能合约默认是拒绝来自任何地址的转账，那么如何让合约能够支持接收转账呢？

1、部署转账

在进行合约开发时，如果想要在部署时，直接向该合约进行转账，只需要给构造函数中添加payable修饰符。

示例：

2、执行合约转账

执行合约转账，则需要给你需要支持转账功能的方法添加payable修饰符

示例：

3、直接转账

支持直接转账，需要借助后备函数(fallback function)，只需要为后备函数添加 payable 修饰符

示例：

J. ETH开发实践——合约地址是怎么得来的

在把智能合约成功部署到ETH网络时，会得到合约地址，那么，这个合约地址是由什么决定的呢？合约地址由合约创建者的地址(sender address)和这笔部署交易中的nonce(发送者的累积交易次数)决定，将 sender 和 nonce 经过RLP编码后，再进行Keccak-256(SHA3)散列， 最后裁掉前面12个字节即得到合约地址。

example in js: