基于区块链的毕业设计Hash Collisions in Distributed ledgers – 分布式账本中的哈希冲突

本文提供基于区块链的毕业设计国外最新区块链项目源码下载,包括solidity,eth,fabric等blockchain区块链,基于区块链的毕业设计Hash Collisions in Distributed ledgers – 分布式账本中的哈希冲突 是一篇很好的国外资料

Hash Collisions in Distributed ledgers

This program generates a public private key pair, a wallet address, and checks the fund of the wallet. The program does this continuesly at a rate of about 5 checks per second, probabilistically exploring hash collisions on Ethereum. The program performs the checks through the Etherscan API.

Cryptogrpahy in distributed ledgers

Distributed ledgers all have one thing in common: Their utilization of assymetric cryptography.

Any individual participating in a decentralized protocol has to have a crypto wallet to do so. A crypto wallet is essentially a public private key pair but instead of the wwallet address being the public key, it is a hashed public key. The public and private key pairs are 256 bits and the public key is created from the private key using the Elliptic Curve Encryption System. The public key (256 bits) is then hashed to a 160 bit walllet address.

When you are authorizing transactions, you want to prove that you are the owner of the private key corresponding to funds in the wallet. This is done using a Digital Signature Algorithm. When a user authorizes a transaction, they prove that the user is the owner of the private key corresponding to the public key’s funds. Because of the mathematical relationship between the public and private keys, users can sign a transaction with their private key, creating a digital signature. A digital signature reveals no information about the private key but can be verified with the corresponding public key. Thus proof can be constructed.

Back of the Napkin Math

The keyspace is 2^160. The Etherscan API only accepts five queries per second with a maximum of three free API keys per account. A single account can query 15 keys per second and about 1,296,000 a day. This barely puts a dent in the keyspace as 1,296,000/2^160 is around 0.0000000000000000000000000000000000000000008 of the total keyspace.

As of August 2021, there are a little under 1,000,000 active Ethereum wallets with Eth or Eth-based tokens in them. Some of these may be smart contracts, some of these may be lost wallets. 1,000,000/(2^160) is about 0.0000000000000000000000000000000000000000006. Multiplied by the number of searches a day 1,296,000 is about 0.00000000000000000000000000000000000008, which is about ten magnitudes greater than searching the whole keyspace.

Potential Optimizations

While searching the entire keyspace would be a fruitless endeavor, there are four optimizations to propose for this research to be worthwhile. There are two domain abstractions and two computational optimizations that worthwhile

Computational Optimizations

Currently, the computational restriction is the use of Etherscans API. To eliminate the requirement of this API. One could instead make a dump of all wallets with a transaction count > 0.

The Second computational optimization is in regards to programmatic optimization. Python, an interpreted language, is not as fast as a precompiled language low-level language like C, Rust, or Go. Utilizing these languages to implement the Van Oorschot-Wiener parallel Collision search, would result in a significant speedup. With this method the expected number of inputs to be tried in order for a collision to be found is is k = sqrt((pi*n)/2). For our n = 2^160, k = 1.5151638e+24. If you search 1,296,000 a day (which we should do better) than is would take 1.2063406e+18 days. However these calculations are the probability of calculating a single collision in the entire key space, while we are just search for any of aa given 1,000,000 collisions. Does the birthday paradox apply here?

Domain Abstraction Optimizations

Wallets with leading 0s produce lower transaction fees for related transactions. In short, this is because an address with leading zeros takes up less memory on the distributed network. As a result, there is a high demand for these “Vanity wallets” with leading zeros. If we can restrict the searched domain for wallets with leading zeros in their addresses, this could significantly reduce the search space.

The second domain optimization is regarding the phenomena of two private keys sharing an address. Because private/public keys are 256 bits and addresses are 160 bits, by the pigeon hole principle there exists multiple private/public key pairs that share an address.

Run the program

pip install secrets

pip install etherscan-python

pip install etherium

python generator.py

Collaboration

If anyone wants to collaborate on any of these reasearch endeavors please reach out to me. Information availible on my github page

Resources

  • Efficient Ethereum Addresses
  • Pigon Hole Principle proof of two private keys to one addresss
  • Vanity Wallet Generator JavaScript
  • Two private keys –> one address
  • Week random source for ECDSA
  • Python Resource
  • van Oorschot–Wiener parallel collision search machine

分布式账本中的哈希冲突

