当前位置: 首页 > article >正文

以太坊学习

以太坊原理书

区块链的一些基础概念

账户是什么

以太坊的账户共分成两类,外部账户 (Externally Owned Account, EOA ) 与 智能合约 (Contract Account, CA )。

外部账户由 一把私钥 与该私钥对应的公开地址来表示,是普通用户的账户。智能合约账户 没有私钥 ,仅有公开的地址,它的行为由合约自身包含的代码逻辑来控制。

  • nonce 已执行交易总数,用来标示该账户发出的交易数量;
  • balance 持币数量,记录用户的以太币余额;
    • 持币数量包含了该账户当下可花费的以太币的数量。外部账户和智能合约都可以持有以太币。
  • storage hash(智能合约独有) 存储区的哈希值,指向智能合约账户的存储数据区;
    • 存储区即为智能合约在运行中,产生的数据的存储地。 在合约的生命周期里,该区域的内容被合约代码不断写入、读取。 存储区存放于以太坊网络节点的硬盘上。 存储区的内容通过散列函数得出校验哈希值,该值即为存储区的哈希值。
  • code hash(智能合约独有) 代码区的哈希值,指向智能合约账户存储的智能合约代码。
    • 代码区即为智能合约代码本身。 在合约的生命周期中,该区域的内容是不可更改的 只读状态。 代码区存放于以太坊网络节点的硬盘中,当运行时被读入虚拟机执行。代码区的内容通过散列函数得出校验哈希值,该值即为代码区的哈希值。

什么是区块

在这里插入图片描述
区块(block) 是多个合法签名的 交易的有序集合 。任何一个区块都包含几部分:其前一区块的哈希值、当前区块的哈希值、一个计算工作量的参数、一个时间戳以及该区块包含的交易列表的哈希值。在区块模型中,交易列表会用一棵树型结构来表示,并将该树的哈希值写入区块头进行防伪校验。哈希值的数据量较少,方便网络传输。

区块是 串联 成区块链的,一个区块包含了数笔交易。

区块的样子

以太坊对的区块定义是一个对象,包含了区块头区块体两个组成部分。

区块头 较为轻量级,包含了一系列的数值、引用的数值以及哈希值, 总长度在 508Byte 左右;

区块体 较为重量级,包含了该区块收纳的交易列表和叔块列表,长度视包含的交易多寡而定,目前在 20KB 左右 。

完整的区块的内容如下表所示

在这里插入图片描述

区块信息
区块的第一部分信息,包含了仅与本区块相关的内容,和其他部分相对独立。

  • Number 区块编号:表明矿工希望该块参与哪个高度的区块竞选。
  • Timestamp 时间戳:该区块被挖掘出的时间,以秒为单位的 Unix标准时间戳。
  • Hash :该区块的整体数据的哈希值,和本区块内容唯一对应。
  • ParentHash 父块哈希值:本区块基于前一个区块的哈希值,该哈希值唯一指定了前一个区块是哪块。
  • Nonce :挖掘以太坊区块所需的工作量证明算法的一个参数,重要性处在挖矿概念的核心位置。不断调整该参数代入工作量证明算法最终能产出满足共识机制的特殊结果值。
  • ExtraData :区块额外数据 Hex 值(可选),由打包的矿工来填写,该值的数据自由度高,例如高度为 #5907648 的区块,该值填写的是“七彩神仙鱼”,是一个昵称。

挖矿/矿工信息
区块的第三部分信息,包含了与挖矿相关的数据,这些数据都是挖矿过程中设置的硬指标或者挖矿消耗的花费信息。

  • miner 矿工地址:发掘该区块的矿工的公开地址,挖矿奖励将直接发送给该地址。
  • gasLimit 区块最大消耗 gas 上限: 规定了单一区块所有交易集合所能够消耗的 gas 花费最大值。该上限保证了矿工出块的速度、限制每个矿工能够打包的交易数目。这个值可以根据矿工投票与协议而调整。
  • difficulty 难度值:当前块的挖矿难度值,该值通过两次区块被挖掘之间的时间来动态调整。这个值的计算代表了矿工在计算工作量证明时候面临的难度,保障区块的出块速度在15秒左右的水平。
  • totdifficulty 总难度值: 在目前区块之前的所有区块链中区块包含的所有难度值总和。该值的高低暗示了当前这条链的总难度是否是竞争数条链中最高的,难度积累最大的链条即为最长的链条。
  • size 区块体积:当前区块的总体积,用字节 Byte 为单位来表示。
  • sha3uncles 叔块集合的哈希值:当该区块包含对叔块引用时,这些叔块数据的哈希值填入该值,作为校验手段。

