前几次实验

0CFBBC039848490CD407103D0C2BAA21

现在先整理一下高亮部分的重点：

不可能三角

区块链三元悖论是指普遍持有的观点，即在去中心化、安全性和可扩展性方面，去中心化网络在任何给定时间只能提供三个好处中的两个。

image.png

  • 区块链的可扩展性是指其处理更多交易的能力。

  • 安全性是指保护区块链上的数据免受各种攻击的能力以及区块链对双花的防御。

  • 去中心化是一种网络冗余，可确保网络不受较少实体的控制。

  • 追求“安全”与“去中心化”则无法达到“可扩展性”

    • 比特币区块链技术便是一种追求“去中心化”与“安全”的技术组合。

  • 追求“可扩展性”与“去中心化”则需要牺牲“安全”

    • 极端的案例就是基于P2P的视频播放软件。以往当在线观看人数增多时，基于中央服务器设计的视频服务器会因承载压力变大而速度缓慢。为了提高效率，P2P视频播放软件的设计使得一个节点在下载观看视频文件的同时也不断将数据传输给别人，每个节点不仅是下载者同时也是服务器，资源的分享形成不再依赖于中央服务器的“去中心化”模式

  • 追求“可扩展性”与“安全”则需要牺牲“去中心化”

    • 同样在区块链技术的演化上，除了公有链外，也有联盟链和私有链。联盟链只允许预设的节点进行记账，加入的节点都需要申请和身份验证，这种区块链技术实质上是在确保安全和效率的基础上进行的“部分去中心化”或“多中心化”的妥协。而私有链已经成为了完全“中心化”的技术。

Lighting network

闪电网络（Lightning Network）是一个去中心化的系统。闪电网络的卓越之处在于，无需信任对方以及第三方即可实现实时的、海量的交易网络。

  • 闪电通道的状态更新交易 RSMC(Revocable Sequence Maturity Contract) 可撤销序列合约

    RSMC(可撤销序列到期合约)解决了通道中币单向流动问题

    • image-20230619162227783
      解释一下下方RSMC交易的结构（图X)，左侧为爱丽丝的视角，右侧为鲍伯的视角。中间Funding Tx为共同可见，C1a和RD1a为爱丽丝持有，C1b和RD1b为鲍伯持有。交易图中带有尖括号的签名表示待填入。

    • 构建步骤

      • 1、双方各拿出 0.5 BTC，构建 Funding Tx，输出为爱丽丝和鲍伯的 2/2 多重签名。
      • 2、爱丽丝构造 Commitment Tx：C1a 和 RD1a，并交给鲍伯签名。C1a 的第一个输出为多重签名地址，爱丽丝的另一把私钥爱丽丝2 和鲍伯的 2/2 多重签名，第二个输出为鲍伯 0.5BTC。
      • 3、RD1a 为 C1a 第一个输出的花费交易，输出给爱丽丝 0.5 BTC，但此类型交易带有 sequence，作用是阻止当前交易进块，只有前向交易有 sequence 个确认时才能进块。
      • 4、鲍伯构造Commitment Tx：C1b和RD1b，并交给爱丽丝签名。结构与C1a、RD1a是对称关系。
      • 5、鲍伯对 C1a 和 RD1a 进行签名，并将签名给爱丽丝；同理，爱丽丝对 C1b 和 RD1b 签名，完成后给鲍伯。此时，由于并未对Funding Tx 进行签名，任何一方均无法作恶，任何一方也不会有任何损失。
      • 6、双方均完成对 commitment Tx 的签名并交换后，各自再对Funding Tx 进行签名，并交换。此时，Funding Tx 是完整的交易，广播之。
      • C1a, C1b两笔交易花费的是同一个输出，故他们两个交易只有一个能进块。若爱丽丝广播 C1a，则鲍伯立即拿到 0.5BTC（C1a的第二个输出），而爱丽丝需要等 C1a 得到 1000 个确认，才能通过 RD1a的输出拿到 0.5 BTC。另一方，若鲍伯广播 C1b，则爱丽丝立即拿到 0.5BTC，鲍伯等待 C1b 得到 1000 个确认，才能通过 RD1b 拿到0.5BTC。也就是说，单方广播交易终止合约的那一方会延迟拿到币，而另一放则立即拿币。

    • 交易更新

      • image-20230619162301962
        爱丽丝和鲍伯各自 0.5 BTC 的余额，此时爱丽丝从鲍伯处购买了一件商品，价格为 0.1 BTC，那么余额应该变为爱丽丝 0.4 BTC，鲍伯 0.6 BTC。于是创建新的 Commitment Tx，对于爱丽丝来说是 C2a 和 RD2a，对于鲍伯来说是 C2b 和 RD2b，过程与上面类似。
      • image-20230619162313565
        爱丽丝交出爱丽丝2 的私钥给鲍伯，那么鲍伯就可以修改 RD1a 的输出给他自己，形成新的交易 BR1a。若爱丽丝破坏合约存在C2a的情况下依然广播出C1a，那么爱丽丝的惩罚就是失去她全部的币。爱丽丝交出爱丽丝2的私钥，或者对交易BR1a进行签名，两者是等同的，都是对C1a的放弃。 反之亦然，鲍伯交出鲍伯2的私钥给爱丽丝即意味放弃C1b，而仅能认可C2b。 引入sequence的目的是，阻止后续交易进块（RD1a），给出一个实施惩罚窗口期，当发现对方破坏合约时，可以有1000个块确认的时间去实施惩罚交易，即广播BR1a代替RD1a。若错过 1000 个块时间窗口，则无法再实施惩罚了（RD1a进块了)

    • 交易关闭
      关闭 RSMC，直接按照最终的余额构造出一个Commitment TX即可，例如输出为爱丽丝0.1BTC，鲍伯0.9BTC，无需再设置多重签名，构造惩罚交易等。

    • 总结

      支付通道是两个参与者开设的一对一合约，其设计目标是允许双方无限次地相互支付、并且支付无需真正用到区块链（显然，如果需要用到区块链，从概念上来说就做不到 “无限次” 相互支付了）。 具体的方法是：让双方把资金锁入一个只有双方都同意才能解锁的保险箱（UTXO），然后，双方通过交换带签名、可被覆盖的交易来表示和更新双方的所有权状态（也即双方的余额），从而实现支付的效果；这些交易都是有效的交易，因此它们可以随时拿到区块链上执行，因此这些交易无需得到区块链的确认，依然能为支付提供安全性； 又因为这些交易不会用到区块链，而且发送较旧的交易到区块链上（也即欺诈对手）会遭受惩罚，所以双方可以无限次地相互支付；最后，当双方（或某一方）想退出通道时，只需发送一笔交易到链上，即可结算合约。

      • 缺点
        • 场景有限
          • 只适用于小额支付场景
        • 资金占用率较高
          • 多个通道资金独立
      • 优势
        • 某种程度上扩容了 BTC 交易处理能力
        • 节省交易费用
      • 对比特币的影响
        • 增加了交易场景但减少了矿工的收入
        • 比特币的发行与手续费问题