这个程序生成一个公私密钥对,一个钱包地址,并检查钱包的资金。该程序以每秒约5次检查的速度连续执行此操作,可能会在以太坊eth上探索哈希冲突。该程序通过Etherscan API执行检查

分布式账本中的加密

分布式账本都有一个共同点:它们对非对称加密的利用

任何参与分散协议的个人都必须拥有加密钱包才能这样做。加密钱包本质上是一个公钥-私钥对,但wwallet地址不是公钥,而是一个哈希公钥。公钥和私钥对为256位,公钥是使用椭圆曲线加密系统从私钥创建的。然后将公钥(256位)散列到160位Wallet地址

当您授权交易时,您需要证明您是钱包中资金对应的私钥的所有者。这是使用数字签名算法完成的。当用户授权交易时,他们证明该用户是与公钥资金对应的私钥的所有者。由于公钥和私钥之间的数学关系,用户可以使用私钥签署交易,从而创建数字签名。数字签名不显示有关私钥的信息,但可以使用相应的公钥进行验证。因此,可以构造证据

餐巾纸后面的数学

键空间为2^160。Etherscan API每秒仅接受五个查询,每个帐户最多可接受三个免费API密钥。单个帐户每秒可以查询15个密钥,每天大约查询1296000个密钥。这几乎不会影响键空间,因为1296000/2^160约为总键空间的0.0000000000000000000000000000008

截至2021年8月,有不到1000000个以太坊eth钱包在使用Eth或基于Eth的代币。其中有些可能是智能合同,有些可能是丢失的钱包。1000000/(2^160)约为0.0000000000000000006。乘以每天搜索的次数1296000大约是0.00000000000000000000000008,这比搜索整个键空间大约大十个数量级

潜在优化

虽然搜索整个键空间将是徒劳的,但有四种优化建议值得进行这项研究。目前有两个领域抽象和两个计算优化是值得的

计算优化

目前,计算限制是使用Etherscans API。以消除此API的要求。您可以使用交易计数来转储所有钱包>0.

第二个计算优化与程序优化有关。Python是一种解释性语言,它的速度不如预编译语言(如C、Rust或Go等低级语言)快。利用这些语言来实现Van Oorschot-Wiener并行碰撞搜索将导致显著的加速。使用此方法,为了找到冲突而尝试的预期输入数为k=sqrt((pi*n)/2)。对于我们的n=2^160,k=1.5151638e+24。如果您每天搜索1296000(我们应该做得更好),则需要1.2063406e+18天。然而,这些计算是计算整个密钥空间中单个碰撞的概率,而我们只是搜索给定1000000个碰撞中的任何一个。生日悖论在这里适用吗

域抽象优化

领先0的钱包会降低关联交易的交易费用。简而言之,这是因为带前导零的地址在分布式网络上占用的内存更少。因此,对这些前导零的“虚荣钱包”的需求量很大。如果我们可以限制搜索域中地址前导为零的钱包,这将大大减少搜索空间

第二个域优化是关于两个私钥共享一个地址的现象。由于私钥/公钥为256位,地址为160位,根据鸽子洞原理,存在多个共享一个地址的私钥/公钥对

运行程序

-pip install secrets

-pip install etherscan python

-pip install etherium

-python generator.py

协作

如果有人想在这些研究工作中合作,请联系我。我的github页面上可用的信息

参考资料

  • 高效以太坊eth地址
  • 两个私钥对一个地址的Pigon-Hole原理证明
  • 虚荣钱包生成器JavaScript
  • 两个私钥–>一个地址
  • 用于ECDSA的每周随机源
  • Python资源
  • van Oorschot–维纳并行冲突搜索机

部分转自网络,侵权联系删除区块链源码网

www.interchains.cc

https://www.interchains.cc/24364.html

区块链毕设网(www.interchains.cc)全网最靠谱的原创区块链毕设代做网站 部分资料来自网络,侵权联系删除! 最全最大的区块链源码站 ! QQ3039046426
区块链知识分享网, 以太坊dapp资源网, 区块链教程, fabric教程下载, 区块链书籍下载, 区块链资料下载, 区块链视频教程下载, 区块链基础教程, 区块链入门教程, 区块链资源 » 基于区块链的毕业设计Hash Collisions in Distributed ledgers – 分布式账本中的哈希冲突

提供最优质的资源集合

立即查看 了解详情