区块体
区块的第四部分信息。区块体是区块中占大头的数据区域,可以占领到 75% 以上的区块空间。它包含了交易数据的列表,以及引用的叔块的列表。

  • transactions 交易列表: 所有入选该区块的交易的哈希值列表,每个哈希是一个 32字节 的数据。根据哈希值,可以用客户端在以太坊节点上唯一查询该笔交易。
  • uncles 叔块列表:所有该区块引用的叔块的哈希值的列表,每个哈希也是一个 32字节 的数据。根据该值可以唯一在区块链上查询该区块。叔块是未能成功竞争进入区块链的区块。被成功引用的叔块可以获得少量奖励。

完整的区块的示意图,图中中间区域是以太坊的区块
在这里插入图片描述

开源的区块链平台

以太坊(Ethereum)

除了以太坊之外,市面上还有许多其他开源的区块链平台,支持不同的用例和技术特点。以下是一些主要的开源区块链平台:

  1. 比特币(Bitcoin)
    主要用途:数字货币
    特点:比特币是第一个区块链平台,专注于作为点对点的数字货币系统。它的设计目标是实现去中心化的、安全的、抗审查的支付系统。
    共识机制:工作量证明(PoW)
    开发语言:C++
    适用场景:主要用于数字支付和价值转移。
    Bitcoin GitHub Repository
  2. Hyperledger Fabric
    主要用途:企业级区块链
    特点:由Linux基金会托管的开源区块链项目,专注于企业应用。Hyperledger Fabric具有模块化架构,支持可插拔的共识机制,允许企业定制解决方案。Fabric还支持私有链和许可链。
    共识机制:多种(Raft、Kafka等)
    开发语言:Go、Java、JavaScript
    适用场景:企业供应链管理、金融服务、医疗等领域的区块链解决方案。
    Hyperledger Fabric GitHub Repository
  3. Polkadot
    主要用途:跨链互操作性
    特点:Polkadot专注于解决不同区块链之间的互操作性问题。它通过"中继链"和"平行链"架构,允许不同的区块链进行通信和数据交换。
    共识机制:Nominated Proof of Stake (NPoS)
    开发语言:Rust
    适用场景:多链生态系统,跨链资产转移和跨链智能合约调用。
    Polkadot GitHub Repository
  4. Cardano
    主要用途:可扩展的智能合约平台
    特点:Cardano是一个基于科学研究和严格的同行评审而设计的区块链平台。其目标是提供更加安全和可扩展的智能合约平台,同时减少能耗。
    共识机制:Ouroboros(权益证明,PoS)
    开发语言:Haskell
    适用场景:智能合约、去中心化应用(DApps)、金融服务。
    Cardano GitHub Repository
  5. EOS.IO
    主要用途:高性能的去中心化应用平台
    特点:EOS.IO是一个支持高性能和低延迟的区块链平台,旨在为去中心化应用(DApps)提供高吞吐量和低交易成本。它通过区块生产者来治理网络。
    共识机制:Delegated Proof of Stake (DPoS)
    开发语言:C++
    适用场景:去中心化应用、社交网络、金融服务等。
    EOS.IO GitHub Repository
  6. Corda
    主要用途:企业区块链,专注于金融服务
    特点:Corda是专为企业设计的分布式账本技术(DLT)平台,最初由R3财团开发。Corda允许跨组织的直接交互,并且支持隐私保护,适用于金融、供应链、保险等行业。
    共识机制:Notary服务(用于交易的确定性)
    开发语言:Kotlin、Java
    适用场景:金融行业、供应链、政府等领域。
    Corda GitHub Repository
  7. Tron
    主要用途:内容分享和去中心化应用
    特点:Tron是一个专注于去中心化娱乐内容分享的区块链平台,目标是为内容创作者提供去中心化的平台,从而避免对中心化内容分发平台的依赖。
    共识机制:Delegated Proof of Stake (DPoS)
    开发语言:Java
    适用场景:去中心化应用、内容分享、NFT、社交平台等。
    Tron GitHub Repository
  8. Tezos
    主要用途:自我升级的区块链平台
    特点:Tezos具有自我治理和自我升级的能力,允许协议规则在链上进行变更而无需硬分叉。它专注于降低区块链的分裂风险,同时支持智能合约和DApps开发。
    共识机制:Liquid Proof of Stake (LPoS)
    开发语言:OCaml
    适用场景:智能合约、DApps、去中心化金融(DeFi)。
    Tezos GitHub Repository
  9. Avalanche
    主要用途:高吞吐量、可定制区块链网络
    特点:Avalanche支持用户创建自定义的区块链和子网,提供高吞吐量和快速确认时间,允许通过模块化架构来设计不同应用的区块链。
    共识机制:Avalanche Consensus (PoS)
    开发语言:Go
    适用场景:去中心化金融、企业应用、代币化资产等。
    Avalanche GitHub Repository
  10. Solana
    主要用途:高性能区块链,专注于去中心化应用和DeFi
    特点:Solana是一个以高吞吐量和低延迟为设计目标的区块链平台,能够处理大规模的交易量,适用于DeFi、去中心化应用和NFT市场。
    共识机制:Proof of History (PoH) + Proof of Stake (PoS)
    开发语言:Rust、C++
    适用场景:DeFi、去中心化应用、NFT等。
    Solana GitHub Repository