HTLC (Hashed Timelock Contract) 哈希时间锁合约

HTLC解决了币跨节点传递的问题 HTLC 的核心是时间锁和哈希锁。时间锁指，交易双方约定在某个时间内提交才有效，超时则承诺方案失效（无论是提出方或接受方）。哈希锁指，对一个哈希值 H，如果提供原像 R 使得 Hash ® = H，则承诺有效，否则失效。如果交易因为各种原因未能成功，时间锁能够让交易参与各方拿回自己资金，避免因欺诈或交易失败造成的损失。接下来，我们用一个例子说明 HTLC 工作流程。

  • 中转交易(路由)

    假设 Alice 想开启一个与 Bob 的交易，交易金额为 0.5 BTC，但 Alice 需要通过 Carol 才能与 Bob 建立通道进行交易:

    • image-20230619162336888
    • image-20230619162346691
    • 第一步： Bob 设定原像 R （也被称为暗示数），把哈希值 H = Hash(R) 告诉 Alice。
    • 第二步：Alice 通过 HTLC 向 Carol 进行条件支付：当且仅当 Carol 在 T 时刻前提供与哈希值 H 对应的原像 R，Alice 才向 Carol 支付 0.5 BTC。类似地，Carol 通过 HTLC 向 Bob 进行条件支付：当且仅当 Bob 在 t 时刻前提供与哈希值 H 对应的原像 R，Carol 才向 Bob 支付 0.5 BTC，其中 t<T。
    • 第三步： Bob 如果在 t 时刻前向 Carol 提供 R，获得 0.5 BTC，此时 Carol 知悉 R。反之，0.5 BTC 会返回给 Carol，Carol 不会遭受任何损失。
    • 第四步：Carol 如果在 T 时刻前向 Alice 提供 R，获得 0.5 BTC。反之，0.5 BTC 会返回给 Alice，Alice 不会遭受任何损失
    • HTLC 效果
      • 第一，在参与者理性前提下，HTLC 中所有「条件支付」要么全部完成，要么全不完成但所有参与者都能拿回自己的资金，因此是原子式的（ Atomic ）。这是序贯博弈均衡的结果。
      • 第二，原像 R （信息）和资金相向流动，原像 R 可以被视为收据（ Receipt ）。在 HTLC 中原像和哈希值的传输可以全部在链下完成，链上只做相关内容的检验，因此可以有效保护客户隐私信息。
      • image-20230619162406287

  • HTLC 主要特点

    • 时间敏感性
      HTLC 机制对交易时间的敏感性使得交易发起者不必浪费时间持续等待以确定他们的付款是否通过。如果设定时间已过，资金将被退回交易发起者，能够有效避免恶意拖延交易，降低交易对手风险。
    • 去信任化
      HTLC 的最大优势是去信任化。HTLC 消除了对中心化交易和受信任中介的依赖。交易可以经由两方或多方执行而不需要它们彼此信任。由于用户不需要将资金提供给第三方托管机构，安全性也会相对提高。交易可以直接从用户的个人钱包发起，大幅地降低了第三方参与的风险。
    • 跨资产交互性
      在 HTLC 中，资金锁定实现了质押效果，为不同资产之间的交易提供了信任基础。而原像及哈希秘钥的传递，则保证了交易的原子性。

  • 总结

    • 优点
      • 充分利用 RSMC 的技术特性与优势, 建立快速支付网络
      • 无需第三方协调即可完成
      • 理论上支持多跳
    • 缺点
      • 资金利用率低
      • 支付金额最大值受限于状态通道中的代币上限

