eth算法会被破译吗

⑴ eth挖矿是什么原理

凡是涉及到币，就一定离不开挖矿。以太坊网络中，想要获得以太坊，也要通过挖矿来实现。说到挖矿，就一定离不开共识机制。
不知道大家还记得比特币的共识机制是什么吗？比特币的共识机制是 PoW (这是英文 Proof of Work 的缩写，意思是“工作量证明机制”）。简单来说，就是多劳多得，你付出的计算工作越高，那么你就越有可能第一个找到正确的哈希值，就越有可能得到比特币奖励。
但是，比特币的PoW存在着一定的缺陷，就是它处理交易的速度太慢，矿工们需要不断地通过计算来碰撞哈希值，这是劳民伤财且效率低下的。对区块链知识有涉猎的朋友们应该看到这样一种说法：
以太坊为了弥补比特币的不足，提出了新的共识机制，名叫 PoS(这是英文的缩写，意思是“权益证明”，也有翻译成“股权证明”的）。
PoS 简单来讲，其实就跟它的字面意思一样：权益嘛，股权嘛，你持有的币越多相当于你的股权越多，你的权益越高。
以太坊的PoS就是说：你持币越多，你持有币的时间越久，你的计算难度就会降低，挖矿会容易一些。
在以太坊最初的设定中，以太坊希望能够通过阶段性的升级，在前期依旧采用PoW来构建一个相对稳定的系统，之后逐渐采用 PoW+PoS，最后完全过渡到 PoS。所以，说以太坊的共识机制是PoS，没错，但是PoS只是以太坊发布之初的一个计划或者说目标，目前以太坊还没有过渡到 PoS，以太坊采用的共识机制仍是 PoW，就是比特币那个 PoW，但是又和比特币的PoW稍稍不同。
这里的信息量有点大，
第一个信息点是：以太坊目前采用的共识机制也是PoW，但是和比特币的PoW稍稍不同。那么，和比特币的PoW到底有什么不同呢：简单来说，就是以太坊挖矿难度可以调节，比特币挖矿难度不能调节。就好比咱们高考，因为各个省份的教学情况、生源人数都不一样，所以高考分为全国卷和各省自主命题。
以太坊说我赞成这样分地区出题，比特币说：不行，必须全国同一卷，大家难度都一样！
通俗解释，就是，比特币是利用计算机算力做大量的哈希碰撞，列举出各种可能性，来找到一个正确哈希值。而以太坊系统呢，它有一个特殊的公式用来计算之后的每个块的难度。如果某个区块比前一个区块验证的更快，以太坊协议就会增加区块的难度。通过调整区块难度，就可以调整验证区块所需的时间。
以太坊协议规定，难度的动态调整方式是使全网创建新区块的时间间隔为 15 秒，网络用 15 秒时间创建区块链，这样一来，因为时间太快，系统的同步性就大大提升，恶意参与者很难在如此短的时间发动51%（也就是半数以上）的算力去修改历史数据。
第二个信息点是：以太坊最初的设定中，希望通过阶段性升级来最终实现由 PoW 向
PoS过渡的。
时间追溯到 2014 年，在以太坊发布之初，团队宣布将项目的发布分为四个阶段，即 Froniter（前沿）、Homestead（家园）、Metropolis（大都会）和 Serenity（宁静）。前三个阶段共识机制采用 PoW（工作量证明机制），第四个阶段切换到 PoS（权益证明机制）。
2015年7月30号，以太坊第一个阶段“前沿”正式发布，这个阶段只适用于开发者使用，开发人员可于在以太坊网络上编写智能合约和去中心化应用程序 DAPP，矿工开始进入以太坊网络维护网络安全并挖矿得到以太币。前沿版本类似于测试版，证明以太坊网络到底是不是可靠的。
2016年3月14日，以太坊进入到第二个阶段“家园”，这一阶段，以太坊提供了钱包功能，让普通用户也可以方便体验和使用以太坊。其他方面没有什么明显的技术提升，只是表明以太坊网络已经可以平稳运行。
2017 年 9 月，以太坊已经进行到第三个阶段“大都会”。“大都会”由拜占庭和君士坦丁堡两次升级组成，这个阶段的的目标是希望能够引入 PoW 和 PoS 的混合链模式，为 PoW向PoS的顺滑过渡做准备。最近比较热门的“以太坊君士坦丁堡升级”升级的就是这个，在君士坦丁堡升级中呢，以太坊将对底层协议和算法做一些改变，来为实现 PoW 和
PoS奠定良好的基础。
以太坊挖矿会得到对多少奖励呢？赢得区块创建竞争成功的矿工会得到这么几项收入：
1、 静态奖励，5个以太坊；
2、 区块内所花费的燃料成本，也就是Gas，这部分我们上一期内容讲过;
3、 作为区块组成部分，包含“叔区块”的额外奖励，叔就是叔叔的叔，每个叔区块可以得到挖矿报酬的1/32作为奖励，也就是5乘以1/32，等于0.15625 个以太坊。这里我们简单解释一下“叔区块”，“叔区块”这个概念是以太坊提出来的，为什么要引进叔块的概念？这还要从比特币说起。在比特币协议中，最长的链被认为是绝对的正确。如果一个块不是最长链的一部分，那么它被称为是“孤块”。一个孤立的块是一个块，它也是合法的，但是可能发现的稍晚，或者是网络传输稍慢，而没有能成为最长的链的一部分。在比特币中，孤块没有意义，随后将被抛弃掉，发现这个孤块的矿工也拿不到采矿相关的奖励。
但是，以太坊不认为孤块是没有价值的，以太坊系统也会给与发现孤块的矿工回报。在以太坊中，孤块被称为“叔块”(uncle block)，它们可以为主链的安全作出贡献。 以太坊十几秒的出块间隔太快了，会降低安全性，通过鼓励引用叔块，使引用主链获得更多的安全保证(因为孤块本身也是合法的) ，而且，支付报酬给叔块，还能激发矿工积极挖矿，积极引用叔块，所以，以太坊认为，它是有价值的。

⑵ 自己的加密算法 别人能破译吗

你的加密算法很先进么？有多复杂？
你能问出这样的问题，我猜你对加密的认识不大可能有多深入。那么在专家的眼里，你的加密算法可以再几秒钟内被破解。
与其相信你自己的加密算法，还不如用winrar加密来的可靠。
据我所知，加密算法目前AES足够日常使用，256bit的AES是没有暴力破解价值的。

像网上盛传的图片伪装加密，mp3伪装加密什么的，相信相关技术人员早就想好了一套专门的标准破解流程(SOP)，所以，嘿嘿，不堪一击~~

⑶ 什么是以太币/以太坊ETH

以太币（ETH）是以太坊（Ethereum）的一种数字代币，被视为“比特币2.0版”，采用与比特币不同的区块链技术“以太坊”（Ethereum），一个开源的有智能合约成果的民众区块链平台，由全球成千上万的计算机构成的共鸣网络。开发者们需要支付以太币（ETH）来支撑应用的运行。和其他数字货币一样，以太币可以在交易平台上进行买卖 。

温馨提示：以上解释仅供参考，不作任何建议。入市有风险，投资需谨慎。您在做任何投资之前，应确保自己完全明白该产品的投资性质和所涉及的风险，详细了解和谨慎评估产品后，再自身判断是否参与交易。
应答时间：2020-12-02，最新业务变化请以平安银行官网公布为准。
[平安银行我知道]想要知道更多？快来看“平安银行我知道”吧~
https://b.pingan.com.cn/paim/iknow/index.html

⑷ 以太坊技术系列-以太坊数据结构

本篇文章和大家介绍一下以太坊的数据结构，上篇文章我们提到，以太坊为了实现智能合约这一功能，使用了基于账户的模型。我们来看看以太坊中数据结构。

既然是基于账户的模型，我们需要通过账户地址找到账户的状态。就像通过银行卡号可以找到你在银行中的各种信息一样。最简单的想法当然是一个简单的哈希表 key是账户地址 value是账户状态。但这里有个问题解决不了。

轻节点如何校验账户合法性？

上篇我们说过，区块链中有2类节点，全节点和轻节点，轻节点只会存储block header，所以轻节点如何才能校验账号是否合法呢？

这个思路和我们平时用的md5校验一致，我们会对区块内的信息进行hash运算从而得出区块内信息唯一确定的值，区块链所有节点中这个值都是相同的。

在这个过程中我们用到了一种数据结构Merkle Tree（哈希树），我们先看下Merkle Tree（哈希树）的示意图。

上篇文章说到区块链中的链表(哈希链)和我们平时常见链表不同的是将指针从地址改为了hash指，这里也一样，哈希树和二叉树的区别有2个

1.将地址改为了哈希值

2.只有叶子节点存储数据

回到之前的问题轻节点是如何校验1个账户或交易是否是在链上的呢？

整个流程如上图所示

1.轻节点需要判断1个账号是否合法

2.轻节点由于只存储block header，所以拿到1个账号的时候会向全节点发出请求

3.全节点存储了所有账户状态，将账户路径中的需要计算用到的hash值返回给轻节点

4.轻节点本地进行计算根hash值，如果计算结果和自己存储一致则账户合法，不一致则不合法。

那以太坊中的账户信息的数据结构就是这样吗？

直接用这样的数据结构来存储账户信息会有2个问题

查找困难

生成hash值不确定

第1个问题应该比较容易发现，在这个树中寻找1个账号需要的复杂度是O(n),因为没有任何顺序。

第2个问题其实也是因为无序导致的，无序的组合每个节点针对同一批账户生成的hash值不一致，这就导致无法达成共识。

既然2个问题都和顺序有关，那我们类似二叉排序树一样，使用哈希排序树是不是就可以解决问题了呢？

使用排序树后会带来另外1个问题

插入困难

因为要维持树是有序的，很可能带来树结构的很大变动。

以太坊中使用了另外一种数据结构字典树。和哈希树不同，字典树应该是很多地方都有使用。我们简单来看下字典树的结构。

字典树能够较好地解决哈希树的2个缺点1.查找困难 2.生成的hash值不确定以及排序二叉树的1个缺点 插入困难。

但字典树我们可以看到可能树的深度可能由于部分元素导致整棵树深度非常深。

这时我们可以进一步优化，将相同路径进行压缩。这就是压缩字典树。

将哈希树和压缩字典树结合，就可以得到以太坊存储账户的最终数据结构-MPT。

将压缩字典树里面的指针从地址改为指针，并且将数据存储在叶子节点中即可。

介绍完状态树的数据结构，我们接下来讨论1个问题，区块中存储的账户状态是什么样的范围。有2种选择。

只保存当时区块中产生交易的账户状态。

保存全局所有的账户。

我们可以看下这2种方式，无非就是空间和时间的平衡，只保存当前区块产生的交易意味着是做懒加载(需要的时候才去寻找账户)，在区块链中这个代价是非常大的，因为寻找的账户之前从未交易过，这样会遍历整个区块链。另外一种保存全局的账户方式虽然看起来空间消耗较大，但查找快捷，而且空间的问题我们可以通过其他方式优化。所以最终以太坊选择了第2种每个区块都报错全局所有账户的方式。

我们来看下以太坊中是如何保存状态树的。

可以看到以太坊中虽然每个区块都保存了全部账户，但是会将未发生变化的账户状态指向前1个节点，本身只存储发生变化的状态，这样可以较大程度优化空间占用。

介绍完以太坊中比较复杂的状态树后，我们继续来看看以太坊中的另外两棵树，交易树和收据树。

首先介绍一下，为什么需要交易树&收据树。

1.交易树

虽然以太坊是基于账户的模型，但是就像银行不仅会存储银行卡的余额，还会存储卡中的每笔钱怎么来的以及怎么花的。交易树中就存储着当前区块中的包含的所有交易。

2.收据树

由于智能合约的引入增加了不少复杂性，所以以太坊用收据树存储着一些交易操作的额外信息。比如交易过程中执行日志就包含在收据树中方便查询。收据树和交易树是一一对应的。每发生一次交易就会有一次收据。

和状态树不同交易树和收据树只维护当前区块内发生的交易，因为当时区块发生交易时不需要再去查找另外1个交易，也就之前需要可能遍历整个区块链的查找操作了。

由于以太坊中的出块速度较快，我们进行一些查询一些符合条件交易的时候会面临大量数据遍历困难的问题。收据树中引入了布隆过滤器可以帮助我们有效缓解这一困难。

布隆过滤器将大集合中每个元素进行hash运算映射到1个较小的集合，这时再来1个元素要判断是否在大集合的时候，不需要遍历整个大集合，而是去进行hash运算去小集合中寻找是否存在，如果不存在，肯定不在大集合中，如果存在则不能说明任何问题。

如上图所示，布隆过滤器只能证明某1个元素不在集合中，不能证明1个元素在结合中。

以太坊中如果我们要在较多区块中寻找某1个交易，则可以利用布隆过滤器，过滤掉肯定不存在目标交易的区块，然后进入收据树内继续利用布隆过滤器筛选，剩下的才是可能的目标交易的交易，进行一一比对即可。

我们介绍了以太坊的核心数据结构，状态树&交易树&收据树，他们都是使用相同的数据结构-哈希压缩字典树。但状态树是维护1颗全局账户树，交易树和收据树则是维护本区块内的交易或收据。

介绍完数据结构后，后面我们会用几篇文章来介绍以太坊中的一些核心算法，比如共识机制，挖矿算法等。

⑸ 如果墨客moac的ETH算法被专业矿机攻破怎么办

ethash算法，是可以改的！

⑹ 【深度知识】以太坊数据序列化RLP编码/解码原理

RLP(Recursive Length Prefix)，中文翻译过来叫递归长度前缀编码，它是以太坊序列化所采用的编码方式。RLP主要用于以太坊中数据的网络传输和持久化存储。

对象序列化方法有很多种，常见的像JSON编码，但是JSON有个明显的缺点：编码结果比较大。例如有如下的结构：

变量s序列化的结果是{"name":"icattlecoder","sex":"male"},字符串长度35，实际有效数据是icattlecoder 和male，共计16个字节，我们可以看到JSON的序列化时引入了太多的冗余信息。假设以太坊采用JSON来序列化，那么本来50GB的区块链可能现在就要100GB，当然实际没这么简单。

所以，以太坊需要设计一种结果更小的编码方法。

RLP编码的定义只处理两类数据：一类是字符串（例如字节数组），一类是列表。字符串指的是一串二进制数据，列表是一个嵌套递归的结构，里面可以包含字符串和列表，例如["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]就是一个复杂的列表。其他类型的数据需要转成以上的两类，转换的规则不是RLP编码定义的，可以根据自己的规则转换，例如struct可以转成列表，int可以转成二进制（属于字符串一类），以太坊中整数都以大端形式存储。

从RLP编码的名字可以看出它的特点：一个是递归，被编码的数据是递归的结构，编码算法也是递归进行处理的；二是长度前缀，也就是RLP编码都带有一个前缀，这个前缀是跟被编码数据的长度相关的，从下面的编码规则中可以看出这一点。

对于值在[0, 127]之间的单个字节，其编码是其本身。

例1：a的编码是97。

如果byte数组长度l <= 55，编码的结果是数组本身，再加上128+l作为前缀。

例2：空字符串编码是128，即128 = 128 + 0。

例3：abc编码结果是131 97 98 99，其中131=128+len("abc")，97 98 99依次是a b c。

如果数组长度大于55， 编码结果第一个是183加数组长度的编码的长度，然后是数组长度的本身的编码，最后是byte数组的编码。

请把上面的规则多读几篇，特别是数组长度的编码的长度。

例4：编码下面这段字符串：

The length of this sentence is more than 55 bytes, I know it because I pre-designed it
这段字符串共86个字节，而86的编码只需要一个字节，那就是它自己，因此，编码的结果如下：

184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前三个字节的计算方式如下：

184 = 183 + 1，因为数组长度86编码后仅占用一个字节。
86即数组长度86
84是T的编码
例5：编码一个重复1024次"a"的字符串，其结果为：185 4 0 97 97 97 97 97 97 ...。
1024按 big endian编码为004 0，省略掉前面的零，长度为2，因此185 = 183 + 2。

规则1~3定义了byte数组的编码方案，下面介绍列表的编码规则。在此之前，我们先定义列表长度是指子列表编码后的长度之和。

如果列表长度小于55，编码结果第一位是192加列表长度的编码的长度，然后依次连接各子列表的编码。

注意规则4本身是递归定义的。
例6：["abc", "def"]的编码结果是200 131 97 98 99 131 100 101 102。
其中abc的编码为131 97 98 99,def的编码为131 100 101 102。两个子字符串的编码后总长度是8，因此编码结果第一位计算得出：192 + 8 = 200。

如果列表长度超过55，编码结果第一位是247加列表长度的编码长度，然后是列表长度本身的编码，最后依次连接各子列表的编码。

规则5本身也是递归定义的，和规则3相似。

例7：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
的编码结果是:

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前两个字节的计算方式如下：

248 = 247 +1
88 = 86 + 2，在规则3的示例中，长度为86，而在此例中，由于有两个子字符串，每个子字符串本身的长度的编码各占1字节，因此总共占2字节。
第3个字节179依据规则2得出179 = 128 + 51
第55个字节163同样依据规则2得出163 = 128 + 35

例8：最后我们再来看个稍复杂点的例子以加深理解递归长度前缀，

["abc",["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]]
编码结果是：

248 94 131 97 98 99 248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
列表第一项字符串abc根据规则2，编码结果为131 97 98 99,长度为4。
列表第二项也是一个列表项：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
根据规则5，结果为

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
长度为90，因此，整个列表的编码结果第二位是90 + 4 = 94, 占用1个字节，第一位247 + 1 = 248

以上5条就是RPL的全部编码规则。

各语言在具体实现RLP编码时，首先需要将对像映射成byte数组或列表两种形式。以go语言编码struct为例，会将其映射为列表，例如Student这个对象处理成列表["icattlecoder","male"]

如果编码map类型，可以采用以下列表形式：

[["",""],["",""],["",""]]

解码时，首先根据编码结果第一个字节f的大小，执行以下的规则判断：

1.如果f∈ [0,128),那么它是一个字节本身。

2.如果f∈[128,184)，那么它是一个长度不超过55的byte数组，数组的长度为 l=f-128

3.如果f∈[184,192)，那么它是一个长度超过55的数组，长度本身的编码长度ll=f-183,然后从第二个字节开始读取长度为ll的bytes，按照BigEndian编码成整数l，l即为数组的长度。

4.如果f∈(192,247]，那么它是一个编码后总长度不超过55的列表，列表长度为l=f-192。递归使用规则1~4进行解码。

5.如果f∈(247,256]，那么它是编码后长度大于55的列表，其长度本身的编码长度ll=f-247,然后从第二个字节读取长度为ll的bytes,按BigEndian编码成整数l，l即为子列表长度。然后递归根据解码规则进行解码。

以上解释了什么叫递归长度前缀编码，这个名字本身很好的解释了编码规则。

（1） 以太坊源码学习—RLP编码( https://segmentfault.com/a/1190000011763339 )
（2）简单分析RLP编码原理
( https://blog.csdn.net/itchosen/article/details/78183991 )