生成钱包地址和私钥

首先使用一个可靠的随机源来产生 32 bytes 的随机数,即为私钥,然后使用 ECDSA-secp256k1 算法,带入私钥计算出公钥,这个过程是不可逆的,并且是唯一与私钥对应的。再将其进一步放入一个哈希算法生成哈希值,截取哈希值的最后40位16进制字符得到地址(160 bits或20 bytes)。

私钥地址空间有 2 256 2^{256} 2256,而宇宙中的已知原子总数有 1 0 80 10^{80} 1080 2 256 ÷ 1 0 80 ≈ 1 0 69 2^{256} \div 10^{80} \approx 10^{69} 2256÷10801069。可以说在全人类都参与使用加密货币的情况下,即使每次交易都使用新的地址, 碰巧遇上他人私钥的概率比生活中选中一个原子去砸中另外一个原子的概率还要小。

交易

交易的发送

客户端软件通过 web3 与向网络发送交易的示意图
客户端软件通过 web3 与向网络发送交易的示意图

交易分为简单的转账交易与智能合约调用,收到交易请求的节点进行相应的余额变更或者执行合约代码,在这个过程中是要消耗计算机算力、 内存与占用硬盘存储空间的。
相应地,该交易发起者也需要支付交易费来承担该计算行为,交易是用以太币支付的。

用户与以太坊互动的行为只有一种:发送交易。 以太坊上的交易活动是由三个步骤完成的:

  • 用户签名打包一条或多条消息,组装成一笔交易,发送到以太坊网络上。
  • 该交易被矿工捕获,并收纳入某一个区块。
  • 区块形成后,被矿工广播到节点网络中,最终加入区块链。

交易与消息的区别

在以太坊中,经常混淆的两个概念是交易 transaction 与消息 message

交易 是外部账户发起的,可以包含一条消息。

消息 在账户与账户之间传递数据(data)与价值(value),消息的具体表现形式如下:

  • 数据:一个账户向另一个账户请求函数调用
  • 价值:一个账户向另一个账户发送以太币

举例说明:某用户调用了智能合约A的一个方法。可能会依序发生如下的效果:

  • A合约代码被运行,该方法中调用了另一个智能合约B的一个方法。(函数调用)
  • B合约代码被运行。运行中要给账户C 转账以太币。(价值转移)
  • 以上的函数调用和价值转移这类消息并不是外部可见的,不记录在区块里。