UTXO 模型 (Unspent Transaction Outputs)

transaction-based ledger (BTC) / Account-based ledger (ETH)

  • image-20230619162632925
  • 特点
  • 优点
    • 允许并行交易
    • 能够快速有效的追溯交易和资产
    • 根据 UTXO 模型可以让所有比特币节点在任意时刻就比特币的资产状态达成共识
    • 易于独立验证
  • 缺点
    • UTXO 模型无法支持很好的应用扩展性

哈希函数

散列函数（英语：Hash function）又称散列算法、哈希函数，是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。该函数将数据打乱混合，重新创建一个叫做散列值（hash values，hash codes，hash sums，或hashes）的指纹。散列值通常用一个短的随机字母和数字组成的字符串来代表。

  • 性质

    • 定义里面讲的是哈希函数接收任意长度的输入，但在实际实现中，大家都会指明一个具体可接收的阈值，例如SHA-2最高接受(2^64-1)/8长度的字节字符串。此处需要理解的是哈希函数拥有较为庞大的输入值域，它接受长度非常长的输入值。
    • 产生固定长度的输出值
    • 不可逆性，已知哈希函数fn与x的哈希值无法反向求出x，当然这里的不可逆是指计算上行不通，正着算很好算，反着算在当前的计算机计算能力条件下做不到。
    • 对于特定的哈希函数，只要输入值不变，那么输出的值也是唯一不变的。
    • 哈希函数的计算时间不应过长，即通过输入值求出输出值的时间不宜过长。
    • 无冲突性，即对于输入值x，与哈希函数fn，无法求出一个值y，使得x与y的哈希值相等。
    • 由于哈希函数实际上代表着一种映射（对应关系），将一个大区间上的数值映射到一个小区间上，它一定是有冲突的，这里的无冲突同样是指“求冲突在计算上行不通”，正向地计算很容易
    • 即使修改了输入值的一个比特位，也会使得输出值发生巨大的变化。
    • 哈希函数产生的映射应当保持均匀，即不要使得映射结果堆积在小区间的某一块区域。

  • 常见算法

    • image-20230619162850945

  • 应用场景

    • 保护数据，散列值可用于唯一地识别机密信息，这个应用场景是基于属性“无冲突”的特性，实际上各种散列函数为了实现更强的抗碰撞，都有各自更加复杂的设计。
    • 确保传递真实的消息，这个实际上是“数字签名”的内容。人们通过哈希函数获得“指纹”（摘要），打包原文与“摘要”一同发送，接收者只需要将原文进行一次哈希后与“摘要”进行匹配即可。那么如果有人将“摘要”与原文配套修改了怎么办，那我岂不是被欺骗了？实际上摘要的安全性一般还要由加密来保证，关于公钥私钥的加密解密的内容好文也有很多，此处超纲不谈。
    • 散列表，这应当是最经典的用法了，在学校我们学习散列表时都会提及，散列表是数组加链表的组成，上文我们举的关于“电话簿”的例子其实就类似于散列表的定义。
    • 错误校正，这个概念同样很好理解，假设小A给小B发送一封信件，由于此信件过大，发送的时候需要拆分成三分标序后发送，到达目的地再行组装。那么，如何保证组装的数据顺序没错呢？如何保证数据发送的过程中没有丢包呢？我们只需要携带一份原完整信件的哈希值（摘要）一同发送即可，到达目的地的数据拼装好后，调用哈希函数进行一次哈希，将得到的数据与摘要进行匹配，无误则说明数据完整。

  • SHA256

    • 技术原理

      • 常量初始化

        • 8 个哈希初值
          对自然数中前8个质数（2,3,5,7,11,13,17,19）的平方根的小数部分取前 32bit 而来
        • 64 个常量
          这些常量是对自然数中前64个质数(2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79,83,89,97…)的立方根的小数部分取前32bit而来

      • 信息预处理(pre-processing)

        在想要Hash的消息后面补充需要的信息，使整个消息满足指定的结构。

        • 附加填充比特

          在报文末尾进行填充，使报文长度在对 512 取模以后的余数是 448

          • 先补第一个比特为 1，然后都补 0，直到长度满足对 512 取模后余数是 448
          • 信息必须进行填充，也就是说，即使长度已经满足对 512 取模后余数是 448，补位也必须要进行，这时要填充 512 个比特
          • 举例说明
            以信息“abc”为例显示补位的过程。
          • a,b,c 对应的ASCII码分别是 97,98,99
          • 于是原始信息的二进制编码为：01100001 01100010 01100011 补位第一步，首先补一个“1” ： 0110000101100010 01100011 1
          • 补位第二步,补 423 个“0”：01100001 01100010 01100011 10000000 00000000 … 00000000
          • image-20230619162922191

        • 附加长度值

          将原始数据（第一步填充前的消息）的长度信息补到已经进行了填充操作的消息后面

          • SHA256 用一个 64 位的数据来表示原始消息的长度。
          • 通过 SHA256 计算的消息长度必须要小于 2^64，当然绝大多数情况这足够大了。
          • image-20230619162930628
          • 最终补完以后的消息二进制位数长度是512的倍数.

      • 分段处理

      • 逻辑运算与公式定义

        • image-20230619162936793
        • image-20230619162941683
          计算公式定义

      • 计算消息摘要

        整个算法需要做的就是完成 n 次迭代，n 次迭代的结果就是最终的哈希值，即 256bit 的数字摘要。

        • 将补码处理后的消息以 512 位为单位分成 N块

          Chunk i = M(i)

          • image-20230619162946864

        • 对每个块进行处理，构造64个字（word）

          对于每一块，将块分解为 16 个 32-bit 的 big-endian 的字，记为w[0], …, w[15]

          • 每段消息分成 16 个 32 位的字组
            第 i 消息块的前 32 位表示为: M0(i) ,第二个 32 位为 M1(i), 以此类推, 最后 32 位的消息块可表示为: M15(i).
          • 其余的字由计算公式得到：计算如下
            • image-20230619162952182

        • 64 次循环计算

          • 第一次循环将使用初始化的 8 个哈希初值
            • image-20230619162957156
            • image-20230619163001203
          • K1，K2，…..K63 为初始化的64个常量值
          • 计算Ch(e,f,g), Maj(a,b,c), ∑0(a), ∑1(e),Wj
            • image-20230619163006701
            • image-20230619163012261
            • image-20230619163016252
              计算第 i 个中间哈希值 H(i)

    • SHA256 在比特币中的应用

      • 数据摘要
        • 区块信息摘要
        • 哈希指针
      • 加密计算
      • PoW 挖矿计算
      • 挖矿难度计算

