web3ethsubscribe
㈠ Python3 使用Web3.py查询以太坊账户余额
from web3 import Web3
def QuerryBalanceETH(accounts):
w3 = Web3(Web3.HTTPProvider('https://mainnet. infura .io/v3/ {此处设置自己托管账户ID} '))
#accounts = w3.eth.accounts
balance = w3.eth.getBalance(accounts,'latest')#latest表示使用区块链中最后一个块的状态,也就是最后的余额
print('balance@latest => {0}'.format(balance))
return balance
1、什么是Infura?
专业一点讲,Infura是一种IaaS(Infrastructure as a Service)产品,目的是为了降低访问以太坊数据的门槛。
通俗一点讲,Infura就是一个可以让你的dApp快速接入以太坊的平台,不需要本地运行以太坊节点。
从程序员的角度讲,Infura就是一个Web3 Provider,背后是负载均衡的API节点集群。使用它的好处就是,你永远不必担心连接的节点失效的问题,Infura会管理好这一切。
除此之外,Infura还可以很方便地接入IPFS,这是另外一个话题,这里就不讨论了。
最后,也是非常重要的一点:Infura目前是免费的。
2、如何使用Infura?
使用Infura首先需要注册一个账户,访问官网 https://infura.io ,点击注册并提供一个邮箱,会收到一封邮件,点击邮件中的链接激活就可以了,然后你就会看到下面的界面:
点击右上角的黑色按钮,创建新项目,就可以生成你专属的Project ID了(左边的红框)。
参考文章: https://blog.csdn.net/TurkeyCock/article/details/85103434
㈡ 以太坊中的国际银行账号iban
简单地说,以太坊中的iban账号是以太坊为了和传统的银行系统对接而引入的概念,web3.js中提供了以太坊地址和iban地址之间的转换方法。
iban这个概念源于传统的银行系统,其英文全称为 International Bank Account Number ,即国际银行帐号。iban的作用是为全球任意一家银行中的任意一个账户生成一个全球唯一的账号,以便进行跨行交易。一个iban账号看起来像这样:
iban地址最多可以包含34个字母和数字,其中的字母大小写不敏感。在iban
中包含以下信息:
以太坊引入了一个新的IBAN国别码:XE,其中E代表Ethereum,X代表非法币(non-jurisdictional currencies)。同时,以太坊提出了三种BBAN的编码格式:direct、basic和indirect。
direct编码方案中的BBAN为30个字母/数字,只有一个字段:账户编号。例如,以太坊地址 转换为direct方案的BBAN账号,就得到 。
可以使用web3.js中的 web3.eth.Iban.fromEthereumAddress()
方法来执行这一转换:
basic编码方案与direct方案的唯一区别在于,其BBAN长度为31个字母/数字,因此该方案不兼容IBAN。
indrect编码方案中的BBAN长度为16个字母/数字,包含三个字段:
例如,一个采用indrect编码方案的以太坊iban账号,看起来是这样:
前面的 XE 表示国别码, 81 为校验和,后面的16个字符就是indrect编码的BBAN,其中:
如前所述,使用 web3.eth.Iban.fromEthereumAddress() 方法,可以将一个以太坊地址转换为direct编码方案的iban账号。与之对应的,可以使用 web3.eth.Iban.toAddress 方法,将一个采用direct编码方案的iban账号,转换回以太坊地址。例如:
iban账号中的校验和用来帮助核验一个给定字符串是否为有效的iban账号。可以使用web3.js中的 web3.eth.Iban.isValid()
来进行执行校验。例如:
原文: http://blog.hubwiz.com/2018/06/03/ethereum-iban/
㈢ 【ETH钱包开发03】web3j转账ETH
在之前的文章中,讲解了创建、导出、导入钱包。
【ETH钱包开发01】创建、导出钱包
【ETH钱包开发02】导入钱包
本文主要讲解以太坊转账相关的一些知识。交易分为ETH转账和ERC-20 Token转账,本篇先讲一下ETH转账。
1、解锁账户发起交易。钱包keyStore文件保存在geth节点上,用户发起交易需要解锁账户,适用于中心化的交易所。
2、钱包文件离线签名发起交易。钱包keyStore文件保存在本地,用户使用密码+keystore的方式做离线交易签名来发起交易,适用于dapp,比如钱包。
本文主要讲一下第二种方式,也就是钱包离线签名转账的方式。
交易流程
1、通过keystore加载转账所需的凭证Credentials
2、创建一笔交易RawTransaction
3、使用Credentials对象对交易签名
4、发起交易
注意以下几点:
1、Credentials
这里,我是通过获取私钥的方式来加载 Credentials
还有另外一种方式,通过密码+钱包文件keystore方式来加载 Credentials
2、nonce
nonce是指发起交易的账户下的交易笔数,每一个账户nonce都是从0开始,当nonce为0的交易处理完之后,才会处理nonce为1的交易,并依次加1的交易才会被处理。
可以通过 eth_gettransactioncount 获取nonce
3、gasPrice和gasLimit
交易手续费由gasPrice 和gasLimit来决定,实际花费的交易手续费是 gasUsed * gasPrice 。所有这两个值你可以自定义,也可以使用系统参数获取当前两个值
关于 gas ,你可以参考我之前的一篇文章。
以太坊(ETH)GAS详解
gasPrice和gasLimit影响的是转账的速度,如果gas过低,矿工会最后才打包你的交易。在app中,通常给定一个默认值,并且允许用户自己选择手续费。
如果不需要自定义的话,还有一种方式来获取。获取以太坊网络最新一笔交易的 gasPrice ,转账的话, gasLimit 一般设置为21000就可以了。
Web3j还提供另外一种简单的方式来转账以太币,这种方式的好处是不需要管理nonce,不需要设置gasPrice和gasLimit,会自动获取最新一笔交易的gasPrice,gasLimit 为21000(转账一般设置成这个值就够用了)。
这个问题,我想是很多朋友所关心的吧。但是到目前为止,我还没有看到有讲解这方面的博客。
之前问过一些朋友,他们说可以通过区块号、区块哈希来判断,也可以通过Receipt日志来判断。但是经过我的一番尝试,只有 BlockHash 是可行的,在web3j中根据 blocknumber 和 transactionReceipt 都会报空指针异常。
原因大致是这样的:在发起一笔交易之后,会返回 txHash ,然后我们可以根据这个 txHash 去查询这笔交易相关的信息。但是刚发起交易的时候,由于手续费问题或者以太网络拥堵问题,会导致你的这笔交易还没有被矿工打包进区块,因此一开始是查不到的,通常需要几十秒甚至更长的时间才能获取到结果。我目前的解决方案是轮询的去刷 BlockHash ,一开始的时候 BlockHash 的值为0x00000000000,等到打包成功的时候就不再是0了。
这里我使用的是rxjava的方式去轮询刷的,5s刷新一次。
正常情况下,几十秒内就可以获取到区块信息了。
区块确认数=当前区块高度-交易被打包时的区块高度。
㈣ 欧易交易所怎么转账到web3
欧易交易所转账到web3方法步骤:
第一步:点击“转账汇款”-“境外外汇汇款”菜单,进入境外外汇汇款页面。
第二步:选择汇款账户及子账户,确认或修改汇款人拼音/英文名称,输入汇款人地址。
第三步:输入收款人账号、姓名、地址、开户行SWIFT代码或地区清算 代码+开户行名称+开户行地址(或调用“收款人名册”相关信息)。
第四步:输入汇款金额,选择收支申报交易编码,选择收款人常驻国家。确认或修改申请人手机号码。
第五步:点击“下一步”按钮,进入汇款信息确认界面。
第六步:确认汇款信息,点击“确认”按钮。验证网银安全工具。
验证通过,现实汇款受理成功页面。
㈤ 什么是Web3
中心化帮助数十亿人上网,并创建了稳定、强大的基础设施。与此同时,少数中心化实体在大片互联网上占有一席之地,单方面决定应该允许什么和不应该允许什么。
Web3 是解决这个难题的答案。Web3 不是由大型科技公司垄断的互联网,而是去中心化,并由其用户构建、运营和拥有。Web3 将权力掌握在个人而非公司手中。在讨论 Web3 之前,让我们先来看看我们是如何走到这一步的。
大多数人认为互联网是现代生活的持续支柱——它是被发明出来的,从那以后就一直存在。然而,我们大多数人今天所知道的互联网与最初想象的完全不同。为了更好地理解这一点,将互联网的短暂历史分成松散的时期是有帮助的——web 1.0 和 web 2.0。
1989 年,在日内瓦的 CERN,Tim Berners-Lee 正忙于开发后来成为互联网的协议。他的想法?创建开放的、分散的协议,允许从地球上的任何地方共享信息。
互联网的第一次诞生,现在被称为“Web 1.0”,大约发生在 1990 年到 2004 年之间。Web 1.0 上的互联网主要是公司拥有的静态网站,用户之间的互动几乎为零——个人很少生产内容——导致它被称为只读网络。
随着社交媒体平台的出现,Web 2.0 时期开始于 2004 年。Web 不再是只读的,而是演变为可读写的。公司不再向用户提供内容,而是开始提供平台来共享用户生成的内容并参与用户与用户的交互。随着越来越多的人上网,少数顶级公司开始控制网络上产生的不成比例的流量和价值。Web 2.0 也催生了广告驱动的收入模式。虽然用户可以创建内容,但他们并不拥有它或从它的货币化中受益。
“Web 3.0”的前提是以太坊联合创始人 Gavin Wood 在 2014 年以太坊推出后不久创造的。 Gavin 提出了一个解决许多早期加密货币采用者认为的问题的解决方案:互联网需要太多的信任。也就是说,今天人们知道和使用的大多数互联网都依赖于信任少数私营公司来为公众的最大利益行事。
Web3 已成为一个包罗万象的术语,代表了一个新的、更好的互联网的愿景。Web3 的核心是使用区块链、加密货币和 NFT 以所有权的形式将权力交还给用户。 2021 年 Twitter 上的一篇帖子 说得最好:Web1 是只读的,Web2 是读/写的,Web3 将是读/写/拥有的。
尽管提供一个严格的定义 Web3 是什么具有挑战性,但有一些核心原则指导它的创建。
尽管 Web3 的杀手级功能不是孤立的,也不适合整齐的类别,但为简单起见,我们尝试将它们分开以使它们更易于理解。
Web3 以前所未有的方式让您拥有数字资产的所有权。例如,假设您正在玩 web2 游戏。如果您购买游戏内物品,它会直接与您的帐户绑定。如果游戏创建者删除您的帐户,您将丢失这些物品。或者,如果您停止玩游戏,您将失去投资于游戏内物品的价值。
Web3 允许通过 非同质化的代币 (NFT) 直接拥有所有权。其他人甚至游戏的创造者,都没有权力剥夺你的所有权。而且,如果您停止玩游戏,您可以在公开市场上出售或交易游戏内你的物品并收回它们的价值。
平台和内容创作者之间的权力动态是严重失衡的。
OnlyFans 是一个用户生成的成人内容网站,拥有超过 100 万内容创作者,其中许多人使用该平台作为他们的主要收入来源。2021 年 8 月,OnlyFans 宣布了禁止色情内容的决定。该公告在平台上的创作者中引发了愤怒,他们认为他们帮助创建了一个平台现在却被这个平台被剥夺了收入。在强烈反对之后,这个决定很快被推翻。尽管创作者赢得了这场战斗,但它突显了 Web 2.0 创作者的一个问题:如果你离开一个平台,你就会失去声誉并追随你的人。
在 Web3 上,您的数据位于区块链上。当您决定离开一个平台时,您可以将您的声誉带走,将其插入另一个更符合您的价值观的接口。
Web 2.0 要求内容创建者信任平台而不是更改规则,但抵抗审查是 Web3 平台的原生特性。
传统上,您将为您使用的每个平台创建一个帐户。例如,您可能有一个 Twitter 帐户、一个 YouTube 帐户和一个 Reddit 帐户。想要更改您的显示名称或个人资料图片?您必须在每个帐户中执行此操作。在某些情况下,您可以使用社交登录,但这会带来一个熟悉的问题——审查。只需单击一下,这些平台就可以将您锁定在整个在线生活之外。更糟糕的是,许多平台要求您信任他们的个人身份信息才能创建帐户。
Web3 通过允许您使用以太坊地址和 ENS 配置文件控制您的数字身份来解决这些问题。使用以太坊地址可以跨平台提供安全、抵抗审查和匿名的单一登录。
Web2 的支付基础设施依赖于银行和支付处理程序,不包括没有银行账户的人或碰巧住在错误国家境内的人。Web3 使用 ETH 等代币在浏览器中直接汇款,不需要受信任的第三方。
更多关于 ETH
尽管当前形式的 Web3 有许多好处,但生态系统仍然必须解决许多限制才能使其蓬勃发展。
任何人都可以零成本使用重要的 Web3 功能,例如使用以太坊登录。但是,交易的相对成本仍然让许多人望而却步。由于高昂的交易费用,Web3 不太可能在不太富裕的发展中国家使用。在以太坊上,这些挑战正在通过 网络升级 和 第 2 层扩展解决方案来解决 。该技术已经准备就绪,但我们需要在第 2 层采用更高级别的技术,以使每个人都可以访问 Web3。
目前使用 Web3 的技术门槛太高了。用户必须理解安全问题、理解复杂的技术文档并浏览不直观的用户界面。 尤其是钱包提供商 正在努力解决这个问题,但在 Web3 被大规模采用之前还需要更多的进展。
Web3 引入了新的范式,这些范式需要学习与 Web2.0 中使用的不同的心智模型。随着 Web1.0 在 1990 年代后期越来越流行,类似的教育活动也发生了。万维网的支持者使用一系列教育技术来教育公众,从简单的比喻(信息高速公路、浏览器、网上冲浪)到 电视广播 。Web3 并不难,但它是不同的。让 Web2 用户了解这些 Web3 范式的教育计划对其成功至关重要。
Ethereum.org 通过我们的 翻译计划 为 Web3 教育做出贡献,旨在将重要的以太坊内容翻译成尽可能多的语言。
Web3 生态系统很年轻并且发展迅速。因此,它目前主要依赖于中心化基础设施(GitHub、Twitter、Discord 等)。许多 Web3 公司都在争先恐后地填补这些空白,但构建高质量、可靠的基础架构需要时间。
Web3 是一个年轻且不断发展的生态系统。Gavin Wood 在 2014 年创造了这个词,但其中许多想法直到最近才成为现实。仅在去年,人们对加密货币的兴趣就大幅增加,对第 2 层扩展解决方案的改进,对新治理形式的大规模实验以及数字身份的革命。
我们才刚刚开始使用 Web3 创建更好的互联网,但随着我们继续改进支持它的基础设施,互联网的未来看起来一片光明。
㈥ 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网络的拥堵状况,发送每笔交易时,设置合理的矿工费用,避免大量的交易积压在交易池。
㈦ Web3py简单使用方法(三)
一.Web3py的一些使用的例子:
1.查询区块:
···
web3.eth.getBlock(12345)
web3.eth.getBlock('')
web3.eth.getBlock('latest')
web3.eth.blockNumber
二.web3py还提供几个详细模块的api,具体可上文档查询。
1.Web3.eth : http://web3py.readthedocs.io/en/latest/web3.eth.html
2.Web3.shh : http://web3py.readthedocs.io/en/latest/web3.shh.html
3.Web3.personal : http://web3py.readthedocs.io/en/latest/web3.personal.html
4.Web3.version : http://web3py.readthedocs.io/en/latest/web3.version.html
5.Web3.txpool : http://web3py.readthedocs.io/en/latest/web3.txpool.html
6.Web3.miner : http://web3py.readthedocs.io/en/latest/web3.miner.html
7.Web3.admin : http://web3py.readthedocs.io/en/latest/web3.admin.html
㈧ 以太坊如何使用web3.js或者rpc接口获取交易数据交易时间与确认数
如果要查询主网上的交易记录,可以使用etherscan。但是,如果是你自己搭建的私链,应该如何查询交易记录呢?
答案是你需要自己监听链上的日志,存到数据库里,然后在这个数据库中查询。例如:
varaddr=""
varfilter=web3.eth.filter({fromBlock:0,toBlock:'latest',address:addr});
filter.get(function(err,transactions){
transactions.forEach(function(tx){
vartxInfo=web3.eth.getTransaction(tx.transactionHash);
//这时可以将交易信息txInfo存入数据库
});
});
web3.eth.filter()用来监听链上的日志,web3.eth.getTransaction()用来提取指定交易的信息,一旦获得交易信息,就可以存入数据库供查询用了。
推荐一个实战入门,你可以看看:以太坊教程
㈨ 以太坊中的计量单位及相互转换
首先我们来看一下以太币单位之间的转换,以太币的最小单位为wei,1个eth相当于10的18次方wei。通常,大家也使用Gwei作为展示单位。比较常用的就是eth,Gwei和wei。
为了使用和验证web3的操作命令,我们先进入geth的console控制台,在这里对具体的单位或进制转换进行详细的实例演示。
此转换方法为web3.toDecimal(hexString)。直接在控制台输入一下命令进行使用此函数进行转换。
通过此函数将十六进制的0x16转换为十进制的22。
转换函数:web3.fromDecimal(number)。
控制台命令及结果如下:
把给定数字或十六进制字符串转为 BigNumber 类型的实例。
此处转换需要注意的是BigNumber只会保留小数点后20位,超过20位的部分将会被截取掉。
上面表格中列出了以太币之间的单位进制,同样可以使用web3进行相应的转换,基本函数为web3.fromWei和web3.toWei(number, unit)。
具体实例如下:
其他的相关转换大家可自行尝试,下面列出相应的转换种类:
通过上面的函数,在交易的过程中我们就可以随意的单位进行发送交易,而不必使用最小单位wei。
通过查询余额的方法,我们也可以看出区块链中存储这些数据的单位为wei。
代币中的单位
在编写ERC-20的代币合约时我们可以指定代币的单位,比如:
这里就指定了代币单位精确到小数点后几位。比如精确到小数点后3位,那么1个代币存储时就是1000个最小单位的值。