交易的特性

原子性:例如某智能合约在执行的过程中修改了一个或者数个外部账户的余额。 这些修改操作要么完全执行,要么完全不执行 ,它不会部分执行,部分不执行。哪怕智能合约在执行某些操作后出现异常而失败,之前执行成功的部分操作也会被“回滚”来撤销影响

“串行” 执行:每一笔交易都会影响世界状态的一小部分,它们发生影响的顺序不是同时的,而是一个接一个的,单一时刻只有一个交易被执行,不会有并行出现。哪怕归入了同一个区块的数笔交易,在以太坊虚拟机上也有先后的执行顺序,并不会在虚拟机中多线程并发执行。

“进入区块链的顺序不确定”:当全球的数万名用户向区块链中的节点发送交易时,交易最终进入区块链的顺序并不取决于发送的前后顺序。

消息在因特网上广播扩散的快慢,交易费用的高低等诸多因素影响着交易最终进入区块链的顺序。负责记账的矿工因为受到共识规定的约束,所以打包出来的区块内含的多个交易也可能有顺序上的排列组合的考量。

某个矿工成功打包的区块有可能不能入选最终的区块链,导致用户的交易没有在第一时间进入区块链,此时用户交易会临时等待,直到进入被另一个矿工捕获被打包。举一个例子:如下图所示,用户发出的一笔 交易A,同时被三个矿工捕获,并且和 B、C、D、E交易自由地组合在一起执行打包形成一个区块。三位矿工分别选取了任意的三条交易进行组合打包,最快被打包完成的区块胜选并进入区块链,成为最新的区块,其余两个矿工的打包完成的区块则未能入选。

在这种情形下,交易A 何时进入区块链,是否能在交易B 之前,是不确定的。
在这里插入图片描述

交易的样子

{
  nonce: web3.toHex(10),
  GasPrice: web3.toHex(100000000000),
  Gas: web3.toHex(140000),
  from: '0x633296baebc20f33ac2e1c1b105d7cd1f6a0718b',
  to: '0xD1E1cdbCE15f1009B5A7874053E09C728Df91d47',
  value: web3.toHex(0),
  data: '0xcc9ab24952616d6100000000000000000000000000000000000000000000000000000000'
}

nonce:该账户已发送交易数量,一个正整数。

交易费 = Gas x GasPrice

一般智能合约部署是开销最大的交易,因为需要声明存储空间并执行初始化操作;而交易转账则花费较少;

From 该笔交易的发送方。

To 该笔交易的接收方。

若该交易为普通以太币转账交易,则接收方为受益人账户地址;若该交易为调用智能合约的交易,则接收方为智能合约的地址;若该交易为创建智能合约,则接收方地址可空缺。

value 具体转移多少以太币到接收方。

data 数据字段。

当若进行以太币纯转账交易时,该字段可空缺;若进行为智能合约调用,则该值包含编码后的函数名和参数的字节码;若为进行合约创建,则该值包含初始化合约的字节码。

以太坊上最常见的交易是:

  • 以太币转账
  • 智能合约调用
  • 智能合约创建

这三种交易在交易发送时经历的步骤是一模一样的,区别仅在于填写交易时选择传递数据 data 还是传递价值 value

共识机制

工作量证明机制(PoW,Proof of Work),权益证明机制(PoS,Proof of Stake)

比特币的 PoW 机制(简单版)

“拜占庭将军问题”映射到比特币网络中,每台网络计算机都是“将军”,连接计算机的网络即为“信使”。在网络中的每个节点都有可能发出欺骗性的区块(假账本),这些区块能否进入区块链?是否被其他各个节点认同?为了排除错误取得网络共识, 比特币网络规定了如下实用准则:

  1. 单一区块所包含的交易集合在执行哈希后的 256bits (32字节) 的哈希值必须是一个特殊数值,它的开头必须满足一定数量的 0000... 作为起始。
  2. 区块串联形成区块链,每个链条环节(称为高度)有且仅有一个区块。
  3. 一旦找到符合条件的区块,立即广播,该区块进入该高度的候选区。候选区内可以包含多个候选者。
  4. 矿工可以从任一候选者基础上,往后计算新区块。
  5. 最高的链才是最终的区块链账本,其他较短的分支链条都不被承认,优胜劣汰。