节点类型与职能

  • image-20230619163113258

  • 全节点（ Full Node ）

    全节点是一个程序，例如中本聪自己写的 Bitcoin Coin 这个程序运行起来之后，会把整条区块链都下载到本地。

    • 需要保持一直在线
    • 在本地硬盘上维护完整的区块链信息
    • 在内存里维护 utxo 集合, 以便快速检验交易的正确性
    • 监听比特币网络上的交易信息, 验证每个交易的合法性
    • 决定哪些交易会被打包到区块里
    • 监听别的矿工挖出来的区块, 验证期合法性
    • 挖矿(构建区块)
      • 决定沿着哪条链挖下去
      • 但出现登场的分叉的时候, 选择哪一个分叉

  • 轻客户端（ Thin Client )

    轻客户端可以安装在电脑上也可以安装在手机上，为啥呢？因为轻客户端只会去下载区块头，每个区块头只有80K，所以一条区块头组成的链，只有几十兆。

    • 不是一直在线
    • 不用保存整个区块链, 只要保存每个区块的块头
    • 不用保存全部交易, 只保存与自己相关的交易
    • 无法检验大多数交易的合法性, 只能检验与自己相关的那些交易的合法性
    • 无法检测网上发布的区块链的正确性
    • 可以验证挖矿难度
    • 只能检测哪个是最长链, 不知道哪个是最长合法链

比特币交易原理 0.5

  • UTXO 模型 (Unspent Transaction Outputs)
  • 交易形式
  • 当 A 说给 B 支付了1个比特币的时候 他需要证明(第三方验证所需要的信息)
    • 你是从哪里获得这些比特币的?
    • 你的比特币地址是多少?
    • B 的比特币地址是多少?
    • 你的公钥是什么?
    • 你用私钥生成的数字签名。
  • 对交易的每个输出 TxOut，需要有
    • 这个 UTXO 的币值
    • 锁定脚本 Script
  • 对交易的每个输入 TxIn，需要有
    • 这笔 UTXO 来自之前哪笔交易的第几个输出（需要表达交易链条）
    • 解锁脚本 Script
  • 交易 hash 的生成 —— 序列化和反序列化
    在传输前需要将数据结构转换成方便网络传输的字节流形式，这个过程称为序列化(serialization)。 https://tool.oschina.net/hexconvert/ 进制转换

签名的验证

  • 交易发送至其它节点后，其它节点会对其进行验证，只有验证通过的
  • 交易才会被继续传播。交易验证的项目很多，这里只讲关于签名的验证。

核心点

  • 证明交易所引用的 UTXO 的确属于付款人

  • 证明交易的所有数据的确是付款人提供的，且未被修改过

验证过程

用解锁脚本解锁对应 UTXO 的锁定脚本，对应上图就是橙色线所连接的两个脚本： <PubK(B)> OP_DUP OP_HASH160 <PubKHash(B)> OP_EQUALVERIFY OP_CHECKSIG

  1. 入栈

  2. <PubK(B)> <PubK(B)>入栈

  3. OP_DUP 复制位于栈顶的<PubK(B)> ,将副本置于栈顶。

  4. OP_HASH160 对位于栈顶的<PubK(B)>副本进行 HASH160,<PubK(B)>转变为<PubKHash(B)>。

  5. <PubKHash(B)> <PubKHash(B)>入栈

  6. OP_EQUALVERIFY 比较位于栈顶的两个元素是否相同，若相同则移除这两个元素，继续执行。若不同，则中断执行，返回失败。

    1. 到这里就完成了证明交易所引用的 UTXO 的确属于付款人的流程

  7. OP_CHECKSIG 检查签名（注意栈内现有的元素为<PubK(B)>）,根据结果返回成功或失败。

    1. ECDSA：The Elliptic Curve Digital Signature Algorithm

2 7 OP_ADD 3 OP_SUB 1 OP_ADD 7 OP_EQUAL 结果是多少

P2PKH (Pay To Public Key Hash) 最常用

Pay-to-PubKeyHash 是一种传统的比特币地址格式。其地址以数字 1 开头。

  • 更多的条件可以是：
    • 解锁 BTC 至少需要两个签名
    • 提供口令（password）才能解锁
    • BTC 需要等待一段时间才能解锁
  • 发送方需要在交易中包含 PubKey 脚本
    因此，这会增加交易的体积，产生的交易费比普通交易高出 5 倍左右。
  • 为什么 不直接存放 pubKey 而放 pubKeyHash ?