区块重组

区块重组(Reorganization 或 Reorg)是区块链网络中的一个过程,发生在链分叉时。当节点发现当前所追随的链并不是最长链时,它会切换到更长的链,并将已经存在于较短链中的区块丢弃或放入未确认区。这一过程就是区块重组

区块重组的原理:

  • 链分叉的产生:当网络中的多个矿工几乎同时挖出不同的区块并广播到网络中时,可能会出现链分叉,即同一个区块高度上出现了多个候选区块。此时,比特币网络中会有两个(或更多)平行的区块链分支。
  • 节点选择链条:每个节点会根据自己接收到的区块来构建本地的区块链。如果节点在链分叉时收到的是某一个分支的区块,它就会暂时认为这是最长链,继续在这个链上挖矿和接收新区块。
  • 新区块加入,导致链重组:
    • 随着时间的推移,矿工们基于不同的链分支继续挖矿。如果其中一个分支链延申得更快,生成了更多的区块,这个分支就变成了最长链。
    • 当一个节点发现另一个分支变成了更长的链时(即有更多的工作量),该节点会丢弃自己之前所遵循的短链上的区块,并将其切换到新的最长链。这个切换的过程就是区块重组。
  • 交易的影响:
    • 如果某个区块被丢弃(在较短的链上),该区块中的交易会被重新放入未确认交易池(mempool),并等待重新打包到新的区块中。
    • 对用户而言,如果交易所在的区块被重组掉,交易可能需要更长时间才能被确认。
    • 由于区块重组的可能性,常规比特币交易一般需要等待6个确认,以确保交易所在的链已经成为最长链,不再容易发生重组。

矿工与挖矿奖励

谁是矿工?

某些算力较强的节点出块速度较快,这些节点能够用比他人更快的速度计算出符合共识的区块,这些为社区贡献算力出块的计算机就俗称为 矿工 。它们打包交易,组成区块,并将区块向网络广播。成功进入区块链的区块能让矿工获得 挖矿奖励

矿工怎么收集交易?

以太坊的打包过程比较直接,就是矿工在待打包池中选择一些交易来进行打包。由于需要保证一定的出块速度,维持网络的可用性,矿工一次打包的交易条数是有限制的,通过单一区块的 GasLimit来进行限制,矿工在收集交易时候不能无限制添加交易,接近 GasLimit 上限就不可以再添加了,只能等待进入下一区块。

这个上限是由算法与矿工投票共同决定,目前主网上这个数值大概是 8000000,如果你发送单一交易的时候 指定交易费的数量超过这个值,就会引发“超过单一区块 Gas上限”的错误而遭到无法打包进入区块的窘境。

以太坊区块链的等待池子中的交易可以从 etherscan.io 网站中查询 ,数据是完全公开、透明的。

绝大部分交易被记入区块的顺序是取决于交易费高低的。

低交易费等待的时间会比较久,也可能因为交易数量太多而被暂时剔除出该池子,这个现象在交易发送方看来,就是过了数小时交易也没有“确认”。在这种情况下,该交易很可能无法进入区块,更不用提进入最终的区块链。所以在发送交易的时候,我们不要设置过低的Gas交易费,以防止转账超时而影响业务。

以太坊目前每隔 15~20 秒产生一个区块

数据结构

以太坊作为一条区块链,无非就是存储了一堆“区块”。而区块的组成部分,有很大占比是“三棵大树”。

所谓的“三棵大树”,分别为 状态树 (stateRoot)、交易树 (transactionsRoot)和 收据树 (receiptsRoot)。

还有“一棵小树”, 存储树 (storageRoot)。之所以将存储树称为一棵小树,是因为该树每个账户都有,记录该账户的存储区,它是状态树的一个组成部分

状态树

在这里插入图片描述

以太坊账户分为外部账户合约账户两种。这棵树的每个叶子节点就代表了一个账户