区块高度

  • 第一个区块，其区块高度为 0
  • 和之前哈希值 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 所引用的区块为同一个区块
  • 区块哈希值或者区块高度
  • 和区块哈希值不同的是，区块高度并不是唯一的标识符。虽然一个单一的区块总是会有一个明确的、固定的区块高度， 但反过来却并不成立，一个区块高度并不总是标识一个唯一的区块。
    • 提示一个区块的区块哈希值总是能唯一地标识出一个特定区块。一个区块也总是有特定的区块高度。但是，一个特定的区块高度并不一定总是能唯一地标识一个特定区块。更确切地说，两个或者更多数量的区块也许会为了区块链中的一个位置而竞争

以太坊技术

  • 特点
      1. 支持图灵完备的智能合约，设计了编程语言 Solidity 和虚拟机 EVM
      1. 采用账户系统和世界状态，而不是 UTXO，容易支持更复杂的逻辑
      1. 选用了内存需求较高的哈希函数，避免出现强算力矿机、矿池攻击
      1. 叔块（Uncle Block）激励机制，降低矿池的优势，并减少出块时间（10 分钟降低到 15 秒左右）
      1. 通过 Gas 限制代码执行指令数，避免循环执行攻击
      1. 最开始是 PoW 共识算法，2022 年转为 PoS 算法

UTXO的不足

  • 缺少图灵完备性（lack of turing-completeness）。尽管比特币的脚本语言可以支持多种计算，但是它不能支持所有的计算。
  • 价值盲（value-blindness）。UTXO 脚本不能为账户的取款额度提供精细的控制。
  • 缺少状态（lack of state）。UTXO 只能是已花费或者未花费状态，这意味着 UTXO 只能用于建立简单的、一次性的合约。
  • 区块链盲（blockchain-blindness）。UTXO 看不到区块链的数据，比如区块头部的随机数、时间戳和上一个区块数据的哈希值。

以太坊账户 1.5

  • 以太坊被称为 account-based ledger

    账户余额模型可以比较好的防止双花

    • image-20230619164440661
    • 如何避免双花
      通过将 nonce 放入签名的交易来避免

  • 账户类型

    • EOA 账户 - externally owned account
      • balance 此地址的以太币余额
      • nonce —— 计数器 - 外部账户为交易次数
    • 合约账户 - smart contract account
      • balance
      • nonce – 合约账户为创建的合约序号
      • code – codeHash：账户EVM代码的 hash 值。合约账户即为合约代码的哈希值，外部账户为空字符串的哈希值
      • storage – storageRoot：账户存储内容组成的默克尔树根的哈希值。
    • 共同点
      • 接收、持有和发送 ETH 和 token
      • 与已部署的智能合约进行交互
    • 区别
      • 外部账户 EOA
        • 创建帐户是免费的
        • 可以发起交易
        • 外部所有的帐户之间只能进行以太币和代币交易
        • 由一对加密密钥组成：控制帐户活动的公钥和私钥
      • 合约账户
        • 创建合约存在成本，因为需要使用网络存储空间
        • 只能在收到交易时发送交易
        • 从外部帐户向合约帐户发起的交易能触发可执行多种操作的代码，例如转移代币甚至创建新合约
        • 合约帐户没有私钥。 相反，它们由智能合约代码逻辑控制

什么是 GAS？

  • Gas 是指在以太坊网络上执行特定操作所需的计算工作量

  • 为什么需要 GAS

    由于每笔以太坊交易都需要计算资源才能执行，每笔交易都需要付费。 在这个方面上，Gas 是指在以太坊成功进行交易所需的费用。

    • 燃料费用有助于确保以太坊网络的安全
      在网络上执行的每次计算都需要收费，这样可以防止不良行为者给网络带来垃圾信息。
    • 为了防止代码中出现无意或恶意的无限循环或其他计算浪费，要求每个交易对可以采用的代码执行计算步骤设置一个限制。

  • Gas 费用是以太坊的货币以太 (ETH) 支付的
    Gas 价格以 Gwei 标明，Gwei 本身就是 ETH 的一个单位――每个 Gwei 等于 0.000000001 ETH (10-9 ETH)。

  • “gwei”一词本身表示“giga-wei”，等于 1,000,000,000 wei
    Wei 本身（以 b-money 的发明者 Wei Dai 命名）是 ETH 中最小的单位。

  • 问题

    • 如何衡量智能合约代码所需要的 Gas 消耗?
    • 如何精确的预估还未上链的交易的 Gas 量