账户若是一个智能合约账户,则必定包含了 存储树 (storageRoot)和 代码存储 (codeHash)。
存储树 是账户状态的一个 域 ,该值随着合约的存储区的增加、删除、改动而不断变更。存储树保存了智能合约的变量数据,它维持着256位的变量数据索引与RLP 算法编码过的256位数据本身。
代码存储 是只读的,它是合约账户的所执行的代码,它在合约第一次创建完毕后就不可以再变更。

交易树

每个区块都有一棵独立的 交易树 (transactionsRoot),这棵树包含了当前区块打包的所有交易。交易的排列顺序由矿工在打包时唯一确定(交易费的高低通常决定了交易在区块中的排列顺序,也影响了交易被打包的速度)。

收据树

每个区块都有一棵独立的 收据树 (receiptsRoot)。收据树中包含了执行交易期间产生的相应的收据,就和我们去超市买东西,在交易完毕后拿到的收据小票一样。

以太坊虚拟机

虚拟机执行操作

写操作则是需要花费以太币的操作,因为它更改了某一个或者数个账户的存储空间。 存储空间是区块链的一部分,是要被全世界的计算机永久同步存储的,这个更改的过程代价昂贵: 例如将一个值从 0 变为非零值需要耗费 20000 单位的gas;修改一个 非0 值需要消耗 5000 单位gas; 将一个值从 非0 赋值为 0 可以回收 15000 单位的gas;取一个变量值需要 200 gas。而相对比,从内存取变量值仅需 3 gas。

虚拟机结构

相比于台式机或者手机,以太坊的虚拟机更加紧凑,资源更加匮乏。 它并不包含正常的CPU 所具备的硬件寄存器(Register),所以执行速度没有这么快。 它的执行宽度都是 256bit 的固定长度值,所以相对比较容易编程,它包含了存储堆栈内存三大存储机构。

Storage 存储

存储区的数据都是 256bit 的键和值配对存储,如下图所示
在这里插入图片描述
索引和值都是 256位 的数据

如果查询时一个键对应的值不存在,则它读取的值为 0

存储区的读写操作都是以 256bit 为单位的,没有更小的操作空间。故而 uint8uint256 在单值存储的情况下占用的空间相同,耗费的 Gas 也相同。 将 unit8 包裹进入 struct 结构体以后可以通过优化来节约空间位置,节省 gas 支出。

Stack 堆栈

堆栈有且仅有 1024 层深度,当我们执行递归调用过多的时候,堆栈就会击穿 1024 层,则代码执行失败。

堆栈仅有高处的 16 层是可以被快速访问的,堆栈的宽度也是 256bit,也就是 32byte,一个 word 的长度,任何读写操作都是 256bit 为一个单位进行的。 编译器往往会将代码执行中的临时变量、变量地址放到堆栈上临时保存,变量地址可以进一步索引到内存 Memory 中。

数据都是 256bit 进出堆栈

Memory 内存

内存在以太坊虚拟机中和真实计算机的内存概念相近:一旦虚拟机启动,内存就处在不断变化之中,承载了程序运行时的指令和数据的保存。 一旦虚拟机执行结束并关机,内存保存的数据就会灰飞烟灭。

内存的管理办法也是按照 256bit 为单位进行读取和写入。写入时候也可以选择 8bit 为单位写入,因为内存的宽度是 8bit

内存 Memory,合约执行完毕就会自动清空。

Gas 花费与退回

发送交易的时候我们可以指定 gas 的花费上限,以防止智能合约代码有bug而导致无限循环执行下去。

一旦 gas 过早耗尽,则虚拟机抛出异常,结束代码执行。 另外有种情况是代码执行完毕后 gas 还有剩余,这时候虚拟机会按照约定退还给发送方相应的 gas 找零。

有一类情况很特殊,就是Solidity智能合约代码的 assert() 函数与 require() 函数。在执行时候这两个函数都是做真假条件判断的,但是 assert 函数感情更加强烈,往往判断的都是关键的安全性条件require() 函数则较为普通的条件判断。

assert() 函数判断一旦失败,则会扣完剩下所有的 gas 作为惩罚措施; require() 判断失败则仅仅停止目前的执行,收取执行到当前步骤相应的 gas 费用,再撤销发生的变更。

以太坊与比特币账户的区别

以太坊与比特币的账户模型,从根本设计出发点来讲是不同的。

根据以太坊黄皮书的描述,以太坊账户的概念与“银行储蓄账户”的概念相似。每个人都能开设账户,且账户初始余额为0。 当以太坊区块链运行时,不断产生的交易会往账户中增加或者减少相应的款项,账户余额随着交易的执行而变更。检索和查询账户余额的操作是便利的,仅需要找到该账户,并读取最后的账户状态即可知晓。

比特币的”Unspent Transaction Output”未花费结余模型(以下简称 UTXO)则刚好相反。比特币的概念与纸币的概念相似。 例如一个用户收到100元、20元、10元的纸币,比特币没有真正的“账户”的概念。 该用户持有的余额并不是一个单纯的总和数字,而是在此钱包中所有未花费的纸币(输出)的总和。 这就是”Unspent Transaction Output”名称的由来。

而任何支付行为也不是简单的对账户余额的加减。 支付行为是两个顺序操作的过程:

  1. 取出在钱包中未花费的数张纸币。
  2. 支付给对方相应款项,并同时创建一张面额较小的纸币,作为找零交给自身。

这个操作胜在不需要时刻保持追踪每个用户的余额,减轻了系统负担。但是,当想查询一个用户究竟有多少余额的时候,需要遍历区块链交易历史,并集齐该用户所有未花费的输出,才能计算出余额。 所幸比特币钱包软件帮助我们自动收集数据,代劳了这个枯燥的过程。

隐私与安全性的比较

比特币用户和钱包采用如下的两条准则保护用户的隐私:

  • 任一地址仅用于一次收款,一次付款。不可反复收款/付款。
  • 用户每次收款都推荐生成新的地址来接收款项。
  • 用户使用过的地址,即使余额为零也永远不删除,保留在钱包软件中

而以太坊则恰恰相反,它鼓励的是:

  • 任何地址都可以被反复使用,收款/付款不受限制。一个人对应一个地址。
  • 以太坊地址除了接收以太币,还能接收其他数字资产。

传送门

结论:比特币的隐私性更好些


http://www.kler.cn/a/301918.html

相关文章:

  • 从电动汽车到车载充电器:LM317LBDR2G 线性稳压器在汽车中的多场景应用
  • 【解决】Layout 下创建槽位后,执行 Image 同步槽位位置后表现错误的问题。
  • NFS-Ganesha 核心架构解读
  • 时钟之CSS+JS版
  • 【3D Slicer】的小白入门使用指南四
  • 【postman】怎么通过curl看请求报什么错
  • 从卷积的物理意义出发的第二种卷积计算方法
  • 《深度学习》OpenCV轮廓检测 模版匹配 解析及实现
  • Redis的C客户端(hiredis库)使用
  • ctfshow-web入门-sql注入(web249-web253)nosql 注入
  • 鸿蒙(API 12 Beta6版)超帧功能开发【ABR功能开发】
  • FastAPI+Vue3零基础开发ERP系统项目实战课 20240906 上课笔记 fastapi的各种练习
  • 【深度学习 transformer】基于Transformer的图像分类方法及应用实例
  • idea同时装了两个版本,每次打开低版本都需要重新激活破解
  • 性能测试-jmeter脚本录制(十五)
  • RK3568平台开发系列讲解(LCD篇)Framebuffer开发
  • 大佬,简单解释下“嵌入式软件开发”和“嵌入式硬件开发”的区别
  • 【Unity学习心得】如何使用Unity制作“饥荒”风格的俯视角2.5D游戏
  • 汽车驾校开设无人机培训机构技术分析
  • 第十七章 番外 共现矩阵
  • 经典文献阅读之--Multi S-Graphs(一种高效的实时分布式语义关系协同SLAM)
  • ubuntu20.04/22.04/24.04 docker 容器安装方法
  • RB-SQL:利用检索LLM框架处理大型数据库和复杂多表查询的NL2SQL
  • JAVAWeb-XML-Tomcat(纯小白下载安装调试教程)-HTTP
  • 算法设计(二)
  • 【Java OJ】弦截法求根(循环)