Gas 的基本机制

  • 每笔交易必须指明自身愿意消耗的 gas 数量 (Gas Limit) 以及愿意为每单元 gas 支付的费用（即 gasprice ）
  • 交易执行期间的所有操作，包括读写数据库、发送消息以及每一步的计算都会消耗一定数量的 gas
  • 如果交易执行完毕，消耗的 gas 值小于指定的限制值，则交易执行正常，并将剩余的 gas 值赋予变量 gas_rem ; 在交易完成后，发送者会收到返回的 gas_rem * gasprice 价值的以太币，而给矿工的奖励是（startgas - gas_rem）* gasprice 价值的以太币；
  • 如果交易执行中，gas消耗殆尽，则所有的执行恢复原样，但交易仍然有效，只是交易的唯一结果是将 startgas * gasprice 价值的以太币支付给矿工，其他不变；
  • 当一个合约发送消息给另一个合约，可以对这个消息引起的子执行设置一个 gas 限制。如果子执行耗尽了 gas，则子执行恢复原样，但 gas 仍然消耗
  • 思考几个问题
    • 如果不指定 Gas fee 会有什么后果
    • 如果我们用执行时间来预估 Gas 可行吗
    • 能不能不使用提前指定+退回的方式, 而是一边执行一边扣除 Gas?
    • 如果合约调用合约的子限制不存在, 会不会有问题?
    • 如果不用使用者来支付 Gas fee, 使用合约来支付, 可行吗

MPT 的在以太坊的应用

  • 状态树：涉及到以太坊平台账号及合约账号的数据存储。
    • 查找的键值是地址
    • 结构是全局的
  • 交易树：每一个区块中的每笔交易内容(from, to, gas, data 等等)构建的交易树
    • 查找的键值是交易哈希
    • 结构是按照区块独立的
  • 收据树：以太坊中的每一笔交易都有对应的收据，收据树的信息是为了方便一些相关账户的查询。
    • 查找的键值是交易哈希
    • 结构是按照区块独立的

是什么导致了燃料费的变化?

  • 网络拥堵的情况
  • 合约的执行步骤
    • 存储操作:在区块链上读写存储都需要消耗Gas读存储消耗较少,写存储消耗较多
    • 算术运算:任何算数运算如加减乘除都需要消耗一定的 Gas。复杂的运算会消耗更多的Gas。
    • 循环和嵌套调用都会按照 QU
    • ADRATIC PLAN消耗Gas。所以需要避免无限循环和过多的嵌套调用。
    • 调用其他合约: 当一个智能合约调用另一个智能合约时,都会产生Gas 消耗。如果被调用的合约过于复杂,会消耗较多的Gas。
    • 存储变量类型:存储复杂变量如映射和数组会比简单变量消耗更多的Gas
  • 优先级的争夺
  • 如何优化?

PoW 优缺点

  • 优点
    • 无门槛无许可
      工作量证明并无对错。 你不需要以太币来启动，出块奖励允许你从 0 ETH 获得正的收益。 而在权益证明中，你需要以太币来启动获取收益的过程。
    • 稳定安全
      工作量证明是一个经过考验和测试的共识机制，多年来一直保持了比特币和以太坊的安全性和去中心化。
    • 容易实施
      与权益证明方式相比，工作量证明是比较容易实施的。
  • 缺点
    • 工作量证明消耗了大量能源，对环境不利。
    • 如果你想要挖矿，需要花大量的启动资金去购买专业设备。
    • 算力的不断增加，矿池可能会主导挖矿过程，导致中心化和安全风险。

POS

  • 优缺点
    • 相对 PoW 的优势
    • 优点
      • 质押使个人更容易参与其中保障网络的安全，促进去中心化。
      • 验证者节点可以在普通笔记本电脑上运行。
      • 质押池让用户可以在没有 32 个以太币的情况下质押。
      • 权益质押更加去中心化。 规模经济不像适用于工作量证明挖矿那样适用于权益证明。
      • 权益证明的加密经济安全性高于工作量证明
      • 需要发行较少的新以太币就可以激励网络参与者
    • 缺点
      • 与工作量证明相比，权益证明仍处于起步阶段，并且经过的实践检验较少。
      • 实现权益证明比实现工作量证明更加复杂。
      • 用户需要运行三种软件才能参与以太坊的权益证明。
        • beacon chain
        • eth 执行节点
        • eth 验证人